Subject: [IPsec] Transport Mode and NAT [Was: IPsec maintenance/extensions WG?]

From: Chinh Nguyen <[email-masked]>
Date: Wed, 23 Apr 2008 11:24:12 -0400

Dan McDonald wrote:
 >> Consider 1 single NAT-ted peer:
 >>
 >> X -- N[at] -- Y
 >>
 >> X can negotiate TSi=(X), TSr=(Y). This is no good for Y since it 
will be
 >> sending data addressed to N. That is, the security policy (SP) 
generated
 >> from selectors (X,Y) by Y will not match Y's outgoing packets with
 >> addresses (Y,N).
 >
 > Y doesn't know about X save for NAT-OA - and as you point out, that only
 > helps the checksums.  Y talking to X is governed by Y's rules for talking
 > with N.  That's just how it works, welcome to the world of NAT.  :-P
 >
 >> Alternatively, X can negotiate TSi=(N), TSr=(Y) if it somehow knows the
 >> address of NAT device or perhaps it can send TSi=(*), TSr=(Y) and Y can
 >> reply with TSi=(N), TSr=(Y). This is good for Y but now, the selectors
 >> (N,Y) that are used by X will not match packets coming out of X, which
 >> have addresses (X,Y).
 >
 > Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a 
NAT in
 > betweeen and it must treat (X) as (N) for purposes of its local IPsec 
policy.

I see the disconnect now. We have simple policies (address, port, proto) 
so they are mapped directly to TS, then the final TS is mapped into 
"ipsec policies" for packet processing. As such, I could not see how an 
"ipsec driver" on Y can use TS(X,Y) for traffic destined for N. Thus, X 
should not propose (X,Y). (And similarly, Y does not propose (N,Y) for X).

What you are saying is that there may be extra policy 
processing/book-keeping for a particular peer. That the agreed-upon TS 
are not the whole story. Is this because 4301 in some ways supercedes 
4306? Because I'm sure 4306 is reasonably clear on how TS should be used.

For completeness, I would like to point out (from my old e-mail), that 
given the more general situation:
     X -- N1 -- N2 -- Y

If X sends TSi(X,*) TSr(N2,*) and Y responds TSi(X,N1) TSr(N2,Y), both 
sides will get selectors that match their respective packets: (X,N2), 
(X,Y), (N1,N2), (N1,Y). Not only that, both sides will know the NAT-OA, 
both i and r.

This will also work when there is only 1 NAT device. And in the case of 
no NAT: X -> TSi(X,*) TSr(Y,*) Y -> TSi(X,X) TSr(Y,Y) which is the 
TS(X,Y) that you would expect.

Chinh
--
http://www.certicom.com
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Dan McDonald <[email-masked]>
Date: Wed, 23 Apr 2008 11:41:48 -0400

> Dan McDonald wrote:
<SNIP!>
> should not propose (X,Y). (And similarly, Y does not propose (N,Y) for X).

But X doesn't know about N - all it can propose is X,Y.  It's up to Y to
understand there's a NAT in between.

> processing/book-keeping for a particular peer.

Yes.

> That the agreed-upon TS are not the whole story. Is this because 4301 in
> some ways supercedes 4306? Because I'm sure 4306 is reasonably clear on how
> TS should be used.

Take IPsec out of the equation for a second -- there's no way to know what is
behind the NAT, or which entity behind the NAT is talking.  That holds true
when you introduce IPsec into the mix.  IKE's NAT-OA allows checksum
adjustments to happen, but it doesn't help the non-NAT-ted Y's generic IP
code how to figure out if it's X, or A, or B that's taking behind the NAT.

> (X,Y), (N1,N2), (N1,Y). Not only that, both sides will know the NAT-OA, 

You make one small mistake --> there will NEVER be an (X,Y) packet on the
wire.  Put sniffers on each of the links you draw above, and you'll see
(X,N2), (N1,N2), and (N1,Y).

> TS(X,Y) that you would expect.

Yes.

Dan

---

From: Chinh Nguyen <[email-masked]>
Date: Wed, 23 Apr 2008 17:24:37 -0400

> understand there's a NAT in between.

Yes, all X can propose is (X,Y) and all Y can respond is (X,Y). So if we 
were to map (X,Y) directly to some ipsec security policy rule, there's 
no way packets outbound from Y for N would get encrypted.

As you pointed out, this requires extra logic. I'm not aware if this was 
stated in 4306. It may have been covered by one of the addendums or 
clarification drafts (e.g., draft-kukec-ikev2-tutorial-additions-02).

Certainly, from my perspective, this is problematic as we rely on the TS.

> code how to figure out if it's X, or A, or B that's taking behind the NAT.

Yes. A message from Y to N would be ambiguous. "Are you trying to use 
the security policy for X, A, or B?" You noted previously that there may 
be some ways to solve this.

In theory, a reply from Y to X may not be. The encrypted packet from X, 
or A would both have source ip N but different source (NAT) ports. If 
you can "stamp" the decrypted packet with this info and track it, then 
the reply to that packet may also be similarly tracked. Anyway, now 
we're on to something else entirely.

> (X,N2), (N1,N2), and (N1,Y).

Yes. For both X and Y, there are 3 unused combination. X only needs (X, 
N2) and Y only needs (N1,Y). This is certainly wasteful. However, it 
seems to allow us to correctly negotiate when behind NAT using strictly 
the TS payloads and some fairly simple logic. Y: "If transport mode, 
then TSi = the source IP of peer (N1 if X behind NAT), and TSr=my own 
IP, and also whatever the peer sent".

There's also the benefit of both sides knowing the NAT-OAi and NAT-OAr. 
But this is not crucial as full checksumming can be done.

Chinh
--
http://www.certicom.com

---

From: [email-masked]
Date: Thu, 24 Apr 2008 14:10:46 -0400

> > <SNIP!>
> >>  > Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that
there's a NAT in
> >>  > between and it must treat (X) as (N) for purposes of its local
IPsec policy.

> clarification drafts (e.g., draft-kukec-ikev2-tutorial-additions-02).

The "extra logic" is implied by Section 2.23 of RFC 4306.  In essence,
the logic is that when the NAT detection source IP payload doesn't
match,
then the actual source address of the packet containing that payload
(i.e., N) has to be used as the remote address for local IPsec traffic
policy, because traffic for that SA will be sent to/received from that
source address (N) and not the address in the traffic selector (X).

If one thinks about it, this is reasonably obvious, because X is not
a valid address that Y can communicate with, and hence using X for local
traffic processing at Y is doomed to failure.  The upshot is that the
traffic selectors for the SA pair is (X, Y) and (as Dan wrote)
Y "must treat (X) as (N) for purposes of its IPsec policy."

In the reverse direction, if Y initiates, all it can propose is (Y,N).
X sees the NAT Detection Destination IP payload fail to match and
hence knows that it has to use X instead of N as the local address
in its IPsec policy.

[... snip ...]

> >> If X sends TSi(X,*) TSr(N2,*) and Y responds TSi(X,N1) TSr(N2,Y)

Nooo - don't do that!!!  That response by Y mixes addresses from
different networks in both traffic selectors; that's a bad idea that
is sure to cause confusion.  X (private address) and N1 (X's public
address as seen by N2 and Y) aren't addresses in the same network,
and likewise for Y (private address) and N2 (public address of Y as
seen by X and N1).  The traffic selectors for this case (X is initiator)
are (X,N2); Y will see both the source and destination NAT detection
payloads fail to match and know that both addresses have been NAT-ed.

NAT traversal mechanisms should to be used to communicate NAT
translation information, rather than trying to abuse traffic selectors
for that purpose.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Chinh Nguyen <[email-masked]>
Date: Fri, 25 Apr 2008 10:26:25 -0400

> source address (N) and not the address in the traffic selector (X).

In section 2.23, there is mention that the original source/dest in the 
TS can be used for incremental checksum fixup (3rd to last paragraph of 
section). But that's about it.

In section 2.9 on TS negotiation, not much is stated. Although it's 
implied that TS communicate only "some of the information from their SPD 
to their peers".

In any case, it's clear from David and Dan's messages that extra 
book-keeping is required for Transport mode and NAT. Am I correct in 
thinking that NAT-OA (and incremental checksum) is only available to the 
responder? The initiator can detect there's NAT via the NAT-D payloads, 
but the TS it receives back will be the values it sends, no new information.

In a nutshell, is this the correct logic for transport mode (possibly 
with NAT)?

Initiator:
1. Sends TS(Si, Sr) where Si and Sr are single IPs: init's address and 
resp's address as seen by init. Expects to receive TS(Si, Sr) from resp.
2. Ipsec processing done with Si, Sr.
3. If nat is detected, do full checksum update.

Responder:
1. Expects TS(Si, Sr) where Si and Sr are single IPs. Sends back TS(Si, Sr).
2. Ipsec processing done with IPi, IPr: init's IP address and IP resp's 
address as seen by resp (e.g., the source/dest in the IKE packet header).
3. If remote nat detected (init behind NAT), do incremental checksum 
where NAT=IPi, NAT-OAi=Si. If local nat detected (resp behind NAT), do 
incremental checksum where NAT=Sr, NAT-OAr=IPr.

Chinh
--
http://www.certicom.com

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Apr 2008 14:37:51 +0300

> section). But that's about it.

Yes, that statement is incomplete, as it does not tell how it can be
used, and I have not found a interoperable way to do it, thus as far
as I know it cannot be done. This means there is no interoperable way
to do incremental checksum fixup in the IKEv2 for transport mode
NAT-T. The NAT-T rfc still offers other options which are usable
(ignore, recompute), thus this does not cause problems, it just means
on of the options is not available. 

> implied that TS communicate only "some of the information from their SPD 

The whole transport mode part is bit underspecified in the IKEv2, as
IKEv2 do not really specify what the IP addresses in the traffic
selectors really mean in the transport mode case. As transport mode
must be used between hosts, so the IP addresses must be addresses from
the host itself, but can there be multiple IP-addresses in the
transport mode traffic selectors, in case there is multiple
IP-addresses for the host (in general case, not in NAT-T case)?

Also the transport mode NAT-T part saying there must "contain exactly
one IP address", does not allow using any kind of wildcard selectors.
There is also confusion can there be multiple traffic selectors
payloads still, even when there is only one IP-address in those
traffic selectors (i.e. MAY/SHOULD/MUST you send the first traffic
selector matching the exact fields in the data packet?).

Again if there can be only one IP address in the NAT-T case in the
traffic selectors, that means it must be the real end node addresses
(i.e. before NAT), so they are usable for the incremental checksum
calculation, but that will mean that when the responder who is not
behind the NAT starts receiving packets the IP-addresses it receives
do not match the traffic selectors negotiated etc.

> but the TS it receives back will be the values it sends, no new information.

I think it is clear that more specification is needed to make
transport mode NAT-T usable, and currently you have only option to
recompute or ignore the checksum, there is no option to incrementally
fixup the checksum, as there is no NAT-OA available for you. 

> 3. If nat is detected, do full checksum update.

That looks ok. 

> address as seen by resp (e.g., the source/dest in the IKE packet header).

In most of the cases you simply need to ignore the source address of
the packet, and assume it is always Si. The problem is that the
address nat uses (IPi) might change when the NAT is rebooted, and also
when you do the SAD checks (RFC 4301, section 5.2, step 4) you need to
use the NAT's address not the negotiated traffic selectors. (I
actually remembered that the step 4 would not have been there for the
transport mode SAs, but the RFC 4301 does not seem to make any
difference between transport mode and tunnel mode SAs there).

One of the solutions could be to use the built in reverse NAT inside
the IPsec device to NAT the IPi to Si before transport mode IPsec
processing. This way the traffic selectors match (SAD has Si and Sr)
and this should also survive even the address changes caused by NAT
reboots, provided the reverse NAT is also updated.

> incremental checksum where NAT=Sr, NAT-OAr=IPr.

Anyways, I do not think there is really a way to do anything
interoperably, so more specification is needed. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec