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 esp-encap 2797/tcp esp-encap esp-encap 2797/udp esp-encap # Jorn Sierwald 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 <> 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