idnits 2.17.1 draft-ietf-capwap-protocol-specification-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 6145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6169. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-capwap-protocol-binding-ieee80211]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Unless otherwise specified, a control message that lists a set of supported (or expected) message elements MUST not expect the message elements to be in any specific order. The sender MAY include the message elements in any order. Unless otherwise noted, one message element of each type is present in a given control message. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2008) is 5859 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1456, but not defined == Unused Reference: 'RFC2132' is defined on line 6048, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-06 -- Unexpected draft version: The latest known version of draft-calhoun-dhc-capwap-ac-option is -00, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. 'I-D.calhoun-dhc-capwap-ac-option' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun, Editor 3 Internet-Draft Cisco Systems, Inc. 4 Expires: September 14, 2008 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 March 13, 2008 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-10 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 14, 2008. 38 Abstract 40 This specification defines the Control And Provisioning of Wireless 41 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF 42 CAPWAP working group protocol requirements. The CAPWAP protocol is 43 designed to be flexible, allowing it to be used for a variety of 44 wireless technologies. This document describes the base CAPWAP 45 protocol. The CAPWAP protocol binding which defines extensions for 46 use with the IEEE 802.11 wireless LAN protocol is available in 47 [I-D.ietf-capwap-protocol-binding-ieee80211]. Extensions are 48 expected to be defined to enable use of the CAPWAP protocol with 49 additional wireless technologies. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 54 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 1.2. Conventions used in this document . . . . . . . . . . . . 9 56 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 57 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 59 2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 13 60 2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 14 61 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 16 62 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 63 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 31 64 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 33 65 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 33 66 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 34 67 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 35 68 2.4.4. DTLS EndPoint Authentication and Authorization . . . 36 69 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 40 70 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 40 71 3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 40 72 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 41 73 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 42 74 3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . . 42 75 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 43 76 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . . 45 77 4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 45 78 4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 46 79 4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 49 80 4.4.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 49 81 4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 50 82 4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 51 83 4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 51 84 4.5.1. Control Message Format . . . . . . . . . . . . . . . 52 85 4.5.2. Control Message Quality of Service . . . . . . . . . 55 86 4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 55 87 4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 56 88 4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 58 89 4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 60 90 4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 61 91 4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 61 92 4.6.5. AC Name with Index . . . . . . . . . . . . . . . . . 62 93 4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 62 94 4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 63 95 4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 63 96 4.6.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 64 97 4.6.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 64 98 4.6.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 65 99 4.6.12. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 66 100 4.6.13. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 66 101 4.6.14. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 67 102 4.6.15. CAPWAP Transport Protocol . . . . . . . . . . . . . . 67 103 4.6.16. Data Transfer Data . . . . . . . . . . . . . . . . . 68 104 4.6.17. Data Transfer Mode . . . . . . . . . . . . . . . . . 69 105 4.6.18. Decryption Error Report . . . . . . . . . . . . . . . 69 106 4.6.19. Decryption Error Report Period . . . . . . . . . . . 70 107 4.6.20. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 70 108 4.6.21. Delete Station . . . . . . . . . . . . . . . . . . . 71 109 4.6.22. Delete Static MAC ACL Entry . . . . . . . . . . . . . 71 110 4.6.23. Discovery Type . . . . . . . . . . . . . . . . . . . 72 111 4.6.24. Duplicate IPv4 Address . . . . . . . . . . . . . . . 73 112 4.6.25. Duplicate IPv6 Address . . . . . . . . . . . . . . . 73 113 4.6.26. Idle Timeout . . . . . . . . . . . . . . . . . . . . 74 114 4.6.27. Image Data . . . . . . . . . . . . . . . . . . . . . 75 115 4.6.28. Image Identifier . . . . . . . . . . . . . . . . . . 75 116 4.6.29. Image Information . . . . . . . . . . . . . . . . . . 76 117 4.6.30. Initiate Download . . . . . . . . . . . . . . . . . . 77 118 4.6.31. Location Data . . . . . . . . . . . . . . . . . . . . 77 119 4.6.32. Maximum Message Length . . . . . . . . . . . . . . . 77 120 4.6.33. Radio Administrative State . . . . . . . . . . . . . 78 121 4.6.34. Radio Operational State . . . . . . . . . . . . . . . 78 122 4.6.35. Result Code . . . . . . . . . . . . . . . . . . . . . 79 123 4.6.36. Returned Message Element . . . . . . . . . . . . . . 81 124 4.6.37. Session ID . . . . . . . . . . . . . . . . . . . . . 81 125 4.6.38. Statistics Timer . . . . . . . . . . . . . . . . . . 82 126 4.6.39. Vendor Specific Payload . . . . . . . . . . . . . . . 82 127 4.6.40. WTP Board Data . . . . . . . . . . . . . . . . . . . 83 128 4.6.41. WTP Descriptor . . . . . . . . . . . . . . . . . . . 84 129 4.6.42. WTP Fallback . . . . . . . . . . . . . . . . . . . . 85 130 4.6.43. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 86 131 4.6.44. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 87 132 4.6.45. WTP IPv6 IP Address . . . . . . . . . . . . . . . . . 87 133 4.6.46. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 88 134 4.6.47. WTP Name . . . . . . . . . . . . . . . . . . . . . . 89 135 4.6.48. WTP Operational Statistics . . . . . . . . . . . . . 89 136 4.6.49. WTP Radio Statistics . . . . . . . . . . . . . . . . 90 137 4.6.50. WTP Reboot Statistics . . . . . . . . . . . . . . . . 91 138 4.6.51. WTP Static IP Address Information . . . . . . . . . . 92 139 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 93 140 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 93 141 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 93 142 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 94 143 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 94 144 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 94 145 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 94 146 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 94 147 4.7.8. ImageDataStartTimer . . . . . . . . . . . . . . . . . 94 148 4.7.9. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 95 149 4.7.10. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 95 150 4.7.11. ResponseTimeout . . . . . . . . . . . . . . . . . . . 95 151 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 95 152 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 95 153 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 95 154 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 95 155 4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 96 156 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 96 157 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 96 158 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 96 159 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 96 160 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 96 161 4.8.5. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 96 162 4.8.6. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 96 163 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 97 164 4.8.8. ReportInterval . . . . . . . . . . . . . . . . . . . 97 165 4.8.9. RetransmitCount . . . . . . . . . . . . . . . . . . . 97 166 4.8.10. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 97 167 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 97 168 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 97 169 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 97 170 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 97 171 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 97 172 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 98 173 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 98 174 4.9.7. Static ACL Table . . . . . . . . . . . . . . . . . . 98 175 4.9.8. Static IP Address . . . . . . . . . . . . . . . . . . 98 176 4.9.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 98 177 4.9.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 98 178 4.9.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 98 179 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 99 180 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 99 181 5.2. Discovery Response Message . . . . . . . . . . . . . . . 100 182 5.3. Primary Discovery Request Message . . . . . . . . . . . . 101 183 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 102 184 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 104 185 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 104 186 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 105 187 7. Control Channel Management . . . . . . . . . . . . . . . . . 108 188 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 108 189 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 108 190 8. WTP Configuration Management . . . . . . . . . . . . . . . . 110 191 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 110 192 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 111 193 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 111 194 8.3. Configuration Status Response . . . . . . . . . . . . . . 112 195 8.4. Configuration Update Request . . . . . . . . . . . . . . 113 196 8.5. Configuration Update Response . . . . . . . . . . . . . . 114 197 8.6. Change State Event Request . . . . . . . . . . . . . . . 114 198 8.7. Change State Event Response . . . . . . . . . . . . . . . 116 199 8.8. Clear Configuration Request . . . . . . . . . . . . . . . 116 200 8.9. Clear Configuration Response . . . . . . . . . . . . . . 116 201 9. Device Management Operations . . . . . . . . . . . . . . . . 118 202 9.1. Firmware Management . . . . . . . . . . . . . . . . . . . 118 203 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 121 204 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 122 205 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . . 123 206 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 123 207 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . . 124 208 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 125 209 9.6. Data Transfer Request . . . . . . . . . . . . . . . . . . 125 210 9.7. Data Transfer Response . . . . . . . . . . . . . . . . . 126 211 10. Station Session Management . . . . . . . . . . . . . . . . . 127 212 10.1. Station Configuration Request . . . . . . . . . . . . . . 127 213 10.2. Station Configuration Response . . . . . . . . . . . . . 127 214 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 129 215 12. Security Considerations . . . . . . . . . . . . . . . . . . . 131 216 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 131 217 12.1.1. Converting Protected Data into Unprotected Data . . . 132 218 12.1.2. Converting Unprotected Data into Protected Data 219 (Insertion) . . . . . . . . . . . . . . . . . . . . . 132 220 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 132 221 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 132 222 12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 132 223 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . . 133 224 12.4. Interference with a DTLS Session . . . . . . . . . . . . 134 225 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . . 134 226 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 135 227 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 136 228 12.8. AAA Security . . . . . . . . . . . . . . . . . . . . . . 137 230 13. Management Considerations . . . . . . . . . . . . . . . . . . 138 231 14. Transport Considerations . . . . . . . . . . . . . . . . . . 139 232 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140 233 15.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 140 234 15.2. Wireless Binding Identifiers . . . . . . . . . . . . . . 140 235 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 141 236 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 237 17.1. Normative References . . . . . . . . . . . . . . . . . . 142 238 17.2. Informational References . . . . . . . . . . . . . . . . 143 239 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 144 240 Intellectual Property and Copyright Statements . . . . . . . . . 145 242 1. Introduction 244 This document describes the CAPWAP Protocol, a standard, 245 interoperable protocol which enables an Access Controller (AC) to 246 manage a collection of Wireless Termination Points (WTPs). The 247 CAPWAP protocol is defined to be independent of layer 2 technology. 249 The emergence of centralized IEEE 802.11 Wireless Local Area Network 250 (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by 251 an Access Controller (AC) suggested that a standards based, 252 interoperable protocol could radically simplify the deployment and 253 management of wireless networks. WTPs require a set of dynamic 254 management and control functions related to their primary task of 255 connecting the wireless and wired mediums. Traditional protocols for 256 managing WTPs are either manual static configuration via HTTP, 257 proprietary Layer 2 specific or non-existent (if the WTPs are self- 258 contained). An IEEE 802.11 binding is defined in 259 [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the 260 CAPWAP protocol with IEEE 802.11 WLAN networks. 262 CAPWAP assumes a network configuration consisting of multiple WTPs 263 communicating via the Internet Protocol (IP) to an AC. WTPs are 264 viewed as remote RF interfaces controlled by the AC. The CAPWAP 265 protocol supports two modes of operation: Split and Local MAC. In 266 Split MAC mode all L2 wireless data and management frames are 267 encapsulated via the CAPWAP protocol and exchanged between the AC and 268 the WTP. As shown in Figure 1, the wireless frames received from a 269 mobile device, which is referred to in this specification as a 270 Station (STA), are directly encapsulated by the WTP and forwarded to 271 the AC. 273 +-+ wireless frames +-+ 274 | |--------------------------------| | 275 | | +-+ | | 276 | |--------------| |---------------| | 277 | |wireless PHY/ | | CAPWAP | | 278 | | MAC sublayer | | | | 279 +-+ +-+ +-+ 280 STA WTP AC 282 Figure 1: Representative CAPWAP Architecture for Split MAC 284 The Local MAC mode of operation allows for the data frames to be 285 either locally bridged, or tunneled as 802.3 frames. The latter 286 implies that the WTP performs the 802.11 Integration function. In 287 either case the L2 wireless management frames are processed locally 288 by the WTP, and then forwarded to the AC. Figure 2 shows the Local 289 MAC mode, in which a station transmits a wireless frame which is 290 encapsulated in an 802.3 frame and forwarded to the AC. 292 +-+wireless frames +-+ 802.3 frames +-+ 293 | |----------------| |--------------| | 294 | | | | | | 295 | |----------------| |--------------| | 296 | |wireless PHY/ | | CAPWAP | | 297 | | MAC sublayer | | | | 298 +-+ +-+ +-+ 299 STA WTP AC 301 Figure 2: Representative CAPWAP Architecture for Local MAC 303 Provisioning WTPs with security credentials, and managing which WTPs 304 are authorized to provide service are traditionally handled by 305 proprietary solutions. Allowing these functions to be performed from 306 a centralized AC in an interoperable fashion increases manageability 307 and allows network operators to more tightly control their wireless 308 network infrastructure. 310 1.1. Goals 312 The goals for the CAPWAP protocol are listed below: 314 1. To centralize the authentication and policy enforcement functions 315 for a wireless network. The AC may also provide centralized 316 bridging, forwarding, and encryption of user traffic. 317 Centralization of these functions will enable reduced cost and 318 higher efficiency by applying the capabilities of network 319 processing silicon to the wireless network, as in wired LANs. 321 2. To enable shifting of the higher level protocol processing from 322 the WTP. This leaves the time critical applications of wireless 323 control and access in the WTP, making efficient use of the 324 computing power available in WTPs which are the subject to severe 325 cost pressure. 327 3. To provide a generic encapsulation and transport mechanism, 328 enabling the CAPWAP protocol to be applied to many access point 329 types in the future, via a specific wireless binding. 331 The CAPWAP protocol concerns itself solely with the interface between 332 the WTP and the AC. Inter-AC and station-to AC-communication are 333 strictly outside the scope of this document. 335 1.2. Conventions used in this document 337 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 338 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 339 document are to be interpreted as described in RFC 2119 [RFC2119]. 341 1.3. Contributing Authors 343 This section lists and acknowledges the authors of significant text 344 and concepts included in this specification. 346 The CAPWAP Working Group selected the Lightweight Access Point 347 Protocol (LWAPP) [add reference, when available] to be used as the 348 basis of the CAPWAP protocol specification. The following people are 349 authors of the LWAPP document: 351 Bob O'Hara, Cisco Systems, Inc. 352 170 West Tasman Drive, San Jose, CA 95134 353 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 355 Pat Calhoun, Cisco Systems, Inc. 356 170 West Tasman Drive, San Jose, CA 95134 357 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 359 Rohit Suri, Cisco Systems, Inc. 360 170 West Tasman Drive, San Jose, CA 95134 361 Phone: +1 408-853-5548, Email: rsuri@cisco.com 363 Nancy Cam Winget, Cisco Systems, Inc. 364 170 West Tasman Drive, San Jose, CA 95134 365 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 367 Scott Kelly, Aruba Networks 368 1322 Crossman Ave, Sunnyvale, CA 94089 369 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 371 Michael Glenn Williams, Nokia, Inc. 372 313 Fairchild Drive, Mountain View, CA 94043 373 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 375 Sue Hares, Nexthop Technologies, Inc. 376 825 Victors Way, Suite 100, Ann Arbor, MI 48108 377 Phone: +1 734 222 1610, Email: shares@nexthop.com 379 DTLS is used as the security solution for the CAPWAP protocol. The 380 following people are authors of significant DTLS-related text 381 included in this document: 383 Scott Kelly, Aruba Networks 384 1322 Crossman Ave, Sunnyvale, CA 94089 385 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 387 Eric Rescorla, Network Resonance 388 2483 El Camino Real, #212,Palo Alto CA, 94303 389 Email: ekr@networkresonance.com 391 The concept of using DTLS to secure the CAPWAP protocol was part of 392 the Secure Light Access Point Protocol (SLAPP) proposal [add 393 reference when available]. The following people are authors of the 394 SLAPP proposal: 396 Partha Narasimhan, Aruba Networks 397 1322 Crossman Ave, Sunnyvale, CA 94089 398 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 400 Dan Harkins, Tropos Networks 401 555 Del Rey Avenue, Sunnyvale, CA, 95085 402 Phone: +1 408 470 7372, Email: dharkins@tropos.com 404 Subbu Ponnuswamy, Aruba Networks 405 1322 Crossman Ave, Sunnyvale, CA 94089 406 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 408 The following individuals contributed significant security related 409 text to the draft: 411 T. Charles Clancy, Laboratory for Telecommunications Sciences, 412 8080 Greenmead Drive, College Park, MD 20740 413 Phone: +1 240-373-5069, Email: clancy@ltsnet.net 415 Scott Kelly, Aruba Networks 416 1322 Crossman Ave, Sunnyvale, CA 94089 417 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 419 1.4. Terminology 421 Access Controller (AC): The network entity that provides WTP access 422 to the network infrastructure in the data plane, control plane, 423 management plane, or a combination therein. 425 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 426 Address, WTP IP Address, AC control port, WTP control port and the 427 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control 428 packets are sent and received. 430 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 431 Address, WTP IP Address, AC data port, WTP data port, and the 432 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data 433 packets are sent and received. 435 Station (STA): A device that contains an interface to a wireless 436 medium (WM). 438 Wireless Termination Point (WTP): The physical or network entity that 439 contains an RF antenna and wireless PHY to transmit and receive 440 station traffic for wireless access networks. 442 This document uses additional terminology defined in [RFC3753]. 444 2. Protocol Overview 446 The CAPWAP protocol is a generic protocol defining AC and WTP control 447 and data plane communication via a CAPWAP protocol transport 448 mechanism. CAPWAP control messages, and optionally CAPWAP data 449 messages, are secured using Datagram Transport Layer Security (DTLS) 450 [RFC4346]. DTLS is a standards-track IETF protocol based upon TLS. 451 The underlying security-related protocol mechanisms of TLS have been 452 successfully deployed for many years. 454 The CAPWAP protocol Transport layer carries two types of payload, 455 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 456 messages encapsulate forwarded wireless frames. CAPWAP protocol 457 Control messages are management messages exchanged between a WTP and 458 an AC. The CAPWAP Data and Control packets are sent over separate 459 UDP ports. Since both data and control packets can exceed the 460 Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data 461 or control message can be fragmented. The fragmentation behavior is 462 defined in Section 3. 464 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 465 Discovery Request message, causing any Access Controller (AC) 466 receiving the message to respond with a Discovery Response message. 467 From the Discovery Response messages received, a WTP selects an AC 468 with which to establish a secure DTLS session. CAPWAP protocol 469 messages will be fragmented to the maximum length discovered to be 470 supported by the network. 472 Once the WTP and the AC have completed DTLS session establishment, a 473 configuration exchange occurs in which both devices agree on version 474 information. During this exchange the WTP may receive provisioning 475 settings. The WTP is then enabled for operation. 477 When the WTP and AC have completed the version and provision exchange 478 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 479 the wireless data frames sent between the WTP and AC. The CAPWAP 480 protocol will fragment the L2 frames if the size of the encapsulated 481 wireless user data (Data) or protocol control (Management) frames 482 causes the resulting CAPWAP protocol packet to exceed the MTU 483 supported between the WTP and AC. Fragmented CAPWAP packets are 484 reassembled to reconstitute the original encapsulated payload. MTU 485 Discovery and Fragmentation are described in Section 3. 487 The CAPWAP protocol provides for the delivery of commands from the AC 488 to the WTP for the management of stations that are communicating with 489 the WTP. This may include the creation of local data structures in 490 the WTP for the stations and the collection of statistical 491 information about the communication between the WTP and the stations. 493 The CAPWAP protocol provides a mechanism for the AC to obtain 494 statistical information collected by the WTP. 496 The CAPWAP protocol provides for a keep alive feature that preserves 497 the communication channel between the WTP and AC. If the AC fails to 498 appear alive, the WTP will try to discover a new AC. 500 2.1. Wireless Binding Definition 502 The CAPWAP protocol is independent of a specific WTP radio 503 technology. Elements of the CAPWAP protocol are designed to 504 accommodate the specific needs of each wireless technology in a 505 standard way. Implementation of the CAPWAP protocol for a particular 506 wireless technology MUST follow the binding requirements defined for 507 that technology. 509 When defining a binding for wireless technologies, the authors MUST 510 include any necessary definitions for technology-specific messages 511 and all technology-specific message elements for those messages. At 512 a minimum, a binding MUST provide: 514 1. The definition for a binding-specific Statistics message element, 515 carried in the WTP Event Request message 517 2. A message element carried in the Station Configuration Request 518 message to configure station information on the WTP 520 3. A WTP Radio Information message element carried in the Discovery, 521 Primary Discovery and Join Request and Response messages, 522 indicating the binding specific radio types supported at the WTP 523 and AC. 525 If technology specific message elements are required for any of the 526 existing CAPWAP messages defined in this specification, they MUST 527 also be defined in the technology binding document. 529 The naming of binding-specific message elements MUST begin with the 530 name of the technology type, e.g., the binding for IEEE 802.11, 531 provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with 532 "IEEE 802.11". 534 The CAPWAP binding concept MUST also be used in any future 535 specification that add functionality to either the base CAPWAP 536 protocol specification, or any published CAPWAP binding 537 specification. A separate WTP Radio Information message element MUST 538 be created to properly advertise support for the specification. This 539 mechanism allows for future protocol extensibility, while providing 540 the necessary capabilities advertisement, through the WTP Radio 541 Information message element, to ensure WTP/AC interoperability. 543 2.2. CAPWAP Session Establishment Overview 545 This section describes the session establishment process message 546 exchanges in the ideal case. The annotated ladder diagram shows the 547 AC on the right, the WTP on the left, and assumes the use of 548 certificates for DTLS authentication. The CAPWAP Protocol State 549 Machine is described in detail in Section 2.3. Note that DTLS allows 550 certain messages to be aggregated into a single frame, which is 551 denoted via an asterisk in the following figure. 553 ============ ============ 554 WTP AC 555 ============ ============ 556 [----------- begin optional discovery ------------] 558 Discover Request 559 ------------------------------------> 560 Discover Response 561 <------------------------------------ 563 [----------- end optional discovery ------------] 565 (-- begin DTLS handshake --) 567 ClientHello 568 ------------------------------------> 569 HelloVerifyRequest (with cookie) 570 <------------------------------------ 572 ClientHello (with cookie) 573 ------------------------------------> 574 ServerHello, 575 Certificate, 576 ServerHelloDone* 577 <------------------------------------ 579 (-- WTP callout for AC authorization --) 581 Certificate (optional), 582 ClientKeyExchange, 583 CertificateVerify (optional), 584 ChangeCipherSpec, 585 Finished* 586 ------------------------------------> 588 (-- AC callout for WTP authorization --) 590 ChangeCipherSpec, 591 Finished* 592 <------------------------------------ 594 (-- DTLS session is established now --) 596 Join Request 597 ------------------------------------> 598 Join Response 599 <------------------------------------ 600 [-- Join State Complete --] 602 (-- assume image is up to date --) 604 Configuration Status Request 605 ------------------------------------> 606 Configuration Status Response 607 <------------------------------------ 608 [-- Configure State Complete --] 610 Change State Event Request 611 ------------------------------------> 612 Change State Event Response 613 <------------------------------------ 614 [-- Data Check State Complete --] 616 (-- enter RUN state --) 618 : 619 : 621 Echo Request 622 ------------------------------------> 623 Echo Response 624 <------------------------------------ 626 : 627 : 629 Event Request 630 ------------------------------------> 631 Event Response 632 <------------------------------------ 634 : 635 : 637 At the end of the illustrated CAPWAP message exchange, the AC and WTP 638 are securely exchanging CAPWAP control messages. This is an 639 idealized illustration, provided to clarify protocol operation. 640 Section 2.3 provides a detailed description of the corresponding 641 state machine. 643 2.3. CAPWAP State Machine Definition 645 The following state diagram represents the lifecycle of a WTP-AC 646 session. Use of DTLS by the CAPWAP protocol results in the 647 juxtaposition of two nominally separate yet tightly bound state 648 machines. The DTLS and CAPWAP state machines are coupled through an 649 API consisting of commands (see Section 2.3.2.1) and notifications 650 (see Section 2.3.2.2). Certain transitions in the DTLS state machine 651 are triggered by commands from the CAPWAP state machine, while 652 certain transitions in the CAPWAP state machine are triggered by 653 notifications from the DTLS state machine. 655 /-------------------------------------\ 656 | /-------------------------\| 657 | p| || 658 | q+----------+ r +------------+ || 659 | | Run |-->| Reset |-\|| 660 | +----------+ +------------+ ||| 661 n| o ^ ^ ^ s||| 662 +------------+--------/ | | ||| 663 | Data Check | /-------/ | ||| 664 +------------+<-------\ | | ||| 665 | | | ||| 666 /------------------+--------\ | ||| 667 f| m| h| j v k| ||| 668 +--------+ +-----------+ +--------------+||| 669 | Join |---->| Configure | | Image Data |||| 670 +--------+ n +-----------+ +--------------+||| 671 ^ |g i| l| ||| 672 | | \-------------------\ | ||| 673 | \--------------------------------------\| | ||| 674 \------------------------\ || | ||| 675 /--------------<----------------+---------------\ || | ||| 676 | /------------<----------------+-------------\ | || | ||| 677 | | 4 |d t| | vv v vvv 678 | | +----------------+ +--------------+ +-----------+ 679 | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | 680 /-|-|---+----------------+ +--------------+ e +-----------+ 681 | | | |$ ^ ^ |5 ^6 ^ ^ |w 682 v v v | | | | \-------\ | | | 683 | | | | | | \---------\ | | /-----------/ | 684 | | | | | \--\ | | | | | 685 | | | | | | | | | | | 686 | | | v 3| 1 |% # v | |a |b v 687 | | \->+------+-->+------+ +-----------+ +--------+ 688 | | | Idle | | Disc | | Authorize | | Dead | 689 | | +------+<--+------+ +-----------+ +--------+ 690 | | ^ 0^ 2 |! 691 | | | | | +-------+ 692 *| |u | \---------+---| Start | 693 | | |@ | +-------+ 694 | \->+---------+<------/ 695 \--->| Sulking | 696 +---------+& 698 Figure 3: CAPWAP Integrated State Machine 700 The CAPWAP protocol state machine, depicted above, is used by both 701 the AC and the WTP. In cases where states are not shared (i.e. not 702 implemented in one or the other of the AC or WTP), this is explicitly 703 called out in the transition descriptions below. For every state 704 defined, only certain messages are permitted to be sent and received. 705 The CAPWAP control message definitions specify the state(s) in which 706 each message is valid. 708 Since the WTP only communicates with a single AC, it only has a 709 single instance of the CAPWAP state machine. The state machine works 710 differently on the AC since it communicates with many WTPs. The AC 711 uses the concept of three threads. Note that the term thread used 712 here does not necessarily imply that implementers must use threads, 713 but it is one possible way of implementing the AC's state machine. 715 Listener Thread: The AC's Listener thread handles inbound DTLS 716 session establishment requests, through the DTLSListen command. 717 Upon creation, the Listener thread starts in the DTLS Setup state. 718 Once a DTLS session has been validated, which occurs when the 719 state machine enters the "Authorize" state, the Listener thread 720 creates a WTP session specific Service thread and state context. 721 The state machine transitions in figure Figure 3 are represented 722 by numerals. It is necessary for the AC to protect itself against 723 various attacks that exist with non-authenticated frames. See 724 Section 12 for more information. 726 Discovery Thread: The AC's Discovery thread is responsible for 727 receiving, and responding to, Discovery Request messages. The 728 state machine transitions in figure Figure 3 are represented by 729 numerals. Note that the Discovery thread does not maintain any 730 per-WTP specific context information, and a single state context 731 exists. It is necessary for the AC to protect itself against 732 various attacks that exist with non-authenticated frames. See 733 Section 12 for more information. 735 Service Thread: The AC's Service thread handles the per-WTP states, 736 and one such thread exists per-WTP connection. This thread is 737 created by the listener thread when the Authorize state is 738 reached. When created, the Service thread inherits a copy of the 739 state machine context from the Listener thread. When 740 communication with the WTP is complete, the Service thread is 741 terminated and all associated resources are released. The state 742 machine transitions in figure Figure 3 are represented by 743 alphabetic characters. 745 2.3.1. CAPWAP Protocol State Transitions 747 This section describes the various state transitions, and the events 748 that cause them. This section does not discuss interactions between 749 DTLS- and CAPWAP-specific states. Those interactions, and DTLS- 750 specific states and transitions, are discussed in Section 2.3.2. 752 Start to Idle (0): This transition occurs once device initialization 753 is complete. 755 WTP: This state transition is used to start the WTP's CAPWAP 756 state machine. 758 AC: The AC creates the Discovery and Listener threads and starts 759 the CAPWAP state machine. 761 Idle to Discovery (1): This transition occurs to support the CAPWAP 762 discovery process . 764 WTP: The WTP enters the Discovery state prior to transmitting the 765 first Discovery Request message (see Section 5.1). Upon 766 entering this state, the WTP sets the DiscoveryInterval timer 767 (see Section 4.7). The WTP resets the DiscoveryCount counter 768 to zero (0) (see Section 4.8). The WTP also clears all 769 information from ACs it may have received during a previous 770 Discovery phase. 772 AC: This state transition is executed by the AC's Discovery 773 thread, and occurs when a Discovery Request message is 774 received. The AC SHOULD respond with a Discovery Response 775 message (see Section 5.2). 777 Discovery to Discovery (#): In the Discovery state, the WTP 778 determines which AC to connect to. 780 WTP: This transition occurs when the DiscoveryInterval timer 781 expires. If the WTP is configured with a list of ACs, it 782 transmits a Discovery Request message to every AC from which it 783 has not received a Discovery Response message. For every 784 transition to this event, the WTP increments the DiscoveryCount 785 counter. See Section 5.1 for more information on how the WTP 786 knows the ACs to which it should transmit the Discovery Request 787 messages. The WTP restarts the DiscoveryInterval timer 788 whenever it transmits Discovery Request messages. 790 AC: This is an invalid state transition for the AC. 792 Discovery to Idle (2): This transition occurs on the AC's Discovery 793 thread when the Discovery processing is complete. 795 WTP: This is an invalid state transition for the WTP. 797 AC: This state transition is executed by the AC's Discovery 798 thread when it has transmitted the Discovery Response, in 799 response to a Discovery Request. 801 Discovery to Sulking (!): This transition occurs on a WTP when AC 802 Discovery fails. 804 WTP: The WTP enters this state when the DiscoveryInterval timer 805 expires and the DiscoveryCount variable is equal to the 806 MaxDiscoveries variable (see Section 4.8). Upon entering this 807 state, the WTP MUST start the SilentInterval timer. While in 808 the Sulking state, all received CAPWAP protocol messages MUST 809 be ignored. 811 AC: This is an invalid state transition for the AC. 813 Sulking to Idle (@): This transition occurs on a WTP when it must 814 restart the discovery phase. 816 WTP: The WTP enters this state when the SilentInterval timer (see 817 Section 4.7) expires. The FailedDTLSSessionCount, 818 DiscoveryCount and FailedDTLSAuthFailCount counters are reset 819 to zero. 821 AC: This is an invalid state transition for the AC. 823 Sulking to Sulking (&): The Sulking state provides the silent 824 period, minimizing the possibility for Denial of Service (DoS) 825 attacks. 827 WTP: All packets received from the AC while in the sulking state 828 are ignored. 830 AC: This is an invalid state transition for the AC. 832 Idle to DTLS Setup (3): This transition occurs to establish a secure 833 DTLS session with the peer. 835 WTP: The WTP initiates this transition by invoking the DTLSStart 836 command, which starts the DTLS session establishment with the 837 chosen AC. When the discovery phase is bypassed, it is assumed 838 the WTP has locally configured ACs. 840 AC: Upon entering the Idle state from the Start state, the newly 841 created Listener thread automatically transitions to the DTLS 842 Setup and invokes the DTLSListen command (see Section 2.3.2.1). 844 Discovery to DTLS Setup (%): This transition occurs to establish a 845 secure DTLS session with the peer. 847 WTP: The WTP initiates this transition by invoking the DTLSStart 848 command (see Section 2.3.2.1), which starts the DTLS session 849 establishment with the chosen AC. The decision of which AC to 850 connect to is the result of the discovery phase, which is 851 described in Section 3.3. 853 AC: This is an invalid state transition for the AC. 855 DTLS Setup to Idle ($): This transition occurs when the DTLS 856 connection setup fails. 858 WTP: The WTP initiates this state transition when it receives a 859 DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), 860 and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount 861 counter have not reached the value of the 862 MaxFailedDTLSSessionRetry variable (see Section 4.8). This 863 error notification aborts the secure DTLS session 864 establishment. When this notification is received, the 865 FailedDTLSSessionCount counter is incremented. 867 AC: This is an invalid state transition for the AC. 869 DTLS Setup to Sulking (*): This transition occurs when repeated 870 attempts to setup the DTLS connection have failed. 872 WTP: The WTP enters this state when the FailedDTLSSessionCount or 873 the FailedDTLSAuthFailCount counter reaches the value of the 874 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 875 entering this state, the WTP MUST start the SilentInterval 876 timer. While in the Sulking state, all received CAPWAP and 877 DTLS protocol messages received MUST be ignored. 879 AC: This is an invalid state transition for the AC. 881 DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS 882 Session failed to be established. 884 WTP: This is an invalid state transition for the WTP. 886 AC: The AC's Listener initiates this state transition when it 887 receives a DTLSEstablishFail notification from DTLS (see 888 Section 2.3.2.2). This error notification aborts the secure 889 DTLS session establishment. When this notification is 890 received, the FailedDTLSSessionCount counter is incremented. 891 The Listener thread then invokes the DTLSListen command (see 892 Section 2.3.2.1). 894 DTLS Setup to Authorize (5): This transition occurs when an incoming 895 DTLS session is being established, and the DTLS stack needs 896 authorization to proceed with the session establishment. 898 WTP: This state transition occurs when the WTP receives the 899 DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon 900 entering this state, the WTP performs an authorization check 901 against the AC credentials. See Section 2.4.4 for more 902 information on AC authorization. 904 AC: This state transition is handled by the AC's Listener thread 905 when the DTLS module initiates the DTLSPeerAuthorize 906 notification (see Section 2.3.2.2). The Listener thread forks 907 an instance of the Service thread, along with a copy of the 908 state context. Once created, the Service thread performs an 909 authorization check against the WTP credentials. See 910 Section 2.4.4 for more information on WTP authorization. 912 Authorize to DTLS Setup (6): This transition is executed by the 913 Listener thread to enable it to listen for new incoming sessions. 915 WTP: This is an invalid state transition for the WTP. 917 AC: This state transition occurs when the AC's Listener thread 918 has created the WTP context and the Service thread. The 919 Listener thread then invokes the DTLSListen command (see 920 Section 2.3.2.1). 922 Authorize to DTLS Connect (a): This transition occurs to notify the 923 DTLS stack that the session should be established. 925 WTP: This state transition occurs when the WTP has successfully 926 authorized the AC's credentials (see Section 2.4.4). This is 927 done by invoking the DTLSAccept DTLS command (see 928 Section 2.3.2.1). 930 AC: This state transition occurs when the AC has successfully 931 authorized the WTP's credentials (see Section 2.4.4). This is 932 done by invoking the DTLSAccept DTLS command (see 933 Section 2.3.2.1). 935 Authorize to DTLS Teardown (b): This transition occurs to notify the 936 DTLS stack that the session should be aborted. 938 WTP: This state transition occurs when the WTP was unable to 939 authorize the AC, using the AC credentials. The WTP then 940 aborts the DTLS session by invoking the DTLSAbortSession 941 command (see Section 2.3.2.1). 943 AC: This state transition occurs when the AC was unable to 944 authorize the WTP, using the WTP credentials. The AC then 945 aborts the DTLS session by invoking the DTLSAbortSession 946 command (see Section 2.3.2.1). 948 DTLS Connect to DTLS Teardown (c): This transition occurs when the 949 DTLS Session failed to be established. 951 WTP: This state transition occurs when the WTP receives either a 952 DTLSAborted or DTLSAuthenticateFail notification (see 953 Section 2.3.2.2), indicating that the DTLS session was not 954 successfully established. When this transition occurs due to 955 the DTLSAuthenticateFail notification, the 956 FailedDTLSAuthFailCount is incremented, otherwise the 957 FailedDTLSSessionCount counter is incremented. 959 AC: This state transition occurs when the AC receives either a 960 DTLSAborted or DTLSAuthenticateFail notification (see 961 Section 2.3.2.2), indicating that the DTLS session was not 962 successfully established, and both of the 963 FailedDTLSAuthFailCount and FailedDTLSSessionCount counters 964 have not reached the value of the MaxFailedDTLSSessionRetry 965 variable (see Section 4.8). 967 DTLS Connect to Join (d): This transition occurs when the DTLS 968 Session is successfully established. 970 WTP: This state transition occurs when the WTP receives the 971 DTLSEstablished notification (see Section 2.3.2.2), indicating 972 that the DTLS session was successfully established. When this 973 notification is received, the FailedDTLSSessionCount counter is 974 set to zero. 976 AC: This state transition occurs when the AC receives the 977 DTLSEstablished notification (see Section 2.3.2.2), indicating 978 that the DTLS session was successfully established. When this 979 notification is received, the FailedDTLSSessionCount counter is 980 set to zero, and the WaitJoin timer is started (see 981 Section 4.7). 983 Join to DTLS Teardown (e): This transition occurs when the join 984 process failed. 986 WTP: This state transition occurs when the WTP receives a Join 987 Response message with a Result Code message element containing 988 an error, if the Image Identifier provided by the AC in the 989 Join Response message differs from the WTP's currently running 990 firmware version and the WTP has the requested image in its 991 non-volatile memory, or if the WaitDTLS timer expires. This 992 causes the WTP to initiate the DTLSShutdown command (see 993 Section 2.3.2.1). This transition also occurs if the WTP 994 receives one of the following DTLS notifications: DTLSAborted, 995 DTLSReassemblyFailure or DTLSPeerDisconnect. 997 AC: This state transition occurs either if the WaitJoin timer 998 expires or if the AC transmits a Join Response message with a 999 Result Code message element containing an error. This causes 1000 the AC to initiate the DTLSShutdown command (see 1001 Section 2.3.2.1). This transition also occurs if the AC 1002 receives one of the following DTLS notifications: DTLSAborted, 1003 DTLSReassemblyFailure or DTLSPeerDisconnect. 1005 Join to Image Data (f): This state transition is used by the WTP and 1006 the AC to download executable firmware. 1008 WTP: The WTP enters the Image Data state when it receives a 1009 successful Join Response message and determines and the 1010 included Image Identifier message element is not the same as 1011 its currently running image. The WTP also detects that the 1012 requested image version is not currently available in the WTP's 1013 non-volatile storage (see Section 9.1 for a full description of 1014 the firmware download process). The WTP initializes the 1015 EchoInterval timer (see Section 4.7), and transmits the Image 1016 Data Request message (see Section 9.1.1) requesting the start 1017 of the firmware download. 1019 AC: This state transition occurs when the AC receives the Image 1020 Data Request message from the WTP. The AC MUST transmit an 1021 Image Data Response message (see Section 9.1.2) to the WTP, 1022 which includes a portion of the firmware. The AC MUST start 1023 the ImageDataStartTimer timer (see Section 4.7). 1025 Join to Configure (g): This state transition is used by the WTP and 1026 the AC to exchange configuration information. 1028 WTP: The WTP enters the Configure state when it receives a 1029 successful Join Response message, and determines that the 1030 included Image Identifier message element is the same as its 1031 currently running image. The WTP transmits the Configuration 1032 Status message (see Section 8.2) to the AC with message 1033 elements describing its current configuration. The WTP also 1034 starts the ResponseTimeout timer (see Section 4.7). 1036 AC: This state transition occurs immediately after the AC 1037 transmits the Join Response message to the WTP. If the AC 1038 receives the Configuration Status message from the WTP, the AC 1039 MUST transmit a Configuration Status Response message (see 1040 Section 8.3) to the WTP, and MAY include specific message 1041 elements to override the WTP's configuration. The AC also 1042 starts the ChangeStatePendingTimer timer (see Section 4.7). 1044 Configure to Reset (h): This state transition is used to reset the 1045 connection either due to an error during the configuration phase, 1046 or when the WTP determines it needs to reset in order for the new 1047 configuration to take effect. 1049 WTP: The WTP enters the Reset state when it receives a 1050 Configuration Status Response message indicating an error or 1051 when it determines that a reset of the WTP is required, due to 1052 the characteristics of a new configuration. 1054 AC: The AC transitions to the Reset state when it receives a 1055 Change State Event message from the WTP that contains an error 1056 for which AC policy does not permit the WTP to provide service. 1057 This state transition also occurs when the AC 1058 ChangeStatePendingTimer timer expires. 1060 Configure to DTLS Teardown (i): This transition occurs when the 1061 configuration process aborts due to a DTLS error. 1063 WTP: The WTP enters this state when it receives one of the 1064 following DTLS notifications: DTLSAborted, 1065 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1066 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1067 receives frequent DTLSDecapFailure notifications. 1069 AC: The AC enters this state when it receives one of the 1070 following DTLS notifications: DTLSAborted, 1071 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1072 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1073 receives frequent DTLSDecapFailure notifications. 1075 Image Data to Image Data (j): The Image Data state is used by the 1076 WTP and the AC during the firmware download phase. 1078 WTP: The WTP enters the Image Data state when it receives an 1079 Image Data Response message indicating that the AC has more 1080 data to send. 1082 AC: This state transition occurs when the AC receives the Image 1083 Data Request message from the WTP while already in the Image 1084 Data state. The AC resets the ImageDataStartTimer timer. 1086 Image Data to Reset (k): This state transition is used to reset the 1087 DTLS connection prior to restarting the WTP after an image 1088 download. 1090 WTP: When an image download completes, the WTP enters the Reset 1091 state. The WTP MAY also transition to this state upon 1092 receiving an Image Data Response message from the AC (see 1093 Section 9.1.2) indicating a failure. 1095 AC: The AC enters the Reset state when an error occurs during the 1096 image download process or if the ImageDataStartTimer timer 1097 expires. 1099 Image Data to DTLS Teardown (l): This transition occurs when the 1100 firmware download process aborts due to a DTLS error. 1102 WTP: The WTP enters this state when it receives one of the 1103 following DTLS notifications: DTLSAborted, 1104 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1105 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1106 receives frequent DTLSDecapFailure notifications. 1108 AC: The AC enters this state when it receives one of the 1109 following DTLS notifications: DTLSAborted, 1110 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1111 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1112 receives frequent DTLSDecapFailure notifications. 1114 Configure to Data Check (m): This state transition occurs when the 1115 WTP and AC confirm the configuration. 1117 WTP: The WTP enters this state when it receives a successful 1118 Configuration Status Response message from the AC. The WTP 1119 initializes the EchoInterval timer (see Section 4.7), and 1120 transmits the Change State Event Request message (see 1121 Section 8.6). 1123 AC: This state transition occurs when the AC receives the Change 1124 State Event Request message (see Section 8.6) from the WTP. 1125 The AC responds with a Change State Event Response message (see 1126 Section 8.7). The AC MUST start the DataCheckTimer timer (see 1127 Section 4.7). 1129 Data Check to DTLS Teardown (n): This transition occurs when the WTP 1130 does not complete the Data Check exchange. 1132 WTP: This state transition occurs if the WTP does not receive the 1133 Change State Event Response message before a CAPWAP 1134 transmission timeout occurs. 1136 AC: The AC enters this state when the DataCheckTimer timer 1137 expires (see Section 4.7). 1139 Data Check to Run (o): This state transition occurs when the linkage 1140 between the control and data channels is established, causing the 1141 WTP and AC to enter their normal state of operation. 1143 WTP: The WTP enters this state when it receives a successful 1144 Change State Event Response message from the AC. The WTP 1145 initiates the data channel, which MAY require the establishment 1146 of a DTLS session, starts the DataChannelKeepAlive timer (see 1147 Section 4.7) and transmits a Data Channel Keep Alive packet 1148 (see Section 4.4.1). The WTP then starts the 1149 DataChannelDeadInterval timer (see Section 4.7). 1151 AC: This state transition occurs when the AC receives the Data 1152 Channel Keep Alive packet (see Section 4.4.1), with a Session 1153 ID message element matching that included by the WTP in the 1154 Join Request message. The AC disables the DataCheckTimer 1155 timer. Note that if AC policy is to require the data channel 1156 to be encrypted, this process would also require the 1157 establishment of a data channel DTLS session. Upon receiving 1158 the Data Channel Keep Alive packet, the AC transmits its own 1159 Data Channel Keep Alive packet. 1161 Run to DTLS Teardown (p): This state transition occurs when an error 1162 has occurred in the DTLS stack, causing the DTLS session to be 1163 torn down. 1165 WTP: The WTP enters this state when it receives one of the 1166 following DTLS notifications: DTLSAborted, 1167 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1168 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1169 receives frequent DTLSDecapFailure notifications. The WTP also 1170 transitions to this state if the underlying reliable 1171 transport's RetransmitCount counter has reached the 1172 MaxRetransmit variable (see Section 4.7). 1174 AC: The AC enters this state when it receives one of the 1175 following DTLS notifications: DTLSAborted, 1176 DTLSReassemblyFailure or DTLSPeerDisconnect (see 1177 Section 2.3.2.2). The WTP MAY tear down the DTLS session if it 1178 receives frequent DTLSDecapFailure notifications. The AC 1179 transitions to this state if the underlying reliable 1180 transport's RetransmitCount counter has reached the 1181 MaxRetransmit variable (see Section 4.7). 1183 Run to Run (q): This is the normal state of operation. 1185 WTP: This is the WTP's normal state of operation. There are many 1186 events that result this state transition: 1188 Configuration Update: The WTP receives a Configuration Update 1189 Request message(see Section 8.4). The WTP MUST respond with 1190 a Configuration Update Response message (see Section 8.5). 1192 Change State Event: The WTP receives a Change State Event 1193 Response message, or determines that it must initiate a 1194 Change State Event Request message, as a result of a failure 1195 or change in the state of a radio. 1197 Echo Request: The WTP sends an Echo Request message 1198 (Section 7.1) or receives the corresponding Echo Response 1199 message, (see Section 7.2) from the AC. 1201 Clear Config Request: The WTP receives a Clear Configuration 1202 Request message (see Section 8.8). The WTP MUST reset its 1203 configuration back to manufacturer defaults. 1205 WTP Event: The WTP sends a WTP Event Request message, 1206 delivering information to the AC (see Section 9.4). The WTP 1207 receives a WTP Event Response message from the AC (see 1208 Section 9.5). 1210 Data Transfer: The WTP sends a Data Transfer Request message 1211 to the AC (see Section 9.6). The WTP receives a Data 1212 Transfer Response message from the AC (see Section 9.7). 1214 Station Configuration Request: The WTP receives a Station 1215 Configuration Request message (see Section 10.1), to which 1216 it MUST respond with a Station Configuration Response 1217 message (see Section 10.2). 1219 AC: This is the AC's normal state of operation: 1221 Configuration Update: The AC sends a Configuration Update 1222 Request message (see Section 8.4) to the WTP to update its 1223 configuration. The AC receives a Configuration Update 1224 Response message (see Section 8.5) from the WTP. 1226 Change State Event: The AC receives a Change State Event 1227 Request message (see Section 8.6), to which it MUST respond 1228 with the Change State Event Response message (see 1229 Section 8.7). 1231 Echo Request: The AC receives an Echo Request message (see 1232 Section 7.1), to which it MUST respond with an Echo Response 1233 message(see Section 7.2). 1235 Clear Config Response: The AC receives a Clear Configuration 1236 Response message from the WTP (see Section 8.9). 1238 WTP Event: The AC receives a WTP Event Request message from 1239 the WTP (see Section 9.4) and MUST generate a corresponding 1240 WTP Event Response message (see Section 9.5). 1242 Data Transfer: The AC receives a Data Transfer Request message 1243 from the WTP (see Section 9.6) and MUST generate a 1244 corresponding Data Transfer Response message (see 1245 Section 9.7). 1247 Station Configuration Request: The AC sends a Station 1248 Configuration Request message (see Section 10.1) or receives 1249 the corresponding Station Configuration Response message 1250 (see Section 10.2) from the WTP. 1252 Run to Reset (r): This state transition is used when either the AC 1253 or WTP tear down the connection. This may occur as part of normal 1254 operation, or due to error conditions. 1256 WTP: The WTP enters the Reset state when it receives a Reset 1257 Request message from the AC. 1259 AC: The AC enters the Reset state when it transmits a Reset 1260 Request message to the WTP. 1262 Reset to DTLS Teardown (s): This transition occurs when the CAPWAP 1263 reset is complete, to terminate the DTLS session. 1265 WTP: This state transition occurs when the WTP receives a Reset 1266 Response message. This causes the WTP to initiate the 1267 DTLSShutdown command (see Section 2.3.2.1). 1269 AC: This state transition occurs when the AC transmits a Reset 1270 Response message. The AC does not invoke the DTLSShutdown 1271 command (see Section 2.3.2.1). 1273 DTLS Teardown to Idle (t): This transition occurs when the DTLS 1274 session has been shutdown. 1276 WTP: This state transition occurs when the WTP has successfully 1277 cleaned up all resources associated with the control plane DTLS 1278 session. The data plane DTLS session is also shutdown, and all 1279 resources released, if a DTLS session was established for the 1280 data plane. Any timers set for the current instance of the 1281 state machine are also cleared. 1283 AC: This is an invalid state transition for the AC. 1285 DTLS Teardown to Sulking (u): This transition occurs when repeated 1286 attempts to setup the DTLS connection have failed. 1288 WTP: The WTP enters this state when the FailedDTLSSessionCount or 1289 the FailedDTLSAuthFailCount counter reaches the value of the 1290 MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon 1291 entering this state, the WTP MUST start the SilentInterval 1292 timer. While in the Sulking state, all received CAPWAP and 1293 DTLS protocol messages received MUST be ignored. 1295 AC: This is an invalid state transition for the AC. 1297 DTLS Teardown to Dead (w): This transition occurs when the DTLS 1298 session has been shutdown. 1300 WTP: This is an invalid state transition for the WTP. 1302 AC: This state transition occurs when the AC has successfully 1303 cleaned up all resources associated with the control plane DTLS 1304 session. The data plane DTLS session is also shutdown, and all 1305 resources released, if a DTLS session was established for the 1306 data plane. Any timers set for the current instance of the 1307 state machine are also cleared. The AC's Service thread is 1308 terminated. 1310 2.3.2. CAPWAP/DTLS Interface 1312 This section describes the DTLS Commands used by CAPWAP, and the 1313 notifications received from DTLS to the CAPWAP protocol stack. 1315 2.3.2.1. CAPWAP to DTLS Commands 1317 Six commands are defined for the CAPWAP to DTLS API. These 1318 "commands" are conceptual, and may be implemented as one or more 1319 function calls. This API definition is provided to clarify 1320 interactions between the DTLS and CAPWAP components of the integrated 1321 CAPWAP state machine. 1323 Below is a list of the minimal command API: 1325 o DTLSStart is sent to the DTLS component to cause a DTLS session to 1326 be established. Upon invoking the DTLSStart command, the WaitDTLS 1327 timer is started. The WTP initiates this DTLS command, as the AC 1328 does not initiate DTLS sessions. 1330 o DTLSListen is sent to the DTLS component to allow the DTLS 1331 component to listen for incoming DTLS session requests. 1333 o DTLSAccept is sent to the DTLS component to allow the DTLS session 1334 establishment to continue successfully. 1336 o DTLSAbortSession is sent to the DTLS component to cause the 1337 session that is in the process of being established to be aborted. 1338 This command is also sent when the WaitDTLS timer expires. When 1339 this command is executed, the FailedDTLSSessionCount counter is 1340 incremented. 1342 o DTLSShutdown is sent to the DTLS component to cause session 1343 teardown. 1345 o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU 1346 size used by the DTLS component. See Section 3.5 for more 1347 information on MTU Discovery. The default size is 1468 bytes. 1349 2.3.2.2. DTLS to CAPWAP Notifications 1351 DTLS notifications are defined for the DTLS to CAPWAP API. These 1352 "notifications" are conceptual, and may be implemented in numerous 1353 ways (e.g. as function return values). This API definition is 1354 provided to clarify interactions between the DTLS and CAPWAP 1355 components of the integrated CAPWAP state machine. It is important 1356 to note that the notifications listed below MAY cause the CAPWAP 1357 state machine to jump from one state to another using a state 1358 transition not listed in Section 2.3.1. When a notification listed 1359 below occurs, the target CAPWAP state shown in Figure 3 becomes the 1360 current state. 1362 Below is a list of the API notifications: 1364 o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS 1365 session establishment once the peer's identity has been received. 1366 This notification MAY be used by the CAPWAP component to authorize 1367 the session, based on the peer's identity. The authorization 1368 process will lead to the CAPWAP component initiating either the 1369 DTLSAccept or DTLSAbortSession commands. 1371 o DTLSEstablished is sent to the CAPWAP component to indicate that 1372 that a secure channel now exists, using the parameters provided 1373 during the DTLS initialization process. When this notification is 1374 received, the FailedDTLSSessionCount counter is reset to zero. 1375 When this notification is received, the WaitDTLS timer is stopped. 1377 o DTLSEstablishFail is sent when the DTLS session establishment has 1378 failed, either due to a local error, or due to the peer rejecting 1379 the session establishment. When this notification is received, 1380 the FailedDTLSSessionCount counter is incremented. 1382 o DTLSAuthenticateFail is sent when DTLS session establishment 1383 failed due to an authentication error. When this notification is 1384 received, the FailedDTLSAuthFailCount counter is incremented. 1386 o DTLSAborted is sent to the CAPWAP component to indicate that 1387 session abort (as requested by CAPWAP) is complete; this occurs to 1388 confirm a DTLS session abort, or when the WaitDTLS timer expires. 1389 When this notification is received, the WaitDTLS timer is stopped. 1391 o DTLSReassemblyFailure MAY be sent to the CAPWAP component to 1392 indicate DTLS fragment reassembly failure. 1394 o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a 1395 decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP 1396 module to indicate an encryption/authentication failure. This 1397 notification is intended for informative purposes only, and is not 1398 intended to cause a change in the CAPWAP state machine (see 1399 Section 12.4). 1401 o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the 1402 DTLS session has been torn down. Note that this notification is 1403 only received if the DTLS session has been established. 1405 2.4. Use of DTLS in the CAPWAP Protocol 1407 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1408 protocol. In this document DTLS and CAPWAP are discussed as 1409 nominally distinct entities; however they are very closely coupled, 1410 and may even be implemented inseparably. Since there are DTLS 1411 library implementations currently available, and since security 1412 protocols (e.g. IPsec, TLS) are often implemented in widely 1413 available acceleration hardware, it is both convenient and forward- 1414 looking to maintain a modular distinction in this document. 1416 This section describes a detailed walk-through of the interactions 1417 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1418 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1419 encountered during the normal course of operation. 1421 2.4.1. DTLS Handshake Processing 1423 Details of the DTLS handshake process are specified in [RFC4347]. 1424 This section describes the interactions between the DTLS session 1425 establishment process and the CAPWAP protocol. Note that the 1426 conceptual DTLS state is shown below to help understand the point at 1427 which the DTLS states transition. In the normal case, the DTLS 1428 handshake will proceed as follows (NOTE: this example uses 1429 certificates, but preshared keys are also supported): 1431 ============ ============ 1432 WTP AC 1433 ============ ============ 1434 ClientHello ------> 1435 <------ HelloVerifyRequest 1436 (with cookie) 1438 ClientHello ------> 1439 (with cookie) 1440 <------ ServerHello 1441 <------ Certificate 1442 <------ ServerHelloDone 1444 (WTP callout for AC authorization 1445 occurs in CAPWAP Auth state) 1447 Certificate* 1448 ClientKeyExchange 1449 CertificateVerify* 1450 [ChangeCipherSpec] 1451 Finished ------> 1453 (AC callout for WTP authorization 1454 occurs in CAPWAP Auth state) 1456 [ChangeCipherSpec] 1457 <------ Finished 1459 DTLS, as specified, provides its own retransmit timers with an 1460 exponential back-off. However, DTLS will never terminate the 1461 handshake due to non-responsiveness; instead, DTLS will continue to 1462 increase its back-off timer period. Hence, timing out incomplete 1463 DTLS handshakes is entirely the responsibility of the CAPWAP module. 1465 The DTLS implementation used by CAPWAP MUST support TLS Session 1466 Resumption. Session resumption is used to establish the DTLS session 1467 used for the data channel. The DTLS implementation on the WTP MUST 1468 return some unique identifier to the CAPWAP module to enable 1469 subsequent establishment of a DTLS-encrypted data channel, if 1470 necessary. 1472 2.4.2. DTLS Session Establishment 1474 The WTP, either through the Discovery process, or through pre- 1475 configuration, determines the AC to connect to. The WTP uses the 1476 DTLSStart command to request that a secure connection be established 1477 to the selected AC. Prior to initiation of the DTLS handshake, the 1478 WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize 1479 DTLS notification, the AC sets the WaitDTLS timer. If the 1480 DTLSEstablished notification is not received prior to timer 1481 expiration, the DTLS session is aborted by issuing the 1482 DTLSAbortSession DTLS command. This notification causes the CAPWAP 1483 module to transition to the Idle state. Upon receiving a 1484 DTLSEstablished notification, the WaitDTLS timer is deactivated. 1486 2.4.3. DTLS Error Handling 1488 If the AC does not respond to any DTLS messages sent by the WTP, the 1489 DTLS specification calls for the WTP to retransmit these messages. 1490 If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession 1491 command, causing DTLS to terminate the handshake and remove any 1492 allocated session context. Note that DTLS MAY send a single TLS 1493 Alert message to the AC to indicate session termination. 1495 If the WTP does not respond to any DTLS messages sent by the AC, the 1496 CAPWAP protocol allows for three possibilities, listed below. Note 1497 that DTLS MAY send a single TLS Alert message to the AC to indicate 1498 session termination. 1500 o The message was lost in transit; in this case, the WTP will re- 1501 transmit its last outstanding message, since it did not receive a 1502 reply. 1504 o The WTP sent a DTLS Alert, which was lost in transit; in this 1505 case, the AC's WaitDTLS timer will expire, and the session will be 1506 terminated. 1508 o Communication with the WTP has completely failed; in this case, 1509 the AC's WaitDTLS timer will expire, and the session will be 1510 terminated. 1512 The DTLS specification provides for retransmission of unacknowledged 1513 requests. If retransmissions remain unacknowledged, the WaitDTLS 1514 timer will eventually expire, at which time the CAPWAP component will 1515 terminate the session. 1517 If a cookie fails to validate, this could represent a WTP error, or 1518 it could represent a DoS attack. Hence, AC resource utilization 1519 SHOULD be minimized. The AC MAY log a message indicating the 1520 failure, but SHOULD NOT attempt to reply to the WTP. 1522 Since DTLS handshake messages are potentially larger than the maximum 1523 record size, DTLS supports fragmenting of handshake messages across 1524 multiple records. There are several potential causes of re-assembly 1525 errors, including overlapping and/or lost fragments. The DTLS 1526 component MUST send a DTLSReassemblyFailure notification to the 1527 CAPWAP component. Whether precise information is given along with 1528 notification is an implementation issue, and hence is beyond the 1529 scope of this document. Upon receipt of such an error, the CAPWAP 1530 component SHOULD log an appropriate error message. Whether 1531 processing continues or the DTLS session is terminated is 1532 implementation dependent. 1534 DTLS decapsulation errors consist of three types: decryption errors, 1535 authentication errors, and malformed DTLS record headers. Since DTLS 1536 authenticates the data prior to encapsulation, if decryption fails, 1537 it is difficult to detect this without first attempting to 1538 authenticate the packet. If authentication fails, a decryption error 1539 is also likely, but not guaranteed. Rather than attempt to derive 1540 (and require the implementation of) algorithms for detecting 1541 decryption failures, decryption failures are reported as 1542 authentication failures. The DTLS component MUST provide a 1543 DTLSDecapFailure notification to the CAPWAP component when such 1544 errors occur. If a malformed DTLS record header is detected, the 1545 packets SHOULD be silently discarded, and the receiver MAY log an 1546 error message. 1548 There is currently only one encapsulation error defined: MTU 1549 exceeded. As part of DTLS session establishment, the CAPWAP 1550 component informs the DTLS component of the MTU size. This may be 1551 dynamically modified at any time when the CAPWAP component sends the 1552 DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). 1553 The value provided to the DTLS stack is the result of the MTU 1554 Discovery process, which is described in Section 3.5. The DTLS 1555 component returns this notification to the CAPWAP component whenever 1556 a transmission request will result in a packet which exceeds the MTU. 1558 2.4.4. DTLS EndPoint Authentication and Authorization 1560 DTLS supports endpoint authentication with certificates or preshared 1561 keys. The TLS algorithm suites for each endpoint authentication 1562 method are described below. 1564 2.4.4.1. Authenticating with Certificates 1566 Note that only block ciphers are currently recommended for use with 1567 DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]. 1568 At present, the following algorithms MUST be supported when using 1569 certificates for CAPWAP authentication: 1571 o TLS_RSA_WITH_AES_128_CBC_SHA 1573 The following algorithms SHOULD be supported when using certificates: 1575 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1577 The following algorithms MAY be supported when using certificates: 1579 o TLS_RSA_WITH_AES_256_CBC_SHA 1581 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1583 2.4.4.2. Authenticating with Preshared Keys 1585 Pre-shared keys present significant challenges from a security 1586 perspective, and for that reason, their use is strongly discouraged. 1587 Several methods for authenticating with preshared keys are defined 1588 [RFC4279], and we focus on the following two: 1590 o PSK key exchange algorithm - simplest method, ciphersuites use 1591 only symmetric key algorithms 1593 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1594 Diffie-Hellman exchange. These ciphersuites give some additional 1595 protection against dictionary attacks and also provide Perfect 1596 Forward Secrecy (PFS). 1598 The first approach (plain PSK) is susceptible to passive dictionary 1599 attacks; hence, while this algorithm MUST be supported, special care 1600 should be taken when choosing that method. In particular, user- 1601 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1602 be strongly discouraged. 1604 The following cryptographic algorithms MUST be supported when using 1605 preshared keys: 1607 o TLS_PSK_WITH_AES_128_CBC_SHA 1609 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1611 The following algorithms MAY be supported when using preshared keys: 1613 o TLS_PSK_WITH_AES_256_CBC_SHA 1615 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1617 2.4.4.3. Certificate Usage 1619 Certificate authorization by the AC and WTP is required so that only 1620 an AC may perform the functions of an AC and that only a WTP may 1621 perform the functions of a WTP. This restriction of functions to the 1622 AC or WTP requires that the certificates used by the AC MUST be 1623 distinguishable from the certificate used by the WTP. To accomplish 1624 this differentiation, the x.509 certificates MUST include the 1625 Extended Key Usage (EKU) certificate extension [RFC3280]. 1627 The EKU field indicates one or more purposes for which a certificate 1628 may be used. It is an essential part in authorization. Its syntax 1629 is as follows: 1631 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1633 KeyPurposeId ::= OBJECT IDENTIFIER 1635 Here we define two KeyPurposeId values, one for the WTP and one for 1636 the AC. Inclusion of one of these two values indicates a certificate 1637 is authorized for use by a WTP or AC, respectively. These values are 1638 formatted as id-kp fields. 1640 id-kp OBJECT IDENTIFIER ::= 1641 { iso(1) identified-organization(3) dod(6) internet(1) 1642 security(5) mechanisms(5) pkix(7) 3 } 1644 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1646 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1648 All capwap devices MUST support the ExtendedKeyUsage certificate 1649 extension if it is present in a certificate. If the extension is 1650 present, then the certificate MUST have either the id-kp-capwapAC or 1651 the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. 1652 Similarly, if the extension is present, a device must have the id-kp- 1653 capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. 1655 Part of the CAPWAP certificate validation process includes ensuring 1656 that the proper EKU is included and allowing the CAPWAP session to be 1657 established only if the extension properly represents the device. 1658 For instance, an AC SHOULD NOT accept a connection request from 1659 another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is 1660 present in the certificate. 1662 CAPWAP implementations MUST support certificates where the common 1663 name (CN) for both the WTP and AC is the MAC address of that device. 1664 The MAC address MUST be formatted as ASCII HEX, e.g. 1665 01:23:45:67:89:ab. Note that the CN field MAY contain either of the 1666 EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. 1668 ACs and WTPs MUST authorize (e.g. through access control lists) 1669 certificates of devices to which they are connecting, e.g., based on 1670 the issuer, MAC address, or organizational information specified in 1671 the certificate. The identities specified in the certificates bind a 1672 particular DTLS session to a specific pair of mutually-authenticated 1673 and authorized MAC addresses. The particulars of authorization 1674 filter construction are implementation details which are, for the 1675 most part, not within the scope of this specification. However, at 1676 minimum, all devices MUST verify that the appropriate EKU bit is set 1677 according to the role of the peer device (AC vs. WTP), and that the 1678 issuer of the certificate is appropriate for the domain in question. 1680 2.4.4.4. PSK Usage 1682 When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST 1683 contain the "PSK identity hint" field and the ClientKeyExchange 1684 message MUST contain the "PSK identity" field. These fields are used 1685 to help the WTP select the appropriate PSK for use with the AC, and 1686 then indicate to the AC which key is being used. When PSKs are 1687 provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for 1688 the key MUST be specified. 1690 The PSK Hint SHOULD uniquely identify the AC and the PSK Identity 1691 SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints 1692 and identities be the ASCII HEX-formatted MAC addresses of the 1693 respective devices, since each pairwise combination of WTP and AC 1694 SHOULD have a unique PSK. The PSK hint and identity SHOULD be 1695 sufficient to perform authorization, as simply having knowledge of a 1696 PSK does not necessarily imply authorization. 1698 If a single PSK is being used for multiple devices on a CAPWAP 1699 network, which is NOT RECOMMENDED, the PSK Hint and Identity can no 1700 longer be a MAC address, so appropriate hints and identities SHOULD 1701 be selected to identify the group of devices to which the PSK is 1702 provisioned. 1704 3. CAPWAP Transport 1706 Communication between a WTP and an AC is established using the 1707 standard UDP client/server model. The CAPWAP protocol supports both 1708 UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, 1709 UDP is used for the CAPWAP control and data channels. 1711 When run over IPv6, the CAPWAP control channel always uses UDP, while 1712 the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is 1713 the default transport protocol for the CAPWAP data channel. However, 1714 if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is 1715 used for the CAPWAP data channel. 1717 This section describes how the CAPWAP protocol is carried over IP and 1718 UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol 1719 message element Section 4.6.15 describes the rules to use in 1720 determining which transport protocol is to be used. 1722 3.1. UDP Transport 1724 One of the CAPWAP protocol requirements is to allow a WTP to reside 1725 behind a middlebox, firewall and/or Network Address Translation (NAT) 1726 device. Since a CAPWAP session is initiated by the WTP (client) to 1727 the well-known UDP port of the AC (server), the use of UDP is a 1728 logical choice. The UDP checksum field in CAPWAP packets MUST be set 1729 to zero. 1731 CAPWAP protocol control packets sent from the WTP to the AC use the 1732 CAPWAP control channel, as defined in Section 1.4. The CAPWAP 1733 control port at the AC is the well known UDP port [to be IANA 1734 assigned]. The CAPWAP control port at the WTP can be any port 1735 selected by the WTP. 1737 CAPWAP protocol data packets sent from the WTP to the AC use the 1738 CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port 1739 at the AC is the well known UDP port [to be IANA assigned]. The 1740 CAPWAP data port at the WTP can be any port selected by the WTP. 1742 3.2. UDP-Lite Transport 1744 When CAPWAP is run over IPv6, UDP-Lite is the default transport 1745 protocol, which reduces the checksum processing required for each 1746 packet (compared to the use of UDP over IPv6 [RFC1883]). When UDP- 1747 Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. 1749 UDP-Lite uses the same port assignments as UDP. 1751 3.3. AC Discovery 1753 The AC discovery phase allows the WTP to determine which ACs are 1754 available, and chose the best AC with which to establish a CAPWAP 1755 session. The discovery phase occurs when the WTP enters the optional 1756 Discovery state. A WTP does not need to complete the AC Discovery 1757 phase if it uses a pre-configured AC. This section details the 1758 mechanism used by a WTP to dynamically discover candidate ACs. 1760 A WTP and an AC will frequently not reside in the same IP subnet 1761 (broadcast domain). When this occurs, the WTP must be capable of 1762 discovering the AC, without requiring that multicast services are 1763 enabled in the network. 1765 When the WTP attempts to establish communication with an AC, it sends 1766 the Discovery Request message and receives the Discovery Response 1767 message from the AC(s). The WTP MUST send the Discovery Request 1768 message to either the limited broadcast IP address (255.255.255.255), 1769 a well known multicast address or to the unicast IP address of the 1770 AC. For IPv6 networks, since broadcast does not exist, the use of 1771 "All ACs multicast address" is used instead. Upon receipt of the 1772 Discovery Request message, the AC sends a Discovery Response message 1773 to the unicast IP address of the WTP, regardless of whether the 1774 Discovery Request message was sent as a broadcast, multicast or 1775 unicast message. 1777 WTP use of a limited IP broadcast, multicast or unicast IP address is 1778 implementation dependent. 1780 When a WTP transmits a Discovery Request message to a unicast 1781 address, the WTP must first obtain the IP address of the AC. Any 1782 static configuration of an AC's IP address on the WTP non-volatile 1783 storage is implementation dependent. However, additional dynamic 1784 schemes are possible, for example: 1786 DHCP: See [I-D.calhoun-dhc-capwap-ac-option] for more information on 1787 the use of DHCP to discover AC IP addresses. 1789 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1790 more AC addresses. 1792 An AC MAY also communicate alternative ACs to the WTP within the 1793 Discovery Response message through the AC IPv4 List (see 1794 Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses 1795 provided in these two message elements are intended to help the WTP 1796 discover additional ACs through means other than those listed above. 1798 The AC Name with Index message element (see Section 4.6.5), is used 1799 to communicate a list of preferred ACs to the WTP. The WTP SHOULD 1800 attempt to utilize the ACs listed in the order provided by the AC. 1801 The Name to IP Address mapping is handled via the Discovery message 1802 exchange, in which the ACs provide their identity in the AC Name (see 1803 Section 4.6.4) message element in the Discovery Response message. 1805 Once the WTP has received Discovery Response messages from the 1806 candidate ACs, it MAY use other factors to determine the preferred 1807 AC. For instance, each binding defines a WTP Radio Information 1808 message element (see Section 2.1), which the AC includes in Discovery 1809 Response messages. The presence of one or more of these message 1810 elements is used to identify the CAPWAP bindings supported by the AC. 1811 A WTP MAY connect to an AC based on the supported bindings 1812 advertised. 1814 3.4. Fragmentation/Reassembly 1816 While fragmentation and reassembly services are provided by IP, the 1817 CAPWAP protocol also provides such services. Environments where the 1818 CAPWAP protocol is used involve firewall, NAT and "middle box" 1819 devices, which tend to drop IP fragments to minimize possible DoS 1820 attacks. By providing fragmentation and reassembly at the 1821 application layer, any fragmentation required due to the tunneling 1822 component of the CAPWAP protocol becomes transparent to these 1823 intermediate devices. Consequently, the CAPWAP protocol can be used 1824 in any network configuration. 1826 3.5. MTU Discovery 1828 Once a WTP has discovered the AC it wishes to establish a CAPWAP 1829 session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU 1830 discovered is used to configure the DTLS component (see 1831 Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit 1832 the MTU, defined in Section 3.4. The procedures described in 1833 [RFC1191], for IPv4, or [RFC1981], for IPv6 SHOULD be used. 1834 Alternatively, implementers MAY use the procedures defined in 1835 [RFC4821]. The WTP SHOULD also periodically re-evaluate the MTU 1836 using the guidelines provided in these two RFCs. 1838 4. CAPWAP Packet Formats 1840 This section contains the CAPWAP protocol packet formats. A CAPWAP 1841 protocol packet consists of one or more CAPWAP Transport Layer packet 1842 headers followed by a CAPWAP message. The CAPWAP message can be 1843 either of type Control or Data, where Control packets carry 1844 signaling, and Data packets carry user payloads. The CAPWAP frame 1845 formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP 1846 Data and Control packets are defined below. 1848 The CAPWAP Control protocol includes two messages that are never 1849 protected by DTLS: the Discovery Request message and the Discovery 1850 Response message. These messages need to be in the clear to allow 1851 the CAPWAP protocol to properly identify and process them. The 1852 format of these packets are as follows: 1854 CAPWAP Control Packet (Discovery Request/Response): 1855 +-------------------------------------------+ 1856 | IP | UDP | CAPWAP | Control | Message | 1857 | Hdr | Hdr | Header | Header | Element(s) | 1858 +-------------------------------------------+ 1860 All other CAPWAP control protocol messages MUST be protected via the 1861 DTLS protocol, which ensures that the packets are both authenticated 1862 and encrypted. These packets include the CAPWAP DTLS Header, which 1863 is described in Section 4.2. The format of these packets is as 1864 follows: 1866 CAPWAP Control Packet (DTLS Security Required): 1867 +------------------------------------------------------------------+ 1868 | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | 1869 | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | 1870 +------------------------------------------------------------------+ 1871 \---------- authenticated -----------/ 1872 \------------- encrypted ------------/ 1874 The CAPWAP protocol allows optional protection of data packets, using 1875 DTLS. Use of data packet protection is determined by AC policy. 1876 When DTLS is utilized, the optional CAPWAP DTLS Header is present, 1877 which is described in Section 4.2. The format of CAPWAP data packets 1878 is shown below: 1880 CAPWAP Plain Text Data Packet : 1881 +-------------------------------+ 1882 | IP | UDP | CAPWAP | Wireless | 1883 | Hdr | Hdr | Header | Payload | 1884 +-------------------------------+ 1886 DTLS Secured CAPWAP Data Packet: 1887 +--------------------------------------------------------+ 1888 | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | 1889 | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | 1890 +--------------------------------------------------------+ 1891 \------ authenticated -----/ 1892 \------- encrypted --------/ 1894 UDP Header: All CAPWAP packets are encapsulated within either UDP, 1895 or UDP-Lite when used over IPv6. Section 3 defines the specific 1896 UDP or UDP-Lite usage. 1898 CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are 1899 prefixed with the CAPWAP DTLS header (see Section 4.2). 1901 DTLS Header: The DTLS header provides authentication and encryption 1902 services to the CAPWAP payload it encapsulates. This protocol is 1903 defined in RFC 4347 [RFC4347]. 1905 CAPWAP Header: All CAPWAP protocol packets use a common header that 1906 immediately follows the CAPWAP preamble or DTLS header. The 1907 CAPWAP Header is defined in Section 4.3. 1909 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1910 payload is a CAPWAP data packet. The CAPWAP protocol does not 1911 specify the format of the wireless payload, which is defined by 1912 the appropriate wireless standard. Additional information is in 1913 Section 4.4. 1915 Control Header: The CAPWAP protocol includes a signaling component, 1916 known as the CAPWAP control protocol. All CAPWAP control packets 1917 include a Control Header, which is defined in Section 4.5.1. 1918 CAPWAP data packets do not contain a Control Header field. 1920 Message Elements: A CAPWAP Control packet includes one or more 1921 message elements, which are found immediately following the 1922 Control Header. These message elements are in a Type/Length/value 1923 style header, defined in Section 4.6. 1925 A CAPWAP implementation MUST be capable of receiving a reassembled 1926 CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY 1927 indicate that it supports a higher maximum message length, by 1928 including the Maximum Message Length message element, see 1929 Section 4.6.32 in the Join Request message or the Join Response 1930 message. 1932 4.1. CAPWAP Preamble 1934 The CAPWAP preamble is common to all CAPWAP transport headers and is 1935 used to identify the header type that immediately follows. The 1936 reason for this header is to avoid needing to perform byte 1937 comparisons in order to guess whether the frame is DTLS encrypted or 1938 not. It also provides an extensibility framework that can be used to 1939 support additional transport types. The format of the preamble is as 1940 follows: 1942 0 1943 0 1 2 3 4 5 6 7 1944 +-+-+-+-+-+-+-+-+ 1945 |Version| Type | 1946 +-+-+-+-+-+-+-+-+ 1948 Version: A 4 bit field which contains the version of CAPWAP used in 1949 this packet. The value for this specification is zero (0). 1951 Payload Type: A 4 bit field which specifies the payload type that 1952 follows the UDP header. The following values are supported: 1954 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) 1955 immediately follows the UDP header. If the packet is received 1956 on the CAPWAP data channel, the CAPWAP stack MUST treat the 1957 packet as a clear text CAPWAP data packet. If received on the 1958 CAPWAP control channel, the CAPWAP stack MUST treat the packet 1959 as a clear text CAPWAP control packet. If the control packet 1960 is not a Discovery Request or Discovery Response packet, the 1961 packet MUST be dropped. 1963 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, 1964 immediately follows the UDP header (see Section 4.2). 1966 4.2. CAPWAP DTLS Header 1968 The CAPWAP DTLS Header is used to identify the packet as a DTLS 1969 encrypted packet. The first eight bits includes the common CAPWAP 1970 Preamble. The remaining 24 bits are padding to ensure 4 byte 1971 alignment, and MAY be used in a future version of the protocol. The 1972 DTLS packet [RFC4347] always immediately follows this header. The 1973 format of the CAPWAP DTLS Header is as follows: 1975 0 1 2 3 1976 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 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 |CAPWAP Preamble| Reserved | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 1982 CAPWAP Preamble's Payload Type field MUST be set to one (1). 1984 Reserved: The 24-bit field is reserved for future use. All 1985 implementations complying with this protocol MUST set to zero any 1986 bits that are reserved in the version of the protocol supported by 1987 that implementation. Receivers MUST ignore all bits not defined 1988 for the version of the protocol they support. 1990 4.3. CAPWAP Header 1992 All CAPWAP protocol messages are encapsulated using a common header 1993 format, regardless of the CAPWAP Control or CAPWAP Data transport 1994 used to carry the messages. However, certain flags are not 1995 applicable for a given transport. Refer to the specific transport 1996 section in order to determine which flags are valid. 1998 Note that the optional fields defined in this section MUST be present 1999 in the precise order shown below. 2001 0 1 2 3 2002 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | Fragment ID | Frag Offset |Rsvd | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | (optional) Radio MAC Address | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | (optional) Wireless Specific Information | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Payload .... | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2015 CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The 2016 CAPWAP Preamble's Payload Type field MUST be set to zero (0). If 2017 the CAPWAP DTLS Header is present, the version number in both 2018 CAPWAP Preambles MUST match. The reason for this duplicate field 2019 is to avoid any possible tampering of the version field in the 2020 preamble which is not encrypted or authenticated. 2022 HLEN: A 5 bit field containing the length of the CAPWAP transport 2023 header in 4 byte words (Similar to IP header length). This length 2024 includes the optional headers. 2026 RID: A 5 bit field which contains the Radio ID number for this 2027 packet. Given that MAC Addresses are not necessarily unique 2028 across physical radios in a WTP, the Radio Identifier (RID) field 2029 is used to indicate which physical radio the message is associated 2030 with. 2032 WBID: A 5 bit field which is the wireless binding identifier. The 2033 identifier will indicate the type of wireless packet associated 2034 with the radio. The following values are defined: 2036 1 - IEEE 802.11 2038 2 - IEEE 802.16 2040 3 - EPCGlobal 2042 T: The Type 'T' bit indicates the format of the frame being 2043 transported in the payload. When this bit is set to one (1), the 2044 payload has the native frame format indicated by the WBID field. 2045 When this bit is zero (0) the payload is an IEEE 802.3 frame. 2047 F: The Fragment 'F' bit indicates whether this packet is a fragment. 2048 When this bit is one (1), the packet is a fragment and MUST be 2049 combined with the other corresponding fragments to reassemble the 2050 complete information exchanged between the WTP and AC. 2052 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 2053 whether the packet contains the last fragment of a fragmented 2054 exchange between WTP and AC. When this bit is 1, the packet is 2055 the last fragment. When this bit is 0, the packet is not the last 2056 fragment. 2058 W: The Wireless 'W' bit is used to specify whether the optional 2059 Wireless Specific Information field is present in the header. A 2060 value of one (1) is used to represent the fact that the optional 2061 header is present. 2063 M: The M bit is used to indicate that the Radio MAC Address optional 2064 header is present. This is used to communicate the MAC address of 2065 the receiving radio. 2067 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep 2068 Alive packet. This packet is used to map the data channel to the 2069 control channel for the specified Session ID and to maintain 2070 freshness of the data channel. The K bit MUST NOT be set for data 2071 packets containing user data. 2073 Flags: A set of reserved bits for future flags in the CAPWAP header. 2074 All implementations complying with this protocol MUST set to zero 2075 any bits that are reserved in the version of the protocol 2076 supported by that implementation. Receivers MUST ignore all bits 2077 not defined for the version of the protocol they support. 2079 Fragment ID: A 16 bit field whose value is assigned to each group of 2080 fragments making up a complete set. The fragment ID space is 2081 managed individually for every WTP/AC pair. The value of Fragment 2082 ID is incremented with each new set of fragments. The Fragment ID 2083 wraps to zero after the maximum value has been used to identify a 2084 set of fragments. 2086 Fragment Offset: A 13 bit field that indicates where in the payload 2087 this fragment belongs during re-assembly. This field is valid 2088 when the 'F' bit is set to 1. The fragment offset is measured in 2089 units of 8 octets (64 bits). The first fragment has offset zero. 2090 Note the CAPWAP protocol does not allow for overlapping fragments. 2092 Reserved: The 3-bit field is reserved for future use. All 2093 implementations complying with this protocol MUST set to zero any 2094 bits that are reserved in the version of the protocol supported by 2095 that implementation. Receivers MUST ignore all bits not defined 2096 for the version of the protocol they support. 2098 Radio MAC Address: This optional field contains the MAC address of 2099 the radio receiving the packet. This is useful in packets sent 2100 from the WTP to the AC, when the native wireless frame format is 2101 converted to 802.3 by the WTP. This field is only present if the 2102 'M' bit is set. The HLEN field assumes 4 byte alignment, and this 2103 field MUST be padded with zeroes (0x00) if it is not 4 byte 2104 aligned. 2106 The field contains the basic format: 2108 0 1 2 3 2109 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 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Length | MAC Address 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 Length: The length of the MAC Address field [EUI-48] [EUI-64]. 2116 MAC Address: The MAC Address of the receiving radio. 2118 Wireless Specific Information: This optional field contains 2119 technology specific information that may be used to carry per 2120 packet wireless information. This field is only present if the 2121 'W' bit is set. The WBID field in the CAPWAP header is used to 2122 identify the format of the wireless specific information optional 2123 field. The HLEN field assumes 4 byte alignment, and this field 2124 MUST be padded with zeroes (0x00) if it is not 4 byte aligned. 2126 The Wireless Specific Information field uses the following format: 2128 0 1 2 3 2129 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 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | Length | Data... 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 Length: The length of the data field 2136 Data: Wireless specific information, defined by the wireless 2137 specific binding specified in the CAPWAP Header's WBID field. 2139 Payload: This field contains the header for a CAPWAP Data Message or 2140 CAPWAP Control Message, followed by the data contained in the 2141 message. 2143 4.4. CAPWAP Data Messages 2145 There are two different types of CAPWAP data packets, CAPWAP Data 2146 Channel Keep Alive packets and Data Payload packets. The first is 2147 used by the WTP to synchronize the control and data channels, and to 2148 maintain freshness of the data channel. The second is used to 2149 transmit user payloads between the AC and WTP. This section 2150 describes both types of CAPWAP data packet formats. 2152 Both CAPWAP data messages are transmitted on the CAPWAP data channel. 2154 4.4.1. CAPWAP Data Keepalive 2156 The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP 2157 control channel with the data channel, and to maintain freshness of 2158 the data channel, ensuring that the channel is still functioning. 2159 The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP 2160 when the DataChannelKeepAlive timer expires. When the CAPWAP Data 2161 Channel Keep Alive packet is transmitted, the WTP sets the 2162 DataChannelDeadInterval timer. 2164 In the CAPWAP Data Channel Keep Alive packet, all of the fields in 2165 the CAPWAP header, except the HLEN field and the K bit, are set to 2166 zero upon transmission. Upon receiving a CAPWAP Data Channel Keep 2167 Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive 2168 packet back to the WTP. The contents of the transmitted packet are 2169 identical to the contents of the received packet. 2171 Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP 2172 cancels the DataChannelDeadInterval timer and resets the 2173 DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive 2174 packet is retransmitted by the WTP in the same manner as the CAPWAP 2175 control messages. If the DataChannelDeadInterval timer expires, the 2176 WTP tears down the control DTLS session, and the data DTLS session if 2177 one existed. 2179 The CAPWAP Data Channel Keep Alive packet contains the following 2180 payload immediately following the CAPWAP Header (see Section 4.3) 2182 0 1 2 3 2183 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 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | Message Element Length | Message Element [0..N] ... 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 Message Element Length: The Length field indicates the number of 2189 bytes following the CAPWAP Header. 2191 Message Element[0..N]: The message element(s) carry the information 2192 pertinent to each of the CAPWAP Data Keepalive message. The 2193 following message elements MUST be present in this CAPWAP message: 2195 Session ID, see Section 4.6.37 2197 4.4.2. Data Payload 2199 A CAPWAP protocol Data Payload packet encapsulates a forwarded 2200 wireless frame. The CAPWAP protocol defines two different modes of 2201 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 2202 encapsulation requires that for 802.11 frames, the 802.11 2203 *Integration* function be performed in the WTP. An IEEE 802.3 2204 encapsulated user payload frame has the following format: 2206 +------------------------------------------------------+ 2207 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 2208 +------------------------------------------------------+ 2210 The CAPWAP protocol also defines the native wireless encapsulation 2211 mode. The format of the encapsulated CAPWAP data frame is subject to 2212 the rules defined by the specific wireless technology binding. Each 2213 wireless technology binding MUST contain a section entitled "Payload 2214 Encapsulation", which defines the format of the wireless payload that 2215 is encapsulated within CAPWAP Data packets. 2217 For 802.3 payload frames, the 802.3 frame is encapsulated (excluding 2218 the IEEE 802.3 FCS checksum). If the encapsulated frame would exceed 2219 the transport layer's MTU, the sender is responsible for 2220 fragmentation of the frame, as specified in Section 3.4. 2222 4.4.3. Establishment of a DTLS Data Channel 2224 If the AC and WTP are configured to tunnel the data channel over 2225 DTLS, the proper DTLS session must be initiated. To avoid having to 2226 reauthenticate and reauthorize an AC and WTP, the DTLS data channel 2227 MUST be initiated using the TLS session resumption feature [RFC4346]. 2229 When establishing the DTLS-encrypted data channel, the WTP MUST 2230 provide the identifier returned during the initialization of the 2231 control channel to the DTLS component so it can perform the 2232 resumption using the proper session information. 2234 The AC DTLS implementation MUST NOT accept a session resumption 2235 request for a DTLS session in which the control channel for the 2236 session has been torn down. 2238 4.5. CAPWAP Control Messages 2240 The CAPWAP Control protocol provides a control channel between the 2241 WTP and the AC. Control messages are divided into the following 2242 message types: 2244 Discovery: CAPWAP Discovery messages are used to identify potential 2245 ACs, their load and capabilities. 2247 Join: CAPWAP Join messages are used by a WTP to request service from 2248 an AC, and for the AC to respond to the WTP. 2250 Control Channel Management: CAPWAP control channel management 2251 messages are used to maintain the control channel. 2253 WTP Configuration Management: The WTP Configuration messages are 2254 used by the AC to deliver a specific configuration to the WTP. 2255 Messages which retrieve statistics from a WTP are also included in 2256 WTP Configuration Management. 2258 Station Session Management: Station Session Management messages are 2259 used by the AC to deliver specific station policies to the WTP. 2261 Device Management Operations: Device management operations are used 2262 to request and deliver a firmware image to the WTP. 2264 Binding Specific CAPWAP Management Messages: Messages in this 2265 category are used by the AC and the WTP to exchange protocol- 2266 specific CAPWAP management messages. These messages may or may 2267 not be used to change the link state of a station. 2269 Discovery, Join, Control Channel Management, WTP Configuration 2270 Management and Station Session Management CAPWAP control messages 2271 MUST be implemented. Device Management Operations messages MAY be 2272 implemented. 2274 CAPWAP control messages sent from the WTP to the AC indicate that the 2275 WTP is operational, providing an implicit keep-alive mechanism for 2276 the WTP. The Control Channel Management Echo Request and Echo 2277 Response messages provide an explicit keep-alive mechanism when other 2278 CAPWAP control messages are not exchanged. 2280 4.5.1. Control Message Format 2282 All CAPWAP control messages are sent encapsulated within the CAPWAP 2283 header (see Section 4.3). Immediately following the CAPWAP header, 2284 is the control header, which has the following format: 2286 0 1 2 3 2287 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 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | Message Type | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | Seq Num | Msg Element Length | Flags | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | Msg Element [0..N] ... 2294 +-+-+-+-+-+-+-+-+-+-+-+-+ 2296 4.5.1.1. Message Type 2298 The Message Type field identifies the function of the CAPWAP control 2299 message. The Message Type field is comprised of an IANA Enterprise 2300 Number and an enterprise specific message type number. The first 2301 three octets contain the enterprise number in network byte order, 2302 with zero used for CAPWAP protocol defined message types and the IEEE 2303 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11 2304 technology specific message types. The last octet is the enterprise 2305 specific message type number, which has a range from 0 to 255. 2307 The message type field is defined as: 2309 Message Type = 2310 IANA Enterprise Number * 256 + 2311 Enterprise Specific Message Type Number 2313 The CAPWAP protocol reliability mechanism requires that messages be 2314 defined in pairs, consisting of both a Request and a Response 2315 message. The Response message MUST acknowledge the Request message. 2316 The assignment of CAPWAP control Message Type Values always occurs in 2317 pairs. All Request messages have odd numbered Message Type Values, 2318 and all Response messages have even numbered Message Type Values. 2319 The Request value MUST be assigned first. As an example, assigning a 2320 Message Type Value of 3 for a Request message and 4 for a Response 2321 message is valid, while assigning a Message Type Value of 4 for a 2322 Response message and 5 for the corresponding Request message is 2323 invalid. 2325 When a WTP or AC receives a message with a Message Type Value field 2326 that is not recognized and is an odd number, the number in the 2327 Message Type Value Field is incremented by one, and a Response 2328 message with a Message Type Value field containing the incremented 2329 value and containing the Result Code message element with the value 2330 (Unrecognized Request) is returned to the sender of the received 2331 message. If the unknown message type is even, the message is 2332 ignored. 2334 The valid values for CAPWAP Control Message Types are specified in 2335 the table below: 2337 CAPWAP Control Message Message Type 2338 Value 2339 Discovery Request 1 2340 Discovery Response 2 2341 Join Request 3 2342 Join Response 4 2343 Configuration Status 5 2344 Configuration Status Response 6 2345 Configuration Update Request 7 2346 Configuration Update Response 8 2347 WTP Event Request 9 2348 WTP Event Response 10 2349 Change State Event Request 11 2350 Change State Event Response 12 2351 Echo Request 13 2352 Echo Response 14 2353 Image Data Request 15 2354 Image Data Response 16 2355 Reset Request 17 2356 Reset Response 18 2357 Primary Discovery Request 19 2358 Primary Discovery Response 20 2359 Data Transfer Request 21 2360 Data Transfer Response 22 2361 Clear Configuration Request 23 2362 Clear Configuration Response 24 2363 Station Configuration Request 25 2364 Station Configuration Response 26 2366 4.5.1.2. Sequence Number 2368 The Sequence Number Field is an identifier value used to match 2369 Request and Response packets. When a CAPWAP packet with a Request 2370 Message Type Value is received, the value of the Sequence Number 2371 field is copied into the corresponding Response message. 2373 When a CAPWAP control message is sent, the sender's internal sequence 2374 number counter is monotonically incremented, ensuring that no two 2375 pending Request messages have the same Sequence Number. The Sequence 2376 Number field wraps back to zero. 2378 4.5.1.3. Message Element Length 2380 The Length field indicates the number of bytes following the Sequence 2381 Number field. 2383 4.5.1.4. Flags 2385 The Flags field MUST be set to zero. 2387 4.5.1.5. Message Element[0..N] 2389 The message element(s) carry the information pertinent to each of the 2390 control message types. Every control message in this specification 2391 specifies which message elements are permitted. 2393 When a WTP or AC receives a CAPWAP message without a message element 2394 that is specified as mandatory for the CAPWAP message, then the 2395 CAPWAP message is discarded. If the received message was a Request 2396 message for which the corresponding Response message carries message 2397 elements, then a corresponding Response message with a Result Code 2398 message element indicating "Failure - Missing Mandatory Message 2399 Element" is returned to the sender. 2401 When a WTP or AC receives a CAPWAP message with a message element 2402 that the WTP or AC does not recognize, the CAPWAP message is 2403 discarded. If the received message was a Request message for which 2404 the corresponding Response message carries message elements, then a 2405 corresponding Response message with a Result Code message element 2406 indicating "Failure - Unrecognized Message Element" and one or more 2407 Returned Message Element message elements is included, containing the 2408 unrecognized message element(s). 2410 4.5.2. Control Message Quality of Service 2412 It is recommended that CAPWAP control messages be sent by both the AC 2413 and the WTP with an appropriate Quality of Service precedence value, 2414 ensuring that congestion in the network minimizes occurrences of 2415 CAPWAP control channel disconnects. Therefore, a Quality of Service 2416 enabled CAPWAP device SHOULD use the following values: 2418 802.1P: The precedence value of 7 SHOULD be used. 2420 DSCP: The DSCP tag value of 46 SHOULD be used. 2422 4.5.3. Retransmissions 2424 The CAPWAP control protocol operates as a reliable transport. For 2425 each Request message, a Response message is defined, which is used to 2426 acknowledge receipt of the Request message. In addition, the control 2427 header Sequence Number field is used to pair the Request and Response 2428 messages (see Section 4.5.1). 2430 Response messages are not explicitly acknowledged, therefore if a 2431 Response message is not received, the original Request message is 2432 retransmitted. Implementations MAY cache Response messages to 2433 respond to a retransmitted Request messages with minimal local 2434 processing. Retransmitted Request messages MUST NOT be altered by 2435 the sender. The sender MUST assume that the original Request message 2436 was processed, but that the Response message was lost. Any 2437 alterations to the original Request message MUST have a new Sequence 2438 Number, and be treated as a new Request message by the receiver. 2440 After transmitting a Request message, the RetransmitInterval (see 2441 Section 4.7) timer and MaxRetransmit (see Section 4.8) variable are 2442 used to determine if the original Request message needs to be 2443 retransmitted. The RetransmitInterval timer is used the first time 2444 the Request is retransmitted. The timer is then doubled every 2445 subsequent time the same Request message is retransmitted, up to 2446 MaxRetransmit but no more than half the EchoInterval timer (see 2447 Section 4.7.7). Response messages are not subject to these timers. 2449 When a Request message is retransmitted, it MUST be re-encrypted via 2450 the DTLS stack. If the peer had received the Request message, and 2451 the corresponding Response message was lost, it is necessary to 2452 ensure that retransmitted Request messages are not identified as 2453 replays by the DTLS stack. Similarly, any cached Response messages 2454 that are retransmitted as a result of receiving a retransmitted 2455 Request message MUST be re-encrypted via DTLS. 2457 Duplicate Response messages, identified by the Sequence Number field 2458 in the CAPWAP control message header, SHOULD be discarded upon 2459 receipt. 2461 4.6. CAPWAP Protocol Message Elements 2463 This section defines the CAPWAP Protocol message elements which are 2464 included in CAPWAP protocol control messages. 2466 Message elements are used to carry information needed in control 2467 messages. Every message element is identified by the Type Value 2468 field, defined below. The total length of the message elements is 2469 indicated in the message element Length field. 2471 All of the message element definitions in this document use a diagram 2472 similar to the one below in order to depict its format. Note that to 2473 simplify this specification, these diagrams do not include the header 2474 fields (Type and Length). The header field values are defined in the 2475 message element descriptions. 2477 Unless otherwise specified, a control message that lists a set of 2478 supported (or expected) message elements MUST not expect the message 2479 elements to be in any specific order. The sender MAY include the 2480 message elements in any order. Unless otherwise noted, one message 2481 element of each type is present in a given control message. 2483 Additional message elements may be defined in separate IETF 2484 documents. 2486 The format of a message element uses the TLV format shown here: 2488 0 1 2 3 2489 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 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | Type | Length | 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 | Value ... | 2494 +-+-+-+-+-+-+-+-+ 2496 The 16 bit Type field identifies the information carried in the Value 2497 field and Length (16 bits) indicates the number of bytes in the Value 2498 field. Type field values are allocated as follows: 2500 Usage Type Values 2502 CAPWAP Protocol Message Elements 1-1023 2503 IEEE 802.11 Message Elements 1024-2047 2504 IEEE 802.16 Message Elements 2048 - 3071 2505 EPCGlobal Message Elements 3072 - 4095 2506 Reserved for Future Use 4096 - 65024 2508 The table below lists the CAPWAP protocol Message Elements and their 2509 Type values. 2511 CAPWAP Message Element Type Value 2513 AC Descriptor 1 2514 AC IPv4 List 2 2515 AC IPv6 List 3 2516 AC Name 4 2517 AC Name with Index 5 2518 AC Timestamp 6 2519 Add MAC ACL Entry 7 2520 Add Station 8 2521 Add Static MAC ACL Entry 9 2522 CAPWAP Control IPV4 Address 10 2523 CAPWAP Control IPV6 Address 11 2524 CAPWAP Local IPV4 Address TBD 2525 CAPWAP Local IPV6 Address TBD 2526 CAPWAP Timers 12 2527 CAPWAP Transport Protocol TBD 2528 Data Transfer Data 13 2529 Data Transfer Mode 14 2530 Decryption Error Report 15 2531 Decryption Error Report Period 16 2532 Delete MAC ACL Entry 17 2533 Delete Station 18 2534 Delete Static MAC ACL Entry 19 2535 Discovery Type 20 2536 Duplicate IPv4 Address 21 2537 Duplicate IPv6 Address 22 2538 Idle Timeout 23 2539 Image Data 24 2540 Image Identifier 25 2541 Image Info 26 2542 Initiate Download 27 2543 Location Data 28 2544 Maximum Message Length 29 2545 Radio Administrative State 31 2546 Radio Operational State 32 2547 Result Code 33 2548 Returned Message Element 34 2549 Session ID 35 2550 Statistics Timer 36 2551 Vendor Specific Payload 37 2552 WTP Board Data 38 2553 WTP Descriptor 39 2554 WTP Fallback 40 2555 WTP Frame Tunnel Mode 41 2556 WTP IPv4 IP Address 42 2557 WTP IPv6 IP Address 43 2558 WTP MAC Type 44 2559 WTP Name 45 2560 WTP Operational Statistics 46 2561 WTP Radio Statistics 47 2562 WTP Reboot Statistics 48 2563 WTP Static IP Address Information 49 2565 4.6.1. AC Descriptor 2567 The AC Descriptor message element is used by the AC to communicate 2568 its current state. The value contains the following fields. 2570 0 1 2 3 2571 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 2572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2573 | Stations | Limit | 2574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2575 | Active WTPs | Max WTPs | 2576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 | Security | R-MAC Field | Reserved1 | DTLS Policy | 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | Vendor Identifier | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | Type=4 | Length | 2582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2583 | Value... 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | Vendor Identifier | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | Type=5 | Length | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2589 | Value... 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 Type: 1 for AC Descriptor 2594 Length: >= 12 2596 Stations: The number of stations currently served by the AC 2598 Limit: The maximum number of stations supported by the AC 2600 Active WTPs: The number of WTPs currently attached to the AC 2602 Max WTPs: The maximum number of WTPs supported by the AC 2604 Security: A 8 bit mask specifying the authentication credential 2605 type supported by the AC. The following values are supported (see 2606 Section 2.4.4): 2608 1 - X.509 Certificate Based 2610 2 - Pre-Shared Secret 2612 R-MAC Field: The AC supports the optional Radio MAC Address field 2613 in the CAPWAP transport Header (see Section 4.3). 2615 Reserved: A set of reserved bits for future use. All 2616 implementations complying with this protocol MUST set to zero any 2617 bits that are reserved in the version of the protocol supported by 2618 that implementation. Receivers MUST ignore all bits not defined 2619 for the version of the protocol they support. 2621 DTLS Policy: The AC communicates its policy on the use of DTLS for 2622 the CAPWAP data channel. The AC MAY communicate more than one 2623 supported option, represented by the bit field below. The WTP 2624 MUST abide by one of the options communicated by AC. The 2625 following bit field values are supported: 2627 1 - Clear Text Data Channel Supported 2629 2 - DTLS Enabled Data Channel Supported 2631 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2632 Network Management Private Enterprise Codes" 2634 Type: Vendor specific encoding of AC information. The following 2635 values are supported. The Hardware and Software Version values 2636 MUST be included. 2638 4 - Hardware Version: The AC's hardware version number. 2640 5 - Software Version: The AC's Software (firmware) version 2641 number. 2643 Length: Length of vendor specific encoding of AC information. 2645 Value: Vendor specific encoding of AC information. 2647 4.6.2. AC IPv4 List 2649 The AC IPv4 List message element is used to configure a WTP with the 2650 latest list of ACs available for the WTP to join. 2652 0 1 2 3 2653 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 2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2655 | AC IP Address[] | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2658 Type: 2 for AC IPv4 List 2660 Length: >= 4 2662 The AC IP Address: An array of 32-bit integers containing AC IPv4 2663 Addresses. 2665 4.6.3. AC IPv6 List 2667 The AC IPv6 List message element is used to configure a WTP with the 2668 latest list of ACs available for the WTP to join. 2670 0 1 2 3 2671 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 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | AC IP Address[] | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | AC IP Address[] | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | AC IP Address[] | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2679 | AC IP Address[] | 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2682 Type: 3 for AC IPV6 List 2684 Length: >= 16 2686 The AC IP Address: An array of 128-bit integers containing AC IPv6 2687 Addresses. 2689 4.6.4. AC Name 2691 The AC Name message element contains an UTF-8 representation of the 2692 AC identity. The value is a variable length byte string. The string 2693 is NOT zero terminated. 2695 0 2696 0 1 2 3 4 5 6 7 2697 +-+-+-+-+-+-+-+-+ 2698 | Name ... 2699 +-+-+-+-+-+-+-+-+ 2701 Type: 4 for AC Name 2703 Length: > 0 2705 Name: A variable length UTF-8 encoded string containing the AC's 2706 name 2708 4.6.5. AC Name with Index 2710 The AC Name with Index message element is sent by the AC to the WTP 2711 to configure preferred ACs. The number of instances of this message 2712 element is equal to the number of ACs configured on the WTP. 2714 0 1 2715 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2717 | Index | AC Name... 2718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 Type: 5 for AC Name with Index 2722 Length: > 2 2724 Index: The index of the preferred server (1=primary, 2=secondary). 2726 AC Name: A variable length UTF-8 encoded string containing the AC 2727 name. 2729 4.6.6. AC Timestamp 2731 The AC Timestamp message element is sent by the AC to synchronize the 2732 WTP clock. 2734 0 1 2 3 2735 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 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 | Timestamp | 2738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 Type: 6 for AC Timestamp 2742 Length: 4 2744 Timestamp: The AC's current time, allowing all of the WTPs to be 2745 time synchronized in the format defined by Network Time Protocol 2746 (NTP) in RFC 1305 [RFC1305]. 2748 4.6.7. Add MAC ACL Entry 2750 The Add MAC Access Control List (ACL) Entry message element is used 2751 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2752 no longer provides service to the MAC addresses provided in the 2753 message. The MAC Addresses provided in this message element are not 2754 expected to be saved in non-volatile memory on the WTP. 2756 0 1 2 3 2757 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 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 | Num of Entries| Length | MAC Address ... 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2762 Type: 7 for Add MAC ACL Entry 2764 Length: >= 8 2766 Num of Entries: The number of instances of the Type/MAC Addresses 2767 fields in the array. 2769 Length: The length of the MAC Address field. 2771 MAC Address: MAC Addresses to add to the ACL. 2773 4.6.8. Add Station 2775 The Add Station message element is used by the AC to inform a WTP 2776 that it should forward traffic for a station. The Add Station 2777 message element is accompanied by technology specific binding 2778 information element(s) which may include security parameters. 2779 Consequently, the security parameters MUST be applied by the WTP for 2780 the station. 2782 After station policy has been delivered to the WTP through the Add 2783 Station message element, an AC MAY change any policies by sending a 2784 modified Add Station message element. When a WTP receives an Add 2785 Station message element for an existing station, it MUST override any 2786 existing state for the station. 2788 0 1 2 3 2789 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 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2791 | Radio ID | Length | MAC Address ... 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 | VLAN Name... 2794 +-+-+-+-+-+-+-+-+ 2796 Type: 8 for Add Station 2798 Length: >= 8 2800 Radio ID: An 8-bit value representing the radio 2802 Length: The length of the MAC Address field. 2804 MAC Address: The station's MAC Address 2806 VLAN Name: An optional variable length UTF-8 encoded string 2807 containing the VLAN Name on which the WTP is to locally bridge 2808 user data. Note this field is only valid with WTPs configured in 2809 Local MAC mode. 2811 4.6.9. Add Static MAC ACL Entry 2813 The Add Static MAC ACL Entry message element is used by an AC to add 2814 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2815 provides any service to the MAC addresses provided in the message. 2816 The MAC Addresses provided in this message element are expected to be 2817 saved in non-volatile memory on the WTP. 2819 0 1 2 3 2820 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 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2822 | Num of Entries| Length | MAC Address ... 2823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 Type: 9 for Add Static MAC ACL Entry 2827 Length: >= 8 2829 Num of Entries: The number of instances of the Type/MAC Addresses 2830 fields in the array. 2832 Length: The length of the MAC Address field. 2834 MAC Address: MAC Addresses to add to the permanent ACL. 2836 4.6.10. CAPWAP Control IPv4 Address 2838 The CAPWAP Control IPv4 Address message element is sent by the AC to 2839 the WTP during the discovery process and is used by the AC to provide 2840 the interfaces available on the AC, and the current number of WTPs 2841 connected. When multiple CAPWAP Control IPV4 Address message 2842 elements are returned, the WTP SHOULD perform load balancing across 2843 the multiple interfaces. 2845 0 1 2 3 2846 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 2847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2848 | IP Address | 2849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 | WTP Count | 2851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2853 Type: 10 for CAPWAP Control IPv4 Address 2855 Length: 6 2857 IP Address: The IP Address of an interface. 2859 WTP Count: The number of WTPs currently connected to the interface. 2861 4.6.11. CAPWAP Control IPv6 Address 2863 The CAPWAP Control IPv6 Address message element is sent by the AC to 2864 the WTP during the discovery process and is used by the AC to provide 2865 the interfaces available on the AC, and the current number of WTPs 2866 connected. This message element is useful for the WTP to perform 2867 load balancing across multiple interfaces. 2869 0 1 2 3 2870 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 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 | IP Address | 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 | IP Address | 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 | IP Address | 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | IP Address | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2880 | WTP Count | 2881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2883 Type: 11 for CAPWAP Control IPv6 Address 2885 Length: 18 2887 IP Address: The IP Address of an interface. 2889 WTP Count: The number of WTPs currently connected to the interface. 2891 4.6.12. CAPWAP Local IPv4 Address 2893 The CAPWAP Local IPv4 Address message element is sent by either the 2894 WTP or the AC in the Join Request, Configuration Status Request or 2895 Image Data Request message in order to communicate the IP Address of 2896 the transmitter. The receiver uses this to determine whether a 2897 middlebox exists between the two peers, by comparing the source IP 2898 address of the packet against the value of the message element. 2900 0 1 2 3 2901 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 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 | IP Address | 2904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 Type: TBD for CAPWAP Local IPv4 Address 2908 Length: 4 2910 IP Address: The IP Address of the sender. 2912 4.6.13. CAPWAP Local IPv6 Address 2914 The CAPWAP Local IPv6 Address message element is sent by either the 2915 WTP or the AC in the Discovery Response or Join Request in order to 2916 communicate the IP Address of the transmitter. The receiver uses 2917 this to determine whether a middlebox exists between the two peers, 2918 by comparing the source IP address of the packet against the value of 2919 the message element. 2921 0 1 2 3 2922 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 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 | IP Address | 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2926 | IP Address | 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | IP Address | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 | IP Address | 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 Type: TBD for CAPWAP Local IPv6 Address 2935 Length: 16 2936 IP Address: The IP Address of the sender. 2938 4.6.14. CAPWAP Timers 2940 The CAPWAP Timers message element is used by an AC to configure 2941 CAPWAP timers on a WTP. 2943 0 1 2944 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 | Discovery | Echo Request | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 Type: 12 for CAPWAP Timers 2951 Length: 2 2953 Discovery: The number of seconds between CAPWAP Discovery messages, 2954 when the WTP is in the discovery phase. 2956 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2957 messages. The default value for this message element is specified 2958 in Section 4.7.7. 2960 4.6.15. CAPWAP Transport Protocol 2962 When CAPWAP is run over IPv6, the UDP-Lite or UDP transports MAY be 2963 used (see Section 3). The CAPWAP IPv6 Transport Protocol message 2964 element is used by either the WTP or the AC to signal which transport 2965 protocol is to be used for the CAPWAP data channel. 2967 Upon receiving the Join Request, the AC MAY set the CAPWAP Transport 2968 Protocol to UDP-Lite in the Configuration Status Request or Image 2969 Data Request message if the CAPWAP message was received over IPv6, 2970 and the CAPWAP Local IPv6 Address message element (see 2971 Section 4.6.13) is present and the address matches the packet's 2972 source IP address. 2974 Upon receiving the Configuration Status Request or Image Data Request 2975 message, the WTP MAY set the CAPWAP Transport Protocol to UDP-Lite in 2976 the Configuration Status Response or Image Data Response message if 2977 the message was received over IPv6, and the CAPWAP Local IPv6 Address 2978 message element (see Section 4.6.13) is present and the address 2979 matches the packet's source IP address. 2981 For any other condition, the CAPWAP Transport Protocol MUST be set to 2982 UDP. 2984 0 2985 0 1 2 3 4 5 6 7 2986 +-+-+-+-+-+-+-+-+ 2987 | Transport | 2988 +-+-+-+-+-+-+-+-+ 2990 Type: TBD for CAPWAP Transport Protocol 2992 Length: 1 2994 Transport: The transport to use for the CAPWAP data channel. 2996 1 - UDP-Lite The UDP-Lite transport protocol is to be used for 2997 the CAPWAP data channel. Note that this option is illegal is 2998 either the WTP or the AC uses IPv4. 3000 2 - UDP The UDP transport protocol is to be used for the CAPWAP 3001 data channel. 3003 4.6.16. Data Transfer Data 3005 The Data Transfer Data message element is used by the WTP to provide 3006 information to the AC for debugging purposes. 3008 0 1 2 3009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | Data Type | Data Length | Data .... 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3014 Type: 13 for Data Transfer Data 3016 Length: >= 3 3018 Data Type: An 8-bit value the type of information being sent. The 3019 following values are supported: 3021 1 - WTP Crash Data 3023 2 - WTP Memory Dump 3025 Data Length: Length of data field. 3027 Data: Debug information. 3029 4.6.17. Data Transfer Mode 3031 The Data Transfer Mode message element is used by the WTP to indicate 3032 the type of data transfer information it is sending to the AC for 3033 debugging purposes. 3035 0 3036 0 1 2 3 4 5 6 7 3037 +-+-+-+-+-+-+-+-+ 3038 | Data Type | 3039 +-+-+-+-+-+-+-+-+ 3041 Type: 14 for Data Transfer Mode 3043 Length: 1 3045 Data Type: An 8-bit value the type of information being requested. 3046 The following values are supported: 3048 1 - WTP Crash Data 3050 2 - WTP Memory Dump 3052 4.6.18. Decryption Error Report 3054 The Decryption Error Report message element value is used by the WTP 3055 to inform the AC of decryption errors that have occurred since the 3056 last report. Note that this error reporting mechanism is not used if 3057 encryption and decryption services are provided in the AC. 3059 0 1 2 3060 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 | Radio ID |Num Of Entries | Length | MAC Address... 3063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3065 Type: 15 for Decryption Error Report 3067 Length: >= 9 3069 Radio ID: The Radio Identifier refers to an interface index on the 3070 WTP. 3072 Num of Entries: The number of instances of the Type/MAC Addresses 3073 fields in the array. 3075 Length: The length of the MAC Address field. 3077 MAC Address: MAC addresses of the station that has caused 3078 decryption errors. 3080 4.6.19. Decryption Error Report Period 3082 The Decryption Error Report Period message element value is used by 3083 the AC to inform the WTP how frequently it should send decryption 3084 error report messages. Note that this error reporting mechanism is 3085 not used if encryption and decryption services are provided in the 3086 AC. 3088 0 1 2 3089 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3091 | Radio ID | Report Interval | 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 Type: 16 for Decryption Error Report Period 3096 Length: 3 3098 Radio ID: The Radio Identifier refers to an interface index on the 3099 WTP. 3101 Report Interval: A 16-bit unsigned integer indicating the time, in 3102 seconds. The default value for this message element can be found 3103 in Section 4.8.8. 3105 4.6.20. Delete MAC ACL Entry 3107 The Delete MAC ACL Entry message element is used by an AC to delete a 3108 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 3109 MAC addresses provided in the message. 3111 0 1 2 3 3112 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 3113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3114 | Num of Entries| Length | MAC Address ... 3115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 Type: 17 for Delete MAC ACL Entry 3119 Length: >= 8 3120 Num of Entries: The number of instances of the Type/MAC Addresses 3121 fields in the array. 3123 Length: The length of the MAC Address field. 3125 MAC Address: An array of MAC Addresses to delete from the ACL. 3127 4.6.21. Delete Station 3129 The Delete Station message element is used by the AC to inform a WTP 3130 that it should no longer provide service to a particular station. 3131 The WTP MUST terminate service to the station immediately upon 3132 receiving this message element. 3134 The transmission of a Delete Station message element could occur for 3135 various reasons, including for administrative reasons, or if the 3136 station has roamed to another WTP. 3138 The Delete Station message element MAY be sent by the WTP, in the WTP 3139 Event Request message, to inform the AC that a particular station is 3140 no longer being provided service. This could occur as a result of an 3141 Idle Timeout (see section 4.4.43), due to internal resource shortages 3142 or for some other reason. 3144 0 1 2 3 3145 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 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | Radio ID | Length | MAC Address... 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 Type: 18 for Delete Station 3152 Length: >= 8 3154 Radio ID: An 8-bit value representing the radio 3156 Length: The length of the MAC Address field. 3158 MAC Address: The station's MAC Address 3160 4.6.22. Delete Static MAC ACL Entry 3162 The Delete Static MAC ACL Entry message element is used by an AC to 3163 delete a previously added static MAC ACL entry on a WTP, ensuring 3164 that the WTP provides service to the MAC addresses provided in the 3165 message. 3167 0 1 2 3 3168 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 3169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3170 | Num of Entries| Length | MAC Address ... 3171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 Type: 19 for Delete Static MAC ACL Entry 3175 Length: >= 8 3177 Num of Entries: The number of instances of the Type/MAC Addresses 3178 fields in the array. 3180 Length: The length of the MAC Address field. 3182 MAC Address: An array of MAC Addresses to delete from the static 3183 MAC ACL entry. 3185 4.6.23. Discovery Type 3187 The Discovery Type message element is used by the WTP to indicate how 3188 it has come to know about the existence of the AC to which it is 3189 sending the Discovery Request message. 3191 0 3192 0 1 2 3 4 5 6 7 3193 +-+-+-+-+-+-+-+-+ 3194 | Discovery Type| 3195 +-+-+-+-+-+-+-+-+ 3197 Type: 20 for Discovery Type 3199 Length: 1 3201 Discovery Type: An 8-bit value indicating how the WTP discovered 3202 the AC. The following values are supported: 3204 0 - Unknown 3206 1 - Static Configuration 3208 2 - DHCP 3210 3 - DNS 3211 4 - AC Referral (used when the AC was configured either through 3212 the AC IPv4 List or AC IPv6 List message element) 3214 4.6.24. Duplicate IPv4 Address 3216 The Duplicate IPv4 Address message element is used by a WTP to inform 3217 an AC that it has detected another IP device using the same IP 3218 address that the WTP is currently using. 3220 The WTP MUST transmit this message element with the status set to 1 3221 after it has detected a duplicate IP address. When the WTP detects 3222 that the duplicate IP address has been cleared, it MUSY send this 3223 message element with the status set to 0. 3225 0 1 2 3 3226 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 3227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3228 | IP Address | 3229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3230 | Status | Length | MAC Address ... 3231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 Type: 21 for Duplicate IPv4 Address 3235 Length: >= 12 3237 IP Address: The IP Address currently used by the WTP. 3239 Status: The status of the duplicate IP address. The value MUST be 3240 set to 1 when a duplicate address is detected, and 0 when the 3241 duplicate address has been cleared. 3243 Length: The length of the MAC Address field. 3245 MAC Address: The MAC Address of the offending device. 3247 4.6.25. Duplicate IPv6 Address 3249 The Duplicate IPv6 Address message element is used by a WTP to inform 3250 an AC that it has detected another host using the same IP address 3251 that the WTP is currently using. 3253 The WTP MUST transmit this message element with the status set to 1 3254 after it has detected a duplicate IP address. When the WTP detects 3255 that the duplicate IP address has been cleared, it MUST send this 3256 message element with the status set to 0. 3258 0 1 2 3 3259 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 3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3261 | IP Address | 3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3263 | IP Address | 3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3265 | IP Address | 3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3267 | IP Address | 3268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3269 | Status | Length | MAC Address ... 3270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3272 Type: 23 for Duplicate IPv6 Address 3274 Length: >= 24 3276 IP Address: The IP Address currently used by the WTP. 3278 Status: The status of the duplicate IP address. The value MUST be 3279 set to 1 when a duplicate address is detected, and 0 when the 3280 duplicate address has been cleared. 3282 Length: The length of the MAC Address field. 3284 MAC Address: The MAC Address of the offending device. 3286 4.6.26. Idle Timeout 3288 The Idle Timeout message element is sent by the AC to the WTP to 3289 provide the idle timeout value that the WTP SHOULD enforce for its 3290 active stations. The value applies to all radios on the WTP. 3292 0 1 2 3 3293 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 3294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3295 | Timeout | 3296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 Type: 23 for Idle Timeout 3300 Length: 4 3302 Timeout: The current idle timeout to be enforced by the WTP. The 3303 default value for this message element is specified in 3304 Section 4.8.5. 3306 4.6.27. Image Data 3308 The Image Data message element is present in the Image Data Request 3309 message sent by the AC and contains the following fields. 3311 0 1 2 3 3312 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 3313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 | Opcode | Value ... 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3317 Type: 24 for Image Data 3319 Length: >= 1 3321 Opcode: An 8-bit value representing the transfer opcode. The 3322 following values are supported: 3324 1 - Image data is included 3326 2 - Last Image Data Block is included (EOF) 3328 5 - An error occurred. Transfer is aborted 3330 Value: The Image Data field contains up to 1024 characters. If the 3331 block being sent is the last one, the Opcode is set to 2. The AC 3332 MAY opt to abort the data transfer by setting the Opcode to 5. 3333 When the Opcode is 5, the Value field has a zero length. 3335 4.6.28. Image Identifier 3337 The Image Identifier message element is sent by the AC to the WTP and 3338 is used to indicate the expected active software version that is to 3339 be run on the WTP. The value is a variable length UTF-8 encoded 3340 string, which is NOT zero terminated. 3342 0 1 2 3 3343 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 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | Vendor Identifier | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Value... 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 Type: 25 for Image Identifier 3352 Length: >= 1 3354 Value: A variable length UTF-8 encoded string containing the 3355 firmware identifier to be run on the WTP. 3357 4.6.29. Image Information 3359 The Image Information message element is present in the Image Data 3360 Response message sent by the AC to the WTP and contains the following 3361 fields. 3363 0 1 2 3 3364 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 3365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3366 | File Size | 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3368 | Hash | 3369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3370 | Hash | 3371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3372 | Hash | 3373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 | Hash | 3375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3377 Type: 26 for Image Information 3379 Length: 18 3381 File Size: A 32-bit value containing the size of the file, in 3382 bytes, that will be transferred by the AC to the WTP. 3384 Hash: A 16 octet hash of the image. The hash is computed using 3385 MD5, using the following pseudo-code: 3387 #include 3388 CapwapCreateHash(char *hash, char *image, int image_len) 3389 { 3390 MD_CTX context; 3392 MDInit (&context); 3393 MDUpdate (&context, buffer, len); 3394 MDFinal (hash, &context); 3395 } 3397 4.6.30. Initiate Download 3399 The Initiate Download message element is used by the AC to inform the 3400 WTP that the WTP SHOULD initiate a firmware upgrade. The WTP 3401 subsequently transmits an Image Data Request message which includes 3402 the Image Download message element. This message element does not 3403 contain any data. 3405 Type: 27 for Initiate Download 3407 Length: 0 3409 4.6.31. Location Data 3411 The Location Data message element is a variable length byte UTF-8 3412 encoded string containing user defined location information (e.g. 3413 "Next to Fridge"). This information is configurable by the network 3414 administrator, and allows the WTP location to be determined. The 3415 string is not zero terminated. 3417 0 3418 0 1 2 3 4 5 6 7 3419 +-+-+-+-+-+-+-+-+- 3420 | Location ... 3421 +-+-+-+-+-+-+-+-+- 3423 Type: 28 for Location Data 3425 Length: > 0 3427 Location: A non-zero terminated UTF-8 encoded string containing the 3428 WTP location. 3430 4.6.32. Maximum Message Length 3432 The Maximum Message Length message element is included in the Join 3433 Request message by the WTP to indicate the maximum CAPWAP message 3434 length that it supports to the AC. The Maximum Message Length 3435 message element is optionally included in Join Response message by 3436 the AC to indicate the maximum CAPWAP message length that it supports 3437 to the WTP. 3439 0 1 2 3440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3442 | Maximum Message Length | 3443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 3445 Type: 29 for Maximum Message Length 3447 Length: 2 3449 Maximum Message Length An 16-bit unsigned integer indicating the 3450 maximum message length. 3452 4.6.33. Radio Administrative State 3454 The Radio Administrative State message element is used to communicate 3455 the state of a particular radio. The Radio Administrative State 3456 message element is sent by the AC to change the state of the WTP. 3457 The WTP saves the value, to ensure that it remains across WTP resets. 3458 The WTP communicates this message element during the configuration 3459 phase, in the Configuration Status Request message, to ensure that AC 3460 has the WTP radio current administrative state settings. The message 3461 element contains the following fields. 3463 0 1 3464 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3466 | Radio ID | Admin State | 3467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3469 Type: 31 for Radio Administrative State 3471 Length: 2 3473 Radio ID: An 8-bit value representing the radio to configure. The 3474 Radio ID field MAY also include the value of 0xff, which is used 3475 to identify the WTP. If an AC wishes to change the administrative 3476 state of a WTP, it includes 0xff in the Radio ID field. 3478 Admin State: An 8-bit value representing the administrative state 3479 of the radio. The default value for the Admin State field is 3480 listed in Section 4.8.1. The following values are supported: 3482 1 - Enabled 3484 2 - Disabled 3486 4.6.34. Radio Operational State 3488 The Radio Operational State message element is sent by the WTP to the 3489 AC to communicate a radio's operational state. This message element 3490 is included in the Configuration Update Response message by the WTP 3491 if it was requested to change the state of its radio, via the Radio 3492 Administrative State message element, but was unable to comply to the 3493 request. This message element is included in the Change State Event 3494 message when a WTP radio state was changed unexpectedly. This could 3495 occur due to a hardware failure. Note that the operational state 3496 setting is not saved on the WTP, and therefore does not remain across 3497 WTP resets. The value contains three fields, as shown below. 3499 0 1 2 3500 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 | Radio ID | State | Cause | 3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 Type: 32 for Radio Operational State 3507 Length: 3 3509 Radio ID: The Radio Identifier refers to an interface index on the 3510 WTP. A value of 0xFF is invalid, as it is not possible to change 3511 the WTP's operational state. 3513 State: An 8-bit boolean value representing the state of the radio. 3514 A value of one disables the radio, while a value of two enables 3515 it. 3517 Cause: When a radio is inoperable, the cause field contains the 3518 reason the radio is out of service. The following values are 3519 supported: 3521 0 - Normal 3523 1 - Radio Failure 3525 2 - Software Failure 3527 3 - Administratively Set 3529 4.6.35. Result Code 3531 The Result Code message element value is a 32-bit integer value, 3532 indicating the result of the Request message corresponding to the 3533 Sequence Number included in the Response message. 3535 0 1 2 3 3536 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 3537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3538 | Result Code | 3539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3541 Type: 33 for Result Code 3543 Length: 4 3545 Result Code: The following values are defined: 3547 0 Success 3549 1 Failure (AC List message element MUST be present) 3551 2 Success (NAT detected) 3553 3 Join Failure (unspecified) 3555 4 Join Failure (Resource Depletion) 3557 5 Join Failure (Unknown Source) 3559 6 Join Failure (Incorrect Data) 3561 7 Join Failure (Session ID already in use) 3563 8 Join Failure (WTP Hardware not supported) 3565 9 Join Failure (Binding Not Supported) 3567 10 Reset Failure (Unable to Reset) 3569 11 Reset Failure (Firmware Write Error) 3571 12 Configuration Failure (Unable to Apply Requested Configuration 3572 - Service Provided Anyhow) 3574 13 Configuration Failure (Unable to Apply Requested Configuration 3575 - Service Not Provided) 3577 14 Image Data Error (Invalid Checksum) 3579 15 Image Data Error (Invalid Data Length) 3581 16 Image Data Error (Other Error) 3583 17 Image Data Error (Image Already Present) 3585 18 Message Unexpected (Invalid in current state) 3586 19 Message Unexpected (Unrecognized Request) 3588 20 Failure - Missing Mandatory Message Element 3590 21 Failure - Unrecognized Message Element 3592 4.6.36. Returned Message Element 3594 The Returned Message Element is sent by the WTP in the Change State 3595 Event Request message to communicate to the AC which message elements 3596 in the Configuration Status Response it was unable to apply locally. 3597 The Returned Message Element message element contains a result code 3598 indicating the reason that the configuration could not be applied, 3599 and encapsulates the failed message element. 3601 0 1 2 3602 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3604 | Reason | Message Element... 3605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3607 Type: 34 for Returned Message Element 3609 Length: >= 1 3611 Reason: The reason why the configuration in the offending message 3612 element could not be applied by the WTP. 3614 1 - Unknown Message Element 3616 2 - Unsupported Message Element 3618 3 - Unknown Message Element Value 3620 4 - Unsupported Message Element Value 3622 Message Element: The Message Element field encapsulates the message 3623 element sent by the AC in the Configuration Status Response 3624 message that caused the error. 3626 4.6.37. Session ID 3628 The Session ID message element value contains a randomly generated 3629 unsigned 32-bit integer. 3631 0 1 2 3 3632 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 3633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3634 | Session ID | 3635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3637 Type: 35 for Session ID 3639 Length: 16 3641 Session ID: A 32-bit unsigned integer used as a random session 3642 identifier 3644 4.6.38. Statistics Timer 3646 The Statistics Timer message element value is used by the AC to 3647 inform the WTP of the frequency with which it expects to receive 3648 updated statistics. 3650 0 1 3651 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3653 | Statistics Timer | 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3656 Type: 36 for Statistics Timer 3658 Length: 2 3660 Statistics Timer: A 16-bit unsigned integer indicating the time, in 3661 seconds. The default value for this timer is specified in 3662 Section 4.7.14. 3664 4.6.39. Vendor Specific Payload 3666 The Vendor Specific Payload message element is used to communicate 3667 vendor specific information between the WTP and the AC. The Vendor 3668 Specific Payload message element MAY be present in any CAPWAP 3669 message. The message element uses the following format: 3671 0 1 2 3 3672 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 3673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3674 | Vendor Identifier | 3675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3676 | Element ID | Value... | 3677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3679 Type: 37 for Vendor Specific 3681 Length: >= 7 3683 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3684 Network Management Private Enterprise Codes" [RFC3232] 3686 Element ID: A 16-bit Element Identifier which is managed by the 3687 vendor. 3689 Value: The value associated with the vendor specific element. 3691 4.6.40. WTP Board Data 3693 The WTP Board Data message element is sent by the WTP to the AC and 3694 contains information about the hardware present. 3696 0 1 2 3 3697 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 3698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3699 | Vendor Identifier | 3700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3701 | Type=0 | Length | 3702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3703 | Value... 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3705 | Type=1 | Length | 3706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3707 | Value... 3708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3709 | Optional additional vendor specific WTP board data TLVs..... 3710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3712 Type: 38 for WTP Board Data 3714 Length: >=14 3716 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3717 Network Management Private Enterprise Codes" 3719 Type: The following values are supported: 3721 0 - WTP Model Number: The WTP Model Number MUST be included in 3722 the WTP Board Data message element. 3724 1 - WTP Serial Number: The WTP Serial Number MUST be included in 3725 the WTP Board Data message element. 3727 2 - Board ID: A hardware identifier, which MAY be included in 3728 the WTP Board Data message element. 3730 3 - Board Revision A revision number of the board, which MAY be 3731 included in the WTP Board Data message element. 3733 4 - Base MAC Address The WTP's Base MAC Address, which MAY be 3734 assigned to the primary Ethernet interface. 3736 4.6.41. WTP Descriptor 3738 The WTP Descriptor message element is used by a WTP to communicate 3739 its current hardware and software (firmware) configuration. The 3740 value contains the following fields. 3742 0 1 2 3 3743 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 3744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3745 | Max Radios | Radios in use | Encryption Capabilities | 3746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3747 | Vendor Identifier | 3748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3749 | Type=0 | Length | 3750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3751 | Value... 3752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3753 | Vendor Identifier | 3754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3755 | Type=1 | Length | 3756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3757 | Value... 3758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3759 | Vendor Identifier | 3760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3761 | Type=2 | Length | 3762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3763 | Value... 3764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3765 | Vendor Identifier | 3766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3767 | Type=3 | Length | 3768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3769 | Value... 3770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3772 Type: 39 for WTP Descriptor 3774 Length: >= 31 3776 Max Radios: An 8-bit value representing the number of radios (where 3777 each radio is identified via the Radio ID field) supported by the 3778 WTP. 3780 Radios in use: An 8-bit value representing the number of radios in 3781 use in the WTP. 3783 Encryption Capabilities: This 16-bit field is used by the WTP to 3784 communicate its capabilities to the AC. A WTP that does not have 3785 any encryption capabilities sets this field to zero (0). Refer to 3786 the specific wireless binding for further specification of the 3787 Encryption Capabilities field. 3789 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 3790 Network Management Private Enterprise Codes". 3792 Type: The following values are supported. The Hardware Version, 3793 Active Software Version, and Boot Version values MUST be included. 3794 Zero or more Other Software Version values MAY be included. 3796 0 - Hardware Version: The WTP hardware version number. 3798 1 - Active Software Version: The WTP running software version 3799 number. 3801 2 - Boot Version: The WTP boot loader version number. 3803 3 - Other Software Version: The WTP non-running software 3804 (firmware) version number. 3806 Length: Length of vendor specific encoding of WTP information. 3808 Value: Vendor specific data of WTP information encoded in the UTF-8 3809 format. 3811 4.6.42. WTP Fallback 3813 The WTP Fallback message element is sent by the AC to the WTP to 3814 enable or disable automatic CAPWAP fallback in the event that a WTP 3815 detects its preferred AC, and is not currently connected to it. 3817 0 3818 0 1 2 3 4 5 6 7 3819 +-+-+-+-+-+-+-+-+ 3820 | Mode | 3821 +-+-+-+-+-+-+-+-+ 3823 Type: 40 for WTP Fallback 3825 Length: 1 3827 Mode: The 8-bit value indicates the status of automatic CAPWAP 3828 fallback on the WTP. When enabled, if the WTP detects that its 3829 primary AC is available, and that the WTP is not connected to the 3830 primary AC, the WTP SHOULD automatically disconnect from its 3831 current AC and reconnect to its primary AC. If disabled, the WTP 3832 will only reconnect to its primary AC through manual intervention 3833 (e.g., through the Reset Request message). The default value for 3834 this field is specified in Section 4.8.10. The following values 3835 are supported: 3837 1 - Enabled 3839 2 - Disabled 3841 4.6.43. WTP Frame Tunnel Mode 3843 The WTP Frame Tunnel Mode message element allows the WTP to 3844 communicate the tunneling modes of operation which it supports to the 3845 AC. A WTP that advertises support for all types allows the AC to 3846 select which type will be used, based on its local policy. 3848 0 3849 0 1 2 3 4 5 6 7 3850 +-+-+-+-+-+-+-+-+ 3851 | Tunnel Mode | 3852 +-+-+-+-+-+-+-+-+ 3854 Type: 41 for WTP Frame Tunnel Mode 3856 Length: 1 3858 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3859 modes for station data that are supported by the WTP. The 3860 following values are supported: 3862 1 - Local Bridging: When Local Bridging is used, the WTP does 3863 not tunnel user traffic to the AC; all user traffic is locally 3864 bridged. This value MUST NOT be used when the WTP MAC Type is 3865 set to Split-MAC. 3867 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode 3868 requires the WTP and AC to encapsulate all user payload as 3869 native IEEE 802.3 frames (see Section 4.4). All user traffic 3870 is tunneled to the AC. This value MUST NOT be used when the 3871 WTP MAC Type is set to Split-MAC. 3873 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3874 the WTP and AC to encapsulate all user payloads as native 3875 wireless frames, as defined by the wireless binding (see for 3876 example Section 4.4). 3878 7 - All: The WTP is capable of supporting all frame tunnel 3879 modes. 3881 4.6.44. WTP IPv4 IP Address 3883 The WTP IPv4 address is used to perform NAT detection. 3885 0 1 2 3 3886 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 3887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3888 | WTP IPv4 IP Address | 3889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3891 Type: 42 for WTP IPv4 IP Address 3893 Length: 4 3895 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3896 packets. This field is used for NAT detection. 3898 4.6.45. WTP IPv6 IP Address 3900 The WTP IPv6 address is used to perform NAT detection (e.g., IPv4 to 3901 IPv6 NAT to help with technology transition). 3903 0 1 2 3 3904 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 3905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3906 | WTP IPv6 IP Address | 3907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3908 | WTP IPv6 IP Address | 3909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3910 | WTP IPv6 IP Address | 3911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3912 | WTP IPv6 IP Address | 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3915 Type: 43 for WTP IPv6 IP Address 3917 Length: 32 3919 WTP IPv6 IP Address: The IPv6 address from which the WTP is sending 3920 packets. This field is used for NAT detection. 3922 4.6.46. WTP MAC Type 3924 The WTP MAC-Type message element allows the WTP to communicate its 3925 mode of operation to the AC. A WTP that advertises support for both 3926 modes allows the AC to select the mode to use, based on local policy. 3928 0 3929 0 1 2 3 4 5 6 7 3930 +-+-+-+-+-+-+-+-+ 3931 | MAC Type | 3932 +-+-+-+-+-+-+-+-+ 3934 Type: 44 for WTP MAC Type 3936 Length: 1 3938 MAC Type: The MAC mode of operation supported by the WTP. The 3939 following values are supported 3941 0 - Local-MAC: Local-MAC is the default mode that MUST be 3942 supported by all WTPs. 3944 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3945 to receive and process native wireless frames. 3947 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3948 MAC. 3950 4.6.47. WTP Name 3952 The WTP Name message element is a variable length byte UTF-8 encoded 3953 string. The string is not zero terminated. 3955 0 3956 0 1 2 3 4 5 6 7 3957 +-+-+-+-+-+-+-+-+- 3958 | WTP Name ... 3959 +-+-+-+-+-+-+-+-+- 3961 Type: 45 for WTP Name 3963 Length: variable 3965 WTP Name: A non-zero terminated UTF-8 encoded string containing the 3966 WTP name. 3968 4.6.48. WTP Operational Statistics 3970 The WTP Operational Statistics message element is sent by the WTP to 3971 the AC to provide statistics related to the operation of the WTP. 3973 0 1 2 3 3974 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 3975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3976 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3979 Type: 46 for WTP Operational Statistics 3981 Length: 4 3983 Radio ID: The radio ID of the radio to which the statistics apply. 3985 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3986 queue utilization, calculated as the sum of utilized transmit 3987 queue lengths divided by the sum of maximum transmit queue 3988 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3989 representative of congestion conditions over wireless interfaces 3990 between the WTP and stations. 3992 Wireless Link Frames per Sec: The number of frames transmitted or 3993 received per second by the WTP over the air interface. 3995 4.6.49. WTP Radio Statistics 3997 The WTP Radio Statistics message element is sent by the WTP to the AC 3998 to communicate statistics on radio behavior and reasons why the WTP 3999 radio has been reset. 4001 0 1 2 3 4002 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 4003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4004 | Radio ID | Last Fail Type| Reset Count | 4005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4006 | SW Failure Count | HW Failure Count | 4007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4008 | Other Failure Count | Unknown Failure Count | 4009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4010 | Config Update Count | Channel Change Count | 4011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4012 | Band Change Count | Current Noise Floor | 4013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4015 Type: 47 for WTP Radio Statistics 4017 Length: 20 4019 Radio ID: The radio ID of the radio to which the statistics apply. 4021 Last Failure Type: The last WTP failure. The following values are 4022 supported: 4024 0 - Statistic Not Supported 4026 1 - Software Failure 4028 2 - Hardware Failure 4030 3 - Other Failure 4032 255 - Unknown (e.g., WTP doesn't keep track of info) 4034 Reset Count: The number of times that that the radio has been 4035 reset. 4037 SW Failure Count: The number of times that the radio has failed due 4038 to software related reasons. 4040 HW Failure Count: The number of times that the radio has failed due 4041 to hardware related reasons. 4043 Other Failure Count: The number of times that the radio has failed 4044 due to known reasons, other than software or hardware failure. 4046 Unknown Failure Count: The number of times that the radio has 4047 failed for unknown reasons. 4049 Config Update Count: The number of times that the radio 4050 configuration has been updated. 4052 Channel Change Count: The number of times that the radio channel 4053 has been changed. 4055 Band Change Count: The number of times that the radio has changed 4056 frequency bands. 4058 Current Noise Floor: A signed integer which indicates the noise 4059 floor of the radio receiver in units of dBm. 4061 4.6.50. WTP Reboot Statistics 4063 The WTP Reboot Statistics message element is sent by the WTP to the 4064 AC to communicate reasons why WTP reboots have occurred. 4066 0 1 2 3 4067 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 4068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4069 | Reboot Count | AC Initiated Count | 4070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4071 | Link Failure Count | SW Failure Count | 4072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4073 | HW Failure Count | Other Failure Count | 4074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4075 | Unknown Failure Count |Last Failure Type| 4076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4078 Type: 48 for WTP Reboot Statistics 4080 Length: 15 4081 Reboot Count: The number of reboots that have occurred due to a WTP 4082 crash. A value of 65535 implies that this information is not 4083 available on the WTP. 4085 AC Initiated Count: The number of reboots that have occurred at the 4086 request of a CAPWAP protocol message, such as a change in 4087 configuration that required a reboot or an explicit CAPWAP 4088 protocol reset request. A value of 65535 implies that this 4089 information is not available on the WTP. 4091 Link Failure Count: The number of times that a CAPWAP protocol 4092 connection with an AC has failed due to link failure. 4094 SW Failure Count: The number of times that a CAPWAP protocol 4095 connection with an AC has failed due to software related reasons. 4097 HW Failure Count: The number of times that a CAPWAP protocol 4098 connection with an AC has failed due to hardware related reasons. 4100 Other Failure Count: The number of times that a CAPWAP protocol 4101 connection with an AC has failed due to known reasons, other than 4102 AC initiated, link, SW or HW failure. 4104 Unknown Failure Count: The number of times that a CAPWAP protocol 4105 connection with an AC has failed for unknown reasons. 4107 Last Failure Type: The failure type of the most recent WTP failure. 4108 The following values are supported: 4110 0 - Not Supported 4112 1 - AC Initiated (see Section 9.2) 4114 2 - Link Failure 4116 3 - Software Failure 4118 4 - Hardware Failure 4120 5 - Other Failure 4122 255 - Unknown (e.g., WTP doesn't keep track of info) 4124 4.6.51. WTP Static IP Address Information 4126 The WTP Static IP Address Information message element is used by an 4127 AC to configure or clear a previously configured static IP address on 4128 a WTP. 4130 0 1 2 3 4131 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 4132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4133 | IP Address | 4134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4135 | Netmask | 4136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4137 | Gateway | 4138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4139 | Static | 4140 +-+-+-+-+-+-+-+-+ 4142 Type: 49 for WTP Static IP Address Information 4144 Length: 13 4146 IP Address: The IP Address to assign to the WTP. This field is 4147 only valid if the static field is set to one. 4149 Netmask: The IP Netmask. This field is only valid if the static 4150 field is set to one. 4152 Gateway: The IP address of the gateway. This field is only valid 4153 if the static field is set to one. 4155 Netmask: The IP Netmask. This field is only valid if the static 4156 field is set to one. 4158 Static: An 8-bit boolean stating whether the WTP should use a 4159 static IP address or not. A value of zero disables the static IP 4160 address, while a value of one enables it. 4162 4.7. CAPWAP Protocol Timers 4164 This section contains the CAPWAP timers. 4166 4.7.1. ChangeStatePendingTimer 4168 The maximum time, in seconds, the AC will wait for the Change State 4169 Event Request from the WTP after having transmitted a successful 4170 Configuration Status Response message. The default value is 25 4171 seconds. 4173 4.7.2. DataChannelKeepAlive 4175 The DataChannelKeepAlive timer is used by the WTP to determine the 4176 next opportunity when it must transmit the Data Channel KeepAlive. 4178 Default: 30 4180 4.7.3. DataChannelDeadInterval 4182 The minimum time, in seconds, a WTP MUST wait without having received 4183 a Data Channel Keep Alive packet before the destination for the Data 4184 Channel Keep Alive packets may be considered dead. The value of this 4185 timer MUST be no less than 2*DataChannelKeepAlive seconds and no 4186 greater that 240 seconds. 4188 Default: 5 4190 4.7.4. DataCheckTimer 4192 The number of seconds the AC will wait for the Data Channel Keep 4193 Alive, which is required by the CAPWAP state machine's Data Check 4194 state. The AC resets the state machine if this timer expires prior 4195 to transitioning to the next state. 4197 Default: 30 4199 4.7.5. DiscoveryInterval 4201 The minimum time, in seconds, that a WTP MUST wait after receiving a 4202 Discovery Response message, before initiating a DTLS handshake. 4204 Default: 5 4206 4.7.6. DTLSSessionDelete 4208 The minimum time, in seconds, a WTP MUST wait for DTLS session 4209 deletion. 4211 Default: 5 4213 4.7.7. EchoInterval 4215 The minimum time, in seconds, between sending Echo Request messages 4216 to the AC with which the WTP has joined. 4218 Default: 30 4220 4.7.8. ImageDataStartTimer 4222 The number of seconds the AC will wait for the WTP to initiate the 4223 Image Data process. 4225 Default: 30 4227 4.7.9. MaxDiscoveryInterval 4229 The maximum time allowed between sending Discovery Request messages, 4230 in seconds. This value MUST be no less than 2 seconds and no greater 4231 than 180 seconds. 4233 Default: 20 seconds. 4235 4.7.10. MaxFailedDTLSSessionRetry 4237 The maximum number of failed DTLS session establishment attempts 4238 before the CAPWAP device enters a silent period. 4240 Default: 3. 4242 4.7.11. ResponseTimeout 4244 The minimum time, in seconds, in which the WTP or AC MUST respond to 4245 a CAPWAP Request message. 4247 Default: 1 4249 4.7.12. RetransmitInterval 4251 The minimum time, in seconds, in which a non-acknowledged CAPWAP 4252 packet will be retransmitted. 4254 Default: 3 4256 4.7.13. SilentInterval 4258 For a WTP, this is the minimum time, in seconds, a WTP MUST wait 4259 before it MAY again send Discovery Request messages or attempt to a 4260 establish DTLS session. For an AC, this is the minimum time, in 4261 seconds, during which the AC SHOULD ignore all CAPWAP and DTLS 4262 packets received from the WTP that is in the Sulking state. 4264 Default: 30 4266 4.7.14. StatisticsTimer 4268 The default Statistics Interval is 120 seconds. 4270 4.7.15. WaitDTLS 4272 The maximum time, in seconds, a WTP MUST wait without having received 4273 a DTLS Handshake message from an AC. This timer MUST be greater than 4274 30 seconds. 4276 Default: 60 4278 4.7.16. WaitJoin 4280 The maximum time, in seconds, after which the DTLS session has been 4281 established that the AC will wait before receiving a Join Request 4282 message. This timer MUST be greater than 30 seconds. 4284 Default: 60 4286 4.8. CAPWAP Protocol Variables 4288 A WTP or AC that implements the CAPWAP Discovery phase MUST allow for 4289 the following variables to be configured by system management; 4290 default values are specified, making explicit configuration 4291 unnecessary in many cases. If the default values are explicitly 4292 overridden by the AC, the WTP MUST save the values sent by the AC. 4294 4.8.1. AdminState 4296 The default Administrative State value is enabled (1). 4298 4.8.2. DiscoveryCount 4300 The number of Discovery Request messages transmitted by a WTP to a 4301 single AC. This is a monotonically increasing counter. 4303 4.8.3. FailedDTLSAuthFailCount 4305 The number of failed DTLS session establishment attempts due to 4306 authentication failures. 4308 4.8.4. FailedDTLSSessionCount 4310 The number of failed DTLS session establishment attempts. 4312 4.8.5. IdleTimeout 4314 The default Idle Timeout is 300 seconds. 4316 4.8.6. MaxDiscoveries 4318 The maximum number of Discovery Request messages that will be sent 4319 after a WTP boots. 4321 Default: 10 4323 4.8.7. MaxRetransmit 4325 The maximum number of retransmissions for a given CAPWAP packet 4326 before the link layer considers the peer dead. 4328 Default: 5 4330 4.8.8. ReportInterval 4332 The default Report Interval is 120 seconds. 4334 4.8.9. RetransmitCount 4336 The number of retransmissions for a given CAPWAP packet. This is a 4337 monotonically increasing counter. 4339 4.8.10. WTPFallBack 4341 The default WTP Fallback value is enabled (1). 4343 4.9. WTP Saved Variables 4345 In addition to the values defined in Section 4.8, the following 4346 values SHOULD be saved on the WTP in non-volatile memory. CAPWAP 4347 wireless bindings MAY define additional values that SHOULD be stored 4348 on the WTP. 4350 4.9.1. AdminRebootCount 4352 The number of times the WTP has rebooted administratively, defined in 4353 Section 4.6.50. 4355 4.9.2. FrameEncapType 4357 For WTPs that support multiple Frame Encapsulation Types, it is 4358 useful to save the value configured by the AC. The Frame 4359 Encapsulation Type is defined in Section 4.6.43. 4361 4.9.3. LastRebootReason 4363 The reason why the WTP last rebooted, defined in Section 4.6.50. 4365 4.9.4. MacType 4367 For WTPs that support multiple MAC Types, it is useful to save the 4368 value configured by the AC. The MACType is defined in 4369 Section 4.6.46. 4371 4.9.5. PreferredACs 4373 The preferred ACs, with the index, defined in Section 4.6.5. 4375 4.9.6. RebootCount 4377 The number of times the WTP has rebooted, defined in Section 4.6.50. 4379 4.9.7. Static ACL Table 4381 The static ACL table saved on the WTP, as configured by the Add 4382 Static MAC ACL Entry message element, see Section 4.6.9. 4384 4.9.8. Static IP Address 4386 The static IP Address assigned to the WTP, as configured by the WTP 4387 Static IP Address Information message element (see Section 4.6.51). 4389 4.9.9. WTPLinkFailureCount 4391 The number of times the link to the AC has failed, see 4392 Section 4.6.50. 4394 4.9.10. WTPLocation 4396 The WTP Location, defined in Section 4.6.31. 4398 4.9.11. WTPName 4400 The WTP Name, defined in Section 4.6.47. 4402 5. CAPWAP Discovery Operations 4404 The Discovery messages are used by a WTP to determine which ACs are 4405 available to provide service, and the capabilities and load of the 4406 ACs. 4408 5.1. Discovery Request Message 4410 The Discovery Request message is used by the WTP to automatically 4411 discover potential ACs available in the network. The Discovery 4412 Request message provides ACs with the primary capabilities of the 4413 WTP. A WTP must exchange this information to ensure subsequent 4414 exchanges with the ACs are consistent with the WTP's functional 4415 characteristics. 4417 Discovery Request messages MUST be sent by a WTP in the Discover 4418 state after waiting for a random delay less than 4419 MaxDiscoveryInterval, after a WTP first comes up or is 4420 (re)initialized. A WTP MUST send no more than the maximum of 4421 MaxDiscoveries Discovery Request messages, waiting for a random delay 4422 less than MaxDiscoveryInterval between each successive message. 4424 This is to prevent an explosion of WTP Discovery Request messages. 4425 An example of this occurring is when many WTPs are powered on at the 4426 same time. 4428 If a Discovery Response message is not received after sending the 4429 maximum number of Discovery Request messages, the WTP enters the 4430 Sulking state and MUST wait for an interval equal to SilentInterval 4431 before sending further Discovery Request messages. 4433 Upon receiving a Discovery Request message, the AC will respond with 4434 a Discovery Response message sent to the address in the source 4435 address of the received Discovery Request message. Once a Discovery 4436 Response has been received, if the WTP decides to establish a session 4437 with the responding AC, it SHOULD perform an MTU discovery, using the 4438 process described in Section 3.5. 4440 It is possible for the AC to receive a cleartext Discovery Request 4441 message while a DTLS session is already active with the WTP. This is 4442 most likely the case if the WTP has rebooted, perhaps due to a 4443 software or power failure, but could also be caused by a DoS attack. 4444 In such cases, any WTP state, including the state machine instance, 4445 MUST NOT be cleared until another DTLS session has been successfully 4446 established, communicated via the DTLSSessionEstablished DTLS 4447 notification (see Section 2.3.2.2). 4449 The binding specific WTP Radio Information message element (see 4450 Section 2.1) is included in the Discovery Request message to 4451 advertise WTP support for one or more CAPWAP bindings. 4453 The Discovery Request message is sent by the WTP when in the 4454 Discovery State. The AC does not transmit this message. 4456 The following message elements MUST be included in the Discovery 4457 Request message: 4459 o Discovery Type, see Section 4.6.23 4461 o WTP Board Data, see Section 4.6.40 4463 o WTP Descriptor, see Section 4.6.41 4465 o WTP Frame Tunnel Mode, see Section 4.6.43 4467 o WTP MAC Type, see Section 4.6.46 4469 o WTP Radio Information message element(s)that the WTP supports; 4470 These are defined by the individual link layer CAPWAP Binding 4471 Protocols (see Section 2.1). 4473 The following message elements MAY be included in the Discovery 4474 Request message: 4476 o Vendor Specific Payload, see Section 4.6.39 4478 5.2. Discovery Response Message 4480 The Discovery Response message provides a mechanism for an AC to 4481 advertise its services to requesting WTPs. 4483 When a WTP receives a Discovery Response message, it MUST wait for an 4484 interval not less than DiscoveryInterval for receipt of additional 4485 Discovery Response messages. After the DiscoveryInterval elapses, 4486 the WTP enters the DTLS-Init state and selects one of the ACs that 4487 sent a Discovery Response message and send a DTLS Handshake to that 4488 AC. 4490 One or more binding specific WTP Radio Information message elements 4491 (see Section 2.1) are included in the Discovery Request message to 4492 advertise AC support for the CAPWAP bindings. The AC MAY include 4493 only the bindings it shares in common with the WTP, known through the 4494 WTP Radio Information message elements received in the Discovery 4495 Request message, or it MAY include all of the bindings supported. 4496 The WTP MAY use the supported bindings in its AC decision process. 4497 Note that if the WTP joins an AC that does not support a specific 4498 CAPWAP binding, service for that binding MUST NOT be provided by the 4499 WTP. 4501 The Discovery Response message is sent by the AC when in the Idle 4502 State. The WTP does not transmit this message. 4504 The following message elements MUST be included in the Discovery 4505 Response Message: 4507 o AC Descriptor, see Section 4.6.1 4509 o AC Name, see Section 4.6.4 4511 o WTP Radio Information message element(s)that the AC supports; 4512 These are defined by the individual link layer CAPWAP Binding 4513 Protocols (see Section 2.1 for more information). 4515 o One of the following message elements MUST be included in the 4516 Discovery Response Message: 4518 * CAPWAP Control IPv4 Address, see Section 4.6.10 4520 * CAPWAP Control IPv6 Address, see Section 4.6.11 4522 The following message elements MAY be included in the Discovery 4523 Response message: 4525 o Vendor Specific Payload, see Section 4.6.39 4527 5.3. Primary Discovery Request Message 4529 The Primary Discovery Request message is sent by the WTP to determine 4530 whether its preferred (or primary) AC is available. 4532 A Primary Discovery Request message is sent by a WTP when it has a 4533 primary AC configured, and is connected to another AC. This 4534 generally occurs as a result of a failover, and is used by the WTP as 4535 a means to discover when its primary AC becomes available. Since the 4536 WTP only has a single instance of the CAPWAP state machine, the 4537 Primary Discovery Request is sent by the WTP when in the Run State. 4538 The AC does not transmit this message. 4540 The frequency of the Primary Discovery Request messages should be no 4541 more often than the sending of the Echo Request message. 4543 Upon receipt of a Primary Discovery Request message, the AC responds 4544 with a Primary Discovery Response message sent to the address in the 4545 source address of the received Primary Discovery Request message. 4547 The following message elements MUST be included in the Primary 4548 Discovery Request message. 4550 o Discovery Type, see Section 4.6.23 4552 o WTP Board Data, see Section 4.6.40 4554 o WTP Descriptor, see Section 4.6.41 4556 o WTP Frame Tunnel Mode, see Section 4.6.43 4558 o WTP MAC Type, see Section 4.6.46 4560 o WTP Radio Information message element(s)that the WTP supports; 4561 These are defined by the individual link layer CAPWAP Binding 4562 Protocols (see Section 2.1 for more information). 4564 The following message elements MAY be included in the Primary 4565 Discovery Request message: 4567 o Vendor Specific Payload, see Section 4.6.39 4569 5.4. Primary Discovery Response 4571 The Primary Discovery Response message enables an AC to advertise its 4572 availability and services to requesting WTPs that are configured to 4573 have the AC as its primary AC. 4575 The Primary Discovery Response message is sent by an AC after 4576 receiving a Primary Discovery Request message. 4578 When a WTP receives a Primary Discovery Response message, it may 4579 establish a CAPWAP protocol connection to its primary AC, based on 4580 the configuration of the WTP Fallback Status message element on the 4581 WTP. 4583 The Primary Discovery Response message is sent by the AC when in the 4584 Idle State. The WTP does not transmit this message. 4586 The following message elements MUST be included in the Primary 4587 Discovery Response message. 4589 o AC Descriptor, see Section 4.6.1 4591 o AC Name, see Section 4.6.4 4593 o WTP Radio Information message element(s)that the AC supports; 4594 These are defined by the individual link layer CAPWAP Binding 4595 Protocols (see Section 2.1 for more information). 4597 One of the following message elements MUST be included in the 4598 Discovery Response Message: 4600 o CAPWAP Control IPv4 Address, see Section 4.6.10 4602 o CAPWAP Control IPv6 Address, see Section 4.6.11 4604 The following message elements MAY be included in the Primary 4605 Discovery Response message: 4607 o Vendor Specific Payload, see Section 4.6.39 4609 6. CAPWAP Join Operations 4611 The Join Request message is used by a WTP to request service from an 4612 AC after a DTLS connection is established to that AC. The Join 4613 Response message is used by the AC to indicate that it will or will 4614 not provide service. 4616 6.1. Join Request 4618 The Join Request message is used by a WTP to request service through 4619 the AC. A Join Request message is sent by a WTP after (optionally) 4620 receiving one or more Discovery Response messages, and completion of 4621 DTLS session establishment. When an AC receives a Join Request 4622 message it responds with a Join Response message. 4624 Upon completion of the DTLS handshake, and receiving the 4625 DTLSEstablished notification, the WTP sends the Join Request message 4626 to the AC. When the AC is notified of the DTLS session 4627 establishment, it does not clear the WaitDTLS timer until it has 4628 received the Join Request message, at which time it sends a Join 4629 Response message to the WTP, indicating success or failure. 4631 One or more WTP Radio Information message elements (see Section 2.1) 4632 are included in the Join Request to request service for the CAPWAP 4633 bindings by the AC. Including a binding that is unsupported by the 4634 AC will result in a failed Join Response. 4636 If the AC rejects the Join Request, it sends a Join Response message 4637 with a failure indication and initiates an abort of the DTLS session 4638 via the DTLSAbort command. 4640 If an invalid (i.e. malformed) Join Request message is received, the 4641 message MUST be silently discarded by the AC. No response is sent to 4642 the WTP. The AC SHOULD log this event. 4644 The Join Request is sent by the WTP when in the Join State. The AC 4645 does not transmit this message. 4647 The following message elements MUST be included in the Join Request 4648 message. 4650 o Location Data, see Section 4.6.31 4652 o WTP Board Data, see Section 4.6.40 4654 o WTP Descriptor, see Section 4.6.41 4655 o WTP Name, see Section 4.6.47 4657 o Session ID, see Section 4.6.37 4659 o WTP Frame Tunnel Mode, see Section 4.6.43 4661 o WTP MAC Type, see Section 4.6.46 4663 o WTP Radio Information message element(s)that the WTP supports; 4664 These are defined by the individual link layer CAPWAP Binding 4665 Protocols (see Section 2.1 for more information). 4667 At least one of the following message element MUST be included in the 4668 Join Request message. 4670 o WTP IPv4 IP Address, see Section 4.6.44 4672 o WTP IPv6 IP Address, see Section 4.6.45 4674 The following message element MAY be included in the Join Request 4675 message. 4677 o Maximum Message Length, see Section 4.6.32 4679 o WTP Reboot Statistics, see Section 4.6.50 4681 o WTP IPv4 IP Address, see Section 4.6.44 4683 o WTP IPv6 IP Address, see Section 4.6.45 4685 o Vendor Specific Payload, see Section 4.6.39 4687 6.2. Join Response 4689 The Join Response message is sent by the AC to indicate to a WTP that 4690 it is capable and willing to provide service to the WTP. 4692 The WTP, receiving a Join Response message, checks for success or 4693 failure. If the message indicates success, the WTP clears the 4694 WaitDTLS timer for the session and proceeds to the Configure state. 4696 If the WaitDTLS Timer expires prior to reception of the Join Response 4697 message, the WTP MUST terminate the handshake, deallocate session 4698 state and initiate the DTLSAbort command. 4700 If an invalid (malformed) Join Response message is received, the WTP 4701 SHOULD log an informative message detailing the error. This error 4702 MUST be treated in the same manner as AC non-responsiveness. The 4703 WaitDTLS timer will eventually expire, and the WTP MAY (if it is so 4704 configured) attempts to join a new AC. 4706 If one of the WTP Radio Information message elements (see 4707 Section 2.1) in the Join Request message requested support for a 4708 CAPWAP binding which the AC does not support, the AC sets the Result 4709 Code message element to "Binding Not Supported". 4711 The AC includes the Image Identifier message element to indicate the 4712 software version it expects the WTP to run. This information is used 4713 to determine whether the WTP MUST either change its currently running 4714 firmware image, or download a new version (see Section 9.1.1). 4716 The Join Response message is sent by the AC when in the Join State. 4717 The WTP does not transmit this message. 4719 The following message elements MAY be included in the Join Response 4720 message. 4722 o AC IPv4 List, see Section 4.6.2 4724 o AC IPv6 List, see Section 4.6.3 4726 o Image Identifier, see Section 4.6.28 4728 o Maximum Message Length, see Section 4.6.32 4730 o Vendor Specific Payload, see Section 4.6.39 4732 The following message elements MUST be included in the Join Response 4733 message. 4735 o Result Code, see Section 4.6.35 4737 o AC Descriptor, see Section 4.6.1 4739 o AC Name, see Section 4.6.4 4741 o WTP Radio Information message element(s)that the AC supports; 4742 These are defined by the individual link layer CAPWAP Binding 4743 Protocols (see Section 2.1). 4745 One of the following message elements MUST be included in the 4746 Discovery Response Message: 4748 o CAPWAP Control IPv4 Address, see Section 4.6.10 4749 o CAPWAP Control IPv6 Address, see Section 4.6.11 4751 7. Control Channel Management 4753 The Control Channel Management messages are used by the WTP and AC to 4754 maintain a control communication channel. CAPWAP control messages, 4755 such as the WTP Event Request message sent from the WTP to the AC 4756 indicate to the AC that the WTP is operational. When such control 4757 messages are not being sent, the Echo Request and Echo Response 4758 messages are used to maintain the control communication channel. 4760 7.1. Echo Request 4762 The Echo Request message is a keep-alive mechanism for CAPWAP control 4763 messages. 4765 Echo Request messages are sent periodically by a WTP in the Run state 4766 (see Section 2.3) to determine the state of the control connection 4767 between the WTP and the AC. The Echo Request message is sent by the 4768 WTP when the EchoInterval timer expires. 4770 The Echo Request message is sent by the WTP when in the Run State. 4771 The AC does not transmit this message. 4773 The following message elements MAY be included in the Echo Request 4774 message: 4776 o Vendor Specific Payload, see Section 4.6.39 4778 When an AC receives an Echo Request message it responds with an Echo 4779 Response message. 4781 7.2. Echo Response 4783 The Echo Response message acknowledges the Echo Request message. 4785 An Echo Response message is sent by an AC after receiving an Echo 4786 Request message. After transmitting the Echo Response message, the 4787 AC SHOULD reset its EchoInterval timer. If another Echo Request 4788 message or other control message is not received by the AC when the 4789 timer expires, the AC SHOULD consider the WTP to be no longer 4790 reachable. 4792 The Echo Response message is sent by the AC when in the Run State. 4793 The WTP does not transmit this message. 4795 The following message elements MAY be included in the Echo Response 4796 message: 4798 o Vendor Specific Payload, see Section 4.6.39 4800 When a WTP receives an Echo Response message it initializes the 4801 EchoInterval to the configured value. 4803 8. WTP Configuration Management 4805 WTP Configuration messages are used to exchange configuration 4806 information between the AC and the WTP. 4808 8.1. Configuration Consistency 4810 The CAPWAP protocol provides flexibility in how WTP configuration is 4811 managed. A WTP has two options: 4813 1. The WTP retains no configuration and accepts the configuration 4814 provided by the AC. 4816 2. The WTP retains the configuration of parameters provided by the AC 4817 that are non-default values. 4819 If the WTP opts to save configuration locally, the CAPWAP protocol 4820 state machine defines the Configure state, which allows for 4821 configuration exchange. In the Configure state, the WTP sends its 4822 current configuration overrides to the AC via the Configuration 4823 Status message. A configuration override is a non-default parameter. 4824 As an example, in the CAPWAP protocol, the default antenna 4825 configuration is internal omni antenna. A WTP that either has no 4826 internal antennas, or has been explicitly configured by the AC to use 4827 external antennas, sends its antenna configuration during the 4828 configure phase, allowing the AC to become aware of the WTP's current 4829 configuration. 4831 Once the WTP has provided its configuration to the AC, the AC sends 4832 its configuration to the WTP. This allows the WTP to receive 4833 configuration and policies from the AC. 4835 The AC maintains a copy of each active WTP configuration. There is 4836 no need for versioning or other means to identify configuration 4837 changes. If a WTP becomes inactive, the AC MAY delete the inactive 4838 WTP configuration. If a WTP fails, and connects to a new AC, the WTP 4839 provides its overridden configuration parameters, allowing the new AC 4840 to be aware of the WTP configuration. 4842 This model allows for resiliency in case of an AC failure, ensuring 4843 another AC can provide service to the WTP. A new AC would be 4844 automatically updated with WTP configuration changes, eliminating the 4845 need for inter-AC communication and the need for all ACs to be aware 4846 of the configuration of all WTPs in the network. 4848 Once the CAPWAP protocol enters the Run state, the WTPs begin to 4849 provide service. It is common for administrators to require that 4850 configuration changes be made while the network is operational. 4852 Therefore, the Configuration Update Request is sent by the AC to the 4853 WTP to make these changes at run-time. 4855 8.1.1. Configuration Flexibility 4857 The CAPWAP protocol provides the flexibility to configure and manage 4858 WTPs of varying design and functional characteristics. When a WTP 4859 first discovers an AC, it provides primary functional information 4860 relating to its type of MAC and to the nature of frames to be 4861 exchanged. The AC configures the WTP appropriately. The AC also 4862 establishes corresponding internal state for the WTP. 4864 8.2. Configuration Status 4866 The Configuration Status message is sent by a WTP to deliver its 4867 current configuration to the AC. 4869 The Configuration Status message carries binding specific message 4870 elements. Refer to the appropriate binding for the definition of 4871 this structure. 4873 When an AC receives a Configuration Status message it acts upon the 4874 content of the message and responds to the WTP with a Configuration 4875 Status Response message. 4877 The Configuration Status message includes multiple Radio 4878 Administrative State message elements, one for the WTP, and one for 4879 each radio in the WTP. 4881 The Configuration Status message is sent by the WTP when in the 4882 Configure State. The AC does not transmit this message. 4884 The following message elements MUST be included in the Configuration 4885 Status message. 4887 o AC Name, see Section 4.6.4 4889 o AC Name with Index, see Section 4.6.5 4891 o Radio Administrative State, see Section 4.6.33 4893 o Statistics Timer, see Section 4.6.38 4895 o WTP Reboot Statistics, see Section 4.6.50 4897 The following message elements MAY be included in the Configuration 4898 Status message. 4900 o WTP Static IP Address Information, see Section 4.6.51 4902 o Vendor Specific Payload, see Section 4.6.39 4904 8.3. Configuration Status Response 4906 The Configuration Status Response message is sent by an AC and 4907 provides a mechanism for the AC to override a WTP's requested 4908 configuration. 4910 A Configuration Status Response message is sent by an AC after 4911 receiving a Configuration Request message. 4913 The Configuration Status Response message carries binding specific 4914 message elements. Refer to the appropriate binding for the 4915 definition of this structure. 4917 When a WTP receives a Configuration Status Response message it acts 4918 upon the content of the message, as appropriate. If the 4919 Configuration Status Response message includes a Radio Operational 4920 State message element that causes a change in the operational state 4921 of one of the radios, the WTP transmits a Change State Event to the 4922 AC, as an acknowledgement of the change in state. 4924 The Configuration Status Response message is sent by the AC when in 4925 the Configure State. The WTP does not transmit this message. 4927 The following message elements MUST be included in the Configuration 4928 Status Response message. 4930 o AC IPv4 List, see Section 4.6.2 4932 o AC IPv6 List, see Section 4.6.3 4934 o CAPWAP Timers, see Section 4.6.14 4936 o Decryption Error Report Period, see Section 4.6.19 4938 o Idle Timeout, see Section 4.6.26 4940 o WTP Fallback, see Section 4.6.42 4942 The following message element MAY be included in the Configuration 4943 Status Response message. 4945 o WTP Static IP Address Information, see Section 4.6.51 4946 o Vendor Specific Payload, see Section 4.6.39 4948 8.4. Configuration Update Request 4950 Configuration Update Request messages are sent by the AC to provision 4951 the WTP while in the Run state. This is used to modify the 4952 configuration of the WTP while it is operational. 4954 When a WTP receives a Configuration Update Request message, it 4955 responds with a Configuration Update Response message, with a Result 4956 Code message element indicating the result of the configuration 4957 request. 4959 The AC includes the Image Identifier and Initiate Download message 4960 elements to force the WTP to update its firmware while in the Run 4961 state. The WTP MAY proceed to download the requested firmware if it 4962 determines the version specified in the Image Identifier message 4963 element is not in its non-volatile storage (see Section 9.1.1). 4965 The Configuration Update Request is sent by the AC when in the Run 4966 State. The WTP does not transmit this message. 4968 One or more of the following message elements MAY be included in the 4969 Configuration Update message. 4971 o AC Name with Index, see Section 4.6.5 4973 o AC Timestamp, see Section 4.6.6 4975 o Add MAC ACL Entry, see Section 4.6.7 4977 o Add Static MAC ACL Entry, see Section 4.6.9 4979 o CAPWAP Timers, see Section 4.6.14 4981 o Decryption Error Report Period, see Section 4.6.19 4983 o Delete MAC ACL Entry, see Section 4.6.20 4985 o Delete Static MAC ACL Entry, see Section 4.6.22 4987 o Idle Timeout, see Section 4.6.26 4989 o Location Data, see Section 4.6.31 4991 o Radio Administrative State, see Section 4.6.33 4992 o Statistics Timer, see Section 4.6.38 4994 o WTP Fallback, see Section 4.6.42 4996 o WTP Name, see Section 4.6.47 4998 o WTP Static IP Address Information, see Section 4.6.51 5000 o Image Identifier, see Section 4.6.28 5002 o Initiate Download, see Section 4.6.30 5004 o Vendor Specific Payload, see Section 4.6.39 5006 8.5. Configuration Update Response 5008 The Configuration Update Response message is the acknowledgement 5009 message for the Configuration Update Request message. 5011 The Configuration Update Response message is sent by a WTP after 5012 receiving a Configuration Update Request message. 5014 When an AC receives a Configuration Update Response message the 5015 result code indicates if the WTP successfully accepted the 5016 configuration. 5018 The Configuration Update Response message is sent by the WTP when in 5019 the Run State. The AC does not transmit this message. 5021 The following message element MUST be present in the Configuration 5022 Update message. 5024 Result Code, see Section 4.6.35 5026 The following message elements MAY be present in the Configuration 5027 Update Response message. 5029 o Radio Operational State, see Section 4.6.34 5031 o Vendor Specific Payload, see Section 4.6.39 5033 8.6. Change State Event Request 5035 The Change State Event Request message is used by the WTP for two 5036 main purposes: 5038 o When sent by the WTP following the reception of a Configuration 5039 Status Response message from the AC, the WTP uses the Change State 5040 Event Request message to provide an update on the WTP radio's 5041 operational state and to confirm that the configuration provided 5042 by the AC was successfully applied. 5044 o When sent during the Run state, the WTP uses the Change State 5045 Event Request message to notify the AC of an unexpected change in 5046 the WTP's radio operational state. 5048 When an AC receives a Change State Event Request message it responds 5049 with a Change State Event Response message and modifies its data 5050 structures for the WTP as needed. The AC MAY decide not to provide 5051 service to the WTP if it receives an error, based on local policy, 5052 and to transition to the Reset state. 5054 The Change State Event Request message is sent by a WTP to 5055 acknowledge or report an error condition to the AC for a requested 5056 configuration in the Configuration Status Response message. The 5057 Change State Event Request message includes the Result Code message 5058 element, which indicates whether the configuration was successfully 5059 applied. If the WTP is unable to apply a specific configuration 5060 request, it indicates the failure by including one or more Returned 5061 Message Element message elements (see Section 4.6.36). 5063 The Change State Event Request message is sent by the WTP in the 5064 Configure or Run State. The AC does not transmit this message. 5066 The WTP MAY save its configuration to persistent storage prior to 5067 transmitting the response. However, this is implementation specific 5068 and is not required. 5070 The following message elements MUST be present in the Change State 5071 Event Request message. 5073 o Radio Operational State, see Section 4.6.34 5075 o Result Code, see Section 4.6.35 5077 One or more of the following message elements MAY be present in the 5078 Change State Event Request message. 5080 o Returned Message Element(s), see Section 4.6.36 5082 o Vendor Specific Payload, see Section 4.6.39 5084 8.7. Change State Event Response 5086 The Change State Event Response message acknowledges the Change State 5087 Event Request message. 5089 A Change State Event Response message is sent by an AC in response to 5090 a Change State Event Request message. 5092 The Change State Event Response message is sent by the AC when in the 5093 Configure or Run state. The WTP does not transmit this message. 5095 The following message elements MAY be included in the Change State 5096 Event Response message: 5098 o Vendor Specific Payload, see Section 4.6.39 5100 The WTP does not take any action upon receipt of the Change State 5101 Event Response message. 5103 8.8. Clear Configuration Request 5105 The Clear Configuration Request message is used to reset the WTP 5106 configuration. 5108 The Clear Configuration Request message is sent by an AC to request 5109 that a WTP reset its configuration to the manufacturing default 5110 configuration. The Clear Config Request message is sent while in the 5111 Run state. 5113 The Clear Configuration Request is sent by the AC when in the Run 5114 State. The WTP does not transmit this message. 5116 The following message elements MAY be included in the Clear 5117 Configuration Request message: 5119 o Vendor Specific Payload, see Section 4.6.39 5121 When a WTP receives a Clear Configuration Request message it resets 5122 its configuration to the manufacturing default configuration. 5124 8.9. Clear Configuration Response 5126 The Clear Configuration Response message is sent by the WTP after 5127 receiving a Clear Configuration Request message and resetting its 5128 configuration parameters to the manufacturing default values. 5130 The Clear Configuration Response is sent by the WTP when in the Run 5131 State. The AC does not transmit this message. 5133 The Clear Configuration Request message MUST include the following 5134 message element. 5136 o Result Code, see Section 4.6.35 5138 The following message elements MAY be included in the Clear 5139 Configuration Request message: 5141 o Vendor Specific Payload, see Section 4.6.39 5143 9. Device Management Operations 5145 This section defines CAPWAP operations responsible for debugging, 5146 gathering statistics, logging, and firmware management. 5148 9.1. Firmware Management 5150 This section describes the firmware download procedures used by the 5151 CAPWAP protocol. Firmware download can occur during the Image Data 5152 or Run state. 5154 Figure 4 provides an example of a WTP that performs a firmware 5155 upgrade while in the Image Data state. In this example, the WTP does 5156 not already have the requested firmware (Image Identifier = x), and 5157 downloads the image from the AC. 5159 WTP AC 5161 Join Request 5162 --------------------------------------------------------> 5164 Join Response (Image Identifier = x) 5165 <------------------------------------------------------ 5167 Image Data Request (Image Identifier = x) 5168 --------------------------------------------------------> 5170 Image Data Response (Result Code = Success, 5171 Image Information = {size,hash}, 5172 Initiate Download) 5173 <------------------------------------------------------ 5175 Image Data Request (Image Data = Data) 5176 <------------------------------------------------------ 5178 Image Data Response (Result Code = Success) 5179 --------------------------------------------------------> 5181 ..... 5183 Image Data Request (Image Data = EOF) 5184 <------------------------------------------------------ 5186 Image Data Response (Result Code = Success) 5187 --------------------------------------------------------> 5189 (WTP enters the Reset State) 5191 Figure 4: WTP Firmware Download Case 1 5193 Figure 5 provides an example in which the WTP has the image specified 5194 by the AC in its non-volative storage. The WTP opts to NOT download 5195 the firmware and immediately reset. 5197 WTP AC 5199 Join Request 5200 --------------------------------------------------------> 5202 Join Response (Image Identifier = x) 5203 <------------------------------------------------------ 5205 (WTP enters the Reset State) 5207 Figure 5: WTP Firmware Download Case 2 5209 Figure 6 provides an example of a WTP that performs a firmware 5210 upgrade while in the Run state. This mode of firmware upgrade allows 5211 the WTP to download its image while continuing to provide service. 5212 The WTP will not automatically reset until it is notified by the AC, 5213 with a Reset Request message. 5215 WTP AC 5217 Configuration Update Request (Image Identifier = x) 5218 <------------------------------------------------------ 5220 Configuration Update Response (Result Code = Success) 5221 --------------------------------------------------------> 5223 Image Data Request (Image Identifier = x) 5224 --------------------------------------------------------> 5226 Image Data Response (Result Code = Success, 5227 Image Information = {size,hash}, 5228 Initiate Download) 5229 <------------------------------------------------------ 5231 Image Data Request (Image Data = Data) 5232 <------------------------------------------------------ 5234 Image Data Response (Result Code = Success) 5235 --------------------------------------------------------> 5237 ..... 5239 Image Data Request (Image Data = EOF) 5240 <------------------------------------------------------ 5242 Image Data Response (Result Code = Success) 5243 --------------------------------------------------------> 5245 ..... 5247 (administratively requested reboot request) 5248 Reset Request (Image Identifier = x) 5249 <------------------------------------------------------ 5251 Reset Response (Result Code = Success) 5252 --------------------------------------------------------> 5254 Figure 6: WTP Firmware Download Case 3 5256 Figure 7 provides another example of the firmware download while in 5257 the Run state. In this example, the WTP already has the image 5258 specified by the AC in its non-volative storage. The WTP opts to NOT 5259 download the firmware. The WTP resets upon receipt of a Reset 5260 Request message from the AC. 5262 WTP AC 5264 Configuration Update Request (Image Identifier = x, 5265 Image Information = {size,hash}, 5266 Initiate Download) 5267 <------------------------------------------------------ 5269 Configuration Update Response (Result Code = Already Have Image) 5270 --------------------------------------------------------> 5272 ..... 5274 (administratively requested reboot request) 5275 Reset Request (Image Identifier = x) 5276 <------------------------------------------------------ 5278 Reset Response (Result Code = Success) 5279 --------------------------------------------------------> 5281 Figure 7: WTP Firmware Download Case 4 5283 9.1.1. Image Data Request 5285 The Image Data Request message is used to update firmware on the WTP. 5286 This message and its companion Response message are used by the AC to 5287 ensure that the image being run on each WTP is appropriate. 5289 Image Data Request messages are exchanged between the WTP and the AC 5290 to download a new firmware image to the WTP. When a WTP or AC 5291 receives an Image Data Request message it responds with an Image Data 5292 Response message. The message elements contained within the Image 5293 Data Request message are required to determine the intent of the 5294 request. 5296 The decision that new firmware is to be downloaded to the WTP can 5297 occur in one of two ways: 5299 When the WTP joins the AC, the Join Response message includes the 5300 Image Identifier message element, which informs the WTP of the 5301 firmware it is expected to run. if the WTP does not currently have 5302 the requested firmware version, it transmits an Image Data Request 5303 message, with the appropriate Image Identifier message element. 5304 If the WTP already has the requested firmware, it simply resets. 5306 Once the WTP is in the Run state, it is possible for the AC to 5307 cause the WTP to initiate a firmware download by sending a 5308 Configuration Update Request message with the Initiate Download 5309 and Image Identifier message elements. The WTP then transmits the 5310 Image Data Request message, which includes the Image Identifier 5311 message element to start the download process. Note that when the 5312 firmware is downloaded in this way, the WTP does not automatically 5313 reset after the download is complete. The WTP will only reset 5314 when it receives a Reset Request message from the AC. If the WTP 5315 already had the requested firmware version in its non-volatile 5316 storage, the WTP does not transmit the Image Data Request message 5317 and responds with a Configuration Update Response message with the 5318 Result Code set to Image Already Present. 5320 Regardless of how the download was initiated, once the AC receives an 5321 Image Data Request message with the Image Identifier message element, 5322 it begins the transfer process by transmitting an Image Data Request 5323 message that includes the Image Data message element. This continues 5324 until the firmware image has been transferred. 5326 The Image Data Request message is sent by the WTP or the AC when in 5327 the Image Data or Run State. 5329 The following message elements MAY be included in the Image Data 5330 Request message. 5332 o Image Data, see Section 4.6.27 5334 o Image Identifier, see Section 4.6.28 5336 o Vendor Specific Payload, see Section 4.6.39 5338 9.1.2. Image Data Response 5340 The Image Data Response message acknowledges the Image Data Request 5341 message. 5343 An Image Data Response message is sent in response to a received 5344 Image Data Request message. Its purpose is to acknowledge the 5345 receipt of the Image Data Request message. The Result Code is 5346 included to indicate whether a previously sent Image Data Request 5347 message was invalid. 5349 The Image Data Response message is sent by the WTP or the AC when in 5350 the Image Data or Run State. 5352 The following message element MUST be included in the Image Data 5353 Response message. 5355 o Result Code, see Section 4.6.35 5357 The following message elements MAY be included in the Image Data 5358 Response message. 5360 o Image Information, see Section 4.6.29 5362 o Initiate Download, see Section 4.6.30 5364 o Vendor Specific Payload, see Section 4.6.39 5366 Upon receiving an Image Data Response message indicating an error, 5367 the WTP MAY retransmit a previous Image Data Request message, or 5368 abandon the firmware download to the WTP by transitioning to the 5369 Reset state. 5371 9.2. Reset Request 5373 The Reset Request message is used to cause a WTP to reboot. 5375 A Reset Request message is sent by an AC to cause a WTP to 5376 reinitialize its operation. 5378 The Reset Request is sent by the AC when in the Run State. The WTP 5379 does not transmit this message. 5381 The following message elements MUST be included in the Reset Request 5382 message. 5384 o Image Identifier, see Section 4.6.28 5386 The following message elements MAY be included in the Reset Request 5387 message: 5389 o Vendor Specific Payload, see Section 4.6.39 5391 When a WTP receives a Reset Request message, it responds with a Reset 5392 Response message indicating success and then reinitialize itself. If 5393 the WTP is unable to write to its non-volatile storage, to ensure 5394 that it runs the requested software version indicated in the Image 5395 Identifier message element, it MAY send the appropriate Result Code 5396 message element, but MUST reboot. If the WTP is unable to reset, 5397 including a hardware reset, it sends a Reset Response message to the 5398 AC with a Result Code message element indicating failure. The AC no 5399 longer provides service to the WTP. 5401 9.3. Reset Response 5403 The Reset Response message acknowledges the Reset Request message. 5405 A Reset Response message is sent by the WTP after receiving a Reset 5406 Request message. 5408 The Reset Response is sent by the WTP when in the Run State. The AC 5409 does not transmit this message. 5411 The following message element MAY be included in the Reset Response 5412 message. 5414 o Result Code, see Section 4.6.35 5416 o Vendor Specific Payload, see Section 4.6.39 5418 When an AC receives a successful Reset Response message, it is 5419 notified that the WTP will reinitialize its operation. An AC that 5420 receives a Reset Response message indicating failure may opt to no 5421 longer provide service to the WTP. 5423 9.4. WTP Event Request 5425 The WTP Event Request message is used by a WTP to send information to 5426 its AC. The WTP Event Request message MAY be sent periodically, or 5427 sent in response to an asynchronous event on the WTP. For example, a 5428 WTP MAY collect statistics and use the WTP Event Request message to 5429 transmit the statistics to the AC. 5431 When an AC receives a WTP Event Request message it will respond with 5432 a WTP Event Response message. 5434 The presence of the Delete Station message element is used by the WTP 5435 to inform the AC that it is no longer providing service to the 5436 station. This could be the result of an Idle Timeout (see 5437 Section 4.6.26), due to resource shortages, or some other reason. 5439 The WTP Event Request message is sent by the WTP when in the Run 5440 State. The AC does not transmit this message. 5442 The WTP Event Request message MUST contain one of the message 5443 elements listed below, or a message element that is defined for a 5444 specific wireless technology. More than one of each message element 5445 listed MAY be included in the WTP Event Request message. 5447 o Decryption Error Report, see Section 4.6.18 5449 o Duplicate IPv4 Address, see Section 4.6.24 5451 o Duplicate IPv6 Address, see Section 4.6.25 5452 o WTP Operational Statistics, see Section 4.6.48 5454 o WTP Radio Statistics, see Section 4.6.49 5456 o WTP Reboot Statistics, see Section 4.6.50 5458 o Delete Station, see Section 4.6.21 5460 o Vendor Specific Payload, see Section 4.6.39 5462 9.5. WTP Event Response 5464 The WTP Event Response message acknowledges receipt of the WTP Event 5465 Request message. 5467 A WTP Event Response message is sent by an AC after receiving a WTP 5468 Event Request message. 5470 The WTP Event Response message is sent by the AC when in the Run 5471 State. The WTP does not transmit this message. 5473 The following message elements MAY be included in the WTP Event 5474 Response message: 5476 o Vendor Specific Payload, see Section 4.6.39 5478 9.6. Data Transfer Request 5480 The Data Transfer Request message is used to deliver debug 5481 information from the WTP to the AC. 5483 Data Transfer Request messages are sent by the WTP to the AC when the 5484 WTP determines that it has important information to send to the AC. 5485 For instance, if the WTP detects that its previous reboot was caused 5486 by a system crash, it can send the crash file to the AC. The remote 5487 debugger function in the WTP also uses the Data Transfer Request 5488 message to send console output to the AC for debugging purposes. 5490 When the AC receives a Data Transfer Request message it responds to 5491 the WTP with a Data Transfer Response message. The AC MAY log the 5492 information received. 5494 The Data Transfer Request message is sent by the WTP when in the Run 5495 State. The AC does not transmit this message. 5497 The Data Transfer Request message MUST contain one of the message 5498 elements listed below. 5500 o Data Transfer Data, see Section 4.6.16 5502 o Data Transfer Mode, see Section 4.6.17 5504 The following message elements MAY be included in the Data Transfer 5505 Request message: 5507 o Vendor Specific Payload, see Section 4.6.39 5509 9.7. Data Transfer Response 5511 The Data Transfer Response message acknowledges the Data Transfer 5512 Request message. 5514 A Data Transfer Response message is sent in response to a received 5515 Data Transfer Request message. Its purpose is to acknowledge receipt 5516 of the Data Transfer Request message. 5518 The Data Transfer Response message is sent by the AC when in the Run 5519 State. The WTP does not transmit this message. 5521 The following message elements MAY be included in the Data Transfer 5522 Response message: 5524 o Vendor Specific Payload, see Section 4.6.39 5526 Upon receipt of a Data Transfer Response message, the WTP transmits 5527 more information, if more information is available. 5529 10. Station Session Management 5531 Messages in this section are used by the AC to create, modify or 5532 delete station session state on the WTPs. 5534 10.1. Station Configuration Request 5536 The Station Configuration Request message is used to create, modify 5537 or delete station session state on a WTP. The message is sent by the 5538 AC to the WTP, and MAY contain one or more message elements. The 5539 message elements for this CAPWAP control message include information 5540 that is generally highly technology specific. Refer to the 5541 appropriate binding document for definitions of the messages elements 5542 that are included in this control message. 5544 The Station Configuration Request message is sent by the AC when in 5545 the Run State. The WTP does not transmit this message. 5547 The following CAPWAP Control message elements MAY be included in the 5548 Station Configuration Request message. More than one of each message 5549 element listed MAY be included in the Station Configuration Request 5550 message. 5552 o Add Station, see Section 4.6.8 5554 o Delete Station, see Section 4.6.21 5556 o Vendor Specific Payload, see Section 4.6.39 5558 10.2. Station Configuration Response 5560 The Station Configuration Response message is used to acknowledge a 5561 previously received Station Configuration Request message. 5563 The Station Configuration Response message is sent by the WTP when in 5564 the Run State. The AC does not transmit this message. 5566 The following message element MUST be present in the Station 5567 Configuration Response message. 5569 o Result Code, see Section 4.6.35 5571 The following message elements MAY be included in the Station 5572 Configuration Response message: 5574 o Vendor Specific Payload, see Section 4.6.39 5576 The Result Code message element indicates that the requested 5577 configuration was successfully applied, or that an error related to 5578 processing of the Station Configuration Request message occurred on 5579 the WTP. 5581 11. NAT Considerations 5583 There are three specific situations in which a NAT deployment may be 5584 used in conjunction with a CAPWAP-enabled deployment. The first 5585 consists of a configuration in which a single WTP is behind a NAT 5586 system. Since all communication is initiated by the WTP, and all 5587 communication is performed over IP using two UDP ports, the protocol 5588 easily traverses NAT systems in this configuration. 5590 In the second case, two or more WTPs are deployed behind the same NAT 5591 system. Here, the AC would receive multiple connection requests from 5592 the same IP address, and cannot differentiate the originating WTP of 5593 the connection requests. The CAPWAP Data Check state, which 5594 establishes the data plane connection and communicates the Data 5595 Keepalive, includes the Session Identifier message element, which is 5596 used to bind the control and data plane. Use of the Session 5597 Identifier message element enables the AC to match the control and 5598 data plane flows from multiple WTPs behind the same NAT system 5599 (multiple WTPs sharing the same IP address). 5601 In the third configuration, the AC is deployed behind a NAT. Two 5602 issues exist in this situation. First, an AC communicates its 5603 interfaces and corresponding WTP load using the CAPWAP Control IPv4 5604 Address and CAPWAP Control IPv6 Address message elements. This 5605 message element is mandatory, but contains invalid information if a 5606 middlebox is present between the AC and WTP. The WTP MUST NOT 5607 utilize the information in these message elements if it detects a NAT 5608 (as described in the CAPWAP Transport Protocol message element). 5609 Note this would disable the load balancing capabilities of the CAPWAP 5610 protocol. Alternatively, the AC could have a configured NAT'ed 5611 address, which it would include in either of the two control address 5612 message elements. 5614 The CAPWAP protocol allows for all of the AC identities supporting a 5615 group of WTPs to be communicated through the AC List message element. 5616 This feature MUST be ignored by the WTP when it detects the AC is 5617 behind a middlebox. 5619 The CAPWAP protocol allows an AC to configure a static IP address on 5620 a WTP using the WTP Static IP Address Information message element. 5621 This message element SHOULD NOT be used in NAT'ed environments, 5622 unless the administrator is familiar with the internal IP addressing 5623 scheme within the WTP's private network, and does not rely on the 5624 public address seen by the AC. 5626 When a WTP detects the duplicate address condition, it generates a 5627 message to the AC, which includes the Duplicate IP Address message 5628 element. The IP Address embedded within this message element is 5629 different from the public IP address seen by the AC. 5631 12. Security Considerations 5633 This section describes security considerations for the CAPWAP 5634 protocol. It also provides security recommendations for protocols 5635 used in conjunction with CAPWAP. 5637 12.1. CAPWAP Security 5639 As it is currently specified, the CAPWAP protocol sits between the 5640 security mechanisms specified by the wireless link layer protocol 5641 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 5642 between the STA and WTP using a series of preestablished trust 5643 relationships: 5645 STA WTP AC AAA 5646 ============================================== 5648 DTLS Cred AAA Cred 5649 <------------><-------------> 5651 EAP Credential 5652 <------------------------------------------> 5654 wireless link layer 5655 (e.g.802.11 PTK) 5656 <--------------> or 5657 <---------------------------> 5658 (derived) 5660 Within CAPWAP, DTLS is used to secure the link between the WTP and 5661 AC. In addition to securing control messages, it's also a link in 5662 this chain of trust for establishing link layer keys. Consequently, 5663 much rests on the security of DTLS. 5665 In some CAPWAP deployment scenarios, there are two channels between 5666 the WTP and AC: the control channel, carrying CAPWAP control 5667 messages, and the data channel, over which client data packets are 5668 tunneled between the AC and WTP. Typically, the control channel is 5669 secured by DTLS, while the data channel is not. 5671 The use of parallel protected and unprotected channels deserves 5672 special consideration, but does not create a threat. There are two 5673 potential concerns: attempting to convert protected data into un- 5674 protected data and attempting to convert un-protected data into 5675 protected data. These concerns are addressed below. 5677 12.1.1. Converting Protected Data into Unprotected Data 5679 Since CAPWAP does not support authentication-only ciphers (i.e. all 5680 supported ciphersuites include encryption and authentication), it is 5681 not possible to convert protected data into unprotected data. Since 5682 encrypted data is (ideally) indistinguishable from random data, the 5683 probability of an encrypted packet passing for a well-formed packet 5684 is effectively zero. 5686 12.1.2. Converting Unprotected Data into Protected Data (Insertion) 5688 The use of message authentication makes it impossible for the 5689 attacker to forge protected records. This makes conversion of 5690 unprotected records to protected records impossible. 5692 12.1.3. Deletion of Protected Records 5694 An attacker could remove protected records from the stream, though 5695 not undetectably so, due the built-in reliability of the underlying 5696 CAPWAP protocol. In the worst case, the attacker would remove the 5697 same record repeatedly, resulting in a CAPWAP session timeout and 5698 restart. This is effectively a DoS attack, and could be accomplished 5699 by a man in the middle regardless of the CAPWAP protocol security 5700 mechanisms chosen. 5702 12.1.4. Insertion of Unprotected Records 5704 An attacker could inject packets into the unprotected channel, but 5705 this may become evident if sequence number desynchronization occurs 5706 as a result. Only if the attacker is a MiM can packets be inserted 5707 undetectably. This is a consequence of that channel's lack of 5708 protection, and not a new threat resulting from the CAPWAP security 5709 mechanism. 5711 12.2. Session ID Security 5713 Since DTLS does not export a unique session identifier, there can be 5714 no explicit protocol binding between the DTLS layer and CAPWAP layer. 5715 As a result, implementations MUST provide a mechanism for performing 5716 this binding. For example, an AC MUST NOT associate decrypted DTLS 5717 control packets with a particular WTP session based solely on the 5718 Session ID in the packet header. Instead, identification should be 5719 done based on which DTLS session decrypted the packet. Otherwise one 5720 authenticated WTP could spoof another authenticated WTP by altering 5721 the Session ID in the encrypted CAPWAP header. 5723 It should be noted that when the CAPWAP data channel is unencrypted, 5724 the WTP Session ID is exposed and possibly known to adversaries and 5725 other WTPs. This would allow the forgery of the source of data- 5726 channel traffic. This, however, should not be a surprise for 5727 unencrypted data channels. When the data channel is encrypted, the 5728 Session ID is not exposed, and therefore can safely be used to 5729 associate a data and control channel. The 64-bit length of the 5730 Session ID mitigates online guessing attacks where an adversarial, 5731 authenticated WTP tries to correlate his own data channel with 5732 another WTP's control channel. Note that for encrypted data 5733 channels, the Session ID should only be used for correlation for the 5734 first packet immediately after the initial DTLS handshake. Future 5735 correlation should instead be done via identification of a packet's 5736 DTLS session. 5738 12.3. Discovery or DTLS Setup Attacks 5740 Since the Discovery Request messages are sent in the clear, it is 5741 important that AC implementations NOT assume that receiving a 5742 Discovery Request message from a WTP implies that the WTP has 5743 rebooted, and consequently tear down any active DTLS sessions. 5744 Discovery Request messages can easily be spoofed by malicious 5745 devices, so it is important that the AC maintain two separate sets of 5746 states for the WTP until the DTLSSessionEstablished notification is 5747 received, indicating that the WTP was authenticated. Once a new DTLS 5748 session is successfully established, any state referring to the old 5749 session can be cleared. 5751 Similarly, entering the DTLS Setup phase SHOULD NOT assume that the 5752 WTP has reset, and therefore should not discard active state until 5753 the DTLS session has been successfully established. While the 5754 HelloVerifyRequest provides some protection against denial of service 5755 (DoS) attacks on the AC, an adversary capable of receiving packets at 5756 a valid address (or a malfunctioning or misconfigured WTP) may 5757 repeatedly attempt DTLS handshakes with the AC, potentially creating 5758 a resource shortage. If either the FailedDTLSSessionCount or the 5759 FailedDTLSAuthFailCount counter reaches the value of 5760 MaxFailedDTLSSessionRetry variable (see Section 4.8), implementations 5761 MAY choose to rate-limit new DTLS handshakes for some period of time. 5762 It is RECOMMENDED that implementations choosing to implement rate 5763 limiting use a random discard technique, rather than mimicking the 5764 WTP's sulking behavior. This will ensure that messages from valid 5765 WTPs will have some probability of eliciting a response, even in the 5766 face of a significant DoS attack. 5768 Some CAPWAP implementations may wish to restrict the DTLS setup 5769 process to only those peers that have been configured in the access 5770 control list, authorizing only those clients to initiate a DTLS 5771 handshake. Note that the impact of this on mitigating denial of 5772 service attacks against the DTLS layer is minimal, because DTLS 5773 already uses client-side cookies to minimize processor consumption 5774 attacks. 5776 12.4. Interference with a DTLS Session 5778 If a WTP or AC repeatedly receives packets which fail DTLS 5779 authentication or decryption, this could indicate a DTLS 5780 desynchronization between the AC and WTP, a link prone to 5781 undetectable bit errors, or an attacker trying to disrupt a DTLS 5782 session. 5784 In the state machine (section 2.3), transitions to the DTLS tear down 5785 state can be triggered by frequently receiving DTLS packets with 5786 authentication or decryption errors. The threshold or technique for 5787 deciding when to move to the tear down state should be chosen 5788 carefully. Being able to easily transition to DTLS TD allows easy 5789 detection of malfunctioning devices, but allows for denial of service 5790 attacks. Making it difficult to transition to DTLS TD prevents 5791 denial of service attacks, but makes it more difficult to detect and 5792 reset a malfunctioning session. Implementers should set this policy 5793 with care. 5795 12.5. CAPWAP Pre-Provisioning 5797 In order for CAPWAP to establish a secure communication with a peer, 5798 some level of pre-provisioning on both the WTP and AC is necessary. 5799 This section will detail the minimal number of configuration 5800 parameters. 5802 When using preshared keys, it is necessary to configure the preshared 5803 key for each possible peer with which a DTLS session may be 5804 established. To support this mode of operation, one or more entries 5805 of the following table may be configured on either the AC or WTP: 5807 o Identity: The identity of the peering AC or WTP. This format MAY 5808 be either in the form of an IP address or host name (the latter of 5809 which needs to be resolved to an IP address using DNS). 5811 o Key: The pre-shared key for use with the peer when establishing 5812 the DTLS session (see Section 12.6 for more information). 5814 o Key Identifier: The pre-shared key identifier, as described in RFC 5815 4279 [RFC4279]. 5817 When using certificates, the following items need to be pre- 5818 provisioned: 5820 o Device Certificate: The local device's certificate (see 5821 Section 12.7 for more information) 5823 o Trust Anchor: Trusted root certificate chain used to validate any 5824 certificate received from CAPWAP peers. Note that one or more 5825 root certificate MAY be configured on a given device. 5827 Regardless of the authentication method, the following items need to 5828 be pre-provisioned: 5830 o Access Control List: The access control list table contains the 5831 identities of one or more CAPWAP peers, along with a rule. The 5832 rule is used to determine whether communication with the peer is 5833 permitted (see Section 2.4.4.3 for more information). 5835 12.6. Use of Preshared Keys in CAPWAP 5837 While use of preshared keys may provide deployment and provisioning 5838 advantages not found in public key based deployments, it also 5839 introduces a number of operational and security concerns. In 5840 particular, because the keys must typically be entered manually, it 5841 is common for people to base them on memorable words or phrases. 5842 These are referred to as "low entropy passwords/passphrases". 5844 Use of low-entropy preshared keys, coupled with the fact that the 5845 keys are often not frequently updated, tends to significantly 5846 increase exposure. For these reasons, the following recommendations 5847 are made: 5849 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 5850 SHOULD have a unique PSK. Since WTPs will likely be widely 5851 deployed, their physical security is not guaranteed. If PSKs are 5852 not unique for each WTP, key reuse would allow the compromise of 5853 one WTP to result in the compromise of others 5855 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 5857 o It is RECOMMENDED that implementations that allow the 5858 administrator to manually configure the PSK also provide a 5859 capability for generation of new random PSKs, taking RFC 4086 5860 [RFC4086] into account. 5862 o Preshared keys SHOULD be periodically updated. Implementations 5863 MAY facilitate this by providing an administrative interface for 5864 automatic key generation and periodic update, or it MAY be 5865 accomplished manually instead. 5867 Every pairwise combination of WTP and AC on the network SHOULD have a 5868 unique PSK. This prevents the domino effect (see Guidance for AAA 5869 Key Management [I-D.housley-aaa-key-mgmt]). If PSKs are tied to 5870 specific WTPs, then knowledge of the PSK implies a binding to a 5871 specified identity that can be authorized. 5873 If PSKs are shared, this binding between device and identity is no 5874 longer possible. Compromise of one WTP can yield compromise of 5875 another WTP, violating the CAPWAP security hierarchy. Consequently, 5876 sharing keys between WTPs is NOT RECOMMENDED. 5878 12.7. Use of Certificates in CAPWAP 5880 For public-key-based DTLS deployments, each device SHOULD have unique 5881 credentials, with an extended key usage authorizing the device to act 5882 as either a WTP or AC. If devices do not have unique credentials, it 5883 is possible that by compromising one device, any other device using 5884 the same credential may also be considered to be compromised. 5886 Certificate validation involves checking a large variety of things. 5887 Since the necessary things to validate are often environment- 5888 specific, many are beyond the scope of this document. In this 5889 section, we provide some basic guidance on certificate validation. 5891 Each device is responsible for authenticating and authorizing devices 5892 with which they communicate. Authentication entails validation of 5893 the chain of trust leading to the peer certificate, followed by the 5894 peer certificate itself. Implementations SHOULD also provide a 5895 secure method for verifying that the credential in question has not 5896 been revoked. 5898 Note that if the WTP relies on the AC for network connectivity (e.g. 5899 the AC is a layer 2 switch to which the WTP is directly connected), 5900 the WTP may not be able to contact an OCSP server or otherwise obtain 5901 an up to date CRL if a compromised AC doesn't explicitly permit this. 5902 This cannot be avoided, except through effective physical security 5903 and monitoring measures at the AC. 5905 Proper validation of certificates typically requires checking to 5906 ensure the certificate has not yet expired. If devices have a real- 5907 time clock, they SHOULD verify the certificate validity dates. If no 5908 real-time clock is available, the device SHOULD make a best-effort 5909 attempt to validate the certificate validity dates through other 5910 means. Failure to check a certificate's temporal validity can make a 5911 device vulnerable to man-in-the-middle attacks launched using 5912 compromised, expired certificates, and therefore devices should make 5913 every effort to perform this validation. 5915 12.8. AAA Security 5917 The AAA protocol is used to distribute EAP keys to the ACs, and 5918 consequently its security is important to the overall system 5919 security. When used with TLS or IPsec, security guidelines specified 5920 in RFC 3539 [RFC3539] SHOULD be followed. 5922 In general, the link between the AC and AAA server SHOULD be secured 5923 using a strong ciphersuite keyed with mutually authenticated session 5924 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 5925 secret authentication as it is often vulnerable to dictionary 5926 attacks, but rather SHOULD use stronger underlying security 5927 mechanisms. 5929 13. Management Considerations 5931 The CAPWAP protocol assumes that it is the only configuration 5932 interface to the WTP to configure parameters that are specified in 5933 the CAPWAP specifications. While the use of a separate management 5934 protocol MAY be used for the purposes of monitoring the WTP directly, 5935 configuring the WTP through a separate management interface is not 5936 recommended. Configuring the WTP through a separate protocol, such 5937 as via a CLI or SNMP, could lead to the AC state being out of sync 5938 with the WTP. 5940 14. Transport Considerations 5942 The CAPWAP WG carefully considered the congestion control 5943 requirements of the CAPWAP protocol, both for the CAPWAP control and 5944 data channels. 5946 CAPWAP specifies a single-threaded command/response protocol to be 5947 used on the control channel, and we have specified that an 5948 exponential back-off algorithm should be used when commands are 5949 retransmitted. When CAPWAP runs in its default mode (Local MAC), the 5950 control channel is the only CAPWAP channel. 5952 However, CAPWAP can also be run in Split MAC mode, in which case 5953 there will be a DTLS-encrypted data channel between each WTP and the 5954 AC. The WG discussed various options for providing congestion 5955 control on this channel. However, due to performance problems with 5956 TCP when it is run over another congestion control mechanism and the 5957 fact that the vast majority of traffic run over the CAPWAP data 5958 channel is likely to be congestion-controlled IP traffic, the CAPWAP 5959 WG felt that specifying a congestion control mechanism for the CAPWAP 5960 data channel would be more likely to cause problems than to resolve 5961 any. 5963 Because there is no congestion control mechanism specified for the 5964 CAPWAP data channel, it is recommended that non-congestion-controlled 5965 traffic not be tunneled over CAPWAP. When a significant amount of 5966 non-congestion-controlled traffic is expected to be present on a 5967 WLAN, the CAPWAP connection between the AC and the WTP for that LAN 5968 should be configured to remain in Local MAC mode with Distribution 5969 function at the WTP. 5971 The lock step nature of the CAPWAP protocol's control channel can 5972 cause the firmware download process to take some time, depending upon 5973 the RTT. This is not expected to be a problem since the CAPWAP 5974 protocol allows firmware to be downloaded while the WTP provides 5975 service to wireless clients/devices. 5977 It is necessary for the WTP and AC to configure their MTU based on 5978 the capabilities of the path. See Section 3.5 for more information. 5980 15. IANA Considerations 5982 A separate UDP port for data channel communications is (currently) 5983 the selected demultiplexing mechanism, and a port must be assigned 5984 for this purpose in Section 3.1. The UDP port numbers are listed by 5985 IANA at http://www.iana.org/assignments/port-numbers. 5987 IANA needs to assign an organization local multicast address called 5988 the "All ACs multicast address" from the IPv6 multicast address 5989 registry in Section 3.3 5991 15.1. CAPWAP Message Types 5993 The Message Type field in the CAPWAP header (Section 4.5.1.1) is used 5994 to identify the operation performed by the message. There are 5995 multiple namespaces, which is identified via the first three octets 5996 of the field containing the IANA Enterprise Number [RFC2434]. When 5997 the Enterprise Number is set to zero, the message types are reserved 5998 for use by the base CAPWAP specification which are controlled and 5999 maintained by IANA and requires a Standards Action. 6001 15.2. Wireless Binding Identifiers 6003 The Wireless Binding Identifier (WBID) field in the CAPWAP header 6004 (Section 4.3) is used to identify the wireless technology associated 6005 with the packet. Due to the limited address space available, a new 6006 WBID request requires Standards Action. 6008 16. Acknowledgements 6010 The following individuals are acknowledged for their contributions to 6011 this protocol specification: Puneet Agarwal, Abhijit Choudhury, 6012 Saravanan Govindan, Peter Nilsson, and David Perkins. 6014 Michael Vakulenko contributed text to describe how CAPWAP can be used 6015 over layer 3 (IP/UDP) networks. 6017 17. References 6019 17.1. Normative References 6021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6022 Requirement Levels", BCP 14, RFC 2119, March 1997. 6024 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 6025 Requirements for Security", BCP 106, RFC 4086, June 2005. 6027 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 6028 Specification, Implementation", RFC 1305, March 1992. 6030 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 6031 X.509 Public Key Infrastructure Certificate and 6032 Certificate Revocation List (CRL) Profile", RFC 3280, 6033 April 2002. 6035 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 6036 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 6038 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 6039 for Transport Layer Security (TLS)", RFC 4279, 6040 December 2005. 6042 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 6043 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 6045 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 6046 Security", RFC 4347, April 2006. 6048 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 6049 Extensions", RFC 2132, March 1997. 6051 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 6052 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 6053 October 1998. 6055 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 6056 G. Fairhurst, "The Lightweight User Datagram Protocol 6057 (UDP-Lite)", RFC 3828, July 2004. 6059 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 6060 Discovery", RFC 4821, March 2007. 6062 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6063 (IPv6) Specification", RFC 1883, December 1995. 6065 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6066 November 1990. 6068 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 6069 for IP version 6", RFC 1981, August 1996. 6071 [I-D.ietf-capwap-protocol-binding-ieee80211] 6072 Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", 6073 draft-ietf-capwap-protocol-binding-ieee80211-06 (work in 6074 progress), February 2008. 6076 [I-D.calhoun-dhc-capwap-ac-option] 6077 Calhoun, P., "CAPWAP Access Controller DHCP Option", 6078 draft-calhoun-dhc-capwap-ac-option-02 (work in progress), 6079 March 2008. 6081 17.2. Informational References 6083 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 6084 an On-line Database", RFC 3232, January 2002. 6086 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 6087 RFC 3753, June 2004. 6089 [I-D.housley-aaa-key-mgmt] 6090 Housley, R. and B. Aboba, "Guidance for AAA Key 6091 Management", draft-housley-aaa-key-mgmt-09 (work in 6092 progress), February 2007. 6094 [DTLS-DESIGN] 6095 Modadugu et al, N., "The Design and Implementation of 6096 Datagram TLS", Feb 2004. 6098 [EUI-48] IEEE, "Guidelines for use of a 48-bit Extended Unique 6099 Identifier", Dec 2005. 6101 [EUI-64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 6102 REGISTRATION AUTHORITY". 6104 Editors' Addresses 6106 Pat R. Calhoun 6107 Cisco Systems, Inc. 6108 170 West Tasman Drive 6109 San Jose, CA 95134 6111 Phone: +1 408-853-5269 6112 Email: pcalhoun@cisco.com 6114 Michael P. Montemurro 6115 Research In Motion 6116 5090 Commerce Blvd 6117 Mississauga, ON L4W 5M4 6118 Canada 6120 Phone: +1 905-629-4746 x4999 6121 Email: mmontemurro@rim.com 6123 Dorothy Stanley 6124 Aruba Networks 6125 1322 Crossman Ave 6126 Sunnyvale, CA 94089 6128 Phone: +1 630-363-1389 6129 Email: dstanley@arubanetworks.com 6131 Full Copyright Statement 6133 Copyright (C) The IETF Trust (2008). 6135 This document is subject to the rights, licenses and restrictions 6136 contained in BCP 78, and except as set forth therein, the authors 6137 retain all their rights. 6139 This document and the information contained herein are provided on an 6140 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6141 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 6142 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 6143 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 6144 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6145 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6147 Intellectual Property 6149 The IETF takes no position regarding the validity or scope of any 6150 Intellectual Property Rights or other rights that might be claimed to 6151 pertain to the implementation or use of the technology described in 6152 this document or the extent to which any license under such rights 6153 might or might not be available; nor does it represent that it has 6154 made any independent effort to identify any such rights. Information 6155 on the procedures with respect to rights in RFC documents can be 6156 found in BCP 78 and BCP 79. 6158 Copies of IPR disclosures made to the IETF Secretariat and any 6159 assurances of licenses to be made available, or the result of an 6160 attempt made to obtain a general license or permission for the use of 6161 such proprietary rights by implementers or users of this 6162 specification can be obtained from the IETF on-line IPR repository at 6163 http://www.ietf.org/ipr. 6165 The IETF invites any interested party to bring to its attention any 6166 copyrights, patents or patent applications, or other proprietary 6167 rights that may cover technology that may be required to implement 6168 this standard. Please address the information to the IETF at 6169 ietf-ipr@ietf.org.