[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NIST IPv6 document
On Wed, 5 Jan 2011 18:57:50 +0100
Phil Regnauld <regnauld at nsrc.org> wrote:
> Jeff Wheeler (jsw) writes:
> > are badly needed. The largest current routing devices have room for
> > about 100,000 ARP/NDP entries, which can be used up in a fraction of a
> > second with a gigabit of malicious traffic flow. What happens after
> > that is the problem, and we need to tell our vendors what knobs we
> > want so we can "choose our own failure mode" and limit damage to one
> > interface/LAN.
>
> Well there are *some* knobs:
>
> http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1369018
>
> Not very smart, as it just controls how fast you run out of entries.
>
> I haven't read all entries in this thread yet, but I wonder if
> http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01 has been
> mentioned ?
>
The problem fundamentally is the outstanding state while the NS/NA
transaction takes place. IPX had big subnets (i.e. /32s out of 80 bit
addresses), but as it didn't use a layer 3 to layer 2 address resolution
protocol (layer 2 addresses were the layer 3 node addresses), requiring
transaction state, it didn't (or wouldn't have) had this issue.
I think the answer is to go stateless for the NS/NA transaction, either
blindly trusting the received NAs (initially compatible with current
NS/NA mechanisms), which reduces the set of nodes that can exploit
neighbor cache tables to those onlink, and then eventually moving
towards a nonce based verification of received NAs, which in effect
carries the NS/NA transaction state within the packet, rather than
storing it within the NS'ing node's memory. Going stateless means
losing ICMPv6 destination unreachables for non-existent neighbors
however (a) vendors aren't implementing those on P2P links already
because they switch off ND address resolution, (b) the /127 P2P proposal
switches them off because it proposes switching off ND address
resolution, and (c) firewalls commonly drop them inbound from the
Internet anyway.
Other possible options -
http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html
> Seems also that this topic has been brought up here a year ago give
> or take a couple of weeks:
>
> http://www.mail-archive.com/nanog at nanog.org/msg18841.html
>
>
> Cheers,
> Phil
>