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

From: "Kraus, Michael" <[email-masked]>
Date: Thu, 4 May 2006 09:01:20 -0500

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.

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

Message: 1
Date: Wed, 3 May 2006 15:16:21 -0700 (PDT)
From: "David T. Perkins" <[email-masked]>
Subject: Re: [Capwap] to mux or not to mux?
To: Charles Clancy <[email-masked]>
Cc: capwap <[email-masked]>
Message-ID:
	<[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:
> The DTLS tunnels would NOT be merged.  You'd have something like:

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

> +---------+------------+------------------------
> | 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.
> 
> --
> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> 
> Nancy Winget (ncamwing) wrote:
> > Charles,
> > 
> > With a MUX, yes they are logical channels, but I believe the 
> > implication is that these channels are merged into a single DTLS 
> > tunnel...are you saying they are not?
> > 
> > But as you state, if UDP is a MUX header, why the need to introduce 
> > yet another one instead of just using UDP for separation?
> > 
> > 	Nancy.   
> > 
> > -----Original Message-----
> > From: Charles Clancy [mailto:[email-masked]]
> > Sent: Wednesday, May 03, 2006 2:29 PM
> > To: Michael Montemurro
> > Cc: Nancy Winget (ncamwing); capwap
> > Subject: Re: [Capwap] to mux or not to mux?
> > 
> > Even with the MUX header, you have two independent, logical channels. 
> > If you think about it, UDP is really just one big MUX header.  What 
> > we're doing is really nothing different.  It should not impact 
> > anything to do with sequence numbers or key derivation.
> > 
> > --
> > t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> > 
> > Michael Montemurro wrote:
> > 
> >>Nancy brings up an interesting point here.
> >> 
> >>If we go with the MUX header approach, how do we achieve key 
> >>separation between the control and data channels?
> >> 
> >>How do we derive the keys and how do we maintain sequence counters.
> >> 
> >>Cheers,
> >> 
> >>        Mike
> >> 
> >>
> >>
> >> 
> >>On 5/2/06, *Nancy Winget (ncamwing)* <[email-masked] 
> >><mailto:[email-masked]>> wrote:
> >>
> >>
> >>    I don't believe adding a MUX is the right answer.  First, the
> > 
> > addition
> > 
> >>    is a change in DTLS and also brings up other issues of concern:
> >>    - distinguishing the control from data plane is a good thing as
> > 
> > the
> > 
> >>    firewall rules may be different for each plane which is already
> >>    addressed by the UDP assignments.
> >>    - merging the control and data plane into a single UDP (dtls)
> > 
> > tunnel
> > 
> >>    forces the two planes to be synchronized from an anti-replay
> >>    perspective. This effectively restricts the architecture to 
> >> force
> > 
> > them
> > 
> >>    to use a centralized DTLS encapsulation/decapsulation which imho
> > 
> > is too
> > 
> >>    restrictive
> >>
> >>           Nancy.
> >>
> >>    -----Original Message-----
> >>    From: Scott G. Kelly [mailto:[email-masked]
> >>    <mailto:[email-masked]>]
> >>    Sent: Monday, May 01, 2006 11:38 AM
> >>    To: capwap
> >>    Subject: [Capwap] to mux or not to mux?
> >>
> >>    Some time ago, I proposed that we use a single port for capwap,
> > 
> > and
> > 
> >>    insert a mux header right after the UDP header to differentiate
> > 
> > between
> > 
> >>    control and data. While there was some discussion, we did not
> > 
> > reach a
> > 
> >>    conclusion.
> >>
> >>    Here's what it would look like:
> >>
> >>    +---------+-------------+-------------------------------
> >>    | UDP Hdr | MUX Hdr = 1 | DTLS Enc Control Packet ....
> >>    +---------+-------------+----------------------
> >>
> >>    The capwap editors are currently working hard to produce the 01
> > 
> > version
> > 
> >>    of the capwap document, and it would be best for implementers if
> > 
> > this
> > 
> >>    question could be decided prior to publication of that document.
> > 
> > To
> > 
> >>    facilitate this, I've summarized briefly below.
> >>
> >>    Using separate ports for control/data has a number of drawbacks:
> >>
> >>    - if firewalls are between the AC and WTP, multiple rules are 
> >>required
> >>
> >>    - we must be able to explicitly bind the data and control 
> >> channels
> > 
> > at
> > 
> >>    the AC in order to ensure proper operation; if they use the same
> > 
> > port
> > 
> >>    (and therefore, flow), this is straightforward; if not, we must
> > 
> > add
> > 
> >>    protocol elements for detecting and accounting for NATs along 
> >> the
> > 
> > AC-WTP
> > 
> >>    path, and for explicitly (and securely) creating the bindings
> > 
> > between
> > 
> >>    the two channels
> >>
> >>    - there are race conditions that must be dealt with; in
> > 
> > particular, it
> > 
> >>    is possible to have the left hand (control channel) not knowing
> > 
> > for
> > 
> >>    certain what the right hand (data channel) is doing (and vice
> >>versa)
> >>
> >>    - If there *are* NATs along the path, using two ports will require
> >>    keepalives on both ports, and error handling for when one 
> >> channel
> > 
> > goes
> > 
> >>    away but the other does not (e.g. if a middlebox deletes the NAT
> >>    bindings for any reason)
> >>
> >>    - there are many more error conditions to manage in the state
> > 
> > machine,
> > 
> >>    due to the channel binding and NAT issues
> >>
> >>    Clearly, using two ports adds *significant* complexity to the
> >>    implementation, and will likely result in operational problems 
> >> in
> > 
> > some
> > 
> >>    environments.
> >>
> >>    Using a mux header has one drawback (that I can think of):
> >>
> >>    - it adds n bytes to the header. I'm tempted to say n will be 4
> > 
> > for
> > 
> >>    32-bit alignment, but it could also be only 1 or 2 bytes, if
> >>    bits-on-the-wire overhead is an overriding concern.
> >>
> >>    Using a mux hader has several advantages:
> >>
> >>    - we get NAT traversal for free, by simply configuring the echo
> > 
> > interval
> > 
> >>    to be smaller than the NAT binding lifetime for the path in 
> >>question
> >>
> >>    - we only open one port through intermediate firewalls (and any
> >>    intermediate NATs)
> >>
> >>    - the implementation (state machine, error handling) is *much*
> > 
> > simpler,
> > 
> >>    and therefore more likely
> >>    to (inter)operate according to spec
> >>
> >>    We need to decide on this, preferably within the next day or two.
> >>    Please
> >>    speak up and make your preferences known.
> >>
> >>    Thanks,
> >>
> >>    Scott
> >>
> >>    _________________________________________________________________
> >>    To unsubscribe or modify your subscription options, please visit:
> >>    http://lists.frascone.com/mailman/listinfo/capwap
> >>
> >>    Archives: http://lists.frascone.com/pipermail/capwap
> >>    _________________________________________________________________
> >>    To unsubscribe or modify your subscription options, please visit:
> >>    http://lists.frascone.com/mailman/listinfo/capwap
> >>
> >>    Archives: http://lists.frascone.com/pipermail/capwap
> >>
> >>
> >>
> >>--------------------------------------------------------------------
> >>--
> >>--
> >>
> >>_________________________________________________________________
> >>To unsubscribe or modify your subscription options, please visit:
> >>http://lists.frascone.com/mailman/listinfo/capwap
> >>
> >>Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 

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

Message: 2
Date: Wed, 03 May 2006 15:25:48 -0700
From: Jim Murphy <[email-masked]>
Subject: Re: [Capwap] BSSID-WLAN mappings
To: "T. Charles Clancy" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252; format=flowed

T. Charles Clancy wrote:
> 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.

It doesn't matter if the packet originated on the wired side or not because all
broadcast packets from stations must be retransmitted by the AP.

Yes, people should be using good crypto, but we should not limit the legitimate
flexibility of the protocol to enforce it.

Thanks,

Jim

> --
> 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: Wed, 3 May 2006 16:19:03 -0700
From: "Dorothy Stanley" <[email-masked]>
Subject: Re: [Capwap] Re: Issues 101: 11.8.1.1 Change to re-use 802.11
	Information element definitions
To: Puneet <[email-masked]>
Cc: [email-masked]
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Puneet, all,

>         2. for the encryption policies we could use the format used in
> the RSN IEs (OUI + encryption_type); that allows support for different
> vendor specific encryption types in a clean manner (CKIP for example
> would then use the Cisco OUI, instead of being clubbed together with the
> other 'standard' encryption types; and it makes it easier for vendors to
> not step on each others toes).

Agree that this approach should be used to indicate ciphersto use. This IE
is used to
add a WLAN (BSS) on the WTP (also one for Update WLAN).
Why is delivering the RSNIE/WPAIE not enough here - since the
group key cipher is indicated in those IEs? Suggest deleting the encryption

policy
field in the IEEE 802.11 Add WLAN and Update WLAN message elements.

Separately, the encryption policy in the IEEE Mobile Session Key message
element
should be updated to use the RSNIE format.

Dorothy

On 5/3/06, Puneet <[email-masked]> wrote:
>
> >   1. does the encryption policy refer to broadcast traffic or
> > unicast too? If its also unicast, then there could be multiple
> > encryption types enabled at the same type on the WLAN, in that case how

> > is the encryption-policy field filled in?
> >
> > <PRC>
> > This is a good question as the text is obviously not clear enough. I am

> > proposing the following text (as well as for the Update WLAN section):
> >
> >    Encryption Policy:  A 32-bit value specifying the encryption scheme
> >       to apply to traffic to and from the mobile station.
>
> this might also be a good place to note that the format of those 32
> bits is the same as what the IEEE 802.11i specification mentions. That
> allows vendor specific encryption types, and can also be updated by
> IEEE for new types without having to update the CAPWAP specification.
>
> >         2. for the encryption policies we could use the format used in
> > the RSN IEs (OUI + encryption_type); that allows support for different
> > vendor specific encryption types in a clean manner (CKIP for example
> > would then use the Cisco OUI, instead of being clubbed together with the
> > other 'standard' encryption types; and it makes it easier for vendors to
> > not step on each others toes).
> >
> > <PRC>
> > Based on Dorothy's e-mail and recommendation, I would propose the
> > following new section:
> >
> > 11.8.1.4.  IEEE 802.11 Information Element
> >
> >    The IEEE 802.11 Information Element is used to communicate any IE
> >    defined in the IEEE 802.11 protocol.  The data field contains the raw
> >    IE as it would be included within an IEEE 802.11 MAC management
> >    message.
>
> <snip>
>
> I think my request was to change the encryption-type to use the IEEE
> 802.11i format, but thats now what this element seems to do. Can we
> replace those list of numbers 1,2,3,4,5 for encryption types since in
> the current text they mix standard and vendor specific types, and if
> IEEE updates something in 802.11i, we'll need to update the capwap
> spec again.
>
> >         4. Does the 'Suppress SSID' field also disable the use of that
> > SSID in broadcast probe responses? If so, why do we also need the 'IEEE

> > 802.11 Broadcast Probe Mode' in section 11.9.12? Also, why is this IE
> > global for the WTP? The AC might configure the WTP with 10 WLANs, but it
> > may want probe responses generated for only four of those when a
> > broadcast probe request comes in.
> >
> > <PRC> Section 11.9.12 deals with the changing of the mode of operation
> > after the WLAN is already operational.</PRC>
>
> I still dont understand why this needs to be global. To quote the current

> draft:
> "Since broadcast NULL probes are not sent to a specific BSSID, the WTP
> cannot know
> which SSID the sending station is querying.  Therefore, this behavior
> must be global
> to the WTP."
> However when a broadcast probe request comes in, of all the WLANs
> mapped to that WTP, the user should be able to configure which ones
> are responded to. That text seems incorrect.
>
> Thanks,
> Puneet
> _________________________________________________________________
> 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/20060503/109b5034/attach
ment.htm

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

_________________________________________________________________
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 15
*************************************

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: "David T. Perkins" <[email-masked]>
Date: Thu, 4 May 2006 07:19:53 -0700 (PDT)

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