modifications to protocol exchanges, eavesdropping, and Denial of
Service (DoS) attacks, among other potential compromises. So the
protocol must provide confidentiality, integrity, and authenticity
for those exchanges.
As a result of realizing this objective, it should not be possible
for individual WTP breaches to affect the security of the WLAN as a
whole. So WTP misuse will be protected against.
Additionally, the key establishment protocol for authentication and
securing CAPWAP exchanges must be designed to minimize the
possibility of future compromises after the keys are established.
CAPWAP MUST NOT prevent the use of asymmetric authentication. The
security considerations of such asymmetric authentication are
described in the Security Considerations section.
If the CAPWAP protocol meets the criteria to require automated key
management per BCP 107 [RFC4107], then mutual authentication MUST be
accomplished via an authenticated key exchange.
Protocol Requirement:
The CAPWAP protocol MUST support mutual authentication of WTPs and
the centralized controller. It also MUST ensure that information
exchanges are integrity protected and SHOULD ensure confidentiality
through encryption.
Motivation and Protocol Benefits:
WLANs are increasingly deployed in critical aspects of enterprise and
consumer networks. In these contexts, protocol security is crucial
to ensure the privacy and integrity expected from network
administrators and end-users. So securing the CAPWAP protocol has
direct benefits in addressing these concerns.
In many cases, the network path between a WTP and WLAN controller
contains untrusted links. Such links could be leveraged by rogue
WTPs to gain access to the WLAN system. They could also be used by
rogue WLAN controllers to gain control of legitimate WTPs and their
associated terminals to either redirect or compromise terminal
traffic. These security concerns can be mitigated with this
objective.
Relation to Problem Statement:
Security problems in large-scale WLANs are detailed in the Problem
Statement. These include complications arising from rogue WTPs and
compromised interfaces between WTPs and the WLAN controller. The
requirement for protocol security addresses these problems and
highlights the importance of protecting against them.
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.
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).
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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).
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