nanog mailing list archives
Re: NIST IPv6 document
From: Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>
Date: Sun, 9 Jan 2011 11:18:02 +1030
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.
Current thread:
- Re: NIST IPv6 document, (continued)
- Re: NIST IPv6 document Owen DeLong (Jan 05)
- Re: NIST IPv6 document Robert E. Seastrom (Jan 06)
- Re: NIST IPv6 document Jeff Wheeler (Jan 06)
- Re: NIST IPv6 document Owen DeLong (Jan 06)
- Re: NIST IPv6 document Jeff Wheeler (Jan 06)
- Message not available
- Re: NIST IPv6 document Jeff Wheeler (Jan 06)
- Re: NIST IPv6 document Mark Smith (Jan 07)
- Re: NIST IPv6 document Dobbins, Roland (Jan 07)
- Re: NIST IPv6 document Mark Smith (Jan 07)
- Re: NIST IPv6 document Owen DeLong (Jan 07)
- Re: NIST IPv6 document Mark Smith (Jan 08)
- Re: NIST IPv6 document Dobbins, Roland (Jan 07)
- Re: NIST IPv6 document TJ (Jan 07)
- Re: NIST IPv6 document Dobbins, Roland (Jan 07)
- Re: NIST IPv6 document TJ (Jan 07)
- Re: NIST IPv6 document Justin M. Streiner (Jan 07)
- Re: NIST IPv6 document Owen DeLong (Jan 07)
- Message not available
- Re: NIST IPv6 document Tim Chown (Jan 10)
- Re: NIST IPv6 document Owen DeLong (Jan 10)
- Re: NIST IPv6 document Jack Bates (Jan 10)
- Re: NIST IPv6 document Iljitsch van Beijnum (Jan 05)