Subject: Re: [Capwap] to mux or not to mux?

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 1 May 2006 12:00:10 -0700 (GMT-07:00)

T. Charles Clancy wrote:

>I think another drawback of the MUX header is that stock DTLS 
>implementations will likely already have support for running over plain 
>UDP.  Thus any CAPWAP DTLS implementation might be a little less 
>out-of-the-box.  Of course, CAPWAP will need to muck with the DTLS state 
>machine on a low level anyway, so it's unlikely any implementation would 
>work out-of-the-box.
>
>That being said, I'm personally in favor of the MUX header.

Actually, stock DTLS implementations (openssl in particular) can't handle multiple clients on a single socket "connection" without adding some intermediate de-muxing anyway, so as you say, it won't work out-of-the-box regardless.

FWIW, I already have mux header code running with openssl. It was pretty straightforward to implement.

--Scott

>--
>t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
>
>
>On Mon, 1 May 2006, Scott G. Kelly wrote:
>
>> Some time ago, I proposed that we use a single port for capwap, and 
>> insert a mux header right after the UDP header to differentiate between 
>> control and data. While there was some discussion, we did not reach a 
>> conclusion.
>>
>> Here's what it would look like:
>>
>> +---------+-------------+-------------------------------
>> | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet ....
>> +---------+-------------+----------------------
>>
>> The capwap editors are currently working hard to produce the 01 version 
>> of the capwap document, and it would be best for implementers if this 
>> question could be decided prior to publication of that document. To 
>> facilitate this, I've summarized briefly below.
>>
>> Using separate ports for control/data has a number of drawbacks:
>>
>> - if firewalls are between the AC and WTP, multiple rules are required
>>
>> - we must be able to explicitly bind the data and control channels at 
>> the AC in order to ensure proper operation; if they use the same port 
>> (and therefore, flow), this is straightforward; if not, we must add 
>> protocol elements for detecting and accounting for NATs along the AC-WTP 
>> path, and for explicitly (and securely) creating the bindings between 
>> the two channels
>>
>> - there are race conditions that must be dealt with; in particular, it 
>> is possible to have the left hand (control channel) not knowing for 
>> certain what the right hand (data channel) is doing (and vice versa)
>>
>> - If there *are* NATs along the path, using two ports will require 
>> keepalives on both ports, and error handling for when one channel goes 
>> away but the other does not (e.g. if a middlebox deletes the NAT 
>> bindings for any reason)
>>
>> - there are many more error conditions to manage in the state machine, 
>> due to the channel binding and NAT issues
>>
>> Clearly, using two ports adds *significant* complexity to the 
>> implementation, and will likely result in operational problems in some 
>> environments.
>>
>> Using a mux header has one drawback (that I can think of):
>>
>> - it adds n bytes to the header. I'm tempted to say n will be 4 for 
>> 32-bit alignment, but it could also be only 1 or 2 bytes, if 
>> bits-on-the-wire overhead is an overriding concern.
>>
>> Using a mux hader has several advantages:
>>
>> - we get NAT traversal for free, by simply configuring the echo interval 
>> to be smaller than the NAT binding lifetime for the path in question
>>
>> - we only open one port through intermediate firewalls (and any 
>> intermediate NATs)
>>
>> - the implementation (state machine, error handling) is *much* simpler, 
>> and therefore more likely
>>  to (inter)operate according to spec
>>
>> We need to decide on this, preferably within the next day or two. Please 
>> speak up and make your preferences known.
>>
>> Thanks,
>>
>> Scott
>>
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
>>
>> Archives: http://lists.frascone.com/pipermail/capwap
>>

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

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Mon, 1 May 2006 15:15:10 -0400

Scott, Charles,

For the reasons below, I'm in favor of using a MUX header to distinguish
control from data traffic versus using separate ports.

Cheers,

          Mike

On 5/1/06, Scott G. Kelly <[email-masked]> wrote:
> Actually, stock DTLS implementations (openssl in particular) can't handle
> multiple clients on a single socket "connection" without adding some
> intermediate de-muxing anyway, so as you say, it won't work out-of-the-box
> regardless.
>

---

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 3 May 2006 07:54:04 -0700

Scott, Charles,

I am also in favor of using the MUX header to distinguish control and data
traffic
versus using separate ports, for the reasons Mike references, and for the
simplicity of the solution overall.

Dorothy

On 5/1/06, Michael Montemurro <[email-masked]> wrote:
> > Actually, stock DTLS implementations (openssl in particular) can't
> > handle multiple clients on a single socket "connection" without adding some
> > >t. charles clancy, ph.d.  |  [email-masked]  |   www.cs.umd.edu/~clancy<http://www.cs.umd.edu/%7Eclancy>
> > >
> > >