Network Working Group S. Govindan, Ed. Request for Comments: 4564 H. Cheng Category: Informational Panasonic ZH. Yao Huawei WH. Zhou China Mobile L. Yang Intel July 2006 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability among Wireless Local Area Network (WLAN) devices of alternative designs.
1. Introduction ....................................................3 2. Terminology .....................................................3 3. Requirements Notation ...........................................4 4. Objectives Overview .............................................4 5. Objectives ......................................................5 5.1. Mandatory and Accepted Objectives ..........................5 5.1.1. Logical Groups ......................................5 5.1.2. Support for Traffic Separation ......................6 5.1.3. Wireless Terminal Transparency ......................8 5.1.4. Configuration Consistency ...........................8 5.1.5. Firmware Trigger ....................................9 5.1.6. Monitoring and Exchange of System-wide Resource State .....................................10 5.1.7. Resource Control Objective .........................11 5.1.8. CAPWAP Protocol Security ...........................12 5.1.9. System-wide Security ...............................14 5.1.10. IEEE 802.11i Considerations .......................15 5.1.11. Interoperability Objective .......................17 5.1.12. Protocol Specifications ..........................18 5.1.13. Vendor Independence ..............................19 5.1.14. Vendor Flexibility ...............................19 5.1.15. NAT Traversal ....................................20 5.2. Desirable Objectives ......................................21 5.2.1. Multiple Authentication Mechanisms .................21 5.2.2. Support for Future Wireless Technologies ...........21 5.2.3. Support for New IEEE Requirements ..................22 5.2.4. Interconnection Objective ..........................23 5.2.5. Access Control ....................................24 5.3. Non-Objectives ............................................25 5.3.1. Support for Non-CAPWAP WTPs ........................25 5.3.2. Technical Specifications ...........................26 5.4. Operator Requirements .....................................27 5.4.1. AP Fast Handoff ....................................27 6. Summary and Conclusion .........................................27 7. Security Considerations ........................................28 8. Acknowledgements ...............................................29 9. Normative References ...........................................29 10. Informative References ........................................29
RFC3990]. Many vendors have addressed these challenges by developing new architectures and solutions. A survey of the various developments was conducted to better understand the context of these challenges. This survey is a first step towards designing interoperability among the solutions. The Architecture Taxonomy [RFC4118] is a result of this survey in which major WLAN architecture families are classified. Broadly, these are the autonomous, centralized WLAN, and distributed mesh architectures. The Architecture Taxonomy identified the centralized WLAN architecture as one in which portions of the wireless medium access control (MAC) operations are centralized in a WLAN controller. This centralized WLAN architecture is further classified into remote-MAC, split-MAC, and local-MAC designs. Each differs in the degree of separation of wireless MAC layer capabilities between WTPs and WLAN controller. This document puts forward critical objectives for achieving interoperability in the CAPWAP framework. It presents requirements that address the challenges of controlling and provisioning large- scale WLAN deployments. The realization of these objectives in a CAPWAP protocol will ensure that WLAN equipment of major design types may be integrally deployed and managed. RFC4118], [802.11], [802.11i], and [802.11e]. Additionally, the following terms are defined. Centralized WLAN: A WLAN based on the centralized WLAN Architecture [RFC4118]. Switching Segment: Those aspects of a centralized WLAN that primarily deal with switching or routing of control and data information between Wireless Termination Points (WTPs) and the WLAN controller.
Wireless Medium Segment: Those aspects of a centralized WLAN that primarily deal with the wireless interface between WTPs and wireless terminals. The Wireless Medium Segment is specific to layer 2 wireless technology, such as IEEE 802.11. CAPWAP Framework: A term that covers the local-MAC and split-MAC designs of the Centralized WLAN Architecture. Standardization efforts are focused on these designs. CAPWAP Protocol: The protocol between WLAN controller and WTPs in the CAPWAP framework. It facilitates control, management, and provisioning of WTPs in an interoperable manner. Logical Group: A logical separation of a physical WTP is termed logical group. So a single physical WTP will operate a number of logical groups. Virtual access points (APs) are examples of logical groups. Here, each Basic Service Set Identifier (BSSID) and constituent wireless terminals' radios are denoted as distinct logical groups of a physical WTP. Logical groups are maintained without conflicting with the CAPWAP objectives, particularly the 'Wireless Terminal Transparency' objective. RFC2119].
Additionally, a general classification is used for objectives relating to the overall impact of the CAPWAP protocol specifications.
In traditional WLANs, each physical WTP represents one complete subset of a larger WLAN system. Shared WLANs differ in that each physical WTP represents a number of logical subsets of possibly a number of larger WLAN systems. Each logical division of a physical WTP is referred to as a logical group (see definition in Section 2). So WLANs are managed in terms of logical groups instead of physical WTPs. Logical groups are based on BSSIDs and other types of virtual APs. Protocol Requirement: The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups. For all operating modes, including those in which the WTP performs local bridging and those in which the Access Controller (AC) performs centralized bridging, the protocol MUST provide provisions for configuring logical groups at the WTP. Motivation and Protocol Benefits: Commercial realities necessitate that WLANs be manageable in terms of their logical groups. This allows separation of logical services and underlying infrastructure management. A protocol that realizes this need ensures simpler and cost-effective WLANs, which directly address the requirements of network service operators. Relation to Problem Statement: This objective addresses the problem of management complexity in terms of costs. Cost complexity is reduced by sharing WLAN deployments. Consequently, deployment and management cost- efficiencies are realized.
states that control and data aspects of the exchanges be mutually separated for further simplicity. This will allow solutions for each type of exchange to be independently optimized. Furthermore, in the context of shared WLAN deployments, the mutual separation of control and data also addresses security concerns. In particular, given the likelihood of different logical groups, such as those established by different virtual APs, being managed by different administrators, separation of control and data is a first step towards individually containing and securing the logical groups. It is also important to ensure that traffic from each logical group is mutually separated to maintain the integrity and independence of the logical groups. Protocol Requirement: The CAPWAP protocol MUST define transport control messages such that the transport of control messages is separate from the transport of data messages. Motivation and Protocol Benefits: The aim of separating data and control aspects of the protocol is to simplify the protocol. It also allows for the flexibility of addressing each type of traffic in the most appropriate manner. Furthermore, this requirement will help remotely located WTPs to handle data traffic in alternative ways without the need for forwarding them across a wide network to the WLAN controller. Separation of WTP control and data also aids in the secure realization of shared WLAN deployments. Relation to Problem Statement: Broadly, this objective relates to the challenge of managing complexity in large-scale WLANs. The requirement for traffic separation simplifies control as this is separated from the task of data transport.
Protocol Requirement: The CAPWAP protocol MUST include support for regular exchanges of state information between WTPs and the WLAN controller. Examples of state information include WTP processing load and memory utilization. Motivation and Protocol Benefits: A protocol that provides access to regular state information can in turn be used to enhance WLAN configuration and performance. The CAPWAP protocol will be better equipped to address configuration- related problems with the regularly available state information. So with greater state information, control and management operations can be improved. Relation to Problem Statement: One of the major challenges described in the Problem Statement is that of maintaining consistent configuration across the numerous WTPs of a WLAN. This objective addresses the fundamental issue behind this -- availability of timely state information.
Relation to Problem Statement: Inconsistencies in the configuration of WTPs have been identified as a major challenge for large-scale WTPs. This objective helps overcome the challenge by providing a way for the CAPWAP protocol to initiate delivery of firmware updates that are compatible among all WTPs.
Relation to Problem Statement: The Problem Statement highlights the challenge of dealing with large numbers of WTPs and the dynamic nature of the wireless medium. Information on the state of WTPs and the medium is important to deal with them effectively. So this objective relates to the problem of managing consistency in large WLANs.
Motivation and Protocol Benefits: A protocol that addresses QoS aspects of WLAN systems will deliver high performance thereby being beneficial for subscribers and for resource utilization efficiency. Since CAPWAP deals with WTPs directly and with the wireless medium indirectly, both of these must be considered for performance. For the wireless medium segment, QoS aspects in the protocol enable high-quality communications within the domain of a WLAN controller. Since each domain generally covers an enterprise or a group of service providers, such protocol performance has wide-ranging effects. Within the switching segment of CAPWAP, a QoS-enabled protocol minimizes the adverse effects of dynamic traffic characteristics so as to ensure system-wide performance. Relation to Problem Statement: QoS control is critical to large WLANs and relates to a number of aspects. In particular, this objective can help address the problem of managing dynamic conditions of the wireless medium. Furthermore, traffic characteristics in large-scale WLANs are constantly varying. So network utilization becomes inefficient, and user experience is unpredictable. The interaction and coordination between the two aspects of system- wide QoS are therefore critical for performance.
If authentication is performed via an authenticated key exchange, future knowledge of derived keys is not sufficient for authentication. Any session keys used between the WLAN controller and WTPs MUST be mutually derived using entropy contributed by both parties. This ensures that no one party has control over the resulting session keys. Once WTPs and the WLAN controller have been mutually authenticated, information exchanges between them must be secured against various security threats. So the CAPWAP protocol MUST provide integrity protection and replay protection. The protocol SHOULD provide confidentiality through encryption. This should cover illegitimate modifications to protocol exchanges, eavesdropping, and Denial of Service (DoS) attacks, among other potential compromises. So the protocol must provide confidentiality, integrity, and authenticity for those exchanges. As a result of realizing this objective, it should not be possible for individual WTP breaches to affect the security of the WLAN as a whole. So WTP misuse will be protected against. Additionally, the key establishment protocol for authentication and securing CAPWAP exchanges must be designed to minimize the possibility of future compromises after the keys are established. CAPWAP MUST NOT prevent the use of asymmetric authentication. The security considerations of such asymmetric authentication are described in the Security Considerations section. If the CAPWAP protocol meets the criteria to require automated key management per BCP 107 [RFC4107], then mutual authentication MUST be accomplished via an authenticated key exchange. Protocol Requirement: The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller. It also MUST ensure that information exchanges are integrity protected and SHOULD ensure confidentiality through encryption.
Motivation and Protocol Benefits: WLANs are increasingly deployed in critical aspects of enterprise and consumer networks. In these contexts, protocol security is crucial to ensure the privacy and integrity expected from network administrators and end-users. So securing the CAPWAP protocol has direct benefits in addressing these concerns. In many cases, the network path between a WTP and WLAN controller contains untrusted links. Such links could be leveraged by rogue WTPs to gain access to the WLAN system. They could also be used by rogue WLAN controllers to gain control of legitimate WTPs and their associated terminals to either redirect or compromise terminal traffic. These security concerns can be mitigated with this objective. Relation to Problem Statement: Security problems in large-scale WLANs are detailed in the Problem Statement. These include complications arising from rogue WTPs and compromised interfaces between WTPs and the WLAN controller. The requirement for protocol security addresses these problems and highlights the importance of protecting against them.
Protocol Requirement: The design of the CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by external entities. Motivation and Protocol Benefits: The external threats to the centralized WLAN architecture become increasingly crucial given the low cost of wireless clients. Since it is relatively inexpensive for rogue individuals to mount attacks, it is important that WLAN systems are protected against them. Adequate mechanisms to thwart such external threats will be of tremendous benefit to the WLAN systems controlled and managed with the CAPWAP protocol. Relation to Problem Statement: This objective is based on the security needs highlighted in the Problem Statement. Specifically, the Problem Statement discusses the effects of the shared wireless medium. This represents the external aspects of the CAPWAP framework from which certain threats can arise. The system-wide security objective addresses such threats in relation to the Problem Statement.
Here, CAPWAP will first need to identify the location of the authenticator and encryption points between each WLAN controller-WTP pair. This will likely be part of the initial WTP configuration. Subsequently, the WTPs that realize encryption will need CAPWAP to exchange key information with the authenticator at the WLAN controller. For the WTPs that do not realize encryption, CAPWAP needs to adapt its control to bypass the key exchange phase. Clearly, the centralized WLAN architecture presents a different platform for authentication mechanisms compared to legacy WLANs in which a WTP realized both authenticator and encryption roles. So this objective highlights the need for CAPWAP to support authentication and key management in the centralized WLAN architecture. Protocol Requirement: The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e., the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol MUST allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. Motivation and Protocol Benefits: The immediate focus of CAPWAP is on supporting IEEE 802.11-based WLANs. As such, it is necessary for the protocol to recognize the major distinction in WLAN design with respect to IEEE 802.11i authenticator and encryption points. This represents a significant variation that has been highlighted in the Architecture Taxonomy. The CAPWAP protocol benefits by accommodating such a major consideration from IEEE 802.11i. These requirements will be common for all authentication mechanisms over the centralized WLAN architecture. So they are applicable to IEEE 802.11i, Universal Access Method (UAM), and other mechanisms. Relation to Problem Statement: The Problem Statement highlights the availability of different WTP designs and the need to ensure interoperability among them. In this regard, operational changes occurring due to the separation of the IEEE 802.11i authenticator and encryption points need to be accommodated within the CAPWAP protocol.
Motivation and Protocol Benefits: The benefits of realizing this architecture objective are both technical and practical. First, there are substantial overlaps in the control operations of local-MAC and split-MAC architecture designs. The Architecture Taxonomy tabulates major common features of the two designs. As a result, it is technically practical to devise a single protocol that manages both types of devices. Next, the ability to operate a CAPWAP protocol for both types of architectural designs enhances its practical prospects as it will have wider appeal. Furthermore, the additional complexity resulting from such alternative interfaces is marginal. Consequently, the benefits of this objective will far outweigh any cost of realizing it. Relation to Problem Statement: The objective for supporting both local-MAC and split-MAC WTPs is fundamental to addressing the Problem Statement. It forms the basis for those problems to be uniformly addressed across the major WLAN architectures. This is the ultimate aim of standardization efforts. The realization of this objective will ensure the development of a comprehensive set of mechanisms that address the challenges of large-scale WLAN deployments.
Motivation and Protocol Benefits: It is beneficial for WLAN equipment vendors to refer to a single set of specifications while implementing the CAPWAP protocol. This helps to ease and quicken the development process. Relation to Problem Statement: This requirement is based on WG discussions that have been determined to be important for CAPWAP.
Protocol Requirement: The CAPWAP protocol MUST NOT limit WTP vendors in their choice of local-MAC or split-MAC WTPs. It MUST be compatible with both types of WTPs. Motivation and Protocol Benefits: This requirement is to ensure that WTP vendors have sufficient flexibility in selecting the type of wireless MAC design that they consider best for deployments. Relation to Problem Statement: This requirement is based on WG discussions that have been determined to be important for CAPWAP.
support for new wireless technologies within the CAPWAP protocol, such as IEEE 802.16. The protocol should therefore not rely on specifics of IEEE 802.11 technology. In all cases where the CAPWAP protocol messages contain specific layer 2 information elements, the definition of the protocol needs to provide for extensibility so that these elements can be defined for specific layer 2 wireless protocols. This may entail assigning a layer 2 wireless protocol type and version field to the message PDU. Examples of other wireless protocols that might be supported include but are not limited to 802.16e, 802.15.x, etc. Protocol Requirement: CAPWAP protocol messages MUST be designed to be extensible for specific layer 2 wireless technologies. It should not be limited to the transport of elements relating to IEEE 802.11. Motivation and Protocol Benefits: There are many benefits to an extensible protocol. It allows for application in different networks and provides greater scope. Furthermore, service providers require WLAN solutions that will be able to meet current and future market requirements. Relation to Problem Statement: The Problem Statement describes some of the advances taking place in other standards bodies like the IEEE. It is important for the CAPWAP protocol to reflect the advances and provide a framework in which they can be supported.
Protocol Requirement: The CAPWAP protocol MUST be openly designed to support new IEEE 802.11 definitions and extensions. Motivation and Protocol Benefits: There are a number of advances being made within the IEEE regarding the functionality of IEEE 802.11 technology. Since this represents one of the major wireless technologies in use today, it will be beneficial for CAPWAP to incorporate the relevant new extensions. Relation to Problem Statement: The Problem Statement presents an overview of the task of the IEEE 802.11 working group. This group is focused on defining the functional architecture of WTPs and new extensions for it. It is necessary for the CAPWAP protocol to reflect these definitions and extensions.
Motivation and Protocol Benefits: The main aim of the CAPWAP protocol is to achieve interoperability among various WTPs and WLAN controllers. As such, the motivation for this requirement is for the protocol to be operable independent of underlying interconnection technologies. Relation to Problem Statement: The Problem Statement discusses the complexity of configuring large WLANs. The selection of available interconnection technologies for large-scale deployments further intensifies this complexity. This requirement avoids part of the complexity by advocating independence of the operational aspects of the protocol from underlying transport.
Motivation and Protocol Benefits: Due to the scale of deployments in which CAPWAP will be employed, comprehensive access control is crucial. The effectiveness of access control in turn is affected by the information on which such control is based. As a result, this objective has critical relevance to a CAPWAP protocol. Relation to Problem Statement: This objective addresses the issue of access control in large WLANs. Broadly, it relates the problem of managing the complexity scale of such networks. With collective information of both switching and wireless medium segments, realizing this objective will help control and manage complexity.
Motivation and Protocol Benefits: It is expected that in many cases, the centralized WLAN architecture will be deployed incrementally with legacy systems. In this regard, it is necessary for the protocol to be used in scenarios with mixed WLAN devices. Relation to Problem Statement: The Problem Statement highlights management complexity as a major issue with large WLANs. One part of this complexity can be related to the incremental deployment of centralized WLAN devices for which this objective is applicable. Section 5.1.12).
Additionally, this document includes requirements from network service operators that have been derived based on their experience in operating large-scale WLANs. The resulting requirements from this document will be used in conjunction with the CAPWAP Problem Statement [RFC3990] and CAPWAP Architecture Taxonomy [RFC4118] to develop and evaluate an interoperable protocol for the control and provisioning of WTPs in large-scale WLANs.
Considering asymmetric, non-mutual authentication between WTPs and the WLAN controller, there is a risk of a rogue participant exploiting such an arrangement. It is preferable to avoid non-mutual authentication. In some cases, the legitimacy of the protocol exchange participants may be verified externally, for example, by means of physical containment within a close environment. Asymmetric authentication may be appropriate here without risk of security compromises. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005. [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005. [802.11] IEEE Standard 802.11, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", June 2003. [802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC) Security Enhancements", July 2004. [802.11e] IEEE Standard 802.11e, "Medium Access Control (MAC) Quality of Service Enhancements", November 2005. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
Hong Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore Phone: +65 6550 5447 EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).