|The Trouble with NAT
by Lisa Phifer, Core Competence
Those who are implementing virtual private networks often ask whether it is possible to safely combine IP Security (IPSec) and Network Address Translation (NAT). Unfortunately, this is not a question with a simple "yes" or "no" answer. IPSec and NAT can be employed together in some configurations, but not in others. This article explores the issues and limitations associated with combing NAT and "NAT-sensitive" protocols like IPSec. It examines configurations that do not work, and explains why. It illustrates methods for using NAT and IPSec together, and discusses an emerging protocol that may someday prove more IPSec friendly.
This article builds upon "IP Security and NAT: Oil and Water?"  and "Realm-Specific IP for VPNs and Beyond"  , works previously published by ISP-Planet.
What Is Network Address Translation?
NAT was originally developed as an interim solution to combat IPv4 address depletion by allowing globally registered IP addresses to be re-used or shared by several hosts. The "classic" NAT defined by RFC 1631  maps IP addresses from one realm to another. Although it can be used to translate between any two address realms, NAT is most often used to map IPs from the nonroutable private address spaces defined by RFC 1918  , shown below.
These addresses were allocated for use by private networks that either do not require external access or require limited access to outside services. Enterprises can freely use these addresses to avoid obtaining registered public addresses. But, because private addresses can be used by many, individually within their own realm, they are nonroutable over a common infrastructure. When communication between a privately addressed host and a public network (like the Internet) is needed, address translation is required. This is where NAT comes in.
NAT routers (or NATificators) sit on the border between private and public networks, converting private addresses in each IP packet into legally registered public ones. They also provide transparent packet forwarding between addressing realms. The packet sender and receiver (should) remain unaware that NAT is taking place. Today, NAT is commonly supported by WAN access routers and firewalls--devices situated at the network edge.
NAT works by creating bindings between addresses. In the simplest case, a one-to-one mapping may be defined between public and private addresses. Known as static NAT, this can be accomplished by a straight-forward, stateless implementation that transforms only the network part of the address, leaving the host part intact. The payload of the packet must also be considered during the translation process. The IP checksum must, of course, be recalculated. Because TCP checksums are computed from a pseudo-header containing source and destination IP address (prepended to the TCP payload), NAT must also regenerate the TCP checksum.
More often, a pool of public IP addresses is shared by an entire private IP subnet (dynamic NAT). Edge devices that run dynamic NAT create bindings "on the fly," building a NAT Table. Connections initiated by private hosts are assigned a public address from a pool. As long as the private host has an outgoing connection, it can be reached by incoming packets sent to this public address. After the connection is terminated (or a timeout is reached), the binding expires, and the address is returned to the pool for reuse. Dynamic NAT is more complex because state must be maintained, and connections must be rejected when the pool is exhausted. But, unlike static NAT, dynamic NAT enables address reuse, reducing the demand for legally registered public addresses.
A variation of dynamic NAT known as Network Address Port Translation (NAPT) may be used to allow many hosts to share a single IP address by multiplexing streams differentiated by TCP/UDP port num- ber. For example, suppose private hosts 192.168.0.2 and 192.168.0.3 both send packets from source port 1108. A NAPT router might trans- late these to a single public IP address 22.214.171.124 and two different source ports, say 61001 and 61002. Response traffic received for port 61001 is routed back to 192.168.0.2:1108, while port 61002 traffic is routed back to 192.168.0.3:1108.
NAPT (masquerading) is commonly implemented on small Office/ Home Office (SOHO) routers to enable shared Internet access for an entire LAN through a single public address. Because NAPT maps individual ports, it is not possible to "reverse map" incoming connections for other ports unless another table is configured. A virtual server table can make a server on a privately addressed DMZ reachable from the Internet via the public address of the NAPT router (one server per port). This is really a limited form of static NAT, applied to incoming requests.
In some cases, static NAT, dynamic NAT, NAPT, and even bidirectional NAT or NAPT may be used together. For example, an enterprise may locate public Web servers outside of the firewall, on a DMZ, while placing a mail server and clients on the private inside network, behind a NAT-ing firewall. Furthermore, suppose there are applications within the private network that periodically connect to the Internet for long periods of time. In this case:
Where is NAT used today? Outbound NAT is commonly employed by multihost residential users, teleworkers, and small businesses that share a single public IP for outbound traffic while blocking inbound session requests. In other words, small LANs connected via ISDN, Digital Subscriber Line (DSL), or cable modem.
Bidirectional static NAT/NAPT combinations are typically used by en-terprises that host services behind a masquerading firewall. NAT can also be employed by enterprises wishing to insulate themselves from Internet Service Provider (ISP) address changes, or by those wanting to obscure private network topology for security reasons.
Our need to conserve IPv4 addresses has prompted many to overlook the inherent limitations of NAT, recognized in RFC 1631 but deemed acceptable for a short-term solution.
As noted previously, NAT regenerates TCP checksums. This, of course, requires the TCP header containing the checksum to be visible (that is, not encrypted). If only the TCP payload is encrypted and immutable between the application source and destination (for instance, Secure Shell Protocol [SSH], Secure Sockets Layer [SSL]), then the checksum in the TCP header can be recalculated without a visible TCP payload. But if the TCP header is encrypted (for instance, IPSec transport mode), the TCP checksum field in the TCP header cannot be modified.
Furthermore, many application protocols carry IP addresses in an application-level protocol . In such cases, an Application-Level Gateway (ALG) is needed to complete the translation. For example:
NAT-sensitive protocols such as Kerberos, X-Windows, remote shell, Session Initiation Protocol (SIP), and others are further described in the Internet Draft "Protocol Complications with the IP Network Address Translation"  . Another Internet Draft, "NAT Friendly Application Design Guidelines "  , explains how new application protocols can integrate smoothly with NAT. But there are still cases where ALGs simply cannot "fix" packets modified by NAT.
Impact of NAT on IPSec
The IPSec Authentication Header (AH)  is an example. AH runs the entire IP packet, including invariant header fields such as source and destination IP address, through a message digest algorithm to produce a keyed hash. This hash is used by the recipient to authenticate the packet. If any field in the original IP packet is modified, authentication will fail and the recipient will discard the packet. AH is intended to prevent unauthorized modification, source spoofing, and man-in-the-middle attacks. But NAT, by definition, modifies IP packets. Therefore, AH + NAT simply cannot work.
The IPSec Encapsulating Security Payload (ESP)  also employs a message digest algorithm for packet authentication. But, unlike AH, the hash created by ESP does not include the outer packet header fields. This solves one problem, but leaves others.
IPSec supports two "modes." Transport mode provides end-to-end security between hosts, while tunnel mode protects encapsulated IP packets between security gateways--for example, between two firewalls or between a roaming host and a remote access server. When TCP or UDP are involved--as they are in transport mode ESP--there is a catch-22. Because NAT modifies the TCP packet, NAT must also recalculate the checksum used to verify integrity. If NAT updates the TCP checksum, ESP authentication will fail. If NAT does not update the checksum (for example, payload encrypted), TCP verification will fail.
If the transport endpoint is under your control, you might be able to turn off checksum verification. In other words, ESP can pass through NAT in tunnel mode, or in transport mode with TCP checksums dis- abled or ignored by the receiver.Figure 5: NAT vs. ESP
If we stick to ESP in tunnel mode or turn off checksums, there's still another obstacle: the Internet Key Exchange (IKE)  . IPSec-based Virtual Private Networks (VPNs) use IKE to automate security association setup and authenticate endpoints. The most basic and common method of authentication in use today is preshared key. Unfortunately, this method depends upon the source IP address of the packet. If NAT is inserted between endpoints, the outer source IP address will be translated into the address of the NAT router, and no longer identify the originating security gateway. To avoid this problem, it is possible to use another IKE "main mode" and "quick mode" identifier (for example, user ID or fully qualified domain name).
A further problem may occur after a Security Association (SA) has been up for awhile. When the SA expires, one security gateway will send a rekey request to the other. If the SA was initiated from the well-known IKE port UDP/500, that port is used as the destination for the rekey request. If more than one security gateway lies behind a NAPT router, how can the incoming rekey be directed to the right private IP address? Rekeys can be made to work by "floating" the IKE port so that each gateway is addressable through a unique port number, allowing incoming requests to be demultiplexed by the NAPT router.
At this point, two things should be clear: (1) it is possible to find a "flavor" of IPSec that will run through NAT, but (2) one must do so with great care and attention to detail. Recent Internet Drafts   have recorded these problems for further consideration, and RFC 2709  describes a security model for running tunnel-mode IPSec through NAT.
One Solution: Avoid the Problem
By far the easiest way to combine IPSec and NAT is to completely avoid these problems by locating IPSec endpoints in public address space. That is, NAT before IPSec; don't perform IPSec before NAT. This can be accomplished in two ways:
Many routers, firewalls, security gateways, and Internet appliances implement IPSec and NAT in the same box. These products perform outbound address translation before applying security policies; the order is reversed for inbound packets. A typical "any-to-any" security policy is easily specified with such a product. Granular policies can be a bit more difficult because filters are often based on IP address, and care must be taken to avoid overlapping filters.
If you cannot avoid translating IPSec-protected traffic midstream, limit use of IPSec to tunnel-mode ESP and design security policies with care. If you simply cannot NAT before IPSec or require transport-mode ESP, there may still be hope. The Internet Engineering Task Force (IETF) is now defining Realm-Specific IP (RSIP), an alternative that may someday prove kinder to IPSec.
What Is RSIP?
RSIP  leases public IP addresses and ports to RSIP hosts located in private addressing realms. Unlike NAT, RSIP does not operate in stealth mode and does not translate addresses on the fly. Instead, RSIP allows hosts to directly participate concurrently in several addressing realms. Although RSIP does require host awareness, it avoids violating the end- to-end nature of the Internet. With RSIP, IP payload flows from source to destination without modifications that cripple IPSec AH and many other NAT-sensitive protocols.
RSIP gateways are multihomed devices that straddle two or more addressing realms, just as NAT-capable firewalls and routers do today. When an RSIP-savvy host wants to communicate beyond its own private network, it registers with an RSIP gateway. The RSIP gateway allocates a unique public IP address (or a shared public IP address and a unique set of TCP/UDP ports) and binds the private address of the RSIP host to this public address. The RSIP host uses this public source address to send packets to public destinations until its lease expires or is renewed.
But the RSIP host cannot send a publicly addressed packet as-is; it must first get the packet to the RSIP gateway. To do this, the host wraps the original packet inside a privately addressed outer packet. This "encapsulation" can be accomplished using any standard tunneling protocol: IP-in-IP, the Generic Routing Encapsulation (GRE), or the Layer 2 Tunneling Protocol (L2TP). Upon receipt, the RSIP gateway strips off the outer packet and forwards the original packet across the public network, toward its final destination.
For simplicity, we talk about RSIP linking one private network to the public Internet, but RSIP can also be used to relay traffic between several privately addressed networks. An RSIP host can lease several different addresses as needed to reach different destinations networks. We've also focused on outgoing traffic, but an RSIP host can ask the RSIP gateway to "listen" and relay incoming packets addressed to a public IP and port.
Combining RSIP and IPSec
At first glance, RSIP sounds like a promising way for hosts to share public addresses while avoiding the pitfalls associated with applying NAT to IPSec traffic. But it turns out that RSIP extensions are needed to accommodate end-to-end IPSec  .
Basic RSIP relies on unique port numbers to demultiplex arriving packets, but IPSec ESP encrypts port numbers. When several RSIP hosts use the same RSIP gateway to relay ESP, another discriminator is needed. Fortunately, every IPSec packet carries a unique Security Parameters Index (SPI), assigned during security association setup. Unfortunately, the SPI is guaranteed unique only for the responder. To enable demultiplexing, the tuple (SPI, protocol [AH or ESP], destination IP address) must also be unique at the initiating RSIP gateway.
A similar problem occurs during association setup with the IKE. IKE packets usually carry the well-known source port UDP/500. Using dif-ferent source ports is the preferred solution, but if several RSIP hosts use the same RSIP gateway to relay IKE from port UDP/500, another dis-criminator is needed. Again, there is a convenient answer: every IKE packet carries the initiator cookie supplied in the first packet of an IKE session. The RSIP gateway can route IKE responses to the correct RSIP host using the tuple (initiator cookie, destination port [IKE], destination IP address). But rekeys may still be an issue.
To fix these problems, extensions have been proposed to allow RSIP hosts to register with an RSIP gateway for IPSec support, and allow hosts to request and receive unique SPI values along with leased IP addresses and ports.
Possible Applications for RSIP
RSIP specifications  are still at the Internet Draft stage. If and when RSIP matures, there may be a wide variety of applications:
These scenarios, and the relationship of RSIP to IP multicast and differentiated services, are more fully explored in the RSIP framework  .
Although NAT can be combined with IPSec and other NAT-sensitive protocols in certain scenarios, NAT tampers with end-to-end message integrity. RSIP--or whatever RSIP evolves into--may someday prove to be a better address-sharing solution for protocols that are adversely impacted by NAT. If RSIP fails to mature, another solution may be developed to broaden use of NAT with IPSec. Alternatives now under discussion within the IETF include UDP encapsulation and changes to IKE itself  .
Despite its origin as a short-term solution, NAT is unlikely to disappear in the very near future. Until it does, understanding the relationship between NAT and IPSec and alternatives for safe combined deployment will remain an important aspect of VPN design.
 Phifer, L., "IP Security and NAT: Oil and Water?" ISP-Planet, June 15, 2000.
 Phifer, L., "Realm-Specific IP for VPNs and Beyond," ISP-Planet, June 23, 2000.
 Egevang, K. and Francis, P., "The IP Network Address Translator (NAT)," RFC 1631, May 1994.
 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J., and Lear, E., "Address Allocation for Private Internets," RFC 1918, February 1996.
 Kent, S. and Atkinson, R., "IP Authentication Header," RFC 2402, November 1998.
 Kent, S. and Atkinson, R., "IP Encapsulating Security Payload (ESP)," RFC 2406, November 1998.
 Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)," RFC 2409, November 1998.
 Srisuresh, P. and Holdrege, M., "IP Network Address Translator (NAT) Terminology and Considerations," RFC 2663, August 1999.
 Srisuresh, P., Tsirtsis, G., Akkiraju, P. and Heffernan, A., "DNS Extensions to Network Address Translators (DNS_ALG)," RFC 2694, September 1999.
 Srisuresh, P., "Security Model with Tunnel-Mode IPSec for NAT Domains," RFC 2709, October 1999.
 Tsirtsis, G. and Srisuresh, P., "Network Address Translation-Protocol Translation (NAT-PT)," RFC 2766, February 2000.
 Srisuresh, P. and Holdrege, M., "Protocol Complications with the IP Network Address Translator," Internet Draft, Work in Progress, July 2000.
 Senie, D., "NAT Friendly Application Design Guidelines," Internet Draft, Work in Progress, July 2000.
 Aboba, B., "NAT and IPSec," Internet Draft, Work in Progress, July 2000.
 Stenberg, M., Paavolainan, S., Ylonen, T., and Kivinen, T., "IPSec NAT-Traversal," Internet Draft, Work in Progress, July 2000.
 Borella, M. and Lo, J., "Realm-Specific IP: Protocol Specification," Internet Draft, Work in Progress, March 2000.
 Montenegro, G. and Borella, M., "RSIP Support for End-to-End IPSec," Internet Draft, Work in Progress, March 2000.
 Borella, M., Lo, J., Grabelsky, D., and Montenegro, G., "Realm-Specific IP: Framework," Internet Draft, Work in Progress, March 2000.
LISA PHIFER is vice president of Core Competence, Inc. (www.corecom.com ), a consulting firm specializing in Internet, network management, and security technologies. She earned her Master's Degree in Computer Science from Villanova University. A Bellcore award recipient for her work in ATM network operations, Lisa has been in-volved in the design and deployment of networking protocols for over 18 years. She represented Bellcore and Unisys in several industry-standards organizations, and has par-ticipated in The Internet Security Conference (TISC) since its inception. Lisa consults, teaches, and writes about a variety of technologies, including caching, load balancing, DSL, ISDN, IPSec, PKI, OSS, and VPNs. Her monthly column on virtual private net-working is published by ISP-Planet. E-mail: firstname.lastname@example.org