Re: NIST IPv6 document

[Owen DeLong <owen () delong com>]

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?

Owen