NAT and NAPT are techniques used to share and hide private IP addresses on edge devices like routers and firewalls. Unfortunately, when an IPsec session runs through NAT or NAPT, security is often compromised.

by Lisa Phifer VP Core Competence, Inc. [April 19, 2001]

In past columns, we have discussed the challenge of safely combining IPsec with Network Address Translation. In today's column, we'll look at a promising new solution to this perennial problem—NAT traversal.

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. (To learn more, read last year's column IP Security and NAT: Oil and Water?)

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.

—End 

Phifer will be instructing a course about VPN deployment issues at The Internet Security Conference (TSDC) held at the Century Plaza Hotel in Los Angeles, California on June 4-8, 2001.

Related articles:
[June 23, 2000]	Realm-Specific IP for VPNs and Beyond
[June 15, 2000]	IP Security and NAT: Oil and Water?
[May 24, 2000]	VPN Product Briefs: May 2000