Subject: Re: [Capwap] New mux header for CAPWAP

From: "Rohit Suri (rsuri)" <[email-masked]>
Date: Fri, 9 Jun 2006 03:02:39 +0530

I have been reading through the conversations on this and I think there
is a bigger issue that has not been considered. Not allowing separation
of data and control plane by using easy to recognize method such as UDP
ports would restrict system scaling. Consider for the moment the fact
that because we are bundling the channels into a single crypto stream,
it will become impossible to separate the control and data planes.

 I understand that this is not currently in the protocol, the reality is
that creating such a restriction today will dictate future systems. The
side effect I believe is being lost is that an AC can only be as fast as
a single DTLS crypto accelerator. As faster 802.11 technologies come
around, such as 802.11n, there will be a need for bigger and faster
systems. In order to solve this, we will in the future have to remove
the MUX and allow for the separation.

I think system scaling is much bigger issue than NAT, which can be
addressed by adding an keepalive mechanism in the data plane. We can
also do this only when we detect a NAT is in play (look at outer IP
address vs. a message element in the protocol). So we can have our cake
and eat it too.

Therefore, I personally feel very uncomfortable crippling future
products to up front protocol development time.

Regards
Rohit

-----Original Message-----
From: Charles Clancy [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 12:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Capwap] New mux header for CAPWAP

For the record, personally I'm in favor of MUX headers.  While I agree
that QoS is an issue, I think NAT traversal is a bigger issue.

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

[email-masked] wrote:
> 
> The CAPWAP editors have asked the Chairs to resolve the Mux vs 
> Multiport issue # 115, in order to progress the specification.  Based 
> on the discussion that has taken place the chairs are in agreement the

> simplest, cleanest solution for this is to add a Mux header.  Barring 
> any unforseen events, we will instruct the editors resolve in favor of

> a new Mux header.
> 
> We intend to close this issue by the end of the week, Friday, 6/9.  
> Please review the issue and send any constructive comments to the list

> by Friday.
> 
> Best Regards,
> Dorothy
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _________________________________________________________________
> 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: Thu, 08 Jun 2006 17:43:10 -0400

Quick comment:  There is not a 1-to-1 correlation between UDP port and 
DTLS session.  We would still have two different crypto streams when 
using the MUX header.

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 8 Jun 2006 15:08:32 -0700 (PDT)

HI,

Did you see and understand the following from my message
from "Thu, 8 Jun 2006 01:47:21 -0700 (PDT)" with
subject "[Capwap] Proposal for CAPWAP packet format":

 NOTE: A CAPWAP MUX header is needed whether or not the same or
        different UDP ports are used for CAPWAP control and
        data messages. This is because both CAPWAP data and
        control messages can be unprotected or protected by
        DTLS, and the MUX header is needed to distinguish
        protected from unprotected. Remember that CAPWAP
        "discovery requests" and "discovery responses" are
        unprotected, and that all other CAPWAP control
        message types are protected.

It does not look like it was factored into your argument.

> products to up front protocol development time.

Regards,
/david t. perkins