Subject: [IPsec] Negotiation of Transport Mode Behind NAT in IKEv2

From: Chinh Nguyen <[email-masked]>
Date: Wed, 12 Mar 2008 10:32:06 -0400

This question is related to Scott Moonen's question "Questions regarding 
NAT traversal in IKEv2" (dated 23/08/2007). I quote

 > I'll phrase my question in terms of the following configuration, with
 > a NAT in front of the initiator, and with the establishment of a
 > transport mode SA; other configurations are possible:

 >      [initiator@A]--[NAT@X]----------------[responder@Y]

 > The initiator's private address is A and its public address is X. 
The > responder's address is Y.  The above RFC text requires the initiator
 > to supply A for TSi and Y for TSr; this also makes perfect sense
 > knowing that the initiator's SPD uses address pair (A, Y), and the
 > that the initiator properly has no knowledge of X.

As asked by him and answered by draft 
draft-kukec-ikev2-tutorial-additions-02 (page 19) and specified by 
RFC46, the original IP (address A) in the TS should be used to do 
incremental checksum.

However, this incremental checksum can only be done by 1 side: the one 
that has both the original IP and the NAT IP. Furthermore, this is not 
sufficient if there are 2 NAT devices. This is why in the IKEv1 RFC 
3947, there are 2 NAT-OA payloads (NAT-OAi and NAT-OAr). So you really 
can't do incremental checksum with transport mode NAT in IKEv2. 
(However, you can always fall back on full checksumming.)

But the main gist of my question is that you can't negotiate transport 
mode with (A,Y) either. As Scott noted, Y sees packets from X, not A. So 
it seems to me that with a TS of (A, Y), Y will reject decrypted packets 
from X and bypass packets destined for X since they do not match (A, Y).

In fact, consider the possible TSi, TSr values of the following devices 
that are both behind NAT.

a -- X ----- Y -- b

The choices are TSi = [a, X, *], TSr = [b, Y, *]

[I]nitiator a             [R]esponder b
TSi = a -> R cannot use*  TSr = a -> R cannot use
TSi = X -> I cannot see   TSi = X -> I cannot use
TSi = * -> ok             TSi = * -> ok
TSr = b -> I cannot see   TSr = b -> I cannot use
TSr = Y -> R cannot use   TSr = Y -> R cannot use
TSr = * -> ok             TSr = * -> ok

* Because device does not use that address as source or does not use as 
destination.

In a nutshell, the use of private IP in TS means one side cannot use 
because it sends _to_ the NAT. The use of NAT IP in TS means one side 
cannot use because it sends _from_ the private IP.

Only a TSi/TSr = */* request and response generate the matching SP. But 
that would mean all packets to everywhere are encrypted, unless each 
side locally narrows the TS.

If someone has some insight about this, that would be great.

One solution I can think of is this:
Initiator a sends TSi = ((a), (*)), TSr = ((Y), (*)). Responder b sends 
back TSi = ((a), (X)), TSr = ((Y), (b)).

That is, a sends the 2 IPs as a sees them + an all selector.  Responder 
b echos back the 2 IPs and replaces the all with the 2 IPs that b sees.

The combination TSi = ((a), (X)), TSr = ((Y), (b)) matches packets that 
a sends (a, Y) and that b sends (X, b). The downside is that the other 3 
combinations are not used. (If the TS are converted to SP, then there 
are 8 SPs, 4 out 4 in, and 6 are not "used").

Note that if there are no NATs, then a requests TSi = ((a), (*)), TSr = 
((b), (*)) and b responds TSi = ((a), (a)), TSr = ((b), (b)) (or more 
simply TSi = (a), TSr = (b)) which is as expected. This will also work 
if there is 1 NAT device.

As a bonus, the combination TSi = ((a), (X)), TSr = ((Y), (b)) means 
that both sides have access to both "NAT-OAi" and "NAT-OAr" and can do 
incremental checksum.

Chinh
--
http://www.certicom.com
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec