[136960] in North American Network Operators' Group
Re: Failure modes: NAT vs SPI
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Mon Feb 7 03:52:07 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <AANLkTimBSCeKr8_e0YfuSmgzoSwO2DGDFqHer096t247@mail.gmail.com>
Date: Mon, 7 Feb 2011 09:50:55 +0100
To: Dave Cardwell <dave.cardwell1@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 4 feb 2011, at 22:02, Dave Cardwell wrote:
> 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?
> 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.
Ok, I had a hard time making up my mind whether a sarcastic or a factual =
response was in order...
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.
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.
(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.)=
