[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UDP encapsulation of IKE for NAT traversal



<snip>

 > 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:

It is not.

 > "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."

This means that the source addresses are sent in the NAT-OA payload, not
that the IKE traffic would be encapsulated.

Quote (from the same section):
,----
| The original source address of packets put to this transport mode IPsec
| SA is sent to other end using NAT-OA (NAT Original Address) payload.
`----

 > 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?

IKE isn't encapsulated. The current UDP encapsulation is defined so that it
will seem like an invalid IKE packet.

 > 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).

The IPsec host behind NAT doesn't need to know much (only that it wants to
negotiate using the UDP-tunnel mode instead of normal tunnel if the
detection sequence fails).

The responding host who gets traffic from clients behind NATs has to do
either of the following:

  - in network with unique addresses, one can just use the QM IDs as
addresses to use (Note: This can be also done with say, DHCP-over-IPsec to
GET unique address and then use it in tunnel mode to communicate with the responder)

  - in network where clients addresses behind NAT may overlap, there's need
for NAT action in the responder.

The point being, when the initiator negotiates IPsec SA, the 'remote
identity' handled by responder is done so that when the packet comes in it
is translated to addressable form (if need be), and when packets are sent
out they're translated to addressable form (if need be) and then sent forward.

How this is done is an implementation issue, and I think it was addressed
bit more in my earlier drafts on topic (but, I'm not sure if they should be
in the draft anyway).

 > Any ideas?
 > 
 > Graham Welling
 > Cryptek Secure Communications
 > gwelling@cryptek.com

-Markus

--
Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)
Chief Engineer / SSH 囲碁先生