[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: UDP-encapsulated IPsec Transport mode



James,
Will there be any problem if the gateway (or any peer) treats the NATed
public address as the Phase 2 traffic selector, ignoring the private
address sent by client ? Obviously, the private address is of no use to
the gateway. Even the SPD lookup policy is based on the NATed address. 

One other way the authors could have pursued is: the IKE gateway sending
the NATed address (NA) to the client in the Phase 1 as a NAT-NA payload.
This way, the client will get to know of its public address. But since
the NAT-NA can dynamically change, the gateway has to send the NAT-NA
payload every time the NATed public address changes.

-Satyadeva Konduru

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]
> On Behalf Of James Huang
> Sent: Wednesday, November 06, 2002 4:12 PM
> To: ipsec@lists.tislabs.com; 'l2tpext@ietf.org'
> Subject: UDP-encapsulated IPsec Transport mode
> 
> 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).
> 
> Regards,
> James C. Huang
> 
>