RE: Towards closure on NAT traversal.

["Henrik Levkowetz" <henrik@levkowetz.com>]

Tony Hain wrote:
> 
> 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.

Excellent! Does that mean that the job is done and the solution
standardized? If we have a consistent IPsec over UDP mechanism,
that's fine by me. I'm outta here if the job's done.

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

I don't understand what you mean to say by that.

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

Additional to what? If you mean additional to a functioning IPsec over
UDP standard, I fully agree. The IPsec over UDP drafts were the starting
point for our MIP over UDP work, but are they complete and progressing?
My impression was that there's some hesitancy here, but I could be
woefully wrong; if so, my apologies.

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

Ok

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

Mmm, are you talking of codifying IPsec over UDP, or inventing something
different? I don't think anything different is needed, but I think that
IPsec over UDP belongs here and would be acceptable.

> 
> >
> >
> > Which two other WGs is that?
> 
> MidCom & IPv6 transition.

Sorry, no sale. Midcom is not doing NAT traversal, and IPv6 is not doing
NAT traversal except possibly indirectly, and that's not for currently
deployed NATs today.

	Regards,
		Henrik