Re: Failure modes: NAT vs SPI

[Owen DeLong <owen () delong com>]

On Feb 7, 2011, at 12:50 AM, Iljitsch van Beijnum wrote:

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