Subject: Another NAT Traversal question

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Mon, 24 Feb 2003 23:37:22 -0500

I'm worried about UDP/TCP checksums.

In tunnel mode, it's not a problem, since
the inner IP header doesn't get modified
by the NAT.

In UDP-encapsulation, it's not a problem,
since the inner IP header doesn't get modified,
and the outer UDP header is unencrypted and
the NAT can fix the checksum.

What seems to be a problem is Transport mode.
I thought I remembered some sort of payload
type that would say "my IP address as I
sent it is XXX", so that the receiving ESP
could adjust the TCP checksum appropriately
once it decrypts the packet. However, I
don't see that in the current IKEv2 spec. Instead
I see this NAT-DETECTION-SOURCE-IP payload,
but that's a hash of the IP address, not
the actual address. Now I suppose with only
32 bits of address, the receiver could calculate
the actual address on the other side, but that
seems needlessly computationally expensive.

So...have we given up on Transport mode (would
be fine with me), or does this really work
somehow and I don't understand it?

Radia

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Feb 2003 10:32:08 +0100

In your previous mail you wrote:

   ...

=> this is the NAT-OA (NAT Original Address) of
draft-ietf-ipsec-nat-t-ike-05.txt.

   could adjust the TCP checksum appropriately
   once it decrypts the packet. However, I
   don't see that in the current IKEv2 spec.

=> yes, someone forgot this...

   Instead I see this NAT-DETECTION-SOURCE-IP payload,

=> NAT-D (NAT discovery) from the same draft.

=> this is why I proposed to replace the hash by the full
address. In fact, the hash is useful only when the peer
wants to keep its address secret.

   be fine with me),

=> NO, Transport mode is still very important.

   or does this really work somehow and I don't understand it?
   
=> it doesn't work yet.

Thanks

[email-masked]

---

From: "Jayant Shukla" <[email-masked]>
Date: Tue, 25 Feb 2003 08:42:00 -0800

The checksum is being fixed according to the new IP addresses in the IP
header and therefore you don't need the original IP address. 

From what I recall, the authors had given up on the transport mode and
one of them had stated on this list that only 'tunnel mode' will be
pushed for v2.

Regards,
Jayant
www.trlokom.com 

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Radia Perlman - Boston Center for Networking
> Sent: Monday, February 24, 2003 8:37 PM
> To: [email-masked]
> Subject: Another NAT Traversal question
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Feb 2003 01:15:13 +0100

=> so you give up the transport checksum ?

=> I am afraid that there is no consensus to drop the transport mode,
so as the NAT traversal is in the charter, there is a problem to
really solve.
   
Regards

---

From: Ari Huttunen <[email-masked]>
Date: Wed, 26 Feb 2003 10:27:18 +0200

> so as the NAT traversal is in the charter, there is a problem to

Let's ask it this way: what is the real need for transport mode ESP
to work over NAT? You can do everything with tunnel mode ESP, including
L2TP/IPsec.

ps. I do not represent anybody else except me personally on this issue.

Ari

-- 
I play it cool and dig all jive,
  that's the reason I stay alive.
   My motto as I live and learn,
    is dig and be dug in return. <Langston Hughes>

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com

F(ully)-Secure products: Securing the Mobile Enterprise

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 26 Feb 2003 11:00:23 +0200

Sure you can do L2TP/IPsec with tunnel mode, but that wastes another 20
bytes for the extra IP header.  This is AFAIK the only reason to prefer
transport mode.

I also believe that transport mode is not worth the trouble, but other
people disagree.

Yoav

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ari Huttunen
Sent: Wednesday, February 26, 2003 10:27 AM
To: Francis Dupont
Cc: Jayant Shukla; [email-masked]; [email-masked]
Subject: Re: Another NAT Traversal question

Ari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Feb 2003 11:42:14 +0100

to work over NAT?

=> we have no choice : we need transport mode and there are NATs (including
in the charter)...

   You can do everything with tunnel mode ESP, including L2TP/IPsec.
   
=> there are two important differences between tunnel and transport modes:
overhead and selector checking. The first one can be removed with good
compression, including header compression, but the second cannot: tunnel
mode and transport mode over a tunnel will be ever different.
IMHO if we have to give up something, it should be the NAT traversal...

Regards

---

From: "Jayant Shukla" <[email-masked]>
Date: Wed, 26 Feb 2003 09:16:25 -0800

> On Behalf Of Francis Dupont
> Sent: Tuesday, February 25, 2003 4:15 PM
> To: Jayant Shukla
> Cc: [email-masked]; [email-masked]

Hi Francis,

I am not sure I understand what you mean. My explanation is based on the
draft. 

> so as the NAT traversal is in the charter, there is a problem to

fair enough! 

Regards,
Jayant
www.trlokom.com

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 26 Feb 2003 14:04:13 -0500

Yoav Nir wrote:
> Sure you can do L2TP/IPsec with tunnel mode.........

I second this opinion.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Feb 2003 11:32:16 +0100

=> my concern is that I believe the way you fix the checksum will give
a correct checksum from a wrong one, i.e., you loose the detection
of errors which is the purpose of the checksum.
IMHO the checksum must be fixed using the original and new IP addresses,
i.e., you add the original addresses and substract the new addresses
in an one-complement arithmetic (the checksum is the opposite of the
sum of the pseudo-header and the transport message in one-complement.
At the exception of UDP/IPv4, zero is normalized, i.e., +0 is used.
What I propose is a direct application of RFC 1624 which requires
the original addresses).

Regards

PS (for the list): should we be more accurate in IKEv2 draft?
Current text in draft-ietf-ipsec-nat-t-ike-05.txt is:

The original source and destination addresses are used in
transport mode to incrementally update the TCP/IP checksums so that they
will match after the NAT transform (The NAT cannot do this, because the
TCP/IP checksum is inside the UDP encapsulated IPsec packet).

(BTW this text is fine for me, the issue is that it is not in both drafts).

---

From: "Jayant Shukla" <[email-masked]>
Date: Fri, 28 Feb 2003 08:59:50 -0800

> What I propose is a direct application of RFC 1624 which requires

I don't think you need to do what you have explained. Since you will
authenticate and decrypt the packet, it guarantees that you don't have
any flipped bits in the body of the encapsulated data.

If you want, test the checksum before you authenticate/decrypt the
packet.

Regards,
Jayant
www.trlokom.com