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

[Ray Hunter <[e-mail]>]

> Brian E Carpenter <mailto:[e-mail]>
> 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
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)
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.

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.
This may currently break many widely-deployed solutions, such as SLAAC.

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.
/


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