Subject: [IPsec] IKEv2 NAT-T and Traffic Selectors

From: Matthew Cini Sarreo <[email-masked]>
Date: Tue, 22 Sep 2009 10:15:35 +0200

Hello all,

I have a question regarding proper choosing of traffic selectors in the
situation where an initator is behind a NAT device. Let us use the following
scenario:

[initiator@A]--[NAT@X]----------------[responder@Y]

Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have
a 24bit mask. The initiator policy requires traffic selectors for the whole
subnet. In the case that A is initiating:
TSi 192.168.2.0 to 192.168.2.255
TSr 192.168.4.0 to 192.168.4.255

Y does not know about 192.168.2.* but only about 192.168.3.*. So when it
receives TSi it does not match with anything it knows about. Should the
responder just accept these due to NAT being previously detected, or should
the initiator send selectors with address A (TSi) and Y (TSr) and due to
there being NAT the responder just copy them in the reply?

Regards,
Matt

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2009 15:01:59 +0300

> TSr 192.168.4.0 to 192.168.4.255

As these are subnets, I assume this is tunnel mode not transport mode.  

> there being NAT the responder just copy them in the reply?

The Y should be configured to accept 192.168.2.0/24 as this is tunnel
mode and packets exiting from the tunnel will have those addresses as
their source address. NAT does not change this, it only affects the
gateway address, i.e only the outer IP address of the ESP packet.
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 22 Sep 2009 12:52:51 -0400

Hi Matt.  Our implementation works a little differently from Tero's, so 
I'm replying just to provide a different perspective.

For our implementation, we've decided that foreign network addresses 
should not generally appear in either our configuration or our primary 
displays.  In your scenario, if IPsec were not in use, a TCP connection 
through NAT@X would appear to have a remote address of X at the responder. 
 For our implementation this would remain true even when IPsec is 
introduced along the path.

Speaking in terms of IKEv1, if our IKE is responder in this scenario, we 
will note the proposed IDi as the real client address and X as the public 
client address.  We will compare address X against our PAD and SPD for 
policy decisions, but we will echo the original IDi and IDr in our 
response.  Obviously this means that we need to do address translation 
within our platform to map 192.168.2.* to 192.168.3.5.  This grows a 
little tricky for ICMP messages with embedded packets.  Note that in any 
case the responder really ought to perform port translation in this 
configuration.

Our design decision does prevent our implementation from initiating to a 
remote IPsec gateway if that gateway is behind a NAT, since we have 
excluded the possibility of configuring addresses in the network behind 
that NAT.  We believe that initiating to a gateway behind a NAT is an 
uncommon configuration, especially for our platform.

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

From:
Tero Kivinen <[email-masked]>
To:
Matthew Cini Sarreo <[email-masked]>
Cc:
[email-masked]
Date:
09/22/2009 08:02 AM
Subject:
[IPsec]  IKEv2 NAT-T and Traffic Selectors

The Y should be configured to accept 192.168.2.0/24 as this is tunnel
mode and packets exiting from the tunnel will have those addresses as
their source address. NAT does not change this, it only affects the
gateway address, i.e only the outer IP address of the ESP packet.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Tue, 22 Sep 2009 13:04:35 -0400

> I'm replying just to provide a different perspective.

<mucho snippage deleted!>

> uncommon configuration, especially for our platform.

Your design (which is similar to the one in Solaris/OpenSolaris) WOULD allow
initiation to a behind-a-NAT peer if (and only if) the NAT was smart enough
to redirect 500 and 4500 to a single entity inside its private network.
(I'll be experimenting with this directly when I move into my new house this
weekend, actually.  :)

Dan

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 22 Sep 2009 13:38:43 -0400

Dan,

> (I'll be experimenting with this directly when I move into my new house 
this

Certainly -- initiating to a peer behind a static NAT is not a problem for 
our implementation as long as we either use transport mode or elide 
IDi/IDr (i.e., end-to-end protecting all protocols).  Initiating to a 
gateway behind that NAT is a problem, since you cannot populate IDr 
without knowing addresses in the foreign network.

From:
Dan McDonald <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
[email-masked]
Date:
09/22/2009 01:20 PM
Subject:
Re: [IPsec] IKEv2 NAT-T and Traffic Selectors

> uncommon configuration, especially for our platform.

Your design (which is similar to the one in Solaris/OpenSolaris) WOULD 
allow
initiation to a behind-a-NAT peer if (and only if) the NAT was smart 
enough
to redirect 500 and 4500 to a single entity inside its private network.
(I'll be experimenting with this directly when I move into my new house 
this
weekend, actually.  :)

Dan

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 24 Sep 2009 12:13:00 -0600

All,

During the IPsecME interim meeting earlier this week, there was initial consensus from the participants that the WESP header should be aligned on an 8 octet boundary for IPv6 in the following manner.

We will extend the WESP header by a 4 octet reserved field (all zeros) and use a new bit 'X' in the flags field to denote presence (or absence) of this alignment field.
This can be depicted as follows:

Existing WESP header:
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   HdrLen      |  TrailerLen   |V|V|E|  Rsvd   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposed change
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Header  |   HdrLen      |  TrailerLen   |V|V|E|X| Rsvd  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Reserved (zeros) for IPv6 alignment           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If 'X' is set (value 1), the 4 octet reserved field is present (needed for IPv6). If 'X' is clear (value 0), the 4 octet reserved field is absent (needed for IPv4).

This comment was from AD review of the document and ticket #109 has been generated to track this item.

Any additional feedback?

Thanks,
- Ken

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Sep 2009 11:44:02 -0700

>Proposed change

No hat:

I agree with the idea, but I would word it a bit differently. It's not "reserved", it is actually used. "IPv6Padding (4 octets)" might make it clearer.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Grewal, Ken" <[email-masked]>
Date: Thu, 24 Sep 2009 13:55:22 -0600

Thanks Paul and agreed.

- Ken

>-----Original Message-----
>From: Paul Hoffman [mailto:[email-masked]]
>Sent: Thursday, September 24, 2009 11:44 AM
>To: Grewal, Ken; [email-masked]
>Subject: Re: [IPsec] WESP #109 - WESP header alignment for IPv6
>
>I agree with the idea, but I would word it a bit differently. It's not
>"reserved", it is actually used. "IPv6Padding (4 octets)" might make it
>clearer.
>
>--Paul Hoffman, Director
>--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Sep 2009 11:52:01 +0300

On Sep 24, 2009, at 9:44 PM, Paul Hoffman wrote:

> I agree with the idea, but I would word it a bit differently. It's  
> not "reserved", it is actually used. "IPv6Padding (4 octets)" might  
> make it clearer.

Or maybe "extra 32 reserved bits" so that everyone can extend ESP :-)

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Sep 2009 08:07:04 -0700

>Or maybe "extra 32 reserved bits" so that everyone can extend ESP :-)

You ended that with a smiley, but the intention is not clear. Ken proposed that the X flag *only* be used when there are IPv6 addresses, and that is what people on the call thought was right. Can you clarify whether you mean that you want this for *all* uses of WESP, or just for IPv6? If the former, why?

--Paul Hoffman, Director
--VPN Consortium