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

RE: UDP-encapsulated IPsec Transport mode



Satyadeva,

	I thought about NAT-NA too.  But I think the better idea which can
do without NAT-NA is as follows:
(1) The security gateway (SG) will insert entries into its filtering
database based on the traffic selector (ID) specified by the client during
the QM exchange.
(2) After the SG decrypted and decapsulated an UDP-encapsulated IPsec packet
in the transport mode (i.e. removing the outer UDP header and ESP header),
it will modify the source IP address in the outer IP header using the
address in the NAT-OA payload it received in the QM exchange.  

With this scheme, the packet after decapsulation will pass the security
policy at the SG and the checksum in the inner UDP/TCP header no longer need
to be re-computed by the SG as was described in section 3.1.2 in the draft.
Also it will solve the issue of multiple clients behind the same NAT box
described in section 5.3.

The above  is my personal opinion.  I hope the authors of the draft can
provide more clarification.

Regards,
James Huang



> -----Original Message-----
> From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> Sent: Friday, November 08, 2002 2:51 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: 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
> > 
> > 
> 
>