[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: UDP-encapsulated IPsec Transport mode
> -----Original Message-----
> From: Satyadeva Konduru [mailto:skonduru@caymas.com]
> Sent: Friday, November 08, 2002 6:08 PM
> To: James Huang; ipsec@lists.tislabs.com; l2tpext@ietf.org
> Subject: RE: UDP-encapsulated IPsec Transport mode
>
>
>
>
>
> > 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.
>
Satyadeva,
I am not sure. But in Appendix A of the draft, it did mention a
"build-in NAT/NAPT" soultion to solve the multiple clients behind a NAT box
issue. The draft said that SSH/Microsoft has intellectual property rights
to the solution. I am not sure whether the "build-in NAT/NAPT" soultion is
the same as what I described in my previous emails.
- James Huang
>
> > -----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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>