Subject: [mobile-ip] Tightening RR spec wrt RR between two Mobile Nodes

From: "Greg O'Shea" <[email-masked]>
Date: Fri, 2 May 2003 15:46:58 +0100

If I'm not missing something then I believe the draft 21 spec needs to
be tightened to avoid a potential weakness when RR is used between two
mobile nodes. I gather this might have previously been discussed off the
list, perhaps inconclusively, or prehaps it is buried in the issues list
somewhere, but in any case I think the spec needs tightening because the
fix is straightforward.

Assume that MN1 is abroad and has completed RR with CN, so MN1 sends
packets for CN directly without using the reverse tunnel via HA1. Then
CN moves to another network, so CN becomes MN2, and MN2 initiates RR and
sends HoTi and CoTi to MN1. At this point MN1 will send its CoT directly
towards MN2 and, since it knows MN2 has a binding for MN1, it sends its
HoT directly towards HA2's home net. This is a problem because both the
home and the care-of cookies have been exposed on MN1's foreign network,
putting MN2 at risk. In such cases RR is vulnerable to anyone who can
monitor the (arbitrarily insecure) foreign net of MN1, which is a
different scenario to the well-managed "server-only" networks
anticipated for immobile correspondents [5.2, 15.4.1].

Another case in which I expect the same thing to occur is when two
mobile have completed RR and one (or both) of them decide to refresh RR
before the existing bindings have expired, again because reverse
tunnelling of HoT is disabled due to Route Optimization.

Note: this does not necessarily happen if MN1 and MN2 run RR
simultaneously, because in the absence of a BLE for the counterparty
they will both reverse tunnel HoT via their Home Agent (I'm making the
important assumption that MN-HA reverse tunnel is IPSec ESP; but if the
tunnel is insecure then the same weakness arises in respect of both
mobiles). 

A simple solution is to require that a roaming mobile must use a secure
reverse tunnel to its home agent as the path for sending HoT while
abroad from its home network. This will render the home cookie invisible
on MN1's foreign net.

I think it is important to prevent this in the spec else mipv6 RR is
unreliable for use in mobile p2p scenarios, and since there is no way to
detect if a CN will move in future it is the case that all RR bindings
are potentially p2p. 

For example you could tighten the text in 5.2.5 under HoT, which is
ambibuous in the case of two mobiles. For example, replace this:
"The Home Test message is sent to the mobile node via the home network,
where it is presumed that the home agent will tunnel the message to the
mobile node."
With this or similar:
"The Home Test message is sent via a secure reverse tunnel to the Home
Network of the correspondent node, if the correspondent is mobile, but
in any case it is forwarded to the home network of the Mobile Node,
where it is presumed that the Home Agent of the Mobile Node will tunnel
the message to the Mobile Node."

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 May 2003 09:52:58 -0700

check issue #269. it covers the issue you raise, I think.

Vijay

> Greg O'Shea wrote:
> mobile nodes. I gather this might have previously been discussed off
> the list, perhaps inconclusively, or prehaps it is buried in the
> issues list somewhere, but in any case I think the spec needs
> tightening because the fix is straightforward.
> 
> CN moves to another network, so CN becomes MN2, and MN2 initiates RR
> and sends HoTi and CoTi to MN1. At this point MN1 will send its CoT
> directly towards MN2 and, since it knows MN2 has a binding for MN1, it
> sends its HoT directly towards HA2's home net. This is a problem
> because both the home and the care-of cookies have been exposed on
> MN1's foreign network, putting MN2 at risk. In such cases RR is
> vulnerable to anyone who can monitor the (arbitrarily insecure)
> foreign net of MN1, which is a different scenario to the well-managed
> "server-only" networks anticipated for immobile correspondents [5.2,
> 15.4.1].
> 
> mobile have completed RR and one (or both) of them decide to refresh
> RR before the existing bindings have expired, again because reverse
> important assumption that MN-HA reverse tunnel is IPSec ESP; but if
> the tunnel is insecure then the same weakness arises in respect of
> both mobiles).
> 
> A simple solution is to require that a roaming mobile must use a
> secure reverse tunnel to its home agent as the path for sending HoT
> while abroad from its home network. This will render the home cookie
> invisible on MN1's foreign net.
> 
> unreliable for use in mobile p2p scenarios, and since there is no way
> to detect if a CN will move in future it is the case that all RR
> bindings are potentially p2p.
> 
> "The Home Test message is sent to the mobile node via the home
> network, where it is presumed that the home agent will tunnel the
> message to the mobile node."
> 
> With this or similar:
> where it is presumed that the Home Agent of the Mobile Node will
> tunnel the message to the Mobile Node."
> 
> Greg

---

From: Jari Arkko <[email-masked]>
Date: Sat, 03 May 2003 00:07:01 +0300

Erik Nordmark wrote:
> That is the picture I have in my head, but the spec might not clearly say
> this.
> 
> Case 1: if the source address of the HoTI is the MN2's Home Address, then since
> MH messages don't get HAO applied to them, the packet must be tunneled to
> MN2's home agent. And since MN1 should not apply RH2 to MH packets the HoT
> will go through the MN2's HA. I think this is clear in the recently suggested 
> clarifications in response to my comments from the IESG discussion of the
> document [HAO and RH2 should not be applied to MH packets except BA, or
> whatever the exact proposed text is.]

Yes. The BC check is also included in the new text. The text is:

    Mobility Header messages MUST NOT be sent with a type 2 routing
    header, except as described in Section 9.5.4 for Binding
    Acknowledgement.  Mobility Header messages also MUST NOT be used with
    a Home Address destination option, except as described in Section
    11.7.1 and Section 11.7.2 for Binding Update.  Binding Cache
    information (when present) for the destination MUST NOT be used in
    sending Mobility Header messages.  That is, Mobility Header messages
    bypass the Binding Cache check described in Section 9.3.2 which is
    normally performed for all packets.  This applies even for message
    sent to or from a correspondent node which is itself a mobile node.

> Case 2: there is no that that says that MN2 can't use its CoA as source
> when sending the CoTI and HoTI. In fact implementors might think this is
> an optimization since these packets are part of single request/response
> exchange thus can't benefit from using the more stable home address.
> But that creates the security exposure you've identified since the
> CoT and HoT will now be sent directly to the CoA i.e. they will be
> visible on MN2's visited link.
> So a clarification is needed here.

Section 11.6.1 requires that HoTI be sent with source = home address.
We also talk in the draft about setting the source address of CoTI
to be the care-of address, and RR crypto would fail if some other address
were used. I'm not sure what else we should say?

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 2 May 2003 21:36:00 +0200 (CEST)

Note that CoT and HoT should already be ok since they are always sent
to the source of the CoTI/HoTI. But adding explicit text as you suggest
might not hurt.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 5 May 2003 13:02:13 +0200 (CEST)

> were used. I'm not sure what else we should say?

I think I was confused. AFAICT you already have this covered.

  Erik