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

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

Rajeev,

>  
>
>     > 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?
>
>
> The combination of LLA and NCoA is used to identify the MN.
>
> Since we trust the MN to the extent that the FBU is authenticated, we
> also expect the LLA to be genuine.
> This is similar to the MN, which otherwise has an SA with the HA,
> misbehaving which we have talked earlier. I can include this also in
> the Security Considerations if you want.

You do not authenticate MNs because you trust them; you authenticate
them because otherwise some other nodes might claim they are the MN.
Similarly with this, even when you authenticate the node in question,
you want to ensure that the authenticated identity actually has been
authorized to do whatever action it claims it wants to do.

In the simplest case this would mean things like establishing a security
association with a particular node and then storing its IP and MAC
addresses, and then later when that particular security association is
used, refuse to accept any other IP or MAC address.

I think you should state something similar here.

>
>     >  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.
>
>
> Proxy ND operation specification has been there for a long time..Note
> that the NAR defends the address once it is known to be
> duplicate-free. We do not specify how the NAR arrives at that
> resolution: it could be that it maintains a pool or by any other means.

This seems backwards. If you actually do have proxy ND, you should use
it to find out whether the address is duplicate-free. The mechanisms and
protocols for this exist; you only pay in terms of some DAD delay.
However, since that is already configurable per link, I really don't see
much of a problem.
 
>
>
>     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.
>
>
> No. It is designed for the most prevalent scenarios where there are no
> collisions (either due to the availability of duplicate-free addresses
> or due to the extremely low probability of address collisions). The
> recovery operations, in the extremely unlikely event of collisions,
> are described in the appendix.

Rajeev, it is a PS-level requirement that you be able to operate in IPv6
the way IPv6 is normally is run. We can debate about which scenario is
more prevalent, but it would be pointless. All you need to do is to
provide support for both. We can't publish PS specs that do not have
complete functionality for what they do, or that force us to disable
something that is core functionality in ND.


Jari



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