simple, interoperable protocol for managing large-scale WLANs. The
architecture requirements specify the structural features of the
protocol such as those relating to WTP types (local-MAC and split-
MAC) and WTP structures (logical groups). The operations
requirements address the functional aspects dealing with WTP
configuration and management. Finally, the security requirements
cover authentication and integrity aspects of protocol exchanges.
The objectives have additionally been prioritized to reflect their
immediate significance to the development and evaluation of an
interoperable CAPWAP protocol. The priorities are Mandatory and
Accepted, Desirable, and Non-Objectives. They reflect working group
consensus on the effectiveness of the requirements in the context of
protocol design.
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.
7. Security Considerations
The CAPWAP framework highlights support for both local-MAC and
split-MAC WTPs. In deployments where both types of WTPs are used, it
is crucial to ensure that each be secured in consideration of its
capabilities. The Architecture Taxonomy illustrates how different
WTPs incorporate varying levels of functionalities. Development of
the CAPWAP protocol should ensure that the deployment of both local-
MAC and split-MAC WTPs within a single WLAN do not present loopholes
for security compromises.
In shared WLAN deployments made of a number of logical groups,
traffic from each group needs to be mutually separated. So in
addition to protocol-related exchanges, data traffic from wireless
terminals should also be segregated with respect to the logical
groups to which they belong. It should not be possible for data or
control traffic from one logical group to stray to or influence
another logical group.
The use of IEEE 802.11i over the centralized WLAN architecture allows
for implementations in which the PMK is shared across WTPs. This
raises the ambiguity between legitimate sharing and illegitimate
copies. Wireless terminals may unknowingly fall prey to or exploit
this ambiguity. The resolution of this issue is currently being
evaluated by the IEEE 802 and IETF liaisons.
The low cost of launching attacks on WLANs makes the CAPWAP protocol
a target. A first step in securing against any form of attacks is to
continuously monitor the WLAN for conditions of potential threats
from rogue WTPs or wireless terminals. For example, profiles for DoS
and replay attacks need to be considered for the CAPWAP protocol to
effectively monitor security conditions.
The open environment of many WLAN deployments makes physical security
breaches highly probable. Compromises resulting from theft and
physical damage must be considered during protocol development. For
instance, it should not be possible for a single compromised WTP to
affect the WLAN as a whole.
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.
8. Acknowledgements
The authors would like to thank the working group chairs, Dorothy
Gellert and Mahalingam Mani, for their support and patience with this
document. We would also like to thank participants of the working
group who have helped shape the objectives. In particular, the
authors thank James Kempf, Pat Calhoun, Inderpreet Singh, Dan
Harkins, T. Sridhar, Charles Clancy, and Emek Sadot for their
invaluable inputs. We also extend our gratitude to the IEEE 802.11
Ad-Hoc Committee for its evaluation of the document. The authors
also acknowledge the contributions from Meimei Dang, Satoshi Iino,
Mikihito Sugiura, and Dong Wang.
9. Normative References
[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.
10. Informative References
[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.
Authors’ Addresses
Saravanan Govindan
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5441
EMail: saravanan.govindan@sg.panasonic.com
Zhonghui Yao
Huawei Longgang Production Base
Shenzhen 518 129
P. R. China
Phone: +86 755 2878 0808
EMail: yaoth@huawei.com
Wenhui Zhou
China Mobile
53A, Xibianmen Ave, Xuanwu District
Beijing 100 053
P. R. China
Phone: +86 10 6600 6688 ext.3061
EMail: zhouwenhui@chinamobile.com
L. Lily Yang
Intel Corp.
JF3-206, 2111 NE 25th Ave.
Hilsboro, OR 97124
USA
Phone: +1 503 264 8813
EMail: lily.l.yang@intel.com
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: hong.cheng@sg.panasonic.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
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).