doc: Add RFC documents

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]
+