RE: Another NAT Traversal question

["Jayant Shukla" <jshukla@trlokom.com>]

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: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of Radia Perlman - Boston Center for Networking
> Sent: Monday, February 24, 2003 8:37 PM
> To: ipsec@lists.tislabs.com
> Subject: Another NAT Traversal question
> 
> 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