Rate of growth on IPv6 not fast enough?

Tue Apr 20 22:38:21 UTC 2010

On Tue, 20 Apr 2010 12:59:32 -0700
Owen DeLong <owen at delong.com> wrote:

> 
> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
> 
> > Jack Bates wrote:
> >> .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various
> >> programs that dislike multiple connections from a single IP, and the
> >> crap load of vpn clients that appear on the network and do not support
> >> nat traversal (either doesn't support it, or big corp A refuses to
> >> enable it).
> > 
> > If this were really an issue I'd expect my nieces and nephews, all of whom are big
> > game players, would have mentioned it.  They haven't though, despite being behind
> > cheap NATing CPE from D-Link and Netgear.
> > 
> > Address conservation aside, the main selling point of NAT is its filtering of inbound
> > session requests.  NAT _always_ fails-closed by forcing inbound connections to pass
> > validation by stateful inspection.  Without this you'd have to depend on less
> 
> Repeating the same falsehood does not make it any less false.
> 
> > reliable (fail-open) mechanisms and streams could be initiated from the Internet at
> > large.  In theory you could enforce fail-closed reliably without NAT, but the rules
> 
> Stateful Inspection can be implemented fail-closed. I point to Juniper ScreenOS
> and Services JunOS as examples of this.  Absent a specific permit or specific
> configuration telling it to pass particular traffic inbound, traffic must pass the same
> stateful inspection that NAT would require.  This is default behavior in those boxes.
> The rules are not complex at all.
> 

Frankly, when you hear people strongly using the argument stateful
firewalling == NAT, you start to wonder if they've ever seen a stateful
firewall using public addresses.

> > would have to be more complex and complexity is the enemy of security.  Worse, if
> > non-NATed CPE didn't do adequate session validation, inspection, and tracking, as
> 
> Again, you simply are not correct here. I'm not sure what level of implementation is
> available in low-end gear as it hasn't met my needs in a long long time.  However,
> I will say that although an SRX-100 is not especially low-end at 10x absolute low
> end pricing and 5x average home gateway pricing, it is low-enough end that I
> know this can be done in reasonable gear.
> 
> > low-end gear might be expected to cut corners on, end-user networks would be more
> > exposed to nefarious outside-initiated streams.
> > 
> Frankly, even with NAT, corner-cutting in those areas can lead to things passing which
> you don't expect.
> 
> > Arguments against NAT uniformly fail to give credit to these security considerations,
> 
> Because they are false.  It's not that they fail to give credit to them. It's that they know
> them to be false. It's like saying that discussions of breathing gas fail to give credit
> to the respiratory effects of the trace amounts of argon present in the atmosphere.
> 
> > which is a large reason the market has not taken IPv6 seriously to-date.  Even in big
> > business, CISOs are able to shoot-down netops recommendations for 1:1 address mapping
> > with ease (not that vocal NAT opponents get jobs where internal security is a
> > concern).
> > 
> While I recognize that there is a group of people who religiously believe that NAT
> has a security benefit, I don't think the represent a significant fraction of the reasons
> IPv6 is not getting deployed. Frankly, many of them have more IPv6 deployed than
> they realize and their NAT is not protecting them from it at all. It may even be helping
> some of the nefarious traffic that may be taking advantage of the current situation
> to remain safely anonymized and invisible.
> 
> 
> Owen
> 
> 