NIST IPv6 document

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Sun Jan 9 00:48:02 UTC 2011


On Fri, 7 Jan 2011 14:53:02 -0800
Owen DeLong <owen at 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" <rdobbins at 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.




More information about the NANOG mailing list