Subject: Re: [Capwap] need clarification on UDP ports

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 23 Oct 2006 07:28:35 -0700

> I've been re-thinking my position on this, given that the 
> working group is committed to a multiport approach. Certainly 
> there are multiple ways to solve this, and while I would 
> prefer a solution that didn't involve adding yet more ports, 
> we are where we are.
> 
> That said, I think adding a 3rd port which is only used for 
> discovery operations solves part of the problem.  In that 
> case, the control channel is always DTLS traffic, and we have 
> an unambiguous solution which requires no protocol hacks.

True, and if we decide that hacks are not acceptable, then a third port
is really the only way to solve this one. However, I'd like people to
consider the zero filled DTLS header. Yes, it is "hack-ish", but 
I believe it to be completely workable.

> 
> As for the data channel, it's a little more complex. If 
> hardware vendors must know a priori whether data is protected 
> or not, the only options are either two data ports or a type 
> header, and given the dramatic allergic reactions we've seen 
> to protocol layering beyond the udp header here, distinct 
> ports seem to be the only option on the table. However, if 
> hardware vendors support tuple-plumbing, we can do this with 
> one data port.
> 
> Tuple-plumbing solves the problem by letting the application 
> tell the hardware when a session is protected or not, but you 
> have to look at the source port too. This is part of the 
> problem some of Pat's signalling is meant to solve. Once the 
> AC knows what characteristics a given tuple should have, this 
> can be plumbed into the hardare.

I'm a big believer that the data plane must know apriori the
CAPWAP data plane formats. Regardless, one must validate the
packet to detect erroneous formats, so an implementation that
guards itself against attacks, which folks should be implementing,
will not view this as a deficit.

> 
> This still leaves two problems: associating a NAT'd data 
> channel with the appropriate control channel, and the QoS 
> problem for the data channel. The channel association can be 
> solved by using the session ID, as has been noted numerous 
> times in past threads. One way this could be extended to 
> encompass multiple data channels would be to extend the 
> session ID field, and treat the high-order portion as the 
> session id, and the low-order portion as the channel id 
> (control channel has channel id 0, data channel with no QoS 
> has channel id 1, and so on). Just a thought.

Right, and recall in my proposal that I had proposed two alternatives,
one more complex than the other. The simpler approach was to simply
include a session ID in the CAPWAP header, which was used to
create the correlation between the control and data plane.

> 
> Since there will be initial ambiguity when multiple WTPs are 
> behind a NAT, there are two options:
> 
> 1) don't worry about it; let the WTP establish a DTLS session 
> without knowing which control channel it belongs to, and then 
> get the session binding out of the first protected data 
> packet (which may be an echo) to create the binding; if no 
> packets come within some preset interval, tear down the DTLS session.
> 
> 2) do some inline signalling, as Pat suggested. This could be 
> via a capwap header with some special value, or it could be 
> the text STARTDTLS along with the session/channel id - whatever.

The above alternative requires no inline signalling on the data plane,
and only requires that the session ID be present in the header to help
associate both planes.

This does not, however, also address keeping the NAT table fresh. 
In my proposal, I had included an inline signalling scheme to keep
the session alive, but I now realize there are much simpler methods of
handling this. The WTP could simply send an 802.11 NULL data frame
(either on behalf of a valid station, or some agreed upon MAC address
defined in the CAPWAP standard).

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Hasan Raza" <[email-masked]>
Date: Tue, 24 Oct 2006 09:33:51 -0700

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
Sent: Mon 10/23/2006 7:28 AM
To: Scott G. Kelly; [email-masked]
Cc: capwap
Subject: Re: [Capwap] need clarification on UDP ports

> I believe it to be completely workable.
For that matter any unique pattern of fixed amount of bytes in front
of udp header can work for discovery packets. Why should it be zero filled
DTLS header only? The only restriction on the pattern should be
that it is uniquely different from first fixed bytes of the DTLS header.
All zeros is a good pattern, though. I think zero filled DTLS header
would impose variable header size problems (in future), because version
field would also become zero.

Hasan