RE: UDP-encapsulated IPsec Transport mode

["Satyadeva Konduru" <skonduru@caymas.com>]

James,
Your suggestion will only "bypass" NAT but it will not "traverse" NAT.
My understanding is that the SG should see only the NATed public
address. If you take the transport mode in a larger context (not just
L2tp/ipsec), let us suppose there is a host accepting TCP connections.
As per your suggestion, if you replace the NATed address with NAT-OA,
there would be multiple TCP connections from different clients (all with
the same private address) mapping to the same socket pair.

-Satyadeva. 

> -----Original Message-----
> From: James Huang [mailto:james.huang@watchguard.com]
> Sent: Friday, November 08, 2002 3:26 PM
> To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: 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
> > >
> > >
> >
> >
>