Subject: [Ipsec] Questions regarding NAT traversal in IKEv2

From: Scott C Moonen <[email-masked]>
Date: Thu, 23 Aug 2007 20:52:13 -0400

All, I have two questions related to the negotiation of NAT traversal in 
IKEv2.

Question 1:
Under RFC 3947, IKEv1 explicitly indicated the use of UDP encapsulation by 
defining two additional encapsulation modes, UDP-Encapsulated-Tunnel and 
UDP-Encapsulated-Transport.  In IKEv2 the encapsulation mode is agreed 
upon using notifications, and only a USE_TRANSPORT_MODE notification is 
defined.  There is no UDP encapsulation notification, so is it correct to 
say that in IKEv2 UDP encapsulation is purely inferred by the existence of 
a NAT (under the same conditions that IKE switches to use port 4500), with 
no explicit indications?  Can I assume that it is permissible to discard a 
UDP-encapsulated ESP packet if the peer has erroneously sent one when no 
NAT is detected?

Question 2:
RFC 4306 states:

      The original source and destination IP address required for the
      transport mode TCP and UDP packet checksum fixup (see [Hutt05])
      are obtained from the Traffic Selectors associated with the
      exchange.  In the case of NAT traversal, the Traffic Selectors
      MUST contain exactly one IP address, which is then used as the
      original IP address.

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 fact that the 
initiator properly has no knowledge of X.  The responder is therefore made 
aware that packets' original addresses are (A, Y).  (However it is clear 
that the responder will need special logic when it detects the existence 
of NATs to correlate these TS addresses with its own SPD, which has no 
knowledge of A and uses the address pair (X, Y).)

At this point there seems to be a contradiction in the RFC.  The above 
quoted text suggests that the responder should reply with X for TSi and Y 
for TSr.  However, this contradicts the indication in section 2.9 of the 
RFC that the TS payloads on reply must be a subset of the initiator's TS 
payloads.  Section 4.10 of RFC 4718 is even more explicit in indicating 
that the values of TSi and TSr on reply should either be identical to or a 
proper subset of the values supplied by the initiator.

Depending on which statement takes precedence, one of the following 
behaviors must be chosen:

The responder should transform the TSi address to X in its reply as 
suggested in the text quoted above.  The initiator will require 
special-case NAT traversal logic to recognize that these updated addresses 
are not a contravention of its SPD or its original proposal, and save 
these addresses for checksum fixup.
The responder should echo back the initiator's original TSi and TSr 
addresses as required by section 2.9 of RFC 4306 and section 4.10 of RFC 
4718.  The initiator has no knowledge of address pair (X, Y), and 
therefore it will be unable to update the checksum as described in the 
first option of section 3.1.2 of RFC 3948.  However, the remaining 
checksum solutions documented there are equally acceptable for this 
transport-mode tunnel provided that there is some other form of integrity 
checking (e.g., ESP authentication).

It is not clear to me which of these two options is correct, although for 
several reasons I have strong inclinations toward option #2.  There is of 
course a similar lack of guidance in this case for the use of ID payloads 
in IKEv1 NAT traversal; however, in the case of IKEv1 the ID payloads are 
not required for transport mode and the NAT-OA payloads are unambiguously 
described to be asymmetrical, so all problems are eliminated in many 
cases.  In the case of IKEv2 NAT traversal we are now overloading the TS 
payloads for dual purposes, thus creating my dilemma above.

Thanks in advance for your response!

Scott Moonen ([email-masked])
http://www.linkedin.com/in/smoonen

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Jeffrey Sun <[email-masked]>
Date: Fri, 24 Aug 2007 15:16:34 -0700

Scott & All,
  Please correct me if I misunderstood the question or if I've 
misinterpreted the RFCs.

1.  Regarding Question 1:
I agree with you that in IKEv2, the UDP encapsulation is inferred by 
(assuming both endpoints currently have the NAT-T feature on) the 
detection of a fronting NAT.  Furthermore, the negotiation of Transport 
Mode further implies the processing of the UDP in context.

In regards to the discarding of an UDP-encapsulated ESP packet when no 
NAT is detected, I'm of the opinion that the packet shouldn't be 
discarded, but I do think that this is an implementation specific 
situation.  However, if one does discard the ESP packet, as far as I 
know, there isn't a specific Notify Message you could send through the 
IKE_SA describing this issue and as a result, the traffic being 
transmitted will essentially be black-holed.  In general though, I 
haven't been able to see a situation in which UDP-encapsulated ESP 
packets would be sent when a NAT is not detected; furthermore, it does 
follow the tenet of being liberal in what one receives....Let me know if 
I've overlooked something.

2.  Regarding Question 2:
"At this point there seems to be a contradiction in the RFC."  I don't 
quite see the contradiction that you've pointed out.  My interpretation 
of the quote is aligned to what you described in Option 2.  The TSi 
Payload would contain the Original Address A. 

In the context of ESP Transport Mode SA with required UDP encapsulation, 
wouldn't the Initiator simply recompute the checksum field in the inner 
TCP/UDP header (following the ESP Header) or simply zero out the 
checksum if it's an inner UDP header (following the ESP Header)?  Note, 
the outer UDP header's checksum is ignored.

Hope this Helps,
 - Jeff

Scott C Moonen wrote:
>
> All, I have two questions related to the negotiation of NAT traversal 
> in IKEv2.
>
> Question 1:
> Under RFC 3947, IKEv1 explicitly indicated the use of UDP 
> encapsulation by defining two additional encapsulation modes, 
> UDP-Encapsulated-Tunnel and UDP-Encapsulated-Transport.  In IKEv2 the 
> encapsulation mode is agreed upon using notifications, and only a 
> USE_TRANSPORT_MODE notification is defined.  There is no UDP 
> encapsulation notification, so is it correct to say that in IKEv2 UDP 
> encapsulation is purely inferred by the existence of a NAT (under the 
> same conditions that IKE switches to use port 4500), with no explicit 
> indications?  Can I assume that it is permissible to discard a 
> UDP-encapsulated ESP packet if the peer has erroneously sent one when 
> no NAT is detected?
>
> Question 2:
> RFC 4306 states:
>
> 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:
>
> 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 
> fact that the initiator properly has no knowledge of X.  The responder 
> is therefore made aware that packets' original addresses are (A, Y). 
>  (However it is clear that the responder will need special logic when 
> it detects the existence of NATs to correlate these TS addresses with 
> its own SPD, which has no knowledge of A and uses the address pair (X, 
> Y).)
>
> quoted text suggests that the responder should reply with X for TSi 
> and Y for TSr.  However, this contradicts the indication in section 
> 2.9 of the RFC that the TS payloads on reply must be a subset of the 
> initiator's TS payloads.  Section 4.10 of RFC 4718 is even more 
> explicit in indicating that the values of TSi and TSr on reply should 
> either be identical to or a proper subset of the values supplied by 
> the initiator.
>
>    1. The responder should transform the TSi address to X in its reply
>       as suggested in the text quoted above.  The initiator will
>       require special-case NAT traversal logic to recognize that these
>       updated addresses are not a contravention of its SPD or its
>       original proposal, and save these addresses for checksum fixup.
>    2. The responder should echo back the initiator's original TSi and
>       TSr addresses as required by section 2.9 of RFC 4306 and section
>       4.10 of RFC 4718.  The initiator has no knowledge of address
>       pair (X, Y), and therefore it will be unable to update the
>       checksum as described in the first option of section 3.1.2 of
>       RFC 3948.  However, the remaining checksum solutions documented
>       there are equally acceptable for this transport-mode tunnel
>       provided that there is some other form of integrity checking
>       (e.g., ESP authentication).
>
>
> It is not clear to me which of these two options is correct, although 
> for several reasons I have strong inclinations toward option #2. 
>  There is of course a similar lack of guidance in this case for the 
> use of ID payloads in IKEv1 NAT traversal; however, in the case of 
> IKEv1 the ID payloads are not required for transport mode and the 
> NAT-OA payloads are unambiguously described to be asymmetrical, so all 
> problems are eliminated in many cases.  In the case of IKEv2 NAT 
> traversal we are now overloading the TS payloads for dual purposes, 
> thus creating my dilemma above.
>
> ------------------------------------------------------------------------
>