Brief Description of IPsec NAT Traversal by malj


									                              - Nortel Networks Confidential -

       A Backgrounder on Contivity’s IPsec NAT Traversal Implementation

Contivity will shortly be implementing a feature to address Contivity IPsec traffic
traversing through a NAT router or access device. This feature, officially called ―IPsec
ESP encapsulation in UDP for NAT traversal‖, is scheduled for mid-year 2001 release.
Both Contivity VPN switch and Contivity IPsec client software are being modified to
support this feature, which will become available in R4.0 switch and R4.1 client software
versions, respectively. This paper provides a backgrounder on the details of the Contivity
implementation—more commonly referred to as ―IPsec NAT Traversal‖.

Network Address Translation (NAT) is commonly found in subscriber access paths
between mobile remote users and the Internet. It serves the purpose of translating private
IP addresses to public IP addresses and may be implemented in CPE-based Internet
access devices or within the Internet ―cloud‖ (see Figure 1).


                            Subscriber                 RAS
                          Service Gateway

                                               IP              Subscriber
                     Frame                  Backbone         Service Gateway


         NAT                      DSL
               SME/SOHO                                                        GPRS

                                          Millions of new ‘always
                                          on’ IP enabled mobile
                      NAT                 devices

  Figure 1. NAT may be implemented in Internet access devices or in the “Cloud”

The problem is that NAT implementations are not always application transparent and can
restrict certain IP-based protocols from traversing the network. IPsec is one such
protocol. Many NAT devices do not pass IPsec traffic (i.e., are not ―IPsec aware‖) and
therefore prevent remote mobile Contivity IPsec clients from communicating to their
home Contivity VPN switch.

                                             Page 1                                    March 2001
                            - Nortel Networks Confidential -

Feature Description
IPsec NAT Traversal is a feature designed to allow Contivity IPsec traffic to pass through
a standard NAT device that is not IPsec aware. This feature has previously been widely
described as ―UDP Wrapper.‖ However for a number of reasons, this name will not be
officially used when this feature is introduced. Instead, the official name is ―IPsec ESP
encapsulation in UDP for NAT Traversal‖, which correctly describes that this protocol
works with Encapsulating Security Payload (ESP) traffic only and is encapsulated within
UDP. In short, Contivity will encapsulate the IPsec ESP packet within a UDP packet,
allowing the traffic to pass through any NAT device limited to transmitting TCP/UDP
traffic only.

Network Address Port Translation (NAPT, or N-to-1 NAT) implementations within NAT
devices commonly use TCP/UDP source port numbers to associate individual IP sessions
with their respective client(s). For example in Figure 2, all inbound traffic from the
Contivity switch to clients behind the NAT device is destined for IP address
The NAPT implementation (within the NAT device) must map the multiple IP sessions to
the clients behind the NAT device. Associating each client/session to an outbound
TCP/UDP source port is the way this is normally done.

This mechanism does not work with IPsec, however. This is because IPsec ESP
encapsulates and encrypts the actual protocol header, transmitting the IP traffic as a
different protocol type—IP protocol 50. With ESP traffic, there is no source port that can
be used to identify sessions. Contivity’s IPsec NAT traversal feature encapsulates IPsec
within UDP so that the NAPT device passes IPsec ESP traffic without problem. This, in
addition, has the side effect of permitting other non-TCP/UDP protocols, or other
complex protocols that cannot normally traverse NAT, to traverse through a NAT device.

NOTE 1: Workarounds to transmitting IPsec through NAPT exist in some NAT devices.
These are generically referred to as ―IPsec aware NAT‖ devices. But in many cases,
NAT products do not support this capability, or have not been upgraded to support it.
Contivity is thus providing the mechanism to communicate through such non-IPsec
aware devices. Furthermore, many IPsec aware NAT devices have significant limitations
(such as only one IPsec connection at a time) that make Contivity’s IPsec NAT Traversal
an improvement.

NOTE 2: IPsec NAT traversal only works with ESP-encapsulated IPsec traffic. It does
not support IPsec AH (Authentication Header) mode.

NOTE 3: More information on NAT and IPsec can be found on the Contivity SP&C
Web site at Even though this
presentation, ―NAT issues with IPsec‖, was created before details of Contivity’s IPsec
NAT Traversal feature were available, it provides a good general backgrounder on the

                                         Page 2                               March 2001
                            - Nortel Networks Confidential -

             Figure 2: Contivity IPsec Traversal through a NAT device

Contivity’s IPsec NAT Traversal feature—as its name implies—has not been designed as
a masquerade protocol to circumvent firewalls. Instead, it has been designed purely to
work with NAPT. Masquerade protocols are designed to hide a security protocol, such
as IPsec, within a well-known protocol such as HTTP. These solutions make it easier for
IPsec to pass through many common firewall products without additional ports being
opened on the firewall. Even though IPsec generally passes through firewalls without
problem—you merely need to open the appropriate ports on the firewall (UDP 500 and IP
protocol 50)—customers often desire to pass traffic through the firewall using an already
open port number, most commonly HTTP.

Contivity’s IPsec NAT Traversal was not designed as a masquerade protocol for a
number of reasons:

      Disguising one protocol within another is not considered good security practice.
       Therefore we use a well-known UDP port number for easy identification.
      Significant additional overhead is required to determine what is real HTTP traffic
       and what is IPsec HTTP
      As the default port for HTTP is TCP 80, there is additional overhead needed to
       maintain the TCP state machine
      The standards bodies for IPsec have not even considered masquerade mode

                                         Page 3                              March 2001
                            - Nortel Networks Confidential -

Implementation Details
Standard IPsec ESP traffic actually involves two separate session types: 1) IKE and 2)
ESP. IKE normally uses UDP port 500 for its sessions. ESP, on the other hand, does not
use a standard TCP/UDP header and is transmitted as IP protocol 50.

In general, IKE sessions will traverse any NAPT implementation without problem.
However, Contivity currently does not accept IKE traffic that uses a port other than UDP
port 500. With IPsec NAT Traversal, Contivity will accept and use a modified UDP port
number, in cases where the NAT device has modified it. For example in Figure 2, the
NAT device modifies the UDP port number for the IKE session from 500 to 60,001.
Contivity now accepts and uses UDP port number 60,001 for the IKE session when
sending through the NAT device, enabling the IKE session to traverse NAPT with no

When transmitting ESP traffic through a NAPT device, Contivity client and switch
devices will now encapsulate the ESP packet within UDP using a well-known port
number. For example in Figure 2, the Contivity client and/or switch will add a UDP
header with port number 10,001 to ESP packets. This has the effect of adding an
overhead of 8 bytes to the ESP packet—with a zero checksum that is not used. The NAT
device, in turn, modifies the UDP port number for the ESP session from 10,001 to
60,002. Contivity now accepts and uses UDP port 60,002 for the ESP session when
communicating through the NAT device.

Since there is no IETF standard for IPsec NAT Traversal at this time, the Contivity-
assigned UDP port number for the ESP session is user-configurable within the range of
ports 1024 to 49151. Nortel is working closely with Microsoft and Cisco within the IETF
to standardize IPsec NAT traversal. As of this writing (March 2001), an IPsec
informational standard has just reached draft status. Contivity intends to adhere to this
informational standard later in the year.

In actual implementation, the Contivity client and switch will detect when NAPT is being
used in a network and automatically switch to IPsec NAT Traversal mode. There are
three modes available which are configurable at the group level.

      Mode 1 : IPsec NAT Traversal disabled
      Mode 2 : IPsec NAT Traversal enabled – always on when NAPT detected
      Mode 3 : IPsec NAT Traversal enabled – auto-detect IPsec aware NAPT

When IPSec NAT Traversal is enabled (Mode 2 and Mode 3), the Contivity client and
switch can automatically determine that NAPT is being used on the network. They use a
hash of the source and destination IP address and UDP/TCP port, which if it does not
match, signifies that NAPT is being used. Whenever NAPT is detected in Mode 2, IPsec
NAT Traversal mode will be used. In Mode 3, Contivity makes a further check to
determine if the NAPT device is actually IPsec aware and therefore IPsec NAT Traversal
is not needed. This is done by simply waiting for 5 seconds to see if ESP traffic gets

                                         Page 4                              March 2001
                            - Nortel Networks Confidential -

through OK. Mode 2 has the disadvantage of adding extra overhead for each ESP packet,
even if that NAPT device is IPsec aware. Mode 3 has the disadvantage of introducing a 5
second delay while Contivity determines whether ESP data is getting through the NAPT
device, and therefore does need IPsec NAT Traversal.

A further issue with many NAPT devices is that they timeout sessions—sometimes in
minutes and sometimes in seconds—and change the outbound UDP source port in mid-
session. This is referred to as port floating. To avoid interruption of IPsec sessions in
mid-flow, Contivity implements a keep-alive. For IKE sessions, Contivity’s existing IKE
keep-alive interval has been set to one minute, which ensures that the port number does
not float during a re-key. (NOTE: It is OK for the port number to float outside of a re-
key). ESP sessions, however, cannot work with a floating UDP port. So, a new
configurable ESP keep-alive has been implemented with a default of 18 seconds. This
keep-alive is automatically increased to one minute if Contivity determines that the IKE
session is not seeing UDP port floating. The logic being that if the IKE session does not
see port floating within the one minute interval, then neither will the ESP session.

Summary of Contivity’s IPsec NAT Traversal
The key advantages of the Contivity implementation of IPsec NAT Traversal are:
    No client side configuration or user awareness of this is required.
    Server side configurable, and can be made available to specific groups only.
    Configuration options and implementation minimize transmission overhead.

In comparison, Cisco’s equivalent implementation of UDP wrapper lacks the following
features offered by Contivity:
     No detection of NAT device – requires a static configuration. Cisco must
        configure UDP wrapper as always on, adding UDP overhead for all IPsec ESP
        traffic even if it’s not required.
     No configurable keep-alive or keep-alive backoff mechanism. Cisco only
        supports a fixed 18 second keep-alive. They cannot back-off the keep-alive
        interval and are forced to send out a keep-alive every 18 seconds whether or not
        it’s needed this frequently.

                                         Page 5                               March 2001

To top