Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP

[Tero Kivinen]

Paul Hoffman writes:
> Here is the edited text. Please be sure it is still correct.

There is the same typo my original text had:

> <t>NAT A will then replace the source address of the IKE packet from
> IP1 to IPN2, and NAT B will replace the destination address of the IKE
         ^^^^

This should be IPN1.

> packet from IPN2 to IP2, so when the packet arrives to the server it
> will still have the exactly same traffic selectors which were sent by
> the client, but the IP address of the IKE packet has been replaced to
> IPN1 and IP2.</t>

> <figure><artwork><![CDATA[
> For the responder, when transport mode is proposed by client:
> 
> - Store the original traffic selector IP addresses as real source
>   and destination address in case we need to undo address
>   substitution.

The IP addresses are also needed for the RFC 3948 incremental checksum
fixup in udp encapsulation, not only for undoing the address
substitution. 

> - If the client is behind a NAT, substitute the IP address in the
>   TSi entries with the remote address of the IKE SA.
> 
> - If the server is behind a NAT substitute the IP address in the
>   TSr entries with the local address of the IKE SA.

"Client" and "server" are ok here, but my original text used "other
end" and "this end" at least in our implementation our NAT traversal
detection does tests that way. I.e. it know whether this end and/or
other end is behind nat and knows to enable suitable processing based
on that (i.e. sending of RFC3948 keepalives etc). Client and server
makes this bit more vpn roadwarrior case centric, compared to using
"this end" and "other end".

But either one is acceptable here.
-- 
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec