Internet DRAFT - draft-huttunen-ipsec-esp-in-udp
draft-huttunen-ipsec-esp-in-udp
INTERNET-DRAFT A. Huttunen, J. Sierwald
Expires September 2001 F-Secure Corporation
Category: Informational W. Dixon, B. Swander
Microsoft
V. Volpe
Cisco Systems
L. DiBurro
Nortel Networks
March 2001
IPsec ESP Encapsulation in UDP for NAT Traversal
<draft-huttunen-ipsec-esp-in-udp-01.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 September 2001
1. Abstract
NAT is widely used for Internet "connection sharing" and ships as a standard
feature in every router and edge device. Cable and DSL deployments have been
known to install NAT in embedded devices resident inside the home. Additionally
most hotel Internet connections are using NAT. Many airport & wireless services
in public areas use NAT to connect to the Internet. Some Internet Service
Providers use a centralized NAT to connect their clients to the Internet.
Without a solution to the problem, the L2TP/IPSec VPN client and an IPSec tunnel
mode VPN client can not connect from home or from business sites which use NAT to
connect to the Internet. Likewise, transport TCP and UPD traffic that is
protected by IPSec transport mode can not be exchanged between peer to peer or
server-to-server applications.
Without an IETF standard solution for IPSec over NAT, vendor products will not
interoperate, and will be forced to support multiple methods.
This proposal allows ESP to pass through NAT if the NAT allows UDP traffic. It
does not require the NAT to be aware of IPSec and IKE negotiation. The technique
is used only if the initiator and the responder support it. And it is only used
when necessary, because the initiator imbeds information that tells the responder
how the packet addressing was formatted when it was originally sent.
This technique allows L2TP protected by IPSec transport mode using the most
popular and default encryption format (IPSec ESP) to go through existing NATs
which do either port and address translation of UDP packets or pure-address
translation.
It also allows IPSec tunnel mode to go through the same type of NATs, a
requirement for many in the industry which implement IKECFG, XAUTH extensions to
IPSec tunnel mode for remote access. Address assignment can also use the standards
track DHCP over IPSec method.
Note however that when IPSec tunneling through a NAT between an end system
(static internal & external IP) and a gateway, or between two gateways - the
internal addresses used by packets inside the IPSec tunnel can not be changed,
even though the external address is changed so the internal packet will retain a
potentially invalid address on the destination network. To handle this case, we
can do one of the following:
- In the gateway-to-gateway case, perform a second NAT function either before the
tunnel ingress or after the tunnel egress to handle address space transitions.
-In the case where traffic inside the tunnel is clear text TCP & UDP
traffic, this is normal NAT and not affected by the IPSec tunnel (through
which that traffic passed) being NATed itself.
-In the case where traffic inside the IPSec tunnel is IPSec transport
traffic, this spec provides the mechanism for the IPSec transport peers to
detect this second NAT and pass it accordingly.
- Not use the RFC method of negotiating an IPSec tunnel, instead use address
assignment inside IKE (with or without IKECFG/XAUTH) for end-system to gateway
IPSec tunnels.
- Keep the internal address as is, and configure the destination network to be
able to handle it.
This method should be able to be used in all scales where NAT is deployed today to
do simple pure address-to-address, or address and port translation. However, it
will not be able to be used where the NAT would otherwise perform packet
inspection and replacement of address or port information inside the packet (e.g.
modifying the FTP PORT command packet). Thus UDP encapsulated IPSec transport and
tunnel traffic will be successful if the communications model is that the client
initiates TCP connections & UDP sessions from itself out through the NAT.
This protocol does not involve the client communicating directly with the NAT for
the purpose of opening ports to receive inbound connections. If required, another
method such as RSIP may be used by the application first to communicate with the
NAT.
IKE & IPSec issues with NAT are documented in this draft
(http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt ) [2]. This
proposal provides a solution to all issues identified when using IKE Identity
Protect Mode (Main Mode), Aggressive Mode or Quick Mode. Other extensions such as
ISAKMP Config Mode (IKECFG) and XAUTH may be present. Address assignment can also
use the standards track DHCP over IPSec method.
Most importantly, this proposal does not require change to the NAT device itself,
which is seen as practically too difficult, and presents a problem on the order of
magnitude similar to deployment of IPv6 where all end-systems, and at least 1
intermediate point (the NAT) must change. We expect the technique described here
to be used in the interim to pass IPv4 addressed traffic only and will become, one
hopes, outdated as IPv6 is deployed, enabling true end-to-end secure IPSec
communication without address translation.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and server
respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 [1].
3. Design Overview and Rationale
The IETF standard for NAT traversal by IPSec should be unencumbered from
intellectual property claims to ensure rapid adoption by the IPSec vendor
community.
We propose to UDP encapsulate the ESP traffic, thereby allowing it through the
NAT.
During design several different criteria needed to be balanced
-Encapsulation using UDP port 500 was chosen so as to enable easy deployment
without the need to change firewall rules used by corporations.
-The chosen method allows only ESP traffic to be encapsulated in UDP. This
ensures that the most widely needed traffic protection method is supported,
while ensuring that the method is as simple as possible, mainly in terms of
implementation effort.
-Encapsulation using UDP port 500 makes each packet 8 bytes larger than
encapsulation using a different port, this is however balanced by the reduced
need to have keepalive packets.
-UDP encapsulation can break some of the current HW offload products.
3.1 NAT Scenarios
All below scenarios may support an IPSec transport/tunnel SA for all possible
traffic, where 1 or more TCP or UDP sessions may be protected by the single IPSec
transport/tunnel SA pair. There may be multiple transport/tunnel SAs of finer
granularity as well.
A. One or more clients behind a NAT connecting simultaneously to a destination IP
Client1 private IP <-> NAT Internet IP <---------> Internet IP Server
Client2 private IP <->
NAT is doing pure address translation 1:1, or doing address and port translation
many:1
B. One or more clients behind NAT1 connecting simultaneously to the same dest IP
address which is behind NAT2
client1 private IP <-> NAT1 Internet IP <-> Internet IP NAT2 <-> private IP
server
Client2 private IP <->
NAT1 is performing many:1 port address translation, NAT2 is performing 1:1 address
translation (into DMZ)
C. One or more clients through 2 or more outbound NATs to destination Internet IP
address
Client1 private IP <-> NAT1 private IP <-> NAT2 Internet IP <-> Internet IP
Server
Client2 private IP <->
NAT1, NAT2 are performing many:1 port address translation.
D. Internet client connecting to server behind NAT.
Client1 Internet IP <------------> Internet IP NAT <--> private IP Server1
<--> private IP Server2
NAT would most likely be doing 1:1 address translation.
E. Multiple clients identifically configured (i.e. Client1 and Client2 have the
same private network IP address assigned to them, like 10.1.2.3), each behind
their own NAT, connected to same Internet IP.
Client1 private IP <-> NAT1 Internet IP <-> Internet IP Server
Client2 private IP <-> NAT2 Internet IP <->
F. One or more clients inside a GW, comprising a remote worker's home LAN,
connecting to the corporation's LAN protected by the corporation GW. Both home LAN
and corporation LAN are using IP addresses from the same private address pool.
Client1 private IP (corp) <-> GW private IP (isp) <-> NAT1 Internet IP <-> GW <->
private IP (corp) <-> server
F1. an IPSec tunnel SA for all traffic, where 1 or more TCP or UDP sessions may be
protected by the single IPSec tunnel SA pair, between the two GWs.
3.2 Encapsulation Scheme and Keeping NAT mappings alive
We SHOULD provide a solution to keep alive the NAT port flow mapping - otherwise
rekey from the responder will fail - same issue for stateful FWs opening a hole
for corresponding inbound ports when it sees outbound src & dst port. See a
section below for the specifics on constructing and using a NAT keepalive packet.
This draft uses the well-known IKE UDP port 500 to encapsulate both IKE control
traffic and ESP data traffic. To distinguish these from one another, ESP traffic
contains 8 bytes of zero after the UDP header. Normal IKE packets would contain
the initiator cookie in this field which is never = 0.
ESP inside UDP encapsulation
------------------------------------------------------------
IPv4 |orig IP hdr | UDP | 8 bytes 0 |ESP | Data |
|(any options)| Hdr | |Header | |
------------------------------------------------------------
|<- encrypted->|
|<- authenticated -------->|
IKE control inside UDP encapsulation
----------------------------------------------------------
IPv4 |orig IP hdr | UDP | Initiator | Responder|Rest of IKE |
|(any options)| Hdr | Cookie | Cookie |Header Fields|
----------------------------------------------------------
Initiator cookies is 8 bytes, but non zero. Responder cookie is 8 bytes and may
be zero. Implementations must be resilient to modification of this 8 byte 0
field, making it non-zero and thus get received by IKE where it would attempt to
parse invalid data.
This approach allows for:
1. a single well known port over which ESP UDP encapsulation would be done. The
IKE port is already assigned, and well-known for IPSec so firewalls needn't
change, too.
2. minimization of keep-alive/heartbeats for both IKE & ESP - as long as there was
traffic flowing middle devices like stateful FWs & NATs would keep the mapping
alive
3. maintenance of alignment boundaries.
MTU reductions must be adjusted appropriated to account for 8 bytes + UDP header
for ESP payloads.
This approach doesn't support AH.
4. Implementation Details
4.1 IKE Main Mode exchange
IKE MM initiator SA payload
- Sends from IKE Src S, Dest 500. S is usually 500. This is not required, and
the initiator may choose to float its source port.
- Sends a VendorId payload of MD5("ESPThruNAT")
IKE MM responder SA payload
- Receive on UDP port 500. It may also be the case that implementations support
receiving on a non-500 destination port. We say this is a well-known-to-the-
client destination port in this case.
- If Vendor ID payload for ESPThruNAT present UDP encapsulation capability is
supported, the responder MUST construct and send the NAT Discovery payload of
MD5(Initiator IP addr, I port, Responder IP addr, R port). The IP addresses
and ports must be in network byte-order before calculating the hash.
- The port value 0 MUST NOT be used in the hash. If the internal representation
of the port is 0, 500 must be used for generating this hash.
- If the Initiator source port is not 500, store it for future use. In
scenarios A, B, and C, the source port is not likely to be 500.
- Reply back to initiator's source port
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ NAT Discovery ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: NAT Discovery Payload Format
The NAT Discovery Payload fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last
in the message, then this field will be 0.
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header.
. NAT Discovery data (16 octets) - MD5 Hash = MD5(initiator IKE IP address,
initiator IKE port, responder IKE IP address, responder IKE port). For an IKE
packet constructed by the initiator:
o The initiator IP address is the source address of the packet. 4 octets
for V4 address, in network order. 16 octets for V6 address, in network
byte-order.
o The initiator port is the source port of the packet. 2 octets, network
byte-order.
o The responder IP address is the destination address of the packet. 4
octets for V4 address, in network order. 16 octets for V6 address, in
network byte-order.
o The responder port is the destination port of the packet. 2 octets,
network byte-order.
The payload type for the NAT Discovery Payload is one hundred thirty (130).
IKE MM Initiator KE payload
Upon receiving NAT Discovery payload, compute the equivalent MD5 hash locally and
compare with the received MD5 hash. If they differ, NAT is present. Send Vendor
Id payload of MD5("ESPThruNAT") and the locally generated NAT Discovery payload to
responder, so responder knows also whether NAT exists. If UDP encapsulation is
supported, the NAT Discovery payload MUST be sent.
IKE_MM_ID payload
If NAT Discovery payloads have determined that NAT is present, then IP addresses
SHOULD NOT be sent in the ID payload. Since the NAT may be changing the IP
addresses, sending an IP address that is incorrect as your ID is not recommended.
It is up to each peer's policy how to handle this scenario. The recommended
approach is to send fully qualified DNS name (FQDN) or some other sort of name-
based identity, such as the DN of the subject name in the certificate when using
RSA signature authentication. Since reverse DNS lookups may fail, it is again up
to local policy if/how to verify this identity. If a peer can determine that its
address is not going to be translated, i.e. the address is a 'real' address, then
this valid IP address can be sent as the MM Id.
4.2 Aggressive Mode
The rules for constructing the VID and the NAT Discovery Payload are the same as
for Main Mode.
In addition to normal aggressive mode:
IKE AM Initiator
- Send Vendor ID for ESPThruNAT
IKE_AM_Responder
- If Nat traversal is supported, the responder MUST send the Vendor ID for
ESPThruNAT and the Nat Discovery payload as defined above.
IKE AM Initiator 3rd message
- Send Nat Discovery payload.
Since Aggressive Mode sends the initiator's identity in the first payload, before
NAT Discovery Payloads are exchanged, the initiator cannot select a different
identity based on the result. If IP address based identity is used by the
initiator and NAT is detected to exist, a warning SHOULD be issued.
The Aggressive Mode negotiation MUST NOT be aborted for this reason, however.
4.3 Identity Protect Mode Phase 2 (Quick Mode)
IKE QM Initiator
If policy allows UDP encapsulation, construct a proposal to negotiate UDP
encapsulation. This will be encoded as the encapsulation attribute. Two new
values will be added, UDP-TRANSPORT (61441), and UDP-TUNNEL (61440). Any non-UDP
encapsulated offers MAY be rejected by the peer, depending on policy.
Initiator Proxy ID. The recommended proxy id is hostname FQDN in place of the
source address (scenario A, C) and destination address (scenario B, D) for
transport mode, with the same recommendations as the MM IDs. IP address MAY be
used as a proxy ID if that IP address is a 'real' address. For tunnel mode, this
ID can be the private address or net being protected.
Initiator
SA, ProxyID initiator, ProxyID Responder ----------->
[src addr, src port] [dest addr, dest port]
IKE_QM_Responder
- Receives offers, rejects all that are not NAT Encapsulated based on policy
- Local policy decision how to verify the proxy IDs. In transport mode, easiest
is to ignore it, and simply use the Main Mode address.
4.4 IPSec formats
This encapsulation method has the benefit of no additional IKE complexity, and NAT
keep alives are aggregated. However, the expense is an extra 8 bytes in the
header for each data packet.
IKE tells IPSec:
- inbound SA = ESPUDP protocol - normal ESP parameters
- outbound SA = ESPUDP protocol - normal ESP parameters
- which ports to use. In scenarios A & C, initiator machine inside NAT will use
src port S, dst port 500; Machine outside of NAT will use src port 500, dest
port NAT mapped port. S is usually 500, but may be floated.
IPSec formats IPSec packets as:
ESP inside UDP encapsulation
------------------------------------------------------------
IPv4 |orig IP hdr | UDP | 8 bytes 0 | ESP |Data |
|(any options)| Hdr | | Header | |
------------------------------------------------------------
|<- encrypted->|
|<--authenticated -------->|
IKE control inside UDP encapsulation
----------------------------------------------------------
IPv4 |orig IP hdr | UDP | Initiator | Responder|Rest of IKE |
|(any options)| Hdr | Cookie | Cookie |Header Fields|
----------------------------------------------------------
ESP over NAT packet format receiving:
- IPSec aware of new format inspects initiator cookie 8 bytes field -
decrypts if dword= 0.
- IPSec inspects initiator cookie - passes up UDP packet with initiator cookie set
<> 0
- Otherwise, IPSec strips UDP header, verifies that the UDP ports are the expected
values, and processes the ESP payload
ESP over NAT packet format outbound:
- IPSec transforms original packet into ESP
- IPSec takes constructs UDP encapsulation header with ports received from IKE, and
the rest of the ESP as usual.
As an example:
C <-> NAT <-> X
C sends srcport=500, dstport=500 (src 500,dst 500)
NAT modifies to (1000,500). X replies with (500,1000). NAT modifies to (500,500).
C gets (500,500). This is the same for both IKE and IPSec traffic.
Now if C is sending from a different source port than 500:
C sends (1111,500). NAT modifies to (2222,500). X replies to (500,2222). NAT
modifies to (500,1111). C gets (500,1111).
Since C's IPSec driver is going to need to determine this is an encapsulated
packet, it will need to know to look at dest port 1111 for all packets. Thus,
the IPSec subsystem MAY listen on well-known ports other than 500 for IPSec
traffic if mutually agreed upon by the peers.
4.3 NAT Keepalives
The keepalives will be sent by the Phase I initiator. The purpose of the
keepalives is only to keep up the NAT mapping, and not to keep alive any IKE or
IPSec or other state. Thus, the keepalive format is simply a UDP packet with the
correct source and destination ports and addresses. The packet contains a single
data octet of 0xff. This packet is sent as often as the initiator deems
necessary, and SHOULD be silently discarded by the receiving IPSec driver. The
keep alives SHOULD only be sent if traffic (either IKE of IPSec) is not already
present in the desired interval. In addition, in order to allow the peer outside
the NAT to initiate a rekey after the Main Mode has been torn down, the keep
alives SHOULD be continued for some configurable period after all MMs and QMs are
torn down. The default time for the extra keep alives SHOULD be 5 minutes. The
packet SHOULD be silently discarded. Since the NAT can fix-up the checksum of
this packet and this packet has no IPSec hashing to verify integrity, checksum
computation SHOULD be enabled for the keep alive packets.
NAT keepalive packet
----------------------------
IPv4 |orig IP hdr | UDP | 0xFF |
|(any options)| Hdr | |
----------------------------
See also ref [3].
5. IPSec over NAT Operation
A: 10.1.1.1 10.1.1.11 NAT 172.1.1.1 X: 172.0.0.2
B: 10.1.1.2
We have machines A,B in the private address space, talking to the external machine
on the internet X. A initiates a MM to X. A sends the IKE packet with src IP =
10.1.1.1, dst IP= 172.0.0.2, src port = 500, dst port = 500. This packet hits the
NAT, which translates it to src IP = 172.1.1.1, src port = 6666. X gets the
packet, and remembers that it came from src port 6666, and sends IKE reply to src
IP 172.0.0.2, dst IP 172.1.1.1, src port 500, dst port 6666. The NAT will
translate this to 10.1.1.1, dst port 500, and send to A. The MM exchange
continues. At the end, A has a MM [10.1.1.1 (host FQDN),172.0.0.2, src 500, dst
500], and X has the MM [172.0.0.2, 172.1.1.1 (host FQDN), src 500, dst 6666]. If
we are doing preshared key authentication in MM, then machine A would send the
xxxxx as its IKE ID payload.
Now, for QM, A proposes the QM proxy IDs as [src host FQDN, dst host FQDN, proto,
src port, dest port] = [proxy source, proxy destination, protocol, src & dest
ports], and transform ID ESPNAT in the SA payload. The QM succeeds when source
port is ignored. When A plumbs the QM SAs into the driver (and possibly filters
to match it), it uses its real addresses.
Client A's QMs in driver:
A->X: [10.1.1.1,172.0.0.2, proto, src port, dst port]; UDP src 500, dst 500
X->A: [172.0.0.2,10.1.1.1, proto, src port, dst port]; UDP src *, dst 500
Gateway X's QMs in driver:
A->X: [172.1.1.1,172.0.0.2, proto, src port, dst port]; UDP src 6666, dst 500
X->A: [172.0.0.2,172.1.1.1, proto, src port, dst port]; UDP src 500, dst 6666
Now, the data packet is sent on A to 172.0.0.2. It matches the drivers outbound
filter, its outbound SA, and the driver encrypts it. It is sent out with IP src
10.1.1.1, dst 172.0.0.2, UDP src 500, dst 500. It hits the NAT, and the NAT
translates the src address, and source portcreates an entry for the SPI. When
the reply comes back from X, the NAT maps the SPI from X with the SPI send from A.
Now the NAT knows which internal host to send the packet to, and A gets it.
Multiple private network clients
Now B wants to connect to X. When B sends to X, the NAT will translate to
172.1.1.1, src port 7777. Thus, the NAT will be able to correctly multiplex X's
response. X will end up with 2 main modes, 1 to A and 1 to B.
To A: [172.0.0.2, 172.1.1.1, src 500, dst 6666]
To B: [172.0.0.2, 172.1.1.1, src 500, dst 7777]
Multiple private clients are handled by having the external machine add the
local/peer IKE ports to its SA key.
IKE Rekey
If the gateway X initiates a MM or QM rekey, it must do so from the same src (500)
to the same destination (6666). The NAT will have maintained the mapping
(assuming keep-alive scheme is present either in IKE or in layers above IPSec).
If the client A initiates a MM rekey, we just begin the above process over again.
TCP, UDP checksum in IPSec transport
We need to handle the tcp and udp checksum when IPSec ESP transport is used. The
IPSeced packet will look like (from RFC 2406):
AFTER APPLYING ESP
---------------------------------------------------------------
IPv4 |orig IP hdr |UDP |8 bytes | ESP | | | ESP | ESP|
|(any options)|Hdr | 0 | Hdr | TCP | Data | Trailer |Auth|
---------------------------------------------------------------
|<----- encrypted --------->|
|<-- authenticated -------------->|
Notice that none of the IP header is protected, so the NAT is free to modify the
addresses. When the NAT modifies the address in the IP header, it can recalculate
the IP checksum, which is also unprotected. However, in the TCP (or UDP) portion,
is the TCP (or UDP) header, which contains its own checksum. This checksum is
over the pseudoheader, which contains the src and dst addresses in the IP header.
Thus, if the NAT changes an address in the IP header, it cannot recomputed the TCP
(or UDP) checksum since that portion of the packet is encrypted.
There are 2 ways around this problem. One is disabling checksum checking on both
peers for packets on the SAs in question. The other option is to compute the TCP
(or UDP) checksum correctly before sending the packet, or after receiving the
packet. If done before sending the packet, it would require that the client know
its external address, which is not an assumption in this specification. If done
after decrypting the IPSec packet, but would be unnecessary CPU cycles if the
stack accepted the value of zero for checksum or using some other implementation
specific method. So the choice for performance reasons is to disable UDP & TCP
checksum by the stack when possible.
Disabling host OS UDP & TCP checksums loses very little functionality since nearly
the entire packet is protected by the hash from the ESP. This hash will verify
the integrity in transit of all fields protected by the TCP (or UDP) checksums
except for those fields in the pseudoheader. Of these fields (src, dst ip
address, protocol, length) src and dst address are generally the most important,
and verification of them is insured by possession of the session keys for the
IPSec session. For large TCP segments that result in multiple IP packets (initial
plus IP fragments), the TCP segment can only be reconstituted using individually
properly reassembled and authenticated IPSec packet. So there is no value in re-
checking TCP checksum.
Therefore, TCP checksum MUST not be checked when the packet arrives secured by a
SA using NAT encapsulation. UDP packets SHOULD have their xsum field set to 0 on
sending into an SA using NAT encapsulation. UDP check sums MUST not be checked on
receiving a packet in an SA using NAT encapsulation.
6. Justification of design
Other methods were carefully considered, and discarded.
6.1 Floated IKE port
First, there is the option of floating IKE to a different well-known port during
the negotiation, and the using this new port number as a demultiplexer. This
would allow the encapsulated packet format to be:
ESP inside UDP floated port encapsulation
--------------------------------------------------
IPv4 |orig IP hdr | UDP |Type | ESP | Data |
|(any options)| Hdr | | Hdr | |
--------------------------------------------------
|<-- encrypted->|
|<-- authenticated --------->|
The IKE format on the floated port is:
IKE control inside UDP encapsulation
----------------------------------------------------------------
IPv4 |orig IP hdr | UDP | Type |Initiator | Responder|Rest of IKE |
|(any options)| Hdr | |Cookie | Cookie |Header Fields|
----------------------------------------------------------------
This would allow the 4 octet type field to give the type of the data following.
We can modify these formats in this way because the floated port distinguished
between the normal IKE format on port 500, and this format on the new port.
This method was discarded because it is very difficult to float IKE to a new port.
The biggest difficulty is resolving the conflict between floating the port,
preferably before any quick modes are negotiated, yet negotiating in quick mode
the encapsulation attribute. Thus, we'd have to always float IKE to a new port if
NAT were detected, even if that NAT is known to be IPSec aware, and that UDP
encapsulation, and therefore IKE floating is unneeded. However, even though IKE
would need to be floated always, actual ESP traffic could be either encapsulated
in UDP or not, as defined by policy and as negotiated by QM.
In addition, firewalls will need to open another UDP hole, which will meet with
strong opposition.
6.2 Using two UDP ports
This approach left IKE on 500, and encapsulates the IPSec traffic using a
different well-known port. The biggest problem with this is that 2 sets of keep-
alives must be sent to keep the NAT mappings alive. This will be expensive for
the IKE mapping, since IKE traffic is usually infrequent. For wireless, this is
extremely expensive. The second problem is that the IPSec subsystem doesn't get
the encapsulation information (the ports) from IKE, but must create that state
upon receiving the first encapsulated packet. This is more prone to denial of
service. It is possible to fail the connection if the attacker grabs the first
encapsulated packet, and modifies the unprotected encapsulation header before the
receiving IPSec subsystem gets it. This would cause the receiving IPSec
subsystem to create state based upon an incorrect mapping, and traffic would fail.
The proposed approach is more immune to these first packet manipulations, since an
attacker who modified the ports in the UDP header of the initial IKE packet would
only cause multiple Main Modes state entries to be created on the responder, but
wouldn't necessarily scuttle the connection.
This method will also make firewalls open an additional UDP hole.
7. Security Considerations
The authors do not think this method exposes any security vulnerabilities into
otherwise sound IPSec implementation. However, the following issues need to be
addressed by implementers.
When using IPsec tunnel mode, clients connecting to the gateway may be using the
same IP address in the inner IP header. One scenario where this is likely to
happen is when the clients are using in the inner IP header their local private
network address, and they are in different private networks. The GW MUST ensure
that traffic destined towards the clients is sent only to the correct recipient.
When using IPsec tunnel mode, a client connecting to a gateway may be trying to
steal an IP address from the network protected by the gateway. The QM initiated
by the client MUST only be allowed by the gateway if:
- The QM IP address identities match the static policy defined at the gateway.
- The QM IP source address matches the address assigned to the client by the
gateway.
- The gateway is configured to do further NAT to the packets, ensuring that
whatever IP address the client is using, this cannot be used to steal local
network IP addresses.
Any of these ensures that attacker is not possible to steal local network IP
addresses.
8. References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
2 Aboba, B., "NAT and IPSEC", Internet draft (work in progress),
draft-aboba-nat-ipsec-02.txt, July 2000
3 Huitema, C., "Short term NAT requirements for UDP based peer-to-peer
applications", Internet draft (work in progress),
draft-huitema-natreq4udp-00.txt, February 2001
The following IETF WGs have work which has fed into this specification and could
be the one to pursue standardizing a solution:
NAT Working Group: http://www.ietf.org/html.charters/nat-charter.html
IPSec Working Group: http://www.ietf.org/html.charters/ipsec-charter.html
IPSec Remote Access Working Group: http://www.ietf.org/html.charters/ipsra-
charter.html
IKE & IPSec issues with NAT are documented in these drafts.
http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-04.txt
Lucent has published an information RFC to describe how IPSec tunnels can pass
through NATs.
http://www.ietf.org/rfc/rfc2709.txt
Lucent has documented the VPN Masquerade method of IPSec over NAT, where the NAT
is aware of IKE and ESP traffic specifically and takes steps to estimate how to
pass the traffic.
http://search.ietf.org/internet-drafts/draft-brustoloni-vma-00.txt
3Com and others have documented a method for IPSec traversal of NATs where the NAT
is changed to support communication with the IPSec peer:
http://search.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-04.txt
SSH Communications Security is known to have intellectual property on some parts
of their design documented in the link below. This design we believe avoids what
we guess is the intellectual property.
http://search.ietf.org/internet-drafts/draft-stenberg-ipsec-nat-traversal-01.txt
0. Acknowledgments
Tamir Zegman of CheckPoint provided helpful advice for producing the û00 version
of this draft.
Many people engaged in discussion which lead to this proposal. In particular,
engineers at Microsoft, Cisco Systems, Checkpoint, F-Secure, SSH Communications
Security, Inc.
1. Author's Addresses
Ari Huttunen
F-Secure Corporation
Phone: +358-9-2520 0700
E-Mail: Ari.Huttunen@F-Secure.com
Joern Sierwald
F-Secure Corporation
E-Mail: Joern@F-Secure.com
William Dixon, Brian Swander
Microsoft
One Microsoft Way, Redmond WA 98052
Phone: 425-703-8729
Email: wdixon@microsoft.com
Victor Volpe
Cisco Systems
Email: vvolpe@cisco.com
Larry DiBurro
Nortel Networks
Phone: 978-264-7171
ldiburro@nortelnetworks
