IP Security and NAT

One question asked frequently by those planning to implement virtual private networks concerns the ability to combine IP security (IPsec) and Network Address Translation (NAT). Many have heard rumors and war stories about incompatibilities between IPsec and NAT. Others have seen blanket denials issued by vendors who successfully combine IPsec and NAT within a single product. As is so often the case, reality lies somewhere between the two extremes: IPsec and NAT can be employed together in some configurations, but not in others. In today's column, we'll explore the issues and limitations associated with combining IPsec and NAT, and take a brief look at recent advances in this area.

Today, NAT is commonly supported by WAN access routers and firewalls — devices situated at the network edge. NAT starts by creating bindings between addresses. A one-to-one mapping may be defined between public and private IP addresses (static NAT). More often, a pool of public IP addresses is shared by an entire private IP subnet (dynamic NAT). Edge devices that run NAT use these bindings to translate addresses carried in IP packet headers and provide transparent packet forwarding between realms. The end systems remain unaware that NAT is taking place.

A variation 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 numbers as well as IP addresses.

For example, suppose private hosts 10.0.0.1 and 10.0.0.2 both send packets from source port 2000. A NAPT device might translate these to a single public IP address 207.29.194.28 but two different source ports, say 2998 and 2999. Response traffic received for port 2998 is routed to 10.0.0.1 while port 2999 traffic is routed to 10.0.0.2.

Where do ISPs and their customers use NAT?
Outbound (traditional) NAT is commonly employed by multi-host residential users, teleworkers, and small businesses that share a single public IP for outbound traffic while blocking inbound session requests. In other words, small subscriber LANs connected via ISDN, DSL, or cable modem. Bi-directional NAT is typically used by enterprise customers who host their own servers behind a masquerading firewall. Here, the NAT device maps selected destination ports to inside (private) IPs for inbound request routing. NAT can also be employed by enterprise customers wishing to insulate themselves from ISP address changes, or by those wanting to obscure private network topology for security reasons.

Our need to conserve IPv.4 addresses has prompted many to overlook NAT's inherent weaknesses. Protocols like FTP may carry IP addresses in application-level payload; in these cases, an application-level gateway is needed to complete the translation started by NAT. In other cases, translation simply cannot "fix" a packet modified by NAT.

Impact of NAT on IPsec
The IPsec Authentication Header (AH) is a case in point. AH runs the entire IP packet, including invariant header fields like source and destination 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. Ergo, AH + NAT cannot work.

The other IPsec protocol, the 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 IPsec 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/UDP packet, NAT must also recalculate the checksum used to verify integrity. If NAT updates the checksum, ESP authentication will fail. If NAT does not update the checksum, TCP/UDP verification will fail. If the transport endpoint were under your control, you might be able to turn off checksums. Bottom line: ESP can pass through NAT in tunnel mode, or in transport mode with checksums disabled or ignored by the receiver.

If we stick to ESP in tunnel mode or turn off checksums, there's still one obstacle: the Internet Key Exchange (IKE). IPsec-based VPNs use IKE to automate security association setup and authenticate endpoints. The most basic and common method of authentication in use today is pre-shared key. Unfortunately, this method depends upon the packet's source IP address. If NAT is inserted between endpoints, the source IP address will be that of the NAT device, not the originating security gateway. To avoid this problem, use another IKE authentication method (e.g., public key signature or X.509 digital certificate) or look for a VPN product that doesn't use source IP address for IKE "main mode" identification.

A further problem may occur after a security association has been up for a while. When the association expires, one security gateway will send a rekey request to the well-known IKE port 500 at the other security gateway. If more than one security gateway lies behind a NAPT device, 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 every gateway uses a different port number, allowing requests to be demultiplexed by a NAPT device.

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. See RFC 2709 for a security model that covers 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 IPsec before NAT. This can be accomplished in two ways:

1. Perform NAT on a device located behind your IPsec security gateway
2. Use an IPsec device that also performs NAT

Many devices that implement IPsec also support 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.

A small sampling of the VPN platforms that support both IPsec and NAT include:

1. Routers from Cisco and Enterasys
   
2. Firewalls from WatchGuard and AXENT
   
3. Special-purpose security gateways from Radguard
   
4. Internet appliances from vendors like FreeGate and
   
5. Software solutions like FreeS/WAN combined with Linux VPN Masquerade.

While these products avoid the problem by combining IPsec and NAT in a single box, others prefer to tackle NAT-in-the-middle head-on. For example, NexLand recently announced ISB2LAN, a low-end NAT appliance that employs patent-pending "multi-session pass-thru technology". According to NexLand, ISB2LAN can be inserted transparently in the middle of an ESP tunnel. It supports one public address with up to 2.5 Mbps aggregate throughput. It will be interesting to see if this solution can scale up to a large number of tunnels with frequent, granular IKE exchanges. It is also important to understand the security implications of allowing NAT-in-the-middle: as RFC 2709 succinctly puts it, "If NATs and ALGs are not in a trusted boundary, that is a major security problem."

NAT in a nutshell
NAT is most often used to convert RFC 1918 private addresses into routable public addresses. With static NAT, each private address maps to one public address. With NAPT, both IP address and port are mapped, allowing many privately addressed hosts to share one public address. IP address and port fields are not the only values modified by NAT and NAPT. Checksums must be recomputed and embedded IP addresses carried in application protocols like FTP may also be translated.

There is no problem when NAT is applied before IPsec. However, when this order is reversed—watch out:

• The IPsec Authentication Header (AH) protects entire IP packets, including IP headers, against modification in transit. NAT and NAPT modify the IP header, so are inherently incompatible with AH.
• The IPsec Encapsulating Security Payload (ESP) usually encrypts IP packets. NAPT modifies TCP and UDP ports, but clearly can't do so when these fields are obscured by encryption. NAPT is therefore incompatible with ESP.
• ESP in tunnel mode can sometimes get through static NAT. Even in this case, Internet Key Exchange (IKE) authentication still presents several problems.

NAT traversal
NAT was originally developed as a short-term measure to combat IPv4 address exhaustion. However, widespread implementation and lengthy migration to IPv6 have made it impossible for IPsec vendors to ignore NAT. Cisco, CheckPoint, F-Secure, Microsoft, and SSH Communications are among those vendors working to enable IPsec NAT traversal.

Two competing approaches have been proposed to the IETF—one developed by SSH Communications and another co-authored by F-Secure, Microsoft, Cisco, and Nortel. While these Internet Drafts differ in detail, they share much in common. At the March 2001 IETF meeting, authors agreed to merge these proposals into a hybrid approach that is expected to advance rapidly through the standards process.

UDP encapsulation
At the heart of this promising solution lies UDP encapsulation. Wrapping an IPsec packet inside a UDP/IP header lets NAT and NAPT do their thing, without modifying—that is to say breaking, the encapsulated IPsec packet (below).

The abbreviated format shown here works only for IPsec ESP. SSH Communications proposed an extended format that also accommodates IPsec AH. Because AH is used infrequently, the market demand for AH NAT traversal is debatable. In this column, we'll focus on ESP.

In-side-out, out-side-in
Of course, encapsulation requires decapsulation. ESP-protected packets are exchanged between IKE peers: gateway-to-gateway, client-to-gateway, and client-to-client. Peers must support the same method of UDP ESP encapsulation. Today, this is sometimes possible between same-vendor devices. A common standard will enable multi-vendor interoperability.

To promote compatibility with existing implementations, IKE peers will exchange a known value to determine whether they both support NAT traversal (UDP ESP encapsulation). If the peers agree, they will use IKE probes or discovery payloads to determine whether NAT or NAPT is being applied at some point between them. Only when IKE peers agree and NAT or NATP is encountered will UDP ESP encapsulation be used.

Overloading UDP port 500
Since IKE peers already communicate over UDP port 500, these drafts propose sending UDP encapsulated ESP on this same port. Doing so avoids poking new holes in firewall rules and packet filters. It also ensures that IKE and UDP encapsulated ESP packets are subjected to the same mid-stream address translation.

In the proposal, the sender indicates that an encapsulated packet follows by setting the first 8 bytes of the UDP payload to zero. These bytes overlap the IKE Initiator Cookie field, for which zero is an invalid value. Thus, implementations can use these bytes to discriminate between IKE and UDP-encapsulated ESP arriving on port 500. Because only peers that agree will ever send UDP-encapsulated ESP packets, backward compatibility is not an issue (below).

Keep it flowing
Static NAT is just that—unchanged. However, NAPT mappings are dynamic. Typically, a private IP address and source port (192.168.0.1:X) are temporarily bound to a shared public IP address and an unused port (207.126.101.100:Y). A timeout dissolves this binding after seconds or minutes of inactivity, enabling NAPT pool reuse.

IPsec VPNs protect traffic exchanged between mutually authenticated endpoints. For NAT traversal to work, endpoints cannot be dynamically re-mapped mid-session. To preserve dynamic NAPT bindings for the life of an IPsec session, a one-byte UDP "keepalive" may be used. This "keepalive" also maintains stateful firewall return paths.

Almost a proven solution
This solution will of course be refined, but it's been proven through implementation to overcome many IPsec vs. NAT/NAPT hurdles. This is very good news indeed for the ISP community. NAT and NAPT are simply everywhere. The ability to overlay IPsec VPNs without NAT/NAPT interference will simplify deployment planning and reduce support calls.

While the IETF is dotting the I's and crossing the T's on this NAT traversal (or ESP-in-UDP) standard, it's important to realize that a few problems will still remain:

• Overlapping private addresses are still possible and must be dealt with during network planning and security policy definition. Watch out for environments where several customer locations use the same privately addressed subnets.
• A NAT or NAPT device encountered mid-path still cannot modify encrypted application payload (for example, embedded IPs in FTP, IRC, SNMP, LDAP, and H.323). Try to determine whether this presents a problem for your customers during VPN design.
• It's very possible that, in the interest of simplicity and efficiency for ESP NAT traversal, AH NAT traversal will not be supported. If your customer insists on using AH, find out why and nudge them politely towards ESP.

With luck, by this time next year, ESP NAT traversal will be commonplace in IPsec/IKE products. We recommend that ISPs keep a watchful eye on this emerging standard and encourage suppliers to support it.