idnits 2.17.1 draft-ietf-capwap-protocol-binding-ieee80211-06.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 2583. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2607. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([3]), 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 (February 21, 2008) is 5903 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-09 -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: August 24, 2008 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 February 21, 2008 10 CAPWAP Protocol Binding for IEEE 802.11 11 draft-ietf-capwap-protocol-binding-ieee80211-06 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 August 24, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 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 [3]. 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 . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 15 73 3. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . . . . 16 74 3.1. IEEE 802.11 WLAN Configuration Request . . . . . . . . . . 16 75 3.2. IEEE 802.11 WLAN Configuration Response . . . . . . . . . 17 76 4. CAPWAP Data Message Bindings . . . . . . . . . . . . . . . . . 18 77 5. CAPWAP Control Message bindings . . . . . . . . . . . . . . . 20 78 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 20 79 5.2. Discovery Response Message . . . . . . . . . . . . . . . . 20 80 5.3. Primary Discovery Request Message . . . . . . . . . . . . 20 81 5.4. Primary Discovery Response Message . . . . . . . . . . . . 20 82 5.5. Join Request Message . . . . . . . . . . . . . . . . . . . 20 83 5.6. Join Response Message . . . . . . . . . . . . . . . . . . 21 84 5.7. Configuration Status Message . . . . . . . . . . . . . . . 21 85 5.8. Configuration Status Response Message . . . . . . . . . . 21 86 5.9. Configuration Update Request Message . . . . . . . . . . . 22 87 5.10. Station Configuration Request . . . . . . . . . . . . . . 23 88 5.11. Change State Event Request . . . . . . . . . . . . . . . . 23 89 5.12. WTP Event Request . . . . . . . . . . . . . . . . . . . . 23 90 6. IEEE 802.11 Message Element Definitions . . . . . . . . . . . 24 91 6.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . . . . 24 92 6.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . . . . 28 93 6.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . . . . 29 94 6.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . . . . 30 95 6.5. IEEE 802.11 Direct Sequence Control . . . . . . . . . . . 30 96 6.6. IEEE 802.11 Information Element . . . . . . . . . . . . . 31 97 6.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . . . . 32 98 6.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . . . . 34 99 6.9. IEEE 802.11 Multi-Domain Capability . . . . . . . . . . . 34 100 6.10. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . . . . 35 101 6.11. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . . . . 36 102 6.12. IEEE 802.11 RSNA Error Report From Station . . . . . . . . 37 103 6.13. IEEE 802.11 Station . . . . . . . . . . . . . . . . . . . 39 104 6.14. IEEE 802.11 Station QoS Profile . . . . . . . . . . . . . 40 105 6.15. IEEE 802.11 Station Session Key . . . . . . . . . . . . . 40 106 6.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . . . . 42 107 6.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . . . . 46 108 6.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . . . . 46 109 6.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . . . . 47 110 6.20. IEEE 802.11 Update Station QoS . . . . . . . . . . . . . . 47 111 6.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . . . . 48 112 6.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . . . . 50 113 6.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . . . . 51 114 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . . . . 53 115 6.25. IEEE 802.11 WTP Radio Information . . . . . . . . . . . . 53 116 7. IEEE 802.11 Binding WTP Saved Variables . . . . . . . . . . . 55 117 7.1. IEEE80211AntennaInfo . . . . . . . . . . . . . . . . . . . 55 118 7.2. IEEE80211DSControl . . . . . . . . . . . . . . . . . . . . 55 119 7.3. IEEE80211MACOperation . . . . . . . . . . . . . . . . . . 55 120 7.4. IEEE80211OFDMControl . . . . . . . . . . . . . . . . . . . 55 121 7.5. IEEE80211Rateset . . . . . . . . . . . . . . . . . . . . . 55 122 7.6. IEEE80211TxPower . . . . . . . . . . . . . . . . . . . . . 55 123 7.7. IEEE80211QoS . . . . . . . . . . . . . . . . . . . . . . . 55 124 7.8. IEEE80211RadioConfig . . . . . . . . . . . . . . . . . . . 55 125 8. Technology Specific Message Element Values . . . . . . . . . . 56 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 127 9.1. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . . 57 128 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 129 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 60 130 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 131 12.1. Normative References . . . . . . . . . . . . . . . . . . . 61 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 [1]. 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 [6], reside in the AC. 241 To provide system component interoperability, the WTP and AC MUST 242 support 802.11 encryption/decryption at the WTP. The WTP and AC MAY 243 support 802.11 encryption/decryption at the AC. 245 2.1.1. Split MAC 247 This section shows the division of labor between the WTP and the AC 248 in a Split MAC architecture. Figure 1 shows the separation of 249 functionality between CAPWAP components. 251 Function Location 252 Distribution Service AC 253 Integration Service AC 254 Beacon Generation WTP 255 Probe Response Generation WTP 256 Power Mgmt/Packet Buffering WTP 257 Fragmentation/Defragmentation WTP/AC 258 Assoc/Disassoc/Reassoc AC 260 IEEE 802.11 QOS 261 Classifying AC 262 Scheduling WTP/AC 263 Queuing WTP 265 IEEE 802.11 RSN 266 IEEE 802.1X/EAP AC 267 RSNA Key Management AC 268 IEEE 802.11 Encryption/Decryption WTP/AC 270 Figure 1: Mapping of 802.11 Functions for Split MAC Architecture 272 In a Split MAC Architecture, the Distribution and Integration 273 services reside on the AC, and therefore all user data is tunneled 274 between the WTP and the AC. As noted above, all real-time IEEE 275 802.11 services, including the Beacon and Probe Response frames, are 276 handled on the WTP. 278 All remaining IEEE 802.11 MAC management frames are supported on the 279 AC, including the Association Request frame which allows the AC to be 280 involved in the access policy enforcement portion of the IEEE 802.11 281 protocol. The IEEE 802.1X and IEEE 802.11 key management function 282 are also located on the AC. This implies that the AAA client also 283 resides on the AC. 285 While the admission control component of IEEE 802.11 resides on the 286 AC, the real time scheduling and queuing functions are on the WTP. 287 Note that this does not prevent the AC from providing additional 288 policy and scheduling functionality. 290 Note that in the following figure, the use of '( - )' indicates that 291 processing of the frames is done on the WTP. 293 Client WTP AC 295 Beacon 296 <----------------------------- 297 Probe Request 298 ----------------------------( - )-------------------------> 299 Probe Response 300 <----------------------------- 301 802.11 AUTH/Association 302 <---------------------------------------------------------> 303 Station Configuration Request 304 [Add Station (Station Message 305 Elements)] 306 <--------------------------> 307 802.1X Authentication & 802.11 Key Exchange 308 <---------------------------------------------------------> 309 Station Configuration Request 310 [Add Station (AES-CCMP, 311 PTK=x)] 312 <--------------------------> 313 802.11 Action Frames 314 <---------------------------------------------------------> 315 802.11 DATA (1) 316 <---------------------------( - )-------------------------> 318 Figure 2: Split MAC Message Flow 320 Figure 2 provides an illustration of the division of labor in a Split 321 MAC architecture. In this example, a WLAN has been created that is 322 configured for IEEE 802.11, using 802.1X based end user 323 authentication and AES-CCMP link layer encryption. The following 324 process occurs: 326 o The WTP generates the IEEE 802.11 Beacon frames, using information 327 provided to it through the IEEE 802.11 Add WLAN (see Section 6.1) 328 message element, including the RSNIE, which indicates support of 329 802.1X and AES-CCMP. 331 o The WTP processes the Probe Request frame and responds with a 332 corresponding Probe Response frame. The Probe Request frame is 333 then forwarded to the AC for optional processing. 335 o The WTP forwards the IEEEE 802.11 Authentication and Association 336 frames to the AC, which is responsible for responding to the 337 client. 339 o Once the association is complete, the AC transmits a Station 340 Configuration Request message, which includes an Add Station 341 message element, to the WTP (see Section 4.6.8 in [3]). In the 342 above example, the WLAN was configured for IEEE 802.1X. 344 o If the WTP is providing encryption/decryption services, once the 345 client has completed the IEEE 802.11 key exchange, the AC 346 transmits another Station Configuration Request message which 347 includes an Add Station message element, an IEEE 802.11 Station 348 message element, an IEEE 802.11 Station Session Key message 349 element and an IEEE 802.11 Information Element message element 350 which includes the RSNIE to the WTP, delivering the security 351 policy to enforce for the station (in this case AES-CCMP), and the 352 encryption key to use. If encryption/decryption is handled in the 353 AC, the IEEE 802.11 Information message element with an RSNIE 354 would not be included. 356 o The WTP forwards any IEEE 802.11 Management Action frames received 357 to the AC. 359 o All IEEE 802.11 station data frames are tunneled between the WTP 360 and the AC. 362 The WTP SHALL include the IEEE 802.11 MAC header contents in all 363 frames transmitted to the AC. 365 When 802.11 encryption/decryption is performed at the WTP, the WTP 366 MUST decrypt the uplink frames, MUST set the Protected Frame field to 367 0, and MUST make the frame format consistent with that of an 368 unprotected 802.11 frame prior to transmitting the frames to the AC. 369 The fields added to an 802.11 protected frame (i.e., IV/EIV, MIC, and 370 ICV) MUST be stripped off prior to transmission from the WTP to AC. 371 For downlink frames, the Protected Frame field MUST be set to 0 by 372 the AC as the frame being sent is unencrypted. The WTP MUST apply 373 the required protection policy for the WLAN, and set the Protected 374 Frame field on transmission over the air. The Protected Frame field 375 always needs to accurately indicate the status of the 802.11 frame 376 that is carrying it. 378 When 802.11 encryption/decryption is performed at the AC, the WTP 379 SHALL NOT decrypt the uplink frames prior to transmitting the frames 380 to the AC. The AC and WTP SHALL populate the IEEE 802.11 MAC header 381 fields as described in Figure 3. 383 MAC header field Location 384 Frame Control: 385 Version AC 386 ToDS AC 387 FromDS AC 388 Type AC 389 SubType AC 390 MoreFrag WTP/AC 391 Retry WTP 392 Pwr Mgmt - 393 MoreData WTP 394 Protected WTP/AC 395 Order AC 396 Duration: WTP 397 Address 1: AC 398 Address 2: AC 399 Address 3: AC 400 Sequence Ctrl: WTP 401 Address 4: AC 402 QoS Control: AC 403 Frame Body: AC 404 FCS: WTP 406 Figure 3: Population of the IEEE 802.11 MAC header Fields for 407 Downlink Frames 409 When 802.11 encryption/decryption is performed at the AC, the 410 MoreFrag bit is populated at the AC. The Pwr Mgmt bit is not 411 applicable to downlink frames, and is set to 0. Note that the FCS 412 field is not included in 802.11 frames exchanged between the WTP and 413 the AC. Upon sending data frames to the AC, the WTP is responsible 414 for validating, and stripping the FCS field. Upon receiving data 415 frames from the AC, the WTP is responsible for adding the FCS field, 416 and populating the field as described in [2]. 418 2.1.2. Local MAC 420 This section shows the division of labor between the WTP and the AC 421 in a Local MAC architecture. Figure 4 shows the separation of 422 functionality among CAPWAP components. 424 Function Location 425 Distribution Service WTP/AC 426 Integration Service WTP 427 Beacon Generation WTP 428 Probe Response Generation WTP 429 Power Mgmt/Packet Buffering WTP 430 Fragmentation/Defragmentation WTP 431 Assoc/Disassoc/Reassoc WTP/AC 433 IEEE 802.11 QOS 434 Classifying WTP 435 Scheduling WTP 436 Queuing WTP 438 IEEE 802.11 RSN 439 IEEE 802.1X/EAP AC 440 RSNA Key Management AC 441 IEEE 802.11 Encryption/Decryption WTP 443 Figure 4: Mapping of 802.11 Functions for Local AP Architecture 445 In the Local MAC mode, the integration service exists on the WTP, 446 while the distribution service MAY reside on either the WTP or the 447 AC. When it resides on the AC, station generated frames are not 448 forwarded to the AC in their native format, but encapsulated as 802.3 449 frames. 451 While the MAC is terminated on the WTP, it is necessary for the AC to 452 be aware of mobility events within the WTPs. Thus the WTP MUST 453 forward the IEEE 802.11 Association Request frames to the AC. The AC 454 MAY reply with a failed Association Response frame if it deems it 455 necessary, and upon receipt of a failed Association Response frame 456 from the AC, the WTP MUST send a Disassociation frame to the station. 458 The IEEE 802.1X and RSNA Key Management functions reside in the AC. 459 Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management 460 frames to the AC and forward the corresponding responses to the 461 station. This implies that the AAA client also resides on the AC. 463 Note that in the following figure, the use of '( - )' indicates that 464 processing of the frames is done on the WTP. 466 Client WTP AC 468 Beacon 469 <----------------------------- 470 Probe 471 <----------------------------> 472 802.11 AUTH 473 <----------------------------- 474 802.11 Association 475 <---------------------------( - )-------------------------> 476 Station Configuration Request[ 477 Add Station (Station Message 478 Elements)] 479 <--------------------------> 480 802.1X Authentication & 802.11 Key Exchange 481 <---------------------------------------------------------> 482 802.11 Action Frames 483 <---------------------------------------------------------> 484 Station Configuration Request[ 485 Add Station (AES-CCMP, 486 PTK=x)] 487 <--------------------------> 488 802.11 DATA 489 <-----------------------------> 491 Figure 5: Local MAC Message Flow 493 Figure 5 provides an illustration of the division of labor in a Local 494 MAC architecture. In this example, a WLAN that is configured for 495 IEEE 802.11 has been created using AES-CCMP for privacy. The 496 following process occurs: 498 o The WTP generates the IEEE 802.11 Beacon frames, using information 499 provided to it through the Add WLAN (see Section 6.1) message 500 element. 502 o The WTP processes a Probe Request frame and responds with a 503 corresponding Probe Response frame. 505 o The WTP forwards the IEEE 802.11 Authentication and Association 506 frames to the AC. 508 o Once the association is complete, the AC transmits a Station 509 Configuration Request message, which includes the Add Station 510 message element, to the WTP (see Section 4.6.8 in [3]). In the 511 above example, the WLAN is configured for IEEE 802.1X, and 512 therefore the '802.1X only' policy bit is enabled. 514 o The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange 515 messages to the AC for processing. 517 o The AC transmits another Station Configuration Request message 518 including an Add Station message element, an IEEE 802.11 Station 519 message element, an IEEE 802.11 Station Session Key message 520 element and an IEEE 802.11 Information Element message element 521 which includes the RSNIE to the WTP, stating the security policy 522 to enforce for the client (in this case AES-CCMP), as well as the 523 encryption key to use. The Add Station message element MAY 524 include a VLAN name, which when present is used by the WTP to 525 identify the VLAN on which the user's data frames are to be 526 bridged. 528 o The WTP forwards any IEEE 802.11 Management Action frames received 529 to the AC. 531 o The WTP MAY locally bridge client data frames (and provide the 532 necessary encryption and decryption services). The WTP MAY also 533 tunnel client data frames to the AC, using 802.3 frame tunnel mode 534 or 802.11 frame tunnel mode. 536 2.2. Roaming Behavior 538 This section expands upon the examples provided in the previous 539 section, and describes how the CAPWAP control protocol is used to 540 provide secure roaming. 542 Once a client has successfully associated with the network in a 543 secure fashion, it is likely to attempt to roam to another WTP. 544 Figure 6 shows an example of a currently associated station moving 545 from its "Old WTP" to a "New WTP". The figure is valid for multiple 546 different security policies, including IEEE 802.1X and WPA or WPA2, 547 both with key caching (where the IEEE 802.1x exchange would be 548 bypassed) and without. 550 Client Old WTP New WTP AC 552 Association Request/Response 553 <--------------------------------------( - )--------------> 554 Station Configuration Request[ 555 Add Station (Station Message 556 Elements)] 557 <----------------> 558 802.1X Authentication (if no key cache entry exists) 559 <--------------------------------------( - )--------------> 560 802.11 4-way Key Exchange 561 <--------------------------------------( - )--------------> 562 Station Configuration Request 563 [Delete Station] 564 <----------------------------------> 565 Station Configuration Request 566 [Add Station (AES-CCMP, 567 PTK=x)] 568 <----------------> 570 Figure 6: Client Roaming Example 572 2.3. Group Key Refresh 574 Periodically, the Group Key (GTK)for the BSS needs to be updated. 575 The AC uses an EAPOL-Key frame to update the group key for each STA 576 in the BSS. While the AC is updating the GTK, each L2 broadcast 577 frame transmitted to the BSS needs to be duplicated and transmitted 578 using both the current GTK and the new GTK. Once the GTK update 579 process has completed, broadcast frames transmitted to the BSS will 580 be encrypted using the new GTK. 582 In the case of Split MAC, the AC needs to duplicate all broadcast 583 packets and update the key index so that the packet is transmitted 584 using both the current and new GTK to ensure that all STA's in the 585 BSS receive the broadcast frames. In the case of local MAC, the WTP 586 needs to duplicate and transmit broadcast frames using the 587 appropriate index to ensure that all STA's in the BSS continue to 588 receive broadcast frames. 590 The Group Key update procedure is shown in the following figure. The 591 AC will signal the update to the GTK using an IEEE 802.11 592 Configuration Request message, including an IEEE 802.11 Update WLAN 593 message element with the new GTK, its index, the TSC for the Group 594 Key and the Key Status set to 3 (begin GTK update). The AC will then 595 begin updating the GTK for each STA. During this time, the AC (for 596 Split MAC) or WTP (for Local MAC) MUST duplicate broadcast packets 597 and transmit them encrypted with both the current and new GTK. When 598 the AC has completed the GTK update to all STA's in the BSS, the AC 599 MUST transmit an IEEE 802.11 Configuration Request message including 600 an IEEE 802.11 Update WLAN message element containing the new GTK, 601 its index, and the Key Status set to 4 (GTK update complete). 603 Client WTP AC 605 IEEE 802.11 WLAN Configuration Request [Update 606 WLAN (GTK, GTK Index, GTK Start, 607 Group TSC) ] 608 <-------------------------------------------- 609 802.1X EAPoL (GTK Message 1) 610 <-------------( - )------------------------------------------- 611 802.1X EAPoL (GTK Message 2) 612 -------------( - )-------------------------------------------> 613 IEEE 802.11 WLAN Configuration Request [ Update 614 WLAN (GTK Index, GTK Complete) ] 615 <-------------------------------------------- 617 Figure 7: Group Key Update Procedure 619 2.4. BSSID to WLAN ID Mapping 621 The CAPWAP protocol binding enables the WTP to assign BSSIDs upon 622 creation of a WLAN (see Section 6.1). While manufacturers are free 623 to assign BSSIDs using any arbitrary mechanism, it is advised that 624 where possible the BSSIDs are assigned as a contiguous block. 626 When assigned as a block, implementations can still assign any of the 627 available BSSIDs to any WLAN. One possible method is for the WTP to 628 assign the address using the following algorithm: base BSSID address 629 + WLAN ID. 631 The WTP communicates the maximum number of BSSIDs that it supports 632 during configuration via the IEEE 802.11 WTP WLAN Radio Configuration 633 message element (see Section 6.23). 635 2.5. Quality of Service for IEEE 802.11 MAC Management Messages 637 It is recommended that IEEE 802.11 MAC Management frames be sent by 638 both the AC and the WTP with appropriate Quality of Service values, 639 listed below, to ensure that congestion in the network minimizes 640 occurrences of packet loss. 642 802.1P: The precedence value of 7 SHOULD be used for all IEEE 643 802.11 MAC management frames, except for Probe Requests which 644 SHOULD use 4. 646 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 647 MAC management frames, except for Probe Requests which SHOULD use 648 34. 650 2.6. Run State Operation 652 The Run state is the normal state of operation for the CAPWAP 653 protocol in both the WTP and the AC. 655 When the WTP receives a WLAN Configuration Request message (see 656 Section 3.1), it MUST respond with a WLAN Configuration Response 657 message (see Section 3.2) and it remains in the Run state. 659 When the AC sends a WLAN Configuration Request message (see 660 Section 3.1) or receives the corresponding WLAN Configuration 661 Response message (see Section 3.2) from the WTP, it remains in the 662 Run state. 664 3. IEEE 802.11 Specific CAPWAP Control Messages 666 This section defines CAPWAP Control Messages that are specific to the 667 IEEE 802.11 binding. Two messages are defined, IEEE 802.11 WLAN 668 Configuration Request and IEEE 802.11 WLAN Configuration Response. 669 See Section 4.5 in [3] for CAPWAP Control message definitions and the 670 derivation of the Message Type value from the IANA Enterprise number. 672 The valid message types for IEEE 802.11 specific control messages are 673 listed below. The IANA Enterprise number used with these messages is 674 13277. 676 CAPWAP Control Message Message Type 677 Value 679 IEEE 802.11 WLAN Configuration Request 3398912 680 IEEE 802.11 WLAN Configuration Response 3398913 682 3.1. IEEE 802.11 WLAN Configuration Request 684 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 685 WTP in order to change services provided by the WTP. This control 686 message is used to either create, update or delete a WLAN on the WTP. 688 The IEEE 802.11 WLAN Configuration Request is sent as a result of 689 either some manual administrative process (e.g., deleting a WLAN), or 690 automatically to create a WLAN on a WTP. When sent automatically to 691 create a WLAN, this control message is sent after the CAPWAP 692 Configuration Update Request message (see Section 8.4 in [3]) has 693 been received by the WTP. 695 Upon receiving this control message, the WTP will modify the 696 necessary services, and transmit an IEEE 802.11 WLAN Configuration 697 Response. 699 A WTP MAY provide service for more than one WLAN, therefore every 700 WLAN is identified through a numerical index. For instance, a WTP 701 that is capable of supporting up to 16 SSIDs, could accept up to 16 702 IEEE 802.11 WLAN Configuration Request messages that include the Add 703 WLAN message element. 705 Since the index is the primary identifier for a WLAN, an AC MAY 706 attempt to ensure that the same WLAN is identified through the same 707 index number on all of its WTPs. An AC that does not follow this 708 approach MUST find some other means of maintaining a WLAN-Identifier- 709 to-SSID mapping table. 711 The following message elements MAY be included in the IEEE 802.11 712 WLAN Configuration Request message. Only one message element MUST be 713 present. 715 o IEEE 802.11 Add WLAN, see Section 6.1 717 o IEEE 802.11 Delete WLAN, see Section 6.4 719 o IEEE 802.11 Update WLAN, see Section 6.21 721 The following message element MAY be present. 723 o IEEE 802.11 Information Element, see Section 6.6 725 o Vendor Specific Payload, see [3] 727 3.2. IEEE 802.11 WLAN Configuration Response 729 The IEEE 802.11 WLAN Configuration Response message is sent by the 730 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 731 WLAN Configuration Request message, and to indicate that the 732 requested configuration was successfully applied, or that an error 733 related to the processing of the IEEE 802.11 WLAN Configuration 734 Request message occurred on the WTP. 736 The following message element MAY be included in the IEEE 802.11 WLAN 737 Configuration Response message. 739 o IEEE 802.11 Assigned WTP BSSID, see Section 6.3 741 o Vendor Specific Payload, see [3] 743 The following message element MUST be included in the IEEE 802.11 744 WLAN Configuration Response message. 746 o Result Code, see Section 4.6.35 in [3] 748 4. CAPWAP Data Message Bindings 750 This section describes the CAPWAP Data Message bindings to support 751 transport of IEEE 802.11 frames. 753 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 754 message, which is used to encapsulate a wireless payload. For 755 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 756 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 757 checksum is handled by the WTP. This allows the WTP to validate 758 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 759 when an AC wishes to transmit a frame to a station, the WTP 760 computes and adds the FCS checksum. 762 Optional Wireless Specific Information: This optional CAPWAP header 763 field (see Section 4.3 in [3]) is only used with CAPWAP data 764 messages, and it serves two purposes, depending upon the direction 765 of the message. For messages from the WTP to the AC, the field 766 uses the format described in the "IEEE 802.11 Frame Info" field 767 (see below). However, for messages sent by the AC to the WTP, the 768 format used is described in the "Destination WLANs" field (also 769 defined below). 771 Note that in both cases, the two optional headers fit in the 772 "Data" field of the Wireless Specific Information header. 774 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 775 station over the air, it is encapsulated and this field is used to 776 include radio and PHY specific information associated with the 777 frame. 779 The IEEE 802.11 Frame Info field has the following format: 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | RSSI | SNR | Data Rate | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 RSSI: RSSI is a signed, 8-bit value. It is the received signal 788 strength indication, in dBm. 790 SNR: SNR is a signed, 8-bit value. It is the signal to noise 791 ratio of the received IEEE 802.11 frame, in dB. 793 Data Rate: The data rate field is a 16 bit unsigned value. The 794 contents of the field is set to 10 times the data rate in Mbps 795 of the packet received by the WTP. For instance, a packet 796 received at 5.5Mbps would be set to 55, while 11Mbps would be 797 set to 110. 799 Destination WLANs The Destination WLANs field is used to specify the 800 target WLANs for a given frame, and is only used with broadcast 801 and multicast frames. This field allows the AC to transmit a 802 single broadcast or multicast frame to the WTP, and allows the WTP 803 to perform the necessary frame replication. The field uses the 804 following format: 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | WLAN ID bitmap | Reserved | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 WLAN ID bitmap: This bit field indicates the WLAN ID (see 813 Section 6.1) on which the WTP will transmit the included frame. 814 For instance, if a multicast packet is to be transmitted on 815 WLANs 1 and 3, bits 1 and 3 of this field would be enabled. 816 This field is to be set to zero for unicast packets and is 817 unused if the WTP is not providing IEEE 802.11 encryption. 819 Reserved: All implementations complying with this protocol MUST 820 set to zero any bits that are reserved in the version of the 821 protocol supported by that implementation. Receivers MUST 822 ignore all bits not defined for the version of the protocol 823 they support. 825 5. CAPWAP Control Message bindings 827 This section describes the IEEE 802.11 specific message elements 828 included in CAPWAP Control Messages. 830 5.1. Discovery Request Message 832 The following IEEE 802.11 specific message element MUST be included 833 in the CAPWAP Discovery Request Message. 835 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 836 802.11 WTP Radio Information message element MUST be present for 837 every radio in the WTP. 839 5.2. Discovery Response Message 841 The following IEEE 802.11 specific message element MUST be included 842 in the CAPWAP Discovery Response Message. 844 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 845 802.11 WTP Radio Information message element MUST be present for 846 every radio in the WTP. 848 5.3. Primary Discovery Request Message 850 The following IEEE 802.11 specific message element MUST be included 851 in the CAPWAP Primary Discovery Request Message. 853 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 854 802.11 WTP Radio Information message element MUST be present for 855 every radio in the WTP. 857 5.4. Primary Discovery Response Message 859 The following IEEE 802.11 specific message element MUST be included 860 in the CAPWAP Primary Discovery Response Message. 862 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 863 802.11 WTP Radio Information message element MUST be present for 864 every radio in the WTP. 866 5.5. Join Request Message 868 The following IEEE 802.11 specific message element MUST be included 869 in the CAPWAP Join Request Message. 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.6. Join Response Message 877 The following IEEE 802.11 specific message element MUST be included 878 in the CAPWAP Join Response Message. 880 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 881 802.11 WTP Radio Information message element MUST be present for 882 every radio in the WTP. 884 5.7. Configuration Status Message 886 The following IEEE 802.11 specific message elements MAY be included 887 in the CAPWAP Configuration Status Message. More than one of each 888 message element listed MAY be included. 890 o IEEE 802.11 Antenna, see Section 6.2 892 o IEEE 802.11 Direct Sequence Control, see Section 6.5 894 o IEEE 802.11 MAC Operation, see Section 6.7 896 o IEEE 802.11 Multi Domain Capability, see Section 6.9 898 o IEEE 802.11 OFDM Control, see Section 6.10 900 o IEEE 802.11 Supported Rates, see Section 6.17 902 o IEEE 802.11 Tx Power, see Section 6.18 904 o IEEE 802.11 TX Power Level, see Section 6.19 906 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 908 o IEEE 802.11 WTP Radio Information, see Section 6.25. An IEEE 909 802.11 WTP Radio Information message element MUST be present for 910 every radio in the WTP. 912 5.8. Configuration Status Response Message 914 The following IEEE 802.11 specific message elements MAY be included 915 in the CAPWAP Configuration Status Response Message. More than one 916 of each message element listed MAY be included. 918 o IEEE 802.11 Antenna, see Section 6.2 919 o IEEE 802.11 Direct Sequence Control, see Section 6.5 921 o IEEE 802.11 MAC Operation, see Section 6.7 923 o IEEE 802.11 Multi Domain Capability, see Section 6.9 925 o IEEE 802.11 OFDM Control, see Section 6.10 927 o IEEE 802.11 Rate Set, see Section 6.11 929 o IEEE 802.11 Supported Rates, see Section 6.17 931 o IEEE 802.11 Tx Power, see Section 6.18 933 o IEEE 802.11 WTP Quality of Service, see Section 6.22 935 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 937 5.9. Configuration Update Request Message 939 The following IEEE 802.11 specific message elements MAY be included 940 in the CAPWAP Configuration Update Request Message. More than one of 941 each message element listed MAY be included. 943 o IEEE 802.11 Antenna, see Section 6.2 945 o IEEE 802.11 Direct Sequence Control, see Section 6.5 947 o IEEE 802.11 MAC Operation, see Section 6.7 949 o IEEE 802.11 Multi Domain Capability, see Section 6.9 951 o IEEE 802.11 OFDM Control, see Section 6.10 953 o IEEE 802.11 Rate Set, see Section 6.11 955 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 957 o IEEE 802.11 Tx Power, see Section 6.18 959 o IEEE 802.11 WTP Quality of Service, see Section 6.22 961 o IEEE 802.11 WTP Radio Configuration, see Section 6.23 963 5.10. Station Configuration Request 965 The following IEEE 802.11 specific message elements MAY included in 966 the CAPWAP Station Configuration Request message. More than one of 967 each message element listed MAY be included. 969 o IEEE 802.11 Station, see Section 6.13 971 o IEEE 802.11 Station Session Key, see Section 6.15 973 o Station QoS Profile, see Section 6.14 975 5.11. Change State Event Request 977 The following IEEE 802.11 specific message elements MAY included in 978 the CAPWAP Station Configuration Request message. 980 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 6.24 982 5.12. WTP Event Request 984 The following IEEE 802.11 specific message elements MAY be included 985 in the CAPWAP WTP Event Request message. More than one of each 986 message element listed MAY be included. 988 o IEEE 802.11 MIC Countermeasures, see Section 6.8 990 o IEEE 802.11 RSNA Error Report From Station, see Section 6.12 992 o IEEE 802.11 Statistics, see Section 6.16 994 6. IEEE 802.11 Message Element Definitions 996 The following IEEE 802.11 specific message elements are defined in 997 this section. 999 IEEE 802.11 Message Element Type Value 1001 IEEE 802.11 Add WLAN 1024 1002 IEEE 802.11 Antenna 1025 1003 IEEE 802.11 Assigned WTP BSSID 1026 1004 IEEE 802.11 Delete WLAN 1027 1005 IEEE 802.11 Direct Sequence Control 1028 1006 IEEE 802.11 Information Element 1029 1007 IEEE 802.11 MAC Operation 1030 1008 IEEE 802.11 MIC Countermeasures 1031 1009 IEEE 802.11 Multi-Domain Capability 1032 1010 IEEE 802.11 OFDM Control 1033 1011 IEEE 802.11 Rate Set 1034 1012 IEEE 802.11 RSNA Error Report From Station 1035 1013 IEEE 802.11 Station 1036 1014 IEEE 802.11 Station QoS Profile 1037 1015 IEEE 802.11 Station Session Key 1038 1016 IEEE 802.11 Statistics 1039 1017 IEEE 802.11 Supported Rates 1040 1018 IEEE 802.11 Tx Power 1041 1019 IEEE 802.11 Tx Power Level 1042 1020 IEEE 802.11 Update Station QoS 1043 1021 IEEE 802.11 Update WLAN 1044 1022 IEEE 802.11 WTP Quality of Service 1045 1023 IEEE 802.11 WTP Radio Configuration 1046 1024 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 1025 IEEE 802.11 WTP Radio Information 1048 1027 6.1. IEEE 802.11 Add WLAN 1029 The IEEE 802.11 Add WLAN message element is used by the AC to define 1030 a WLAN on the WTP. The inclusion of this message element MUST also 1031 include IEEE 802.11 Information Element message elements, containing 1032 the following IEEE 802.11 IEs: 1034 Power Capability information element 1035 WPA information element 1037 RSN information element 1039 EDCA Parameter Set information element 1041 QoS Capability information element 1043 WMM information element 1045 If present, the RSN information element is sent with the IEEE 802.11 1046 Add WLAN message element to instruct the WTP on the usage of the Key 1047 field. 1049 An AC MAY include additional information elements as desired. The 1050 message element uses the following format: 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Radio ID | WLAN ID | Capabilities | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Key Index | Key Status | Key Length | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Key... | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Group TSC | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Group TSC | QoS | Auth Type | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Type: 1024 for IEEE 802.11 Add WLAN 1070 Length: >= 49 1072 Radio ID: An 8-bit value representing the radio. 1074 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1076 Capability: A 16-bit value containing the capabilities information 1077 field to be advertised by the WTP in the Probe Request and Beacon 1078 frames. 1080 Key-Index: The Key Index associated with the key. 1082 Key Status: A 1 byte value that specifies the state and usage of 1083 the key that has been included. The following values describe the 1084 key usage and its status: 1086 0 - A value of zero, with the inclusion of the RSN Information 1087 Element means that the WLAN uses per-station encryption keys, and 1088 therefore the key in the 'Key' field is only used for multicast 1089 traffic. 1091 1 - When set to one, the WLAN employs a shared WEP key, also known 1092 as a static WEP key, and uses the encryption key for both unicast 1093 and multicast traffic for all stations. 1095 2 - The value of 2 indicates that the AC will begin rekeying the GTK 1096 with the STA's in the BSS. It is only valid when IEEE 802.11 is 1097 enabled as the security policy for the BSS. 1099 3 - The value of 3 indicates that the AC has completed rekeying the 1100 GTK and broadcast packets no longer need to be duplicated and 1101 transmitted with both GTK's. 1103 Key Length: A 16-bit value representing the length of the Key 1104 field. 1106 Key: A 32 byte Session Key to use to provide data privacy. For 1107 encryption schemes that employ a separate encryption key for 1108 unicast and multicast traffic, the key included here only applies 1109 to multicast frames, and the cipher suite is specified in an 1110 accompanied RSN Information Element. In these scenarios, the key 1111 and cipher information is communicated via the Add Station message 1112 element, see Section 4.6.8 in [3] and the IEEE 802.11 Station 1113 Session Key message element, see Section 6.15. 1115 Group TSC A 48-bit value containing the Transmit Sequence Counter 1116 for the updated group key. The WTP will set the TSC for 1117 broadcast/multicast frames to this value for the updated group 1118 key. 1120 QOS: An 8-bit value specifying the default QOS policy for the WTP 1121 to apply to network traffic received for a non-WMM enabled STA. 1123 The following values are supported: 1125 0 - Best Effort 1127 1 - Video 1129 2 - Voice 1131 3 - Background 1133 Auth Type: An 8-bit value specifying the supported authentication 1134 type. 1136 The following values are supported: 1138 0 - Open System 1140 1 - WEP Shared Key 1142 MAC Mode: This field specifies whether the WTP should support the 1143 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 1144 request a mode of operation that was not advertised by the WTP 1145 during the discovery process (see Section 4.6.46 in [3]). The 1146 following values are supported: 1148 0 - Local-MAC: Service for the WLAN is to be provided in Local 1149 MAC mode. 1151 1 - Split-MAC: Service for the WLAN is to be provided in Split 1152 MAC mode. 1154 Tunnel Mode: This field specifies the frame tunneling type to be 1155 used for 802.11 data frames from all stations associated with the 1156 WLAN. The AC MUST NOT request a mode of operation that was not 1157 advertised by the WTP during the discovery process (see Section 1158 4.6.43 in [3]). IEEE 802.11 management frames SHALL be tunneled 1159 using 802.11 Tunnel mode. The following values are supported: 1161 0 - Local Bridging: All user traffic is to be locally bridged. 1163 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC 1164 in 802.3 format (see Section 4.3 in [3]). 1166 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 1167 in 802.11 format. 1169 Supress SSID: A boolean indicating whether the SSID is to be 1170 advertised by the WTP. A value of zero suppresses the SSID in the 1171 802.11 Beacon and Probe Response frames, while a value of one will 1172 cause the WTP to populate the field. 1174 SSID: The SSID attribute is the service set identifier that will be 1175 advertised by the WTP for this WLAN. 1177 6.2. IEEE 802.11 Antenna 1179 The IEEE 802.11 Antenna message element is communicated by the WTP to 1180 the AC to provide information on the antennas available. The AC MAY 1181 use this element to reconfigure the WTP's antennas. The message 1182 element contains the following fields: 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Radio ID | Diversity | Combiner | Antenna Cnt | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | Antenna Selection [0..N] | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 Type: 1025 for IEEE 802.11 Antenna 1194 Length: >= 5 1196 Radio ID: An 8-bit value representing the radio to configure. 1198 Diversity: An 8-bit value specifying whether the antenna is to 1199 provide receive diversity. The value of this field is the same as 1200 the IEEE 802.11 dot11DiversitySelectionRx MIB element, see [2]. 1201 The following values are supported: 1203 0 - Disabled 1205 1 - Enabled (may only be true if the antenna can be used as a 1206 receive antenna) 1208 Combiner: An 8-bit value specifying the combiner selection. The 1209 following values are supported: 1211 1 - Sectorized (Left) 1213 2 - Sectorized (Right) 1214 3 - Omni 1216 4 - MIMO 1218 Antenna Count: An 8-bit value specifying the number of Antenna 1219 Selection fields. This value SHOULD be the same as the one found 1220 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [2]). 1222 Antenna Selection: One 8-bit antenna configuration value per 1223 antenna in the WTP. The following values are supported: 1225 1 - Internal Antenna 1227 2 - External Antenna 1229 6.3. IEEE 802.11 Assigned WTP BSSID 1231 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 1232 the IEEE 802.11 WLAN Configuration Request included the IEEE 802.11 1233 Add WLAN message element. The BSSID value field of this message 1234 element contains the BSSID that has been assigned by the WTP, 1235 enabling the WTP to perform its own BSSID assignment. 1237 The WTP is free to assign the BSSIDs the way it sees fit, but it is 1238 highly recommended that the WTP assign the BSSID using the following 1239 algorithm: BSSID = {base BSSID} + WLAN ID. 1241 0 1 2 3 1242 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 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Radio ID | WLAN ID | BSSID 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | BSSID | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 1251 Length: 6 1253 Radio ID: An 8-bit value representing the radio. 1255 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1257 BSSID: The BSSID assigned by the WTP for the WLAN created as a 1258 result of receiving an IEEE 802.11 Add WLAN. 1260 6.4. IEEE 802.11 Delete WLAN 1262 The IEEE 802.11 Delete WLAN message element is used to inform the WTP 1263 that a previously created WLAN is to be deleted, and contains the 1264 following fields: 1266 0 1 1267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Radio ID | WLAN ID | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 Type: 1027 for IEEE 802.11 Delete WLAN 1274 Length: 3 1276 Radio ID: An 8-bit value representing the radio 1278 WLAN ID: An 8-bit value specifying the WLAN Identifier 1280 6.5. IEEE 802.11 Direct Sequence Control 1282 The IEEE 802.11 Direct Sequence Control message element is a bi- 1283 directional element. When sent by the WTP, it contains the current 1284 state. When sent by the AC, the WTP MUST adhere to the values 1285 provided. This element is only used for IEEE 802.11b radios. The 1286 message element has the following fields. 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Radio ID | Reserved | Current Chan | Current CCA | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Energy Detect Threshold | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Type: 1028 for IEEE 802.11 Direct Sequence Control 1298 Length: 8 1300 Radio ID: An 8-bit value representing the radio to configure. 1302 Reserved: All implementations complying with this protocol MUST set 1303 to zero any bits that are reserved in the version of the protocol 1304 supported by that implementation. Receivers MUST ignore all bits 1305 not defined for the version of the protocol they support. 1307 Current Channel: This attribute contains the current operating 1308 frequency channel of the DSSS PHY. This value comes from the IEEE 1309 802.11 dot11CurrentChannel MIB element (see [2]). 1311 Current CCA: The current CCA method in operation, whose value can 1312 be found in the IEEE 802.11 dot11CCAModeSupported MIB element (see 1313 [2]). Valid values are: 1315 1 - energy detect only (edonly) 1317 2 - carrier sense only (csonly) 1319 4 - carrier sense and energy detect (edandcs) 1321 8 - carrier sense with timer (cswithtimer) 1323 16 - high rate carrier sense and energy detect (hrcsanded) 1325 Energy Detect Threshold: The current Energy Detect Threshold being 1326 used by the DSSS PHY. The value can be found in the IEEE 802.11 1327 dot11EDThreshold MIB element (see [2]). 1329 6.6. IEEE 802.11 Information Element 1331 The IEEE 802.11 Information Element is used to communicate any IE 1332 defined in the IEEE 802.11 protocol. The data field contains the raw 1333 IE as it would be included within an IEEE 802.11 MAC management 1334 message. 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Radio ID | WLAN ID |B|P| Flags |Info Element... 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Type: 1029 for IEEE 802.11 Information Element 1344 Length: >= 2 1346 Radio ID: An 8-bit value representing the radio. 1348 WLAN ID: An 8-bit value specifying the WLAN Identifier. 1350 B: When set, the WTP is to include the information element in IEEE 1351 802.11 Beacons associated with the WLAN. 1353 P: When set, the WTP is to include the information element in Probe 1354 Responses associated with the WLAN. 1356 Flags: All implementations complying with this protocol MUST set to 1357 zero any bits that are reserved in the version of the protocol 1358 supported by that implementation. Receivers MUST ignore all bits 1359 not defined for the version of the protocol they support. 1361 Info Element: The IEEE 802.11 Information Element, which includes 1362 the type, length and value field. 1364 6.7. IEEE 802.11 MAC Operation 1366 The IEEE 802.11 MAC Operation message element is sent by the AC to 1367 set the IEEE 802.11 MAC parameters on the WTP, and contains the 1368 following fields. 1370 0 1 2 3 1371 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 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Radio ID | Reserved | RTS Threshold | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Short Retry | Long Retry | Fragmentation Threshold | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Tx MSDU Lifetime | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Rx MSDU Lifetime | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 Type: 1030 for IEEE 802.11 MAC Operation 1384 Length: 16 1386 Radio ID: An 8-bit value representing the radio to configure. 1388 Reserved: All implementations complying with this protocol MUST set 1389 to zero any bits that are reserved in the version of the protocol 1390 supported by that implementation. Receivers MUST ignore all bits 1391 not defined for the version of the protocol they support. 1393 RTS Threshold: This attribute indicates the number of octets in an 1394 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 1395 RTS/CTS handshake MUST be performed at the beginning of any frame 1396 exchange sequence where the MPDU is of type Data or Management, 1397 the MPDU has an individual address in the Address1 field, and the 1398 length of the MPDU is greater than this threshold. Setting this 1399 attribute to be larger than the maximum MSDU size MUST have the 1400 effect of turning off the RTS/CTS handshake for frames of Data or 1401 Management type transmitted by this STA. Setting this attribute 1402 to zero MUST have the effect of turning on the RTS/CTS handshake 1403 for all frames of Data or Management type transmitted by this STA. 1404 The default value of this attribute MUST be 2347. The value of 1405 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 1406 element, (see [2]). 1408 Short Retry: This attribute indicates the maximum number of 1409 transmission attempts of a frame, the length of which is less than 1410 or equal to RTSThreshold, that MUST be made before a failure 1411 condition is indicated. The default value of this attribute MUST 1412 be 7. The value of this field comes from the IEEE 802.11 1413 dot11ShortRetryLimit MIB element, (see [2]). 1415 Long Retry: This attribute indicates the maximum number of 1416 transmission attempts of a frame, the length of which is greater 1417 than dot11RTSThreshold, that MUST be made before a failure 1418 condition is indicated. The default value of this attribute MUST 1419 be 4. The value of this field comes from the IEEE 802.11 1420 dot11LongRetryLimit MIB element, (see [2]). 1422 Fragmentation Threshold: This attribute specifies the current 1423 maximum size, in octets, of the MPDU that MAY be delivered to the 1424 PHY. An MSDU MUST be broken into fragments if its size exceeds 1425 the value of this attribute after adding MAC headers and trailers. 1426 An MSDU or MMPDU MUST be fragmented when the resulting frame has 1427 an individual address in the Address1 field, and the length of the 1428 frame is larger than this threshold. The default value for this 1429 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 1430 attached PHY and MUST never exceed the lesser of 2346 or the 1431 aMPDUMaxLength of the attached PHY. The value of this attribute 1432 MUST never be less than 256. The value of this field comes from 1433 the IEEE 802.11 dot11FragmentationThreshold MIB element, (see 1434 [2]). 1436 Tx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1437 after the initial transmission of an MSDU, after which further 1438 attempts to transmit the MSDU MUST be terminated. The default 1439 value of this attribute MUST be 512. The value of this field 1440 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 1441 element, (see [2]). 1443 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 1444 after the initial reception of a fragmented MMPDU or MSDU, after 1445 which further attempts to reassemble the MMPDU or MSDU MUST be 1446 terminated. The default value MUST be 512. The value of this 1447 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 1448 element, (see [2]). 1450 6.8. IEEE 802.11 MIC Countermeasures 1452 The IEEE 802.11 MIC Countermeasures message element is sent by the 1453 WTP to the AC to indicate the occurrence of a MIC failure. For more 1454 information on MIC failure events, see the 1455 dot11RSNATKIPCounterMeasuresInvoked MIB element definition in [2]. 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Radio ID | WLAN ID | MAC Address | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | MAC Address | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 Type: 1031 for IEEE 802.11 MIC Countermeasures 1467 Length: 8 1469 Radio ID: The Radio Identifier, typically refers to some interface 1470 index on the WTP. 1472 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 1473 on which the MIC failure occurred. 1475 MAC Address: The MAC Address of the station that caused the MIC 1476 failure. 1478 6.9. IEEE 802.11 Multi-Domain Capability 1480 The IEEE 802.11 Multi-Domain Capability message element is used by 1481 the AC to inform the WTP of regulatory limits. The AC will transmit 1482 one message element per frequency band to indicate the regulatory 1483 constraints in that domain. The message element contains the 1484 following fields. 1486 0 1 2 3 1487 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 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Radio ID | Reserved | First Channel # | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Number of Channels | Max Tx Power Level | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 Type: 1032 for IEEE 802.11 Multi-Domain Capability 1496 Length: 8 1498 Radio ID: An 8-bit value representing the radio to configure. 1500 Reserved: All implementations complying with this protocol MUST set 1501 to zero any bits that are reserved in the version of the protocol 1502 supported by that implementation. Receivers MUST ignore all bits 1503 not defined for the version of the protocol they support. 1505 First Channnel #: This attribute indicates the value of the lowest 1506 channel number in the sub-band for the associated domain country 1507 string. The value of this field comes from the IEEE 802.11 1508 dot11FirstChannelNumber MIB element (see [2]). 1510 Number of Channels: This attribute indicates the value of the total 1511 number of channels allowed in the sub-band for the associated 1512 domain country string. The value of this field comes from the 1513 IEEE 802.11 dot11NumberofChannels MIB element (see [2]). 1515 Max Tx Power Level: This attribute indicates the maximum transmit 1516 power, in dBm, allowed in the sub-band for the associated domain 1517 country string. The value of this field comes from the IEEE 1518 802.11 dot11MaximumTransmitPowerLevel MIB element (see [2]). 1520 6.10. IEEE 802.11 OFDM Control 1522 The IEEE 802.11 OFDM Control message element is a bi-directional 1523 element. When sent by the WTP, it contains the current state. When 1524 sent by the AC, the WTP MUST adhere to the received values. This 1525 message element is only used for 802.11a radios and contains the 1526 following fields: 1528 0 1 2 3 1529 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 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Radio ID | Reserved | Current Chan | Band Support | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | TI Threshold | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Type: 1033 for IEEE 802.11 OFDM Control 1538 Length: 8 1539 Radio ID: An 8-bit value representing the radio to configure. 1541 Reserved: All implementations complying with this protocol MUST set 1542 to zero any bits that are reserved in the version of the protocol 1543 supported by that implementation. Receivers MUST ignore all bits 1544 not defined for the version of the protocol they support. 1546 Current Channel: This attribute contains the current operating 1547 frequency channel of the OFDM PHY. The value of this field comes 1548 from the IEEE 802.11 dot11CurrentFrequency MIB element (see [2]). 1550 Band Supported: The capability of the OFDM PHY implementation to 1551 operate in the three U-NII bands. The value of this field comes 1552 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 1553 [2]), coded as an integer value of a three bit field as follows: 1555 Bit 0 - capable of operating in the lower (5.15-5.25 GHz) U-NII 1556 band 1558 Bit 1 - capable of operating in the middle (5.25-5.35 GHz) U-NII 1559 band 1561 Bit 2 - capable of operating in the upper (5.725-5.825 GHz) U-NII 1562 band 1564 For example, for an implementation capable of operating in the 1565 lower and mid bands this attribute would take the value 3. 1567 TI Threshold: The Threshold being used to detect a busy medium 1568 (frequency). CCA MUST report a busy medium upon detecting the 1569 RSSI above this threshold. The value of this field comes from the 1570 IEEE 802.11 dot11TIThreshold MIB element (see [2]). 1572 6.11. IEEE 802.11 Rate Set 1574 The rate set message element value is sent by the AC and contains the 1575 supported operational rates. It contains the following fields. 1577 0 1 2 3 1578 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 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Radio ID | Rate Set... 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Type: 1034 for IEEE 802.11 Rate Set 1585 Length: >= 3 1587 Radio ID: An 8-bit value representing the radio to configure. 1589 Rate Set: The AC generates the Rate Set that the WTP is to include 1590 in its Beacon and Probe messages. The length of this field is 1591 between 2 and 8 bytes. The value of this field comes from the 1592 IEEE 802.11 dot11OperationalRateSet MIB element (see [2]). 1594 6.12. IEEE 802.11 RSNA Error Report From Station 1596 The IEEE 802.11 RSN Error Report From Station message element is used 1597 by a WTP to send RSN error reports to the AC. The WTP does not need 1598 to transmit any reports that do not include any failures. The fields 1599 from this message element come from the IEEE 802.11 1600 Dot11RSNAStatsEntry table, see [2]. 1602 0 1 2 3 1603 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 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Client MAC Address | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Client MAC Address | BSSID | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | BSSID | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Radio ID | WLAN ID | Reserved | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | TKIP ICV Errors | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | TKIP Local MIC Failures | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | TKIP Remote MIC Failures | 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 | CCMP Replays | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | CCMP Decrypt Errors | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | TKIP Replays | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 Type: 1035 for IEEE 802.11 RSNA Error Report From Station 1628 Length: 14 1630 Client MAC Address: The Client MAC Address of the station. 1632 BSSID: The BSSID on which the failures are being reported on. 1634 Radio ID: The Radio Identifier, typically refers to some interface 1635 index on the WTP 1637 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 1639 Reserved: All implementations complying with this protocol MUST set 1640 to zero any bits that are reserved in the version of the protocol 1641 supported by that implementation. Receivers MUST ignore all bits 1642 not defined for the version of the protocol they support. 1644 TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV 1645 errors encountered when decrypting packets from the station. The 1646 value of this field comes from the IEEE 802.11 1647 dot11RSNAStatsTKIPICVErrors MIB element (see [2]). 1649 TKIP Local MIC Failures: A 32-bit value representing the number of 1650 MIC failures encountered when checking the integrity of packets 1651 received from the station. The value of this field comes from the 1652 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 1653 [2]). 1655 TKIP Remote MIC Failures: A 32-bit value representing the number of 1656 MIC failures reported by the station encountered (possibly via the 1657 EAPOL-Key frame). The value of this field comes from the IEEE 1658 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [2]). 1660 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 1661 discarded by the replay detection mechanism. The value of this 1662 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 1663 (see [2]). 1665 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 1666 MDPUs discarded by the decryption algorithm. The value of this 1667 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 1668 element (see [2]). 1670 TKIP Replays: A 32-bit value representing the number of TKIP 1671 Replays detected in frames received from the station. The value 1672 of this field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays 1673 MIB element (see [2]). 1675 6.13. IEEE 802.11 Station 1677 The IEEE 802.11 Station message element accompanies the Add Station 1678 message element, and is used to deliver IEEE 802.11 station policy 1679 from the AC to the WTP. 1681 The latest IEEE 802.11 Station message element overrides any 1682 previously received message elements. 1684 If the QoS field is set, the WTP MUST observe and provide policing of 1685 the 802.11e priority tag to ensure that it does not exceed the value 1686 provided by the AC. 1688 0 1 2 3 1689 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 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Radio ID | Association ID | Flags | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 | MAC Address | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 | MAC Address | Capabilities | 1696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1697 | WLAN ID |Supported Rates| 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 Type: 1036 for IEEE 802.11 Station 1702 Length: >= 8 1704 Radio ID: An 8-bit value representing the radio 1706 Association ID: A 16-bit value specifying the IEEE 802.11 1707 Association Identifier 1709 Flags: All implementations complying with this protocol MUST set to 1710 zero any bits that are reserved in the version of the protocol 1711 supported by that implementation. Receivers MUST ignore all bits 1712 not defined for the version of the protocol they support. 1714 MAC Address: The station's MAC Address 1716 Capabilities: A 16-bit field containing the IEEE 802.11 1717 Capabilities Information Field to use with the station. 1719 WLAN ID: An 8-bit value specifying the WLAN Identifier 1720 Supported Rates: The variable length field containing the supported 1721 rates to be used with the station, as found in the IEEE 802.11 1722 dot11OperationalRateSet MIB element (see [2]). 1724 6.14. IEEE 802.11 Station QoS Profile 1726 The IEEE 802.11 Station QoS Profile message element contains the 1727 maximum IEEE 802.11e priority tag that may be used by the station. 1728 Any packet received that exceeds the value encoded in this message 1729 element MUST either be dropped or tagged using the maximum value 1730 permitted by to the user. The priority tag MUST be between zero (0) 1731 and seven (7). This message element MUST NOT be present without the 1732 IEEE 802.11 Station (see Section 6.13) message element 1734 0 1 2 3 1735 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 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | MAC Address | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 | MAC Address | 802.1P Precedence Tag | 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 Type: 1037 for IEEE 802.11 Station QOS Profile 1744 Length: 8 1746 MAC Address: The station's MAC Address 1748 802.1P Precedence Tag: The maximum 802.1P precedence value that the 1749 WTP will allow in the TID field in the extended 802.11e QOS Data 1750 header. 1752 6.15. IEEE 802.11 Station Session Key 1754 The IEEE 802.11 Station Session Key message element is sent when the 1755 AC determines that encryption of a station must be performed in the 1756 WTP. This message element MUST NOT be present without the IEEE 1757 802.11 Station (see Section 6.13) message element, and MUST NOT be 1758 sent if the WTP had not specifically advertised support for the 1759 requested encryption scheme. 1761 The RSN information element MUST sent along with the IEEE 802.11 1762 Station Session Key in order to instruct the WTP on the usage of the 1763 Key field. The AKM field of the RSM information element is used by 1764 the WTP to identify the authentication protocol. 1766 If the IEEE 802.11 Station Session Key message element's AKM-Only bit 1767 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 1768 of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an 1769 encryption key is in force, requiring that the AKM packets be 1770 encrypted. Once the station has successfully completed 1771 authentication via the AKM, the AC MUST send a new Add Station 1772 message element to remove the AKM-Only restriction, and optionally 1773 push the session key down to the WTP. 1775 0 1 2 3 1776 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 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | MAC Address | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | MAC Address |A|C| Flags | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Pairwise TSC | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Pairwise TSC | Pairwise RSC | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Pairwise RSC | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Key... 1789 +-+-+-+-+-+-+-+- 1791 Type: 1038 for IEEE 802.11 Station Session Key 1793 Length: >= 25 1795 MAC Address: The station's MAC Address 1797 Flags: All implementations complying with this protocol MUST set to 1798 zero any bits that are reserved in the version of the protocol 1799 supported by that implementation. Receivers MUST ignore all bits 1800 not defined for the version of the protocol they support. The 1801 following bits are defined: 1803 A: The one bit AKM-Only field is set by the AC to inform the WTP 1804 that is MUST NOT accept any 802.11 data frames, other than AKM 1805 frames. This is the equivalent of the WTP's IEEE 802.1X port 1806 for the station to be in the closed state. When set, the WTP 1807 MUST drop any non-IEEE 802.1X packets it receives from the 1808 station. 1810 C: The one bit field is set by the AC to inform the WTP that 1811 encryption services will be provided by the AC. When set, the 1812 WTP SHOULD police frames received from stations to ensure that 1813 are properly encrypted as specified in the RSN Information 1814 Element, but does not need to take specific cryptographic 1815 action on the frame. Similarly, for transmitted frames, the 1816 WTP only needs to forward already encrypted frames. 1818 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 1819 use for unicast packets transmitted to the station. 1821 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 1822 unicast packets received from the station. 1824 Key: The key the WTP is to use when encrypting traffic to/from the 1825 station. For dynamically created keys, this is commonly known as 1826 a Pairwise Transient Key (PTK). 1828 6.16. IEEE 802.11 Statistics 1830 The IEEE 802.11 Statistics message element is sent by the WTP to 1831 transmit its current statistics, and contains the following fields. 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Radio ID | Reserved | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Tx Fragment Count | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Multicast Tx Count | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Failed Count | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 | Retry Count | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | Multiple Retry Count | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | Frame Duplicate Count | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | RTS Success Count | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | RTS Failure Count | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | ACK Failure Count | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Rx Fragment Count | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Multicast RX Count | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | FCS Error Count | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Tx Frame Count | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Decryption Errors | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | Discarded QoS Fragment Count | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Associated Station Count | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | QoS CF Polls Received Count | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | QoS CF Polls Unused Count | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | QoS CF Polls Unusable Count | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 Type: 1039 for IEEE 802.11 Statistics 1879 Length: 60 1881 Radio ID: An 8-bit value representing the radio. 1883 Reserved: All implementations complying with this protocol MUST set 1884 to zero any bits that are reserved in the version of the protocol 1885 supported by that implementation. Receivers MUST ignore all bits 1886 not defined for the version of the protocol they support. 1888 Tx Fragment Count: A 32-bit value representing the number of 1889 fragmented frames transmitted. The value of this field comes from 1890 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 1891 [2]). 1893 Multicast Tx Count: A 32-bit value representing the number of 1894 multicast frames transmitted. The value of this field comes from 1895 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 1896 (see [2]). 1898 Failed Count: A 32-bit value representing the transmit excessive 1899 retries. The value of this field comes from the IEEE 802.11 1900 dot11FailedCount MIB element (see [2]). 1902 Retry Count: A 32-bit value representing the number of transmit 1903 retries. The value of this field comes from the IEEE 802.11 1904 dot11RetryCount MIB element (see [2]). 1906 Multiple Retry Count: A 32-bit value representing the number of 1907 transmits that required more than one retry. The value of this 1908 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 1909 element (see [2]). 1911 Frame Duplicate Count: A 32-bit value representing the duplicate 1912 frames received. The value of this field comes from the IEEE 1913 802.11 dot11FrameDuplicateCount MIB element (see [2]). 1915 RTS Success Count: A 32-bit value representing the number of 1916 successfully transmitted Ready To Send (RTS). The value of this 1917 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 1918 (see [2]). 1920 RTS Failure Count: A 32-bit value representing the failed 1921 transmitted RTS. The value of this field comes from the IEEE 1922 802.11 dot11RTSFailureCount MIB element (see [2]). 1924 ACK Failure Count: A 32-bit value representing the number of failed 1925 acknowledgements. The value of this field comes from the IEEE 1926 802.11 dot11ACKFailureCount MIB element (see [2]). 1928 Rx Fragment Count: A 32-bit value representing the number of 1929 fragmented frames received. The value of this field comes from 1930 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [2]). 1932 Multicast RX Count: A 32-bit value representing the number of 1933 multicast frames received. The value of this field comes from the 1934 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 1935 [2]). 1937 FCS Error Count: A 32-bit value representing the number of FCS 1938 failures. The value of this field comes from the IEEE 802.11 1939 dot11FCSErrorCount MIB element (see [2]). 1941 Decryption Errors: A 32-bit value representing the number of 1942 Decryption errors that occurred on the WTP. Note that this field 1943 is only valid in cases where the WTP provides encryption/ 1944 decryption services. The value of this field comes from the IEEE 1945 802.11 dot11WEPUndecryptableCount MIB element (see [2]). 1947 Discarded QoS Fragment Count: A 32-bit value representing the 1948 number of discarded QoS fragments received. The value of this 1949 field comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount 1950 MIB element (see [2]). 1952 Associated Station Count: A 32-bit value representing the number of 1953 number of associated stations. The value of this field comes from 1954 the IEEE 802.11 dot11AssociatedStationCount MIB element (see [2]). 1956 QoS CF Polls Received Count: A 32-bit value representing the number 1957 of (+)CF-Polls received. The value of this field comes from the 1958 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [2]). 1960 QoS CF Polls Unused Count: A 32-bit value representing the number 1961 of (+)CF-Polls that have been received, but not used. The value 1962 of this field comes from the IEEE 802.11 1963 dot11QosCFPollsUnusedCount MIB element (see [2]). 1965 QoS CF Polls Unusable Count: A 32-bit value representing the number 1966 of (+)CF-Polls that have been received, but could not be used due 1967 to the TXOP size being smaller than the time that is required for 1968 one frame exchange sequence. The value of this field comes from 1969 the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see 1970 [2]). 1972 6.17. IEEE 802.11 Supported Rates 1974 The IEEE 802.11 Supported Rates message element is sent by the WTP to 1975 indicate the rates that it supports, and contains the following 1976 fields. 1978 0 1 2 3 1979 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 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Radio ID | Supported Rates... 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1984 Type: 1040 for IEEE 802.11 Supported Rates 1986 Length: >= 3 1988 Radio ID: An 8-bit value representing the radio. 1990 Supported Rates: The WTP includes the Supported Rates that its 1991 hardware supports. The format is identical to the Rate Set 1992 message element and is between 2 and 8 bytes in length. 1994 6.18. IEEE 802.11 Tx Power 1996 The IEEE 802.11 Tx Power message element value is bi-directional. 1997 When sent by the WTP, it contains the current power level of the 1998 radio in question. When sent by the AC, it contains the power level 1999 the WTP MUST adhere to. 2001 0 1 2 3 2002 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 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | Radio ID | Reserved | Current Tx Power | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 Type: 1041 for IEEE 802.11 Tx Power 2009 Length: 4 2011 Radio ID: An 8-bit value representing the radio to configure. 2013 Reserved: All implementations complying with this protocol MUST set 2014 to zero any bits that are reserved in the version of the protocol 2015 supported by that implementation. Receivers MUST ignore all bits 2016 not defined for the version of the protocol they support. 2018 Current Tx Power: This attribute contains the current transmit 2019 output power in mW, as described in the dot11CurrentTxPowerLevel 2020 MIB variable, see [2]. 2022 6.19. IEEE 802.11 Tx Power Level 2024 The IEEE 802.11 Tx Power Level message element is sent by the WTP and 2025 contains the different power levels supported. The values found in 2026 this message element are found in the IEEE 802.11 2027 Dot11PhyTxPowerEntry MIB table, see [2]. 2029 The value field contains the following: 2031 0 1 2 3 2032 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 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Radio ID | Num Levels | Power Level [n] | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 Type: 1042 for IEEE 802.11 Tx Power Level 2039 Length: >= 4 2041 Radio ID: An 8-bit value representing the radio to configure. 2043 Num Levels: The number of power level attributes. The value of 2044 this field comes from the IEEE 802.11 2045 dot11NumberSupportedPowerLevels MIB element (see [2]). 2047 Power Level: Each power level fields contains a supported power 2048 level, in mW. The value of this field comes from the 2049 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element, see 2050 [2]. 2052 6.20. IEEE 802.11 Update Station QoS 2054 The IEEE 802.11 Update Station QoS message element is used to change 2055 the Quality of Service policy on the WTP for a given station. 2057 0 1 2 3 2058 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 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | Radio ID | MAC Address | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | MAC Address | DSCP Tag | 802.1P Tag | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Type: 1043 for IEEE 802.11 Update Station QoS 2067 Length: 8 2069 Radio ID: The Radio Identifier, typically refers to some interface 2070 index on the WTP 2072 MAC Address: The station's MAC Address. 2074 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2076 802.1P Tag: The 802.1P precedence value to use if packets are to be 2077 IEEE 802.1P tagged. 2079 6.21. IEEE 802.11 Update WLAN 2081 The IEEE 802.11 Update WLAN message element is used by the AC to 2082 define a wireless LAN on the WTP. The inclusion of this message 2083 element MUST also include the IEEE 802.11 Information Element message 2084 element, containing the following 802.11 IEs: 2086 Power Capability information element 2088 WPA information element 2090 RSN information element 2092 EDCA Parameter Set information element 2094 QoS Capability information element 2096 WMM information element 2098 The message element uses the following format: 2100 0 1 2 3 2101 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 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Radio ID | WLAN ID | Capability | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Key Index | Key Status | Key Length | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Key... | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2110 Type: 1044 for IEEE 802.11 Update WLAN 2112 Length: 43 2114 Radio ID: An 8-bit value representing the radio. 2116 WLAN ID: An 8-bit value specifying the WLAN Identifier. 2118 Capability: A 16-bit value containing the capabilities information 2119 field to be advertised by the WTP within the Probe and Beacon 2120 messages. 2122 Key-Index: The Key Index associated with the key. 2124 Key Status: A 1 byte value that specifies the state and usage of 2125 the key that has been included. The following values describe the 2126 key usage and its status: 2128 0 - A value of zero, with the inclusion of the RSN Information 2129 Element means that the WLAN uses per-station encryption keys, and 2130 therefore the key in the 'Key' field is only used for multicast 2131 traffic. 2133 1 - When set to one, the WLAN employs a shared WEP key, also known 2134 as a static WEP key, and uses the encryption key for both unicast 2135 and multicast traffic for all stations. 2137 2 - The value of 2 indicates that the AC will begin rekeying the GTK 2138 with the STA's in the BSS. It is only valid when IEEE 802.11 is 2139 enabled as the security policy for the BSS. 2141 3 - The value of 3 indicates that the AC has completed rekeying the 2142 GTK and broadcast packets no longer need to be duplicated and 2143 transmitted with both GTK's. 2145 Key Length: A 16-bit value representing the length of the Key 2146 field. 2148 Key: A 32 byte Session Key to use to provide data privacy. For 2149 static WEP keys, which is true when the 'Key Status' bit is set to 2150 one, this key is used for both unicast and multicast traffic. For 2151 encryption schemes that employ a separate encryption key for 2152 unicast and multicast traffic, the key included here only applies 2153 to multicast data, and the cipher suite is specified in an 2154 accompanied RSN Information Element. In these scenarios, the key, 2155 and cipher information, is communicated via the Add Station 2156 message element, see Section 4.6.8 in [3]. 2158 6.22. IEEE 802.11 WTP Quality of Service 2160 The IEEE 802.11 WTP Quality of Service message element value is sent 2161 by the AC to the WTP to communicate quality of service configuration 2162 information. 2164 0 1 2165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | Radio ID | Tag Packets | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 Type: 1045 for IEEE 802.11 WTP Quality of Service 2172 Length: >= 2 2174 Radio ID: The Radio Identifier, typically refers to some interface 2175 index on the WTP 2177 Tag Packets: A value indicating whether CAPWAP packets should be 2178 tagged for QoS purposes. The following values are currently 2179 supported: 2181 0 - Untagged 2183 1 - 802.1P 2185 2 - DSCP 2187 Immediately following the above header is the following data 2188 structure. This data structure will be repeated five times; once 2189 for every QoS profile. The order of the QoS profiles are Voice, 2190 Video, Best Effort and Background. 2192 0 1 2 3 2193 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 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Queue Depth | CWMin | CWMax | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | CWMax | AIFS | Dot1P Tag | DSCP Tag | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 Queue Depth: The number of packets that can be on the specific QoS 2201 transmit queue at any given time. 2203 CWMin: The Contention Window minimum value for the QoS transmit 2204 queue. The value of this field comes from the IEEE 802.11 2205 dot11EDCATableCWMin MIB element (see [2]). 2207 CWMax: The Contention Window maximum value for the QoS transmit 2208 queue. The value of this field comes from the IEEE 802.11 2209 dot11EDCATableCWMax MIB element (see [2]). 2211 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 2212 transmit queue. The value of this field comes from the IEEE 2213 802.11 dot11EDCATableAIFSN MIB element (see [2]). 2215 Dot1P Tag: The 802.1P precedence value to use if packets are to be 2216 802.1P tagged. 2218 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 2220 6.23. IEEE 802.11 WTP Radio Configuration 2222 The IEEE 802.11 WTP WLAN Radio Configuration message element is used 2223 by the AC to configure a Radio on the WTP, and by the WTP to deliver 2224 its radio configuration to the AC. The message element value 2225 contains the following fields: 2227 0 1 2 3 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | BSSID | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | BSSID | Beacon Period | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Country Code | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 2241 Length: 16 2243 Radio ID: An 8-bit value representing the radio to configure. 2245 Short Preamble: An 8-bit value indicating whether short preamble is 2246 supported. The following values are currently supported: 2248 0 - Short preamble not supported. 2250 1 - Short preamble is supported. 2252 BSSID: The WLAN Radio's base MAC Address. 2254 Number of BSSIDs: This attribute contains the maximum number of 2255 BSSIDs supported by the WTP. This value restricts the number of 2256 logical networks supported by the WTP, and is between 1 and 16. 2258 DTIM Period: This attribute specifies the number of beacon 2259 intervals that elapse between transmission of Beacons frames 2260 containing a TIM element whose DTIM Count field is 0. This value 2261 is transmitted in the DTIM Period field of Beacon frames. The 2262 value of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 2263 element (see [2]). 2265 Beacon Period: This attribute specifies the number of TU that a 2266 station uses for scheduling Beacon transmissions. This value is 2267 transmitted in Beacon and Probe Response frames. The value of 2268 this field comes from the IEEE 802.11 dot11BeaconPeriod MIB 2269 element (see [2]). 2271 Country Code: This attribute identifies the country in which the 2272 station is operating. The value of this field comes from the IEEE 2273 802.11 dot11CountryString MIB element (see [2]). Special 2274 attention is required with use of this field, as implementations 2275 which take action based on this field could violate regulatory 2276 requirements. Some regulatory bodies do permit configuration of 2277 the country code under certain restrictions, such as the FCC, when 2278 WTPs are certified as Software Defined Radios. 2280 The WTP and AC MAY ignore the value of this field, depending upon 2281 regulatory requirements, for example to avoid classification as a 2282 Software Defined Radio. When this field is used, the first two 2283 octets of this string is the two character country code as 2284 described in document ISO/IEC 3166- 1, and the third octet MUST 2285 have the value 1, 2 or 3 as defined below. When the value of the 2286 third octet is 255, the country code field is not used, and MUST 2287 be ignored. 2289 1 an ASCII space character, if the regulations under which the 2290 station is operating encompass all environments in the country, 2292 2 an ASCII 'O' character, if the regulations under which the 2293 station is operating are for an outdoor environment only, or 2295 3 an ASCII 'I' character, if the regulations under which the 2296 station is operating are for an indoor environment only 2298 255 Country Code field is not used; ignore the field. 2300 6.24. IEEE 802.11 WTP Radio Fail Alarm Indication 2302 The IEEE 802.11 WTP Radio Fail Alarm Indication message element is 2303 sent by the WTP to the AC when it detects a radio failure. 2305 0 1 2 3 2306 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 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Radio ID | Type | Status | Pad | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2311 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 2313 Length: 4 2315 Radio ID: The Radio Identifier, typically refers to some interface 2316 index on the WTP 2318 Type: The type of radio failure detected. The following values are 2319 supported: 2321 1 - Receiver 2323 2 - Transmitter 2325 Status: An 8-bit boolean indicating whether the radio failure is 2326 being reported or cleared. A value of zero is used to clear the 2327 event, while a value of one is used to report the event. 2329 Pad: All implementations complying with version zero of this 2330 protocol MUST set these bits to zero. Receivers MUST ignore all 2331 bits not defined for the version of the protocol they support. 2333 6.25. IEEE 802.11 WTP Radio Information 2335 The IEEE 802.11 WTP Radio Information message element is used to 2336 communicate the radio information for each IEEE 802.11 radio in the 2337 WTP. The Discovery Request message, Primary Discovery Request 2338 message and Join Request message MUST include one such message 2339 element per radio in the WTP. The Radio-Type field is used by the AC 2340 in order to determine which IEEE 802.11 technology specific binding 2341 is to be used with the WTP. 2343 The message element contains two fields, as shown below. 2345 0 1 2 3 2346 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 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Radio ID | Radio Type | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | Radio Type | 2351 +-+-+-+-+-+-+-+-+ 2353 Type: 1048 for IEEE 802.11 WTP Radio Information 2355 Length: 5 2357 Radio ID: The Radio Identifier, which typically refers to an 2358 interface index on the WTP 2360 Radio Type: The type of radio present. Note this bit field can be 2361 used to specify support for more than a single type of PHY/MAC. 2362 The following values are supported: 2364 1 - 802.11b: An IEEE 802.11b radio. 2366 2 - 802.11a: An IEEE 802.11a radio. 2368 4 - 802.11g: An IEEE 802.11g radio. 2370 8 - 802.11n: An IEEE 802.11n radio. 2372 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types 2373 indicated are supported in the WTP. 2375 7. IEEE 802.11 Binding WTP Saved Variables 2377 This section contains the IEEE 802.11 binding specific variables that 2378 SHOULD be saved in non-volatile memory on the WTP. 2380 7.1. IEEE80211AntennaInfo 2382 The WTP per radio antenna configuration, defined in Section 6.2. 2384 7.2. IEEE80211DSControl 2386 The WTP per radio Direct Sequence Control configuration, defined in 2387 Section 6.5. 2389 7.3. IEEE80211MACOperation 2391 The WTP per radio MAC Operation configuration, defined in 2392 Section 6.7. 2394 7.4. IEEE80211OFDMControl 2396 The WTP per radio MAC Operation configuration, defined in 2397 Section 6.10. 2399 7.5. IEEE80211Rateset 2401 The WTP per radio Basic Rate Set configuration, defined in 2402 Section 6.11. 2404 7.6. IEEE80211TxPower 2406 The WTP per radio Transmit Power configuration, defined in 2407 Section 6.18. 2409 7.7. IEEE80211QoS 2411 The WTP per radio Quality of Service configuration, defined in 2412 Section 6.22. 2414 7.8. IEEE80211RadioConfig 2416 The WTP per radio Radio Configuration, defined in Section 6.23. 2418 8. Technology Specific Message Element Values 2420 This section lists IEEE 802.11 specific values for the generic CAPWAP 2421 message elements which include fields whose values are technology 2422 specific. 2424 IEEE 802.11 uses the following values: 2426 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [4]. 2428 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 2429 [7]. 2431 9. Security Considerations 2433 This section describes security considerations for using IEEE 802.11 2434 with the CAPWAP protocol. 2436 9.1. IEEE 802.11 Security 2438 When used with an IEEE 802.11 infrastructure with WEP encryption, the 2439 CAPWAP protocol does not add any new vulnerabilities. Derived 2440 session keys between the STA and WTP can be compromised, resulting in 2441 many well-documented attacks. Implementers SHOULD discourage the use 2442 of WEP and encourage use of technically sound cryptographic solutions 2443 such as those in an IEEE 802.11 RSN. 2445 STA authentication is performed using IEEE 802.lX, and consequently 2446 EAP. Implementers SHOULD use EAP methods meeting the requirements 2447 specified [5]. 2449 When used with IEEE 802.11 RSN security, the CAPWAP protocol may 2450 introduce new vulnerabilities, depending on whether the link security 2451 (packet encryption and integrity verification) is provided by the WTP 2452 or the AC. When the link security function is provided by the AC, no 2453 new security concerns are introduced. 2455 However, when the WTP provides link security, a new vulnerability 2456 will exist when the following conditions are true: 2458 o The client is not the first to associate to the WTP/ESSID (i.e. 2459 other clients are associated), and a GTK already exists 2461 o traffic has been broadcast under the existing GTK 2463 Under these circumstances, the receive sequence counter (KeyRSC) 2464 associated with the GTK is non-zero, but because the AC anchors the 2465 4-way handshake with the client, the exact value of the KeyRSC is not 2466 known when the AC constructs the message containing the GTK. The 2467 client will update its Key RSC value to the current valid KeyRSC upon 2468 receipt of a valid multicast/broadcast message, but prior to this, 2469 previous multicast/broadcast traffic which was secured with the 2470 existing GTK may be replayed, and the client will accept this traffic 2471 as valid. 2473 Typically, busy networks will produce numerous multicast or broadcast 2474 frames per second, so the window of opportunity with respect to such 2475 replay is expected to be very small. In most conditions, it is 2476 expected that replayed frames could be detected (and logged) by the 2477 WTP. 2479 The only way to completely close this window is to provide the exact 2480 KeyRSC value in message 3 of the 4-way handshake; any other approach 2481 simply narrows the window to varying degrees. Given the low relative 2482 threat level this presents, the additional complexity introduced by 2483 providing the exact KeyRSC value is not warranted. That is, this 2484 specification provides for a calculated risk in this regard. 2486 The AC SHOULD use an RSC of 0 when computing message-3 of the 4-way 2487 802.11i handshake, unless the AC has knowledge of a more optimal RSC 2488 value to use. Mechanisms for determining a more optimal RSC value 2489 are outside the scope of this specification. 2491 10. IANA Considerations 2493 There are no IANA Considerations. 2495 11. Acknowledgements 2497 The following individuals are acknowledged for their contributions to 2498 this binding specification: Puneet Agarwal, Charles Clancy, Saravanan 2499 Govindan, Scott Kelly, Peter Nilsson, Bob O'Hara, David Perkins and 2500 Margaret Wasserman. 2502 12. References 2504 12.1. Normative References 2506 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2507 Levels", BCP 14, RFC 2119, March 1997. 2509 [2] "Information technology - Telecommunications and information 2510 exchange between systems - Local and metropolitan area networks 2511 - Specific requirements - Part 11: Wireless LAN Medium Access 2512 Control (MAC) and Physical Layer (PHY) specifications", 2513 IEEE Standard 802.11, 1999, 2514 . 2516 [3] Calhoun, P., "CAPWAP Protocol Specification", 2517 draft-ietf-capwap-protocol-specification-09 (work in progress), 2518 February 2008. 2520 [4] "Information technology - Telecommunications and information 2521 exchange between systems - Local and metropolitan area networks 2522 - Specific requirements - Part 11: Wireless LAN Medium Access 2523 Control (MAC) and Physical Layer (PHY) specifications Amendment 2524 6: Medium Access Control (MAC) Security Enhancements", 2525 IEEE Standard 802.11i, July 2004, 2526 . 2529 12.2. Informational References 2531 [5] Stanley, D., Walker, J., and B. Aboba, "Extensible 2532 Authentication Protocol (EAP) Method Requirements for Wireless 2533 LANs", RFC 4017, March 2005. 2535 [6] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for 2536 Control and Provisioning of Wireless Access Points (CAPWAP)", 2537 RFC 4118, June 2005. 2539 [7] "WiFi Protected Access (WPA), WPAfor802.11ver3_073004.pdf", 2540 August 2004. 2542 Editors' Addresses 2544 Pat R. Calhoun 2545 Cisco Systems, Inc. 2546 170 West Tasman Drive 2547 San Jose, CA 95134 2549 Phone: +1 408-853-5269 2550 Email: pcalhoun@cisco.com 2552 Michael P. Montemurro 2553 Research In Motion 2554 5090 Commerce Blvd 2555 Mississauga, ON L4W 5M4 2556 Canada 2558 Phone: +1 905-629-4746 x4999 2559 Email: mmontemurro@rim.com 2561 Dorothy Stanley 2562 Aruba Networks 2563 1322 Crossman Ave 2564 Sunnyvale, CA 94089 2566 Phone: +1 630-363-1389 2567 Email: dstanley@arubanetworks.com 2569 Full Copyright Statement 2571 Copyright (C) The IETF Trust (2008). 2573 This document is subject to the rights, licenses and restrictions 2574 contained in BCP 78, and except as set forth therein, the authors 2575 retain all their rights. 2577 This document and the information contained herein are provided on an 2578 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2579 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2580 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2581 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2582 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2583 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2585 Intellectual Property 2587 The IETF takes no position regarding the validity or scope of any 2588 Intellectual Property Rights or other rights that might be claimed to 2589 pertain to the implementation or use of the technology described in 2590 this document or the extent to which any license under such rights 2591 might or might not be available; nor does it represent that it has 2592 made any independent effort to identify any such rights. Information 2593 on the procedures with respect to rights in RFC documents can be 2594 found in BCP 78 and BCP 79. 2596 Copies of IPR disclosures made to the IETF Secretariat and any 2597 assurances of licenses to be made available, or the result of an 2598 attempt made to obtain a general license or permission for the use of 2599 such proprietary rights by implementers or users of this 2600 specification can be obtained from the IETF on-line IPR repository at 2601 http://www.ietf.org/ipr. 2603 The IETF invites any interested party to bring to its attention any 2604 copyrights, patents or patent applications, or other proprietary 2605 rights that may cover technology that may be required to implement 2606 this standard. Please address the information to the IETF at 2607 ietf-ipr@ietf.org. 2609 Acknowledgment 2611 Funding for the RFC Editor function is provided by the IETF 2612 Administrative Support Activity (IASA).