idnits 2.17.1 draft-ohara-capwap-lwapp-02.txt: -(3132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3137): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3186): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4852. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 114 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3751 has weird spacing: '...gmented frame...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 31, 2005) is 6958 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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' ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. '3') ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Unknown state RFC: RFC 815 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3384 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. '10') -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '13') (Obsoleted by RFC 4301) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun 3 Internet-Draft B. O'Hara 4 Expires: October 2, 2005 Airespace 5 S. Kelly 6 Facetime Communications 7 R. Suri 8 Airespace 9 M. Williams 10 Nokia, Inc. 11 S. Hares 12 Nexthop Technologies, Inc. 13 N. Cam Winget 14 Cisco Systems, Inc. 15 March 31, 2005 17 Light Weight Access Point Protocol (LWAPP) 18 draft-ohara-capwap-lwapp-02 20 Status of this Memo 22 This document is an Internet-Draft and is subject to all provisions 23 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 24 author represents that any applicable patent or other IPR claims of 25 which he or she is aware have been or will be disclosed, and any of 26 which he or she become aware will be disclosed, in accordance with 27 RFC 3668. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on October 2, 2005. 47 Copyright Notice 48 Copyright (C) The Internet Society (2005). 50 Abstract 52 In the recent years, there has been a shift in wireless LAN product 53 architectures from autonomous access points to centralized control of 54 light weight access points. The general goal has been to move most 55 of the traditional wireless functionality such as access control 56 (user authentication and authorization), mobility and radio 57 management out of the access point into a centralized controller. 59 The IETF's CAPWAP WG has identified that a standards based protocol 60 is necessary between a wireless Access Controller and Wireless 61 Termination Points (the latter are also commonly referred to as Light 62 Weight Access Points). This specification defines the Light Weight 63 Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol 64 requirements. Although the LWAPP protocol is designed to be flexible 65 enough to be used for a variety of wireless technologies, this 66 specific document describes the base protocol, and an extension that 67 allows it to be used with the IEEE's 802.11 wireless LAN protocol. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1.1 Conventions used in this document . . . . . . . . . . . 9 73 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 74 2.1 Wireless Binding Definition . . . . . . . . . . . . . . 11 75 2.2 LWAPP State Machine Definition . . . . . . . . . . . . . 12 76 3. LWAPP Transport Layers . . . . . . . . . . . . . . . . . . . 20 77 3.1 LWAPP Transport Header . . . . . . . . . . . . . . . . . 20 78 3.1.1 VER Field . . . . . . . . . . . . . . . . . . . . . 20 79 3.1.2 RID Field . . . . . . . . . . . . . . . . . . . . . 20 80 3.1.3 C Bit . . . . . . . . . . . . . . . . . . . . . . . 20 81 3.1.4 F Bit . . . . . . . . . . . . . . . . . . . . . . . 20 82 3.1.5 L Bit . . . . . . . . . . . . . . . . . . . . . . . 21 83 3.1.6 Fragment ID . . . . . . . . . . . . . . . . . . . . 21 84 3.1.7 Length . . . . . . . . . . . . . . . . . . . . . . . 21 85 3.1.8 Status and WLANS . . . . . . . . . . . . . . . . . . 21 86 3.1.9 Payload . . . . . . . . . . . . . . . . . . . . . . 21 87 3.2 Using IEEE 802.3 MAC as LWAPP transport . . . . . . . . 21 88 3.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . 22 89 3.2.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 22 90 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC 91 transport . . . . . . . . . . . . . . . . . . . . . 22 92 3.2.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 22 93 3.2.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 23 94 3.3 Using IPv4/UDP as LWAPP transport . . . . . . . . . . . 23 95 3.3.1 Framing . . . . . . . . . . . . . . . . . . . . . . 23 96 3.3.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 23 97 3.3.3 LWAPP Message Header format over IPv4/UDP transport 24 98 3.3.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 24 99 3.3.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 25 100 4. LWAPP Packet Definitions . . . . . . . . . . . . . . . . . . 26 101 4.1 LWAPP Data Messages . . . . . . . . . . . . . . . . . . 26 102 4.2 LWAPP Control Messages Overview . . . . . . . . . . . . 26 103 4.2.1 Control Message Format . . . . . . . . . . . . . . . 27 104 4.2.2 Message Element Format . . . . . . . . . . . . . . . 29 105 5. LWAPP Discovery Operations . . . . . . . . . . . . . . . . . 31 106 5.1 Discovery Request . . . . . . . . . . . . . . . . . . . 31 107 5.1.1 Discovery Type . . . . . . . . . . . . . . . . . . . 32 108 5.1.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 32 109 5.1.3 WTP Radio Information . . . . . . . . . . . . . . . 33 110 5.2 Discovery Response . . . . . . . . . . . . . . . . . . . 33 111 5.2.1 AC Address . . . . . . . . . . . . . . . . . . . . . 34 112 5.2.2 AC Descriptor . . . . . . . . . . . . . . . . . . . 34 113 5.2.3 AC Name . . . . . . . . . . . . . . . . . . . . . . 35 114 5.2.4 WTP Manager Control IP Address . . . . . . . . . . . 35 115 5.3 Primary Discovery Request . . . . . . . . . . . . . . . 36 116 5.3.1 Discovery Type . . . . . . . . . . . . . . . . . . . 36 117 5.3.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 36 118 5.3.3 WTP Radio Information . . . . . . . . . . . . . . . 36 119 5.4 Primary Discovery Response . . . . . . . . . . . . . . . 36 120 5.4.1 AC Descriptor . . . . . . . . . . . . . . . . . . . 37 121 5.4.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 37 122 5.4.3 WTP Manager Control IP Address . . . . . . . . . . . 37 123 6. Control Channel Management . . . . . . . . . . . . . . . . . 38 124 6.1 Join Request . . . . . . . . . . . . . . . . . . . . . . 38 125 6.1.1 WTP Descriptor . . . . . . . . . . . . . . . . . . . 39 126 6.1.2 AC Address . . . . . . . . . . . . . . . . . . . . . 39 127 6.1.3 WTP Name . . . . . . . . . . . . . . . . . . . . . . 39 128 6.1.4 Location Data . . . . . . . . . . . . . . . . . . . 39 129 6.1.5 WTP Radio Information . . . . . . . . . . . . . . . 39 130 6.1.6 Certificate . . . . . . . . . . . . . . . . . . . . 40 131 6.1.7 Session ID . . . . . . . . . . . . . . . . . . . . . 40 132 6.1.8 Test . . . . . . . . . . . . . . . . . . . . . . . . 40 133 6.1.9 WNonce . . . . . . . . . . . . . . . . . . . . . . . 41 134 6.1.10 DH-Params . . . . . . . . . . . . . . . . . . . . . 41 135 6.2 Join Response . . . . . . . . . . . . . . . . . . . . . 42 136 6.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 42 137 6.2.2 Status . . . . . . . . . . . . . . . . . . . . . . . 43 138 6.2.3 Certificate . . . . . . . . . . . . . . . . . . . . 43 139 6.2.4 Session Key . . . . . . . . . . . . . . . . . . . . 43 140 6.2.5 WTP Manager Data IP Address . . . . . . . . . . . . 44 141 6.2.6 AC List . . . . . . . . . . . . . . . . . . . . . . 44 142 6.2.7 ANonce . . . . . . . . . . . . . . . . . . . . . . . 45 143 6.2.8 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 45 144 6.2.9 DH-Params . . . . . . . . . . . . . . . . . . . . . 46 145 6.3 Join ACK . . . . . . . . . . . . . . . . . . . . . . . . 46 146 6.3.1 Session ID . . . . . . . . . . . . . . . . . . . . . 46 147 6.3.2 WNonce . . . . . . . . . . . . . . . . . . . . . . . 46 148 6.3.3 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 46 149 6.4 Join Confirm . . . . . . . . . . . . . . . . . . . . . . 46 150 6.4.1 Session ID . . . . . . . . . . . . . . . . . . . . . 47 151 6.4.2 ANonce . . . . . . . . . . . . . . . . . . . . . . . 47 152 6.4.3 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 47 153 6.5 Echo Request . . . . . . . . . . . . . . . . . . . . . . 47 154 6.6 Echo Response . . . . . . . . . . . . . . . . . . . . . 47 155 6.7 Key Update Request . . . . . . . . . . . . . . . . . . . 48 156 6.7.1 Session ID . . . . . . . . . . . . . . . . . . . . . 48 157 6.8 Key Update Response . . . . . . . . . . . . . . . . . . 48 158 6.8.1 Session Key . . . . . . . . . . . . . . . . . . . . 49 159 6.9 Key Update Trigger . . . . . . . . . . . . . . . . . . . 49 160 6.9.1 Session ID . . . . . . . . . . . . . . . . . . . . . 49 161 7. WTP Configuration Management . . . . . . . . . . . . . . . . 50 162 7.1 Configure Request . . . . . . . . . . . . . . . . . . . 50 163 7.1.1 Administrative State . . . . . . . . . . . . . . . . 50 164 7.1.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 51 165 7.1.3 AC Name with Index . . . . . . . . . . . . . . . . . 51 166 7.1.4 WTP Board Data . . . . . . . . . . . . . . . . . . . 51 167 7.1.5 Statistics Timer . . . . . . . . . . . . . . . . . . 52 168 7.1.6 WTP Static IP Address Information . . . . . . . . . 52 169 7.1.7 WTP Reboot Statistics . . . . . . . . . . . . . . . 53 170 7.2 Configure Response . . . . . . . . . . . . . . . . . . . 53 171 7.2.1 Decryption Error Report Period . . . . . . . . . . . 54 172 7.2.2 Change State Event . . . . . . . . . . . . . . . . . 54 173 7.2.3 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 55 174 7.2.4 AC List . . . . . . . . . . . . . . . . . . . . . . 55 175 7.2.5 WTP Fallback . . . . . . . . . . . . . . . . . . . . 55 176 7.2.6 Idle Timeout . . . . . . . . . . . . . . . . . . . . 56 177 7.3 Configuration Update Request . . . . . . . . . . . . . . 56 178 7.3.1 WTP Name . . . . . . . . . . . . . . . . . . . . . . 56 179 7.3.2 Change State Event . . . . . . . . . . . . . . . . . 57 180 7.3.3 Administrative State . . . . . . . . . . . . . . . . 57 181 7.3.4 Statistics Timer . . . . . . . . . . . . . . . . . . 57 182 7.3.5 Location Data . . . . . . . . . . . . . . . . . . . 57 183 7.3.6 Decryption Error Report Period . . . . . . . . . . . 57 184 7.3.7 AC List . . . . . . . . . . . . . . . . . . . . . . 57 185 7.3.8 Add Blacklist Entry . . . . . . . . . . . . . . . . 57 186 7.3.9 Delete Blacklist Entry . . . . . . . . . . . . . . . 58 187 7.3.10 Add Static Blacklist Entry . . . . . . . . . . . . . 58 188 7.3.11 Delete Static Blacklist Entry . . . . . . . . . . . 59 189 7.3.12 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 59 190 7.3.13 AC Name with Index . . . . . . . . . . . . . . . . . 59 191 7.3.14 WTP Fallback . . . . . . . . . . . . . . . . . . . . 59 192 7.3.15 Idle Timeout . . . . . . . . . . . . . . . . . . . . 59 193 7.4 Configuration Update Response . . . . . . . . . . . . . 59 194 7.4.1 Result Code . . . . . . . . . . . . . . . . . . . . 60 195 7.5 Change State Event Request . . . . . . . . . . . . . . . 60 196 7.5.1 Change State Event . . . . . . . . . . . . . . . . . 60 197 7.6 Change State Event Response . . . . . . . . . . . . . . 60 198 7.7 Clear Config Indication . . . . . . . . . . . . . . . . 61 199 8. Device Management Operations . . . . . . . . . . . . . . . . 62 200 8.1 Image Data Request . . . . . . . . . . . . . . . . . . . 62 201 8.1.1 Image Download . . . . . . . . . . . . . . . . . . . 62 202 8.1.2 Image Data . . . . . . . . . . . . . . . . . . . . . 62 203 8.2 Image Data Response . . . . . . . . . . . . . . . . . . 63 204 8.3 Reset Request . . . . . . . . . . . . . . . . . . . . . 63 205 8.4 Reset Response . . . . . . . . . . . . . . . . . . . . . 63 206 8.5 WTP Event Request . . . . . . . . . . . . . . . . . . . 63 207 8.5.1 Decryption Error Report . . . . . . . . . . . . . . 64 208 8.5.2 Duplicate IP Address . . . . . . . . . . . . . . . . 64 209 8.6 WTP Event Response . . . . . . . . . . . . . . . . . . . 65 210 8.7 Data Transfer Request . . . . . . . . . . . . . . . . . 65 211 8.7.1 Data Transfer Mode . . . . . . . . . . . . . . . . . 65 212 8.7.2 Data Transfer Data . . . . . . . . . . . . . . . . . 66 214 8.8 Data Transfer Response . . . . . . . . . . . . . . . . . 66 215 9. Mobile Session Management . . . . . . . . . . . . . . . . . 67 216 9.1 Mobile Config Request . . . . . . . . . . . . . . . . . 67 217 9.1.1 Delete Mobile . . . . . . . . . . . . . . . . . . . 67 218 9.2 Mobile Config Response . . . . . . . . . . . . . . . . . 68 219 9.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 68 220 10. Session Key Generation . . . . . . . . . . . . . . . . . . 69 221 10.1 Securing WTP-AC communications . . . . . . . . . . . . . 69 222 10.2 LWAPP Frame Encryption . . . . . . . . . . . . . . . . . 70 223 10.3 Authenticated Key Exchange . . . . . . . . . . . . . . . 71 224 10.3.1 Certificate Based Approach . . . . . . . . . . . . . 71 225 10.3.2 Pre-Shared Key Approach . . . . . . . . . . . . . . 74 226 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . 78 227 11.1 Division of labor . . . . . . . . . . . . . . . . . . . 78 228 11.1.1 Split MAC . . . . . . . . . . . . . . . . . . . . . 78 229 11.1.2 Local MAC . . . . . . . . . . . . . . . . . . . . . 79 230 11.2 Transport specific bindings . . . . . . . . . . . . . . 79 231 11.2.1 Status and WLANS field . . . . . . . . . . . . . . . 79 232 11.3 Data Message bindings . . . . . . . . . . . . . . . . . 80 233 11.4 Control Message bindings . . . . . . . . . . . . . . . . 80 234 11.4.1 Mobile Config Request . . . . . . . . . . . . . . . 80 235 11.4.2 WTP Event Request . . . . . . . . . . . . . . . . . 85 236 11.5 802.11 Control Messages . . . . . . . . . . . . . . . . 87 237 11.5.1 IEEE 802.11 WLAN Config Request . . . . . . . . . . 87 238 11.5.2 IEEE 802.11 WLAN Config Response . . . . . . . . . . 91 239 11.5.3 IEEE 802.11 WTP Event . . . . . . . . . . . . . . . 91 240 11.6 Message Element Bindings . . . . . . . . . . . . . . . . 92 241 11.6.1 IEEE 802.11 WTP WLAN Radio Configuration . . . . . . 93 242 11.6.2 IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 94 243 11.6.3 IEEE 802.11 Multi-domain Capability . . . . . . . . 95 244 11.6.4 IEEE 802.11 MAC Operation . . . . . . . . . . . . . 95 245 11.6.5 IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 97 246 11.6.6 IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 97 247 11.6.7 IEEE 802.11 Direct Sequence Control . . . . . . . . 97 248 11.6.8 IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 98 249 11.6.9 IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 99 250 11.6.10 IEEE 802.11 Supported Rates . . . . . . . . . . . 99 251 11.6.11 IEEE 802.11 CFP Status . . . . . . . . . . . . . . 100 252 11.6.12 IEEE 802.11 WTP Mode and Type . . . . . . . . . . 100 253 11.6.13 IEEE 802.11 Broadcast Probe Mode . . . . . . . . . 101 254 11.6.14 IEEE 802.11 WTP Quality of Service . . . . . . . . 101 255 11.6.15 IEEE 802.11 MIC Error Report From Mobile . . . . . 102 256 11.7 IEEE 802.11 Message Element Values . . . . . . . . . . . 103 257 12. LWAPP Protocol Timers . . . . . . . . . . . . . . . . . . 104 258 12.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 104 259 12.2 SilentInterval . . . . . . . . . . . . . . . . . . . . . 104 260 12.3 NeighborDeadInterval . . . . . . . . . . . . . . . . . . 104 261 12.4 EchoInterval . . . . . . . . . . . . . . . . . . . . . . 104 262 12.5 DiscoveryInterval . . . . . . . . . . . . . . . . . . . 104 263 12.6 RetransmitInterval . . . . . . . . . . . . . . . . . . . 104 264 12.7 ResponseTimeout . . . . . . . . . . . . . . . . . . . . 105 265 12.8 KeyLifetime . . . . . . . . . . . . . . . . . . . . . . 105 266 13. LWAPP Protocol Variables . . . . . . . . . . . . . . . . . 106 267 13.1 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 106 268 13.2 DiscoveryCount . . . . . . . . . . . . . . . . . . . . . 106 269 13.3 RetransmitCount . . . . . . . . . . . . . . . . . . . . 106 270 13.4 MaxRetransmit . . . . . . . . . . . . . . . . . . . . . 106 271 14. Security Considerations . . . . . . . . . . . . . . . . . 107 272 14.1 Certificate based Session Key establishment . . . . . . 107 273 14.2 PSK based Session Key establishment . . . . . . . . . . 108 274 15. IANA Considerations . . . . . . . . . . . . . . . . . . . 109 275 16. IPR Statement . . . . . . . . . . . . . . . . . . . . . . 110 276 17. References . . . . . . . . . . . . . . . . . . . . . . . . 111 277 17.1 Normative References . . . . . . . . . . . . . . . . . . 111 278 17.2 Informational References . . . . . . . . . . . . . . . . 112 279 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 112 280 Intellectual Property and Copyright Statements . . . . . . . 114 282 1. Introduction 284 Unlike wired network elements, Wireless Termination Points (WTPs) 285 require a set of dynamic management and control functions related to 286 their primary task of connecting the wireless and wired mediums. 287 Today, protocols for managing WTPs are either manual static 288 configuration via HTTP, proprietary Layer 2 specific or non-existent 289 (if the WTPs are self-contained). The emergence of simple 802.11 290 WTPs that are managed by a WLAN appliance or switch (also known as an 291 Access Controller, or AC) suggests that having a standardized, 292 interoperable protocol could radically simplify the deployment and 293 management of wireless networks. In many cases the overall control 294 and management functions themselves are generic and could apply to an 295 AP for any wireless Layer 2 protocol. Being independent of specific 296 wireless Layer 2 technologies, such a protocol could better support 297 interoperability between Layer 2 devices and enable smoother 298 intertechnology handovers. 300 The details of how these functions would be implemented are dependent 301 on the particular Layer 2 wireless technology. Such a protocol would 302 need provisions for binding to specific technologies. 304 LWAPP assumes a network configuration that consists of multiple WTPs 305 communicating either via layer 2 (MAC) or layer 3 (IP) to an AC. The 306 WTPs can be considered as remote RF interfaces, being controlled by 307 the AC. The AC forwards all L2 frames it wants to transmit to an WTP 308 via the LWAPP protocol. Packets from mobile nodes are forwarded by 309 the WTP to the AC, also via this protocol. Figure 1 illustrates this 310 arrangement as applied to an IEEE 802.11 binding. 312 +-+ 802.11frames +-+ 313 | |--------------------------------| | 314 | | +-+ | | 315 | |--------------| |---------------| | 316 | | 802.11 PHY/ | | LWAPP | | 317 | | MAC sublayer | | | | 318 +-+ +-+ +-+ 319 STA WTP AC 321 Figure 1: LWAPP Architecture 323 Security is another aspect of Wireless Termination Point management 324 that is not well served by existing solutions. Provisioning WTPs 325 with security credentials, and managing which WTPs are authorized to 326 provide service are today handled by proprietary solutions. Allowing 327 these functions to be performed from a centralized AC in an 328 interoperable fashion increases managability and allows network 329 operators to more tightly control their wireless network 330 infrastructure. 332 This document describes the Light Weight Access Point Protocol 333 (LWAPP), allowing an AC to manage a collection of WTPs. The protocol 334 is defined to be independent of Layer 2 technology, but an 802.11 335 binding is provided for use in growing 802.11 wireless LAN networks. 337 Goals 339 The following are goals for this protocol: 340 1. Centralization of the bridging, forwarding, authentication and 341 policy enforcement functions for a wireless network. Optionally, 342 the AC may also provide centralized encryption of user traffic. 343 This will permit reduced cost and higher efficiency when applying 344 the capabilities of network processing silicon to the wireless 345 network, as it has already been applied to wired LANs. 346 2. Permit shifting of the higher level protocol processing burden 347 away from the WTP. This leaves the computing resource of the WTP 348 to the timing critical applications of wireless control and 349 access. This makes the most efficient use of the computing power 350 available in WTPs that are the subject of severe cost pressure. 351 3. Providing a generic encapsulation and transport mechanism, the 352 protocol may be applied to other access point type in the future 353 by adding the binding. 355 The LWAPP protocol concerns itself solely with the interface between 356 the WTP and the AC. Inter-AC, or mobile to AC communication is 357 strictly outside the scope of this document. 359 1.1 Conventions used in this document 361 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 362 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 363 document are to be interpreted as described in RFC 2119 [1]. 365 2. Protocol Overview 367 LWAPP is a generic protocol defining how Wireless Termination Points 368 communicate with Access Controllers. Wireless Termination Points and 369 Access Controllers may communicate either by means of Layer 2 370 protocols or by means of a routed IP network. 372 LWAPP messages and procedures defined in this document apply to both 373 types of transports unless specified otherwise. Transport 374 independence is achieved by defining formats for both MAC level and 375 IP level transport (see Section 3). Also defined are framing, 376 fragmentation/reassembly, and multiplexing services to LWAPP for each 377 transport type. 379 The LWAPP Transport layer carries two types of payload. LWAPP Data 380 Messages are forwarded wireless frames. LWAPP Control Messages are 381 management messages exchanged between an WTP and an AC. The LWAPP 382 transport header defines the "C-bit", which is used to distinguish 383 data and control traffic. When used over IP, the LWAPP data and 384 control traffic are also sent over separate UDP ports. Since both 385 data and control frames can exceed PMTU, the payload of an LWAPP data 386 or control message can be fragmented. The fragmentation behavior is 387 highly dependent upon the lower layer transport and is defined in 388 Section 3. 390 The Light Weight Access Protocol (LWAPP) begins with a discovery 391 phase. The WTPs send a Discovery Request frame, causing any Access 392 Controller (AC) , receiving that frame to respond with a Discovery 393 Response. From the Discovery Responses received, an WTP will select 394 an AC with which to associate, using the Join Request and Join 395 Response. The Join Request also provides an MTU discovery mechanism, 396 to determine whether there is support for the transport of large 397 frames between the WTP and it's AC. If support for large frames is 398 not present, the LWAPP frames will be fragmented to the maximum 399 length discovered to be supported by the network. 401 Once the WTP and the AC have joined, a configuration exchange is 402 accomplished that will cause both devices to agree on version 403 information. During this exchange the WTP may receive provisioning 404 settings. For the 802.11 binding, this information would typically 405 include a name (802.11 Service Set Identifier, SSID), and security 406 parameters, the data rates to be advertised as well as the radio 407 channel (channels, if the WTP is capable of operating more than one 408 802.11 MAC and PHY simultaneously) to be used. Finally, the WTPs are 409 enabled for operation. 411 When the WTP and AC have completed the version and provision exchange 412 and the WTP is enabled, the LWAPP encapsulates the wireless frames 413 sent between them. LWAPP will fragment its packets, if the size of 414 the encapsulated wireless user data (Data) or protocol control 415 (Management) frames causes the resultant LWAPP packet to exceed the 416 MTU supported between the WTP and AC. Fragmented LWAPP packets are 417 reassembled to reconstitute the original encapsulated payload. 419 In addition to the functions thus far described, LWAPP also provides 420 for the delivery of commands from the AC to the WTP for the 421 management of devices that are communicating with the WTP. This may 422 include the creation of local data structures in the WTP for the 423 managed devices and the collection of statistical information about 424 the communication between the WTP and the 802.11 devices. LWAPP 425 provides the ability for the AC to obtain any statistical information 426 collected by the WTP. 428 LWAPP also provides for a keep alive feature that preserves the 429 communication channel between the WTP and AC. If the AC fails to 430 appear alive, the WTP will try to discover a new AC to communicate 431 through. 433 This Document uses terminology defined in [5] 435 2.1 Wireless Binding Definition 437 This draft standard specifies a protocol independent of a specific 438 wireless access point radio technology. Elements of the protocol are 439 designed to accommodate specific needs of each wireless technology in 440 a standard way. Implementation of this standard for a particular 441 wireless technology must follow the binding requirements defined for 442 that technology. This specification includes a binding for the IEEE 443 802.11 (see Section 11). 445 When defining a binding for other technologies, the authors MUST 446 include any necessary definitions for technology-specific messages 447 and all technology-specific message elements for those messages. At 448 a minimum, a binding MUST provide the definition for a 449 binding-specific Statistics message element, which is carried in the 450 WTP Event Request message, and Add Mobile message element, which is 451 carried in the Mobile Configure Request. If any technology specific 452 message elements are required for any of the existing LWAPP messages 453 defined in this specification, they MUST also be defined in the 454 technology binding document. 456 The naming of binding-specific message elements MUST begin with the 457 name of the technology type, e.g., the binding for IEEE 802.11, 458 provided in this standard, begins with "IEEE 802.11"." 460 2.2 LWAPP State Machine Definition 462 The following state diagram represents the lifecycle of an WTP-AC 463 session: 465 /-------------\ 466 | v 467 | +------------+ 468 | C| Idle |<-----------------------------------\ 469 | +------------+<-----------------------\ | 470 | ^ |a ^ | | 471 | | | \----\ | | 472 | | | |t u | | 473 | | | +-----------+------>+------------+ | 474 | / | C| Run | | Key Update | | 475 | / | r+-----------+<------+------------+ | 476 | / | ^ |s w x| | 477 | | v | | | | 478 | | +--------------+ | | v |y 479 | | C| Discovery | q| \--------------->+-------+ 480 | | b+--------------+ +-------------+ | Reset | 481 | | |d f| ^ | Configure |------->+-------+ 482 | | | | | +-------------+p ^ 483 | |e v | | ^ ^ | 484 | +---------+ v |i |k 2| | 485 | C| Sulking | +------------+ +--------------+ | 486 | +---------+ C| Join |--->| Join-Confirm | | 487 | g+------------+z +--------------+ | 488 | |h m| 3| |4 | 489 | | | | v |o 490 |\ | | | +------------+ 491 \\-----------------/ \--------+---->| Image Data |C 492 \------------------------------------/ +------------+n 494 Figure 2: LWAPP State Machine 496 The LWAPP state machine, depicted above, is used by both the AC and 497 the WTP. For every state defined, only certain messages are 498 permitted to be sent and received. In all of the LWAPP control 499 messages defined in this document, the state for which each command 500 is valid is specified. 502 Note that in the state diagram figure above, the 'C' character is 503 used to represent a condition that causes the state to remain the 504 same. 506 The following text discusses the various state transitions, and the 507 events that cause them. 508 Idle to Discovery (a): This is the initialization state. 509 WTP: The WTP enters the Discovery state prior to transmitting the 510 first Discovery Request (see Section 5.1). Upon entering this 511 state, the WTP sets the DiscoveryInterval timer (see 512 Section 12). The WTP resets the DiscoveryCount counter to zero 513 (0) (see Section 13). The WTP also clears all information from 514 ACs (e.g., AC Addresses) it may have received during a previous 515 Discovery phase. 516 AC: The AC does not need to maintain state information for the WTP 517 upon reception of the Discovery Request, but it MUST respond 518 with a Discovery Response (see Section 5.2). 519 Discovery to Discovery (b): This is the state the WTP uses to 520 determine which AC it wishes to connect to. 521 WTP: This event occurs when the DiscoveryInterval timer expires. 522 The WTP transmits a Discovery Request to every AC which the WTP 523 hasn't received a response to. For every transition to this 524 event, the WTP increments DisoveryCount counter. See 525 Section 5.1) for more information on how the WTP knows which 526 ACs it should transmit the Discovery Requests to. The WTP 527 restarts the DiscoveryInterval timer. 528 AC: This is a noop. 529 Discovery to Sulking (d): This state occurs on a WTP when Discovery 530 or connectivity to the AC fails. 531 WTP: The WTP enters this state when the DiscoveryInterval timer 532 expires and the DiscoveryCount variable is equal to the 533 MaxDiscoveries variable (see Section 13). Upon entering this 534 state, the WTP will start the SilentInterval timer. While in 535 the Sulking state, all LWAPP messages received are ignored. 536 AC: This is a noop. 537 Sulking to Idle (e): This state occurs on a WTP when it must restart 538 the discovery phase. 539 WTP: The WTP enters this state when the SilentInterval timer (see 540 Section 12) expires. 541 AC: This is a noop. 542 Discovery to Join (f): This state is used by the WTP to confirm its 543 commitment to an AC that it wishes to be provided service. 544 WTP: The WTP selects the best AC based on the information it 545 gathered during the Discovery Phase. It then transmits a Join 546 Request (see Section 6.1 to its preferred AC. The WTP starts 547 the WaitJoin Timer (see Section 12). 548 AC: The AC enters this state for the given WTP upon reception of a 549 Join Request. The AC processes the request and responds with a 550 Join Response. 551 Join to Join (g): This state transition occurs during the join phase. 553 WTP: The WTP enters this state when the WaitJoin timer expires, 554 and the underlying transport requires LWAPP MTU detection 555 Section 3). 556 AC: This state occurs when the AC receives a retransmission of a 557 Join Request. The WTP processes the request and responds with 558 the Join Response.. 559 Join to Idle (h): This state is used when the join process failed. 560 WTP: This state transition occurs if the WTP is configured to use 561 PSK security and receives a Join Response that includes an 562 invalid PSK-MIC message element. 563 AC: The AC enters this state when it transmits an unsuccessful 564 Join Response. 565 Join to Discovery (i): This state is used when the join process 566 failed. 567 WTP: The WTP enters this state when it receives an unsuccessful 568 Join Response. Upon entering this state, the WTP sets the 569 DiscoveryInterval timer (see Section 12). The WTP resets the 570 DiscoveryCount counter to zero (0) (see Section 13). This 571 state transition may also occur if the PSK-MIC (see 572 Section 6.2.8) message element is invalid. 573 AC: This state transition is invalid. 574 Join to Join-Confirm (z): This state is used solely with the LWAPP 575 PSK Mode, and is used for the purposes of key confirmation. 576 WTP: This state is entered when the WTP receives a Join Response 577 that includes a valid PSK-MIC message element. The WTP MUST 578 respond with a Join ACK, which is used to provide key 579 confirmation. 580 AC: The AC enters this state when it receives a Join ACK that 581 includes a valid PSK-MIC message element. The AC MUST respond 582 with a Join Confirm message, which includes the Session Key 583 message element. 584 Join to Configure (k): This state is used by the WTP and the AC to 585 exchange configuration information. 586 WTP: The WTP enters this state when it receives a successful Join 587 Response, and determines that its version number and the 588 version number advertised by the AC are the same. The WTP 589 transmits the Configure Request (see Section 7.1) message to 590 the AC with a snapshot of its current configuration. This 591 state transition is only valid when the Certificate message 592 element is present in the Join Response, and not if the PSK-MIC 593 message element is present. The WTP also starts the 594 ResponseTimeout timer (see Section 12). 595 AC: This state transition occurs when the AC receives the 596 Configure Request from the WTP. Note that the AC MUST only 597 allow this state transition if the Join process used 598 certificate based security, through the presence on the 599 Certificate message element. The AC must transmit a Configure 600 Response (see Section 7.2) to the WTP, and may include specific 601 message elements to override the WTP's configuration. 602 Join to Image Data (m): This state is used by the WTP and the AC to 603 download executable firmware. 604 WTP: The WTP enters this state when it receives a successful Join 605 Response, and determines that its version number and the 606 version number advertised by the AC are different. This state 607 transition is only valid when the Certificate message element 608 is present in the Join Response, and not if the PSK-MIC message 609 element is present. The WTP transmits the Image Data Request 610 (see Section 8.1) message requesting that the AC's latest 611 firmware be initiated. 612 AC: This state transition occurs when the AC receives the Image 613 Data Request from the WTP. Note that the AC MUST only allow 614 this state transition if the Join process used certificate 615 based security, through the presence on the Certificate message 616 element. The AC must transmit a Image Data Response (see 617 Section 8.2) to the WTP, which includes a portion of the 618 firmware. 619 Join-Confirm to Idle (3): This state is used when the join process 620 failed. 621 WTP: This state transition occurs when the WTP receives an invalid 622 Join Confirm. 623 AC: The AC enters this state when it receives an invalid Join ACK. 624 Join-Confirm to Configure (2): This state is used by the WTP and the 625 AC to exchange configuration information. 626 WTP: The WTP enters this state when it receives a successful Join 627 Confirm, and determines that its version number and the version 628 number advertised by the AC are the same. The WTP transmits 629 the Configure Request (see Section 7.1) message to the AC with 630 a snapshot of its current configuration. The WTP also starts 631 the ResponseTimeout timer (see Section 12). 632 AC: This state transition occurs when the AC receives the 633 Configure Request from the WTP. The AC must transmit a 634 Configure Response (see Section 7.2) to the WTP, and may 635 include specific message elements to override the WTP's 636 configuration. 637 Join-Confirm to Image Data (4): This state is used by the WTP and the 638 AC to download executable firmware. 639 WTP: The WTP enters this state when it receives a successful Join 640 Confirm, and determines that its version number and the version 641 number advertised by the AC are different. The WTP transmits 642 the Image Data Request (see Section 8.1) message requesting 643 that the AC's latest firmware be initiated. 644 AC: This state transition occurs when the AC receives the Image 645 Data Request from the WTP. The AC must transmit a Image Data 646 Response (see Section 8.2) to the WTP, which includes a portion 647 of the firmware. 649 Image Data to Image Data (n): This state is used by WTP and the AC 650 during the firmware download phase. 651 WTP: The WTP enters this state when it receives a Image Data 652 Response that indicates that the AC has more data to send. 653 AC: This state transition occurs when the AC receives the Image 654 Data Request from the WTP while already in this state, and it 655 detects that the firmware download has not completed. 656 Image Data to Reset (o): This state is used when the firmware 657 download is completed. 658 WTP: The WTP enters this state when it receives a Image Data 659 Response that indicates that the AC has no more data to send, 660 or if the underlying LWAPP transport indicates a link failure. 661 At this point, the WTP reboots itself. 662 AC: This state transition occurs when the AC receives the Image 663 Data Request from the WTP while already in this state, and it 664 detects that the firmware download has completed, or if the 665 underlying LWAPP transport indicates a link failure. Note that 666 the AC itself does not reset, but it places the specific WTPs 667 context it is communicating with in the reset state, meaning 668 that it clears all state associated with the WTP. 669 Configure to Reset (p): This state transition occurs if the Configure 670 phase fails. 671 WTP: The WTP enters this state when the reliable transport fails 672 to deliver the Configure Request, or if the ResponseTimeout 673 Timer (see Section 12)expires. 674 AC: This state transition occurs if the AC is unable to transmit 675 the Configure Response to a specific WTP. Note that the AC 676 itself does not reset, but it places the specific WTPs context 677 it is communicating with in the reset state, meaning that it 678 clears all state associated with the WTP. 679 Configure to Run (q): This state transition occurs when the WTP and 680 AC enters their normal state of operation. 681 WTP: The WTP enters this state when it receives a successful 682 Configure Response from the AC. The WTP initializes the 683 HeartBeat Timer (see Section 12), and transmits the Change 684 State Event Request message (see Section 7.5). 685 AC: This state transition occurs when the AC receives the Change 686 State Event Request (see Section 7.5) from the WTP. The AC 687 responds with a Change State Event Response (see Section 7.6) 688 message. The AC must start the Session ID and Neighbor Dead 689 timers (see Section 12). 690 Run to Run (r): This is the normal state of operation. 691 WTP: This is the WTP's normal state of operation, and there are 692 many events that cause this to occur: 693 Configuration Update: The WTP receives a Configuration Update 694 Request (see Section 7.3). The WTP MUST respond with a 695 Configuration Update Response (see Section 7.4). 697 Change State Event: The WTP receives a Change State Event 698 Response, or determines that it must initiate a Change State 699 Event Request, as a result of a failure or change in the 700 state of a radio. 701 Echo Request: The WTP receives an Echo Request message 702 Section 6.5), which it MUST respond with an Echo Response 703 (see Section 6.6). 704 Clear Config Indication: The WTP receives a Clear Config 705 Indication message Section 7.7). The WTP MUST reset its 706 configuration back to manufacturer defaults. 707 WTP Event: The WTP generates a WTP Event Request to send 708 information to the AC Section 8.5). The WTP receives a WTP 709 Event Response from the AC Section 8.6). 710 Data Transfer: The WTP generates a Data Transfer Request to the 711 AC Section 8.7). The WTP receives a Data Transfer Response 712 from the AC Section 8.8). 713 WLAN Config Request: The WTP receives an WLAN Config Request 714 message Section 11.5.1), which it MUST respond with an WLAN 715 Config Response (see Section 11.5.2). 716 Mobile Config Request: The WTP receives an Mobile Config 717 Request message Section 9.1), which it MUST respond with an 718 Mobile Config Response (see Section 9.2). 719 AC: This is the AC's normal state of operation, and there are many 720 events that cause this to occur: 721 Configuration Update: The AC sends a Configuration Update 722 Request (see Section 7.3) to the WTP to update its 723 configuration. The AC receives a Configuration Update 724 Response (see Section 7.4) from the WTP. 725 Change State Event: The AC receives a Change State Event 726 Request (see Section 7.5), which it MUST respond to with the 727 Change State Event Response (see Section 7.6). 728 Echo: The AC sends an Echo Request message Section 6.5) or 729 receives the associated Echo Response (see Section 6.6) from 730 the WTP. 731 Clear Config Indication: The AC sends a Clear Config Indication 732 message Section 7.7). 733 WLAN Config: The AC sends an WLAN Config Request message 734 Section 11.5.1) or receives the associated WLAN Config 735 Response (see Section 11.5.2) from the WTP. 736 Mobile Config: The AC sends an Mobile Config Request message 737 Section 9.1) or receives the associated Mobile Config 738 Response (see Section 9.2) from the WTP. 739 Data Transfer: The AC receives a Data Transfer Request from the 740 AC (see Section 8.7) and MUST generate the associated Data 741 Transfer Response message (see Section 8.8). 743 WTP Event: The AC receives a WTP Event Request from the AC (see 744 Section 8.5) and MUST generate the associated WTP Event 745 Response message (see Section 8.6). 746 Run to Reset (s): This event occurs when the AC wishes for the WTP to 747 reboot. 748 WTP: The WTP enters this state when it receives a Reset Request 749 (see Section 8.3). It must respond with a Reset Response (see 750 Section 8.4), and once the reliable transport acknowledgement 751 has been received, it must reboot itself. 752 AC: This state transition occurs either through some 753 administrative action, or via some internal event on the AC 754 that causes it to request that the WTP disconnect. Note that 755 the AC itself does not reset, but it places the specific WTPs 756 context it is communicating with in the reset state. 757 Run to Idle (t): This event occurs when an error occurs in the 758 communication between the WTP and the AC. 759 WTP: The WTP enters this state when the underlying reliable 760 transport in unable to transmit a message within the 761 RetransmitInterval timer (see Section 12), and the maximum 762 number of RetransmitCount counter has reached the MaxRetransmit 763 variable (see Section 13). 764 AC: The AC enters this state when the underlying reliable 765 transport in unable to transmit a message within the 766 RetransmitInterval timer (see Section 12), and the maximum 767 number of RetransmitCount counter has reached the MaxRetransmit 768 variable (see Section 13). 769 Run to Key Update (u): This event occurs when the WTP and the AC are 770 to exchange new keying material, with which it must use to protect 771 all future messages. 772 WTP: This state transition occurs when the KeyLifetime timer 773 expires (see Section 12). 774 AC: The WTP enters this state when it receives a Key Update 775 Request (see Section 6.7). It must create new keying material 776 and include it in the Key Update Response (see Section 6.8). 777 Key Update to Run (w): This event occurs when the key exchange phase 778 is completed. 779 WTP: This state transition occurs when the WTP receives the Key 780 Update Response. The WTP must plumb the new keys in its crypto 781 module, allowing it to communicate with the AC using the new 782 key. 783 AC: The AC enters this state when it transmits the Key Update 784 Response message. The key is then plumbed into its crypto 785 module, allowing it to communicate with the WTP using the new 786 key. 787 Key Update to Reset (x): This event occurs when the key exchange 788 phase times out. 790 WTP: This state transition occurs when the WTP does not receive a 791 Key Update Response from the AC. 792 AC: The AC enters this state when it is unable to process a Key 793 Update Request. 794 Reset to Idle (y): This event occurs when the state machine is 795 restarted. 796 WTP: The WTP reboots itself. After reboot the WTP will start its 797 LWAPP state machine in the Idle state. 798 AC: The AC clears out any state associated with the WTP. The AC 799 generally does this as a result of the reliable link layer 800 timing out. 802 3. LWAPP Transport Layers 804 The LWAPP protocol can operate at layer 2 or 3. For layer 2 support, 805 the LWAPP messages are carried in a native Ethernet frame. As such, 806 the protocol is not routable and depends upon layer 2 connectivity 807 between the WTP and the AC. Layer 3 support is provided by 808 encapsulating the LWAPP messages within UDP. 810 3.1 LWAPP Transport Header 812 All LWAPP protocol packets are encapsulated using a common header 813 format, regardless of the transport used to carry the frames. 814 However, certain flags are not applicable for a given transport, and 815 it is therefore necessary to refer to the specific transport section 816 in order to determine which flags are valid. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |VER| RID |C|F|L| Frag ID | Length | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Status/WLANs | Payload... | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 3.1.1 VER Field 828 A 2 bit field which contains the version of LWAPP used in this 829 packet. The value for this draft is 0. 831 3.1.2 RID Field 833 A 3 bit field which contains the Radio ID number for this packet. 834 WTPs with multiple radios but a single MAC Address use this field to 835 indicate which radio is associated with the packet. 837 3.1.3 C Bit 839 The Control Message 'C' bit indicates whether this packet carries a 840 data or control message. When this bit is zero (0), the packet 841 carries an LWAPP data message in the payload (see Section 4.1). When 842 this bit is one (1), the packet carries an LWAPP control message as 843 defined in section Section 4.2 for consumption by the addressed 844 destination. 846 3.1.4 F Bit 848 The Fragment 'F' bit indicates whether this packet is a fragment. 850 When this bit is one (1), the packet is a fragment and MUST be 851 combined with the other corresponding fragments to reassemble the 852 complete information exchanged between the WTP and AC. 854 3.1.5 L Bit 856 The Not Last 'L' bit is valid only if the 'F' bit is set and 857 indicates whether the packet contains the last fragment of a 858 fragmented exchange between WTP and AC. When this bit is 1, the 859 packet is not the last fragment. When this bit is 0, the packet is 860 the last fragment. 862 3.1.6 Fragment ID 864 An 8 bit field whose value is assigned to each group of fragments 865 making up a complete set. The fragment ID space is managed 866 individually for every WTP/AC pair. The value of Fragment ID is 867 incremented with each new set of fragments. The Fragment ID wraps to 868 zero after the maximum value has been used to identify a set of 869 fragments. LWAPP only supports up to 2 fragments per frame. 871 3.1.7 Length 873 The 16 bit length field contains the number of bytes in the Payload. 874 The field is encoded as an unsigned number. If the LWAPP packet is 875 encrypted, the length field includes the AES-CCM MIC (see 876 Section 10.2 for more information). 878 3.1.8 Status and WLANS 880 The interpretation of this 16 bit field is binding specific. Refer 881 to the transport portion of the binding for a wireless technology for 882 the specification. 884 3.1.9 Payload 886 This field contains the header for an LWAPP Data Message or LWAPP 887 Control Message, followed by the data associated with that message. 889 3.2 Using IEEE 802.3 MAC as LWAPP transport 891 This section describes how the LWAPP protocol is provided over native 892 ethernet frames. An LWAPP packet is formed from the MAC frame header 893 followed by the LWAPP message header. The following figure provides 894 an example of the frame formats used when LWAPP is used over the IEEE 895 802.3 transport. 897 Layer 2 LWAPP Data Frame 898 +-----------------------------------------------------------+ 899 | MAC Header | LWAPP Header [C=0] | Forwarded Data ... | 900 +-----------------------------------------------------------+ 902 Layer 2 LWAPP Control Frame 903 +---------------------------------------------------+ 904 | MAC Header | LWAPP Header [C=1] | Control Message | 905 +---------------------------------------------------+ 906 | Message Elements ... | 907 +----------------------+ 909 3.2.1 Framing 911 Source Address 913 A MAC address belonging to the interface from which this message is 914 sent. If multiple source addresses are configured on an interface, 915 then the one chosen is implementation dependent. 917 Destination Address 919 A MAC address belonging to the interface to which this message is to 920 be sent. This destination address MAY be either an individual 921 address or a multicast address, if more than one destination 922 interface is intended. 924 Ethertype 926 The Ethertype field is set to 0x88bb. 928 3.2.2 AC Discovery 930 When run over IEEE 802.3, LWAPP messages are distributed to a 931 specific MAC level broadcast domain. The AC discovery mechanism used 932 with this transport is for an WTP to transmit a Discovery Request 933 message to a broadcast destination MAC address. The ACs will receive 934 this message and reply based on their policy. 936 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC transport 938 All of the fields described in Section 3.1 are used when LWAPP uses 939 the IEEE 802.3 MAC transport. 941 3.2.4 Fragmentation/Reassembly 943 Fragmentation at the MAC layer is managed using the F,L and Frag ID 944 fields of the LWAPP message header. The LWAPP protocol only allows a 945 single packet to be fragmented into 2, which is sufficient for a 946 frame that exceeds MTU due to LWAPP encapsulation. When used with 947 layer 2 (Ethernet) transport, both fragments MUST include the LWAPP 948 header. 950 3.2.5 Multiplexing 952 LWAPP control messages and data messages are distinguished by the C 953 Bit in the LWAPP message header. 955 3.3 Using IPv4/UDP as LWAPP transport 957 This section defines how LWAPP makes use of IPV4/UDP transport 958 between the WTP and the AC. When this transport is used, the MAC 959 layer is controlled by the IPv4 stack, and there are therefore no 960 special MAC layer requirements. The following figure provides an 961 example of the frame formats used when LWAPP is used over the 962 IPv4/UDP transport. 964 Layer 3 LWAPP Data Frame 965 +--------------------------------------------+ 966 | MAC Header | IP | UDP | LWAPP Header [C=0] | 967 +--------------------------------------------+ 968 |Forwarded Data ... | 969 +-------------------+ 971 Layer 3 LWAPP Control Frame 972 +--------------------------------------------+ 973 | MAC Header | IP | UDP | LWAPP Header [C=1] | 974 +--------------------------------------------+ 975 | Control Message | Message Elements ... | 976 +-----------------+----------------------+ 978 3.3.1 Framing 980 Communication between WTP and AC is established according to the 981 standard UDP client/server model. The connection is initiated by the 982 WTP (client) to the well-known UDP port of the AC (server) used for 983 control messages. This UDP port number of the AC is 12222 for LWAPP 984 data and 12223 for LWAPP control frames. 986 3.3.2 AC Discovery 988 When LWAPP is run over routed IPv4 networks, the WTP and the AC do 989 not need to reside in the same IP subnet (broadcast domain). 990 However, in the event the peers reside on separate subnets, there 991 must exist a mechanism for the WTP to discover the AC. 993 As the WTP attempts to establish communication with the AC, it sends 994 the Discovery Request message and receives the corresponding response 995 message from the AC. The WTP must send the Discovery Request message 996 to either the limited broadcast IP address (255.255.255.255), a well 997 known multicast address or to the unicast IP address of the AC. Upon 998 receipt of the message, the AC issues a Discovery Response message to 999 the unicast IP address of the WTP, regardless of whether Discovery 1000 Request was sent as a broadcast, multicast or unicast message. 1002 Whether the WTP uses a limited IP broadcast, multicast or unicast IP 1003 address is implementation dependent. 1005 In order for a WTP to transmit a Discovery Request to a unicast 1006 address, the WTP must first obtain the IP address of the AC. Any 1007 static configuration of an AC's IP address on the WTP non-volatile 1008 storage is implementation dependent. However, additional dynamic 1009 schemes are possible, for example: 1010 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1011 embedded inside a DHCP vendor specific option 43 extension. An 1012 example of the actual format of the vendor specific payload is of 1013 the form "10.1.1.1, 10.1.1.2". 1014 DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to or more AC 1015 addresses 1017 3.3.3 LWAPP Message Header format over IPv4/UDP transport 1019 All of the fields described in Section 3.1 are used when LWAPP uses 1020 the IPv4/UDP transport, with the following exceptions: 1022 3.3.3.1 F Bit 1024 This flag field is not used with this transport, and MUST be set to 1025 zero. 1027 3.3.3.2 L Bit 1029 This flag field is not used with this transport, and MUST be set to 1030 zero. 1032 3.3.3.3 Frag ID 1034 This field is not used with this transport, and MUST be set to zero. 1036 3.3.4 Fragmentation/Reassembly 1038 When LWAPP is implemented at L3, the transport layer uses IP 1039 fragmentation to fragment and reassemble LWAPP messages that are 1040 longer than MTU size used by either WTP or AC. The details of IP 1041 fragmentation are covered in [8]. When used with the IP transport, 1042 only the first fragment would include the LWAPP header 1044 [ed: IP fragmentation may raise security concerns and bring 1045 additional configuration requirements for certain firewalls and NATs. 1046 One alternative is to re-use the layer 2 (application layer) 1047 fragmentation reassembly. Comments are welcomed.] 1049 3.3.5 Multiplexing 1051 LWAPP messages convey control information between WTP and AC, as well 1052 as binding specific data frames or binding specific management 1053 frames. As such, LWAPP messages need to be multiplexed in the 1054 transport sub-layer and be delivered to the proper software entities 1055 in the endpoints of the protocol. However, the 'C' bit is still used 1056 to differentiate between data and control frames. 1058 In case of Layer 3 connection, multiplexing is achieved by use of 1059 different UDP ports for control and data packets (see Section 3.3.1. 1061 As part of Join procedure, the WTP and AC may negotiate different IP 1062 Addresses for data or control messages. The IP Address returned in 1063 the AP Manager Control IP Address message element is used to inform 1064 the WTP with the IP address to which it must sent all control frames. 1065 The AP Manager Data IP Address message element MAY be present only if 1066 the AC has a different IP Address which the WTP is to use to send its 1067 data LWAPP frames. 1069 In the event the WTP and AC are separated by a NAT, with the WTP 1070 using private IP address space, it is the responsibility of the NAT 1071 to manage appropriate UDP port mapping. 1073 4. LWAPP Packet Definitions 1075 This section contains the packet types and format. The LWAPP 1076 protocol is designed to be transport agnostic by specifying packet 1077 formats for both MAC frames and IP packets. An LWAPP packet consists 1078 of an LWAPP Transport Layer packet header followed by an LWAPP 1079 message. 1081 Transport details can be found in Section 3. 1083 4.1 LWAPP Data Messages 1085 An LWAPP data message is a forwarded wireless frame. When forwarding 1086 wireless frames, the sender simply encapsulates the wireless frame in 1087 an LWAPP data packet, using the appropriate transport rules defined 1088 in section Section 3. 1090 In the event that the encapsulated frame would exceed the transport 1091 layer's MTU, the sender is responsible for the fragmentation of the 1092 frame, as specified in the transport specific section of Section 3. 1094 The actual format of the encapsulated LWAPP data frame is subject to 1095 the rules defined under the specific wireless technology binding. 1097 4.2 LWAPP Control Messages Overview 1099 The LWAPP Control protocol provides a control channel between the WTP 1100 and the AC. The control channel is the series of control messages 1101 between the WTP and AC, associated with a session ID and key. 1102 Control messages are divided into the following distinct message 1103 types: 1104 Discovery: LWAPP Discovery messages are used to identify potential 1105 ACs, their load and capabilities. 1106 Control Channel Management: Messages that fall within this 1107 classification are used for the discovery of ACs by the WTPs as 1108 well as the establishment and maintenance of an LWAPP control 1109 channel. 1110 WTP Configuration: The WTP Configuration messages are used by the AC 1111 to push a specific configuration to the WTPs it has a control 1112 channel with. Messages that deal with the retrieval of statistics 1113 from the WTP also fall in this category. 1114 Mobile Session Management: Mobile session management messages are 1115 used by the AC to push specific mobile policies to the WTP. 1116 Firmware Management: Messages in this category are used by the AC to 1117 push a new firmware image down to the WTP. 1119 Control Channel, WTP Configuration and Mobile Session Management MUST 1120 be implemented. Firmware Management MAY be implemented. 1122 In addition, technology specific bindings may introduce new control 1123 channel commands that depart from the above list. 1125 4.2.1 Control Message Format 1127 All LWAPP control messages are sent encapsulated within the LWAPP 1128 header (see Section 3.1). Immediately following the header, is the 1129 LWAPP control header, which has the following format: 1131 0 1 2 3 1132 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 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Message Type | Seq Num | Msg Element Length | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Session ID | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Msg Element [0..N] | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 4.2.1.1 Message Type 1143 The Message Type field identifies the function of the LWAPP control 1144 message. The valid values for Message Type are the following: 1146 Description Value 1147 Discovery Request 1 1148 Discovery Response 2 1149 Join Request 3 1150 Join Response 4 1151 Join ACK 5 1152 Join Confirm 6 1153 Unused 7-9 1154 Configure Request 10 1155 Configure Response 11 1156 Configuration Update Request 12 1157 Configuration Update Response 13 1158 WTP Event Request 14 1159 WTP Event Response 15 1160 Change State Event Request 16 1161 Change State Event Response 17 1162 Unused 18-21 1163 Echo Request 22 1164 Echo Response 23 1165 Image Data Request 24 1166 Image Data Response 25 1167 Reset Request 26 1168 Reset Response 27 1169 Unused 28-29 1170 Key Update Request 30 1171 Key Update Response 31 1172 Primary Discovery Request 32 1173 Primary Discovery Response 33 1174 Data Transfer Request 34 1175 Data Transfer Response 35 1176 Clear Config Indication 36 1177 WLAN Config Request 37 1178 WLAN Config Response 38 1179 Mobile Config Request 39 1180 Mobile Config Response 40 1182 4.2.1.2 Sequence Number 1184 The Sequence Number Field is an identifier value to match 1185 request/response packet exchanges. When an LWAPP packet with a 1186 request message type is received, the value of the sequence number 1187 field is copied into the corresponding response packet. 1189 When an LWAPP control frame is sent, its internal sequence number 1190 counter is monotonically incremented, ensuring that no two requests 1191 pending have the same sequence number. This field will wrap back to 1192 zero. 1194 4.2.1.3 Message Element Length 1196 The Length field indicates the number of bytes following the Session 1197 ID field. If the LWAPP packet is encrypted, the length field 1198 includes the AES-CCM MIC (see Section 10.2 for more information). 1200 4.2.1.4 Session ID 1202 The Session ID is a 32-bit unsigned integer that is used to identify 1203 the security context for encrypted exchanges between the WTP and the 1204 AC. Note that a Session ID is a random value that MUST be unique 1205 between a given AC and any of the WTP it may be communicating with. 1207 4.2.1.5 Message Element[0..N] 1209 The message element(s) carry the information pertinent to each of the 1210 control message types. Every control message in this specification 1211 specifies which message elements are permitted. 1213 4.2.2 Message Element Format 1215 The message element is used to carry information pertinent to a 1216 control message. Every message element is identified by the Type 1217 field, whose numbering space is managed via IANA (see Section 15). 1218 The total length of the message elements is indicated in the Message 1219 Element Length field. 1221 All of the message element definitions in this document use a diagram 1222 similar to the one below in order to depict its format. Note that in 1223 order to simplify this specification, these diagrams do not include 1224 the header fields (Type and Length). However, in every message 1225 element description, the header's fields values will be defined. 1227 Note that additional message elements may be defined in separate IETF 1228 documents. 1230 The format of a message element uses the TLV format shown here: 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | Type | Length | Value ... | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 Where Type (8 bit) identifies the character of the information 1239 carried in the Value field and Length (16 bits) indicates the number 1240 of bytes in the Value field. 1242 4.2.2.1 Generic Message Elements 1244 This section includes message elements that are not bound to a 1245 specific control message. 1247 4.2.2.1.1 Vendor Specific 1249 The Vendor Specific Payload is used to communicate vendor specific 1250 information between the WTP and the AC. The value contains the 1251 following format: 1253 0 1 2 3 1254 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 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Vendor Identifier | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Element ID | Value... | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 Type: 104 for Vendor Specific 1262 Length: >= 7 1263 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 1264 Network Management Private Enterprise Codes" [11] 1265 Element ID: A 16-bit Element Identifier which is managed by the 1266 vendor. 1267 Value: The value associated with the vendor specific element. 1269 5. LWAPP Discovery Operations 1271 The Discovery messages are used by an WTP to determine which ACs are 1272 available to provide service, as well as the capabilities and load of 1273 the ACs. 1275 5.1 Discovery Request 1277 The Discovery Request is used by the WTP to automatically discover 1278 potential ACs available in the network. An WTP must transmit this 1279 command even if it has a statically configured AC, as it is a 1280 required step in the LWAPP state machine. 1282 Discovery Requests MUST be sent by an WTP in the Discover state after 1283 waiting for a random delay less than MaxDiscoveryInterval, after an 1284 WTP first comes up or is (re)initialized. An WTP MUST send no more 1285 than a maximum of MaxDiscoveries discoveries, waiting for a random 1286 delay less than MaxDiscoveryInterval between each successive 1287 discovery. 1289 This is to prevent an explosion of WTP Discoveries. An example of 1290 this occurring would be when many WTPs are powered on at the same 1291 time. 1293 Discovery requests MUST be sent by an WTP when no echo responses are 1294 received for NeighborDeadInterval and the WTP returns to the Idle 1295 state. Discovery requests are sent after NeighborDeadInterval, they 1296 MUST be sent after waiting for a random delay less than 1297 MaxDiscoveryInterval. An WTP MAY send up to a maximum of 1298 MaxDiscoveries discoveries, waiting for a random delay less than 1299 MaxDiscoveryInterval between each successive discovery. 1301 If a discovery response is not received after sending the maximum 1302 number of discovery requests, the WTP enters the Sulking state and 1303 MUST wait for an interval equal to SilentInterval before sending 1304 further discovery requests. 1306 The Discovery Request message may be sent as a unicast, broadcast or 1307 multicast message. 1309 Upon receiving a discovery request, the AC will respond with a 1310 Discovery Response sent to the address in the source address of the 1311 received discovery request. 1313 The following subsections define the message elements that MUST be 1314 included in this LWAPP operation. 1316 5.1.1 Discovery Type 1318 The Discovery message element is used to configure an WTP to operate 1319 in a specific mode. 1321 0 1322 0 1 2 3 4 5 6 7 1323 +-+-+-+-+-+-+-+-+ 1324 | Discovery Type| 1325 +-+-+-+-+-+-+-+-+ 1327 Type: 58 for Discovery Type 1328 Length: 1 1329 Discovery Type: An 8-bit value indicating how the AC was discovered. 1330 The following values are supported: 1331 0 - Broadcast 1332 1 - Configured 1334 5.1.2 WTP Descriptor 1336 The WTP descriptor message element is used by the WTP to communicate 1337 it's current hardware/firmware configuration. The value contains the 1338 following fields. 1340 0 1 2 3 1341 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 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Hardware Version | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Software Version | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Boot Version | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | Max Radios | Radios in use | Encryption Capabilities | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 Type: 3 for WTP Descriptor 1353 Length: 16 1354 Hardware Version: A 32-bit integer representing the WTP's hardware 1355 version number 1356 Software Version: A 32-bit integer representing the WTP's Firmware 1357 version number 1358 Boot Version: A 32-bit integer representing the WTP's boot loader's 1359 version number 1360 Max Radios: An 8-bit value representing the number of radios (where 1361 each radio is identified via the RID field) supported by the WTP 1363 Radios in use: An 8-bit value representing the number of radios 1364 present in the WTP 1365 Encryption Capabilities: This 16-bit field is used by the WTP to 1366 communicate it's capabilities to the AC. Since most WTPs support 1367 link layer encryption, the AC may make use of these services. 1368 There are binding dependent encryption capabilites. An WTP that 1369 does not have any encryption capabilities would set this field to 1370 zero (0). Refer to the specific binding for the specification. 1372 5.1.3 WTP Radio Information 1374 The WTP radios information message element is used to communicate the 1375 radio information in a specific slot. The Discovery Request MUST 1376 include one such message element per radio in the WTP. The 1377 Radio-Type field is used by the AC in order to determine which 1378 technology specific binding is to be used with the WTP. 1380 The value contains two fields, as shown. 1382 0 1 1383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Radio ID | Radio Type | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 Type: 4 for WTP Radio Information 1389 Length: 2 1390 Radio ID: The Radio Identifier, typically refers to some interface 1391 index on the WTP 1392 Radio Type: The type of radio present. The following values are 1393 supported 1394 1 - 802.11bg: An 802.11bg radio. 1395 2 - 802.11a: An 802.11a radio. 1396 3 - 802.16: An 802.16 radio. 1397 4 - Ultra Wideband: An UWB radio. 1398 7 - all: Used to specify all radios in the WTP. 1400 5.2 Discovery Response 1402 The Discovery Response is a mechanism by which an AC advertises its 1403 services to requesting WTPs. 1405 Discovery Responses are sent by an AC after receiving a Discovery 1406 Request. 1408 When an WTP receives a Discovery Response, it MUST wait for an 1409 interval not less than DiscoveryInterval for receipt of additional 1410 Discovery Responses. After the DiscoveryInterval elapses, the WTP 1411 enters the Joining state and will select one of the ACs that sent a 1412 Discovery Response and send a Join Request to that AC. 1414 The following subsections define the message elements that MUST be 1415 included in this LWAPP operation. 1417 5.2.1 AC Address 1419 The AC address message element is used to communicate the identity of 1420 the AC. The value contains two fields, as shown. 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Reserved | MAC Address | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | MAC Address | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 Type: 2 for AC Address 1431 Length: 7 1432 Reserved: MUST be set to zero 1433 Mac Address: The MAC Address of the AC 1435 5.2.2 AC Descriptor 1437 The AC payload message element is used by the AC to communicate it's 1438 current state. The value contains the following fields. 1440 0 1 2 3 1441 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 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | Reserved | Hardware Version ... | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | HW Ver | Software Version ... | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | SW Ver | Stations | Limit | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Limit | Radios | Max Radio | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Max Radio | Security | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Type: 6 for AC Descriptor 1455 Length: 17 1456 Reserved: MUST be set to zero 1457 Hardware Version: A 32-bit integer representing the AC's hardware 1458 version number 1459 Software Version: A 32-bit integer representing the AC's Firmware 1460 version number 1461 Stations: A 16-bit integer representing number of mobile stations 1462 currently associated with the AC 1463 Limit: A 16-bit integer representing the maximum number of stations 1464 supported by the AC 1465 Radios: A 16-bit integer representing the number of WTPs currently 1466 attached to the AC 1467 Max Radio: A 16-bit integer representing the maximum number of WTPs 1468 supported by the AC 1469 Security: A 8 bit bit mask specifying the security schemes supported 1470 by the AC. The following values are supported: 1471 1 - X.509 Certificate Based (Section 10.3.1) 1472 2 - Pre-Shared Secret (Section 10.3.2) 1474 5.2.3 AC Name 1476 The AC name message element contains an ASCII representation of the 1477 AC's identity. The value is a variable length byte string. The 1478 string is NOT zero terminated. 1480 0 1481 0 1 2 3 4 5 6 7 1482 +-+-+-+-+-+-+-+-+ 1483 | Name ... 1484 +-+-+-+-+-+-+-+-+ 1486 Type: 31 for AC Name 1487 Length: > 0 1488 Name: A variable length ASCII string containing the AC's name 1490 5.2.4 WTP Manager Control IP Address 1492 The WTP Manager Control IP Address message element is sent by the AC 1493 to the WTP during the discovery process and is used by the AC to 1494 provide the interfaces available on the AC, and their current load. 1495 This message elemenet is useful for the WTP to perform load balancing 1496 across multiple interfaces. 1498 0 1 2 3 1499 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 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | IP Address | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | WTP Count | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 Type: 99 for WTP Manager Control IP Address 1507 Length: 6 1508 IP Address: The IP Address of an interface. 1509 WTP Count: The number of WTPs currently connected to the interface. 1511 5.3 Primary Discovery Request 1513 The Primary Discovery Request is sent by the WTP in order to 1514 determine whether its preferred (or primary) AC is available. 1516 Primary Discovery Request are sent by an WTP when it has a primary AC 1517 configured, and is connected to another AC. This generally occurs as 1518 a result of a failover, and is used by the WTP as a means to discover 1519 when its primary AC becomes available. As a consequence, this 1520 message is only sent by a WTP when it is in the Run state. 1522 The frequency of the Primary Discovery Requests should be no more 1523 often than the sending of the Echo Request message. 1525 Upon receiving a discovery request, the AC will respond with a 1526 Primary Discovery Response sent to the address in the source address 1527 of the received Primary Discovery Request. 1529 The following subsections define the message elements that MUST be 1530 included in this LWAPP operation. 1532 5.3.1 Discovery Type 1534 The Discovery Type message element is defined in section 1535 Section 5.1.1. 1537 5.3.2 WTP Descriptor 1539 The WTP Descriptor message element is defined in section 1540 Section 5.1.2. 1542 5.3.3 WTP Radio Information 1544 An WTP Radio Information message element must be present for every 1545 radio in the WTP. This message element is defined in section 1546 Section 5.1.3. 1548 5.4 Primary Discovery Response 1550 The Primary Discovery Response is a mechanism by which an AC 1551 advertises its availability and services to requesting WTPs that are 1552 configured to have the AC as its primary AC. 1554 Primary Discovery Responses are sent by an AC after receiving a 1555 Primary Discovery Request. 1557 When an WTP receives a Primary Discovery Response, it may opt to 1558 establish an LWAPP connection to its primary AC, based on the 1559 configuration of the WTP Fallback Status message element on the WTP. 1561 The following subsections define the message elements that MUST be 1562 included in this LWAPP operation. 1564 5.4.1 AC Descriptor 1566 The Discovery Type message element is defined in section 1567 Section 5.2.2. 1569 5.4.2 AC Name 1571 The AC Name message element is defined in section Section 5.2.3. 1573 5.4.3 WTP Manager Control IP Address 1575 An WTP Radio Information message element must be present for every 1576 radio in the WTP. This message element is defined in section 1577 Section 5.2.4. 1579 6. Control Channel Management 1581 The Control Channel Management messages are used by the WTP and AC to 1582 create and maintain a channel of communication on which various other 1583 commands may be transmitted, such as configuration, firmware update, 1584 etc. 1586 6.1 Join Request 1588 The Join Request is used by an WTP to inform an AC that it wishes to 1589 provide services through it. 1591 Join Requests are sent by an WTP in the Joining state after receiving 1592 one or more Discovery Responses. The Join Request is also used as an 1593 MTU discovery mechanism by the WTP. The WTP issues a Join Request 1594 with a Test message element, bringing the total size of the message 1595 to exceed MTU. 1597 If the transport used does not provide MTU path discovery, the 1598 initial Join Request is padded with the Test message element to 1596 1599 bytes. If a Join Response is received, the WTP can forward frames 1600 without requiring any fragmentation. If no Join Response is 1601 received, it issues a second Join Request padded with the Test 1602 payload to a total of 1500 bytes. The WTP continues to cycle from 1603 large (1596) to small (1500) packets until a Join Response has been 1604 received , or until both packets sizes have been retransmitted 3 1605 times . If the Join Response is not received after the maximum 1606 number of retransmissions, the WTP MUST abandon the AC and restart 1607 the discovery phase. 1609 When an AC receives a Join Request it will respond with a Join 1610 Response. If the certificate based security mechanism is used, the 1611 AC validates the certificate found in the request. If valid, the AC 1612 generates a session key which will be used to secure the control 1613 frames it exchanges with the WTP. When the AC issues the Join 1614 Response, the AC creates a context for the session with the WTP. 1616 If the pre-shared session key security mechanism is used, the AC 1617 saves the WTP's nonce, found in the WNonce message element, creates 1618 its own nonce which it includes in the ANonce message element. 1619 Finally, the AC creates the PSK-MIC, which is computed using a key 1620 that is derived from the PSK. 1622 A Join Request that includes both a WNonce and a Certificate message 1623 element MUST be considered invalid. 1625 Details on the key generation is found in Section 10. 1627 The following subsections define the message elements that MUST be 1628 included in this LWAPP operation. 1630 6.1.1 WTP Descriptor 1632 The WTP Descriptor message element is defined in section 1633 Section 5.1.2. 1635 6.1.2 AC Address 1637 The AC Address message element is defined in section Section 5.2.1. 1639 6.1.3 WTP Name 1641 The WTP name message element value is a variable length byte string. 1642 The string is NOT zero terminated. 1644 0 1645 0 1 2 3 4 5 6 7 1646 +-+-+-+-+-+-+-+-+ 1647 | Name ... 1648 +-+-+-+-+-+-+-+-+ 1650 Type: 5 for WTP Name 1651 Length: > 0 1652 Name: A non zero terminated string containing the WTP's name. 1654 6.1.4 Location Data 1656 The location data message element is a variable length byte string 1657 containing user defined location information (e.g. "Next to 1658 Fridge"). The string is NOT zero terminated. 1660 0 1661 0 1 2 3 4 5 6 7 1662 +-+-+-+-+-+-+-+-+ 1663 | Location ... 1664 +-+-+-+-+-+-+-+-+ 1666 Type: 35 for Location Data 1667 Length: > 0 1668 Location: A non zero terminated string containing the WTP's 1669 location. 1671 6.1.5 WTP Radio Information 1673 An WTP Radio Information message element must be present for every 1674 radio in the WTP. This message element is defined in section 1675 Section 5.1.3. 1677 6.1.6 Certificate 1679 The certificate message element value is a byte string containing a 1680 DER-encoded x.509v3 certificate. This message element is only 1681 included if the LWAPP security type used between the WTP and the AC 1682 makes use of certificates (see Section 10 for more information). 1684 0 1685 0 1 2 3 4 5 6 7 1686 +-+-+-+-+-+-+-+-+ 1687 | Certificate... 1688 +-+-+-+-+-+-+-+-+ 1690 Type: 44 for Certificate 1691 Length: > 0 1692 Certificate: A non zero terminated string containing the device's 1693 certificate. 1695 6.1.7 Session ID 1697 The session ID message element value contains a randomly generated 1698 [4] unsigned 32-bit integer. 1700 0 1 2 3 1701 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 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | Session ID | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 Type: 45 for Session ID 1707 Length: 4 1708 Session ID: 32 bit random session identifier. 1710 6.1.8 Test 1712 The test message element is used as padding to perform MTU discovery, 1713 and MAY contain any value, of any length. 1715 0 1716 0 1 2 3 4 5 6 7 1717 +-+-+-+-+-+-+-+-+ 1718 | Padding ... 1719 +-+-+-+-+-+-+-+-+ 1721 Type: 18 for Test 1722 Length: > 0 1723 Padding: A variable length pad. 1725 6.1.9 WNonce 1727 The wnonce message element is sent by a WTP that is configured to 1728 make use of the pre-shared key security mechanism. See 1729 Section 10.3.2 for more information. 1731 0 1 2 3 1732 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 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Nonce | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Nonce | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Nonce | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Nonce | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 Type: 107 for WNonce 1744 Length: 16 1745 Nonce: A 16 octet random nonce. 1747 6.1.10 DH-Params 1749 The DH-Params message element is used in order for the WTP and the AC 1750 to perform a Diffie Hellman exchange. This message element contains 1751 the g, p, g^x mod p - where x is the exponent chosen by the sender. 1752 See Section 10.3.2 for more information. 1754 0 1 2 3 1755 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 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | Nonce | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | Nonce | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | Nonce | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | Nonce | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 Type: 111 for DH-Params 1767 Length: 16 1768 Nonce: Contains g, p, g^x mod p, where 'x' is the exponent chosen by 1769 the sender. 1771 6.2 Join Response 1773 The Join Response is sent by the AC to indicate to an WTP whether it 1774 is capable and willing to provide service to it. 1776 Join Responses are sent by the AC after receiving a Join Request. 1777 Once the Join Response has been sent, the heartbeat timer is 1778 initiated for the session to EchoInterval. Expiration of the timer 1779 will result in deletion of the AC-WTP session. The timer is 1780 refreshed upon receipt of the Echo Request. 1782 If the security method used is certificate based, when a WTP receives 1783 a Join Response it enters the Joined state and initiates either a 1784 Configure Request or Image Data to the AC to which it is now joined. 1785 Upon entering the Joined state, the WTP begins timing an interval 1786 equal to NeighborDeadInterval. Expiration of the timer will result 1787 in the transmission of the Echo Request. 1789 If the security method used is pre-shared secret based, when a WTP 1790 receives a Join Response that includes a valid PSK-MIC message 1791 element, it responds with a Join ACK that also MUST include a locally 1792 computed PSK-MIC message element. 1794 The following subsections define the message elements that MUST be 1795 included in this LWAPP operation. 1797 6.2.1 Result Code 1799 The Result Code message element value is a 32-bit integer value, 1800 indicating the result of the request operation corresponding to the 1801 sequence number in the message. The Result Code is included in a 1802 successful Join Response. 1804 0 1 2 3 1805 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 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Result Code | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 Type: 2 for Result Code 1811 Length: 4 1812 Result Code: The following values are defined: 1813 0 Success 1814 1 Failure (AC List message element MUST be present) 1816 6.2.2 Status 1818 The Status message element is sent by the AC to the WTP in a 1819 non-successful Join Response message. This message element is used 1820 to indicate the reason for the failure and should only be accompanied 1821 with a Result Code message element that indicates a failure. 1823 0 1824 0 1 2 3 4 5 6 7 1825 +-+-+-+-+-+-+-+-+ 1826 | Status | 1827 +-+-+-+-+-+-+-+-+ 1829 Type: 60 for Status 1830 Length: 1 1831 Status: The status field indicates the reason for an LWAPP failure. 1832 The following values are supported: 1833 1 - Reserved - do not use 1834 2 - Resource Depletion 1835 3 - Unknown Source 1836 4 - Incorrect Data 1838 6.2.3 Certificate 1840 The Certificate message element is defined in section Section 6.1.6. 1841 Note this message element is only included if the WTP and the AC make 1842 use of certificate based security as defined in section Section 10. 1844 6.2.4 Session Key 1846 The Session Key message element is sent by the AC to the WTP and 1847 includes the randomly generated session key, which is used to protect 1848 the LWAPP control messages. More details are available in 1849 Section 10. The value contains the following fields. 1851 0 1 2 3 1852 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 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 | Security | Session Key .... 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 Type: 46 for Session Key 1858 Length: > 1 1859 Security: The LWAPP security model used. The following values are 1860 supported: 1861 0 - Unused 1862 1 - X.509 Certificate Based (Section 10.3.1) 1863 2 - Pre-Shared Secret (Section 10.3.2) 1864 Session Key: An Encrypted Session Key. The encryption procedures 1865 used for this field depends upon the security model used, which 1866 are defined in section Section 10. 1868 6.2.5 WTP Manager Data IP Address 1870 The WTP Manager Data IP Address message element is optionally sent by 1871 the AC to the WTP during the join phase. If present, the IP Address 1872 contained in this message element is the address the WTP is to use 1873 when sending any of its LWAPP data frames. 1875 Note this message element is only valid when LWAPP uses the IP/UDP 1876 layer 3 transport 1878 0 1 2 3 1879 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 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | IP Address | 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 Type: TBD for WTP Manager Data IP Address 1885 Length: 4 1886 IP Address: The IP Address of an interface. 1888 6.2.6 AC List 1890 The AC List message element is used to configure an WTP with the 1891 latest list of ACs in a cluster. This message element MUST be 1892 included if the Join Response returns a failure indicating that the 1893 AC cannot handle the WTP at this time, allowing the WTP to find an 1894 alternate AC to connect to. 1896 0 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | AC IP Address[] | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 Type: 59 for AC List 1903 Length: >= 4 1904 AC IP Address: An array of 32-bit integers containing an AC's IP 1905 Address. 1907 6.2.7 ANonce 1909 The anonce message element is sent by a AC that is configured to make 1910 use of the pre-shared key security method. See Section 10.3.2 for 1911 more information. 1913 0 1 2 3 1914 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 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Nonce | 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Nonce | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Nonce | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Nonce | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 Type: 108 for Test 1926 Length: 16 1927 Nonce: A 16 octet random nonce. 1929 6.2.8 PSK-MIC 1931 The PSK-MIC message element includes a message integrity check, whose 1932 purpose is to provide confirmation to the peer that the sender has 1933 the proper session key. This message element is only included if the 1934 security method used between the WTP and the AC is the pre-shared 1935 secret mechanism. See Section 10.3.2 for more information. 1937 When present, the PSK-MIC message element MUST be the last message 1938 element in the message. The MIC is computed over the complete LWAPP 1939 packet, from the LWAPP control header as defined in Section 4.2.1 to 1940 the end of the packet (which MUST be this PSK-MIC message element). 1941 The MIC field in this message element and the sequence number field 1942 in the LWAPP control header MUST be set to zeroes prior to computing 1943 the MIC. The length field in the LWAPP control header must already 1944 include this message element prior to computing the MIC. 1946 0 1 2 3 1947 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 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | SPI | MIC ... 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 Type: 109 for PSK-MIC 1954 Length: > 1 1955 SPI: The SPI field specifies the cryptographic algorithm used to 1956 create the message integrity check. The following values are 1957 supported: 1958 0 - Unused 1959 1 - HMAC-SHA-1 (RFC 2104 [14]) 1960 MIC: A 20 octet Message Integrity Check. 1962 6.2.9 DH-Params 1964 The Certificate message element is defined in section Section 6.1.10. 1965 Note this message element is only included if the WTP and the AC make 1966 use of pre-shared key based security as defined in section 1967 Section 10.3.2. 1969 6.3 Join ACK 1971 The Join ACK message is sent by the WTP upon receiving a Join 1972 Response, which has a valid PSK-MIC message element, as a means of 1973 providing key confirmation to the AC. The Join ACK is only used in 1974 the case where the WTP makes use of the pre-shared key LWAPP mode 1975 (See Section 10.3.2 for more information). 1977 Note that the AC should never receive this message unless the 1978 security method used between the WTP and the AC is pre-shared secret 1979 based. 1981 The following subsections define the message elements that MUST be 1982 included in this LWAPP operation. 1984 6.3.1 Session ID 1986 The Session ID message element is defined in section Section 6.1.7. 1988 6.3.2 WNonce 1990 The WNonce message element is defined in section Section 6.1.9. 1992 6.3.3 PSK-MIC 1994 The PSK-MIC message element is defined in section Section 6.2.8. 1996 6.4 Join Confirm 1998 The Join Confirm message is sent by the AC upon receiving a Join ACK, 1999 which has a valid PSK-MIC message element, as a means of providing 2000 key confirmation to the WTP. The Join Confirm is only used in the 2001 case where the WTP makes use of the pre-shared key LWAPP mode (See 2002 Section 10.3.2 for more information). 2004 If the security method used is pre-shared key based, when an WTP 2005 receives a Join Confirm it enters the Joined state and initiates 2006 either a Configure Request or Image Data to the AC to which it is now 2007 joined. Upon entering the Joined state, the WTP begins timing an 2008 interval equal to NeighborDeadInterval. Expiration of the timer will 2009 result in the transmission of the Echo Request. 2011 This message is never received, or sent, when the security type used 2012 between the WTP and the AC is certificated based. 2014 The following subsections define the message elements that MUST be 2015 included in this LWAPP operation. 2017 6.4.1 Session ID 2019 The Session ID message element is defined in section Section 6.1.7. 2021 6.4.2 ANonce 2023 The ANonce message element is defined in section Section 6.2.7. 2025 6.4.3 PSK-MIC 2027 The PSK-MIC message element is defined in section Section 6.2.8. 2029 6.5 Echo Request 2031 The Echo Request message is a keepalive mechanism for the LWAPP 2032 control message. 2034 Echo Requests are sent periodically by an WTP in the Run state (see 2035 Figure 2) to determine the state of the connection between the WTP 2036 and the AC. The Echo Request is sent by the WTP when the Heartbeat 2037 timer expires, and it MUST start its NeighborDeadInterval timer. 2039 The Echo Request carries no message elements. 2041 When an AC receives an Echo Request it responds with an Echo 2042 Response. 2044 6.6 Echo Response 2046 The Echo Response acknowledges the Echo Request, and are only 2047 accepted while in the Run state (see Figure 2). 2049 Echo Responses are sent by an AC after receiving an Echo Request. 2050 After transmitting the Echo Response, the AC should reset its 2051 Heartbeat timer to expire in the value configured for EchoInterval. 2052 If another Echo request is not received by the AC when the timer 2053 expires, the AC SHOULD consider the WTP to no longer be reachable. 2055 The Echo Response carries no message elements. 2057 When an WTP receives an Echo Response it stops the 2058 NeighborDeadInterval timer, and starts the Heartbeat timer to 2059 EchoInterval. 2061 If the NeighborDeadInterval timer expires prior to receiving an Echo 2062 Response, the WTP enters the Idle state. 2064 6.7 Key Update Request 2066 The Key Update Request updates the LWAPP session key used to secure 2067 messages between the WTP and the AC. 2069 Key Update Requests are sent by an WTP in the Run state to update a 2070 session key. The Session ID message element MUST include a new 2071 session identifier. 2073 When an AC receives a Key Update Request it generates a new key (see 2074 Section 10) and responds with a Key Update Response. 2076 The following subsections define the message elements that MUST be 2077 included in this LWAPP operation. 2079 6.7.1 Session ID 2081 The Session ID message element is defined in section Section 6.1.7. 2083 6.8 Key Update Response 2085 The Key Update Response updates the LWAPP session key used to secure 2086 messages between the WTP and the AC, and acknowledges the Key Update 2087 Request. 2089 Key Update Responses are sent by a AC after receiving a Key Update 2090 Request. The Key Update Responses is secured using public key 2091 cryptography when certificates were used in the Join Request/Response 2092 exchange. However, the session keys are AES Key-wrapped when the AC 2093 and WTP invoked PSK-mode to establish the first session key. 2095 When an WTP receives a Key Update Response it will use the 2096 information contained in the Session Key message element to determine 2097 the keying material used to encrypt the LWAPP communications between 2098 the WTP and the AC. 2100 The following subsections define the message elements that MUST be 2101 included in this LWAPP operation. 2103 6.8.1 Session Key 2105 The Session Key message element is defined in section Section 6.2.4. 2107 6.9 Key Update Trigger 2109 The Key Update Trigger is used by the AC to request that a Key Update 2110 Request be initiated by the WTP. 2112 Key Update Trigger are sent by an AC in the Run state to inform the 2113 WTP to initiate a Key Update Request message. 2115 When a WTP receives a Key Update Trigger it generates a key Update 2116 Request. 2118 The following subsections define the message elements that MUST be 2119 included in this LWAPP operation. 2121 6.9.1 Session ID 2123 The Session ID message element is defined in section Section 6.1.7. 2125 7. WTP Configuration Management 2127 The Wireless Termination Point Configuration messages are used to 2128 exchange configuration between the AC and the WTP. 2130 7.1 Configure Request 2132 The Configure Request message is sent by an WTP to send its current 2133 configuration to its AC. 2135 Configure Requests are sent by an WTP after receiving a Join 2136 Response, while in the Configure state. 2138 The Configure Request carries binding specific message elements. 2139 Refer to the appropriate binding for the definition of this 2140 structure. 2142 When an AC receives a Configure Request it will act upon the content 2143 of the packet and respond to the WTP with a Configure Response. 2145 The Configure Request includes multiple Administrative State message 2146 Elements. There is one such message element for the WTP, and then 2147 one per radio in the WTP. 2149 The following subsections define the message elements that MUST be 2150 included in this LWAPP operation. 2152 7.1.1 Administrative State 2154 The administrative event message element is used to communicate the 2155 state of a particular radio. The value contains the following 2156 fields. 2158 0 1 2159 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 | Radio ID | Admin State | 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 Type: 27 for Administrative State 2165 Length: 2 2166 Radio ID: An 8-bit value representing the radio to configure. The 2167 Radio ID field may also include the value of 0xff, which is used 2168 to identify the WTP itself. Therefore, if an AC wishes to change 2169 the administrative state of an WTP, it would include 0xff in the 2170 Radio ID field. 2172 Admin State: An 8-bit value representing the administrative state of 2173 the radio. The following values are supported: 2174 1 - Enabled 2175 2 - Disabled 2177 7.1.2 AC Name 2179 The AC Name message element is defined in section Section 5.2.3. 2181 7.1.3 AC Name with Index 2183 The AC Name with Index message element is sent by the AC to the WTP 2184 to configure preferred ACs. The number of instances where this 2185 message element would be present is equal to the number of ACs 2186 configured on the WTP. 2188 0 1 2189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Index | AC Name... 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 Type: 90 for AC Name with Index 2195 Length: 5 2196 Index: The index of the preferred server (e.g., 1=primary, 2197 2=secondary). 2198 AC Name: A variable length ASCII string containing the AC's name. 2200 7.1.4 WTP Board Data 2202 The WTP Board Data message element is sent by the WTP to the AC and 2203 contains information about the hardware present. 2205 0 1 2 3 2206 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 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | Card ID | Card Revision | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | WTP Model | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | WTP Model | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | WTP Serial Number ... | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | Reserved | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | Ethernet MAC Address | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | Ethernet MAC Address | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 Type: 50 for WTP Board Data 2224 Length: 26 2225 Card ID: A hardware identifier. 2226 Card Revision: 4 byte Revision of the card. 2227 WTP Model: 8 byte WTP Model Number. 2228 WTP Serial Number: 24 byte WTP Serial Number. 2229 Reserved: A 4 byte reserved field that MUST be set to zero (0). 2230 Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. 2232 7.1.5 Statistics Timer 2234 The statistics timer message element value is used by the AC to 2235 inform the WTP of the frequency which it expects to receive updated 2236 statistics. 2238 0 1 2239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Statistics Timer | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 Type: 37 for Statistics Timer 2245 Length: 2 2246 Statistics Timer: A 16-bit unsigned integer indicating the time, in 2247 seconds 2249 7.1.6 WTP Static IP Address Information 2251 The WTP Static IP Address Information message element is used by an 2252 AC to configure or clear a previously configured static IP address on 2253 an WTP. 2255 0 1 2 3 2256 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 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | IP Address | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | Netmask | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Gateway | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 | Static | 2265 +-+-+-+-+-+-+-+-+ 2267 Type: 82 for WTP Static IP Address Information 2268 Length: 13 2269 IP Address: The IP Address to assign to the WTP. 2270 Netmask: The IP Netmask. 2271 Gateway: The IP address of the gateway. 2272 Netmask: The IP Netmask. 2273 Static: An 8-bit boolean stating whether the WTP should use a static 2274 IP address or not. A value of zero disables the static IP 2275 address, while a value of one enables it. 2277 7.1.7 WTP Reboot Statistics 2279 The WTP Reboot Statistics message element is sent by the WTP to the 2280 AC to communicate information about reasons why reboots have 2281 occurred. 2283 0 1 2 3 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Crash Count | LWAPP Initiated Count | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | Link Failure Count | Failure Type | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 Type: 67 for WTP Reboot Statistics 2292 Length: 7 2293 Crash Count: The number of reboots that have occurred due to an WTP 2294 crash. 2295 LWAPP Initiated Count: The number of reboots that have occured at 2296 the request of some LWAPP message, such as a change in 2297 configuration that required a reboot or an explicit LWAPP reset 2298 request. 2299 Link Failure Count: The number of times that an LWAPP connection 2300 with an AC has failed. 2301 Failure Type: The last WTP failure. The following values are 2302 supported: 2303 0 - Link Failure 2304 1 - LWAPP Initiated 2305 2 - WTP Crash 2307 7.2 Configure Response 2309 The Configure Response message is sent by an AC and provides an 2310 opportunity for the AC to override an WTP's requested configuration. 2312 Configure Responses are sent by an AC after receiving a Configure 2313 Request. 2315 The Configure Response carries binding specific message elements. 2316 Refer to the appropriate binding for the definition of this 2317 structure. 2319 When an WTP receives a Configure Response it acts upon the content of 2320 the packet, as appropriate. If the Configure Response message 2321 includes a Change State Event message element that causes a change in 2322 the operational state of one of the Radio, the WTP will transmit a 2323 Change State Event to the AC, as an acknowledgement of the change in 2324 state. 2326 The following subsections define the message elements that MUST be 2327 included in this LWAPP operation. 2329 7.2.1 Decryption Error Report Period 2331 The Decryption Error Report Period message element value is used by 2332 the AC to inform the WTP how frequently it should send decryption 2333 error report messages. 2335 0 1 2 2336 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Radio ID | Report Interval | 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 Type: 38 for Decryption Error Report Period 2342 Length: 3 2343 Radio ID: The Radio Identifier, typically refers to some interface 2344 index on the WTP 2345 Report Interval: A 16-bit unsigned integer indicating the time, in 2346 seconds 2348 7.2.2 Change State Event 2350 The WTP radios information message element is used to communicate the 2351 operational state of a radio. The value contains two fields, as 2352 shown. 2354 0 1 2355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 | Radio ID | State | Cause | 2358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 Type: 26 for Change State Event 2361 Length: 3 2362 Radio ID: The Radio Identifier, typically refers to some interface 2363 index on the WTP. 2364 State: An 8-bit boolean value representing the state of the radio. 2365 A value of one disables the radio, while a value of two enables 2366 it. 2367 Cause: In the event of a radio being inoperable, the cause field 2368 would contain the reason the radio is out of service. 2369 Cause: In the event of a radio being inoperable, the cause field 2370 would contain the reason the radio is out of service. The 2371 following values are supported: 2372 0 - Normal 2373 1 - Radio Failure 2374 2 - Software Failure 2376 7.2.3 LWAPP Timers 2378 The LWAPP Timers message element is used by an AC to configure LWAPP 2379 timers on an WTP. 2381 0 1 2382 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Discovery | Echo Request | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 Type: 68 for LWAPP Timers 2388 Length: 2 2389 Discovery: The number of seconds between LWAPP Discovery packets, 2390 when the WTP is in the discovery mode. 2391 Echo Request: The number of seconds between WTP Echo Request LWAPP 2392 messages. 2394 7.2.4 AC List 2396 The AC List message element is defined in section Section 6.2.6. 2398 7.2.5 WTP Fallback 2400 The WTP Fallback message element is sent by the AC to the WTP to 2401 enable or disable automatic LWAPP fallback in the event that an WTP 2402 detects its preferred AC, and is not currently connected to it. 2404 0 2405 0 1 2 3 4 5 6 7 2406 +-+-+-+-+-+-+-+-+ 2407 | Mode | 2408 +-+-+-+-+-+-+-+-+ 2410 Type: 91 for WTP Fallback 2411 Length: 1 2412 Mode: The 8-bit boolean value indicates the status of automatic 2413 LWAPP fallback on the WTP. A value of zero disables the fallback 2414 feature, while a value of one enables it. When enabled, if the 2415 WTP detects that its primary AC is available, and it is not 2416 connected to it, it SHOULD automatically disconnect from its 2417 current AC and reconnect to its primary. If disabled, the WTP 2418 will only reconnect to its primary through manual intervention 2419 (e.g., through the Reset Request command). 2421 7.2.6 Idle Timeout 2423 The Idle Timeout message element is sent by the AC to the WTP to 2424 provide it with the idle timeout that it should enforce on its active 2425 mobile station entries. 2427 0 1 2 3 2428 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 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Timeout | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 Type: 97 for Idle Timeout 2434 Length: 4 2435 Timeout: The current idle timeout to be enforced by the WTP. 2437 7.3 Configuration Update Request 2439 Configure Update Requests are sent by the AC to provision the WTP 2440 while in the Run state. This is used to modify the configuration of 2441 the WTP while it is operational. 2443 When an AC receives a Configuration Update Request it will respond 2444 with a Configuration Update Response, with the appropriate Result 2445 Code. 2447 The following subsections define the message elements introduced by 2448 this LWAPP operation. 2450 7.3.1 WTP Name 2452 The WTP Name message element is defined in section Section 6.1.3. 2454 7.3.2 Change State Event 2456 The Change State Event message element is defined in section 2457 Section 7.2.2. 2459 7.3.3 Administrative State 2461 The Administrative State message element is defined in section 2462 Section 7.1.1. 2464 7.3.4 Statistics Timer 2466 The Statistics Timer message element is defined in section 2467 Section 7.1.5. 2469 7.3.5 Location Data 2471 The Location Data message element is defined in section 2472 Section 6.1.4. 2474 7.3.6 Decryption Error Report Period 2476 The Decryption Error Report Period message element is defined in 2477 section Section 7.2.1. 2479 7.3.7 AC List 2481 The AC List message element is defined in section Section 6.2.6. 2483 7.3.8 Add Blacklist Entry 2485 The Add Blacklist Entry message element is used by an AC to add a 2486 blacklist entry on an WTP, ensuring that the WTP no longer provides 2487 any service to the MAC addresses provided in the message. The MAC 2488 Addresses provided in this message element are not expected to be 2489 saved in non-volative memory on the WTP. 2491 0 1 2 3 2492 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 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Num of Entries| MAC Address[] | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | MAC Address[] | 2497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2499 Type: 65 for Add Blacklist Entry 2500 Length: >= 7 2501 Num of Entries: The number of MAC Addresses in the array. 2502 MAC Address: An array of MAC Addresses to add to the blacklist 2503 entry. 2505 7.3.9 Delete Blacklist Entry 2507 The Delete Blacklist Entry message element is used by an AC to delete 2508 a previously added blacklist entry on an WTP, ensuring that the WTP 2509 provides service to the MAC addresses provided in the message. 2511 0 1 2 3 2512 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 2513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2514 | Num of Entries| MAC Address[] | 2515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 | MAC Address[] | 2517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 Type: 66 for Delete Blacklist Entry 2520 Length: >= 7 2521 Num of Entries: The number of MAC Addresses in the array. 2522 MAC Address: An array of MAC Addresses to delete from the blacklist 2523 entry. 2525 7.3.10 Add Static Blacklist Entry 2527 The Add Static Blacklist Entry message element is used by an AC to 2528 add a permanent blacklist entry on an WTP, ensuring that the WTP no 2529 longer provides any service to the MAC addresses provided in the 2530 message. The MAC Addresses provided in this message element are 2531 expected to be saved in non-volative memory on the WTP. 2533 0 1 2 3 2534 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 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | Num of Entries| MAC Address[] | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 | MAC Address[] | 2539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 Type: 70 for Delete Blacklist Entry 2542 Length: >= 7 2543 Num of Entries: The number of MAC Addresses in the array. 2545 MAC Address: An array of MAC Addresses to add to the permanent 2546 blacklist entry. 2548 7.3.11 Delete Static Blacklist Entry 2550 The Delete Static Blacklist Entry message element is used by an AC to 2551 delete a previously added static blacklist entry on an WTP, ensuring 2552 that the WTP provides service to the MAC addresses provided in the 2553 message. 2555 0 1 2 3 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Num of Entries| MAC Address[] | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | MAC Address[] | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 Type: 71 for Delete Blacklist Entry 2564 Length: >= 7 2565 Num of Entries: The number of MAC Addresses in the array. 2566 MAC Address: An array of MAC Addresses to delete from the static 2567 blacklist entry. 2569 7.3.12 LWAPP Timers 2571 The LWAPP Timers message element is defined in section Section 7.2.3. 2573 7.3.13 AC Name with Index 2575 The AC Name with Index message element is defined in section 2576 Section 7.1.3. 2578 7.3.14 WTP Fallback 2580 The WTP Fallback message element is defined in section Section 7.2.5. 2582 7.3.15 Idle Timeout 2584 The Idle Timeout message element is defined in section Section 7.2.6. 2586 7.4 Configuration Update Response 2588 The Configuration Update Response is the acknowledgement message for 2589 the Configuration Update Request. 2591 Configuration Update Responses are sent by an WTP after receiving a 2592 Configuration Update Request. 2594 When an AC receives a Configure Update Response the result code 2595 indicates if the WTP successfully accepted the configuration. 2597 The following subsections define the message elements that must be 2598 present in this LWAPP operation. 2600 7.4.1 Result Code 2602 The Result Code message element is defined in section Section 6.2.1. 2604 7.5 Change State Event Request 2606 The Change State Event is used by the WTP to inform the AC of a 2607 change in the operational state. 2609 The Change State Event message is sent by the WTP when it receives a 2610 Configuration Response that includes a Change State Event message 2611 element. It is also sent in the event that the WTP detects an 2612 operational failure with a radio. The Change State Event may be sent 2613 in either the Configure or Run state (see Figure 2. 2615 When an AC receives a Change State Event it will respond with a 2616 Change State Event Response and make any necessary modifications to 2617 internal WTP data structures. 2619 The following subsections define the message elements that must be 2620 present in this LWAPP operation. 2622 7.5.1 Change State Event 2624 The Change State Event message element is defined in section 2625 Section 7.2.2. 2627 7.6 Change State Event Response 2629 The Change State Event Response acknowledges the Change State Event. 2631 Change State Event Response are sent by an WTP after receiving a 2632 Change State Event. 2634 The Change State Event Response carries no message elements. Its 2635 purpose is to acknowledge the receipt of the Change State Event. 2637 The WTP does not need to perform any special processing of the Change 2638 State Event Response message. 2640 7.7 Clear Config Indication 2642 The Clear Config Indication is used to reset an WTP's configuration. 2644 The Clear Config Indication is sent by an AC to request that an WTP 2645 reset its configuration to manufacturing defaults. The Clear Config 2646 Indication message is sent while in the Run LWAPP state. 2648 The Reset Request carries no message elements. 2650 When an WTP receives a Clear Config Indication it will reset its 2651 configuration to manufacturing defaults. 2653 8. Device Management Operations 2655 This section defines LWAPP operations responsible for debugging, 2656 gathering statistics, logging, and firmware management. 2658 8.1 Image Data Request 2660 The Image Data Request is used to update firmware on the WTP. This 2661 message and its companion response are used by the AC to ensure that 2662 the image being run on each WTP is appropriate. 2664 Image Data Requests are exchanged between the WTP and the AC to 2665 download a new program image to an WTP. 2667 When an WTP or AC receives an Image Data Request it will respond with 2668 a Image Data Response. 2670 The format of the Image Data and Image Download message elements are 2671 described in the following subsections. 2673 8.1.1 Image Download 2675 The image download message element is sent by the WTP to the AC and 2676 contains the image filename. The value is a variable length byte 2677 string. The string is NOT zero terminated. 2679 8.1.2 Image Data 2681 The image data message element is present when sent by the AC and 2682 contains the following fields. 2684 0 1 2 3 2685 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 2686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 | Opcode | Checksum | Image Data | 2688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2689 | Image Data ... | 2690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2692 Type: 33 for Image Data 2693 Length: >= 5 2694 Opcode: An 8-bit value representing the transfer opcode. The 2695 following values are supported: 2696 3 - Image data is included 2697 5 - An error occurred. Transfer is aborted 2699 Checksum: A 16-bit value containing a checksum of the image data 2700 that follows 2701 Image Data: The Image Data field contains 1024 characters, unless 2702 the payload being sent is the last one (end of file) 2704 8.2 Image Data Response 2706 The Image Data Response acknowledges the Image Data Request. 2708 An Image Data Responses is sent in response to an Image Data Request. 2709 Its purpose is to acknowledge the receipt of the Image Data Request 2710 packet. 2712 The Image Data Response carries no message elements. 2714 No action is necessary on receipt. 2716 8.3 Reset Request 2718 The Reset Request is used to cause an WTP to reboot. 2720 Reset Requests are sent by an AC to cause an WTP to reinitialize its 2721 operation. 2723 The Reset Request carries no message elements. 2725 When an WTP receives a Reset Request it will respond with a Reset 2726 Response and then reinitialize itself. 2728 8.4 Reset Response 2730 The Reset Response acknowledges the Reset Request. 2732 Reset Responses are sent by an WTP after receiving a Reset Request. 2734 The Reset Response carries no message elements. Its purpose is to 2735 acknowledge the receipt of the Reset Request. 2737 When an AC receives a Reset Response it is notified that the WTP will 2738 now reinitialize its operation. 2740 8.5 WTP Event Request 2742 WTP Event Request is used by an WTP to send an information to its AC. 2743 These types of events may be periodical, or some asynchronous event 2744 on the WTP. For instance, an WTP collects statistics and uses the 2745 WTP Event Request to transmit this information to the AC. 2747 When an AC receives a WTP Event Request it will respond with a WTP 2748 Event Request. 2750 The WTP Event Request message MUST contain one of the following 2751 message element described in the next subsections, or a message 2752 element that is defined for a specific technology. 2754 8.5.1 Decryption Error Report 2756 The Decryption Error Report message element value is used by the WTP 2757 to inform the AC of decryption errors that have occured since the 2758 last report. 2760 0 1 2 2761 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2763 | Radio ID |Num Of Entries | Mobile MAC Address | 2764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2765 | Mobile MAC Address[] | 2766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 Type: 39 for Decryption Error Report 2769 Length: >= 8 2770 Radio ID: The Radio Identifier, typically refers to some interface 2771 index on the WTP 2772 Num Of Entries: An 8-bit unsigned integer indicating the number of 2773 mobile MAC addresses. 2774 Mobile MAC Address: An array of mobile station MAC addresses that 2775 have caused decryption errors. 2777 8.5.2 Duplicate IP Address 2779 The Duplicate IP Address message element is used by an WTP to inform 2780 an AC that it has detected another host using the same IP address it 2781 is currently using. 2783 0 1 2 3 2784 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 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | IP Address | 2787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 | MAC Address | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2790 | MAC Address | 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 Type: 77 for Duplicate IP Address 2794 Length: 10 2795 IP Address: The IP Address currently used by the WTP. 2796 MAC Address: The MAC Address of the offending device. 2798 8.6 WTP Event Response 2800 WTP Event Response acknowledges the WTP Event Request. 2802 WTP Event Response are sent by an AC after receiving a WTP Event 2803 Request. 2805 The WTP Event Response carries no message elements. 2807 8.7 Data Transfer Request 2809 The Data Transfer Request is used to upload debug information from 2810 the WTP to the AC. 2812 Data Transfer Requests are sent by the WTP to the AC when it 2813 determines that it has important information to send to the AC. For 2814 instance, if the WTP detects that its previous reboot was caused by a 2815 system crash, it would want to send the crash file to the AC. The 2816 remote debugger function in the WTP also uses the data transfer 2817 request in order to send console output to the AC for debugging 2818 purposes. 2820 When an AC receives an Data Transfer Request it will respond with a 2821 Data Transfer Response. The AC may log the information received, as 2822 it sees fit. 2824 The data transfer request message MUST contain ONE of the following 2825 message element described in the next subsection. 2827 8.7.1 Data Transfer Mode 2829 The Data Transfer Mode message element is used by the AC to request 2830 information from the WTP for debugging purposes. 2832 0 2833 0 1 2 3 4 5 6 7 2834 +-+-+-+-+-+-+-+-+ 2835 | Data Type | 2836 +-+-+-+-+-+-+-+-+ 2838 Type: 52 for Data Transfer Mode 2839 Length: 1 2840 Data Type: An 8-bit value the type of information being requested. 2841 The following values are supported: 2842 1 - WTP Crash Data 2843 2 - WTP Memory Dump 2845 8.7.2 Data Transfer Data 2847 The Data Transfer Data message element is used by the WTP to provide 2848 information to the AC for debugging purposes. 2850 0 1 2 3 2851 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 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 | Data Type | Data Length | Data .... 2854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2856 Type: 53 for Data Transfer Data 2857 Length: >= 3 2858 Data Type: An 8-bit value the type of information being sent. The 2859 following values are supported: 2860 1 - WTP Crash Data 2861 2 - WTP Memory Dump 2862 Data Length: Length of data field. 2863 Data: Debug information. 2865 8.8 Data Transfer Response 2867 The Data Transfer Response acknowledges the Data Transfer Request. 2869 An Data Transfer Response is sent in response to an Data Transfer 2870 Request. Its purpose is to acknowledge the receipt of the Data 2871 Transfer Request packet. 2873 The Data Transfer Response carries no message elements. 2875 Upon receipt of a Data Transfer Response, the WTP transmits more 2876 information, if any is available. 2878 9. Mobile Session Management 2880 Messages in this section are used by the AC to create, modify or 2881 delete mobile station session state on the WTPs. 2883 9.1 Mobile Config Request 2885 The Mobile Config Request message is used to create, modify or delete 2886 mobile session state on an WTP. The message is sent by the AC to the 2887 WTP, and may contain one or more message elements. The message 2888 elements for this LWAPP control message include information that is 2889 generally highly technology specific. Therefore, please refer to the 2890 appropriate binding section or document for the definitions of the 2891 messages elements that may be used in this control message. 2893 This section defines the format of the Delete Mobile message element, 2894 since it does not contain any technology specific information. 2896 9.1.1 Delete Mobile 2898 The Delete Mobile message element is used by the AC to inform an WTP 2899 that it should no longer provide service to a particular mobile 2900 station. The WTP must terminate service immediately upon receiving 2901 this message element. 2903 The transmission of a Delete Mobile message element could occur for 2904 various reasons, including for administrative reaons, as a result of 2905 the fact that the mobile has roamed to another WTP, etc. 2907 Once access has been terminated for a given station, any future 2908 packets received from the mobile must result in a deauthenticate 2909 message, as specified in [6]. 2911 0 1 2 3 2912 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 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 | Radio ID | MAC Address | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 | MAC Address | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 Type: 30 for Delete Mobile 2920 Length: 7 2921 Radio ID: An 8-bit value representing the radio 2922 MAC Address: The mobile station's MAC Address 2924 9.2 Mobile Config Response 2926 The Mobile Configuration Response is used to acknowledge a previously 2927 received Mobile Configuration Request, and includes a Result Code 2928 message element which indicates whether an error occured on the WTP. 2930 This message requires no special processing, and is only used to 2931 acknowledge the Mobile Configuration Request. 2933 The data transfer request message MUST contain the message elements 2934 described in the next subsection. 2936 9.2.1 Result Code 2938 The Result Code message element is defined in section Section 6.2.1. 2940 10. Session Key Generation 2942 Note: This version only defines a certificate and a shared secret 2943 based mechanism to secure control LWAPP traffic exchanged between the 2944 WTP and the AC. 2946 10.1 Securing WTP-AC communications 2948 While it is generally straightforward to produce network 2949 installations in which the communications medium between the WTP and 2950 AC is not accessible to the casual user (e.g. these LAN segments are 2951 isolated, no RJ45 or other access ports exist between the WTP and the 2952 AC), this will not always be the case. Furthermore, a determined 2953 attacker may resort to various more sophisticated monitoring and/or 2954 access techniques, thereby compromising the integrity of this 2955 connection. 2957 In general, a certain level of threat on the local (wired) LAN is 2958 expected and accepted in most computing environments. That is, it is 2959 expected that in order to provide users with an acceptable level of 2960 service and maintain reasonable productivity levels, a certain amount 2961 of risk must be tolerated. It is generally believed that a certain 2962 perimeter is maintained around such LANs, that an attacker must have 2963 access to the building(s) in which such LANs exist, and that they 2964 must be able to "plug in" to the LAN in order to access the network. 2966 With these things in mind, we can begin to assess the general 2967 security requirements for AC-WTP communications. While an in-depth 2968 security analysis of threats and risks to these communication is 2969 beyond the scope of this document, some discussion of the motivation 2970 for various security-related design choices is useful. The 2971 assumptions driving the security design thus far include the 2972 following: 2973 o WTP-AC communications take place over a wired connection which may 2974 be accessible to a sophisticated attacker 2975 o access to this connection is not trivial for an outsider (i.e. 2976 someone who does not "belong" in the building) to access 2977 o if authentication and/or privacy of end to end traffic for which 2978 the WTP and AC are intermediaries is required, this may be 2979 provided via IPsec [13]. 2980 o privacy and authentication for at least some WTP-AC control 2981 traffic is required (e.g. WEP keys for user sessions, passed from 2982 AC to WTP) 2983 o the AC can be trusted to generate strong cryptographic keys 2985 AC-WTP traffic can be considered to consist of two types: data 2986 traffic (e.g. to or from an end user), and control traffic which is 2987 strictly between the AC and WTP. Since data traffic may be secured 2988 using IPsec (or some other end-to-end security mechanism), we confine 2989 our solution to control traffic. The resulting security consists of 2990 two components: an authenticated key exchange, and control traffic 2991 security encapsulation. The security encapsulation is accomplished 2992 using AES CCM, described in [3]. This encapsulation provides for 2993 strong AES-based authentication and encryption. The exchange of 2994 cryptographic keys used for CCM is described below. 2996 10.2 LWAPP Frame Encryption 2998 While, the LWAPP protocol uses AES-CCM to encrypt control traffic, it 2999 is important to note that not all control frames are encrypted. The 3000 LWAPP discovery and join phase are not encrypted. The Discovery 3001 messages are sent in the clear since there does not exist a security 3002 association between the WTP and the AC during the discovery phase. 3003 The Join phase is an authenticated exchange used to negotiate 3004 symmetric session keys (see Section 6.2.4). 3006 Once the join phase has been successfully completed, the LWAPP state 3007 machine Figure 2 will move to the Configure state, at which time all 3008 LWAPP control frames are encrypted using AES-CCM. 3010 Encryption of a control message begins at the Message Element field, 3011 meaning the Msg Type, Seq Num, Msg Element Length and Session ID 3012 fields are left intact (see Section 4.2.1). 3014 The AES-CCM 12 byte authentication data is appended to the end of the 3015 message. The authentication data is calculated from the start of the 3016 LWAPP packet, and includes the complete LWAPP control header (see 3017 Section 4.2.1). 3019 The AES-CCM block cipher protocol requires an initialization vector. 3020 The LWAPP protocol requires that the WTP and the AC maintain two 3021 separate IVs, one for transmission and one for reception. The IV is 3022 initialized on both the WTP and the AC to the Session ID, and the IV 3023 is monotonically increased for every packet transmitted. Note that 3024 the IV is implicit, and is not transmitted in the LWAPP header, and 3025 therefore an LWAPP device MUST keep track of both bi-directional IVs. 3026 The IV is 13 bytes long, and the first byte is set to zero, while the 3027 remaining twelve bytes are set to the monotonically increasing 32 bit 3028 counter previously mentioned. The following pseudo code provides an 3029 example of how the IVs are managed for a transmitted packet. 3031 void SetNonce(char *buffer, int sessionId, int xmitIv) 3032 { 3033 if (xmitIv == 0) { 3034 xmitIv = sessionId; 3035 memset(buffer, '\0', 13); 3037 /* Initialize the IV Buffer */ 3038 buffer[1] = (xmitIv >> 24) & 0xff; 3039 buffer[2] = (xmitIv >> 16) & 0xff; 3040 buffer[3] = (xmitIv >> 8) & 0xff; 3041 buffer[4] = (xmitIv & 0xff); 3042 buffer[5] = (xmitIv >> 24) & 0xff; 3043 buffer[6] = (xmitIv >> 16) & 0xff; 3044 buffer[7] = (xmitIv >> 8) & 0xff; 3045 buffer[8] = (xmitIv & 0xff); 3046 buffer[9] = (xmitIv >> 24) & 0xff; 3047 buffer[10] = (xmitIv >> 16) & 0xff; 3048 buffer[11] = (xmitIv >> 8) & 0xff; 3049 buffer[12] = (xmitIv & 0xff); 3050 } else { 3051 xmitIv = bignuminc-12(xmitIv); 3052 } 3054 return; 3055 } 3057 10.3 Authenticated Key Exchange 3059 This section describes the key management component of the LWAPP 3060 protocol. There are two modes supported by LWAPP; certificate and 3061 pre-shared key. 3063 10.3.1 Certificate Based Approach 3065 This section details the key management protocol which makes use of 3066 X.509 certificates. 3068 The following notations are used throughout this section: 3069 o Kpriv - the private key of a public-private key pair 3070 o Kpub - the public key of the pair 3071 o KeyMaterial - output of KDF-256(key, WTP-MAC) 3072 o K1 - AES-CCM Encryption Key 3073 o K2 - AES Key-Wrap Key 3074 o SessionID - randomly generated LWAPP session identifier, provided 3075 by the WTP in the Join Request 3076 o M - a clear-text message 3077 o C - a cipher-text message. 3078 o S - signed cipher-text message. 3079 o PKCS1(z) - the PKCS#1 encapsulation of z 3080 o E-x{Kpriv, M} - RSA encryption of M using X's private key 3081 o E-x{Kpub, M} - RSA encryption of M using X's public key 3082 o S-x{M} - an RSA digital signature over M produced by X 3083 o V-x{S-x, M} - RSA verification of X's digital signature over M 3084 o D-x{Kpriv, C} - RSA decryption of C using X's private key 3085 o D-x{Kpub, C} - RSA decryption of C using X's public key 3086 o Certificate-AC - AC's Certificate 3087 o Certificate-WTP - WTP's Certificate 3089 10.3.1.1 Session Key Generation 3091 The AC and WTP accomplish mutual authentication and a cryptographic 3092 key exchange in a single round trip using the Join Request and 3093 Response pair (see Section 6.1). 3095 Note that the constant 'x' is used in the above notations to 3096 represent one of the parties in the LWAPP exchange. For instance, if 3097 the WTP must encrypt some text, it would use its own private key, and 3098 therefore the notation "E-wtp{Kpriv, M}" would be used. 3100 The following text describes the exchange between the WTP and the AC 3101 that creates a session key, which is used to secure LWAPP control 3102 messages. 3103 o The WTP adds the Certificate message element (see Section 6.1.6) 3104 with the contents set to Certificate-WTP in the Join Request. 3105 o The WTP adds the Session ID message element (see Section 6.1.7) 3106 with the contents set to a randomly generated session identifer 3107 (see RFC 1750 [4]) in the Join Request. The WTP MUST save the 3108 Session ID in order to validate the Join Response. 3109 o Upon receiving the Join Request, the AC verifies Certificate-WTP, 3110 encoded in the Certificate message element. The AC SHOULD also 3111 perform some authorization check, ensuring that the WTP is allowed 3112 to connect to the AC. 3113 o The AC generates a 32 byte random session key. The first 16 3114 bytes, K1 are used to protect the LWAPP traffic while the latter 3115 16 bytes, K2 are used to keywrap the keys in the Key Update 3116 Response using RFC 3394 [10]. 3117 o The AC encrypts the key into cipher-text (C), using E-wtp{Kpub , 3118 PKCS1(KeyMaterial)}. This encrypts the PKCS#1-encoded key 3119 material with the public key of the WTP, so that only the WTP can 3120 decrypt it and determine the session keys. 3122 o The AC encrypts the concatenation of sessionID and cipher text (C) 3123 into cipher text(C�), using E-ac{Kpriv, SessionID|C}. This 3124 encrypts using the private key of AC and can be decrypted using 3125 the public key of AC, proving that AC produced this; this forms 3126 the basis of trust for WTP with respect to the source of the 3127 session keys. The cipher-text (C�) is then copied into the 3128 session key field within the Session Key message element. 3129 o AC creates the Join Response, and includes two message elements. 3130 Certificate-AC is included in the Certificate message element. 3131 The Session Key message element is added, with the Security field 3132 set to one (1 - X.509 Certificate Based), and the cipher-text (C�) 3133 is included in the Session Key field. The resulting Join Response 3134 is sent to the WTP. 3135 o WTP verifies authenticity of Certificate-AC in the Join Response's 3136 Certificate message element. 3137 o WTP computes D-ac{Kpub, 'C�}, where 'C� is the content of Session 3138 Key field in Session Key Message element. The resulting data 3139 includes the SessionID and cipher text (C). SessionID is 3140 validated against the SessionID that was sent in the Join Request. 3141 o WTP computes PKCS1(KeyMaterial) = D-ac{Kpriv , C}, decrypting the 3142 session keys using its private key, where C is the cipher text 3143 retrieved by decrypting the session key field in earlier step. 3144 Since these were encrypted with the WTP's public key, only the WTP 3145 can successfully decrypt the session key. The resulting 32 octet 3146 KeyMaterial is split into two 16 octet keys, K1 and K2, 3147 respectively. 3148 o K1 is now plumbed into the crypto engine as the AES-CCM session 3149 key. From this point on, all control protocol payloads between 3150 the WTP and AC are encrypted and authenticated using the new 3151 session key. 3153 10.3.1.2 Refreshing Cryptographic Keys 3155 Since AC-WTP associations will tend to be relatively long-lived, it 3156 is sensible to periodically refresh the encryption and authentication 3157 keys; this is referred to as "rekeying". When the key lifetime 3158 reaches 95% of the configured value, identified in the KeyLifetime 3159 timer (see Section 12), the rekeying will proceed as follows: 3160 o WTP generates a fresh random Session identier value and encodes it 3161 within the Key Update Request's Session ID message element. The 3162 new session identifier is saved on the WTP in order to verify the 3163 Key Update Response. The protected Key Update Request is sent to 3164 the AC. 3165 o The AC generates a 32 byte random session key. The first 16 3166 bytes, K1 are used to protect the LWAPP traffic while the latter 3167 16 bytes, K2 are used to keywrap the keys in the Key Update 3168 Response using RFC 3394 [10]. 3170 o The AC encrypts the key into cipher-text (C), using E-wtp{Kpub , 3171 PKCS1(KeyMaterial)}. This encrypts the PKCS#1-encoded key 3172 material with the public key of the WTP, so that only the WTP can 3173 decrypt it and determine the session keys. 3174 o The AC encrypts the concatenation of sessionID and cipher text (C) 3175 into cipher text(C�), using E-ac{Kpriv, SessionID|C}. This 3176 encrypts using the private key of AC and can be decrypted using 3177 the public key of AC, proving that AC produced this; this forms 3178 the basis of trust for WTP with respect to the the source of the 3179 session keys. The cipher-text (C�) is then copied into the 3180 session key field within the Session Key message element. 3181 o AC creates the Key Update Response message, and includes the 3182 Session Key message element with the Security field set to one (1 3183 - X.509 Certificate Based), and the cipher-text (C�) is included 3184 in the Session Key field. The resulting encrypted Key Update 3185 Response is sent to the WTP. 3186 o WTP computes D-ac{Kpub, C�}, where C� is the conten of Session Key 3187 field in Session Key Message element. The resulting data includes 3188 the SessionID and cipher text (C). SessionID is validated against 3189 the SessionID that was sent in the Join Request. 3190 o WTP computes PKCS1(KeyMaterial) = D-ac{Kpriv , C}, decrypting the 3191 session keys using its private key, where C is the cipher text 3192 retrieved by decrypting the session key field in earlier step. 3193 Since these were encrypted with the WTP's public key, only the WTP 3194 can successfully decrypt the session key. The resulting 32 octet 3195 KeyMaterial is split into two 16 octet keys, K1 and K2, 3196 respectively. 3197 o K1 is now plumbed into the crypto engine as the AES-CCM session 3198 key. From this point on, all control protocol payloads between 3199 the WTP and AC are encrypted and authenticated using the new 3200 session key. 3202 If WTP does not receive the Key Update Response by the time the 3203 ResponseTimeout timer expires (see Section 12), the WTP MUST delete 3204 the new and old session information, and reset the state machine to 3205 the Idle state. 3207 Following a rekey process, both the WTP and the AC keep the previous 3208 encryption for one second in order to be able to process packets that 3209 arrive out of order. 3211 10.3.2 Pre-Shared Key Approach 3213 This section details the key management protocol which makes use of 3214 pre-shared secrets. 3216 The following notations are used throughout this section: 3218 o PSK - the pre-shared key shared between the WTP and the AC 3219 o K0 - the result of a KDF using the PSK and the WTP's MAC Address 3220 o K1 - the confirmation Key 3221 o K2 - the encryption Key 3222 o K3 - the keywrap Key (see RFC 3394 [10]) 3223 o KeyMaterial - concatenation of K1, K2 and K3 3224 o SessionID - randomly generated LWAPP session identifier, provided 3225 by the WTP in the Join Request 3226 o MIC(K1, packet) - A message integrity check, using HMAC-SHA1 and 3227 K1, of the complete LWAPP packet, with the sequence number field 3228 set to zero. 3229 o E(K0E, plaintext) - Plaintext is encrypted with K0E, using 3230 AES-CBC. 3231 o D(K0E, cryptotext) - Cryptotext is decrypted with K0E, using 3232 AES-CBC. 3233 o WNonce - The WTP's randomly generated Nonce. 3234 o ANonce - The AC's randomly generated Nonce. 3235 o EWNonce - The payload of the WNonce message element, which 3236 includes the WNonce. 3237 o EANonce - The payload of the ANonce message element, which 3238 includes the ANonce. 3239 o WTP-MAC - The WTP's MAC Address. 3240 o AC-MAC - The AC's MAC Address. 3242 10.3.2.1 Session Key Generation 3244 The AC and WTP accomplish mutual authentication and a cryptographic 3245 key exchange in a dual round trip using the Join Request, Join 3246 Response, Join ACK and Join Confirm (see Section 6.1). 3248 The following text describes the exchange between the WTP and the AC 3249 that creates a session key, which is used to secure LWAPP control 3250 messages. 3251 o The WTP creates K0 through the following algorithm: K0 = 3252 KDF-256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || 3253 AC-MAC}, where WTP-MAC is the WTP's MAC Address in the form 3254 "xx:xx:xx:xx:xx:xx". Similarly, the AC-MAC is an ASCII encoding 3255 of the AC's MAC Address, of the form "xx:xx:xx:xx:xx:xx". The 3256 first 16 octets is the K0 encryption key (K0E), and the second 16 3257 octets is the K0 Derivation key (K0D). 3258 o The WTP creates a random nonce, known as WNonce, and encrypts it 3259 using the following algorithm: EWNonce = E{K0E, WNonce}. The 3260 encrypted nonce is added to the Join Request's WNonce message 3261 element (see Section 6.1.9). 3262 o The WTP adds the Session ID message element (see Section 6.1.7) 3263 with the contents set to a randomly generated session identifer 3264 (see RFC 1750 [4]) in the Join Request. The WTP MUST save the 3265 Session ID in order to validate the Join Response. 3267 o Upon receiving the Join Request, the AC creates K0, using K0 = 3268 KDF-256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || 3269 AC-MAC}. WNonce = D{K0E, EWNonce}, where EWNonce is found in the 3270 WNonce message element. 3271 o The AC then creates its own random nonce, known as ANonce. The 3272 WANonce is then created, through E{K0E, NOT WNonce || ANonce}. 3273 "NOT WNonce" means that the AC takes WNonce and inverts all of the 3274 bits within the field. The results of the encryption is inserted 3275 in the Join Response's ANonce message element (see Section 6.1.9). 3276 o The AC then uses the KDF function to create a 48 octet session 3277 key. The KDF function used is as follows: KDF-384{K0D, "LWAPP Key 3278 Generation", WNonce || ANonce || WTP-MAC || AC-MAC}. The KDF 3279 function is defined in [7]. The resulting octets are split into 3280 three 16 octet keys (K1, K2 and K3, in that exact order). 3281 o The AC creates the PSK-MIC (see Section 6.2.8) message element 3282 whose payload includes MIC{K1, Join Response} using K1 as the 3283 confirmation key, which is added to the Join Response. The 3284 resulting Join Response is sent to the WTP. 3285 o Upon receiving the Join Response, the WTP decrypts ANonce from the 3286 contents of the ANonce message element, using ANonce = D{K0E, 3287 WANonce} 3288 o The WTP uses a KDF function to create a 48 octet session key. The 3289 KDF function used is as follows: KDF-384{K0D, "LWAPP Key 3290 Generation", WNonce || ANonce || WTP-MAC || AC-MAC}. The KDF 3291 function is defined in [7]. The resulting octets are split into 3292 three 16 octet keys (K1, K2 and K3, in that exact order). 3293 o WTP verifies authenticity of the PSK-MIC field by using MIC{K1, 3294 Join Response}. 3295 o The WTP creates the PSK-MIC message element whose payload includes 3296 MIC{K1, Join ACK}, which is added to the Join ACK, as well as the 3297 WNonce message element. The resulting Join ACK is sent to the AC. 3298 o AC verifies that WTP's Nonce in the Join ACK's WNonce message 3299 element matches the value it had received in the Join Request. 3300 o AC verifies authenticity of the PSK-MIC message element, by using 3301 its own saved version of K1. It then creates another PSK-MIC 3302 message element, whose payload includes MIC{K1, Join Confirm}, 3303 which is added to the Join Confirm, as well as the Session ID 3304 message element. The resulting Join Confirm is sent to the WTP. 3305 o WTP verifies authenticity of the PSK-MIC message element, by using 3306 its own saved version of K1, using the SessionID it had used in 3307 the original Join Request. 3308 o K2 is now plumbed into the crypto engine as the AES-CCM session 3309 key. From this point on, all control protocol payloads between 3310 the WTP and AC are encrypted and authenticated using the new 3311 session key. 3313 10.3.2.2 Refreshing Cryptographic Keys 3315 Since AC-WTP associations will tend to be relatively long-lived, it 3316 is sensible to periodically refresh the encryption and authentication 3317 keys; this is referred to as "rekeying". When the key lifetime 3318 reaches 95% of the configured value, identified in the KeyLifetime 3319 timer (see Section 12), the rekeying will proceed as follows: 3320 o WTP generates a fresh random Session identier value and encodes it 3321 within the Key Update Request's Session ID message element. The 3322 new session identifier is saved on the WTP in order to verify the 3323 Key Update Response. The Key Update Request is sent to the AC. 3324 o The AC generates 2 new random 16 octet, which are the new K2 and 3325 K3. This new K3 is the AES Key Wrap key that will be used in the 3326 next rekey event. These two session keys are concatenated into a 3327 32 octet value, which is encrypted using the AES Key Wrap (see RFC 3328 3384 [9]), and using K3, which was either created in the KDF 3329 function during the Join phase, or communicated in the previous 3330 Key Update Response to the WTP. The output of the AES Key Wrap 3331 function is used as the Payload of the Session Key message 3332 element. 3333 o AC then sends a protected Key Update Response message to the WTP 3334 using the old session key. Once the message has been sent, the 3335 new K2 session key is plumbed into the AC's crypto engine. 3336 o WTP verifies that SessionID in the Key Update Response's Session 3337 Key message element matches an outstanding request 3338 o WTP uses the AES Key Wrap function, with the K3 which it had 3339 received from the AC in the original Join phase, or mututally 3340 generated in the previous Join Update Request exchange. The 3341 output of the Key Wrap function is a 32 octet value, which is 3342 split into two separate 16 octet session keys, K2 and K3. 3343 o K2 is now plumbed into the crypto engine as the AES-CCM session 3344 key. From this point on, all control protocol payloads between 3345 the WTP and AC are encrypted and authenticated using the new 3346 session key. 3348 If WTP does not receive the Key Update Response by the time the 3349 ResponseTimeout timer expires (see Section 12), the WTP MUST delete 3350 the new and old session information, and reset the state machine to 3351 the Idle state. 3353 Following a rekey process, both the WTP and the AC keep the previous 3354 encryption for one second in order to be able to process packets that 3355 arrive out of order. 3357 11. IEEE 802.11 Binding 3359 This section defines the extensions required for the LWAPP protocol 3360 to be used with the IEEE 802.11 protocol. 3362 11.1 Division of labor 3364 The LWAPP protocol, when used with IEEE 802.11 devices, requires a 3365 specific behavior from the WTP and the AC, specifically in terms of 3366 which 802.11 protocol functions are handled. 3368 11.1.1 Split MAC 3370 This section discusses the roles and responsibilities of the WTP and 3371 the AC when the LWAPP protocol is used in a Split MAC mode. 3373 The responsibility of the WTP is to handle the following functions: 3374 o 802.11 Control Protocol. These functions are very latency 3375 sensitive, and include such functions as packet acknowledgement, 3376 retransmissions, etc. 3377 o 802.11 Beacons. The information elements to be included in the 3378 beacon is controlled by the AC. Since inter-beacon timing is very 3379 critical, the actual beacons are generated by the WTP. Any 802.11 3380 protocol extension that requires changes within the beacon on a 3381 per frame basis (e.g., 802.11e's QBSS) must be handled solely 3382 within the WTP. 3383 o 802.11 Probe Response. As with the beacons, the information to 3384 include in the probe responses is sent by the AC. Stations 3385 generally expect probe requests to be responded to within 3 to 10 3386 milliseconds, and as a consequence it is very difficult to provide 3387 this function in the AC. Note that the WTP does forward the Probe 3388 Requests received to the AC, for its own information. Whether the 3389 AC makes use of these frames is implementation dependent, and is 3390 outside the scope of this document. 3391 o 802.11e Frame Queuing. The 802.11e standard defines a control 3392 protocol, which is carried within the 802.11 MAC management 3393 protocol, as well as defines how packet prioritization is handled 3394 through various timing parameters. The actual packet 3395 prioritization must be handled in the WTP, since only the WTP has 3396 complete visibility into the RF. 3397 o 802.11i Frame Encryption. The 802.11i standard defines a control 3398 protocol used for the establishment of a security association, as 3399 well as a means to encrypt and decrypt 802.11 data frames. The 3400 actual encryption and decryption services MAY occur in the WTP. 3402 The responsibility of the AC is to handle the following functions: 3404 o 802.11 MAC Management. All 802.11 MAC Management frames not 3405 listed above are handled exclusively within the AC. This includes 3406 the 802.11 (re)association request, action frames, etc. 3407 o 802.11 Data. The WTP simply encapsulates all 802.11 data frames 3408 received, and forwards them to the AC. 3409 o 802.11e Resource Reservat. The 802.11e standard defines a control 3410 protocol, which is carried within the 802.11 MAC management 3411 protocol, as well as defines how packet prioritization is handled 3412 through various timing parameters. The signaling defined in this 3413 specification is handled within the AC. 3414 o 802.11i Authentication and Key Exchange. The 802.11i standard 3415 defines a control protocol used for the establishment of a 3416 security association, as well as a means to encrypt and decrypt 3417 802.11 data frames. The authentication (802.1X/EAP) and key 3418 exchange component of this standard is handled within the AC. 3420 11.1.2 Local MAC 3422 This section discusses the roles and responsibilities of the WTP and 3423 the AC when the LWAPP protocol is used in a Local MAC mode. 3425 TBD 3427 11.2 Transport specific bindings 3429 All LWAPP transports have the following IEEE 802.11 specific 3430 bindings: 3432 11.2.1 Status and WLANS field 3434 The interpretation of this 16 bit field depends on the direction of 3435 transmission of the packet. Refer to the figure in Section 3436 Section 3.1. 3438 Status 3440 When an LWAPP packet is transmitted from an WTP to an AC, this field 3441 is called the status field and indicates radio resource information 3442 associated with the frame. When the message is an LWAPP control 3443 message this field is transmitted as zero. 3445 The status field is divided into the signal strength and signal to 3446 noise ratio with which an IEEE 802.11 frame was received, encoded in 3447 the following manner: 3449 0 1 3450 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3453 | RSSI | SNR | 3454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3456 RSSI: RSSI is a signed, 8-bit value. It is the received signal 3457 strength indication, in dBm. 3458 SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio 3459 of the received IEEE 802.11 frame, in dB. 3460 WLANs field: When an LWAPP data message is transmitted from an AC to 3461 an WTP, this 16 bit field indicates on which WLANs the 3462 encapsulated IEEE 802.11 frame is to be transmitted. For unicast 3463 packets, this field is not used by the WTP. For broadcast or 3464 multicast packets, the WTP might require this information if it 3465 provides encryption services. 3466 Given that a single broadcast or multicast packet might need to be 3467 sent to multiple wireless LANs (presumably each with a different 3468 broadcast key), this field is defined as a bit field. A bit set 3469 indicates a WLAN ID (see Section Section 11.5.1.1) which will be 3470 sent the data. The WLANS field is encoded in the following 3471 manner: 3473 0 1 3474 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3476 | WLAN ID(s) | 3477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3479 11.3 Data Message bindings 3481 There are no LWAPP Data Message bindings for IEEE 802.11. 3483 11.4 Control Message bindings 3485 The IEEE 802.11 binding has the following Control Message 3486 definitions. 3488 11.4.1 Mobile Config Request 3490 This section contains the 802.11 specific message elements that are 3491 used with the Mobile Config Request. 3493 11.4.1.1 Add Mobile 3495 The Add Mobile Request is used by the AC to inform an WTP that it 3496 should forward traffic from a particular mobile station. The add 3497 mobile request may also include security parameters that must be 3498 enforced by the WTP for the particular mobile. 3500 When the AC sends an Add Mobile Request, it includes any security 3501 parameters that may be required. An AC that wishes to update a 3502 mobile's policy on an WTP may be done by simply sending a new Add 3503 Mobile message element. 3505 When an WTP receives an Add Mobile message element, it must first 3506 override any existing state it may have for the mobile station in 3507 question. The latest Add Mobile overrides any previously received 3508 messages. If the Add Mobile message element's EAP Only bit is set, 3509 the WTP MUST drop all 802.11 packets that do not contain EAP packets. 3510 Note that when EAP Only is set, the Encryption Policy field MAY have 3511 additional values, and therefore it is possible to inform an WTP to 3512 only accept encrypted EAP packets. Once the mobile station has 3513 successfully completed EAP authentication, the AC must send a new Add 3514 Mobile message element to push the session key down to the WTP as 3515 well as to remove the EAP Only restriction. 3517 If the QoS field is set, the WTP MUST observe and provide policing of 3518 the 802.11e priority tag to ensure that it does not exceed the value 3519 provided by the AC. 3521 0 1 2 3 3522 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 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 | Radio ID | Association ID | MAC Address | 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 | MAC Address | 3527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3528 | MAC Address |E|C| Encryption Policy | 3529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3530 |Encrypt Policy | Session Key... | 3531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 | Pairwise TSC... | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 | Pairwise RSC... | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 | Capabilities | WLAN ID | WME Mode | 3537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3538 | 802.11e Mode | Qos | Supported Rates | 3539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3540 | Supported Rates | 3541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3543 Type: 29 for Add Mobile 3544 Length: 36 3545 Radio ID: An 8-bit value representing the radio 3546 Association ID: A 16-bit value specifying the 802.11 Association 3547 Identifier 3548 MAC Address: The mobile station's MAC Address 3549 E: The one bit field is set by the AC to inform the WTP that is MUST 3550 NOT accept any 802.11 data frames, other than 802.1X frames. This 3551 is the equivalent of the WTP's 802.1X port for the mobile station 3552 to be in the closed state. When set, the WTP MUST drop any 3553 non-802.1X packets it receives from the mobile station. 3554 C: The one bit field is set by the AC to inform the WTP that 3555 encryption services will be provided by the AC. When set, the WTP 3556 SHOULD police frames received from stations to ensure that they 3557 comply to the stated encryption policy, but does not need to take 3558 specific cryptographic action on the frame. Similarly, for 3559 transmitted frames, the WTP only needs to forward already 3560 encrypted frames. 3561 Encryption Policy: The policy field informs the WTP how to handle 3562 packets from/to the mobile station. The following values are 3563 supported: 3564 0 - Encrypt WEP 104: All packets to/from the mobile station must 3565 be encrypted using standard 104 bit WEP. 3566 1 - Clear Text: All packets to/from the mobile station do not 3567 require any additional crypto processing by the WTP. 3568 2 - Encrypt WEP 40: All packets to/from the mobile station must 3569 be encrypted using standard 40 bit WEP. 3570 3 - Encrypt WEP 128: All packets to/from the mobile station must 3571 be encrypted using standard 128 bit WEP. 3572 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3573 must be encrypted using 128 bit AES CCMP [7] 3574 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3575 be encrypted using TKIP and authenticated using Michael [15] 3576 Session Key: A 32 octet session key the WTP is to use when 3577 encrypting traffic to or decrypting traffic from the mobile 3578 station. The type of key is determined based on the Encryption 3579 Policy field. 3580 Pairwise TSC: The TSC to use for unicast packets transmitted to the 3581 mobile. 3582 Pairwise RSC: The RSC to use for unicast packets received from the 3583 mobile. 3584 Capabilities: A 16-bit field containing the 802.11 capabilities to 3585 use with the mobile. 3586 WLAN ID: An 8-bit value specifying the WLAN Identifier 3587 WME Mode: A 8-bit boolean used to identify whether the station is 3588 WME capable. A value of zero is used to indicate that the station 3589 is not WME capable, while a value of one means that the station is 3590 WME capable. 3592 802.11e Mode: A 8-bit boolean used to identify whether the station 3593 is 802.11e capable. A value of zero is used to indicate that the 3594 station is not 802.11e capable, while a value of one means that 3595 the station is 802.11e capable. 3596 QoS: An 8-bit value specifying the QoS policy to enforce for the 3597 station. The following values are supported: PRC: TO CHECK 3598 0 - Silver (Best Effort) 3599 1 - Gold (Video) 3600 2 - Platinum (Voice) 3601 3 - Bronze (Background) 3602 Supported Rates: The supported rates to be used with the mobile 3603 station. 3605 11.4.1.2 IEEE 802.11 Mobile Session Key 3607 The Mobile Session Key Payload message element is sent when the AC 3608 determines that encryption of a mobile station must be performed in 3609 the WTP. This message element MUST NOT be present without the Add 3610 Mobile (see Section 11.4.1.1) message element, and MUST NOT be sent 3611 if the WTP had not specifically advertised support for the requested 3612 encryption scheme (see ???). 3614 0 1 2 3 3615 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 3616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3617 | MAC Address | 3618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3619 | MAC Address | Encryption Policy | 3620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3621 | Encryption Policy | Session Key... | 3622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3624 Type: 105 for IEEE 802.11 Mobile Session Key 3625 Length: >= 11 3626 MAC Address: The mobile station's MAC Address 3627 Encryption Policy: The policy field informs the WTP how to handle 3628 packets from/to the mobile station. The following values are 3629 supported: 3630 0 - Encrypt WEP 104: All packets to/from the mobile station must 3631 be encrypted using standard 104 bit WEP. 3632 1 - Clear Text: All packets to/from the mobile station do not 3633 require any additional crypto processing by the WTP. 3634 2 - Encrypt WEP 40: All packets to/from the mobile station must 3635 be encrypted using standard 40 bit WEP. 3636 3 - Encrypt WEP 128: All packets to/from the mobile station must 3637 be encrypted using standard 128 bit WEP. 3639 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3640 must be encrypted using 128 bit AES CCMP [7] 3641 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3642 be encrypted using TKIP and authenticated using Michael [15] 3643 Session Key: The session key the WTP is to use when encrypting 3644 traffic to/from the mobile station. 3646 11.4.1.3 QoS Profile 3648 The QoS Profile Payload message element contains the maximum 802.11e 3649 priority tag that may be used by the station. Any packets received 3650 that exceeds the value encoded in this message element must either be 3651 dropped or tagged using the maximum value permitted by to the user. 3652 The priority tag must be between zero (0) and seven (7). 3654 0 1 2 3 3655 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 3656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3657 | MAC Address | 3658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3659 | MAC Address | 802.1P Precedence Tag | 3660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3662 Type: TBD for IEEE 802.11 QOS Profile 3663 Length: 12 3664 MAC Address: The mobile station's MAC Address 3665 802.1P Precedence Tag: The maximum 802.1P precedence value that the 3666 WTP will allow in the TID field in the extended 802.11e QOS Data 3667 header. 3669 11.4.1.4 IEEE 802.11 Update Mobile QoS 3671 The Update Mobile QoS message element is used to change the Quality 3672 of Service policy on the WTP for a given mobile station. 3674 0 1 2 3 3675 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 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3677 | Radio ID | Association ID | MAC Address | 3678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3679 | MAC Address | 3680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3681 | MAC Address | QoS Profile | Vlan Identifier | 3682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3683 | DSCP Tag | 802.1P Tag | 3684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 Type: 106 for IEEE 802.11 Update Mobile QoS 3687 Length: 14 3688 Radio ID: The Radio Identifier, typically refers to some interface 3689 index on the WTP 3690 Association ID: The 802.11 Association Identifier. 3691 MAC Address: The mobile station's MAC Address. 3692 QoS Profile: An 8-bit value specifying the QoS policy to enforce for 3693 the station. The following values are supported: 3694 0 - Silver (Best Effort) 3695 1 - Gold (Video) 3696 2 - Platinum (Voice) 3697 3 - Bronze (Background) 3698 VLAN Identifier: PRC. 3699 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 3700 802.1P Tag: The 802.1P precedence value to use if packets are to be 3701 802.1P tagged. 3703 11.4.2 WTP Event Request 3705 This section contains the 802.11 specific message elements that are 3706 used with the WTP Event Request message. 3708 11.4.2.1 IEEE 802.11 Statistics 3710 The statistics message element is sent by the WTP to transmit it's 3711 current statistics. The value contains the following fields. 3713 0 1 2 3 3714 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 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 | Radio ID | Tx Fragment Count | 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 |Tx Fragment Cnt| Multicast Tx Count | 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 | Mcast Tx Cnt | Failed Count | 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3722 | Failed Count | Retry Count | 3723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3724 | Retry Count | Multiple Retry Count | 3725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3726 |Multi Retry Cnt| Frame Duplicate Count | 3727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3728 | Frame Dup Cnt | RTS Success Count | 3729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3730 |RTS Success Cnt| RTS Failure Count | 3731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3732 |RTS Failure Cnt| ACK Failure Count | 3733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3734 |ACK Failure Cnt| Rx Fragment Count | 3735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3736 |Rx Fragment Cnt| Multicast RX Count | 3737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3738 | Mcast Rx Cnt | FCS Error Count | 3739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3740 | FCS Error Cnt| Tx Frame Count | 3741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3742 | Tx Frame Cnt | Decryption Errors | 3743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3744 |Decryption Errs| 3745 +-+-+-+-+-+-+-+-+ 3747 Type: 38 for Statistics 3748 Length: 57 3749 Radio ID: An 8-bit value representing the radio. 3750 Tx Fragment Count: A 32-bit value representing the number of 3751 fragmented frames transmitted. 3752 Multicast Tx Count: A 32-bit value representing the number of 3753 multicast frames transmitted. 3754 Failed Count: A 32-bit value representing the transmit excessive 3755 retries. 3756 Retry Count: A 32-bit value representing the number of transmit 3757 retries. 3759 Multiple Retry Count: A 32-bit value representing the number of 3760 transmits that required more than one retry. 3761 Frame Duplicate Count: A 32-bit value representing the duplicate 3762 frames received. 3763 RTS Success Count: A 32-bit value representing the number of 3764 successfully transmitted Ready To Send (RTS). 3765 RTS Failure Count: A 32-bit value representing the failed 3766 transmitted RTS. 3767 ACK Failure Count: A 32-bit value representing the number of failed 3768 acknowledgements. 3769 Rx Fragment Count: A 32-bit value representing the number of 3770 fragmented frames received. 3771 Multicast RX Count: A 32-bit value representing the number of 3772 multicast frames received. 3773 FCS Error Count: A 32-bit value representing the number of FCS 3774 failures. 3775 Decryption Errors: A 32-bit value representing the number of 3776 Decryption errors that occured on the WTP. Note that this field 3777 is only valid in cases where the WTP provides 3778 encryption/decryption services. 3780 11.5 802.11 Control Messages 3782 This section will define LWAPP Control Messages that are specific to 3783 the IEEE 802.11 binding. 3785 11.5.1 IEEE 802.11 WLAN Config Request 3787 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 3788 WTP in order to change services provided by the WTP. This control 3789 message is used to either create, update or delete a WLAN on the WTP. 3791 The IEEE 802.11 WLAN Configuration Request is sent as a result of 3792 either some manual admistrative process (e.g., deleting a WLAN), or 3793 automatically to create a WLAN on an WTP. When sent automatically to 3794 create a WLAN, this control message is sent after the LWAPP 3795 Configuration Request message has been received by the WTP. 3797 Upon receiving this control message, the WTP will modify the 3798 necessary services, and transmit an IEEE 802.11 WLAN Configuration 3799 Response. 3801 An WTP MAY provide service for more than one WLAN, therefore every 3802 WLAN is identified through a numerical index. For instance, an WTP 3803 that is capable of supporting up to 16 SSIDs, could accept up to 16 3804 IEEE 802.11 WLAN Configuration Request messages that include the Add 3805 WLAN message element. 3807 Since the index is the primary identifier for a WLAN, an AC SHOULD 3808 attempt to ensure that the same WLAN is identified through the same 3809 index number on all of its WTPs. An AC that does not follow this 3810 approach MUST find some other means of maintaining a WLAN Identifier 3811 to SSID mapping table. 3813 The following subsections define the message elements that are value 3814 for this LWAPP operation. Only one message MUST be present. 3816 11.5.1.1 IEEE 802.11 Add WLAN 3818 The Add WLAN message element is used by the AC to define a wireless 3819 LAN on the WTP. The value contains the following format: 3821 0 1 2 3 3822 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 3823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3824 | Radio ID | WLAN Capability | WLAN ID | 3825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3826 | Encryption Policy | 3827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3828 | Key ... | 3829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3830 | Key Index | Shared Key | WPA Data Len |WPA IE Data ...| 3831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3832 | RSN Data Len |RSN IE Data ...| Reserved .... | 3833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3834 | WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...| 3835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3836 | QoS | Auth Type |Broadcast SSID | Reserved... | 3837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3838 | SSID ... | 3839 +-+-+-+-+-+-+-+-+ 3841 Type: 7 for IEEE 802.11 Add WLAN 3842 Length: >= 298 3843 Radio ID: An 8-bit value representing the radio. 3844 WLAN Capability: A 16-bit value containing the capabilities to be 3845 advertised by the WTP within the Probe and Beacon messages. 3846 WLAN ID: A 16-bit value specifying the WLAN Identifier. 3847 Encryption Policy: A 32-bit value specifying the encryption scheme 3848 to apply to traffic to and from the mobile station. 3849 The following values are supported: 3850 0 - Encrypt WEP 104: All packets to/from the mobile station must 3851 be encrypted using standard 104 bit WEP. 3853 1 - Clear Text: All packets to/from the mobile station do not 3854 require any additional crypto processing by the WTP. 3855 2 - Encrypt WEP 40: All packets to/from the mobile station must 3856 be encrypted using standard 40 bit WEP. 3857 3 - Encrypt WEP 128: All packets to/from the mobile station must 3858 be encrypted using standard 128 bit WEP. 3859 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3860 must be encrypted using 128 bit AES CCMP [7] 3861 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3862 be encrypted using TKIP and authenticated using Michael [15] 3863 6 - Encrypt CKIP: All packets to/from the mobile station must be 3864 encrypted using Cisco TKIP. 3865 Key: A 32 byte Session Key to use with the encryption policy. 3866 Key-Index: The Key Index associated with the key. 3867 Shared Key: A 1 byte boolean that specifies whether the key included 3868 in the Key field is a shared WEP key. A value of zero is used to 3869 state that the key is not a shared WEP key, while a value of one 3870 is used to state that the key is a shared WEP key. 3871 WPA Data Len: Length of the WPA IE. 3872 WPA IE: A 32 byte field containing the WPA Information Element. 3873 RSN Data Len: Length of the RSN IE. 3874 RSN IE: A 64 byte field containing the RSN Information Element. 3875 Reserved: A 49 byte reserved field, which MUST be set to zero (0). 3876 WME Data Len: Length of the WME IE. 3877 WME IE: A 32 byte field containing the WME Information Element. 3878 DOT11E Data Len: Length of the 802.11e IE. 3879 DOT11E IE: A 32 byte field containing the 802.11e Information 3880 Element. 3881 QOS: An 8-bit value specifying the QoS policy to enforce for the 3882 station. 3883 The following values are supported: 3884 0 - Silver (Best Effort) 3885 1 - Gold (Video) 3886 2 - Platinum (Voice) 3887 3 - Bronze (Background) 3888 Auth Type: An 8-bit value specifying the station's authentication 3889 type. 3890 The following values are supported: 3891 0 - Open System 3892 1 - WEP Shared Key 3893 2 - WPA/WPA2 802.1X 3894 3 - WPA/WPA2 PSK 3895 Broadcast SSID: A boolean indicating whether the SSID is to be 3896 broadcast by the WTP. A value of zero disables SSID broadcast, 3897 while a value of one enables it. 3899 Reserved: A 40 byte reserved field. 3900 SSID: The SSID attribute is the service set identifier that will be 3901 advertised by the WTP for this WLAN. 3903 11.5.1.2 IEEE 802.11 Delete WLAN 3905 The delete WLAN message element is used to inform the WTP that a 3906 previously created WLAN is to be deleted. The value contains the 3907 following fields: 3909 0 1 2 3910 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3912 | Radio ID | WLAN ID | 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 Type: 28 for IEEE 802.11 Delete WLAN 3916 Length: 3 3917 Radio ID: An 8-bit value representing the radio 3918 WLAN ID: A 16-bit value specifying the WLAN Identifier 3920 11.5.1.3 IEEE 802.11 Update WLAN 3922 The Update WLAN message element is used by the AC to define a 3923 wireless LAN on the WTP. The value contains the following format: 3925 0 1 2 3 3926 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 3927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3928 | Radio ID | WLAN ID |Encrypt Policy | 3929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3930 | Encryption Policy | Key... | 3931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3932 | Key ... | 3933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3934 | Key Index | Shared Key | WLAN Capability | 3935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3937 Type: 34 for IEEE 802.11 Update WLAN 3938 Length: 43 3939 Radio ID: An 8-bit value representing the radio. 3940 WLAN ID: A 16-bit value specifying the WLAN Identifier. 3941 Encryption Policy: A 32-bit value specifying the encryption scheme 3942 to apply to traffic to and from the mobile station. 3943 The following values are supported: 3945 0 - Encrypt WEP 104: All packets to/from the mobile station must 3946 be encrypted using standard 104 bit WEP. 3947 1 - Clear Text: All packets to/from the mobile station do not 3948 require any additional crypto processing by the WTP. 3949 2 - Encrypt WEP 40: All packets to/from the mobile station must 3950 be encrypted using standard 40 bit WEP. 3951 3 - Encrypt WEP 128: All packets to/from the mobile station must 3952 be encrypted using standard 128 bit WEP. 3953 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3954 must be encrypted using 128 bit AES CCMP [7] 3955 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3956 be encrypted using TKIP and authenticated using Michael [15] 3957 6 - Encrypt CKIP: All packets to/from the mobile station must be 3958 encrypted using Cisco TKIP. 3959 Key: A 32 byte Session Key to use with the encryption policy. 3960 Key-Index: The Key Index associated with the key. 3961 Shared Key: A 1 byte boolean that specifies whether the key included 3962 in the Key field is a shared WEP key. A value of zero means that 3963 the key is not a shared WEP key, while a value of one is used to 3964 state that the key is a shared WEP key. 3965 WLAN Capability: A 16-bit value containing the capabilities to be 3966 advertised by the WTP within the Probe and Beacon messages. 3968 11.5.2 IEEE 802.11 WLAN Config Response 3970 The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the 3971 AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN 3972 Configuration Request. 3974 This LWAPP control message does not include any message elements. 3976 11.5.3 IEEE 802.11 WTP Event 3978 The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order 3979 to report asynchronous events to the AC. There is no reply message 3980 expected from the AC, except that the message is acknowledged via the 3981 reliable transport. 3983 When the AC receives the IEEE 802.11 WTP Event, it will take whatever 3984 action is necessary, depending upon the message elements present in 3985 the message. 3987 The IEEE 802.11 WTP Event message MUST contain one of the following 3988 message element described in the next subsections. 3990 11.5.3.1 IEEE 802.11 MIC Countermeasures 3992 The MIC Countermeasures message element is sent by the WTP to the AC 3993 to indicate the occurrence of a MIC failure. 3995 0 1 2 3 3996 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 3997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3998 | Radio ID | WLAN ID | MAC Address | 3999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4000 | MAC Address | 4001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4003 Type: 61 for IEEE 802.11 MIC Countermeasures 4004 Length: 8 4005 Radio ID: The Radio Identifier, typically refers to some interface 4006 index on the WTP. 4007 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 4008 on which the MIC failure occurred. 4009 MAC Address: The MAC Address of the mobile station that caused the 4010 MIC failure. 4012 11.5.3.2 IEEE 802.11 WTP Radio Fail Alarm Indication 4014 The WTP Radio Fail Alarm Indication message element is sent by the 4015 WTP to the AC when it detects a radio failure. 4017 0 1 2 3 4018 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 4019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4020 | Radio ID | Type | Status | Pad | 4021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4023 Type: 95 for WTP Radio Fail Alarm Indication 4024 Length: 4 4025 Radio ID: The Radio Identifier, typically refers to some interface 4026 index on the WTP 4027 Type: The type of radio failure detected. The following values are 4028 supported: 4029 1 - Receiver 4030 2 - Transmitter 4031 Status: An 8-bit boolean indicating whether the radio failure is 4032 being reported or cleared. A value of zero is used to clear the 4033 event, while a value of one is used to report the event. 4034 Pad: Reserved field MUST be set to zero (0). 4036 11.6 Message Element Bindings 4038 The IEEE 802.11 Message Element binding has the following 4039 definitions: 4041 Conf Conf Conf Add 4042 Req Resp Upd Mobile 4044 IEEE 802.11 WTP WLAN Radio Configuration X X X 4045 IEEE 802.11 Rate Set X X 4046 IEEE 802.11 Multi-domain Capability X X X 4047 IEEE 802.11 MAC Operation X X X 4048 IEEE 802.11 Tx Power X X X 4049 IEEE 802.11 Tx Power Level X 4050 IEEE 802.11 Direct Sequence Control X X X 4051 IEEE 802.11 OFDM Control X X X 4052 IEEE 802.11 Supported Rates X X 4053 IEEE 802.11 Antenna X X X 4054 IEEE 802.11 CFP Status X X 4055 IEEE 802.11 Broadcast Probe Mode X X 4056 IEEE 802.11 WTP Mode and Type X? X 4057 IEEE 802.11 WTP Quality of Service X X 4058 IEEE 802.11 MIC Error Report From Mobile X 4059 IEEE 802.11 Update Mobile QoS X 4060 IEEE 802.11 Mobile Session Key X 4061 VOIP STUFF 4063 11.6.1 IEEE 802.11 WTP WLAN Radio Configuration 4065 The WTP WLAN radio configuration is used by the AC to configure a 4066 Radio on the WTP. The message element value contains the following 4067 Fields: 4069 0 1 2 3 4070 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 4071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4072 | Radio ID | Reserved | Occupancy Limit | 4073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4074 | CFP Per | CFP Maximum Duration | BSS ID | 4075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4076 | BSS ID | 4077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4078 | BSS ID | Beacon Period | DTIM Per | 4079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4080 | Country String | 4081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4083 Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration 4084 Length: 20 4085 Radio ID: An 8-bit value representing the radio to configure. 4086 Reserved: MUST be set to zero 4087 Occupancy Limit: This attribute indicates the maximum amount of 4088 time, in TU, that a point coordinator MAY control the usage of the 4089 wireless medium without relinquishing control for long enough to 4090 allow at least one instance of DCF access to the medium. The 4091 default value of this attribute SHOULD be 100, and the maximum 4092 value SHOULD be 1000. 4093 CFP Period: The attribute describes the number of DTIM intervals 4094 between the start of CFPs. 4095 CFP Maximum Duration: The attribute describes the maximum duration 4096 of the CFP in TU that MAY be generated by the PCF. 4097 BSSID: The WLAN Radio's base MAC Address. For WTPs that support 4098 more than a single WLAN, the value of the WLAN Identifier is added 4099 to the last octet of the BSSID. Therefore, a WTP that supports 16 4100 WLANs MUST have 16 MAC Addresses reserved for it, and the last 4101 nibble is used to represent the WLAN ID. 4102 Beacon Period: This attribute specifies the number of TU that a 4103 station uses for scheduling Beacon transmissions. This value is 4104 transmitted in Beacon and Probe Response frames. 4105 DTIM Period: This attribute specifies the number of beacon intervals 4106 that elapses between transmission of Beacons frames containing a 4107 TIM element whose DTIM Count field is 0. This value is 4108 transmitted in the DTIM Period field of Beacon frames. 4109 Country Code: This attribute identifies the country in which the 4110 station is operating. The first two octets of this string is the 4111 two character country code as described in document ISO/IEC 3166- 4112 1. The third octet MUST be one of the following: 4113 1. an ASCII space character, if the regulations under which the 4114 station is operating encompass all environments in the 4115 country, 4116 2. an ASCII 'O' character, if the regulations under which the 4117 station is operating are for an outdoor environment only, or 4118 3. an ASCII 'I' character, if the regulations under which the 4119 station is operating are for an indoor environment only 4121 11.6.2 IEEE 802.11 Rate Set 4123 The rate set message element value is sent by the AC and contains the 4124 supported operational rates. It contains the following fields. 4126 0 1 2 3 4127 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 4128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4129 | Radio ID | Rate Set | 4130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 Type: 16 for IEEE 802.11 Rate Set 4133 Length: 4 4134 Radio ID: An 8-bit value representing the radio to configure. 4135 Rate Set: The AC generates the Rate Set that the WTP is to include 4136 in it's Beacon and Probe messages. 4138 11.6.3 IEEE 802.11 Multi-domain Capability 4140 The multi-domain capability message element is used by the AC to 4141 inform the WTP of regulatory limits. The value contains the 4142 following fields. 4144 0 1 2 3 4145 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 4146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4147 | Radio ID | Reserved | First Channel # | 4148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4149 | Number of Channels | Max Tx Power Level | 4150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4152 Type: 10 for IEEE 802.11 Multi-Domain Capability 4153 Length: 8 4154 Radio ID: An 8-bit value representing the radio to configure. 4155 Reserved: MUST be set to zero 4156 First Channnel #: This attribute indicates the value of the lowest 4157 channel number in the subband for the associated domain country 4158 string. 4159 Number of Channels: This attribute indicates the value of the total 4160 number of channels allowed in the subband for the associated 4161 domain country string. 4162 Max Tx Power Level: This attribute indicates the maximum transmit 4163 power, in dBm, allowed in the subband for the associated domain 4164 country string. 4166 11.6.4 IEEE 802.11 MAC Operation 4168 The MAC operation message element is sent by the AC to set the 802.11 4169 MAC parameters on the WTP. The value contains the following fields. 4171 0 1 2 3 4172 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 4173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4174 | Radio ID | Reserved | RTS Threshold | 4175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4176 | Short Retry | Long Retry | Fragmentation Threshold | 4177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4178 | Tx MSDU Lifetime | 4179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 | Rx MSDU Lifetime | 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4183 Type: 11 for IEEE 802.11 MAC Operation 4184 Length: 16 4185 Radio ID: An 8-bit value representing the radio to configure. 4186 Reserved: MUST be set to zero 4187 RTS Threshold: This attribute indicates the number of octets in an 4188 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 4189 RTS/CTS handshake MUST be performed at the beginning of any frame 4190 exchange sequence where the MPDU is of type Data or Management, 4191 the MPDU has an individual address in the Address1 field, and the 4192 length of the MPDU is greater than this threshold. Setting this 4193 attribute to be larger than the maximum MSDU size MUST have the 4194 effect of turning off the RTS/CTS handshake for frames of Data or 4195 Management type transmitted by this STA. Setting this attribute 4196 to zero MUST have the effect of turning on the RTS/CTS handshake 4197 for all frames of Data or Management type transmitted by this STA. 4198 The default value of this attribute MUST be 2347. 4199 Short Retry: This attribute indicates the maximum number of 4200 transmission attempts of a frame, the length of which is less than 4201 or equal to RTSThreshold, that MUST be made before a failure 4202 condition is indicated. The default value of this attribute MUST 4203 be 7. 4204 Long Retry: This attribute indicates the maximum number of 4205 transmission attempts of a frame, the length of which is greater 4206 than dot11RTSThreshold, that MUST be made before a failure 4207 condition is indicated. The default value of this attribute MUST 4208 be 4. 4209 Fragmentation Threshold: This attribute specifies the current 4210 maximum size, in octets, of the MPDU that MAY be delivered to the 4211 PHY. An MSDU MUST be broken into fragments if its size exceeds 4212 the value of this attribute after adding MAC headers and trailers. 4213 An MSDU or MMPDU MUST be fragmented when the resulting frame has 4214 an individual address in the Address1 field, and the length of the 4215 frame is larger than this threshold. The default value for this 4216 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 4217 attached PHY and MUST never exceed the lesser of 2346 or the 4218 aMPDUMaxLength of the attached PHY. The value of this attribute 4219 MUST never be less than 256. 4220 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 4221 after the initial transmission of an MSDU, after which further 4222 attempts to transmit the MSDU MUST be terminated. The default 4223 value of this attribute MUST be 512. 4224 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 4225 after the initial reception of a fragmented MMPDU or MSDU, after 4226 which further attempts to reassemble the MMPDU or MSDU MUST be 4227 terminated. The default value MUST be 512. 4229 11.6.5 IEEE 802.11 Tx Power 4231 The Tx power message element value is bi-directional. When sent by 4232 the WTP, it contains the current power level of the radio in 4233 question. When sent by the AC, it contains the power level the WTP 4234 MUST adhere to. 4236 0 1 2 3 4237 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 4238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4239 | Radio ID | Reserved | Current Tx Power | 4240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4242 Type: 12 for IEEE 802.11 Tx Power 4243 Length: 4 4244 Radio ID: An 8-bit value representing the radio to configure. 4245 Reserved: MUST be set to zero 4246 Current Tx Power: This attribute contains the transmit output power 4247 in mW. 4249 11.6.6 IEEE 802.11 Tx Power Level 4251 The Tx power level message element is sent by the WTP and contains 4252 the different power levels supported. The value contains the 4253 following fields. 4255 0 1 2 3 4256 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 4257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4258 | Radio ID | Num Levels | Power Level [n] | 4259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4261 Type: 13 for IEEE 802.11 Tx Power Level 4262 Length: >= 4 4263 Radio ID: An 8-bit value representing the radio to configure. 4264 Num Levels: The number of power level attributes. 4265 Power Level: Each power level fields contains a supported power 4266 level, in mW. 4268 11.6.7 IEEE 802.11 Direct Sequence Control 4270 The direct sequence control message element is a bi-directional 4271 element. When sent by the WTP, it contains the current state. When 4272 sent by the AC, the WTP MUST adhere to the values. This element is 4273 only used for 802.11b radios. The value has the following fields. 4275 0 1 2 3 4276 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 4277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4278 | Radio ID | Reserved | Current Chan | Current CCA | 4279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4280 | Energy Detect Threshold | 4281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4283 Type: 14 for IEEE 802.11 Direct Sequence Control 4284 Length: 8 4285 Radio ID: An 8-bit value representing the radio to configure. 4286 Reserved: MUST be set to zero 4287 Current Channel: This attribute contains the current operating 4288 frequency channel of the DSSS PHY. 4289 Current CCA: The current CCA method in operation. Valid values are: 4290 1 - energy detect only (edonly) 4291 2 - carrier sense only (csonly) 4292 4 - carrier sense and energy detect (edandcs) 4293 8 - carrier sense with timer (cswithtimer) 4294 16 - high rate carrier sense and energy detect (hrcsanded) 4295 Energy Detect Threshold: The current Energy Detect Threshold being 4296 used by the DSSS PHY. 4298 11.6.8 IEEE 802.11 OFDM Control 4300 The OFDM control message element is a bi-directional element. When 4301 sent by the WTP, it contains the current state. When sent by the AC, 4302 the WTP MUST adhere to the values. This element is only used for 4303 802.11a radios. The value contains the following fields: 4305 0 1 2 3 4306 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 4307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4308 | Radio ID | Reserved | Current Chan | Band Support | 4309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4310 | TI Threshold | 4311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4313 Type: 15 for IEEE 802.11 OFDM Control 4314 Length: 8 4315 Radio ID: An 8-bit value representing the radio to configure. 4316 Reserved: MUST be set to zero 4317 Current Channel: This attribute contains the current operating 4318 frequency channel of the OFDM PHY. 4319 Band Supported: The capability of the OFDM PHY implementation to 4320 operate in the three U-NII bands. Coded as an integer value of a 4321 three bit field as follows: 4323 capable of operating in the lower (5.15-5.25 GHz) U-NII band 4324 capable of operating in the middle (5.25-5.35 GHz) U-NII band 4325 capable of operating in the upper (5.725-5.825 GHz) U-NII band 4326 For example, for an implementation capable of operating in the 4327 lower and mid bands this attribute would take the value 4328 TI Threshold: The Threshold being used to detect a busy medium 4329 (frequency). CCA MUST report a busy medium upon detecting the 4330 RSSI above this threshold. 4332 11.6.9 IEEE 802.11 Antenna 4334 The antenna message element is communicated by the WTP to the AC to 4335 provide information on the antennas available. The AC MAY use this 4336 element to reconfigure the WTP's antennas. The value contains the 4337 following fields: 4339 0 1 2 3 4340 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 4341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4342 | Radio ID | Diversity | Combiner | Antenna Cnt | 4343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4344 | Antenna Selection [0..N] | 4345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4347 Type: 41 for IEEE 802.11 Antenna 4348 Length: >= 8 4349 Radio ID: An 8-bit value representing the radio to configure. 4350 Diversity: An 8-bit value specifying whether the antenna is to 4351 provide receive diversity. The following values are supported: 4352 0 - Disabled 4353 1 - Enabled (may only be true if the antenna can be used as a 4354 receive antenna) 4355 Combiner: An 8-bit value specifying the combiner selection. The 4356 following values are supported: 4357 1 - Sectorized (Left) 4358 2 - Sectorized (Right) 4359 3 - Omni 4360 4 - Mimo 4361 Antenna Count: An 8-bit value specifying the number of Antenna 4362 Selection fields. 4363 Antenna Selection: One 8-bit antenna configuration value per antenna 4364 in the WTP. The following values are supported: 4365 1 - Internal Antenna 4366 2 - External Antenna 4368 11.6.10 IEEE 802.11 Supported Rates 4370 The supported rates message element is sent by the WTP to indicate 4371 the rates that it supports. The value contains the following fields. 4373 0 1 2 3 4374 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 4375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4376 | Radio ID | Supported Rates | 4377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4379 Type: 16 for IEEE 802.11 Supported Rates 4380 Length: 4 4381 Radio ID: An 8-bit value representing the radio. 4382 Supported Rates: The WTP includes the Supported Rates that it's 4383 hardware supports. The format is identical to the Rate Set 4384 message element. 4386 11.6.11 IEEE 802.11 CFP Status 4388 The CFP Status message element is sent to provide the CF Polling 4389 configuration. 4391 0 1 4392 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4394 | Radio ID | Status | 4395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4397 Type: 48 for IEEE 802.11 CFP Status 4398 Length: 2 4399 Radio ID: The Radio Identifier, typically refers to some interface 4400 index on the WTP 4401 Status: An 8-bit boolean containing the status of the CF Polling 4402 feature. A value of zero disables CFP Status, while a value of 4403 one enables it. 4405 11.6.12 IEEE 802.11 WTP Mode and Type 4407 The WTP Mode and Type message element is used to configure an WTP to 4408 operate in a specific mode. 4410 0 1 4411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4413 | Mode | Type | 4414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4416 Type: 54 for IEEE 802.11 WTP Mode and Type 4417 Length: 2 4418 Mode: An 8-bit value the type of information being sent. The 4419 following values are supported: 4420 0 - Normal Mode 4421 1 - Monitoring Mode 4422 2 - REAP Mode 4423 3 - Rogue Detector Mode 4424 4 - Sniffer Mode 4425 Type: The type field is not currently used. 4427 11.6.13 IEEE 802.11 Broadcast Probe Mode 4429 The Broadcast Probe Mode message element indicates whether an WTP 4430 will respond to NULL SSID probe requests. Since broadcast NULL 4431 probes are not sent to a specific BSSID, the WTP cannot know which 4432 SSID the sending station is querying. Therefore, this behavior must 4433 be global to the WTP. 4435 0 4436 0 1 2 3 4 5 6 7 4437 +-+-+-+-+-+-+-+-+ 4438 | Status | 4439 +-+-+-+-+-+-+-+-+ 4441 Type: 51 for IEEE 802.11 Broadcast Probe Mode 4442 Length: 1 4443 Status: An 8-bit boolean indicating the status of whether an WTP 4444 shall response to a NULL SSID probe request. A value of zero 4445 disables NULL SSID probe response, while a value of one enables 4446 it. 4448 11.6.14 IEEE 802.11 WTP Quality of Service 4450 The WTP Quality of Service message element value is sent by the AC to 4451 the WTP to communicate quality of service configuration information. 4453 0 1 4454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4456 | Radio ID | Tag Packets | 4457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4459 Type: 57 for IEEE 802.11 WTP Quality of Service 4460 Length: 12 4461 Radio ID: The Radio Identifier, typically refers to some interface 4462 index on the WTP 4463 Tag Packets: An value indicating whether LWAPP packets should be 4464 tagged with for QoS purposes. The following values are currently 4465 supported: 4466 0 - Untagged 4467 1 - 802.1P 4468 2 - DSCP 4469 Immediately following the above header is the following data 4470 structure. This data structure will be repeated five times; once 4471 for every QoS profile. The order of the QoS profiles are Uranium, 4472 Platinum, Gold, Silver and Bronze. 4474 0 1 2 3 4475 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 4476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4477 | Queue Depth | CWMin | CWMax | 4478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4479 | CWMax | AIFS | CBR | 4480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4481 | Dot1P Tag | DSCP Tag | 4482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4484 Queue Depth: The number of packets that can be on the specific QoS 4485 transmit queue at any given time. 4486 CWMin: The Contention Window minimum value for the QoS transmit 4487 queue. 4488 CWMax: The Contention Window maximum value for the QoS transmit 4489 queue. 4490 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 4491 transmit queue. 4492 CBR: The CBR value to observe for the QoS transmit queue. 4493 Dot1P Tag: The 802.1P precedence value to use if packets are to be 4494 802.1P tagged. 4495 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 4497 11.6.15 IEEE 802.11 MIC Error Report From Mobile 4499 The MIC Error Report From Mobile message element is sent by an AC to 4500 an WTP when it receives a MIC failure notification, via the Error bit 4501 in the EAPOL-Key frame. 4503 0 1 2 3 4504 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 4505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4506 | Client MAC Address | 4507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4508 | Client MAC Address | BSSID | 4509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4510 | BSSID | 4511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4512 | Radio ID | WLAN ID | 4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4515 Type: 79 for IEEE 802.11 MIC Error Report From Mobile 4516 Length: 14 4517 Client MAC Address: The Client MAC Address of the station reporting 4518 the MIC failure. 4519 BSSID: The BSSID on which the MIC failure is being reported. 4520 Radio ID: The Radio Identifier, typically refers to some interface 4521 index on the WTP 4522 WLAN ID: The WLAN ID on which the MIC failure is being reported. 4524 11.7 IEEE 802.11 Message Element Values 4526 This section lists IEEE 802.11 specific values for any generic LWAPP 4527 message elements which include fields whose values are technology 4528 specific. 4530 IEEE 802.11 uses the following values: 4531 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 4532 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 4533 [15]. 4535 12. LWAPP Protocol Timers 4537 An WTP or AC that implements LWAPP discovery MUST implement the 4538 following timers. 4540 12.1 MaxDiscoveryInterval 4542 The maximum time allowed between sending discovery requests from the 4543 interface, in seconds. Must be no less than 2 seconds and no greater 4544 than 180 seconds. 4546 Default: 20 seconds. 4548 12.2 SilentInterval 4550 The minimum time, in seconds, an WTP MUST wait after failing to 4551 receive any responses to its discovery requests, before it MAY again 4552 send discovery requests. 4554 Default: 30 4556 12.3 NeighborDeadInterval 4558 The minimum time, in seconds, an WTP MUST wait without having 4559 received Echo Responses to its Echo Requests, before the destination 4560 for the Echo Request may be considered dead. Must be no less than 4561 2*EchoInterval seconds and no greater than 240 seconds. 4563 Default: 60 4565 12.4 EchoInterval 4567 The minimum time, in seconds, between sending echo requests to the AC 4568 with which the WTP has joined. 4570 Default: 30 4572 12.5 DiscoveryInterval 4574 The minimum time, in seconds, that an WTP MUST wait after receiving a 4575 Discovery Response, before sending a join request. 4577 Default: 5 4579 12.6 RetransmitInterval 4581 The minimum time, in seconds, which a non-acknowledged LWAPP packet 4582 will be retransmitted. 4584 Default: 3 4586 12.7 ResponseTimeout 4588 The minimum time, in seconds, which an LWAPP Request message must be 4589 responded to. 4591 Default: 1 4593 12.8 KeyLifetime 4595 The maximum time, in seconds, which an LWAPP session key is valid. 4597 Default: 28800 4599 13. LWAPP Protocol Variables 4601 An WTP or AC that implements LWAPP discovery MUST allow for the 4602 following variables to be configured by system management; default 4603 values are specified so as to make it unnecessary to configure any of 4604 these variables in many cases. 4606 13.1 MaxDiscoveries 4608 The maximum number of discovery requests that will be sent after an 4609 WTP boots. 4611 Default: 10 4613 13.2 DiscoveryCount 4615 The number of discoveries transmitted by a WTP to a single AC. This 4616 is a monotonically increasing counter. 4618 13.3 RetransmitCount 4620 The number of retransmissions for a given LWAPP packet. This is a 4621 monotonically increasing counter. 4623 13.4 MaxRetransmit 4625 The maximum number of retransmissions for a given LWAPP packet before 4626 the link layer considers the peer dead. 4628 Default: 5 4630 14. Security Considerations 4632 LWAPP uses either an authenticated key exchange or key agreement 4633 mechanism to ensure peer authenticity and establish fresh session 4634 keys to protect the LWAPP communications. 4636 Fresh keying material is ensured in certificated based construction 4637 as the AC generates new keying material in either the Join Response 4638 or Key Update Response (see RFC 1750 [4]. In the PSK construction 4639 both parties, WTP and AC mutually derive new keying material through 4640 the exchange of the nonces in the Join Request/Response exchange. 4641 The rekeys are ensured new keying material through the Key Update 4642 Response. 4644 It is important to note that Perfect Forward Secrecy is not a 4645 requirement for the LWAPP protocol. 4647 14.1 Certificate based Session Key establishment 4649 LWAPP uses public key cryptography to ensure trust between the WTP 4650 and the AC. During the Join phase, the AC generates a session key, 4651 which is used to secure future control messages. The WTP does not 4652 participate in the key generation, but public key cryptography is 4653 used to authenticate the resulting key material. A secured delivery 4654 mechanism to place the certificate in the devices is required. In 4655 order to maximize session key security, the WTP and AC periodically 4656 update the session keys, which are encrypted using public key 4657 cryptography. This ensures that a potentially previously compromised 4658 key does not affect the security of communication with new key 4659 material. 4661 One question that periodically arises is why the Join Request is not 4662 signed. It was felt that requiring a signature in this messages was 4663 not required for the following reasons: 4664 1. The Join Request is replayable, so requiring a signature doesn't 4665 provide much protection unless the switches keep track of all 4666 previous Join Requests from a given WTP. One alternative would 4667 have been to add a timestamp, but this introduces clock 4668 synchronization issues. Further, authentication occurs in a later 4669 exchange anyway (see point 2 below). 4670 2. The WTP is authenticated by virtue of the fact that it can 4671 decrypt and then use the session keys (encrypted with its own 4672 public key), so it *is* ultimately authenticated. 4673 3. A signed Join Request provides a potential Denial of Service 4674 attack on the AC, which would have to authenticate each 4675 (potentially malicious) message. 4677 The WTP-Certificate that is included in the Join Request MUST be 4678 validated by the AC. It is also good practice that the AC perform 4679 some form of authorization, ensuring that the WTP in question is 4680 allowed to establish an LWAPP session with it. 4682 14.2 PSK based Session Key establishment 4684 Use of a fixed shared secret of limited entropy (for example, a PSK 4685 that is relatively short, or was chosen by a human and thus may 4686 contain less entropy than its length would imply) may allow an 4687 attacker to perform a brute-force or dictionary attack to recover the 4688 secret. 4690 It is RECOMMENDED that implementations that allow the administrator 4691 to manually configure the PSK also provide a functionality for 4692 generating a new random PSK, taking RFC 1750 [4] into account. 4694 Since the key generation does not expose the nonces in plaintext, 4695 there are no practical passive attacks possible. 4697 15. IANA Considerations 4699 This document requires no action by IANA. 4701 16. IPR Statement 4703 The IETF has been notified of intellectual property rights claimed in 4704 regard to some or all of the specification contained in this 4705 document. For more information consult the online list of claimed 4706 rights. 4708 Please refer to http://www.ietf.org/ietf/IPR for more information. 4710 17. References 4712 17.1 Normative References 4714 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4715 Levels", BCP 14, RFC 2119, March 1997. 4717 [2] National Institute of Standards and Technology, "Advanced 4718 Encryption Standard (AES)", FIPS PUB 197, November 2001, 4719 . 4721 [3] Whiting, D., Housley, R. and N. Ferguson, "Counter with CBC-MAC 4722 (CCM)", RFC 3610, September 2003. 4724 [4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 4725 Recommendations for Security", RFC 1750, December 1994. 4727 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 4728 RFC 3753, June 2004. 4730 [6] "Information technology - Telecommunications and information 4731 exchange between systems - Local and metropolitan area networks 4732 - Specific requirements - Part 11: Wireless LAN Medium Access 4733 Control (MAC) and Physical Layer (PHY) specifications", 4734 IEEE Standard 802.11, 1999, 4735 4736 . 4738 [7] "Information technology - Telecommunications and information 4739 exchange between systems - Local and metropolitan area networks 4740 - Specific requirements - Part 11: Wireless LAN Medium Access 4741 Control (MAC) and Physical Layer (PHY) specifications Amendment 4742 6: Medium Access Control (MAC) Security Enhancements", 4743 IEEE Standard 802.11i, July 2004, 4744 . 4747 [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 4748 1982. 4750 [9] Stokes, E., Weiser, R., Moats, R. and R. Huber, "Lightweight 4751 Directory Access Protocol (version 3) Replication 4752 Requirements", RFC 3384, October 2002. 4754 [10] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) 4755 Key Wrap Algorithm", RFC 3394, September 2002. 4757 17.2 Informational References 4759 [11] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an 4760 On-line Database", RFC 3232, January 2002. 4762 [12] Bradner, S., "The Internet Standards Process -- Revision 3", 4763 BCP 9, RFC 2026, October 1996. 4765 [13] Kent, S. and R. Atkinson, "Security Architecture for the 4766 Internet Protocol", RFC 2401, November 1998. 4768 [14] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 4769 for Message Authentication", RFC 2104, February 1997. 4771 [15] "WiFi Protected Access (WPA) rev 1.6", April 2003. 4773 Authors' Addresses 4775 Pat R. Calhoun 4776 Airespace 4777 110 Nortech Parkway 4778 San Jose, CA 95134 4780 Phone: +1 408-635-2000 4781 Email: pcalhoun@airespace.com 4783 Bob O'Hara 4784 Airespace 4785 110 Nortech Parkway 4786 San Jose, CA 95134 4788 Phone: +1 408-635-2025 4789 Email: bob@airespace.com 4791 Scott Kelly 4792 Facetime Communications 4793 1159 Triton Dr 4794 Foster City, CA 94404 4796 Phone: +1 650 572-5846 4797 Email: scott@hyperthought.com 4798 Rohit Suri 4799 Airespace 4800 110 Nortech Parkway 4801 San Jose, CA 95134 4803 Phone: +1 408-635-2026 4804 Email: rsuri@airespace.com 4806 Michael Glenn Williams 4807 Nokia, Inc. 4808 313 Fairchild Drive 4809 Mountain View, CA 94043 4811 Phone: +1 650-714-7758 4812 Email: Michael.G.Williams@Nokia.com 4814 Sue Hares 4815 Nexthop Technologies, Inc. 4816 825 Victors Way, Suite 100 4817 Ann Arbor, MI 48108 4819 Phone: +1 734 222 1610 4820 Email: shares@nexthop.com 4822 Nancy 4823 Cisco Systems, Inc. 4824 170 West Tasman Drive 4825 San Jose, CA 95134 4827 Phone: +1 408-853-0532 4828 Email: ncamwing@cisco.com 4830 Intellectual Property Statement 4832 The IETF takes no position regarding the validity or scope of any 4833 Intellectual Property Rights or other rights that might be claimed to 4834 pertain to the implementation or use of the technology described in 4835 this document or the extent to which any license under such rights 4836 might or might not be available; nor does it represent that it has 4837 made any independent effort to identify any such rights. Information 4838 on the procedures with respect to rights in RFC documents can be 4839 found in BCP 78 and BCP 79. 4841 Copies of IPR disclosures made to the IETF Secretariat and any 4842 assurances of licenses to be made available, or the result of an 4843 attempt made to obtain a general license or permission for the use of 4844 such proprietary rights by implementers or users of this 4845 specification can be obtained from the IETF on-line IPR repository at 4846 http://www.ietf.org/ipr. 4848 The IETF invites any interested party to bring to its attention any 4849 copyrights, patents or patent applications, or other proprietary 4850 rights that may cover technology that may be required to implement 4851 this standard. Please address the information to the IETF at 4852 ietf-ipr@ietf.org. 4854 Disclaimer of Validity 4856 This document and the information contained herein are provided on an 4857 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4858 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4859 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4860 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4861 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4862 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4864 Copyright Statement 4866 Copyright (C) The Internet Society (2005). This document is subject 4867 to the rights, licenses and restrictions contained in BCP 78, and 4868 except as set forth therein, the authors retain all their rights. 4870 Acknowledgment 4872 Funding for the RFC Editor function is currently provided by the 4873 Internet Society.