[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UDP encapsulation of IKE for NAT traversal
As a newbie to this list I would beg for apologies in advance if this
question has been addressed before (I did see a flurry of activity from
October of 2000 under the subject "NAT and IPsec" although the issue below
was not directly addressed). And please, no screaming flames if this
question is answered in one of the RFCs or drafts (although we've read
through most of the relevant documents).
In implementing NAPT awareness in our IPSec product we have encountered a
scenario where it would seem that tunneling of the IKE packets between the
peers is necessary if NAT is being used. Consider the following
configuration:
------- ------- --------
------- | | | | | | ------
| | | | | | -------- | | | |
| Host |C |IPSec |C | |A | | S| IPSec | S| Host |
|Client |----|encryp-|----| NAT |-----|Internet|-----| encryp-|---| Web |
| | |tor | | | | | | tor | | Svr |
| | | | | | | | | | | |
------- | | | | | | | | ------
| | | | | | | |
| | | | -------- | |
------- ------- --------
Assume that there is a security policy known to encryptors C and S allowing
ESP tunnel mode traffic between C and S.
Assume that the private IP address C *behind* the NAT is translated to
public IP address A.
Assume following convention for TCP_UDP/IP packet headers: source and
destination addresses and ports are written as:
src_addr, dest_addr: src_port, dest_port
e.g. 1.2.3.4,5.6.7.8:1000,2000
The client (IP address C) wishes to open a session with the web server (IP
address S) and sends an IP packet to S as C,S:Pc,80.
The IPSec encryptor C detects that there is no SA for the address pair C and
S and begins the IKE process by issuing an IKE packet to S. The IKE has IP
header C,S:500,500.
The NAT translates the source address and source port of the IKE packet as
A,S:Pa,500.
As a result of the subsequent IKE exchange encryptor C has a SA between C
and S, and encryptor S has a SA between A and S (and not C and S). This
assumes of course that IP address A was present in the policy database of
encryptor S.
Herein lies our confusion. Once the IPSec SA is setup between C and S, a
HTTP/TCP/IP packet from the web server destined for the client (i.e.
S,C:80,Pc) will result in encryptor S not being able to find a SA, since the
SA that was established was between A and S.
One solution that we are considering is that the IKE/UDP/IP packet itself be
encapsulated in UDP so that the original IP addresses and ports are left
intact. Looking at draft-ietf-ipsec-nat-t-ike-01.txt it is not clear (at
least to us) whether this is the intention or not. Section 4.2 of the draft
states:
"In case of transport mode both ends SHOULD send the original source
address to the other end. For the tunnel mode both ends SHOULD NOT send
original source address to the other end."
We notice in draft-ietf-ipsec-udp-encaps-01.txt in section 5 headed "Usage
with Another Key Management Protocol" that the "...key management packet..."
is UDP encapsulated. Does this apply to the standard IKE as well? And does
the *key management packet* include the original IP/UDP headers?
Other solutions (and some of these are proprietary) are (i) that we use a
vendor specific payload in the IKE packet from C to S to inform S of the IP
address (as well as the Ethernet address) of C, (ii) that the policy
database that resides in S have an entry that relates IP addresses C and S
together with the NAT address A (a problem here is if the client C is using
DHCP to acquire its IP address - in this case, the policy cannot know the
private IP address behind the NAT), and (iii) that encryptor S brute force
the received NAT-D hash to try to determine which IP address and port in the
policy table initiated the IKE (again, useless for a DHCP host, and
problematic due to the possibility of hash collisions).
If the entire IKE packet is to be UDP encapsulated then should it *always*
tunnel the IKE, or only for those cases where NAT is detected? The
discussion from October of last year proposed that two IKE *probes*, regular
IKE and NAT-IKE, be sent and then a determination made on which to use based
on a response or non-response. However, in the above configuration the
transmission of regular IKE would result in a response being received fine,
albeit with the knowledge that NAT was present.
Any ideas?
Graham Welling
Cryptek Secure Communications
gwelling@cryptek.com