RE: Clarification of potential NAT multiple client solutions

["Jayant Shukla" <jshukla@trlokom.com>]

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of William Dixon
> Sent: Thursday, August 01, 2002 9:58 AM
> 
> 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-Masquerad
> e-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.  
> 

	The requirement of the working group also states that IKE cannot

	be modified. 


> 2. while some NATs today do support IPsec pass-thru, they do 
> not all do it in the same way consistently, 

	Can you explain what you mean by consistently? Any solid
observations
	that you can use to back up this claim?

	Over the last 1-2 years NAT vendors have learned a lot about
IPsec
	pass thru and some of the earlier bugs have been fixed through
	firmware upgrades. 

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

	PPTP never got standardized, so what you do expect? PPTP is 
	published as informational RFC in IETF, and I think it is
	unreasonable of you to expect NAT vendors to support
non-standard
	protocols. 

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

	You have not explained what this inconsistency is?! Did you
	check for firmware upgrades with those vendors? In our
	experience, we saw a more uniform behavior from varous NATs and 
	we tested NATs from seven different vendors. 


> 3. NAT IPsec pass-thru has to guess on the inbound ESP SPI 
> association to the right internal client.  

	It can be done systematically and does not have to be a guess. 
	See my explanation down below or read the link you sent.

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

	This is not true! You do realize that IKE sessions can be 
	demultiplexed based on cookies?

	For IPsec messages, all the NAT gateway has to do is to allow 
	the first outbound IPsec packet and inhibit new outbound IPsec 
	connections until the first host to start an IPsec connection 
	receives a reply. 
	
	At that moment, the gateway knows the SPIs for that host's IPsec

	connection unambiguously. 

	Continue this until all clients have IPsec session established. 
	This can typically be done very fast and other clients should
not 
	see any significant delay. 

	BTW, it is explained very well in the link you sent.


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

	IPsec pass-thru can enable multiple IPsec clients behind a NAT.

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

	This statement is grossly misinformed. Why do you keep bringing 
	Main mode into this? See my explanation of how IPsec and IKE 
	connections are de-multiplexed. 


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

	Not a valid arguement. Time-outs are absolutely necessary and
you 
	must live with them. Even if a time out occours, IPsec pass thru
	mechanism should re-establish the connection. 

	In fact, your approach also is also faced with the time-out
problem 
	and needs keep-alives. 
	

> 5. the likelihood of both NATs supporting a compatible IPsec 
> passthru in the double NAT case, is low.  And still requires #4.
> 
	This is very interesting! Are you saying that your method
enables
	multiple initiator and responders to be behind NATs and still
communicate
	to each other? If so, please explain. 

	My guess is that you have a VPN gateway behind the other NAT
that sits
	in the DMZ. All IKE/IPsec packets reach this gateway and
therefore
	no demultiplexing is required.


Regards,
Jayant
www.trlokom.com