Subject: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP

From: Yaron Sheffer <[email-masked]>
Date: Wed, 26 Aug 2009 00:22:59 +0300

[2.23, NAT Traversal]

>     o  Implementations MUST process received UDP-encapsulated ESP packets

>        even when no NAT was detected.

>     o  The original source and destination IP address required for the

>        transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])

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

Tero:

Getting original source and destination IP address from the traffic

selectors do not really work currently. Especially when combined with

the selectors from the packet and when responder is behind nat or

similar problems.

Paul: Not done. Specify replacement text and discuss on the mailing list.

People who care about Transport Mode are requested to help resolve this NAT
Traversal issue.

Thanks,

            Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Aug 2009 15:52:11 +0300

> People who care about Transport Mode are requested to help resolve this NAT

I wrote better long description about the problem, and also proposed
solution text at 2009-04-07:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html
-- 
[email-masked]

---

From: Dan McDonald <[email-masked]>
Date: Wed, 26 Aug 2009 11:24:52 -0400

On Wed, Aug 26, 2009 at 03:52:11PM +0300, Tero Kivinen wrote:

<mucho snippage deleted!>

> http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html

The text referenced above summarizes the problem AND solution quite nicely,
and reduces my response to a lame, but succinct +1.

Dan

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 26 Aug 2009 14:03:12 -0400

Tero, I am not comfortable with the following statement:

        . . . thus it will send back traffic selectors having IPN1 and IP2 
as their IP addresses . . .

I would prefer that the server re-map the TS values back to IP1 and IPN2 
when sending its response.  This is consistent with the general 
expectation that the response's TS payloads are a subset of the request's 
payloads.  The client does not absolutely need this information (it would 
perhaps help for deterministic checksum fixup, however in transport mode 
as long as an integrity algorithm is used the checksum provides no 
additional value anyway).  I think it is also advantageous to contain this 
fixup processing to one code path (processing TS payloads in received 
requests), and it also simplifies the response message processing (the 
client does not need to complicate its checks to verify that the 
response's TS payloads are a subset of the request's).  This separation of 
responsibility is more advantageous to a client implementation that needs 
to be as minimal as possible.

Finally, what I propose above is how our own IKEv1 implementation works in 
cases where ID payloads are sent for transport mode. :)  As a responder we 
found it best to bend over backwards to cater to the initiator's view of 
the world.

I'm also concerned about the following statement:

        After this it does SPD lookup based on those new traffic 
selectors. . . .
        If entry is found but it does not allow transport mode, then MUST
        undo the address substitution and redo the SPD lookup using the
        original traffic selectors. . . .

This statement is incoherent to me.  From the fact that the initiator 
proposed transport mode, it is clear that the initiator identifies TSi 
with itself and TSr with the server.  The address substitution exactly 
translates these addresses into the domain of the responder's SPD.  If the 
responder's policy indicates that transport mode is not acceptable for 
this SPD entry, then I think the only possible outcome is that SA 
negotiation should be failed.  No other SPD entry could possibly match the 
initiator's intentions.  However, the MUST quoted above causes the 
responder to treat these addresses in an incoherent way:

1) The responder has detected a NAT in front of the initiator, so treating 
IP1 as being within the domain of the responder's SPD isn't appropriate; 
we need to use IPN1.
2) NATs aside, the responder knows that the initiator identifies IP1 with 
the initiator itself (because the initiator proposed transport mode), so 
treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps 
as some address behind the initiator for which it is acting as a gateway 
-- isn't appropriate, because the initiator could not possibly have had 
gateways in mind.
3) The responder has detected a NAT in front of itself, so treating IPN2 
as being within the domain of the responder's SPD isn't appropriate; we 
need to use IP2.
4) NATs aside, the responder knows that the initiator identifies IPN2 as 
the responder (because the initiator proposed transport mode), so treating 
IPN2 as anything other than the responder (i.e., IP2) -- as though it were 
some address behind the responder for which the responder is acting as a 
gateway -- isn't appropriate, because the initiator could not possibly 
have had gateways in mind.

I don't think this is an appropriate way for the responder to interpret 
TSi and TSr.  I propose that the MUST above be changed to "MUST fail the 
SA negotiation."

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
1-919-254-1388 (T/L: 444-1388)
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Yaron Sheffer <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
08/26/2009 12:01 PM
Subject:
[IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated 
transport mode ESP

I wrote better long description about the problem, and also proposed
solution text at 2009-04-07:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Aug 2009 11:14:48 +0300

Scott C Moonen writes:
> when sending its response.

This is not possible, as the other end needs to know the address if
IPN1 and IP2 (those are not known to him otherwise). Those addresses
are used as original source and destination addresses for incremental
checksum fixup. 

> This is consistent with the general 
> payloads.

Yes, but then we still would have problem that we do not get the
original addresses from anywhere. Currently IKEv2 says they are taken
from the traffic selectors, but if we do not send IPN1 and IP2 back
from responder to initiator, initiator does not get them anywhere.

> The client does not absolutely need this information (it would 
> additional value anyway).

RFC3948 do want them to do incremental checksum fixup, and one of the
reasons we want to modify this text is to provide that information.

> I think it is also advantageous to contain this 

Yes, it might make it bit more simplier, but would loose functionality
that is supposed to be there. The initiators processing of the
responders reply is quite simple anyways, i.e. check if
USE_TRASPORT_MODE was returned (i.e. transport mode was selected), and
if so store traffic selectors as original addresses, and replace them
similarly as is done in other cases. Then normal processing can
continue without any changes (i.e. traffic selector verification,
IPsec SA installing etc). 

> found it best to bend over backwards to cater to the initiator's view of 

In IKEv1 there is separate payloads for sending the original
addresses. In IKEv2 we do not have that, thus we must use traffic
selectors for that.

> with itself and TSr with the server.

No. As USE_TRASPORT_MODE is only hint in IKEv2. Responder has full
choice of ignoring it and using tunnel mode instead. TSi and TSr do
NOT identify initiator at all, initiator is already identified by the
ID payloads. TSi and TSr are used to select suitable SPD entry for the
given identified initiator.

As for transport-mode NAT-T case the original TSi and TSr can be quite
unknown for the responder, we first try with the converted addresses,
but if we need to fall back to tunnel-mode NAT-T, then we want to keep
original traffic selectors as now the packets exiting from the tunnel
will have those addresses (i.e. packets coming from the tunnel will
have IP1 and IPN2 as their source and destination addresses, as NAT in
the middle does not substitute them). 

> The address substitution exactly 
> initiator's intentions.

Initiator asked that if possible use transport mode with these
addresses, if transport mode is not possible then use tunnel mode.
Even if transport mode was not allowed, it is possible that responder
do have tunnel mode rule that is allowed for that client even when
transport mode was not.

I do not see how you can claim that "No other SPD entry" could not be
found, as initiator only gave hint that it would like to use transport
mode. The use of tunnel vs transport mode is fully based on the
responders policy. 

> However, the MUST quoted above causes the 

Yes, for transport mode. For tunnel mode the IP1 is within the domain
of responder's SPD as that is what responder will see in the packets
coming out from the tunnel. 

> -- isn't appropriate, because the initiator could not possibly have had 

I do not understand that statement at all. Other end is identified by
the ID payloads, not by traffic selectors or by IP-addresses. If NATs
are involved it is completely possible that responder have multiple
clients connecting to it each having same IP1 (10.0.0.1) as their TSi
field. Also it is possible that it has multiple clients using
different IP1, but using same IPN1 as their outer address (but
different ports for UDP encapsulation). RFC 3948 security
considerations section has text about these different overlapping
address problems.

> as being within the domain of the responder's SPD isn't appropriate; we 

Again only for transport mode. For tunnel mode IPN2 is again ok, as
that is the packet which is exiting from the tunnel. Of course if
tunnel mode was used instead of transport mode then the implementation
must use some method to make sure that those packets exiting from the
tunnel and having destination address of IPN2 are still directly
processed by the local stack.

> TSi and TSr.  I propose that the MUST above be changed to "MUST fail the 

That would be against the 1.3.1 of the IKEv2bis or 3.10.1 of RFC4306
which says:

   ... If the request is accepted, the response MUST
   also include a notification of type USE_TRANSPORT_MODE.  If the
   responder declines the request, the Child SA will be established in
   tunnel mode.  
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 27 Aug 2009 16:05:46 -0400

Tero, in short:

1) I still prefer to echo back TS payloads as I described.  I realize that 
the TS payloads are the only opportunity that IKEv2 has to reproduce the 
effect of IKEv1's NAT-OA payloads.  But using the traffic selectors in 
this way -- and only if the responder ends up agreeing to transport mode! 
-- still strikes me aesthetically as quite jarring, which is certainly a 
subjective thing but not a meaningless thing. :)  As I indicated, I'm not 
worried about being unable to deterministically fixup the checksums 
because in transport mode with integrity protection, checksums aren't 
critical.  I'm interested to hear what other implementers think.

2) I think we have a fundamental disagreement about whether it is proper 
for addresses in foreign networks to be configured in the SPD.  Our own 
IKEv1 NAT-T implementation has made some (I think reasonable) design 
assumptions that exclude this, even in NAT-T tunnel mode.  So, briefly, 
the MUST as you have written it is not even possible for our 
implementation to satisfy, because by definition our SPD cannot contain 
addresses from foreign networks.  As you might guess, our assumptions lead 
to certain implications (such as the fact that we need to do various IP 
header address fixup and also port translation).  I'm not sure it's worth 
boring the list with all the details.  Perhaps what I can do is put 
together a note over the next couple of days to privately discuss our 
implementation with you.  I'd mainly like to make sure that if there is a 
MUST here, it is written in such a way that implementations such as ours 
are not broken by definition.

3) I agree with you about my suggested replacement text, "MUST fail the SA 
negotiation."  Because of the way that USE_TRANSPORT_MODE is negotiated, 
what I propose is not correct.  For our own implementation, the correct 
behavior would be to accept the proposed SA without use of transport mode. 
 At the moment I'm not sure how best to word this MUST to accommodate 
implementations that do and do not allow foreign network addresses in the 
SPD.

Thanks,

From:
Tero Kivinen <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>, [email-masked]
Date:
08/27/2009 04:15 AM
Subject:
Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated 
transport mode ESP

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Aug 2009 14:47:05 +0300

> critical.  I'm interested to hear what other implementers think.

The problem is that if you do not fix checksums incrementally you need
to recalculate them completely, which is costly operation, especially
when it happens after decryption, which means you cannot usually use
the hardware on the network card. Then when you have recalculated them
you need to recalculate them again to verify them.

In some implementations you can skip that calculation by using special
flags in implementation, but there is no generic way to do it (except
for IPv4 UDP where you can set the checksum to 0). See RFC3948 section
3.1.2 for details.

Using traffic selectors for the NAT-OA payloads is already in the
RFC4306:

2.23.  NAT Traversal
...
      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.  

So this is not new thing to add to IKEv2, the problem is that
currently RFC4306 does not tell how to do that so it actually works.

In my text I try to fix this omission and specify how it can be done
without breaking existing MUSTs in RFC4306 and trying to follow other
text in RFC4306.

> are not broken by definition.

Hmm... Actually now when you point it out, I think the MUST is too
strong, as there might also be implementations which do not support
tunnel mode at all (host implementations are not required to support
tunnel mode), thus perhaps that second policy lookup "MUST" needs to
be changed to "SHOULD" or even "MAY".

Would that be acceptable for you?

-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 28 Aug 2009 15:53:02 -0400

Tero, changing the MUST to MAY is ok.  If we choose SHOULD then I would 
prefer to present alternatives, something to the effect of "SHOULD either 
[do what you proposed] or accept the proposal with the use of tunnel mode, 
as appropriate."

From:
08/28/2009 07:47 AM

2.23.  NAT Traversal
...

-- 
[email-masked]