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

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Wed, 3 May 2006 14:34:11 -0700

Charles, 

With a MUX, yes they are logical channels, but I believe the implication
is that these channels are merged into a single DTLS tunnel...are you
saying they are not?  

But as you state, if UDP is a MUX header, why the need to introduce yet
another one instead of just using UDP for separation?

	Nancy.   

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Wednesday, May 03, 2006 2:29 PM
To: Michael Montemurro
Cc: Nancy Winget (ncamwing); 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.  |  [email-masked]  |  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)* <[email-masked] 
> <mailto:[email-masked]>> 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:[email-masked]
>     <mailto:[email-masked]>]
>     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

---

From: Charles Clancy <[email-masked]>
Date: Wed, 03 May 2006 17:45:11 -0400

The DTLS tunnels would NOT be merged.  You'd have something like:

+---------+------------+------------------------
| UDP hdr | MUX = 0x01 |  DTLS(CAPWAP Control)
+---------+------------+-----------

or

+---------+------------+------------------------
| UDP hdr | MUX = 0x02 |  CAPWAP Data
+---------+------------+-----------

UDP is indeed a MUX header, but it's a MUX header that everything 
already understands.  So, it all comes down to whether or not we want 
intermediate network devices to distinguish between control and data. 
For NAT traversal, it's easier if the NAT treats everything the same, 
and doesn't have to know that the two ports are related.  Same for 
firewall / port forwarding.  I think intermediate network devices should 
treat everything as "CAPWAP", and we should therefore do our own MUX.

---

From: Charles Clancy <[email-masked]>
Date: Wed, 03 May 2006 17:56:12 -0400

Just to clarify, MUXing or not MUXing does not affect security one way 
or the other.  Thus my opinion is as a member of the WG, and not as a 
security advisor.  It apparently affects deployments and 
implementations, which is not my expertise, and thus my comments should 
be weighted as such.

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 3 May 2006 15:16:21 -0700 (PDT)

HI,

Please don't forget about the discovery message. With it,
you have 3 values for MUX. See below..

Also, please note that in the prototype that I'm developing,
I'm using the UNMODIFIED DTLS implementation in openSSL.
That is, adding the MUX header does not require any modification
of the openSSL. By the way,my two wishes are:
1) an Ethereal decode for the below
2) the addition of the NULL encryption type to the
   CAPWAP protocol for debugging

+---------+------------+------------------------
| UDP hdr | MUX = 0x00 |  Discovery Request or Response
+---------+------------+-----------