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

[Ray Hunter <[e-mail]>]

> Lorenzo Colitti <mailto:[e-mail]>
> 9 January 2014 03:27
>
>     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.
>     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.
>
>
> It's true that some implementations may have made incorrect 
> assumptions about IPv6 attacks based on their IPv4 knowledge. But on 
> the other hand, a /64 provides plentiful space, freedom from 
> renumbering, and operational simplicity because "you will always have 
> enough subnet space" and "you can pick your own IID because a /64 
> provides enough space for everyone".
>
> I don't think it's a good trade-off to give up those advantages just 
> because of some implementations may temporarily have made insecure 
> choices. By the same token, we didn't design IPv4 to be partitioned 
> into security zones, even though I'm sure that when IPv4 rolled 
> around, people were shocked - and I'm sure some got burnt - by the 
> fact that enabling IPv4 on a machine suddenly meant that the machine 
> was suddenly accessible from anywhere in the world. I think it's much 
> better to start with a flexible, full-featured, simple architecture 
> and them secure it.
>
> It's not that securing it is hard to do: in first instance, make the 
> abuse systems just track /64s instead of tracking /128s, and problem 
> solved. Of course, you still have the problem that there are too many 
> /64s to keep track of, but there's no way around that except to stick 
> with IPv4, or make a new protocol that has more address space than 
> IPv4 but less address space than IPv6... but why would you want that?
>
> I know that smaller subnets are consistent with IPv4. But "different 
> from IPv4" doesn't mean "worse than IPv4". In many cases, it means 
> "better than IPv4".
>
> ------------------------------------------------------------------------
Most organisations I know have way less than 100K hosts globally, and 
typically 10's or 100s of hosts per LAN.

We seem to agree that people can't track at /64 because 2^64 is too big 
to track.

Why then would we suggest that people track at /64 level when you 
already admit there's equally too many /64's to track (also 2^64)?

The point is that people *could* trivially track and filter at /128 
within an enterprise *if* we give network infra people the ability to 
control/register which /128(s) the end host uses.

Ideally, that ability to control/register active /128's should not rely 
on cooperation of L2 switches or other LAN functionality that requires 
purchasing new switches, or constant MIB scanning.

I think that's a valid problem statement, and assigning >>/64 
(purposefully breaking SLAAC, whilst deploying stateful DHCPv6, or 
static addressing) is one way to address that problem.

Is there anything better?

-- 
Regards,
RayH