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

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 26 Aug 2005 17:13:43 -0400

> Soliman, Hesham wrote:
 > > 
 > >  > I am having a hard time understanding where we interface 
 > >  > with oDAD. It 
 > >  > does not guarantee that an address is collision-free. 
 > Only DAD can 
 > >  > assure you that. 
 > > 
 > > => Wrong. DAD doesn't assure that. oDAD and DAD do the same
 > > thing, the only difference is that *if* there is a collision, 
 > > oDAD will cause traffic to be routed to the wrong node for 
 > > a very short period of time (0.5 RTT on the link itself). 
 > 
 > Wrong is strong :-) oDAD has to do DAD to assure an address is 
 > collision-free, which it does.

=> I think you missed my point about "wrong". The following statement
is wrong:
   > Only DAD can assure you that.
DAD has known weaknesses and doesn't "assure" or guarantee that 
there are no collisions. 

 > 
 > So, did you have any input on the rest of the text below?
 > 

=> Well, since the premise didn't make sense to me I didn't 
see a need to comment on the solution. I don't think we 
need to do anything here except use existing mechanisms
in IPv6 RFCs. But I have one comment on the following:

 > >  > About intentional collisions: a MN may visit NAR's link, 
 > >  > come back to 
 > >  > PAR's link, send FBU to PAR binding PCoA to an address on 
 > >  > NAR's link and 
 > >  > never move. It's traffic is redirected to a victim on 
 > NAR's link.

=> This is obviously a security threat and is not related to 
the address collision discussion. 

Let's dig deeper into this case. The root cause of the problem
here is that there is no reachability test for the NCoA. Of course
there is no security at all in FMIP right now so when we have 
a secure FMIP solution we can discuss this threat. 
The only case today where we have no reachability test for a CoA
is the BU sent to the HA. In this case, the WG assumed (for better
or for worse), that a malicious MN can be trackable. We've taken
the same approach in HMIPv6. The AR here is essentially a tmp HA. 

So, we can look into this case and decide whether we need to do
a reachability test or not, but it's important to note that this
has no bearing on the address collision discussion.

Hesham

===========================================================
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: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 14:26:43 -0700

> DAD has known weaknesses and doesn't "assure" or guarantee that 

Agreed (I stated this (role of DAD) in a previous e-mail).

> 
>  > >  > About intentional collisions:  
> 

By having the NAR proxy the NCE for NCoA after processing HI, we do not 
actually forward packets to NCoA until the MN sends unsolicited NA (at 
which point if there is a collision, it is as good as anything else that 
allows traffic forwarding when DAD is in progress).

-Rajeev

---

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

> allows traffic forwarding when DAD is in progress).

But there's no guarantee that the unsolicited NA came from the same node 
that triggered the HI. Some other node on the link could spoof the IP and/or 
link addresses.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 15:08:52 -0700

> has no bearing on the address collision discussion.

This is a good point.

I wonder if a SEND-protected NS/NA exchange initiated by the NAR is 
sufficient. In the usual case, the NS is multicast to All-Nodes, so there is 
no guarantee that the receiver of the NS is at the same link address as the 
sender of the NA. The CGA on the SEND-protected NA sent back guarantees that 
the owner of the address is the sender, though.

We could fix this by requiring the link address in the CGA calculation. Or 
doing an RR test, the NS is unicast to a specific link address from which 
the NA must come.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 15:24:27 -0700

James Kempf wrote:
>> By having the NAR proxy the NCE for NCoA after processing HI, we do 
>> not actually forward packets to NCoA until the MN sends unsolicited NA 
>> (at which point if there is a collision, it is as good as anything 
>> else that allows traffic forwarding when DAD is in progress).
>>
> 
> that triggered the HI. Some other node on the link could spoof the IP 
> and/or link addresses.

If it did, it will subject itself to re-direction :-)
I know you are referring to hijacking..

This is ND problem. This can happen on a link running ND today.
Not specifically FMIP problem. In that sense, deficiencies in ND are 
applicable to many other protocols including MIP.

-Rajeev

---

From: Greg Daley <[email-masked]>
Date: Mon, 29 Aug 2005 12:12:05 +1000

Hi James,

James Kempf wrote:
> sufficient. In the usual case, the NS is multicast to All-Nodes, so 
> there is no guarantee that the receiver of the NS is at the same link 
> address as the sender of the NA. The CGA on the SEND-protected NA sent 
> back guarantees that the owner of the address is the sender, though.
> 
> We could fix this by requiring the link address in the CGA calculation. 
> Or doing an RR test, the NS is unicast to a specific link address from 
> which the NA must come.
> 

I think it's also worth looking at systems which are being applied to
MIP6-RO, such as Credit Based authorization.

The credit could be shared with the NAR if there's a HI/HAck
(both PAR and NAR decrement?), in order to handle ping-pong or rapid
movement.

Greg