On Jan 29, 2008 3:13 AM, Jari Arkko <
jari.arkko at piuha.net> wrote:
> 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.
Yes, yet the HA trusts the MN to be at CoA (i.e., no RR) in MIP6. I guess this is not the right place to discuss this, and I did not imply that you trust someone carte blanche because you authenticated them (".. to the _extent_ that FBU is authenticated.."). Clearly, authentication and authorization are separate but related concepts, and trust is a function of the domain in which you perform both.
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.
Ok.
> 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.
The issue is when you perform these operations.. When NAR receives HI, if it engages in these operations, that adds to the critical handover delay. So, the design separates the two: NAR can maintain a pool (and do proxy ND if necessary) which is duplicate-free, and provide messages to transport the NCoA.
> 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.
I was only providing the design rationale..
In sum, a) proxy ND is used to defend an address like in an HA (it could also be used to maintain a pool of duplicate-free addresses for which the protocol provides a transport message for), and b) DAD could be turned off depending on specific deployment consideration (i.e., address collision is not an issue)
Is this okay?
Thanks,
-Rajeev
Jari
