Capwap Mailing List: RE: to mux or not to mux?

[Bob O'Hara (boohara) (boohara]

So, if UDP already provides the equivalent mux functionality, why should
we discard that functionality and try to replace it with something home
grown?  The only argument that seems to hold any water at all is that
this preserves, in some sense, the openssl code.

However, there has also been a statement made that this code needs to be
modified if one wishes to use it and support more than a single WTP at
an AC.

I believe that there are a set of implementations and architectures for
an AC that are precluded by the use of a single tunnel, hidden behind a
home grown mux header.  One of the most easily understood is one that
has been already described in this thread, separate termination of the
control and data tunnels on different devices.

An issue was raised that this architecture, somehow, compromises
security.  That would certainly be true if we have only a single tunnel
carrying both data and control channels that needs to terminate in two
different locations.  However, with separate tunnels for each channel
(UDP port), each channel performs its own authentication and key
negotiation, as well as its own independent encryption and replay
protection.

The whole reason CAPWAP exists is as a result of innovation in the
architecture of WLAN systems by a number of different companies.  I
don't think that we should be considering a proposal for the protocol
that limits the ability of the users of this protocol to continue to
innovate.  If we don't provide the ability for some innovation within
the protocol, all innovation will be done outside the protocol,
resulting in very little, if any, multi-vendor interoperability.

 -Bob
 
-----Original Message-----
From: Charles Clancy [mailto:clancy [at] cs.umd.edu] 
Sent: Wednesday, May 03, 2006 2:29 PM
To: Michael Montemurro
Cc: capwap
Subject: Re: [Capwap] to mux or not to mux?

Even with the MUX header, you have two independent, logical channels. 
If you think about it, UDP is really just one big MUX header.  What 
we're doing is really nothing different.  It should not impact anything 
to do with sequence numbers or key derivation.

-- 
t. charles clancy, ph.d.  |  tcc [at] umd.edu  |  www.cs.umd.edu/~clancy

Michael Montemurro wrote:
> Nancy brings up an interesting point here.
>  
> If we go with the MUX header approach, how do we achieve key
separation 
> between the control and data channels?
>  
> How do we derive the keys and how do we maintain sequence counters.
>  
> Cheers,
>  
>         Mike
>  
> 
> 
>  
> On 5/2/06, *Nancy Winget (ncamwing)* <ncamwing [at] cisco.com 
> <mailto:ncamwing [at] cisco.com>> wrote:
> 
> 
>     I don't believe adding a MUX is the right answer.  First, the
addition
>     is a change in DTLS and also brings up other issues of concern:
>     - distinguishing the control from data plane is a good thing as
the
>     firewall rules may be different for each plane which is already
>     addressed by the UDP assignments.
>     - merging the control and data plane into a single UDP (dtls)
tunnel
>     forces the two planes to be synchronized from an anti-replay
>     perspective. This effectively restricts the architecture to force
them
>     to use a centralized DTLS encapsulation/decapsulation which imho
is too
>     restrictive
> 
>            Nancy.
> 
>     -----Original Message-----
>     From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com
>     <mailto:s.kelly [at] ix.netcom.com>]
>     Sent: Monday, May 01, 2006 11:38 AM
>     To: capwap
>     Subject: [Capwap] to mux or not to mux?
> 
>     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
> 
> 
> 
>
------------------------------------------------------------------------
> 
> _________________________________________________________________
> 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