summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4564.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4564.txt')
-rw-r--r--doc/rfc/rfc4564.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc4564.txt b/doc/rfc/rfc4564.txt
new file mode 100644
index 0000000..4618890
--- /dev/null
+++ b/doc/rfc/rfc4564.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+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).
+
+Abstract
+
+ This 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 1]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+Table of Contents
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 2]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+1. Introduction
+
+ The growth in large-scale Wireless Local Area Network (WLAN)
+ deployments has brought into focus a number of technical challenges.
+ Among them is the complexity of managing large numbers of Wireless
+ Termination Points (WTPs), which is further exacerbated by variations
+ in their design. Another challenge is the maintenance of consistent
+ configurations among the numerous WTPs of a system. The dynamic
+ nature of the wireless medium is also a concern together with WLAN
+ security. The challenges affecting large-scale WLAN deployments have
+ been highlighted in [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.
+
+2. Terminology
+
+ This document uses terminology defined in [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.
+
+
+
+Govindan, et al. Informational [Page 3]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+3. Requirements Notation
+
+ 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 [RFC2119].
+
+4. Objectives Overview
+
+ The objectives for CAPWAP have been broadly classified to address
+ architecture, operation, and security requirements of managing
+ large-scale WLAN deployments.
+
+ Architecture objectives deal with system-level aspects of the CAPWAP
+ protocol. They address issues of protocol extensibility, diversity
+ in network deployments and architecture designs, and differences in
+ transport technologies.
+
+ Operational objectives address the control and management features of
+ the CAPWAP protocol. They deal with operations relating to WLAN
+ monitoring, resource management, Quality of Service (QoS), and access
+ control.
+
+ Security objectives address potential threats to WLANs and their
+ containment. In the CAPWAP context, security requirements cover the
+ protocol between the WLAN controller and WTPs and also the WLAN
+ system as a whole.
+
+
+
+Govindan, et al. Informational [Page 4]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ Additionally, a general classification is used for objectives
+ relating to the overall impact of the CAPWAP protocol specifications.
+
+5. Objectives
+
+ The objectives described in this document have been prioritized based
+ on their immediate significance in the development and evaluation of
+ a control and provisioning protocol for large-scale WLAN deployments.
+ The priorities are:
+
+ i. Mandatory and Accepted Objectives
+ ii. Desirable Objectives
+ iii. Non-Objectives
+
+ The priorities have been assigned to individual objectives in
+ accordance with working group discussions.
+
+ Furthermore, a distinct category of objectives is provided based on
+ requirements gathered from network service operators. These are
+ specific needs that arise from operators' experiences in deploying
+ and managing large-scale WLANs.
+
+ a. Operator Requirements
+
+5.1. Mandatory and Accepted Objectives
+
+ Objectives prioritized as mandatory and accepted have been deemed
+ crucial for the control and provisioning of WTPs. They directly
+ address the challenges of large-scale WLAN deployments and MUST be
+ realized by a CAPWAP protocol.
+
+5.1.1. Logical Groups
+
+ Classification: Architecture
+
+ Description:
+
+ Large WLAN deployments are complex and expensive. Furthermore,
+ enterprises deploying such networks are under pressure to improve the
+ efficiency of their expenditures.
+
+ Shared WLAN deployments, where a single physical WLAN infrastructure
+ supports a number of logical networks, are increasingly used to
+ address these two issues of large-scale WLANs. These are popular as
+ they allow deployment and management costs to be spread across
+ businesses.
+
+
+
+
+
+Govindan, et al. Informational [Page 5]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.2. Support for Traffic Separation
+
+ Classification: Operations
+
+ Description:
+
+ The centralized WLAN architecture simplifies complexity associated
+ with large-scale deployments by consolidating portions of wireless
+ MAC functionality at a central WLAN controller and distributing the
+ remaining across WTPs. As a result, WTPs and WLAN controller
+ exchange control and data information between them. This objective
+
+
+
+
+
+Govindan, et al. Informational [Page 6]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 7]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+5.1.3. Wireless Terminal Transparency
+
+ Classification: Operations
+
+ Description:
+
+ The CAPWAP protocol is applicable between a centralized WLAN
+ controller and a number of WTPs; i.e., it affects only the switching
+ segment of the centralized WLAN architecture. Its operations should
+ therefore be independent of the wireless terminal. Wireless
+ terminals should not be required to be aware of the existence of the
+ CAPWAP protocol.
+
+ Protocol Requirement:
+
+ Wireless terminals MUST NOT be required to recognize or be aware of
+ the CAPWAP protocol.
+
+ Motivation and Protocol Benefits:
+
+ IEEE 802.11-based wireless terminals are mature and widely available.
+ It would be beneficial for CAPWAP not to impose new requirements on
+ these wireless terminals. In effect, this requirement ensures that
+ the setup cost of the protocol is reduced as the numerous existing
+ wireless terminals need not be altered.
+
+ Relation to Problem Statement:
+
+ The Problem Statement highlights the challenges faced by large WLANs
+ consisting of many WTPs. It does not refer to the operations of
+ wireless terminals and this objective emphasizes the independence.
+
+5.1.4. Configuration Consistency
+
+ Classification: Operations
+
+ Description:
+
+ WLANs in the CAPWAP framework contain numerous WTPs, each of them
+ needing to be configured and managed in a consistent manner. The
+ main concern in ensuring consistency is availability of appropriate
+ information corresponding to WTP configuration states. So
+ configuration consistency can be achieved by providing the
+ centralized WLAN controller with regular updates on the state of WTP
+ operations. The centralized WLAN controller can in turn apply
+ information from the regular updates to ensure consistently among the
+ WTPs.
+
+
+
+
+Govindan, et al. Informational [Page 8]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.5. Firmware Trigger
+
+ Classification: Operations
+
+ Description:
+
+ One specific aspect of configuration consistency is the firmware used
+ by various WTPs. The scale of large WLANs introduces possibilities
+ for variations in the firmware used among WTPs. This objective
+ highlights the need for the CAPWAP protocol to trigger the delivery
+ of appropriate versions of firmware to WTPs. The actual delivery of
+ firmware need not be inclusive to the protocol.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST support a trigger for delivery of firmware
+ updates.
+
+ Motivation and Protocol Benefits:
+
+ The CAPWAP protocol interfaces many WTPs to a centralized WLAN
+ controller. Firmware distribution allows these interfaces to be
+ compatible. This in turn results in consistent configuration and
+ simplified management. So the protocol benefits by including
+ triggers for the distribution of firmware updates.
+
+
+
+
+Govindan, et al. Informational [Page 9]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.6. Monitoring and Exchange of System-wide Resource State
+
+ Classification: Operations
+
+ Description:
+
+ The centralized WLAN architecture is made up of a switching segment
+ and wireless medium segment. In the switching segment, network
+ congestion, WTP status, and firmware information have to be
+ monitored. In the wireless medium segment, the dynamic nature of the
+ medium itself has to be monitored. Overall, there are also various
+ statistics that need to be considered for efficient WLAN operation.
+
+ The CAPWAP protocol should be capable of monitoring the various
+ information sources and deliver the resulting information to the
+ relevant WLAN devices -- either WTPs or the WLAN controller.
+ Moreover, given the relationship among information sources, the
+ CAPWAP protocol should combine state information from them. For
+ example, statistics information and status signals from WTPs may be
+ merged before being exchanged.
+
+ Examples of statistics information that the CAPWAP protocol should
+ monitor and exchange include congestion state, interference levels,
+ loss rates, and various delay factors.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST allow for the exchange of statistics,
+ congestion, and other WLAN state information.
+
+ Motivation and Protocol Benefits:
+
+ The effectiveness of a protocol is based on the relevance of
+ information on which it operates. This requirement for resource
+ monitoring and exchange can provide the appropriate information to
+ the CAPWAP protocol.
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 10]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.7. Resource Control Objective
+
+ Classification: Operations
+
+ Description:
+
+ Integral to the success of any wireless network system is the
+ performance and quality it can offer its subscribers. Since CAPWAP-
+ based WLANs combine a switching segment and a wireless medium
+ segment, performance and quality need to be coordinated across both
+ of these segments. So QoS performance must be enforced system-wide.
+
+ This objective highlights QoS over the entire WLAN system, which
+ includes the switching segment and the wireless medium segment.
+ Given the fundamental differences between the two, it is likely that
+ there are alternate QoS mechanisms between WTPs and wireless service
+ subscribers and between WTPs and WLAN controllers. For instance, the
+ former will be based on IEEE 802.11e, whereas the latter will be an
+ alternative. So resources need to be adjusted in a coordinated
+ fashion over both segments. The CAPWAP protocol should ensure that
+ these adjustments are appropriately exchanged between WLAN
+ controllers and WTPs.
+
+ In addition to IEEE 802.11e, there are a number of other IEEE 802.11
+ task groups that may affect network resources. These include IEEE
+ 802.11 TGk, TGu, and TGv, which are currently in progress. CAPWAP
+ should therefore not be restricted to IEEE 802.11e-based mapping.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to
+ equivalent QoS priorities across the switching and wireless medium
+ segments.
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 11]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.8. CAPWAP Protocol Security
+
+ Classification: Security
+
+ Description:
+
+ This objective addresses the security of the CAPWAP protocol.
+
+ The CAPWAP protocol MUST first provide for the participating entities
+ -- the WLAN controller and WTPs -- to be explicitly mutually
+ authenticated. This is to ensure that rogue elements do not gain
+ access to the WLAN system. Rogue WTPs should not be allowed to
+ breach legitimate WLANs, and at the same time rogue WLAN controllers
+ should not be allowed to gain control of legitimate WTPs. For
+ example, WTPs may need to regularly renew their authentication state
+ with the WLAN controller and similarly for WLAN controllers.
+
+
+
+
+Govindan, et al. Informational [Page 12]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 13]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.9. System-wide Security
+
+ Classification: Security
+
+ Description:
+
+ The emphasis of this objective is on the security threats external to
+ the centralized CAPWAP segment of a WLAN system. The focus is
+ therefore on rogue wireless clients and other illegitimate wireless
+ interferences. There are a number of specific external threats that
+ need to be addressed within the CAPWAP framework.
+
+ i. PMK Sharing
+
+ One aspect of this objective relates to recent discussions on
+ Pairwise Master Key (PMK) sharing in the CAPWAP framework. This
+ objective highlights the need to prevent exploitation of this
+ ambiguity by rogue wireless clients. It is to ensure that any
+ ambiguities arising from the CAPWAP framework are not cause for
+ security breaches.
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 14]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.10. IEEE 802.11i Considerations
+
+ Classification: Operations
+
+ Description:
+
+ The CAPWAP protocol must support authentication in the centralized
+ WLAN architecture in which the authenticator and encryption points
+ can be located on distinct entities, i.e., WLAN controller or WTP.
+ The Architecture Taxonomy illustrates a number of variants, in both
+ local-MAC and split-MAC designs, in which the authenticator is
+ located at the WLAN controller and the encryption points are at the
+ WTPs. The CAPWAP protocol must be applicable to these variants and
+ allow authentication mechanisms and their constituent processes to be
+ operable in these cases.
+
+ An important issue to consider in this case is the exchange of key
+ information when authenticator and encryption points are located on
+ distinct entities. For example, consider the case where IEEE 802.11i
+ is used in a WLAN in which the WLAN controller realizes the
+ authenticator, some WTPs realize encryption (possibly local-MAC
+ WTPs), and other WTPs rely on the WLAN controller for encryption
+ (possibly split-MAC WTPs).
+
+
+
+
+Govindan, et al. Informational [Page 15]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+
+
+
+Govindan, et al. Informational [Page 16]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+5.1.11. Interoperability Objective
+
+ Classification: Architecture
+
+ Description:
+
+ Two major designs of the centralized WLAN architecture are local-MAC
+ and split-MAC. With the focusing of standardization efforts on these
+ two designs, it is crucial to ensure mutual interoperation among
+ them.
+
+ This objective for the CAPWAP protocol is to ensure that WTPs of both
+ local-MAC and split-MAC architecture designs are capable of
+ interoperation within a single WLAN. Consequently, a single WLAN
+ controller will be capable of controlling both types of WTPs using a
+ single CAPWAP protocol. Integral support for these designs comprises
+ a number of protocol aspects.
+
+ i. Capability negotiations between WLAN controller and WTPs
+
+ WTP designs differ in the degree of IEEE 802.11 MAC functionalities
+ that each type of WTP realizes. The major distinctions, split-MAC
+ and local-MAC, differ in the processing of IEEE 802.11 MAC frames.
+ In this regard, the CAPWAP protocol should include functionality that
+ allows for negotiations of significant capabilities between WTPs and
+ the WLAN controller.
+
+ As a first step, such negotiations could cover the type of WTP,
+ split-MAC or local-MAC, as this provides substantial information on
+ their respective capabilities.
+
+ ii. Establishment of alternative interfaces
+
+ The capability differences among different WTPs essentially equate to
+ alternative interfaces with a WLAN controller. So the CAPWAP
+ protocol should be capable of adapting its operations to the major
+ different interfaces. In a first case, this would include
+ accommodating capability differences between local-MAC and split-MAC
+ WTPs.
+
+ The definition of these interfaces in terms of finer granularity of
+ functionalities will be based on AP functionality documents produced
+ by the IEEE 802.11 AP Functionality (APF) Ad-Hoc Committee.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST include sufficient capabilities negotiations
+ to distinguish between major types of WTPs.
+
+
+
+Govindan, et al. Informational [Page 17]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.12. Protocol Specifications
+
+ Classification: General
+
+ Description:
+
+ WLAN equipment vendors require sufficient details from protocol
+ specifications so that implementing them will allow for compatibility
+ with other equipment that runs the same protocol. In this light, it
+ is important for the CAPWAP protocol specifications to be reasonably
+ complete for realization.
+
+ Protocol Requirement:
+
+ Any WTP or WLAN controller vendor or any person MUST be able to
+ implement the CAPWAP protocol from the specification itself and by
+ that it is required that all such implementations do interoperate.
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 18]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.13. Vendor Independence
+
+ Classification: General
+
+ Description:
+
+ Rapid developments in WLAN technologies result in equipment vendors
+ constantly modifying their devices. In many cases, developments are
+ independently made for WLAN controllers and WTPs. The CAPWAP
+ protocol should not affect the independence of device modifications.
+
+ Protocol Requirement:
+
+ A WTP vendor SHOULD be able to make modifications to hardware without
+ any WLAN controller vendor involvement.
+
+ Motivation and Protocol Benefits:
+
+ Independence in the type of hardware for WLAN equipment ensures that
+ new developments do not hamper protocol operation.
+
+ Relation to Problem Statement:
+
+ This requirement is based on WG discussions that have been determined
+ to be important for CAPWAP.
+
+5.1.14. Vendor Flexibility
+
+ Classification: General
+
+ Description:
+
+ The CAPWAP protocol must not be specified for a particular type of
+ wireless MAC design. It should be compatible with both local-MAC and
+ split-MAC WTPs.
+
+
+
+
+
+Govindan, et al. Informational [Page 19]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.1.15. NAT Traversal
+
+ Classification: General
+
+ Description:
+
+ WLAN deployments may involve WTPs and the WLAN controller
+ communicating across Network Address Translators (NATs). The CAPWAP
+ protocol must be capable of operating across topologies that contain
+ known NAT configurations. It requires appropriate discovery and
+ identification mechanisms for NAT traversal.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST NOT prevent the operation of established
+ methods of NAT traversal.
+
+ Motivation and Protocol Benefits:
+
+ The widespread adoption of WLANs raises the possibility for WLAN
+ topologies containing NATs. It is important for the CAPWAP protocol
+ to be applicable within such topologies. This requirement aims to
+ make the CAPWAP protocol relevant for NAT traversal.
+
+ Relation to Problem Statement:
+
+ This requirement is based on WG discussions that have been determined
+ to be important for CAPWAP.
+
+
+
+
+
+
+Govindan, et al. Informational [Page 20]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+5.2. Desirable Objectives
+
+ These objectives have been determined to be desirable for a CAPWAP
+ protocol but not mandatory. Realizing these objectives may help
+ improve control of WLANs but need not necessarily be required for all
+ networks or scenarios.
+
+5.2.1. Multiple Authentication Mechanisms
+
+ Classification: Architecture
+
+ Description:
+
+ Shared WLAN infrastructure raises the issue of multiple
+ authentication mechanisms. This is because each logical group is
+ likely to be associated with different service providers or WLAN
+ domains. As a result, the authentication needs within them will be
+ different. Although CAPWAP is required to support IEEE 802.11i, it
+ is also necessary for it to support other authentication mechanisms.
+ For example, one logical group may use IEEE 802.11i, whereas another
+ may use web authentication. CAPWAP must be able to operate in such
+ shared WLANs.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST support different authentication mechanisms
+ in addition to IEEE 802.11i.
+
+ Motivation and Protocol Benefits:
+
+ The benefit of supporting various authentication mechanisms is that
+ the protocol then becomes flexible for use in various deployments.
+ The protocol will therefore not mandate the use of any particular
+ mechanisms that may not be appropriate for a particular deployment.
+
+ Relation to Problem Statement:
+
+ This objective relates to the problem of management complexity.
+ Shared WLAN deployments simplify management of large networks.
+
+5.2.2. Support for Future Wireless Technologies
+
+ Classification: Architecture
+
+ Description:
+
+ The rapid pace of technology developments means that new advances
+ need to be catered to in current analyses. Among these is the
+
+
+
+Govindan, et al. Informational [Page 21]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.2.3. Support for New IEEE Requirements
+
+ Classification: Architecture
+
+ Description:
+
+ The IEEE 802.11 APF Ad-Hoc Committee has reviewed IEEE 802.11
+ functionality and has made more thorough definitions for the new
+ requirements. The CAPWAP protocol must be able to incorporate these
+ definitions with minimal change. Furthermore, a number of extensions
+ for IEEE 802.11 are currently being standardized. The CAPWAP
+ protocol must also be able to incorporate these new extensions with
+ minimal change.
+
+
+
+
+
+
+Govindan, et al. Informational [Page 22]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.2.4. Interconnection Objective
+
+ Classification: Architecture
+
+ Description:
+
+ Large-scale WLAN deployments are likely to use a variety of
+ interconnection technologies between different devices of the
+ network. It should therefore be possible for the CAPWAP protocol to
+ operate over various interconnection technologies.
+
+ As a result of realizing this objective, the protocol will be capable
+ of operation over both IPv4 and IPv6. It will also be designed such
+ that it can operate within tightly administered networks, such as
+ enterprise networks, or on open, public access networks. For
+ example, VLAN tunnels can be used across different types of networks
+ over which CAPWAP will operate.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST NOT be constrained to specific underlying
+ transport mechanisms.
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 23]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.2.5. Access Control
+
+ Classification: Operations
+
+ Description:
+
+ This objective focuses on the informational needs of WLAN access
+ control and specifically the role of the CAPWAP protocol in
+ transporting this information between WTPs and their WLAN controller.
+
+ The following are some specific information aspects that need to be
+ transported by the CAPWAP protocol:
+
+ i. IEEE 802.11 association and authentication
+
+ The association of wireless clients is distinct for initial and
+ roaming cases. As a result, access control mechanisms require
+ specific contextual information regarding each case. Additionally,
+ load balancing, QoS, security, and congestion information in both
+ wireless medium segments and switching segments need to be
+ considered.
+
+ ii. WTP Access Control
+
+ In addition to controlling access for wireless clients, it is also
+ necessary to control admission of new WTPs. Given the threat of
+ rogue WTPs, it is important for CAPWAP to relay appropriate
+ authentication information between new WTPs and the WLAN controller.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol MUST be capable of exchanging information
+ required for access control of WTPs and wireless terminals.
+
+
+
+Govindan, et al. Informational [Page 24]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.3. Non-Objectives
+
+ The following objectives have been prioritized as non-objectives
+ during the course of working group consultations. They have been
+ prioritized so in the context of CAPWAP and its considerations. They
+ may, however, be applicable in alternative contexts.
+
+5.3.1. Support for Non-CAPWAP WTPs
+
+ Classification: Architecture
+
+ Description:
+
+ The CAPWAP protocol should provide an engine-mechanism to spring WTP
+ auto-configuration and/or software version updates and should support
+ integration with existing network management system. WLAN controller
+ as a management agent is optional.
+
+ If entities other than WLAN controllers manage some aspects of WTPs,
+ such as software downloads, the CAPWAP protocol may be used for WTPs
+ to notify WLAN controllers of any changes made by the other entities.
+
+ Protocol Requirement:
+
+ The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and
+ existing network management systems.
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 25]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+5.3.2. Technical Specifications
+
+ Classification: General
+
+ Description:
+
+ The CAPWAP protocol must not require AC and WTP vendors to share
+ technical specifications to establish compatibility. The protocol
+ specifications alone must be sufficient for compatibility.
+
+ Protocol Requirement:
+
+ WTP vendors SHOULD NOT have to share technical specifications for
+ hardware and software to AC vendors in order for interoperability to
+ be achieved.
+
+ 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.
+
+ This objective has been prioritized as a non-objective as it is a
+ duplicate of the Protocol Specifications objective (Section 5.1.12).
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 26]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+5.4. Operator Requirements
+
+ The following objectives have been provided by network service
+ operators. They represent the requirements from those ultimately
+ deploying the CAPWAP protocol in their WLANs.
+
+5.4.1. AP Fast Handoff
+
+ Classification: Operations
+
+ Description:
+
+ Network service operators consider handoffs crucial because of the
+ mobile nature of their customers. In this regard, the CAPWAP
+ protocol should not adversely affect AP fast-handoff procedures. The
+ protocol may support optimizations for fast handoff procedures so as
+ to allow better support for real-time services during handoffs.
+
+ Protocol Requirement:
+
+ CAPWAP protocol operations MUST NOT impede or obstruct the efficacy
+ of AP fast-handoff procedures.
+
+6. Summary and Conclusion
+
+ The objectives presented in this document address three main aspects
+ of the CAPWAP protocol, namely:
+
+ i. Architecture
+ ii. Operations
+ iii. Security
+
+ These requirements are aimed at focusing standardization efforts on a
+ 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.
+
+
+
+
+Govindan, et al. Informational [Page 27]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+
+
+Govindan, et al. Informational [Page 28]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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.
+
+
+
+Govindan, et al. Informational [Page 29]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 30]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 31]
+
+RFC 4564 CAPWAP Objectives July 2006
+
+
+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).
+
+
+
+
+
+
+
+Govindan, et al. Informational [Page 32]
+