ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-

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