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

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Mon, 1 May 2006 23:24:51 -0700

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]] 
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

---

From: Scott G Kelly <[email-masked]>
Date: Tue, 02 May 2006 07:04:18 -0700

Hi Nancy,

> is a change in DTLS and also brings up other issues of concern:

No, this is a misconception: it is *not* a change to DTLS. It is a 
change to the openssl implementation of DTLS, but the fact is that you 
must demultiplex incoming DTLS messages prior to handing them to openssl 
in any event.

I've said this several times before, but it must not have been clear, so 
let me try to get everyone to focus on this statement:

You *cannot* use the stock openssl implementation without modification 
if you intend to support more than one WTP. You MUST modify it. This is 
NOT a modification of the DTLS spec, it's a modification of the OPENSSL 
IMPLEMENTATION.

I hope that is clear.

This modification is required because openssl was implemented with 
certain assumptions about "servers" that really depend on the tcp 
(connection-oriented) sockets abstraction, and these assumptions were 
naively carried forward into the (datagram) DTLS implementation. I have 
already corrected this in my implementation (and there's at least 2 ways 
to do it without even touching the openssl code), and it introduces 
absolutely no security-relevant concerns.

Nothing is being changed in DTLS. Full stop.

> addressed by the UDP assignments. 

Please explain why firewalls (which ostensibly won't understand 
encapsulated 802.11 traffic) need separate packet filtering rules for a 
data plane that is tightly bound to the associated control channel.

> perspective. 

Huh? Please explain this statement, as I must be missing something. 
LWAPP does this today, and has for, what, over 3 years now?  I don't 
believe this has ever been a problem for LWAPP, but even if it were, it 
would not be for capwap. This is because the proposed mux header is 
outside of the capwap transport layer, and so capwap will not be aware 
of it. It will not interact with antireplay in specification-compliant 
implementation.

> This effectively restricts the architecture to force them

DTLS en/decapsulation is completely independent of the MUX header, so 
this statement makes no sense to me. Am I missing something?

Scott

---

From: "Michael Montemurro" <[email-masked]>
Date: Wed, 3 May 2006 13:43:01 -0400

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

---

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

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:
> On 5/2/06, *Nancy Winget (ncamwing)* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     From: Scott G. Kelly [mailto:[email-masked]
>     <mailto:[email-masked]>]
> ------------------------------------------------------------------------
>