Re: Failure modes: NAT vs SPI
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.)
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
On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote:
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.
Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds?
On Feb 10, 2011, at 7:53 AM, Lamar Owen wrote:
On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote:
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.
Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds?
The point is that you DOS the network on traffic before you can usefully scan it. A 600 million node botnet scanning a /64 on a gigabit ethernet can still only successfully inject ~1,000,000 PPS or less. Even if we assum 1,000,000 pps success rate, you've only reduced the scan time to 584,542 years. Even if you're somehow able to get 600 million nodes to successfully inject 1,000,000,000 packets per second (an unachievable number in any present day technology) you still need 584 years to scan a single /64 subnet. Owen
On 2/10/11 7:53 AM, Lamar Owen wrote:
On Monday, February 07, 2011 04:33:23 am Owen DeLong wrote:
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.
Sounds like a job for a 600 million node botnet. You don't think this hasn't already crossed botnet ops minds?
There are more useful things to do with the compute cycles...
----- Original Message -----
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
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...
I see you decided to go with "sarcastic".
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.
I'm sure it's clear to you that "no one's doing it now" is not a valid response to prophylactic secure network planning...
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.
So, you're not going to actually address the problem seriously? Got it. Cheers, -- jra
On Mon, 07 Feb 2011 11:15:51 EST, Jay Ashworth said:
From: "Iljitsch van Beijnum" <iljitsch@muada.com> 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.
I'm sure it's clear to you that "no one's doing it now" is not a valid response to prophylactic secure network planning...
Iljitsch's claim is that enough script kiddies *are* doing it now that people's routers crash and they turn off IPv6, not that "people are so scare of it they panic and turn it off before they see if it's a problem". For what it's worth, I've never seen an IPv6 scan cause a problem for our network. Not saying that such a scan *wouldn't* cause a problem, but the fact we've been doing it for over a decade and not seen a big problem seems to go counter to "everyone who turns on IPv6 gets hit by it".
On 2/7/2011 10:43 AM, Valdis.Kletnieks@vt.edu wrote:
For what it's worth, I've never seen an IPv6 scan cause a problem for our network. Not saying that such a scan*wouldn't* cause a problem, but the fact we've been doing it for over a decade and not seen a big problem seems to go counter to "everyone who turns on IPv6 gets hit by it".
I think it becomes a problem only in certain architectures. ie, providing /64 subnets without SPI can lead to a scan actually able to create effect ND. This implies that many networks aren't necessarily effected by it, as they implement a certain level of security. I'd also surmise that IPv6 scanning isn't as prevalent today as it will be at some point. Nachi was an interesting (even if illegal) concept except for being overly aggressive. Jack
On 7 feb 2011, at 17:15, Jay Ashworth wrote:
Ok, I had a hard time making up my mind whether a sarcastic or a factual response was in order...
I see you decided to go with "sarcastic".
Not sure if Owen noticed... :-)
I'm sure it's clear to you that "no one's doing it now" is not a valid response to prophylactic secure network planning...
Well, no and yes. There's only a few panes of glass keeping people out of most houses. We know glass is easy to break. We know it gets broken and people get in who aren't wanted there once in a while. Still only a few people see the need to install steel bars in front of their windows. In real life we take risks all the time. In the networked world somehow it always has to be all or nothing, with few people occupying the reasonable middle ground. But in this case, we know there's a potential problem and waiting for it to become acute is not the best approach.
So, you're not going to actually address the problem seriously?
Vendors should modify their neighbor discovery implementations such that it still works even when large numbers of addresses are scanned. The easiest way would be to keep only a limited number of incomplete ND cache entries and throw those away on an LRU base, but create a full ND cache entry that is kept around when a neighbor advertisement is received, even if there is no incomplete ND cache entry at that time. AFAIK the incomplete ND cache entries don't do anything we can't do without. "Solving" this with NAT is the classic example of shooting a mosquito with a canon. I also don't think any protocol modifications are necessary.
participants (7)
-
Iljitsch van Beijnum -
Jack Bates -
Jay Ashworth -
Joel Jaeggli -
Lamar Owen -
Owen DeLong -
Valdis.Kletnieks＠vt.edu