Main Archive Page > Month Archives  > ipsec archives

[Ipsec] Questions regarding NAT traversal in IKEv2

From: Scott C Moonen <smoonen_at_nospam>
Date: Fri Aug 24 2007 - 00:52:13 GMT
To: ipsec@ietf.org

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 (smoonen@us.ibm.com)
http://www.linkedin.com/in/smoonen

---

Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec