On Tue, 20 Apr 2010 12:59:32 -0700 Owen DeLong <o...@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 > >
