Subject: [Capwap] Re: Issues 101: 11.8.1.1 Change to re-use 802.11 Information element definitions

From: Puneet <[email-masked]>
Date: Wed, 3 May 2006 10:11:54 -0700

>   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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 3 May 2006 16:19:03 -0700

Puneet, all,

> 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