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

Sun Sep 5 17:02:44 UTC 2010

Inline...

On Sep 4, 2010, at 15:24, William Allen Simpson <william.allen.simpson at gmail.com> wrote:

> 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 youdoubt hhave and a thing you know.

What we get instead is much like what happens in ipv4 (a flood of arp traffic). There are Implementation specific techniques that can be used to mitigate the cost of that traffic both to the router and the local net.

> [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!]

Ask on 6lowpan about that, I doubt that they would agree. 

> (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.

Right, and when you in v4 have a couple wireless nets that's are /20s the background load can be considerable across all of them and you need to mitigate accordingly.

> 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.
> 