Subject: Re: Another NAT Traversal question

From: [email-masked]
Date: Fri, 28 Feb 2003 23:11:07 -0500

Ari Huttunen <[email-masked]> wrote:
> Francis Dupont wrote:
> >    >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.
> >
> > => 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.
>
> 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.

IKEv2 certainly hasn't given up on transport mode (though I share with
others some skepticism concerning its value).

Whether to support transport mode through a NAT is a fair question.
It will add some complexity to the ESP implementation because
on decapsulation ESP would have to adjust the TCP checksums because
they are based on the IP addresses that the NAT changed but the
NAT can't fix the checksums because they are encrypted.

My vote would be to just say no to using transport through NATs,
but it isn't that hard to specify. The spec currently says that
tunnel mode is mandatory to support and transport mode is optional,
so an implementation could choose to not support transport mode
over NATs without losing interoperability (though it would lose
performance).

[email-masked] wrote:
>
> 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).

You're right. I thought I'd copied that text to
draft-ietf-ipsec-ikev2-05.txt, but I see that it's not there. The spec as
it stands is not incorrect, but fails to specify how you're supposed to
compute and adjust the TCP checksums for transport mode through NATs.

But looking at it again here, I don't think this works. If the TCP checksum
is computed based on the addresses the sender of the packet sees, then
packets going from the node with real addresses destined for the node with
NATed addresses will have a TCP checksum computed based on the source
address of the node with the real address and the destination address of
the IPsec gateway. To adjust the checksum, the receiver would have to know
the address of the NAT box, but I believe that as currently specified in
both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know the IP
address of the NAT box. How does this work in deployed systems?? We could
add more fields, but I have an alternate proposal:

The traffic selectors have to contain the IP addresses of each node as
known to the node itself. What if we said that if you use NATed transport
mode, you have to compute and verify the TCP checksums using the addresses
in the traffic selectors. That way the NAT-OA payload is not needed and the
above problem is solved.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "Jayant Shukla" <[email-masked]>
Date: Sat, 1 Mar 2003 22:14:12 -0800

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of [email-masked]
>

I agree!

> address of the node with the real address and the destination address
of

You are correct and transport mode NAT traversal only works with L2TP or
if there is only one host behind the destination NAT. Another reason to
kill it because it is not a general solution.

> both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know
the
> IP
> in the traffic selectors. That way the NAT-OA payload is not needed
and
> the

Good suggestion! Now you are moving in the direction of our method. :-)
Regarding how it works in deployed systems! A more general version of
your proposal is in our product and there are tens of thousands users
using it in all kinds of situations. 

You will realize that using the IP address of the node as known to node
itself is not good either as there may be IP address conflict between
road warriors. Take a look at the free version of our product to see how
we have solved the problem. 

Anyway, we have addressed all possible deployment scenarios except for
mobile IP. We are hard at work to address that. Unfortunately, there are
only 24 hrs in a day. :-)

IMHO, killing the current transport mode with NAT traversal is very
important. Especially if one is concerned about efficiency, security,
and QoS for applications like VoIP. There is no need for a solution that
is not covered by another solution and at the same time creates
obstacles in deployment of many important applications and a better
solution.

Regards,
Jayant
www.trlokom.com

---

From: Francis Dupont <[email-masked]>
Date: Sun, 02 Mar 2003 15:00:55 +0100

In your previous mail you wrote:

=> personally I have no interest in NAT traversal (my objective is
to reconcile IPsec with mobility and multihoming) so I use Tero's
draft as the state of art for NAT traversal. There is in it a simple
solution for transport mode through a NAT so I can't see a good reason
to give up on it.

   My vote would be to just say no to using transport through NATs,
   but it isn't that hard to specify.

=> I agree: if the burden is small enough, just keep it.

   The spec currently says that
   tunnel mode is mandatory to support and transport mode is optional,
   so an implementation could choose to not support transport mode
   over NATs without losing interoperability (though it would lose
   performance).
   
=> NAT traversal itself is optional.

   drafts).

=> I am afraid the spec as it stands is incorrect, but not about this point.

   But looking at it again here, I don't think this works.

=> I disagree but we have a procedure point here: can we assume that
the draft-ietf-ipsec-ikev2-05.txt works and just imports the NAT traversal
stuff from it with as little as possible changes (i.e., no spurious
change :-)?

   If the TCP checksum
   the IPsec gateway.

=> which IPsec gateway? It is transport mode.

   To adjust the checksum, the receiver would have to know
   the address of the NAT box, but I believe that as currently specified in
   both IKEv2 and NAT Traversal for IKEv1, the NATed node does not know the IP
   address of the NAT box. How does this work in deployed systems??

=> the node which is at the good side (i.e., not behind) of NATs knows
the real address of the other node. There are two equivalent ways to
implement this:
 - exchange the real address with the NATed address when packets go
   between the network (where IPsec is) and transport layers. Theorically
   this is the best because the PCB will get the real address but it is
   hairy to implement.
 - adjust the transport checksum when packets go between the network and
   transport layers. This is the solution described in Tero's draft.
   Note that this is an "incremental update", not a recomputation,
   so the checksum is still end-to-end between the transport layers of
   the two peers.

   We could add more fields, but I have an alternate proposal:

=> I prefer Tero's draft one because it is proved to work.
In fact, I propose to discuss this in Tero's draft context only.
   
Thanks

[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 03 Mar 2003 11:37:07 -0500

> NAT can't fix the checksums because they are encrypted.

Yes, but it's just an incremental update.  For the record, the ESP
code to handle this for both TCP and UDP is approximately 60 lines of
C, and is based on having a NAT_OA payload during the phase-2
exchange.

> add more fields, but I have an alternate proposal:

It works by just completely recomputing the checksum rather than
incrementally recomputing the checksum if you don't have a NAT-OA.
Sure, it takes more time to do this, but it means you don't need to
know the NAT's external IP Address.  Besides, when you're using IPsec
(especially with authentication), the UDP/TCP checksums are generally
irrelevant.

> in the traffic selectors. That way the NAT-OA payload is not needed and the

Which problem?  The problem of not being able to _incrementally_
update the checksum?  I'm not convinced it's a major issue, having
implemented the logic to do this.

>           --Charlie

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com