[Mipshop] Re: New revision of draft-ietf-mipshop-fmipv6-rfc4068bis

[Jari Arkko <jari.arkko at piuha.net>]

Rajeev,

>  
>
>     > >      1. determines whether NCoA supplied in the HI message is
>     a valid
>     > >      address for use, and if it is, starts proxying [rfc2461] the
>     > >      address for PROXY_ND_LIFETIME during which the MN is
>     expected to
>     > >      connect to NAR.  In case there is already an NCoA
>     present, NAR may
>     > >      verify if the LLA is the same as its own or that of the
>     MN itself.
>     > >      If so, NAR may allow the use of NCoA.
>     >
>     > 1) How does the NAR know what addresses are present on the link?
>
>     This is the address duplication issue.
>
>
> As we have agreed, typically NAR may not have means to keep a list of
> all the addresses on the link, although it is feasible with a data
> structure like "visitor list" in MIP4 or an access control list when
> access control is enforced. For our purposes here, I can reword the
> above to "In case there is already an NCoA present in its neighbor
> cache, .."

Ok. Please make sure that you also handle the case where the proxy ND
operation fails due to a collision NOT in the cache.

>  
>
>     >
>     > 2) For the case that LLA equals the MN's LLA: how do we know
>     that the
>     > LLA in the HI message is not spoofed?
>     We had a discussion about this earlier and agreed to state that
>     you need to
>     state there is an assumption that the two routers trust each
>     other. But
>     when I am looking at the document again, I am still concerned. The
>     issue
>     is that the LLA information does not come from the other router,
>     it merely
>     comes through it. If I am another MN on the other link, I can fool the
>     NAR into thinking that I am the same node by claiming that I have the
>     same IP address and MAC address as the victim.
>
>
> So, the issue is whether the MN which can provide an authenticated FBU
> could abuse the use of LLA? (That's what I can gather by "spoofing the
> LLA" in HI message).

Right. What is the LLA information used for?

>
>     > > However, the MN itself does not have to
>     > >    wait on PAR's link for this exchange to take place.  It can
>     handover
>     > >    any time after sending the FBU message; sometimes it may be
>     forced to
>     > >    handover without sending the FBU.  In any case, it can
>     still confirm
>     > >    using NCoA from NAR's link by sending the UNA message.
>     >
>     > But if it does this too early, won't the NAR detect a collision for
>     > the new care of address?
>
>     Part of the collision issue.
>
>
>  The protocol a) allows a deployment to maintain duplicate-free
> addresses (by means beyond the scope of the protocol) and provides HI
> and HAck for exchange, b) states that it SHOULD only be used where the
> probability of collision is extremely low. This is specified in
> Section 5.5 and same holds above. Please let me know if you would like
> me to reword anything.

I thought that due to changes mentioned earlier in this e-mail, you now
are doing
proxy ND on behalf of mobile nodes, so you DO appear to specify a
mechanism for
providing duplicate-free addresses.

I think that is required. If in addition you want to specify that in
environments
where the probability of collision is very low people can turn of DAD (by
setting DupAddrDetectTransmits to 0 per RFC 4862), that's fine. But it is
not fine to say that this protocol only works if there are no collisions.

>
>     >
>     > >    The source IP address is PCoA when FBU is sent from PAR's
>     link, and
>     > >    the source IP address is NCoA when sent from NAR's link.
>     > >
>     > >    The FBU MUST also include the Home Address Option and the Home
>     > >    Address is PCoA.  A FBU message MUST be protected so that
>     PAR is able
>     > >    to determine that the FBU message is sent by a genuine MN.
>     > Is the HAO included even when the source address is the PCoA?
>
>     I'm withdrawing my comment after re-reading RFC 3775 :-)
>
>
> So, we could revert back to always having the HAO right?

Yes.
 
Jari



_______________________________________________
Mipshop mailing list
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop