|Main Archive Page > Month Archives > ipsec archives|
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>
> 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
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. -- firstname.lastname@example.org _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec