| Main Archive Page > Month Archives > ipsec archives |
Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP
From: Paul Hoffman <paul.hoffman_at_nospam>Date: Mon Sep 21 2009 - 14:24:30 GMT
To: Tero Kivinen <kivinen@iki.fi>
At 2:49 PM +0300 9/21/09, Tero Kivinen wrote:
>The IP addresses are also needed for the RFC 3948 incremental checksum
>fixup in udp encapsulation, not only for undoing the address
>substitution.
As I said in my earlier note, I have removed all discussion of RFC 3948 from this new text. RFC 3948 is for IKEv1 only, and is not relevant here.
> > - 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.
I changed to "client" and "server" to match the figure. Let me know if this is not OK.
--Paul Hoffman, Director
--VPN Consortium
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec