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

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Sep 2009 15:38:51 -0700

Here is the edited text. Please be sure it is still correct.

<section anchor='sect-2.23.1' title='Transport Mode NAT Traversal'>

<t>Transport mode used with NAT Traversal requires special handling
of the traffic selectors used in the IKEv2. The complete scenario
looks like:</t>

<figure><artwork><![CDATA[
+------+        +------+            +------+         +------+
|Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
|node  |<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+
]]></artwork></figure>

<t>(Other scenarios are simplications of this complex case, so this
discussion uses the complete scenario.)</t>

<t>In this scenario, there are two address translating NATs: NAT A
and NAT B. NAT A is dynamic NAT that maps the clients source address
IP1 to IPN1. NAT B is static NAT configured so that connections
coming to IPN2 address are mapped to the gateways adddress IP2, that
is, IPN2 destination address is mapped to IP2. This allows the client
to connect to a server by connecting to the IPN2. NAT B does not
necessarely need to be a static NAT, but the client needs to know how
to connect to the server, and it can only do that if it somehow knows
the outer address of the NAT B, that is, the IPN2 address. If NAT B
is a static NAT, then its address can be configured to the client's
configuration. Other options would be find it using some other
protocol (like DNS), but those are outside of scope of IKEv2.</t>

<t>In this scenario, both client and server are configured to use
transport mode for the traffic originating from the client node and
destined to the server.<t>

<t>When the client starts creating the IKEv2 SA and Child SA for
sending traffic to the server, it has a triggering packet with source
IP address of IP1, and a destination IP address of IPN2. Its PAD and
SPD needs to have configuration matching those addresses (or wildcard
entries covering them). Because this is transport mode, it uses
exactly same addresses as the traffic selectors and outer IP address
of the IKE packets. For transport mode, it MUST use exactly one IP
address in the TSi and TSr payloads. It can have multiple traffic
selectors if it has, for example, multiple port ranges that it wants
to negotiate, but all TSi entries must use IP1-IP1 range as the IP
addresses, and all TSr entries must have the IPN2-IPN2 range as IP
the addresses. The first traffic selector of TSi and TSr SHOULD have
very specific traffic selectors including protocol and port numbers
from the packet triggering the request.</t>

<t>NAT A will then replace the source address of the IKE packet from
IP1 to IPN2, and NAT B will replace the destination address of the IKE
packet from IPN2 to IP2, so when the packet arrives to the server it
will still have the exactly same traffic selectors which were sent by
the client, but the IP address of the IKE packet has been replaced to
IPN1 and IP2.</t>

<t>When the server receives this packet, it normally looks the PAD
based on the ID and then searches the SPD based on the traffic
selectors. Because IP1 does not really mean anything to the server
(it is the address client has behind the NAT), it is useless to do
lookup based on that if transport mode is used. On the other hand,
the server cannot know whether transport mode is allowed by its
policy before it finds the matching SPD entry.</t>

<t>In this case, the server should first check that as initiator
requested transport mode and do address substitution on the traffic
selectors. It needs to first store the old traffic selector IP
addresses to be used later for the incremental checksum fixup (the IP
address in the TSi can be stored as the real source address and the
IP address in the TSr can be stored as the real destination address).
After that, if the other end was detected as being behind a NAT, the
server replaces the IP address in TSi payloads with the IP address
obtained from the source address of the IKE packet received (that is,
it replaces IP1 in TSi with IPN1). If the server's end was detected
to be behind NAT, it replaces the IP addresses in the TSr payloads
with the IP address obtained from the destination address of the IKE
packet received (thta is, it replaces IPN2 in TSr with IP2).</t>

<t>After this address substitution, both the traffic selectors and
the IKE UDP source/destination addresses look the same, and the
server does SPD lookup based on those new traffic selectors. If an
entry is found and it allows transport mode, then that entry is used.
If an entry is found but it does not allow transport mode, then the
server MAY undo the address substitution and redo the SPD lookup
using the original traffic selectors. If the second lookup succeeds,
the server will create an SA in tunnel mode using real traffic
selectors sent by the other end.</t>

<t>This address substitution in transport mode is needed because the
SPD is looked up using the addresses that will be seen by the local
host. This also will make sure the SAD entries for the tunnel exit
checks and return packets is added using the addresses as seen by the
local operating system stack.</t>

<t>The most common case is that the server's SPD will contain
wildcard entries matching any addresses, but this allows also making
different SPD entries, for example, for different known NATs outer
addresses.</t>

<t>After the SPD lookup, the server will do traffic selector
narrowing based on the SPD entry it found. It will again use the
already-substituted traffic selectors, and it will thus send back
traffic selectors having IPN1 and IP2 as their IP addresses; it can
still narrow down the protocol number or port ranges used by the
traffic selectors. The SAD entry created for the Child SA will have
the addresses as seen by the server, namely IPN1 and IP2.</t>

<t>When the client receives the server's reply to the Child SA, it
will do similar processing. If the transport mode SA was created, the
client can store the original returned traffic selectors as real
source and destination addresses. It will replace the IP addresses in
the traffic selectors with the ones from the IP header of the IKE
packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it will
use those traffic selectors when verifying the SA against sent
traffic selectors, and when installing the SAD entry.</t>

<t>A summary of the rules for NAT-traversal in transport mode is:</t>

<figure><artwork><![CDATA[
For the client proposing transport mode:

- The TSi entries MUST have exactly one IP address, and that MUST
  match the source address of the IKE SA.

- The TSr entries MUST have exactly one IP address, and that MUST
  match the destination address of the IKE SA.

- The first TSi and TSr traffic selectors SHOULD have very specific
  traffic selectors including protocol and port numbers from the
  packet triggering the request.

- There MAY be multiple TSi and TSr entries.

- If transport mode for the SA was selected (that is, if the server
  included USE_TRANSPORT_MODE notification in its reply):

  - Store the original traffic selectors as the real source and
    destination address.

  - If the server is behind a NAT, substitute the IP address in the
    TSr  entries with the remote address of the IKE SA.

  - If the client is behind a NAT, substitute the IP address in the
     TSi entries with the local address of the IKE SA.

  - Do address substitution before using those traffic selectors
    for anything else other than storing original content of them.
    This includes verification that traffic selectors were narrowed
    correctly by other end, creation of the SAD entry, and so on.
]]></artwork></figure>

<figure><artwork><![CDATA[
For the responder, when transport mode is proposed by client:

- Store the original traffic selector IP addresses as real source
  and destination address in case we need to undo address
  substitution.

- If the client is behind a NAT, substitute the IP address in the
  TSi entries with the remote address of the IKE SA.

- If the server is behind a NAT substitute the IP address in the
  TSr entries with the local address of the IKE SA. 

- Do PAD and SPD lookup using the ID and substituted traffic
  selectors.

- If no SPD entry was found, or if found SPD entry does not
  allow transport mode, undo the traffic selector substitutions.
  Do PAD and SPD lookup again using the ID and original traffic
  selectors, but also searching for tunnel mode SPD entry (that
  is, fall back to tunnel mode). 

- However, if a transport mode SPD entry was found, do normal
  traffic selection narrowing based on the substituted traffic
  selectors and SPD entry. Use the resulting traffic selectors when
  creating SAD entries, and when sending traffic selectors back to
  the client.
]]></artwork></figure>

</section>

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Sep 2009 14:49:28 +0300

> IP1 to IPN2, and NAT B will replace the destination address of the IKE
	 ^^^^

This should be IPN1.

>   and destination address in case we need to undo address

The IP addresses are also needed for the RFC 3948 incremental checksum
fixup in udp encapsulation, not only for undoing the address
substitution. 

>   TSr entries with the local address of the IKE SA.

"Client" and "server" are ok here, but my original text used "other
end" and "this end" at least in our implementation our NAT traversal
detection does tests that way. I.e. it know whether this end and/or
other end is behind nat and knows to enable suitable processing based
on that (i.e. sending of RFC3948 keepalives etc). Client and server
makes this bit more vpn roadwarrior case centric, compared to using
"this end" and "other end".

But either one is acceptable here.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Sep 2009 07:24:30 -0700

>fixup in udp encapsulation, not only for undoing the address

As I said in my earlier note, I have removed all discussion of RFC 3948 from this new text. RFC 3948 is for IKEv1 only, and is not relevant here.

>But either one is acceptable here.

I changed to "client" and "server" to match the figure. Let me know if this is not OK.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 21 Sep 2009 12:31:27 -0400

Paul,

> NAT B does not necessarely need 

s/necessarely/necessarily/

> replaces the IP address in TSi payloads . . .
> replaces the IP addresses in the TSr payloads . . .
> it will thus send back traffic selectors having IPN1 and IP2 as their IP 
addresses . . .
. . .

As it seems there is no support for my alternative suggestion, I'm ok with 
this direction.

> replaces the IP addresses in the TSr payloads . . .

I think it's ok to change this to singular: "the IP address in the TSr 
payloads".

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

From:
Paul Hoffman <[email-masked]>
To:
Tero Kivinen <[email-masked]>, Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>
Date:
09/19/2009 06:40 PM
Subject:
Re: [IPsec] #28: Obtaining src/dest IP addresses for  UDP-encapsulated 
transport mode ESP

</section>

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2009 11:52:58 +0300

Paul Hoffman writes:
> As I said in my earlier note, I have removed all discussion of RFC
> 3948 from this new text. RFC 3948 is for IKEv1 only, and is not
> relevant here.

RFC3947 is for IKEv1, RFC3948 is for IKEv1 and IKEv2. We do have
references from RFC4306 to RFC3948 as that is the only document that
describes how to do the UDP encapsulation. The problem is that it just
says "peer's real source and distination address have been received
according to [RFC3947], incrementally ..." and the longer description
of original source and destination addresses are in the RFC3947
section 5.2.

So we definately need reference to RFC3948 (we already have that as
[UDPENCAPS]), but as its description of the addresses is so short my
original text refered to longer text in RFC3947. On the other hand as
this longer text is just background information and is not really
needed for protocol reasons the ones implementing UDPENCAPS/RFC3948
can then see the reference to RFC3947 and read that as background
information if they want to. 

> I changed to "client" and "server" to match the figure. Let me know

As I said it is OK, I just explained my reasons to why I originally
selected other words, but matching the ones in the figure is also
good. 
-- 
[email-masked]