RE: IPSec NAT pass-through: how the server distinguish different clients?

[Rajesh Patel <rajeshmpatel@yahoo.com>]

William -

> Raj, what scenario are you talking about ?  Where are the NATs, where
> are the initiators, responders, what is their policy,
tunnel/transport,
> is there app integration with IKE or is it transparent to IKE, is
IPsec
> integrated into the initiator/responder TCPIP stack or is it
> bump-in-the-wire, a mix, etc ?

I am discussing the scenario from Section 5.3 of your draft.  There it
clearly states that the proposal may not work when multiple clients
behind a NAT are communicating with a server using Transport mode.
In my previous e-mail, I explained what will not work.  To me, this
is the *only* scenario of interest, because I cannot think of any
other case that is not solved by the already deployed method of
IPsec pass-thru.  Can you?

> Isn't this the general problem with IKE quick mode SA proposals going
> through a NAT unmodified ?  The NAT's support IKE/ESP passthrough
> doesn't solve that either.  

No it isn't. 

> Even being able to talk to the first-hop NAT
> to learn your external IP doesn't solve the upstream NAT problem.

I did not suggest that. It is not even relevant to my question. The
problem arises because traffic-desc (transport layer port numbers as
IP address is same) may clash between clients that are behind NAT.
What has that got to do with NATs IP address? I think you might be
confusing the check-sum problem with the problem that I have pointed
out. 

> Brian's mail outlined many of implementation techniques possible to
> solve the client behind a NAT problem, which can require work on the
> initiator or responder or both.  

He gave six options:

1) First two have patent issues. 
2) Next two are plain ridiculous. Application level fix in a network
layer
   solution? Tying application to IKE? IPR issues even there!
3) Last two amount to abandoning transport mode.  

> If your complaint is that it isn't perfect solution for IPsec IPv4

My complain is that 50% of your draft is trying to solve a problem that
IPsec pass-thru already solves and remaining 50% of your draft proposes
a solution that does not work! 

Basically your draft requires IPsec vendors to implement stuff the does
not seem to be necessary, considering the proliferation of NATs with
IPsec pass-thru. Versions after Versions of this flawed draft have
been released over the past two years, and we have had to waste our
time and money implementing them. 

> through NATs, then my answer is, yes, but it will help us bridge the
gap
> and secure IPv4 traffic in many scenarios before IPv6 is more
generally
> available.

When are you people going to figure out that NATs are not going to
disappear when IPv6 is deployed?  Whenever that happens.....

Raj

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com