[136961] in North American Network Operators' Group
Re: Failure modes: NAT vs SPI
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Feb 7 04:34:37 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <C9CC5A01-1430-4C31-AF4E-4FF501D3F2E7@muada.com>
Date: Mon, 7 Feb 2011 01:33:23 -0800
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: Dave Cardwell <dave.cardwell1@gmail.com>, NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 7, 2011, at 12:50 AM, Iljitsch van Beijnum wrote:
> On 4 feb 2011, at 22:02, Dave Cardwell wrote:
>=20
>> Without wanting to get into whether NAT provides security to hosts
>> that exist on the inside. I am curious if the potential to overflow
>> ND caches with incomplete* entries exists on currently shipping CPE
>> hardware and if NAT helps prevent this?
>=20
>> e.g.
>> In v4 with a /24 on the inside an attacker can send a single packet =
to
>> each consecutive address causing at most 254 arp requests to be sent
>> on the lan segment and upto 253 incomplete entries, until they
>> timeout.
>> In v6 with a /64 on the inside it seems like the same tactic would
>> lead to more outstanding ND requests than any realistically sized
>> cache would support.
>=20
> Ok, I had a hard time making up my mind whether a sarcastic or a =
factual response was in order...
>=20
> This is of course a very big problem, and one of the reasons why =
everyone who's tried IPv6 immediately turns it off again: script kiddies =
are continuously scanning the entire IPv6 address space so this happens =
to regular IPv6 users all the time.
>=20
Uh, no.
1. Scanning even an entire /64 at 1,000 pps will take =
18,446,744,073,709,551 seconds
which is 213,503,982,334 days or 584,542,000 years.
I would posit that since most networks cannot absorb a 1,000 pps =
attack even without
the deleterious effect of incomplete ND on the router, no =
network has yet had even
a complete /64 scanned. IPv6 simply hasn't been around that =
long.
Claiming that anyone (or any collection of random people) is =
even capable of continuously
scanning the entire IPv6 address space is absurd.
2. The few scanning attacks we've seen haven't gotten very far =
before giving up.
We've not had any negative ND effects as a result.
> Since this is a problem that is inherent to the ND protocol that is =
impossible to fix without modifying the IPv6 standards significantly, =
the easiest way to solve this with the least amount of impact to =
applications, the ability to host services and the end-to-end model in =
particular is to use a single public IPv6 address and NAT all local =
stuff behind it.
>=20
That's a horrible solution. For one thing, it breaks the end-to-end =
model you claim you are protecting.
Further, it doesn't really help and there are much better solutions.
For example, on point-to-point links, block traffic to addresses outside =
of the assigned addresses
on the link.
Fast flushing of incomplete ND entries can also help here. That may =
require a software upgrade in
some routers, but, it doesn't require a rewrite of the protocol =
standards.
Finally, an SPI firewall shouldn't be permitting most of that traffic =
in, since it should only be
permitting packets in to hosts that have legitimate external services on =
them. As such the
sweep should only generate ND traffic for hosts that exist and provide =
external services.
> (BTW, there have been some discussions on NAT66 in the IETF, but that =
wouldn't be a port overloading 1-to-many NAT, but rather a 1-to-1 NAT, =
because with IPv6, there obviously isn't any reason to use address =
sharing. The thinking is that such a 1-to-1 NAT is less harmful than a =
port overloading 1-to-many NAT so it would be beneficial to specify the =
former to avoid the latter. But many people within the IETF don't =
support that strategy.)
A 1:1 NAT wouldn't solve your ND problem. The traffic will be dutifully =
translated and
still generate a sweep of ND packets.
Owen
