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

[Ray Hunter <[e-mail]>]

> Lorenzo Colitti <mailto:[e-mail]>
> 10 January 2014 09:59
>
>     IPv6 /64 breaks address scarcity.
>
>
> Wait, maybe I see your position now. You're thinking of a transit 
> network, and you want to limit the number of addresses assigned at the 
> edge so the middleboxes can cope?

Not just middleboxes. Any process that tracks anything on the basis of 
an IP address.

As a simple example, think of a mail server. Mail servers get abused. 
They can generally handle themselves.

To mitigate resource depletion, postfix runs an "anvil" process in 
memory. It's a light weight process that simply tracks the number of 
recent connections in memory from each source IPv4 /32 for a short period.
When an individual IPv4 source address sends "too many requests too 
quickly", postfix does not even open the TCP session with this client.
The main postfix process daemon can then continue to serve other 
well-behaved nodes whilst the rogue node is "shut out".

With IPv6 /64, and massively oversized allocations, that defence 
approach is invalidated, because the anvil process itself becomes a 
weakness, as it cannot track to /128.
You could possibly track at /64, although even that might be too big to 
handle in memory, with the consequence that one rogue node can create 
false positives, and take down a whole LAN or site.

How do you know that the remote rogue site or rogue host is a single /64 
and not a /52 or /56 or /48?
Do you track all of the above simultaneously? That has potential for 
even bigger false positives.

In general, if you want to provide a third party access to your mail 
server or other server for information exchange, you probably want some 
way of throttling access at the Network Network Interface (NNI) from 
individual rogue nodes without cutting off well-behaved nodes.

Or alternatively, providing preferential access to well-behaved nodes, 
with WFQ-like solutions.

Either way you need to be able to differentiate and track node behaviour 
at a fairly granular level.

Address scarcity has some upside too, in that it limits attack source 
surface, and allows tracking at node level, and I do not feel that has 
been sufficiently acknowledged.

Registration of "well-behaved nodes" could be another potential 
approach. Perhaps leveraging AD forests.
>
> But I still don't understand. In most cases, in such a transit network 
> you can't do individual machine tracking already because machines are 
> behind NATs. So why is it so important to track every machine in IPv6?
>
In the areas I work in, they are inter-enterprise connections to trusted 
3rd parties.
We try to avoid NAT wherever possible (isn't that the right thing to do? ;)
We even use registered addresses on the inside and outside.

Security people want as tight a filter as possible. It cannot be the 
case that a technical problem in a trusted third party spills over into 
your enterprise, even if this is protected contractually.

It's a real nice have to have some upper limit of possible source 
addresses or sessions for scaling of logs/ scanners/ network intrusion 
detection systems etc.
Otherwise the middleboxes themselves can fall over.

It's would also be nice to know who these people are (admittedly we only 
"know" that today due to some level of trust linked to address 
allocation schemes e.g. this person is assigned this IPv4address in DHCP 
or via their SSL VPN connection login). Some of that could be translated 
into IPv6 with prefix lengths >>64e.g.: an SSL VPN with a /127 = a person.

IPv4 and IPv6 is probably not the layer where this identity link should 
be established, but it's generally all we have today.
> Also, I don't understand why you wouldn't use hierarchical addressing 
> and delegation - which is what you might naturally do even in IPv4 - 
> and track ranges instead of individual addresses.
In an enterprise NNI, or private cloud service, the source and 
destination ranges would be huge, and the complete list of individual 
allocations are generally unknown to the other party.

The customer might have a /32. The private cloud provider might have a 
/32. There is generally no hierarchy. These are peer networks of equals.
But even then, there's probably only a few tens to thousands machines on 
each side of the NNI that need to communicate.

We generally limit the number of potential source addresses and sessions 
today by filtering to /32 or /24 or /16 at the NNI plus only allowing 
certain port numbers.

That's massively smaller than granting access to a single IPv6 LAN of 
/64 for a single port.

For example, a single source IPv4 /32 with access to 1 port on 4 
destination IPv4 servers is never ever going to be able to saturate a 
flow-based WFQ session table, even if it is compromised. This source 
machine can only ever create 4 flows simply because of the ACL at the NNI.

A single source machine (that has been compromised ) running IPv6 
connected to a /64 using SLAAC + temporary addresses  (and which 
connects to 1 port on 1 server connected to /64 with SLAAC) could easily 
saturate a flow-based WFQ table, causing service degradation to other 
well-behaved nodes, simply because the ACL is so much bigger, and the 
compromised machine can create so many more rogue flows.
>
> Perhaps I don't understand the use case. Can you say more about what 
> sort of networks would need this functionality?
>
Interconnections between enterprises, or within enterprises where 
different sites are managed by different parties, and avoiding cross 
contamination of resource depletion attacks sourced from single rogue 
nodes or sites.
Even an ACL for a single /64 for a single port is massively bigger than 
the biggest access we grant today. Which probably leaves static 
addressing as the only option. Because alternative defence mechanisms 
simply aren't in place yet.

-- 
Regards,
RayH