[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Another NAT Traversal question







Ari Huttunen <Ari.Huttunen@f-secure.com> 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).

Francis.Dupont@enst-bretagne.fr 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).