Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

[Brian E Carpenter <[e-mail]>]

Hi Ray,

Thanks for the comments.

On 08/01/2014 00:11, Ray Hunter wrote:
...
> Where exactly is the requirement that IPv6 has to use /64 prefix length
> really enshrined?

I don't think it is enshrined in any one place; in fact at one level
the architecture carefully avoids it.

> I think the draft can help clarify that, and that alone makes it
> worthwhile proceeding.
> 
> 
> I humbly disagree with the conclusions in Section 9.
> 
> The argument seems to assume that all n hosts must be allocated within
> one single prefix with a prefix length >> 64.

That is a very common deployment model, surely? I don't think the death
of the L2 switch has been declared yet; I see plenty of them around.

I agree that it *could* be done differently as you describe below.

> Therefore it assumes that increasing prefix length reduces attack search
> space (given some knowledge of one or more active IPv6 addresses)
> 
> IMHO Address space is address space. Allocation density is allocation
> density. IPv6 supports multiple prefixes per link and the concept of
> determining "on link prefixes" via rfc5942 (unlike the "subnet mask"
> mechanism of IPv4).
> 
> It should be perfectly feasible to allocate a /64 to a router interface
> in an IPAM tool, but then configure the equivalent of n prefixes each
> containing 1 or 2 address with prefix length /128 or /127 (depending on
> the implementation) for n hosts and which are equally sparsely assigned
> across the /64, and all sharing a single L2 link. Even end node to end
> node communication should flow directly (avoiding the router) as these
> prefixes could be marked "on link" via the AdvOnLinkFlag = L flag.
> 
> Anyway, in the majority of modern day wired deployments, the delta cost
> of L3 over L2 is minimal, as the most dominant form of wired LAN
> (Ethernet) are commonly switched in silicon, and multicast has to be
> emulated. Wired Ethernet has in effect become a point to point protocol.
> So deploying a dedicated L3 connection per end host is both technically
> and financially feasible, and may have significant operational benefits
> in certain scenarios. Allocating a /64 for each such port on a L3 switch
> is sub optimal IMHO. And by the same privacy argument, allocating n
> hosts sparsely over a single /64 of address space spread over multiple
> L3 interfaces would have the same net effect for off-net attackers as n
> hosts sharing a flat L2 LAN using a single /64, with the added advantage
> that even locally the individual end nodes would not be able to
> passively observe each other's traffic or addresses (advantageous in
> shared hosting environments).
> 
> An attacker that happens to discover the address of node A would not
> find this information helpful in attempts to locate node B, any more
> than if it were a flat /64.
> 
> So to me it's a non-relevant argument one way or the other.
> 
> Section 2.2
> 
> It may not be a widely held belief, but I remain concerned about the
> potential for resource exhaustion for any number of processes due to the
> "massive over sizing" of prefixes to /64: any number of untested
> processes that track state based on /128 IPv6 address could be attacked.
> The flip side of expanding privacy through address obfuscation at IID
> level is that the source space available for attacks also increases. ND
> cache exhaustion is probably just the first issue we've discovered of
> many that exist. 

That is a bit of a vague argument to put in an RFC though. Can you find at
least one example of such an attack?

     Brian

> This may have knock on operational consequences, which
> in the IPv4 world have relied on the scarcity of IPv4 address space to
> be able to operate correctly under stress scenarios. We're going to
> discover who has been swimming naked when the tide goes out. Call that
> FUD, or operational expediency, whichever you like. BCP38 has saved me
> on a number of occasions when all else has failed.
> 
>