Welcome to Volume 3, Issue 22 of The Internet Security Conference newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me.
Enjoy, and be safe,
Dave
Editor's Corner
You've booked into a hotel that has broadband access. You've got a ton of work to complete before tomorrow's meeting. You must get to your company Intranet to access information your workmates have completed while you were traveling. You fire up your IPsec client and attempt to connect through your corporate security gateway.
Nothing. Nada. Zilch. What's up with this?
There's a good chance that NAT is standing between you and your security gateway. Maybe it's PAT. Who are these guys and why are they interfering with your business? NAT and PAT are Network and Port Address Translation, respectively. They don't always play nicely with IPsec. They are the bane of secure remote access and the root of a considerable portion of VPN help desk calls.
Fortunately, help is on the horizon. Today, Lisa Phifer explains when and how NAT and PAT break IKE and IPsec, and discusses a standards initiative designed to remove some of the barriers NAT and PAT place between roaming users and IPsec security gateways.
Enjoy.
Lisa Phifer, Core Competence
Network Address Translation (NAT) is a method of mapping private IP addresses to public ones. Developed to conserve IPv4 addresses, NAT is widely used today for Internet connection sharing and to obscure the "real" addresses of hosts and servers located behind a firewall.
IP Security (IPsec) and the Internet Key Exchange (IKE) support virtual private networks (VPNs) based on IP. The IPsec Authentication Header (AH) and Encapsulating Security Payload (ESP) use symmetric key crypto to provide confidentiality and data integrity in site-to-site and remote access VPNs.
Applying NAT before IPsec - for example, having your firewall or IPsec security gateway perform both functions on outbound packets - is not a problem. Unfortunately, as many frustrated travelers have discovered, applying NAT after IPsec can lead to heartache.
NAT works by substituting public IP addresses for private IP addresses whenever IP packets are forwarded across the public Internet, changing the content each packet. But IPsec AH uses a Hashed Message Authentication Code (HMAC) to detect and prevent any change to IP packets. Thus, if an IP packet is protected by AH before it passes through a NAT device (a firewall or router configured to translate IP addresses), the HMAC integrity check on the modified packet will fail and the receiver will discard the modified packet. So forget about pushing AH through NAT.
When IPsec ESP is used in tunnel mode, private IP packets are encapsulated inside public IP wrappers. When the inner packet is encrypted, it cannot be modified by a NAT device encountered mid-tunnel (between the ESP endpoints). However, the outer packet IP header is cleartext so that intermediate gateways can forward the packet; it can be modified without affecting ESP's HMAC on the inner packet. This means that ESP tunnel mode packets can safely pass through this simple NAT.
However, most firewalls and routers use Port Address Translation (PAT) to multiplex entire private subnets onto a single public IP address. PAT further modifies the IP payload by also changing the TCP or UDP port number, keeping a map to direct return traffic to the correct host on the private subnet. This can't be done when the inner packet is encrypted by ESP because the port number is hidden.
Mid-tunnel NAT/PAT is common in remote access scenarios. Teleworkers with DSL or cable modems frequently find NAT/PAT in their path when service providers use private addresses on local loops and cable passings. Similarly, travelers using a hotel or conference LAN often encounter NAT/PAT somewhere upstream. Visitors on a corporate LAN usually bump into NAT/PAT on their way to the Internet. The bottom line: If you're planning to deploy IPsec remote access, you'll probably need to find a way through NAT/PAT.
To initiate an IPsec tunnel, a VPN client sends a cleartext IKE message over UDP (by default, on port 500). When it hits NAT/PAT on an intervening firewall or router, the packet is translated so that it appears to originate from the firewall/router's public IP.
If the VPN client uses its IP as its IKE ID, authentication fails immediately. Fortunately, most VPN clients use another kind of ID, like email address. But they don't get much further. The far-end VPN gateway finds a matching policy and responds with more IKE.
If the firewall/router is running an IKE daemon, it may mistakenly try to process the IKE response instead of relaying it to the VPN client. The VPN client and far-end gateway retry and timeout while the intervening firewall/router mutters to itself, "Why does he keep sending me IKE for non-existent security associations?"
If the firewall/router does translate the IKE response back to the initiating VPN client, subsequent IKE messages can still be a problem. The far-end VPN gateway may send IKE messages to disconnect or reopen the IPsec tunnel when the existing tunnel expires. The firewall/router is likely to drop these unsolicited IKE packets. Or it may implement 1-to-1 reverse NAT, letting just one client "listen" for inbound traffic to UDP port 500.
Widespread address translation make it impossible for VPN vendors to ignore these problems and still hope for ubiquitous IPsec remote access. Cisco, F-Secure, Microsoft, and SSH Communications are among those working on new IETF standards for NAT Traversal. Early implementations are available in products today. Interoperability testing was conducted this summer.
AH traversal through NAT was dropped in the last draft - it did not quite work and working group polls found nobody with a burning requirement for AH. However, pushing ESP through NAT/PAT may soon be much easier.
At the heart of NAT Traversal lies UDP encapsulation. Wrapping an ESP-protected packet inside a UDP packet permits address translation without modifying (and breaking) the encapsulated payload [Figure 1].
Encapsulated ESP is sent on the same UDP port used by IKE (usually port 500). This ensures that the same firewall rules, packet filters, and address translators are encountered by IKE and UDP-encapsulated ESP packets.
The sender indicates encapsulated ESP by sending a zero "Non-IKE Marker" as the first octet of the UDP payload. This is the IKE Initiator Cookie field, for which zero is invalid. Peers can therefore discriminate between IKE and UDP-encapsulated ESP arriving on port 500 [Figure 2].
PAT mappings are dynamic. The private source address and port (for example, 192.168.0.100:500) carried by IKE or UDP-encapsulated ESP are temporarily bound to a shared public IP address and an unused port (for example, 207.126.101.1:1045). A timeout dissolves this binding after seconds or minutes of inactivity, enabling reuse. For NAT Traversal to succeed, dynamic mappings must kept alive for the life of each security association. By default, a one-byte UDP "keepalive" is generated every 20 seconds after the SA has been up for at least 5 minutes.
Compatibility with existing IKE Main, Aggressive, and Quick Mode implementations is essential. IKE peers express support for NAT Traversal by including a Vendor string in the first two messages of IKE Phase 1. If either peer does not support NAT Traversal, "normal" IKE ensues without further ado.
If both peers support NAT Traversal, NAT Discovery payloads are included in the next pair of IKE messages. The recipient hashes the IP addresses and ports in the received packet header, then compares them to hashes carried in the payload to determine whether translation occurred in between.
Encapsulation mode is negotiated during IKE Phase 2. To avoid needless overhead, peers should propose UDP-Encapsulated Tunnel or Transport mode only when translation has been detected.
If UDP-Encapsulated Transport mode is negotiated, peers may exchange NAT-Original-Address payloads during IKE Phase 2 so that each host knows the "real" IP address of the other.
Original addresses can be used to recompute TCP/UDP checksums that would otherwise fail because midstream NAT/PAT could not see or adjust encrypted checksums. Some implementations may simply turn off checksum verification at the receiver.
Midstream NAT/PAT also cannot modify encrypted application payload - for example, embedded IPs in FTP, SNMP, LDAP, or H.323 packets. Some NAT Traversal implementations may use the original addresses to update IPs embedded in application payload.
With NAT Traversal, NAT/PAT devices can remain completely unaware of IKE and IPsec. This is critical in most cases. However, proprietary "IPsec pass-throughs" have already been added to some NAT/PAT devices. These IPsec-aware translators may parse IKE, using cookies to maintain VPN client pseudo-sessions and PAT mappings. Testing is now underway to determine how NAT Traversal might impact these pass-throughs.
NAT and PAT are everywhere. IPv6 may relieve the address crunch, but address translation will be with us for years to come. Standards that allow IKE and IPsec to play nicely when pushed through NAT/PAT are therefore essential. When standard NAT Traversal is widely deployed, it will greatly simplify remote access VPN deployment.
© 2001 - 2006 Core Competence & Mactivity, Inc.
![[Figure 1]](../images/v322-fig1.gif){kind=link}
![[Figure 2]](../images/v322-fig2.gif){kind=link}