just seen my first IPv6 network abuse scan, is this the start for more?

William Allen Simpson william.allen.simpson at gmail.com
Sat Sep 4 22:24:06 UTC 2010

On 9/3/10 7:43 AM, Matthias Flittner wrote:
 >> Since recently we noticed  "Neighbour table overflow" warnings from
 >> the kernel on a lot of Linux machines. As this was very annoying for
 >> us and our customers I started to dump traffic and tried to find the
 >> cause.
 > sounds for me as an typicall IPv6 DoS attack. (see RFC3756)
 > Sheng Jiang has discussed this issue in his draft:
 > http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection-01
That's what happens when you rip all the security assumptions and
requirements out of neighbor discovery!  The original design wasn't
subject to any of these problems, because:

(1) Every request was assumed to be authenticated.  Every system
was assumed to have a public/private key pair, or a unique secret
burned-in at manufacture, paired with its MAC address.  A thing you
have and a thing you know.

[There were supposed exceptions for light bulbs, but good security
practices dictate that light bulbs aren't globally accessible.
Nowadays, I wouldn't agree to a light bulb exception, as even the
puniest system on a chip has plenty of room to store a key pair,
and far more processing power than we were using in the old pizza
box sized cell phones!]

(2) Every router wouldn't send anything from upstream until the
downstream had registered its local address and been assigned one or
more global dynamic addresses.

Back in the day, we'd already seen subnets bigger than the 30 allowed
by thinnet, we actually discussed the ARP pollution problem, and we
designed to eliminate it.

And by "we", I don't include the folks that mangled present-day neighbor
discovery.  I used to have a recording of one of them made at Xerox PARC
claiming the existing ethernet process was good enough, we didn't need
that extra stuff for security, mobility, unidirectional satellite links,
hidden (radio) terminals, etc.

On 9/3/10 9:07 AM, Matthias Flittner wrote:
> typically this fill the NC with faked entries and exhaust the node's
> cache resources. "This interrupts the normal functions of the targeted
> IPv6 node."
> In other words: The attacker sends a lot of ICMPv6 echo requests to your
> /64 subnet. Your router has to resolve this addresses internaly (each NA
> is stored in NC of the router). The node's cace resources are exhausted
> and no "normal" NA could be stored. I think that was your problem.
> Unfortunately is there no standardized way to mitigate this attacks, yet.
> However there are many approaches which could help or could be discussed.
> (like http://www.freepatentsonline.com/20070130427.pdf or other)
That caused me to burst out laughing!

Wow, all it takes is another 15 years, and more folk just rediscover
lessons learned in the first 15 years....

Now, they "patent" it.  Kinda fails the "skilled in the art" test.

More information about the NANOG mailing list