[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: UDP-encapsulated IPsec Transport mode

To: "'James Huang'" <james.huang@watchguard.com>, <ipsec@lists.tislabs.com>, <l2tpext@ietf.org>
Subject: RE: UDP-encapsulated IPsec Transport mode
From: "Satyadeva Konduru" <skonduru@caymas.com>
Date: Fri, 8 Nov 2002 18:08:13 -0800
Importance: Normal
In-Reply-To: <989d9ce16ef1ef2b10afa29ecbfd9dfe3dcc61f6@watchguard.com>
Sender: owner-ipsec@lists.tislabs.com



> 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

So, what you are suggesting is that a dynamic PAT be applied between
IP/IPSec layer and the socket layer within a host. Two things:
1) Dynamic PAT will still involve checksum recomputation (however
simple) which you wanted to avoid, right?? 
2) Also, I am not convinced that the solution has to be this complicated
when all you want to know is the Phase 2 traffic selector. NAT-NA
payload type solution seems simple (to me, of course :-))

Anyway, why is the draft silent on this issue?? Either, it is too
obvious to mention or didn't forsee this issue.

-Satyadeva.


> -----Original Message-----
> From: James Huang [mailto:james.huang@watchguard.com]
> Sent: Friday, November 08, 2002 5:17 PM
> To: 'Satyadeva Konduru'; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
> 
> 
> 
> > -----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
> >
> 
> 
> 
> >
> > > >
> > > > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
Prev by Date: RE: UDP-encapsulated IPsec Transport mode
Next by Date: RE: UDP-encapsulated IPsec Transport mode
Prev by thread: RE: UDP-encapsulated IPsec Transport mode
Next by thread: RE: UDP-encapsulated IPsec Transport mode
Index(es):
- Date
- Thread