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

Hi,

On 11 Jan 2014, at 14:26, Ray Hunter <v6ops@globis.net> wrote:

>> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com>
>> 10 January 2014 23:27
>>> But problems in their /48 with a rogue node assigning zillions of addresses and creating zillions of sessions should not spill over into the rest of the network managed by others.
>> 
>> Who says that is a rogue node? It sounds like perfectly legitimate
>> behaviour for a virtual machine environment that is designed to
>> virtualise at layer 3. If you want those VM addresses to be
>> unguessable for an off-path attacker, you might well spread them
>> sparsely across a /64.
>> 
>> Anyway -- I am not seeing much in this thread that suggests text changes
>> in the -why64 draft (which is intended to be factual). I take Ray's
>> original point that there *might* be other risks than ND exhaustion,
>> and we'll add that to the next version.
>> 
>> Regards
>>    Brian
>> 
>> 
> Agreed.
> 
> I would also like to reiterate a basic requirement from network and system operators, and propose the following text for -why64.
> 
> 
> /
> There is a desire by many network operators to

Many, or some?

> 1) know and audit which nodes are active on a network (perhaps by carrying out exhaustive scanning of address space that is allowed to communicate off link)

Or polling the network devices via SNMP or similar.  Exhaustive scanning of v6 space…no.

> 2) be able to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN or site, in order to prevent potential resource depletion attacks or other problems spreading beyond a certain scope of control.

Documenting some examples of this would be useful.  ND cache is one, which I think is already mentioned.

> One way of limiting the scan space, or limiting the number of possible source addresses and sessions from a LAN, is to increase the prefix length >> 64.

Which is what makes this relevant to ‘why64’.

> This may currently break many widely-deployed solutions, such as SLAAC.

Well, ‘This will cause significant issues for the operation of the network, as described elsewhere in this document’

> There are alternatives, which present a different set of trade offs e.g. with respect to the right of privacy of the end user versus the rights of the operator to control and protect their network.
> /

Those alternatives are more likely to be viable in a tightly managed environment, where there is administrative control of all devices, e.g. so provacy addresses can be disabled by policy.

Tim

> 
> Whether you think the solution of extending prefix length >>64 is good or not is a separate debate.
> IMHO Technically it should be possible. CIDR has NOT been deprecated.
> 
> I think imposing a hard limit of /64 is harmful, as it limits operators choice of operations model and protocols
> e.g. flow-based WFQ becomes vulnerable to trivial attacks from a single node, whereas there's nothing fundamentally wrong with flow-based WFQ technology per se, or indeed other mechanisms that require tracking state to /128.
> e..g exhaustive network scanning to check for vulnerable open ports on unpatched machines becomes impractical, whereas there's nothing fundamentally wrong with the concept in an enterprise environment.
> 
> Lorenzo and I clearly disagree on this point, but I see no value in continuing the debate on list wrt this draft.
> it took long enough to get to the current status on allowing use of /127 instead of /64 for point to point links (3627, 6164, 6547)
> 
> -- 
> Regards,
> RayH
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------