Subject: RE: [Mip6] rr weaknesses?

From: Soliman Hesham <[email-masked]>
Date: Sun, 15 Feb 2004 23:09:44 -0500

Jari, 

 >     As the return
 >     routability is not considered by many people as very safe or
 >     efficient, some new ways to
 > 
 > I agree about the efficiency part*.
 > 
 > But I'm wondering if you have any specific worries about the
 > safety part. I mean beyond issues that already exist in plain
 > IPv4 and IPv6, such as MitMs being able to do bad things.

=> The vulnerability of RR is simple: If an attacker
gets hold of HOT and COT, it's over he can do whatever
he wants. In other words if he can generate HOTI and COTI
(which is easy) and be able to receive HOT and COT then
he could do whatever he wants. This is more than what can be 
done today in v4 or v6 because the attacker can move and 
continue to steal/bomb for the lifetime of the token. 

I know there is nothing new in what I'm saying but IMO
this is the bottom line vulnerability and it's because 
everything is done in the clear. 
 
 > *) Well, I guess on the overall scheme of things, 1 RTT can 
 > be considered
 > relatively effient. 

=> Efficiency is not an absolute thing. We need to know
efficient for what? In scenarios where there is frequent
mobility I don't think it's efficient in terms of air interface
use or tolerable for most apps.

Hesham

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "Christian Vogt" <[email-masked]>
Date: Mon, 16 Feb 2004 10:08:02 +0100

Soliman Hesham wrote:
> [...]
> he wants. 
> [...]
[The complete reference is given below.]

Hi Soliman, hi Francis, hi Jari,

I might add that getting a HoT message - more precisely, a Home Keygen Token - is sufficient if the attacker wants to steal data from its victim. All the attacker needs is an IP address X which (1) it is reachable through (*), and (2) which it can use as a care-of address. The attacker would simply send a CoTI message on behalf of the victim using X as a care-of address. It would normally receive the returning CoT message because it is reachable at IP address X. Finally, the attacker could authenticate a faked BU message with the intercept Home Keygen Token and the Care-of Keygen Token from the (normally received) CoT message.

We have elaborated on this issue in section 6.1 of the Early Binding Updates proposal [1].

Note that the Care-of Keygen Token from an overheard CoT message would not be interesting for the attack described above. The reason is that a Care-of Keygen Token is bound to a particular care-of address. Therefore, an overheard Care-of Keygen Token could be used for a later replay attack, directing the victim's data to the victim's previous location [2], but that's about all.

(*) Actually, it is already sufficient if the attacker can listen to messages on the path between the CN and IP address X. The attacker would then have to eavesdrop on the returning CoT message rather than "normally receiving" it.

Best regards,

- Christian

[1] Early Binding Updates for Mobile IPv6
    http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt
[2] Mobile IP version 6 Route Optimization Security Design Background
    http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-02.txt

|
| Christian Vogt
| Institute of Telematics, University of Karlsruhe (TH)
| www.tm.uka.de/~chvogt/
|

> use or tolerable for most apps.
Šž¦j)bž	b²Ó"§¨žµú+‚m¦ÏÿÃ"z×è®æj)fjåŠËbú?š*z

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 22:43:20 +0200

> continue to steal/bomb for the lifetime of the token. 

True, but it would be useful to compare this to other attacks
that the same mitm can do. For instance, ARP spoofing, sending
TCP RSTs, messing with TCP ACKs, dropping packets.

> use or tolerable for most apps.

I hate to press you for more information since I basically
agree that we need additional optimized mechanisms. But can
you say more about the specific requirements that you
are looking for "most apps"? Is there a paper somewhere that
has simulated mobility in some environment that shows how much
time you are spending on RR signaling vs. other movement related
tasks? How does home registration compare, what about IPv6 network
attachment? How about 1X/11i tasks? Or link layer attachment?

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 17 Feb 2004 10:05:06 -0800

> attachment? How about 1X/11i tasks? Or link layer attachment?

We had a paper in Internetworking03 last summer which measured RR signaling
delay on a network that simulated a regional HA/CN based on an RTT to the HA
and CN of 60 ms (about what I measured with ping between our San Jose office
and Berkeley). Here is a table of results:

                               Time
BU w.o. RR            116 ms
RR                          119 ms
Total                       235 ms

This cost would be expected typically on a per subnet move basis, and would
naturally increase as the CN/HA distance increased and decrease as it
decreased.  Typical .11 handover times run about 100-200 ms (see Bill
Arbaugh's paper on the topic) w.o. .11i reauth, but the AP and card
manufacturers are working on improving this, as is the 802.11 WG, since
VoIPo802.11 is *the* hot topic right now. I don't have any figures for raw
cdma2K 1X attachment, but I think that is not too relevent, since 3GPP2 also
has support for L2 mobility that takes care of forwarding packets for
in-progress sessions.

For VoIP, I think 235 ms is not acceptable, to say nothing of 435 ms if L2
mobility is taken into account, since it will be very noticable. However, by
using FMIP and context transfer (as Charlie mentioned in a previous note),
the handover time can be reduced substantially, since the local repair of
routing between the access routers would be expected to be very fast if the
access network deployment is properly done (about 1 RTT between the new AR
and old). Alternatively,  by deploying an HMIP MAP on every leaf subnet and
running a sliding buffer at the MAP,  one could cover most of the delay,
with a risk of introducing ringing artifacts occasionally should the buffer
end up with more than 2 or 3 packets. Some data comparing these approaches
(perhaps for MOBOPTS?) would be very interesting.

            jak