Network Working Group P. Calhoun, Editor Internet-Draft Cisco Systems, Inc. Expires: September 14, 2008 M. Montemurro, Editor Research In Motion D. Stanley, Editor Aruba Networks March 13, 2008 CAPWAP Protocol Specification draft-ietf-capwap-protocol-specification-10 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 14, 2008. Calhoun, Editor, et al. Expires September 14, 2008 [Page 1] Internet-Draft CAPWAP Protocol Specification March 2008 Abstract This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF CAPWAP working group protocol requirements. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol. The CAPWAP protocol binding which defines extensions for use with the IEEE 802.11 wireless LAN protocol is available in [I-D.ietf-capwap-protocol-binding-ieee80211]. Extensions are expected to be defined to enable use of the CAPWAP protocol with additional wireless technologies. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Conventions used in this document . . . . . . . . . . . . 9 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Wireless Binding Definition . . . . . . . . . . . . . . . 13 2.2. CAPWAP Session Establishment Overview . . . . . . . . . . 14 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . . 16 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . . 18 2.3.2. CAPWAP/DTLS Interface . . . . . . . . . . . . . . . . 31 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 33 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . . 33 2.4.2. DTLS Session Establishment . . . . . . . . . . . . . 34 2.4.3. DTLS Error Handling . . . . . . . . . . . . . . . . . 35 2.4.4. DTLS EndPoint Authentication and Authorization . . . 36 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 40 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . . 40 3.2. UDP-Lite Transport . . . . . . . . . . . . . . . . . . . 40 3.3. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 41 3.4. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 42 3.5. MTU Discovery . . . . . . . . . . . . . . . . . . . . . . 42 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 43 4.1. CAPWAP Preamble . . . . . . . . . . . . . . . . . . . . . 45 4.2. CAPWAP DTLS Header . . . . . . . . . . . . . . . . . . . 45 4.3. CAPWAP Header . . . . . . . . . . . . . . . . . . . . . . 46 4.4. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 49 4.4.1. CAPWAP Data Keepalive . . . . . . . . . . . . . . . . 49 4.4.2. Data Payload . . . . . . . . . . . . . . . . . . . . 50 4.4.3. Establishment of a DTLS Data Channel . . . . . . . . 51 4.5. CAPWAP Control Messages . . . . . . . . . . . . . . . . . 51 4.5.1. Control Message Format . . . . . . . . . . . . . . . 52 Calhoun, Editor, et al. Expires September 14, 2008 [Page 2] Internet-Draft CAPWAP Protocol Specification March 2008 4.5.2. Control Message Quality of Service . . . . . . . . . 55 4.5.3. Retransmissions . . . . . . . . . . . . . . . . . . . 55 4.6. CAPWAP Protocol Message Elements . . . . . . . . . . . . 56 4.6.1. AC Descriptor . . . . . . . . . . . . . . . . . . . . 58 4.6.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 60 4.6.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 61 4.6.4. AC Name . . . . . . . . . . . . . . . . . . . . . . . 61 4.6.5. AC Name with Index . . . . . . . . . . . . . . . . . 62 4.6.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 62 4.6.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . . 63 4.6.8. Add Station . . . . . . . . . . . . . . . . . . . . . 63 4.6.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 64 4.6.10. CAPWAP Control IPv4 Address . . . . . . . . . . . . . 64 4.6.11. CAPWAP Control IPv6 Address . . . . . . . . . . . . . 65 4.6.12. CAPWAP Local IPv4 Address . . . . . . . . . . . . . . 66 4.6.13. CAPWAP Local IPv6 Address . . . . . . . . . . . . . . 66 4.6.14. CAPWAP Timers . . . . . . . . . . . . . . . . . . . . 67 4.6.15. CAPWAP Transport Protocol . . . . . . . . . . . . . . 67 4.6.16. Data Transfer Data . . . . . . . . . . . . . . . . . 68 4.6.17. Data Transfer Mode . . . . . . . . . . . . . . . . . 69 4.6.18. Decryption Error Report . . . . . . . . . . . . . . . 69 4.6.19. Decryption Error Report Period . . . . . . . . . . . 70 4.6.20. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 70 4.6.21. Delete Station . . . . . . . . . . . . . . . . . . . 71 4.6.22. Delete Static MAC ACL Entry . . . . . . . . . . . . . 71 4.6.23. Discovery Type . . . . . . . . . . . . . . . . . . . 72 4.6.24. Duplicate IPv4 Address . . . . . . . . . . . . . . . 73 4.6.25. Duplicate IPv6 Address . . . . . . . . . . . . . . . 73 4.6.26. Idle Timeout . . . . . . . . . . . . . . . . . . . . 74 4.6.27. Image Data . . . . . . . . . . . . . . . . . . . . . 75 4.6.28. Image Identifier . . . . . . . . . . . . . . . . . . 75 4.6.29. Image Information . . . . . . . . . . . . . . . . . . 76 4.6.30. Initiate Download . . . . . . . . . . . . . . . . . . 77 4.6.31. Location Data . . . . . . . . . . . . . . . . . . . . 77 4.6.32. Maximum Message Length . . . . . . . . . . . . . . . 77 4.6.33. Radio Administrative State . . . . . . . . . . . . . 78 4.6.34. Radio Operational State . . . . . . . . . . . . . . . 78 4.6.35. Result Code . . . . . . . . . . . . . . . . . . . . . 79 4.6.36. Returned Message Element . . . . . . . . . . . . . . 81 4.6.37. Session ID . . . . . . . . . . . . . . . . . . . . . 81 4.6.38. Statistics Timer . . . . . . . . . . . . . . . . . . 82 4.6.39. Vendor Specific Payload . . . . . . . . . . . . . . . 82 4.6.40. WTP Board Data . . . . . . . . . . . . . . . . . . . 83 4.6.41. WTP Descriptor . . . . . . . . . . . . . . . . . . . 84 4.6.42. WTP Fallback . . . . . . . . . . . . . . . . . . . . 85 4.6.43. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . . 86 4.6.44. WTP IPv4 IP Address . . . . . . . . . . . . . . . . . 87 4.6.45. WTP IPv6 IP Address . . . . . . . . . . . . . . . . . 87 Calhoun, Editor, et al. Expires September 14, 2008 [Page 3] Internet-Draft CAPWAP Protocol Specification March 2008 4.6.46. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 88 4.6.47. WTP Name . . . . . . . . . . . . . . . . . . . . . . 89 4.6.48. WTP Operational Statistics . . . . . . . . . . . . . 89 4.6.49. WTP Radio Statistics . . . . . . . . . . . . . . . . 90 4.6.50. WTP Reboot Statistics . . . . . . . . . . . . . . . . 91 4.6.51. WTP Static IP Address Information . . . . . . . . . . 92 4.7. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 93 4.7.1. ChangeStatePendingTimer . . . . . . . . . . . . . . . 93 4.7.2. DataChannelKeepAlive . . . . . . . . . . . . . . . . 93 4.7.3. DataChannelDeadInterval . . . . . . . . . . . . . . . 94 4.7.4. DataCheckTimer . . . . . . . . . . . . . . . . . . . 94 4.7.5. DiscoveryInterval . . . . . . . . . . . . . . . . . . 94 4.7.6. DTLSSessionDelete . . . . . . . . . . . . . . . . . . 94 4.7.7. EchoInterval . . . . . . . . . . . . . . . . . . . . 94 4.7.8. ImageDataStartTimer . . . . . . . . . . . . . . . . . 94 4.7.9. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 95 4.7.10. MaxFailedDTLSSessionRetry . . . . . . . . . . . . . . 95 4.7.11. ResponseTimeout . . . . . . . . . . . . . . . . . . . 95 4.7.12. RetransmitInterval . . . . . . . . . . . . . . . . . 95 4.7.13. SilentInterval . . . . . . . . . . . . . . . . . . . 95 4.7.14. StatisticsTimer . . . . . . . . . . . . . . . . . . . 95 4.7.15. WaitDTLS . . . . . . . . . . . . . . . . . . . . . . 95 4.7.16. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 96 4.8. CAPWAP Protocol Variables . . . . . . . . . . . . . . . . 96 4.8.1. AdminState . . . . . . . . . . . . . . . . . . . . . 96 4.8.2. DiscoveryCount . . . . . . . . . . . . . . . . . . . 96 4.8.3. FailedDTLSAuthFailCount . . . . . . . . . . . . . . . 96 4.8.4. FailedDTLSSessionCount . . . . . . . . . . . . . . . 96 4.8.5. IdleTimeout . . . . . . . . . . . . . . . . . . . . . 96 4.8.6. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 96 4.8.7. MaxRetransmit . . . . . . . . . . . . . . . . . . . . 97 4.8.8. ReportInterval . . . . . . . . . . . . . . . . . . . 97 4.8.9. RetransmitCount . . . . . . . . . . . . . . . . . . . 97 4.8.10. WTPFallBack . . . . . . . . . . . . . . . . . . . . . 97 4.9. WTP Saved Variables . . . . . . . . . . . . . . . . . . . 97 4.9.1. AdminRebootCount . . . . . . . . . . . . . . . . . . 97 4.9.2. FrameEncapType . . . . . . . . . . . . . . . . . . . 97 4.9.3. LastRebootReason . . . . . . . . . . . . . . . . . . 97 4.9.4. MacType . . . . . . . . . . . . . . . . . . . . . . . 97 4.9.5. PreferredACs . . . . . . . . . . . . . . . . . . . . 98 4.9.6. RebootCount . . . . . . . . . . . . . . . . . . . . . 98 4.9.7. Static ACL Table . . . . . . . . . . . . . . . . . . 98 4.9.8. Static IP Address . . . . . . . . . . . . . . . . . . 98 4.9.9. WTPLinkFailureCount . . . . . . . . . . . . . . . . . 98 4.9.10. WTPLocation . . . . . . . . . . . . . . . . . . . . . 98 4.9.11. WTPName . . . . . . . . . . . . . . . . . . . . . . . 98 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 99 5.1. Discovery Request Message . . . . . . . . . . . . . . . . 99 Calhoun, Editor, et al. Expires September 14, 2008 [Page 4] Internet-Draft CAPWAP Protocol Specification March 2008 5.2. Discovery Response Message . . . . . . . . . . . . . . . 100 5.3. Primary Discovery Request Message . . . . . . . . . . . . 101 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 102 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 104 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 104 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . . 105 7. Control Channel Management . . . . . . . . . . . . . . . . . 108 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 108 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . . 108 8. WTP Configuration Management . . . . . . . . . . . . . . . . 110 8.1. Configuration Consistency . . . . . . . . . . . . . . . . 110 8.1.1. Configuration Flexibility . . . . . . . . . . . . . . 111 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 111 8.3. Configuration Status Response . . . . . . . . . . . . . . 112 8.4. Configuration Update Request . . . . . . . . . . . . . . 113 8.5. Configuration Update Response . . . . . . . . . . . . . . 114 8.6. Change State Event Request . . . . . . . . . . . . . . . 114 8.7. Change State Event Response . . . . . . . . . . . . . . . 116 8.8. Clear Configuration Request . . . . . . . . . . . . . . . 116 8.9. Clear Configuration Response . . . . . . . . . . . . . . 116 9. Device Management Operations . . . . . . . . . . . . . . . . 118 9.1. Firmware Management . . . . . . . . . . . . . . . . . . . 118 9.1.1. Image Data Request . . . . . . . . . . . . . . . . . 121 9.1.2. Image Data Response . . . . . . . . . . . . . . . . . 122 9.2. Reset Request . . . . . . . . . . . . . . . . . . . . . . 123 9.3. Reset Response . . . . . . . . . . . . . . . . . . . . . 123 9.4. WTP Event Request . . . . . . . . . . . . . . . . . . . . 124 9.5. WTP Event Response . . . . . . . . . . . . . . . . . . . 125 9.6. Data Transfer Request . . . . . . . . . . . . . . . . . . 125 9.7. Data Transfer Response . . . . . . . . . . . . . . . . . 126 10. Station Session Management . . . . . . . . . . . . . . . . . 127 10.1. Station Configuration Request . . . . . . . . . . . . . . 127 10.2. Station Configuration Response . . . . . . . . . . . . . 127 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 129 12. Security Considerations . . . . . . . . . . . . . . . . . . . 131 12.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . . 131 12.1.1. Converting Protected Data into Unprotected Data . . . 132 12.1.2. Converting Unprotected Data into Protected Data (Insertion) . . . . . . . . . . . . . . . . . . . . . 132 12.1.3. Deletion of Protected Records . . . . . . . . . . . . 132 12.1.4. Insertion of Unprotected Records . . . . . . . . . . 132 12.2. Session ID Security . . . . . . . . . . . . . . . . . . . 132 12.3. Discovery or DTLS Setup Attacks . . . . . . . . . . . . . 133 12.4. Interference with a DTLS Session . . . . . . . . . . . . 134 12.5. CAPWAP Pre-Provisioning . . . . . . . . . . . . . . . . . 134 12.6. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . . 135 12.7. Use of Certificates in CAPWAP . . . . . . . . . . . . . . 136 12.8. AAA Security . . . . . . . . . . . . . . . . . . . . . . 137 Calhoun, Editor, et al. Expires September 14, 2008 [Page 5] Internet-Draft CAPWAP Protocol Specification March 2008 13. Management Considerations . . . . . . . . . . . . . . . . . . 138 14. Transport Considerations . . . . . . . . . . . . . . . . . . 139 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140 15.1. CAPWAP Message Types . . . . . . . . . . . . . . . . . . 140 15.2. Wireless Binding Identifiers . . . . . . . . . . . . . . 140 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 141 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 17.1. Normative References . . . . . . . . . . . . . . . . . . 142 17.2. Informational References . . . . . . . . . . . . . . . . 143 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 144 Intellectual Property and Copyright Statements . . . . . . . . . 145 Calhoun, Editor, et al. Expires September 14, 2008 [Page 6] Internet-Draft CAPWAP Protocol Specification March 2008 1. Introduction This document describes the CAPWAP Protocol, a standard, interoperable protocol which enables an Access Controller (AC) to manage a collection of Wireless Termination Points (WTPs). The CAPWAP protocol is defined to be independent of layer 2 technology. The emergence of centralized IEEE 802.11 Wireless Local Area Network (WLAN) architectures, in which simple IEEE 802.11 WTPs are managed by an Access Controller (AC) suggested that a standards based, interoperable protocol could radically simplify the deployment and management of wireless networks. WTPs require a set of dynamic management and control functions related to their primary task of connecting the wireless and wired mediums. Traditional protocols for managing WTPs are either manual static configuration via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs are self- contained). An IEEE 802.11 binding is defined in [I-D.ietf-capwap-protocol-binding-ieee80211] to support use of the CAPWAP protocol with IEEE 802.11 WLAN networks. CAPWAP assumes a network configuration consisting of multiple WTPs communicating via the Internet Protocol (IP) to an AC. WTPs are viewed as remote RF interfaces controlled by the AC. The CAPWAP protocol supports two modes of operation: Split and Local MAC. In Split MAC mode all L2 wireless data and management frames are encapsulated via the CAPWAP protocol and exchanged between the AC and the WTP. As shown in Figure 1, the wireless frames received from a mobile device, which is referred to in this specification as a Station (STA), are directly encapsulated by the WTP and forwarded to the AC. +-+ wireless frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | |wireless PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: Representative CAPWAP Architecture for Split MAC The Local MAC mode of operation allows for the data frames to be either locally bridged, or tunneled as 802.3 frames. The latter implies that the WTP performs the 802.11 Integration function. In either case the L2 wireless management frames are processed locally by the WTP, and then forwarded to the AC. Figure 2 shows the Local MAC mode, in which a station transmits a wireless frame which is Calhoun, Editor, et al. Expires September 14, 2008 [Page 7] Internet-Draft CAPWAP Protocol Specification March 2008 encapsulated in an 802.3 frame and forwarded to the AC. +-+wireless frames +-+ 802.3 frames +-+ | |----------------| |--------------| | | | | | | | | |----------------| |--------------| | | |wireless PHY/ | | CAPWAP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 2: Representative CAPWAP Architecture for Local MAC Provisioning WTPs with security credentials, and managing which WTPs are authorized to provide service are traditionally handled by proprietary solutions. Allowing these functions to be performed from a centralized AC in an interoperable fashion increases manageability and allows network operators to more tightly control their wireless network infrastructure. 1.1. Goals The goals for the CAPWAP protocol are listed below: 1. To centralize the authentication and policy enforcement functions for a wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs. 2. To enable shifting of the higher level protocol processing from the WTP. This leaves the time critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs which are the subject to severe cost pressure. 3. To provide a generic encapsulation and transport mechanism, enabling the CAPWAP protocol to be applied to many access point types in the future, via a specific wireless binding. The CAPWAP protocol concerns itself solely with the interface between the WTP and the AC. Inter-AC and station-to AC-communication are strictly outside the scope of this document. Calhoun, Editor, et al. Expires September 14, 2008 [Page 8] Internet-Draft CAPWAP Protocol Specification March 2008 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.3. Contributing Authors This section lists and acknowledges the authors of significant text and concepts included in this specification. The CAPWAP Working Group selected the Lightweight Access Point Protocol (LWAPP) [add reference, when available] to be used as the basis of the CAPWAP protocol specification. The following people are authors of the LWAPP document: Bob O'Hara, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com Pat Calhoun, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com Rohit Suri, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-5548, Email: rsuri@cisco.com Nancy Cam Winget, Cisco Systems, Inc. 170 West Tasman Drive, San Jose, CA 95134 Phone: +1 408-853-0532, Email: ncamwing@cisco.com Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com Michael Glenn Williams, Nokia, Inc. 313 Fairchild Drive, Mountain View, CA 94043 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com Sue Hares, Nexthop Technologies, Inc. 825 Victors Way, Suite 100, Ann Arbor, MI 48108 Phone: +1 734 222 1610, Email: shares@nexthop.com DTLS is used as the security solution for the CAPWAP protocol. The following people are authors of significant DTLS-related text included in this document: Calhoun, Editor, et al. Expires September 14, 2008 [Page 9] Internet-Draft CAPWAP Protocol Specification March 2008 Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com Eric Rescorla, Network Resonance 2483 El Camino Real, #212,Palo Alto CA, 94303 Email: ekr@networkresonance.com The concept of using DTLS to secure the CAPWAP protocol was part of the Secure Light Access Point Protocol (SLAPP) proposal [add reference when available]. The following people are authors of the SLAPP proposal: Partha Narasimhan, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-480-4716, Email: partha@arubanetworks.com Dan Harkins, Tropos Networks 555 Del Rey Avenue, Sunnyvale, CA, 95085 Phone: +1 408 470 7372, Email: dharkins@tropos.com Subbu Ponnuswamy, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com The following individuals contributed significant security related text to the draft: T. Charles Clancy, Laboratory for Telecommunications Sciences, 8080 Greenmead Drive, College Park, MD 20740 Phone: +1 240-373-5069, Email: clancy@ltsnet.net Scott Kelly, Aruba Networks 1322 Crossman Ave, Sunnyvale, CA 94089 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 1.4. Terminology Access Controller (AC): The network entity that provides WTP access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. CAPWAP Control Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC control port, WTP control port and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP control packets are sent and received. Calhoun, Editor, et al. Expires September 14, 2008 [Page 10] Internet-Draft CAPWAP Protocol Specification March 2008 CAPWAP Data Channel: A bi-directional flow defined by the AC IP Address, WTP IP Address, AC data port, WTP data port, and the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP data packets are sent and received. Station (STA): A device that contains an interface to a wireless medium (WM). Wireless Termination Point (WTP): The physical or network entity that contains an RF antenna and wireless PHY to transmit and receive station traffic for wireless access networks. This document uses additional terminology defined in [RFC3753]. Calhoun, Editor, et al. Expires September 14, 2008 [Page 11] Internet-Draft CAPWAP Protocol Specification March 2008 2. Protocol Overview The CAPWAP protocol is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP control messages, and optionally CAPWAP data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4346]. DTLS is a standards-track IETF protocol based upon TLS. The underlying security-related protocol mechanisms of TLS have been successfully deployed for many years. The CAPWAP protocol Transport layer carries two types of payload, CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data messages encapsulate forwarded wireless frames. CAPWAP protocol Control messages are management messages exchanged between a WTP and an AC. The CAPWAP Data and Control packets are sent over separate UDP ports. Since both data and control packets can exceed the Maximum Transmission Unit (MTU) length, the payload of a CAPWAP data or control message can be fragmented. The fragmentation behavior is defined in Section 3. The CAPWAP Protocol begins with a discovery phase. The WTPs send a Discovery Request message, causing any Access Controller (AC) receiving the message to respond with a Discovery Response message. From the Discovery Response messages received, a WTP selects an AC with which to establish a secure DTLS session. CAPWAP protocol messages will be fragmented to the maximum length discovered to be supported by the network. Once the WTP and the AC have completed DTLS session establishment, a configuration exchange occurs in which both devices agree on version information. During this exchange the WTP may receive provisioning settings. The WTP is then enabled for operation. When the WTP and AC have completed the version and provision exchange and the WTP is enabled, the CAPWAP protocol is used to encapsulate the wireless data frames sent between the WTP and AC. The CAPWAP protocol will fragment the L2 frames if the size of the encapsulated wireless user data (Data) or protocol control (Management) frames causes the resulting CAPWAP protocol packet to exceed the MTU supported between the WTP and AC. Fragmented CAPWAP packets are reassembled to reconstitute the original encapsulated payload. MTU Discovery and Fragmentation are described in Section 3. The CAPWAP protocol provides for the delivery of commands from the AC to the WTP for the management of stations that are communicating with the WTP. This may include the creation of local data structures in the WTP for the stations and the collection of statistical information about the communication between the WTP and the stations. Calhoun, Editor, et al. Expires September 14, 2008 [Page 12] Internet-Draft CAPWAP Protocol Specification March 2008 The CAPWAP protocol provides a mechanism for the AC to obtain statistical information collected by the WTP. The CAPWAP protocol provides for a keep alive feature that preserves the communication channel between the WTP and AC. If the AC fails to appear alive, the WTP will try to discover a new AC. 2.1. Wireless Binding Definition The CAPWAP protocol is independent of a specific WTP radio technology. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST follow the binding requirements defined for that technology. When defining a binding for wireless technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. At a minimum, a binding MUST provide: 1. The definition for a binding-specific Statistics message element, carried in the WTP Event Request message 2. A message element carried in the Station Configuration Request message to configure station information on the WTP 3. A WTP Radio Information message element carried in the Discovery, Primary Discovery and Join Request and Response messages, indicating the binding specific radio types supported at the WTP and AC. If technology specific message elements are required for any of the existing CAPWAP messages defined in this specification, they MUST also be defined in the technology binding document. The naming of binding-specific message elements MUST begin with the name of the technology type, e.g., the binding for IEEE 802.11, provided in [I-D.ietf-capwap-protocol-binding-ieee80211], begins with "IEEE 802.11". The CAPWAP binding concept MUST also be used in any future specification that add functionality to either the base CAPWAP protocol specification, or any published CAPWAP binding specification. A separate WTP Radio Information message element MUST be created to properly advertise support for the specification. This mechanism allows for future protocol extensibility, while providing the necessary capabilities advertisement, through the WTP Radio Calhoun, Editor, et al. Expires September 14, 2008 [Page 13] Internet-Draft CAPWAP Protocol Specification March 2008 Information message element, to ensure WTP/AC interoperability. 2.2. CAPWAP Session Establishment Overview This section describes the session establishment process message exchanges in the ideal case. The annotated ladder diagram shows the AC on the right, the WTP on the left, and assumes the use of certificates for DTLS authentication. The CAPWAP Protocol State Machine is described in detail in Section 2.3. Note that DTLS allows certain messages to be aggregated into a single frame, which is denoted via an asterisk in the following figure. ============ ============ WTP AC ============ ============ [----------- begin optional discovery ------------] Discover Request ------------------------------------> Discover Response <------------------------------------ [----------- end optional discovery ------------] (-- begin DTLS handshake --) ClientHello ------------------------------------> HelloVerifyRequest (with cookie) <------------------------------------ ClientHello (with cookie) ------------------------------------> ServerHello, Certificate, ServerHelloDone* <------------------------------------ (-- WTP callout for AC authorization --) Certificate (optional), ClientKeyExchange, CertificateVerify (optional), ChangeCipherSpec, Finished* ------------------------------------> Calhoun, Editor, et al. Expires September 14, 2008 [Page 14] Internet-Draft CAPWAP Protocol Specification March 2008 (-- AC callout for WTP authorization --) ChangeCipherSpec, Finished* <------------------------------------ (-- DTLS session is established now --) Join Request ------------------------------------> Join Response <------------------------------------ [-- Join State Complete --] (-- assume image is up to date --) Configuration Status Request ------------------------------------> Configuration Status Response <------------------------------------ [-- Configure State Complete --] Change State Event Request ------------------------------------> Change State Event Response <------------------------------------ [-- Data Check State Complete --] (-- enter RUN state --) : : Echo Request ------------------------------------> Echo Response <------------------------------------ : : Event Request ------------------------------------> Event Response <------------------------------------ : : Calhoun, Editor, et al. Expires September 14, 2008 [Page 15] Internet-Draft CAPWAP Protocol Specification March 2008 At the end of the illustrated CAPWAP message exchange, the AC and WTP are securely exchanging CAPWAP control messages. This is an idealized illustration, provided to clarify protocol operation. Section 2.3 provides a detailed description of the corresponding state machine. 2.3. CAPWAP State Machine Definition The following state diagram represents the lifecycle of a WTP-AC session. Use of DTLS by the CAPWAP protocol results in the juxtaposition of two nominally separate yet tightly bound state machines. The DTLS and CAPWAP state machines are coupled through an API consisting of commands (see Section 2.3.2.1) and notifications (see Section 2.3.2.2). Certain transitions in the DTLS state machine are triggered by commands from the CAPWAP state machine, while certain transitions in the CAPWAP state machine are triggered by notifications from the DTLS state machine. Calhoun, Editor, et al. Expires September 14, 2008 [Page 16] Internet-Draft CAPWAP Protocol Specification March 2008 /-------------------------------------\ | /-------------------------\| | p| || | q+----------+ r +------------+ || | | Run |-->| Reset |-\|| | +----------+ +------------+ ||| n| o ^ ^ ^ s||| +------------+--------/ | | ||| | Data Check | /-------/ | ||| +------------+<-------\ | | ||| | | | ||| /------------------+--------\ | ||| f| m| h| j v k| ||| +--------+ +-----------+ +--------------+||| | Join |---->| Configure | | Image Data |||| +--------+ n +-----------+ +--------------+||| ^ |g i| l| ||| | | \-------------------\ | ||| | \--------------------------------------\| | ||| \------------------------\ || | ||| /--------------<----------------+---------------\ || | ||| | /------------<----------------+-------------\ | || | ||| | | 4 |d t| | vv v vvv | | +----------------+ +--------------+ +-----------+ | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | /-|-|---+----------------+ +--------------+ e +-----------+ | | | |$ ^ ^ |5 ^6 ^ ^ |w v v v | | | | \-------\ | | | | | | | | | \---------\ | | /-----------/ | | | | | | \--\ | | | | | | | | | | | | | | | | | | | v 3| 1 |% # v | |a |b v | | \->+------+-->+------+ +-----------+ +--------+ | | | Idle | | Disc | | Authorize | | Dead | | | +------+<--+------+ +-----------+ +--------+ | | ^ 0^ 2 |! | | | | | +-------+ *| |u | \---------+---| Start | | | |@ | +-------+ | \->+---------+<------/ \--->| Sulking | +---------+& Figure 3: CAPWAP Integrated State Machine The CAPWAP protocol state machine, depicted above, is used by both the AC and the WTP. In cases where states are not shared (i.e. not implemented in one or the other of the AC or WTP), this is explicitly Calhoun, Editor, et al. Expires September 14, 2008 [Page 17] Internet-Draft CAPWAP Protocol Specification March 2008 called out in the transition descriptions below. For every state defined, only certain messages are permitted to be sent and received. The CAPWAP control message definitions specify the state(s) in which each message is valid. Since the WTP only communicates with a single AC, it only has a single instance of the CAPWAP state machine. The state machine works differently on the AC since it communicates with many WTPs. The AC uses the concept of three threads. Note that the term thread used here does not necessarily imply that implementers must use threads, but it is one possible way of implementing the AC's state machine. Listener Thread: The AC's Listener thread handles inbound DTLS session establishment requests, through the DTLSListen command. Upon creation, the Listener thread starts in the DTLS Setup state. Once a DTLS session has been validated, which occurs when the state machine enters the "Authorize" state, the Listener thread creates a WTP session specific Service thread and state context. The state machine transitions in figure Figure 3 are represented by numerals. It is necessary for the AC to protect itself against various attacks that exist with non-authenticated frames. See Section 12 for more information. Discovery Thread: The AC's Discovery thread is responsible for receiving, and responding to, Discovery Request messages. The state machine transitions in figure Figure 3 are represented by numerals. Note that the Discovery thread does not maintain any per-WTP specific context information, and a single state context exists. It is necessary for the AC to protect itself against various attacks that exist with non-authenticated frames. See Section 12 for more information. Service Thread: The AC's Service thread handles the per-WTP states, and one such thread exists per-WTP connection. This thread is created by the listener thread when the Authorize state is reached. When created, the Service thread inherits a copy of the state machine context from the Listener thread. When communication with the WTP is complete, the Service thread is terminated and all associated resources are released. The state machine transitions in figure Figure 3 are represented by alphabetic characters. 2.3.1. CAPWAP Protocol State Transitions This section describes the various state transitions, and the events that cause them. This section does not discuss interactions between DTLS- and CAPWAP-specific states. Those interactions, and DTLS- specific states and transitions, are discussed in Section 2.3.2. Calhoun, Editor, et al. Expires September 14, 2008 [Page 18] Internet-Draft CAPWAP Protocol Specification March 2008 Start to Idle (0): This transition occurs once device initialization is complete. WTP: This state transition is used to start the WTP's CAPWAP state machine. AC: The AC creates the Discovery and Listener threads and starts the CAPWAP state machine. Idle to Discovery (1): This transition occurs to support the CAPWAP discovery process . WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request message (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 4.7). The WTP resets the DiscoveryCount counter to zero (0) (see Section 4.8). The WTP also clears all information from ACs it may have received during a previous Discovery phase. AC: This state transition is executed by the AC's Discovery thread, and occurs when a Discovery Request message is received. The AC SHOULD respond with a Discovery Response message (see Section 5.2). Discovery to Discovery (#): In the Discovery state, the WTP determines which AC to connect to. WTP: This transition occurs when the DiscoveryInterval timer expires. If the WTP is configured with a list of ACs, it transmits a Discovery Request message to every AC from which it has not received a Discovery Response message. For every transition to this event, the WTP increments the DiscoveryCount counter. See Section 5.1 for more information on how the WTP knows the ACs to which it should transmit the Discovery Request messages. The WTP restarts the DiscoveryInterval timer whenever it transmits Discovery Request messages. AC: This is an invalid state transition for the AC. Discovery to Idle (2): This transition occurs on the AC's Discovery thread when the Discovery processing is complete. WTP: This is an invalid state transition for the WTP. Calhoun, Editor, et al. Expires September 14, 2008 [Page 19] Internet-Draft CAPWAP Protocol Specification March 2008 AC: This state transition is executed by the AC's Discovery thread when it has transmitted the Discovery Response, in response to a Discovery Request. Discovery to Sulking (!): This transition occurs on a WTP when AC Discovery fails. WTP: The WTP enters this state when the DiscoveryInterval timer expires and the DiscoveryCount variable is equal to the MaxDiscoveries variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP protocol messages MUST be ignored. AC: This is an invalid state transition for the AC. Sulking to Idle (@): This transition occurs on a WTP when it must restart the discovery phase. WTP: The WTP enters this state when the SilentInterval timer (see Section 4.7) expires. The FailedDTLSSessionCount, DiscoveryCount and FailedDTLSAuthFailCount counters are reset to zero. AC: This is an invalid state transition for the AC. Sulking to Sulking (&): The Sulking state provides the silent period, minimizing the possibility for Denial of Service (DoS) attacks. WTP: All packets received from the AC while in the sulking state are ignored. AC: This is an invalid state transition for the AC. Idle to DTLS Setup (3): This transition occurs to establish a secure DTLS session with the peer. WTP: The WTP initiates this transition by invoking the DTLSStart command, which starts the DTLS session establishment with the chosen AC. When the discovery phase is bypassed, it is assumed the WTP has locally configured ACs. AC: Upon entering the Idle state from the Start state, the newly created Listener thread automatically transitions to the DTLS Setup and invokes the DTLSListen command (see Section 2.3.2.1). Calhoun, Editor, et al. Expires September 14, 2008 [Page 20] Internet-Draft CAPWAP Protocol Specification March 2008 Discovery to DTLS Setup (%): This transition occurs to establish a secure DTLS session with the peer. WTP: The WTP initiates this transition by invoking the DTLSStart command (see Section 2.3.2.1), which starts the DTLS session establishment with the chosen AC. The decision of which AC to connect to is the result of the discovery phase, which is described in Section 3.3. AC: This is an invalid state transition for the AC. DTLS Setup to Idle ($): This transition occurs when the DTLS connection setup fails. WTP: The WTP initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2), and the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. AC: This is an invalid state transition for the AC. DTLS Setup to Sulking (*): This transition occurs when repeated attempts to setup the DTLS connection have failed. WTP: The WTP enters this state when the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP and DTLS protocol messages received MUST be ignored. AC: This is an invalid state transition for the AC. DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS Session failed to be established. WTP: This is an invalid state transition for the WTP. AC: The AC's Listener initiates this state transition when it receives a DTLSEstablishFail notification from DTLS (see Section 2.3.2.2). This error notification aborts the secure DTLS session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. The Listener thread then invokes the DTLSListen command (see Calhoun, Editor, et al. Expires September 14, 2008 [Page 21] Internet-Draft CAPWAP Protocol Specification March 2008 Section 2.3.2.1). DTLS Setup to Authorize (5): This transition occurs when an incoming DTLS session is being established, and the DTLS stack needs authorization to proceed with the session establishment. WTP: This state transition occurs when the WTP receives the DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon entering this state, the WTP performs an authorization check against the AC credentials. See Section 2.4.4 for more information on AC authorization. AC: This state transition is handled by the AC's Listener thread when the DTLS module initiates the DTLSPeerAuthorize notification (see Section 2.3.2.2). The Listener thread forks an instance of the Service thread, along with a copy of the state context. Once created, the Service thread performs an authorization check against the WTP credentials. See Section 2.4.4 for more information on WTP authorization. Authorize to DTLS Setup (6): This transition is executed by the Listener thread to enable it to listen for new incoming sessions. WTP: This is an invalid state transition for the WTP. AC: This state transition occurs when the AC's Listener thread has created the WTP context and the Service thread. The Listener thread then invokes the DTLSListen command (see Section 2.3.2.1). Authorize to DTLS Connect (a): This transition occurs to notify the DTLS stack that the session should be established. WTP: This state transition occurs when the WTP has successfully authorized the AC's credentials (see Section 2.4.4). This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1). AC: This state transition occurs when the AC has successfully authorized the WTP's credentials (see Section 2.4.4). This is done by invoking the DTLSAccept DTLS command (see Section 2.3.2.1). Authorize to DTLS Teardown (b): This transition occurs to notify the DTLS stack that the session should be aborted. Calhoun, Editor, et al. Expires September 14, 2008 [Page 22] Internet-Draft CAPWAP Protocol Specification March 2008 WTP: This state transition occurs when the WTP was unable to authorize the AC, using the AC credentials. The WTP then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). AC: This state transition occurs when the AC was unable to authorize the WTP, using the WTP credentials. The AC then aborts the DTLS session by invoking the DTLSAbortSession command (see Section 2.3.2.1). DTLS Connect to DTLS Teardown (c): This transition occurs when the DTLS Session failed to be established. WTP: This state transition occurs when the WTP receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established. When this transition occurs due to the DTLSAuthenticateFail notification, the FailedDTLSAuthFailCount is incremented, otherwise the FailedDTLSSessionCount counter is incremented. AC: This state transition occurs when the AC receives either a DTLSAborted or DTLSAuthenticateFail notification (see Section 2.3.2.2), indicating that the DTLS session was not successfully established, and both of the FailedDTLSAuthFailCount and FailedDTLSSessionCount counters have not reached the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). DTLS Connect to Join (d): This transition occurs when the DTLS Session is successfully established. WTP: This state transition occurs when the WTP receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero. AC: This state transition occurs when the AC receives the DTLSEstablished notification (see Section 2.3.2.2), indicating that the DTLS session was successfully established. When this notification is received, the FailedDTLSSessionCount counter is set to zero, and the WaitJoin timer is started (see Section 4.7). Calhoun, Editor, et al. Expires September 14, 2008 [Page 23] Internet-Draft CAPWAP Protocol Specification March 2008 Join to DTLS Teardown (e): This transition occurs when the join process failed. WTP: This state transition occurs when the WTP receives a Join Response message with a Result Code message element containing an error, if the Image Identifier provided by the AC in the Join Response message differs from the WTP's currently running firmware version and the WTP has the requested image in its non-volatile memory, or if the WaitDTLS timer expires. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the WTP receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. AC: This state transition occurs either if the WaitJoin timer expires or if the AC transmits a Join Response message with a Result Code message element containing an error. This causes the AC to initiate the DTLSShutdown command (see Section 2.3.2.1). This transition also occurs if the AC receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect. Join to Image Data (f): This state transition is used by the WTP and the AC to download executable firmware. WTP: The WTP enters the Image Data state when it receives a successful Join Response message and determines and the included Image Identifier message element is not the same as its currently running image. The WTP also detects that the requested image version is not currently available in the WTP's non-volatile storage (see Section 9.1 for a full description of the firmware download process). The WTP initializes the EchoInterval timer (see Section 4.7), and transmits the Image Data Request message (see Section 9.1.1) requesting the start of the firmware download. AC: This state transition occurs when the AC receives the Image Data Request message from the WTP. The AC MUST transmit an Image Data Response message (see Section 9.1.2) to the WTP, which includes a portion of the firmware. The AC MUST start the ImageDataStartTimer timer (see Section 4.7). Join to Configure (g): This state transition is used by the WTP and the AC to exchange configuration information. Calhoun, Editor, et al. Expires September 14, 2008 [Page 24] Internet-Draft CAPWAP Protocol Specification March 2008 WTP: The WTP enters the Configure state when it receives a successful Join Response message, and determines that the included Image Identifier message element is the same as its currently running image. The WTP transmits the Configuration Status message (see Section 8.2) to the AC with message elements describing its current configuration. The WTP also starts the ResponseTimeout timer (see Section 4.7). AC: This state transition occurs immediately after the AC transmits the Join Response message to the WTP. If the AC receives the Configuration Status message from the WTP, the AC MUST transmit a Configuration Status Response message (see Section 8.3) to the WTP, and MAY include specific message elements to override the WTP's configuration. The AC also starts the ChangeStatePendingTimer timer (see Section 4.7). Configure to Reset (h): This state transition is used to reset the connection either due to an error during the configuration phase, or when the WTP determines it needs to reset in order for the new configuration to take effect. WTP: The WTP enters the Reset state when it receives a Configuration Status Response message indicating an error or when it determines that a reset of the WTP is required, due to the characteristics of a new configuration. AC: The AC transitions to the Reset state when it receives a Change State Event message from the WTP that contains an error for which AC policy does not permit the WTP to provide service. This state transition also occurs when the AC ChangeStatePendingTimer timer expires. Configure to DTLS Teardown (i): This transition occurs when the configuration process aborts due to a DTLS error. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. Calhoun, Editor, et al. Expires September 14, 2008 [Page 25] Internet-Draft CAPWAP Protocol Specification March 2008 Image Data to Image Data (j): The Image Data state is used by the WTP and the AC during the firmware download phase. WTP: The WTP enters the Image Data state when it receives an Image Data Response message indicating that the AC has more data to send. AC: This state transition occurs when the AC receives the Image Data Request message from the WTP while already in the Image Data state. The AC resets the ImageDataStartTimer timer. Image Data to Reset (k): This state transition is used to reset the DTLS connection prior to restarting the WTP after an image download. WTP: When an image download completes, the WTP enters the Reset state. The WTP MAY also transition to this state upon receiving an Image Data Response message from the AC (see Section 9.1.2) indicating a failure. AC: The AC enters the Reset state when an error occurs during the image download process or if the ImageDataStartTimer timer expires. Image Data to DTLS Teardown (l): This transition occurs when the firmware download process aborts due to a DTLS error. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. Configure to Data Check (m): This state transition occurs when the WTP and AC confirm the configuration. WTP: The WTP enters this state when it receives a successful Configuration Status Response message from the AC. The WTP initializes the EchoInterval timer (see Section 4.7), and transmits the Change State Event Request message (see Section 8.6). Calhoun, Editor, et al. Expires September 14, 2008 [Page 26] Internet-Draft CAPWAP Protocol Specification March 2008 AC: This state transition occurs when the AC receives the Change State Event Request message (see Section 8.6) from the WTP. The AC responds with a Change State Event Response message (see Section 8.7). The AC MUST start the DataCheckTimer timer (see Section 4.7). Data Check to DTLS Teardown (n): This transition occurs when the WTP does not complete the Data Check exchange. WTP: This state transition occurs if the WTP does not receive the Change State Event Response message before a CAPWAP transmission timeout occurs. AC: The AC enters this state when the DataCheckTimer timer expires (see Section 4.7). Data Check to Run (o): This state transition occurs when the linkage between the control and data channels is established, causing the WTP and AC to enter their normal state of operation. WTP: The WTP enters this state when it receives a successful Change State Event Response message from the AC. The WTP initiates the data channel, which MAY require the establishment of a DTLS session, starts the DataChannelKeepAlive timer (see Section 4.7) and transmits a Data Channel Keep Alive packet (see Section 4.4.1). The WTP then starts the DataChannelDeadInterval timer (see Section 4.7). AC: This state transition occurs when the AC receives the Data Channel Keep Alive packet (see Section 4.4.1), with a Session ID message element matching that included by the WTP in the Join Request message. The AC disables the DataCheckTimer timer. Note that if AC policy is to require the data channel to be encrypted, this process would also require the establishment of a data channel DTLS session. Upon receiving the Data Channel Keep Alive packet, the AC transmits its own Data Channel Keep Alive packet. Run to DTLS Teardown (p): This state transition occurs when an error has occurred in the DTLS stack, causing the DTLS session to be torn down. WTP: The WTP enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The WTP also transitions to this state if the underlying reliable Calhoun, Editor, et al. Expires September 14, 2008 [Page 27] Internet-Draft CAPWAP Protocol Specification March 2008 transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). AC: The AC enters this state when it receives one of the following DTLS notifications: DTLSAborted, DTLSReassemblyFailure or DTLSPeerDisconnect (see Section 2.3.2.2). The WTP MAY tear down the DTLS session if it receives frequent DTLSDecapFailure notifications. The AC transitions to this state if the underlying reliable transport's RetransmitCount counter has reached the MaxRetransmit variable (see Section 4.7). Run to Run (q): This is the normal state of operation. WTP: This is the WTP's normal state of operation. There are many events that result this state transition: Configuration Update: The WTP receives a Configuration Update Request message(see Section 8.4). The WTP MUST respond with a Configuration Update Response message (see Section 8.5). Change State Event: The WTP receives a Change State Event Response message, or determines that it must initiate a Change State Event Request message, as a result of a failure or change in the state of a radio. Echo Request: The WTP sends an Echo Request message (Section 7.1) or receives the corresponding Echo Response message, (see Section 7.2) from the AC. Clear Config Request: The WTP receives a Clear Configuration Request message (see Section 8.8). The WTP MUST reset its configuration back to manufacturer defaults. WTP Event: The WTP sends a WTP Event Request message, delivering information to the AC (see Section 9.4). The WTP receives a WTP Event Response message from the AC (see Section 9.5). Data Transfer: The WTP sends a Data Transfer Request message to the AC (see Section 9.6). The WTP receives a Data Transfer Response message from the AC (see Section 9.7). Station Configuration Request: The WTP receives a Station Configuration Request message (see Section 10.1), to which it MUST respond with a Station Configuration Response message (see Section 10.2). Calhoun, Editor, et al. Expires September 14, 2008 [Page 28] Internet-Draft CAPWAP Protocol Specification March 2008 AC: This is the AC's normal state of operation: Configuration Update: The AC sends a Configuration Update Request message (see Section 8.4) to the WTP to update its configuration. The AC receives a Configuration Update Response message (see Section 8.5) from the WTP. Change State Event: The AC receives a Change State Event Request message (see Section 8.6), to which it MUST respond with the Change State Event Response message (see Section 8.7). Echo Request: The AC receives an Echo Request message (see Section 7.1), to which it MUST respond with an Echo Response message(see Section 7.2). Clear Config Response: The AC receives a Clear Configuration Response message from the WTP (see Section 8.9). WTP Event: The AC receives a WTP Event Request message from the WTP (see Section 9.4) and MUST generate a corresponding WTP Event Response message (see Section 9.5). Data Transfer: The AC receives a Data Transfer Request message from the WTP (see Section 9.6) and MUST generate a corresponding Data Transfer Response message (see Section 9.7). Station Configuration Request: The AC sends a Station Configuration Request message (see Section 10.1) or receives the corresponding Station Configuration Response message (see Section 10.2) from the WTP. Run to Reset (r): This state transition is used when either the AC or WTP tear down the connection. This may occur as part of normal operation, or due to error conditions. WTP: The WTP enters the Reset state when it receives a Reset Request message from the AC. AC: The AC enters the Reset state when it transmits a Reset Request message to the WTP. Reset to DTLS Teardown (s): This transition occurs when the CAPWAP reset is complete, to terminate the DTLS session. Calhoun, Editor, et al. Expires September 14, 2008 [Page 29] Internet-Draft CAPWAP Protocol Specification March 2008 WTP: This state transition occurs when the WTP receives a Reset Response message. This causes the WTP to initiate the DTLSShutdown command (see Section 2.3.2.1). AC: This state transition occurs when the AC transmits a Reset Response message. The AC does not invoke the DTLSShutdown command (see Section 2.3.2.1). DTLS Teardown to Idle (t): This transition occurs when the DTLS session has been shutdown. WTP: This state transition occurs when the WTP has successfully cleaned up all resources associated with the control plane DTLS session. The data plane DTLS session is also shutdown, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. AC: This is an invalid state transition for the AC. DTLS Teardown to Sulking (u): This transition occurs when repeated attempts to setup the DTLS connection have failed. WTP: The WTP enters this state when the FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter reaches the value of the MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon entering this state, the WTP MUST start the SilentInterval timer. While in the Sulking state, all received CAPWAP and DTLS protocol messages received MUST be ignored. AC: This is an invalid state transition for the AC. DTLS Teardown to Dead (w): This transition occurs when the DTLS session has been shutdown. WTP: This is an invalid state transition for the WTP. AC: This state transition occurs when the AC has successfully cleaned up all resources associated with the control plane DTLS session. The data plane DTLS session is also shutdown, and all resources released, if a DTLS session was established for the data plane. Any timers set for the current instance of the state machine are also cleared. The AC's Service thread is terminated. Calhoun, Editor, et al. Expires September 14, 2008 [Page 30] Internet-Draft CAPWAP Protocol Specification March 2008 2.3.2. CAPWAP/DTLS Interface This section describes the DTLS Commands used by CAPWAP, and the notifications received from DTLS to the CAPWAP protocol stack. 2.3.2.1. CAPWAP to DTLS Commands Six commands are defined for the CAPWAP to DTLS API. These "commands" are conceptual, and may be implemented as one or more function calls. This API definition is provided to clarify interactions between the DTLS and CAPWAP components of the integrated CAPWAP state machine. Below is a list of the minimal command API: o DTLSStart is sent to the DTLS component to cause a DTLS session to be established. Upon invoking the DTLSStart command, the WaitDTLS timer is started. The WTP initiates this DTLS command, as the AC does not initiate DTLS sessions. o DTLSListen is sent to the DTLS component to allow the DTLS component to listen for incoming DTLS session requests. o DTLSAccept is sent to the DTLS component to allow the DTLS session establishment to continue successfully. o DTLSAbortSession is sent to the DTLS component to cause the session that is in the process of being established to be aborted. This command is also sent when the WaitDTLS timer expires. When this command is executed, the FailedDTLSSessionCount counter is incremented. o DTLSShutdown is sent to the DTLS component to cause session teardown. o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU size used by the DTLS component. See Section 3.5 for more information on MTU Discovery. The default size is 1468 bytes. 2.3.2.2. DTLS to CAPWAP Notifications DTLS notifications are defined for the DTLS to CAPWAP API. These "notifications" are conceptual, and may be implemented in numerous ways (e.g. as function return values). This API definition is provided to clarify interactions between the DTLS and CAPWAP components of the integrated CAPWAP state machine. It is important to note that the notifications listed below MAY cause the CAPWAP state machine to jump from one state to another using a state Calhoun, Editor, et al. Expires September 14, 2008 [Page 31] Internet-Draft CAPWAP Protocol Specification March 2008 transition not listed in Section 2.3.1. When a notification listed below occurs, the target CAPWAP state shown in Figure 3 becomes the current state. Below is a list of the API notifications: o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS session establishment once the peer's identity has been received. This notification MAY be used by the CAPWAP component to authorize the session, based on the peer's identity. The authorization process will lead to the CAPWAP component initiating either the DTLSAccept or DTLSAbortSession commands. o DTLSEstablished is sent to the CAPWAP component to indicate that that a secure channel now exists, using the parameters provided during the DTLS initialization process. When this notification is received, the FailedDTLSSessionCount counter is reset to zero. When this notification is received, the WaitDTLS timer is stopped. o DTLSEstablishFail is sent when the DTLS session establishment has failed, either due to a local error, or due to the peer rejecting the session establishment. When this notification is received, the FailedDTLSSessionCount counter is incremented. o DTLSAuthenticateFail is sent when DTLS session establishment failed due to an authentication error. When this notification is received, the FailedDTLSAuthFailCount counter is incremented. o DTLSAborted is sent to the CAPWAP component to indicate that session abort (as requested by CAPWAP) is complete; this occurs to confirm a DTLS session abort, or when the WaitDTLS timer expires. When this notification is received, the WaitDTLS timer is stopped. o DTLSReassemblyFailure MAY be sent to the CAPWAP component to indicate DTLS fragment reassembly failure. o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP module to indicate an encryption/authentication failure. This notification is intended for informative purposes only, and is not intended to cause a change in the CAPWAP state machine (see Section 12.4). o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the DTLS session has been torn down. Note that this notification is only received if the DTLS session has been established. Calhoun, Editor, et al. Expires September 14, 2008 [Page 32] Internet-Draft CAPWAP Protocol Specification March 2008 2.4. Use of DTLS in the CAPWAP Protocol DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP protocol. In this document DTLS and CAPWAP are discussed as nominally distinct entities; however they are very closely coupled, and may even be implemented inseparably. Since there are DTLS library implementations currently available, and since security protocols (e.g. IPsec, TLS) are often implemented in widely available acceleration hardware, it is both convenient and forward- looking to maintain a modular distinction in this document. This section describes a detailed walk-through of the interactions between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be encountered during the normal course of operation. 2.4.1. DTLS Handshake Processing Details of the DTLS handshake process are specified in [RFC4347]. This section describes the interactions between the DTLS session establishment process and the CAPWAP protocol. Note that the conceptual DTLS state is shown below to help understand the point at which the DTLS states transition. In the normal case, the DTLS handshake will proceed as follows (NOTE: this example uses certificates, but preshared keys are also supported): Calhoun, Editor, et al. Expires September 14, 2008 [Page 33] Internet-Draft CAPWAP Protocol Specification March 2008 ============ ============ WTP AC ============ ============ ClientHello ------> <------ HelloVerifyRequest (with cookie) ClientHello ------> (with cookie) <------ ServerHello <------ Certificate <------ ServerHelloDone (WTP callout for AC authorization occurs in CAPWAP Auth state) Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished ------> (AC callout for WTP authorization occurs in CAPWAP Auth state) [ChangeCipherSpec] <------ Finished DTLS, as specified, provides its own retransmit timers with an exponential back-off. However, DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period. Hence, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module. The DTLS implementation used by CAPWAP MUST support TLS Session Resumption. Session resumption is used to establish the DTLS session used for the data channel. The DTLS implementation on the WTP MUST return some unique identifier to the CAPWAP module to enable subsequent establishment of a DTLS-encrypted data channel, if necessary. 2.4.2. DTLS Session Establishment The WTP, either through the Discovery process, or through pre- configuration, determines the AC to connect to. The WTP uses the DTLSStart command to request that a secure connection be established to the selected AC. Prior to initiation of the DTLS handshake, the Calhoun, Editor, et al. Expires September 14, 2008 [Page 34] Internet-Draft CAPWAP Protocol Specification March 2008 WTP sets the WaitDTLS timer. Upon receiving the DTLSPeerAuthorize DTLS notification, the AC sets the WaitDTLS timer. If the DTLSEstablished notification is not received prior to timer expiration, the DTLS session is aborted by issuing the DTLSAbortSession DTLS command. This notification causes the CAPWAP module to transition to the Idle state. Upon receiving a DTLSEstablished notification, the WaitDTLS timer is deactivated. 2.4.3. DTLS Error Handling If the AC does not respond to any DTLS messages sent by the WTP, the DTLS specification calls for the WTP to retransmit these messages. If the WaitDTLS timer expires, CAPWAP will issue the DTLSAbortSession command, causing DTLS to terminate the handshake and remove any allocated session context. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. If the WTP does not respond to any DTLS messages sent by the AC, the CAPWAP protocol allows for three possibilities, listed below. Note that DTLS MAY send a single TLS Alert message to the AC to indicate session termination. o The message was lost in transit; in this case, the WTP will re- transmit its last outstanding message, since it did not receive a reply. o The WTP sent a DTLS Alert, which was lost in transit; in this case, the AC's WaitDTLS timer will expire, and the session will be terminated. o Communication with the WTP has completely failed; in this case, the AC's WaitDTLS timer will expire, and the session will be terminated. The DTLS specification provides for retransmission of unacknowledged requests. If retransmissions remain unacknowledged, the WaitDTLS timer will eventually expire, at which time the CAPWAP component will terminate the session. If a cookie fails to validate, this could represent a WTP error, or it could represent a DoS attack. Hence, AC resource utilization SHOULD be minimized. The AC MAY log a message indicating the failure, but SHOULD NOT attempt to reply to the WTP. Since DTLS handshake messages are potentially larger than the maximum record size, DTLS supports fragmenting of handshake messages across multiple records. There are several potential causes of re-assembly errors, including overlapping and/or lost fragments. The DTLS Calhoun, Editor, et al. Expires September 14, 2008 [Page 35] Internet-Draft CAPWAP Protocol Specification March 2008 component MUST send a DTLSReassemblyFailure notification to the CAPWAP component. Whether precise information is given along with notification is an implementation issue, and hence is beyond the scope of this document. Upon receipt of such an error, the CAPWAP component SHOULD log an appropriate error message. Whether processing continues or the DTLS session is terminated is implementation dependent. DTLS decapsulation errors consist of three types: decryption errors, authentication errors, and malformed DTLS record headers. Since DTLS authenticates the data prior to encapsulation, if decryption fails, it is difficult to detect this without first attempting to authenticate the packet. If authentication fails, a decryption error is also likely, but not guaranteed. Rather than attempt to derive (and require the implementation of) algorithms for detecting decryption failures, decryption failures are reported as authentication failures. The DTLS component MUST provide a DTLSDecapFailure notification to the CAPWAP component when such errors occur. If a malformed DTLS record header is detected, the packets SHOULD be silently discarded, and the receiver MAY log an error message. There is currently only one encapsulation error defined: MTU exceeded. As part of DTLS session establishment, the CAPWAP component informs the DTLS component of the MTU size. This may be dynamically modified at any time when the CAPWAP component sends the DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). The value provided to the DTLS stack is the result of the MTU Discovery process, which is described in Section 3.5. The DTLS component returns this notification to the CAPWAP component whenever a transmission request will result in a packet which exceeds the MTU. 2.4.4. DTLS EndPoint Authentication and Authorization DTLS supports endpoint authentication with certificates or preshared keys. The TLS algorithm suites for each endpoint authentication method are described below. 2.4.4.1. Authenticating with Certificates Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]. At present, the following algorithms MUST be supported when using certificates for CAPWAP authentication: o TLS_RSA_WITH_AES_128_CBC_SHA The following algorithms SHOULD be supported when using certificates: Calhoun, Editor, et al. Expires September 14, 2008 [Page 36] Internet-Draft CAPWAP Protocol Specification March 2008 o TLS_DH_RSA_WITH_AES_128_CBC_SHA The following algorithms MAY be supported when using certificates: o TLS_RSA_WITH_AES_256_CBC_SHA o TLS_DH_RSA_WITH_AES_256_CBC_SHA 2.4.4.2. Authenticating with Preshared Keys Pre-shared keys present significant challenges from a security perspective, and for that reason, their use is strongly discouraged. Several methods for authenticating with preshared keys are defined [RFC4279], and we focus on the following two: o PSK key exchange algorithm - simplest method, ciphersuites use only symmetric key algorithms o DHE_PSK key exchange algorithm - use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). The first approach (plain PSK) is susceptible to passive dictionary attacks; hence, while this algorithm MUST be supported, special care should be taken when choosing that method. In particular, user- readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD be strongly discouraged. The following cryptographic algorithms MUST be supported when using preshared keys: o TLS_PSK_WITH_AES_128_CBC_SHA o TLS_DHE_PSK_WITH_AES_128_CBC_SHA The following algorithms MAY be supported when using preshared keys: o TLS_PSK_WITH_AES_256_CBC_SHA o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 2.4.4.3. Certificate Usage Certificate authorization by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be Calhoun, Editor, et al. Expires September 14, 2008 [Page 37] Internet-Draft CAPWAP Protocol Specification March 2008 distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509 certificates MUST include the Extended Key Usage (EKU) certificate extension [RFC3280]. The EKU field indicates one or more purposes for which a certificate may be used. It is an essential part in authorization. Its syntax is as follows: ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER Here we define two KeyPurposeId values, one for the WTP and one for the AC. Inclusion of one of these two values indicates a certificate is authorized for use by a WTP or AC, respectively. These values are formatted as id-kp fields. id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } All capwap devices MUST support the ExtendedKeyUsage certificate extension if it is present in a certificate. If the extension is present, then the certificate MUST have either the id-kp-capwapAC or the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. Similarly, if the extension is present, a device must have the id-kp- capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. Part of the CAPWAP certificate validation process includes ensuring that the proper EKU is included and allowing the CAPWAP session to be established only if the extension properly represents the device. For instance, an AC SHOULD NOT accept a connection request from another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is present in the certificate. CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device. The MAC address MUST be formatted as ASCII HEX, e.g. 01:23:45:67:89:ab. Note that the CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. ACs and WTPs MUST authorize (e.g. through access control lists) certificates of devices to which they are connecting, e.g., based on Calhoun, Editor, et al. Expires September 14, 2008 [Page 38] Internet-Draft CAPWAP Protocol Specification March 2008 the issuer, MAC address, or organizational information specified in the certificate. The identities specified in the certificates bind a particular DTLS session to a specific pair of mutually-authenticated and authorized MAC addresses. The particulars of authorization filter construction are implementation details which are, for the most part, not within the scope of this specification. However, at minimum, all devices MUST verify that the appropriate EKU bit is set according to the role of the peer device (AC vs. WTP), and that the issuer of the certificate is appropriate for the domain in question. 2.4.4.4. PSK Usage When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST contain the "PSK identity hint" field and the ClientKeyExchange message MUST contain the "PSK identity" field. These fields are used to help the WTP select the appropriate PSK for use with the AC, and then indicate to the AC which key is being used. When PSKs are provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for the key MUST be specified. The PSK Hint SHOULD uniquely identify the AC and the PSK Identity SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints and identities be the ASCII HEX-formatted MAC addresses of the respective devices, since each pairwise combination of WTP and AC SHOULD have a unique PSK. The PSK hint and identity SHOULD be sufficient to perform authorization, as simply having knowledge of a PSK does not necessarily imply authorization. If a single PSK is being used for multiple devices on a CAPWAP network, which is NOT RECOMMENDED, the PSK Hint and Identity can no longer be a MAC address, so appropriate hints and identities SHOULD be selected to identify the group of devices to which the PSK is provisioned. Calhoun, Editor, et al. Expires September 14, 2008 [Page 39] Internet-Draft CAPWAP Protocol Specification March 2008 3. CAPWAP Transport Communication between a WTP and an AC is established using the standard UDP client/server model. The CAPWAP protocol supports both UDP and UDP-Lite [RFC3828] transport protocols. When run over IPv4, UDP is used for the CAPWAP control and data channels. When run over IPv6, the CAPWAP control channel always uses UDP, while the CAPWAP data channel may use either UDP or UDP-Lite. UDP-Lite is the default transport protocol for the CAPWAP data channel. However, if a middlebox or IPv4 to IPv6 gateway has been discovered, UDP is used for the CAPWAP data channel. This section describes how the CAPWAP protocol is carried over IP and UDP/UDP-Lite transport protocols. The CAPWAP Transport Protocol message element Section 4.6.15 describes the rules to use in determining which transport protocol is to be used. 3.1. UDP Transport One of the CAPWAP protocol requirements is to allow a WTP to reside behind a middlebox, firewall and/or Network Address Translation (NAT) device. Since a CAPWAP session is initiated by the WTP (client) to the well-known UDP port of the AC (server), the use of UDP is a logical choice. The UDP checksum field in CAPWAP packets MUST be set to zero. CAPWAP protocol control packets sent from the WTP to the AC use the CAPWAP control channel, as defined in Section 1.4. The CAPWAP control port at the AC is the well known UDP port [to be IANA assigned]. The CAPWAP control port at the WTP can be any port selected by the WTP. CAPWAP protocol data packets sent from the WTP to the AC use the CAPWAP data channel, as defined in Section 1.4. The CAPWAP data port at the AC is the well known UDP port [to be IANA assigned]. The CAPWAP data port at the WTP can be any port selected by the WTP. 3.2. UDP-Lite Transport When CAPWAP is run over IPv6, UDP-Lite is the default transport protocol, which reduces the checksum processing required for each packet (compared to the use of UDP over IPv6 [RFC1883]). When UDP- Lite is used, the checksum field MUST have a coverage of 8 [RFC3828]. UDP-Lite uses the same port assignments as UDP. Calhoun, Editor, et al. Expires September 14, 2008 [Page 40] Internet-Draft CAPWAP Protocol Specification March 2008 3.3. AC Discovery The AC discovery phase allows the WTP to determine which ACs are available, and chose the best AC with which to establish a CAPWAP session. The discovery phase occurs when the WTP enters the optional Discovery state. A WTP does not need to complete the AC Discovery phase if it uses a pre-configured AC. This section details the mechanism used by a WTP to dynamically discover candidate ACs. A WTP and an AC will frequently not reside in the same IP subnet (broadcast domain). When this occurs, the WTP must be capable of discovering the AC, without requiring that multicast services are enabled in the network. When the WTP attempts to establish communication with an AC, it sends the Discovery Request message and receives the Discovery Response message from the AC(s). The WTP MUST send the Discovery Request message to either the limited broadcast IP address (255.255.255.255), a well known multicast address or to the unicast IP address of the AC. For IPv6 networks, since broadcast does not exist, the use of "All ACs multicast address" is used instead. Upon receipt of the Discovery Request message, the AC sends a Discovery Response message to the unicast IP address of the WTP, regardless of whether the Discovery Request message was sent as a broadcast, multicast or unicast message. WTP use of a limited IP broadcast, multicast or unicast IP address is implementation dependent. When a WTP transmits a Discovery Request message to a unicast address, the WTP must first obtain the IP address of the AC. Any static configuration of an AC's IP address on the WTP non-volatile storage is implementation dependent. However, additional dynamic schemes are possible, for example: DHCP: See [I-D.calhoun-dhc-capwap-ac-option] for more information on the use of DHCP to discover AC IP addresses. DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or more AC addresses. An AC MAY also communicate alternative ACs to the WTP within the Discovery Response message through the AC IPv4 List (see Section 4.6.2) and AC IPv6 List (see Section 4.6.2). The addresses provided in these two message elements are intended to help the WTP discover additional ACs through means other than those listed above. The AC Name with Index message element (see Section 4.6.5), is used Calhoun, Editor, et al. Expires September 14, 2008 [Page 41] Internet-Draft CAPWAP Protocol Specification March 2008 to communicate a list of preferred ACs to the WTP. The WTP SHOULD attempt to utilize the ACs listed in the order provided by the AC. The Name to IP Address mapping is handled via the Discovery message exchange, in which the ACs provide their identity in the AC Name (see Section 4.6.4) message element in the Discovery Response message. Once the WTP has received Discovery Response messages from the candidate ACs, it MAY use other factors to determine the preferred AC. For instance, each binding defines a WTP Radio Information message element (see Section 2.1), which the AC includes in Discovery Response messages. The presence of one or more of these message elements is used to identify the CAPWAP bindings supported by the AC. A WTP MAY connect to an AC based on the supported bindings advertised. 3.4. Fragmentation/Reassembly While fragmentation and reassembly services are provided by IP, the CAPWAP protocol also provides such services. Environments where the CAPWAP protocol is used involve firewall, NAT and "middle box" devices, which tend to drop IP fragments to minimize possible DoS attacks. By providing fragmentation and reassembly at the application layer, any fragmentation required due to the tunneling component of the CAPWAP protocol becomes transparent to these intermediate devices. Consequently, the CAPWAP protocol can be used in any network configuration. 3.5. MTU Discovery Once a WTP has discovered the AC it wishes to establish a CAPWAP session with, it SHOULD perform a Path MTU (PMTU) discovery. The MTU discovered is used to configure the DTLS component (see Section 2.3.2.1), while non-DTLS frames need to be fragmented to fit the MTU, defined in Section 3.4. The procedures described in [RFC1191], for IPv4, or [RFC1981], for IPv6 SHOULD be used. Alternatively, implementers MAY use the procedures defined in [RFC4821]. The WTP SHOULD also periodically re-evaluate the MTU using the guidelines provided in these two RFCs. Calhoun, Editor, et al. Expires September 14, 2008 [Page 42] Internet-Draft CAPWAP Protocol Specification March 2008 4. CAPWAP Packet Formats This section contains the CAPWAP protocol packet formats. A CAPWAP protocol packet consists of one or more CAPWAP Transport Layer packet headers followed by a CAPWAP message. The CAPWAP message can be either of type Control or Data, where Control packets carry signaling, and Data packets carry user payloads. The CAPWAP frame formats for CAPWAP Data packets, and for DTLS encapsulated CAPWAP Data and Control packets are defined below. The CAPWAP Control protocol includes two messages that are never protected by DTLS: the Discovery Request message and the Discovery Response message. These messages need to be in the clear to allow the CAPWAP protocol to properly identify and process them. The format of these packets are as follows: CAPWAP Control Packet (Discovery Request/Response): +-------------------------------------------+ | IP | UDP | CAPWAP | Control | Message | | Hdr | Hdr | Header | Header | Element(s) | +-------------------------------------------+ All other CAPWAP control protocol messages MUST be protected via the DTLS protocol, which ensures that the packets are both authenticated and encrypted. These packets include the CAPWAP DTLS Header, which is described in Section 4.2. The format of these packets is as follows: CAPWAP Control Packet (DTLS Security Required): +------------------------------------------------------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Control| Message | DTLS | | Hdr | Hdr | DTLS Hdr | Hdr | Header | Header | Element(s)| Trlr | +------------------------------------------------------------------+ \---------- authenticated -----------/ \------------- encrypted ------------/ The CAPWAP protocol allows optional protection of data packets, using DTLS. Use of data packet protection is determined by AC policy. When DTLS is utilized, the optional CAPWAP DTLS Header is present, which is described in Section 4.2. The format of CAPWAP data packets is shown below: Calhoun, Editor, et al. Expires September 14, 2008 [Page 43] Internet-Draft CAPWAP Protocol Specification March 2008 CAPWAP Plain Text Data Packet : +-------------------------------+ | IP | UDP | CAPWAP | Wireless | | Hdr | Hdr | Header | Payload | +-------------------------------+ DTLS Secured CAPWAP Data Packet: +--------------------------------------------------------+ | IP | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS | | Hdr | Hdr | DTLS Hdr | Hdr | Hdr | Payload | Trlr | +--------------------------------------------------------+ \------ authenticated -----/ \------- encrypted --------/ UDP Header: All CAPWAP packets are encapsulated within either UDP, or UDP-Lite when used over IPv6. Section 3 defines the specific UDP or UDP-Lite usage. CAPWAP DTLS Header: All DTLS encrypted CAPWAP protocol packets are prefixed with the CAPWAP DTLS header (see Section 4.2). DTLS Header: The DTLS header provides authentication and encryption services to the CAPWAP payload it encapsulates. This protocol is defined in RFC 4347 [RFC4347]. CAPWAP Header: All CAPWAP protocol packets use a common header that immediately follows the CAPWAP preamble or DTLS header. The CAPWAP Header is defined in Section 4.3. Wireless Payload: A CAPWAP protocol packet that contains a wireless payload is a CAPWAP data packet. The CAPWAP protocol does not specify the format of the wireless payload, which is defined by the appropriate wireless standard. Additional information is in Section 4.4. Control Header: The CAPWAP protocol includes a signaling component, known as the CAPWAP control protocol. All CAPWAP control packets include a Control Header, which is defined in Section 4.5.1. CAPWAP data packets do not contain a Control Header field. Message Elements: A CAPWAP Control packet includes one or more message elements, which are found immediately following the Control Header. These message elements are in a Type/Length/value style header, defined in Section 4.6. A CAPWAP implementation MUST be capable of receiving a reassembled CAPWAP message of length 4096 bytes. A CAPWAP implementation MAY indicate that it supports a higher maximum message length, by Calhoun, Editor, et al. Expires September 14, 2008 [Page 44] Internet-Draft CAPWAP Protocol Specification March 2008 including the Maximum Message Length message element, see Section 4.6.32 in the Join Request message or the Join Response message. 4.1. CAPWAP Preamble The CAPWAP preamble is common to all CAPWAP transport headers and is used to identify the header type that immediately follows. The reason for this header is to avoid needing to perform byte comparisons in order to guess whether the frame is DTLS encrypted or not. It also provides an extensibility framework that can be used to support additional transport types. The format of the preamble is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Version| Type | +-+-+-+-+-+-+-+-+ Version: A 4 bit field which contains the version of CAPWAP used in this packet. The value for this specification is zero (0). Payload Type: A 4 bit field which specifies the payload type that follows the UDP header. The following values are supported: 0 - CAPWAP Header. The CAPWAP Header (see Section 4.3) immediately follows the UDP header. If the packet is received on the CAPWAP data channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP data packet. If received on the CAPWAP control channel, the CAPWAP stack MUST treat the packet as a clear text CAPWAP control packet. If the control packet is not a Discovery Request or Discovery Response packet, the packet MUST be dropped. 1 - CAPWAP DTLS Header. The CAPWAP DTLS Header, and DTLS packet, immediately follows the UDP header (see Section 4.2). 4.2. CAPWAP DTLS Header The CAPWAP DTLS Header is used to identify the packet as a DTLS encrypted packet. The first eight bits includes the common CAPWAP Preamble. The remaining 24 bits are padding to ensure 4 byte alignment, and MAY be used in a future version of the protocol. The DTLS packet [RFC4347] always immediately follows this header. The format of the CAPWAP DTLS Header is as follows: Calhoun, Editor, et al. Expires September 14, 2008 [Page 45] Internet-Draft CAPWAP Protocol Specification March 2008 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |CAPWAP Preamble| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble's Payload Type field MUST be set to one (1). Reserved: The 24-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. 4.3. CAPWAP Header All CAPWAP protocol messages are encapsulated using a common header format, regardless of the CAPWAP Control or CAPWAP Data transport used to carry the messages. However, certain flags are not applicable for a given transport. Refer to the specific transport section in order to determine which flags are valid. Note that the optional fields defined in this section MUST be present in the precise order shown below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fragment ID | Frag Offset |Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Radio MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (optional) Wireless Specific Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CAPWAP Preamble: The CAPWAP Preamble is defined in Section 4.1. The CAPWAP Preamble's Payload Type field MUST be set to zero (0). If the CAPWAP DTLS Header is present, the version number in both CAPWAP Preambles MUST match. The reason for this duplicate field is to avoid any possible tampering of the version field in the preamble which is not encrypted or authenticated. Calhoun, Editor, et al. Expires September 14, 2008 [Page 46] Internet-Draft CAPWAP Protocol Specification March 2008 HLEN: A 5 bit field containing the length of the CAPWAP transport header in 4 byte words (Similar to IP header length). This length includes the optional headers. RID: A 5 bit field which contains the Radio ID number for this packet. Given that MAC Addresses are not necessarily unique across physical radios in a WTP, the Radio Identifier (RID) field is used to indicate which physical radio the message is associated with. WBID: A 5 bit field which is the wireless binding identifier. The identifier will indicate the type of wireless packet associated with the radio. The following values are defined: 1 - IEEE 802.11 2 - IEEE 802.16 3 - EPCGlobal T: The Type 'T' bit indicates the format of the frame being transported in the payload. When this bit is set to one (1), the payload has the native frame format indicated by the WBID field. When this bit is zero (0) the payload is an IEEE 802.3 frame. F: The Fragment 'F' bit indicates whether this packet is a fragment. When this bit is one (1), the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the WTP and AC. L: The Last 'L' bit is valid only if the 'F' bit is set and indicates whether the packet contains the last fragment of a fragmented exchange between WTP and AC. When this bit is 1, the packet is the last fragment. When this bit is 0, the packet is not the last fragment. W: The Wireless 'W' bit is used to specify whether the optional Wireless Specific Information field is present in the header. A value of one (1) is used to represent the fact that the optional header is present. M: The M bit is used to indicate that the Radio MAC Address optional header is present. This is used to communicate the MAC address of the receiving radio. Calhoun, Editor, et al. Expires September 14, 2008 [Page 47] Internet-Draft CAPWAP Protocol Specification March 2008 K: The 'Keep-alive' K bit indicates the packet is a Data Channel Keep Alive packet. This packet is used to map the data channel to the control channel for the specified Session ID and to maintain freshness of the data channel. The K bit MUST NOT be set for data packets containing user data. Flags: A set of reserved bits for future flags in the CAPWAP header. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Fragment ID: A 16 bit field whose value is assigned to each group of fragments making up a complete set. The fragment ID space is managed individually for every WTP/AC pair. The value of Fragment ID is incremented with each new set of fragments. The Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. Fragment Offset: A 13 bit field that indicates where in the payload this fragment belongs during re-assembly. This field is valid when the 'F' bit is set to 1. The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero. Note the CAPWAP protocol does not allow for overlapping fragments. Reserved: The 3-bit field is reserved for future use. All implementations complying with this protocol MUST set to zero any bits that are reserved in the version of the protocol supported by that implementation. Receivers MUST ignore all bits not defined for the version of the protocol they support. Radio MAC Address: This optional field contains the MAC address of the radio receiving the packet. This is useful in packets sent from the WTP to the AC, when the native wireless frame format is converted to 802.3 by the WTP. This field is only present if the 'M' bit is set. The HLEN field assumes 4 byte alignment, and this field MUST be padded with zeroes (0x00) if it is not 4 byte aligned. The field contains the basic format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Editor, et al. Expires September 14, 2008 [Page 48] Internet-Draft CAPWAP Protocol Specification March 2008 Length: The length of the MAC Address field [EUI-48] [EUI-64]. MAC Address: The MAC Address of the receiving radio. Wireless Specific Information: This optional field contains technology specific information that may be used to carry per packet wireless information. This field is only present if the 'W' bit is set. The WBID field in the CAPWAP header is used to identify the format of the wireless specific information optional field. The HLEN field assumes 4 byte alignment, and this field MUST be padded with zeroes (0x00) if it is not 4 byte aligned. The Wireless Specific Information field uses the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: The length of the data field Data: Wireless specific information, defined by the wireless specific binding specified in the CAPWAP Header's WBID field. Payload: This field contains the header for a CAPWAP Data Message or CAPWAP Control Message, followed by the data contained in the message. 4.4. CAPWAP Data Messages There are two different types of CAPWAP data packets, CAPWAP Data Channel Keep Alive packets and Data Payload packets. The first is used by the WTP to synchronize the control and data channels, and to maintain freshness of the data channel. The second is used to transmit user payloads between the AC and WTP. This section describes both types of CAPWAP data packet formats. Both CAPWAP data messages are transmitted on the CAPWAP data channel. 4.4.1. CAPWAP Data Keepalive The CAPWAP Data Channel Keep Alive packet is used to bind the CAPWAP control channel with the data channel, and to maintain freshness of the data channel, ensuring that the channel is still functioning. The CAPWAP Data Channel Keep Alive packet is transmitted by the WTP when the DataChannelKeepAlive timer expires. When the CAPWAP Data Channel Keep Alive packet is transmitted, the WTP sets the Calhoun, Editor, et al. Expires September 14, 2008 [Page 49] Internet-Draft CAPWAP Protocol Specification March 2008 DataChannelDeadInterval timer. In the CAPWAP Data Channel Keep Alive packet, all of the fields in the CAPWAP header, except the HLEN field and the K bit, are set to zero upon transmission. Upon receiving a CAPWAP Data Channel Keep Alive packet, the AC transmits a CAPWAP Data Channel Keep Alive packet back to the WTP. The contents of the transmitted packet are identical to the contents of the received packet. Upon receiving a CAPWAP Data Channel Keep Alive packet, the WTP cancels the DataChannelDeadInterval timer and resets the DataChannelKeepAlive timer. The CAPWAP Data Channel Keep Alive packet is retransmitted by the WTP in the same manner as the CAPWAP control messages. If the DataChannelDeadInterval timer expires, the WTP tears down the control DTLS session, and the data DTLS session if one existed. The CAPWAP Data Channel Keep Alive packet contains the following payload immediately following the CAPWAP Header (see Section 4.3) 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Element Length | Message Element [0..N] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Element Length: The Length field indicates the number of bytes following the CAPWAP Header. Message Element[0..N]: The message element(s) carry the information pertinent to each of the CAPWAP Data Keepalive message. The following message elements MUST be present in this CAPWAP message: Session ID, see Section 4.6.37 4.4.2. Data Payload A CAPWAP protocol Data Payload packet encapsulates a forwarded wireless frame. The CAPWAP protocol defines two different modes of encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 encapsulation requires that for 802.11 frames, the 802.11 *Integration* function be performed in the WTP. An IEEE 802.3 encapsulated user payload frame has the following format: +------------------------------------------------------+ | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | +------------------------------------------------------+ Calhoun, Editor, et al. Expires September 14, 2008 [Page 50] Internet-Draft CAPWAP Protocol Specification March 2008 The CAPWAP protocol also defines the native wireless encapsulation mode. The format of the encapsulated CAPWAP data frame is subject to the rules defined by the specific wireless technology binding. Each wireless technology binding MUST contain a section entitled "Payload Encapsulation", which defines the format of the wireless payload that is encapsulated within CAPWAP Data packets. For 802.3 payload frames, the 802.3 frame is encapsulated (excluding the IEEE 802.3 FCS checksum). If the encapsulated frame would exceed the transport layer's MTU, the sender is responsible for fragmentation of the frame, as specified in Section 3.4. 4.4.3. Establishment of a DTLS Data Channel If the AC and WTP are configured to tunnel the data channel over DTLS, the proper DTLS session must be initiated. To avoid having to reauthenticate and reauthorize an AC and WTP, the DTLS data channel MUST be initiated using the TLS session resumption feature [RFC4346]. When establishing the DTLS-encrypted data channel, the WTP MUST provide the identifier returned during the initialization of the control channel to the DTLS component so it can perform the resumption using the proper session information. The AC DTLS implementation MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down. 4.5. CAPWAP Control Messages The CAPWAP Control protocol provides a control channel between the WTP and the AC. Control messages are divided into the following message types: Discovery: CAPWAP Discovery messages are used to identify potential ACs, their load and capabilities. Join: CAPWAP Join messages are used by a WTP to request service from an AC, and for the AC to respond to the WTP. Control Channel Management: CAPWAP control channel management messages are used to maintain the control channel. WTP Configuration Management: The WTP Configuration messages are used by the AC to deliver a specific configuration to the WTP. Messages which retrieve statistics from a WTP are also included in WTP Configuration Management. Calhoun, Editor, et al. Expires September 14, 2008 [Page 51] Internet-Draft CAPWAP Protocol Specification March 2008 Station Session Management: Station Session Management messages are used by the AC to deliver specific station policies to the WTP. Device Management Operations: Device management operations are used to request and deliver a firmware image to the WTP. Binding Specific CAPWAP Management Messages: Messages in this category are used by the AC and the WTP to exchange protocol- specific CAPWAP management messages. These messages may or may not be used to change the link state of a station. Discovery, Join, Control Channel Management, WTP Configuration Management and Station Session Management CAPWAP control messages MUST be implemented. Device Management Operations messages MAY be implemented. CAPWAP control messages sent from the WTP to the AC indicate that the WTP is operational, providing an implicit keep-alive mechanism for the WTP. The Control Channel Management Echo Request and Echo Response messages provide an explicit keep-alive mechanism when other CAPWAP control messages are not exchanged. 4.5.1. Control Message Format All CAPWAP control messages are sent encapsulated within the CAPWAP header (see Section 4.3). Immediately following the CAPWAP header, is the control header, which has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq Num | Msg Element Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Element [0..N] ... +-+-+-+-+-+-+-+-+-+-+-+-+ 4.5.1.1. Message Type The Message Type field identifies the function of the CAPWAP control message. The Message Type field is comprised of an IANA Enterprise Number and an enterprise specific message type number. The first three octets contain the enterprise number in network byte order, with zero used for CAPWAP protocol defined message types and the IEEE 802.11 IANA assigned enterprise number 13277 is used for IEEE 802.11 technology specific message types. The last octet is the enterprise specific message type number, which has a range from 0 to 255. Calhoun, Editor, et al. Expires September 14, 2008 [Page 52] Internet-Draft CAPWAP Protocol Specification March 2008 The message type field is defined as: Message Type = IANA Enterprise Number * 256 + Enterprise Specific Message Type Number The CAPWAP protocol reliability mechanism requires that messages be defined in pairs, consisting of both a Request and a Response message. The Response message MUST acknowledge the Request message. The assignment of CAPWAP control Message Type Values always occurs in pairs. All Request messages have odd numbered Message Type Values, and all Response messages have even numbered Message Type Values. The Request value MUST be assigned first. As an example, assigning a Message Type Value of 3 for a Request message and 4 for a Response message is valid, while assigning a Message Type Value of 4 for a Response message and 5 for the corresponding Request message is invalid. When a WTP or AC receives a message with a Message Type Value field that is not recognized and is an odd number, the number in the Message Type Value Field is incremented by one, and a Response message with a Message Type Value field containing the incremented value and containing the Result Code message element with the value (Unrecognized Request) is returned to the sender of the received message. If the unknown message type is even, the message is ignored. The valid values for CAPWAP Control Message Types are specified in the table below: Calhoun, Editor, et al. Expires September 14, 2008 [Page 53] Internet-Draft CAPWAP Protocol Specification March 2008 CAPWAP Control Message Message Type Value Discovery Request 1 Discovery Response 2 Join Request 3 Join Response 4 Configuration Status 5 Configuration Status Response 6 Configuration Update Request 7 Configuration Update Response 8 WTP Event Request 9 WTP Event Response 10 Change State Event Request 11 Change State Event Response 12 Echo Request 13 Echo Response 14 Image Data Request 15 Image Data Response 16 Reset Request 17 Reset Response 18 Primary Discovery Request 19 Primary Discovery Response 20 Data Transfer Request 21 Data Transfer Response 22 Clear Configuration Request 23 Clear Configuration Response 24 Station Configuration Request 25 Station Configuration Response 26 4.5.1.2. Sequence Number The Sequence Number Field is an identifier value used to match Request and Response packets. When a CAPWAP packet with a Request Message Type Value is received, the value of the Sequence Number field is copied into the corresponding Response message. When a CAPWAP control message is sent, the sender's internal sequence number counter is monotonically incremented, ensuring that no two pending Request messages have the same Sequence Number. The Sequence Number field wraps back to zero. 4.5.1.3. Message Element Length The Length field indicates the number of bytes following the Sequence Number field. Calhoun, Editor, et al. Expires September 14, 2008 [Page 54] Internet-Draft CAPWAP Protocol Specification March 2008 4.5.1.4. Flags The Flags field MUST be set to zero. 4.5.1.5. Message Element[0..N] The message element(s) carry the information pertinent to each of the control message types. Every control message in this specification specifies which message elements are permitted. When a WTP or AC receives a CAPWAP message without a message element that is specified as mandatory for the CAPWAP message, then the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Missing Mandatory Message Element" is returned to the sender. When a WTP or AC receives a CAPWAP message with a message element that the WTP or AC does not recognize, the CAPWAP message is discarded. If the received message was a Request message for which the corresponding Response message carries message elements, then a corresponding Response message with a Result Code message element indicating "Failure - Unrecognized Message Element" and one or more Returned Message Element message elements is included, containing the unrecognized message element(s). 4.5.2. Control Message Quality of Service It is recommended that CAPWAP control messages be sent by both the AC and the WTP with an appropriate Quality of Service precedence value, ensuring that congestion in the network minimizes occurrences of CAPWAP control channel disconnects. Therefore, a Quality of Service enabled CAPWAP device SHOULD use the following values: 802.1P: The precedence value of 7 SHOULD be used. DSCP: The DSCP tag value of 46 SHOULD be used. 4.5.3. Retransmissions The CAPWAP control protocol operates as a reliable transport. For each Request message, a Response message is defined, which is used to acknowledge receipt of the Request message. In addition, the control header Sequence Number field is used to pair the Request and Response messages (see Section 4.5.1). Response messages are not explicitly acknowledged, therefore if a Calhoun, Editor, et al. Expires September 14, 2008 [Page 55] Internet-Draft CAPWAP Protocol Specification March 2008 Response message is not received, the original Request message is retransmitted. Implementations MAY cache Response messages to respond to a retransmitted Request messages with minimal local processing. Retransmitted R