Network Working Group B. O'Hara Request for Comments: 3990 P. Calhoun Category: Informational Airespace J. Kempf Docomo Labs USA February 2005 Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement 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 (2005).
AbstractThis document describes the Configuration and Provisioning for Wireless Access Points (CAPWAP) problem statement.
Large deployments of 802.11 WLANs have introduced several problems that require solutions. The limitations on the scalability of bridging should come as no surprise to the networking community, as similar limitations arose in the early 1980s for wired network bridging during the expansion and interconnection of wired local area networks. This document will describe the problems introduced by the large-scale deployment of 802.11 WLANs in enterprise networks.
Recently, to address some, or all, of the above problems, multiple vendors have begun offering proprietary solutions that combine aspects of network switching, centralized control and management, and distributed wireless access in a variety of new architectures. Since interoperable solutions allow enterprises and service providers a broader choice, a standardized, interoperable interface between access points and a centralized controller addressing the problems seems desirable. In currently fielded devices, the physical portions of this network system are one or more 802.11 access points (APs) and one or more central control devices, alternatively described as controllers (or as access controllers, ACs). Ideally, a network designer would be able to choose one or more vendors for the APs and one or more vendors for the central control devices in sufficient numbers to design a network with 802.11 wireless access to meet the designer's requirements. Current implementations are proprietary and are not interoperable. This is due to a number of factors, including the disparate architectural choices made by the various manufacturers. A taxonomy of the architectures employed in the existing products in the market will provide the basis of an output document to be provided to the IEEE 802.11 Working Group. This taxonomy will be utilized by the 802.11 Working Group as input to their task of defining the functional architecture of an access point. The functional architecture, including descriptions of detailed functional blocks, interfaces, and information flow, will be reviewed by CAPWAP to determine if further work is necessary to apply or develop standard protocols providing for multi-vendor interoperable implementations of WLANs built from devices that adhere to the newly appearing hierarchical architecture using a functional split between an access point and an access controller.
determined. Physical security should also be addressed for those devices that contain sensitive security parameters that might compromise the security of the system, if those parameters were to fall into the hands of an attacker. To provide comprehensive radio coverage, APs are often installed in locations that are difficult to secure. The CAPWAP architecture may reduce the consequences of a stolen AP. If high-value secrets, such as a RADIUS shared secret, are stored in the AC, then the physical loss of an AP does not compromise these secrets. Further, the AC can easily be located in a physically secure location. Of course, concentrating all the high-value secrets in one place makes the AC an attractive target, and strict physical, procedural, and technical controls are needed to protect the secrets.
Full Copyright Statement Copyright (C) The Internet Society (2005). 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 IETF's procedures with respect to rights in IETF 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 ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.