Home / Blogs

Lights Going Out on the Internet? Not Just Yet

In his article titled, “End of Life Announcement”, John Walker (author of the Speak Freely application) makes a few arguments about Network Address Translation (NAT) that are simply not true:

“One need only read discussions on the Speak Freely mailing list and Forum over the last year to see how many users, after switching from slow, unreliable dial-up Internet connections to broadband, persistent access via DSL or cable television modems discover, to their dismay, that they can no longer receive calls from other Speak Freely users. The vast majority of such connections use Network Address Translation (NAT) in the router connected to the broadband link, which allows multiple machines on a local network to share the broadband Internet access. But NAT does a lot more than that.

A user behind a NAT box is no longer a peer to other sites on the Internet. Since the user no longer has an externally visible Internet Protocol (IP) address (fixed or variable), there is no way (in the general case—there may be “workarounds” for specific NAT boxes, but they’re basically exploiting bugs which will probably eventually be fixed) for sites to open connections or address packets to his machine. The user is demoted to acting exclusively as a client. While the user can contact and freely exchange packets with sites not behind NAT boxes, he cannot be reached by connections which originate at other sites. In economic terms, the NATted user has become a consumer of services provided by a higher-ranking class of sites, producers or publishers, not subject to NAT.

There are powerful forces, including government, large media organisations, and music publishers who think this situation is just fine. In essence, every time a user—they love the word “consumer”—goes behind a NAT box, a site which was formerly a peer to their own sites goes dark, no longer accessible to others on the Internet, while their privileged sites remain. The lights are going out all over the Internet. My paper, The Digital Imprimatur, discusses the technical background, economic motivations, and social consequences of this in much more (some will say tedious) detail. Suffice it to say that, as the current migration of individual Internet users to broadband connections with NAT proceeds, the population of users who can use a peer to peer telephony product like Speak Freely will shrink apace. It is irresponsible to encourage people to buy into a technology which will soon cease to work.”

Traffic is transported in envelopes called packets. They are very comparable with real life envelopes: they both carry a to-address as well as a from-address. The postal system knows how to get it from [from] to [to] in a magical way as long as you deposit the envelope in the mailbox. It might bounce it back if something goes wrong down the way. So far so good. However, the envelopes also carry a certain color, called a port number. From this color, the receiving end can determine where to send the envelope to internally. For example, if a “blue” envelope arrives at my server, it knows the web server program should get it and process whatever’s in the envelope, while as a “red” envelope arrives, that one should be passed to the mail handler. There are about a 1000 predetermined envelope colors defined. If a colored envelope arrives at a system where it has no decent handler for, the envelope is simply thrown away. Of course, the system knows where to send answers to, by just reversing the from and to labels.

Pretty smart concept right? Wrong. The whole concept crumbles when I open two browsers [or tabs] at the same time and browse to the same server. The system would have no idea how to distinguish the traffic for the two sessions: both would have the same to and from addresses, as well as use the same envelope color. So the system is just a bit smarter. Only the first envelope sent is actually in the predetermined color. As soon as the two systems communicating over the internet have established a session, they determine an arbitrary envelope color just for the time of that session. In terms of browsing, one can think of a session as the exchange of traffic for building one page. There are about 64000 arbitrary envelope colors available.

So where does NAT come in? Just as in the real world, an ISP will only give you one address in the internet world. For a dial-up connection, this usually is not a big deal. But on a cable or DSL line, one usually wants to connect more than one computer. Actually, an office with 300 computers would also like to have them all connected to the internet, but might not want to have 300 individual addresses. NAT is a clever solution that takes a bit of the envelope sorting out of the computers, while at the same time, those computers are not aware of that. Think of a NAT router as the janitor in an apartment building: the building has just one address and all envelopes coming from that same address. As one of the apartment owners send out a “blue” envelope, the janitor remembers it and when the answer arrives, he knows he has to dispatch that answer to the right apartment owner. As unique colors are quickly assigned to a particular session, the smart janitor can uniquely distinguish what response goes where. Note that neither the apartment owner, nor the addressee actually has knowledge about the janitor and what he’s doing.

So what happens with incoming envelopes that are initiated by somebody “outside”, instead of being responses to letters initiated from within the building? As the janitor has no way of knowing what apartment to send it to, he does the only thing possible: throw it away. And that is the nice side effect of NAT. It effectively blocks all unsolicited traffic; major security device! So far everything’s in line with the article I mentioned: all systems are “hidden” behind a janitor. This also implies that systems that are designed to be public, i.e. an internet web server can, by definition, never be NATted. They must have their own address, their own “house” to be reachable. In short: NATted systems are secured from the outside world, but as long as they initiate their sessions, are by magic fully functional.

Now, there are two exceptions to the inbound envelope thing. First is called Port Address Translation or PAT. PAT is actually very simple: give the janitor a small, fixed table stating that if an unsolicited envelope with a certain predetermined color comes in, it should always be passed to a certain apartment within the building. It’s like saying to the janitor: throw away all unsolicited envelopes, unless it’s about cars, in which case it should go to number 12. By definition, a color can only be linked to one apartment. The janitor does not have a copier. With this mechanism, you can still create i.e. a public web server behind a NAT device. One has to know the color and the internal address. It’s even possible to instruct the janitor to send all unsolicited envelopes to a single apartment. Note that this apartment will then receive all unsolicited incoming traffic, effectively canceling the security side effect.

The other exception is actually not an exception but clever application design. Take i.e. ICQ. One can happily chat while all parties are behind a NAT router. The crux is that all users connect to a central, public system. The sessions are initiated exclusively by the user. As soon as the session is established, messages can be transferred from user A to the server and then passed by the server to user B, using the session user B initiated earlier. P2P designers took the concept a bit further as they let each single user determine if they are NATted. The unNATted users pass traffic on behalf of other, NATted users. What’s really clever about that design is that it will dynamically create “servers” throughout the internet, so more capacity emerge as unNATted users connect. It is quite scary to discover that even behind NAT other users can still download from your shared KaZaa folder or call you with Skype. Now you know to make that happen, one needs intermediate systems your computer connects to, to make it work. Remember that without some kind of PAT rule, two NATted users can never create a single session between each other. It also means one should really, really trust those P2P programs, because if they carry some kind of malicious payload, the added security added by NAT is nixed.

So, are the lights going out on the internet? Most certainly not, at least not because of NAT. Does it affect the addressability of end-users? Most certainly yes and with that it added improved security; personally, I’m very nervous to use the phone to connect instead of the NATted connection I use at home because I know what’s being blocked and I’m never certain about which programs on XP respond to certain incoming colored envelopes. NAT does not replace a decent firewall, but it’s much better than nothing. Is NAT circumventable? Oh yes, if one use centralized or dynamically assigned servers. John Walker shouldn’t whine but take a look at Skype or other P2P systems.

By Jeroen Meijer, Independant network and groupware consultant

Filed Under

Comments

Javier  –  Jan 24, 2004 9:51 AM

I am sorry, but you missed the whole point. As long as you are behind the NAT, you wil always need somebody else’s help to cross the NAT barrier, name it “an outside server on a P2P network” or “PAT rule”. The fact is that as a user behind a NAT you no longer can accept spontaneous incoming traffic unless that traffic first goes first to somebody else for clearing before it arrives are your computer door. Before NAT, you could setup your own Webserver (similar to hanging your shingle out of your door) anytime you wanted and anyone on the internet could find you out. Now you need somebody’s permission (the PAT server manager) or the help of mysterious elves (P2P users on selected protocols) to hang out your shingle. That is the whole point of John Walker’s article.

Pierre Beyssac  –  Feb 15, 2004 4:39 PM

Your colored-envelope analogy is nice but not correct in the way you describe it. There are TWO colors, one on each end. The “first envelope color” and “arbitrary envelope color” negociation you describe do not exist in TCP: the envelope colors stay the same throughout the connection. The only arbitrary envelope color is (in general) on the client side.

This is the basic way a TCP connection works, and it is how the web uses TCP. Other protocols may have different, more complicated schemes (for example FTP). This can interfere with NAT processing.

Jason  –  Feb 17, 2004 9:26 PM

I thought this analogy was beautiful. I’m encouraging people to read it! Of course, Pierre Beyssac post made and important correction to the description of TCP and UDP communication: 2 colors and a to-address and from-address needed, arbitrary client color (usually non-overlapping with server colors). I guess the correction could be that there is a colored envelope and colored note paper and depending on the direction of the communication the note and envelope exchange color.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

New TLDs

Sponsored byRadix

Cybersecurity

Sponsored byVerisign

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

DNS

Sponsored byDNIB.com