Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 25 Aug 2005 17:24:52 -0400

> Thomas did express some reservations about oDAD, based on 
 > packets getting 
 > out to the Internet with a potential duplicate during the 
 > IETF review.

=> Well, now it seems to have passed IESG.

 > >> But it doesn't solve it for predictive handover, because the
 > > > PAR might start
 > > > tunneling packets prior to the MN even arriving on the link.
 > > > If there's
 > > > another MN on the link with the same address, the NAR will
 >  >> send the tunneled
 >  >> packets to it.
 > >
 > >=> Again, It's based on ***probability*** of what's *acceptable*.
 > >Every thing that could fail in a handover has a higher probability
 > >of failing than DAD! There is no point in securing a glass
 > >house by adding more locks on the door...
 > 
 > Even if there are no errors and the only problem is just a duplicate 
 > address, the period of exposure is potentially longer than 
 > with the node 
 > doing oDAD on the link.

=> Longer by about 100 ms, sure. Again, this is a corner case
that we should accept given that it's the least likely corner
case in the whole design. 

Hesham

 >             jak 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 14:38:31 -0700

> case in the whole design.

An event which, in the natural order of things, is relatively improbabile 
can become very likely in the face of malicious human intent.

Not checking for duplicates opens a specific attack in which the attacker 
can intercept some part of a victim MN's traffic prior to movement if 
handover is predictive. The attacker establishes a duplicate nCoA on NAR 
prior to the victim MN's movement, then when the PAR starts sending buffered 
traffic, the attacker gets the traffic rather than the victim. At a minimum, 
the attacker can disrupt the MN's traffic. The attack is particularly 
troublesome because it happens on a link where the MN isn't currently 
(though it will be shortly). The probability of the attacker being able to 
deduce the victim's future address is reduced if the MN uses SEND or RFC 
3041 addresses, but it can't be guaranteed that this will always be the 
case, since many MN's will likely use RFC 3513 addresses. The attack can be 
eliminated entirely by using DHCP-assigned addresses, but as we've been 
discussing, it is not at all clear at this point how to cleanly integrate 
DHCP and FMIP.

            jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 26 Aug 2005 13:36:50 +1000

Hi James,

James Kempf wrote:
> An event which, in the natural order of things, is relatively 
> improbabile can become very likely in the face of malicious human intent.
> 
> Not checking for duplicates opens a specific attack in which the 
> attacker can intercept some part of a victim MN's traffic prior to 
> movement if handover is predictive. The attacker establishes a duplicate 
> nCoA on NAR prior to the victim MN's movement, then when the PAR starts 
> sending buffered traffic, the attacker gets the traffic rather than the 
> victim. At a minimum, the attacker can disrupt the MN's traffic. The 
> attack is particularly troublesome because it happens on a link where 
> the MN isn't currently (though it will be shortly). The probability of 
> the attacker being able to deduce the victim's future address is reduced 
> if the MN uses SEND or RFC 3041 addresses, but it can't be guaranteed 
> that this will always be the case, since many MN's will likely use RFC 
> 3513 addresses. The attack can be eliminated entirely by using 
> DHCP-assigned addresses, but as we've been discussing, it is not at all 
> clear at this point how to cleanly integrate DHCP and FMIP

The same arguments apply even when a host is present on a link, since
the attacker doesn't have to do DAD in order to spoof an address.
The on-link attacker case is neatly handled by SEND, and 3513/3041
addresses are vulnerable.

The work required to generate a CGA address which matches the CGA of
a mobile device with a different public key is quite high.  If
the CGA cannot be easily generated,  then the attacker cannot
create an NCE on the router to steal/disrupt traffic.

I think that we should be encouraging people to use SEND then,
because it resolves the issue in exactly the same way as it would be
solved if the host was already present.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 10:07:24 -0700

Agree.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Soliman, Hesham" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 25, 2005 8:36 PM
Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?

>> prior to the victim MN's movement, then when the PAR starts sending 
>> buffered traffic, the attacker gets the traffic rather than the victim. 
>> At a minimum, the attacker can disrupt the MN's traffic. The attack is 
>> particularly troublesome because it happens on a link where the MN isn't 
>> currently (though it will be shortly). The probability of the attacker 
>> being able to deduce the victim's future address is reduced if the MN 
>> uses SEND or RFC 3041 addresses, but it can't be guaranteed that this 
>> will always be the case, since many MN's will likely use RFC 3513 
>> addresses. The attack can be eliminated entirely by using DHCP-assigned 
>> addresses, but as we've been discussing, it is not at all clear at this 
>> point how to cleanly integrate DHCP and FMIP
>