At Thu, 2 Oct 2008 07:33:20 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
> FYI Again, I'm sorry for my overly delayed response. Now that it's open (and I don't think there's no secret in the discussion), I'm going to respond to some other points in the referred message: > > If we incorporate this issue into the 'ipv6-subnet-model' draft, > > I'd like to see a clear consensus on this in the working group > > since it will significantly change the role of this document and > > affect much more existing implementors. We should probably even > > change its title. (I'd not necessarily object to this approach > > once the wg can reach consensus on this point). > > Sure. But I don't expect any real pushback from the WG. The on-link > definition needs to be fixed somewhere. Who is going to argue > against that? And this (the subnet model) document really needs to > be able to state or point to the correct definition of on-link. Frankly, I personally don't expect a pushback either. But in my past experience in the 2462bis work, even a most trivial (and reasonable to me) change could get unexpected pushback once it turns out to require modification of some existing implementation. That's why I wanted to see an explicit support from implementors (as I said in a separate message, I understand we may still end up regarding no-response as a "consensus"). > > For example, an attacking node can easily exploit forged redirect > > messages for the same purpose (but only for hosts as the victim). > > So, if we specifically want to change these particular points at > > this timing while leaving other general issues, I believe we > > should give sufficient explanation for that. In my understand, > > the main point is: > > > - this can be used as a route injection attack from a malicious > > host to a router (not to another host) > > Observation: the reason this attack works is because some > implementations don't scope ND messages properly. That is, they > allow an ND/NA received on one interface to impact data structures > that are global rather than per-interface. Logically, ND/NA traffic > should only apply to the interface/link on which it was received > on. E.g, consider what happens with IPv6 LL addresses, especially if > the same address (with a different MAC addr) is used on different > links. First of all, now that cert advisories have been issued, I have no objection to handling this specific point only. But, I don't agree with your observation above. This is not because an implementation don't scope ND messages. Even if the node only has a single interface (so no scoping is possible in the first place), when it receives an NS whose source - isn't link-local, - doesn't match any on-link prefix advertised via RA, or - hasn't been told as on-link via a Redirect, the node could consider the NS source address as on-link if it literally applies the definition of on-link as defined in RFC4861, because it's an address from which a "Neighbor Discovery message is received". In fact, *BSDs correctly "scope" ND messages per-link, and it doesn't confuse the same link-local addresses received on different links wrt ND processing. It still believes an unknown address as on-link if it receives an ND message from that address, based on the literal RFC definition of on-link. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
