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

RE: Clarification of potential NAT multiple client solutions



A few things that the solution the current drafts represent make it
better than the NAT supporting IPsec pass-thru that you describe.  While
this link describes the limitations of the full and correctly
implemented IPsec pass-thru solution, there are a few other things to
note:

http://www.impsec.org/linux/masquerade/VPN-howto/VPN-Masquerade-6.html#s
s6.1

1. the requirements for this WG work state that a solution to the IPsec
NAT compatibility problem requires no change to deployed NATs.  

2. while some NATs today do support IPsec pass-thru, they do not all do
it in the same way consistently, and it's certainly not something
customers can depend on in the infrastructure.  Despite the fact that
many (most ?) NATs support a similar method for PPTP pass-thu, I hit the
case all the time while traveling where one doesn't.  Thus #1.  Futher,
our own internal testing of at least 8 or 10 NATs found discrepancies in
their implementation.  We didn't get into the details of the NAT
vendors' code of course, but the different behavior was obvious in the
impact to UDP500 encapsulation, thus we had to move it to another port.

3. NAT IPsec pass-thru has to guess on the inbound ESP SPI association
to the right internal client.  Given #2, this means they may only
support 1 IPsec client behind the NAT, or they have to inhibit a new
outbound IKE Main Mode SA (with responder cookie = 0 specifically) until
they see an inbound ESP SPI they don't recognize.  The requirements
document states that multiple clients behind the same NAT (say a
business scenario) must be able to connect to the same destination IP
address.  The limitation of pass-thru can introduce scaling problems in
this scenario, both with the ability to initially connect and the
ability to rekey Main Mode.  Not all implementations keep the Main Mode
active while quick mode is active.  So a simple quick mode rekey may
drive a new Main Mode.

4. if the NAT solely is responsible for the pass-thru hole, it can time
out the hole.  So keep-alives are required by the client.

5. the likelihood of both NATs supporting a compatible IPsec passthru in
the double NAT case, is low.  And still requires #4.


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