Subject: [ipv6] Re: /64 ND DoS

From: Ray Hunter <[email-masked]>
Date: Wed, 13 Jul 2011 01:47:32 +0200

>
> Message: 9
> Date: Tue, 12 Jul 2011 13:50:16 -0400
> From: Jared Mauch<[email-masked]>
> To: Philip Homburg<[email-masked]>
> Cc:[email-masked]
> Subject: Re: /64 ND DoS
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
> I think this needs to be refined, hence the feedback process via the community here.  I think sending to all-routers (or all-hosts) is generally an unwelcome event, but it is a way to have the host communicate with something that is setting the "i'm a router" bit.
>
> - Jared
>    
It seems to me that the root cause of the problem is the size of the 
(default) /64 prefix defined for SLAAC compared to the capabilities of 
current computers / routers to provide sufficient slots/ resources for 
ND, especially when under remote attack.

One mitigation measure is suggested in section 6.2. Appropriate Subnet 
Sizing.

Here's a brute-force "what if" scenario for your consideration / discussion.

Today SLAAC addresses (RFC4862) are built on EUI-64 addresses, which in 
turn are derived from EUI-48, with some defined padding.

But EUI-48 itself has a not-very-well-published sub-structure of a 
"manufacturer's IEEE-assigned company_id" and a "manufacturer-selected 
extension identifier"

What if SLAAC was (temporarily) redefined to build EUI-64 identifiers 
with the manufacturer's IEEE-assigned company_id set to a single well 
known value? i.e. EUI-64 was derived from the "manufacturer-selected 
extension identifier" only.

That would effectively mean there'd be 2^24 different possible interface 
identifiers per prefix.

Are 2^24 interface identifiers small enough that every implementation 
could simply provide enough resources (for ND) to cope with all 
addresses being in play simultaneously?

2^24 is approx 17e6 table entries as a maximum, which may not be 
excessive for most modern devices, even most embedded ones. Whereas 2^64 
has already been shown to be excessive via the ND vulnerability.

Would 2^24 interface identifiers be large enough to ensure that SLAAC 
can still produce enough node identifiers whilst avoiding producing 
excessive collisions in Duplicate Address Detection (DAD)?
[bearing in mind anyway the limited variation in the first 24 bits of 
EUI-48 in practice]

Or can SLAAC and DAD be amended to 'guess and test' a new interface 
identifier automatically on detection of a duplicate address [like 
Appletalk node ID acquisition on Extended Networks]?

Would 2^24 interface identifiers be large enough that RFC 4941 (privacy 
extension) addresses are still reasonably useful?
[again bearing in mind the limited variation in the first 24 bits of 
EUI-48 in practice]

IMVHO this might be a useful compromise to investigate further.

regards,
RayH

---

From: Florian Weimer <[email-masked]>
Date: Wed, 13 Jul 2011 07:39:08 +0000

> addresses being in play simultaneously?

You'd need per-interface and per-VLAN tables.  I don't think that's
feasible.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Ray Hunter <[email-masked]>
Date: Wed, 13 Jul 2011 10:06:12 +0200

> You'd need per-interface and per-VLAN tables.  I don't think that's
So where's the limit for ND and prefix length on today's implementations 
and platforms?

What if SLAAC was limited to using 20 bits or even just 16 bits of MAC 
BIA information or even in extremis dare I say 12 bits?

That would mean taking one or even two steps closer to Appletalk's node 
ID auto configuration mechanism. [implying higher chance of collisions 
and that DAD would almost certainly have to be adjusted to allow 
generation of random node IDs, and then testing for uniqueness on 
interface status transition. ].

IMHO There's no reason why this (temporary) limit on the amount of MAC 
BIA information used for SLAAC couldn't change over time as the power of 
platforms increases, and that this limit could also be dynamically 
advertised via RA as a per prefix option.

Or are you saying that a brute force solution (a la ARP) is simply a no go?

regards,
RayH

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 10:11:31 +0200 (CEST)

> So where's the limit for ND and prefix length on today's implementations 

Todays L3 switches typically have an ND/ARP table size limitations in the 
1-4k entry range.

> BIA information or even in extremis dare I say 12 bits?

/120 would be more doable. When I think of ND table size per customer, I'm 
thinking limitation to 16-32 entries, after that the customer needs to get 
a router.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Jul 2011 10:14:13 +0200

>That would effectively mean there'd be 2^24 different possible interface 

With SLAAC you get an IPv6 address that is essentially guaranteed to be
unique. 

There is absolutly no rule for allocating the lower 24 bits in an ehternet
address. If every vendor would simply start counting at 1, you can expect
a huge number of collisions.

>has already been shown to be excessive via the ND vulnerability.

There are plenty of embedded devices with a relatively small number of
megabytes. There is plenty of hardware that would not support this.

>[again bearing in mind the limited variation in the first 24 bits of 

I think there is something to be said for this. Add some text that if a router
advertises a prefix longer than /64 for SLAAC then the host will generate a
series of random numbers, test each of them in sequence and start using 
one that is collision free. What may be needed is that the host will keep
performing duplicate address detection periodically. On a typical home net
that might make it possible to go /112.

However, I much more prefer to solve the DoS problem for /64s than to just
give up.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 13 Jul 2011 12:45:39 -0400

On Jul 13, 2011, at 4:11 AM, Mikael Abrahamsson wrote:

>> So where's the limit for ND and prefix length on today's implementations and platforms?
> 
> Todays L3 switches typically have an ND/ARP table size limitations in the 1-4k entry range.
> 
>> What if SLAAC was limited to using 20 bits or even just 16 bits of MAC BIA information or even in extremis dare I say 12 bits?
> 
> /120 would be more doable. When I think of ND table size per customer, I'm thinking limitation to 16-32 entries, after that the customer needs to get a router.

We have seen problems in the 2^11 or 2^12 in IPv4 land with directly-connected customer lans.  The ability for the Mac <-> IP (ARP) to work properly is a serious issue with reasonable routers.

I think the larger issue here is that an ARP either solicited/unsolicited does not cause an entry to age.  That is what happens in IPv6 (NDP) land, so that's an issue IMHO.

- Jared