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

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

> 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

On 10/01/2014 21:10, Ray Hunter wrote:
>> Lorenzo Colitti <mailto:[e-mail]>
>> 10 January 2014 06:01
>>
>>
>>     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.
>>
>>
>> In your network you are free to assign addresses exclusively using
>> DHCPv6.
>>
>> *However* - if you are doing this for the purpose of tracking, that
>> only makes any sense at all if the current switches you have (since
>> you've already said you're not going to buy new ones) can snoop DHCPv6
>> requests for address assignments enforce IPv6-to-MAC address mappings.
>>
>> Do they?
>>
> You are apparently imposing a model which assumes a single management
> vendor is responsible right up until the edge of the network at port level.
> 
> That is rarely true in any enterprise I've worked on. They are not my
> customer's switches. They don't manage them at all. They subcontract
> that to multiple parties.
> 
> In the case of multiple management providers, people need to protect
> their own services from the failings of others.
> 
> If a site is under autonomous management (e.g. trusted 3rd party) then
> they may be assigned a /48 in your model.
> 
> OK they're responsible for their own /48 and they can suffer the
> consequences of poor management of devices in their site.
> 
> 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.
> 
> WFQ QoS (and many other processes which requires tracking of individual
> sessions or IP addresses) running in another vendor's network should not
> fail because of a single node in a single 3rd party network swamps an
> address/session table.
> 
> I think that people need some way of limiting the number of active
> /128's at the network-network interface. It would be even better if we
> could either register or control to the /128 and identify those to a
> host or user.
> 
> One way of doing that is to agree with trusted 3rd party sites (which
> generally only have a tiny number of hosts allowed to communicate across
> the boundary) to only assign an agreed /120 out of their /48 allocation,
> which requires prefix lengths >>64 (this ID) or at least the ability to
> apply ACL filters >> /64.
> 
> Another way is source address validation at the edge, with limits
> assigned on a first come first served basis.
> 
> Another is to ban all processes that need to track an individual IPv6
> address.
> 
> Another is to contract that the site themselves are responsible for
> limiting resource depletion attacks, but I'd still want some protection
> on the receiving side.
> 
> I'd rather be tracking the 100K nodes that I know should be on the
> network out of a potential 24*2^16 addresses, rather than trying to stop
> a 100 zillion anonymous nodes who I can't even identify so that the 100K
> can work.
> 
> DHCP has been successfully implemented in multi-vendor environments. The
> local LAN manager/outsourcer only has to configure up the LAN interface
> either the correct IP address and subnet mask, and point a DHCP proxy at
> a regional server (managed by someone else) They can make changes within
> a site autonomously without bothering the central team, and it all just
> works.
> 
> DHCPv6 potentially can provide a form of centralised registration (and
> then be linked to admission control, or at least give cooperating end
> nodes a higher QoS than unidentified end nodes) and support a similar
> operations model.
> You could also allocate a /64, configure a DHCPv6 address pool to assign
> addresses from a range >>64 and apply and ACL, or assign and allocate
>>>64 prefix length (which seems easier).
> 
> 
> Because if they don't, disabling SLAAC gives you no security at all,
> because malicious hosts on your network will still be free to create and
> use arbitrary IPv6 addresses, which you will not be able to track. In
> fact, this gives you the same level of security as you could by
> disabling privacy addresses and using autoconf - malicious hosts can
> still do what they want, and for well-behaved hosts, instead of having
> the MAC address in the IPv6 address, you now have to go and get it from
> the DHCPv6 server logs. Lose/lose.
> 
> That is also a problem. The assumption seems to be that there has been
> of smart nodes and a dumb network that does not run any processes
> requiring differential services or that tracking of individual end hosts
> is universally bad.
> 
> But I thought we'd established that we're not exclusively talking about
> forcing use of particular addresses for all machines, rather
> establishing which nodes are genuinely active, and attempting to
> establish centrally what machine they are being used by.
>>
>> Or - as Tim points out, SNMP scraping will do this securely for you
>> today, and vendors are already building better and more scalable
>> address registration notification features (syslog, etc.) into switches.
> Not everyone allows SNMP access from other management vendors in a multi
> vendor environment. Not everyone feeds syslog to other management vendors.
> Again, you are imposing an alien operations model. It imposes polling,
> It imposes inter-vendor cooperation and access to all remote devices via
> a management protocol.
> Every time a switch on any one of 1000 sites changes, you're going to
> have to update your central poller. A central registration model avoids
> that overhead.
>> And if you're not doing this for the purpose of tracking, then why are
>> you doing it? Is it just because it's what you do in IPv4? If so, then
>> sorry, that's not a valid technical argument.
> At the risk of repeeating myself: helpdesk call correlation, problem
> correlation, log correlation, ability to track to /128 (for future
> filtering or tracking or resource protection of processes and devices
> within the network that rely on databases or caches keyed by IP address)
> 
> In IPv4, this protection happens automatically due to address scarcity,
> without doing anything else.
> 
> IPv6 /64 breaks address scarcity.
> 
>