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