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

[Lorenzo Colitti <[e-mail]>]

On Fri, Jan 10, 2014 at 7:50 PM, Ray Hunter <[e-mail]> wrote:
>
> 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.
>

But Postfix mail servers are exposed to the Internet. And the Internet
already connects tens of millions of users that have /56 prefixes at their
beck and call to mount an attack. Obviously, the naive approach of tracking
to /128 is not going to scale. But neither does the naive approach of
storing BGP tables in linked lists. Fortunately, router implementations use
patricia tries and hash tables, and equivalently, fortunately it's possible
to do better than to track at the /128 level.


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

Three minutes of thought suggest that you could have separate /64, /56 and
/48 tables (or whatever) and when a certain threshold of entries in one
table match the entries in the table one level shorter, delete them and
block the covering prefix at the shorter prefix level. Thinking about it
for three hours instead of three minutes will probably produce several more
sophisticated ideas - one example is looking for evenly-spaced spikes in
prefix usage patterns in historical log data to detect ISP assigned prefix
sizes in particular blocks, and then track that region of the IPv6 space at
that block size.


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

Why individual rogue nodes? In most networks (maybe yours is an exception;
but in general, anything exposed to residential users), you can't see the
nodes. You can see NAT pool IPs. So we're already tracking by the block,
even in IPv4.


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

If address scarcity is what you want, there's a well-supported,
ubiquitously deployed protocol you can use: IPv4. Unfortunately, its main
problem is... address scarcity. We're trying to fix that problem. We can't
fix it by creating more scarcity.

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


Why can't you associate an SSLVPN connection login with a /64? It's still
one login.


> Some of that could be translated into IPv6 with prefix lengths >>64e.g.:
> an SSL VPN with a /127 = a person.
>

Why a /127? Why not a /64? It's the same number of state entries - one per
login. And a /127 (or even a /128) is not one machine. It could be one
machine, or it could be a distributed cluster of machines running a
transparent TCP proxy for 100000 clients. For example:

star.c10r.facebook.com has IPv6 address 2a03:2880:f00f:300:face:b00c:0:1

You don't think that's one machine, right?

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

But WFQ scales in terms of the buffer size (i.e., the total length of the
queue), not in the number of flows, right? If what you're queueing is
packets, then the queue is not unbounded and there is no scaling issue.


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

In this case, what you want DHCP for is not tracking - it's predictability.
You want to assign a given client an address that will pass through the
security pinhole.

There's nothing stopping you from doing this even if the client is on a /64
subnet with SLAAC turned on - just assign addresses via DHCPv6 or
statically, configure the firewall to pass one /128, and configure the
application to use the "magic" address you gave it. You don't need to
create scarcity for that to work; it would work perfectly well if the host
had a SLAAC address and 5 temporary addresses for Internet access, for
example.