On Tue, 27 Jul 2010 12:34:40 -0700 Owen DeLong <owen@delong.com> wrote:
On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote:
Please see comments inline.
On 7/22/10 10:13 PM, "Owen DeLong" <owen@delong.com> wrote:
In all reality:
1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change.
2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal.
I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available.
It's only water under the bridge for IPv4. If we start putting NAT66 into play, it will be the same thing all over again.
Additionally, it's only water under the bridge for existing applications. Each new application seems to go through the same exercise because for some reason, no two NAT gateways seem to have exactly the same traversal requirements and no two applications seem to implement the same set of traversal code.
What is worse about that is that we networking people have ended up shifting the cost of fixing our problem onto the application developers and onto the application users. Because we don't provide end-to-end visibility between peers on the Internet ("Internet transparency" - see RFC4924), application developers have to try to develop methods of doing that themselves. As you've said, this creates additional application complexity, additional bugs, and duplicate functionality between different applications, all at the application layer. (HTTP has become the de facto substrate protocol of the Internet because firewalls permit it, and client server communication has become the de facto communications method for applications that would truly benefit from peer-to-peer communications (i.e. more scalable, more available), because client server overcomes the lack of global reachability NAT creates)) Who pays this additional application development cost? Everybody, including us networking people, because we also use applications too. We get code that is possibly more buggy because it is more complex, written by people who are usually not networking code experts. We might miss out on better user interfaces or less buggy code that's there to do what the application's purpose is, because that time was instead spent on developing network layer work arounds. It seems to me that the best place to solve problems is whether they exist or where they're caused. Those solutions usually solve the problem properly, and commonly are also the cheapest way to solve it. The network layer is where these problems exist, and that's where they should be solved. We should use IPv6 to restore Internet transparency, so that application developers don't have to do it for us - again. We'll end up with a better and simpler Internet to operate, and better and/or cheaper applications. Regards, Mark.
The elimination of NAT is one of the greatest features of IPv6.
Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall.
I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing.
Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT.
Owen
Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this.
Not so much... SOHO gateways should implement stateful inspection with the same default policy a NAT box provides today...
1. Outbound packets create a state table entry. 2. Inbound packets are only forwarded if they match an existing state table entry.
Pretty simple, actually.
Owen