[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-huttunen-ipsec-esp-in-udp-00.txt
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
References: