RE: UDP-encapsulated IPsec Transport mode

[James Huang <james.huang@watchguard.com>]

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

	If these multiple clients use the same private address, then when
the server (LNS) receives an inbound  SCCRQ , it should have chosen a
distinct UDP port number for each client.
           If we take a larger context as you suggested where there is a
server running in the SG listening to a well-known TCP port.  If the above
multiple clients also chose the same TCP port number,  then I agree doing
NAT will not be enough.  In that case, the SG will have to do NAT (on the
inbound source IP address) + dynamic PAT (on the inbound TCP source port)
before passing a decapsulated inbound packet to the server.

-- James

> -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
> > > >
> > > >
> > >
> > >
> > 
> 
>