[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Clarification of potential NAT multiple client solutions



There are lots of problems with that form of passthru with transport
mode.  Just a couple: 

1. if you have multiple simultaneous connections behind the NAT, the NAT
will have difficulty mapping the unseen spis from the external host to
the outgoing SPI it has seen since it only uses time proximity and no
better smarts.  This problem also exists for tunnel mode passthru.  So
it cannot claim to be an industrial strength solution.
2. Still have the demux issues of multiple clients behind the same NAT
talking to the same external server
3. Still need to modify IKE to get the negotiation to succeed (QM
proxies addrs at least)
4. Still need to deal with the incorrect transport layer xsum

In short, passthru is potentially tolerable for tunnel mode in some
scenarios, but fails pretty badly for transport.

bs


-----Original Message-----
From: Jayant Shukla [mailto:jshukla@trlokom.com] 
Sent: Thursday, August 01, 2002 9:36 AM
To: William Dixon; Brian Swander; ipsec@lists.tislabs.com
Subject: RE: Clarification of potential NAT multiple client solutions 

Hi William,

I am referring to the method used by NAT boxes to let IKE & IPsec
traffic pass through based on cookies and SPI. It is the same method
that caused problem for the earlier version of your draft that required
eight bytes of zeros to be inserted after the UDP header.

Regards,
Jayant
www.trlokom.com 

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of William Dixon
> Sent: Wednesday, July 31, 2002 10:33 PM
> To: Jayant Shukla; Brian Swander; ipsec@lists.tislabs.com
> Subject: RE: Clarification of potential NAT multiple client solutions 
> 
> 
> Jayant, what exactly do you mean by the "ipsec-passthu" technique ?  
> 
> -----Original Message-----
> From: Jayant Shukla [mailto:jshukla@trlokom.com] 
> Sent: Wednesday, July 31, 2002 2:54 PM
> To: Brian Swander; ipsec@lists.tislabs.com
> Subject: RE: Clarification of potential NAT multiple client solutions 
> 
> 
> 
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]
> > On Behalf Of Brian Swander
> 
> 
> > Bottom line is that there are a variety of solutions for this
> scenario.
> 
> o.k.! 
> 
> > 3. upper layer protocol awareness of the inbound & outbound IPsec SA
> > (where it doesn't use source IP and source port as the session
> identifier.
> > E.g. L2TP session ID mapped to the IPsec SA pair which 
> doesn't use the
> UDP
> > source port or source IP address for peer uniqueness)
> 
> Why not just use IPsec pass-thru? Instead of mapping the L2TP 
> ID to the IPsec SA, just use information from the IPsec SA. 
> 
> > 4. application integration with IKE initiation such that it 
> can rebind
> to
> > a different source port if the IKE quick mode SA proposal 
> is rejected
> by
> > the responder, then repropose the new QM selector.  
> Microsoft may have
> 
> > intellectual property rights relating to this implementation
> technique.
> > See the Microsoft IPR notice on the IETF web site for the details.
> 
> Application port negotiation as part of IKE??
> You are not serious, I hope!
> 
> > 6. don't support the scenario of multiple clients behind 
> the same NAT
> > simultaneously.  Simply fail the second attempt at Main Mode or the
> Quick
> > Mode
> 
> So, it is worse than IPsec pass-thru! 
> 
> Using IPsec pass-thru we can support multiple IPsec clients 
> behind a NAT and every single NAT vendor has IPsec pass-thru 
> implemented. 
> 
> What is the advantage of your solution over IPsec pass-thru?  
> 
> Regards,
> Jayant
> www.trlokom.com 
> 
> 
> 
> 
>