Message: 9
Date: Tue, 12 Jul 2011 13:50:16 -0400
From: Jared Mauch<[email protected]>
To: Philip Homburg<[email protected]>
Cc:[email protected]
Subject: Re: /64 ND DoS
Message-ID:<[email protected]>
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
