Re: NIST IPv6 document

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

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