idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2579. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6263 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 2490, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2501, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2504, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2507, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 4017 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 4118 (ref. '7') ** Obsolete normative reference: RFC 4346 (ref. '8') (Obsoleted by RFC 5246) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun, Editor 3 Internet-Draft Cisco Systems, Inc. 4 Expires: September 5, 2007 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 March 4, 2007 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 5, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Wireless LAN product architectures have evolved from single 45 autonomous access points to systems consisting of a centralized 46 Access Controller (AC) and Wireless Termination Points (WTPs). The 47 general goal of centralized control architectures is to move access 48 control, including user authentication and authorization, mobility 49 management and radio management from the single access point to a 50 centralized controller. 52 This specification defines the Control And Provisioning of Wireless 53 Access Points (CAPWAP) Protocol Binding Specification for use with 54 the IEEE 802.11 Wireless Local Area Network protocol. The CAPWAP 55 Protocol Specification is defined separately [1]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Conventions used in this document . . . . . . . . . . . . 4 62 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 6 64 2.1. Split MAC and Local MAC Functionality . . . . . . . . . . 6 65 2.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 9 67 2.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . . 12 68 2.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . . 13 69 2.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . . 14 70 2.5. Quality of Service for IEEE 802.11 MAC Management 71 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 2.6. Run State Operation . . . . . . . . . . . . . . . . . . . 14 73 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 15 74 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 15 75 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 16 76 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 17 77 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 19 78 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 19 79 5.2. Discovery Response Message . . . . . . . . . . . . . . . . 19 80 5.3. Primary Discovery Request Message . . . . . . . . . . . . 19 81 5.4. Primary Discovery Response Message . . . . . . . . . . . . 19 82 5.5. Join Request Message . . . . . . . . . . . . . . . . . . . 19 83 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 20 84 5.7. Configuration Status Message . . . . . . . . . . . . . . . 20 85 5.8. Configuration Status Response Message . . . . . . . . . . 20 86 5.9. Configuration Update Request Message . . . . . . . . . . . 21 87 5.10. Station Configuration Request . . . . . . . . . . . . . . 22 88 5.11. Change State Event Request . . . . . . . . . . . . . . . . 22 89 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 22 90 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 23 91 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 23 92 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 27 93 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 28 94 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 29 95 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 29 96 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 30 97 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 31 98 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 33 99 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 33 100 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 34 101 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 35 102 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 36 103 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 38 104 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 39 105 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 39 106 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 41 107 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 45 108 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 45 109 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 46 110 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 46 111 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 47 112 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 49 113 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 50 114 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 52 115 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 52 116 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 54 117 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 54 118 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 54 119 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 54 120 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 54 121 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 54 122 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 54 123 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 54 124 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 54 125 8. Technology Specific Message Element Values . . . . . . . . . . 55 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 56 127 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 56 128 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 129 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 59 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 131 12.1. Normative References . . . . . . . . . . . . . . . . . . . 60 132 12.2. Informational References . . . . . . . . . . . . . . . . . 61 133 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 134 Intellectual Property and Copyright Statements . . . . . . . . . . 63 136 1. Introduction 138 This specification defines the Control And Provisioning of Wireless 139 Access Points (CAPWAP) Protocol Binding Specification for use with 140 the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP 141 control message fields, new control messages and message elements are 142 defined. The minimum required definitions for a binding-specific 143 Statistics message element, Station message element, and WTP Radio 144 Information message element are included. 146 1.1. Goals 148 The goals for this CAPWAP protocol binding are listed below: 150 1. To centralize the authentication and policy enforcement functions 151 for an IEEE 802.11 wireless network. The AC may also provide 152 centralized bridging, forwarding, and encryption of user traffic. 153 Centralization of these functions will enable reduced cost and 154 higher efficiency by applying the capabilities of network 155 processing silicon to the wireless network, as in wired LANs. 157 2. To enable shifting of the higher level protocol processing from 158 the WTP. This leaves the time-critical applications of wireless 159 control and access in the WTP, making efficient use of the 160 computing power available in WTPs which are subject to severe cost 161 pressure. 163 The CAPWAP protocol binding extensions defined herein apply solely to 164 the interface between the WTP and the AC. Inter-AC and station-to-AC 165 communication are strictly outside the scope of this document. 167 1.2. Conventions used in this document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [2]. 173 1.3. Terminology 175 Access Controller (AC): The network entity that provides WTP access 176 to the network infrastructure in the data plane, control plane, 177 management plane, or a combination therein. 179 Basic Service Set (BSS): A set of stations controlled by a single 180 coordination function. 182 Distribution: The service that, by using association information, 183 delivers medium access control (MAC) service data units (MSDUs) 184 within the distribution system (DS). 186 Distribution System Service (DSS): The set of services provided by 187 the distribution system (DS) that enable the medium access control 188 (MAC) layer to transport MAC service data units (MSDUs) between 189 stations that are not in direct communication with each other over a 190 single instance of the wireless medium (WM). These services include 191 the transport of MSDUs between the access points (APs) of basic 192 service sets (BSSs) within an extended service set (ESS), transport 193 of MSDUs between portals and BSSs within an ESS, and transport of 194 MSDUs between stations in the same BSS in cases where the MSDU has a 195 multicast or broadcast destination address, or where the destination 196 is an individual address, but the station sending the MSDU chooses to 197 involve the DSS. DSSs are provided between pairs of IEEE 802.11 198 MACs. 200 Integration: The service that enables delivery of medium access 201 control (MAC) service data units (MSDUs) between the distribution 202 system (DS) and an existing, non-IEEE 802.11 local area network (via 203 a portal). 205 Station (STA): A device that contains an IEEE 802.11 conformant 206 medium access control (MAC) and physical layer (PHY) interface to the 207 wireless medium (WM). 209 Portal: The logical point at which medium access control (MAC) 210 service data units (MSDUs) from a non-IEEE 802.11 local area network 211 (LAN) enter the distribution system (DS) of an extended service set 212 (ESS). 214 WLAN: In this document, WLAN refers to a logical component 215 instantiated on a WTP device. A single physical WTP may operate a 216 number of WLANs. Each Basic Service Set Identifier (BSSID) and its 217 constituent wireless terminal radios is denoted as a distinct WLAN on 218 a physical WTP. 220 Wireless Termination Point (WTP): The physical or network entity that 221 contains an IEEE 802.11 RF antenna and wireless PHY to transmit and 222 receive station traffic for wireless access networks. 224 2. IEEE 802.11 Binding 226 This section describes use of the CAPWAP protocol with the IEEE 227 802.11 Wireless Local Area Network protocol, including Local and 228 Split MAC operation, Group Key Refresh, BSSID to WLAN Mapping, IEEE 229 802.11 MAC management frame Quality of Service tagging and Run State 230 operation. 232 2.1. Split MAC and Local MAC Functionality 234 The CAPWAP protocol, when used with IEEE 802.11 devices, requires 235 specific behavior from the WTP and the AC to support the required 236 IEEE 802.11 protocol functions. 238 For both the Split and Local MAC approaches, the CAPWAP functions, as 239 defined in the taxonomy specification [7], reside in the AC. 241 This is a placeholder for the resolution of issue 138 once agreement 242 has been reached in the working group. 244 2.1.1. Split MAC 246 This section shows the division of labor between the WTP and the AC 247 in a Split MAC architecture. Figure 1 shows the separation of 248 functionality between CAPWAP components. 250 Function Location 251 Distribution Service AC 252 Integration Service AC 253 Beacon Generation WTP 254 Probe Response Generation WTP 255 Power Mgmt/Packet Buffering WTP 256 Fragmentation/Defragmentation WTP/AC 257 Assoc/Disassoc/Reassoc AC 259 IEEE 802.11 QOS 260 Classifying AC 261 Scheduling WTP/AC 262 Queuing WTP 264 IEEE 802.11 RSN 265 IEEE 802.1X/EAP AC 266 RSNA Key Management AC 267 IEEE 802.11 Encryption/Decryption WTP/AC 269 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 271 In a Split MAC Architecture,the Distribution and Integration services 272 reside on the AC, and therefore all user data is tunneled between the 273 WTP and the AC. As noted above, all real-time IEEE 802.11 services, 274 including the beacon and probe response frames, are handled on the 275 WTP. 277 All remaining IEEE 802.11 MAC management frames are supported on the 278 AC, including the Association Request frame which allows the AC to be 279 involved in the access policy enforcement portion of the IEEE 802.11 280 protocol. The IEEE 802.1X and IEEE 802.11 key management function 281 are also located on the AC. This implies that the AAA client also 282 resides on the AC. 284 While the admission control component of IEEE 802.11 resides on the 285 AC, the real time scheduling and queuing functions are on the WTP. 286 Note that this does not prevent the AC from providing additional 287 policy and scheduling functionality. 289 Note that in the following figure, the use of '( - )' indicates that 290 processing of the frames is done on the WTP. 292 Client WTP AC 294 Beacon 295 <----------------------------- 296 Probe Request 297 ----------------------------( - )-------------------------> 298 Probe Response 299 <----------------------------- 300 802.11 AUTH/Association 301 <---------------------------------------------------------> 302 Station Configuration Request[Add Station (Station Message Elements)] 303 <-------------------------> 304 802.1X Authentication & 802.11 Key Exchange 305 <---------------------------------------------------------> 306 Station Configuration Request[Add Station (AES-CCMP, PTK=x)] 307 <-------------------------> 308 802.11 Action Frames 309 <---------------------------------------------------------> 310 802.11 DATA (1) 311 <---------------------------( - )-------------------------> 313 Figure 2: Split MAC Message Flow 315 Figure 2 provides an illustration of the division of labor in a Split 316 MAC architecture. In this example, a WLAN has been created that is 317 configured for IEEE 802.11, using 802.1X based end user 318 authentication and AES-CCMP link layer encryption. The following 319 process occurs: 321 o The WTP generates the IEEE 802.11 beacon frames, using information 322 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 323 message element, including the RSNIE, which indicates support of 324 802.1X and AES-CCMP. 326 o The WTP processes the probe request frame and responds with a 327 corresponding probe response frame. The probe request frame is 328 then forwarded to the AC for optional processing. 330 o The WTP forwards the IEEEE 802.11 Authentication and Association 331 frames to the AC, which is responsible for responding to the 332 client. 334 o Once the association is complete, the AC transmits a Station 335 Configuration Request message, which includes an Add Station 336 message element, to the WTP (see Section 4.5.8 in [1]). In the 337 above example, the WLAN was configured for IEEE 802.1X. 339 o If the WTP is providing encryption/decryption services, once the 340 client has completed the IEEE 802.11 key exchange, the AC 341 transmits another Station Configuration Request message which 342 includes an Add Station message element, an IEEE 802.11 Station 343 message element, an IEEE 802.11 Station Session Key message 344 element and an IEEE 802.11 Information Element message element 345 which includes the RSNIE to the WTP, delivering the security 346 policy to enforce for the station (in this case AES-CCMP), and the 347 encryption key to use. If encryption/decryption is handled in the 348 AC, the IEEE 802.11 Information message element with an RSNIE 349 would not be included. 351 o The WTP forwards any IEEE 802.11 Management Action frames received 352 to the AC. 354 o All IEEE 802.11 station data frames are tunneled between the WTP 355 and the AC. 357 The WTP SHALL include the IEEE 802.11 MAC header contents in all 358 frames transmitted to the AC. When 802.11 encryption/decryption is 359 performed at the WTP,the WTP SHALL decrypt the uplink frames prior to 360 transmitting the frames to the AC. The WTP SHALL also add padding, 361 if necessary, for downlink frames coming from the AC. When 802.11 362 encryption/decryption is performed at the AC,the WTP SHALL NOT 363 decrypt the uplink frames prior to transmitting the frames to the AC. 364 The AC and WTP SHALL populate the IEEE 802.11 MAC header fields as 365 described in Figure 3. 367 MAC header field Location 368 Frame Control: 369 Version AC 370 ToDS AC 371 FromDS AC 372 Type AC 373 SubType AC 374 MoreFrag WTP/AC 375 Retry WTP 376 Pwr Mgmt - 377 MoreData WTP 378 Protected AC 379 Order AC 380 Duration: WTP 381 Address 1: AC 382 Address 2: AC 383 Address 3: AC 384 Sequence Ctrl: WTP 385 Address 4: AC 386 QoS Control: AC 387 Frame Body: AC 388 FCS: WTP 390 Figure 3: Population of the IEEE 802.11 MAC header Fields for 391 Downlink Frames 393 When 802.11 encryption/decryption is performed at the AC, the 394 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 395 applicable to downlink frames, and is set to 0. Note that the FCS 396 field is not included in 802.11 frames exchanged between the WTP and 397 the AC. Upon sending data frames to the AC, the WTP is responsible 398 for validating, and stripping the FCS field. Upon receiving data 399 frames from the AC, the WTP is responsible for adding the FCS field, 400 and populating the field as described in [3]. 402 2.1.2. Local MAC 404 This section shows the division of labor between the WTP and the AC 405 in a Local MAC architecture. Figure 4 shows the separation of 406 functionality among CAPWAP components. 408 Function Location 409 Distribution Service WTP/AC 410 Integration Service WTP 411 Beacon Generation WTP 412 Probe Response Generation WTP 413 Power Mgmt/Packet Buffering WTP 414 Fragmentation/Defragmentation WTP 415 Assoc/Disassoc/Reassoc WTP/AC 417 IEEE 802.11 QOS 418 Classifying WTP 419 Scheduling WTP 420 Queuing WTP 422 IEEE 802.11 RSN 423 IEEE 802.1X/EAP AC 424 RSNA Key Management AC 425 IEEE 802.11 Encryption/Decryption WTP 427 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 429 Since the Distribution and Integration Services exist on the WTP, 430 station generated frames are not forwarded to the AC, with the 431 exception listed in the following paragraphs. 433 While the MAC is terminated on the WTP, it is necessary for the AC to 434 be aware of mobility events within the WTPs. Thus the WTP MUST 435 forward the IEEE 802.11 Association Request frames to the AC. The AC 436 MAY reply with a failed Association Response frame if it deems it 437 necessary, and upon receipt of a failed Association Response frame 438 from the AC, the WTP must send a Disassociation frame to the station. 440 The IEEE 802.1X and RSNA Key Management functions reside in the AC. 441 Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management 442 frames to the AC and forward the corresponding responses to the 443 station. This implies that the AAA client also resides on the AC. 445 Note that in the following figure, the use of '( - )' indicates that 446 processing of the frames is done on the WTP. 448 Client WTP AC 450 Beacon 451 <----------------------------- 452 Probe 453 <----------------------------> 454 802.11 AUTH 455 <----------------------------- 456 802.11 Association 457 <---------------------------( - )-------------------------> 458 Station Configuration Request[Add Station (Station Message Elements)] 459 <-------------------------> 460 802.1X Authentication & 802.11 Key Exchange 461 <---------------------------------------------------------> 462 802.11 Action Frames 463 <---------------------------------------------------------> 464 Station Configuration Request[Add Station (AES-CCMP, PTK=x)] 465 <-------------------------> 466 802.11 DATA 467 <-----------------------------> 469 Figure 5: Local MAC Message Flow 471 Figure 5 provides an illustration of the division of labor in a Local 472 MAC architecture. In this example, a WLAN that is configured for 473 IEEE 802.11 has been created using AES-CCMP for privacy. The 474 following process occurs: 476 o The WTP generates the IEEE 802.11 beacon frames, using information 477 provided to it through the Add WLAN (see Section 6.1) message 478 element. 480 o The WTP processes a probe request frame and responds with a 481 corresponding probe response frame. 483 o The WTP forwards the IEEE 802.11 Authentication and Association 484 frames to the AC. 486 o Once the association is complete, the AC transmits a Station 487 Configuration Request message, which includes the Add Station 488 message element, to the WTP (see Section 10.1 in [1]). In the 489 above example, the WLAN is configured for IEEE 802.1X, and 490 therefore the '802.1X only' policy bit is enabled. 492 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 493 messages to the AC for processing. 495 o The AC transmits another Station Configuration Request message 496 including an Add Station message element, an IEEE 802.11 Station 497 message element, an IEEE 802.11 Station Session Key message 498 element and an IEEE 802.11 Information Element message element 499 which includes the RSNIE to the WTP, stating the security policy 500 to enforce for the client (in this case AES-CCMP), as well as the 501 encryption key to use. The Add Station message element MAY 502 include a VLAN name, which when present is used by the WTP to 503 identify the VLAN on which the user's data frames are to be 504 bridged. 506 o The WTP forwards any IEEE 802.11 Management Action frames received 507 to the AC. 509 o The WTP may locally bridge client data frames (and provide the 510 necessary encryption and decryption services). The WTP may also 511 tunnel client data frames to the AC, using 802.3 frame tunnel mode 512 or 802.11 frame tunnel mode. 514 2.2. Roaming Behavior 516 This section expands upon the examples provided in the previous 517 section, and describes how the CAPWAP control protocol is used to 518 provide secure roaming. 520 Once a client has successfully associated with the network in a 521 secure fashion, it is likely to attempt to roam to another WTP. 522 Figure 6 shows an example of a currently associated station moving 523 from its "Old WTP" to a "new WTP". The figure is valid for multiple 524 different security policies, including IEEE 802.1X and WPA or WPA2, 525 both with key caching (where the IEEE 802.1x exchange would be 526 bypassed) and without. 528 Client Old WTP WTP AC 530 Association Request/Response 531 <--------------------------------------( - )--------------> 532 Station Configuration Request[Add Station (Station Message Elements)] 533 <----------------> 534 802.1X Authentication (if no key cache entry exists) 535 <--------------------------------------( - )--------------> 536 802.11 4-way Key Exchange 537 <--------------------------------------( - )--------------> 538 Station Configuration Request[Delete Station] 539 <----------------------------------> 540 Station Configuration Request[Add Station (AES-CCMP, PTK=x)] 541 <----------------> 543 Figure 6: Client Roaming Example 545 2.3. Group Key Refresh 547 Periodically, the Group Key (GTK)for the BSS needs to be updated. 548 The AC uses an EAPOL-Key frame to update the group key for each STA 549 in the BSS. While the AC is updating the GTK, each L2 broadcast 550 frame transmitted to the BSS needs to be duplicated and transmitted 551 using both the current GTK and the new GTK. Once the GTK update 552 process has completed, broadcast frames transmitted to the BSS will 553 be encrypted using the new GTK. 555 In the case of Split MAC, the AC needs to duplicate all broadcast 556 packets and update the key index so that the packet is transmitted 557 using both the current and new GTK to ensure that all STA's in the 558 BSS receive the broadcast frames. In the case of local MAC, the WTP 559 needs to duplicate and transmit broadcast frames using the 560 appropriate index to ensure that all STA's in the BSS continue to 561 receive broadcast frames. 563 The Group Key update procedure is shown in the following figure. The 564 AC will signal the update to the GTK using an IEEE 802.11 565 Configuration Request message, including an IEEE 802.11 Update WLAN 566 message element with the new GTK, its index, the TSC for the Group 567 Key and the Key Status set to 3 (begin GTK update). The AC will then 568 begin updating the GTK for each STA. During this time, the AC (for 569 Split MAC) or WTP (for Local MAC) must duplicate broadcast packets 570 and transmit them encrypted with both the current and new GTK. When 571 the AC has completed the GTK update to all STA's in the BSS, the AC 572 must transmit an IEEE 802.11 Configuration Request message including 573 an IEEE 802.11 Update WLAN message element containing the new GTK, 574 its index, and the Key Status set to 4 (GTK update complete). 576 Client WTP AC 578 IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK, GTK Index, GTK Start, Group TSC) ) 579 <---------------------------------------------- 580 802.1X EAPoL (GTK Message 1) 581 <-------------( - )------------------------------------------- 582 802.1X EAPoL (GTK Message 2) 583 -------------( - )-------------------------------------------> 584 IEEE 802.11 WLAN Configuration Request ( Update WLAN (GTK Index, GTK Complete) ) 585 <--------------------------------------------- 587 Figure 7: Group Key Update Procedure 589 2.4. BSSID to WLAN ID Mapping 591 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 592 creation of a WLAN (see Section 6.1). While manufacturers are free 593 to assign BSSIDs using any arbitrary mechanism, it is advised that 594 where possible the BSSIDs are assigned as a contiguous block. 596 When assigned as a block, implementations can still assign any of the 597 available BSSIDs to any WLAN. One possible method is for the WTP to 598 assign the address using the following algorithm: base BSSID address 599 + WLAN ID. 601 The WTP communicates the maximum number of BSSIDs that it supports 602 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 603 message element (see Section 6.23). 605 2.5. Quality of Service for IEEE 802.11 MAC Management Messages 607 It is recommended that IEEE 802.11 MAC Management frames be sent by 608 both the AC and the WTP with appropriate Quality of Service values, 609 listed below, to ensure that congestion in the network minimizes 610 occurrences of packet loss. 612 802.1P: The precedence value of 7 SHOULD be used for all IEEE 613 802.11 MAC management frames, except for Probe Requests which 614 SHOULD use 4. 616 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 617 MAC management frames, except for Probe Requests which SHOULD use 618 34. 620 2.6. Run State Operation 622 The Run state is the normal state of operation for the CAPWAP 623 protocol in both the WTP and the AC. 625 When the WTP receives a WLAN Configuration Request message (see 626 Section 3.1), it MUST respond with a WLAN Configuration Response 627 message (see Section 3.2) and it remains in the Run state. 629 When the AC sends a WLAN Configuration Request message (see 630 Section 3.1) or receives the corresponding WLAN Configuration 631 Response message (see Section 3.2) from the WTP, it remains in the 632 Run state. 634 3. IEEE 802.11 Specific CAPWAP Control Messages 636 This section defines CAPWAP Control Messages that are specific to the 637 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 638 Configuration Request and IEEE 802.11 WLAN Configuration Response. 639 See Section 4.4 in [1] for CAPWAP Control message definitions and the 640 derivation of the Message Type value from the IANA Enterprise number. 642 The valid message types for IEEE 802.11 specific control messages are 643 listed below. The IANA Enterprise number used with these messages is 644 13277. 646 CAPWAP Control Message Message Type 647 Value 649 IEEE 802.11 WLAN Configuration Request 3398912 650 IEEE 802.11 WLAN Configuration Response 3398913 652 3.1. IEEE 802.11 WLAN Configuration Request 654 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 655 WTP in order to change services provided by the WTP. This control 656 message is used to either create, update or delete a WLAN on the WTP. 658 The IEEE 802.11 WLAN Configuration Request is sent as a result of 659 either some manual admistrative process (e.g., deleting a WLAN), or 660 automatically to create a WLAN on a WTP. When sent automatically to 661 create a WLAN, this control message is sent after the CAPWAP 662 Configuration Update Request message (see Section 8.5 in [1]) has 663 been received by the WTP. 665 Upon receiving this control message, the WTP will modify the 666 necessary services, and transmit an IEEE 802.11 WLAN Configuration 667 Response. 669 A WTP MAY provide service for more than one WLAN, therefore every 670 WLAN is identified through a numerical index. For instance, a WTP 671 that is capable of supporting up to 16 SSIDs, could accept up to 16 672 IEEE 802.11 WLAN Configuration Request messages that include the Add 673 WLAN message element. 675 Since the index is the primary identifier for a WLAN, an AC MAY 676 attempt to ensure that the same WLAN is identified through the same 677 index number on all of its WTPs. An AC that does not follow this 678 approach MUST find some other means of maintaining a WLAN-Identifier- 679 to-SSID mapping table. 681 The following message elements may be included in the IEEE 802.11 682 WLAN Configuration Request message. Only one message element MUST be 683 present. 685 o IEEE 802.11 Add WLAN, see Section 6.1 687 o IEEE 802.11 Delete WLAN, see Section 6.4 689 o IEEE 802.11 Update WLAN, see Section 6.21 691 The following message element MAY be present. 693 o IEEE 802.11 Information Element, see Section 6.6 695 3.2. IEEE 802.11 WLAN Configuration Response 697 The IEEE 802.11 WLAN Configuration Response message is sent by the 698 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 699 WLAN Configuration Request message, and to indicate that the 700 requested configuration was successfully applied, or that an error 701 related to the processing of the IEEE 802.11 WLAN Configuration 702 Request message occurred on the WTP. 704 The following message element MAY be included in the IEEE 802.11 WLAN 705 Configuration Response message. 707 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 709 The following message element MUST be included in the IEEE 802.11 710 WLAN Configuration Response message. 712 o Result Code, see Section 4.5.31 in [1] 714 4. CAPWAP Data Message Bindings 716 This section describes the CAPWAP Data Message bindings to support 717 transport of IEEE 802.11 frames. 719 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 720 message, which is used to encapsulate a wireless payload. For 721 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 722 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 723 checksum is handled by the WTP. This allows the WTP to validate 724 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 725 when an AC wishes to transmit a frame to a station, the WTP 726 computes and adds the FCS checksum. 728 Optional Wireless Specific Information: The optional CAPWAP header 729 field (see Section 4.2 in [1]) is only used with CAPWAP data 730 messages, and it serves two purposes, depending upon the direction 731 of the message. For messages from the WTP to the AC, the field 732 uses the format described in the "IEEE 802.11 Frame Info" field 733 (see below). However, for messages sent by the AC to the WTP, the 734 format used is described in the "Destination WLANs" field (also 735 defined below). 737 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 738 station over the air, it is encapsulated and this field is used to 739 include radio and PHY specific information associated with the 740 frame. 742 The IEEE 802.11 Frame Info field has the following format: 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | RSSI | SNR | Data Rate | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 RSSI: RSSI is a signed, 8-bit value. It is the received signal 751 strength indication, in dBm. 753 SNR: SNR is a signed, 8-bit value. It is the signal to noise 754 ratio of the received IEEE 802.11 frame, in dB. 756 Data Rate: The data rate field is a 16 bit unsigned value. The 757 contents of the field is set to 10 times the data rate in Mbps 758 of the packet received by the WTP. For instance, a packet 759 received at 5.5Mbps would be set to 55, while 11Mbps would be 760 set to 110. 762 Destination WLANs The Destination WLANs field is used to specify the 763 target WLANs for a given frame, and is only used with broadcast 764 and multicast frames. This field allows the AC to transmit a 765 single broadcast or multicast frame to the WTP, and allows the WTP 766 to perform the necessary frame replication. The field uses the 767 following format: 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | WLAN ID bitmap | Reserved | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 WLAN ID bitmap: This bit field indicates the WLAN ID (see 776 Section 6.1) on which the WTP will transmit the included frame. 777 For instance, if a multicast packet is to be transmitted on 778 WLANs 1 and 3, bits 1 and 3 of this field would be enabled. 779 This field is to be set to zero for unicast packets and is 780 unused if the WTP is not providing IEEE 802.11 encryption. 782 Reserved: All implementations complying with this protocol MUST 783 set to zero any bits that are reserved in the version of the 784 protocol supported by that implementation. Receivers MUST 785 ignore all bits not defined for the version of the protocol 786 they support. 788 5. CAPWAP Control Message bindings 790 This section describes the IEEE 802.11 specific message elements 791 included in CAPWAP Control Messages. 793 5.1. Discovery Request Message 795 The following IEEE 802.11 specific message element MUST be included 796 in the CAPWAP Discovery Request Message. 798 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 799 802.11 WTP Radio Information message element MUST be present for 800 every radio in the WTP. 802 5.2. Discovery Response Message 804 The following IEEE 802.11 specific message element MUST be included 805 in the CAPWAP Discovery Response Message. 807 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 808 802.11 WTP Radio Information message element MUST be present for 809 every radio in the WTP. 811 5.3. Primary Discovery Request Message 813 The following IEEE 802.11 specific message element MUST be included 814 in the CAPWAP Primary Discovery Request Message. 816 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 817 802.11 WTP Radio Information message element MUST be present for 818 every radio in the WTP. 820 5.4. Primary Discovery Response Message 822 The following IEEE 802.11 specific message element MUST be included 823 in the CAPWAP Primary Discovery Response Message. 825 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 826 802.11 WTP Radio Information message element MUST be present for 827 every radio in the WTP. 829 5.5. Join Request Message 831 The following IEEE 802.11 specific message element MUST be included 832 in the CAPWAP Join Request Message. 834 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 835 802.11 WTP Radio Information message element MUST be present for 836 every radio in the WTP. 838 5.6. Join Response Message 840 The following IEEE 802.11 specific message element MUST be included 841 in the CAPWAP Join Response Message. 843 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 844 802.11 WTP Radio Information message element MUST be present for 845 every radio in the WTP. 847 5.7. Configuration Status Message 849 The following IEEE 802.11 specific message elements may be included 850 in the CAPWAP Configuration Status Message. More than one of each 851 message element listed may be included. 853 o IEEE 802.11 Antenna, see Section 6.2 855 o IEEE 802.11 Direct Sequence Control, see Section 6.5 857 o IEEE 802.11 MAC Operation, see Section 6.7 859 o IEEE 802.11 Multi Domain Capability, see Section 6.9 861 o IEEE 802.11 OFDM Control, see Section 6.10 863 o IEEE 802.11 Supported Rates, see Section 6.17 865 o IEEE 802.11 Tx Power, see Section 6.18 867 o IEEE 802.11 TX Power Level, see Section 6.19 869 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 871 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 872 802.11 WTP Radio Information message element MUST be present for 873 every radio in the WTP. 875 5.8. Configuration Status Response Message 877 The following IEEE 802.11 specific message elements may be included 878 in the CAPWAP Configuration Status Response Message. More than one 879 of each message element listed may be included. 881 o IEEE 802.11 Antenna, see Section 6.2 882 o IEEE 802.11 Direct Sequence Control, see Section 6.5 884 o IEEE 802.11 MAC Operation, see Section 6.7 886 o IEEE 802.11 Multi Domain Capability, see Section 6.9 888 o IEEE 802.11 OFDM Control, see Section 6.10 890 o IEEE 802.11 Rate Set, see Section 6.11 892 o IEEE 802.11 Supported Rates, see Section 6.17 894 o IEEE 802.11 Tx Power, see Section 6.18 896 o IEEE 802.11 WTP Quality of Service, see Section 6.22 898 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 900 5.9. Configuration Update Request Message 902 The following IEEE 802.11 specific message elements may be included 903 in the CAPWAP Configuration Update Request Message. More than one of 904 each message element listed may be included. 906 o IEEE 802.11 Antenna, see Section 6.2 908 o IEEE 802.11 Direct Sequence Control, see Section 6.5 910 o IEEE 802.11 MAC Operation, see Section 6.7 912 o IEEE 802.11 Multi Domain Capability, see Section 6.9 914 o IEEE 802.11 OFDM Control, see Section 6.10 916 o IEEE 802.11 Rate Set, see Section 6.11 918 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 920 o IEEE 802.11 Tx Power, see Section 6.18 922 o IEEE 802.11 WTP Quality of Service, see Section 6.22 924 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 926 5.10. Station Configuration Request 928 The following IEEE 802.11 specific message elements MAY included in 929 the CAPWAP Station Configuration Request message. More than one of 930 each message element listed may be included. 932 o IEEE 802.11 Station, see Section 6.13 934 o IEEE 802.11 Station Session Key, see Section 6.15 936 o Station QoS Profile, see Section 6.14 938 5.11. Change State Event Request 940 The following IEEE 802.11 specific message elements MAY included in 941 the CAPWAP Station Configuration Request message. 943 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 945 5.12. WTP Event Request 947 The following IEEE 802.11 specific message elements MAY be included 948 in the CAPWAP WTP Event Request message.More than one of each message 949 element listed may be included. 951 o IEEE 802.11 MIC Countermeasures, see Section 6.8 953 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 955 o IEEE 802.11 Statistics, see Section 6.16 957 6. IEEE 802.11 Message Element Definitions 959 The following IEEE 802.11 specific message elements are defined in 960 this section. 962 IEEE 802.11 Message Element Type Value 964 IEEE 802.11 Add WLAN 1024 965 IEEE 802.11 Antenna 1025 966 IEEE 802.11 Assigned WTP BSSID 1026 967 IEEE 802.11 Delete WLAN 1027 968 IEEE 802.11 Direct Sequence Control 1028 969 IEEE 802.11 Information Element 1029 970 IEEE 802.11 MAC Operation 1030 971 IEEE 802.11 MIC Countermeasures 1031 972 IEEE 802.11 Multi-Domain Capability 1032 973 IEEE 802.11 OFDM Control 1033 974 IEEE 802.11 Rate Set 1034 975 IEEE 802.11 RSNA Error Report From Station 1035 976 IEEE 802.11 Station 1036 977 IEEE 802.11 Station QoS Profile 1037 978 IEEE 802.11 Station Session Key 1038 979 IEEE 802.11 Statistics 1039 980 IEEE 802.11 Supported Rates 1040 981 IEEE 802.11 Tx Power 1041 982 IEEE 802.11 Tx Power Level 1042 983 IEEE 802.11 Update Station QoS 1043 984 IEEE 802.11 Update WLAN 1044 985 IEEE 802.11 WTP Quality of Service 1045 986 IEEE 802.11 WTP Radio Configuration 1046 987 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 988 IEEE 802.11 WTP Radio Information 1048 990 6.1. IEEE 802.11 Add WLAN 992 The IEEE 802.11 Add WLAN message element is used by the AC to define 993 a WLAN on the WTP. The inclusion of this message element MUST also 994 include IEEE 802.11 Information Element message elements, containing 995 the following IEEE 802.11 IEs: 997 Power Capability information element 998 WPA information element 1000 RSN information element 1002 EDCA Parameter Set information element 1004 QoS Capability information element 1006 WMM information element 1008 If present, the RSN information element is sent with the IEEE 802.11 1009 Add WLAN message element to instruct the WTP on the usage of the Key 1010 field. 1012 An AC MAY include additional information elements as desired. The 1013 message element uses the following format: 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Radio ID | WLAN ID | Capabilities | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Key Index | Key Status | Key Length | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Key... | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Group TSC | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Group TSC | QoS | Auth Type | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 Type: 1024 for IEEE 802.11 Add WLAN 1033 Length: >= 49 1035 Radio ID: An 8-bit value representing the radio. 1037 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1039 Capability: A 16-bit value containing the capabilities information 1040 field to be advertised by the WTP in the Probe Request and Beacon 1041 frames. 1043 Key-Index: The Key Index associated with the key. 1045 Key Status: A 1 byte value that specifies the state and usage of 1046 the key that has been included. The following values describe the 1047 key usage and its status: 1049 0 - A value of zero, with the inclusion of the RSN Information 1050 Element means that the WLAN uses per-station encryption keys, and 1051 therefore the key in the 'Key' field is only used for multicast 1052 traffic. 1054 1 - When set to one, the WLAN employs a shared WEP key, also known 1055 as a static WEP key, and uses the encryption key for both unicast 1056 and multicast traffic for all stations. 1058 2 - The value of 2 indicates that the AC will begin rekeying the GTK 1059 with the STA's in the BSS. It is only valid when IEEE 802.11 is 1060 enabled as the security policy for the BSS. 1062 3 - The value of 3 indicates that the AC has completed rekeying the 1063 GTK and broadcast packets no longer need to be duplicated and 1064 transmitted with both GTK's. 1066 Key Length: A 16-bit value representing the length of the Key 1067 field. 1069 Key: A 32 byte Session Key to use to provide data privacy. For 1070 encryption schemes that employ a separate encryption key for 1071 unicast and multicast traffic, the key included here only applies 1072 to multicast frames, and the cipher suite is specified in an 1073 accompanied RSN Information Element. In these scenarios, the key 1074 and cipher information is communicated via the Add Station message 1075 element, see Section 4.5.8 in [1] and the IEEE 802.11 Station 1076 Session Key message element, see Section 6.15. 1078 Group TSC A 48-bit value containing the Transmit Sequence Counter 1079 for the updated group key. The WTP will set the TSC for 1080 broadcast/multicast frames to this value for the updated group 1081 key. 1083 QOS: An 8-bit value specifying the default QOS policy for the WTP 1084 to apply to network traffic received for a non-WMM enabled STA. 1086 The following values are supported: 1088 0 - Best Effort 1090 1 - Video 1092 2 - Voice 1094 3 - Background 1096 Auth Type: An 8-bit value specifying the supported authentication 1097 type. 1099 The following values are supported: 1101 0 - Open System 1103 1 - WEP Shared Key 1105 MAC Mode: This field specifies whether the WTP should support the 1106 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1107 request a mode of operation that was not advertised by the WTP 1108 during the discovery process (see Section 4.4.42 in [1]). The 1109 following values are supported: 1111 0 - Local-MAC: Service for the WLAN is to be provided in Local 1112 MAC mode. 1114 1 - Split-MAC: Service for the WLAN is to be provided in Split 1115 MAC mode. 1117 Tunnel Mode: This field specifies the frame tunneling type to be 1118 used for 802.11 data frames from all stations associated with the 1119 WLAN. The AC MUST NOT request a mode of operation that was not 1120 advertised by the WTP during the discovery process (see Section 1121 4.4.40 in [1]). IEEE 802.11 managment frames SHALL be tunneled 1122 using 802.11 Tunnel mode. The following values are supported: 1124 0 - Local Bridging: All user traffic is to be locally bridged. 1126 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1127 in 802.3 format (see Section 4.2 in [1]). 1129 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1130 in 802.11 format. 1132 Supress SSID: A boolean indicating whether the SSID is to be 1133 advertised by the WTP. A value of zero supresses the SSID in the 1134 802.11 Beacon and Probe Response frames, while a value of one will 1135 cause the WTP to populate the field. 1137 SSID: The SSID attribute is the service set identifier that will be 1138 advertised by the WTP for this WLAN. 1140 6.2. IEEE 802.11 Antenna 1142 The IEEE 802.11 Antenna message element is communicated by the WTP to 1143 the AC to provide information on the antennas available. The AC MAY 1144 use this element to reconfigure the WTP's antennas. The message 1145 element contains the following fields: 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Radio ID | Diversity | Combiner | Antenna Cnt | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Antenna Selection [0..N] | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 Type: 1025 for IEEE 802.11 Antenna 1157 Length: >= 5 1159 Radio ID: An 8-bit value representing the radio to configure. 1161 Diversity: An 8-bit value specifying whether the antenna is to 1162 provide receive diversity. The value of this field is the same as 1163 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [3]. 1164 The following values are supported: 1166 0 - Disabled 1168 1 - Enabled (may only be true if the antenna can be used as a 1169 receive antenna) 1171 Combiner: An 8-bit value specifying the combiner selection. The 1172 following values are supported: 1174 1 - Sectorized (Left) 1176 2 - Sectorized (Right) 1177 3 - Omni 1179 4 - MIMO 1181 Antenna Count: An 8-bit value specifying the number of Antenna 1182 Selection fields. This value should be the same as the one found 1183 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [3]). 1185 Antenna Selection: One 8-bit antenna configuration value per 1186 antenna in the WTP. The following values are supported: 1188 1 - Internal Antenna 1190 2 - External Antenna 1192 6.3. IEEE 802.11 Assigned WTP BSSID 1194 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1195 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1196 Add WLAN message element. The BSSID value field of this message 1197 element contains the BSSID that has been assigned by the WTP, 1198 enabling the WTP to perform its own BSSID assignment. 1200 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1201 highly recommended that the WTP assign the BSSID using the following 1202 algorithm: BSSID = {base BSSID} + WLAN ID. 1204 0 1 2 3 1205 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 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Radio ID | WLAN ID | BSSID 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | BSSID | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1214 Length: 6 1216 Radio ID: An 8-bit value representing the radio. 1218 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1220 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1221 result of receiving an IEEE 802.11 Add WLAN. 1223 6.4. IEEE 802.11 Delete WLAN 1225 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1226 that a previously created WLAN is to be deleted, and contains the 1227 following fields: 1229 0 1 1230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Radio ID | WLAN ID | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 Type: 1027 for IEEE 802.11 Delete WLAN 1237 Length: 3 1239 Radio ID: An 8-bit value representing the radio 1241 WLAN ID: An 8-bit value specifying the WLAN Identifier 1243 6.5. IEEE 802.11 Direct Sequence Control 1245 The IEEE 802.11 Direct Sequence Control message element is a bi- 1246 directional element. When sent by the WTP, it contains the current 1247 state. When sent by the AC, the WTP MUST adhere to the values 1248 provided. This element is only used for IEEE 802.11b radios. The 1249 message element has the following fields. 1251 0 1 2 3 1252 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 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Radio ID | Reserved | Current Chan | Current CCA | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Energy Detect Threshold | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Type: 1028 for IEEE 802.11 Direct Sequence Control 1261 Length: 8 1263 Radio ID: An 8-bit value representing the radio to configure. 1265 Reserved: All implementations complying with this protocol MUST set 1266 to zero any bits that are reserved in the version of the protocol 1267 supported by that implementation. Receivers MUST ignore all bits 1268 not defined for the version of the protocol they support. 1270 Current Channel: This attribute contains the current operating 1271 frequency channel of the DSSS PHY. This value comes from the IEEE 1272 802.11 dot11CurrentChannel MIB element (see [3]). 1274 Current CCA: The current CCA method in operation, whose value can 1275 be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see 1276 [3]). Valid values are: 1278 1 - energy detect only (edonly) 1280 2 - carrier sense only (csonly) 1282 4 - carrier sense and energy detect (edandcs) 1284 8 - carrier sense with timer (cswithtimer) 1286 16 - high rate carrier sense and energy detect (hrcsanded) 1288 Energy Detect Threshold: The current Energy Detect Threshold being 1289 used by the DSSS PHY. The value can be found in the IEEE 802.11 1290 dot11EDThreshold MIB element (see [3]). 1292 6.6. IEEE 802.11 Information Element 1294 The IEEE 802.11 Information Element is used to communicate any IE 1295 defined in the IEEE 802.11 protocol. The data field contains the raw 1296 IE as it would be included within an IEEE 802.11 MAC management 1297 message. 1299 0 1 2 3 1300 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 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Radio ID | WLAN ID |B|P| Flags |Info Element... 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 Type: 1029 for IEEE 802.11 Information Element 1307 Length: >= 2 1309 Radio ID: An 8-bit value representing the radio. 1311 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1313 B: When set, the WTP is to include the information element in 1314 beacons associated with the WLAN. 1316 P: When set, the WTP is to include the information element in probe 1317 responses associated with the WLAN. 1319 Flags: All implementations complying with this protocol MUST set to 1320 zero any bits that are reserved in the version of the protocol 1321 supported by that implementation. Receivers MUST ignore all bits 1322 not defined for the version of the protocol they support. 1324 Info Element: The IEEE 802.11 Information Element, which includes 1325 the type, length and value field. 1327 6.7. IEEE 802.11 MAC Operation 1329 The IEEE 802.11 MAC Operation message element is sent by the AC to 1330 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1331 following fields. 1333 0 1 2 3 1334 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 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Radio ID | Reserved | RTS Threshold | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Short Retry | Long Retry | Fragmentation Threshold | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Tx MSDU Lifetime | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Rx MSDU Lifetime | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 Type: 1030 for IEEE 802.11 MAC Operation 1347 Length: 16 1349 Radio ID: An 8-bit value representing the radio to configure. 1351 Reserved: All implementations complying with this protocol MUST set 1352 to zero any bits that are reserved in the version of the protocol 1353 supported by that implementation. Receivers MUST ignore all bits 1354 not defined for the version of the protocol they support. 1356 RTS Threshold: This attribute indicates the number of octets in an 1357 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 1358 RTS/CTS handshake MUST be performed at the beginning of any frame 1359 exchange sequence where the MPDU is of type Data or Management, 1360 the MPDU has an individual address in the Address1 field, and the 1361 length of the MPDU is greater than this threshold. Setting this 1362 attribute to be larger than the maximum MSDU size MUST have the 1363 effect of turning off the RTS/CTS handshake for frames of Data or 1364 Management type transmitted by this STA. Setting this attribute 1365 to zero MUST have the effect of turning on the RTS/CTS handshake 1366 for all frames of Data or Management type transmitted by this STA. 1367 The default value of this attribute MUST be 2347. The value of 1368 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1369 element, (see [3]). 1371 Short Retry: This attribute indicates the maximum number of 1372 transmission attempts of a frame, the length of which is less than 1373 or equal to RTSThreshold, that MUST be made before a failure 1374 condition is indicated. The default value of this attribute MUST 1375 be 7. The value of this field comes from the IEEE 802.11 1376 dot11ShortRetryLimit MIB element, (see [3]). 1378 Long Retry: This attribute indicates the maximum number of 1379 transmission attempts of a frame, the length of which is greater 1380 than dot11RTSThreshold, that MUST be made before a failure 1381 condition is indicated. The default value of this attribute MUST 1382 be 4. The value of this field comes from the IEEE 802.11 1383 dot11LongRetryLimit MIB element, (see [3]). 1385 Fragmentation Threshold: This attribute specifies the current 1386 maximum size, in octets, of the MPDU that MAY be delivered to the 1387 PHY. An MSDU MUST be broken into fragments if its size exceeds 1388 the value of this attribute after adding MAC headers and trailers. 1389 An MSDU or MMPDU MUST be fragmented when the resulting frame has 1390 an individual address in the Address1 field, and the length of the 1391 frame is larger than this threshold. The default value for this 1392 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1393 attached PHY and MUST never exceed the lesser of 2346 or the 1394 aMPDUMaxLength of the attached PHY. The value of this attribute 1395 MUST never be less than 256. The value of this field comes from 1396 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1397 [3]). 1399 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 1400 after the initial transmission of an MSDU, after which further 1401 attempts to transmit the MSDU MUST be terminated. The default 1402 value of this attribute MUST be 512. The value of this field 1403 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1404 element, (see [3]). 1406 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1407 after the initial reception of a fragmented MMPDU or MSDU, after 1408 which further attempts to reassemble the MMPDU or MSDU MUST be 1409 terminated. The default value MUST be 512. The value of this 1410 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1411 element, (see [3]). 1413 6.8. IEEE 802.11 MIC Countermeasures 1415 The IEEE 802.11 MIC Countermeasures message element is sent by the 1416 WTP to the AC to indicate the occurrence of a MIC failure. For more 1417 information on MIC failure events, see the 1418 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in [3]. 1420 0 1 2 3 1421 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 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Radio ID | WLAN ID | MAC Address | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | MAC Address | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 Type: 1031 for IEEE 802.11 MIC Countermeasures 1430 Length: 8 1432 Radio ID: The Radio Identifier, typically refers to some interface 1433 index on the WTP. 1435 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1436 on which the MIC failure occurred. 1438 MAC Address: The MAC Address of the station that caused the MIC 1439 failure. 1441 6.9. IEEE 802.11 Multi-Domain Capability 1443 The IEEE 802.11 Multi-Domain Capability message element is used by 1444 the AC to inform the WTP of regulatory limits. The AC will transmit 1445 one message element per frequency band to indicate the regulatory 1446 constraints in that domain. The message element contains the 1447 following fields. 1449 0 1 2 3 1450 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 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | Radio ID | Reserved | First Channel # | 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Number of Channels | Max Tx Power Level | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1459 Length: 8 1461 Radio ID: An 8-bit value representing the radio to configure. 1463 Reserved: All implementations complying with this protocol MUST set 1464 to zero any bits that are reserved in the version of the protocol 1465 supported by that implementation. Receivers MUST ignore all bits 1466 not defined for the version of the protocol they support. 1468 First Channnel #: This attribute indicates the value of the lowest 1469 channel number in the subband for the associated domain country 1470 string. The value of this field comes from the IEEE 802.11 1471 dot11FirstChannelNumber MIB element (see [3]). 1473 Number of Channels: This attribute indicates the value of the total 1474 number of channels allowed in the subband for the associated 1475 domain country string. The value of this field comes from the 1476 IEEE 802.11 dot11NumberofChannels MIB element (see [3]). 1478 Max Tx Power Level: This attribute indicates the maximum transmit 1479 power, in dBm, allowed in the subband for the associated domain 1480 country string. The value of this field comes from the IEEE 1481 802.11 dot11MaximumTransmitPowerLevel MIB element (see [3]). 1483 6.10. IEEE 802.11 OFDM Control 1485 The IEEE 802.11 OFDM Control message element is a bi-directional 1486 element. When sent by the WTP, it contains the current state. When 1487 sent by the AC, the WTP MUST adhere to the received values. This 1488 message element is only used for 802.11a radios and contains the 1489 following fields: 1491 0 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Radio ID | Reserved | Current Chan | Band Support | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | TI Threshold | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 Type: 1033 for IEEE 802.11 OFDM Control 1501 Length: 8 1502 Radio ID: An 8-bit value representing the radio to configure. 1504 Reserved: All implementations complying with this protocol MUST set 1505 to zero any bits that are reserved in the version of the protocol 1506 supported by that implementation. Receivers MUST ignore all bits 1507 not defined for the version of the protocol they support. 1509 Current Channel: This attribute contains the current operating 1510 frequency channel of the OFDM PHY. The value of this field comes 1511 from the IEEE 802.11 dot11CurrentFrequency MIB element (see [3]). 1513 Band Supported: The capability of the OFDM PHY implementation to 1514 operate in the three U-NII bands. The value of this field comes 1515 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1516 [3]), coded as an integer value of a three bit field as follows: 1518 Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII 1519 band 1521 Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII 1522 band 1524 Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII 1525 band 1527 For example, for an implementation capable of operating in the 1528 lower and mid bands this attribute would take the value 3. 1530 TI Threshold: The Threshold being used to detect a busy medium 1531 (frequency). CCA MUST report a busy medium upon detecting the 1532 RSSI above this threshold. The value of this field comes from the 1533 IEEE 802.11 dot11TIThreshold MIB element (see [3]). 1535 6.11. IEEE 802.11 Rate Set 1537 The rate set message element value is sent by the AC and contains the 1538 supported operational rates. It contains the following fields. 1540 0 1 2 3 1541 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 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Radio ID | Rate Set... 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 Type: 1034 for IEEE 802.11 Rate Set 1548 Length: >= 3 1550 Radio ID: An 8-bit value representing the radio to configure. 1552 Rate Set: The AC generates the Rate Set that the WTP is to include 1553 in it's Beacon and Probe messages. The length of this field is 1554 between 2 and 8 bytes. The value of this field comes from the 1555 IEEE 802.11 dot11OperationalRateSet MIB element (see [3]). 1557 6.12. IEEE 802.11 RSNA Error Report From Station 1559 The IEEE 802.11 RSN Error Report From Station message element is used 1560 by a WTP to send RSN error reports to the AC. The WTP does not need 1561 to transmit any reports that do not include any failures. The fields 1562 from this message element come from the IEEE 802.11 1563 Dot11RSNAStatsEntry table, see [3]. 1565 0 1 2 3 1566 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 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Client MAC Address | 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Client MAC Address | BSSID | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | BSSID | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Radio ID | WLAN ID | Reserved | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | TKIP ICV Errors | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | TKIP Local MIC Failures | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | TKIP Remote MIC Failures | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | CCMP Replays | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | CCMP Decrypt Errors | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | TKIP Replays | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 1591 Length: 14 1593 Client MAC Address: The Client MAC Address of the station. 1595 BSSID: The BSSID on which the failures are being reported on. 1597 Radio ID: The Radio Identifier, typically refers to some interface 1598 index on the WTP 1600 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 1602 Reserved: All implementations complying with this protocol MUST set 1603 to zero any bits that are reserved in the version of the protocol 1604 supported by that implementation. Receivers MUST ignore all bits 1605 not defined for the version of the protocol they support. 1607 TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV 1608 errors encountered when decrypting packets from the station. The 1609 value of this field comes from the IEEE 802.11 1610 dot11RSNAStatsTKIPICVErrors MIB element (see [3]). 1612 TKIP Local MIC Failures: A 32-bit value representing the number of 1613 MIC failures encountered when checking the integrity of packets 1614 received from the station. The value of this field comes from the 1615 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 1616 [3]). 1618 TKIP Remote MIC Failures: A 32-bit value representing the number of 1619 MIC failures reported by the station encountered (possibly via the 1620 EAPOL-Key frame). The value of this field comes from the IEEE 1621 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [3]). 1623 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 1624 discarded by the replay detection mechanism. The value of this 1625 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 1626 (see [3]). 1628 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 1629 MDPUs discarded by the decryption algorithm. The value of this 1630 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 1631 element (see [3]). 1633 TKIP Replays: A 32-bit value representing the number of TKIP 1634 Replays detected in frames received from the station. The value 1635 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 1636 MIB element (see [3]). 1638 6.13. IEEE 802.11 Station 1640 The IEEE 802.11 Station message element accompanies the Add Station 1641 message element, and is used to deliver IEEE 802.11 station policy 1642 from the AC to the WTP. 1644 The latest IEEE 802.11 Station message element overrides any 1645 previously received message elements. 1647 If the QoS field is set, the WTP MUST observe and provide policing of 1648 the 802.11e priority tag to ensure that it does not exceed the value 1649 provided by the AC. 1651 0 1 2 3 1652 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 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Radio ID | Association ID | Flags | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | MAC Address | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | MAC Address | Capabilities | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | WLAN ID |Supported Rates| 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 Type: 1036 for IEEE 802.11 Station 1665 Length: >= 8 1667 Radio ID: An 8-bit value representing the radio 1669 Association ID: A 16-bit value specifying the IEEE 802.11 1670 Association Identifier 1672 Flags: All implementations complying with this protocol MUST set to 1673 zero any bits that are reserved in the version of the protocol 1674 supported by that implementation. Receivers MUST ignore all bits 1675 not defined for the version of the protocol they support. 1677 MAC Address: The station's MAC Address 1679 Capabilities: A 16-bit field containing the IEEE 802.11 1680 Capabilities Information Field to use with the station. 1682 WLAN ID: An 8-bit value specifying the WLAN Identifier 1683 Supported Rates: The variable length field containing the supported 1684 rates to be used with the station, as found in the IEEE 802.11 1685 dot11OperationalRateSet MIB element (see [3]). 1687 6.14. IEEE 802.11 Station QoS Profile 1689 The IEEE 802.11 Station QoS Profile message element contains the 1690 maximum IEEE 802.11e priority tag that may be used by the station. 1691 Any packet received that exceeds the value encoded in this message 1692 element must either be dropped or tagged using the maximum value 1693 permitted by to the user. The priority tag must be between zero (0) 1694 and seven (7). This message element MUST NOT be present without the 1695 IEEE 802.11 Station (see Section 6.13) message element 1697 0 1 2 3 1698 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 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | MAC Address | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | MAC Address | 802.1P Precedence Tag | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 Type: 1037 for IEEE 802.11 Station QOS Profile 1707 Length: 8 1709 MAC Address: The station's MAC Address 1711 802.1P Precedence Tag: The maximum 802.1P precedence value that the 1712 WTP will allow in the TID field in the extended 802.11e QOS Data 1713 header. 1715 6.15. IEEE 802.11 Station Session Key 1717 The IEEE 802.11 Station Session Key message element is sent when the 1718 AC determines that encryption of a station must be performed in the 1719 WTP. This message element MUST NOT be present without the IEEE 1720 802.11 Station (see Section 6.13) message element, and MUST NOT be 1721 sent if the WTP had not specifically advertised support for the 1722 requested encryption scheme. 1724 The RSN information element MUST sent along with the IEEE 802.11 1725 Station Session Key in order to instruct the WTP on the usage of the 1726 Key field. The AKM field of the RSM information element is used by 1727 the WTP to identify the authentication protocol. 1729 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 1730 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 1731 of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an 1732 encryption key is in force, requiring that the AKM packets be 1733 encrypted. Once the station has successfully completed 1734 authentication via the AKM, the AC must send a new Add Station 1735 message element to remove the AKM-Only restriction, and optionally 1736 push the session key down to the WTP. 1738 0 1 2 3 1739 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 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 | MAC Address | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | MAC Address |A|C| Flags | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | Pairwise TSC | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | Pairwise TSC | Pairwise RSC | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Pairwise RSC | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Key... 1752 +-+-+-+-+-+-+-+- 1754 Type: 1038 for IEEE 802.11 Station Session Key 1756 Length: >= 25 1758 MAC Address: The station's MAC Address 1760 Flags: All implementations complying with this protocol MUST set to 1761 zero any bits that are reserved in the version of the protocol 1762 supported by that implementation. Receivers MUST ignore all bits 1763 not defined for the version of the protocol they support. The 1764 following bits are defined: 1766 A: The one bit AKM-Only field is set by the AC to inform the WTP 1767 that is MUST NOT accept any 802.11 data frames, other than AKM 1768 frames. This is the equivalent of the WTP's IEEE 802.1X port 1769 for the station to be in the closed state. When set, the WTP 1770 MUST drop any non-IEEE 802.1X packets it receives from the 1771 station. 1773 C: The one bit field is set by the AC to inform the WTP that 1774 encryption services will be provided by the AC. When set, the 1775 WTP SHOULD police frames received from stations to ensure that 1776 are properly encrypted as specified in the RSN Information 1777 Element, but does not need to take specific cryptographic 1778 action on the frame. Similarly, for transmitted frames, the 1779 WTP only needs to forward already encrypted frames. 1781 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 1782 use for unicast packets transmitted to the station. 1784 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 1785 unicast packets received from the station. 1787 Key: The key the WTP is to use when encrypting traffic to/from the 1788 station. For dynamically created keys, this is commonly known as 1789 a Pairwise Transient Key (PTK). 1791 6.16. IEEE 802.11 Statistics 1793 The IEEE 802.11 Statistics message element is sent by the WTP to 1794 transmit its current statistics, and contains the following fields. 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Radio ID | Reserved | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Tx Fragment Count | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Multicast Tx Count | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Failed Count | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Retry Count | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Multiple Retry Count | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Frame Duplicate Count | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 | RTS Success Count | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | RTS Failure Count | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | ACK Failure Count | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Rx Fragment Count | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | Multicast RX Count | 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | FCS Error Count | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Tx Frame Count | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Decryption Errors | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Discarded QoS Fragment Count | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Associated Station Count | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | QoS CF Polls Received Count | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | QoS CF Polls Unused Count | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | QoS CF Polls Unusable Count | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Type: 1039 for IEEE 802.11 Statistics 1842 Length: 60 1844 Radio ID: An 8-bit value representing the radio. 1846 Reserved: All implementations complying with this protocol MUST set 1847 to zero any bits that are reserved in the version of the protocol 1848 supported by that implementation. Receivers MUST ignore all bits 1849 not defined for the version of the protocol they support. 1851 Tx Fragment Count: A 32-bit value representing the number of 1852 fragmented frames transmitted. The value of this field comes from 1853 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 1854 [3]). 1856 Multicast Tx Count: A 32-bit value representing the number of 1857 multicast frames transmitted. The value of this field comes from 1858 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 1859 (see [3]). 1861 Failed Count: A 32-bit value representing the transmit excessive 1862 retries. The value of this field comes from the IEEE 802.11 1863 dot11FailedCount MIB element (see [3]). 1865 Retry Count: A 32-bit value representing the number of transmit 1866 retries. The value of this field comes from the IEEE 802.11 1867 dot11RetryCount MIB element (see [3]). 1869 Multiple Retry Count: A 32-bit value representing the number of 1870 transmits that required more than one retry. The value of this 1871 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 1872 element (see [3]). 1874 Frame Duplicate Count: A 32-bit value representing the duplicate 1875 frames received. The value of this field comes from the IEEE 1876 802.11 dot11FrameDuplicateCount MIB element (see [3]). 1878 RTS Success Count: A 32-bit value representing the number of 1879 successfully transmitted Ready To Send (RTS). The value of this 1880 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 1881 (see [3]). 1883 RTS Failure Count: A 32-bit value representing the failed 1884 transmitted RTS. The value of this field comes from the IEEE 1885 802.11 dot11RTSFailureCount MIB element (see [3]). 1887 ACK Failure Count: A 32-bit value representing the number of failed 1888 acknowledgements. The value of this field comes from the IEEE 1889 802.11 dot11ACKFailureCount MIB element (see [3]). 1891 Rx Fragment Count: A 32-bit value representing the number of 1892 fragmented frames received. The value of this field comes from 1893 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [3]). 1895 Multicast RX Count: A 32-bit value representing the number of 1896 multicast frames received. The value of this field comes from the 1897 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 1898 [3]). 1900 FCS Error Count: A 32-bit value representing the number of FCS 1901 failures. The value of this field comes from the IEEE 802.11 1902 dot11FCSErrorCount MIB element (see [3]). 1904 Decryption Errors: A 32-bit value representing the number of 1905 Decryption errors that occurred on the WTP. Note that this field 1906 is only valid in cases where the WTP provides encryption/ 1907 decryption services. The value of this field comes from the IEEE 1908 802.11 dot11WEPUndecryptableCount MIB element (see [3]). 1910 Discarded QoS Fragment Count: A 32-bit value representing the 1911 number of discarded QoS fragments received. The value of this 1912 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 1913 MIB element (see [3]). 1915 Associated Station Count: A 32-bit value representing the number of 1916 number of associated stations. The value of this field comes from 1917 the IEEE 802.11 dot11AssociatedStationCount MIB element (see [3]). 1919 QoS CF Polls Received Count: A 32-bit value representing the number 1920 of (+)CF-Polls received. The value of this field comes from the 1921 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [3]). 1923 QoS CF Polls Unused Count: A 32-bit value representing the number 1924 of (+)CF-Polls that have been received, but not used. The value 1925 of this field comes from the IEEE 802.11 1926 dot11QosCFPollsUnusedCount MIB element (see [3]). 1928 QoS CF Polls Unusable Count: A 32-bit value representing the number 1929 of (+)CF-Polls that have been received, but could not be used due 1930 to the TXOP size being smaller than the timethat is required for 1931 one frame exchange sequence. The value of this field comes from 1932 the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see 1933 [3]). 1935 6.17. IEEE 802.11 Supported Rates 1937 The IEEE 802.11 Supported Rates message element is sent by the WTP to 1938 indicate the rates that it supports, and contains the following 1939 fields. 1941 0 1 2 3 1942 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 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | Radio ID | Supported Rates... 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 Type: 1040 for IEEE 802.11 Supported Rates 1949 Length: >= 3 1951 Radio ID: An 8-bit value representing the radio. 1953 Supported Rates: The WTP includes the Supported Rates that its 1954 hardware supports. The format is identical to the Rate Set 1955 message element and is between 2 and 8 bytes in length. 1957 6.18. IEEE 802.11 Tx Power 1959 The IEEE 802.11 Tx Power message element value is bi-directional. 1960 When sent by the WTP, it contains the current power level of the 1961 radio in question. When sent by the AC, it contains the power level 1962 the WTP MUST adhere to. 1964 0 1 2 3 1965 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 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Radio ID | Reserved | Current Tx Power | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 Type: 1041 for IEEE 802.11 Tx Power 1972 Length: 4 1974 Radio ID: An 8-bit value representing the radio to configure. 1976 Reserved: All implementations complying with this protocol MUST set 1977 to zero any bits that are reserved in the version of the protocol 1978 supported by that implementation. Receivers MUST ignore all bits 1979 not defined for the version of the protocol they support. 1981 Current Tx Power: This attribute contains the current transmit 1982 output power in mW, as described in the dot11CurrentTxPowerLevel 1983 MIB variable, see [3]. 1985 6.19. IEEE 802.11 Tx Power Level 1987 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 1988 contains the different power levels supported. The values found in 1989 this message element are found in the IEEE 802.11 1990 Dot11PhyTxPowerEntry MIB table, see [3]. 1992 The value field contains the following: 1994 0 1 2 3 1995 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 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | Radio ID | Num Levels | Power Level [n] | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 Type: 1042 for IEEE 802.11 Tx Power Level 2002 Length: >= 4 2004 Radio ID: An 8-bit value representing the radio to configure. 2006 Num Levels: The number of power level attributes. The value of 2007 this field comes from the IEEE 802.11 2008 dot11NumberSupportedPowerLevels MIB element (see [3]). 2010 Power Level: Each power level fields contains a supported power 2011 level, in mW. The value of this field comes from the 2012 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 2013 [3]. 2015 6.20. IEEE 802.11 Update Station QoS 2017 The IEEE 802.11 Update Station QoS message element is used to change 2018 the Quality of Service policy on the WTP for a given station. 2020 0 1 2 3 2021 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 2 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2023 | Radio ID | MAC Address | 2024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 | MAC Address | DSCP Tag | 802.1P Tag | 2026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 Type: 1043 for IEEE 802.11 Update Station QoS 2030 Length: 8 2032 Radio ID: The Radio Identifier, typically refers to some interface 2033 index on the WTP 2035 MAC Address: The station's MAC Address. 2037 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2039 802.1P Tag: The 802.1P precedence value to use if packets are to be 2040 IEEE 802.1P tagged. 2042 6.21. IEEE 802.11 Update WLAN 2044 The IEEE 802.11 Update WLAN message element is used by the AC to 2045 define a wireless LAN on the WTP. The inclusion of this message 2046 element MUST also include the IEEE 802.11 Information Element message 2047 element, containing the following 802.11 IEs: 2049 Power Capability information element 2051 WPA information element 2053 RSN information element 2055 EDCA Parameter Set information element 2057 QoS Capability information element 2059 WMM information element 2061 The message element uses the following format: 2063 0 1 2 3 2064 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 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 | Radio ID | WLAN ID | Capability | 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Key Index | Key Status | Key Length | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 | Key... | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 Type: 1044 for IEEE 802.11 Update WLAN 2075 Length: 43 2077 Radio ID: An 8-bit value representing the radio. 2079 WLAN ID: An 8-bit value specifying the WLAN Identifier. 2081 Capability: A 16-bit value containing the capabilities information 2082 field to be advertised by the WTP within the Probe and Beacon 2083 messages. 2085 Key-Index: The Key Index associated with the key. 2087 Key Status: A 1 byte value that specifies the state and usage of 2088 the key that has been included. The following values describe the 2089 key usage and its status: 2091 0 - A value of zero, with the inclusion of the RSN Information 2092 Element means that the WLAN uses per-station encryption keys, and 2093 therefore the key in the 'Key' field is only used for multicast 2094 traffic. 2096 1 - When set to one, the WLAN employs a shared WEP key, also known 2097 as a static WEP key, and uses the encryption key for both unicast 2098 and multicast traffic for all stations. 2100 2 - The value of 2 indicates that the AC will begin rekeying the GTK 2101 with the STA's in the BSS. It is only valid when IEEE 802.11 is 2102 enabled as the security policy for the BSS. 2104 3 - The value of 3 indicates that the AC has completed rekeying the 2105 GTK and broadcast packets no longer need to be duplicated and 2106 transmitted with both GTK's. 2108 Key Length: A 16-bit value representing the length of the Key 2109 field. 2111 Key: A 32 byte Session Key to use to provide data privacy. For 2112 static WEP keys, which is true when the 'Key Status' bit is set to 2113 one, this key is used for both unicast and multicast traffic. For 2114 encryption schemes that employ a separate encryption key for 2115 unicast and multicast traffic, the key included hereonly applies 2116 to multicast data, and the cipher suite is specified in an 2117 accompanied RSN Information Element. In these scenarios, the key, 2118 and cipher information, is communicated via the Add Station 2119 message element, see Section 4.5.8 in [1]. 2121 6.22. IEEE 802.11 WTP Quality of Service 2123 The IEEE 802.11 WTP Quality of Service message element value is sent 2124 by the AC to the WTP to communicate quality of service configuration 2125 information. 2127 0 1 2128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | Radio ID | Tag Packets | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 Type: 1045 for IEEE 802.11 WTP Quality of Service 2135 Length: >= 2 2137 Radio ID: The Radio Identifier, typically refers to some interface 2138 index on the WTP 2140 Tag Packets: An value indicating whether CAPWAP packets should be 2141 tagged with for QoS purposes. The following values are currently 2142 supported: 2144 0 - Untagged 2146 1 - 802.1P 2148 2 - DSCP 2150 Immediately following the above header is the following data 2151 structure. This data structure will be repeated five times; once 2152 for every QoS profile. The order of the QoS profiles are Voice, 2153 Video, Best Effort and Background. 2155 0 1 2 3 2156 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 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 | Queue Depth | CWMin | CWMax | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | CWMax | AIFS | Dot1P Tag | DSCP Tag | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 Queue Depth: The number of packets that can be on the specific QoS 2164 transmit queue at any given time. 2166 CWMin: The Contention Window minimum value for the QoS transmit 2167 queue. The value of this field comes from the IEEE 802.11 2168 dot11EDCATableCWMin MIB element (see [3]). 2170 CWMax: The Contention Window maximum value for the QoS transmit 2171 queue. The value of this field comes from the IEEE 802.11 2172 dot11EDCATableCWMax MIB element (see [3]). 2174 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 2175 transmit queue. The value of this field comes from the IEEE 2176 802.11 dot11EDCATableAIFSN MIB element (see [3]). 2178 Dot1P Tag: The 802.1P precedence value to use if packets are to be 2179 802.1P tagged. 2181 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2183 6.23. IEEE 802.11 WTP Radio Configuration 2185 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2186 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2187 its radio configuration to the AC. The message element value 2188 contains the following fields: 2190 0 1 2 3 2191 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 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | BSSID | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | BSSID | Beacon Period | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | Country Code | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2204 Length: 16 2206 Radio ID: An 8-bit value representing the radio to configure. 2208 Short Preamble: An 8-bit value indicating whether short preamble is 2209 supported. The following values are currently supported: 2211 0 - Short preamble not supported. 2213 1 - Short preamble is supported. 2215 BSSID: The WLAN Radio's base MAC Address. 2217 Number of BSSIDs: This attribute contains the maximum number of 2218 BSSIDs supported by the WTP. This value restricts the number of 2219 logical networks supported by the WTP, and is between 1 and 16. 2221 DTIM Period: This attribute specifies the number of beacon 2222 intervals that elapse between transmission of Beacons frames 2223 containing a TIM element whose DTIM Count field is 0. This value 2224 is transmitted in the DTIM Period field of Beacon frames. The 2225 value of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2226 element (see [3]). 2228 Beacon Period: This attribute specifies the number of TU that a 2229 station uses for scheduling Beacon transmissions. This value is 2230 transmitted in Beacon and Probe Response frames. The value of 2231 this field comes from the IEEE 802.11 dot11BeaconPeriod MIB 2232 element (see [3]). 2234 Country Code: This attribute identifies the country in which the 2235 station is operating. The value of this field comes from the IEEE 2236 802.11 dot11CountryString MIB element (see [3]). Special 2237 attention is required with use of this field, as implementations 2238 which take action based on this field could violate regulatory 2239 requirements. Some regulatory bodies do permit configuration of 2240 the country code under certain restrictions, such as the FCC, when 2241 WTPs are certified as Software Defined Radios. 2243 The WTP and AC may ignore the value of this field, depending upon 2244 regulatory requirements, for example to avoid classification as a 2245 Software Defined Radio. When this field is used, the first two 2246 octets of this string is the two character country code as 2247 described in document ISO/IEC 3166- 1, and the third octet MUST 2248 have the value 1, 2 or 3 as defined below. When the value of the 2249 third octet is 255, the country code field is not used, and MUST 2250 be ignored. 2252 1 an ASCII space character, if the regulations under which the 2253 station is operating encompass all environments in the country, 2255 2 an ASCII 'O' character, if the regulations under which the 2256 station is operating are for an outdoor environment only, or 2258 3 an ASCII 'I' character, if the regulations under which the 2259 station is operating are for an indoor environment only 2261 255 Country Code field is not used; ignore the field. 2263 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2265 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2266 sent by the WTP to the AC when it detects a radio failure. 2268 0 1 2 3 2269 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 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Radio ID | Type | Status | Pad | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2276 Length: 4 2278 Radio ID: The Radio Identifier, typically refers to some interface 2279 index on the WTP 2281 Type: The type of radio failure detected. The following values are 2282 supported: 2284 1 - Receiver 2286 2 - Transmitter 2288 Status: An 8-bit boolean indicating whether the radio failure is 2289 being reported or cleared. A value of zero is used to clear the 2290 event, while a value of one is used to report the event. 2292 Pad: All implementations complying with version zero of this 2293 protocol MUST set these bits to zero. Receivers MUST ignore all 2294 bits not defined for the version of the protocol they support. 2296 6.25. IEEE 802.11 WTP Radio Information 2298 The IEEE 802.11 WTP Radio Information message element is used to 2299 communicate the radio information for each IEEE 802.11 radio in the 2300 WTP. The Discovery Request message, Primary Discovery Request 2301 message and Join Request message MUST include one such message 2302 element per radio in the WTP. The Radio-Type field is used by the AC 2303 in order to determine which IEEE 802.11 technology specific binding 2304 is to be used with the WTP. 2306 The message element contains two fields, as shown below. 2308 0 1 2 3 2309 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 2310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 | Radio ID | Radio Type | 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Radio Type | 2314 +-+-+-+-+-+-+-+-+ 2316 Type: 1048 for IEEE 802.11 WTP Radio Information 2318 Length: 5 2320 Radio ID: The Radio Identifier, which typically refers to an 2321 interface index on the WTP 2323 Radio Type: The type of radio present. Note this bitfield can be 2324 used to specify support for more than a single type of PHY/MAC. 2325 The following values are supported: 2327 1 - 802.11b: An IEEE 802.11b radio. 2329 2 - 802.11a: An IEEE 802.11a radio. 2331 4 - 802.11g: An IEEE 802.11g radio. 2333 8 - 802.11n: An IEEE 802.11n radio. 2335 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types 2336 indicated are supported in the WTP. 2338 7. IEEE 802.11 Binding WTP Saved Variables 2340 This section contains the IEEE 802.11 binding specific variables that 2341 SHOULD be saved in non-volatile memory on the WTP. 2343 7.1. IEEE80211AntennaInfo 2345 The WTP per radio antenna configuration, defined in Section 6.2. 2347 7.2. IEEE80211DSControl 2349 The WTP per radio Direct Sequence Control configuration, defined in 2350 Section 6.5. 2352 7.3. IEEE80211MACOperation 2354 The WTP per radio MAC Operation configuration, defined in 2355 Section 6.7. 2357 7.4. IEEE80211OFDMControl 2359 The WTP per radio MAC Operation configuration, defined in 2360 Section 6.10. 2362 7.5. IEEE80211Rateset 2364 The WTP per radio Basic Rate Set configuration, defined in 2365 Section 6.11. 2367 7.6. IEEE80211TxPower 2369 The WTP per radio Transmit Power configuration, defined in 2370 Section 6.18. 2372 7.7. IEEE80211QoS 2374 The WTP per radio Quality of Service configuration, defined in 2375 Section 6.22. 2377 7.8. IEEE80211RadioConfig 2379 The WTP per radio Radio Configuration, defined in Section 6.23. 2381 8. Technology Specific Message Element Values 2383 This section lists IEEE 802.11 specific values for the generic CAPWAP 2384 message elements which include fields whose values are technology 2385 specific. 2387 IEEE 802.11 uses the following values: 2389 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [4]. 2391 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 2392 [11]. 2394 9. Security Considerations 2396 This section describes security considerations for using IEEE 802.11 2397 with the CAPWAP protocol. 2399 9.1. IEEE 802.11 Security 2401 When used with an IEEE 802.11 infrastructure with WEP encryption, the 2402 CAPWAP protocol does not add any new vulnerabilities. Derived 2403 session keys between the STA and WTP can be compromised, resulting in 2404 many well-documented attacks. Implementors SHOULD discourage the use 2405 of WEP and encourage use of technically sound cryptographic solutions 2406 such as those in an IEEE 802.11 RSN. 2408 STA authentication is performed using IEEE 802.lX, and consequently 2409 EAP. Implementors SHOULD use EAP methods meeting the requirements 2410 specified [6]. 2412 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 2413 introduce new vulnerabilities, depending on whether the link security 2414 (packet encryption and integrity verification) is provided by the WTP 2415 or the AC. When the link security function is provided by the AC, no 2416 new security concerns are introduced. 2418 However, when the WTP provides link security, a new vulnerability 2419 will exist when the following conditions are true: 2421 o The client is not the first to associate to the WTP/ESSID (i.e. 2422 other clients are associated), and a GTK already exists 2424 o traffic has been broadcast under the existing GTK 2426 Under these circumstances, the receive sequence counter (KeyRSC) 2427 associated with the GTK is non-zero, but because the AC anchors the 2428 4-way handshake with the client, the exact value of the KeyRSC is not 2429 known when the AC constructs the message containing the GTK. The 2430 client will update its Key RSC value to the current valid KeyRSC upon 2431 receipt of a valid multicast/broadcast message, but prior to this, 2432 previous multicast/broadcast traffic which was secured with the 2433 existing GTK may be replayed, and the client will accept this traffic 2434 as valid. 2436 Typically, busy networks will produce numerous multicast or broadcast 2437 frames per second, so the window of opportunity with respect to such 2438 replay is expected to be very small. In most conditions, it is 2439 expected that replayed frames could be detected (and logged) by the 2440 WTP. 2442 The only way to completely close this window is to provide the exact 2443 KeyRSC value in message 3 of the 4-way handshake; any other approach 2444 simply narrows the window to varying degrees. Given the low relative 2445 threat level this presents, the additional complexity introduced by 2446 providing the exact KeyRSC value is not warranted. That is, this 2447 specification provides for a calculated risk in this regard. 2449 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 2450 802.11i handshake, unless the AC has knowledge of a more optimal RSC 2451 value to use. Mechanisms for determining a more optimal RSC value 2452 are outside the scope of this specification. 2454 10. IANA Considerations 2456 There are no IANA Considerations. 2458 11. Acknowledgements 2460 The following individuals are acknowledged for their contributions to 2461 this binding specification: Puneet Agarwal, Charles Clancy, Saravanan 2462 Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, David Perkins and 2463 Margaret Wasserman. 2465 12. References 2467 12.1. Normative References 2469 [1] "draft-ietf-capwap-protocol-specification-05". 2471 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2472 Levels", BCP 14, RFC 2119, March 1997. 2474 [3] "Information technology - Telecommunications and information 2475 exchange between systems - Local and metropolitan area networks 2476 - Specific requirements - Part 11: Wireless LAN Medium Access 2477 Control (MAC) and Physical Layer (PHY) specifications", 2478 IEEE Standard 802.11, 1999, 2479 . 2482 [4] "Information technology - Telecommunications and information 2483 exchange between systems - Local and metropolitan area networks 2484 - Specific requirements - Part 11: Wireless LAN Medium Access 2485 Control (MAC) and Physical Layer (PHY) specifications Amendment 2486 6: Medium Access Control (MAC) Security Enhancements", 2487 IEEE Standard 802.11i, July 2004, . 2490 [5] Aboba, B. and J. Wood, "Authentication, Authorization and 2491 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 2493 [6] Stanley, D., Walker, J., and B. Aboba, "Extensible 2494 Authentication Protocol (EAP) Method Requirements for Wireless 2495 LANs", RFC 4017, March 2005. 2497 [7] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for 2498 Control and Provisioning of Wireless Access Points (CAPWAP)", 2499 RFC 4118, June 2005. 2501 [8] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 2502 Protocol Version 1.1", RFC 4346, April 2006. 2504 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 2505 RFC 3753, June 2004. 2507 [10] Rescorla et al, E., "Datagram Transport Layer Security", 2508 June 2004. 2510 12.2. Informational References 2512 [11] "WiFi Protected Access (WPA) rev 1.6", April 2003. 2514 Editors' Addresses 2516 Pat R. Calhoun 2517 Cisco Systems, Inc. 2518 170 West Tasman Drive 2519 San Jose, CA 95134 2521 Phone: +1 408-853-5269 2522 Email: pcalhoun@cisco.com 2524 Michael P. Montemurro 2525 Research In Motion 2526 5090 Commerce Blvd 2527 Mississauga, ON L4W 5M4 2528 Canada 2530 Phone: +1 905-629-4746 x4999 2531 Email: mmontemurro@rim.com 2533 Dorothy Stanley 2534 Aruba Networks 2535 1322 Crossman Ave 2536 Sunnyvale, CA 94089 2538 Phone: +1 630-363-1389 2539 Email: dstanley@arubanetworks.com 2541 Full Copyright Statement 2543 Copyright (C) The IETF Trust (2007). 2545 This document is subject to the rights, licenses and restrictions 2546 contained in BCP 78, and except as set forth therein, the authors 2547 retain all their rights. 2549 This document and the information contained herein are provided on an 2550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2557 Intellectual Property 2559 The IETF takes no position regarding the validity or scope of any 2560 Intellectual Property Rights or other rights that might be claimed to 2561 pertain to the implementation or use of the technology described in 2562 this document or the extent to which any license under such rights 2563 might or might not be available; nor does it represent that it has 2564 made any independent effort to identify any such rights. Information 2565 on the procedures with respect to rights in RFC documents can be 2566 found in BCP 78 and BCP 79. 2568 Copies of IPR disclosures made to the IETF Secretariat and any 2569 assurances of licenses to be made available, or the result of an 2570 attempt made to obtain a general license or permission for the use of 2571 such proprietary rights by implementers or users of this 2572 specification can be obtained from the IETF on-line IPR repository at 2573 http://www.ietf.org/ipr. 2575 The IETF invites any interested party to bring to its attention any 2576 copyrights, patents or patent applications, or other proprietary 2577 rights that may cover technology that may be required to implement 2578 this standard. Please address the information to the IETF at 2579 ietf-ipr@ietf.org. 2581 Acknowledgment 2583 Funding for the RFC Editor function is provided by the IETF 2584 Administrative Support Activity (IASA).