Re: UDP-encapsulated IPsec Transport mode

[Markus Stenberg <fingon@iki.fi>]

James Huang <james.huang@watchguard.com> writes:
> Hi all,
> 	In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there is
> some discussions on the issue of multiple clients running UDP-encapsulated
> IPsec transport mode tunnels behind a NAT box.  However, I did not find any
> discussion on another related issue:  In the traffic selector (ID) payload
> the client sends out during quick mode exchange, should the client use its
> own private address or the public routable address (i.e. the NAT box's
> public IP address)?  If it the later, how does the client know about that
> public address?  This seems to be a serious issue, especially for L2TP
> voluntary tunnels secured by IPsec (in transport mode).

L2TP specific issues I am blissfully unaware of; however, because the NAT
boxes are not neccessarily even controlled by the IPsec user, sending the
public address is not really an option that can be supported everywhere.

Here's how the information flow goes as far as I see it:

 Public address doesn't really need to be sent in any case as the remote
 side's public address is the address we're talking IKE with (or at least
 remote address+port combination, but in NAPT case you don't really have
 more of an remote address in any case).

 Private address that is used by the OS for actual traffic is provided
 within the NAT-OA payload so the checksums et al can be corrected.

Therefore, at least as far as implementation I used to work on goes, ID
payload in transport mode case doesn't matter (I seem to recall we sent
private address, but pretty much ignored what was sent by remote).

-Markus

> Regards,
> James C. Huang

-- 
"Every program has (at least) two purposes: the one for which it was
written, and another for which it wasn't. "

>From ACM's SIGPLAN publication, (September, 1982), Article "Epigrams
in Programming", by Alan J. Perlis of Yale University.