Subject: [Capwap] Section 11.8.1.1 'IEEE 802.11 Add WLAN'

From: Puneet <[email-masked]>
Date: Fri, 14 Apr 2006 00:28:32 -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?

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

3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 bytes? If each
of those IEs is preceded by an element that specifies their lengths, then
the IEs could be made variable length.

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

5. maybe rename WME to WMM?

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: Tue, 18 Apr 2006 19:10:49 -0700

Hi Puneet,

For the moment, I've included these questions in issue 101, since all are
related to 11.8.1.1, but can open a new issue
if needed. Comments inline

Dorothy

On 4/14/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?
>

It's likely broadcast only. A single key is included - the GTK?
But since the WPAIE and RSNIE are included, it's not clear the encryption
policy is needed, since the
valid ciphersuites to advertize in the beacons - unicast and broadcast are
included in the IEs.

> encryption types; and it makes it easier for vendors to not step on each

Agreed, see Issue 101

> the IEs could be made variable length.

Also see issue 101. New IEs should not be defined here, but the existing
802.11 IE definitions re-used

> broadcast probe responses? If so, why do we also need the 'IEEE 802.11Broadcast 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.
>

Agree, need to retain flexibility for the AC to customize the probe
responses generated.

Agreed

 Thanks,

---

From: Puneet <[email-masked]>
Date: Thu, 20 Apr 2006 10:25:22 -0700

> related to 11.8.1.1, but can open a new issue if needed. Comments inline
>

thanks, I think a single issue is fine.

> valid ciphersuites to advertize in the beacons - unicast and broadcast are

If its broadcast-only, can we change the text from:

Encryption Policy:  A 32-bit value specifying the encryption scheme to
apply to *traffic to and from* the mobile station

to:

Encryption Policy:  A 32-bit value specifying the encryption scheme to
apply to *broadcast trafic to* the mobile stations

Thanks,
Puneet

>  3. why are the lengths of the IEs (WPA, RSN etc) fixed at 32 bytes? If
> > each of those IEs is preceded by an element that specifies their lengths,
> > then the IEs could be made variable length.
> >
>