On Fri, 7 Jan 2011 14:53:02 -0800 Owen DeLong <o...@delong.com> wrote:
> > On Jan 7, 2011, at 1:28 PM, Mark Smith wrote: > > > On Fri, 7 Jan 2011 09:38:32 +0000 > > "Dobbins, Roland" <rdobb...@arbor.net> wrote: > > > >> > >> On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: > >> > >>> Doesn't this risk already exist in IPv4? > >> > >> > >> There are various vendor knobs/features to ameliorate ARP-level issues in > >> switching gear. Those same knobs aren't viable in IPv6 due to the way > >> ND/NS work, > > > > I was commenting on the mentality the OP seemed to be > > expressing, about *both* onlink and off link sources triggering address > > resolution for lots of non-existent destinations, and that this was a > > new and unacceptable threat. I think the offlink risk is a > > far more significant one. I think the onlink risk pretty much no worse > > than any of the other things that LAN attached devices can do if they > > choose to. > > > >> and as you mention, the ND stuff is layer-3-routable. > >> > > > > The issue isn't that ND is layer 3 routable - it isn't unless a router > > implementation is broken. The problem is that somebody on the Internet > > could send 1000s of UDP packets (i.e. an offlink traffic source) > > towards destinations that don't exist on the target subnet. The > > upstream router will then perform address resolution, sending ND NSes > > for those unknown destinations, and while waiting to see if ND NAs are > > returned, will maintain state for each outstanding ND NS. This state is > > what is exploitable remotely, unless the state table size is large > > enough to hold all possible outstanding ND NA entries for all possible > > addresses on the target subnet. > > > > I think this problem can be avoided by getting rid of this offlink > > traffic triggered address resolution state. The purpose of the state > > (from the Neighbor Discovery RFC) is two fold - > > > > - to allow the ND NS to be resent up to two times if no ND NA response > > is received to ND NSes. A number of triggering packets (e.g. UDP > > ones or TCP SYNs) are queued as well so that they can be resent if and > > when ND NS/NA completes. > > > > - to allow ICMP destination unreachables to be generated if the ND > > NS/NA transaction fails, even after resending. > > > > I think it is acceptable to compromise on these requirements. > > I'm inclined to agree with you, but... > > I think it might also make sense to eliminate the ND NS/NA transaction > altogether for addresses that do not begin with xxxx:xxxx:xxxx:xxxx:000x. > In other words, for non SLAAC addresses, we need the ND NS/NA > process (even if we do it stateless which isn't an entirely bad idea), > but, for SLAAC addresses, the MAC is embedded in the IP address, > so, why not just use that? > I think then you'd only be able to avoid the issue by maintaining "MAC/SLAAC" only segments, with no stateful DHCPv6, privacy address or static addressed nodes, so that (stateful or stateless) ND NS/NA could be disabled. While it would work for those types of nodes, it wouldn't restore the properties we'd have to give up for the stateless ND NS/NA idea, as they need state to be performed, regardless of the destination address type. I think there are a variety of valid and legitimate reasons to preserve the ability to have different layer 3 and layer 2 node addresses, rather than 1-to-1 mapping them. Therefore I think an ideal solution to this problem solves it for all cases, rather than having different solutions or mitigations for different situations. With your suggestion, in theory a solution would now exist for point-to-point links via /127 configured prefix lengths and for "MAC/SLAAC" only LAN segments. Neither of those solutions can be used for stateful DHCPv6 segments, or segments where privacy addresses are useful and could be used - so we'd only be at 2 out of (at least) 4 situations to mitigate it. I think when you start going down the path of creating a number of different special cases with fairly different methods of addressing them, it is worth sitting back and saying is there a single general solution that will cover all cases. That is what has been done in IPv6 with ND address resolution, rather than having link specific methods of configuring and/or discovering IPv6 addresses (e.g. in IPv4 IPCP, ARP etc.), so if there is a solution that can be applied within ND address resolution, it automatically applies to all existing and future link types that IPv6 operates over. Regards, Mark.
