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

RE: Towards closure on NAT traversal.



Henrik Levkowetz wrote:
> No. But if one is a vendor attempting to deploy IPsec in gateways
> and on employees machines at home today, it is necessary to find
> a solution which will permit co-existence of IPsec with NATs of
> many varied kinds. In Sweden, where I'm situated, ADSL is being
> rolled out on a wide front, and many households have multiple
> machines which they connect through (at best) the one public IP-
> address they've been given -- or at worst through the one private
> IP-address they've got.
>
> So at least here it's a very real problem, to accomplish consistent
> NAT traversal for IPsec, today, not tomorrow. There's a potential
> customer base with existing equipment here which a commercial firm
> can't ignore. And that equipment is not IPv6 capable.
>

And IPsec over UDP does this job just fine, in fact I am running that on
another machine as I type with a remote X desktop.

> ...<snip>...
>
> > I would not wish fixing IKE on MidCom (independent of
> getting it through
> > a NAT), but the real issue is finding a generalized NAT
> traversal which
> > IPsec can use. If every WG does a one-off, it is less
> likely that any
> > given path will contain the right set of NAT hacks to make any
> > applications work.
>
> Unfortunately, sometimes a generic NAT traversal mechanism may
> not take care of a specific protocol's needs, or may give much more
> overhead than a solution tailored to one specific protocol.

Shades of not-invented-here... Overhead comes in many forms, and the one
that is being overlooked in this thread is the cost of an additional NAT
traversal mechansim that requires implementation resources, testing,
troubleshooting, documentation, memory & disk on every machine...

>
> By using Mobile-IP's NAT traversal, and running IPsec inside a MIP
> tunnel, we can today reliably and consistently accomplish NAT
> traversal for IPsec. IF that is an acceptable solution with acceptable
> overhead, then all we have to do ( >:-} ) is to deploy
> Mobile-IP clients
> and Agents with all IPsec implementations, and the problem is solved.
>
> But how many would find that acceptable as a general solution?

If we didn't already have IPsec over UDP it might be reasonable.

>
> From my understanding of midcom's charter, they will not be looking
> at NAT traversal solutions, but rather will be defining standards for
> applications to talk to middleboxes in order to effect better
> interoperation. This means that any results from midcom will not be of
> benefit for situations where you want to traverse the NATs which are
> already deployed in homes and ISP's today.

But taking some period of time to define something completely new here,
that will take additional time to implement and ship, and may only work
with a subset of existing NATs, is an acceptable approach?

>
>
> Which two other WGs is that?

MidCom & IPv6 transition.