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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Jun 2006 07:52:59 -0700

Dorothy,
 
I'm somewhat surprised by your conclusion. While some vendors have
claimed that adding the MUX is simpler, folks more familiar with
Ethernet switches and routers than the ones that have come up with this
proposal, including folks that have to deploy them (read: customers),
have stated on this list that this feature will make it very complex to
run CAPWAP in their networks.
 
So once more, I will state my concern. Let's assume that a branch office
is connected through a WAN. The WTP will mark packets as it sees fit,
but given that all CAPWAP packets are encrypted, there is no way for the
enterprise customer to specify what QoS properties to apply to LWAPP
control, IEEE 802.11 management and data frames on the WAN router. The
only thing one can do is let the WTP apply the labels, but these labels
may be inconsistent with the QoS policies used in all of the other
applications used by the customers. The reality is that the CAPWAP
protocol is timing sensitive, especially as it comes to control, and
802.11 management packets. 
 
So in order to deploy CAPWAP, they have to change their network wide QoS
policies across all of their infrastructure.
 
How can this possibly justify taking the easy route? How does this
decision benefit the internet community?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: Tuesday, June 06, 2006 6:45 PM
	To: [email-masked]
	Subject: [Capwap] New mux header for CAPWAP

	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

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 7 Jun 2006 10:16:28 -0700

Dorothy,

This decision to use a mux header is quite different from my
recollection of the consensus on this issue.  In the spirit of open
standards development, can you document the chairs' discussion and how
you came to this decision?  If this decision is your assessment of rough
consensus in the working group, I fear your math is severely flawed and
ask that you document those you feel favor this mux header and those
your feel do not.

 -Bob

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 06, 2006 6:45 PM
To: [email-masked]
Subject: [Capwap] New mux header for CAPWAP

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 7 Jun 2006 19:16:41 -0400 (EDT)

Comments inline below...

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Jun 7, 2006 10:52 AM
>To: [email-masked], [email-masked]
>Subject: Re: [Capwap] New mux header for CAPWAP
>
>Dorothy,
> 

Hmmm - a contest about who knows how much about which gear?  Now there's a rathole, and surely we have more productive things to discuss? Moving on... as for customer testimonials, I think we saw one post claiming that ISPs wouldn't trust customers to do their own QoS marking on their own private WAN links vs one customer who suggested that the multiport approach would be problematic for firewall configuration. Not exactly a groundswell.

>but given that all CAPWAP packets are encrypted, there is no way for the

Since when are all CAPWAP packets encrypted? Last time I read the draft, only the control PDUs required encryption. If granular QoS is needed for the data channel, then either you don't want to encrypt it, or you want the encryptor to do the marking.

>applications used by the customers. 

There is no reason why vendors can't provide the configuration knobs for this, so I must be missing something, because it sounds like your concern is that the customer will configure the AC/WTP to apply labels which are inconsistent with his own QoS policies...

> The reality is that the CAPWAP

But this raises an interesting point: if it's so sensitive that it may not work right in this configuration, why choose this architecture to begin with? This is not the only option. More below...

>decision benefit the internet community?

There are many ways to build networks, and some work better than others. Obviously, splitting capwap across WAN links that have congestion problems is going to be problematic, and for the reasons you mentioned above (i.e. that the encapsulated data will likely have QoS granularity requirements of its own which cannot be addressed by using a separate UDP port for all data), this sounds like an architecture to be avoided.

I spent the morning talking with ISP folks and traffic engineers. The first question that came up was, "do you expect to have congestion problems on that WAN link?", and when I responded "apparently", I was asked "why don't you just add enough bandwidth to resolve this?". When I replied that maybe it was because that would cost too much money, the next question was, "if you are afraid that you'll be losing timing-sensitive capwap packets, what's happening to the application data in your data channel? Don't you need granular QoS on that as well? If your classification is only 5-tuple based, how will you classify those when they all use the same <capwap data channel> port?"

It went on and on like that.  The last question I was asked: "Why would you even try to *build* a network like that?"

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 8 Jun 2006 09:56:18 -0700

> Since when are all CAPWAP packets encrypted? Last time I read 
> the draft, only the control PDUs required encryption. If 
> granular QoS is needed for the data channel, then either you 
> don't want to encrypt it, or you want the encryptor to do the marking.

If packets are traversing a WAN, they may need to be - even if it's 
802.11i...

> There is no reason why vendors can't provide the 
> configuration knobs for this, so I must be missing something, 
> because it sounds like your concern is that the customer will 
> configure the AC/WTP to apply labels which are inconsistent 
> with his own QoS policies...
... In which case there's no way for the WTP to even know what's
inside the packet, ergo it can't even do any packet classification.
The best it can do is management vs. data. Many customers want/expect
to be able to provide some classification of packets based on
applications.

However, if we want to allow the WTP to perform packet classification,
we have more protocol work to do.

> There are many ways to build networks, and some work better 
> than others. Obviously, splitting capwap across WAN links 
> that have congestion problems is going to be problematic, and 
> for the reasons you mentioned above (i.e. that the 
> encapsulated data will likely have QoS granularity 
> requirements of its own which cannot be addressed by using a 
> separate UDP port for all data), this sounds like an 
> architecture to be avoided.
WAN links do get congested. These are not fiber links. There's
frequently more data than bandwidth available...

> I spent the morning talking with ISP folks and traffic 
> engineers. The first question that came up was, "do you 
> expect to have congestion problems on that WAN link?", and 
> when I responded "apparently", I was asked "why don't you 
> just add enough bandwidth to resolve this?". When I replied 
> that maybe it was because that would cost too much money, the 
> next question was, "if you are afraid that you'll be losing 
> timing-sensitive capwap packets, what's happening to the 
> application data in your data channel? Don't you need 
> granular QoS on that as well? If your classification is only 
> 5-tuple based, how will you classify those when they all use 
> the same <capwap data channel> port?"

So your premise appears to be "If we can't do it perfectly, it
is not worth doing at all". An interesting approach, but let's 
look at the side effect here. If the data frames are dropped, then
it's the station's responsibility to retransmit - inconvenient, but
not critical. However, if the CAPWAP control frames are dropped, then
the whole CAPWAP session drops. That's an expensive price to pay for
taking the easy way out.

Pat Calhoun

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 8 Jun 2006 15:33:20 -0700 (GMT-07:00)

Hi Rohit!

>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 think you may have misunderstood: the data and control channels will not be bundled into a single crypto stream (not ever, in my view). Even if someone implements data channel encryption, it will almost certainly have to be independent of control channel encryption in all cases. My gut feeling is that there would be serious operational issues otherwise in terms of anti-replay and other channel interactions. I suppose it's possible that there is *some* scenario where you could combine the two - but I don't currentlly believe this could be done in general for capwap.  

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

Like I said, the channels won't be bundled together. Also, this and previous posts make me think there's a fundamental misunderstanding about DTLS.  This is really important to understand: DTLS does not care what sort of transport is underneath. It is oblivious to whether it runs over UDP, GRE, TCP, SMTP (yes, you could even send dtls records in emails), or CAPWAP... whatever. It is completely transport-agnostic.

That means you could multiplex virtually any number of DTLS sessions over the same transport session (e.g. using the same UDP port), and then demultiplex them at the receiving side.  This is true whether your transport is UDP or even ethernet, for that matter.  

Any DTLS crypto accelerator will have to be able to handle mutliple simultaneous DTLS sessions (just like SSL/TLS accelerators).  Some will be capable of doing their own session lookup based on the record header, but even for the cheapest ones (which ostensibly would not be used in high end systems),  it is a simple matter for the receiving AC to distribute independent dtls streams to parallel crypto accelerators, and contrary to what we've heard on this list,  software, fpga's, and network processors are all well-suited to and commonly used for such tasks. Also, FPGAs and network processors which can be used for this purpose are commonly included in ACs available on the market today.

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

I don't know. I get the impression that what we are actually being asked is to cripple the protocol in order to match up with past products (i.e. those legacy switching products that can only classify based on ports). I must admit, I'm kind of surprised by such arguments, given the rich classification capabilities described by NBAR. 

Anyway, I don't think there really are scaling issues, unless we are constrained to combining AC functionality with legacy switching gear. Otherwise, there is nothing to prevent us from building systems which meet our needs as throughput climbs. And as someone else pointed out in a related discussion, "the purpose of capwap is not to make <ACs> cheaper" - I substituted ACs for APs, but I don't think anything is lost in translation. 

Scott

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Thu, 8 Jun 2006 15:35:50 -0700

Hi Dorothy,
 
As stated already by others, this decision will present serious issues,
QoS as a for instance in using a MUX versus UDP.  I will also restate
that there will be security implications as we use the MUX and how that
interacts with the DTLS encapsulation.  If we believe the MUX is used to
differentiate between data and control plane, then we need to make sure
that it doesn't impede or lend any new vulnerabilities on how we apply
DTLS.  Having a single secure tunnel for both data and control plane
will at minimum restrict the CAPWAP architecture and present potential
packet ordering issues between the two to make the security work. 
 
There is greater merit in keeping the separation via the use of distinct
UDP ports.
    Nancy.

Best Regards, 
Dorothy

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 8 Jun 2006 15:46:36 -0700 (GMT-07:00)

Hi Nancy,

-----Original Message-----
>From: "Nancy Winget (ncamwing)" <[email-masked]>
>Sent: Jun 8, 2006 3:35 PM

This is sheer and utter nonsense. DTLS is entirely oblivious to the transport encapuslation. There are no security implications to consider based on the choice of UDP vs any other transport.

You guys keep talking about a single tunnel for data and control, but you are the only ones talking about this - it is not in the draft, and it has never been proposed. Bundling capwap control and data together is not and *cannot be* the plan. Let it go.

I hope this doesn't sound rude, because I don't mean it that way - but I do mean to forcefully convey that we are wasting our time and energy debating a non-existent issue.

Scott

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Thu, 8 Jun 2006 16:19:18 -0700

I disagree....if it is independent of transport encapsulation then why
for example is it DTLS vs. TLS?  We chose DTLS because it uses the UDP
model....we are now tweaking this by introducing the concept of a MUX.
Having lived through the WEP debacle, I am merely stating that there may
be repercusions that need further analysis.

I do not believe this is a non-existant issue, nor is it nonsense to
those trying to analyze the security behind CAPWAP.  It is something I'm
highlighting as complicating the analysis....maybe not for you, but it
will to those analyzing the security of this.  

   Nancy.

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 3:47 PM
To: Nancy Winget (ncamwing); [email-masked];
[email-masked]

Hi Nancy,

-----Original Message-----

>interacts with the DTLS encapsulation.  If we believe the MUX is used 
>to differentiate between data and control plane, then we need to make 
>sure that it doesn't impede or lend any new vulnerabilities on how we 
>apply DTLS.  Having a single secure tunnel for both data and control 
>plane will at minimum restrict the CAPWAP architecture and present 
>potential packet ordering issues between the two to make the security
work.
> 
>There is greater merit in keeping the separation via the use of 
>distinct UDP ports.
>    Nancy.

This is sheer and utter nonsense. DTLS is entirely oblivious to the
transport encapuslation. There are no security implications to consider
based on the choice of UDP vs any other transport.

You guys keep talking about a single tunnel for data and control, but
you are the only ones talking about this - it is not in the draft, and
it has never been proposed. Bundling capwap control and data together is
not and *cannot be* the plan. Let it go.

I hope this doesn't sound rude, because I don't mean it that way - but I
do mean to forcefully convey that we are wasting our time and energy
debating a non-existent issue.

Scott

---

From: "Kraus, Michael" <[email-masked]>
Date: Thu, 8 Jun 2006 18:24:41 -0500

Greetings!

Before saying that going to a mux header is the simplest/cleanest, I would
suggest reviewing the original objectives of this WG.  From 5.1.2 of the
objectives:

>   Protocol Requirement:
>
>   The CAPWAP Protocol MUST define transport control messages such that
>   the transport of control messages is separate from the transport of
>   data messages.

How is transport defined?  To me, a mux header merely identifies control vs.
data but does not provide a separate transport mechanism (more on this below).

>   Motivation and Protocol Benefits:
>
>   The aim of separating data and control aspects of the protocol is to
>   simplify the protocol.

This is where a MUX header makes sense, since it mitigates the NAT traversal
concern (rather than adding a keep alive type of functionality, which would
somewhat increase overhead/complexity).

>  It also allows for the flexibility of addressing each type of traffic in the
most appropriate manner.

With a MUX header, the network devices will not be able to remark DSCP values of
data traffic, perform traffic engineering (policy-based routing), or apply
different security requirements.  For security/DoS/network optimization, it does
not always make sense for control and data traffic for applications to take the
same network path, have the same access, and receive the same priority.  By
requiring the same port, and a mux header the control and data traffic must take
the same network path.  If manufacturers provide classification within the WTP,
this would help alleviate the QoS concerns, but network traffic
engineering/security is still a concern.  Deep packet inspection techniques
(NBAR) are slow in coming across vendors, slow in market adoption, and
complex/costly to implement.  Proliferation of this technology/protocol is
dependent upon the cost effectiveness of the solution.  Upgrading access points
to a CAPWAP solution provides some potential cost savings, through centralized
policy and management.  But, if you say to do it "right" you need to also
upgrade your entire network infrastructure to support deep packet inspection
techniques, this quickly becomes too costly of a solution to implement.  Current
project I'm working on, it costs roughly $3M to do all wireless access points.
But, to upgrade all network infrastructure to support NBAR, I'd is estimate is
at $40M.  Some corners of the network here still have 10Base2 hubs!  The reason
802.11 has been success is because it has been inexpensive, creating a
dependency of the wireless network on the wired network would hamper further
proliferation.

>   Furthermore, this requirement will help remotely located WTPs to
>   handle data traffic in alternative ways without the need for
>   forwarding them across a wide network to the WLAN controller.

WLAN Controller should be renamed to AC here.

>   Separation of WTP control and data also aids in the secure
>   realization of shared WLAN deployments.

Security should not be limited to whether the control data is being encrypted,
while the data may or may not be.  It is more far reaching.  Perhaps you want to
have an network segment act as a transit area for control data, but not for data
traffic.  Logical network segmentation of traffic for security (DoS) prevention
is something that is present in certain environments (especially manufacturing
and high security).

>   Relation to Problem Statement:
>
>   Broadly, this objective relates to the challenge of managing
>   complexity in large-scale WLANs.  The requirement for traffic
>   separation simplifies control as this is separated from the task of
>   data transport.

The way I interpret this, by using a MUX header, a truly separate transport of
control and data messages cannot be fully realized.  I can see how it simplifies
the protocol (NAT Traversal), so this does provide merit as a viable option.
However, if this is the path that is chosen, we lose some flexibility (traffic
engineering).  

In conclusion, should a MUX header be chosen, I would suggest that the
objectives need to also be reviewed/updated to reflect that the spirit of this
protocol requirement has changed. In particular, stating that a true separate
transport for data and control messages are not going to be achieved by this WG,
but rather an internal identification of data and control messages so that AC
and WTPs can treat data and control messages differently.

Mike

[email-masked] wrote:
> Multiport issue # 115, in order to progress the specification.  Based 
> on the discussion that has taken place the chairs are in agreement the 
> any unforseen events, we will instruct the editors resolve in favor of 
> a new Mux header.
> 

Mike Kraus
Sr. Network Engineer
Applied Information Systems
Cellular Phone (314) 575-0968
Nextel direct connect: 140*1*31368
Providing solutions for ABI, Brewing Operations & Technology, Engineering

The information transmitted (including attachments) is
covered by the Electronic Communications Privacy Act,
18 U.S.C. 2510-2521, is intended only for the person(s) or
entity/entities to which it is addressed and may contain
confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons
or entities other than the intended recipient(s) is prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 8 Jun 2006 16:42:30 -0700 (GMT-07:00)

Hi Nanciy,

>be repercusions that need further analysis.

It is DTLS precisely because it is *not* dependent on the underlying transport, whereas TLS *is*. That's why TLS is not an option, but DTLS is. We chose DTLS because it uses the *connectionless* (or datagram) model - not UDP in particular. And adding a PDU type identifier is simply another layered datagram protocol. There are no security implications introduced by this modification.

>will to those analyzing the security of this.  

If you do such an analysis, I think you will find that one elegant feature of DTLS is that it does not matter what you wrap it in. It can be wrapped in connection-oriented or connectionless protocols, and it can even be multiplexed across both simultaneously - I have actually implemented this. It's very cool in that regard.

Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 8 Jun 2006 17:40:14 -0700 (GMT-07:00)

Hi Michael,

>data but does not provide a separate transport mechanism (more on this below).

I looked at that objective some time ago and went through the same thought process, so I think I understand your concern. I think it's very important to recognize that virtually any protocol can be used as a transport - the Internet works for just this reason. Following is an example of a transport protocol:

[ethernet][IP][UDP][data being transported]

Here's another one: 

[ethernet][IP][UDP][PDU type][data being transported]

>From the perspective of the application consuming the data, these are indistinguishable, assuming appropriate send/recv APIs are provided. Hence, strictly speaking, the objective you cite has been met.

>different security requirements.  

It sounds like we're talking about an enterprise LAN here. In any event, we know that all QoS bets are off if the Internet is one of the hops, so let's eliminate that from the discussion.

And let's be clear here: the claim is that on an enterprise LAN, intermediate gear will need to remark DSCP values, and that it can *only* do this based on the UDP ports, that any deeper packet inspection is too expensive. We noted here earlier that a direct  consequence of this is that the data channel would be an opaque blob to such a system, and the applications within it would be treated the same - they would have no QoS. In this case, you would essentially have two classes: control (the "haves") and data (" the have-nots"). This actually violates another objective in the same document you referred to.

In any event, I don't think this is a realistic scenario, but even if it were, wouldn't this problem be better solved by using a different VLAN tag for the control packets than the data packets?

> For security/DoS/network optimization, it does
>engineering/security is still a concern.  

Again, what network are we talking about here?  When you mention security and DoS optimizations with respect to the wired network, I'm thinking the Internet may be involved - is that what you mean?

> Deep packet inspection techniques

I don't think you need to add fancy classification tools to make this work. I think the AC and WTP have all the information they need. But the fact is that if you *don't* have fancy classification tools, then any re-marking will either be a one-to-one mapping that favors control traffic, and ignores the QoS granularity requirements of the data. That can't really be good from an operational perspective, can it?

>is something that is present in certain environments (especially manufacturing

The same thing can be realized with vlan tagging, can't it? But if the only thing you have for realizing this is (an unauthenticated) tuple-based packet filter (or a vlan tag, for that matter), we don't really expect that to be *secure*, do we? 

I'm not sure exactly what was meant by this clause, but I think we need to be careful to avoid imparting a "scriptural" aura to the objectives document.

>However, if this is the path that is chosen, we lose some flexibility (traffic

I think that adding a capwap layer header (call it a PDU identifier, a capwap frame type, a mux header, whatever) is a separate transport layer, and meets the objective fully. I think we should be careful about loaded terms like "truly" in the same way as we should be careful not to assume the objectives document is scripture. Layering in this manner does not ignore this objective.

>and WTPs can treat data and control messages differently.

No need to modify it in any event - it's really a historical document.

Scott

---

From: "Kraus, Michael" <[email-masked]>
Date: Fri, 9 Jun 2006 06:56:46 -0500

Scott,
  Thanks for the response!  In general, security/DoS concerns are not limited to
the internet, but also to the LAN.  This eminates from the fact there are more
and more untrusted users on the LAN (outsourced support agreements, "guest
wireless access", etc.)  So, you can't necessarily trust all LAN segments.  I
feel this may be somewhat of a tangent, so I'll stop there.

  In general, I believe I understand your points, and agree that there are ways
to accomplish all challenges I've described with using the mux header.  For me,
when you use the same port number, the AC/WTP would typically need to be
involved to modify traffic flows (regardless of purpose: security, QoS, traffic
engineering).  If you use separate port number, you have the option to modify
traffic flows by also [legacy lan] network infrastructure.  I like to have the
options, but can see how it would also be beneficial for the protocol to
sacrifice that flexibility for simplicity of the protocol.

  All in all, I think that the WG has a good understanding of this issue from my
perspective, so I have no further input.

Thanks,
  Mike

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 7:40 PM
To: Kraus, Michael; [email-masked]
Cc: Bob O'Hara (boohara); [email-masked]; [email-masked];
[email-masked]

Hi Michael,

>Greetings!
>
>Before saying that going to a mux header is the simplest/cleanest, I 
>would suggest reviewing the original objectives of this WG.  From 5.1.2 
>of the
>objectives:
>
>>   Protocol Requirement:
>>

I looked at that objective some time ago and went through the same thought
process, so I think I understand your concern. I think it's very important to
recognize that virtually any protocol can be used as a transport - the Internet
works for just this reason. Following is an example of a transport protocol:

Here's another one: 

>From the perspective of the application consuming the data, these are
indistinguishable, assuming appropriate send/recv APIs are provided. Hence,
strictly speaking, the objective you cite has been met.

>This is where a MUX header makes sense, since it mitigates the NAT 
>traversal concern (rather than adding a keep alive type of 
>functionality, which would somewhat increase overhead/complexity).
>
>With a MUX header, the network devices will not be able to remark DSCP 
>values of data traffic, perform traffic engineering (policy-based 
>routing), or apply different security requirements.

It sounds like we're talking about an enterprise LAN here. In any event, we know
that all QoS bets are off if the Internet is one of the hops, so let's eliminate
that from the discussion.

And let's be clear here: the claim is that on an enterprise LAN, intermediate
gear will need to remark DSCP values, and that it can *only* do this based on
the UDP ports, that any deeper packet inspection is too expensive. We noted here
earlier that a direct  consequence of this is that the data channel would be an
opaque blob to such a system, and the applications within it would be treated
the same - they would have no QoS. In this case, you would essentially have two
classes: control (the "haves") and data (" the have-nots"). This actually
violates another objective in the same document you referred to.

In any event, I don't think this is a realistic scenario, but even if it were,
wouldn't this problem be better solved by using a different VLAN tag for the
control packets than the data packets?

> For security/DoS/network optimization, it does not always make sense 
>for control and data traffic for applications to take the same network 
>path, have the same access, and receive the same priority.  By 
>requiring the same port, and a mux header the control and data traffic 
>must take the same network path.  If manufacturers provide 
>classification within the WTP, this would help alleviate the QoS 
>concerns, but network traffic engineering/security is still a concern.

Again, what network are we talking about here?  When you mention security and
DoS optimizations with respect to the wired network, I'm thinking the Internet
may be involved - is that what you mean?

>complex/costly to implement.  Proliferation of this technology/protocol 
>is dependent upon the cost effectiveness of the solution.  Upgrading 
>access points to a CAPWAP solution provides some potential cost 
>savings, through centralized policy and management.  But, if you say to 
>do it "right" you need to also upgrade your entire network 
>infrastructure to support deep packet inspection techniques, this 
>quickly becomes too costly of a solution to implement.  Current project I'm
working on, it costs roughly $3M to do all wireless access points.
>But, to upgrade all network infrastructure to support NBAR, I'd is 
>estimate is at $40M.  Some corners of the network here still have 
>10Base2 hubs!  The reason
>dependency of the wireless network on the wired network would hamper 
>further proliferation.

I don't think you need to add fancy classification tools to make this work. I
think the AC and WTP have all the information they need. But the fact is that if
you *don't* have fancy classification tools, then any re-marking will either be
a one-to-one mapping that favors control traffic, and ignores the QoS
granularity requirements of the data. That can't really be good from an
operational perspective, can it?

>Security should not be limited to whether the control data is being 
>encrypted, while the data may or may not be.  It is more far reaching.  
>Perhaps you want to have an network segment act as a transit area for 
>control data, but not for data traffic.  Logical network segmentation 
>of traffic for security (DoS) prevention is something that is present 
>in certain environments (especially manufacturing and high security).

The same thing can be realized with vlan tagging, can't it? But if the only
thing you have for realizing this is (an unauthenticated) tuple-based packet
filter (or a vlan tag, for that matter), we don't really expect that to be
*secure*, do we? 

I'm not sure exactly what was meant by this clause, but I think we need to be
careful to avoid imparting a "scriptural" aura to the objectives document.

>The way I interpret this, by using a MUX header, a truly separate 
>transport of control and data messages cannot be fully realized.  I can 
>see how it simplifies the protocol (NAT Traversal), so this does provide merit
as a viable option.
>However, if this is the path that is chosen, we lose some flexibility 
>(traffic engineering).

I think that adding a capwap layer header (call it a PDU identifier, a capwap
frame type, a mux header, whatever) is a separate transport layer, and meets the
objective fully. I think we should be careful about loaded terms like "truly" in
the same way as we should be careful not to assume the objectives document is
scripture. Layering in this manner does not ignore this objective.

>objectives need to also be reviewed/updated to reflect that the spirit 
>of this protocol requirement has changed. In particular, stating that a 
>true separate transport for data and control messages are not going to 
>be achieved by this WG, but rather an internal identification of data 
>and control messages so that AC and WTPs can treat data and control messages
differently.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 9 Jun 2006 08:46:35 -0700

> I don't see how this is implied. Assuming you had the backend 
> signalling in place, I think the two cases are equivalent. Am 
> I missing something?

I am pulling some text from a previous post you had sent, which implies
that both control and data MUST terminate on the same system, which is
the point I tried to make in my scaling argument. I presume your
assessment
that one cannot split them up remains.

> If we go with separate ports, there are a number of unpleasant
consequences:
> - there will certainly be issues with NAT traversal; you now need to
> run keepalives over two channels, and even at that, the behavior will
> not be deterministic; busy NAT devices throw out existing dgram
sessions
> when they need the resources, and this will result in one channel up,
and
> one down; 
Which I claim is really not that hard to provide. We can define a NULL
802.11
packet, for instance - or even something more generic by defining a bit
in the
header. This is really trivial.

> - channel binding is ambiguous; it is not clear what data channel goes
> with what control channel unless we add explicit signalling, and this
> adds considerable complexity to the protocol.
This point you had previously made specifically states that one cannot
separate
both the control and the data channel. 

This said, this is also not not very complex to deal with. A WTP has a
specific
MAC address, called a BSSID, which is present in the CAPWAP header, and
is used
to perform the correlation between the control and data plane.

> - all of the added corner and race conditions and error handling
requirements
> add *significant* complexity to the state machines in both ends of the
> connection. That's bad.
I think it wouldn't hurt to go through the exercise to determine exactly
what this
really means so we can all be on the same page. Right now we have no
concrete
proof this is true.

Pat Calhoun

> From: Scott G Kelly [mailto:[email-masked]] 
> Sent: Friday, June 09, 2006 7:18 AM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]; [email-masked]
> Hi Pat,
> Pat Calhoun (pacalhou) wrote:
> > Thanks for the clarification, Scott. That is helpful. Let me ask a 
> > separate question. The protocol currently allows the CAPWAP control 
> > and data flows to be sent to separate devices. While I 
> admit that the 
> > protocol isn't complete in this area, and is probably 
> something that 
> > would need to be worked out in a future version of the CAPWAP 
> > protocol.
> > 
> > However, the MUX implies (at least to me) that the 
> destination of both 
> > the control and the data plane MUST terminate on the same 
> device. This 
> > is particularly troubling as 802.11N is coming our next 
> year, and if 
> > one believes that APs will be able to deliver up to 400Mbps, then 
> > scaling will quickly become a problem.
> 
> 
> Scott
> 
>

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Fri, 9 Jun 2006 13:00:39 -0700

Pat wrote:

	Actually, I disagree. First of all, relying on a bit that states

	whether the data frame is encrypted or not is irrelevant because

	the AC (and WTP, for that matter) will probably rely on the
policy 
	negotiated during the control plane setup more than the bit.

	For instance, if the AC stated that DTLS was required on the
data 
	plane, would it accept a packet in the clear? No, so I don't
think 
	we need to signal that the data plane is explicitely encrypted.
If 
	it doesn't comply to the negotiated mode of operation, it is
dropped.

	For that matter, only 2 ports are needed.

This is quite restrictive.  An AC can have some data traffic from
a remote office and require DTLS on that traffic, as well as some
traffic coming from within the local premises for which it may not
require DTLS in the data plane.  DTLS on the data plane should be
a property of the specific tunnel. This needs to supported.

In general, it is a better design to have the packet fields
clearly indicate that what the nature of the payload is, rather
than depend on lookups of policy tables to decide how to 
parse the packet.  So, I think Dave's proposal of the header 
have encodings to indicate DTLS-encrypted payload or not is
a good idea.  This is still orthogonal to whether we use one
UDP port or two.

Abhijit

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 9 Jun 2006 14:20:14 -0700

> This is quite restrictive.  An AC can have some data traffic 
> from a remote office and require DTLS on that traffic, as 
> well as some traffic coming from within the local premises 
> for which it may not require DTLS in the data plane.  DTLS on 
> the data plane should be a property of the specific tunnel. 
> This needs to supported.

Perhaps I wasn't clear, this is done on a per WTP basis. I can't
imagine some traffic being in the clear, and some not. I see the
decision to encrypt the data plane, on a per WTP basis, as a binary
decision.

> clearly indicate that what the nature of the payload is, 
> rather than depend on lookups of policy tables to decide how 
> to parse the packet.

The reality is that you have to do the policy lookup anyhow. You
don't want to accept an unencrypted packet, when the policy
requires it to be. So you can't avoid this lookup.

Pat Calhoun

> From: Abhijit Choudhury [mailto:[email-masked]] 
> Sent: Friday, June 09, 2006 1:01 PM
> To: Pat Calhoun (pacalhou); David T. Perkins
> Cc: [email-masked]
> Subject: RE: [Capwap] New mux header for CAPWAP
> 
> 	Pat wrote:
> 
> 	the AC (and WTP, for that matter) will probably rely on 
> the policy 
> 	For instance, if the AC stated that DTLS was required 
> on the data 
> 	plane, would it accept a packet in the clear? No, so I 
> don't think 
> 	it doesn't comply to the negotiated mode of operation, 
> it is dropped.
>