idnits 2.17.1 draft-ohara-capwap-lwapp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5833. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. == There is 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 4441 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 (June 24, 2005) is 6881 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 5688, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 5743, but no explicit reference was found in the text -- 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 3394 (ref. '9') ** Obsolete normative reference: RFC 3280 (ref. '10') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '16') (Obsoleted by RFC 4301) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 14 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: December 26, 2005 R. Suri 5 N. Cam Winget 6 Cisco Systems, Inc. 7 S. Kelly 8 Facetime Communications 9 M. Williams 10 Nokia, Inc. 11 S. Hares 12 Nexthop Technologies, Inc. 13 June 24, 2005 15 Light Weight Access Point Protocol 16 draft-ohara-capwap-lwapp-03.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on December 26, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 In the recent years, there has been a shift in wireless LAN product 49 architectures from autonomous access points to centralized control of 50 light weight access points. The general goal has been to move most 51 of the traditional wireless functionality such as access control 52 (user authentication and authorization), mobility and radio 53 management out of the access point into a centralized controller. 55 The IETF's CAPWAP WG has identified that a standards based protocol 56 is necessary between a wireless Access Controller and Wireless 57 Termination Points (the latter are also commonly referred to as Light 58 Weight Access Points). This specification defines the Light Weight 59 Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol 60 requirements. Although the LWAPP protocol is designed to be flexible 61 enough to be used for a variety of wireless technologies, this 62 specific document describes the base protocol, and an extension that 63 allows it to be used with the IEEE's 802.11 wireless LAN protocol. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1.1 Conventions used in this document . . . . . . . . . . . 9 69 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 10 70 2.1 Wireless Binding Definition . . . . . . . . . . . . . . 11 71 2.2 LWAPP State Machine Definition . . . . . . . . . . . . . 12 72 3. LWAPP Transport Layers . . . . . . . . . . . . . . . . . . . 21 73 3.1 LWAPP Transport Header . . . . . . . . . . . . . . . . . 21 74 3.1.1 VER Field . . . . . . . . . . . . . . . . . . . . . 21 75 3.1.2 RID Field . . . . . . . . . . . . . . . . . . . . . 21 76 3.1.3 C Bit . . . . . . . . . . . . . . . . . . . . . . . 21 77 3.1.4 F Bit . . . . . . . . . . . . . . . . . . . . . . . 21 78 3.1.5 L Bit . . . . . . . . . . . . . . . . . . . . . . . 22 79 3.1.6 Fragment ID . . . . . . . . . . . . . . . . . . . . 22 80 3.1.7 Length . . . . . . . . . . . . . . . . . . . . . . . 22 81 3.1.8 Status and WLANS . . . . . . . . . . . . . . . . . . 22 82 3.1.9 Payload . . . . . . . . . . . . . . . . . . . . . . 22 83 3.2 Using IEEE 802.3 MAC as LWAPP transport . . . . . . . . 22 84 3.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . 23 85 3.2.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 23 86 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC 87 transport . . . . . . . . . . . . . . . . . . . . . 23 88 3.2.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 23 89 3.2.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 24 90 3.3 Using IP/UDP as LWAPP transport . . . . . . . . . . . . 24 91 3.3.1 Framing . . . . . . . . . . . . . . . . . . . . . . 24 92 3.3.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 24 93 3.3.3 LWAPP Message Header format over IP/UDP transport . 25 94 3.3.4 Fragmentation/Reassembly for IPv4 . . . . . . . . . 26 95 3.3.5 Fragmentation/Reassembly for IPv6 . . . . . . . . . 26 96 3.3.6 Multiplexing . . . . . . . . . . . . . . . . . . . . 26 97 4. LWAPP Packet Definitions . . . . . . . . . . . . . . . . . . 27 98 4.1 LWAPP Data Messages . . . . . . . . . . . . . . . . . . 27 99 4.2 LWAPP Control Messages Overview . . . . . . . . . . . . 27 100 4.2.1 Control Message Format . . . . . . . . . . . . . . . 28 101 4.2.2 Message Element Format . . . . . . . . . . . . . . . 30 102 4.2.3 Quality of Service . . . . . . . . . . . . . . . . . 31 103 5. LWAPP Discovery Operations . . . . . . . . . . . . . . . . . 32 104 5.1 Discovery Request . . . . . . . . . . . . . . . . . . . 32 105 5.1.1 Discovery Type . . . . . . . . . . . . . . . . . . . 33 106 5.1.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 33 107 5.1.3 WTP Radio Information . . . . . . . . . . . . . . . 34 108 5.2 Discovery Response . . . . . . . . . . . . . . . . . . . 35 109 5.2.1 AC Address . . . . . . . . . . . . . . . . . . . . . 35 110 5.2.2 AC Descriptor . . . . . . . . . . . . . . . . . . . 36 111 5.2.3 AC Name . . . . . . . . . . . . . . . . . . . . . . 37 112 5.2.4 WTP Manager Control IPv4 Address . . . . . . . . . . 37 113 5.2.5 WTP Manager Control IPv6 Address . . . . . . . . . . 38 114 5.3 Primary Discovery Request . . . . . . . . . . . . . . . 38 115 5.3.1 Discovery Type . . . . . . . . . . . . . . . . . . . 39 116 5.3.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 39 117 5.3.3 WTP Radio Information . . . . . . . . . . . . . . . 39 118 5.4 Primary Discovery Response . . . . . . . . . . . . . . . 39 119 5.4.1 AC Descriptor . . . . . . . . . . . . . . . . . . . 39 120 5.4.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 40 121 5.4.3 WTP Manager Control IPv4 Address . . . . . . . . . . 40 122 5.4.4 WTP Manager Control IPv6 Address . . . . . . . . . . 40 123 6. Control Channel Management . . . . . . . . . . . . . . . . . 41 124 6.1 Join Request . . . . . . . . . . . . . . . . . . . . . . 41 125 6.1.1 WTP Descriptor . . . . . . . . . . . . . . . . . . . 42 126 6.1.2 AC Address . . . . . . . . . . . . . . . . . . . . . 42 127 6.1.3 WTP Name . . . . . . . . . . . . . . . . . . . . . . 42 128 6.1.4 Location Data . . . . . . . . . . . . . . . . . . . 42 129 6.1.5 WTP Radio Information . . . . . . . . . . . . . . . 43 130 6.1.6 Certificate . . . . . . . . . . . . . . . . . . . . 43 131 6.1.7 Session ID . . . . . . . . . . . . . . . . . . . . . 43 132 6.1.8 Test . . . . . . . . . . . . . . . . . . . . . . . . 44 133 6.1.9 XNonce . . . . . . . . . . . . . . . . . . . . . . . 44 134 6.2 Join Response . . . . . . . . . . . . . . . . . . . . . 44 135 6.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 45 136 6.2.2 Status . . . . . . . . . . . . . . . . . . . . . . . 46 137 6.2.3 Certificate . . . . . . . . . . . . . . . . . . . . 46 138 6.2.4 WTP Manager Data IPv4 Address . . . . . . . . . . . 46 139 6.2.5 WTP Manager Data IPv6 Address . . . . . . . . . . . 47 140 6.2.6 AC IPv4 List . . . . . . . . . . . . . . . . . . . . 47 141 6.2.7 AC IPv6 List . . . . . . . . . . . . . . . . . . . . 48 142 6.2.8 ANonce . . . . . . . . . . . . . . . . . . . . . . . 48 143 6.2.9 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 49 144 6.3 Join ACK . . . . . . . . . . . . . . . . . . . . . . . . 50 145 6.3.1 Session ID . . . . . . . . . . . . . . . . . . . . . 50 146 6.3.2 WNonce . . . . . . . . . . . . . . . . . . . . . . . 50 147 6.3.3 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 51 148 6.4 Join Confirm . . . . . . . . . . . . . . . . . . . . . . 51 149 6.4.1 Session ID . . . . . . . . . . . . . . . . . . . . . 51 150 6.4.2 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 52 151 6.5 Echo Request . . . . . . . . . . . . . . . . . . . . . . 52 152 6.6 Echo Response . . . . . . . . . . . . . . . . . . . . . 52 153 6.7 Key Update Request . . . . . . . . . . . . . . . . . . . 52 154 6.7.1 Session ID . . . . . . . . . . . . . . . . . . . . . 53 155 6.7.2 XNonce . . . . . . . . . . . . . . . . . . . . . . . 53 156 6.8 Key Update Response . . . . . . . . . . . . . . . . . . 53 157 6.8.1 Session ID . . . . . . . . . . . . . . . . . . . . . 53 158 6.8.2 ANonce . . . . . . . . . . . . . . . . . . . . . . . 53 159 6.8.3 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 53 160 6.9 Key Update ACK . . . . . . . . . . . . . . . . . . . . . 53 161 6.9.1 WNonce . . . . . . . . . . . . . . . . . . . . . . . 54 162 6.9.2 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 54 163 6.10 Key Update Confirm . . . . . . . . . . . . . . . . . . . 54 164 6.10.1 PSK-MIC . . . . . . . . . . . . . . . . . . . . . . 54 165 6.11 Key Update Trigger . . . . . . . . . . . . . . . . . . . 54 166 6.11.1 Session ID . . . . . . . . . . . . . . . . . . . . . 54 167 7. WTP Configuration Management . . . . . . . . . . . . . . . . 55 168 7.1 Configuration Consistency . . . . . . . . . . . . . . . 55 169 7.2 Configure Request . . . . . . . . . . . . . . . . . . . 56 170 7.2.1 Administrative State . . . . . . . . . . . . . . . . 56 171 7.2.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 57 172 7.2.3 AC Name with Index . . . . . . . . . . . . . . . . . 57 173 7.2.4 WTP Board Data . . . . . . . . . . . . . . . . . . . 57 174 7.2.5 Statistics Timer . . . . . . . . . . . . . . . . . . 58 175 7.2.6 WTP Static IP Address Information . . . . . . . . . 59 176 7.2.7 WTP Reboot Statistics . . . . . . . . . . . . . . . 59 177 7.3 Configure Response . . . . . . . . . . . . . . . . . . . 60 178 7.3.1 Decryption Error Report Period . . . . . . . . . . . 61 179 7.3.2 Change State Event . . . . . . . . . . . . . . . . . 61 180 7.3.3 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 62 181 7.3.4 AC IPv4 List . . . . . . . . . . . . . . . . . . . . 62 182 7.3.5 AC IPv6 List . . . . . . . . . . . . . . . . . . . . 63 183 7.3.6 WTP Fallback . . . . . . . . . . . . . . . . . . . . 63 184 7.3.7 Idle Timeout . . . . . . . . . . . . . . . . . . . . 63 185 7.4 Configuration Update Request . . . . . . . . . . . . . . 64 186 7.4.1 WTP Name . . . . . . . . . . . . . . . . . . . . . . 64 187 7.4.2 Change State Event . . . . . . . . . . . . . . . . . 64 188 7.4.3 Administrative State . . . . . . . . . . . . . . . . 64 189 7.4.4 Statistics Timer . . . . . . . . . . . . . . . . . . 64 190 7.4.5 Location Data . . . . . . . . . . . . . . . . . . . 64 191 7.4.6 Decryption Error Report Period . . . . . . . . . . . 64 192 7.4.7 AC IPv4 List . . . . . . . . . . . . . . . . . . . . 64 193 7.4.8 AC IPv6 List . . . . . . . . . . . . . . . . . . . . 65 194 7.4.9 Add Blacklist Entry . . . . . . . . . . . . . . . . 65 195 7.4.10 Delete Blacklist Entry . . . . . . . . . . . . . . . 65 196 7.4.11 Add Static Blacklist Entry . . . . . . . . . . . . . 66 197 7.4.12 Delete Static Blacklist Entry . . . . . . . . . . . 66 198 7.4.13 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 67 199 7.4.14 AC Name with Index . . . . . . . . . . . . . . . . . 67 200 7.4.15 WTP Fallback . . . . . . . . . . . . . . . . . . . . 67 201 7.4.16 Idle Timeout . . . . . . . . . . . . . . . . . . . . 67 202 7.5 Configuration Update Response . . . . . . . . . . . . . 67 203 7.5.1 Result Code . . . . . . . . . . . . . . . . . . . . 68 204 7.6 Change State Event Request . . . . . . . . . . . . . . . 68 205 7.6.1 Change State Event . . . . . . . . . . . . . . . . . 68 206 7.7 Change State Event Response . . . . . . . . . . . . . . 68 207 7.8 Clear Config Indication . . . . . . . . . . . . . . . . 68 208 8. Device Management Operations . . . . . . . . . . . . . . . . 70 209 8.1 Image Data Request . . . . . . . . . . . . . . . . . . . 70 210 8.1.1 Image Download . . . . . . . . . . . . . . . . . . . 70 211 8.1.2 Image Data . . . . . . . . . . . . . . . . . . . . . 70 212 8.2 Image Data Response . . . . . . . . . . . . . . . . . . 71 213 8.3 Reset Request . . . . . . . . . . . . . . . . . . . . . 71 214 8.4 Reset Response . . . . . . . . . . . . . . . . . . . . . 71 215 8.5 WTP Event Request . . . . . . . . . . . . . . . . . . . 72 216 8.5.1 Decryption Error Report . . . . . . . . . . . . . . 72 217 8.5.2 Duplicate IPv4 Address . . . . . . . . . . . . . . . 72 218 8.5.3 Duplicate IPv6 Address . . . . . . . . . . . . . . . 73 219 8.6 WTP Event Response . . . . . . . . . . . . . . . . . . . 74 220 8.7 Data Transfer Request . . . . . . . . . . . . . . . . . 74 221 8.7.1 Data Transfer Mode . . . . . . . . . . . . . . . . . 74 222 8.7.2 Data Transfer Data . . . . . . . . . . . . . . . . . 75 223 8.8 Data Transfer Response . . . . . . . . . . . . . . . . . 75 224 9. Mobile Session Management . . . . . . . . . . . . . . . . . 77 225 9.1 Mobile Config Request . . . . . . . . . . . . . . . . . 77 226 9.1.1 Delete Mobile . . . . . . . . . . . . . . . . . . . 77 227 9.2 Mobile Config Response . . . . . . . . . . . . . . . . . 78 228 9.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 78 229 10. LWAPP Security . . . . . . . . . . . . . . . . . . . . . . 79 230 10.1 Securing WTP-AC communications . . . . . . . . . . . . . 79 231 10.2 LWAPP Frame Encryption . . . . . . . . . . . . . . . . . 80 232 10.3 Authenticated Key Exchange . . . . . . . . . . . . . . . 80 233 10.3.1 Terminology . . . . . . . . . . . . . . . . . . . . 81 234 10.3.2 Initial Key Generation . . . . . . . . . . . . . . . 82 235 10.3.3 Refreshing Cryptographic Keys . . . . . . . . . . . 86 236 10.4 Certificate Usage . . . . . . . . . . . . . . . . . . . 87 237 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . 88 238 11.1 Division of labor . . . . . . . . . . . . . . . . . . . 88 239 11.1.1 Split MAC . . . . . . . . . . . . . . . . . . . . . 88 240 11.1.2 Local MAC . . . . . . . . . . . . . . . . . . . . . 90 241 11.2 Roaming Behavior and 802.11 security . . . . . . . . . . 93 242 11.3 Transport specific bindings . . . . . . . . . . . . . . 94 243 11.3.1 Status and WLANS field . . . . . . . . . . . . . . . 94 244 11.4 BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 95 245 11.5 Quality of Service . . . . . . . . . . . . . . . . . . . 95 246 11.6 Data Message bindings . . . . . . . . . . . . . . . . . 95 247 11.7 Control Message bindings . . . . . . . . . . . . . . . . 95 248 11.7.1 Mobile Config Request . . . . . . . . . . . . . . . 96 249 11.7.2 WTP Event Request . . . . . . . . . . . . . . . . . 102 250 11.8 802.11 Control Messages . . . . . . . . . . . . . . . . 104 251 11.8.1 IEEE 802.11 WLAN Config Request . . . . . . . . . . 104 252 11.8.2 IEEE 802.11 WLAN Config Response . . . . . . . . . . 109 253 11.8.3 IEEE 802.11 WTP Event . . . . . . . . . . . . . . . 109 254 11.9 Message Element Bindings . . . . . . . . . . . . . . . . 111 255 11.9.1 IEEE 802.11 WTP WLAN Radio Configuration . . . . . . 111 256 11.9.2 IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 113 257 11.9.3 IEEE 802.11 Multi-domain Capability . . . . . . . . 114 258 11.9.4 IEEE 802.11 MAC Operation . . . . . . . . . . . . . 114 259 11.9.5 IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 116 260 11.9.6 IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 117 261 11.9.7 IEEE 802.11 Direct Sequence Control . . . . . . . . 117 262 11.9.8 IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 118 263 11.9.9 IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 119 264 11.9.10 IEEE 802.11 Supported Rates . . . . . . . . . . . 120 265 11.9.11 IEEE 802.11 CFP Status . . . . . . . . . . . . . . 120 266 11.9.12 IEEE 802.11 WTP Mode and Type . . . . . . . . . . 121 267 11.9.13 IEEE 802.11 Broadcast Probe Mode . . . . . . . . . 121 268 11.9.14 IEEE 802.11 WTP Quality of Service . . . . . . . . 122 269 11.9.15 IEEE 802.11 MIC Error Report From Mobile . . . . . 123 270 11.10 IEEE 802.11 Message Element Values . . . . . . . . . . 124 271 12. LWAPP Protocol Timers . . . . . . . . . . . . . . . . . . 125 272 12.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 125 273 12.2 SilentInterval . . . . . . . . . . . . . . . . . . . . . 125 274 12.3 NeighborDeadInterval . . . . . . . . . . . . . . . . . . 125 275 12.4 EchoInterval . . . . . . . . . . . . . . . . . . . . . . 125 276 12.5 DiscoveryInterval . . . . . . . . . . . . . . . . . . . 125 277 12.6 RetransmitInterval . . . . . . . . . . . . . . . . . . . 125 278 12.7 ResponseTimeout . . . . . . . . . . . . . . . . . . . . 126 279 12.8 KeyLifetime . . . . . . . . . . . . . . . . . . . . . . 126 280 13. LWAPP Protocol Variables . . . . . . . . . . . . . . . . . 127 281 13.1 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 127 282 13.2 DiscoveryCount . . . . . . . . . . . . . . . . . . . . . 127 283 13.3 RetransmitCount . . . . . . . . . . . . . . . . . . . . 127 284 13.4 MaxRetransmit . . . . . . . . . . . . . . . . . . . . . 127 285 14. NAT Considerations . . . . . . . . . . . . . . . . . . . . 128 286 15. Security Considerations . . . . . . . . . . . . . . . . . 130 287 15.1 Certificate based Session Key establishment . . . . . . 131 288 15.2 PSK based Session Key establishment . . . . . . . . . . 131 289 16. IANA Considerations . . . . . . . . . . . . . . . . . . . 132 290 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 133 291 18. IPR Statement . . . . . . . . . . . . . . . . . . . . . . 134 292 19. References . . . . . . . . . . . . . . . . . . . . . . . . 135 293 19.1 Normative References . . . . . . . . . . . . . . . . . . 135 294 19.2 Informational References . . . . . . . . . . . . . . . . 136 295 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 136 296 Intellectual Property and Copyright Statements . . . . . . . 138 298 1. Introduction 300 Unlike wired network elements, Wireless Termination Points (WTPs) 301 require a set of dynamic management and control functions related to 302 their primary task of connecting the wireless and wired mediums. 303 Today, protocols for managing WTPs are either manual static 304 configuration via HTTP, proprietary Layer 2 specific or non-existent 305 (if the WTPs are self-contained). The emergence of simple 802.11 306 WTPs that are managed by a WLAN appliance or switch (also known as an 307 Access Controller, or AC) suggests that having a standardized, 308 interoperable protocol could radically simplify the deployment and 309 management of wireless networks. In many cases the overall control 310 and management functions themselves are generic and could apply to an 311 AP for any wireless Layer 2 protocol. Being independent of specific 312 wireless Layer 2 technologies, such a protocol could better support 313 interoperability between Layer 2 devices and enable smoother 314 intertechnology handovers. 316 The details of how these functions would be implemented are dependent 317 on the particular Layer 2 wireless technology. Such a protocol would 318 need provisions for binding to specific technologies. 320 LWAPP assumes a network configuration that consists of multiple WTPs 321 communicating either via layer 2 (MAC) or layer 3 (IP) to an AC. The 322 WTPs can be considered as remote RF interfaces, being controlled by 323 the AC. The AC forwards all L2 frames it wants to transmit to an WTP 324 via the LWAPP protocol. Packets from mobile nodes are forwarded by 325 the WTP to the AC, also via this protocol. Figure 1 illustrates this 326 arrangement as applied to an IEEE 802.11 binding. 328 +-+ 802.11frames +-+ 329 | |--------------------------------| | 330 | | +-+ | | 331 | |--------------| |---------------| | 332 | | 802.11 PHY/ | | LWAPP | | 333 | | MAC sublayer | | | | 334 +-+ +-+ +-+ 335 STA WTP AC 337 Figure 1: LWAPP Architecture 339 Security is another aspect of Wireless Termination Point management 340 that is not well served by existing solutions. Provisioning WTPs 341 with security credentials, and managing which WTPs are authorized to 342 provide service are today handled by proprietary solutions. Allowing 343 these functions to be performed from a centralized AC in an 344 interoperable fashion increases managability and allows network 345 operators to more tightly control their wireless network 346 infrastructure. 348 This document describes the Light Weight Access Point Protocol 349 (LWAPP), allowing an AC to manage a collection of WTPs. The protocol 350 is defined to be independent of Layer 2 technology, but an 802.11 351 binding is provided for use in growing 802.11 wireless LAN networks. 353 Goals 355 The following are goals for this protocol: 357 1. Centralization of the bridging, forwarding, authentication and 358 policy enforcement functions for a wireless network. Optionally, 359 the AC may also provide centralized encryption of user traffic. 360 This will permit reduced cost and higher efficiency when applying 361 the capabilities of network processing silicon to the wireless 362 network, as it has already been applied to wired LANs. 364 2. Permit shifting of the higher level protocol processing burden 365 away from the WTP. This leaves the computing resource of the WTP 366 to the timing critical applications of wireless control and 367 access. This makes the most efficient use of the computing power 368 available in WTPs that are the subject of severe cost pressure. 370 3. Providing a generic encapsulation and transport mechanism, the 371 protocol may be applied to other access point type in the future 372 by adding the binding. 374 The LWAPP protocol concerns itself solely with the interface between 375 the WTP and the AC. Inter-AC, or mobile to AC communication is 376 strictly outside the scope of this document. 378 1.1 Conventions used in this document 380 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 381 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 382 document are to be interpreted as described in RFC 2119 [1]. 384 2. Protocol Overview 386 LWAPP is a generic protocol defining how Wireless Termination Points 387 communicate with Access Controllers. Wireless Termination Points and 388 Access Controllers may communicate either by means of Layer 2 389 protocols or by means of a routed IP network. 391 LWAPP messages and procedures defined in this document apply to both 392 types of transports unless specified otherwise. Transport 393 independence is achieved by defining formats for both MAC level and 394 IP level transport (see Section 3). Also defined are framing, 395 fragmentation/reassembly, and multiplexing services to LWAPP for each 396 transport type. 398 The LWAPP Transport layer carries two types of payload. LWAPP Data 399 Messages are forwarded wireless frames. LWAPP Control Messages are 400 management messages exchanged between an WTP and an AC. The LWAPP 401 transport header defines the "C-bit", which is used to distinguish 402 data and control traffic. When used over IP, the LWAPP data and 403 control traffic are also sent over separate UDP ports. Since both 404 data and control frames can exceed PMTU, the payload of an LWAPP data 405 or control message can be fragmented. The fragmentation behavior is 406 highly dependent upon the lower layer transport and is defined in 407 Section 3. 409 The Light Weight Access Protocol (LWAPP) begins with a discovery 410 phase. The WTPs send a Discovery Request frame, causing any Access 411 Controller (AC) , receiving that frame to respond with a Discovery 412 Response. From the Discovery Responses received, an WTP will select 413 an AC with which to associate, using the Join Request and Join 414 Response. The Join Request also provides an MTU discovery mechanism, 415 to determine whether there is support for the transport of large 416 frames between the WTP and it's AC. If support for large frames is 417 not present, the LWAPP frames will be fragmented to the maximum 418 length discovered to be supported by the network. 420 Once the WTP and the AC have joined, a configuration exchange is 421 accomplished that will cause both devices to agree on version 422 information. During this exchange the WTP may receive provisioning 423 settings. For the 802.11 binding, this information would typically 424 include a name (802.11 Service Set Identifier, SSID), and security 425 parameters, the data rates to be advertised as well as the radio 426 channel (channels, if the WTP is capable of operating more than one 427 802.11 MAC and PHY simultaneously) to be used. Finally, the WTPs are 428 enabled for operation. 430 When the WTP and AC have completed the version and provision exchange 431 and the WTP is enabled, the LWAPP encapsulates the wireless frames 432 sent between them. LWAPP will fragment its packets, if the size of 433 the encapsulated wireless user data (Data) or protocol control 434 (Management) frames causes the resultant LWAPP packet to exceed the 435 MTU supported between the WTP and AC. Fragmented LWAPP packets are 436 reassembled to reconstitute the original encapsulated payload. 438 In addition to the functions thus far described, LWAPP also provides 439 for the delivery of commands from the AC to the WTP for the 440 management of devices that are communicating with the WTP. This may 441 include the creation of local data structures in the WTP for the 442 managed devices and the collection of statistical information about 443 the communication between the WTP and the 802.11 devices. LWAPP 444 provides the ability for the AC to obtain any statistical information 445 collected by the WTP. 447 LWAPP also provides for a keep alive feature that preserves the 448 communication channel between the WTP and AC. If the AC fails to 449 appear alive, the WTP will try to discover a new AC to communicate 450 through. 452 This Document uses terminology defined in [5] 454 2.1 Wireless Binding Definition 456 This draft standard specifies a protocol independent of a specific 457 wireless access point radio technology. Elements of the protocol are 458 designed to accommodate specific needs of each wireless technology in 459 a standard way. Implementation of this standard for a particular 460 wireless technology must follow the binding requirements defined for 461 that technology. This specification includes a binding for the IEEE 462 802.11 (see Section 11). 464 When defining a binding for other technologies, the authors MUST 465 include any necessary definitions for technology-specific messages 466 and all technology-specific message elements for those messages. At 467 a minimum, a binding MUST provide the definition for a binding- 468 specific Statistics message element, which is carried in the WTP 469 Event Request message, and Add Mobile message element, which is 470 carried in the Mobile Configure Request. If any technology specific 471 message elements are required for any of the existing LWAPP messages 472 defined in this specification, they MUST also be defined in the 473 technology binding document. 475 The naming of binding-specific message elements MUST begin with the 476 name of the technology type, e.g., the binding for IEEE 802.11, 477 provided in this standard, begins with "IEEE 802.11"." 479 2.2 LWAPP State Machine Definition 481 The following state diagram represents the lifecycle of an WTP-AC 482 session: 484 /-------------\ 485 | v 486 | +------------+ 487 | C| Idle |<-----------------------------------\ 488 | +------------+<-----------------------\ | 489 | ^ |a ^ | | 490 | | | \----\ | | 491 | | | | +------------+ | 492 | | | | -------| Key Confirm| | 493 | | | | w/ +------------+ | 494 | | | | | ^ | 495 | | | |t V |5 | 496 | | | +-----------+ +------------+ | 497 | / | C| Run | | Key Update | | 498 | / | r+-----------+------>+------------+ | 499 | / | ^ |s u x| | 500 | | v | | | | 501 | | +--------------+ | | v |y 502 | | C| Discovery | q| \--------------->+-------+ 503 | | b+--------------+ +-------------+ | Reset | 504 | | |d f| ^ | Configure |------->+-------+ 505 | | | | | +-------------+p ^ 506 | |e v | | ^ | 507 | +---------+ v |i 2| | 508 | C| Sulking | +------------+ +--------------+ | 509 | +---------+ C| Join |--->| Join-Confirm | | 510 | g+------------+z +--------------+ | 511 | |h m| 3| |4 | 512 | | | | v |o 513 |\ | | | +------------+ 514 \\-----------------/ \--------+---->| Image Data |C 515 \------------------------------------/ +------------+n 517 Figure 2: LWAPP State Machine 519 The LWAPP state machine, depicted above, is used by both the AC and 520 the WTP. For every state defined, only certain messages are 521 permitted to be sent and received. In all of the LWAPP control 522 messages defined in this document, the state for which each command 523 is valid is specified. 525 Note that in the state diagram figure above, the 'C' character is 526 used to represent a condition that causes the state to remain the 527 same. 529 The following text discusses the various state transitions, and the 530 events that cause them. 532 Idle to Discovery (a): This is the initialization state. 534 WTP: The WTP enters the Discovery state prior to transmitting the 535 first Discovery Request (see Section 5.1). Upon entering this 536 state, the WTP sets the DiscoveryInterval timer (see 537 Section 12). The WTP resets the DiscoveryCount counter to zero 538 (0) (see Section 13). The WTP also clears all information from 539 ACs (e.g., AC Addresses) it may have received during a previous 540 Discovery phase. 542 AC: The AC does not need to maintain state information for the WTP 543 upon reception of the Discovery Request, but it MUST respond 544 with a Discovery Response (see Section 5.2). 546 Discovery to Discovery (b): This is the state the WTP uses to 547 determine which AC it wishes to connect to. 549 WTP: This event occurs when the DiscoveryInterval timer expires. 550 The WTP transmits a Discovery Request to every AC which the WTP 551 hasn't received a response to. For every transition to this 552 event, the WTP increments DisoveryCount counter. See 553 Section 5.1) for more information on how the WTP knows which 554 ACs it should transmit the Discovery Requests to. The WTP 555 restarts the DiscoveryInterval timer. 557 AC: This is a noop. 559 Discovery to Sulking (d): This state occurs on a WTP when Discovery 560 or connectivity to the AC fails. 562 WTP: The WTP enters this state when the DiscoveryInterval timer 563 expires and the DiscoveryCount variable is equal to the 564 MaxDiscoveries variable (see Section 13). Upon entering this 565 state, the WTP will start the SilentInterval timer. While in 566 the Sulking state, all LWAPP messages received are ignored. 568 AC: This is a noop. 570 Sulking to Idle (e): This state occurs on a WTP when it must restart 571 the discovery phase. 573 WTP: The WTP enters this state when the SilentInterval timer (see 574 Section 12) expires. 576 AC: This is a noop. 578 Discovery to Join (f): This state is used by the WTP to confirm its 579 commitment to an AC that it wishes to be provided service. 581 WTP: The WTP selects the best AC based on the information it 582 gathered during the Discovery Phase. It then transmits a Join 583 Request (see Section 6.1 to its preferred AC. The WTP starts 584 the WaitJoin Timer (see Section 12). 586 AC: The AC enters this state for the given WTP upon reception of a 587 Join Request. The AC processes the request and responds with a 588 Join Response. 590 Join to Join (g): This state transition occurs during the join phase. 592 WTP: The WTP enters this state when the WaitJoin timer expires, 593 and the underlying transport requires LWAPP MTU detection 594 Section 3). 596 AC: This state occurs when the AC receives a retransmission of a 597 Join Request. The AC processes the request and responds with 598 the Join Response.. 600 Join to Idle (h): This state is used when the join process failed. 602 WTP: This state transition occurs if the WTP is configured to use 603 PSK security and receives a Join Response that includes an 604 invalid PSK-MIC message element. 606 AC: The AC enters this state when it transmits an unsuccessful 607 Join Response. 609 Join to Discovery (i): This state is used when the join process 610 failed. 612 WTP: The WTP enters this state when it receives an unsuccessful 613 Join Response. Upon entering this state, the WTP sets the 614 DiscoveryInterval timer (see Section 12). The WTP resets the 615 DiscoveryCount counter to zero (0) (see Section 13). This 616 state transition may also occur if the PSK-MIC (see 617 Section 6.2.9) message element is invalid. 619 AC: This state transition is invalid. 621 Join to Join-Confirm (z): This state is used to provide key 622 confirmation during the join process. 624 WTP: This state is entered when the WTP receives a Join Response. 625 In the event that certificate based security is utilized, this 626 transition will occur if the Certificate message element is 627 present and valid in the Join Response. For pre-shared key 628 security, the Join Response must include a valdd and 629 authenticated PSK-MIC message element. The WTP MUST respond 630 with a Join ACK, which is used to provide key confirmation. 632 AC: The AC enters this state when it receives a valid Join ACK. 633 For certificate based security, the Join ACK MUST include a 634 valid and authenticated PSK-MIC message element. For pre- 635 shared key security, the message must include a valid PSK-MIC 636 message element. The AC MUST respond with a Join Confirm 637 message, which includes the Session Key message element. 639 Join-Confirm to Idle (3): This state is used when the join process 640 failed. 642 WTP: This state transition occurs when the WTP receives an invalid 643 Join Confirm. 645 AC: The AC enters this state when it receives an invalid Join ACK. 647 Join-Confirm to Configure (2): This state is used by the WTP and the 648 AC to exchange configuration information. 650 WTP: The WTP enters this state when it receives a successful Join 651 Confirm, and determines that its version number and the version 652 number advertised by the AC are the same. The WTP transmits 653 the Configure Request (see Section 7.2) message to the AC with 654 a snapshot of its current configuration. The WTP also starts 655 the ResponseTimeout timer (see Section 12). 657 AC: This state transition occurs when the AC receives the 658 Configure Request from the WTP. The AC must transmit a 659 Configure Response (see Section 7.3) to the WTP, and may 660 include specific message elements to override the WTP's 661 configuration. 663 Join-Confirm to Image Data (4): This state is used by the WTP and the 664 AC to download executable firmware. 666 WTP: The WTP enters this state when it receives a successful Join 667 Confirm, and determines that its version number and the version 668 number advertised by the AC are different. The WTP transmits 669 the Image Data Request (see Section 8.1) message requesting 670 that the AC's latest firmware be initiated. 672 AC: This state transition occurs when the AC receives the Image 673 Data Request from the WTP. The AC must transmit a Image Data 674 Response (see Section 8.2) to the WTP, which includes a portion 675 of the firmware. 677 Image Data to Image Data (n): This state is used by WTP and the AC 678 during the firmware download phase. 680 WTP: The WTP enters this state when it receives a Image Data 681 Response that indicates that the AC has more data to send. 683 AC: This state transition occurs when the AC receives the Image 684 Data Request from the WTP while already in this state, and it 685 detects that the firmware download has not completed. 687 Image Data to Reset (o): This state is used when the firmware 688 download is completed. 690 WTP: The WTP enters this state when it receives a Image Data 691 Response that indicates that the AC has no more data to send, 692 or if the underlying LWAPP transport indicates a link failure. 693 At this point, the WTP reboots itself. 695 AC: This state transition occurs when the AC receives the Image 696 Data Request from the WTP while already in this state, and it 697 detects that the firmware download has completed, or if the 698 underlying LWAPP transport indicates a link failure. Note that 699 the AC itself does not reset, but it places the specific WTPs 700 context it is communicating with in the reset state, meaning 701 that it clears all state associated with the WTP. 703 Configure to Reset (p): This state transition occurs if the Configure 704 phase fails. 706 WTP: The WTP enters this state when the reliable transport fails 707 to deliver the Configure Request, or if the ResponseTimeout 708 Timer (see Section 12)expires. 710 AC: This state transition occurs if the AC is unable to transmit 711 the Configure Response to a specific WTP. Note that the AC 712 itself does not reset, but it places the specific WTPs context 713 it is communicating with in the reset state, meaning that it 714 clears all state associated with the WTP. 716 Configure to Run (q): This state transition occurs when the WTP and 717 AC enters their normal state of operation. 719 WTP: The WTP enters this state when it receives a successful 720 Configure Response from the AC. The WTP initializes the 721 HeartBeat Timer (see Section 12), and transmits the Change 722 State Event Request message (see Section 7.6). 724 AC: This state transition occurs when the AC receives the Change 725 State Event Request (see Section 7.6) from the WTP. The AC 726 responds with a Change State Event Response (see Section 7.7) 727 message. The AC must start the Session ID and Neighbor Dead 728 timers (see Section 12). 730 Run to Run (r): This is the normal state of operation. 732 WTP: This is the WTP's normal state of operation, and there are 733 many events that cause this to occur: 735 Configuration Update: The WTP receives a Configuration Update 736 Request (see Section 7.4). The WTP MUST respond with a 737 Configuration Update Response (see Section 7.5). 739 Change State Event: The WTP receives a Change State Event 740 Response, or determines that it must initiate a Change State 741 Event Request, as a result of a failure or change in the 742 state of a radio. 744 Echo Request: The WTP receives an Echo Request message 745 Section 6.5), which it MUST respond with an Echo Response 746 (see Section 6.6). 748 Clear Config Indication: The WTP receives a Clear Config 749 Indication message Section 7.8). The WTP MUST reset its 750 configuration back to manufacturer defaults. 752 WTP Event: The WTP generates a WTP Event Request to send 753 information to the AC Section 8.5). The WTP receives a WTP 754 Event Response from the AC Section 8.6). 756 Data Transfer: The WTP generates a Data Transfer Request to the 757 AC Section 8.7). The WTP receives a Data Transfer Response 758 from the AC Section 8.8). 760 WLAN Config Request: The WTP receives an WLAN Config Request 761 message Section 11.8.1), which it MUST respond with an WLAN 762 Config Response (see Section 11.8.2). 764 Mobile Config Request: The WTP receives an Mobile Config 765 Request message Section 9.1), which it MUST respond with an 766 Mobile Config Response (see Section 9.2). 768 AC: This is the AC's normal state of operation, and there are many 769 events that cause this to occur: 771 Configuration Update: The AC sends a Configuration Update 772 Request (see Section 7.4) to the WTP to update its 773 configuration. The AC receives a Configuration Update 774 Response (see Section 7.5) from the WTP. 776 Change State Event: The AC receives a Change State Event 777 Request (see Section 7.6), which it MUST respond to with the 778 Change State Event Response (see Section 7.7). 780 Echo: The AC sends an Echo Request message Section 6.5) or 781 receives the associated Echo Response (see Section 6.6) from 782 the WTP. 784 Clear Config Indication: The AC sends a Clear Config Indication 785 message Section 7.8). 787 WLAN Config: The AC sends an WLAN Config Request message 788 Section 11.8.1) or receives the associated WLAN Config 789 Response (see Section 11.8.2) from the WTP. 791 Mobile Config: The AC sends an Mobile Config Request message 792 Section 9.1) or receives the associated Mobile Config 793 Response (see Section 9.2) from the WTP. 795 Data Transfer: The AC receives a Data Transfer Request from the 796 AC (see Section 8.7) and MUST generate the associated Data 797 Transfer Response message (see Section 8.8). 799 WTP Event: The AC receives a WTP Event Request from the AC (see 800 Section 8.5) and MUST generate the associated WTP Event 801 Response message (see Section 8.6). 803 Run to Reset (s): This event occurs when the AC wishes for the WTP to 804 reboot. 806 WTP: The WTP enters this state when it receives a Reset Request 807 (see Section 8.3). It must respond with a Reset Response (see 808 Section 8.4), and once the reliable transport acknowledgement 809 has been received, it must reboot itself. 811 AC: This state transition occurs either through some 812 administrative action, or via some internal event on the AC 813 that causes it to request that the WTP disconnect. Note that 814 the AC itself does not reset, but it places the specific WTPs 815 context it is communicating with in the reset state. 817 Run to Idle (t): This event occurs when an error occurs in the 818 communication between the WTP and the AC. 820 WTP: The WTP enters this state when the underlying reliable 821 transport in unable to transmit a message within the 822 RetransmitInterval timer (see Section 12), and the maximum 823 number of RetransmitCount counter has reached the MaxRetransmit 824 variable (see Section 13). 826 AC: The AC enters this state when the underlying reliable 827 transport in unable to transmit a message within the 828 RetransmitInterval timer (see Section 12), and the maximum 829 number of RetransmitCount counter has reached the MaxRetransmit 830 variable (see Section 13). 832 Run to Key Update (u): This event occurs when the WTP and the AC are 833 to exchange new keying material, with which it must use to protect 834 all future messages. 836 WTP: This state transition occurs when the KeyLifetime timer 837 expires (see Section 12). 839 AC: The WTP enters this state when it receives a Key Update 840 Request (see Section 6.7). 842 Key Update to Key Confirm (w): This event occurs during the rekey 843 phase and is used to complete the loop. 845 WTP: This state transition occurs when the WTP receives the Key 846 Update Response. The WTP MUST only accept the message if it is 847 authentic. The WTP responds to this response with a Key Update 848 ACK. 850 AC: The AC enters this state when it receives an authenticated Key 851 Update ACK message. 853 Key Confirm to Run (5): This event occurs when the rekey exchange 854 phase is completed. 856 WTP: This state transition occurs when the WTP receives the Key 857 Update Confirm. The newly derived encryption key and IV must 858 be plumbed into the crypto module after validating the 859 message's authentication. 861 AC: The AC enters this state when it transmits the Key Update 862 Confirm message. The newly derived encryption key and IV must 863 be plumbed into the crypto module after transmitting a Key 864 Update Confirm message. 866 Key Update to Reset (x): This event occurs when the key exchange 867 phase times out. 869 WTP: This state transition occurs when the WTP does not receive a 870 Key Update Response from the AC. 872 AC: The AC enters this state when it is unable to process a Key 873 Update Request. 875 Reset to Idle (y): This event occurs when the state machine is 876 restarted. 878 WTP: The WTP reboots itself. After reboot the WTP will start its 879 LWAPP state machine in the Idle state. 881 AC: The AC clears out any state associated with the WTP. The AC 882 generally does this as a result of the reliable link layer 883 timing out. 885 3. LWAPP Transport Layers 887 The LWAPP protocol can operate at layer 2 or 3. For layer 2 support, 888 the LWAPP messages are carried in a native Ethernet frame. As such, 889 the protocol is not routable and depends upon layer 2 connectivity 890 between the WTP and the AC. Layer 3 support is provided by 891 encapsulating the LWAPP messages within UDP. 893 3.1 LWAPP Transport Header 895 All LWAPP protocol packets are encapsulated using a common header 896 format, regardless of the transport used to carry the frames. 897 However, certain flags are not applicable for a given transport, and 898 it is therefore necessary to refer to the specific transport section 899 in order to determine which flags are valid. 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 |VER| RID |C|F|L| Frag ID | Length | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Status/WLANs | Payload... | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 3.1.1 VER Field 911 A 2 bit field which contains the version of LWAPP used in this 912 packet. The value for this draft is 0. 914 3.1.2 RID Field 916 A 3 bit field which contains the Radio ID number for this packet. 917 WTPs with multiple radios but a single MAC Address use this field to 918 indicate which radio is associated with the packet. 920 3.1.3 C Bit 922 The Control Message 'C' bit indicates whether this packet carries a 923 data or control message. When this bit is zero (0), the packet 924 carries an LWAPP data message in the payload (see Section 4.1). When 925 this bit is one (1), the packet carries an LWAPP control message as 926 defined in section Section 4.2 for consumption by the addressed 927 destination. 929 3.1.4 F Bit 931 The Fragment 'F' bit indicates whether this packet is a fragment. 933 When this bit is one (1), the packet is a fragment and MUST be 934 combined with the other corresponding fragments to reassemble the 935 complete information exchanged between the WTP and AC. 937 3.1.5 L Bit 939 The Not Last 'L' bit is valid only if the 'F' bit is set and 940 indicates whether the packet contains the last fragment of a 941 fragmented exchange between WTP and AC. When this bit is 1, the 942 packet is not the last fragment. When this bit is 0, the packet is 943 the last fragment. 945 3.1.6 Fragment ID 947 An 8 bit field whose value is assigned to each group of fragments 948 making up a complete set. The fragment ID space is managed 949 individually for every WTP/AC pair. The value of Fragment ID is 950 incremented with each new set of fragments. The Fragment ID wraps to 951 zero after the maximum value has been used to identify a set of 952 fragments. LWAPP only supports up to 2 fragments per frame. 954 3.1.7 Length 956 The 16 bit length field contains the number of bytes in the Payload. 957 The field is encoded as an unsigned number. If the LWAPP packet is 958 encrypted, the length field includes the AES-CCM MIC (see 959 Section 10.2 for more information). 961 3.1.8 Status and WLANS 963 The interpretation of this 16 bit field is binding specific. Refer 964 to the transport portion of the binding for a wireless technology for 965 the specification. 967 3.1.9 Payload 969 This field contains the header for an LWAPP Data Message or LWAPP 970 Control Message, followed by the data associated with that message. 972 3.2 Using IEEE 802.3 MAC as LWAPP transport 974 This section describes how the LWAPP protocol is provided over native 975 ethernet frames. An LWAPP packet is formed from the MAC frame header 976 followed by the LWAPP message header. The following figure provides 977 an example of the frame formats used when LWAPP is used over the IEEE 978 802.3 transport. 980 Layer 2 LWAPP Data Frame 981 +-----------------------------------------------------------+ 982 | MAC Header | LWAPP Header [C=0] | Forwarded Data ... | 983 +-----------------------------------------------------------+ 985 Layer 2 LWAPP Control Frame 986 +---------------------------------------------------+ 987 | MAC Header | LWAPP Header [C=1] | Control Message | 988 +---------------------------------------------------+ 989 | Message Elements ... | 990 +----------------------+ 992 3.2.1 Framing 994 Source Address 996 A MAC address belonging to the interface from which this message is 997 sent. If multiple source addresses are configured on an interface, 998 then the one chosen is implementation dependent. 1000 Destination Address 1002 A MAC address belonging to the interface to which this message is to 1003 be sent. This destination address MAY be either an individual 1004 address or a multicast address, if more than one destination 1005 interface is intended. 1007 Ethertype 1009 The Ethertype field is set to 0x88bb. 1011 3.2.2 AC Discovery 1013 When run over IEEE 802.3, LWAPP messages are distributed to a 1014 specific MAC level broadcast domain. The AC discovery mechanism used 1015 with this transport is for an WTP to transmit a Discovery Request 1016 message to a broadcast destination MAC address. The ACs will receive 1017 this message and reply based on their policy. 1019 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC transport 1021 All of the fields described in Section 3.1 are used when LWAPP uses 1022 the IEEE 802.3 MAC transport. 1024 3.2.4 Fragmentation/Reassembly 1026 Fragmentation at the MAC layer is managed using the F,L and Frag ID 1027 fields of the LWAPP message header. The LWAPP protocol only allows a 1028 single packet to be fragmented into 2, which is sufficient for a 1029 frame that exceeds MTU due to LWAPP encapsulation. When used with 1030 layer 2 (Ethernet) transport, both fragments MUST include the LWAPP 1031 header. 1033 3.2.5 Multiplexing 1035 LWAPP control messages and data messages are distinguished by the C 1036 Bit in the LWAPP message header. 1038 3.3 Using IP/UDP as LWAPP transport 1040 This section defines how LWAPP makes use of IP/UDP transport between 1041 the WTP and the AC. When this transport is used, the MAC layer is 1042 controlled by the IP stack, and there are therefore no special MAC 1043 layer requirements. The following figure provides an example of the 1044 frame formats used when LWAPP is used over the IP/UDP transport. IP 1045 stacks can be either IPv4 or IPv6. 1047 Layer 3 LWAPP Data Frame 1048 +--------------------------------------------+ 1049 | MAC Header | IP | UDP | LWAPP Header [C=0] | 1050 +--------------------------------------------+ 1051 |Forwarded Data ... | 1052 +-------------------+ 1054 Layer 3 LWAPP Control Frame 1055 +--------------------------------------------+ 1056 | MAC Header | IP | UDP | LWAPP Header [C=1] | 1057 +--------------------------------------------+ 1058 | Control Message | Message Elements ... | 1059 +-----------------+----------------------+ 1061 3.3.1 Framing 1063 Communication between WTP and AC is established according to the 1064 standard UDP client/server model. The connection is initiated by the 1065 WTP (client) to the well-known UDP port of the AC (server) used for 1066 control messages. This UDP port number of the AC is 12222 for LWAPP 1067 data and 12223 for LWAPP control frames. 1069 3.3.2 AC Discovery 1071 When LWAPP is run over routed IP networks, the WTP and the AC do not 1072 need to reside in the same IP subnet (broadcast domain). However, in 1073 the event the peers reside on separate subnets, there must exist a 1074 mechanism for the WTP to discover the AC. 1076 As the WTP attempts to establish communication with the AC, it sends 1077 the Discovery Request message and receives the corresponding response 1078 message from the AC. The WTP must send the Discovery Request message 1079 to either the limited broadcast IP address (255.255.255.255), a well 1080 known multicast address or to the unicast IP address of the AC. Upon 1081 receipt of the message, the AC issues a Discovery Response message to 1082 the unicast IP address of the WTP, regardless of whether Discovery 1083 Request was sent as a broadcast, multicast or unicast message. 1085 Whether the WTP uses a limited IP broadcast, multicast or unicast IP 1086 address is implementation dependent. 1088 In order for a WTP to transmit a Discovery Request to a unicast 1089 address, the WTP must first obtain the IP address of the AC. Any 1090 static configuration of an AC's IP address on the WTP non-volatile 1091 storage is implementation dependent. However, additional dynamic 1092 schemes are possible, for example: 1094 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1095 embedded inside a DHCP vendor specific option 43 extension. An 1096 example of the actual format of the vendor specific payload for 1097 IPv4 is of the form "10.1.1.1, 10.1.1.2". 1099 DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to or more AC 1100 addresses 1102 3.3.3 LWAPP Message Header format over IP/UDP transport 1104 All of the fields described in Section 3.1 are used when LWAPP uses 1105 the IPv4/UDP or IPv6/UDP transport, with the following exceptions: 1107 3.3.3.1 F Bit 1109 This flag field is not used with this transport, and MUST be set to 1110 zero. 1112 3.3.3.2 L Bit 1114 This flag field is not used with this transport, and MUST be set to 1115 zero. 1117 3.3.3.3 Frag ID 1119 This field is not used with this transport, and MUST be set to zero. 1121 3.3.4 Fragmentation/Reassembly for IPv4 1123 When LWAPP is implemented at L3, the transport layer uses IP 1124 fragmentation to fragment and reassemble LWAPP messages that are 1125 longer than MTU size used by either WTP or AC. The details of IP 1126 fragmentation are covered in [8]. When used with the IP transport, 1127 only the first fragment would include the LWAPP header 1129 [ed: IP fragmentation may raise security concerns and bring 1130 additional configuration requirements for certain firewalls and NATs. 1131 One alternative is to re-use the layer 2 (application layer) 1132 fragmentation reassembly. Comments are welcomed.] 1134 3.3.5 Fragmentation/Reassembly for IPv6 1136 IPv6 does MTU discovery so fragmentation and re-assembly is not 1137 necessary for UDP packets. 1139 3.3.6 Multiplexing 1141 LWAPP messages convey control information between WTP and AC, as well 1142 as binding specific data frames or binding specific management 1143 frames. As such, LWAPP messages need to be multiplexed in the 1144 transport sub-layer and be delivered to the proper software entities 1145 in the endpoints of the protocol. However, the 'C' bit is still used 1146 to differentiate between data and control frames. 1148 In case of Layer 3 connection, multiplexing is achieved by use of 1149 different UDP ports for control and data packets (see Section 3.3.1. 1151 As part of Join procedure, the WTP and AC may negotiate different IP 1152 Addresses for data or control messages. The IP Address returned in 1153 the AP Manager Control IP Address message element is used to inform 1154 the WTP with the IP address to which it must sent all control frames. 1155 The AP Manager Data IP Address message element MAY be present only if 1156 the AC has a different IP Address which the WTP is to use to send its 1157 data LWAPP frames. 1159 In the event the WTP and AC are separated by a NAT, with the WTP 1160 using private IP address space, it is the responsibility of the NAT 1161 to manage appropriate UDP port mapping. 1163 4. LWAPP Packet Definitions 1165 This section contains the packet types and format. The LWAPP 1166 protocol is designed to be transport agnostic by specifying packet 1167 formats for both MAC frames and IP packets. An LWAPP packet consists 1168 of an LWAPP Transport Layer packet header followed by an LWAPP 1169 message. 1171 Transport details can be found in Section 3. 1173 4.1 LWAPP Data Messages 1175 An LWAPP data message is a forwarded wireless frame. When forwarding 1176 wireless frames, the sender simply encapsulates the wireless frame in 1177 an LWAPP data packet, using the appropriate transport rules defined 1178 in section Section 3. 1180 In the event that the encapsulated frame would exceed the transport 1181 layer's MTU, the sender is responsible for the fragmentation of the 1182 frame, as specified in the transport specific section of Section 3. 1184 The actual format of the encapsulated LWAPP data frame is subject to 1185 the rules defined under the specific wireless technology binding. 1187 4.2 LWAPP Control Messages Overview 1189 The LWAPP Control protocol provides a control channel between the WTP 1190 and the AC. The control channel is the series of control messages 1191 between the WTP and AC, associated with a session ID and key. 1192 Control messages are divided into the following distinct message 1193 types: 1195 Discovery: LWAPP Discovery messages are used to identify potential 1196 ACs, their load and capabilities. 1198 Control Channel Management: Messages that fall within this 1199 classification are used for the discovery of ACs by the WTPs as 1200 well as the establishment and maintenance of an LWAPP control 1201 channel. 1203 WTP Configuration: The WTP Configuration messages are used by the AC 1204 to push a specific configuration to the WTPs it has a control 1205 channel with. Messages that deal with the retrieval of statistics 1206 from the WTP also fall in this category. 1208 Mobile Session Management: Mobile session management messages are 1209 used by the AC to push specific mobile policies to the WTP. 1211 Firmware Management: Messages in this category are used by the AC to 1212 push a new firmware image down to the WTP. 1214 Control Channel, WTP Configuration and Mobile Session Management MUST 1215 be implemented. Firmware Management MAY be implemented. 1217 In addition, technology specific bindings may introduce new control 1218 channel commands that depart from the above list. 1220 4.2.1 Control Message Format 1222 All LWAPP control messages are sent encapsulated within the LWAPP 1223 header (see Section 3.1). Immediately following the header, is the 1224 LWAPP control header, which has the following format: 1226 0 1 2 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Message Type | Seq Num | Msg Element Length | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Session ID | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Msg Element [0..N] | 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 4.2.1.1 Message Type 1238 The Message Type field identifies the function of the LWAPP control 1239 message. The valid values for Message Type are the following: 1241 Description Value 1242 Discovery Request 1 1243 Discovery Response 2 1244 Join Request 3 1245 Join Response 4 1246 Join ACK 5 1247 Join Confirm 6 1248 Unused 7-9 1249 Configure Request 10 1250 Configure Response 11 1251 Configuration Update Request 12 1252 Configuration Update Response 13 1253 WTP Event Request 14 1254 WTP Event Response 15 1255 Change State Event Request 16 1256 Change State Event Response 17 1257 Unused 18-21 1258 Echo Request 22 1259 Echo Response 23 1260 Image Data Request 24 1261 Image Data Response 25 1262 Reset Request 26 1263 Reset Response 27 1264 Unused 28-29 1265 Key Update Request 30 1266 Key Update Response 31 1267 Primary Discovery Request 32 1268 Primary Discovery Response 33 1269 Data Transfer Request 34 1270 Data Transfer Response 35 1271 Clear Config Indication 36 1272 WLAN Config Request 37 1273 WLAN Config Response 38 1274 Mobile Config Request 39 1275 Mobile Config Response 40 1277 4.2.1.2 Sequence Number 1279 The Sequence Number Field is an identifier value to match request/ 1280 response packet exchanges. When an LWAPP packet with a request 1281 message type is received, the value of the sequence number field is 1282 copied into the corresponding response packet. 1284 When an LWAPP control frame is sent, its internal sequence number 1285 counter is monotonically incremented, ensuring that no two requests 1286 pending have the same sequence number. This field will wrap back to 1287 zero. 1289 4.2.1.3 Message Element Length 1291 The Length field indicates the number of bytes following the Session 1292 ID field. If the LWAPP packet is encrypted, the length field 1293 includes the AES-CCM MIC (see Section 10.2 for more information). 1295 4.2.1.4 Session ID 1297 The Session ID is a 32-bit unsigned integer that is used to identify 1298 the security context for encrypted exchanges between the WTP and the 1299 AC. Note that a Session ID is a random value that MUST be unique 1300 between a given AC and any of the WTP it may be communicating with. 1302 4.2.1.5 Message Element[0..N] 1304 The message element(s) carry the information pertinent to each of the 1305 control message types. Every control message in this specification 1306 specifies which message elements are permitted. 1308 4.2.2 Message Element Format 1310 The message element is used to carry information pertinent to a 1311 control message. Every message element is identified by the Type 1312 field, whose numbering space is managed via IANA (see Section 16). 1313 The total length of the message elements is indicated in the Message 1314 Element Length field. 1316 All of the message element definitions in this document use a diagram 1317 similar to the one below in order to depict its format. Note that in 1318 order to simplify this specification, these diagrams do not include 1319 the header fields (Type and Length). However, in every message 1320 element description, the header's fields values will be defined. 1322 Note that additional message elements may be defined in separate IETF 1323 documents. 1325 The format of a message element uses the TLV format shown here: 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Type | Length | Value ... | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 Where Type (8 bit) identifies the character of the information 1334 carried in the Value field and Length (16 bits) indicates the number 1335 of bytes in the Value field. 1337 4.2.2.1 Generic Message Elements 1339 This section includes message elements that are not bound to a 1340 specific control message. 1342 4.2.2.1.1 Vendor Specific 1344 The Vendor Specific Payload is used to communicate vendor specific 1345 information between the WTP and the AC. The value contains the 1346 following format: 1348 0 1 2 3 1349 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 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | Vendor Identifier | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | Element ID | Value... | 1354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 Type: 104 for Vendor Specific 1358 Length: >= 7 1360 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 1361 Network Management Private Enterprise Codes" [14] 1363 Element ID: A 16-bit Element Identifier which is managed by the 1364 vendor. 1366 Value: The value associated with the vendor specific element. 1368 4.2.3 Quality of Service 1370 It is recommended that LWAPP control messages be sent by both the AC 1371 and the WTP with an appropriate Quality of Service precedence value, 1372 ensuring that congestion in the network minimizes occurences of LWAPP 1373 control channel disconnects. Therefore, a Quality of Service enabled 1374 LWAPP device should use: 1376 802.1P: The precedence value of 7 SHOULD be used. 1378 DSCP: The dscp tag value of 46 SHOULD be used. 1380 5. LWAPP Discovery Operations 1382 The Discovery messages are used by an WTP to determine which ACs are 1383 available to provide service, as well as the capabilities and load of 1384 the ACs. 1386 5.1 Discovery Request 1388 The Discovery Request is used by the WTP to automatically discover 1389 potential ACs available in the network. An WTP must transmit this 1390 command even if it has a statically configured AC, as it is a 1391 required step in the LWAPP state machine. 1393 Discovery Requests MUST be sent by an WTP in the Discover state after 1394 waiting for a random delay less than MaxDiscoveryInterval, after an 1395 WTP first comes up or is (re)initialized. An WTP MUST send no more 1396 than a maximum of MaxDiscoveries discoveries, waiting for a random 1397 delay less than MaxDiscoveryInterval between each successive 1398 discovery. 1400 This is to prevent an explosion of WTP Discoveries. An example of 1401 this occurring would be when many WTPs are powered on at the same 1402 time. 1404 Discovery requests MUST be sent by an WTP when no echo responses are 1405 received for NeighborDeadInterval and the WTP returns to the Idle 1406 state. Discovery requests are sent after NeighborDeadInterval, they 1407 MUST be sent after waiting for a random delay less than 1408 MaxDiscoveryInterval. An WTP MAY send up to a maximum of 1409 MaxDiscoveries discoveries, waiting for a random delay less than 1410 MaxDiscoveryInterval between each successive discovery. 1412 If a discovery response is not received after sending the maximum 1413 number of discovery requests, the WTP enters the Sulking state and 1414 MUST wait for an interval equal to SilentInterval before sending 1415 further discovery requests. 1417 The Discovery Request message may be sent as a unicast, broadcast or 1418 multicast message. 1420 Upon receiving a discovery request, the AC will respond with a 1421 Discovery Response sent to the address in the source address of the 1422 received discovery request. 1424 The following subsections define the message elements that MUST be 1425 included in this LWAPP operation. 1427 5.1.1 Discovery Type 1429 The Discovery message element is used to configure an WTP to operate 1430 in a specific mode. 1432 0 1433 0 1 2 3 4 5 6 7 1434 +-+-+-+-+-+-+-+-+ 1435 | Discovery Type| 1436 +-+-+-+-+-+-+-+-+ 1438 Type: 58 for Discovery Type 1440 Length: 1 1442 Discovery Type: An 8-bit value indicating how the AC was discovered. 1443 The following values are supported: 1445 0 - Broadcast 1447 1 - Configured 1449 5.1.2 WTP Descriptor 1451 The WTP descriptor message element is used by the WTP to communicate 1452 it's current hardware/firmware configuration. The value contains the 1453 following fields. 1455 0 1 2 3 1456 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 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Hardware Version | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Software Version | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Boot Version | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Max Radios | Radios in use | Encryption Capabilities | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 Type: 3 for WTP Descriptor 1469 Length: 16 1470 Hardware Version: A 32-bit integer representing the WTP's hardware 1471 version number 1473 Software Version: A 32-bit integer representing the WTP's Firmware 1474 version number 1476 Boot Version: A 32-bit integer representing the WTP's boot loader's 1477 version number 1479 Max Radios: An 8-bit value representing the number of radios (where 1480 each radio is identified via the RID field) supported by the WTP 1482 Radios in use: An 8-bit value representing the number of radios 1483 present in the WTP 1485 Encryption Capabilities: This 16-bit field is used by the WTP to 1486 communicate it's capabilities to the AC. Since most WTPs support 1487 link layer encryption, the AC may make use of these services. 1488 There are binding dependent encryption capabilites. An WTP that 1489 does not have any encryption capabilities would set this field to 1490 zero (0). Refer to the specific binding for the specification. 1492 5.1.3 WTP Radio Information 1494 The WTP radios information message element is used to communicate the 1495 radio information in a specific slot. The Discovery Request MUST 1496 include one such message element per radio in the WTP. The Radio- 1497 Type field is used by the AC in order to determine which technology 1498 specific binding is to be used with the WTP. 1500 The value contains two fields, as shown. 1502 0 1 1503 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Radio ID | Radio Type | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Type: 4 for WTP Radio Information 1510 Length: 2 1512 Radio ID: The Radio Identifier, typically refers to some interface 1513 index on the WTP 1515 Radio Type: The type of radio present. The following values are 1516 supported 1518 1 - 802.11bg: An 802.11bg radio. 1520 2 - 802.11a: An 802.11a radio. 1522 3 - 802.16: An 802.16 radio. 1524 4 - Ultra Wideband: An UWB radio. 1526 7 - all: Used to specify all radios in the WTP. 1528 5.2 Discovery Response 1530 The Discovery Response is a mechanism by which an AC advertises its 1531 services to requesting WTPs. 1533 Discovery Responses are sent by an AC after receiving a Discovery 1534 Request. 1536 When an WTP receives a Discovery Response, it MUST wait for an 1537 interval not less than DiscoveryInterval for receipt of additional 1538 Discovery Responses. After the DiscoveryInterval elapses, the WTP 1539 enters the Joining state and will select one of the ACs that sent a 1540 Discovery Response and send a Join Request to that AC. 1542 The following subsections define the message elements that MUST be 1543 included in this LWAPP operation. 1545 5.2.1 AC Address 1547 The AC address message element is used to communicate the identity of 1548 the AC. The value contains two fields, as shown. 1550 0 1 2 3 1551 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 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Reserved | MAC Address | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | MAC Address | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 Type: 2 for AC Address 1560 Length: 7 1562 Reserved: MUST be set to zero 1564 Mac Address: The MAC Address of the AC 1566 5.2.2 AC Descriptor 1568 The AC payload message element is used by the AC to communicate it's 1569 current state. The value contains the following fields. 1571 0 1 2 3 1572 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 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Reserved | Hardware Version ... | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | HW Ver | Software Version ... | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | SW Ver | Stations | Limit | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Limit | Radios | Max Radio | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Max Radio | Security | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 Type: 6 for AC Descriptor 1587 Length: 17 1589 Reserved: MUST be set to zero 1591 Hardware Version: A 32-bit integer representing the AC's hardware 1592 version number 1594 Software Version: A 32-bit integer representing the AC's Firmware 1595 version number 1597 Stations: A 16-bit integer representing number of mobile stations 1598 currently associated with the AC 1600 Limit: A 16-bit integer representing the maximum number of stations 1601 supported by the AC 1603 Radios: A 16-bit integer representing the number of WTPs currently 1604 attached to the AC 1606 Max Radio: A 16-bit integer representing the maximum number of WTPs 1607 supported by the AC 1609 Security: A 8 bit bit mask specifying the security schemes supported 1610 by the AC. The following values are supported (see Section 10): 1612 1 - X.509 Certificate Based 1614 2 - Pre-Shared Secret 1616 5.2.3 AC Name 1618 The AC name message element contains an ASCII representation of the 1619 AC's identity. The value is a variable length byte string. The 1620 string is NOT zero terminated. 1622 0 1623 0 1 2 3 4 5 6 7 1624 +-+-+-+-+-+-+-+-+ 1625 | Name ... 1626 +-+-+-+-+-+-+-+-+ 1628 Type: 31 for AC Name 1630 Length: > 0 1632 Name: A variable length ASCII string containing the AC's name 1634 5.2.4 WTP Manager Control IPv4 Address 1636 The WTP Manager Control IPv4 Address message element is sent by the 1637 AC to the WTP during the discovery process and is used by the AC to 1638 provide the interfaces available on the AC, and their current load. 1639 This message element is useful for the WTP to perform load balancing 1640 across multiple interfaces. 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | IP Address | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | WTP Count | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 Type: 99 for WTP Manager Control IPv4 Address 1652 Length: 6 1654 IP Address: The IP Address of an interface. 1656 WTP Count: The number of WTPs currently connected to the interface. 1658 5.2.5 WTP Manager Control IPv6 Address 1660 The WTP Manager Control IPv6 Address message element is sent by the 1661 AC to the WTP during the discovery process and is used by the AC to 1662 provide the interfaces available on the AC, and their current load. 1663 This message element is useful for the WTP to perform load balancing 1664 across multiple interfaces. 1666 0 1 2 3 1667 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 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | IP Address | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | IP Address | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | IP Address | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | IP Address | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | WTP Count | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 Type: 142 for WTP Manager Control IPv6 Address 1682 Length: 18 1684 IP Address: The IP Address of an interface. 1686 WTP Count: The number of WTPs currently connected to the interface. 1688 5.3 Primary Discovery Request 1690 The Primary Discovery Request is sent by the WTP in order to 1691 determine whether its preferred (or primary) AC is available. 1693 Primary Discovery Request are sent by an WTP when it has a primary AC 1694 configured, and is connected to another AC. This generally occurs as 1695 a result of a failover, and is used by the WTP as a means to discover 1696 when its primary AC becomes available. As a consequence, this 1697 message is only sent by a WTP when it is in the Run state. 1699 The frequency of the Primary Discovery Requests should be no more 1700 often than the sending of the Echo Request message. 1702 Upon receiving a discovery request, the AC will respond with a 1703 Primary Discovery Response sent to the address in the source address 1704 of the received Primary Discovery Request. 1706 The following subsections define the message elements that MUST be 1707 included in this LWAPP operation. 1709 5.3.1 Discovery Type 1711 The Discovery Type message element is defined in section 1712 Section 5.1.1. 1714 5.3.2 WTP Descriptor 1716 The WTP Descriptor message element is defined in section 1717 Section 5.1.2. 1719 5.3.3 WTP Radio Information 1721 An WTP Radio Information message element must be present for every 1722 radio in the WTP. This message element is defined in section 1723 Section 5.1.3. 1725 5.4 Primary Discovery Response 1727 The Primary Discovery Response is a mechanism by which an AC 1728 advertises its availability and services to requesting WTPs that are 1729 configured to have the AC as its primary AC. 1731 Primary Discovery Responses are sent by an AC after receiving a 1732 Primary Discovery Request. 1734 When an WTP receives a Primary Discovery Response, it may opt to 1735 establish an LWAPP connection to its primary AC, based on the 1736 configuration of the WTP Fallback Status message element on the WTP. 1738 The following subsections define the message elements that MUST be 1739 included in this LWAPP operation. 1741 5.4.1 AC Descriptor 1743 The Discovery Type message element is defined in section 1744 Section 5.2.2. 1746 5.4.2 AC Name 1748 The AC Name message element is defined in section Section 5.2.3. 1750 5.4.3 WTP Manager Control IPv4 Address 1752 An WTP Radio Information message element MAY be present for every 1753 radio in the WTP which are reachable via IPv4. This message element 1754 is defined in section Section 5.2.4. 1756 5.4.4 WTP Manager Control IPv6 Address 1758 An WTP Radio Information message element must be present for every 1759 radio in the WTP which are reachable via IPv6. This message element 1760 is defined in section Section 5.2.5. 1762 6. Control Channel Management 1764 The Control Channel Management messages are used by the WTP and AC to 1765 create and maintain a channel of communication on which various other 1766 commands may be transmitted, such as configuration, firmware update, 1767 etc. 1769 6.1 Join Request 1771 The Join Request is used by an WTP to inform an AC that it wishes to 1772 provide services through it. 1774 Join Requests are sent by an WTP in the Joining state after receiving 1775 one or more Discovery Responses. The Join Request is also used as an 1776 MTU discovery mechanism by the WTP. The WTP issues a Join Request 1777 with a Test message element, bringing the total size of the message 1778 to exceed MTU. 1780 If the transport used does not provide MTU path discovery, the 1781 initial Join Request is padded with the Test message element to 1596 1782 bytes. If a Join Response is received, the WTP can forward frames 1783 without requiring any fragmentation. If no Join Response is 1784 received, it issues a second Join Request padded with the Test 1785 payload to a total of 1500 bytes. The WTP continues to cycle from 1786 large (1596) to small (1500) packets until a Join Response has been 1787 received , or until both packets sizes have been retransmitted 3 1788 times . If the Join Response is not received after the maximum 1789 number of retransmissions, the WTP MUST abandon the AC and restart 1790 the discovery phase. 1792 When an AC receives a Join Request it will respond with a Join 1793 Response. If the certificate based security mechanism is used, the 1794 AC validates the certificate found in the request. If valid, the AC 1795 generates a session key which will be used to secure the control 1796 frames it exchanges with the WTP. When the AC issues the Join 1797 Response, the AC creates a context for the session with the WTP. 1799 If the pre-shared session key security mechanism is used, the AC 1800 saves the WTP's nonce, found in the WNonce message element, creates 1801 its own nonce which it includes in the ANonce message element. 1802 Finally, the AC creates the PSK-MIC, which is computed using a key 1803 that is derived from the PSK. 1805 A Join Request that includes both a WNonce and a Certificate message 1806 element MUST be considered invalid. 1808 Details on the key generation is found in Section 10. 1810 The following subsections define the message elements that MUST be 1811 included in this LWAPP operation. 1813 6.1.1 WTP Descriptor 1815 The WTP Descriptor message element is defined in section 1816 Section 5.1.2. 1818 6.1.2 AC Address 1820 The AC Address message element is defined in section Section 5.2.1. 1822 6.1.3 WTP Name 1824 The WTP name message element value is a variable length byte string. 1825 The string is NOT zero terminated. 1827 0 1828 0 1 2 3 4 5 6 7 1829 +-+-+-+-+-+-+-+-+ 1830 | Name ... 1831 +-+-+-+-+-+-+-+-+ 1833 Type: 5 for WTP Name 1835 Length: > 0 1837 Name: A non zero terminated string containing the WTP's name. 1839 6.1.4 Location Data 1841 The location data message element is a variable length byte string 1842 containing user defined location information (e.g. "Next to 1843 Fridge"). The string is NOT zero terminated. 1845 0 1846 0 1 2 3 4 5 6 7 1847 +-+-+-+-+-+-+-+-+ 1848 | Location ... 1849 +-+-+-+-+-+-+-+-+ 1851 Type: 35 for Location Data 1853 Length: > 0 1854 Location: A non zero terminated string containing the WTP's 1855 location. 1857 6.1.5 WTP Radio Information 1859 An WTP Radio Information message element must be present for every 1860 radio in the WTP. This message element is defined in section 1861 Section 5.1.3. 1863 6.1.6 Certificate 1865 The certificate message element value is a byte string containing a 1866 DER-encoded x.509v3 certificate. This message element is only 1867 included if the LWAPP security type used between the WTP and the AC 1868 makes use of certificates (see Section 10 for more information). 1870 0 1871 0 1 2 3 4 5 6 7 1872 +-+-+-+-+-+-+-+-+ 1873 | Certificate... 1874 +-+-+-+-+-+-+-+-+ 1876 Type: 44 for Certificate 1878 Length: > 0 1880 Certificate: A non zero terminated string containing the device's 1881 certificate. 1883 6.1.7 Session ID 1885 The session ID message element value contains a randomly generated 1886 [4] unsigned 32-bit integer. 1888 0 1 2 3 1889 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 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Session ID | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 Type: 45 for Session ID 1896 Length: 4 1897 Session ID: 32 bit random session identifier. 1899 6.1.8 Test 1901 The test message element is used as padding to perform MTU discovery, 1902 and MAY contain any value, of any length. 1904 0 1905 0 1 2 3 4 5 6 7 1906 +-+-+-+-+-+-+-+-+ 1907 | Padding ... 1908 +-+-+-+-+-+-+-+-+ 1910 Type: 18 for Test 1912 Length: > 0 1914 Padding: A variable length pad. 1916 6.1.9 XNonce 1918 The XNonce is used by the WTP to communicate its random nonce during 1919 the join or rekey phase. See Section 10 for more information. 1921 0 1 2 3 1922 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 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Nonce | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | Nonce | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | Nonce | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Nonce | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 Type: 111 for XNonce 1935 Length: 16 1937 Nonce: 1 16 octet random nonce. 1939 6.2 Join Response 1941 The Join Response is sent by the AC to indicate to an WTP whether it 1942 is capable and willing to provide service to it. 1944 Join Responses are sent by the AC after receiving a Join Request. 1945 Once the Join Response has been sent, the heartbeat timer is 1946 initiated for the session to EchoInterval. Expiration of the timer 1947 will result in deletion of the AC-WTP session. The timer is 1948 refreshed upon receipt of the Echo Request. 1950 If the security method used is certificate based, when a WTP receives 1951 a Join Response it enters the Joined state and initiates either a 1952 Configure Request or Image Data to the AC to which it is now joined. 1953 Upon entering the Joined state, the WTP begins timing an interval 1954 equal to NeighborDeadInterval. Expiration of the timer will result 1955 in the transmission of the Echo Request. 1957 If the security method used is pre-shared secret based, when a WTP 1958 receives a Join Response that includes a valid PSK-MIC message 1959 element, it responds with a Join ACK that also MUST include a locally 1960 computed PSK-MIC message element. 1962 The following subsections define the message elements that MUST be 1963 included in this LWAPP operation. 1965 6.2.1 Result Code 1967 The Result Code message element value is a 32-bit integer value, 1968 indicating the result of the request operation corresponding to the 1969 sequence number in the message. The Result Code is included in a 1970 successful Join Response. 1972 0 1 2 3 1973 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 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Result Code | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 Type: 2 for Result Code 1980 Length: 4 1982 Result Code: The following values are defined: 1984 0 Success 1986 1 Failure (AC List message element MUST be present) 1988 6.2.2 Status 1990 The Status message element is sent by the AC to the WTP in a non- 1991 successful Join Response message. This message element is used to 1992 indicate the reason for the failure and should only be accompanied 1993 with a Result Code message element that indicates a failure. 1995 0 1996 0 1 2 3 4 5 6 7 1997 +-+-+-+-+-+-+-+-+ 1998 | Status | 1999 +-+-+-+-+-+-+-+-+ 2001 Type: 60 for Status 2003 Length: 1 2005 Status: The status field indicates the reason for an LWAPP failure. 2006 The following values are supported: 2008 1 - Reserved - do not use 2010 2 - Resource Depletion 2012 3 - Unknown Source 2014 4 - Incorrect Data 2016 6.2.3 Certificate 2018 The Certificate message element is defined in section Section 6.1.6. 2019 Note this message element is only included if the WTP and the AC make 2020 use of certificate based security as defined in section Section 10. 2022 6.2.4 WTP Manager Data IPv4 Address 2024 The WTP Manager Data IPv4 Address message element is optionally sent 2025 by the AC to the WTP during the join phase. If present, the IP 2026 Address contained in this message element is the address the WTP is 2027 to use when sending any of its LWAPP data frames. 2029 Note this message element is only valid when LWAPP uses the IP/UDP 2030 layer 3 transport 2031 0 1 2 3 2032 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | IP Address | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 Type: 143 for WTP Manager Data IPv4 Address 2039 Length: 4 2041 IP Address: The IP Address of an interface. 2043 6.2.5 WTP Manager Data IPv6 Address 2045 The WTP Manager Data IPv6 Address message element is optionally sent 2046 by the AC to the WTP during the join phase. If present, the IP 2047 Address contained in this message element is the address the WTP is 2048 to use when sending any of its LWAPP data frames. 2050 Note this message element is only valid when LWAPP uses the IP/UDP 2051 layer 3 transport 2053 0 1 2 3 2054 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 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | IP Address | 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | IP Address | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | IP Address | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | IP Address | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 Type: 139 for WTP Manager Data IPv6 Address 2067 Length: 16 2069 IP Address: The IP Address of an interface. 2071 6.2.6 AC IPv4 List 2073 The AC List message element is used to configure an WTP with the 2074 latest list of ACs in a cluster. This message element MUST be 2075 included if the Join Response returns a failure indicating that the 2076 AC cannot handle the WTP at this time, allowing the WTP to find an 2077 alternate AC to connect to. 2079 0 1 2 3 2080 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 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | AC IP Address[] | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 Type: 59 for AC List 2087 Length: >= 4 2089 AC IP Address: An array of 32-bit integers containing an AC's IPv4 2090 Address. 2092 6.2.7 AC IPv6 List 2094 The AC List message element is used to configure an WTP with the 2095 latest list of ACs in a cluster. This message element MUST be 2096 included if the Join Response returns a failure indicating that the 2097 AC cannot handle the WTP at this time, allowing the WTP to find an 2098 alternate AC to connect to. 2100 0 1 2 3 2101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | AC IP Address[] | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | AC IP Address[] | 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | AC IP Address[] | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | AC IP Address[] | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 Type: 141 for AC List 2114 Length: >= 16 2116 AC IP Address: An array of 32-bit integers containing an AC's IPv6 2117 Address. 2119 6.2.8 ANonce 2121 The ANonce message element is sent by a AC during the join or rekey 2122 phase. The contents of the ANonce are encrypted as described in 2123 section Section 10 for more information. 2125 0 1 2 3 2126 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 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Nonce | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 | Nonce | 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | Nonce | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | Nonce | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 Type: 108 for ANonce 2139 Length: 16 2141 Nonce: An encrypted 16 octet random nonce. 2143 6.2.9 PSK-MIC 2145 The PSK-MIC message element includes a message integrity check, whose 2146 purpose is to provide confirmation to the peer that the sender has 2147 the proper session key. This message element is only included if the 2148 security method used between the WTP and the AC is the pre-shared 2149 secret mechanism. See Section 10 for more information. 2151 When present, the PSK-MIC message element MUST be the last message 2152 element in the message. The MIC is computed over the complete LWAPP 2153 packet, from the LWAPP control header as defined in Section 4.2.1 to 2154 the end of the packet (which MUST be this PSK-MIC message element). 2155 The MIC field in this message element and the sequence number field 2156 in the LWAPP control header MUST be set to zeroes prior to computing 2157 the MIC. The length field in the LWAPP control header must already 2158 include this message element prior to computing the MIC. 2160 0 1 2 3 2161 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 2162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2163 | SPI | MIC ... 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 Type: 109 for PSK-MIC 2168 Length: > 1 2170 SPI: The SPI field specifies the cryptographic algorithm used to 2171 create the message integrity check. The following values are 2172 supported: 2174 0 - Unused 2176 1 - HMAC-SHA-1 (RFC 2104 [17]) 2178 1 - AES-CMAC ([13]) 2180 MIC: A 20 octet Message Integrity Check. 2182 6.3 Join ACK 2184 The Join ACK message is sent by the WTP upon receiving a Join 2185 Response, which has a valid PSK-MIC message element, as a means of 2186 providing key confirmation to the AC. The Join ACK is only used in 2187 the case where the WTP makes use of the pre-shared key LWAPP mode 2188 (See Section 10 for more information). 2190 Note that the AC should never receive this message unless the 2191 security method used between the WTP and the AC is pre-shared secret 2192 based. 2194 The following subsections define the message elements that MUST be 2195 included in this LWAPP operation. 2197 6.3.1 Session ID 2199 The Session ID message element is defined in section Section 6.1.7. 2201 6.3.2 WNonce 2203 The WNonce message element is sent by a WTP during the join or rekey 2204 phase. The contents of the ANonce are encrypted as described in 2205 section Section 10 for more information. 2207 0 1 2 3 2208 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 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 | Nonce | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2212 | Nonce | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 | Nonce | 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | Nonce | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 Type: 107 for WNonce 2221 Length: 16 2223 Nonce: An encrypted 16 octet random nonce. 2225 6.3.3 PSK-MIC 2227 The PSK-MIC message element is defined in section Section 6.2.9. 2229 6.4 Join Confirm 2231 The Join Confirm message is sent by the AC upon receiving a Join ACK, 2232 which has a valid PSK-MIC message element, as a means of providing 2233 key confirmation to the WTP. The Join Confirm is only used in the 2234 case where the WTP makes use of the pre-shared key LWAPP mode (See 2235 Section 10 for more information). 2237 If the security method used is pre-shared key based, when an WTP 2238 receives a Join Confirm it enters the Joined state and initiates 2239 either a Configure Request or Image Data to the AC to which it is now 2240 joined. Upon entering the Joined state, the WTP begins timing an 2241 interval equal to NeighborDeadInterval. Expiration of the timer will 2242 result in the transmission of the Echo Request. 2244 This message is never received, or sent, when the security type used 2245 between the WTP and the AC is certificated based. 2247 The following subsections define the message elements that MUST be 2248 included in this LWAPP operation. 2250 6.4.1 Session ID 2252 The Session ID message element is defined in section Section 6.1.7. 2254 6.4.2 PSK-MIC 2256 The PSK-MIC message element is defined in section Section 6.2.9. 2258 6.5 Echo Request 2260 The Echo Request message is a keepalive mechanism for the LWAPP 2261 control message. 2263 Echo Requests are sent periodically by an WTP in the Run state (see 2264 Figure 2) to determine the state of the connection between the WTP 2265 and the AC. The Echo Request is sent by the WTP when the Heartbeat 2266 timer expires, and it MUST start its NeighborDeadInterval timer. 2268 The Echo Request carries no message elements. 2270 When an AC receives an Echo Request it responds with an Echo 2271 Response. 2273 6.6 Echo Response 2275 The Echo Response acknowledges the Echo Request, and are only 2276 accepted while in the Run state (see Figure 2). 2278 Echo Responses are sent by an AC after receiving an Echo Request. 2279 After transmitting the Echo Response, the AC should reset its 2280 Heartbeat timer to expire in the value configured for EchoInterval. 2281 If another Echo request is not received by the AC when the timer 2282 expires, the AC SHOULD consider the WTP to no longer be reachable. 2284 The Echo Response carries no message elements. 2286 When an WTP receives an Echo Response it stops the 2287 NeighborDeadInterval timer, and starts the Heartbeat timer to 2288 EchoInterval. 2290 If the NeighborDeadInterval timer expires prior to receiving an Echo 2291 Response, the WTP enters the Idle state. 2293 6.7 Key Update Request 2295 The Key Update Request is used by the WTP to initiate the rekeying 2296 phase. This message is sent by a WTP when in the Run state and MUST 2297 include a new unique Session Identifier. This message MUST also 2298 include a unique Nonce in the XNonce message element, which is used 2299 to protect against replay attacks (see Section 10). 2301 The following subsections define the message elements that MUST be 2302 included in this LWAPP operation. 2304 6.7.1 Session ID 2306 The Session ID message element is defined in section Section 6.1.7. 2308 6.7.2 XNonce 2310 The XNonce message element is defined in section Section 6.1.9. 2312 6.8 Key Update Response 2314 The Key Update Response is sent by the AC in response to the request 2315 message, and includes an encrypted ANonce, which is used to derive 2316 new session keys. This message MUST include a Session Identifier 2317 message element, whose value MUST be identical to the one found in 2318 the Key Update Request. 2320 The AC MUST include a PSK-MIC message element, which provides message 2321 integrity over the whole message. 2323 The following subsections define the message elements that MUST be 2324 included in this LWAPP operation. 2326 6.8.1 Session ID 2328 The Session ID message element is defined in section Section 6.1.7. 2330 6.8.2 ANonce 2332 The ANonce message element is defined in section Section 6.2.8. 2334 6.8.3 PSK-MIC 2336 The PSK-MIC message element is defined in section Section 6.2.9. 2338 6.9 Key Update ACK 2340 The Key Update ACK is sent by the WTP and includes an encryption 2341 version of the WTP's Nonce, which is used in the key derivation 2342 process. The session keys derived are then used as new LWAPP control 2343 message encryption keys (see Section 10). 2345 The WTP MUST include a PSK-MIC message element, which provides 2346 message integrity over the whole message. 2348 The following subsections define the message elements that MUST be 2349 included in this LWAPP operation. 2351 6.9.1 WNonce 2353 The WNonce message element is defined in section Section 6.3.2. 2355 6.9.2 PSK-MIC 2357 The PSK-MIC message element is defined in section Section 6.2.9. 2359 6.10 Key Update Confirm 2361 The Key Update Confirm closes the rekeying loop, and allows the WTP 2362 to recognize that the AC has received and processed the key update 2363 messages. At this point, the WTP updates its session key in its 2364 crypto engine, and the associated Initialization Vector, ensuring 2365 that all future LWAPP control frames are encrypted with the newly 2366 derived encryption key. 2368 The WTP MUST include a PSK-MIC message element, which provides 2369 message integrity over the whole message. 2371 The following subsections define the message elements that MUST be 2372 included in this LWAPP operation. 2374 6.10.1 PSK-MIC 2376 The PSK-MIC message element is defined in section Section 6.2.9. 2378 6.11 Key Update Trigger 2380 The Key Update Trigger is used by the AC to request that a Key Update 2381 Request be initiated by the WTP. 2383 Key Update Trigger are sent by an AC in the Run state to inform the 2384 WTP to initiate a Key Update Request message. 2386 When a WTP receives a Key Update Trigger it generates a key Update 2387 Request. 2389 The following subsections define the message elements that MUST be 2390 included in this LWAPP operation. 2392 6.11.1 Session ID 2394 The Session ID message element is defined in section Section 6.1.7. 2396 7. WTP Configuration Management 2398 The Wireless Termination Point Configuration messages are used to 2399 exchange configuration between the AC and the WTP. 2401 7.1 Configuration Consistency 2403 The LWAPP protocol provides flexibility in how WTP configuration is 2404 managed. To put it simply, a WTP has one of two options: 2406 1. WTP retain no configuration and simply abides by the configuration 2407 provided by the AC. 2409 2. WTP retain the configuration of parameters provided by the AC that 2410 are non-default values. 2412 If the WTP opts to save configuration locally, the LWAPP protocol 2413 state machine defines the "configure" state, which is used during the 2414 initial binding WTP-AC phase, which allows for configuration 2415 exchange. During this period, the WTP sends its current 2416 configuration overrides to the AC via the COnfigure Request message. 2417 A configuration override is a parameter that is non-default. One 2418 example is that in the LWAPP protocol the default antenna 2419 configuration is internal omni antenna. However, a WTP that either 2420 has no internal antennas, or has been explicitely configured by the 2421 AC to use external antennas, would send its antenna configuration 2422 during the configure phase, allowing the AC to become aware of the 2423 WTP's current configuration. 2425 Once the WTP has provided its configuration to the AC, the AC sends 2426 down its own configuration. This allows the WTP to inherit the 2427 configuration and policies on the AC. 2429 An LWAPP AC maintains a copy of each active WTP's configuration. 2430 There is no need for versioning or other means to identify 2431 configuration changes. If a WTP becomes inactive, the AC MAY delete 2432 the configuration associated with it. If a WTP were to fail, and 2433 connect to a new AC, it would provide its overriden configuration 2434 parameters, allowing the new AC to be aware of the WTP's 2435 configuration. 2437 As a consequence, this model allows for relisiency, whereby in light 2438 of an AC failure, another AC could provide service to the WTP. In 2439 this scenario, the new AC would be automatically updated on any 2440 possible WTP configuration changes - eliminating the need for 2441 inter-AC communication or the need for all ACs to be aware of the 2442 configuration of all WTPs in the network. 2444 Once the LWAPP protocol enters the Run state, the WTPs begin to 2445 provide service. However, it is quite common for administrators to 2446 require that configuration changes be made while the network is 2447 operational. Therefore, the Configuration Update Request is sent by 2448 the AC to the WTP in order to make these changes at run-time. 2450 7.2 Configure Request 2452 The Configure Request message is sent by an WTP to send its current 2453 configuration to its AC. 2455 Configure Requests are sent by an WTP after receiving a Join 2456 Response, while in the Configure state. 2458 The Configure Request carries binding specific message elements. 2459 Refer to the appropriate binding for the definition of this 2460 structure. 2462 When an AC receives a Configure Request it will act upon the content 2463 of the packet and respond to the WTP with a Configure Response. 2465 The Configure Request includes multiple Administrative State message 2466 Elements. There is one such message element for the WTP, and then 2467 one per radio in the WTP. 2469 The following subsections define the message elements that MUST be 2470 included in this LWAPP operation. 2472 7.2.1 Administrative State 2474 The administrative event message element is used to communicate the 2475 state of a particular radio. The value contains the following 2476 fields. 2478 0 1 2479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | Radio ID | Admin State | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 Type: 27 for Administrative State 2486 Length: 2 2488 Radio ID: An 8-bit value representing the radio to configure. The 2489 Radio ID field may also include the value of 0xff, which is used 2490 to identify the WTP itself. Therefore, if an AC wishes to change 2491 the administrative state of an WTP, it would include 0xff in the 2492 Radio ID field. 2494 Admin State: An 8-bit value representing the administrative state of 2495 the radio. The following values are supported: 2497 1 - Enabled 2499 2 - Disabled 2501 7.2.2 AC Name 2503 The AC Name message element is defined in section Section 5.2.3. 2505 7.2.3 AC Name with Index 2507 The AC Name with Index message element is sent by the AC to the WTP 2508 to configure preferred ACs. The number of instances where this 2509 message element would be present is equal to the number of ACs 2510 configured on the WTP. 2512 0 1 2513 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 | Index | AC Name... 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 Type: 90 for AC Name with Index 2520 Length: 5 2522 Index: The index of the preferred server (e.g., 1=primary, 2523 2=secondary). 2525 AC Name: A variable length ASCII string containing the AC's name. 2527 7.2.4 WTP Board Data 2529 The WTP Board Data message element is sent by the WTP to the AC and 2530 contains information about the hardware present. 2532 0 1 2 3 2533 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 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 | Card ID | Card Revision | 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 | WTP Model | 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | WTP Model | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | WTP Serial Number ... | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Reserved | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Ethernet MAC Address | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Ethernet MAC Address | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2550 Type: 50 for WTP Board Data 2552 Length: 26 2554 Card ID: A hardware identifier. 2556 Card Revision: 4 byte Revision of the card. 2558 WTP Model: 8 byte WTP Model Number. 2560 WTP Serial Number: 24 byte WTP Serial Number. 2562 Reserved: A 4 byte reserved field that MUST be set to zero (0). 2564 Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. 2566 7.2.5 Statistics Timer 2568 The statistics timer message element value is used by the AC to 2569 inform the WTP of the frequency which it expects to receive updated 2570 statistics. 2572 0 1 2573 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | Statistics Timer | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 Type: 37 for Statistics Timer 2580 Length: 2 2582 Statistics Timer: A 16-bit unsigned integer indicating the time, in 2583 seconds 2585 7.2.6 WTP Static IP Address Information 2587 The WTP Static IP Address Information message element is used by an 2588 AC to configure or clear a previously configured static IP address on 2589 an WTP. 2591 0 1 2 3 2592 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 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 | IP Address | 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | Netmask | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | Gateway | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 | Static | 2601 +-+-+-+-+-+-+-+-+ 2603 Type: 82 for WTP Static IP Address Information 2605 Length: 13 2607 IP Address: The IP Address to assign to the WTP. 2609 Netmask: The IP Netmask. 2611 Gateway: The IP address of the gateway. 2613 Netmask: The IP Netmask. 2615 Static: An 8-bit boolean stating whether the WTP should use a static 2616 IP address or not. A value of zero disables the static IP 2617 address, while a value of one enables it. 2619 7.2.7 WTP Reboot Statistics 2621 The WTP Reboot Statistics message element is sent by the WTP to the 2622 AC to communicate information about reasons why reboots have 2623 occurred. 2625 0 1 2 3 2626 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 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | Crash Count | LWAPP Initiated Count | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 | Link Failure Count | Failure Type | 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2633 Type: 67 for WTP Reboot Statistics 2635 Length: 7 2637 Crash Count: The number of reboots that have occurred due to an WTP 2638 crash. 2640 LWAPP Initiated Count: The number of reboots that have occured at 2641 the request of some LWAPP message, such as a change in 2642 configuration that required a reboot or an explicit LWAPP reset 2643 request. 2645 Link Failure Count: The number of times that an LWAPP connection 2646 with an AC has failed. 2648 Failure Type: The last WTP failure. The following values are 2649 supported: 2651 0 - Link Failure 2653 1 - LWAPP Initiated 2655 2 - WTP Crash 2657 7.3 Configure Response 2659 The Configure Response message is sent by an AC and provides an 2660 opportunity for the AC to override an WTP's requested configuration. 2662 Configure Responses are sent by an AC after receiving a Configure 2663 Request. 2665 The Configure Response carries binding specific message elements. 2666 Refer to the appropriate binding for the definition of this 2667 structure. 2669 When an WTP receives a Configure Response it acts upon the content of 2670 the packet, as appropriate. If the Configure Response message 2671 includes a Change State Event message element that causes a change in 2672 the operational state of one of the Radio, the WTP will transmit a 2673 Change State Event to the AC, as an acknowledgement of the change in 2674 state. 2676 The following subsections define the message elements that MUST be 2677 included in this LWAPP operation. 2679 7.3.1 Decryption Error Report Period 2681 The Decryption Error Report Period message element value is used by 2682 the AC to inform the WTP how frequently it should send decryption 2683 error report messages. 2685 0 1 2 2686 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 | Radio ID | Report Interval | 2689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2691 Type: 38 for Decryption Error Report Period 2693 Length: 3 2695 Radio ID: The Radio Identifier, typically refers to some interface 2696 index on the WTP 2698 Report Interval: A 16-bit unsigned integer indicating the time, in 2699 seconds 2701 7.3.2 Change State Event 2703 The WTP radios information message element is used to communicate the 2704 operational state of a radio. The value contains two fields, as 2705 shown. 2707 0 1 2708 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | Radio ID | State | Cause | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 Type: 26 for Change State Event 2715 Length: 3 2716 Radio ID: The Radio Identifier, typically refers to some interface 2717 index on the WTP. 2719 State: An 8-bit boolean value representing the state of the radio. 2720 A value of one disables the radio, while a value of two enables 2721 it. 2723 Cause: In the event of a radio being inoperable, the cause field 2724 would contain the reason the radio is out of service. 2726 Cause: In the event of a radio being inoperable, the cause field 2727 would contain the reason the radio is out of service. The 2728 following values are supported: 2730 0 - Normal 2732 1 - Radio Failure 2734 2 - Software Failure 2736 7.3.3 LWAPP Timers 2738 The LWAPP Timers message element is used by an AC to configure LWAPP 2739 timers on an WTP. 2741 0 1 2742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | Discovery | Echo Request | 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 Type: 68 for LWAPP Timers 2749 Length: 2 2751 Discovery: The number of seconds between LWAPP Discovery packets, 2752 when the WTP is in the discovery mode. 2754 Echo Request: The number of seconds between WTP Echo Request LWAPP 2755 messages. 2757 7.3.4 AC IPv4 List 2759 The AC List message element is defined in section Section 6.2.6. 2761 7.3.5 AC IPv6 List 2763 The AC List message element is defined in section Section 6.2.7. 2765 7.3.6 WTP Fallback 2767 The WTP Fallback message element is sent by the AC to the WTP to 2768 enable or disable automatic LWAPP fallback in the event that an WTP 2769 detects its preferred AC, and is not currently connected to it. 2771 0 2772 0 1 2 3 4 5 6 7 2773 +-+-+-+-+-+-+-+-+ 2774 | Mode | 2775 +-+-+-+-+-+-+-+-+ 2777 Type: 91 for WTP Fallback 2779 Length: 1 2781 Mode: The 8-bit boolean value indicates the status of automatic 2782 LWAPP fallback on the WTP. A value of zero disables the fallback 2783 feature, while a value of one enables it. When enabled, if the 2784 WTP detects that its primary AC is available, and it is not 2785 connected to it, it SHOULD automatically disconnect from its 2786 current AC and reconnect to its primary. If disabled, the WTP 2787 will only reconnect to its primary through manual intervention 2788 (e.g., through the Reset Request command). 2790 7.3.7 Idle Timeout 2792 The Idle Timeout message element is sent by the AC to the WTP to 2793 provide it with the idle timeout that it should enforce on its active 2794 mobile station entries. 2796 0 1 2 3 2797 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 2798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2799 | Timeout | 2800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2802 Type: 97 for Idle Timeout 2804 Length: 4 2805 Timeout: The current idle timeout to be enforced by the WTP. 2807 7.4 Configuration Update Request 2809 Configure Update Requests are sent by the AC to provision the WTP 2810 while in the Run state. This is used to modify the configuration of 2811 the WTP while it is operational. 2813 When an AC receives a Configuration Update Request it will respond 2814 with a Configuration Update Response, with the appropriate Result 2815 Code. 2817 The following subsections define the message elements introduced by 2818 this LWAPP operation. 2820 7.4.1 WTP Name 2822 The WTP Name message element is defined in section Section 6.1.3. 2824 7.4.2 Change State Event 2826 The Change State Event message element is defined in section 2827 Section 7.3.2. 2829 7.4.3 Administrative State 2831 The Administrative State message element is defined in section 2832 Section 7.2.1. 2834 7.4.4 Statistics Timer 2836 The Statistics Timer message element is defined in section 2837 Section 7.2.5. 2839 7.4.5 Location Data 2841 The Location Data message element is defined in section 2842 Section 6.1.4. 2844 7.4.6 Decryption Error Report Period 2846 The Decryption Error Report Period message element is defined in 2847 section Section 7.3.1. 2849 7.4.7 AC IPv4 List 2851 The AC List message element is defined in section Section 6.2.6. 2853 7.4.8 AC IPv6 List 2855 The AC List message element is defined in section Section 6.2.7. 2857 7.4.9 Add Blacklist Entry 2859 The Add Blacklist Entry message element is used by an AC to add a 2860 blacklist entry on an WTP, ensuring that the WTP no longer provides 2861 any service to the MAC addresses provided in the message. The MAC 2862 Addresses provided in this message element are not expected to be 2863 saved in non-volative memory on the WTP. 2865 0 1 2 3 2866 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 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | Num of Entries| MAC Address[] | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2870 | MAC Address[] | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 Type: 65 for Add Blacklist Entry 2875 Length: >= 7 2877 Num of Entries: The number of MAC Addresses in the array. 2879 MAC Address: An array of MAC Addresses to add to the blacklist 2880 entry. 2882 7.4.10 Delete Blacklist Entry 2884 The Delete Blacklist Entry message element is used by an AC to delete 2885 a previously added blacklist entry on an WTP, ensuring that the WTP 2886 provides service to the MAC addresses provided in the message. 2888 0 1 2 3 2889 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 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Num of Entries| MAC Address[] | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | MAC Address[] | 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2896 Type: 66 for Delete Blacklist Entry 2898 Length: >= 7 2900 Num of Entries: The number of MAC Addresses in the array. 2902 MAC Address: An array of MAC Addresses to delete from the blacklist 2903 entry. 2905 7.4.11 Add Static Blacklist Entry 2907 The Add Static Blacklist Entry message element is used by an AC to 2908 add a permanent blacklist entry on an WTP, ensuring that the WTP no 2909 longer provides any service to the MAC addresses provided in the 2910 message. The MAC Addresses provided in this message element are 2911 expected to be saved in non-volative memory on the WTP. 2913 0 1 2 3 2914 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 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 | Num of Entries| MAC Address[] | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 | MAC Address[] | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 Type: 70 for Delete Blacklist Entry 2923 Length: >= 7 2925 Num of Entries: The number of MAC Addresses in the array. 2927 MAC Address: An array of MAC Addresses to add to the permanent 2928 blacklist entry. 2930 7.4.12 Delete Static Blacklist Entry 2932 The Delete Static Blacklist Entry message element is used by an AC to 2933 delete a previously added static blacklist entry on an WTP, ensuring 2934 that the WTP provides service to the MAC addresses provided in the 2935 message. 2937 0 1 2 3 2938 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 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 | Num of Entries| MAC Address[] | 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | MAC Address[] | 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2945 Type: 71 for Delete Blacklist Entry 2947 Length: >= 7 2949 Num of Entries: The number of MAC Addresses in the array. 2951 MAC Address: An array of MAC Addresses to delete from the static 2952 blacklist entry. 2954 7.4.13 LWAPP Timers 2956 The LWAPP Timers message element is defined in section Section 7.3.3. 2958 7.4.14 AC Name with Index 2960 The AC Name with Index message element is defined in section 2961 Section 7.2.3. 2963 7.4.15 WTP Fallback 2965 The WTP Fallback message element is defined in section Section 7.3.6. 2967 7.4.16 Idle Timeout 2969 The Idle Timeout message element is defined in section Section 7.3.7. 2971 7.5 Configuration Update Response 2973 The Configuration Update Response is the acknowledgement message for 2974 the Configuration Update Request. 2976 Configuration Update Responses are sent by an WTP after receiving a 2977 Configuration Update Request. 2979 When an AC receives a Configure Update Response the result code 2980 indicates if the WTP successfully accepted the configuration. 2982 The following subsections define the message elements that must be 2983 present in this LWAPP operation. 2985 7.5.1 Result Code 2987 The Result Code message element is defined in section Section 6.2.1. 2989 7.6 Change State Event Request 2991 The Change State Event is used by the WTP to inform the AC of a 2992 change in the operational state. 2994 The Change State Event message is sent by the WTP when it receives a 2995 Configuration Response that includes a Change State Event message 2996 element. It is also sent in the event that the WTP detects an 2997 operational failure with a radio. The Change State Event may be sent 2998 in either the Configure or Run state (see Figure 2. 3000 When an AC receives a Change State Event it will respond with a 3001 Change State Event Response and make any necessary modifications to 3002 internal WTP data structures. 3004 The following subsections define the message elements that must be 3005 present in this LWAPP operation. 3007 7.6.1 Change State Event 3009 The Change State Event message element is defined in section 3010 Section 7.3.2. 3012 7.7 Change State Event Response 3014 The Change State Event Response acknowledges the Change State Event. 3016 Change State Event Response are sent by an WTP after receiving a 3017 Change State Event. 3019 The Change State Event Response carries no message elements. Its 3020 purpose is to acknowledge the receipt of the Change State Event. 3022 The WTP does not need to perform any special processing of the Change 3023 State Event Response message. 3025 7.8 Clear Config Indication 3027 The Clear Config Indication is used to reset an WTP's configuration. 3029 The Clear Config Indication is sent by an AC to request that an WTP 3030 reset its configuration to manufacturing defaults. The Clear Config 3031 Indication message is sent while in the Run LWAPP state. 3033 The Reset Request carries no message elements. 3035 When an WTP receives a Clear Config Indication it will reset its 3036 configuration to manufacturing defaults. 3038 8. Device Management Operations 3040 This section defines LWAPP operations responsible for debugging, 3041 gathering statistics, logging, and firmware management. 3043 8.1 Image Data Request 3045 The Image Data Request is used to update firmware on the WTP. This 3046 message and its companion response are used by the AC to ensure that 3047 the image being run on each WTP is appropriate. 3049 Image Data Requests are exchanged between the WTP and the AC to 3050 download a new program image to an WTP. 3052 When an WTP or AC receives an Image Data Request it will respond with 3053 a Image Data Response. 3055 The format of the Image Data and Image Download message elements are 3056 described in the following subsections. 3058 8.1.1 Image Download 3060 The image download message element is sent by the WTP to the AC and 3061 contains the image filename. The value is a variable length byte 3062 string. The string is NOT zero terminated. 3064 8.1.2 Image Data 3066 The image data message element is present when sent by the AC and 3067 contains the following fields. 3069 0 1 2 3 3070 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 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3072 | Opcode | Checksum | Image Data | 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 | Image Data ... | 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 Type: 33 for Image Data 3079 Length: >= 5 3081 Opcode: An 8-bit value representing the transfer opcode. The 3082 following values are supported: 3084 3 - Image data is included 3086 5 - An error occurred. Transfer is aborted 3088 Checksum: A 16-bit value containing a checksum of the image data 3089 that follows 3091 Image Data: The Image Data field contains 1024 characters, unless 3092 the payload being sent is the last one (end of file) 3094 8.2 Image Data Response 3096 The Image Data Response acknowledges the Image Data Request. 3098 An Image Data Responses is sent in response to an Image Data Request. 3099 Its purpose is to acknowledge the receipt of the Image Data Request 3100 packet. 3102 The Image Data Response carries no message elements. 3104 No action is necessary on receipt. 3106 8.3 Reset Request 3108 The Reset Request is used to cause an WTP to reboot. 3110 Reset Requests are sent by an AC to cause an WTP to reinitialize its 3111 operation. 3113 The Reset Request carries no message elements. 3115 When an WTP receives a Reset Request it will respond with a Reset 3116 Response and then reinitialize itself. 3118 8.4 Reset Response 3120 The Reset Response acknowledges the Reset Request. 3122 Reset Responses are sent by an WTP after receiving a Reset Request. 3124 The Reset Response carries no message elements. Its purpose is to 3125 acknowledge the receipt of the Reset Request. 3127 When an AC receives a Reset Response it is notified that the WTP will 3128 now reinitialize its operation. 3130 8.5 WTP Event Request 3132 WTP Event Request is used by an WTP to send an information to its AC. 3133 These types of events may be periodical, or some asynchronous event 3134 on the WTP. For instance, an WTP collects statistics and uses the 3135 WTP Event Request to transmit this information to the AC. 3137 When an AC receives a WTP Event Request it will respond with a WTP 3138 Event Request. 3140 The WTP Event Request message MUST contain one of the following 3141 message element described in the next subsections, or a message 3142 element that is defined for a specific technology. 3144 8.5.1 Decryption Error Report 3146 The Decryption Error Report message element value is used by the WTP 3147 to inform the AC of decryption errors that have occured since the 3148 last report. 3150 0 1 2 3151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 | Radio ID |Num Of Entries | Mobile MAC Address | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 | Mobile MAC Address[] | 3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 Type: 39 for Decryption Error Report 3160 Length: >= 8 3162 Radio ID: The Radio Identifier, typically refers to some interface 3163 index on the WTP 3165 Num Of Entries: An 8-bit unsigned integer indicating the number of 3166 mobile MAC addresses. 3168 Mobile MAC Address: An array of mobile station MAC addresses that 3169 have caused decryption errors. 3171 8.5.2 Duplicate IPv4 Address 3173 The Duplicate IPv4 Address message element is used by an WTP to 3174 inform an AC that it has detected another host using the same IP 3175 address it is currently using. 3177 0 1 2 3 3178 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 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | IP Address | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 | MAC Address | 3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 | MAC Address | 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3187 Type: 77 for Duplicate IPv4 Address 3189 Length: 10 3191 IP Address: The IP Address currently used by the WTP. 3193 MAC Address: The MAC Address of the offending device. 3195 8.5.3 Duplicate IPv6 Address 3197 The Duplicate IPv6 Address message element is used by an WTP to 3198 inform an AC that it has detected another host using the same IP 3199 address it is currently using. 3201 0 1 2 3 3202 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 3203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3204 | IP Address | 3205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3206 | IP Address | 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | IP Address | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | IP Address | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | MAC Address | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 | MAC Address | 3215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3217 Type: 77 for Duplicate IPv6 Address 3219 Length: 10 3220 IP Address: The IP Address currently used by the WTP. 3222 MAC Address: The MAC Address of the offending device. 3224 8.6 WTP Event Response 3226 WTP Event Response acknowledges the WTP Event Request. 3228 WTP Event Response are sent by an AC after receiving a WTP Event 3229 Request. 3231 The WTP Event Response carries no message elements. 3233 8.7 Data Transfer Request 3235 The Data Transfer Request is used to upload debug information from 3236 the WTP to the AC. 3238 Data Transfer Requests are sent by the WTP to the AC when it 3239 determines that it has important information to send to the AC. For 3240 instance, if the WTP detects that its previous reboot was caused by a 3241 system crash, it would want to send the crash file to the AC. The 3242 remote debugger function in the WTP also uses the data transfer 3243 request in order to send console output to the AC for debugging 3244 purposes. 3246 When an AC receives an Data Transfer Request it will respond with a 3247 Data Transfer Response. The AC may log the information received, as 3248 it sees fit. 3250 The data transfer request message MUST contain ONE of the following 3251 message element described in the next subsection. 3253 8.7.1 Data Transfer Mode 3255 The Data Transfer Mode message element is used by the AC to request 3256 information from the WTP for debugging purposes. 3258 0 3259 0 1 2 3 4 5 6 7 3260 +-+-+-+-+-+-+-+-+ 3261 | Data Type | 3262 +-+-+-+-+-+-+-+-+ 3264 Type: 52 for Data Transfer Mode 3266 Length: 1 3268 Data Type: An 8-bit value the type of information being requested. 3269 The following values are supported: 3271 1 - WTP Crash Data 3273 2 - WTP Memory Dump 3275 8.7.2 Data Transfer Data 3277 The Data Transfer Data message element is used by the WTP to provide 3278 information to the AC for debugging purposes. 3280 0 1 2 3 3281 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 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3283 | Data Type | Data Length | Data .... 3284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 Type: 53 for Data Transfer Data 3288 Length: >= 3 3290 Data Type: An 8-bit value the type of information being sent. The 3291 following values are supported: 3293 1 - WTP Crash Data 3295 2 - WTP Memory Dump 3297 Data Length: Length of data field. 3299 Data: Debug information. 3301 8.8 Data Transfer Response 3303 The Data Transfer Response acknowledges the Data Transfer Request. 3305 An Data Transfer Response is sent in response to an Data Transfer 3306 Request. Its purpose is to acknowledge the receipt of the Data 3307 Transfer Request packet. 3309 The Data Transfer Response carries no message elements. 3311 Upon receipt of a Data Transfer Response, the WTP transmits more 3312 information, if any is available. 3314 9. Mobile Session Management 3316 Messages in this section are used by the AC to create, modify or 3317 delete mobile station session state on the WTPs. 3319 9.1 Mobile Config Request 3321 The Mobile Config Request message is used to create, modify or delete 3322 mobile session state on an WTP. The message is sent by the AC to the 3323 WTP, and may contain one or more message elements. The message 3324 elements for this LWAPP control message include information that is 3325 generally highly technology specific. Therefore, please refer to the 3326 appropriate binding section or document for the definitions of the 3327 messages elements that may be used in this control message. 3329 This section defines the format of the Delete Mobile message element, 3330 since it does not contain any technology specific information. 3332 9.1.1 Delete Mobile 3334 The Delete Mobile message element is used by the AC to inform an WTP 3335 that it should no longer provide service to a particular mobile 3336 station. The WTP must terminate service immediately upon receiving 3337 this message element. 3339 The transmission of a Delete Mobile message element could occur for 3340 various reasons, including for administrative reaons, as a result of 3341 the fact that the mobile has roamed to another WTP, etc. 3343 Once access has been terminated for a given station, any future 3344 packets received from the mobile must result in a deauthenticate 3345 message, as specified in [6]. 3347 0 1 2 3 3348 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 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 | Radio ID | MAC Address | 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3352 | MAC Address | 3353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3355 Type: 30 for Delete Mobile 3357 Length: 7 3358 Radio ID: An 8-bit value representing the radio 3360 MAC Address: The mobile station's MAC Address 3362 9.2 Mobile Config Response 3364 The Mobile Configuration Response is used to acknowledge a previously 3365 received Mobile Configuration Request, and includes a Result Code 3366 message element which indicates whether an error occured on the WTP. 3368 This message requires no special processing, and is only used to 3369 acknowledge the Mobile Configuration Request. 3371 The data transfer request message MUST contain the message elements 3372 described in the next subsection. 3374 9.2.1 Result Code 3376 The Result Code message element is defined in section Section 6.2.1. 3378 10. LWAPP Security 3380 Note: This version only defines a certificate and a shared secret 3381 based mechanism to secure control LWAPP traffic exchanged between the 3382 WTP and the AC. 3384 10.1 Securing WTP-AC communications 3386 While it is generally straightforward to produce network 3387 installations in which the communications medium between the WTP and 3388 AC is not accessible to the casual user (e.g. these LAN segments are 3389 isolated, no RJ45 or other access ports exist between the WTP and the 3390 AC), this will not always be the case. Furthermore, a determined 3391 attacker may resort to various more sophisticated monitoring and/or 3392 access techniques, thereby compromising the integrity of this 3393 connection. 3395 In general, a certain level of threat on the local (wired) LAN is 3396 expected and accepted in most computing environments. That is, it is 3397 expected that in order to provide users with an acceptable level of 3398 service and maintain reasonable productivity levels, a certain amount 3399 of risk must be tolerated. It is generally believed that a certain 3400 perimeter is maintained around such LANs, that an attacker must have 3401 access to the building(s) in which such LANs exist, and that they 3402 must be able to "plug in" to the LAN in order to access the network. 3404 With these things in mind, we can begin to assess the general 3405 security requirements for AC-WTP communications. While an in-depth 3406 security analysis of threats and risks to these communication is 3407 beyond the scope of this document, some discussion of the motivation 3408 for various security-related design choices is useful. The 3409 assumptions driving the security design thus far include the 3410 following: 3412 o WTP-AC communications may be accessible to a sophisticated 3413 attacker. For instance, if LWAPP is used in a mesh environment, 3414 where LWAPP is run over the air, additional link layer security, 3415 such as 802.11i, may be required. 3417 o if authentication and/or privacy of end to end traffic for which 3418 the WTP and AC are intermediaries is required, this may be 3419 provided via IPsec [16]. 3421 o privacy and authentication for at least some WTP-AC control 3422 traffic is required (e.g. WEP keys for user sessions, passed from 3423 AC to WTP) 3425 o the AC can be trusted to generate strong cryptographic keys 3427 AC-WTP traffic can be considered to consist of two types: data 3428 traffic (e.g. to or from an end user), and control traffic which is 3429 strictly between the AC and WTP. Since data traffic may be secured 3430 using IPsec (or some other end-to-end security mechanism), we confine 3431 our solution to control traffic. The resulting security consists of 3432 two components: an authenticated key exchange, and control traffic 3433 security encapsulation. The security encapsulation is accomplished 3434 using AES CCM, described in [3]. This encapsulation provides for 3435 strong AES-based authentication and encryption. The exchange of 3436 cryptographic keys used for CCM is described below. 3438 10.2 LWAPP Frame Encryption 3440 While, the LWAPP protocol uses AES-CCM to encrypt control traffic, it 3441 is important to note that not all control frames are encrypted. The 3442 LWAPP discovery and join phase are not encrypted. The Discovery 3443 messages are sent in the clear since there does not exist a security 3444 association between the WTP and the AC during the discovery phase. 3445 The Join phase is an authenticated exchange used to negotiate 3446 symmetric session keys (see Section 10.3). 3448 Once the join phase has been successfully completed, the LWAPP state 3449 machine Figure 2 will move to the Configure state, at which time all 3450 LWAPP control frames are encrypted using AES-CCM. 3452 Encryption of a control message begins at the Message Element field, 3453 meaning the Msg Type, Seq Num, Msg Element Length and Session ID 3454 fields are left intact (see Section 4.2.1). 3456 The AES-CCM 12 byte authentication data is appended to the end of the 3457 message. The authentication data is calculated from the start of the 3458 LWAPP packet, and includes the complete LWAPP control header (see 3459 Section 4.2.1). 3461 The AES-CCM block cipher protocol requires an initialization vector. 3462 The LWAPP protocol requires that the WTP and the AC maintain two 3463 separate IVs, one for transmission and one for reception. The IV 3464 derived during the key exchange phase by both the WTP and the AC is 3465 used as the base for all encrypted packets with a new key. 3467 10.3 Authenticated Key Exchange 3469 This section describes the key management component of the LWAPP 3470 protocol. There are two modes supported by LWAPP; certificate and 3471 pre-shared key. 3473 10.3.1 Terminology 3475 This section details the key management protocol which makes use of 3476 pre-shared secrets. 3478 The following notations are used throughout this section: 3480 o PSK - the pre-shared key shared between the WTP and the AC 3482 o Kpriv - the private key of a public-private key pair 3484 o Kpub - the public key of the pair 3486 o SessionID - randomly generated LWAPP session identifier, provided 3487 by the WTP in the Join Request 3489 o E-x{Kpub, M} - RSA encryption of M using X's public key 3491 o D-x{Kpriv, C} - RSA decryption of C using X's private key 3493 o AES-CMAC(key, packet) - A message integrity check, using AES-CMAC 3494 and key, of the complete LWAPP packet, with the sequence number 3495 field and the payload of the PSK-MIC message element set to zero. 3497 o AES-E(key, plaintext) - Plaintext is encrypted with key, using 3498 AES. 3500 o AES-D(key, ciphertext) - ciphertext is decrypted with key, using 3501 AES. 3503 o Certificate-AC - AC's Certificate 3505 o Certificate-WTP - WTP's Certificate 3507 o WTP-MAC - The WTP's MAC Address. 3509 o AC-MAC - The AC's MAC Address. 3511 o RK0 - the root key, which is created through a KDF function. 3513 o RK0E - the root Encryption key, derived from RK0. 3515 o RK0M - the root MIC key, derived from RK0. 3517 o SK1 - the session Key 3518 o SK1C - the session confirmation Key, derived from SK 3520 o SK1E - the session encryption Key, derived from SK 3522 o SK1W - the session keywrap Key, derived from SK (see RFC 3394 [9]) 3524 o WNonce - The WTP's randomly generated Nonce. 3526 o ANonce - The AC's randomly generated Nonce. 3528 o EWNonce - The payload of the WNonce message element, which 3529 includes the WNonce. 3531 o EANonce - The payload of the ANonce message element, which 3532 includes the ANonce. 3534 10.3.2 Initial Key Generation 3536 The AC and WTP accomplish mutual authentication and a cryptographic 3537 key exchange in a dual round trip using the Join Request, Join 3538 Response, Join ACK and Join Confirm (see Section 6.1). 3540 The following text describes the exchange between the WTP and the AC 3541 that creates a session key, which is used to secure LWAPP control 3542 messages. 3544 o The WTP creates a Join Request using the following process: 3546 o If Certificate based security is used, the WTP adds the 3547 Certificate message element (see Section 6.1.6) with its 3548 contents set to Certificate-WTP. 3550 o Adds the Session ID message element (see Section 6.1.7) with 3551 the contents set to a randomly generated session identifer (see 3552 RFC 1750 [4]). The WTP MUST save the Session ID in order to 3553 validate the Join Response. 3555 o Creates a random Nonce, included in the XNonce message element 3556 (see Section 6.1.9). The WTP MUST save the XNonce to validate 3557 the Join Response. 3559 o The WTP transmits the Join Request to the AC. 3561 o Upon receiving the Join Request the AC uses the following process: 3563 o The AC creates the Join Response, and ensures that the Session 3564 ID message element matches the value found in the Join Request. 3566 o If Certificate based security is used, the AC: 3568 o Adds the Certificate-AC to the Certificate message element. 3570 o Creates a random 'AC Nonce' and encrypts it using the 3571 following algorithm E-wtp(Kpub, XNonce XOR 'AC Nonce'). The 3572 encrypted contents are added to the ANonce's message element 3573 payload. 3575 o If pre-shared key based security is used, the AC: 3577 o Creates RK0 through the following algorithm: RK0 = KDF- 3578 256{PSK, "LWAPP PSK Top K0" || Session ID || WTP-MAC || AC- 3579 MAC}, where WTP-MAC is the WTP's MAC Address in the form 3580 "xx:xx:xx:xx:xx:xx". Similarly, the AC-MAC is an ASCII 3581 encoding of the AC's MAC Address, of the form "xx:xx:xx:xx: 3582 xx:xx". The resulting K0 is split into the following: 3584 o The first 16 octets is known as RK0E, and is used as an 3585 encryption key 3587 o The second 16 octets is known as RK0M, and is used for 3588 MIC'ing purposes 3590 o Creates a random 'AC Nonce' and encrypts it using the 3591 following algorithm AES-E(RK0E, XNonce XOR 'AC Nonce'). The 3592 encrypted contents are added to the ANonce's message element 3593 payload. 3595 o The AC adds a MIC to the contents of the Join Response using 3596 AES-CMAC(RK0M, Join Response) and adds the resulting hash to 3597 the PSK-MIC (Section 6.2.9) message element. 3599 o Upon receiving the Join Response the WTP uses the following 3600 process: 3602 o If Pre-shared key is used, the WTP authenticates the Join 3603 Response's PSK-MIC message element. If authentication fails, 3604 the packet is dropped. 3606 o The WTP decrypts the ANonce message element and XOR's the value 3607 with XNonce to retrieve the 'AC Nonce'. The ANonce payload is 3608 referred to as ciphertext below: 3610 o If Pre-shared key is used, use AES-D(RK0E, ciphertext). The 3611 'AC Nonce' is then recovered using XNonce XOR plaintext. 3613 o If certificates are used, use d-wtp(Kpriv, ciphertext). The 3614 'AC Nonce' is then recovered using XNonce XOR plaintext. 3616 o The WTP creates a random 'WTP Nonce'. 3618 o The WTP uses the KDF function to create a 64 octet session key 3619 (SK). The KDF function used is as follows: KDF-512{'WTP Nonce' 3620 || 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC-MAC}. The 3621 KDF function is defined in [7]. 3623 o SK is then broken down into three separate session keys with 3624 different purposes: 3626 o The first 16 octets is known as SK1C, and is used as a 3627 confirmation key 3629 o The second 16 octets is known as SK1E, and is as the 3630 encryption key 3632 o The third 16 octets is known as SK1D, and is used as the 3633 keywrap key 3635 o The fourth 16 octets is known as IV, and is used as the 3636 Initialization Vector during encryption 3638 o The WTP creates the Join ACK message. 3640 o If Certificate based security is used, the AC: 3642 o Encrypt the 'WTP Nonce' using following algorithm E-ac(Kpub, 3643 'WTP Nonce'). The encrypted contents are added to the 3644 WNonce's message element payload. 3646 o If pre-shared key based security is used, the AC: 3648 o Encrypt the 'WTP Nonce' using following algorithm AES- 3649 E(RK0E, 'WTP Nonce'). The encrypted contents are added to 3650 the WNonce's message element payload. 3652 o The WTP adds a MIC to the contents of the Join ACK using AES- 3653 CMAC(SK1M, Join ACK) and adds the resulting hash to the PSK-MIC 3654 (Section 6.2.9) message element. 3656 o The WTP then transmits the Join ACK to the AC. 3658 o Upon receiving the Join ACK the AC uses the following process: 3660 o The AC authenticates the Join ACK through the PSK-MIC message 3661 element. If authentic, the AC decrypts the WNonce message 3662 element to retrieve the 'WTP Nonce'. If the Join ACK could not 3663 be authenticated, the packet is dropped. 3665 o The AC decrypts the WNonce message element to retrieve the 'WTP 3666 Nonce'. The WNonce payload is referred to as ciphertext below: 3668 o If Pre-shared key is used, use AES-D(RK0E, ciphertext). The 3669 plaintext is then considered the 'WTP Nonce'. 3671 o If certificates are used, use d-ac(Kpriv, ciphertext). The 3672 plaintext is then considered the 'WTP Nonce'. 3674 o The AC then uses the KDF function to create a 64 octet session 3675 key (SK). The KDF function used is as follows: KDF-512{'WTP 3676 Nonce' || 'AC Nonce', "LWAPP Key Generation", WTP-MAC || AC- 3677 MAC}. The KDF function is defined in [7]. The SK is split 3678 into SK1C, SK1E, SK1D and IV as previously noted. 3680 o The AC creates the Join Confirm. 3682 o The AC adds a MIC to the contents of the Join Confirm using 3683 AES-CMAC(SK1M, Join Confirm) and adds the resulting hash to the 3684 MIC (Section 6.2.9) message element. 3686 o The AC then transmits the Join Confirm to the WTP. 3688 o Upon receiving the Join Confirm the WTP uses the following 3689 process: 3691 o The WTP authenticates the Join Confirm through the PSK-MIC 3692 message element. If the Join Confirm could not be 3693 authenticated, the packet is dropped. 3695 o SK1E is now plumbed into the AC and WTP's crypto engine as the 3696 AES-CCM LWAPP control encryption session key. Furthermore, the 3697 random IV is used as the base Initialization Vector. From this 3698 point on, all control protocol payloads between the WTP and AC are 3699 encrypted and authenticated using the new session key. 3701 10.3.3 Refreshing Cryptographic Keys 3703 Since AC-WTP associations will tend to be relatively long-lived, it 3704 is sensible to periodically refresh the encryption and authentication 3705 keys; this is referred to as "rekeying". When the key lifetime 3706 reaches 95% of the configured value, identified in the KeyLifetime 3707 timer (see Section 12), the rekeying will proceed as follows: 3709 o The WTP creates RK0 through the previously defined KDF algorithm: 3710 RK0 = KDF-256{SK1D, "LWAPP PSK Top K0" || Session ID || WTP-MAC || 3711 AC-MAC}. Note the difference in this specific instance is that 3712 SK1D that was previously generated is used instead of the PSK. 3713 Note this is used in both the certificate and pre-shared key 3714 modes. The resulting RK0 create RK0E, RK0M. 3716 o The remaining steps used are identical as the join process, with 3717 the exception that the rekey messages are used instead of join 3718 messages, and the fact that the messages are encrypted using the 3719 previously created SK1E. This means the Join Request is replaced 3720 with the Rekey Request, the Join Response is replaced with the 3721 Rekey Response, etc. The two differences between the rekey and 3722 the join process are: 3724 o The Certificate-WTP and Certificate-AC are not included in the 3725 Rekey-Request and Rekey-Response, respectively. 3727 o Regardless of whether certificates or pre-shared key was used 3728 in the initial key derivation, the process now uses the pre- 3729 shared key mode only, using SK1D as the "PSK". 3731 o The Key Update Request is sent to the AC. 3733 o The newly created SK1E is now plumbed into the AC and WTP's crypto 3734 engine as the AES-CCM LWAPP control encryption session key. 3735 Furthermore, the new random IV is used as the base Initialization 3736 Vector. From this point on, all control protocol payloads between 3737 the WTP and AC are encrypted and authenticated using the new 3738 session key. 3740 If either the WTP or the AC do not receive an expected response by 3741 the time the ResponseTimeout timer expires (see Section 12), the 3742 WTP MUST delete the new and old session information, and reset the 3743 state machine to the Idle state. 3745 Following a rekey process, both the WTP and the AC keep the 3746 previous encryption for 5-10 seconds in order to be able to 3747 process packets that arrive out of order. 3749 10.4 Certificate Usage 3751 Validation of the certificates by the AC and WTP is required so that 3752 only an AC may perform the functions of an AC and that only a WTP may 3753 perform the functions of a WTP. This restriction of functions to the 3754 AC or WTP requires that the certificates used by the AC MUST be 3755 distinguishable from the certificate used by the WTP. To accomplish 3756 this differentiation, the x.509v3 certificates MUST include the 3757 Extensions field [10] and MUST include the NetscapeComment [11] 3758 extension. 3760 For an AC, the value of the NetscapeComment extension MUST be the 3761 string "CAPWAP AC Device Certificate". For a WTP, the value of the 3762 NetscapeComment extension MUST be the string "CAPWAP WTP Device 3763 Certificate". 3765 Part of the LWAPP certificate validation process includes ensuring 3766 that the proper string is included in the NetscapeComment extension, 3767 and only allowing the LWAPP session to be established if the 3768 extension does not represent the same role as the device validating 3769 the certificate. For instance, a WTP MUST NOT accept a certificate 3770 whose NetscapeComment field is set to "CAPWAP WTP Device 3771 Certificate". 3773 11. IEEE 802.11 Binding 3775 This section defines the extensions required for the LWAPP protocol 3776 to be used with the IEEE 802.11 protocol. 3778 11.1 Division of labor 3780 The LWAPP protocol, when used with IEEE 802.11 devices, requires a 3781 specific behavior from the WTP and the AC, specifically in terms of 3782 which 802.11 protocol functions are handled. 3784 For both the Split and Local MAC approaches, the CAPWAP functions, as 3785 defined in the taxonomy specification, reside in the AC. 3787 11.1.1 Split MAC 3789 This section shows the division of labor between the WTP and the AC 3790 in a Split MAC architecture. Figure 3 shows the clear separation of 3791 functionality among LWAPP components. 3793 Function Location 3794 Distribution Service AC 3795 Integration Service AC 3796 Beacon Generation WTP 3797 Probe Response WTP 3798 Power Mgmt/Packet Buffering WTP 3799 Fragmentation/Defragmentation WTP 3800 Assoc/Disassoc/Reassoc AC 3802 802.11e 3803 Classifying AC 3804 Scheduling WTP/AC 3805 Queuing WTP 3807 802.11i 3808 802.1X/EAP AC 3809 Key Management AC 3810 802.11 Encryption/Decryption WTP or AC 3812 Figure 3: Mapping of 802.11 Functions for Split MAC Architecture 3814 The Distribution and Integration services reside on the AC, and 3815 therefore all user data is tunneled between the WTP and the AC. As 3816 noted above, all real-time 802.11 services, including the control 3817 protocol and the beacon and probe response frames, are handled on the 3818 WTP. 3820 All remaining 802.11 MAC management frames are supported on the AC, 3821 including the Association Request which allows the AC to be involved 3822 in the access policy enforcement portion of the 802.11 protocol. The 3823 802.1X and 802.11i key management function are also located on the 3824 AC. 3826 While the admission control component of 802.11e resides on the AC, 3827 the real time scheduling and queuing functions are on the WTP. Note 3828 this does not exclude the AC from providing additional policing and 3829 scheduling functionality. 3831 Note that in the following figure, the use of '( - )' indicates that 3832 processing of the frames is done on the WTP. 3834 Client WTP AC 3836 Beacon 3837 <----------------------------- 3838 Probe Request 3839 ----------------------------( - )-------------------------> 3840 Probe Response 3841 <----------------------------- 3842 802.11 AUTH/Association 3843 <---------------------------------------------------------> 3844 Add Mobile (Clear Text, 802.1X Only) 3845 <-------------------------> 3846 802.1X Authentication & 802.11i Key Exchange 3847 <---------------------------------------------------------> 3848 Add Mobile (AES-CCMP, PTK=x) 3849 <-------------------------> 3850 802.11 Action Frames 3851 <---------------------------------------------------------> 3852 802.11 DATA (1) 3853 <---------------------------( - )-------------------------> 3855 Figure 4: Split MAC Message Flow 3857 Figure 4 provides an illustration of the division of labor in a Split 3858 MAC architecture. In this example, a WLAN has been created that is 3859 configured for 802.11i, using AES-CCMP for privacy. The following 3860 process occurs: 3862 o The WTP generates the 802.11 beacon frames, using information 3863 provided to it through the Add WLAN (see Section Section 11.8.1.1) 3864 message element. 3866 o The WTP processes the probe request and responds with a 3867 corresponding probe response. The problem request is then 3868 forwarded to the AC for optional processing. 3870 o The WTP forwards the 802.11 Authentication and Association frames 3871 to the AC, which is responsible for responding to the client. 3873 o Once the association is complete, the AC transmits an LWAPP Add 3874 Mobile request to the WTP (see section Section 11.7.1.1. In the 3875 above example, the WLAN is configured for 802.1X, and therefore 3876 the '802.1X only' policy bit is enabled. 3878 o If the WTP is providing encryption/decryption services, once the 3879 client has completed the 802.11i key exchange, the AC transmits 3880 another Add Mobile request to the WTP, stating the security policy 3881 to enforce for the client (in this case AES-CCMP), as well as the 3882 encryption key to use. If encryption/decryption is handled in the 3883 AC, the Add Mobile request would have the encryption policy set to 3884 "Clear Text". 3886 o The WTP forwards any 802.11 Action frames received to the AC. 3888 o All client data frames are tunneled between the WTP and the AC. 3889 Note that the WTP is responsible for encrypting and decrypting 3890 frames, if it was indicated in the Add Mobile request. 3892 11.1.2 Local MAC 3894 This section shows the division of labor between the WTP and the AC 3895 in a Local MAC architecture. Figure 5 shows the clear separation of 3896 functiionality among LWAPP components. 3898 Function Location 3899 Distribution Service WTP 3900 Integration Service WTP 3901 Beacon Generation WTP 3902 Probe Response WTP 3903 Power Mgmt/Packet Buffering WTP 3904 Fragmentation/Defragmentation WTP 3905 Assoc/Disassoc/Reassoc WTP 3907 802.11e 3908 Classifying WTP 3909 Scheduling WTP 3910 Queuing WTP 3912 802.11i 3913 802.1X/EAP AC 3914 Key Management AC 3915 802.11 Encryption/Decryption WTP 3917 Figure 5: Mapping of 802.11 Functions for Local AP Architecture 3919 Given the Distribution and Integration Services exist on the WTP, 3920 client data frames are not forwarded to the AC, with the exception 3921 listed in the following paragraphs. 3923 While the MAC is terminated on the WTP, it is necessary for the AC to 3924 be aware of mobility events within the WTPs. As a consequence, the 3925 WTP MUST forward the 802.11 Association Requests to the AC, and the 3926 AC MAY reply with a failed Association Response if it deems it 3927 necessary. 3929 The 802.1X and 802.11i Key Management function resides in the AC. 3930 Therefore, the WTP MUST forward all 802.1X/Key Management frames to 3931 the AC and forward the associated responses to the station. 3933 Note that in the following figure, the use of '( - )' indicates that 3934 processing of the frames is done on the WTP. 3936 Client WTP AC 3938 Beacon 3939 <----------------------------- 3940 Probe 3941 <----------------------------> 3942 802.11 AUTH 3943 <----------------------------- 3944 802.11 Association 3945 <---------------------------( - )-------------------------> 3946 Add Mobile (Clear Text, 802.1X Only) 3947 <-------------------------> 3948 802.1X Authentication & 802.11i Key Exchange 3949 <---------------------------------------------------------> 3950 802.11 Action Frames 3951 <---------------------------------------------------------> 3952 Add Mobile (AES-CCMP, PTK=x) 3953 <-------------------------> 3954 802.11 DATA 3955 <-----------------------------> 3957 Figure 6: Local MAC Message Flow 3959 Figure 6 provides an illustration of the division of labor in a Local 3960 MAC architecture. In this example, a WLAN has been created that is 3961 configured for 802.11i, using AES-CCMP for privacy. The following 3962 process occurs: 3964 o The WTP generates the 802.11 beacon frames, using information 3965 provided to it through the Add WLAN (see Section Section 11.8.1.1) 3966 message element. 3968 o The WTP processes the probe request and responds with a 3969 corresponding probe response. 3971 o The WTP forwards the 802.11 Authentication and Association frames 3972 to the AC, which is responsible for responding to the client. 3974 o Once the association is complete, the AC transmits an LWAPP Add 3975 Mobile request to the WTP (see section Section 11.7.1.1. In the 3976 above example, the WLAN is configured for 802.1X, and therefore 3977 the '802.1X only' policy bit is enabled. 3979 o The WTP forwards all 802.1X and 802.11i key exchange messages to 3980 the AC for processing. 3982 o The AC transmits another Add Mobile request to the WTP, stating 3983 the security policy to enforce for the client (in this case AES- 3984 CCMP), as well as the encryption key to use. The Add Mobile 3985 request MAY include a VLAN name, which when present is used by the 3986 WTP to identify the VLAN on which the user's data frames are to be 3987 bridged. 3989 o The WTP forwards any 802.11 Action frames received to the AC. 3991 o The WTP locally bridges all client data frames, and provides the 3992 necessary encryption and decryption services. 3994 11.2 Roaming Behavior and 802.11 security 3996 It is important that LWAPP implementations react properly to mobile 3997 devices associating to the networks in how they generate Add Mobile 3998 and Delete Mobile messages. This section expands upon the examples 3999 provided in the previous section, and describes how the LWAPP control 4000 protocol is used in order to provide secure roaming. 4002 Once a client has successfully associated with the network in a 4003 secure fashion, it is likely to attempt to roam to another access 4004 point. Figure 7 shows an example of a currently associated station 4005 moving from its "Old WTP" to a new WTP. The figure is useful for 4006 multiple different security policies, including standard 802.1X and 4007 dynamic WEP keys, WPA or even WPA2 both with key caching (where the 4008 802.1x exchange would be bypassed) and without. 4010 Client Old WTP WTP AC 4012 Association Request/Response 4013 <--------------------------------------( - )--------------> 4014 Add Mobile (Clear Text, 802.1X Only) 4015 <----------------> 4016 802.1X Authentication (if no key cache entry exists) 4017 <--------------------------------------( - )--------------> 4018 802.11i 4-way Key Exchange 4019 <--------------------------------------( - )--------------> 4020 Delete Mobile 4021 <----------------------------------> 4022 Add Mobile (AES-CCMP, PTK=x) 4023 <----------------> 4025 Figure 7: Client Roaming Example 4027 11.3 Transport specific bindings 4029 All LWAPP transports have the following IEEE 802.11 specific 4030 bindings: 4032 11.3.1 Status and WLANS field 4034 The interpretation of this 16 bit field depends on the direction of 4035 transmission of the packet. Refer to the figure in Section 4036 Section 3.1. 4038 Status 4040 When an LWAPP packet is transmitted from an WTP to an AC, this field 4041 is called the status field and indicates radio resource information 4042 associated with the frame. When the message is an LWAPP control 4043 message this field is transmitted as zero. 4045 The status field is divided into the signal strength and signal to 4046 noise ratio with which an IEEE 802.11 frame was received, encoded in 4047 the following manner: 4049 0 1 4050 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4052 | RSSI | SNR | 4053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4055 RSSI: RSSI is a signed, 8-bit value. It is the received signal 4056 strength indication, in dBm. 4058 SNR: SNR is a signed, 8-bit value. It is the signal to noise ratio 4059 of the received IEEE 802.11 frame, in dB. 4061 WLANs field: When an LWAPP data message is transmitted from an AC to 4062 an WTP, this 16 bit field indicates on which WLANs the 4063 encapsulated IEEE 802.11 frame is to be transmitted. For unicast 4064 packets, this field is not used by the WTP. For broadcast or 4065 multicast packets, the WTP might require this information if it 4066 provides encryption services. 4068 Given that a single broadcast or multicast packet might need to be 4069 sent to multiple wireless LANs (presumably each with a different 4070 broadcast key), this field is defined as a bit field. A bit set 4071 indicates a WLAN ID (see Section Section 11.8.1.1) which will be 4072 sent the data. The WLANS field is encoded in the following 4073 manner: 4075 0 1 4076 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 4077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4078 | WLAN ID(s) | 4079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4081 11.4 BSSID to WLAN ID Mapping 4083 The LWAPP protocol makes assumptions regarding the BSSIDs used on the 4084 WTP. It is a requirement for the WTP to use a contiguous block of 4085 BSSIDs. The WLAN Identifier field, which is managed by the AC, is 4086 used as an offset into the BSSID list. 4088 For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00, 4089 and the AC sent an Add WLAN message with a WLAN Identifier of 2 (see 4090 Section Section 11.8.1.1), the BSSID for the specific WLAN on the WTP 4091 would be 00:01:02:00:00:02. 4093 The WTP communicates the maximum number of BSSIDs that it supports 4094 during the Config Request within the IEEE 802.11 WTP WLAN Radio 4095 Configuration message element (see Section 11.9.1). 4097 11.5 Quality of Service 4099 It is recommended that 802.11 MAC management be sent by both the AC 4100 and the WTP with appropriate Quality of Service values, ensuring that 4101 congestion in the network minimizes occurences of packet loss. 4102 Therefore, a Quality of Service enabled LWAPP device should use: 4104 802.1P: The precedence value of 6 SHOULD be used for all 802.11 MAC 4105 management messages, except for Probe Requests which SHOULD use 4. 4107 DSCP: The dscp tag value of 46 SHOULD be used for all 802.11 MAC 4108 management messages, except for Probe Requests which SHOULD use 4109 34. 4111 11.6 Data Message bindings 4113 There are no LWAPP Data Message bindings for IEEE 802.11. 4115 11.7 Control Message bindings 4117 The IEEE 802.11 binding has the following Control Message 4118 definitions. 4120 11.7.1 Mobile Config Request 4122 This section contains the 802.11 specific message elements that are 4123 used with the Mobile Config Request. 4125 11.7.1.1 Add Mobile 4127 The Add Mobile Request is used by the AC to inform an WTP that it 4128 should forward traffic from a particular mobile station. The add 4129 mobile request may also include security parameters that must be 4130 enforced by the WTP for the particular mobile. 4132 When the AC sends an Add Mobile Request, it includes any security 4133 parameters that may be required. An AC that wishes to update a 4134 mobile's policy on an WTP may be done by simply sending a new Add 4135 Mobile message element. 4137 When an WTP receives an Add Mobile message element, it must first 4138 override any existing state it may have for the mobile station in 4139 question. The latest Add Mobile overrides any previously received 4140 messages. If the Add Mobile message element's EAP Only bit is set, 4141 the WTP MUST drop all 802.11 packets that do not contain EAP packets. 4142 Note that when EAP Only is set, the Encryption Policy field MAY have 4143 additional values, and therefore it is possible to inform an WTP to 4144 only accept encrypted EAP packets. Once the mobile station has 4145 successfully completed EAP authentication, the AC must send a new Add 4146 Mobile message element to push the session key down to the WTP as 4147 well as to remove the EAP Only restriction. 4149 If the QoS field is set, the WTP MUST observe and provide policing of 4150 the 802.11e priority tag to ensure that it does not exceed the value 4151 provided by the AC. 4153 0 1 2 3 4154 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 4155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4156 | Radio ID | Association ID | MAC Address | 4157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4158 | MAC Address | 4159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4160 | MAC Address |E|C| Encryption Policy | 4161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4162 |Encrypt Policy | Session Key... | 4163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4164 | Pairwise TSC... | 4165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4166 | Pairwise RSC... | 4167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4168 | Capabilities | WLAN ID | WME Mode | 4169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4170 | 802.11e Mode | Qos | Supported Rates | 4171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4172 | Supported Rates | 4173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4174 | VLAN Name... 4175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4177 Type: 29 for Add Mobile 4179 Length: 36 4181 Radio ID: An 8-bit value representing the radio 4183 Association ID: A 16-bit value specifying the 802.11 Association 4184 Identifier 4186 MAC Address: The mobile station's MAC Address 4188 E: The one bit field is set by the AC to inform the WTP that is MUST 4189 NOT accept any 802.11 data frames, other than 802.1X frames. This 4190 is the equivalent of the WTP's 802.1X port for the mobile station 4191 to be in the closed state. When set, the WTP MUST drop any non- 4192 802.1X packets it receives from the mobile station. 4194 C: The one bit field is set by the AC to inform the WTP that 4195 encryption services will be provided by the AC. When set, the WTP 4196 SHOULD police frames received from stations to ensure that they 4197 comply to the stated encryption policy, but does not need to take 4198 specific cryptographic action on the frame. Similarly, for 4199 transmitted frames, the WTP only needs to forward already 4200 encrypted frames. 4202 Encryption Policy: The policy field informs the WTP how to handle 4203 packets from/to the mobile station. The following values are 4204 supported: 4206 0 - Encrypt WEP 104: All packets to/from the mobile station must 4207 be encrypted using standard 104 bit WEP. 4209 1 - Clear Text: All packets to/from the mobile station do not 4210 require any additional crypto processing by the WTP. 4212 2 - Encrypt WEP 40: All packets to/from the mobile station must 4213 be encrypted using standard 40 bit WEP. 4215 3 - Encrypt WEP 128: All packets to/from the mobile station must 4216 be encrypted using standard 128 bit WEP. 4218 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 4219 must be encrypted using 128 bit AES CCMP [7] 4221 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 4222 be encrypted using TKIP and authenticated using Michael [18] 4224 Session Key: A 32 octet session key the WTP is to use when 4225 encrypting traffic to or decrypting traffic from the mobile 4226 station. The type of key is determined based on the Encryption 4227 Policy field. 4229 Pairwise TSC: The TSC to use for unicast packets transmitted to the 4230 mobile. 4232 Pairwise RSC: The RSC to use for unicast packets received from the 4233 mobile. 4235 Capabilities: A 16-bit field containing the 802.11 capabilities to 4236 use with the mobile. 4238 WLAN ID: An 8-bit value specifying the WLAN Identifier 4240 WME Mode: A 8-bit boolean used to identify whether the station is 4241 WME capable. A value of zero is used to indicate that the station 4242 is not WME capable, while a value of one means that the station is 4243 WME capable. 4245 802.11e Mode: A 8-bit boolean used to identify whether the station 4246 is 802.11e capable. A value of zero is used to indicate that the 4247 station is not 802.11e capable, while a value of one means that 4248 the station is 802.11e capable. 4250 QoS: An 8-bit value specifying the QoS policy to enforce for the 4251 station. The following values are supported: PRC: TO CHECK 4253 0 - Silver (Best Effort) 4255 1 - Gold (Video) 4257 2 - Platinum (Voice) 4259 3 - Bronze (Background) 4261 Supported Rates: The supported rates to be used with the mobile 4262 station. 4264 VLAN Name: An optional variable string containing the VLAN Name on 4265 which the WTP is to locally bridge user data. Note this field is 4266 only valid with Local MAC WTPs. 4268 11.7.1.2 IEEE 802.11 Mobile Session Key 4270 The Mobile Session Key Payload message element is sent when the AC 4271 determines that encryption of a mobile station must be performed in 4272 the WTP. This message element MUST NOT be present without the Add 4273 Mobile (see Section 11.7.1.1) message element, and MUST NOT be sent 4274 if the WTP had not specifically advertised support for the requested 4275 encryption scheme (see ???). 4277 0 1 2 3 4278 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 4279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4280 | MAC Address | 4281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4282 | MAC Address | Encryption Policy | 4283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4284 | Encryption Policy | Session Key... | 4285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4287 Type: 105 for IEEE 802.11 Mobile Session Key 4289 Length: >= 11 4291 MAC Address: The mobile station's MAC Address 4293 Encryption Policy: The policy field informs the WTP how to handle 4294 packets from/to the mobile station. The following values are 4295 supported: 4297 0 - Encrypt WEP 104: All packets to/from the mobile station must 4298 be encrypted using standard 104 bit WEP. 4300 1 - Clear Text: All packets to/from the mobile station do not 4301 require any additional crypto processing by the WTP. 4303 2 - Encrypt WEP 40: All packets to/from the mobile station must 4304 be encrypted using standard 40 bit WEP. 4306 3 - Encrypt WEP 128: All packets to/from the mobile station must 4307 be encrypted using standard 128 bit WEP. 4309 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 4310 must be encrypted using 128 bit AES CCMP [7] 4312 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 4313 be encrypted using TKIP and authenticated using Michael [18] 4315 Session Key: The session key the WTP is to use when encrypting 4316 traffic to/from the mobile station. 4318 11.7.1.3 Station QoS Profile 4320 The Station QoS Profile Payload message element contains the maximum 4321 802.11e priority tag that may be used by the station. Any packets 4322 received that exceeds the value encoded in this message element must 4323 either be dropped or tagged using the maximum value permitted by to 4324 the user. The priority tag must be between zero (0) and seven (7). 4326 0 1 2 3 4327 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 4328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4329 | MAC Address | 4330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4331 | MAC Address | 802.1P Precedence Tag | 4332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4334 Type: 140 for IEEE 802.11 Station QOS Profile 4336 Length: 12 4338 MAC Address: The mobile station's MAC Address 4340 802.1P Precedence Tag: The maximum 802.1P precedence value that the 4341 WTP will allow in the TID field in the extended 802.11e QOS Data 4342 header. 4344 11.7.1.4 IEEE 802.11 Update Mobile QoS 4346 The Update Mobile QoS message element is used to change the Quality 4347 of Service policy on the WTP for a given mobile station. 4349 0 1 2 3 4350 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 4351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4352 | Radio ID | Association ID | MAC Address | 4353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4354 | MAC Address | 4355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4356 | MAC Address | QoS Profile | Vlan Identifier | 4357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4358 | DSCP Tag | 802.1P Tag | 4359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4361 Type: 106 for IEEE 802.11 Update Mobile QoS 4363 Length: 14 4365 Radio ID: The Radio Identifier, typically refers to some interface 4366 index on the WTP 4368 Association ID: The 802.11 Association Identifier. 4370 MAC Address: The mobile station's MAC Address. 4372 QoS Profile: An 8-bit value specifying the QoS policy to enforce for 4373 the station. The following values are supported: 4375 0 - Silver (Best Effort) 4377 1 - Gold (Video) 4379 2 - Platinum (Voice) 4381 3 - Bronze (Background) 4383 VLAN Identifier: PRC. 4385 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 4387 802.1P Tag: The 802.1P precedence value to use if packets are to be 4388 802.1P tagged. 4390 11.7.2 WTP Event Request 4392 This section contains the 802.11 specific message elements that are 4393 used with the WTP Event Request message. 4395 11.7.2.1 IEEE 802.11 Statistics 4397 The statistics message element is sent by the WTP to transmit it's 4398 current statistics. The value contains the following fields. 4400 0 1 2 3 4401 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 4402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4403 | Radio ID | Tx Fragment Count | 4404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4405 |Tx Fragment Cnt| Multicast Tx Count | 4406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4407 | Mcast Tx Cnt | Failed Count | 4408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4409 | Failed Count | Retry Count | 4410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4411 | Retry Count | Multiple Retry Count | 4412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4413 |Multi Retry Cnt| Frame Duplicate Count | 4414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4415 | Frame Dup Cnt | RTS Success Count | 4416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4417 |RTS Success Cnt| RTS Failure Count | 4418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4419 |RTS Failure Cnt| ACK Failure Count | 4420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4421 |ACK Failure Cnt| Rx Fragment Count | 4422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4423 |Rx Fragment Cnt| Multicast RX Count | 4424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4425 | Mcast Rx Cnt | FCS Error Count | 4426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4427 | FCS Error Cnt| Tx Frame Count | 4428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4429 | Tx Frame Cnt | Decryption Errors | 4430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4431 |Decryption Errs| 4432 +-+-+-+-+-+-+-+-+ 4434 Type: 38 for Statistics 4436 Length: 57 4438 Radio ID: An 8-bit value representing the radio. 4440 Tx Fragment Count: A 32-bit value representing the number of 4441 fragmented frames transmitted. 4443 Multicast Tx Count: A 32-bit value representing the number of 4444 multicast frames transmitted. 4446 Failed Count: A 32-bit value representing the transmit excessive 4447 retries. 4449 Retry Count: A 32-bit value representing the number of transmit 4450 retries. 4452 Multiple Retry Count: A 32-bit value representing the number of 4453 transmits that required more than one retry. 4455 Frame Duplicate Count: A 32-bit value representing the duplicate 4456 frames received. 4458 RTS Success Count: A 32-bit value representing the number of 4459 successfully transmitted Ready To Send (RTS). 4461 RTS Failure Count: A 32-bit value representing the failed 4462 transmitted RTS. 4464 ACK Failure Count: A 32-bit value representing the number of failed 4465 acknowledgements. 4467 Rx Fragment Count: A 32-bit value representing the number of 4468 fragmented frames received. 4470 Multicast RX Count: A 32-bit value representing the number of 4471 multicast frames received. 4473 FCS Error Count: A 32-bit value representing the number of FCS 4474 failures. 4476 Decryption Errors: A 32-bit value representing the number of 4477 Decryption errors that occured on the WTP. Note that this field 4478 is only valid in cases where the WTP provides encryption/ 4479 decryption services. 4481 11.8 802.11 Control Messages 4483 This section will define LWAPP Control Messages that are specific to 4484 the IEEE 802.11 binding. 4486 11.8.1 IEEE 802.11 WLAN Config Request 4488 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 4489 WTP in order to change services provided by the WTP. This control 4490 message is used to either create, update or delete a WLAN on the WTP. 4492 The IEEE 802.11 WLAN Configuration Request is sent as a result of 4493 either some manual admistrative process (e.g., deleting a WLAN), or 4494 automatically to create a WLAN on an WTP. When sent automatically to 4495 create a WLAN, this control message is sent after the LWAPP 4496 Configuration Request message has been received by the WTP. 4498 Upon receiving this control message, the WTP will modify the 4499 necessary services, and transmit an IEEE 802.11 WLAN Configuration 4500 Response. 4502 An WTP MAY provide service for more than one WLAN, therefore every 4503 WLAN is identified through a numerical index. For instance, an WTP 4504 that is capable of supporting up to 16 SSIDs, could accept up to 16 4505 IEEE 802.11 WLAN Configuration Request messages that include the Add 4506 WLAN message element. 4508 Since the index is the primary identifier for a WLAN, an AC SHOULD 4509 attempt to ensure that the same WLAN is identified through the same 4510 index number on all of its WTPs. An AC that does not follow this 4511 approach MUST find some other means of maintaining a WLAN Identifier 4512 to SSID mapping table. 4514 The following subsections define the message elements that are value 4515 for this LWAPP operation. Only one message MUST be present. 4517 11.8.1.1 IEEE 802.11 Add WLAN 4519 The Add WLAN message element is used by the AC to define a wireless 4520 LAN on the WTP. The value contains the following format: 4522 0 1 2 3 4523 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 4524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4525 | Radio ID | WLAN Capability | WLAN ID | 4526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4527 | Encryption Policy | 4528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4529 | Key ... | 4530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4531 | Key Index | Shared Key | WPA Data Len |WPA IE Data ...| 4532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4533 | RSN Data Len |RSN IE Data ...| Reserved .... | 4534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4535 | WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...| 4536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4537 | QoS | Auth Type |Broadcast SSID | Reserved... | 4538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4539 | SSID ... | 4540 +-+-+-+-+-+-+-+-+ 4542 Type: 7 for IEEE 802.11 Add WLAN 4544 Length: >= 298 4546 Radio ID: An 8-bit value representing the radio. 4548 WLAN Capability: A 16-bit value containing the capabilities to be 4549 advertised by the WTP within the Probe and Beacon messages. 4551 WLAN ID: A 16-bit value specifying the WLAN Identifier. 4553 Encryption Policy: A 32-bit value specifying the encryption scheme 4554 to apply to traffic to and from the mobile station. 4556 The following values are supported: 4558 0 - Encrypt WEP 104: All packets to/from the mobile station must 4559 be encrypted using standard 104 bit WEP. 4561 1 - Clear Text: All packets to/from the mobile station do not 4562 require any additional crypto processing by the WTP. 4564 2 - Encrypt WEP 40: All packets to/from the mobile station must 4565 be encrypted using standard 40 bit WEP. 4567 3 - Encrypt WEP 128: All packets to/from the mobile station must 4568 be encrypted using standard 128 bit WEP. 4570 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 4571 must be encrypted using 128 bit AES CCMP [7] 4573 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 4574 be encrypted using TKIP and authenticated using Michael [18] 4576 6 - Encrypt CKIP: All packets to/from the mobile station must be 4577 encrypted using Cisco TKIP. 4579 Key: A 32 byte Session Key to use with the encryption policy. 4581 Key-Index: The Key Index associated with the key. 4583 Shared Key: A 1 byte boolean that specifies whether the key included 4584 in the Key field is a shared WEP key. A value of zero is used to 4585 state that the key is not a shared WEP key, while a value of one 4586 is used to state that the key is a shared WEP key. 4588 WPA Data Len: Length of the WPA IE. 4590 WPA IE: A 32 byte field containing the WPA Information Element. 4592 RSN Data Len: Length of the RSN IE. 4594 RSN IE: A 64 byte field containing the RSN Information Element. 4596 Reserved: A 49 byte reserved field, which MUST be set to zero (0). 4598 WME Data Len: Length of the WME IE. 4600 WME IE: A 32 byte field containing the WME Information Element. 4602 DOT11E Data Len: Length of the 802.11e IE. 4604 DOT11E IE: A 32 byte field containing the 802.11e Information 4605 Element. 4607 QOS: An 8-bit value specifying the QoS policy to enforce for the 4608 station. 4610 The following values are supported: 4612 0 - Silver (Best Effort) 4614 1 - Gold (Video) 4616 2 - Platinum (Voice) 4618 3 - Bronze (Background) 4620 Auth Type: An 8-bit value specifying the station's authentication 4621 type. 4623 The following values are supported: 4625 0 - Open System 4627 1 - WEP Shared Key 4629 2 - WPA/WPA2 802.1X 4631 3 - WPA/WPA2 PSK 4633 Broadcast SSID: A boolean indicating whether the SSID is to be 4634 broadcast by the WTP. A value of zero disables SSID broadcast, 4635 while a value of one enables it. 4637 Reserved: A 40 byte reserved field. 4639 SSID: The SSID attribute is the service set identifier that will be 4640 advertised by the WTP for this WLAN. 4642 11.8.1.2 IEEE 802.11 Delete WLAN 4644 The delete WLAN message element is used to inform the WTP that a 4645 previously created WLAN is to be deleted. The value contains the 4646 following fields: 4648 0 1 2 4649 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4651 | Radio ID | WLAN ID | 4652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4654 Type: 28 for IEEE 802.11 Delete WLAN 4655 Length: 3 4657 Radio ID: An 8-bit value representing the radio 4659 WLAN ID: A 16-bit value specifying the WLAN Identifier 4661 11.8.1.3 IEEE 802.11 Update WLAN 4663 The Update WLAN message element is used by the AC to define a 4664 wireless LAN on the WTP. The value contains the following format: 4666 0 1 2 3 4667 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 4668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4669 | Radio ID | WLAN ID |Encrypt Policy | 4670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4671 | Encryption Policy | Key... | 4672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4673 | Key ... | 4674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4675 | Key Index | Shared Key | WLAN Capability | 4676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4678 Type: 34 for IEEE 802.11 Update WLAN 4680 Length: 43 4682 Radio ID: An 8-bit value representing the radio. 4684 WLAN ID: A 16-bit value specifying the WLAN Identifier. 4686 Encryption Policy: A 32-bit value specifying the encryption scheme 4687 to apply to traffic to and from the mobile station. 4689 The following values are supported: 4691 0 - Encrypt WEP 104: All packets to/from the mobile station must 4692 be encrypted using standard 104 bit WEP. 4694 1 - Clear Text: All packets to/from the mobile station do not 4695 require any additional crypto processing by the WTP. 4697 2 - Encrypt WEP 40: All packets to/from the mobile station must 4698 be encrypted using standard 40 bit WEP. 4700 3 - Encrypt WEP 128: All packets to/from the mobile station must 4701 be encrypted using standard 128 bit WEP. 4703 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 4704 must be encrypted using 128 bit AES CCMP [7] 4706 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 4707 be encrypted using TKIP and authenticated using Michael [18] 4709 6 - Encrypt CKIP: All packets to/from the mobile station must be 4710 encrypted using Cisco TKIP. 4712 Key: A 32 byte Session Key to use with the encryption policy. 4714 Key-Index: The Key Index associated with the key. 4716 Shared Key: A 1 byte boolean that specifies whether the key included 4717 in the Key field is a shared WEP key. A value of zero means that 4718 the key is not a shared WEP key, while a value of one is used to 4719 state that the key is a shared WEP key. 4721 WLAN Capability: A 16-bit value containing the capabilities to be 4722 advertised by the WTP within the Probe and Beacon messages. 4724 11.8.2 IEEE 802.11 WLAN Config Response 4726 The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the 4727 AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN 4728 Configuration Request. 4730 This LWAPP control message does not include any message elements. 4732 11.8.3 IEEE 802.11 WTP Event 4734 The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order 4735 to report asynchronous events to the AC. There is no reply message 4736 expected from the AC, except that the message is acknowledged via the 4737 reliable transport. 4739 When the AC receives the IEEE 802.11 WTP Event, it will take whatever 4740 action is necessary, depending upon the message elements present in 4741 the message. 4743 The IEEE 802.11 WTP Event message MUST contain one of the following 4744 message element described in the next subsections. 4746 11.8.3.1 IEEE 802.11 MIC Countermeasures 4748 The MIC Countermeasures message element is sent by the WTP to the AC 4749 to indicate the occurrence of a MIC failure. 4751 0 1 2 3 4752 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 4753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4754 | Radio ID | WLAN ID | MAC Address | 4755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4756 | MAC Address | 4757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4759 Type: 61 for IEEE 802.11 MIC Countermeasures 4761 Length: 8 4763 Radio ID: The Radio Identifier, typically refers to some interface 4764 index on the WTP. 4766 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 4767 on which the MIC failure occurred. 4769 MAC Address: The MAC Address of the mobile station that caused the 4770 MIC failure. 4772 11.8.3.2 IEEE 802.11 WTP Radio Fail Alarm Indication 4774 The WTP Radio Fail Alarm Indication message element is sent by the 4775 WTP to the AC when it detects a radio failure. 4777 0 1 2 3 4778 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 4779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4780 | Radio ID | Type | Status | Pad | 4781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4783 Type: 95 for WTP Radio Fail Alarm Indication 4785 Length: 4 4787 Radio ID: The Radio Identifier, typically refers to some interface 4788 index on the WTP 4790 Type: The type of radio failure detected. The following values are 4791 supported: 4793 1 - Receiver 4795 2 - Transmitter 4797 Status: An 8-bit boolean indicating whether the radio failure is 4798 being reported or cleared. A value of zero is used to clear the 4799 event, while a value of one is used to report the event. 4801 Pad: Reserved field MUST be set to zero (0). 4803 11.9 Message Element Bindings 4805 The IEEE 802.11 Message Element binding has the following 4806 definitions: 4808 Conf Conf Conf Add 4809 Req Resp Upd Mobile 4811 IEEE 802.11 WTP WLAN Radio Configuration X X X 4812 IEEE 802.11 Rate Set X X 4813 IEEE 802.11 Multi-domain Capability X X X 4814 IEEE 802.11 MAC Operation X X X 4815 IEEE 802.11 Tx Power X X X 4816 IEEE 802.11 Tx Power Level X 4817 IEEE 802.11 Direct Sequence Control X X X 4818 IEEE 802.11 OFDM Control X X X 4819 IEEE 802.11 Supported Rates X X 4820 IEEE 802.11 Antenna X X X 4821 IEEE 802.11 CFP Status X X 4822 IEEE 802.11 Broadcast Probe Mode X X 4823 IEEE 802.11 WTP Mode and Type X? X 4824 IEEE 802.11 WTP Quality of Service X X 4825 IEEE 802.11 MIC Error Report From Mobile X 4826 IEEE 802.11 Update Mobile QoS X 4827 IEEE 802.11 Mobile Session Key X 4829 11.9.1 IEEE 802.11 WTP WLAN Radio Configuration 4831 The WTP WLAN radio configuration is used by the AC to configure a 4832 Radio on the WTP. The message element value contains the following 4833 Fields: 4835 0 1 2 3 4836 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 4837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4838 | Radio ID | Reserved | Occupancy Limit | 4839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4840 | CFP Per | CFP Maximum Duration | BSS ID | 4841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4842 | BSS ID | 4843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4844 | BSS ID | Beacon Period | DTIM Per | 4845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4846 | Country String | 4847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4848 | Num Of BSSIDs | 4849 +-+-+-+-+-+-+-+-+ 4851 Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration 4853 Length: 20 4855 Radio ID: An 8-bit value representing the radio to configure. 4857 Reserved: MUST be set to zero 4859 Occupancy Limit: This attribute indicates the maximum amount of 4860 time, in TU, that a point coordinator MAY control the usage of the 4861 wireless medium without relinquishing control for long enough to 4862 allow at least one instance of DCF access to the medium. The 4863 default value of this attribute SHOULD be 100, and the maximum 4864 value SHOULD be 1000. 4866 CFP Period: The attribute describes the number of DTIM intervals 4867 between the start of CFPs. 4869 CFP Maximum Duration: The attribute describes the maximum duration 4870 of the CFP in TU that MAY be generated by the PCF. 4872 BSSID: The WLAN Radio's base MAC Address. For WTPs that support 4873 more than a single WLAN, the value of the WLAN Identifier is added 4874 to the last octet of the BSSID. Therefore, a WTP that supports 16 4875 WLANs MUST have 16 MAC Addresses reserved for it, and the last 4876 nibble is used to represent the WLAN ID. 4878 Beacon Period: This attribute specifies the number of TU that a 4879 station uses for scheduling Beacon transmissions. This value is 4880 transmitted in Beacon and Probe Response frames. 4882 DTIM Period: This attribute specifies the number of beacon intervals 4883 that elapses between transmission of Beacons frames containing a 4884 TIM element whose DTIM Count field is 0. This value is 4885 transmitted in the DTIM Period field of Beacon frames. 4887 Country Code: This attribute identifies the country in which the 4888 station is operating. The first two octets of this string is the 4889 two character country code as described in document ISO/IEC 3166- 4890 1. The third octet MUST be one of the following: 4892 1. an ASCII space character, if the regulations under which the 4893 station is operating encompass all environments in the 4894 country, 4896 2. an ASCII 'O' character, if the regulations under which the 4897 station is operating are for an outdoor environment only, or 4899 3. an ASCII 'I' character, if the regulations under which the 4900 station is operating are for an indoor environment only 4902 Number of BSSIDs: This attribute contains the maximum number of 4903 BSSIDs supported by the WTP. This value restricts the number of 4904 logical networks supported by the WTP. 4906 11.9.2 IEEE 802.11 Rate Set 4908 The rate set message element value is sent by the AC and contains the 4909 supported operational rates. It contains the following fields. 4911 0 1 2 3 4912 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 4913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4914 | Radio ID | Rate Set | 4915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4917 Type: 16 for IEEE 802.11 Rate Set 4919 Length: 4 4921 Radio ID: An 8-bit value representing the radio to configure. 4923 Rate Set: The AC generates the Rate Set that the WTP is to include 4924 in it's Beacon and Probe messages. 4926 11.9.3 IEEE 802.11 Multi-domain Capability 4928 The multi-domain capability message element is used by the AC to 4929 inform the WTP of regulatory limits. The value contains the 4930 following fields. 4932 0 1 2 3 4933 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 4934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4935 | Radio ID | Reserved | First Channel # | 4936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4937 | Number of Channels | Max Tx Power Level | 4938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4940 Type: 10 for IEEE 802.11 Multi-Domain Capability 4942 Length: 8 4944 Radio ID: An 8-bit value representing the radio to configure. 4946 Reserved: MUST be set to zero 4948 First Channnel #: This attribute indicates the value of the lowest 4949 channel number in the subband for the associated domain country 4950 string. 4952 Number of Channels: This attribute indicates the value of the total 4953 number of channels allowed in the subband for the associated 4954 domain country string. 4956 Max Tx Power Level: This attribute indicates the maximum transmit 4957 power, in dBm, allowed in the subband for the associated domain 4958 country string. 4960 11.9.4 IEEE 802.11 MAC Operation 4962 The MAC operation message element is sent by the AC to set the 802.11 4963 MAC parameters on the WTP. The value contains the following fields. 4965 0 1 2 3 4966 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 4967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4968 | Radio ID | Reserved | RTS Threshold | 4969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4970 | Short Retry | Long Retry | Fragmentation Threshold | 4971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4972 | Tx MSDU Lifetime | 4973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4974 | Rx MSDU Lifetime | 4975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4977 Type: 11 for IEEE 802.11 MAC Operation 4979 Length: 16 4981 Radio ID: An 8-bit value representing the radio to configure. 4983 Reserved: MUST be set to zero 4985 RTS Threshold: This attribute indicates the number of octets in an 4986 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 4987 RTS/CTS handshake MUST be performed at the beginning of any frame 4988 exchange sequence where the MPDU is of type Data or Management, 4989 the MPDU has an individual address in the Address1 field, and the 4990 length of the MPDU is greater than this threshold. Setting this 4991 attribute to be larger than the maximum MSDU size MUST have the 4992 effect of turning off the RTS/CTS handshake for frames of Data or 4993 Management type transmitted by this STA. Setting this attribute 4994 to zero MUST have the effect of turning on the RTS/CTS handshake 4995 for all frames of Data or Management type transmitted by this STA. 4996 The default value of this attribute MUST be 2347. 4998 Short Retry: This attribute indicates the maximum number of 4999 transmission attempts of a frame, the length of which is less than 5000 or equal to RTSThreshold, that MUST be made before a failure 5001 condition is indicated. The default value of this attribute MUST 5002 be 7. 5004 Long Retry: This attribute indicates the maximum number of 5005 transmission attempts of a frame, the length of which is greater 5006 than dot11RTSThreshold, that MUST be made before a failure 5007 condition is indicated. The default value of this attribute MUST 5008 be 4. 5010 Fragmentation Threshold: This attribute specifies the current 5011 maximum size, in octets, of the MPDU that MAY be delivered to the 5012 PHY. An MSDU MUST be broken into fragments if its size exceeds 5013 the value of this attribute after adding MAC headers and trailers. 5014 An MSDU or MMPDU MUST be fragmented when the resulting frame has 5015 an individual address in the Address1 field, and the length of the 5016 frame is larger than this threshold. The default value for this 5017 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 5018 attached PHY and MUST never exceed the lesser of 2346 or the 5019 aMPDUMaxLength of the attached PHY. The value of this attribute 5020 MUST never be less than 256. 5022 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 5023 after the initial transmission of an MSDU, after which further 5024 attempts to transmit the MSDU MUST be terminated. The default 5025 value of this attribute MUST be 512. 5027 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 5028 after the initial reception of a fragmented MMPDU or MSDU, after 5029 which further attempts to reassemble the MMPDU or MSDU MUST be 5030 terminated. The default value MUST be 512. 5032 11.9.5 IEEE 802.11 Tx Power 5034 The Tx power message element value is bi-directional. When sent by 5035 the WTP, it contains the current power level of the radio in 5036 question. When sent by the AC, it contains the power level the WTP 5037 MUST adhere to. 5039 0 1 2 3 5040 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 5041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5042 | Radio ID | Reserved | Current Tx Power | 5043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5045 Type: 12 for IEEE 802.11 Tx Power 5047 Length: 4 5049 Radio ID: An 8-bit value representing the radio to configure. 5051 Reserved: MUST be set to zero 5053 Current Tx Power: This attribute contains the transmit output power 5054 in mW. 5056 11.9.6 IEEE 802.11 Tx Power Level 5058 The Tx power level message element is sent by the WTP and contains 5059 the different power levels supported. The value contains the 5060 following fields. 5062 0 1 2 3 5063 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 5064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5065 | Radio ID | Num Levels | Power Level [n] | 5066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5068 Type: 13 for IEEE 802.11 Tx Power Level 5070 Length: >= 4 5072 Radio ID: An 8-bit value representing the radio to configure. 5074 Num Levels: The number of power level attributes. 5076 Power Level: Each power level fields contains a supported power 5077 level, in mW. 5079 11.9.7 IEEE 802.11 Direct Sequence Control 5081 The direct sequence control message element is a bi-directional 5082 element. When sent by the WTP, it contains the current state. When 5083 sent by the AC, the WTP MUST adhere to the values. This element is 5084 only used for 802.11b radios. The value has the following fields. 5086 0 1 2 3 5087 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 5088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5089 | Radio ID | Reserved | Current Chan | Current CCA | 5090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5091 | Energy Detect Threshold | 5092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5094 Type: 14 for IEEE 802.11 Direct Sequence Control 5096 Length: 8 5098 Radio ID: An 8-bit value representing the radio to configure. 5100 Reserved: MUST be set to zero 5102 Current Channel: This attribute contains the current operating 5103 frequency channel of the DSSS PHY. 5105 Current CCA: The current CCA method in operation. Valid values are: 5107 1 - energy detect only (edonly) 5109 2 - carrier sense only (csonly) 5111 4 - carrier sense and energy detect (edandcs) 5113 8 - carrier sense with timer (cswithtimer) 5115 16 - high rate carrier sense and energy detect (hrcsanded) 5117 Energy Detect Threshold: The current Energy Detect Threshold being 5118 used by the DSSS PHY. 5120 11.9.8 IEEE 802.11 OFDM Control 5122 The OFDM control message element is a bi-directional element. When 5123 sent by the WTP, it contains the current state. When sent by the AC, 5124 the WTP MUST adhere to the values. This element is only used for 5125 802.11a radios. The value contains the following fields: 5127 0 1 2 3 5128 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 5129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5130 | Radio ID | Reserved | Current Chan | Band Support | 5131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5132 | TI Threshold | 5133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5135 Type: 15 for IEEE 802.11 OFDM Control 5137 Length: 8 5139 Radio ID: An 8-bit value representing the radio to configure. 5141 Reserved: MUST be set to zero 5143 Current Channel: This attribute contains the current operating 5144 frequency channel of the OFDM PHY. 5146 Band Supported: The capability of the OFDM PHY implementation to 5147 operate in the three U-NII bands. Coded as an integer value of a 5148 three bit field as follows: 5150 capable of operating in the lower (5.15-5.25 GHz) U-NII band 5152 capable of operating in the middle (5.25-5.35 GHz) U-NII band 5154 capable of operating in the upper (5.725-5.825 GHz) U-NII band 5156 For example, for an implementation capable of operating in the 5157 lower and mid bands this attribute would take the value 5159 TI Threshold: The Threshold being used to detect a busy medium 5160 (frequency). CCA MUST report a busy medium upon detecting the 5161 RSSI above this threshold. 5163 11.9.9 IEEE 802.11 Antenna 5165 The antenna message element is communicated by the WTP to the AC to 5166 provide information on the antennas available. The AC MAY use this 5167 element to reconfigure the WTP's antennas. The value contains the 5168 following fields: 5170 0 1 2 3 5171 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 5172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5173 | Radio ID | Diversity | Combiner | Antenna Cnt | 5174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5175 | Antenna Selection [0..N] | 5176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5178 Type: 41 for IEEE 802.11 Antenna 5180 Length: >= 8 5182 Radio ID: An 8-bit value representing the radio to configure. 5184 Diversity: An 8-bit value specifying whether the antenna is to 5185 provide receive diversity. The following values are supported: 5187 0 - Disabled 5189 1 - Enabled (may only be true if the antenna can be used as a 5190 receive antenna) 5192 Combiner: An 8-bit value specifying the combiner selection. The 5193 following values are supported: 5195 1 - Sectorized (Left) 5197 2 - Sectorized (Right) 5199 3 - Omni 5201 4 - Mimo 5203 Antenna Count: An 8-bit value specifying the number of Antenna 5204 Selection fields. 5206 Antenna Selection: One 8-bit antenna configuration value per antenna 5207 in the WTP. The following values are supported: 5209 1 - Internal Antenna 5211 2 - External Antenna 5213 11.9.10 IEEE 802.11 Supported Rates 5215 The supported rates message element is sent by the WTP to indicate 5216 the rates that it supports. The value contains the following fields. 5218 0 1 2 3 5219 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 5220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5221 | Radio ID | Supported Rates | 5222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5224 Type: 16 for IEEE 802.11 Supported Rates 5226 Length: 4 5228 Radio ID: An 8-bit value representing the radio. 5230 Supported Rates: The WTP includes the Supported Rates that it's 5231 hardware supports. The format is identical to the Rate Set 5232 message element. 5234 11.9.11 IEEE 802.11 CFP Status 5236 The CFP Status message element is sent to provide the CF Polling 5237 configuration. 5239 0 1 5240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5242 | Radio ID | Status | 5243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5245 Type: 48 for IEEE 802.11 CFP Status 5247 Length: 2 5249 Radio ID: The Radio Identifier, typically refers to some interface 5250 index on the WTP 5252 Status: An 8-bit boolean containing the status of the CF Polling 5253 feature. A value of zero disables CFP Status, while a value of 5254 one enables it. 5256 11.9.12 IEEE 802.11 WTP Mode and Type 5258 The WTP Mode and Type message element is used to configure an WTP to 5259 operate in a specific mode. 5261 0 1 5262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5264 | Mode | Type | 5265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5267 Type: 54 for IEEE 802.11 WTP Mode and Type 5269 Length: 2 5271 Mode: An 8-bit value the type of information being sent. The 5272 following values are supported: 5274 0 - Split MAC 5276 2 - Local MAC 5278 Type: The type field is not currently used. 5280 11.9.13 IEEE 802.11 Broadcast Probe Mode 5282 The Broadcast Probe Mode message element indicates whether an WTP 5283 will respond to NULL SSID probe requests. Since broadcast NULL 5284 probes are not sent to a specific BSSID, the WTP cannot know which 5285 SSID the sending station is querying. Therefore, this behavior must 5286 be global to the WTP. 5288 0 5289 0 1 2 3 4 5 6 7 5290 +-+-+-+-+-+-+-+-+ 5291 | Status | 5292 +-+-+-+-+-+-+-+-+ 5294 Type: 51 for IEEE 802.11 Broadcast Probe Mode 5296 Length: 1 5298 Status: An 8-bit boolean indicating the status of whether an WTP 5299 shall response to a NULL SSID probe request. A value of zero 5300 disables NULL SSID probe response, while a value of one enables 5301 it. 5303 11.9.14 IEEE 802.11 WTP Quality of Service 5305 The WTP Quality of Service message element value is sent by the AC to 5306 the WTP to communicate quality of service configuration information. 5308 0 1 5309 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5311 | Radio ID | Tag Packets | 5312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5314 Type: 57 for IEEE 802.11 WTP Quality of Service 5316 Length: 12 5318 Radio ID: The Radio Identifier, typically refers to some interface 5319 index on the WTP 5321 Tag Packets: An value indicating whether LWAPP packets should be 5322 tagged with for QoS purposes. The following values are currently 5323 supported: 5325 0 - Untagged 5327 1 - 802.1P 5328 2 - DSCP 5330 Immediately following the above header is the following data 5331 structure. This data structure will be repeated five times; once 5332 for every QoS profile. The order of the QoS profiles are Uranium, 5333 Platinum, Gold, Silver and Bronze. 5335 0 1 2 3 5336 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 5337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5338 | Queue Depth | CWMin | CWMax | 5339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5340 | CWMax | AIFS | CBR | 5341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5342 | Dot1P Tag | DSCP Tag | 5343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5345 Queue Depth: The number of packets that can be on the specific QoS 5346 transmit queue at any given time. 5348 CWMin: The Contention Window minimum value for the QoS transmit 5349 queue. 5351 CWMax: The Contention Window maximum value for the QoS transmit 5352 queue. 5354 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 5355 transmit queue. 5357 CBR: The CBR value to observe for the QoS transmit queue. 5359 Dot1P Tag: The 802.1P precedence value to use if packets are to be 5360 802.1P tagged. 5362 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 5364 11.9.15 IEEE 802.11 MIC Error Report From Mobile 5366 The MIC Error Report From Mobile message element is sent by an AC to 5367 an WTP when it receives a MIC failure notification, via the Error bit 5368 in the EAPOL-Key frame. 5370 0 1 2 3 5371 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 5372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5373 | Client MAC Address | 5374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5375 | Client MAC Address | BSSID | 5376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5377 | BSSID | 5378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5379 | Radio ID | WLAN ID | 5380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5382 Type: 79 for IEEE 802.11 MIC Error Report From Mobile 5384 Length: 14 5386 Client MAC Address: The Client MAC Address of the station reporting 5387 the MIC failure. 5389 BSSID: The BSSID on which the MIC failure is being reported. 5391 Radio ID: The Radio Identifier, typically refers to some interface 5392 index on the WTP 5394 WLAN ID: The WLAN ID on which the MIC failure is being reported. 5396 11.10 IEEE 802.11 Message Element Values 5398 This section lists IEEE 802.11 specific values for any generic LWAPP 5399 message elements which include fields whose values are technology 5400 specific. 5402 IEEE 802.11 uses the following values: 5404 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 5406 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 5407 [18]. 5409 12. LWAPP Protocol Timers 5411 An WTP or AC that implements LWAPP discovery MUST implement the 5412 following timers. 5414 12.1 MaxDiscoveryInterval 5416 The maximum time allowed between sending discovery requests from the 5417 interface, in seconds. Must be no less than 2 seconds and no greater 5418 than 180 seconds. 5420 Default: 20 seconds. 5422 12.2 SilentInterval 5424 The minimum time, in seconds, an WTP MUST wait after failing to 5425 receive any responses to its discovery requests, before it MAY again 5426 send discovery requests. 5428 Default: 30 5430 12.3 NeighborDeadInterval 5432 The minimum time, in seconds, an WTP MUST wait without having 5433 received Echo Responses to its Echo Requests, before the destination 5434 for the Echo Request may be considered dead. Must be no less than 5435 2*EchoInterval seconds and no greater than 240 seconds. 5437 Default: 60 5439 12.4 EchoInterval 5441 The minimum time, in seconds, between sending echo requests to the AC 5442 with which the WTP has joined. 5444 Default: 30 5446 12.5 DiscoveryInterval 5448 The minimum time, in seconds, that an WTP MUST wait after receiving a 5449 Discovery Response, before sending a join request. 5451 Default: 5 5453 12.6 RetransmitInterval 5455 The minimum time, in seconds, which a non-acknowledged LWAPP packet 5456 will be retransmitted. 5458 Default: 3 5460 12.7 ResponseTimeout 5462 The minimum time, in seconds, which an LWAPP Request message must be 5463 responded to. 5465 Default: 1 5467 12.8 KeyLifetime 5469 The maximum time, in seconds, which an LWAPP session key is valid. 5471 Default: 28800 5473 13. LWAPP Protocol Variables 5475 An WTP or AC that implements LWAPP discovery MUST allow for the 5476 following variables to be configured by system management; default 5477 values are specified so as to make it unnecessary to configure any of 5478 these variables in many cases. 5480 13.1 MaxDiscoveries 5482 The maximum number of discovery requests that will be sent after an 5483 WTP boots. 5485 Default: 10 5487 13.2 DiscoveryCount 5489 The number of discoveries transmitted by a WTP to a single AC. This 5490 is a monotonically increasing counter. 5492 13.3 RetransmitCount 5494 The number of retransmissions for a given LWAPP packet. This is a 5495 monotonically increasing counter. 5497 13.4 MaxRetransmit 5499 The maximum number of retransmissions for a given LWAPP packet before 5500 the link layer considers the peer dead. 5502 Default: 5 5504 14. NAT Considerations 5506 There are two specific situations where a NAT system may be used in 5507 conjunction with LWAPP. The first consists of a configuration where 5508 the WTP is behind a NAT system. Given that all communication is 5509 initiated by the WTP, and all communication is performed over IP 5510 using a single UDP port, the protocol easily traverses NAT systems in 5511 this configuration. 5513 The second configuration is one where the AC sits behind a NAT and 5514 there are two main issues that exist in this situation. First, an AC 5515 communicates its interfaces, and associated WTP load on these 5516 interfaces, through the WTP Manager Control IP Address. This message 5517 element is currently mandatory, and if NAT compliance became an 5518 issue, it would be possible to either: 5520 1. Make the WTP Manager Control IP Address optional, allowing the WTP 5521 to simply use the known IP Address. However, note that this 5522 approach would eliminate the ability to perform load balancing of 5523 WTP across ACs, and therefore is not the recommended approach. 5525 2. Allow an AC to be able to configure a NAT'ed address for every 5526 associated AC that would generally be communicated in the WTP 5527 Manager Control IP Address message element. 5529 3. Require that if a WTP determines that the AC List message element 5530 consists of a set of IP Addresses that are different from the AC's 5531 IP Address it is currently communicating with, then assume that 5532 NAT is being enforced, and require that the WTP communicate with 5533 the original AC's IP Address (and ignore the WTP Manager Control 5534 IP Address message element(s)). 5536 Another issue related to having an AC behind a NAT system is LWAPP's 5537 support for the CAPWAP Objective to allow the control and data plane 5538 to be separated. In order to support this requirement, the LWAPP 5539 protocol defines the WTP Manager Data IP Address message element, 5540 which allows the AC to inform the WTP that the LWAPP data frames are 5541 to be forwarded to a separate IP Address. This feature MUST be 5542 disabled when an AC is behind a NAT. However, there is no easy way 5543 to provide some default mechanism that satisfies both the data/ 5544 control separation and NAT objectives, as they directly conflict with 5545 each other. As a consequence, user intervention will be required to 5546 support such networks. 5548 LWAPP has a feature that allows for all of the ACs identities 5549 supporting a group of WTPs to be communicated through the AC List 5550 message element. This feature must be disabled when the AC is behind 5551 a NAT and the IP Address that is embedded would be invalid. 5553 The LWAPP protocol has a feature that allows an AC to configure a 5554 static IP address on a WTP. The WTP Static IP Address Information 5555 message element provides such a function, however this feature SHOULD 5556 NOT be used in NAT'ed environments, unless the administrator is 5557 familiar with the internal IP addressing scheme within the WTP's 5558 private network, and does not rely on the public address seen by the 5559 AC. 5561 When a WTP detects the duplicate address condition, it generates a 5562 message to the AC, which includes the Duplicate IP Address message 5563 element. Once again, it is important to note that the IP Address 5564 embedded within this message element would be different from the 5565 public IP address seen by the AC. 5567 15. Security Considerations 5569 LWAPP uses either an authenticated key exchange or key agreement 5570 mechanism to ensure peer authenticity and establish fresh session 5571 keys to protect the LWAPP communications. 5573 The LWAPP protocol defines a join phase, which allows a WTP to bind a 5574 session with an AC. During this process, a session key is mutually 5575 derived, and secured either through an X.509 certificate or a pre- 5576 shared key. The resulting key exchange generates an encryption 5577 session key, which is used to encrypt the LWAPP control packets, and 5578 a key derivation key. 5580 During the established secure communication, the WTP and AC may rekey 5581 using the key update process, which is identical to the join phase, 5582 meaning the session keys are mutually derived. However, the exchange 5583 described for pre-shared session keys is always used for the key 5584 update, with the pre-shared key set to the derivation key created 5585 either during the join, or the last key update if one has occurred. 5586 The key update results in a new derivation key, which is used in the 5587 next key update, as well as an encryption session key to encrypt the 5588 LWAPP control packets. 5590 Replay protection of the Join Request is handled through an exchange 5591 of Nonces during the Join (or key update) phase. The Join Request 5592 includes an XNonce, which is included in the AC's authenticated Join 5593 Replys encrypted ANonce message element, allowing for the two 5594 messages to be bound. Upon receipt of the Join Reply, the WTP 5595 generates the WNonce, and generates a set of session keys using a KDF 5596 function. One of these keys is used to MIC the Join ACK. The AC 5597 responds with a Join Confirm, which must also include a MIC, and 5598 therefore be capable of deriving the same set of session keys. 5600 In both the X.509 certificate and pre-shared key modes, an 5601 initialization vector is created through the above mentioned KDF 5602 function. The IV and the KDF created encryption key are used to 5603 encrypt the LWAPP control frames. 5605 Given that authentication in the Join exchange does not occur until 5606 the WTP transmits the Join ACK message, it is crucial that an AC not 5607 delete any state for a WTP it is service until an authentication Join 5608 ACK has been received. Otherwise, a potential Denial of Service 5609 attack exists, whereby sending a spoofed Join Request for a valid WTP 5610 would cause the AC to reset the WTP's connection. 5612 It is important to note that Perfect Forward Secrecy is not a 5613 requirement for the LWAPP protocol. 5615 Note that the LWAPP protocol does not add any new vulnerabilities to 5616 802.11 infrastructure that makes use of WEP for encryption purposes. 5617 However, implementors SHOULD discourage the use of WEP to allow the 5618 market to move towards technically sound cryptographic solutions, 5619 such as 802.11i. 5621 15.1 Certificate based Session Key establishment 5623 LWAPP uses public key cryptography to ensure trust between the WTP 5624 and the AC. One question that periodically arises is why the Join 5625 Request is not signed. Signing this request would not be optimal for 5626 the following reasons: 5628 1. The Join Request is replayable, so a signature doesn't provide 5629 much protection unless the switches keep track of all previous 5630 Join Requests from a given WTP. 5632 2. Replay detection is handled during the Join Reply and Join ACK 5633 messages. 5635 3. A signed Join Request provides a potential Denial of Service 5636 attack on the AC, which would have to authenticate each 5637 (potentially malicious) message. 5639 The WTP-Certificate that is included in the Join Request MUST be 5640 validated by the AC. It is also good practice that the AC perform 5641 some form of authorization, ensuring that the WTP in question is 5642 allowed to establish an LWAPP session with it. 5644 15.2 PSK based Session Key establishment 5646 Use of a fixed shared secret of limited entropy (for example, a PSK 5647 that is relatively short, or was chosen by a human and thus may 5648 contain less entropy than its length would imply) may allow an 5649 attacker to perform a brute-force or dictionary attack to recover the 5650 secret. 5652 It is RECOMMENDED that implementations that allow the administrator 5653 to manually configure the PSK also provide a functionality for 5654 generating a new random PSK, taking RFC 1750 [4] into account. 5656 Since the key generation does not expose the nonces in plaintext, 5657 there are no practical passive attacks possible. 5659 16. IANA Considerations 5661 This document requires no action by IANA. 5663 17. Acknowledgements 5665 The authors wish to thank Michael Vakulenko for contributing text 5666 that describes how LWAPP can be used over a layer 3 (IP) network. 5668 The authors would like to thanks Russ Housley and Charles Clancy for 5669 their assistance in provide a security review of the LWAPP 5670 specification. Charles' review can be found at [12]. 5672 18. IPR Statement 5674 The IETF has been notified of intellectual property rights claimed in 5675 regard to some or all of the specification contained in this 5676 document. For more information consult the online list of claimed 5677 rights. 5679 Please refer to http://www.ietf.org/ietf/IPR for more information. 5681 19. References 5683 19.1 Normative References 5685 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 5686 Levels", BCP 14, RFC 2119, March 1997. 5688 [2] National Institute of Standards and Technology, "Advanced 5689 Encryption Standard (AES)", FIPS PUB 197, November 2001, 5690 . 5692 [3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC- 5693 MAC (CCM)", RFC 3610, September 2003. 5695 [4] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 5696 Recommendations for Security", RFC 1750, December 1994. 5698 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 5699 RFC 3753, June 2004. 5701 [6] "Information technology - Telecommunications and information 5702 exchange between systems - Local and metropolitan area networks 5703 - Specific requirements - Part 11: Wireless LAN Medium Access 5704 Control (MAC) and Physical Layer (PHY) specifications", 5705 IEEE Standard 802.11, 1999, 5706 . 5709 [7] "Information technology - Telecommunications and information 5710 exchange between systems - Local and metropolitan area networks 5711 - Specific requirements - Part 11: Wireless LAN Medium Access 5712 Control (MAC) and Physical Layer (PHY) specifications Amendment 5713 6: Medium Access Control (MAC) Security Enhancements", 5714 IEEE Standard 802.11i, July 2004, . 5717 [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, 5718 July 1982. 5720 [9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) 5721 Key Wrap Algorithm", RFC 3394, September 2002. 5723 [10] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 5724 Public Key Infrastructure Certificate and Certificate 5725 Revocation List (CRL) Profile", RFC 3280, April 2002. 5727 [11] "Netscape Certificate Extensions Specification", 5728 . 5730 [12] Clancy, C., "Security Review of the Light Weight Access Point 5731 Protocol", May 2005, 5732 . 5734 [13] "Recommendation for Block Cipher Modes of Operation: the CMAC 5735 Mode for Authentication", May 2005, . 5738 19.2 Informational References 5740 [14] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 5741 line Database", RFC 3232, January 2002. 5743 [15] Bradner, S., "The Internet Standards Process -- Revision 3", 5744 BCP 9, RFC 2026, October 1996. 5746 [16] Kent, S. and R. Atkinson, "Security Architecture for the 5747 Internet Protocol", RFC 2401, November 1998. 5749 [17] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 5750 for Message Authentication", RFC 2104, February 1997. 5752 [18] "WiFi Protected Access (WPA) rev 1.6", April 2003. 5754 Authors' Addresses 5756 Pat R. Calhoun 5757 Cisco Systems, Inc. 5758 170 West Tasman Drive 5759 San Jose, CA 95134 5761 Phone: +1 408-853-5269 5762 Email: pcalhoun@cisco.com 5764 Bob O'Hara 5765 Cisco Systems, Inc. 5766 170 West Tasman Drive 5767 San Jose, CA 95134 5769 Phone: +1 408-853-5513 5770 Email: bob.ohara@cisco.com 5771 Rohit Suri 5772 Cisco Systems, Inc. 5773 170 West Tasman Drive 5774 San Jose, CA 95134 5776 Phone: +1 408-853-5548 5777 Email: rsuri@cisco.com 5779 Nancy 5780 Cisco Systems, Inc. 5781 170 West Tasman Drive 5782 San Jose, CA 95134 5784 Phone: +1 408-853-0532 5785 Email: ncamwing@cisco.com 5787 Scott Kelly 5788 Facetime Communications 5789 1159 Triton Dr 5790 Foster City, CA 94404 5792 Phone: +1 650 572-5846 5793 Email: scott@hyperthought.com 5795 Michael Glenn Williams 5796 Nokia, Inc. 5797 313 Fairchild Drive 5798 Mountain View, CA 94043 5800 Phone: +1 650-714-7758 5801 Email: Michael.G.Williams@Nokia.com 5803 Sue Hares 5804 Nexthop Technologies, Inc. 5805 825 Victors Way, Suite 100 5806 Ann Arbor, MI 48108 5808 Phone: +1 734 222 1610 5809 Email: shares@nexthop.com 5811 Intellectual Property Statement 5813 The IETF takes no position regarding the validity or scope of any 5814 Intellectual Property Rights or other rights that might be claimed to 5815 pertain to the implementation or use of the technology described in 5816 this document or the extent to which any license under such rights 5817 might or might not be available; nor does it represent that it has 5818 made any independent effort to identify any such rights. Information 5819 on the procedures with respect to rights in RFC documents can be 5820 found in BCP 78 and BCP 79. 5822 Copies of IPR disclosures made to the IETF Secretariat and any 5823 assurances of licenses to be made available, or the result of an 5824 attempt made to obtain a general license or permission for the use of 5825 such proprietary rights by implementers or users of this 5826 specification can be obtained from the IETF on-line IPR repository at 5827 http://www.ietf.org/ipr. 5829 The IETF invites any interested party to bring to its attention any 5830 copyrights, patents or patent applications, or other proprietary 5831 rights that may cover technology that may be required to implement 5832 this standard. Please address the information to the IETF at 5833 ietf-ipr@ietf.org. 5835 Disclaimer of Validity 5837 This document and the information contained herein are provided on an 5838 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5839 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5840 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5841 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5842 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5845 Copyright Statement 5847 Copyright (C) The Internet Society (2005). This document is subject 5848 to the rights, licenses and restrictions contained in BCP 78, and 5849 except as set forth therein, the authors retain all their rights. 5851 Acknowledgment 5853 Funding for the RFC Editor function is currently provided by the 5854 Internet Society.