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 5:07 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
> 
> 
> 
> 
> >            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.
> 
> I think you got me wrong here. In my example, the multiple 
> clients with
> the same private addresses lie behind "different NAT gateways with
> different public addresses" and hence a single NAT done by a 
> NAT gateway
> in the middle would suffice. Now as per your earlier suggestion of
> replacing the NATed public address with NAT-OA after UDP decapsulation
> does not make sense here, because, all the clients could possibly have
> the same private addresses and ports.
> 
> -Satyadeva
> 

No, I knew this is exactly what you are talking about.  That is why I said
NAT (on the inbound source IP address) using NAT-OA + dynamic PAT (on the
inbound TCP source port) is needed at the security gateway after
decapsulating the UDP/IPsec header.

- James



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