Re: Another NAT Traversal question

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

 In your previous mail you wrote:

   > => 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).
   > 
   
   I don't think you need to do what you have explained.

=> I need it if I consider the transport layer is independent.

   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.
   
=> the transport checksum is between transport layers. If I believe
in your argument, it is impossible to get errors as soon as packets
don't go through a link without CRCs... This is contrary to real
world experiences where bad TCP checksums occured on an Ethernet link...
 IMHO we should not violate the principle of layer separation here.

   If you want, test the checksum before you authenticate/decrypt the
   packet.
   
=> how? the checksum is ciphered.

Regards

Francis.Dupont@enst-bretagne.fr

PS: about NAT traversal for IKEv2, I always follow Tero Kivinen's I-D
(draft-ietf-ipsec-nat-t-ike-05.txt) which is a complete and already
used (i.e., experimentally proved) specification.