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

Versions: 00 01

Internet Engineering Task Force                             Ari Huttunen
Internet-Draft                                            Joern Sierwald
Expires: March 2001                                 F-Secure Corporation


                   ESP Encapsulation in UDP Packets
               draft-huttunen-ipsec-esp-in-udp-00.txt

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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   This document defines a method to encapsulate ESP in UDP, and a method
   to negotiate this encapsulation using IKE.

   The primary motivation for such encapsulation is to allow ESP traffic
   pass through NATs. However, it is also possible to use it without NATs.

   This document defines methods for determining the need for
   UDP encapsulation, both in the presence of Basic NAT (i.e. without
   port translation) and in the presence of NAPT (with port translation).
   This is done by the receiver, based on the information available
   in standard IKE packets.

   ESPUDP in both tunnel mode and transport mode are defined. Tunnel mode
   ESPUDP through NAT is seen easier to implement, but transport mode ESPUDP
   can also be made to go through NAT.

Definitions

   Basic NAT

      With Basic NAT, a block of external addresses are set aside for
      translating addresses of hosts in a private domain as they originate
      sessions to the external domain. For packets outbound from the
      private network, the source IP address and related fields such as IP,
      TCP, UDP and ICMP header checksums are translated. For inbound
      packets, the destination IP address and the checksums as listed above
      are translated. [RFC 2663]

   Network Address Port Translation (NAPT)

      NAPT extends the notion of translation one step further by also
      translating transport identifier (e.g., TCP and UDP port numbers,
      ICMP query identifiers). This allows the transport identifiers of a
      number of private hosts to be multiplexed into the transport
      identifiers of a single external address. NAPT allows a set of hosts
      to share a single external address. Note that NAPT can be combined
      with Basic NAT so that a pool of external addresses are used in
      conjunction with port translation. [RFC 2663]

   ESP encapsulated in UDP (ESPUDP)

      An encapsulation mechanism defined by this draft.

1. Introduction

   This document defines a method to encapsulate ESP in UDP, and a method
   to negotiate this encapsulation using IKE.

   The primary motivation for such encapsulation is to allow ESP traffic
   to pass through NATs. However, it is also possible to use it without NATs.
   The reasons for needing a mechanism to traverse NATs are discussed
   in [ABOBA].

   The main driving principle in creating this document has been
   simplicity. The defined mechanisms can be implemented and deployed
   rapidly, and they are believed to solve all important practical problems.

   This document defines methods for determining the need for
   UDP encapsulation, both in the presence of Basic NAT (i.e. without
   port translation) and in the presence of NAPT (with port translation).
   This is done by the receiver, based on the information available
   in standard IKE packets.

   ESPUDP in both tunnel mode and transport mode are defined. Tunnel mode
   ESPUDP through NAT is seen easier to implement, but transport mode ESPUDP
   can also be made to go through NAT.

   The overhead over ordinary ESP modes is 8 bytes for the UDP header.

2. Design Choices

   This document does not define a method to pass AH packets through
   NATs. The reason is that such mechanism is seen unnecessary.

   No negotiation protocol for ESPUDP is defined. This is for simplicity,
   since practical problems are solvable without such a mechanism. If
   such a mechanism is wanted, something like in [STENBERG] could
   be deployed.

   ESPUDP uses a different port than IKE. This is to enable firewalls
   to differentiate between these two types of traffic.

3. Header Formats

   This section contains definitions for IP, UDP and ESP packet formats
   for easy reference.

   IP header is defined in [RFC 791].

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The checksum in the IP header encompasses only the IP header.


   UDP header is defined in [RFC 768].

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Source Port            |      Destination Port         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length              |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The checksum in the UDP header encompasses parts of the IP header,
   the UDP header, and the UDP payload.

   With ESPUDP the UDP cheksum is disabled. There's no need for it here
   because ESP authentication goes between the same network entities.

   The ESPUDP source and destination ports have the value 2797
   (or 2746, undecided) when sent by the initiator inside a private
   addressing realm.

Reference:
cpudpencap      2746/tcp   CPUDPENCAP
cpudpencap      2746/udp   CPUDPENCAP
#                          Tamir Zegman <zegman@checkpoint.com>
esp-encap       2797/tcp   esp-encap
esp-encap       2797/udp   esp-encap
#                          Jorn Sierwald <joern.sierwald@datafellows.com>


   ESP header is defined in [RFC 2406].

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
   |               Security Parameters Index (SPI)                 | ^Auth.
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
   |                      Sequence Number                          | |erage
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
   |                    Payload Data* (variable)                   | |   ^
   ~                                                               ~ |   |
   |                                                               | |Conf.
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
   |               |     Padding (0-255 bytes)                     | |erage*
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
   |                               |  Pad Length   | Next Header   | v   v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
   |                 Authentication Data (variable)                |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   ESPUDP has the following packet structures.

   Transport mode:
            ---------------------------------------------------------
      IPv4  |orig IP hdr  | UDP | ESP |              |   ESP   | ESP|
            |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth|
            ---------------------------------------------------------
                                      |<------- encrypted ---->|
                                |<-------- authenticated ----->|

   Tunnel mode:
      ----------------------------------------------------------------------
IPv4  | new IP hdr* | UDP | ESP | orig IP hdr*  |             | ESP   | ESP|
      |(any options)| HDr | Hdr | (any options) | Payload Data|Trailer|Auth|
      ----------------------------------------------------------------------
                                |<--------- encrypted --------------->|
                          |<----------- authenticated --------------->|

   NAT translation keepalive:
            ---------------------
      IPv4  |orig IP hdr  | UDP |
            |(any options)| Hdr |
            ---------------------


4. IKE Negotiation

   The peers SHOULD exchange the VID "draft-huttunen-ipsec-esp-in-udp-00.txt"
   in the first two IKE phase I messages if they support this draft. If this
   is not done, the initiator SHOULD NOT use the private encapsulation
   attributes during phase II.

   ESPUDP is negotiated by using one of the following encapsulation
   attributes in an ESP proposal:

     61440     ESPUDP in tunnel mode
     61441     ESPUDP in transport mode


<<WHICH ONES TO USE??>>
61440 ==> UDP encapsulation + ESP in tunnel mode (CheckPoint)
63337 ==> UDP encapsulation + ESP in tunnel mode (F-Secure)
63338 ==> UDP encapsulation + ESP in transport mode (F-Secure)


   The responder SHOULD choose ESPUDP proposals if the packets are
   determined to have come through NAT, even if VIDs were not exchanged
   during phase I. This determination can be done in two ways:

   a) If the IKE source port in the received packet is not 500.

   b) If the phase II identity is an IP address from a private address
      range that is different from the source IP address in the IKE packet,
      and the policy defines a connection from a host.
      See [RFC1918].

   Method a) allows determining NAT traversal in all situations when NAT
   is of type NAPT, assuming the initiator used the source port 500.
   Method b) allows determining NAT traversal in host-to-X situations
   in the presence of Basic NAT.

   If the proposal list contains only ESPUDP proposals
   that are otherwise acceptable, one of them SHOULD be chosen even
   if NAT has not been determined to exist between the peers.

   These methods are not foolproof. If it is determined incorrectly
   that NAT exists, an overhead of 8 bytes is incurred. This can be avoided
   by the initiator by not providing ESPUDP proposals.
   On the other hand, if incorrect determination is made that NAT doesn't
   exist, the connection will fail. This can be avoided by the initiator by
   providing only ESPUDP encapsulated proposals.

   An implementation confirming to this draft MUST implement tunnel mode,
   and MAY implement transport mode. (If and when transport mode operation
   through NAT is specified more fully, this should be reviewed.)

   The source IP address or the source port of the initiator, as seen by
   the responder, MUST NOT change during the connection.

   When ESPUDP is used to traverse NATs, IP address -based phase I identities
   MUST NOT be used to identify entities inside private addressing spaces.
   IP address based identities are used in ESPUDP tunnel mode according to
   standard IKE rules. In ESPUDP transport mode the responder SHOULD accept
   a phase II IP address identity that is different from the IP packet source
   address, iff the phase II identity is a single IP address from a private
   address space.

5. ESPUDP NAT Translation Keepalive

   A peer MAY choose to send a UDP packet using the same ports as
   ESPUDP with no data contained in the UDP packet. The typical
   reason to do this would be to keep the NAT translation table(s)
   active when no user data is being transferred.

   The receiver of such an empty ESPUDP packet MUST silently
   ignore the packet.

   Such empty ESPUDP packets SHOULD NOT force the link to stay
   up, and they SHOULD NOT be counted as user traffic. (They are
   also not a candidate mechanism for IKE/IPsec heartbeats.)

   A peer MAY also choose to send an empty UDP packet using
   the IKE port numbers. This packet is an illegal IKE packet
   and will be discarded by the recipient. No sane IKE implementation
   will terminate a connection due to this, since such packets
   are so easy to forge. The reason for this would be to keep
   the NAT translation tables for IKE messages active.

6. Address Translation Options

   Since separate addressing spaces are being used, addresses must
   be translated by someone. ESPUDP ignores the address translations
   that occur along its route, and thus either of the endpoints
   must do this.

   In ESPUDP tunnel mode, either of the following MUST be done:
   a) The initiator MUST obtain an IP address from the peer, and
      use this IP address in all tunneled packets being sent.
   b) The responder MUST do NAT translation on incoming packets.

   In ESPUDP transport mode, the initiator MUST correct the cheksums
   in the packets being received through NAT. Their checksums will
   be incorrect, since NAT has changed the IP address. Similarly
   the responder MUST correct the checksums. The responder MUST also
   do NAT translation, so that two clients using the same source port
   do not clash.

7. Deployment Considerations

7.1 Client <-> Gateway


          +----+            \ /               +----+          +----+
          |    |-------------|----------------|    |----------|    |
          +----+            / \               +----+          +----+
          Alice's           NAT                 GW            Suzy's
          Laptop                                              Server
                     ESPUDP (tunnel mode)
               ================================

   The effect of ESPUDP is to allow the protected packets to pass
   through the tunnel. However, the contained IP addresses are not affected.
   Since Alice's laptop may have any IP address in its current residing
   network, there must be some method of converting that IP address
   to be usable in Suzy's network.

   Two methods exist:
   a) The GW can assign Alice's laptop an intranet address using some
   mechanism like DHCP or ConfigMode.
   b) The GW can internally assign Alice's laptop an intranet address
   and do NAT translation as the packets pass through the GW.

   Payload protocols carrying IP addresses, like FTP, continue to work
   because the NAT translation for those is done either at Alice's laptop
   (method a) or at the GW (method b).

7.2 Client <-> Client


          +----+            \ /                   +----+
          |    |-------------|--------------------|    |
          +----+            / \                   +----+
          Alice's           NAT                   Suzy's
          Laptop                                  Server
                    ESPUDP (tunnel/
                              transport mode)
               ====================================

   Transport mode ESPUDP requires that both Alice's laptop and Suzy's
   server contain functionality to correct checksums that are invalidated
   by the source IP address being changed. Suzy's server must also do
   NAT to allow several clients using the same UDP source port to connect.
   For this reason, ESPUDP in transport mode is not recommended when
   NAT traversal is required.

  The recommended choice is to use tunnel mode ESP over UDP
  in this situation. Similarly to the Client<->GW case, the contained
  protocols like FTP continue to work.

7.3 Gateway <-> Gateway


          +----+      +----+      \ /               +----+          +----+
          |    |------|    |-------|----------------|    |----------|    |
          +----+      +----+      / \               +----+          +----+
          Alice's       GW        NAT                 GW            Suzy's
          Laptop                                                    Server
                               ESPUDP (tunnel mode)
                          ============================

   The GW<->GW case is similar to the Client<->GW case; ESPUDP allows
   the connection to pass NAT, but a method to convert Alice's laptop's
   address to be suitable in Suzy's network is necessary. The only viable
   option is to do NAT at either of the GWs, since no address assignment
   protocol is defined to work between GWs.

   Contained protocols like FTP continue to work because NAT can be
   performed on unencrypted packets.

7.4 Client <-> Gateway with End-to-end encryption


          +----+            \ /               +----+          +----+
          |    |-------------|----------------|    |----------|    |
          +----+            / \               +----+          +----+
          Alice's           NAT                 GW            Suzy's
          Laptop                                              Server
                     ESPUDP (tunnel mode)
               ================================
                     ESP (transport mode)
               ================================================

   One way to make this work is for the GW to provide Alice's laptop
   a suitable address, so that the GW need not do any NAT to
   the contained packets.

7.5 L2TP over ESPUDP

   This section has not been written/studied yet. What will it require
   to be able to do FTP through all these protocol layers? Volunteers?

8. Security Considerations

   On some systems ESPUDP may have DoS attack consequences,
   especially if ordinary operating system UDP-functionality is
   being used. It may be recommended not to open an ordinary UDP-port
   for this.

   Implementors are warned that it is possible for remote peers to
   negotiate entries that overlap in the GW.

          +----+            \ /
          |    |-------------|----\
          +----+            / \    \
          Alice's         NAT 1     \
          Laptop                     \
         10.1.2.3                     \
          +----+            \ /        \       +----+          +----+
          |    |-------------|----------+------|    |----------|    |
          +----+            / \                +----+          +----+
          Bob's           NAT 2                  GW            Suzy's
          Laptop                                               Server
         10.1.2.3

   Because GW will now see two possible SAs that lead to 10.1.2.3, it
   can become confused where to send packets coming from Suzy's server.
   Implementations MUST devise ways of preventing such a thing from
   occurring; either by disallowing such connections or by other means.

   It is not possible for a hacker to obtain an arbitrary address in the
   intranet being protected by the GW. If address assignment by the GW
   is provided, only the address assigned to the hacker is allowed to pass
   through the GW. In the other case, address is always assigned to
   the hacker internally by the GW and the (arbitrary) IP address of the
   hacker is always translated by a NAT functionality in the GW.

Acknowledgements

   Tamir Zegman of CheckPoint, and William Dixon of Microsoft have
   provided helpful advice for producing this draft.

Authors' Contact Information

   Ari Huttunen
   E-Mail: Ari.Huttunen@F-Secure.com

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

References

   [RFC 1918] Address Allocation for Private Internets

   [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

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

   [STENBERG] Stenberg, M. et. al. IPsec NAT-Traversal, Internet draft
              (work in progress), draft-stenberg-ipsec-nat-traversal-00.txt,
              July 2000


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