[129416] in North American Network Operators' Group
Re: just seen my first IPv6 network abuse scan,
daemon@ATHENA.MIT.EDU (Joel Jaeggli)
Sun Sep 5 13:02:36 2010
From: Joel Jaeggli <joelja@bogus.com>
To: William Allen Simpson <william.allen.simpson@gmail.com>
In-Reply-To: <4C82C706.4070500@gmail.com>
Date: Sun, 5 Sep 2010 10:02:44 -0700
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Inline...
On Sep 4, 2010, at 15:24, William Allen Simpson =
<william.allen.simpson@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:
>=20
> (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.=20
> (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.
>=20
> 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.
>=20
>=20
> 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."
>>=20
>> 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.
>>=20
>> Unfortunately is there no standardized way to mitigate this attacks, =
yet.
>>=20
>> However there are many approaches which could help or could be =
discussed.
>> (like http://www.freepatentsonline.com/20070130427.pdf or other)
>>=20
> That caused me to burst out laughing!
>=20
> Wow, all it takes is another 15 years, and more folk just rediscover
> lessons learned in the first 15 years....
>=20
> Now, they "patent" it. Kinda fails the "skilled in the art" test.
>=20
