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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 28 Apr 2006 11:49:08 -0700

I believe there are many issues in issue 101, some of which were
introduced by Dorothy. I believe that my proposal (below) covers all
sections. Comments most welcomed!

	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.  The
      applicability of the encryption policy depends upon the security
      policy.  For static WEP keys, which is true when the 'Shared Key'
      bit is set, this encryption policy is relevant for both unicast
      and multicast traffic.  For encryption schemes that employ a
      separate encryption key for unicast and multicast traffic, the
      encryption policy defined here only applies to multicast data.  In
      these scenarios, the unicast encryption policy is communicated via
      the Add Mobile (Section 9.1.1).
[...]
   Shared Key:  A 1 byte boolean that specifies whether the key included
      in the Key field is a shared WEP key.  When set to one, the WLAN
      employs a shared WEP key, also known as a static WEP key, and uses
      the encryption key for both unicast and multicast traffic for all
      stations.  A value of zero, with the 'Encryption Policy' field set
      to any value other than 'Clear Text' means that the WLAN uses per-
      station encryption keys, and therefore the key in the 'Key' field
      is only used for multicast traffic.
</PRC>
	
	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.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-
     | Info Element
     +-+-+-+-+-+-+-+-

   Type:  TBD for IEEE 802.11 Information Element

   Length:  >= 1

   Info Element:  The IEEE 802.11 Information Element, which includes
      the type, length and value field.

However, I do not believe that everything can be moved out at this
point. So I would propose changing the Add WLAN to be the following:

11.8.1.1.  IEEE 802.11 Add WLAN

   The Add WLAN message element is used by the AC to define a wireless
   LAN on the WTP.  The inclusion of this message element MUST also
   include the IEEE 802.11 Information Element message element,
   containing the following 802.11 IEs:
      Capability
      WPA IE
      RSN IE
      EDCA Parameter Set IE
      QoS Capability IE
      WMM IE

   The value contains 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    WLAN ID    |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Encryption Policy                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Key Index   |   Shared Key  |      QoS      |   Auth Type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   MAC Mode    |  Tunnel Mode  | Suppress SSID |    SSID ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</PRC>	

	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. 

<PRC> Thanks, that has been fixed</PRC>
	
	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>
	
	5. maybe rename WME to WMM? 

<PRC> No longer relevant </PRC>
	
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