Re: Another NAT Traversal question

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   Whether to support transport mode through a NAT is a fair question.

=> 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.

   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.

=> 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.

   > 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.
   
=> 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
   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.

=> 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

Francis.Dupont@enst-bretagne.fr