Re: draft-huttunen-ipsec-esp-in-udp-00.txt
Jim Tiller <jtiller@belenosinc.com> Sat, 16 September 2000 15:04 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18442; Sat, 16 Sep 2000 08:04:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06882 Sat, 16 Sep 2000 09:42:19 -0400 (EDT)
Date: Sat, 16 Sep 2000 09:54:22 -0400
From: Jim Tiller <jtiller@belenosinc.com>
X-Mailer: The Bat! (v1.44)
Reply-To: Jim Tiller <jtiller@belenosinc.com>
Organization: Belenos, Inc.
X-Priority: 3 (Normal)
Message-ID: <3861667092.20000916095422@belenosinc.com>
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
CC: ipsec <ipsec@lists.tislabs.com>
Subject: Re: draft-huttunen-ipsec-esp-in-udp-00.txt
In-reply-To: <39C1DE00.9E1BE645@F-Secure.com>
References: <39C1DE00.9E1BE645@F-Secure.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello Ari, A long time ago I attempted to draft something very similar to this, I'm glad to see the subject has received some attention again. I have a comment about the port number selection I would like to get some feedback on. This is a point where Check Point and I disagreed in the compilation of a draft. AH> The ESPUDP source and destination ports have the value 2797 AH> (or 2746, undecided) when sent by the initiator inside a private AH> addressing realm. Why can't this be negotiated? It can be argued that many of the systems that are performing NAT are firewalls, or the like. In these scenarios (where a filtering device is performing NAT) it is very common for the firewall to be limiting the type of traffic permitted. It can also be assumed that a system wanting to create an IPSec VPN through the NAT'ing device has no influence in the modification of the filtering policies. So, the use of a fixed port could foreseeable hinder many of the implementations. I agree that the solution in nature is simplified and should be - but there would be little effort in providing the port as an option in a proposal, or similar. I have other issues that I would like to discuss, but it is this one I would like some comments on. -jim Friday, September 15, 2000, 4:29:52 AM, you wrote: AH> Some time ago I mentioned that we're working on an alternative proposal AH> for doing UDP encapsulation of ESP messages. The first version of AH> the draft is now ready, and I submitted it just a moment ago. I've never AH> done such a thing before, so I'll send it to this list as well. AH> Sorry if this causes inconvenience. AH> I'll be available in the San Diego interop workshop, in case anybody AH> wishes to talk about this draft. AH> The reason this draft talks about CheckPoint is that our implementations AH> should be really similar. After we'll do some testing, we'll know better AH> ;). AH> A later version will of course drop any specific company names from it. AH> Comments are appreciated! AH> Ari AH> Internet Engineering Task Force Ari Huttunen AH> Internet-Draft Joern Sierwald AH> Expires: March 2001 F-Secure Corporation AH> ESP Encapsulation in UDP Packets AH> draft-huttunen-ipsec-esp-in-udp-00.txt AH> Status of this Memo AH> This document is an Internet-Draft and is in full conformance with AH> all provisions of Section 10 of RFC2026. AH> Internet-Drafts are working documents of the Internet Engineering AH> Task Force (IETF), its areas, and its working groups. Note that AH> other groups may also distribute working documents as AH> Internet-Drafts. AH> Internet-Drafts are draft documents valid for a maximum of six AH> months and may be updated, replaced, or obsoleted by other documents AH> at any time. It is inappropriate to use Internet-Drafts as reference AH> material or to cite them other than as "work in progress." AH> The list of current Internet-Drafts can be accessed at AH> http://www.ietf.org/ietf/1id-abstracts.txt. AH> The list of Internet-Draft Shadow Directories can be accessed at AH> http://www.ietf.org/shadow.html. AH> This Internet-Draft will expire on January 12, 2001. AH> Copyright Notice AH> Copyright (C) The Internet Society (2000). All Rights Reserved. AH> Abstract AH> This document defines a method to encapsulate ESP in UDP, and a AH> method AH> to negotiate this encapsulation using IKE. AH> The primary motivation for such encapsulation is to allow ESP traffic AH> pass through NATs. However, it is also possible to use it without AH> NATs. AH> This document defines methods for determining the need for AH> UDP encapsulation, both in the presence of Basic NAT (i.e. without AH> port translation) and in the presence of NAPT (with port AH> translation). AH> This is done by the receiver, based on the information available AH> in standard IKE packets. AH> ESPUDP in both tunnel mode and transport mode are defined. Tunnel AH> mode AH> ESPUDP through NAT is seen easier to implement, but transport mode AH> ESPUDP AH> can also be made to go through NAT. AH> Definitions AH> Basic NAT AH> With Basic NAT, a block of external addresses are set aside for AH> translating addresses of hosts in a private domain as they AH> originate AH> sessions to the external domain. For packets outbound from the AH> private network, the source IP address and related fields such as AH> IP, AH> TCP, UDP and ICMP header checksums are translated. For inbound AH> packets, the destination IP address and the checksums as listed AH> above AH> are translated. [RFC 2663] AH> Network Address Port Translation (NAPT) AH> NAPT extends the notion of translation one step further by also AH> translating transport identifier (e.g., TCP and UDP port numbers, AH> ICMP query identifiers). This allows the transport identifiers of AH> a AH> number of private hosts to be multiplexed into the transport AH> identifiers of a single external address. NAPT allows a set of AH> hosts AH> to share a single external address. Note that NAPT can be combined AH> with Basic NAT so that a pool of external addresses are used in AH> conjunction with port translation. [RFC 2663] AH> ESP encapsulated in UDP (ESPUDP) AH> An encapsulation mechanism defined by this draft. AH> 1. Introduction AH> This document defines a method to encapsulate ESP in UDP, and a AH> method AH> to negotiate this encapsulation using IKE. AH> The primary motivation for such encapsulation is to allow ESP traffic AH> to pass through NATs. However, it is also possible to use it without AH> NATs. AH> The reasons for needing a mechanism to traverse NATs are discussed AH> in [ABOBA]. AH> The main driving principle in creating this document has been AH> simplicity. The defined mechanisms can be implemented and deployed AH> rapidly, and they are believed to solve all important practical AH> problems. AH> This document defines methods for determining the need for AH> UDP encapsulation, both in the presence of Basic NAT (i.e. without AH> port translation) and in the presence of NAPT (with port AH> translation). AH> This is done by the receiver, based on the information available AH> in standard IKE packets. AH> ESPUDP in both tunnel mode and transport mode are defined. Tunnel AH> mode AH> ESPUDP through NAT is seen easier to implement, but transport mode AH> ESPUDP AH> can also be made to go through NAT. AH> The overhead over ordinary ESP modes is 8 bytes for the UDP header. AH> 2. Design Choices AH> This document does not define a method to pass AH packets through AH> NATs. The reason is that such mechanism is seen unnecessary. AH> No negotiation protocol for ESPUDP is defined. This is for AH> simplicity, AH> since practical problems are solvable without such a mechanism. If AH> such a mechanism is wanted, something like in [STENBERG] could AH> be deployed. AH> ESPUDP uses a different port than IKE. This is to enable firewalls AH> to differentiate between these two types of traffic. AH> 3. Header Formats AH> This section contains definitions for IP, UDP and ESP packet formats AH> for easy reference. AH> IP header is defined in [RFC 791]. AH> 0 1 2 3 AH> 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 AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> |Version| IHL |Type of Service| Total Length | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Identification |Flags| Fragment Offset | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Time to Live | Protocol | Header Checksum | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Source Address | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Destination Address | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Options | Padding | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> The checksum in the IP header encompasses only the IP header. AH> UDP header is defined in [RFC 768]. AH> 0 1 2 3 AH> 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 AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Source Port | Destination Port | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> | Length | Checksum | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> The checksum in the UDP header encompasses parts of the IP header, AH> the UDP header, and the UDP payload. AH> With ESPUDP the UDP cheksum is disabled. There's no need for it here AH> because ESP authentication goes between the same network entities. AH> The ESPUDP source and destination ports have the value 2797 AH> (or 2746, undecided) when sent by the initiator inside a private AH> addressing realm. AH> Reference: AH> cpudpencap 2746/tcp CPUDPENCAP AH> cpudpencap 2746/udp CPUDPENCAP AH> # Tamir Zegman <zegman@checkpoint.com> AH> esp-encap 2797/tcp esp-encap AH> esp-encap 2797/udp esp-encap AH> # Jorn Sierwald AH> <joern.sierwald@datafellows.com> AH> ESP header is defined in [RFC 2406]. AH> 0 1 2 3 AH> 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 AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> ---- AH> | Security Parameters Index (SPI) | AH> ^Auth. AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> |Cov- AH> | Sequence Number | AH> |erage AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AH> ---- AH> | Payload Data* (variable) | | AH> ^ AH> ~ ~ | AH> | AH> | | AH> |Conf. AH> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> |Cov- AH> | | Padding (0-255 bytes) | AH> |erage* AH> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AH> | AH> | | Pad Length | Next Header | v AH> v AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> ------ AH> | Authentication Data (variable) | AH> ~ ~ AH> | | AH> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AH> ESPUDP has the following packet structures. AH> Transport mode: AH> --------------------------------------------------------- AH> IPv4 |orig IP hdr | UDP | ESP | | ESP | ESP| AH> |(any options)| Hdr | Hdr | Payload Data | Trailer |Auth| AH> --------------------------------------------------------- AH> |<------- encrypted ---->| AH> |<-------- authenticated ----->| AH> Tunnel mode: AH> ---------------------------------------------------------------------- AH> IPv4 | new IP hdr* | UDP | ESP | orig IP hdr* | | ESP | AH> ESP| AH> |(any options)| HDr | Hdr | (any options) | Payload AH> Data|Trailer|Auth| AH> ---------------------------------------------------------------------- AH> |<--------- encrypted --------------->| AH> |<----------- authenticated --------------->| AH> NAT translation keepalive: AH> --------------------- AH> IPv4 |orig IP hdr | UDP | AH> |(any options)| Hdr | AH> --------------------- AH> 4. IKE Negotiation AH> The peers SHOULD exchange the VID AH> "draft-huttunen-ipsec-esp-in-udp-00.txt" AH> in the first two IKE phase I messages if they support this draft. If AH> this AH> is not done, the initiator SHOULD NOT use the private encapsulation AH> attributes during phase II. AH> ESPUDP is negotiated by using one of the following encapsulation AH> attributes in an ESP proposal: AH> 61440 ESPUDP in tunnel mode AH> 61441 ESPUDP in transport mode AH> <<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) AH> The responder SHOULD choose ESPUDP proposals if the packets are AH> determined to have come through NAT, even if VIDs were not exchanged AH> during phase I. This determination can be done in two ways: AH> a) If the IKE source port in the received packet is not 500. AH> b) If the phase II identity is an IP address from a private address AH> range that is different from the source IP address in the IKE AH> packet, AH> and the policy defines a connection from a host. AH> See [RFC1918]. AH> Method a) allows determining NAT traversal in all situations when NAT AH> is of type NAPT, assuming the initiator used the source port 500. AH> Method b) allows determining NAT traversal in host-to-X situations AH> in the presence of Basic NAT. AH> If the proposal list contains only ESPUDP proposals AH> that are otherwise acceptable, one of them SHOULD be chosen even AH> if NAT has not been determined to exist between the peers. AH> These methods are not foolproof. If it is determined incorrectly AH> that NAT exists, an overhead of 8 bytes is incurred. This can be AH> avoided AH> by the initiator by not providing ESPUDP proposals. AH> On the other hand, if incorrect determination is made that NAT AH> doesn't AH> exist, the connection will fail. This can be avoided by the initiator AH> by AH> providing only ESPUDP encapsulated proposals. AH> An implementation confirming to this draft MUST implement tunnel AH> mode, AH> and MAY implement transport mode. (If and when transport mode AH> operation AH> through NAT is specified more fully, this should be reviewed.) AH> The source IP address or the source port of the initiator, as seen by AH> the responder, MUST NOT change during the connection. AH> When ESPUDP is used to traverse NATs, IP address -based phase I AH> identities AH> MUST NOT be used to identify entities inside private addressing AH> spaces. AH> IP address based identities are used in ESPUDP tunnel mode according AH> to AH> standard IKE rules. In ESPUDP transport mode the responder SHOULD AH> accept AH> a phase II IP address identity that is different from the IP packet AH> source AH> address, iff the phase II identity is a single IP address from a AH> private AH> address space. AH> 5. ESPUDP NAT Translation Keepalive AH> A peer MAY choose to send a UDP packet using the same ports as AH> ESPUDP with no data contained in the UDP packet. The typical AH> reason to do this would be to keep the NAT translation table(s) AH> active when no user data is being transferred. AH> The receiver of such an empty ESPUDP packet MUST silently AH> ignore the packet. AH> Such empty ESPUDP packets SHOULD NOT force the link to stay AH> up, and they SHOULD NOT be counted as user traffic. (They are AH> also not a candidate mechanism for IKE/IPsec heartbeats.) AH> A peer MAY also choose to send an empty UDP packet using AH> the IKE port numbers. This packet is an illegal IKE packet AH> and will be discarded by the recipient. No sane IKE implementation AH> will terminate a connection due to this, since such packets AH> are so easy to forge. The reason for this would be to keep AH> the NAT translation tables for IKE messages active. AH> 6. Address Translation Options AH> Since separate addressing spaces are being used, addresses must AH> be translated by someone. ESPUDP ignores the address translations AH> that occur along its route, and thus either of the endpoints AH> must do this. AH> In ESPUDP tunnel mode, either of the following MUST be done: AH> a) The initiator MUST obtain an IP address from the peer, and AH> use this IP address in all tunneled packets being sent. AH> b) The responder MUST do NAT translation on incoming packets. AH> In ESPUDP transport mode, the initiator MUST correct the cheksums AH> in the packets being received through NAT. Their checksums will AH> be incorrect, since NAT has changed the IP address. Similarly AH> the responder MUST correct the checksums. The responder MUST also AH> do NAT translation, so that two clients using the same source port AH> do not clash. AH> 7. Deployment Considerations AH> 7.1 Client <-> Gateway AH> +----+ \ / +----+ +----+ AH> | |-------------|----------------| |----------| | AH> +----+ / \ +----+ +----+ AH> Alice's NAT GW Suzy's AH> Laptop Server AH> ESPUDP (tunnel mode) AH> ================================ AH> The effect of ESPUDP is to allow the protected packets to pass AH> through the tunnel. However, the contained IP addresses are not AH> affected. AH> Since Alice's laptop may have any IP address in its current residing AH> network, there must be some method of converting that IP address AH> to be usable in Suzy's network. AH> Two methods exist: AH> a) The GW can assign Alice's laptop an intranet address using some AH> mechanism like DHCP or ConfigMode. AH> b) The GW can internally assign Alice's laptop an intranet address AH> and do NAT translation as the packets pass through the GW. AH> Payload protocols carrying IP addresses, like FTP, continue to work AH> because the NAT translation for those is done either at Alice's AH> laptop AH> (method a) or at the GW (method b). AH> 7.2 Client <-> Client AH> +----+ \ / +----+ AH> | |-------------|--------------------| | AH> +----+ / \ +----+ AH> Alice's NAT Suzy's AH> Laptop Server AH> ESPUDP (tunnel/ AH> transport mode) AH> ==================================== AH> Transport mode ESPUDP requires that both Alice's laptop and Suzy's AH> server contain functionality to correct checksums that are AH> invalidated AH> by the source IP address being changed. Suzy's server must also do AH> NAT to allow several clients using the same UDP source port to AH> connect. AH> For this reason, ESPUDP in transport mode is not recommended when AH> NAT traversal is required. AH> The recommended choice is to use tunnel mode ESP over UDP AH> in this situation. Similarly to the Client<->GW case, the contained AH> protocols like FTP continue to work. AH> 7.3 Gateway <-> Gateway AH> +----+ +----+ \ / +----+ AH> +----+ AH> | |------| |-------|----------------| |----------| AH> | AH> +----+ +----+ / \ +----+ AH> +----+ AH> Alice's GW NAT GW AH> Suzy's AH> Laptop AH> Server AH> ESPUDP (tunnel mode) AH> ============================ AH> The GW<->GW case is similar to the Client<->GW case; ESPUDP allows AH> the connection to pass NAT, but a method to convert Alice's laptop's AH> address to be suitable in Suzy's network is necessary. The only AH> viable AH> option is to do NAT at either of the GWs, since no address assignment AH> protocol is defined to work between GWs. AH> Contained protocols like FTP continue to work because NAT can be AH> performed on unencrypted packets. AH> 7.4 Client <-> Gateway with End-to-end encryption AH> +----+ \ / +----+ +----+ AH> | |-------------|----------------| |----------| | AH> +----+ / \ +----+ +----+ AH> Alice's NAT GW Suzy's AH> Laptop Server AH> ESPUDP (tunnel mode) AH> ================================ AH> ESP (transport mode) AH> ================================================ AH> One way to make this work is for the GW to provide Alice's laptop AH> a suitable address, so that the GW need not do any NAT to AH> the contained packets. AH> 7.5 L2TP over ESPUDP AH> This section has not been written/studied yet. What will it require AH> to be able to do FTP through all these protocol layers? Volunteers? AH> 8. Security Considerations AH> On some systems ESPUDP may have DoS attack consequences, AH> especially if ordinary operating system UDP-functionality is AH> being used. It may be recommended not to open an ordinary UDP-port AH> for this. AH> Implementors are warned that it is possible for remote peers to AH> negotiate entries that overlap in the GW. AH> +----+ \ / AH> | |-------------|----\ AH> +----+ / \ \ AH> Alice's NAT 1 \ AH> Laptop \ AH> 10.1.2.3 \ AH> +----+ \ / \ +----+ +----+ AH> | |-------------|----------+------| |----------| | AH> +----+ / \ +----+ +----+ AH> Bob's NAT 2 GW Suzy's AH> Laptop Server AH> 10.1.2.3 AH> Because GW will now see two possible SAs that lead to 10.1.2.3, it AH> can become confused where to send packets coming from Suzy's server. AH> Implementations MUST devise ways of preventing such a thing from AH> occurring; either by disallowing such connections or by other means. AH> It is not possible for a hacker to obtain an arbitrary address in the AH> intranet being protected by the GW. If address assignment by the GW AH> is provided, only the address assigned to the hacker is allowed to AH> pass AH> through the GW. In the other case, address is always assigned to AH> the hacker internally by the GW and the (arbitrary) IP address of the AH> hacker is always translated by a NAT functionality in the GW. AH> Acknowledgements AH> Tamir Zegman of CheckPoint, and William Dixon of Microsoft have AH> provided helpful advice for producing this draft. AH> References AH> [RFC 1918] Address Allocation for Private Internets AH> [RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address AH> Translator (NAT) Terminology and Considerations", RFC AH> 2663, August 1999. AH> [ABOBA] Aboba, B., "NAT and IPSEC", Internet draft (work AH> in progress), draft-aboba-nat-ipsec-02.txt, July 2000 AH> [STENBERG] Stenberg, M. et. al. IPsec NAT-Traversal, Internet draft AH> (work in progress), AH> draft-stenberg-ipsec-nat-traversal-00.txt, AH> July 2000
- draft-huttunen-ipsec-esp-in-udp-00.txt Ari Huttunen
- Re: draft-huttunen-ipsec-esp-in-udp-00.txt Jim Tiller