Re: Another NAT Traversal question

[Derek Atkins <derek@ihtfp.com>]

Charlie_Kaufman@notesdev.ibm.com writes:

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

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.

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

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.

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

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
       derek@ihtfp.com             www.ihtfp.com