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

From: "Kraus, Michael" <[email-masked]>
Date: Mon, 1 May 2006 17:03:22 -0500

Firewalling between LAN segments (rather than just at the perimeter) does seem
to be becoming the trend.  So, I too would prefer the same port number, and

utilizing a MUX header to classify control/data.

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

----------------------------------------------------------------------

Message: 1
Date: Mon, 1 May 2006 15:15:10 -0400
From: "Michael Montemurro" <[email-masked]>
Subject: Re: [Capwap] to mux or not to mux?
To: "Scott G. Kelly" <[email-masked]>
Cc: capwap <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Scott, Charles,

For the reasons below, I'm in favor of using a MUX header to distinguish control
from data traffic versus using separate ports.

Cheers,

          Mike

On 5/1/06, Scott G. Kelly <[email-masked]> wrote:
>
> T. Charles Clancy wrote:
>
> >I think another drawback of the MUX header is that stock DTLS 
> >implementations will likely already have support for running over 
> >plain UDP.  Thus any CAPWAP DTLS implementation might be a little 
> >less out-of-the-box.  Of course, CAPWAP will need to muck with the 
> >DTLS state machine on a low level anyway, so it's unlikely any 
> >implementation would work out-of-the-box.
> >
> >That being said, I'm personally in favor of the MUX header.
>
> Actually, stock DTLS implementations (openssl in particular) can't 
> handle multiple clients on a single socket "connection" without adding 
> some intermediate de-muxing anyway, so as you say, it won't work 
> out-of-the-box regardless.
>
> FWIW, I already have mux header code running with openssl. It was 
> pretty straightforward to implement.
>
> --Scott
>
> >--
> >t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> >
> >
> >On Mon, 1 May 2006, Scott G. Kelly wrote:
> >
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.tigertech.net/pipermail/capwap/attachments/20060501/d0ed34f0/attach
ment.htm

------------------------------

Message: 2
Date: Mon, 1 May 2006 15:21:49 -0400 (EDT)
From: "T. Charles Clancy" <[email-masked]>
Subject: Re: [Capwap] BSSID-WLAN mappings
To: Jim Murphy <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="windows-1252"

Sort of...

As I understand the conversation, in the M-SSID case, you could send an
encrypted broadcast packet to other people on your WLAN.  This packet would be
encrypted with a key that other users on other WLANs could know. 
For example, someone on WLAN-B could see NETBIOS broadcast packets from devices
associated to WLAN-A.  They might even think they could communicate with said
NETBIOS machines, but unicast packets addressed to them would fail (hopefully,
assuming the WTP is properly implemented).

Jim's scenario below is somewhat different, where you have someone on the wired
side sending data that CAPWAP intentionally decides should be transmitted to
multiple WLANs.  The concern here is more along the lines of a chosen ciphertext
attack that could leak information about keys by seeing packets encrypted
multiple times with different keys.  Provided people are using good crypto (i.e.
not WEP), this shouldn't be a problem.

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

On Mon, 1 May 2006, Jim Murphy wrote:

> Hi,
>
> Hasn't security already been compromised in CAPWAP by the fact that a 
> data frame could be sent to multiple WLANs using the WLAN/Status field 
> of the CAPWAP header? Each of these WLANs could be running a different 
> crypto type.
>
> Thanks,
>
> Jim
>
> Bob O'Hara (boohara) wrote:
>> As I said, this is a proprietary extension, even if it might have 
>> been provided on some Cisco products.  I hold that CAPWAP is 
>> chartered to implement a protocol to support 802.11, not the myriad 
>> proprietary extension that have been hammered onto its side over the years.
>>  But, the more damning problem for this is the lowering of security 
>> and the violation of the security assumptions on which 802.11i is 
>> based.  Crossing the boundary of a security domain, even if "only" 
>> for multicast, dramatically increases the opportunity for compromise 
>> of data that communicants believe is secure.
>> 
>>  -Bob
>> 
>> 
>> ---------------------------------------------------------------------
>> ---
>> *From:* Jeff Joslin [mailto:[email-masked]]
>> *Sent:* Friday, April 28, 2006 12:47 PM
>> *To:* Bob O'Hara (boohara); [email-masked]
>> *Subject:* RE: [Capwap] BSSID-WLAN mappings
>> 
>> Indeed, the M-SSID mechanism I described is not in the standard but 
>> has been implemented by a number of different vendors, including, as 
>> I recall, Cisco Aironet. Now that 802.11 chip sets and drivers have 
>> better support for M-BSSID, there is little reason to use the more 
>> problematic M-SSID. Its only advantage over M-BSSID is that M-SSID uses up
fewer MAC addresses.
>> 
>> 
>> Jeff
>> 
>> 
>> ---------------------------------------------------------------------
>> ---
>> 
>> *From:* Bob O'Hara (boohara) [mailto:[email-masked]]
>> *Sent:* 28 April 2006 3:35 PM
>> *To:* [email-masked]
>> *Subject:* RE: [Capwap] BSSID-WLAN mappings
>> 
>> 
>> The mechanism below is, of course, not compliant with the 802.11 standard. 
>> It is a proprietary extension.  It is not clear to me why CAPWAP 
>> should support this mechanism, or any other proprietary mechanism.  
>> As Jeff points out below, this is not compatible with all clients 
>> (most likely because the mechanism is not mentioned in the standard) 
>> and also violates the security assumptions of 802.11.
>> 
>>  -Bob
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> ---
>> 
>> *From:* Jeff Joslin [mailto:[email-masked]]
>> *Sent:* Friday, April 28, 2006 12:19 PM
>> *To:* [email-masked]
>> *Subject:* RE: [Capwap] BSSID-WLAN mappings
>> 
>> You can implement multiple SSID with single BSSID by having only one 
>> SSID in the beacon; the others SSIDs are hidden. If a client 
>> broadcasts a probe for one of those hidden SSIDs the AP will respond 
>> and the client can then do a normal association. The AP maintains one 
>> broadcast/multicast key for each encryption type (WEP, TKIP, AES) and 
>> uses the appropriate one according to the encryption type of the 
>> frame's SSID. This allows a certain amount of information leakage 
>> between SSIDs, but in most applications this is acceptable.
>> 
>> 
>> The above scheme works, after a fashion, but creates some client 
>> compatibility issues. Multiple BSSID is preferable.
>> 
>> 
>> One SSID == 1 WLAN. In general we cannot assume that 1 BSSID == 1 WLAN.
>> 
>> 
>> Perhaps 1 VLAN == 1 WLAN is more helpful? It is standard practice to 
>> map each SSID to a separate VLAN.
>> 
>> 
>> Jeff Joslin
>> 
>> Senior Network Architect
>> 
>> BelAir Networks
>> 
>> 
>> ---------------------------------------------------------------------
>> ---
>> 
>> *From:* Pat Calhoun (pacalhou) [mailto:[email-masked]]
>> *Sent:* 28 April 2006 2:57 PM
>> *To:* Puneet; Bob O'Hara (boohara)
>> *Cc:* [email-masked]
>> *Subject:* RE: [Capwap] BSSID-WLAN mappings
>> 
>> 
>> Well, first, there is no way that I am aware of where you can have 
>> multiple SSIDs for a single BSSID. Furthermore, if one were to do 
>> this, how would you handle broadcast packet encryption, where a 
>> station would see packets from a BSSID, but would not be able to 
>> decrypt it - presumably because the AC would have multiple GTKs, not 
>> indexed on a BSSID, but some other non-defined mechanism.
>> 
>> 
>> I contend 1 BSSID == 1 WLAN.
>> 
>> Pat Calhoun
>> CTO, Wireless Networking Business Unit Cisco Systems
>> 
>> 
>> 
>>     
>> ---------------------------------------------------------------------
>> ---
>> 
>>     *From:* Puneet [mailto:[email-masked]]
>>     *Sent:* Monday, April 17, 2006 10:39 AM
>>     *To:* Bob O'Hara (boohara)
>>     *Cc:* [email-masked]
>>     *Subject:* Re: [Capwap] BSSID-WLAN mappings
>> 
>>     Bob,
>> 
>>     >  We should not be implementing, or requiring an CAPWAP
>>     implementation to implement a method
>>     >  that lowers the security of the WLAN.
>> 
>>     I am not sure I understand the argument here: supporting open or WEP

>>     also does the same thing, but CAPWAP supports those encryption
>>     protocols. CAPWAP does not force everyone to support WEP, but it
>>     *allows* it to be setup on a WLAN. Along the same lines we should
>>     allow this mapping too. Maybe make a note that it does not allow
>>     WLAN traffic separation into logical groups over the air (Saravanans

>>     point)
>> 
>>     Thanks,
>>     Puneet
>> 
>>     On 4/17/06, *Bob O'Hara (boohara)* <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>> 
>>     There are also security issues when there is not a 1:1 mapping of
>>     WLAN to BSSID.  Without this restriction, a station will not have
>>     any assurance that traffic it believes is encrypted and protected
>>     according to the policy of the WLAN to which it is associated is not

>>     being decrypted by an oracle (the AP) and rebroadcast to other
>>     stations without the same requirements for abiding with the same
>>     security policies.
>> 
>> 
>>     We should not be implementing, or requiring an CAPWAP implementation

>>     to implement a method that lowers the security of the WLAN.
>> 
>>      -Bob
>> 
>> 
>> 
>>     
>> ---------------------------------------------------------------------
>> ---
>> 
>>     *From:* Puneet [mailto: [email-masked] 
>> <mailto:[email-masked]>]
>> 
>>     *Sent:* Sunday, April 16, 2006 4:47 PM
>>     *To:* Saravanan Govindan
>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>     *Subject:* Re: [Capwap] BSSID-WLAN mappings
>> 
>>     Hi Saravanan,
>> 
>>     I see your point, but this seems to address a very specific
>>     deployment scenario (service providers sharing WLAN equipment). If
>>     nothing else in the CAPWAP messages is dependent on this, then this
>>     should be a recommendation instead of a mandate. That way the
>>     protocol remains inclusive, and also meets its objective.
>> 
>>     I think it is very important that existing implementations are not
>>     excluded just because they dont seem to meet one specific need in a
>>     specific deployment scenario.
>> 
>>     Thanks,
>>     Puneet
>> 
>>     On 4/15/06, *Saravanan Govindan* <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>> 
>>     Hi Puneet,
>> 
>>     My concern regarding the BSSID - WLAN mapping is based on the mandatory
>>     Objective "Logical Groups" (Section 5.1.1 of CAPWAP Objectives).

>> 
>>     The Objective requires that WTP traffic be kept logically distinct
>>     among
>>     logical groups. This arises from the commercial need of service
>>     providers
>>     sharing WLAN infrastructure equipment. Service providers want their
>>     traffic
>>     to be distinguished both over the wireless environment (e.g. BSSIDS)

>>     and
>>     over the AC-WTP environment (e.g. WLANs).
>> 
>>     The BSSID-WLAN mapping issue is the technical requirement coming
>>     from this
>>     commercial need. It allows an AC - or WTP - to decide how logical
>>     groups are
>>     separated over the wireless and AC-WTP segments. So by making this
>>     mapping,
>>     CAPWAP frames of different logical groups (WLANs) can be distinctly
>>     exchanged.
>> 
>>     I agree with others that this mapping should not exclude any
>>     implementation
>>     - my concern is that the mapping be including in the first place.
>> 
>>     Cheers,
>> 
>>     Saravanan
>> 
>> 
>> 
>> 
>>     >  ------------------------------
>>     >  *From:* Puneet [mailto:[email-masked] <mailto:[email-masked]>]
>>     >  *Sent:* Friday, April 14, 2006 12:29 AM
>>     >  *To:* [email-masked] <mailto:[email-masked]>
>>     >  *Subject:* [Capwap] BSSID-WLAN mappings
>>     >
>>     >  the BSSID description in Section 11.9.1 'WTP Radio Configuration'

>>     notes
>>     >  that a WTP that supports 16 WLANS MUST have 16 MAC addresses
>>     reserved for
>>     >  it. Why? ie. what part of the protocol does not work if we have
>>     multiple
>>     >  SSIDs on a single BSSID? (whether thats good design or bad is a
>>     different
>>     >  matter). Since the WLAN ID could be used in all such places to 
>> convey
>>     WLAN
>>     >  information back to the AC, why do we need to mandate this 1:1
>>     BSSID-WLAN
>>     >  mapping?
>>     >
>>     >  Thanks,
>>     >  Puneet
>>     >
>>     >  _________________________________________________________________

>>     >  To unsubscribe or modify your subscription options, please visit:

>>     >  http://lists.frascone.com/mailman/listinfo/capwap
>>     <http://lists.frascone.com/mailman/listinfo/capwap>
>>     >
>>     >  Archives: http://lists.frascone.com/pipermail/capwap
>>     >
>> 
>>     _________________________________________________________________
>>     Get an advanced look at the new version of MSN Messenger.
>>     http://messenger.msn.com.sg/Beta/Default.aspx
>>     <http://messenger.msn.com.sg/Beta/Default.aspx>
>> 
>> 
>> 
>>     _________________________________________________________________
>>     To unsubscribe or modify your subscription options, please visit:
>>     http://lists.frascone.com/mailman/listinfo/capwap
>> 
>>     Archives: http://lists.frascone.com/pipermail/capwap
>>     <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
>

------------------------------

Message: 3
Date: Mon, 1 May 2006 14:46:30 -0700
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: [Capwap] Issue 53: Add Data Rate to LWAPP Header
To: "capwap" <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

All,

The following is a proposed new CAPWAP header format, as a result of discussions
on the list. Comments are most welcomed.

4.1.  CAPWAP Transport Header
 
   All CAPWAP protocol messages are encapsulated using a common header
   format, regardless of the CAPWAP control or CAPWAP Data transport
   used to carry the messages.  However, certain flags are not
   applicable for a given transport.  Refer to the specific transport
   section in order to determine which flags are valid.
 
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VERSION|   RID   | HLEN  |W|F|L|M|          Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Fragment ID          |     Frag Offset         |Rsv-2|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 (optional) Radio MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            (optional) Wireless Specific Information           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Payload ....                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
4.1.1.  VERSION Field
 
   A 4 bit field which contains the version of CAPWAP used in this
   packet.  The value for this draft is 0.
 
4.1.2.  RID Field
 
   A 5 bit field which contains the Radio ID number for this packet.
   WTPs with multiple radios but a single MAC Address use this field to
   indicate which radio is associated with the packet.
 
4.1.3.  HLEN
   Length of CAPWAP tunnel header in 4 byte words. (Similar to IP
   header length). This length includes the optional headers.

4.1.4.  W Bit
 
   The Wireless 'W' bit is used to specify whether the optional wireless
   specific information field is present in the header. A value of one
   (1) is used to represent the fact that the optional header is present.

4.1.5.  F Bit
 
   The Fragment 'F' bit indicates whether this packet is a fragment.
   When this bit is one (1), the packet is a fragment and MUST be
   combined with the other corresponding fragments to reassemble the
   complete information exchanged between the WTP and AC.
 
4.1.6.  L Bit
 
   The Not Last 'L' bit is valid only if the 'F' bit is set and
   indicates whether the packet contains the last fragment of a
   fragmented exchange between WTP and AC.  When this bit is 1, the
   packet is not the last fragment.  When this bit is 0, the packet is
   the last fragment.

4.1.7.  M Bit
 
   The M bit is used to indicate that the Radio MAC Address optional
   header is present. This is used to communicate the MAC address of 
   the receiving radio when the native wireless packet. This field 
   MUST NOT be set to one in packets sent by the AC to the WTP.

4.1.8.  Reserved
 
   The 15-bit Reserved field is reserved and set to 0 in this version of the 
   CAPWAP protocol.
  
4.1.9. Fragment ID
 
   An 16 bit field whose value is assigned to each group of fragments
   making up a complete set.  The fragment ID space is managed
   individually for every WTP/AC pair.  The value of Fragment ID is
   incremented with each new set of fragments.  The Fragment ID wraps to
   zero after the maximum value has been used to identify a set of
   fragments.  
 
4.1.10. Fragment Offset
 
   A 13 bit field that indicates where in the payload will this fragment belong
   during re-assembly. This field is valid when the 'F' bit is set to 1.
The 
   fragment offset is measured in units of 8 octets (64 bits). The first

   fragment has offset zero. 
 
4.1.11.  Reserved-2
 
   The 3-bit Reserved-2 field is reserved and set to 0 in this version of the 
   CAPWAP protocol.

4.1.12.  Radio MAC Address

   This optional field contains the MAC address of the radio receiving the
   packet. This is useful in packets sent from the WTP to the AC, when the
   native wireless frame format is converted to 802.3 by the WTP. This field
   is only present if the 'M' bit is set.

   The field contains the basic format:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Length     |                  MAC Address
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Length:  The number of bytes in the MAC Address field. The length field
      is present since new IEEE technologies are using 48 byte MAC addresses

   MAC Address:  MAC Address of the receiving radio

4.1.13.  Wireless Specific Information

   This optional field contains technology specific information that may
   be used to carry per packet wireless information. This field is only present
   if the 'W' bit is set.

   The field contains the basic format:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Wireless ID  |    Length     |             Data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Wireless ID: The wireless binding identifier. The following values are
      defined:

      1 - IEEE 802.11

   Length:  The length of the data field

   Data:  Wireless specific information, whose details are defined in the
      technology specific binding section.

4.1.14.  Payload
 
   This field contains the header for a CAPWAP Data Message or CAPWAP
   Control Message, followed by the data associated with that message.

[...]

11.3.2.  CAPWAP Wireless Specific Information

   The reserved CAPWAP header field (see figure Section 4.1) is only
   used with CAPWAP data frames, and it serves two purposes, depending
   upon the direction of the frame.  For packets from the WTP to the AC,
   the field uses the format described in Section 11.3.2.1.  However,
   for frames sent by the AC to the WTP, the format used is described in
   described in Section 11.3.2.2.

11.3.2.1.  IEEE 802.11 Frame Info

   When an CAPWAP data frame is received from a station over the air, it
   is encapsulated and this field is used to include radio and PHY
   specific information associated with the frame.

   When used with the IEEE 802.11 binding, the field follows the
   following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     RSSI      |     SNR       |           Data Rate           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RSSI:  RSSI is a signed, 8-bit value.  It is the received signal
      strength indication, in dBm.

   SNR:  SNR is a signed, 8-bit value.  It is the signal to noise ratio
      of the received IEEE 802.11 frame, in dB.

   Data Rate:  The data rate field is a 16 bit unsigned value.  The
      contents of the field is set to 1/10th of the data rate of the
      packet received by the WTP.  For instance, a packet received at  
 
[Rest is identical to -00]

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

------------------------------

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

End of Capwap Digest, Vol 7, Issue 3
************************************

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.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 2 May 2006 13:39:07 -0700

I am not in favor of the MUX header. I believe that we need separation
at the UDP layer, to allow existing hardware to be able to identify how
to treat a packet using existing ACLs. 

Pat Calhoun

> -----Original Message-----
> From: T. Charles Clancy [mailto:[email-masked]] 
> Sent: Monday, May 01, 2006 11:47 AM
> To: Scott G. Kelly
> Cc: capwap
> implementations will likely already have support for running 
> over plain UDP.  Thus any CAPWAP DTLS implementation might be 
> a little less out-of-the-box.  Of course, CAPWAP will need to 
> muck with the DTLS state machine on a low level anyway, so 
> it's unlikely any implementation would work out-of-the-box.
> 
> > between control and data. While there was some discussion, 
> we did not 
> > reach a conclusion.
> >
> implementers 
> > if this question could be decided prior to publication of that 
> > document. To facilitate this, I've summarized briefly below.
> >
> > - 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)
> >
> > 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
> >
> > implementation, and will likely result in operational 
> problems in some 
> > environments.
> >
> > interval to be smaller than the NAT binding lifetime for 
> the path in 
> > question
> >
> > Please speak up and make your preferences known.
> >
> > Thanks,
> >
> > Scott
> >

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 2 May 2006 13:59:11 -0700 (GMT-07:00)

Hi Pat,

>to treat a packet using existing ACLs. 

In the course of this thread and related ones, we've seen quite clearly that using multiple ports rather than one is very costly in terms of the added operational complexity. There are also implicit security considerations in separating the termination points for data and control channels.

What existing hardware needs to be able to distinguish between these packets based on ports, and why? What specific, valuable real-world functionality is lost by using the mux header?

Scott

---

From: "Nancy Winget (ncamwing)" <[email-masked]>
Date: Tue, 2 May 2006 23:17:16 -0700

Hi Scott,

-----Original Message-----
From: Scott G Kelly [mailto:[email-masked]] 
Sent: Tuesday, May 02, 2006 7:04 AM
To: Nancy Winget (ncamwing)
Cc: capwap
Subject: Re: [Capwap] to mux or not to mux?

Hi Nancy,

Nancy Winget (ncamwing) 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:

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.
[NCW] While it may not be a change in DTLS, you are suggesting that
changes be made to compensate for openSSL.  What about other
implementations and instantiations?  I believe that adding this MUX will
force a change with other non-open implementations of DTLS that may not
be warranted.   

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

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.
[NCW] I am referring to the CAPWAP control vs data frames, not 802.11
traffic.

>  - merging the control and data plane into a single UDP (dtls) tunnel 
> forces the two planes to be synchronized from an anti-replay 
> 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.
[NCW] Same comment as above.  LWAPP does this today by distinguishing
them with separate UDP ports and I am advocating that the UDP port
distinction is preferable.

> This effectively restricts the architecture to force them to use a 
> centralized DTLS encapsulation/decapsulation which imho is too 
> restrictive

DTLS en/decapsulation is completely independent of the MUX header, so
this statement makes no sense to me. Am I missing something?
[NCW] My reference here is not to the MUX but to the merging of the
capwap control and data plane into a single port and thus a single DTLS
en/decapsulation.

Scott

> 	Nancy.
> 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?
> 
> between control and data. While there was some discussion, we did not 
> reach a conclusion.
> 
> version of the capwap document, and it would be best for implementers 
> - 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 
> 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

> keepalives on both ports, and error handling for when one channel goes

> - there are many more error conditions to manage in the state machine,

> implementation, and will likely result in operational problems in some

> interval to be smaller than the NAT binding lifetime for the path in 
> question
> 
> simpler, and therefore more likely
>   to (inter)operate according to spec
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 3 May 2006 08:41:03 -0700

> In the course of this thread and related ones, we've seen 
> quite clearly that using multiple ports rather than one is 
> very costly in terms of the added operational complexity. 

I agree - but I still contend that this is an area where the added
cost can be justified.

> There are also implicit security considerations in separating 
> the termination points for data and control channels.
This is a separate issue, and not one that I am using in this argument

> What existing hardware needs to be able to distinguish 
> between these packets based on ports, and why? What specific, 
> valuable real-world functionality is lost by using the mux header?
The reality is that UDP port based ACLs is a known science today, and
being
able to use this existing mechanism to determine how to handle a packet
has
significant value. The alternative requires that we dig much deeper into
the
packet to determine whether it is control or data.

Pat Calhoun

> Sent: Tuesday, May 02, 2006 1:59 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap
> Subject: RE: [Capwap] to mux or not to mux?
> 
> Hi Pat,
> 
> Pat Calhoun wrote:
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 3 May 2006 08:41:40 -0700

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

And I contend there is significant value in being able to use this
library as-is.

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 3 May 2006 14:47:01 -0700

> UDP is indeed a MUX header, but it's a MUX header that 
> everything already understands. 
And that's the beauty with the use of UDP.

Pat Calhoun

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 4 May 2006 04:14:55 -0700 (GMT-07:00)

Hi Charles,

I think whether this has security implications depends on a number of things, and gets tangled pretty fast, but my short answer is that for the most part, you are probably right, and I am mixing my concerns with separate IP termination points for control and data into this discussion. If you are terminating both channels on the same entity and not making middlebox decisions, UDP is very similar to the MUX header, and I think you are correct in asserting there are no additional security considerations.

I think that if you use separate ports and either terminate the ports on two separate entities in the backend, or allow middleboxes to treat the traffic differently in between, you may have security issues to contend with, but I haven't spent a lot of time on analysis.

In the first case, this requires coordination in the backend, and you have the potential for left-hand/right-hand problems, e.g. where data packets should no longer be flowing but they are. I think this is potentially a mini-version of the problems you have when you allow control and data to use separate IP addresses, depending on how someone chooses to implement.

In the second case, you may be opening/closing the data channel at a middlebox depending on the state of the control channel, and again, you may wind up with cases where there is inconsistency.

That said, this is not the overriding concern for me, and should not become a distraction. The real problems are the operational ones cited in earlier emails.

Scott

-----Original Message-----
>From: Charles Clancy <[email-masked]>
>Sent: May 3, 2006 2:56 PM
>To: Charles Clancy <[email-masked]>
>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.
>
>-- 
>Charles Clancy wrote:
>> 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: "Scott G. Kelly" <[email-masked]>
Date: Thu, 4 May 2006 04:25:01 -0700 (GMT-07:00)

As Charles pointed out, the two channels are not merged into one DTLS session. By current definitions, the data channel is not running over DTLS, and I suspect that if we come to agree that optional data channel security is worthwhile, the data channel may well get its own distinct DTLS session.

I'm going to compress this into one response for both Nancy and Pat, since I'm on vacation,  and my wife will definitely give me "the look" if she wakes up and finds me talking to you guys :-)

Please go back and read the threads on this topic, in particular the messages posted during IETF65.  You guys are saying you want to split this into two udp channels because you have middleboxes in between and you want to treat the streams differently. Those posts show why this will induce signficant operational complexity, much of which is outside the scope of our current charter.

Nobody has given any concrete examples which demonstrate that we should incur this complexity.

-----Original Message-----
>From: "Nancy Winget (ncamwing)" <[email-masked]>
>Sent: May 3, 2006 2:34 PM
>To: Charles Clancy <[email-masked]>, Michael Montemurro <[email-masked]>
>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.   
>
>From: Charles Clancy [mailto:[email-masked]] 
>Sent: Wednesday, May 03, 2006 2:29 PM
>To: Michael Montemurro
>Cc: Nancy Winget (ncamwing); capwap
>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.
>
>--
>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:
>> 
>> 
>>     perspective. This effectively restricts the architecture to force
>them
>>     to use a centralized DTLS encapsulation/decapsulation which imho
>is too
>>     restrictive
>> 
>>            Nancy.
>> 
>>     From: Scott G. Kelly [mailto:[email-masked]
>>     <mailto:[email-masked]>]
>between
>>     control and data. While there was some discussion, we did not
>reach a
>>     conclusion.
>> 
>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.
>> 
>at
>between
>>     the two channels
>goes
>machine,
>some

---

From: "Kraus, Michael" <[email-masked]>
Date: Thu, 4 May 2006 10:16:56 -0500

David, 
  
  Maybe I'm misinterpreting something here and may be somewhat off-topic, but
often in QoS you try to classify traffic by source/destination IP/port or by
some higher level interpreter (such as NBAR in the cisco world).  If the same
UDP port number is being used for both control/data, how will intermediate
switches/routers be able to determine what is control vs. data traffic?  This
relates back to your comment below of:

 "So, it all comes down to whether or not we want intermediate network devices
to distinguish between control and data."

 One possible method could be for the WTP to assign the CoS/DSCP values for each
traffic type so the administrator would have the ability to trust the markings
provided by the WTP, or later perform a DSCP-mutation.

  I don't pretend to be a QoS expert, and I'm sure many products can classify
traffic by data outside of known IP/UDP headers.  However, I would argue that
this would likely be platform dependent.  For example, Cisco could create a PDLM
for NBAR for these mux values.  But, obviously this support does not exist
today, and NBAR is dependent upon firmware/hardware support.

  We probably need a "neutral" person on this topic to summarize the Pros/Cons
that have been already stated on this issue...

  Thanks,
     Mike

Message: 2
Date: Thu, 4 May 2006 07:19:53 -0700 (PDT)
From: "David T. Perkins" <[email-masked]>
Subject: Re: [Capwap] to mux or not to mux?
To: "Kraus, Michael" <[email-masked]>
Cc: [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

HI,

Since UDP is being used, why cannot the data traffic packets be
marked with a different QoS values than control traffic packets.

Would you explain and provide an example of use of "current
QoS tools".

Regards,
/david t. perkins

On Thu, 4 May 2006, Kraus, Michael wrote:
> One additional upside to using separate ports would be that different QoS

> policies can be applied against data/control data.  With mux values, this

would
> be more difficult to accomplish with current QoS tools.  With 802.11n data
rates
> being quoted, having the ability to do some "control plane policing" for the
> APs, might be advantageous.
> 
> Date: Wed, 3 May 2006 15:16:21 -0700 (PDT)
> From: "David T. Perkins" <[email-masked]>
> 	<[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> 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
> 
> On Wed, 3 May 2006, Charles Clancy wrote:
> | UDP hdr | MUX = 0x00 |  Discovery Request or Response
> > firewall / port forwarding.  I think intermediate network devices
> > should treat everything as "CAPWAP", and we should therefore do our own MUX.
> >
> > --
> > > 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.
> > >

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 4 May 2006 10:55:01 -0700

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:[email-masked]] 
Sent: Wednesday, May 03, 2006 2:29 PM
To: Michael Montemurro
Cc: capwap
Subject: Re: [Capwap] to mux or not to mux?

> If we go with the MUX header approach, how do we achieve key
separation 
> between the control and data channels?
>  
them
is too
between
reach a
version
this
To
required
at
AC-WTP
between
particular, it
goes
machine,
some
interval
question
>     - the implementation (state machine, error handling) is *much*
simpler,
>     and therefore more likely
------------------------------------------------------------------------

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 May 2006 16:11:05 -0700

The point Michael makes here is the same one I was making. Nearly every
enterprise class system, router or switch, is capable of providing QoS
enforcement using simple ACLs, which rely on IP addresses and ports. QoS
is just one of many features that can be (and are) implemented through
ACLs that would be very useful to CAPWAP.

The use of the MUX makes all of the deployed equipment out there no
longer capable of applying QoS based on control/data plane. I think this
is a serious issue, and justifies the need for two ports. 

Pat Calhoun

> From: Kraus, Michael [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 8:17 AM
> To: [email-masked]
> Cc: [email-masked]
>   Maybe I'm misinterpreting something here and may be 
> somewhat off-topic, but often in QoS you try to classify 
> traffic by source/destination IP/port or by some higher level 
> interpreter (such as NBAR in the cisco world).  If the same 
> UDP port number is being used for both control/data, how will 
> intermediate switches/routers be able to determine what is 
> control vs. data traffic?  This relates back to your comment below of:
> 
>  "So, it all comes down to whether or not we want 
> intermediate network devices to distinguish between control and data."
> 
>  One possible method could be for the WTP to assign the 
> CoS/DSCP values for each traffic type so the administrator 
> would have the ability to trust the markings provided by the 
> WTP, or later perform a DSCP-mutation.
> 
>   I don't pretend to be a QoS expert, and I'm sure many 
> products can classify traffic by data outside of known IP/UDP 
> headers.  However, I would argue that this would likely be 
> platform dependent.  For example, Cisco could create a PDLM 
> for NBAR for these mux values.  But, obviously this support 
> does not exist today, and NBAR is dependent upon 
> firmware/hardware support.
> 
>   We probably need a "neutral" person on this topic to 
> summarize the Pros/Cons that have been already stated on this issue...
> 
> 
>   Thanks,
>      Mike
> 
> Since UDP is being used, why cannot the data traffic packets 
> be marked with a different QoS values than control traffic packets.
> 
> > One additional upside to using separate ports would be that 
> different 
> > QoS
> 
> > policies can be applied against data/control data.  With 
> mux values, 
> > this
> 
> would
> > be more difficult to accomplish with current QoS tools.  
> With 802.11n 
> > data
> rates
> > being quoted, having the ability to do some "control plane 
> policing" 
> > for the APs, might be advantageous.
> > 
> > 
> > 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.
> > > 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.
> > >
> > > --
> > > > 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.
> > > >
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 4 May 2006 19:03:40 -0700 (GMT-07:00)

Please explain what problem is encountered if the same QoS policy is applied to both control and data traffic. Also explain why any such problems cannot be solved by having the WTP and/or AC apply appropriate DSCP or 802.1q marking.

-----Original Message-----
>Sent: May 4, 2006 4:11 PM
>To: "Kraus, Michael" <[email-masked]>, [email-masked]
>Cc: [email-masked]

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 4 May 2006 19:33:24 -0700 (GMT-07:00)

<much trimmed...>

>this preserves, in some sense, the openssl code.

This has been clearly articulated in earlier threads on this topic. If defining our own mux header is "homegrown" and we should interpret that pejoratively (which does seem to be the general intent), then defining our own capwap transport header should be viewed similarly. This is misdirection, intentional or not.

The reasons why it makes sense to combine data and control into one layer 4 channel have been discussed again and again here. In particular, see the NAT-T thread from the end of March. Splitting these channels raises significiant operational issues. Quoting from the NAT-T thread:

"The basic function of the mux header is that it allows you to combine the two channels over one UDP transport session. That accomplishes three things for us: implicit channel binding, elimination of a second keepalive timer and associated processing, and simplification of the state machine, both with respect to normal processing and error states. It's easier to implement and operate."

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; 

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

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

And all of this for what? I've heard some nebulous concerns about QoS, but nobody is offering a detailed and persuasive explanation of why all this added complexity is warranted. Please explain exactly what architectures are being precluded, and why this represents a loss that justifies the added effort the dual-port (actually, tri-port, as discover will require it's own port too) path requires.

Many of us have been through protocol spec development here before, and we all know how hard this sort of complexity makes interoperability, and this ignores how hard it makes it just to get your *own* implementations working together.

>resulting in very little, if any, multi-vendor interoperability.

To be very clear, agreeing on a minimal interoperable spec that we can actually bring to market in no way prevents anyone from innovating. Nobody is bound by this spec - you are always free to implement your own value-add extensions. Also there is nothing to prevent us from adding functionality to the base spec once it is complete.

What I'd like to know is, exactly *what* precluded architecture is so important? What are we losing?

Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 5 May 2006 04:43:06 -0700 (GMT-07:00)

One point I forgot to mention:

>The only argument that seems to hold any water at all is that

Openssl has zero to do with this discussion, and is only adding confusion. I've discussed it along with everyone else, to please don't take this as being aimed just at the above post, but I think we're being distracted.  The fact is, openssl is obvlivious to whether we use two ports or one. It is an implementation, and the standard we want to be discussing is dtls. Let's not waste any more time discussing it, as it is irrelevant to the issues at hand.

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:08:37 -0700

> Please explain what problem is encountered if the same QoS 
> policy is applied to both control and data traffic. Also 
> explain why any such problems cannot be solved by having the 
> WTP and/or AC apply appropriate DSCP or 802.1q marking.

In a network, one cannot guarantee that there will not be any
congestion, hence packet drops. I would contend that the control channel
has priority over the data channel, and it is therefore required to
allow administrators to setup policies in their networks to guarantee
CAPWAP session uptime.

To your second point, yes you can allow the endpoints to tag packets,
but the tag values we've chosen may conflict with existing enterprise
QoS tagging policies. So allowing UDP based ACLs to prioritize allows
the admins to override the decisions.

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:27:21 -0700

I completely agree with Michael's points.

Pat Calhoun

> Sent: Friday, May 05, 2006 6:36 AM
> To: Scott G. Kelly; Pat Calhoun (pacalhou); [email-masked]
> Cc: [email-masked]
> I know of many enterprises who have multiple 54Mbps access 
> points all run back to the same switch, which have a 100Mbps 
> uplink.  In the future, I am anticipating multiple 802.11n 
> access points with a single 1Gbps uplink.  For temporary 
> uses(conferences), I have even setup a WTP having a WAN link 
> back to the AC.  My point being, is that there will always be 
> environments where congestion will occur between the WTP and 
> the AC.  In a perfect world, there is no over-subscription 
> and no congestion. 
> 
> When congestion occurs, typically you want to ensure that the 
> data traffic is dropped, not the control traffic.  I agree 
> with your statement that the WTP or AC could apply the 
> appropriate DSCP or 802.1q marking, and I had too suggested 
> that earlier:  
> 
> ">>  One possible method could be for the WTP to assign the CoS/DSCP 
> >> values for each traffic type so the administrator would have the 
> >> ability to trust the markings provided by the WTP, or 
> later perform a 
> >> DSCP-mutation.?"
> 
> However, I have not seen any mention that if we are going to 
> pursue using a mux header that this would be incorporated 
> into the changes.  If this was to be
> 
> done, it would really make sense for the CAPWAP WG to make 
> CoS/DSCP recommendations for these values.  Vendor 
> interoperability is somewhat hampered from a usability 
> perspective if you need to do different DSCP mutations based 
> upon which vendor WTP/AC you are using.
> 
> Thanks,
>   Mike
> 
> 
> Sent: Thursday, May 04, 2006 9:04 PM
> To: Pat Calhoun (pacalhou); Kraus, Michael; [email-masked]
> Cc: [email-masked]
> explain why any such problems cannot be
> 
> solved by having the WTP and/or AC apply appropriate DSCP or 
> 802.1q marking.
> 
> >enforcement using simple ACLs, which rely on IP addresses and ports.
> >QoS is just one of many features that can be (and are) implemented 
> >through ACLs that would be very useful to CAPWAP.
> >
> >longer capable of applying QoS based on control/data plane. I think 
> >this is a serious issue, and justifies the need for two ports.
> >
> >Pat Calhoun
> >>   Maybe I'm misinterpreting something here and may be somewhat 
> >> off-topic, but often in QoS you try to classify traffic by 
> >> source/destination IP/port or by some higher level 
> interpreter (such 
> >> as NBAR in the cisco world).  If the same UDP port number is being 
> >> used for both control/data, how will intermediate 
> switches/routers be 
> >> able to determine what is control vs. data traffic?  This relates 
> >> back to your comment below of:
> >> 
> >>  "So, it all comes down to whether or not we want intermediate 
> >> network devices to distinguish between control and data."
> >> 
> >>  One possible method could be for the WTP to assign the CoS/DSCP 
> >> values for each traffic type so the administrator would have the 
> >> ability to trust the markings provided by the WTP, or 
> later perform a 
> >> DSCP-mutation.
> >> 
> products can 
> >> classify traffic by data outside of known IP/UDP headers.  
> However, I 
> >> would argue that this would likely be platform dependent.  For 
> >> example, Cisco could create a PDLM for NBAR for these mux values.
> >> But, obviously this support does not exist today, and NBAR is 
> >> dependent upon firmware/hardware support.
> >> 
> summarize the 
> >> Pros/Cons that have been already stated on this issue...
> >> 
> >> 
> >>   Thanks,
> >>      Mike
> >> 
> >> Would you explain and provide an example of use of "current QoS 
> >> tools".
> >> 
> >> Regards,
> >> /david t. perkins
> >> 
> >> -
> >> > That is, adding the MUX header does not require any 
> modification of 
> >> > the
> >> openSSL.
> everything

---

From: "Kraus, Michael" <[email-masked]>
Date: Fri, 5 May 2006 12:46:43 -0500

My oversight there!!  Is it needed to specify that data traffic "SHOULD" be
passed without setting the 802.1p/DSCP value?  Or, is it safe to assume this? 

-----Original Message-----
From: Puneet [mailto:[email-masked]] 
Sent: Friday, May 05, 2006 11:27 AM
To: Kraus, Michael
Cc: Scott G. Kelly; Pat Calhoun (pacalhou); [email-masked];
[email-masked]

> However, I have not seen any mention that if we are going to pursue 
> using a mux header that this would be incorporated into the changes.  
> If this was to be done, it would really make sense for the CAPWAP WG 
> to make CoS/DSCP recommendations for these values.  Vendor 
> interoperability is somewhat hampered from a usability perspective if 
> you need to do different DSCP mutations based upon which vendor WTP/AC you are
using.

I thought the draft did make CoS DSCP recommendations for the control channel.
>From Section 4.3.3.  Quality of Service.

   802.1P:  The precedence value of 7 SHOULD be used.

   DSCP:  The DSCP tag value of 46 SHOULD be used.

so if we use the MUX header, and also specify these DSCP/802.1P values, then is
there still any QoS related benefit in breaking up the control and data channels
into two different ports?

Thanks,
Puneet

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 9 May 2006 14:10:34 -0700 (GMT-07:00)

Meant to send this to the list...

-----Forwarded Message-----
>From: "Scott G. Kelly" <[email-masked]>
>Sent: May 8, 2006 6:27 PM
>To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
>It seems clear that the AC/WTP should not be applying a one-size-fits-all QoS policy to the data channel.  It also seems clear that they can affect control channel QoS using appropriate standardized QoS marking techniques. 
>
>Currently deployed Internet gear uses these standardized techniques to implement QoS, and we've heard no compelling arguments as to why these standards are insufficient for our purposes.
>
>Based on the messages in this and previous related threads, there is no technical basis for using separate UDP ports, but there is clear technical rationale for multiplexing data and control over one UDP channel. 
>
>
>>From: [email-masked]
>>Sent: May 5, 2006 11:40 AM
>>To: [email-masked], [email-masked], [email-masked], [email-masked]
>>Question, doesn't the QoS of the STA's data need to determine the QoS of
>>the data channel carrying it? Other tunnels often copyout the inner DSCP
>>to the outer.
>>
>>BR,
>>Michael
>>
>>From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
>>Sent: Friday, May 05, 2006 7:27 AM
>>To: Kraus, Michael; Scott G. Kelly; [email-masked]
>>Cc: [email-masked]
>>> I know of many enterprises who have multiple 54Mbps access points all 
>>> run back to the same switch, which have a 100Mbps uplink.  In the 
>>> future, I am anticipating multiple 802.11n access points with a single
>>
>>> 1Gbps uplink.  For temporary uses(conferences), I have even setup a 
>>> WTP having a WAN link back to the AC.  My point being, is that there 
>>> will always be environments where congestion will occur between the 
>>> WTP and the AC.  In a perfect world, there is no over-subscription and
>>
>>> no congestion.
>>> 
>>> When congestion occurs, typically you want to ensure that the data 
>>> traffic is dropped, not the control traffic.  I agree with your 
>>> statement that the WTP or AC could apply the appropriate DSCP or 
>>> 802.1q marking, and I had too suggested that earlier:
>>> 
>>> If this was to be
>>> done, it would really make sense for the CAPWAP WG to make CoS/DSCP 
>>> recommendations for these values.  Vendor interoperability is somewhat
>>
>>> hampered from a usability perspective if you need to do different DSCP
>>
>>> mutations based upon which vendor WTP/AC you are using.
>>> 
>>> Thanks,
>>>   Mike
>>> 
>>> 
>>> Please explain what problem is encountered if the same QoS policy is 
>>> applied to both control and data traffic. Also explain why any such 
>>> problems cannot be
>>> 
>>> solved by having the WTP and/or AC apply appropriate DSCP or 802.1q 
>>> marking.
>>>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 May 2006 06:30:29 -0700

> >Currently deployed Internet gear uses these standardized 
> techniques to implement QoS, and we've heard no compelling 
> arguments as to why these standards are insufficient for our purposes.

I disagree with your assessment, and don't believe we have rough
consensus. 

A packet is received by the AP. The AP will have to mark the outer
header to replicate the inner header. The AP doesn't have all of the
complex QoS policies that are required to determine how to deal with the
packet - so the best it can do is replication. The edge device will have
to police, and optionally remark. It may have a separate set of policies
for data vs. control, because the admin knows that control is more
important.

I honestly don't see how the edge device does this job without knowing
the difference between a data packet and a control packet.

Pat Calhoun

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 10 May 2006 15:37:29 -0400 (EDT)

Hi Pat,

>the difference between a data packet and a control packet.

Actually, I don't agree that the WTP can't enforce QoS policies - that's an implementation choice, but it's also beside the point.

Your earlier arguments seemed to indicate that intermediate devices need the UDP header to apply some sort of "QoS ACLs". We saw in discussion on this list that this is not the case. 

This current comment suggests that some "edge device" may need to re-mark packets.  Since these packets are tunneled to the AC, the AC must be the edge device we're talking about here, and if this is true, I'm not understanding is why the AC can't look at a mux header to make the decision. Modern NPUs can easily scan 64 bytes into the packet, and many can go as far as you like.

Are you saying your hardware has some limitation which precludes this?

Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 11 May 2006 06:59:07 -0400 (EDT)

Hi Bob,

I have some questions which I've inlined below...

Bob O'Hara wrote:
>The issue is that the AC is not generally the edge device, i.e., the
>first device that encounters a packet sent from the WTP.  We are not
>mandating (and, in fact, cannot mandate) that the AC live in the wiring
>closet and connect directly to the WTPs.  Therefore, the packets from
>the WTPs pass through an arbitrary number of layer 2 and layer 3 devices
>before arriving at the AC.  
>
>It is at one or more, possibly every one, of these existing intermediate
>devices that the QoS ACLs are currently applied.  By hiding the
>distinction between data and control inside the mux header, we
>immediately prevent all of those existing devices from applying QoS to
>the CAPWAP protocol control and data transmissions, differentially.  
>
>As has been pointed out in previous postings, there are valid reasons
>for desiring to apply this differential QoS to control and data.  The
>mux header prevents this and therefore is not a viable solution for
>CAPWAP.  If we persist on this path, we will wind up with a protocol
>that will find little acceptance.

It's been suggested that control traffic should in some cases have a higher priority than some other traffic, and I'm not disagreeing with this. Since the AC and/or WTP generate all control traffic, they are at liberty to apply the appropriate QoS markings for achieving this, so I see no problem so far. Also, we seem to allow that data packets flowing between the AC and WTP will have been somehow subjected to the network's QoS policy (and accordingly marked) before beginning traversal of the AC/WTP  link.

This being the case, I don't see a problem, so maybe I'm missing something here (and if so, maybe you can enlighten me). There seem to be a couple of underlying assertions here:

1) Data traffic traversing the link between the AC and WTP will have QoS markings. That is, either the endpoints or the AC/WTP will apply these markings with the goal of realizing some sort of traffic engineering policy. 

2) there will be middleboxes between the AC and WTP that optionally alter QoS markings enroute (this is surprising to me, but let's see where it takes us)

3) for some reason, these middleboxes cannot see anything past the UDP header

4) these middleboxes must distinguish between capwap control and data somehow, i.e. they will remap QoS for data differently than they remap QoS for control traffic

Keeping in mind that the AC and WTP can apply whatever markings the administrator deems appropriate for control traffic, there are a few things that confuse me about all of this. 

First, as a consequence of (3), we must blindly apply a uniform mapping function to all data traffic. That is, since we can't tell anything other than that it is data (since we can't look beyond the udp header), we must do a 1 to 1 mapping from the initial marking value to a new marking value, one which entirely ignores the encapsulated application. This is effectively a reversible coordinate shift, in that we are either promoting or demoting data traffic en masse at any given point in time.

Second, in such a universe it is not clear to me why the control traffic (which presumably has been suitably marked by the AC or WTP) would be subject to a different (re)mapping function than the data traffic. If all the traffic must make its way to the AC, and you are blindly remapping data traffic QoS, why would this remapping not also apply (blindly) to control traffic? And if control traffic is not to be remapped, why can't this be accomplished by simply not remapping traffic above a certain prioirity, and setting the control traffic markings accordingly?

In any event, if you could explain some of the use cases you envision and show how they would encounter problems, perhaps this would all be more clear. I don't know about anyone else here, but I'm having a really hard time understanding what we are trying to achieve with this selective remapping.

Scott

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 11 May 2006 17:36:47 -0700

Philip,

NAT would certainly introduce a complication.  But, expecting QoS to be
maintained over the general internet without an SLA from your service
provider is a bit of pie in the sky, today.

 -Bob
 
-----Original Message-----
From: Philip Rakity [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2006 5:08 PM
To: Bob O'Hara (boohara)
Cc: capwap
Subject: Re: [Capwap] to mux or not to mux?

Bob,

Good summary.

One point I am a little confused about is how NAT is handled when we  
use different ports etc.  I would have thought that the devices a  
long the way would need to be changed to handle this.  Another ALG.   
Did I miss understand something?

regards,

Philip

On May 10, 2006, at 2:10 PM, Bob O'Hara (boohara) wrote:

> Sent: Wednesday, May 10, 2006 12:38 PM
> To: Pat Calhoun (pacalhou); capwap
> Subject: RE: RE: [Capwap] to mux or not to mux?
>
> Hi Pat,
>
> Actually, I don't agree that the WTP can't enforce QoS policies -  
> that's
> an implementation choice, but it's also beside the point.
>
> Your earlier arguments seemed to indicate that intermediate devices  
> need
> the UDP header to apply some sort of "QoS ACLs". We saw in  
> discussion on
> this list that this is not the case.
>
> This current comment suggests that some "edge device" may need to
> re-mark packets.  Since these packets are tunneled to the AC, the AC
> must be the edge device we're talking about here, and if this is true,
> I'm not understanding is why the AC can't look at a mux header to make
> the decision. Modern NPUs can easily scan 64 bytes into the packet,  
> and
> many can go as far as you like.
>

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.