RE: UDP-encapsulated IPsec Transport mode

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

>            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


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