The ugly side of NAT

Today, Network Address Translators (or NAT) devices are everywhere. Their rapid rise towards universal adoption was not part of a planned effort. Instead, it was fueled by the continued growth of the internet and the corresponding depletion of the IPv4 address space. Besides obvious advantages, such as IP address reuse and hiding of internal network topologies, NAT technology has some important drawbacks as well. This blog post takes a closer look at these downsides.

History of NAT

The concept of Network Address Translation was first described in a 1994 memo (called RFC 1631) by Kjeld Egevang and Paul Francis. The objective of NAT was to create a mechanism allowing IPv4 addresses to be shared across numerous devices.  Although IPv4 was capable of uniquely addressing some 4.4 billion devices, it was already evident in 1992 that the world was heading down a path of very intensive deployment of IP-based devices. IPv4 would never be able to cover the full range of future device deployment. Using NAT could help overcome this imminent address exhausting.

In addition, it was intended that NATs could be deployed incrementally within the Internet, without causing changes to hosts or other routers. After all, the original RFC describes NAT as a measure capable of “providing temporarily relief while other, more complex and far-reaching solutions are worked out.”

Two decades later, with the long term solution (IPv6) defined for over 15 years and its deployment finally commencing, NAT still dominates the edges of the internet landscape and is still being deployed.

Advantages (Killer features)

A lot of information has been written about the advantages of NAT so here is a summary:

• it prevents the shortage of IPv4 addresses.
• it provides a basic level of security. Only traffic that was initiated from behind the NAT at the LAN side will be forwarded.
• it separates the internal IP network from the public IP address provided by the internet service provider (ISP), so switching between ISPs becomes easy.

Disadvantages (Killer issues)

NAT doesn’t only bring good things, it has some disadvantages as well. Because NAT was developed as a temporary technology, it was not designed with new technologies and protocols in mind. Those protocols therefore have to add a kind of intelligence to overcome these issues.

No strict specification of implementation

IETF was not in favour of standardizing the NAT behaviour, as this would only encourage its deployment. They saw this technology only as a “temporary measure”. Therefore the original specification remained at a general level. However, this forced each NAT implementer into making local decisions as how the NAT should behave under specific circumstances.

We now enjoy a network with widespread deployment of an active device that does not have consistent implementations and, in the worst cases, exhibits non-deterministic behavior. This has made the deployment of certain applications on the internet, such as voice-based applications, incredibly difficult.

Peer-to-peer communication

NAT cannot support applications where the initiator lies on the “outside”. Because the local addresses behind the NAT are private they can’t be routed across the internet. Therefore it’s impossible for the external device to direct any packet to that device behind the NAT in order to initiate a session. This implies that peer-to-peer services, such as voice, cannot work unaltered in a NAT environment.The protocol has to implement its own way to overcome this problem.

The generic approach here for applications to traverse NATs in the “wrong” direction is for the inside device to forge a connection to the outside agent, and for the inside device to then establish what NAT translated address has been used, and the nature of the NAT in the path, and then republish this address as the local entity’s published service rendezvous point. Sounds fragile? Unfortunately, it is.  Passive FTP is one of those implementations. In the VoIP world they use ICE (Interactive Connection Establishment) and STUN servers (Session Traversal Utilities for NAT) to discover the presence of the Network Address Translator and to obtain the mapped (public) IP address (NAT address) and port number that the NAT has allocated for the application’s UDP connections to remote hosts. Skype uses SuperNodes, which are on a public IP, to traverse a NAT and relay the call.

IP Fragmentation and out-of-order

When an IP packet is bigger than the Maximum Transmission Unit (MTU) of the interface, it gets fragmented into smaller frames. The TCP or UDP header is found only in the initial IP fragment (see Frame 1 on picture below) . The subsequent IP packet fragments do not contain a copy of the transport layer packet header (Frame 2 to Frame N).

NAT devices do not have a clear and uniform response to this fragmentation, as they normally rely on the (now missing) TCP/UDP header of each arriving frame for translation. Some of them attempt packet reassembly as if they were the end host and perform the NAT translation only when the original IP packet is reassembled. Of course the reassembled packet may itself be too large to be forwarded, in which case the NAT is forced to further fragment the packet. Other NAT devices do not attempt packet reassembly, but rely on a packet fragment translation state indicating how subsequent fragments must be translated.

This form of behavior becomes a problem when IP fragments arrive out of order, i.e. when some fragments are received before the first IP packet fragment. In such cases, the NAT often has little choice but to silently discard the out of order fragments.

IPSEC

IPSec (Internet Protocol Security) uses a cryptographic hash value for data integrity. But NAT changes the IP packet, thus invalidating those integrity checks.

There is a solution, however, in NAT Traversal or NAT-T. Basically, NAT-T (RFC 3947 and 3948) detects the presence of any NAT devices between two hosts and encapsulates the IPsec traffic in a possible second UDP using a non-IPsec port number. Now when this packet arrives at the NAT, it can safely alter the IP header and UDP header for its translation without invalidating the IPSec integrity checks.

Conclusion

Despite their shortcomings, despite the problems NATs create for numerous applications and their users, and despite a lack of standardization, NAT continues to be an important part of the future of the internet. The benefits still seem to outweigh the disadvantages and its widespread adoption in turn creates a major incentive for application developers to take NAT into account and cope with its inherent problems.

• Category: NAT