RE: Towards closure on NAT traversal.

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

Tony Hain wrote:
> 
> Hallam-Baker, Phillip wrote:
> > The IESG should do no such thing. IPSEC needs to fix their
> > protocol.
> 
> There is nothing wrong with the IPsec protocol in an environment that
> doesn't include NAT (read IPv6 here).

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.

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

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?

> 
> >
> > Again it is very clear that what you are really trying to do
> > here is to kill NAT by some bizare IETF machinations. Won't
> > work, been there tried that. All that approach would do is
> > cause the vendors to diverge further.
> 
> No I am not trying to kill NAT, look at RFC-2993 if you still don't
> understand. If I was really trying to kill off NAT, the first thing I
> would do is spin up 50 WGs to create as divergent and demanding a set of
> requirements for implementation as possible. In reality we have MidCom
> trying to figure out a common set of requirements that make it
> reasonable for NAT vendors to implement them. In that context, this
> group should be feeding requirements to MidCom, and leaving the details
> to others.

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

> 
> >
> > I don't think that it is rational to expect NAT + IPSEC to
> > provide greater connectivity than NAT alone. NAT reduces the
> > functionality of IP, IPSEC + NAT currently eliminates the
> > functionality of IP, the objective of IPSEC has to be to
> > get IPSEC + NAT to give equivalent functionality to plain NAT.
> 
> Again, your perspective seems warped. IPsec + NAT doesn't eliminate the
> functionality of IP, NAT eliminates the functionality of IPsec. This
> thread has been about how to remove that blockage, which duplicates the
> work of two other WGs. In those cases their charter is explicitly to
> make it possible to get through NAT, while the charter here is to focus
> on securing the communications path.

Which two other WGs is that?

	Regards,
		Henrik