I don’t particularly want to see the end of NAT. There is something comforting about a routing boundary between the Internet and my own private networks: the assurance that there is no theoretical way for hosts on my private network to be addressed by the big hostile Internet-at-large except when the NAT process causes such a connection to be possible. Sometimes my use of non-Internet-routable addresses is a *feature*, not a compromise. The “man-in-middle” whose presence you lament is sometimes a much-wanted border guard.

It may be that the same effect can be achieved with IPv6 and an appropriate firewall configuration. Be that as it may, there’s an awful lot of upgrading and retraining involved in the transition to IPv6 for no obvious benefit. Assume for the moment that if I make the migration to IPv6, I’ll want to use a firewall to re-create the lack of end-to-end connectivity I had under NAT, just to simplify my security concerns. Now remind me, why do I want IPv6?

I belong to the school of thought which says we should start designing NAT-friendly and proxy-aware protocols, rather than push for universal end-to-end connectivity. This puts me on the other side of an ideological chasm, of course (although it doesn’t hurt for protocols to be proxy-aware even when full end-to-end addressing is possible). My argument is this: I believe in the end-to-end principle for any given network, like the Internet, but I no longer want many of my machines to actually be *on* the Internet directly, because the Internet is a hostile environment. That’s the facet of this problem that the IPv6 end-to-end boosters too often overlook: network segregation is sometimes a feature, not a compromise, and we need to design protocols that don’t *demand* end-to-end in order to work.

By these criteria, most of the VoIP protocols are found wanting and need fixing. Suggesting that we migrate to IPv6 to solve the problem is the wrong answer, because if and when we do that migration, firewalls will still prevent end-to-end connections in many cases. You could, of course, suggest to systems administrators everywhere that their firewalls are hurting the end-to-end principle, and should therefore be removed. Just be sure to have an escape route planned before you suggest it, and be prepared to duck.

At best, NAT = false sense of security.

Security by obscurity does not work. :-)

I’d like to hear a better argument than that. Security by obscurity is where I don’t tell you what my IP address is. NAT is (roughly speaking) where you can’t address a packet to my host unless it contacts you first, even if you *know* what my IP address is. A NATing router would have been a perfectly good defence against the Blaster Worm, for example (until such time as someone brought the worm into the network some other way).

You’ve given me the brush-off, and I’m not impressed by it, smiley notwithstanding.

Brett,

Below are a number of URLs to documents describing the issues that NAT creates, or how it damages the end-to-end model of the Internet and why that damage is worth avoiding.

The first one is the most important - it describes why end-to-end is the best way to implement network based services, and why it is the model that has been followed during the design of the Internet.

END-TO-END ARGUMENTS IN SYSTEM DESIGN

The old telephone network was the opposite of the “end-to-end” architecture, as services were implemented in the network, rather than at the edges. There was a reason for that, now that reason has gone. Building services within the network increases the costs of the network, with one of the major ones being the deployment of new, network based services.

The end-to-end argument can be summarised as “dumb network, smart hosts”. This paper describes why the Internet architecture ie. end-to-end is better than the “smart network, dumb hosts” model.

Rise of the Stupid Network

NAT builds both state and application understanding within the network. It moves away from the “dumb network, smart hosts” model. This naturally increases the costs of the network, which the users of that network ultimately end up having to bare. It is not the cheapest or optimal solution to the problem.

There are a number of documents which either wholy or partly address the implications of NAT. They aren’t necessarily only providing theoretical argments against it, they also provide practical examples of where NAT creates costs that would be best avoided :

Architectural Implications of NAT

Why are NATs so popular?

Things that NATs break

Anatomy

IP Network Address Translator (NAT) Terminology and Considerations

Traditional IP Network Address Translator (Traditional NAT)

NAT also fails the simplicity goal - in addition to modifying the destination or source IP address in each IP packet, it also has to modify the TCP checksum (as the TCP checksum covers a pseudo header which includes the IP addressing information carried in the IP packet header). Also, for protocols such as FTP, which carry IP addresses in text format, the NAT box may have to offset TCP sequence numbers if it has to increase the length of the IP address within the payload eg “10.1.1.1” being expanded to “192.88.20.15” increases the number of characters in the payload, which requires the TCP sequence numbers in the TCP header to be offset / reset as the packet traverses the NAT box. This problem gets real ugly when the “10.1.1.1” is split across two TCP segments, which TCP is quite freely permitted to do. All this is assuming that the NAT box understands the application protocol in the first place.

More broadly, NAT is really deployed to directly fix “duplicated” or “overlapping” address spaces. Security is not really the reason - a firewall deployed with public address space is as secure. A couple of good links on why duplicated address spaces are worth avoiding. Note that the second is referring to IPv6 “site local” addresses, which are the IPv6 “version” of RFC1918. The same arguments apply to IPv4/RFC1918. I’ve personally been burnt by the VPN issues identified.

Network 10 Considered Harmful (Some Practices Shouldn’t be Codified)

Deprecating Site Local Addresses

VoIP technology has been around for a long time. Maybe it hasn’t become the next “killer app” because of NAT ? If VoIP could have been deployed just as easily as web browsers were (by end-users downloading it onto their edge-devices, and not having to upgrade their “router” ie. router + NAT box), we may have had cheaper phone calls for the last few years.

(and yes, I’m the Mark Smith you probably think I am)

I’ve also written about some of my bad experiences with NAT as a comment to the following article, also on this site :

IP or NAT IP: Mostly IP

All this IPv6 / NAT discussion reminded me of something Tony Hain pointed out a while a back on the IPv6 IETF mailing list.

Tony pointed out that IPv6 is inherently better at hiding a users machine than IPv4 NAT, as a users’s PC will typically be connected to a LAN segment which has been allocated a /64. A /64 leaves 64 bits for the node address, giving a total of (2^64) or 18 446 744 073 709 551 616 possible addresses. The user’s PC could be at any one of these addresses, based upon the IEEE MAC address of their LAN card.

If an attacker could probe 100 addresses per second (using a tool such as nmap), and assuming that the attacker would find a machine on average 50% through the address space, it would take an average of 92 233 720 368 547 758 seconds to find the user’s device, or 2 924 712 086.77 years!

If the user still isn’t happy with those odds, their node address could be changed periodically, say once a day, via Privacy Extensions for Stateless Address Autoconfiguration in IPv6.

The current recommendation for IPv6 address allocation, for all users, including those at home, is a /48, which reserves 16 bits for 65 536 subnets of 64 bits (IAB/IESG Recommendations on IPv6 Address Allocations to Sites). The truely paranoid could extend the randomness of their periodic node address selection to including some, if not all of those 16 subnet bits, assuming they are willing to automate their local router’s subnet configuration. Of course, for every subnet bit included, the work the remote attacker has to perform to find the user’s PC doubles.

While I wouldn’t recommend it, I’d almost go so far as saying for a typical home user, IPv6 without a firewall of any sort will be just as effective as IPv4 + NAT is at “hiding” their PC.

In other words, remote attacks which rely on finding a target via an address probe are useless under IPv6, as they aren’t worth the time. Aren’t they the only type of attacks that IPv4 NAT inherently protects against ?

Social engineering attacks will then probably become the alternative to address probing, using techniques such as convincing a user to download something they shouldn’t from an untrusted web site, or sending them a malicious payload in an email. Of course, IPv6 won’t protect against those types of attacks, then again, neither does IPv4 + NAT today.

Thanks, Mark, for that well-considered response. Some of the points you’ve raised are quite interesting. A sparsely populated address space like IPv6 will certainly have an impact on how malicious code propagates.

But in response to your last point, the security offered by a difficult-to-guess IPv6 address is still not quite as strong as NAT. The security offered by IPv6 is more like what James called “security by obscurity”, since anyone who actually knows your IP address can send packets to your computer. With NAT, the knowledge of the address is unhelpful, since the address isn’t routeable. The avenues of attack in NAT are limited to those that can be conducted where the victim host initiates contact with the hostile host.

Now, as you’ve pointed out, IPv6 addresses aren’t really guessable in a useful way, but they’re not what you would call closely guarded cryptographic secrets either. You reveal your IP address to any host with which you initiate contact, and also potentially to anyone in a position to eavesdrop any of that communication. Is there some DNS record pointing at you, perhaps? The surest way to be safe in IPv6 world (without a firewall) is to not talk to any other hosts: that way you can be relatively sure that your address remains unknown. Anything more than this is something of a compromise.

To achieve the security of NAT in an IPv6 environment, you’d need a router which does the NAT-style state management without actually translating addresses. A firewall, essentially, with reduced complexity relative to full NAT, but a man in the middle that deliberately breaks end-to-end connectivity all the same.

This is more or less my point: on the one hand, I think that the end-to-end design of smart hosts and dumb routers is the best thing since sliced bread; but on the other hand, there are strategic points at which we all want to break that model for security reasons. NAT breaks it. Firewalls break it. Even if we disposed of NAT with IPv6, most of us would still create largely isolated sub-networks for security reasons. I think we need to better understand this issue and start thinking about a network model that embraces it. Think of it as networks with customs checkpoints and border guards. The network is still dumb in the middle and smart at the edges, but there may be “border crossings” involved in getting from one point to another, and these count as a form of “intermediate edge”, if you like.

By embracing NAT I’m taking on a sort of “devil’s advocate” role, of course. NAT is a hack, and creates all sorts of problems: I won’t even attempt to deny that. (Some of your references I’ve already seen; the others I’ll be sure to read in future.) Even so, NAT provides useful effects, beyond compensating for IPv4’s address limitations; NAT is not *just* a problem to be eliminated. If we want to work towards a cleaner solution, we must understand this, and incorporate NAT’s benefits into the new way of doing things, while getting rid of its ugliness.

I suspect that such a revised model of networking will also have a thing or two to say about application protocol design. Few of our existing protocols have been designed with security checkpoints in mind, nor do we have much in the way of protocols by which a host can negotiate (with a border guard) right of passage for incoming guests.

But enough speculating about theory for now.

Brett Watson wrote :

“To achieve the security of NAT in an IPv6 environment, you’d need a router which does the NAT-style state management without actually translating addresses. A firewall, essentially, with reduced complexity relative to full NAT, but a man in the middle that deliberately breaks end-to-end connectivity all the same.”

Brett, you may also be interested in having a read of Distributed Firewalls by Steve Bellovin -

“Conventional firewalls rely on the notions of restricted topology and controlled entry points to function. More precisely, they rely on the assumption that everyone on one side of the entry point—the firewall—is to be trusted, and that anyone on the other side is, at least potentially,  an enemy. The vastly expanded Internet connectivity in recent years has called that assumption into question. We propose a “distributed firewall”, using IPSEC, a policy language, and system management tools.  A distributed firewall preserves central control of access policy, while reducing or eliminating any dependency on topology.”

A firewall on each end-user edge device sounds a bit over the top, until you realise that that is already happening. I think I read that starting at the low end version, XP has a firewall out of the box, and SP2 for XP enabled some fairly strict default firewalling rules. Of course, many of the *nix distributions, intended to run on end-users PCs, have firewalling out of the box as well. End user firewalling at the edge is happening because of necessity, rather than by design.

Of course, by putting the firewall on the communication end points, rather than in between them, end-to-end is restored. We return to the pure “dumb” network, a stateless, application agnostic bit delivery infrastructure, again returning all the smarts to the edge.

Many of the changes that have come in paradigm shifts, like vinyl albums to CD, like VCR to DVD, and even in the current drive for Standard PAL, SECAM, and NTSC analog television signals moving to Digital, High Definition broadcasts happen because there is some exciting value proposition in the time/money investments that go along with them.  Digital media offered improvements along with the investment.

Infrastructre based changes are less exciting to the general consumer, as the benefit is not apparent to them.

To the layman, (and I apologize that this is a US-Centric example) the move towards IPV6 is not much different than when we went from 5 digit zip codes (90210) to using the +4 zipcodes (90210-3465).

In the case of IPV6, the motivation has not shown itself in a “Hey, this is completely important!” way to the audience… Those that ultimately make those investments.

There has been one driving push towards IPV6, which is the fear of scarcity in the IPV4 numbering space.  RFC 1918 (NAT), in combination with Masquerading and Proxying created a very strong dent in the argument of scarcity in the IPV4 space. 

While there are values to End-to-End, peer-to-peer that are gained from IPV6 for more seemless SIP (et al.), the fundamental technology has IPV4 compatible workarounds (STUN, DNSproxy, UDP over HTTP, etc.).

I am willing to bet that new uses which inspire people to spend the time and money to upgrade are going to be what truly drive any form of widescale adoption of IPV6.

Sure, there are many cool new applications, threedegrees, toredo, SIP, VOIP, and other technologies are able to utillize IPV6, yet all work with IPV4.

If the next ‘killer app’ were to offer advanced features in the presence of IPV6, or for that matter simply require that IPV6 be used, it would drive more adoption.

Adoption is the key here, and market forces are what will ultimately drive adoption of the technology. 

The link to the IPv4 exhaustion presentation (http://bgp.potaroo.net/ipv4/) is broken :(

Is it still possible to reach it somewhere? It spotted my interest, and I’d like to know what the arguments are. As it was made years ago, do you believe it is still applicable today?