Request for Comments: 4565 Envysion, Inc.
Category: Informational D. Nelson
Enterasys Networks, Inc.
O. Volinsky
Colubris Networks, Inc.
B. Sarikaya
Huawei USA
July 2006
Evaluation of Candidate Control and Provisioning
of Wireless Access Points (CAPWAP) Protocols
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document is a record of the process and findings of the Control
and Provisioning of Wireless Access Points Working Group (CAPWAP WG)
evaluation team. The evaluation team reviewed the 4 candidate
protocols as they were submitted to the working group on June 26,
2005.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Process Description .............................................3
2.1. Ratings ....................................................3
3. Member Statements ...............................................4
4. Protocol Proposals and Highlights ...............................5
4.1. LWAPP ......................................................5
4.2. SLAPP ......................................................6
4.3. CTP ........................................................6
4.4. WiCoP ......................................................7
5. Security Considerations .........................................7
6. Mandatory Objective Compliance Evaluation .......................8
6.1. Logical Groups .............................................8
6.2. Traffic Separation .........................................8
6.3. STA Transparency ...........................................9
6.4. Configuration Consistency .................................10
6.5. Firmware Trigger ..........................................11
6.6. Monitor and Exchange of System-wide Resource State ........12
6.7. Resource Control ..........................................13
6.8. Protocol Security .........................................15
6.9. System-Wide Security ......................................16
6.10. 802.11i Considerations ...................................17
6.11. Interoperability .........................................17
6.12. Protocol Specifications ..................................18
6.13. Vendor Independence ......................................19
6.14. Vendor Flexibility .......................................19
6.15. NAT Traversal ............................................20
7. Desirable Objective Compliance Evaluation ......................20
7.1. Multiple Authentication ...................................20
7.2. Future Wireless Technologies ..............................21
7.3. New IEEE Requirements .....................................21
7.4. Interconnection (IPv6) ....................................22
7.5. Access Control ............................................23
8. Evaluation Summary and Conclusions .............................24
9. Protocol Recommendation ........................................24
9.1. High-Priority Recommendations Relevant to
Mandatory Objectives ......................................25
9.1.1. Information Elements ...............................25
9.1.2. Control Channel Security ...........................25
9.1.3. Data Tunneling Modes ...............................26
9.2. Additional Recommendations Relevant to Desirable
Objectives ................................................27
9.2.1. Access Control .....................................27
9.2.2. Removal of Layer 2 Encapsulation for Data
Tunneling ..........................................28
9.2.3. Data Encapsulation Standard ........................28
10. Normative References ..........................................29
11. Informative References ........................................29
1. Introduction
This document is a record of the process and findings of the Control
and Provisioning of Wireless Access Points Working Group (CAPWAP WG)
evaluation team. The evaluation team reviewed the 4 candidate
protocols as they were submitted to the working group on June 26,
2005.
1.1. Conventions Used in This Document
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 RFC 2119 [RFC2119].
1.2. Terminology
This document uses terminology defined in RFC 4118 [ARCH], RFC 4564
[OBJ], and IEEE 802.11i [802.11i].
2. Process Description
The process to be described here has been adopted from a previous
evaluation in IETF [RFC3127]. The CAPWAP objectives in RFC 4564
[OBJ] were used to set the scope and direction for the evaluators and
was the primary source of requirements. However, the evaluation team
also used their expert knowledge and professional experience to
consider how well a candidate protocol met the working group
objectives.
For each of the 4 candidate protocols, the evaluation document editor
assigned 2 team members to write evaluation briefs. One member was
assigned to write a "Pro" brief and could take a generous
interpretation of the proposal; this evaluator could grant benefit of
doubt. A second evaluator was assigned to write a "Con" brief and
was required to use strict criteria when performing the evaluation.
2.1. Ratings
The "Pro" and "Con" members independently evaluated how well the
candidate protocol met each objective. Each objective was scored as
an ’F’ for failure, ’P’ for partial, or ’C’ for completely meeting
the objective.
F - Failure to Comply
The evaluation team believes the proposal does not meet the
objective. This could be due to the proposal completely missing any
functionality towards the objective. A proposal could also receive
an ’F’ for improperly implementing the objective.
P - Partial Compliance
The proposal has some functionality that addresses the objective, but
it is incomplete or ambiguous.
C - Compliant
The proposal fully specifies functionality meeting the objective.
The specification must be detailed enough that interoperable
implementations are likely from reading the proposal alone. If the
method is ambiguous or particularly complex, an explanation, use
cases, or even diagrams may need to be supplied in order to receive a
compliant rating.
The 4-person evaluation team held a teleconference for each candidate
to discuss the briefs. One of the working group chairs was also
present at the meeting in an advisory capacity. Each evaluator
presented a brief with supporting details. The team discussed the
issues and delivered a team rating for each objective. These
discussions are documented in the meeting minutes. The team ratings
are used for the compliance evaluation.
The candidate protocols were scored only on the information written
in their draft. This means that a particular protocol might actually
meet the specifics of a requirement, but if the proposal did not
state, describe, or reference how that requirement was met, it might
be scored lower.
3. Member Statements
Darren Loher, Roving Planet
I am employed as the senior architect at Roving Planet, which writes
network and security management software for wireless networks. I
have over 11 years of commercial experience designing and operating
networks. I have implemented and operated networks and network
management systems for a university, large enterprises, and a major
Internet service provider for over 4 years. I also have software
development experience and have written web-based network and systems
management tools including a system for managing a very large
distributed DNS system. I have witnessed the IETF standards process
for several years, my first event being IETF 28. I have rarely
directly participated in any working group activities before this
point. To my knowledge, my company has no direct relationship with
any companies that have authored the CAPWAP protocol submissions.
David Nelson, Enterasys
I am currently cochair of the RADEXT WG, AAA Doctor in O&M Area, and
employed in the core router engineering group of my company. I have
previously served on a protocol evaluation team in the AAA WG, and am
a coauthor of RFC 3127 [RFC3127]. I was an active contributor in the
IEEE 802.11i task group, and previously employed in the WLAN
engineering group of my company. I have had no participation in any
of the submitted protocols. My company does have an OEM relationship
with at least one company whose employees have coauthored one of the
submissions, but I have no direct involvement with our WLAN product
at this time.
Oleg Volinsky, Colubris Networks
I am a member of the Enterprise group of Colubris Networks, a WLAN
vendor. I have over 10 years of experience in design and development
of network products from core routers to home networking equipment.
Over years I have participated in various IETF groups. I have been a
member of CAPWAP WG for over a year. In my current position I have
been monitoring the developments of CAPWAP standards and potential
integration of the resulting protocol into the company’s products. I
have not participated in any of the candidate protocol drafts. I
have not worked for any of the companies whose staff authored any of
the candidate protocols.
Behcet Sarikaya, University of Northern British Columbia
I am currently Professor of Computer Science at UNBC. I have so far
5 years of experience in IETF as a member of mobile networking-
related working groups. I have made numerous I-D contributions and
am a coauthor of one RFC. I have submitted an evaluation draft (with
Andy Lee) that evaluated LWAPP, CTP, and WiCoP. Also I submitted
another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP, and SLAPP as
transport. I also have research interests on next-generation access
point/controller architectures. I have no involvement in any of the
candidate protocol drafts, have not contributed any of the drafts. I
have not worked in any of the companies whose staff has produced any
of the candidate protocols.
4. Protocol Proposals and Highlights
The following proposals were submitted as proposals to the CAPWAP
working group.
4.1. LWAPP
The "Light Weight Access Point Protocol" [LWAPP] was the first CAPWAP
protocol originally submitted to Seamoby Working Group. LWAPP
proposes original solutions for authentication and user data
encapsulation as well as management and configuration information
elements. LWAPP originated as a "split MAC" protocol, but recent
changes have added local MAC support as well. LWAPP has received a
security review from Charles Clancy of the University of Maryland
Information Systems Security Lab.
LWAPP is the most detailed CAPWAP proposal. It provides a thorough
specification of the discovery, security, and system management
methods. LWAPP focuses on the 802.11 WLAN-specific monitoring and
configuration. A key feature of LWAPP is its use of raw 802.11
frames that are tunneled back to the Access Controller (AC) for
processing. In both local- and split-MAC modes, raw 802.11 frames
are forwarded to the AC for management and control. In addition, in
split-MAC mode, user data is tunneled in raw 802.11 form to the AC.
While in concept, LWAPP could be used for other wireless
technologies, LWAPP defines very few primitives that are independent
of the 802.11 layer.
4.2. SLAPP
"Secure Light Access Point Protocol" [SLAPP] distinguishes itself
with the use of well-known, established technologies such as Generic
Routing Encapsulation (GRE) for user data tunneling between the AC
and Wireless Termination Point (WTP) and the proposed standard
Datagram Transport Layer Security [DTLS] for the control channel
transport.
4 modes of operation are supported, 2 local-MAC modes and 2 split-MAC
modes. STA control may be performed by the AC using native 802.11
frames that are encapsulated in SLAPP control packets across all
modes. (STA refers to a wireless station, typically a laptop.)
In SLAPP local-MAC modes, user data frames may be bridged or tunneled
back using GRE to the AC as 802.3 frames. In the split-MAC modes,
user data is always tunneled back to the AC as native 802.11 frames.
Encryption of user data may be performed at either the AC or the WTP
in split-MAC mode.
4.3. CTP
"CAPWAP Tunneling Protocol" [CTP] distinguishes itself with its use
of Simple Network Management Protocol (SNMP) to define configuration
and management data that it then encapsulates in an encrypted control
channel. CTP was originally designed as a local-MAC protocol but the
new version has split-MAC support as well. In addition, CTP is
clearly designed from the beginning to be compatible with multiple
wireless technologies.
CTP defines information elements for management and control between
the AC and WTP. CTP control messages are specified for STA session
state, configuration, and statistics.
In local-MAC mode, CTP does not forward any native wireless frames to
the AC. CTP specifies control messages for STA session activity,
mobility, and radio frequency (RF) resource management between the AC
and WTP. CTP local-MAC mode specifies that the integration function
from the wireless network to 802.3 Ethernet is performed at the WTP
for all user data. User data may either be bridged at the WTP or
encapsulated as 802.3 frames in CTP packets at the WTP and tunneled
to the AC.
CTP’s split-MAC mode is defined as an extension to local-MAC mode.
In CTP’s version of split-MAC operation, wireless management frames
are forwarded in their raw format to the AC. User data frames may be
bridged locally at the WTP, or they may be encapsulated in CTP
packets and tunneled in their native wireless form to the AC.
CTP supplies STA control abstraction, methods for extending the
forwarding of multiple types of native wireless management frames,
and many options for user data tunneling. Configuration management
is an extension of SNMP. This makes CTP one of the most flexible of
the proposed CAPWAP protocols. However, it does define new security
and data tunneling mechanisms instead of leveraging existing
standards.
4.4. WiCoP
"Wireless LAN Control Protocol" [WICOP] introduces new discovery,
configuration, and management of Wireless LAN (WLAN) systems. The
protocol defines a distinct discovery mechanism that integrates WTP-
AC capabilities negotiation.
WiCoP defines 802.11 Quality of Service (QoS) parameters. In
addition, the protocol proposes to use standard security and
authentication methods such as IPsec and Extensible Authentication
Protocol (EAP). The protocol needs to go into detail with regards to
explicit use of the above-mentioned methods. To ensure interoperable
protocol implementations, it is critical to provide users with
detailed unambiguous specification.
5. Security Considerations
Each of the candidate protocols has a Security Considerations
section, as well as security properties. The CAPWAP objectives
document [OBJ] contains security-related requirements. The
evaluation team has considered if and how the candidate protocols
implement the security features required by the CAPWAP objectives.
However, this evaluation team is not a security team and has not
performed a thorough security evaluation or tests. Any protocol
coming out of the CAPWAP working group must undergo an IETF security
review in order to fully meet the objectives.
6. Mandatory Objective Compliance Evaluation
6.1. Logical Groups
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP
LWAPP provides a control message called "Add WLAN". This message is
used by the AC to create a WLAN with a unique ID, i.e., its Service
Set Identifier (SSID). The WTPs in this WLAN have their own Basic
Service Set Identifiers (BSSIDs). LWAPP meets this objective.
SLAPP
SLAPP explicitly supports 0-255 BSSIDs.
CTP
CTP implements a NETWORK_ID attribute that allows a wireless-
technology-independent way of creating logical groups. CTP meets
this objective.
WiCoP
WiCoP provides control tunnels to manage logical groups. There is
one control tunnel for each logical group. WiCoP meets this
objective.
6.2. Traffic Separation
LWAPP:C, SLAPP:C, CTP:P, WiCoP:P
If a protocol distinguishes a data message from a control message,
then it meets this objective.
LWAPP
LWAPP separates control messages from data messages using "C-bit".
"C-bit" is defined in the LWAPP transport header. When C-bit is
equal to zero, the message is a data message. When C-bit is equal to
one, the message is a control message. So, LWAPP meets this
objective.
SLAPP
The SLAPP protocol encapsulates control using DTLS and optionally,
user data with GRE. Of particular note, SLAPP defines 4
"architecture modes" that define how user data is handled in relation
to the AC. SLAPP is compliant with this objective.
CTP
CTP defines separate packet frame types for control and data.
However, the evaluation team could not find a way to configure the
tunneling of user data, so it opted to rate CTP as only partially
compliant. It appears that CTP would rely on SNMP MIB Object
Identifiers (OIDs) for this function, but none were defined in the
specification. Defining the necessary OIDs would make CTP fully
compliant.
WiCoP
WiCoP provides for separation between control and data channels.
However, tunneling methods are not explicitly described. Because of
this, WiCoP partially meets this objective.
6.3. STA Transparency
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
If a protocol does not indicate that STA needs to know about the
protocol, then this objective is met.
The protocol must not define any message formats between STA and
WTP/AC.
LWAPP
LWAPP does not require a STA to be aware of LWAPP. No messages or
protocol primitives are defined that the STA must interact with
beyond the 802.11 standard. LWAPP is fully compliant.
SLAPP
SLAPP places no requirements on STA network elements. No messages or
protocol primitives are defined that the STA must interact with
beyond the 802.11 standard.
CTP
CTP does not require a terminal to know CTP. So, CTP meets this
objective.
WiCoP
WiCoP does not require a terminal to know WiCoP. So, WiCoP meets
this objective.
6.4. Configuration Consistency
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
Given the objective of maintaining configurations for a large number
of network elements involved in 802.11 wireless networks, the
evaluation team would like to recommend that a token, key, or serial
number for configuration be implemented for configuration
verification.
LWAPP
It is possible to obtain and verify all configurable values through
LWAPP. Notably, LWAPP takes an approach that only "non-default"
settings (defaults are specified by LWAPP) are necessary for
transmission when performing configuration consistency checks. This
behavior is explicitly specified in LWAPP. LWAPP is compliant with
this objective.
SLAPP
Numerous events and statistics are available to report configuration
changes and WTP state. SLAPP does not have any built-in abilities to
minimize or optimize configuration consistency verification, but it
is compliant with the objective.
CTP
CTP’s use of SNMP makes configuration consistency checking
straightforward. Where specified in a MIB, one could take advantage
of default values.
WICOP
The WiCoP configuration starts with exchange of capability messages
between the WTP and AC. Next, configuration control data is sent to
the WTP.
WiCoP defines configuration values in groups of configuration data
messages. In addition, the protocol supports configuration using MIB
objects. To maintain data consistency, each configuration message
from the AC is acknowledged by the WTP.
6.5. Firmware Trigger
LWAPP:P, SLAPP:P, CTP:P, WiCoP:C
The evaluation team considered the objective and determined that for
full compliance, the protocol state machine must support the ability
to initiate the process for checking and performing a firmware update
independently of other functions.
Many protocols perform a firmware check and update procedure only on
system startup time. This method received a partial compliance. The
team believed that performing the firmware check only at startup time
was unnecessarily limiting and that allowing it to occur at any time
in the state machine did not increase complexity of the protocol.
Allowing the firmware update process to be initiated during the
running state allows more possibilities for minimizing downtime of
the WTP during the firmware update process.
For example, the firmware check and download of the image over the
network could potentially occur while the WTP was in a running state.
After the file transfer was complete, the WTP could be rebooted just
once and begin running the new firmware image. This could pose a
meaningful reduction in downtime when the firmware image is large,
the link for loading the file is very slow, or the WTP reboot time is
long.
A protocol would only fail compliance if no method was specified for
updating of firmware.
LWAPP
Firmware download is initiated by the WTP only at the Join phase
(when a WTP is first associating with an AC) and not at any other
time. The firmware check and update could be "triggered" indirectly
by the AC by sending a reset message to the WTP. The resulting
reboot would cause a firmware check and update to be performed.
LWAPP is partially compliant because its firmware trigger can only be
used in the startup phases of the state machine.
SLAPP
SLAP includes a firmware check and update procedure that is performed
when a WTP is first connecting to an AC. The firmware check and
update can only be "triggered" indirectly by the AC by sending a
reset message to the WTP. SLAPP is partially compliant because its
firmware trigger can only be used in the startup phases of the state
machine.
CTP
The CTP state machine specifies that the firmware upgrade procedure
must be performed immediately after the authentication exchange as
defined in section 6.2 of [CTP]. However, section 5.2.5 of [CTP]
states that the SW-Update-Req message MAY be sent by the AC. This
indirectly implies that CTP could support an AC-triggered software
update during the regular running state of the WTP. So it seems that
CTP might be fully compliant, but the proposal should be clarified
for full compliance.
WiCoP
In WiCoP, firmware update may be triggered any time in the active
state, so WiCoP is fully compliant.
6.6. Monitor and Exchange of System-wide Resource State
LWAPP:C, SLAPP:C, CTP:P, WiCoP:C
The evaluation team focused on the protocols supplying 3 methods
relevant to statistics from WTPs: The ability to transport
statistics, a minimum set of standard data, and the ability to extend