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