draft-ietf-capwap-objectives-00.txt   draft-ietf-capwap-objectives-01.txt 
CAPWAP Working Group S. Govindan (Editor) Network Working Group S. Govindan (Editor)
Internet-Draft Panasonic Internet-Draft Panasonic
Expires: May 2005 ZH. Yao Expires: August 5, 2005 ZH. Yao
Huawei Huawei
WH. Zhou WH. Zhou
China Mobile China Mobile
L. Yang L. Yang
Intel Intel
H. Cheng H. Cheng
Panasonic Panasonic
November 2004 March 2005
Objectives for Control and Provisioning of Wireless Access Points Objectives for Control and Provisioning of Wireless Access Points
(CAPWAP) (CAPWAP)
draft-ietf-capwap-objectives-00.txt draft-ietf-capwap-objectives-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2005. This Internet-Draft will expire on August 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document presents a set of objectives for an interoperable
protocol for the Control and Provisioning of Wireless Access Points This document presents objectives for an interoperable protocol for
(CAPWAP). It presents objectives in three categories: architecture, the Control and Provisioning of Wireless Access Points (CAPWAP). The
operations and security. The primary purpose of the document is to document aims to establish a set of focused requirements for the
present focused requirements which when realized, will ensure development and evaluation of a CAPWAP protocol. The objectives
interoperability among wireless local area network (WLAN) devices of address Architecture, Operation, Security and Network Operator
alternative designs. These objectives will form the basis for the Requirements that are necessary to enable interoperability among
development and evaluation of a CAPWAP protocol. wireless local area network (WLAN) devices of alternative designs.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Categories of Objectives . . . . . . . . . . . . . . . . . . . 7 4. Objectives Overview . . . . . . . . . . . . . . . . . . . . 6
5. Architecture Objectives . . . . . . . . . . . . . . . . . . . 8 5. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 Interoperability Objective . . . . . . . . . . . . . . . . 8 5.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 7
5.1.1 Objective Details . . . . . . . . . . . . . . . . . . 8 5.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 7
5.1.2 Motivation and Protocol Benefits . . . . . . . . . . . 9 5.1.2 Support for Traffic Separation . . . . . . . . . . . . 8
5.1.3 Relation to Problem Statement . . . . . . . . . . . . 9 5.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 9
5.1.4 Customer Requirements . . . . . . . . . . . . . . . . 9 5.1.4 Configuration Consistency . . . . . . . . . . . . . . 10
5.1.5 Classification (Mandatory, Desirable, Rejected) . . . 9 5.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 11
5.2 Interconnection Objective . . . . . . . . . . . . . . . . 9 5.1.6 Monitoring and Exchange of System-wide Resource
5.2.1 Objective Details . . . . . . . . . . . . . . . . . . 10 State . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2 Motivation and Protocol Benefits . . . . . . . . . . . 10 5.1.7 Resource Control Objective . . . . . . . . . . . . . . 12
5.2.3 Relation to Problem Statement . . . . . . . . . . . . 10 5.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 14
5.2.4 Customer Requirements . . . . . . . . . . . . . . . . 10 5.1.9 System-wide Security . . . . . . . . . . . . . . . . . 15
5.2.5 Classification (Mandatory, Desirable, Rejected) . . . 10 5.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 16
5.3 Support for Logical Networks . . . . . . . . . . . . . . . 10 5.1.11 Interoperability Objective . . . . . . . . . . . . . 17
5.3.1 Objective Details . . . . . . . . . . . . . . . . . . 11 5.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 19
5.3.2 Motivation and Protocol Benefits . . . . . . . . . . . 11 5.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 19
5.3.3 Relation to Problem Statement . . . . . . . . . . . . 12 5.2.2 Support for Future Wireless Technologies . . . . . . . 20
5.3.4 Customer Requirement . . . . . . . . . . . . . . . . . 12 5.2.3 Support for New IEEE Requirements . . . . . . . . . . 21
5.3.5 Classification (Mandatory, Desirable, Rejected) . . . 12 5.2.4 Interconnection Objective . . . . . . . . . . . . . . 22
5.4 Extensibility Objective . . . . . . . . . . . . . . . . . 12 5.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 22
5.4.1 Objective Details . . . . . . . . . . . . . . . . . . 12 5.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24
5.4.2 Motivation and Protocol Benefits . . . . . . . . . . . 13 5.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 24
5.4.3 Relation to Problem Statement . . . . . . . . . . . . 13 5.4 Operator Requirements . . . . . . . . . . . . . . . . . . 24
5.4.4 Customer Requirements . . . . . . . . . . . . . . . . 13 5.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 25
5.4.5 Classification (Mandatory, Desirable, Rejected) . . . 13 6. Summary and Conclusion . . . . . . . . . . . . . . . . . . . 26
6. Operations Objective . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . 27
6.1 WLAN Monitoring Objective . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
6.1.1 Objective Details . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.2 Motivation and Protocol Benefits . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
6.1.3 Relation to Problem Statement . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 30
6.1.4 Customer Requirement . . . . . . . . . . . . . . . . . 15
6.1.5 Classification (Mandatory, Desirable, Rejected) . . . 15
6.2 Resource Control Objective . . . . . . . . . . . . . . . . 15
6.2.1 Objective Details . . . . . . . . . . . . . . . . . . 15
6.2.2 Motivation and Protocol Benefits . . . . . . . . . . . 16
6.2.3 Relation to Problem Statement . . . . . . . . . . . . 16
6.2.4 Customer Requirements . . . . . . . . . . . . . . . . 16
6.2.5 Classification (Mandatory, Desirable, Rejected) . . . 16
6.3 Support for Traffic Separation . . . . . . . . . . . . . . 17
6.3.1 Objective Details . . . . . . . . . . . . . . . . . . 17
6.3.2 Motivation and Protocol Benefits . . . . . . . . . . . 17
6.3.3 Relation to Problem Statement . . . . . . . . . . . . 17
6.3.4 Customer Requirements . . . . . . . . . . . . . . . . 17
6.3.5 Classification (Mandatory, Desirable, Rejected) . . . 17
6.4 STA Admission Control Objective . . . . . . . . . . . . . 17
6.4.1 Objective Details . . . . . . . . . . . . . . . . . . 18
6.4.2 Motivation and Protocol Benefits . . . . . . . . . . . 18
6.4.3 Relation to Problem Statement . . . . . . . . . . . . 18
6.4.4 Customer Requirements . . . . . . . . . . . . . . . . 18
6.4.5 Classification (Mandatory, Desirable, Rejected) . . . 18
6.5 Centralized WTP Management . . . . . . . . . . . . . . . . 18
7. Security Objectives . . . . . . . . . . . . . . . . . . . . . 19
7.1 CAPWAP Protocol Security . . . . . . . . . . . . . . . . . 19
7.1.1 Objective Details . . . . . . . . . . . . . . . . . . 19
7.2 System-wide Security . . . . . . . . . . . . . . . . . . . 19
8. Objectives for Further Discussion . . . . . . . . . . . . . . 20
8.1 Centralized WTP Management . . . . . . . . . . . . . . . . 20
8.2 Security borderline Control . . . . . . . . . . . . . . . 20
8.3 Trust model Definition . . . . . . . . . . . . . . . . . . 20
8.4 IEEE 802.11i Considerations . . . . . . . . . . . . . . . 20
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . 22
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
This document follows the terminologies of [I-D.ietf-capwap-arch]. This document follows the terminologies of [I-D.ietf-capwap-arch].
Additionally, the following terms are defined; Additionally, the following terms are defined;
Switching segment: Those aspects of a centralized WLAN that primarily Switching Segment: Those aspects of a centralized WLAN that primarily
deal with switching or routing control and data information between deal with switching or routing of control and data information
Wireless Termination Points (WTPs) and the WLAN controller. between Wireless Termination Points (WTPs) and the WLAN controller.
Wireless medium segment: Those aspects of a centralized WLAN that Wireless Medium Segment: Those aspects of a centralized WLAN that
primarily deal with the end-user interface which is wireless. primarily deal with the wireless interface between WTPs and wireless
Initially, CAPWAP focuses on IEEE 802.11 technologies but this terminals. The Wireless Medium Segment is specific to layer 2
segment may also refer to other technologies such as IEEE 802.16. wireless technology, such as IEEE 802.11.
CAPWAP framework: A term that includes the local MAC and split MAC CAPWAP Framework: A term that covers the local-MAC and split-MAC
designs of the Centralized WLAN Architecture. Standardization designs of the Centralized WLAN Architecture. Standardization
efforts are focussed on these designs. efforts are focussed on these designs.
CAPWAP protocol: The protocol between WLAN controller and WTPs in the CAPWAP Protocol: The protocol between WLAN controller and WTPs in the
CAPWAP framework. It facilitates control, management and CAPWAP framework. It facilitates control, management and
provisioning of WTPs in an interoperable manner. provisioning of WTPs in an interoperable manner.
3. Introduction 3. Introduction
The growth in large scale wireless local area network (WLAN) The growth in large-scale wireless local area network (WLAN)
deployments has brought to focus a number of technical challenges. deployments has brought to focus a number of technical challenges.
This includes the complexity of managing large numbers of wireless Among them is the complexity of managing large numbers of wireless
termination points (WTPs), which is further exacerbated by termination points (WTPs), which is further exacerbated by variations
differences in their design. Another challenge is the maintenance of in their design. Another challenge is the maintenance of consistent
consistent configurations among the numerous WTPs. The dynamic configurations among the numerous WTPs of a system. The dynamic
nature of the wireless medium is also a concern together with WLAN nature of the wireless medium is also a concern together with WLAN
security. These challenges have been highlighted in security. The challenges affecting large-scale WLAN deployments have
[I-D.ietf-capwap-problem-statement]. been highlighted in [I-D.ietf-capwap-problem-statement].
Many vendors have addressed these challenges for large scale WLAN Many vendors have addressed these challenges by developing new
deployments by developing new architectures and solutions. A survey architectures and solutions. A survey of the various developments
of the various architectures and solutions was conducted to better was conducted to better understand the context of these challenges.
understand the context of the challenges so as to develop This survey is a first step towards designing interoperability among
interoperability among them. The Architecture Taxonomy the solutions. The Architecture Taxonomy [I-D.ietf-capwap-arch] is a
[I-D.ietf-capwap-arch] is a result of this survey in which major result of this survey in which major WLAN architecture families are
architecture families are classified. Broadly, these are the classified. Broadly, these are the autonomous, centralized WLAN and
autonomous, centralized WLAN and distributed mesh architectures. The distributed mesh architectures.
survey showed 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 architecture family is further classified into
remote MAC, split MAC and local MAC. Each differs in the degree of
separation of MAC layer capabilities among WTPs and WLAN controller.
This document puts forth critical objectives for achieving The Architecture Taxonomy identified that the current majority of
interoperability in a CAPWAP framework. It presents objectives that large-scale deployments follow the centralized WLAN architecture in
address the challenges of large scale WLAN deployments. The which portions of the wireless medium access control (MAC) operations
realization of these objectives will ensure that WLAN equipment of are centralized in a WLAN controller. This centralized WLAN
major design types may be integrally deployed and managed. 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.
4. Categories of Objectives 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.
The objectives for the CAPWAP protocol are organized into three major 4. Objectives Overview
categories; architecture, operations and security.
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 Architecture objectives deal with system level aspects of the CAPWAP
protocol. They address issues of protocol extensibility, diverse protocol. They address issues of protocol extensibility, diversity
network deployments and architecture designs and differences in in network deployments and architecture designs and differences in
transport technologies. transport technologies.
Operational objectives address the control and management features of Operational objectives address the control and management features of
the CAPWAP protocol. They deal with operations relating to the CAPWAP protocol. They deal with operations relating to WLAN
system-wide resource management, WTP management, QoS and STA access monitoring, resource management, QoS and access control.
control.
Security objectives address potential threats to WLANs and their Security objectives address potential threats to WLANs and their
containment. Specifically, they deal with securing the CAPWAP containment. In the CAPWAP context, security requirements cover both
protocol and the WLAN system as a whole. The objectives also address the protocol between WLAN controller and WTPs and also the WLAN
security requirements from end-users and service providers. system as a whole.
5. Architecture Objectives
The architectural considerations of centralized WLAN networks are
fundamental to the development and evaluation of a CAPWAP protocol.
The objectives in this category deal with system level aspects
relating to protocol extensibility, diversity of network deployments
and differences among vendor equipment.
5.1 Interoperability Objective
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.
5.1.1 Objective Details
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. Functionality negotiations between WLAN controller and WTPs
Local MAC and split MAC designs differ in the degree of IEEE 802.11
MAC functionalities that each type of WTP realizes. The CAPWAP
protocol should allow WLAN controllers to determine the
functionalities of different WTPs as a first step in controlling
them.
ii. Establishment of alternative interfaces
The functionality 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
different interfaces. The definition of these interfaces is
dependent on the functionality differences among local MAC and split
MAC WTPs. It is therefore out of scope of the objectives
specifications.
[Functionality Classifications] presents additional details on these 5. Objectives
two aspects. It shows how flexibility in the CAPWAP protocol may be
achieved so as to realize this architecture objective.
This objective also addresses the need for flexibly configuring WTPs The objectives described in this document have been prioritized based
based on their design types and other setup aspects. 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;
5.1.2 Motivation and Protocol Benefits i. Mandatory and Accepted Objectives
ii. Desirable Objectives
iii. Rejected Objectives
iv. Operator Requirements
The benefits of realizing this architecture objective are both The priorities have been assigned to individual objectives in
technical and practical. First, there are substantial overlaps in accordance with working group discussions.
the control operations of local MAC and split MAC architecture
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 5.1 Mandatory and Accepted Objectives
architectural designs enhances its practical prospects as it will
have wider appeal.
Furthermore, the additional complexity resulting from such Objectives prioritized as Mandatory and Accepted have been deemed
alternative interfaces is marginal. Consequently, the benefits of crucial for the control and provisioning of WTPs. They directly
this objective will far outweigh any cost of realizing it. address the challenges of large-scale WLAN deployments and must be
realized by a CAPWAP protocol.
5.1.3 Relation to Problem Statement 5.1.1 Logical Groups
The objective for supporting both local MAC and split MAC WTPs is [Ed. Note: Was 5.2.3i]
fundamental to addressing [I-D.ietf-capwap-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 solutions to the
challenges of large scale WLAN deployments.
5.1.4 Customer Requirements Classification: Architecture
A number of service providers and equipment vendors see benefits with Description:
the combined usage of both local MAC and split MAC designs. WTPs of
different designs are placed in different locations so as to
selectively take advantage of their respective characteristics. The
integral support of different architectures therefore addresses
critical needs for the market.
Furthermore, since there are products of each design type already in Large WLAN deployments are complex and expensive. Furthermore,
the market and widely deployed, it is necessary for CAPWAP protocol enterprises deploying such networks are under pressure to improve the
to support both of them. efficiency of their expenditures.
5.1.5 Classification (Mandatory, Desirable, Rejected) 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.
[TBD] [This section to contain reasons for the particular In traditional WLANs, each physical WTP represents one complete
classification of the objective.] 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
APs are examples of logical groups.
5.2 Interconnection Objective Protocol Requirement:
Large scale WLAN deployments are likely to use a variety of WLAN deployment trends require the CAPWAP protocol to be capable of
interconnection technologies between different devices of the controlling and managing physical WTPs in terms of logical groups.
network. It should therefore be possible for the CAPWAP protocol to
operate over the different interconnection technologies. So the
protocol needs to be independent of underlying transport
technologies.
5.2.1 Objective Details Motivation and Protocol Benefits:
WLAN controllers and WTPs must be able to connect by a variety of Commercial realities necessitate that WLANs be manageable in terms of
interconnection technologies. The fundamental intent is for CAPWAP its logical groups. This allows separation of logical services and
protocol exchanges to be transparent to underlying transport underlying infrastructure management. A protocol that realizes this
technologies. As a result of realizing this objective, the protocol need ensures simlper and cost effective WLANs, which directly address
will be capable of operation over different interconnect technologies the requirements of network service operators.
including Ethernet, bus backplanes, ATM (cell) fabrics and also
wireless technologies such as IEEE 802.11. Ethernet architecture is
most widely used and should be recommended.
The CAPWAP protocol should have the ability to support this diversity Relation to Problem Statement:
of interconnection technologies for data and control exchanges. For
example, VLAN tunnels are an example of an interconnection technology
over which CAPWAP may operate.
Related to this objective, is the QoS aspect of interconnection This objective addresses the problem of management complexity in
technologies. Given that QoS will be enabled differently in each of terms of costs. Cost complexity is reduced by sharing WLAN
these technologies, the CAPWAP protocol must ensure that network deployments. Consequently, deployment and management
performance is consistent across different transport means. cost-efficiencies are realized.
Additionally, QoS consistency has to cover the switching segment and
the wireless medium segment.
5.2.2 Motivation and Protocol Benefits 5.1.2 Support for Traffic Separation
[TBD] [Ed. Note: Was 5.2.7 and 5.2.3ii]
5.2.3 Relation to Problem Statement Classification: Operations
[TBD] Description:
5.2.4 Customer Requirements 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.
[TBD] 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.
5.2.5 Classification (Mandatory, Desirable, Rejected) 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.
[TBD] [This section to contain reasons for the particular Protocol Requirement:
classification of the objective.]
5.3 Support for Logical Networks 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.
Large WLAN deployments are complex and expensive. Furthermore, Motivation and Protocol Benefits:
enterprises are under pressure to improve the efficiency of their
expenditures. These issues are increasingly being addressed by means
of shared deployments. As a result, a number of logical networks
cover a single physical WLAN infrastructure. This way the cost of
deployment and management can be shared among network service
providers. A scenario together with additional details for such
shared WLANs is presented in [Functionality Classifications].
5.3.1 Objective Details 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.
The objective for supporting logical networks involves a number of Furthermore, such separation provides for the separation of data and
aspects. These are discussed below; 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.
i. WLAN management in terms of logical groups Separation of WTP control and data also aids in the secure
realization of shared WLAN deployments.
Traditionally, each WTP has represented one complete subset of a Relation to Problem Statement:
larger WLAN system. However, with shared deployments, each WTP
represents a number of subsets of possibly a number of larger WLAN
systems. So with such deployments, WLANs need to be managed in terms
of logical groups instead of physical devices.
ii. Mutual separation of control and communications 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.
Since different logical networks are likely to be associated to 5.1.3 Wireless Terminal Transparency
different enterprises, it is crucial that control and data
communications among them be mutually separated. In addition to
being a security concern, this aspect of the objective also
highlights a complexity concern. Specifically, mixing of traffic for
different logical networks can complicate control. So the CAPWAP
protocol must be capable of separating traffic among logical
networks. VLANs and other types of tunnels may be used for this
purpose.
iii. Multiple authentication mechanisms [Ed. Note: Was 5.2.4iii]
The presence of multiple logical networks within an infrastructure Classification: Operations
also means there are different subscriber groups in a WLAN system.
Since the subscriber groups are likely to belong to different service
providers or WLAN domains, their authentication needs will also be
different. As a result, the CAPWAP protocol must be capable of
transferring different authentication information. For example, one
subscriber group may be authenticated with IEEE 802.11i with the WLAN
controller being the authenticator, while another group could use web
authentication at an alternative server.
5.3.2 Motivation and Protocol Benefits Description:
Given the realities of cost and complexity of WLANs, a CAPWAP The CAPWAP protocol is applicable between a centralized WLAN
protocol that incorporates the objective of supporting logical controller and a number of WTPs, i.e. it affects only the switching
networks ensures simpler and cost effective WLAN management and segment of the centralized WLAN architecture. Its operations should
deployment. A protocol that realizes this is therefore consistent therefore be independent of the wireless terminal. Wireless
with the goal of reducing complexity in large scale WLANs. terminals should not be required to be aware of the existence of the
CAPWAP protocol.
5.3.3 Relation to Problem Statement Protocol Requirement:
This objective for supporting logical networks addresses problem of Wireless terminals should not be required to recognize or be aware of
management complexity in terms of cost. Such cost complexity is the CAPWAP protocol.
reduced by sharing infrastructure among a number of service
providers. Consequently, deployment and managements
cost-efficiencies are realized.
5.3.4 Customer Requirement Motivation and Protocol Benefits:
Businesses require the benefits of management ease by the most cost IEEE 802.11 based wireless terminals are mature and widely available.
effective means. This can be achieved with the objective of It would be beneficial for CAPWAP not to impose new requirements on
supporting logical networks within a single set of physical WLAN these wireless terminals. In effect, this requirement ensures that
equipment. There are a number of ways of realizing this objective the setup cost of the protocol is reduced as the numerous existing
some being virtual APs, VLAN tunnels and other tunnels. wireless terminals need not be altered.
This objective also allows for separation between providers of Relation to Problem Statement:
infrastructure from services. Logical networks allows for the
separation of physical deployment and maintenance from actual
management of WLANs. This helps lower costs and responsibilities for
service providers.
5.3.5 Classification (Mandatory, Desirable, Rejected) 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.
[TBD] [This section to contain reasons for the particular 5.1.4 Configuration Consistency
classification of the objective.]
5.4 Extensibility Objective [Ed. Note: Was 5.2.5i]
Wireless technology is developing at rapid pace in a number of Classification: Operations
industry and scientific groups. With such pace, it is important to
design CAPWAP in a way as to allow future extensibility. In
particular, the IEEE is in the process of specifying standards for
broadband wireless access, namely IEEE 802.16. There also other
activities within the IEEE that needs to be considered in the CAPWAP
context.
5.4.1 Objective Details Description:
This objective has a number of aspects that are described below; 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.
i. Enable support for future wireless technologies Protocol Requirement:
This aspect of the objective essentially purposes that the CAPWAP
protocol does not rely on specifics of IEEE 802.11 technology for its
operations. This will simplify extensibility to support IEEE 802.16.
ii. Enable support for new IEEE extensions 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.
The IEEE is currently reviewing IEEE 802.11 functionality. It is Motivation and Protocol Benefits:
expected that the review will result in new functional blocks,
interfaces or information flows. The CAPWAP protocol must be able to
handle these revisions with minimal changes.
iii. User(Client) Access Requirement 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.
There should not be any impact on the end-user of CAPWAP WLAN in Relation to Problem Statement:
terms of both hardware and software aspects. End-users should not be
required to be aware of the existence of CAPWAP protocol.
5.4.2 Motivation and Protocol Benefits 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.
[TBD] 5.1.5 Firmware Trigger
5.4.3 Relation to Problem Statement [Ed. Note: Was 5.2.5i]
[TBD] [Ed. Note: Was titled "Firmware Distribution]
5.4.4 Customer Requirements Classification: Operations
Service providers are not enthusiastic about deploying technologies Description:
with limited potential for extension. They require WLAN
infrastructure to be able to meet current and future market
requirements. So the objective for extensibility is critical to
service providers and other customers of WLAN equipment.
5.4.5 Classification (Mandatory, Desirable, Rejected) 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.
[TBD] [This section to contain reasons for the particular Protocol Requirement:
classification of the objective.]
6. Operations Objective The CAPWAP protocol must support a trigger for delivery of firmware
updates.
CAPWAP aims to provide an interoperable solution to the control and Motivation and Protocol Benefits:
provisioning of large scale WLAN deployments. In this context, the
operational objectives address functional aspects of the protocol.
These functions cover system monitoring, resource management and QoS.
6.1 WLAN Monitoring Objective 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.
The scale of WLANs in the CAPWAP context results in numerous Relation to Problem Statement:
information sources. For example, the configuration of each WTP can
be considered as an information source. Additionally, the switching
segment and wireless medium segment can also be considered as
information sources. So for effective performance, the CAPWAP
protocol needs to regularly monitor the various information sources.
6.1.1 Objective Details 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.
Large WLANs need a variety of information sources to be monitored. 5.1.6 Monitoring and Exchange of System-wide Resource State
So this objective includes a number of aspects.
i. Configuration consistency [Ed. Note: Was 5.2.5ii]
CAPWAP based WLANs include a large number of WTPs, each of which need [Ed. Note: Was titled "System-wide Resource State"]
to be configured and managed. The protocol should therefore allow Classification: Operations
WTPs to regularly send information on the state of their
configuration to their WLAN controller. Furthermore, it should also
be capable of consistently distributing firmware to all the WTPs.
ii. System-wide resource state Description:
The centralized WLAN architecture is made up of a switching segment The centralized WLAN architecture is made up of a switching segment
and wireless medium segment. In the switching segment, network and wireless medium segment. In the switching segment, network
congestion and WTP status, including firmware information, have to be congestion, WTP status and firmware information have to be monitored.
monitored. In the wireless medium segment, the dynamic nature of the In the wireless medium segment, the dynamic nature of the medium
medium itself has to be monitored. Overall, there are also various itself has to be monitored. Overall, there are also various
statistics that are required for operation. statistics need to be considered for efficient WLAN operation.
The CAPWAP protocol should therefore be capable of monitoring various The CAPWAP protocol should be capable of monitoring the various
information sources. Moreover, given relationships among information information sources and deliver the resulting information to the
sources, CAPWAP should combine information from such sources. For relevant WLAN devices - either WTPs or WLAN controller. Moreover,
example, statistics information may be merged with status signals. given the relationship among information sources, the CAPWAP protocol
So this aspect of the objective proposes collective information should combine state information from them. For example, statistics
arising from different information sources. Within this aspect of information and status signals from WTPs may be merged before being
the monitoring objective, the protocol may also allow WTPs to send exchanged.
regular send feedback using CAPWAP.
6.1.2 Motivation and Protocol Benefits Examples of statistics information that the CAPWAP protocol should
monitor and exchange include; congestion state, interference levels,
loss rates and various delay factors.
The effectiveness of a protocol is based on the relevance of Protocol Requirement:
information on which it operates. The objective for WLAN monitoring
can provide this information to the CAPWAP protocol. So there will
tangible benefits with this objective.
6.1.3 Relation to Problem Statement The CAPWAP protocol must allow for the exchange of statistics,
congestion and other WLAN state information.
This objective addresses the problems of management complexity. This Motivation and Protocol Benefits:
challenge is better solved with the appropriate information resulting
from this WLAN monitoring. With collective information from various
information sources, realizing this objective will help control and
manage complexity.
The objective also helps address the challenge of maintaining The effectivness of a protocol is based on the relevance of
consistent configurations among WTPs. information on which it operates. This requirement for resource
monitoring and exchange can provide the appropriate information to
the CAPWAP protocol.
6.1.4 Customer Requirement Relation to Problem Statement:
WLAN equipment customers require effective management solutions for The Problem Statement highlights the challenge of dealing with large
their networks. This objective will ensure such a solution by numbers of WTPs and the dynamic nature of the wireless medium.
providing collective information from a variety of information Information on the state of WTPs and the medium is important to deal
sources. with them effectively. So this objective relates to the problem of
managing consistency in large WLANs.
6.1.5 Classification (Mandatory, Desirable, Rejected) 5.1.7 Resource Control Objective
[TBD] [This section to contain reasons for the particular [Ed. Note: Was 5.2.6]
classification of the objective.]
6.2 Resource Control Objective Classification: Operations
Description:
Integral to the success of any wireless network system is the Integral to the success of any wireless network system is the
performance and quality it can offer its subscribers. Since CAPWAP performance and quality it can offer its subscribers. Since CAPWAP
based WLANs combine a switching segment and a wireless medium based WLANs combine a switching segment and a wireless medium
segment, performance and quality need to be coordinated across both segment, performance and quality need to be coordinated across both
of these segments. So QoS performance must be enforced system-wide. of these segments. So QoS performance must be enforced system-wide.
6.2.1 Objective Details This objective highlights QoS over the entire WLAN system which
includes the switching segment and the wireless medium segment.
This objective is for QoS over the entire WLAN system which includes Given the fundamental differences between the two, it is likely that
the switching segment and the wireless medium segment. Given the there are alternate QoS mechanisms between WTPs and wireless service
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 subscribers and between WTPs and WLAN controllers. For instance, the
former will be based on IEEE 802.11e while the latter will be an former will be based on IEEE 802.11e while the latter will be an
alternative. So resources need to be adjusted in a coordinated alternative. So resources need to be adjusted in a coordinated
fashion over both segments. The CAPWAP protocol should ensure that fashion over both segments. The CAPWAP protocol should ensure that
these adjustments are appropriately exchanged between WLAN these adjustments are appropriately exchanged between WLAN
controllers and WTPs. controllers and WTPs.
6.2.2 Motivation and Protocol Benefits 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 A protocol that addresses QoS aspects of WLAN systems will deliver
high performance thereby being beneficial for subscribers and high performance thereby being beneficial for subscribers and for
resource utilization. Since CAPWAP deals with WTPs directly and with resource utilization efficiency. Since CAPWAP deals with WTPs
the wireless medium indirectly, both of these must be considered for directly and with the wireless medium indirectly, both of these must
performance. be considered for performance.
For the wireless medium segment, QoS aspects in the protocol enable For the wireless medium segment, QoS aspects in the protocol enable
high quality communications within the domain of a WLAN controller. high quality communications within the domain of a WLAN controller.
Since each domain generally covers an enterprise or a group of Since each domain generally covers an enterprise or a group of
service providers, such protocol performance has wide-ranging service providers, such protocol performance has wide-ranging
effects. effects.
Within the switching segment of CAPWAP, a QoS-enabled protocol Within the switching segment of CAPWAP, a QoS-enabled protocol
minimizes the adverse effects of dynamic traffic characteristics so minimizes the adverse effects of dynamic traffic characteristics so
as to ensure system-wide performance. as to ensure system-wide performance.
6.2.3 Relation to Problem Statement Relation to Problem Statement:
QoS control is critical to large WLANs and relates to a number of QoS control is critical to large WLANs and relates to a number of
aspects. In particular, this objective can help address the problem aspects. In particular, this objective can help address the problem
of managing dynamic conditions of the wireless medium. of managing dynamic conditions of the wireless medium.
Furthermore, traffic characteristics in large scale WLANs are Furthermore, traffic characteristics in large scale WLANs are
constantly varying. So network utilization becomes inefficient and constantly varying. So network utilization becomes inefficient and
user experience is unpredictable. user experience is unpredictable.
The interaction and coordination between the two aspects of The interaction and coordination between the two aspects of
system-wide QoS is therefore critical for performance. system-wide QoS is therefore critical for performance.
6.2.4 Customer Requirements 5.1.8 CAPWAP Protocol Security
VoIP is a major application over WLANs. The basic requirement for [Ed. Note: Was 5.2.10]
such applications is QoS. Furthermore, end-users demand quality
means of communications, so service providers in turn emphasize on
the QoS capabilities of WLAN systems. Adopting this objective will
ensure all demands are met.
6.2.5 Classification (Mandatory, Desirable, Rejected) Classification: Security
[TBD] [This section to contain reasons for the particular Description:
classification of the objective.]
6.3 Support for Traffic Separation This objective addresses the security of the CAPWAP protocol.
The centralized WLAN architecture simplifies complexity associated The CAPWAP protocol must first provide for the participating entities
with large scale deployments. This is achieved by consolidating some - WLAN controller and WTPs - to be mutually authenticated. This is
functionality at a central WLAN controller and distributing the to ensure that rogue WTPs do not breach legitimate WLAN systems. For
remaining across WTPs. As a result, WTPs and WLAN controller example, WTPs may need to regularly renew their authentication state
exchange control and data among them. This objective suggests with the WLAN controller.
separating control and data aspects of the exchanges for further
simplicity.
6.3.1 Objective Details 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.
It is the aim of CAPWAP to simplify the control and management of As a result of realizing this objective it should not be possible for
large scale WLANs. One way of achieving this is to separate control individual WTP breaches to affect the security of the WLAN as a
and data aspects within the protocol. This will allow solutions for whole. So WTP mis-use will be protected against.
control and data exchanges to be independently optimized.
6.3.2 Motivation and Protocol Benefits 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.
The aim of separating data and control aspects of the protocol is to While mutual authentication is necessary for CAPWAP, the protocol
simplify the protocol. It also allows for flexibility since each should not prevent the use of asymmetric, non-mutual authentication.
part can be separately addressed in the most appropriate manner. The security considerations of such asymmetric authentication are
described in the Security Considerations section.
Furthermore, such separation can also allow separation of data and Protocol Requirement:
control paths. This will enable remotely located WTPs to handle data
in alternative ways instead of forwarding them across a wide network
to the WLAN controller.
6.3.3 Relation to Problem Statement The CAPWAP protocol must support mutual authentication of WTPs and
the centralized controller. It must also ensure that information
exchanges between them are secured.
Broadly, this objective relates to the challenge of managing Motivation and Protocol Benefits:
complexity in large scale WLANs.
6.3.4 Customer Requirements 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.
This objective offers simplicity and flexibility in operation. These Relation to Problem Statement:
are important issues for service providers and other enterprises
deploying large scale WLANs.
6.3.5 Classification (Mandatory, Desirable, Rejected) 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.
[TBD] [This section to contain reasons for the particular 5.1.9 System-wide Security
classification of the objective.]
6.4 STA Admission Control Objective [Ed. Note: Was 5.2.11]
STA Admission control deals with client authentication, handoff Classification: Security
between WTPs, load balance, QoS etc. Access control in the CAPWAP
context must be based on a variety of information. This is because
CAPWAP combines both switching and wireless medium segments.
6.4.1 Objective Details Description:
This objective focuses on access control based on collective The emphasis of this objective is on the security threats external to
information from the switching and wireless medium segments. As the centralized CAPWAP segment of a WLAN system. The focus is
such, access to the WLAN is based on both the radio resources, i.e. therefore on rogue wireless clients and other illegitimate wireless
wireless medium segment and network resources, i.e. switching interferences. There are a number of specific external threats that
segment. need to be addressed within the CAPWAP framework.
6.4.2 Motivation and Protocol Benefits i. PMK Sharing
Due to the scale of deployments in which CAPWAP will be employed, One aspect of this objective relates to recent discussions on PMK
comprehensive access control is crucial. The effectiveness of access sharing in the CAPWAP framework. This objective highlights the need
control in turn is affected by the information on which such control to prevent exploitation of this ambiguity by rogue wireless clients.
is based. As a result, this objective has critical relevance to a It is to ensure that any ambiguities arising from the CAPWAP
CAPWAP protocol. framework are not cause for security breaches.
6.4.3 Relation to Problem Statement Protocol Requirement:
This objective addresses the issue of access control in large WLANs. The design of the CAPWAP protocol should not allow for any
Broadly, it relates the problem of managing the complexity scale of compromises to the WLAN system by external entities.
such networks. With collective information of both switching and
wireless medium segments, realizing this objective will help control
and manage complexity.
6.4.4 Customer Requirements Motivation and Protocol Benefits:
[TBD] 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.
6.4.5 Classification (Mandatory, Desirable, Rejected) Relation to Problem Statement:
[TBD] 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.
6.5 Centralized WTP Management 5.1.10 IEEE 802.11i Considerations
Large scale WLAN deployments necessitate in centralized control. The [Ed. Note: Was 5.2.15]
CAPWAP protocol interfaces the central control to the numerous WTPs.
One aspect of centralized control includes firmware distribution.
This objective relates to configuration aspects of the WLAN.
7. Security Objectives Classification: Operations
Security is a major issue for any communications network and is Description:
especially important for large scale WLANs. In this context,
security must encompass both the protocol between WLAN controller and
WTPs and also the WLAN system as a whole. So the following
objectives deal with securing exchanges between WLAN elements and
devising contingencies in case of physical security breaches.
7.1 CAPWAP Protocol Security 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.
This objective addresses the security of the protocol. 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).
7.1.1 Objective Details 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.
[Note: This objective generally deals with the security between WTP Clearly, the centralized WLAN architecture presents a different
and WLAN controller. It deals with threats that arise from within platform for authentication mechanisms compared to legacy WLANs in
the network infrastructure.] 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.
The CAPWAP protocol between WLAN controller and WTPs must be secured Protocol Requirement:
such that information exchange between them is not threatened. As
such, it must provide confidentiality, integrity and authenticity for
those exchanges.
Furthermore, CAPWAP protocol security must ensure that rogue WTPs do The CAPWAP protocol must determine the exact structure of the
not breach legitimate WLAN systems. The CAPWAP protocol should centralized WLAN architecture in which authentication needs to be
therefore include authentication mechanisms for WTPs. For example, supported, i.e. the location of major authentication components.
WTPs may be required to regularly renew their authentication states. This may be achieved during WTP initialization where major
capabilities are distinguished.
As a result of realizing this objective it should not be possible for The protocol must allow for the exchange of key information when
individual WTP breaches to affect the security of the WLAN as a authenticator and encryption roles are located in distinct entities.
whole. So WTP mis-use will be protected against.
7.2 System-wide Security Motivation and Protocol Benefits:
[Note: This objective is to prevent against security threats from The immediate focus of CAPWAP is on supporting IEEE 802.11 based
outside the CAPWAP framework. Specifically, it addresses threats WLANs. As such, it is necessary for the protocol to recognize the
posed by rogue wireless users. For example, recent discussions of major distinction in WLAN design with respect to IEEE 802.11i
PMK sharing in the CAPWAP context illustrates a situation while may authenticator and encryption points. This represents a significant
be taken advantage of by a rogue wireless user. This objective variation that has been highlighted in the Architecture Taxonomy.
differs from that of the previous section in that it deals with The CAPWAP protocol benefits by accommodating such a major
external threats that may affect the WLAN system. consideration fro IEEE 802.11i.
The emphasis here is that there should be no ambiguities arising from These requirements will be common for all authentication mechanisms
the CAPWAP framework that causes threats from external entities.] over the centralized WLAN architecture. So they are applicable to
IEEE 802.11i, UMA and other mechanisms.
8. Objectives for Further Discussion Relation to Problem Statement:
[Note: The following are some of objectives for further discussion in The Problem Statement highlights the availability of different WTP
the WG.] 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.
8.1 Centralized WTP Management 5.1.11 Interoperability Objective
[Ed. Note: Was 5.2.1]
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 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.
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.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
[Ed. Note: Was 5.2.3iii]
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
[Ed. Note: Was 5.2.4i]
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
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
[Ed. Note: Was 5.2.4ii]
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.
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
[Ed. Note: Was 5.2.2]
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.
5.2.5 Access Control
[Ed. Note: Was 5.2.8]
[Ed. Note: Was titled "STA Admission Control Objective"]
Classification: Operations
[Ed. Note: Priority of this objectives needs to be confirmed by WG.]
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
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
[Ed. Note: Was 5.2.12]
[Ed. Note: Was titled "Centralized WTP Management"]
Classification: Architecture
Description:
The CAPWAP protocol should provide an engine-mechanism to spring WTP The CAPWAP protocol should provide an engine-mechanism to spring WTP
auto-configuration and/or software version updates and should support auto-configuration and/or software version updates and should support
integration with existing network management system. WLAN controller integration with existing network management system. WLAN controller
as a management agent is optional. as a management agent is optional.
If entities other than WLAN controllers manage some aspects of WTPs, If entities other than WLAN controllers manage some aspects of WTPs,
such as software downloads, the CAPWAP protocol may be used for 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. to notify WLAN controllers of any changes made by the other entities.
One example of transport mechanism for the CAPWAP protocol is TCP/IP. Protocol Requirement:
This will bring more flexibility to the way in which WLAN systems are
deployed.
8.2 Security borderline Control The CAPWAP protocol should be capable of recognizing legacy WTPs and
existing network management systems.
[Note: This objective addresses the issue of a large WLAN Motivation and Protocol Benefits:
infrastructure featuring the co-existence of different security
policies for different user groups. It deals with traffic flow
isolation on borderline of any two user groups or two users.]
8.3 Trust model Definition 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.
[Note: When 802.1x authenticator role in 802.11i is relocated from Relation to Problem Statement:
WTP to WLAN controller, the following needs to be clarified for
CAPWAP protocol development; whether there are any potential changes
in the trust relationship between WTP and infrastructure. If there
are changes, the new trust model needs to be defined.]
8.4 IEEE 802.11i Considerations 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.
In the centralized WLAN architecture, authentication based on IEEE 5.4 Operator Requirements
802.11i presents options based on the location of the authenticator.
Particularly, if the authenticator is located within the WLAN
controller, means for key distribution need to be considered, whereas
if the authenticator is within a WTP, communications between the AAA
server and the WTP need to be considered. The CAPWAP protocol should
therefore be able to address these options.
9. Summary and Conclusion The following objectives have been provided by network service
operators. They represent the requirements from those ultimately
deploying the CAPWAP protocol in their WLANs.
The objectives presented in this document address architectural, 5.4.1 AP Fast Handoff
operational and security aspects for CAPWAP. They present a
framework which will be used to develop and evaluate candidate
protocols for managing large scale WLAN deployments.
10. Security Considerations [Ed. Note: Operator requirements from China Mobile]
[Note: This section will detail the security implications of the Classification: Operations
various objectives. One way to look at it would be to analyze the
security considerations of the Architecture Taxonomy and borrow/infer
from it.]
The objective dealing with alternative interfaces covers the Description:
interoperability of WTPs from both local MAC and split MAC designs.
As such, a WLAN controller must be capable of securing both of these
design types. This may include handling different degrees of
security or authentication processing for the two types of WTPs.
In shared deployments with a number of logical networks, it is Network service operators consider handoffs crucially because of the
crucial to ensure mutual separation of traffic among them. Access mobile nature of their customers. In this regard, the CAPWAP
control should therefore be distinct for each of the logical protocol should not adversely affect AP fast handoff procedures. The
networks. Furthermore, subscribers to different service providers protocol may support optimizations for fast handoff procedures so as
need to be managed based on their respective requirements, to allow better support for real-time services during handoffs.
subscriptions, etc. Cross exchanges need to be secured against.
It should be ensured that any stray exchanges be prevented with the Protocol Requirement:
automation of discovery and initialization processes.
The objective for WLAN monitoring relates to security also. Wireless CAPWAP protocol operations must not impede or obstruct the efficacy
systems need to be constantly monitored for potential threats in the of AP fast handoff procedures.
form of rogue WTPs or terminals. For example, profiles for DoS and
replay attacks need to be monitored.
In addition to securing protocol exchanges between devices in large 6. Summary and Conclusion
scale WLANs, the CAPWAP protocol should also incorporate
contingencies for physical security breaches. For instance, it
should be ensured that the network as a whole is not compromised if a
single AP is stolen or otherwise compromised. The protocol should
therefore contain measures to detect and contain physical security
threats.
11. Contributors The objectives presented in this document address three main aspects
of the CAPWAP protocol, namely;
This document is the result of a merger of two individual i. Architecture
Internet-Draft submissions. The authors of both drafts have ii. Operations
contributed to shape this document. The authors are; iii. Security
Meimei Dang These requirements are aimed to focus standardization efforts on a
RITT, CATR simple, interoperable protocol for managing large-scale WLANs. The
No.11 YueTanNanJie, Xicheng District architecture requirements specify the structural features of the
Beijing 100045 protocol such as those relating to WTP types (local-MAC and
P. R. China split-MAC) and WTP structures (logical groups). The operations
Phone: +86 10 68094457 requirements address the functional aspects dealing with WTP
Email: dangmeimei@mail.ritt.com.cn configuration and management. Finally, the security requirements
cover authentication and integrity aspects of protocol exchanges.
Satoshi Iino The objectives have additionally been prioritized to reflect their
Panasonic Mobile Communications immediate significance to the development and evaluation of an
600, Saedo-cho interoperable CAPWAP protocol. The priorities are Mandatory and
Tsuzuki-ku Accepted, Desirable and Rejected. They reflect working group
Yokohama 224 8539 consensus on the effectiveness of the requirements in the context of
Japan protocol design.
Phone: +81 45 938 3789
EMail: iino.satoshi@jp.panasonic.com
Mikihito Sugiura Additionally, this document includes requirements from network
Panasonic Mobile Communications service operators that have been derived based on their experience in
600, Saedo-cho operating large- scale WLANs.
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
EMail: sugiura.mikihito@jp.panasonic.com
Dong Wang The resulting requirements from this document will be used in
ZTE conjunction with the CAPWAP Problem Statement
No.68 Zijinghua Rd, Yuhuatai District [I-D.ietf-capwap-problem-statement] and CAPWAP Architecture Taxonomy
Tsuzuki-ku [I-D.ietf-capwap-arch] to develop and evalute an interoperable
Nanjing, Jiangsu Prov. 210 012 protocol for the control and provisioning of WTPs in large-scale
P. R. China WLANs.
Phone: +86 25 5287 1713
EMail: wang.dong@mail.zte.com.cn
12. Acknowledgements 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.
8. Acknowledgements
The authors would like to thank the Working Group Chairs, Dorothy The authors would like to thank the Working Group Chairs, Dorothy
Gellert and Mahalingam Mani, for their support and patience with this Gellert and Mahalingam Mani, for their support and patience with this
document. We would also like to thank participants of the Working document. We would also like to thank participants of the Working
Group who have helped shape the objectives. In particular, the Group who have helped shape the objectives. In particular, the
authors thank Pat Calhoun and Inderpreet Singh for their invaluable authors thank James Kempf, Pat Calhoun, Inderpreet Singh and T.
inputs. Sridhar for their invaluable inputs. The authors also acknowledge
the contributions from Meimei Dang, Satoshi Iino, Mikihito Sugiura
13 References and Dong Wang.
[Functionality Classifications] 9. References
Cheng, H. et al, "Functionality Classifications for
Control and Provisioning of Wireless Access Points",
draft-cheng-capwap-classifications-01, (work in
progress), July 2004.
[I-D.ietf-capwap-arch] [I-D.ietf-capwap-arch]
Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access for Control and Provisioning of Wireless Access
Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in Points(CAPWAP)", Internet-Draft draft-ietf-capwap-arch-06,
progress), November 2004. November 2004.
[I-D.ietf-capwap-problem-statement] [I-D.ietf-capwap-problem-statement]
Calhoun, P., "CAPWAP Problem Statement", Calhoun, P., "CAPWAP Problem Statement",
draft-ietf-capwap-problem-statement-02 (work in progress), Internet-Draft draft-ietf-capwap-problem-statement-02,
September 2004. September 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses Authors' Addresses
Saravanan Govindan Saravanan Govindan
Panasonic Singapore Laboratories Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue #06-3530, Tai Seng Avenue
Singapore 534 415 Singapore 534 415
Singapore Singapore
Phone: +65 6550 5441 Phone: +65 6550 5441
EMail: sgovindan@psl.com.sg Email: sgovindan@psl.com.sg
Zhonghui Yao Zhonghui Yao
Huawei Longgang Production Base Huawei Longgang Production Base
Shenzhen 518 129 Shenzhen 518 129
P. R. China P. R. China
Phone: +86 755 2878 0808 Phone: +86 755 2878 0808
EMail: yaoth@huawei.com Email: yaoth@huawei.com
Wenhui Zhou Wenhui Zhou
China Mobile China Mobile
53A, Xibianmen Ave, Xuanwu District 53A, Xibianmen Ave, Xuanwu District
Beijing 100 053 Beijing 100 053
P. R. China P. R. China
Phone: +86 10 6600 6688 ext.3061 Phone: +86 10 6600 6688 ext.3061
EMail: zhouwenhui@chinamobile.com Email: zhouwenhui@chinamobile.com
L. Lily Yang L. Lily Yang
Intel Corp. Intel Corp.
JF3-206, 2111 NE 25th Ave. JF3-206, 2111 NE 25th Ave.
Hilsboro, OR 97124 Hilsboro, OR 97124
USA USA
Phone: +1 503 264 8813 Phone: +1 503 264 8813
EMail: lily.l.yang@intel.com Email: lily.l.yang@intel.com
Hong Cheng Hong Cheng
Panasonic Singapore Laboratories Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue #06-3530, Tai Seng Avenue
Singapore 534 415 Singapore 534 415
Singapore Singapore
Phone: +65 6550 5447 Phone: +65 6550 5447
EMail: hcheng@psl.com.sg Email: hcheng@psl.com.sg
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 26, line 41 skipping to change at page 30, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/