Subject: [Ipsec] Questions regarding NAT traversal in IKEv2

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Sep 2007 16:29:25 +0300

Scott C Moonen writes:
> 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.

Yes, and if no notification is given then tunnel mode is assumed. 

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

The notification decides whether it is tunnel or transport mode
encapsulation, and for that you add NAT-T UDP encpsulation processing
if you detect NAT between hosts. 

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

If you know how to process those packets, why would you discard them?
What benefit does that give? If you ever plan to support mobike
(rfc4555), there are cases there where you might receive packets that
have UDP encapsulation, even when you thing it should be off and vice
versa. 

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

No, the responder must reply with TSi set to A and TSr set to Y, as
that is the original IP addressed used, and that is the address used
in the narrowing. 

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

Yes, they always must be subset of the values supplied by inititor.
Anything else is considered security violation and will cause the
initiator to terminate the IKE SA (i.e. responder tried to attack the
inititor by asking wider range than initiator was willing to give, if
initiator would have allowed such wider range he would have proposed
it in the beginning). 

> 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 quoted text says original IP address. The original IP address for
the initiator is A. The responder will know it is A because inititor
said so, and he must reply with the same original IP address.

Note, that the IKEv2 NAT-T cannot really be used if the responder is
behind NAT, as then the initiator would need to guess or provide wide
enough range for the responder to narrow the TSr to his own original
IP-address.

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

And as the check is mandatory in IKEv2, and there is no rule in NAT-T
that says you could skip that test, this option is not possible. 

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

Yes. 

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

Yes. There is no way to give that address of X from the responder to
the initiator in the current IKEv2 protocol. Using of the traffic
selectors to send the original address does not really work at all.
There are other cases which cause problems, for example you are
supposed to have first traffic selector to be exact matching from the
packet, and second and later ones to have the real wider traffic
selectors. The NAT-T section contradicts with that.

So my reading is that you cannot use the fast fixing of the addresses
in the IKEv2 NAT-T case when using transport mode, you need to
recalculate the checksum. 

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

Checksum is never meant to be any kind of integrity checking, it is
just to catch up errors in transit, and as we usually have proper
integrity checking also that would catch errors in transit, thus we
can safely recomputate the checksum. 

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

Yes. 
-- 
[email-masked]

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

---

From: <[email-masked]>
Date: Tue, 11 Sep 2007 10:54:30 +0200

In the setup as presented, the initiator's SPD will have an entry
covering the address pair (A, Y); similarly the responder's SPD will
have an entry covering the address pair (A, Y), else it could not
return the TSi = A, TSr = Y.  A packet sent from initiator will be

    IP header src = A, dst = Y
    ESP
    TCP
    data

but after having passed the NAT box, it will be

    IP header src = X, dst = Y
    ESP
    TCP
    data

(The IKEv2 exchange has detected NAT boxes, so I guess also a
UDP header ought to be inserted.)

Question: The responder is the only node knowing about the relation
of A and X.  Is there anything hindering the responder to fix the
TCP checksum both for received and sent packets?

Christian

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: 10. september 2007 15:29
> To: Scott C Moonen
> Cc: [email-masked]
> Subject: [Ipsec] Questions regarding NAT traversal in IKEv2
> 
> Scott C Moonen writes:
> > 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?
> 
> The notification decides whether it is tunnel or transport 
> mode encapsulation, and for that you add NAT-T UDP 
> encpsulation processing if you detect NAT between hosts. 
> 
> UDP-encapsulated ESP 
> > packet if the peer has erroneously sent one when no NAT is detected?
> 
> What benefit does that give? If you ever plan to support 
> mobike (rfc4555), there are cases there where you might 
> receive packets that have UDP encapsulation, even when you 
> thing it should be off and vice versa. 
> 
> > 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.
> 
> No, the responder must reply with TSi set to A and TSr set to 
> Y, as that is the original IP addressed used, and that is the 
> address used in the narrowing. 
> 
> > 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.
> 
> Anything else is considered security violation and will cause 
> the initiator to terminate the IKE SA (i.e. responder tried 
> to attack the inititor by asking wider range than initiator 
> was willing to give, if initiator would have allowed such 
> wider range he would have proposed it in the beginning). 
> 
> The quoted text says original IP address. The original IP 
> address for the initiator is A. The responder will know it is 
> A because inititor said so, and he must reply with the same 
> original IP address.
> 
> Note, that the IKEv2 NAT-T cannot really be used if the 
> responder is behind NAT, as then the initiator would need to 
> guess or provide wide enough range for the responder to 
> narrow the TSr to his own original IP-address.
> 
> > 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.
> 
> And as the check is mandatory in IKEv2, and there is no rule 
> in NAT-T that says you could skip that test, this option is 
> not possible. 
> 
> > addresses as required by section 2.9 of RFC 4306 and 
> section 4.10 of 
> > RFC 4718.
> 
> Yes. 
> 
> therefore 
> > it will be unable to update the checksum as described in the first 
> > option of section 3.1.2 of RFC 3948.
> 
> Yes. There is no way to give that address of X from the 
> responder to the initiator in the current IKEv2 protocol. 
> Using of the traffic selectors to send the original address 
> does not really work at all.
> There are other cases which cause problems, for example you 
> are supposed to have first traffic selector to be exact 
> matching from the packet, and second and later ones to have 
> the real wider traffic selectors. The NAT-T section 
> contradicts with that.
> 
> So my reading is that you cannot use the fast fixing of the 
> addresses in the IKEv2 NAT-T case when using transport mode, 
> you need to recalculate the checksum. 
> 
> > However, the remaining
> > transport-mode tunnel provided that there is some other form of 
> > integrity checking (e.g., ESP authentication).
> 
> Checksum is never meant to be any kind of integrity checking, 
> it is just to catch up errors in transit, and as we usually 
> have proper integrity checking also that would catch errors 
> in transit, thus we can safely recomputate the checksum. 
> 
> > 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.
> 
> Yes. 
> --
> [email-masked]
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 11 Sep 2007 15:37:12 +0300

> TCP checksum both for received and sent packets?

When we were doing the NAT-T for IKEv1, my idea was that responder
would be fixing the checksum all the time (for sent and received
packets), but other people didn't like that idea, thus they required
recipient of the packet to fix the packet (which do make sense in case
you have responders also behind the NATs). So the RFC3948 defines that
recipient of the packet needs to fix it. As IKEv2 uses the same
RFC3948 it uses the same method.

So in the end you end up requiring checksum recalculation in the
recipient end in IKEv2 always. 
-- 
[email-masked]