[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01

  INTERNET-DRAFT                                             A. Huttunen, J. Sierwald
  Expires September 2001                                         F-Secure Corporation
  Category: Informational                                        W. Dixon, B. Swander
                                                                             V. Volpe
                                                                        Cisco Systems
                                                                           L. DiBurro
                                                                      Nortel Networks
                                                                           March 2001

                    IPsec ESP Encapsulation in UDP for NAT Traversal

  Status of this Memo

     This document is an Internet-Draft and is in full conformance with all provisions
     of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering Task Force
     (IETF), its areas, and its working groups. Note that other groups may also
     distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six months and may be
     updated, replaced, or obsoleted by other documents at any time. It is
     inappropriate to use Internet- Drafts as reference material or to cite them other
     than as "work in progress."

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

     This Internet-Draft will expire September 2001

  1. Abstract

     NAT is widely used for Internet "connection sharing" and ships as a standard
     feature in every router and edge device.  Cable and DSL deployments have been
     known to install NAT in embedded devices resident inside the home.  Additionally
     most hotel Internet connections are using NAT.  Many airport & wireless services
     in public areas use NAT to connect to the Internet.  Some Internet Service
     Providers use a centralized NAT to connect their clients to the Internet.

     Without a solution to the problem, the L2TP/IPSec VPN client and an IPSec tunnel
     mode VPN client can not connect from home or from business sites which use NAT to
     connect to the Internet.  Likewise, transport TCP and UPD traffic that is
     protected by IPSec transport mode can not be exchanged between peer to peer or
     server-to-server applications.

     Without an IETF standard solution for IPSec over NAT, vendor products will not
     interoperate, and will be forced to support multiple methods.

     This proposal allows ESP to pass through NAT if the NAT allows UDP traffic.  It
     does not require the NAT to be aware of IPSec and IKE negotiation.  The technique
     is used only if the initiator and the responder support it.  And it is only used
     when necessary, because the initiator imbeds information that tells the responder
     how the packet addressing was formatted when it was originally sent.

     This technique allows L2TP protected by IPSec transport mode using the most
     popular and default encryption format (IPSec ESP) to go through existing NATs
     which do either port and address translation of UDP packets or pure-address

     It also allows IPSec tunnel mode to go through the same type of NATs, a
     requirement for many in the industry which implement IKECFG, XAUTH extensions to
     IPSec tunnel mode for remote access. Address assignment can also use the standards
     track DHCP over IPSec method.

     Note however that when IPSec tunneling through a NAT between an end system
     (static internal & external IP) and a gateway, or between two gateways - the
     internal addresses used by packets inside the IPSec tunnel can not be changed,
     even though the external address is changed so the internal packet will retain a
     potentially invalid address on the destination network. To handle this case, we
     can do one of the following:

     - In the gateway-to-gateway case, perform a second NAT function either before the
       tunnel ingress or after the tunnel egress to handle address space transitions.
         -In the case where traffic inside the tunnel is clear text TCP & UDP
            traffic, this is normal NAT and not affected by the IPSec tunnel (through
            which that traffic passed) being NATed itself.
         -In the case where traffic inside the IPSec tunnel is IPSec transport
            traffic, this spec provides the mechanism for the IPSec transport peers to
            detect this second NAT and pass it accordingly.
     - Not use the RFC method of negotiating an IPSec tunnel, instead use address
       assignment inside IKE (with or without IKECFG/XAUTH) for end-system to gateway
       IPSec tunnels.
     - Keep the internal address as is, and configure the destination network to be
       able to handle it.

     This method should be able to be used in all scales where NAT is deployed today to
     do simple pure address-to-address, or address and port translation.  However, it
     will not be able to be used where the NAT would otherwise perform packet
     inspection and replacement of address or port information inside the packet (e.g.
     modifying the FTP PORT command packet).  Thus UDP encapsulated IPSec transport and
     tunnel traffic will be successful if the communications model is that the client
     initiates TCP connections & UDP sessions from itself out through the NAT.

     This protocol does not involve the client communicating directly with the NAT for
     the purpose of opening ports to receive inbound connections.  If required, another
     method such as RSIP may be used by the application first to communicate with the

     IKE & IPSec issues with NAT are documented in this draft
     (http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt ) [2]. This
     proposal provides a solution to all issues identified when using IKE Identity
     Protect Mode (Main Mode), Aggressive Mode or Quick Mode.  Other extensions such as
     ISAKMP Config Mode (IKECFG) and XAUTH may be present. Address assignment can also
     use the standards track DHCP over IPSec method.

     Most importantly, this proposal does not require change to the NAT device itself,
     which is seen as practically too difficult, and presents a problem on the order of
     magnitude similar to deployment of IPv6 where all end-systems, and at least 1
     intermediate point (the NAT) must change.  We expect the technique described here
     to be used in the interim to pass IPv4 addressed traffic only and will become, one
     hopes, outdated as IPv6 is deployed, enabling true end-to-end secure IPSec
     communication without address translation.

  2. Conventions used in this document

     In examples, "C:" and "S:" indicate lines sent by the client and server

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
     "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
     interpreted as described in RFC-2119 [1].

  3. Design Overview and Rationale

     The IETF standard for NAT traversal by IPSec should be unencumbered from
     intellectual property claims to ensure rapid adoption by the IPSec vendor

     We propose to UDP encapsulate the ESP traffic, thereby allowing it through the

     During design several different criteria needed to be balanced
     -Encapsulation using UDP port 500 was chosen so as to enable easy deployment
       without the need to change firewall rules used by corporations.
     -The chosen method allows only ESP traffic to be encapsulated in UDP. This
       ensures that the most widely needed traffic protection method is supported,
       while ensuring that the method is as simple as possible, mainly in terms of
       implementation effort.
     -Encapsulation using UDP port 500 makes each packet 8 bytes larger than
       encapsulation using a different port, this is however balanced by the reduced
       need to have keepalive packets.
     -UDP encapsulation can break some of the current HW offload products.

  3.1 NAT Scenarios

     All below scenarios may support an IPSec transport/tunnel SA for all possible
     traffic, where 1 or more TCP or UDP sessions may be protected by the single IPSec
     transport/tunnel SA pair.  There may be multiple transport/tunnel SAs of finer
     granularity as well.

     A. One or more clients behind a NAT connecting simultaneously to a destination IP

     Client1 private IP <-> NAT Internet IP <---------> Internet IP Server
     Client2 private IP <->

     NAT is doing pure address translation 1:1, or doing address and port translation

     B. One or more clients behind NAT1 connecting simultaneously to the same dest IP
     address which is behind NAT2

     client1 private IP <-> NAT1 Internet IP <-> Internet IP NAT2 <-> private IP
     Client2 private IP <->

     NAT1 is performing many:1 port address translation, NAT2 is performing 1:1 address
     translation (into DMZ)

     C. One or more clients through 2 or more outbound NATs to destination Internet IP

     Client1 private IP <-> NAT1 private IP <-> NAT2 Internet IP <-> Internet IP
     Client2 private IP <->

     NAT1, NAT2 are performing many:1 port address translation.

     D. Internet client connecting to server behind NAT.

     Client1 Internet IP <------------> Internet IP NAT <--> private IP Server1
                                                        <--> private IP Server2

     NAT would most likely be doing 1:1 address translation.

     E. Multiple clients identifically configured (i.e. Client1 and Client2 have the
     same private network IP address assigned to them, like, each behind
     their own NAT, connected to same Internet IP.

     Client1 private IP <-> NAT1 Internet IP <-> Internet IP Server
     Client2 private IP <-> NAT2 Internet IP <->

     F. One or more clients inside a GW, comprising a remote worker's home LAN,
     connecting to the corporation's LAN protected by the corporation GW. Both home LAN
     and corporation LAN are using IP addresses from the same private address pool.

     Client1 private IP (corp) <-> GW private IP (isp) <-> NAT1 Internet IP <-> GW <->
     private IP (corp) <-> server

     F1. an IPSec tunnel SA for all traffic, where 1 or more TCP or UDP sessions may be
     protected by the single IPSec tunnel SA pair, between the two GWs.

  3.2 Encapsulation Scheme and Keeping NAT mappings alive

     We SHOULD provide a solution to keep alive the NAT port flow mapping - otherwise
     rekey from the responder will fail - same issue for stateful FWs opening a hole
     for corresponding inbound ports when it sees outbound src & dst port.  See a
     section below for the specifics on constructing and using a NAT keepalive packet.

     This draft uses the well-known IKE UDP port 500 to encapsulate both IKE control
     traffic and ESP data traffic. To distinguish these from one another, ESP traffic
     contains 8 bytes of zero after the UDP header. Normal IKE packets would contain
     the initiator cookie in this field which is never = 0.

                 ESP inside UDP encapsulation
     IPv4  |orig IP hdr  | UDP | 8 bytes 0 |ESP        | Data         |
           |(any options)| Hdr |           |Header     |              |
                                                       |<- encrypted->|
                                           |<- authenticated -------->|

                 IKE control inside UDP encapsulation
     IPv4  |orig IP hdr  | UDP | Initiator | Responder|Rest of IKE  |
           |(any options)| Hdr | Cookie    | Cookie   |Header Fields|

     Initiator cookies is 8 bytes, but non zero.  Responder cookie is 8 bytes and may
     be zero.  Implementations must be resilient to modification of this 8 byte 0
     field, making it non-zero and thus get received by IKE where it would attempt to
     parse invalid data.

     This approach allows for:

     1. a single well known port over which ESP UDP encapsulation would be done.  The
     IKE port is already assigned, and well-known for IPSec so firewalls needn't
     change, too.

     2. minimization of keep-alive/heartbeats for both IKE & ESP - as long as there was
     traffic flowing middle devices like stateful FWs & NATs would keep the mapping

     3.  maintenance of alignment boundaries.

     MTU reductions must be adjusted appropriated to account for 8 bytes + UDP header
     for ESP payloads.

     This approach doesn't support AH.

  4. Implementation Details

  4.1 IKE Main Mode exchange

     IKE MM initiator SA payload
      - Sends from IKE Src S, Dest 500.  S is usually 500.  This is not required, and
        the initiator may choose to float its source port.

      - Sends a VendorId payload of MD5("ESPThruNAT")

     IKE MM responder SA payload
      - Receive on UDP port 500.  It may also be the case that implementations support
        receiving on a non-500 destination port.  We say this is a well-known-to-the-
        client destination port in this case.

      - If Vendor ID payload for ESPThruNAT present UDP encapsulation capability is
        supported, the responder MUST construct and send the NAT Discovery payload of
        MD5(Initiator IP addr, I port, Responder IP addr, R port). The IP addresses
        and ports must be in network byte-order before calculating the hash.

      - The port value 0 MUST NOT be used in the hash.  If the internal representation
        of the port is 0, 500 must be used for generating this hash.

      - If the Initiator source port is not 500, store it for future use.  In
        scenarios A, B, and C, the source port is not likely to be 500.

      - Reply back to initiator's source port

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       ! Next Payload  !   RESERVED    !         Payload Length        !
       !                                                               !
       ~                       NAT Discovery                           ~
       !                                                               !

                  Figure 17:  NAT Discovery Payload Format

     The NAT Discovery Payload fields are defined as follows:

      o  Next Payload (1 octet) - Identifier for the payload type of the
         next payload in the message.  If the current payload is the last
         in the message, then this field will be 0.

      o  RESERVED (1 octet) - Unused, set to 0.

      o  Payload Length (2 octets) - Length in octets of the current
         payload, including the generic payload header.

     . NAT Discovery data (16 octets) - MD5 Hash = MD5(initiator IKE IP address,
       initiator IKE port, responder IKE IP address, responder IKE port). For an IKE
       packet constructed by the initiator:
          o The initiator IP address is the source address of the packet.  4 octets
            for V4 address, in network order.  16 octets for V6 address, in network
          o The initiator port is the source port of the packet.  2 octets, network
          o The responder IP address is the destination address of the packet. 4
            octets for V4 address, in network order.  16 octets for V6 address, in
            network byte-order.
          o The responder port is the destination port of the packet.  2 octets,
            network byte-order.

     The payload type for the NAT Discovery Payload is one hundred thirty (130).

     IKE MM Initiator KE payload
     Upon receiving NAT Discovery payload, compute the equivalent MD5 hash locally and
     compare with the received MD5 hash. If they differ, NAT is present.  Send Vendor
     Id payload of MD5("ESPThruNAT") and the locally generated NAT Discovery payload to
     responder, so responder knows also whether NAT exists.  If UDP encapsulation is
     supported, the NAT Discovery payload MUST be sent.

     IKE_MM_ID payload
     If NAT Discovery payloads have determined that NAT is present, then IP addresses
     SHOULD NOT be sent in the ID payload.  Since the NAT may be changing the IP
     addresses, sending an IP address that is incorrect as your ID is not recommended.
     It is up to each peer's policy how to handle this scenario.  The recommended
     approach is to send fully qualified DNS name (FQDN) or some other sort of name-
     based identity, such as the DN of the subject name in the certificate when using
     RSA signature authentication.  Since reverse DNS lookups may fail, it is again up
     to local policy if/how to verify this identity.   If a peer can determine that its
     address is not going to be translated, i.e. the address is a 'real' address, then
     this valid IP address can be sent as the MM Id.

  4.2 Aggressive Mode

     The rules for constructing the VID and the NAT Discovery Payload are the same as
     for Main Mode.
     In addition to normal aggressive mode:

     IKE AM Initiator
      - Send Vendor ID for ESPThruNAT

      - If Nat traversal is supported, the responder MUST send the Vendor ID for
        ESPThruNAT and the Nat Discovery payload as defined above.

     IKE AM Initiator 3rd message
     - Send Nat Discovery payload.

     Since Aggressive Mode sends the initiator's identity in the first payload, before
     NAT Discovery Payloads are exchanged, the initiator cannot select a different
     identity based on the result. If IP address based identity is used by the
     initiator and NAT is detected to exist, a warning SHOULD be issued.
     The Aggressive Mode negotiation MUST NOT be aborted for this reason, however.

  4.3 Identity Protect Mode Phase 2 (Quick Mode)

     IKE QM Initiator
     If policy allows UDP encapsulation, construct a proposal to negotiate UDP
     encapsulation.  This will be encoded as the encapsulation attribute.  Two new
     values will be added, UDP-TRANSPORT (61441), and UDP-TUNNEL (61440).  Any non-UDP
     encapsulated offers MAY be rejected by the peer, depending on policy.

     Initiator Proxy ID.  The recommended proxy id is hostname FQDN in place of the
     source address (scenario A, C) and destination address (scenario B, D) for
     transport mode, with the same recommendations as the MM IDs.  IP address MAY be
     used as a proxy ID if that IP address is a 'real' address. For tunnel mode, this
     ID can be the private address or net being protected.

     SA, ProxyID initiator,     ProxyID Responder   ----------->
         [src addr, src port]   [dest addr, dest port]

      - Receives offers, rejects all that are not NAT Encapsulated based on policy
      - Local policy decision how to verify the proxy IDs.  In transport mode, easiest
        is to ignore it, and simply use the Main Mode address.

  4.4 IPSec formats

     This encapsulation method has the benefit of no additional IKE complexity, and NAT
     keep alives are aggregated.  However, the expense is an extra 8 bytes in the
     header for each data packet.

     IKE tells IPSec:
      - inbound SA = ESPUDP protocol - normal ESP parameters
      - outbound SA = ESPUDP protocol - normal ESP parameters
      - which ports to use.  In scenarios A & C, initiator machine inside NAT will use
        src port S, dst port 500; Machine outside of NAT will use src port 500, dest
        port NAT mapped port.  S is usually 500, but may be floated.

     IPSec formats IPSec packets as:

                 ESP inside UDP encapsulation
     IPv4  |orig IP hdr  | UDP | 8 bytes 0 | ESP       |Data          |
           |(any options)| Hdr |           | Header    |              |
                                                       |<- encrypted->|
                                           |<--authenticated -------->|

                 IKE control inside UDP encapsulation
     IPv4  |orig IP hdr  | UDP | Initiator | Responder|Rest of IKE  |
           |(any options)| Hdr | Cookie    | Cookie   |Header Fields|

     ESP over NAT packet format receiving:
     - IPSec aware of new format inspects initiator cookie 8 bytes field -
     decrypts if dword= 0.
     - IPSec inspects initiator cookie - passes up UDP packet with initiator cookie set
     <> 0
     - Otherwise, IPSec strips UDP header, verifies that the UDP ports are the expected
     values, and processes the ESP payload

     ESP over NAT packet format outbound:
     - IPSec transforms original packet into ESP
     - IPSec takes constructs UDP encapsulation header with ports received from IKE, and
       the rest of the ESP as usual.

     As an example:

     C   <->   NAT   <->    X

     C sends srcport=500, dstport=500 (src 500,dst 500)
     NAT modifies to (1000,500). X replies with (500,1000).  NAT modifies to (500,500).
     C gets (500,500).  This is the same for both IKE and IPSec traffic.

     Now if C is sending from a different source port than 500:
     C sends (1111,500).  NAT modifies to (2222,500).  X replies to (500,2222).  NAT
     modifies to (500,1111).  C gets (500,1111).
     Since C's IPSec driver is going to need to determine this is an encapsulated
     packet, it will need to know to look at dest port 1111 for all packets.   Thus,
     the IPSec subsystem MAY listen on well-known ports other than 500 for IPSec
     traffic if mutually agreed upon by the peers.

  4.3 NAT Keepalives

     The keepalives will be sent by the Phase I initiator.  The purpose of the
     keepalives is only to keep up the NAT mapping, and not to keep alive any IKE or
     IPSec or other state.  Thus, the keepalive format is simply a UDP packet with the
     correct source and destination ports and addresses.  The packet contains a single
     data octet of 0xff.   This packet is sent as often as the initiator deems
     necessary, and SHOULD be silently discarded by the receiving IPSec driver.  The
     keep alives SHOULD only be sent if traffic (either IKE of IPSec) is not already
     present in the desired interval.  In addition, in order to allow the peer outside
     the NAT to initiate a rekey after the Main Mode has been torn down, the keep
     alives SHOULD be continued for some configurable period after all MMs and QMs are
     torn down.  The default time for the extra keep alives SHOULD be 5 minutes.  The
     packet SHOULD be silently discarded.  Since the NAT can fix-up the checksum of
     this packet and this packet has no IPSec hashing to verify integrity, checksum
     computation SHOULD be enabled for the keep alive packets.

               NAT keepalive packet
     IPv4  |orig IP hdr  | UDP | 0xFF |
           |(any options)| Hdr |      |

     See also ref [3].

  5. IPSec over NAT Operation

     A: NAT        X:

     We have machines A,B in the private address space, talking to the external machine
     on the internet X.   A initiates a MM to X.  A sends the IKE packet with src IP =, dst IP=, src port = 500, dst port = 500.  This packet hits the
     NAT, which translates it to src IP =, src port = 6666.  X gets the
     packet, and remembers that it came from src port 6666, and sends IKE reply to src
     IP, dst IP, src port 500, dst port 6666.  The NAT will
     translate this to, dst port 500, and send to A.  The MM exchange
     continues.  At the end, A has a MM [ (host FQDN),, src 500, dst
     500], and X has the MM [, (host FQDN), src 500, dst 6666].  If
     we are doing preshared key authentication in MM, then machine A would send the
     xxxxx as its IKE ID payload.

     Now, for QM, A proposes the QM proxy IDs as [src host FQDN, dst host FQDN, proto,
     src port, dest port] = [proxy source, proxy destination, protocol, src & dest
     ports], and transform ID ESPNAT in the SA payload.  The QM succeeds when source
     port is ignored.  When A plumbs the QM SAs into the driver (and possibly filters
     to match it), it uses its real addresses.

     Client A's QMs in driver:
     A->X:  [,, proto, src port, dst port]; UDP src 500, dst 500
     X->A:  [,, proto, src port, dst port]; UDP src *, dst 500

     Gateway X's QMs in driver:
     A->X:  [,, proto, src port, dst port]; UDP src 6666, dst 500
     X->A:  [,, proto, src port, dst port]; UDP src 500, dst 6666

     Now, the data packet is sent on A to  It matches the drivers outbound
     filter, its outbound SA, and the driver encrypts it.  It is sent out with IP src, dst, UDP src 500, dst 500.  It hits the NAT, and the NAT
     translates the src address, and source portcreates an entry for the SPI.   When
     the reply comes back from X, the NAT maps the SPI from X with the SPI send from A.
     Now the NAT knows which internal host to send the packet to, and A gets it.

     Multiple private network clients

     Now B wants to connect to X.  When B sends to X, the NAT will translate to, src port 7777.  Thus, the NAT will be able to correctly multiplex X's
     response.  X will end up with 2 main modes, 1 to A and 1 to B.
     To A:  [,, src 500, dst 6666]
     To B:  [,, src 500, dst 7777]
     Multiple private clients are handled by having the external machine add the
     local/peer IKE ports to its SA key.

     IKE Rekey

     If the gateway X initiates a MM or QM rekey, it must do so from the same src (500)
     to the same destination (6666).  The NAT will have maintained the mapping
     (assuming keep-alive scheme is present either in IKE or in layers above IPSec).
     If the client A initiates a MM rekey, we just begin the above process over again.

     TCP, UDP checksum in IPSec transport

     We need to handle the tcp and udp checksum when IPSec ESP transport is used.  The
     IPSeced packet will look like (from RFC 2406):

                      AFTER APPLYING ESP
           IPv4  |orig IP hdr  |UDP |8 bytes | ESP |     |      |   ESP   | ESP|
                 |(any options)|Hdr | 0      | Hdr | TCP | Data | Trailer |Auth|
                                                   |<----- encrypted --------->|
                                             |<-- authenticated -------------->|

     Notice that none of the IP header is protected, so the NAT is free to modify the
     addresses.  When the NAT modifies the address in the IP header, it can recalculate
     the IP checksum, which is also unprotected.  However, in the TCP (or UDP) portion,
     is the TCP (or UDP) header, which contains its own checksum.  This checksum is
     over the pseudoheader, which contains the src and dst addresses in the IP header.
     Thus, if the NAT changes an address in the IP header, it cannot recomputed the TCP
     (or UDP) checksum since that portion of the packet is encrypted.

     There are 2 ways around this problem.  One is disabling checksum checking on both
     peers for packets on the SAs in question.  The other option is to compute the TCP
     (or UDP) checksum correctly before sending the packet, or after receiving the
     packet.  If done before sending the packet, it would require that the client know
     its external address, which is not an assumption in this specification.  If done
     after decrypting the IPSec packet, but would be unnecessary CPU cycles if the
     stack accepted the value of zero for checksum or using some other implementation
     specific method.  So the choice for performance reasons is to disable UDP & TCP
     checksum by the stack when possible.

     Disabling host OS UDP & TCP checksums loses very little functionality since nearly
     the entire packet is protected by the hash from the ESP.  This hash will verify
     the integrity in transit of all fields protected by the TCP (or UDP) checksums
     except for those fields in the pseudoheader.  Of these fields (src, dst ip
     address, protocol, length) src and dst address are generally the most important,
     and verification of them is insured by possession of the session keys for the
     IPSec session.  For large TCP segments that result in multiple IP packets (initial
     plus IP fragments), the TCP segment can only be reconstituted using individually
     properly reassembled and authenticated IPSec packet.  So there is no value in re-
     checking TCP checksum.

     Therefore, TCP checksum MUST not be checked when the packet arrives secured by a
     SA using NAT encapsulation.  UDP packets SHOULD have their xsum field set to 0 on
     sending into an SA using NAT encapsulation.  UDP check sums MUST not be checked on
     receiving a packet in an SA using NAT encapsulation.

  6. Justification of design

     Other methods were carefully considered, and discarded.

  6.1 Floated IKE port
     First, there is the option of floating IKE to a different well-known port during
     the negotiation, and the using this new port number as a demultiplexer.   This
     would allow the encapsulated packet format to be:

                 ESP inside UDP floated port encapsulation
     IPv4  |orig IP hdr  | UDP |Type  | ESP | Data          |
           |(any options)| Hdr |      | Hdr |               |
                                            |<-- encrypted->|
                               |<-- authenticated --------->|

     The IKE format on the floated port is:

                 IKE control inside UDP encapsulation
     IPv4  |orig IP hdr  | UDP | Type |Initiator | Responder|Rest of IKE  |
           |(any options)| Hdr |      |Cookie    | Cookie   |Header Fields|

     This would allow the 4 octet type field to give the type of the data following.
     We can modify these formats in this way because the floated port distinguished
     between the normal IKE format on port 500, and this format on the new port.

     This method was discarded because it is very difficult to float IKE to a new port.
     The biggest difficulty is resolving the conflict between floating the port,
     preferably before any quick modes are negotiated, yet negotiating in quick mode
     the encapsulation attribute.  Thus, we'd have to always float IKE to a new port if
     NAT were detected, even if that NAT is known to be IPSec aware, and that UDP
     encapsulation, and therefore IKE floating is unneeded.  However, even though IKE
     would need to be floated always, actual ESP traffic could be either encapsulated
     in UDP or not, as defined by policy and as negotiated by QM.

     In addition, firewalls will need to open another UDP hole, which will meet with
     strong opposition.

  6.2 Using two UDP ports

     This approach left IKE on 500, and encapsulates the IPSec traffic using a
     different well-known port.  The biggest problem with this is that 2 sets of keep-
     alives must be sent to keep the NAT mappings alive.  This will be expensive for
     the IKE mapping, since IKE traffic is usually infrequent.  For wireless, this is
     extremely expensive. The second problem is that the IPSec subsystem doesn't get
     the encapsulation information (the ports) from IKE, but must create that state
     upon receiving the first encapsulated packet.  This is more prone to denial of
     service.  It is possible to fail the connection if the attacker grabs the first
     encapsulated packet, and modifies the unprotected encapsulation header before the
     receiving IPSec subsystem gets it.   This would cause the receiving IPSec
     subsystem to create state based upon an incorrect mapping, and traffic would fail.
     The proposed approach is more immune to these first packet manipulations, since an
     attacker who modified the ports in the UDP header of the initial IKE packet would
     only cause multiple Main Modes state entries to be created on the responder, but
     wouldn't necessarily scuttle the connection.

     This method will also make firewalls open an additional UDP hole.

  7. Security Considerations

     The authors do not think this method exposes any security vulnerabilities into
     otherwise sound IPSec implementation. However, the following issues need to be
     addressed by implementers.

      When using IPsec tunnel mode, clients connecting to the gateway may be using the
      same IP address in the inner IP header. One scenario where this is likely to
      happen is when the clients are using in the inner IP header their local private
      network address, and they are in different private networks. The GW MUST ensure
      that traffic destined towards the clients is sent only to the correct recipient.

      When using IPsec tunnel mode, a client connecting to a gateway may be trying to
      steal an IP address from the network protected by the gateway. The QM initiated
      by the client MUST only be allowed by the gateway if:
      - The QM IP address identities match the static policy defined at the gateway.
      - The QM IP source address matches the address assigned to the client by the
      - The gateway is configured to do further NAT to the packets, ensuring that
        whatever IP address the client is using, this cannot be used to steal local
        network IP addresses.
      Any of these ensures that attacker is not possible to steal local network IP

  8. References

     1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997

     2  Aboba, B., "NAT and IPSEC", Internet draft (work in progress),
        draft-aboba-nat-ipsec-02.txt, July 2000

     3  Huitema, C., "Short term NAT requirements for UDP based peer-to-peer
        applications", Internet draft (work in progress),
        draft-huitema-natreq4udp-00.txt, February 2001

   The following IETF WGs have work which has fed into this specification and could
   be the one to pursue standardizing a solution:
   NAT Working Group: http://www.ietf.org/html.charters/nat-charter.html
   IPSec Working Group:  http://www.ietf.org/html.charters/ipsec-charter.html
   IPSec Remote Access Working Group: http://www.ietf.org/html.charters/ipsra-

   IKE & IPSec issues with NAT are documented in these drafts.


   Lucent has published an information RFC to describe how IPSec tunnels can pass
   through NATs.

   Lucent has documented the VPN Masquerade method of IPSec over NAT, where the NAT
   is aware of IKE and ESP traffic specifically and takes steps to estimate how to
   pass the traffic.

   3Com and others have documented a method for IPSec traversal of NATs where the NAT
   is changed to support communication with the IPSec peer:

   SSH Communications Security is known to have intellectual property on some parts
   of their design documented in the link below.  This design we believe avoids what
   we guess is the intellectual property.

0.  Acknowledgments

   Tamir Zegman of CheckPoint provided helpful advice for producing the รป00 version
   of this draft.

   Many people engaged in discussion which lead to this proposal.  In particular,
   engineers at Microsoft, Cisco Systems, Checkpoint, F-Secure, SSH Communications
   Security, Inc.

1. Author's Addresses

   Ari Huttunen
   F-Secure Corporation
   Phone: +358-9-2520 0700
   E-Mail: Ari.Huttunen@F-Secure.com

   Joern Sierwald
   F-Secure Corporation
   E-Mail: Joern@F-Secure.com

   William Dixon, Brian Swander
   One Microsoft Way, Redmond WA 98052
   Phone: 425-703-8729
   Email: wdixon@microsoft.com

   Victor Volpe
   Cisco Systems
   Email: vvolpe@cisco.com

   Larry DiBurro
   Nortel Networks
   Phone: 978-264-7171

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/