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

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 May 2003 11:04:11 -0700

the text proposed as resolution to issue 269 covers both HoTi
and HoT.

>   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 should include HoT too.

also section 9.4.3 of draft 21.

> 9.4.3 Sending Home Test Messages
> 
>    The correspondent node creates a home keygen token and uses the
>    current nonce index as the Home Nonce Index.  It then creates a Home
>    Test message (Section 6.1.5) and sends it to the mobile node at the
>    latter's home address.  Note that the Home Test message is always
>    sent to the home address of the mobile node without route
>    optimization, even when there is an existing binding for the mobile
>    node.

Vijay

Greg O'Shea wrote:
> No this one's to do with HoT rather than HoTi. #269 is an interesting
> read though, and a good fix to the spec.
> 
> 
> 
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Vijay Devarapalli
>>Sent: 02 May 2003 17:53
>>To: Greg O'Shea
>>Cc: Mobile IPv6 mailling list
>>
>>
>>check issue #269. it covers the issue you raise, I think.
>>
>>Vijay
>>
>>
>>>Greg O'Shea wrote:
>>>
>>>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: Jari Arkko <[email-masked]>
Date: Fri, 02 May 2003 21:23:01 +0300

I agree with Vijay that the change we did earlier should
cover what you Greg requested. Anyway, I'm glad this issue
was caught.

--Jari

---

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