Subject: nat-t issues (was Re: [Capwap] a necessary and sufficient capwap base protocol)

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 29 Mar 2006 13:01:57 -0500 (EST)

Hi Pat,

In the interest of clarity, I'm breaking out a few of the issues in this thread so we can deal with them individually. Comments inline below...

> > Historically, new _tunneling_ protocols are not NAT-able
> > until either the protocols are somehow extended or the market
> > reaches a critical mass, and middlebox vendors are forced by
> > their customers to accommodate the protocols.
> 
> Umm... L2TP was absolutely NAT-able from day one without any ALGs
> required
> on the NAT device. LWAPP used many of the concepts from this
> protocol in
> its early designs.
> 

I was overly general in my statement above - I agree that l2tp does do pretty well with NATs in general these days, though there actually were issues with some NAT implementations dropping fragments in the early days. But, those issues are not there for modern gear. 

We didn't start having problems with l2tp and NAT until we tried to combine it with IPsec. One of the primary reasons for this was that at that point, we began trying to manage two related datagram channels through a nat, not just one. Sound familiar?

If you read on to what I said just below, that gets to the heart of it:

> > LWAPP, as it stands, already runs over one port with a MUX
> > header. This, in conjunction with the built-in heartbeat
> > (echo request/reply), suggests that it should work as-is in
> > some simple NAT scenarios. However, the IPsec group dedicated
> > 2 RFCs to this problem, suggesting that it is not really all
> > that simple. Still, if you could share the details of the
> > scenarios in which it *is* currently working, that might help
> > to clarify how much remains to be done. If we are willing to
> > stick with one channel and a mux header, maybe we can deal
> > with simple nat-t in the base spec, and worry about more
> > complex scenarios in follow-on work.
>
> I don't argue that IPSec had multiple specs for this purpose, but
> again,
> L2TP designed their
> protocol from the get-go with NAT in mind - and it does work. If we
> decide to push this off,
> then we will end up with the multiple specs defining possible
> changes to
> the base spec to
> support NAT environments.
> 
> NAT was a recommendation by the eval team that I agree we need to
> pursue.

In actuality, the IPsec group dedicated *3* RFC's to this problem, if you include the ipsec-nat requirements doc (RFC 3715), and NAT'd l2tp/ipsec was one of problem areas those RFCs were trying to address. I think there are two critical distinctions we must recognize in order to get this dialog off of square 1:

- the current lwapp implementation is getting some traction in NAT environments right now precisely because it multiplexes data and control messages over one channel

- we have a proposal on the table to run these channels over separate datagram ports; this introduces all of the issues IPsec had to deal with; and the IPsec folks, after thinking long and hard about this, solved the problems by putting both channels onto one port (doh!)

Bottom line: we can probably solve most NAT traversal issues by simply using a mux header, rather than two ports, (and this ignores other issues we'll have with the two-port approach, which I'll address in another email)

Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap