One document matched: draft-ietf-capwap-objectives-02.txt
Differences from draft-ietf-capwap-objectives-01.txt
Network Working Group S. Govindan (Editor)
Internet-Draft Panasonic
Expires: October 16, 2005 ZH. Yao
Huawei
WH. Zhou
China Mobile
L. Yang
Intel
H. Cheng
Panasonic
April 14, 2005
Objectives for Control and Provisioning of Wireless Access Points
(CAPWAP)
draft-ietf-capwap-objectives-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Govindan (Editor), et al. Expires October 16, 2005 [Page 1]
Internet-Draft CAPWAP Objectives April 2005
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 (Editor), et al. Expires October 16, 2005 [Page 2]
Internet-Draft CAPWAP Objectives April 2005
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Objectives Overview . . . . . . . . . . . . . . . . . . . . 7
5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 8
5.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 8
5.1.2 Support for Traffic Separation . . . . . . . . . . . . 9
5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 10
5.1.4 Configuration Consistency . . . . . . . . . . . . . . 11
5.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 12
5.1.6 Monitoring and Exchange of System-wide Resource
State . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.7 Resource Control Objective . . . . . . . . . . . . . . 13
5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 15
5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 16
5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 17
5.1.11 Interoperability Objective . . . . . . . . . . . . . 18
5.1.12 Protocol Specifications . . . . . . . . . . . . . . 20
5.1.13 Vendor Independence . . . . . . . . . . . . . . . . 20
5.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 21
5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 21
5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 22
5.2.2 Support for Future Wireless Technologies . . . . . . . 22
5.2.3 Support for New IEEE Requirements . . . . . . . . . . 23
5.2.4 Interconnection Objective . . . . . . . . . . . . . . 24
5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 25
5.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 26
5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 26
5.3.2 Technical Specifications . . . . . . . . . . . . . . . 26
5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 27
5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 27
6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32
Govindan (Editor), et al. Expires October 16, 2005 [Page 3]
Internet-Draft CAPWAP Objectives April 2005
1. 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].
Govindan (Editor), et al. Expires October 16, 2005 [Page 4]
Internet-Draft CAPWAP Objectives April 2005
2. Terminology
This document follows the terminologies of [I-D.ietf-capwap-arch].
Additionally, the following terms are defined;
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.
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 focussed 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 5]
Internet-Draft CAPWAP Objectives April 2005
3. Introduction
The growth in large-scale wireless local area network (WLAN)
deployments has brought to 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 [I-D.ietf-capwap-problem-statement].
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 [I-D.ietf-capwap-arch] 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 that the current majority of
large-scale deployments follow the centralized WLAN architecture 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 controling 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 6]
Internet-Draft CAPWAP Objectives April 2005
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, QoS and access control.
Security objectives address potential threats to WLANs and their
containment. In the CAPWAP context, security requirements cover both
the protocol between WLAN controller and WTPs and also the WLAN
system as a whole.
Additionally, a general classification is used for objectives
relating to the overall impact of the CAPWAP protocol specifications.
Govindan (Editor), et al. Expires October 16, 2005 [Page 7]
Internet-Draft CAPWAP Objectives April 2005
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.
Additionally, one category is provided for requirements gathered from
network service operators. These are specific need that arise from
operators' experiencese in deploying and managing large-scale WLANs.
The priorities are;
i. Mandatory and Accepted Objectives
ii. Desirable Objectives
iii. Rejected Objectives
iv. Operator Requirements
The priorities have been assigned to individual objectives in
accordance with working group discussions.
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.
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. For example, each BSSID of a
physical WTP can be construed to be a logical group. So WLANs are
managed in terms of logical groups instead of physical WTPs. Virtual
Govindan (Editor), et al. Expires October 16, 2005 [Page 8]
Internet-Draft CAPWAP Objectives April 2005
APs are examples of logical groups.
Protocol Requirement:
WLAN deployment trends require the CAPWAP protocol to be capable of
controlling and managing physical WTPs in terms of logical groups.
Motivation and Protocol Benefits:
Commercial realities necessitate that WLANs be manageable in terms of
its logical groups. This allows separation of logical services and
underlying infrastructure management. A protocol that realizes this
need ensures simlper 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
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 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
be mutually separated to maintain the integrity and independence of
the logical groups.
Govindan (Editor), et al. Expires October 16, 2005 [Page 9]
Internet-Draft CAPWAP Objectives April 2005
Protocol Requirement:
In order to maintain the separation of control and data traffic, the
CAPWAP protocol is required to define control messages such that they
do not involve piggybacking or other combination with data traffic.
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, such separation provides for the separation of data and
control paths. This 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.
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 should 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 10]
Internet-Draft CAPWAP Objectives April 2005
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 which
need to be configured and managed in a consistent manner. This is
possible by providing the centralized WLAN controller with regular
updates on the state of their operations. The centralized WLAN
controller can in turn apply information from the regular updates to
consistently configure the WTPs.
Protocol Requirement:
The CAPWAP protocol must allow for regular exchanges of state
information between WTPs and WLAN controller. Examples of state
information include WTP processing load and memory utilization.
Motivation and Protocol Benefits:
A protocol that has access to regular state information can in turn
use this to enhance WLAN performance. The CAPWAP protocol will be
better equipped to address configuration related problems with the
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 fundamentally addresses this challenge by
providing relevant state information based on which configurations
can be appropriately maintained.
Govindan (Editor), et al. Expires October 16, 2005 [Page 11]
Internet-Draft CAPWAP Objectives April 2005
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 prtoocol.
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
appropriately equivalent. This in turn results in consistent
configuration and simplified management. So the protocol benefits by
including triggers for the distribution of firmware updates.
Relation to Problem Statement:
Inconsistencies in the configuration of WTPs has been identified as a
major challenge for large-scale WTPs. This objectives helps overcome
the challenge by providing for a way for the protocol to initiate
delivery of equivalent versions of firmware to 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 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
Govindan (Editor), et al. Expires October 16, 2005 [Page 12]
Internet-Draft CAPWAP Objectives April 2005
relevant WLAN devices - either WTPs or 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 effectivness 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.
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 while the latter will be an
Govindan (Editor), et al. Expires October 16, 2005 [Page 13]
Internet-Draft CAPWAP Objectives April 2005
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 Task
Groups that may affect network resources. These include IEEE TGk,
TGu and TGv, which are currently under progress. CAPWAP should
therefore not be restricted to IEEE 802.11e based mapping.
Protocol Requirement:
The CAPWAP protocol must maintain IEEE 802.11e QoS mappings across
the switching and wireless medium segments.
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 is therefore critical for performance.
Govindan (Editor), et al. Expires October 16, 2005 [Page 14]
Internet-Draft CAPWAP Objectives April 2005
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
- WLAN controller and WTPs - to be mutually authenticated. This is
to ensure that rogue WTPs do not breach legitimate WLAN systems. For
example, WTPs may need to regularly renew their authentication state
with the WLAN controller.
Once WTPs and WLAN controller have been mutually authenticated,
information exchanges between them must be secured against various
security threats. This should cover illegitimate modifications to
protocol exchanges, eavesdropping and DoS attacks, among other
potential compromises. So the protocol must be 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 mis-use 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.
While mutual authentication is necessary for CAPWAP, the protocol
should not prevent the use of asymmetric, non-mutual authentication.
The security considerations of such asymmetric authentication are
described in the Security Considerations section.
Protocol Requirement:
The CAPWAP protocol must support mutual authentication of WTPs and
the centralized controller. It must also ensure that information
exchanges between them are secured.
Motivation and Protocol Benefits:
WLANs are increasingly deployed in critical aspects of enterprise and
consumer networks. In these contexts, protocol security is crucial
to assure the privacy and integrity expected from network
administrators and end-users. So securing the CAPWAP protocol has
direct benefits in addressing these concerns.
Govindan (Editor), et al. Expires October 16, 2005 [Page 15]
Internet-Draft CAPWAP Objectives April 2005
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 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 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 should 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
Govindan (Editor), et al. Expires October 16, 2005 [Page 16]
Internet-Draft CAPWAP Objectives April 2005
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 consistituent 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 which realize encryption will need CAPWAP to
exchange key information with the authenticator at the WLAN
controller. For the WTPs which do not realize encryption, CAPWAP
need 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 17]
Internet-Draft CAPWAP Objectives April 2005
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 fro 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, UMA 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 occuring due to the separation of the
IEEE 802.11i authenticator and encryption points need to be
accommated 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
Govindan (Editor), et al. Expires October 16, 2005 [Page 18]
Internet-Draft CAPWAP Objectives April 2005
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 negotiationg of significant capabilities between WTPs and
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 equates
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 the outcome of the IEEE AP
Functionality (APF) Ad-Hoc Committee. The APF Ad-Hoc Committee will
provide appropriate insight in to specific functional blocks which
may be used for finer capabilities negotiations within the CAPWAP
protocol.
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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 19]
Internet-Draft CAPWAP Objectives April 2005
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 run 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 AC vendor or any person can 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 determined to
be important for CAPWAP.
5.1.13 Vendor Independence
Classification: General
Description:
Rapid developments in WLAN technologies results in equipment vendors
constantly modifying their devices. In many cases, developments are
independently made for ACs and WTPs. The CAPWAP protocol should not
Govindan (Editor), et al. Expires October 16, 2005 [Page 20]
Internet-Draft CAPWAP Objectives April 2005
affect the the independence of device modificaitons.
Protocol Requirement:
A WTP vendor can make modifications to hardware without any AC 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 determined to
be important for CAPWAP.
5.1.14 Vendor Flexibility
Classification: General
Description:
The CAPWAP protocol must not be specified for a particular MAC. It
should be compatible with both local-MAC and split-MAC WTPs.
Protocol Requirement:
WTP vendors must not be bound to a specific MAC.
Motivation and Protocol Benefits:
This requirement is to ensure that WTP vendors have sufficient
flexibility in selecting the type of MAC that they consider best for
deployments.
Relation to Problem Statement:
This requirement is based on WG discussions that have 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 21]
Internet-Draft CAPWAP Objectives April 2005
5.2.1 Multiple Authentication Mechanisms
Classification: Architecture
Description:
Shared WLAN infrastructure raise 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 withing them will be different.
While 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 while 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 which may not be appropriate for a particular deployment.
Relation to Problem Statement:
This objective relates to the problem of management complexity.
Shared WLAN deployments simplifies 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 for 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
Govindan (Editor), et al. Expires October 16, 2005 [Page 22]
Internet-Draft CAPWAP Objectives April 2005
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 is currently reviewing IEEE 802.11 functionality. It is
expected that the review by the IEEE AP Functionality Ad-Hoc
Committee may result in new definitions of functional blocks,
interfaces or information flows. The CAPWAP protocol must be able to
incorporate these revisions with minimal change.
Protocol Requirement:
The CAPWAP protocol must be openly designed to support new IEEE
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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 23]
Internet-Draft CAPWAP Objectives April 2005
Relation to Problem Statement:
The Problem Statement presents an overview of the task of the IEEE
802.11 working group. This group is focussed on defining the
functional architecture of WTPs. It is necessary for the CAPWAP
protocol to reflect these definitions.
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 from underlying
transport.
Govindan (Editor), et al. Expires October 16, 2005 [Page 24]
Internet-Draft CAPWAP Objectives April 2005
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 requires
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
Govindan (Editor), et al. Expires October 16, 2005 [Page 25]
Internet-Draft CAPWAP Objectives April 2005
and manage complexity.
5.3 Rejected Objectives
The following objectives have been rejected during the course of
working group consultations. These objectives have been rejected 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 comlpexity 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:
Govindan (Editor), et al. Expires October 16, 2005 [Page 26]
Internet-Draft CAPWAP Objectives April 2005
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 determined to
be important for CAPWAP.
This objective has been prioritized as rejected 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 crucially 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 27]
Internet-Draft CAPWAP Objectives April 2005
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 to focus 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 Rejected. They reflect working group
consensus on the effectiveness of the requirements in the context of
protocol design.
Additionally, this document includes requirements from network
service operators that have been derived based on their experience in
operating large- scale WLANs.
The resulting requirements from this document will be used in
conjunction with the CAPWAP Problem Statement [I-D.ietf-capwap-
problem-statement] and CAPWAP Architecture Taxonomy [I-D.ietf-capwap-
arch] to develop and evalute an interoperable protocol for the
control and provisioning of WTPs in large-scale WLANs.
Govindan (Editor), et al. Expires October 16, 2005 [Page 28]
Internet-Draft CAPWAP Objectives April 2005
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 their
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
evaluted by the IEEE 802 and IETF liaisons.
The low-cost of launching attacks on WLANs makes the CAPWAP protocol
a target. A first step in securing against any form of attacks is to
continuously monitor the WLAN for conditions of potential threats
from rogue WTPs or wireless terminals. For example, profiles for DoS
and replay attacks need to be considered for the CAPWAP protocol to
effectively monitor security conditions.
The open environment of many WLAN deployments makes physical security
breaches highly probable. Compromises resulting from theft and
physical damage must be considered during protocol development. For
instance, it should not be possible for a single compromised WTP to
affect the WLAN as a whole.
Considering asymmetric, non-mutual authentication between WTPs and
WLAN controller, there is a risk of a rogue participant exploiting
such an arrangement. It is preferrable 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.
Govindan (Editor), et al. Expires October 16, 2005 [Page 29]
Internet-Draft CAPWAP Objectives April 2005
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
and T. Sridhar for their invaluable inputs. The authors also
acknowledge the contributions from Meimei Dang, Satoshi Iino,
Mikihito Sugiura and Dong Wang.
9. References
[I-D.ietf-capwap-arch]
Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access
Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in
progress), November 2004.
[I-D.ietf-capwap-problem-statement]
Calhoun, P., "CAPWAP Problem Statement",
draft-ietf-capwap-problem-statement-02 (work in progress),
September 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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: sgovindan@psl.com.sg
Govindan (Editor), et al. Expires October 16, 2005 [Page 30]
Internet-Draft CAPWAP Objectives April 2005
Zhonghui Yao
Huawei Longgang Production Base
Shenzhen 518 129
P. R. China
Phone: +86 755 2878 0808
Email: yaoth@huawei.com
Wenhui Zhou
China Mobile
53A, Xibianmen Ave, Xuanwu District
Beijing 100 053
P. R. China
Phone: +86 10 6600 6688 ext.3061
Email: zhouwenhui@chinamobile.com
L. Lily Yang
Intel Corp.
JF3-206, 2111 NE 25th Ave.
Hilsboro, OR 97124
USA
Phone: +1 503 264 8813
Email: lily.l.yang@intel.com
Hong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5447
Email: hcheng@psl.com.sg
Govindan (Editor), et al. Expires October 16, 2005 [Page 31]
Internet-Draft CAPWAP Objectives April 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Govindan (Editor), et al. Expires October 16, 2005 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-23 03:09:34 |