Re: Another NAT Traversal question

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

Actually, on an archeological dig in my
house I found the original NAT-Traversal
internet draft for working with IKEv1 and
there was a payload called NAT-OA which
had the actual IP address (the thing I
said I remembered in my message below).
It was indeed used, as I remembered, for
fixing the checksums.

So why isn't it in IKEv2? Is it an
oversight?

Radia


<radia.perlman@sun.com> wrote:
>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
>