draft-ietf-capwap-eval-00.txt   rfc4565.txt 
Network Working Group D. Loher Network Working Group D. Loher
Internet-Draft Roving Planet, Inc. Request for Comments: 4565 Envysion, Inc.
Expires: February 2, 2006 D. Nelson Category: Informational D. Nelson
Enterasys Networks, Inc. Enterasys Networks, Inc.
O. Volinsky O. Volinsky
Colubris Networks, Inc. Colubris Networks, Inc.
B. Sarikaya B. Sarikaya
UNBC Huawei USA
August 2005 Evaluation of Candidate Control and Provisioning
of Wireless Access Points (CAPWAP) Protocols
Evaluation of Candidate CAPWAP Protocols
draft-ietf-capwap-eval-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2006. 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 Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document is a record of the process and findings of the This document is a record of the process and findings of the Control
Configuration and Provisioning of Wireless Access Points Working and Provisioning of Wireless Access Points Working Group (CAPWAP WG)
Group (CAPWAP WG) evaluation team. The evaluation team reviewed the evaluation team. The evaluation team reviewed the 4 candidate
four candidate protocols as they were submitted to the working group protocols as they were submitted to the working group on June 26,
on the 26th of June, 2005. 2005.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document ..........................3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology ................................................3
2. Process Description . . . . . . . . . . . . . . . . . . . . . 5 2. Process Description .............................................3
2.1. Ratings . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Ratings ....................................................3
3. Member Statements . . . . . . . . . . . . . . . . . . . . . . 7 3. Member Statements ...............................................4
4. Protocol Proposals and Highlights . . . . . . . . . . . . . . 9 4. Protocol Proposals and Highlights ...............................5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.1. LWAPP ......................................................5
6. Mandatory Objective Compliance Evaluation . . . . . . . . . . 12 4.2. SLAPP ......................................................6
6.1. Logical Groups . . . . . . . . . . . . . . . . . . . . . . 12 4.3. CTP ........................................................6
6.2. Traffic Separation . . . . . . . . . . . . . . . . . . . . 12 4.4. WiCoP ......................................................7
6.3. STA Transparency . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations .........................................7
6.4. Configuration Consistency . . . . . . . . . . . . . . . . 14 6. Mandatory Objective Compliance Evaluation .......................8
6.5. Firmware Trigger . . . . . . . . . . . . . . . . . . . . . 14 6.1. Logical Groups .............................................8
6.6. Monitor and Exchange of System-wide Resource State . . . . 16 6.2. Traffic Separation .........................................8
6.7. Resource Control . . . . . . . . . . . . . . . . . . . . . 17 6.3. STA Transparency ...........................................9
6.8. Protocol Security . . . . . . . . . . . . . . . . . . . . 18 6.4. Configuration Consistency .................................10
6.9. System-Wide Security . . . . . . . . . . . . . . . . . . 19 6.5. Firmware Trigger ..........................................11
6.10. 802.11i Considerations . . . . . . . . . . . . . . . . . . 20 6.6. Monitor and Exchange of System-wide Resource State ........12
6.11. Interoperability . . . . . . . . . . . . . . . . . . . . . 21 6.7. Resource Control ..........................................13
6.12. Protocol Specifications . . . . . . . . . . . . . . . . . 21 6.8. Protocol Security .........................................15
6.13. Vendor Independence . . . . . . . . . . . . . . . . . . . 22 6.9. System-Wide Security ......................................16
6.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . . . 22 6.10. 802.11i Considerations ...................................17
6.15. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 23 6.11. Interoperability .........................................17
7. Desirable Objective Compliance Evaluation . . . . . . . . . . 24 6.12. Protocol Specifications ..................................18
7.1. Multiple Authentication . . . . . . . . . . . . . . . . . 24 6.13. Vendor Independence ......................................19
7.2. Future Wireless Technologies . . . . . . . . . . . . . . . 24 6.14. Vendor Flexibility .......................................19
7.3. New IEEE Requirements . . . . . . . . . . . . . . . . . . 25 6.15. NAT Traversal ............................................20
7.4. Interconnection (IPv6) . . . . . . . . . . . . . . . . . . 25 7. Desirable Objective Compliance Evaluation ......................20
7.5. Access Control . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Multiple Authentication ...................................20
8. Evaluation Summary and Conclusions . . . . . . . . . . . . . . 27 7.2. Future Wireless Technologies ..............................21
9. Protocol Recommendation . . . . . . . . . . . . . . . . . . . 28 7.3. New IEEE Requirements .....................................21
9.1. High priority recommendations relevant to mandatory 7.4. Interconnection (IPv6) ....................................22
objectives . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5. Access Control ............................................23
9.1.1. Information Elements . . . . . . . . . . . . . . . . . 28 8. Evaluation Summary and Conclusions .............................24
9.1.2. Control Channel Security . . . . . . . . . . . . . . . 28 9. Protocol Recommendation ........................................24
9.1.3. Data Tunneling Modes . . . . . . . . . . . . . . . . . 29 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 9.2. Additional Recommendations Relevant to Desirable
Objectives . . . . . . . . . . . . . . . . . . . . . . . . 31 Objectives ................................................27
9.2.1. Access Control . . . . . . . . . . . . . . . . . . . . 31 9.2.1. Access Control .....................................27
9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling . 31 9.2.2. Removal of Layer 2 Encapsulation for Data
9.2.3. Data Encapsulation Standard . . . . . . . . . . . . . 31 Tunneling ..........................................28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.2.3. Data Encapsulation Standard ........................28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Normative References ..........................................29
Intellectual Property and Copyright Statements . . . . . . . . . . 34 11. Informative References ........................................29
1. Definitions 1. Introduction
1.1. Conventions used in this document 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", 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
This document follows the terminology defined in [ARCH] (a work in This document uses terminology defined in RFC 4118 [ARCH], RFC 4564
progress), and [OBJ] (also a work in progress). [OBJ], and IEEE 802.11i [802.11i].
2. Process Description 2. Process Description
The process to be described here has been adopted from a previous The process to be described here has been adopted from a previous
evaluation in IETF [RFC3127]. The CAPWAP objectives draft [OBJ] was evaluation in IETF [RFC3127]. The CAPWAP objectives in RFC 4564
used to set the scope and direction for the evaluators and was the [OBJ] were used to set the scope and direction for the evaluators and
primary source of requirements. However, the evaluation team also was the primary source of requirements. However, the evaluation team
used their expert knowledge and professional experience to consider also used their expert knowledge and professional experience to
how well a candidate protocol met the working group objectives. consider how well a candidate protocol met the working group
objectives.
For each of the four candidate protocols, the evaluation draft editor For each of the 4 candidate protocols, the evaluation document editor
assigned two team members to write evaluation briefs. One member was assigned 2 team members to write evaluation briefs. One member was
assigned to write a 'Pro' brief and could take a generous assigned to write a "Pro" brief and could take a generous
interpretation of the proposal; this evaluator could grant benefit of interpretation of the proposal; this evaluator could grant benefit of
doubt. A second evaluator was assigned to write a 'Con' brief and doubt. A second evaluator was assigned to write a "Con" brief and
was required to use strict criteria when performing the evaluation. was required to use strict criteria when performing the evaluation.
2.1. Ratings 2.1. Ratings
The "Pro and "Con" members independently evaluated how well the The "Pro" and "Con" members independently evaluated how well the
candidate protocol met each objective. Each objective was scored as candidate protocol met each objective. Each objective was scored as
an 'F' for failure , 'P' for partial or 'C' for completely meeting an 'F' for failure, 'P' for partial, or 'C' for completely meeting
the objective. the objective.
F - Failure to Comply F - Failure to Comply
The evaluation team believes the proposal does not meet the The evaluation team believes the proposal does not meet the
objective. This could be due to the proposal completely missing any objective. This could be due to the proposal completely missing any
functionality towards the objective. A proposal could also receive functionality towards the objective. A proposal could also receive
an 'F' for improperly implementing the objective. an 'F' for improperly implementing the objective.
P - Partial Compliance P - Partial Compliance
The proposal has some functionality that addresses the objective, but The proposal has some functionality that addresses the objective, but
it is incomplete or ambiguous. it is incomplete or ambiguous.
C - Compliant C - Compliant
The proposal fully specifies functionality meeting the objective. The proposal fully specifies functionality meeting the objective.
The specification must be detailed enough that interoperable The specification must be detailed enough that interoperable
implementations are likely from reading the proposal alone. If the implementations are likely from reading the proposal alone. If the
method is ambiguous or particularly complex, an explanation, use method is ambiguous or particularly complex, an explanation, use
cases or even diagrams may need to be supplied in order to receive a cases, or even diagrams may need to be supplied in order to receive a
compliant rating. compliant rating.
The four person evaluation team held a teleconference for each The 4-person evaluation team held a teleconference for each candidate
candidate to discuss the briefs. One of the working group chairs was to discuss the briefs. One of the working group chairs was also
also present at the meeting in an advisory capacity. Each evaluator present at the meeting in an advisory capacity. Each evaluator
presented their brief with supporting details. The team discussed presented a brief with supporting details. The team discussed the
the issues and delivered a team rating for each objective. These issues and delivered a team rating for each objective. These
discussions are documented in the meeting minutes. The team ratings discussions are documented in the meeting minutes. The team ratings
are used for the compliance evaluation. are used for the compliance evaluation.
The candidate protocols were scored only on the information written The candidate protocols were scored only on the information written
in their draft. This means that a particular protocol might actually in their draft. This means that a particular protocol might actually
meet the specifics of a requirement, but if the proposal did not meet the specifics of a requirement, but if the proposal did not
state, describe or reference how that requirement was met, it might state, describe, or reference how that requirement was met, it might
be scored lower. be scored lower.
3. Member Statements 3. Member Statements
Darren Loher, Roving Planet Darren Loher, Roving Planet
I am employed as the senior architect at Roving Planet which writes I am employed as the senior architect at Roving Planet, which writes
network and security management software for wireless networks. I network and security management software for wireless networks. I
have over 11 years of commercial experience designing and operating have over 11 years of commercial experience designing and operating
networks. I have implemented and operated networks and network networks. I have implemented and operated networks and network
management systems for a university, large enterprises and a major management systems for a university, large enterprises, and a major
Internet service provider for over 4 years. I also have software Internet service provider for over 4 years. I also have software
development experience and have written web based network and systems development experience and have written web-based network and systems
management tools including a system for managing a very large management tools including a system for managing a very large
distributed DNS system. I have witnessed the IETF standards process distributed DNS system. I have witnessed the IETF standards process
for several years, my first event being IETF 28. I have rarely for several years, my first event being IETF 28. I have rarely
directly participated in any working group activities before this directly participated in any working group activities before this
point. To my knowledge, my company has no direct relationship with point. To my knowledge, my company has no direct relationship with
any companies that have authored the CAPWAP protocol submissions. any companies that have authored the CAPWAP protocol submissions.
David Nelson, Enterasys David Nelson, Enterasys
I am currently co-chair of the RADEXT WG, AAA Doctor in O&M Area, and 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 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 previously served on a protocol evaluation team in the AAA WG, and am
a co-author of RFC 3127 [RFC3127]. I was an active contributor in a coauthor of RFC 3127 [RFC3127]. I was an active contributor in the
the IEEE 802.11i task group, and previously employed in the WLAN IEEE 802.11i task group, and previously employed in the WLAN
engineering group of my company. I have had no participation in any engineering group of my company. I have had no participation in any
of the submitted protocols. My company does have an OEM relationship of the submitted protocols. My company does have an OEM relationship
with at least one company whose employees have co-authored one of the with at least one company whose employees have coauthored one of the
submissions, but I have no direct involvement with our WLAN product submissions, but I have no direct involvement with our WLAN product
at this time. at this time.
Oleg Volinsky, Colubris Networks Oleg Volinsky, Colubris Networks
I am a member of the Enterprise group of Colubris Networks, a WLAN 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 vendor. I have over 10 years of experience in design and development
of network products from core routers to home networking equipment. of network products from core routers to home networking equipment.
Over years I have participated in various IETF groups. I have been a 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 member of CAPWAP WG for over a year. In my current position I have
been monitoring the developments of CAPWAP standards and potential been monitoring the developments of CAPWAP standards and potential
integration of the resulting protocol into the company's products. I integration of the resulting protocol into the company's products. I
have not participated in any of the candidate protocol drafts. 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 have not worked for any of the companies whose staff authored any of
the candidate protocols. the candidate protocols.
Behcet Sarikaya, University of Northern British Columbia Behcet Sarikaya, University of Northern British Columbia
I am currently Professor of Computer Science at UNBC. I have so far I am currently Professor of Computer Science at UNBC. I have so far
five years of experience in IETF as a member of mobile networking 5 years of experience in IETF as a member of mobile networking-
related working groups. I have made numerous I-D contributions and related working groups. I have made numerous I-D contributions and
am a coauthor of one RFC. I have submitted an evaluation draft (with am a coauthor of one RFC. I have submitted an evaluation draft (with
Andy Lee) that evaluated LWAPP, CTP and WiCoP. Also I submitted Andy Lee) that evaluated LWAPP, CTP, and WiCoP. Also I submitted
another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP and SLAPP as another draft (on CAPWAPHP) that used LWAPP, CTP, WiCoP, and SLAPP as
transport. I also have research interests on next generation access transport. I also have research interests on next-generation access
point/controller architectures. I have no involvement in any of the point/controller architectures. I have no involvement in any of the
candidate protocol drafts, have not contributed any of the drafts. I candidate protocol drafts, have not contributed any of the drafts. I
have not worked in any of the companies whose staff has produced any have not worked in any of the companies whose staff has produced any
of the candidate protocols. of the candidate protocols.
4. Protocol Proposals and Highlights 4. Protocol Proposals and Highlights
The following proposals were submitted as proposals to the CAPWAP The following proposals were submitted as proposals to the CAPWAP
working group. working group.
[LWAPP] "Light Weight Access Point Protocol", Work in progress. 4.1. LWAPP
LWAPP was the first CAPWAP protocol orginally submitted to Seamoby The "Light Weight Access Point Protocol" [LWAPP] was the first CAPWAP
Working Group. LWAPP proposes original solutions for authentication, protocol originally submitted to Seamoby Working Group. LWAPP
user data encapsulation as well as management and configuration proposes original solutions for authentication and user data
information elements. LWAPP originated as a "Split MAC" protocol but encapsulation as well as management and configuration information
recent changes have added local MAC support as well. LWAPP has elements. LWAPP originated as a "split MAC" protocol, but recent
received a security review from Charles Clancy of the University of changes have added local MAC support as well. LWAPP has received a
Maryland Information Systems Security Lab. 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 LWAPP is the most detailed CAPWAP proposal. It provides a thorough
specification of the discovery, security and system management specification of the discovery, security, and system management
methods. LWAPP focuses on the 802.11 WLAN specific monitoring and methods. LWAPP focuses on the 802.11 WLAN-specific monitoring and
configuration. A key feature of LWAPP is it's use of raw 802.11 configuration. A key feature of LWAPP is its use of raw 802.11
frames which are tunneled back to the AC for processing. In both frames that are tunneled back to the Access Controller (AC) for
Local and Split MAC mode, raw 802.11 frames are forwarded to the AC processing. In both local- and split-MAC modes, raw 802.11 frames
for management and control. In addition, in split-MAC mode, user are forwarded to the AC for management and control. In addition, in
data is tunneled in raw 802.11 form to the AC. Although in concept, split-MAC mode, user data is tunneled in raw 802.11 form to the AC.
LWAPP could be used for other wireless technologies, LWAPP defines While in concept, LWAPP could be used for other wireless
very few primitives that are independant of the 802.11 layer. technologies, LWAPP defines very few primitives that are independent
of the 802.11 layer.
[SLAPP]"Secure Light Access Point Protocol", Work in progress. 4.2. SLAPP
SLAPP distinguishes itself with the use of well known, established "Secure Light Access Point Protocol" [SLAPP] distinguishes itself
technologies such as GRE for user data tunneling between AC and WTP with the use of well-known, established technologies such as Generic
and the proposed standard DTLS for the control channel transport. 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.
Four modes of operation are supported, 2 local MAC modes and 2 split 4 modes of operation are supported, 2 local-MAC modes and 2 split-MAC
MAC modes. STA control may be performed by the AC using native modes. STA control may be performed by the AC using native 802.11
802.11 frames which are encapsulated in SLAPP control packets across frames that are encapsulated in SLAPP control packets across all
all modes. modes. (STA refers to a wireless station, typically a laptop.)
In SLAPP local MAC modes, user data frames may be bridged or tunneled 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, 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. 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 Encryption of user data may be performed at either the AC or the WTP
in split-MAC mode. in split-MAC mode.
[CTP]"CAPWAP Tunneling Protocol", Work in progress. 4.3. CTP
CTP distinguishes itself with its use of SNMP to define configuration "CAPWAP Tunneling Protocol" [CTP] distinguishes itself with its use
and management data which it then encapsulates in an encrypted of Simple Network Management Protocol (SNMP) to define configuration
control channel. CTP was originally designed as a local MAC protocol and management data that it then encapsulates in an encrypted control
but the new version has split MAC support as well. In addition, CTP channel. CTP was originally designed as a local-MAC protocol but the
is clearly designed from the beginning to be compatible with multiple new version has split-MAC support as well. In addition, CTP is
clearly designed from the beginning to be compatible with multiple
wireless technologies. wireless technologies.
CTP defines information elements for management and control between CTP defines information elements for management and control between
the AC and WTP. CTP control messages are specified for STA session the AC and WTP. CTP control messages are specified for STA session
state, configuration and statistics. state, configuration, and statistics.
In local MAC mode, CTP does not forward any native wireless frames to In local-MAC mode, CTP does not forward any native wireless frames to
the AC. CTP specifies control messages for STA session activity, the AC. CTP specifies control messages for STA session activity,
mobilitiy and RF resource management between the AC and WTP. CTP mobility, and radio frequency (RF) resource management between the AC
local MAC mode specifies that the integration function from the and WTP. CTP local-MAC mode specifies that the integration function
wireless network to 802.3 Ethernet is performed at the WTP for all from the wireless network to 802.3 Ethernet is performed at the WTP
user data. User data may either be bridged at the WTP or 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 encapsulated as 802.3 frames in CTP packets at the WTP and tunneled
to the AC. to the AC.
CTP's Split-MAC mode is defined as an extension to local-MAC mode. 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 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 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 bridged locally at the WTP, or they may be encapsulated in CTP
packets and tunneled in their native wireless form to the AC. packets and tunneled in their native wireless form to the AC.
CTP supplies STA control abstraction, methods for extending the CTP supplies STA control abstraction, methods for extending the
forwarding of multiple types of native wireless management frames and forwarding of multiple types of native wireless management frames,
many options for user data tunneling. Configuration management is an and many options for user data tunneling. Configuration management
extension of SNMP. This makes CTP one of the most flexible of the is an extension of SNMP. This makes CTP one of the most flexible of
proposed CAPWAP protocols. However, it does define new security and the proposed CAPWAP protocols. However, it does define new security
data tunneling mechanisms instead of leveraging existing standards. and data tunneling mechanisms instead of leveraging existing
standards.
[WICOP]"Wireless LAN Control Protocol", Work in progress. 4.4. WiCoP
The WiCoP protocol introduces new discovery, configuration and "Wireless LAN Control Protocol" [WICOP] introduces new discovery,
management of WLAN systems. The protocol defines a distinct configuration, and management of Wireless LAN (WLAN) systems. The
discovery mechanism that integrates WTP-AC capabilities negotiation. protocol defines a distinct discovery mechanism that integrates WTP-
AC capabilities negotiation.
WiCoP defines 802.11 QoS parameters. In addition, the protocol WiCoP defines 802.11 Quality of Service (QoS) parameters. In
proposes to use standard security and authentication methods such as addition, the protocol proposes to use standard security and
IPSec and EAP. The protocol needs to go into detail with regards to authentication methods such as IPsec and Extensible Authentication
explicit use of the above mentioned methods. To assure interoperable Protocol (EAP). The protocol needs to go into detail with regards to
protocol implementations, it is critical to provide user with explicit use of the above-mentioned methods. To ensure interoperable
protocol implementations, it is critical to provide users with
detailed unambiguous specification. detailed unambiguous specification.
5. Security Considerations 5. Security Considerations
Each of the candidate protocols has a Security Considerations Each of the candidate protocols has a Security Considerations
section, as well as security properties. The CAPWAP Objectives section, as well as security properties. The CAPWAP objectives
document contains security related requirements. The evaluation team document [OBJ] contains security-related requirements. The
has considered if and how the candidate candidate protocols implement evaluation team has considered if and how the candidate protocols
the security features required by the CAPWAP objectives. However, implement the security features required by the CAPWAP objectives.
this evaluation team is not a security team and has not performed a However, this evaluation team is not a security team and has not
thorough security evaluation or tests. Any protocol coming out of performed a thorough security evaluation or tests. Any protocol
the CAPWAP working group must undergo a IETF security review in order coming out of the CAPWAP working group must undergo an IETF security
to fully meet the objectives. review in order to fully meet the objectives.
6. Mandatory Objective Compliance Evaluation 6. Mandatory Objective Compliance Evaluation
6.1. Logical Groups 6.1. Logical Groups
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP provides a control message called "Add WLAN". This message is LWAPP provides a control message called "Add WLAN". This message is
used by AC to create a WLAN with a unique ID, i.e. its SSID. The used by the AC to create a WLAN with a unique ID, i.e., its Service
WTPs in this WLAN have their own BSSIDs. LWAPP meets this objective. Set Identifier (SSID). The WTPs in this WLAN have their own Basic
Service Set Identifiers (BSSIDs). LWAPP meets this objective.
SLAPP SLAPP
SLAPP explicitly supports 0-255 BSSID's. SLAPP explicitly supports 0-255 BSSIDs.
CTP CTP
CTP implements a NETWORK_ID attribute which allows a wireless CTP implements a NETWORK_ID attribute that allows a wireless-
technology independant way of creating logical groups. CTP meets technology-independent way of creating logical groups. CTP meets
this objective. this objective.
WiCoP WiCoP
WiCoP provides control tunnels to manage logical groups. There is WiCoP provides control tunnels to manage logical groups. There is
one control tunnel for each logical group. WiCoP meets this one control tunnel for each logical group. WiCoP meets this
objective. objective.
6.2. Traffic Separation 6.2. Traffic Separation
LWAPP:C, SLAPP:C, CTP:P, WiCoP:P LWAPP:C, SLAPP:C, CTP:P, WiCoP:P
If a protocol distinguishes a data message from a control message, If a protocol distinguishes a data message from a control message,
then it meets this objective. then it meets this objective.
LWAPP LWAPP
LWAPP separates control messages from data messages using "C-bit". LWAPP separates control messages from data messages using "C-bit".
"C-bit" is defined in the LWAPP transport header. When C bit is "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 equal to zero, the message is a data message. When C-bit is equal to
one, message is a control message. So, LWAPP meets this objective one, the message is a control message. So, LWAPP meets this
objective.
SLAPP SLAPP
The SLAPP protocol encapsulates control using DTLS and optionally, The SLAPP protocol encapsulates control using DTLS and optionally,
user data with GRE. Of particular note, SLAPP defines 4 user data with GRE. Of particular note, SLAPP defines 4
"architecture modes" which define how user data is handled in "architecture modes" that define how user data is handled in relation
relation to the AC. SLAPP is compliant with this objective. to the AC. SLAPP is compliant with this objective.
CTP CTP
CTP defines separate packet frame types for control and data. CTP defines separate packet frame types for control and data.
However, the evaluation team could not find a way to configure the However, the evaluation team could not find a way to configure the
tunneling of user data, so opted to rate CTP as only partially tunneling of user data, so it opted to rate CTP as only partially
compliant. It appears that CTP would rely on SNMP MIB OID's for this compliant. It appears that CTP would rely on SNMP MIB Object
function, but none were defined in the specification. Defining the Identifiers (OIDs) for this function, but none were defined in the
necessary OID's would make CTP fully compliant. specification. Defining the necessary OIDs would make CTP fully
compliant.
WiCoP WiCoP
WiCoP provides for separation between control and data channels. WiCoP provides for separation between control and data channels.
However, tunneling methods are not explicitly described. Because of However, tunneling methods are not explicitly described. Because of
this, WiCoP partially meets this objective. this, WiCoP partially meets this objective.
6.3. STA Transparency 6.3. STA Transparency
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
skipping to change at page 14, line 10 skipping to change at page 10, line 20
WiCoP WiCoP
WiCoP does not require a terminal to know WiCoP. So, WiCoP meets WiCoP does not require a terminal to know WiCoP. So, WiCoP meets
this objective. this objective.
6.4. Configuration Consistency 6.4. Configuration Consistency
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
Given the objective of maintaining configurations for a large number Given the objective of maintaining configurations for a large number
of network elements involved in 802.11 wireless networks the of network elements involved in 802.11 wireless networks, the
evaluation team would like to recommend that a token, key or serial evaluation team would like to recommend that a token, key, or serial
number for configuration be implemented for configuration number for configuration be implemented for configuration
verification. verification.
LWAPP LWAPP
It is possible to obtain and verify all configurable values through It is possible to obtain and verify all configurable values through
LWAPP. Notably, LWAPP takes an approach that only "non-default" LWAPP. Notably, LWAPP takes an approach that only "non-default"
settings (defaults are specified by LWAPP) are necessary for settings (defaults are specified by LWAPP) are necessary for
transmission when performing configuration consistency checks. This transmission when performing configuration consistency checks. This
behavior is explicitly specified in LWAPP. LWAPP is compliant with behavior is explicitly specified in LWAPP. LWAPP is compliant with
this objective. this objective.
SLAPP SLAPP
Numerous event and statistics are available to report config changes Numerous events and statistics are available to report configuration
and WTP state. SLAPP does not have any built in abilities to changes and WTP state. SLAPP does not have any built-in abilities to
minimize or optimize configuration consistency verification, but it minimize or optimize configuration consistency verification, but it
is compliant with the objective. is compliant with the objective.
CTP CTP
CTP's use of SNMP makes configuration consistency checking CTP's use of SNMP makes configuration consistency checking
straightfoward. Where specified in an a MIB, one could take straightforward. Where specified in a MIB, one could take advantage
advantage of default values. of default values.
WICOP WICOP
The WiCoP configuration starts with exchange of capability messages The WiCoP configuration starts with exchange of capability messages
between WTP and AC. Next, configuration control data is sent to WTP. between the WTP and AC. Next, configuration control data is sent to
the WTP.
WiCoP defines configuration values in groups of configuration data WiCoP defines configuration values in groups of configuration data
messages. In addition, the protocol supports configuration using MIB messages. In addition, the protocol supports configuration using MIB
objects. To maintain data consistency each configuration message objects. To maintain data consistency, each configuration message
from AC is acknowledged by WTP. from the AC is acknowledged by the WTP.
6.5. Firmware Trigger 6.5. Firmware Trigger
LWAPP:P, SLAPP:P, CTP:P, WiCoP:C LWAPP:P, SLAPP:P, CTP:P, WiCoP:C
The evaluation team considered the objective and determined that for The evaluation team considered the objective and determined that for
full compliance, the protocol state machine must support the ability full compliance, the protocol state machine must support the ability
to initiate the process for checking and performing a firmware update to initiate the process for checking and performing a firmware update
independantly of other functions. independently of other functions.
Many protocols perform a firmware check and update procedure only on Many protocols perform a firmware check and update procedure only on
system startup time. This method received a partial compliance. The system startup time. This method received a partial compliance. The
team believed that performing the firmware check only at startup time team believed that performing the firmware check only at startup time
was unnecessarily limiting and that allowing it to occur at any time was unnecessarily limiting and that allowing it to occur at any time
in the state machine did not increase complexity of the protocol. in the state machine did not increase complexity of the protocol.
Allowing the firmware update process to be initiated occur during the Allowing the firmware update process to be initiated during the
running state allows more possibilities for minimizing downtime of running state allows more possibilities for minimizing downtime of
the WTP during the firmware update process. the WTP during the firmware update process.
For example, the firmware check and download of the image over the For example, the firmware check and download of the image over the
network could potentially occur while the WTP was in a running state. network could potentially occur while the WTP was in a running state.
After the file transfer was complete, the WTP could be rebooted just After the file transfer was complete, the WTP could be rebooted just
once and being running the new firmware image. This could pose a once and begin running the new firmware image. This could pose a
meaningful reduction in downtime when the firmware image is large, 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 the link for loading the file is very slow, or the WTP reboot time is
long. long.
A protocol would only fail compliance if it no method was specified A protocol would only fail compliance if no method was specified for
for updating of firmware. updating of firmware.
LWAPP LWAPP
Firmware download is initiated by the WTP only at the Join phase 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 (when a WTP is first associating with an AC) and not at any other
time. The firmware check and update could be "triggered" indirectly time. The firmware check and update could be "triggered" indirectly
by the AC by sending a reset message to the WTP. The resulting by the AC by sending a reset message to the WTP. The resulting
reboot would cause a firmware check and update to be performed. reboot would cause a firmware check and update to be performed.
LWAPP is partially compliant because its firmware trigger can only be LWAPP is partially compliant because its firmware trigger can only be
used in the startup phases of the state machine. used in the startup phases of the state machine.
SLAPP SLAPP
SLAP{ includes a firmware check and update procedure which is SLAP includes a firmware check and update procedure that is performed
performed when a WTP is first connecting to an AC. The firmware when a WTP is first connecting to an AC. The firmware check and
check and update can only be "triggered" indirectly by the AC by update can only be "triggered" indirectly by the AC by sending a
sending a reset message to the WTP. SLAPP is partially compliant reset message to the WTP. SLAPP is partially compliant because its
because its firmware trigger can only be used in the startup phases firmware trigger can only be used in the startup phases of the state
of the state machine. machine.
CTP CTP
The CTP state machine specifies that the firmware upgrade procedure The CTP state machine specifies that the firmware upgrade procedure
must be performed immediately after the authentication exchange as must be performed immediately after the authentication exchange as
defined in section 6.2 of [CTP]. However, section 5.2.5 of [CTP] 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 states that the SW-Update-Req message MAY be sent by the AC. This
indirectly implies that CTP could support an AC triggered software indirectly implies that CTP could support an AC-triggered software
update during the regular running state of the WTP. So it seems that update during the regular running state of the WTP. So it seems that
CTP might be fully compliant, but the proposal should be clarified CTP might be fully compliant, but the proposal should be clarified
for full compliance. for full compliance.
WiCoP WiCoP
In WiCoP, firmware update may be triggered any time in the active In WiCoP, firmware update may be triggered any time in the active
state, so WiCoP is fully compliant. state, so WiCoP is fully compliant.
6.6. Monitor and Exchange of System-wide Resource State 6.6. Monitor and Exchange of System-wide Resource State
LWAPP:C, SLAPP:C, CTP:P, WiCoP:C LWAPP:C, SLAPP:C, CTP:P, WiCoP:C
The evaluation team focused on the protocols supplying three methods The evaluation team focused on the protocols supplying 3 methods
relevant to statistics from WTP's; The ability to transport relevant to statistics from WTPs: The ability to transport
statistics, a minimum set of standard data and the ability to extend statistics, a minimum set of standard data, and the ability to extend
what data could be reported or collected. what data could be reported or collected.
LWAPP LWAPP
Statistics are sent by WTP using "Event Request" message. LWAPP Statistics are sent by the WTP using an "Event Request" message.
defines an 802.11 statistics message which covers 802.11 MAC layer LWAPP defines an 802.11 statistics message that covers 802.11 MAC
properties. LWAPP is compliant layer properties. LWAPP is compliant.
SLAPP SLAPP
WLAN statisitics transport is supplied via the control channel and WLAN statistics transport is supplied via the control channel and
encoded in SLAPP defined TLV's called information elements. 802.11 encoded in SLAPP-defined TLVs called information elements. 802.11
configuration and statistics information elements are supplied in configuration and statistics information elements are supplied in
[SLAPP] 6.1.3.1. These are extendable and include vendor specific [SLAPP] 6.1.3.1. These are extendable and include vendor-specific
extensions. extensions.
CTP CTP
CTP defines a control message called "CTP Stats-Notify". This CTP defines a control message called "CTP Stats-Notify". This
control message contains statistics in the form of SNMP OID's and is control message contains statistics in the form of SNMP OIDs and is
sent from the WTP to AC. This approach is novel because it leverages sent from the WTP to AC. This approach is novel because it leverages
the use of standard SNMP. the use of standard SNMP.
[CTP] 5.3.10 reccommends the use of 802.11 MIBs where applicable. Section 5.3.10 of [CTP] recommends the use of 802.11 MIBs where
However, the proposal acknowledges that additional configuration and applicable. However, the proposal acknowledges that additional
statistics information is required, but does not specify these MIB configuration and statistics information is required, but does not
extensions. CTP needs to add these extensions to the proposal. specify these MIB extensions. CTP needs to add these extensions to
Also, this minimum set of statistics and configuration OID's must the proposal. Also, this minimum set of statistics and configuration
become requirements in order to fully meet the objective. OIDs must become requirements in order to fully meet the objective.
WiCoP WiCoP
The feedback control message sent by WTP contains many statistics.
WiCoP specifies fifteen statistics WTP needs to send to AC. New The feedback control message sent by the WTP contains many
versions of WiCoP can address any new statistics AC needs to monitor statistics. WiCoP specifies 15 statistics that the WTP needs to send
WTP. WiCoP meets this objective. to the AC. New versions of WiCoP can address any new statistics that
the AC needs to monitor the WTP. WiCoP meets this objective.
6.7. Resource Control 6.7. Resource Control
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
The evaluation team interpreted the resource control objective to The evaluation team interpreted the resource control objective to
mean that the CAPWAP protocol must map 802.11e QoS markings to the mean that the CAPWAP protocol must map 802.11e QoS markings to the
wired network. This mapping must include any encapsulation or wired network. This mapping must include any encapsulation or
tunneling of user data defined by the CAPWAP protocol. Of particular tunneling of user data defined by the CAPWAP protocol. Of particular
note, the evaluation team agreed that the CAPWAP protocol should note, the evaluation team agreed that the CAPWAP protocol should
supply an explicit capability to configure this mapping. Since most supply an explicit capability to configure this mapping. Since most
of the protocols relied only on the 802.11e statically defined of the protocols relied only on the 802.11e statically defined
mapping, most received a partial compliance. mapping, most received a partial compliance.
LWAPP LWAPP
LWAPP defines it's own custom TLV structure which consists of an 8 LWAPP defines its own custom TLV structure, which consists of an
bit type or class of information value and an additional 8 bit value 8-bit type or class of information value and an additional 8-bit
which indexes to a specific variable value that indexes to a specific variable.
LWAPP allows the mobile station based QoS configuration in each Add LWAPP allows the mobile station-based QoS configuration in each Add
Mobile Request sent by AC to WTP for each new mobile station that is Mobile Request sent by AC to WTP for each new mobile station that is
attached. Packet prioritization is left to individual WTPs. 4 attached. Packet prioritization is left to individual WTPs. 4
different QoS policies for each station to enforce can be configured. different QoS policies for each station to enforce can be configured.
Update Mobile QoS message element can be used to change QoS policy at Update Mobile QoS message element can be used to change QoS policy at
the WTP for a given mobile station. LWAPP should support 8 QoS the WTP for a given mobile station. LWAPP should support 8 QoS
policies as this matches 802.11e 802.1p and IP TOS, but for this policies as this matches 802.11e 802.1p and IP TOS, but for this
objective, 4 classes is compliant. objective, 4 classes is compliant.
Overall, LWAPP conforms to the resource control objective. It Overall, LWAPP conforms to the resource control objective. It
enables QoS configuration and mapping. The control can be applied on enables QoS configuration and mapping. The control can be applied on
a logical group basis and also enables the wireless traffic to be a logical group basis and also enables the wireless traffic to be
flexibly mapped to the wired segment. flexibly mapped to the wired segment.
SLAPP SLAPP
Although 802.11e specifies 802.1p and DSCP mappings, there is no Although 802.11e specifies 802.1p and Differentiated Service Code
explicit support for 802.11e in SLAPP. SLAPP must be updated to add Point (DSCP) mappings, there is no explicit support for 802.11e in
802.11e as one of the standard capabilities that a WTP could support SLAPP. SLAPP must be updated to add 802.11e as one of the standard
and specify a mechanism which would allow configuration of mapping capabilities that a WTP could support and specify a mechanism that
the QoS classes. would allow configuration of mapping the QoS classes.
CTP CTP
CTP requires that the WTP and AC copy the QoS marking of user data to CTP requires that the WTP and AC copy the QoS marking of user data to
the data message encapsulation. This mapping is accomplished by the the data message encapsulation. This mapping is accomplished by the
CTP Header's 1 byte policy field. However, no configuration of QoS CTP Header's 1-byte policy field. However, no configuration of QoS
mapping other than copying the user data's already existing markings mapping other than copying the user data's already existing markings
is defined in CTP. It seems clear that SNMP could be used to is defined in CTP. It seems clear that SNMP could be used to
configure the mapping to occur differently, but no OID's are defined configure the mapping to occur differently, but no OIDs are defined
which would enable this. Partial compliance is assigned to CTP for that would enable this. Partial compliance is assigned to CTP for
this objective. this objective.
WiCoP WiCoP
Note: WiCoP rating for Resource Control objective has been upgraded Note: WiCoP rating for resource control objectives has been upgraded
from FAILED to PARTIAL. After an additional review of the WiCoP from Failed to Partial. After an additional review of the WiCoP
protocol proposal, it was determined that the protocol partially protocol proposal, it was determined that the protocol partially
meats Resource control objectives. meets resource control objectives.
WiCoP protocol starts its QoS configuration with 802.11e capability WiCoP protocol starts its QoS configuration with 802.11e capability
exchange between WTP and AC. The QoS capabilities primitives are exchange between the WTP and AC. The QoS capabilities primitives are
included in the capability messages. included in the capability messages.
WiCoP defines the QoS-Value message which contains 802.11e WiCoP defines the QoS-Value message that contains 802.11e
configuration parameters. This is sent for each group supported by configuration parameters. This is sent for each group supported by
WTP. WiCoP does not provide an explicit method for configuration of the WTP. WiCoP does not provide an explicit method for configuration
DSCP tags and 802.1P precedence values. It is possible to configure of DSCP tags and 802.1P precedence values. It is possible to
these parameters through SNMP OID configuration method, but WiCoP configure these parameters through SNMP OID configuration method, but
does not explicitly identify any specific MIBs. Overall, WiCoP WiCoP does not explicitly identify any specific MIBs. Overall, WiCoP
partially meets resource control CAPWAP objects. In order to be partially meets resource control CAPWAP objectives. In order to be
fully compliant with the given objective, the protocol needs to fully compliant with the given objective, the protocol needs to
identify a clear method to configure 802.1p and DSCP mappings. identify a clear method to configure 802.1p and DSCP mappings.
6.8. Protocol Security 6.8. Protocol Security
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
For the purposes of the protocol security objective, the evaluation For the purposes of the protocol security objective, the evaluation
team primarily considered whether or not the candidate protocols team primarily considered whether or not the candidate protocols
implement the security features required by the CAPWAP objectives. implement the security features required by the CAPWAP objectives.
Please refer to the security considerations section of this document. Please refer to the Security Considerations section of this document.
LWAPP LWAPP
It appears that the security mechanisms, including the key management It appears that the security mechanisms, including the key management
portions in LWAPP are correct. One third party security review has portions in LWAPP, are correct. One third-party security review has
been performed. However, further security review is warranted since been performed. However, further security review is warranted since
a CAPWAP specific key exchange mechanism is defined. LWAPP is a CAPWAP-specific key exchange mechanism is defined. LWAPP is
compliant with the objective compliant with the objective.
SLAPP SLAPP
The SLAPP protocol implements authentication of the WTP by the AC The SLAPP protocol implements authentication of the WTP by the AC
using the DTLS protocol. This behavior is defined in both the using the DTLS protocol. This behavior is defined in both the
discovery process and the 802.11 control process. SLAPP allows discovery process and the 802.11 control process. SLAPP allows
mutual and asymmetric authentication. SLAPP also gives informative mutual and asymmetric authentication. SLAPP also gives informative
examples of how to properly use the authentication. SLAPP should add examples of how to properly use the authentication. SLAPP should add
another informative example for authentication of the AC by the WTP. another informative example for authentication of the AC by the WTP.
SLAPP is compliant with the objective. SLAPP is compliant with the objective.
CTP CTP
skipping to change at page 19, line 27 skipping to change at page 15, line 47
CTP. This was due to a misunderstanding of what was meant by CTP. This was due to a misunderstanding of what was meant by
asymmetric authentication by the evaluation team. The definitions of asymmetric authentication by the evaluation team. The definitions of
the terminology used in [OBJ] were clarified on the CAPWAP mailing the terminology used in [OBJ] were clarified on the CAPWAP mailing
list. CTP in fact does implement a form of asymmetric authentication list. CTP in fact does implement a form of asymmetric authentication
through the use of public keys. through the use of public keys.
However, CTP still fails to comply with the objective for two However, CTP still fails to comply with the objective for two
reasons: reasons:
First, CTP does not mutually derive session keys. Second, CTP does First, CTP does not mutually derive session keys. Second, CTP does
not perform explicit mutual authentication because the two parties not perform explicit mutual authentication because the 2 parties
authenticating do not confirm the keys. authenticating do not confirm the keys.
WiCoP WiCoP
There is not enough specific information to implement WiCOP protocol There is not enough specific information to implement WiCoP protocol
security features. While in concept EAP and IPSec make sense, there security features. Although in concept EAP and IPsec make sense,
is no explicit description on how these methods would be used. there is no explicit description on how these methods would be used.
6.9. System-Wide Security 6.9. System-Wide Security
LWAPP:C, SLAPP:C, CTP:F, WiCoP:F LWAPP:C, SLAPP:C, CTP:F, WiCoP:F
LWAPP LWAPP
LWAPP wraps all control and management communication in it's LWAPP wraps all control and management communication in its
authenticated and encrypted control channel. LWAPP does not seem authenticated and encrypted control channel. LWAPP does not seem
particularly vulnerable to DoS. LWAPP should make a recommendation particularly vulnerable to Denial of Service (DoS). LWAPP should
that the join method be throttled to reduce the impact of DOS attacks make a recommendation that the Join method be throttled to reduce the
against it. Use of an established security mechanism such as IPSec impact of DoS attacks against it. Use of an established security
would be preferred. However, LWAPP's independant security review mechanism such as IPsec would be preferred. However, LWAPP's
lended enough confidence to declare LWAPP compliant with the independent security review lent enough confidence to declare LWAPP
objective. compliant with the objective.
SLAPP SLAPP
SLAPP is compliant due to wrapping all control and management SLAPP is compliant due to wrapping all control and management
communication in DTLS. SLAPP also recommends measures to protect communication in DTLS. SLAPP also recommends measures to protect
against discovery request DOS attacks. DTLS has undergone security against discovery request DoS attacks. DTLS has undergone security
review and has at least one known implementation outside of SLAPP. review and has at least one known implementation outside of SLAPP.
At the time of this writing, DTLS is pending proposed standard status At the time of this writing, DTLS is pending proposed standard status
in the IETF. in the IETF.
CTP CTP
CTP introduces a new, unestablished mechanism for AC to WTP CTP introduces a new, unestablished mechanism for AC-to-WTP
authentication. For complete compliance, use of an established authentication. For complete compliance, use of an established
security mechanism with detailed specifications for it's use in CTP security mechanism with detailed specifications for its use in CTP is
is preferred. Alternatively a detailed security review could be preferred. Alternatively, a detailed security review could be
performed. CTP does not point out or recommend or specify any DoS performed. CTP does not point out or recommend or specify any DoS
attack mitigation requirements against Reg-Req and Auth-Req floods, attack mitigation requirements against Reg-Req and Auth-Req floods,
such as a rate limiter. Because CTP received an 'F' on it's protocol such as a rate limiter. Because CTP received an 'F' on its protocol
security objective, it follows that system-wide security must also be security objective, it follows that system-wide security must also be
rated 'F'. rated 'F'.
WiCoP WiCoP
WiCop does not address DoS attack threats. Also, as with the WiCop does not address DoS attack threats. Also, as with the
protocol security objective, the protocol needs to explicitly protocol security objective, the protocol needs to explicitly
describe its tunnel and authentication methods. describe its tunnel and authentication methods.
6.10. 802.11i Considerations 6.10. 802.11i Considerations
LWAPP:C, SLAPP:C, CTP:F, WiCoP:P LWAPP:C, SLAPP:C, CTP:F, WiCoP:P
LWAPP LWAPP
LWAPP explicitly defines mechanisms for handling 802.11i in it's LWAPP explicitly defines mechanisms for handling 802.11i in its modes
modes with encryption terminated at the WTP. In order to accomplish with encryption terminated at the WTP. In order to accomplish this,
this, the AC sends the PTK using the encrypted control channel to the the AC sends the Pairwise Transient Key (PTK) using the encrypted
WTP using the Add Mobile message. When encryption is terminated at control channel to the WTP using the Add Mobile message. When
the AC, there are no special requirements. LWAPP is compliant. encryption is terminated at the AC, there are no special
requirements. LWAPP is compliant.
SLAPP SLAPP
SLAPP defines a control message to send the PTK and GTK to the WTP SLAPP defines a control message to send the PTK and Group Temporal
when the WTP is the encryption endpoint. This control message is Key (GTK) to the WTP when the WTP is the encryption endpoint. This
carried on the DTLS protected control channel. SLAPP is compliant. control message is carried on the DTLS protected control channel.
SLAPP is compliant.
CTP CTP
CTP lacks a specification for a control message to send 802.11i PTK CTP lacks a specification for a control message to send 802.11i PTK
and GTK keys to a WTP when the WTP is an encryption endpoint. Based and GTK keys to a WTP when the WTP is an encryption endpoint. Based
on this, CTP fails compliance for this objective. This requirement on this, CTP fails compliance for this objective. This requirement
could be addressed either by defining new control channel information could be addressed either by defining new control channel information
elements or by simply defining SNMP OID's. The transport of these elements or by simply defining SNMP OIDs. The transport of these
OID's would be contained in the secure control channel and therefore OIDs would be contained in the secure control channel and therefore
protected. protected.
WiCoP WiCoP
WiCoP lacks documentation in the draft on how to handle 4 way WiCoP lacks documentation on how to handle 4-way handshake. The case
handshake. The case for encryption at the AC needs clarification. for encryption at the AC needs clarification.
6.11. Interoperability 6.11. Interoperability
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP supports both split and local mac architectures and is LWAPP supports both split- and local-MAC architectures and is
therefore compliant to the letter of the objectives. LWAPP is therefore compliant to the letter of the objectives. LWAPP is
particularly rich in its support of the split-mac architecture. particularly rich in its support of the split-MAC architecture.
However, LWAPP's support of Local-MAC is somewhat limited and could However, LWAPP's support of local-MAC is somewhat limited and could
be expanded. LWAPP is lacking a mode which allows Local MAC data be expanded. LWAPP is lacking a mode that allows local-MAC data
frames to be tunneled back to the AC. A discussion of possible frames to be tunneled back to the AC. A discussion of possible
extensions and issues is discussed in the recommendations section of extensions and issues is discussed in the recommendations section of
this evaluation. this evaluation.
SLAPP SLAPP
SLAPP is compliant. SLAPP is compliant.
CTP CTP
skipping to change at page 21, line 49 skipping to change at page 18, line 28
WiCoP is compliant. WiCoP is compliant.
6.12. Protocol Specifications 6.12. Protocol Specifications
LWAPP:C, SLAPP:P, CTP:P, WiCoP:P LWAPP:C, SLAPP:P, CTP:P, WiCoP:P
LWAPP LWAPP
LWAPP is nearly fully documented. Only a few sections are noted as LWAPP is nearly fully documented. Only a few sections are noted as
incomplete. Detailed descriptions are often given to explain the incomplete. Detailed descriptions are often given to explain the
purpose of the protocol primitives defined which should encourage purpose of the protocol primitives defined that should encourage
interoperable implementations. interoperable implementations.
SLAPP SLAPP
SLAPP is largely implementable from it's specification. It contains SLAPP is largely implementable from its specification. It contains
enough information to perform an interoperable implementation for enough information to perform an interoperable implementation for its
it's basic elements, however additional informative references or basic elements; however, additional informative references or
examples should be provided covering use of information elements, examples should be provided covering use of information elements,
configuring multiple logical groups, etc. configuring multiple logical groups, and so on.
CTP CTP
As noted earlier, there are a few areas where CTP lacks a complete As noted earlier, there are a few areas where CTP lacks a complete
specification, primarily due to the lack of specific MIB definitions. specification, primarily due to the lack of specific MIB definitions.
WiCoP WiCoP
Due to the lack of specific tunnel specifications and authentication Due to the lack of specific tunnel specifications and authentication
specifications, WiCoP is only partially compliant. specifications, WiCoP is only partially compliant.
skipping to change at page 23, line 22 skipping to change at page 20, line 13
WiCoP is compliant. WiCoP is compliant.
6.15. NAT Traversal 6.15. NAT Traversal
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP may require special considerations due to it carrying the IP LWAPP may require special considerations due to it carrying the IP
address of the AC and data termination points in the payload of address of the AC and data termination points in the payload of
encrypted control messages. To overcome NAT, static NAT mappings may encrypted control messages. To overcome Network Address Translation
need to be created at the NAT'ing device if the AC or data (NAT), static NAT mappings may need to be created at the NAT'ing
termination points addresses are translated from the point of view of device if the AC or data termination points addresses are translated
the WTP. A WTP should be able function in the hidden address space from the point of view of the WTP. A WTP should be able to function
of a NAT'd network. in the hidden address space of a NAT'd network.
SLAPP SLAPP
SLAPP places no out of the ordinary constraints regarding NAT. A WTP SLAPP places no out-of-the-ordinary constraints regarding NAT. A WTP
could function in the hidden address space of a NAT'd network without could function in the hidden address space of a NAT'd network without
any special configuration. any special configuration.
CTP CTP
CTP places no out of the ordinary constraints regarding NAT. A WTP CTP places no out-of-the-ordinary constraints regarding NAT. A WTP
could function in the hidden address space of a NAT'd network without could function in the hidden address space of a NAT'd network without
any special configuration. any special configuration.
WiCoP WiCoP
WiCoP places no out of the ordinary constraints regarding NAT. A WTP WiCoP places no out-of-the-ordinary constraints regarding NAT. A WTP
could function in the hidden address space of a NAT'd network without could function in the hidden address space of a NAT'd network without
any special configuration. any special configuration.
7. Desirable Objective Compliance Evaluation 7. Desirable Objective Compliance Evaluation
7.1. Multiple Authentication 7.1. Multiple Authentication
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP allows for multiple STA authentication mechanisms. LWAPP allows for multiple STA authentication mechanisms.
SLAPP SLAPP
SLAPP does not constrain other authentication techniques for being SLAPP does not constrain other authentication techniques from being
deployed. deployed.
CTP CTP
CTP supports multiple STA authentication mechanisms. CTP supports multiple STA authentication mechanisms.
WiCoP WiCoP
WiCoP allows for multiple STA authentication mechanisms. WiCoP allows for multiple STA authentication mechanisms.
7.2. Future Wireless Technologies 7.2. Future Wireless Technologies
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP could be used for other wireless technologies. However, LWAPP LWAPP could be used for other wireless technologies. However, LWAPP
defines very few primitives that are independant of the 802.11 layer. defines very few primitives that are independent of the 802.11 layer.
SLAPP SLAPP
SLAPP could be used for other wireless technologies. However, SLAPP SLAPP could be used for other wireless technologies. However, SLAPP
defines very few primitives that are independant of the 802.11 layer. defines very few primitives that are independent of the 802.11 layer.
CTP CTP
CTP supplies STA control abstraction, methods for extending the CTP supplies STA control abstraction, methods for extending the
forwarding of multiple types of native wireless management frames and forwarding of multiple types of native wireless management frames,
many options for user data tunneling. Configuration management is an and many options for user data tunneling. Configuration management
extension of SNMP, for which new MIB's could in concept, be easily is an extension of SNMP, to which new MIBs could, in concept, be
plugged in. This helps makes CTP a particularly flexible proposal easily plugged in. This helps makes CTP a particularly flexible
for supporting future wireless technologies. In addition, CTP has proposal for supporting future wireless technologies. In addition,
already defined multiple wireless protocol types in addition to CTP has already defined multiple wireless protocol types in addition
802.11. to 802.11.
WiCoP WiCoP
WiCoP could be used for other wireless technologies. WiCoP could be used for other wireless technologies.
7.3. New IEEE Requirements 7.3. New IEEE Requirements
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP's extensive use of native 802.11 frame forwarding allows it to LWAPP's extensive use of native 802.11 frame forwarding allows it to
be transparent to many 802.11 changes. It however shifts the burden be transparent to many 802.11 changes. It, however, shifts the
of adapting MAC layer changes to the packet processing capabilities burden of adapting MAC layer changes to the packet processing
of the AC. capabilities of the AC.
SLAPP SLAPP
SLAPP's use of native 802.11 frames for control and management allow SLAPP's use of native 802.11 frames for control and management allows
SLAPP a measure of transparency to changes in 802.11. Because SLAPP SLAPP a measure of transparency to changes in 802.11. Because SLAPP
also supports a mode which tunnels user data as 802.3 frames, it has also supports a mode that tunnels user data as 802.3 frames, it has
additonal architectural options for adapting to changes on the additional architectural options for adapting to changes on the
wireless infrastructure. wireless infrastructure.
CTP CTP
CTP has perhaps the greatest ability to adapt to changes in IEEE CTP has perhaps the greatest ability to adapt to changes in IEEE
requirements. Architecturally speaking, CTP has several options requirements. Architecturally speaking, CTP has several options
available for adapting to change. SNMP OID's are easily extended for available for adapting to change. SNMP OIDs are easily extended for
additional control and management functions. Native wireless frames additional control and management functions. Native wireless frames
can be forwarded directly to the AC if necessary. Wireless frames can be forwarded directly to the AC if necessary. Wireless frames
can be bridged to 802.3 frames and tunneled back to the AC to protect can be bridged to 802.3 frames and tunneled back to the AC to protect
the AC from changes at the wireless MAC layer. These options allow the AC from changes at the wireless MAC layer. These options allow
many possible ways to adapt to change of the wireless MAC layer. many possible ways to adapt to change of the wireless MAC layer.
WiCoP WiCoP
Because WiCoP uses 802.11 frames for the data transport, it is Because WiCoP uses 802.11 frames for the data transport, it is
transparent to most IEEE changes. Any new IEEE requirements may need transparent to most IEEE changes. Any new IEEE requirements may need
new configuration and new capability messages between WTP and AC. new configuration and new capability messages between the WTP and AC.
The AC would need to be modified to handle new 802.11 control and The AC would need to be modified to handle new 802.11 control and
management frames. management frames.
7.4. Interconnection (IPv6) 7.4. Interconnection (IPv6)
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP explicitly defines measures for accomodating IPv6. LWAPP is
LWAPP explicitly defines measures for accommodating IPv6. LWAPP is
more sensitive to this in part because it carries IP addresses in two more sensitive to this in part because it carries IP addresses in two
control messages. control messages.
SLAPP SLAPP
SLAPP is transparent to the interconnection layer. DTLS and GRE will SLAPP is transparent to the interconnection layer. DTLS and GRE will
both operate over IPv6. both operate over IPv6.
CTP CTP
skipping to change at page 26, line 30 skipping to change at page 23, line 17
WiCoP is transparent to the interconnection layer and should be able WiCoP is transparent to the interconnection layer and should be able
to operate over IPv6 without changes. to operate over IPv6 without changes.
7.5. Access Control 7.5. Access Control
LWAPP:C, SLAPP:C, CTP:C, WiCoP:C LWAPP:C, SLAPP:C, CTP:C, WiCoP:C
LWAPP LWAPP
LWAPP uses native 802.11 management frames forwarded to the AC for LWAPP uses native 802.11 management frames forwarded to the AC for
the purpose of performing STA access control. WTP's are the purpose of performing STA access control. WTPs are authenticated
authenticated in LWAPP's control protocol Join phase. in LWAPP's control protocol Join phase.
SLAPP SLAPP
SLAPP has support for multiple authentication methods for WTP's. In SLAPP has support for multiple authentication methods for WTPs. In
addition, SLAPP can control STA access via 802.11 management frames addition, SLAPP can control STA access via 802.11 management frames
forwarded to the AC or via SLAPP's information element primitives. forwarded to the AC or via SLAPP's information element primitives.
CTP CTP
CTP specifies STA access control primitives. CTP specifies STA access control primitives.
WiCoP WiCoP
WiCoP specifies access control in [WICOP] section 5.2.2. WiCoP specifies access control in [WICOP] section 5.2.2.
8. Evaluation Summary and Conclusions 8. Evaluation Summary and Conclusions
See Figure 1. See Figure 1 (section numbers correspond to RFC 4564 [OBJ]).
--------------------------------------------------------------- ---------------------------------------------------------------
| CAPWAP Evaluation | LWAPP | SLAPP | CTP | WiCoP | | CAPWAP Evaluation | LWAPP | SLAPP | CTP | WiCoP |
---------------------------------------------------------------| |---------------------------------------------------------------|
| 5.1.1 Logical Groups | C | C | C | C | | 5.1.1 Logical Groups | C | C | C | C |
| 5.1.2 Traffic Separation | C | C | P | P | | 5.1.2 Traffic Separation | C | C | P | P |
| 5.1.3 STA Transparency | C | C | C | C | | 5.1.3 STA Transparency | C | C | C | C |
| 5.1.4 Config Consistency | C | C | C | C | | 5.1.4 Config Consistency | C | C | C | C |
| 5.1.5 Firmware Trigger | P | P | P | C | | 5.1.5 Firmware Trigger | P | P | P | C |
| 5.1.6 Monitor System | C | C | P | C | | 5.1.6 Monitor System | C | C | P | C |
| 5.1.7 Resource Control | C | P | P | P | | 5.1.7 Resource Control | C | P | P | P |
| 5.1.8 Protocol Security | C | C | F | F | | 5.1.8 Protocol Security | C | C | F | F |
| 5.1.9 System Security | C | C | F | F | | 5.1.9 System Security | C | C | F | F |
| 5.1.10 802.11i Consideration | C | C | F | P | | 5.1.10 802.11i Consideration | C | C | F | P |
skipping to change at page 28, line 7 skipping to change at page 24, line 42
| 5.2.2 Future Wireless | C | C | C | C | | 5.2.2 Future Wireless | C | C | C | C |
| 5.2.3 New IEEE Requirements | C | C | C | C | | 5.2.3 New IEEE Requirements | C | C | C | C |
| 5.2.4 Interconnection (IPv6) | C | C | C | C | | 5.2.4 Interconnection (IPv6) | C | C | C | C |
| 5.2.5 Access Control | C | C | C | C | | 5.2.5 Access Control | C | C | C | C |
--------------------------------------------------------------- ---------------------------------------------------------------
Figure 1: Summary Results Figure 1: Summary Results
9. Protocol Recommendation 9. Protocol Recommendation
The proposals presented offer a variety of novel features which The proposals presented offer a variety of novel features that
together would deliver a full featured, flexible and extensible together would deliver a full-featured, flexible, and extensible
CAPWAP protocol. The most novel of these features leverage existing CAPWAP protocol. The most novel of these features leverage existing
standards where feasable. It is this evaluation team's opinion that standards where feasible. It is this evaluation team's opinion that
a mix of the capabilities of the proposals will produce the best a mix of the capabilities of the proposals will produce the best
CAPWAP protocol. CAPWAP protocol.
The recommended features are described below. Many of these novel The recommended features are described below. Many of these novel
capabilities come from CTP and SLAPP and WiCoP. However, LWAPP has capabilities come from CTP and SLAPP and WiCoP. However, LWAPP has
the most complete base protocol and is flexible enough to be extended the most complete base protocol and is flexible enough to be extended
or modified by the working group. We therefore recommend LWAPP be or modified by the working group. We therefore recommend that LWAPP
used as the basis for the CAPWAP protocol. be used as the basis for the CAPWAP protocol.
The evaluation team recommends that the working group carefully The evaluation team recommends that the working group carefully
consider the following issues and recommended changes. The consider the following issues and recommended changes. The
evaluation team believes that a more complete CAPWAP protocol will be evaluation team believes that a more complete CAPWAP protocol will be
delivered by addressing these issues and changes. delivered by addressing these issues and changes.
9.1. High priority recommendations relevant to mandatory objectives 9.1. High-Priority Recommendations Relevant to Mandatory Objectives
9.1.1. Information Elements 9.1.1. Information Elements
LWAPP's attribute value pair system meets the objectives as defined LWAPP's attribute value pair system meets the objectives as defined
by the working group. However, it has only 8 bits assigned for by the working group. However, it has only 8 bits assigned for
attribute types, with an additional 8 bits for a specific element attribute types, with an additional 8 bits for a specific element
within a attribute type. The evaluation team strongly recommends within an attribute type. The evaluation team strongly recommends
that a larger number of bits be assigned for attribute types and that a larger number of bits be assigned for attribute types and
information elements. information elements.
9.1.2. Control Channel Security 9.1.2. Control Channel Security
LWAPP's security mechanisms appear satisfactory and could serve LWAPP's security mechanisms appear satisfactory and could serve
CAPWAP going forward. However, the evaluation team recommends CAPWAP going forward. However, the evaluation team recommends
adoption of a standard security protocol for the control channel. adoption of a standard security protocol for the control channel.
There are several motivations for a standards based security There are several motivations for a standards-based security
protocol, but the primary disadvantage of a new security protocol is protocol, but the primary disadvantage of a new security protocol is
that it will take longer and be more difficult to standardize than that it will take longer and be more difficult to standardize than
reusing an existing IETF standard. First, a new security protocol reusing an existing IETF standard. First, a new security protocol
will face a longer, slower approval processes from the Security Area will face a longer, slower approval processes from the Security Area
Directorate and the IESG. The new CAPWAP security protocol will need Directorate and the IESG. The new CAPWAP security protocol will need
to pass several tests including: to pass several tests including the following:
What is uniquely required by CAPWAP that is not available from an What is uniquely required by CAPWAP that is not available from an
existing standard protocol? How will CAPWAP's security protocol meet existing standard protocol? How will CAPWAP's security protocol meet
security area requirements for extensibility, such as the ability to security area requirements for extensibility, such as the ability to
support future cipher suites and new key exchange methods? How does support future cipher suites and new key exchange methods? How does
this ability compare to established security protocols which have this ability compare to established security protocols that have
these capabilities? these capabilities?
Points such as these are continually receiving more attention in the Points such as these are continually receiving more attention in the
industry and in the IETF. Extensibility of key exchange methods and industry and in the IETF. Extensibility of key exchange methods and
ciper suites are becoming industry standard best practices. These cipher suites are becoming industry standard best practices. These
issues are important topics in the IETF Security Area Advisory Group issues are important topics in the IETF Security Area Advisory Group
(SAAG) and the recent SecMech BOF. (SAAG) and the SecMech BOF, held during the 63rd IETF meeting.
These issues could be nullified by adopting an appropriate existing These issues could be nullified by adopting an appropriate existing
standard security protocol. IPsec or DTLS could be a standards standard security protocol. IPsec or DTLS could be a standards
alternative to LWAPP's specification. DTLS presents a UDP variant of alternative to LWAPP's specification. DTLS presents a UDP variant of
TLS. Although DTLS is relatively new, TLS is a heavily used, tried Transport Layer Security (TLS). Although DTLS is relatively new, TLS
and tested security protocol. is a heavily used, tried-and-tested security protocol.
The evaluation team recommends that whatever security protocol is The evaluation team recommends that whatever security protocol is
specified for CAPWAP, that it's use cases must be described in specified for CAPWAP, its use cases must be described in detail.
detail. LWAPP does a good job of this with it's proposed, LWAPP does a good job of this with its proposed, proprietary method.
proprietary method. If an updated specification is developed, it If an updated specification is developed, it should contain at least
should contain at least one mandatory authentication and cipher one mandatory authentication and cipher method. For example, pre-
method. For example, pre-shared key and x.509 certificates could be shared key and x.509 certificates could be specified as mandatory
specified as mandatory authentication methods and AES CCMP could be authentication methods, and Advanced Encryption Standard (AES)
selected as a mandatory cipher. Counter Mode with CBC-MAC Protocol (CCMP) could be selected as a
mandatory cipher.
Given the possibilities for code reuse, industry reliance on TLS and Given the possibilities for code reuse, industry reliance on TLS, and
the future for TLS, DTLS may be a wise alternative to a security the future for TLS, DTLS may be a wise alternative to a security
method specific to CAPWAP. In addition, use of DTLS would likely method specific to CAPWAP. In addition, use of DTLS would likely
expidite the approval of CAPWAP as a proposed standard over the use expedite the approval of CAPWAP as a proposed standard over the use
of CAPWAP specific security mechanisms. of CAPWAP-specific security mechanisms.
9.1.3. Data Tunneling Modes 9.1.3. Data Tunneling Modes
9.1.3.1. Support for Local MAC User Data Tunneling 9.1.3.1. Support for Local MAC User Data Tunneling
The issue of data encapsulation is closely related to the Split and The issue of data encapsulation is closely related to the split- and
Local MAC architectures. The Split MAC architecture requires some local-MAC architectures. The split-MAC architecture requires some
form of data tunneling. All the proposals except LWAPP offer a form of data tunneling. All the proposals except LWAPP offer a
method of tunneling in Local MAC mode as well. By Local MAC data method of tunneling in local-MAC mode as well. By local-MAC data
tunneling, we mean the tunneling of user data as 802.3 Ethernet tunneling, we mean the tunneling of user data as 802.3 Ethernet
frames back to the AC from a WTP which is otherwise in Local MAC frames back to the AC from a WTP that is otherwise in local-MAC mode.
mode.
Tunneling data in Local MAC mode offers the ability for implementors Tunneling data in local-MAC mode offers the ability for implementers
to innovate in several ways even while using a Local MAC to innovate in several ways even while using a local-MAC
architecture. For example, functions such as mobility, flexible user architecture. For example, functions such as mobility, flexible user
data encryption options, fast handoffs can be enabled through data encryption options, and fast handoffs can be enabled through
tunneling of user data back to an AC, or as LWAPP defines, a data tunneling of user data back to an AC, or as LWAPP defines, a data
termination endpoint, which could be different than the AC. In termination endpoint, which could be different from the AC. In
addition, special QoS or application aware treatments of user data addition, there are special QoS or application-aware treatments of
packets such as voice or video. Improved transparency and user data packets such as voice or video. Improved transparency and
compatibility with future wireless technologies are also possible compatibility with future wireless technologies are also possible
when encapsulating user data in a common format, such as 802.3, when encapsulating user data in a common format, such as 802.3,
between the access point and the AC or other termination point in the between the access point and the AC or other termination point in the
network. network.
Another possibility is when a native wireless MAC changes in the Another possibility is when a native wireless MAC changes in the
future, if a new WTP which supports this MAC change can also support future, if a new WTP that supports this MAC change can also support a
a wireless MAC -> 802.3 integration function, then the wireless MAC wireless MAC -> 802.3 integration function, then the wireless MAC
layer change may remain transparent to an AC and still maintain many layer change may remain transparent to an AC and still maintain many
of the benefits that data tunneling can bring. of the benefits that data tunneling can bring.
LWAPP does support a header for tunneled user data which contains LWAPP does support a header for tunneled user data that contains
layer 1 wireless information (RSSI and SNR) that is independant of layer 1 wireless information (Received Signal Strength Indication
the wireless layer 2 MAC. Innovations related to the use of RSSI and (RSSI) and Signal-to-Noise Ratio (SNR)) that is independent of the
SNR at the AC may be retained even when tunneling 802.3 user data wireless layer 2 MAC. Innovations related to the use of RSSI and SNR
across different wireless MAC's. at the AC may be retained even when tunneling 802.3 user data across
different wireless MACs.
It is likely many other features could be created by innovative It is likely that many other features could be created by innovative
implementors using this method. However, LWAPP narrowly defines the implementers using this method. However, LWAPP narrowly defines the
Local MAC architecture to exclude an option of tunneling data frames local-MAC architecture to exclude an option of tunneling data frames
back to the AC. Given the broad support for tunneling 802.3 data back to the AC. Given the broad support for tunneling 802.3 data
frames between WTP and AC across all the proposals and existing frames between the WTP and AC across all the proposals and existing
proprietary industry implementations, the evaluation team strongly proprietary industry implementations, the evaluation team strongly
recommends the working group consider a data tunneling mode for Local recommends that the working group consider a data tunneling mode for
MAC be added to the LWAPP proposal and become part of the standard local-MAC be added to the LWAPP proposal and become part of the
CAPWAP protocol. standard CAPWAP protocol.
9.1.3.2. Mandatory and Optional Tunneling Modes 9.1.3.2. Mandatory and Optional Tunneling Modes
If more than one tunneling mode is part of the CAPWAP protocol the If more than one tunneling mode is part of the CAPWAP protocol, the
evaluation team recommends that the working group choose one method evaluation team recommends that the working group choose one method
as mandatory and other methods as optional. In addition, the CAPWAP as mandatory and other methods as optional. In addition, the CAPWAP
protocol must implement the ability to negotiate which tunneling protocol must implement the ability to negotiate which tunneling
methods are supported through a capabilities exchange. This allows methods are supported through a capabilities exchange. This allows
AC's and WTP's freedom to implement a variety of modes but always ACs and WTPs freedom to implement a variety of modes but always have
have the option of falling back to a common mode. the option of falling back to a common mode.
The choice of which mode(s) should be mandatory is an important The choice of which mode(s) should be mandatory is an important
decision and may impact many decisions an implementor has to make decision and may impact many decisions implementers have to make with
with their hardware and software choices for both WTP's and AC's. their hardware and software choices for both WTPs and ACs. The
The evaluation team believes the working group should address this evaluation team believes that the working group should address this
issue of Local MAC data tunneling and carefully choose which mode(s) issue of local-MAC data tunneling and carefully choose which mode(s)
should be mandatory. should be mandatory.
9.2. Additional Recommendations Relevant to Desirable Objectives 9.2. Additional Recommendations Relevant to Desirable Objectives
9.2.1. Access Control 9.2.1. Access Control
Abstraction of STA access control, such as that implemented in CTP Abstraction of STA access control, such as that implemented in CTP
and WiCoP, stands out as a valuable feature as it is fundamental to and WiCoP, stands out as a valuable feature as it is fundamental to
the operational capabilities of many types of wireless networks, not the operational capabilities of many types of wireless networks, not
just 802.11. LWAPP implements station access control as a 802.11 just 802.11. LWAPP implements station access control as an 802.11-
specific function via forwarding of 802.11 control frames to the specific function via forwarding of 802.11 control frames to the
access controller. LWAPP has abstracted the STA Delete function out access controller. LWAPP has abstracted the STA Delete function out
of the 802.11 binding. However, the Add STA function is part of the of the 802.11 binding. However, the Add STA function is part of the
802.11 binding. It would be useful to implement the wireless MAC 802.11 binding. It would be useful to implement the wireless MAC
independant functions for adding a STA outside of the 802.11 binding. independent functions for adding a STA outside of the 802.11 binding.
9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling
LWAPP currently specifies layer 2 and layer 3 methods for data LWAPP currently specifies layer 2 and layer 3 methods for data
tunneling. The evaluation team believes the layer 2 method is tunneling. The evaluation team believes that the layer 2 method is
redundant to the layer 3 method. The team recommends the layer 2 redundant to the layer 3 method. The team recommends that the layer
method encapsulation be removed from the LWAPP protocol. 2 method encapsulation be removed from the LWAPP protocol.
9.2.3. Data Encapsulation Standard 9.2.3. Data Encapsulation Standard
LWAPP's layer 3 data encapsulation meet's the working group LWAPP's layer 3 data encapsulation meets the working group
objectives. However, The evaluation team recommends the use of a objectives. However, the evaluation team recommends the use of a
standards based protocol for encapsulation of user data between the standards-based protocol for encapsulation of user data between the
WTP and AC. GRE or L2TP could make good candidates as standards WTP and AC. GRE or Layer 2 Tunneling Protocol (L2TP) could make good
based encapsulation protocols for data tunneling. candidates as standards-based encapsulation protocols for data
tunneling.
Using a standard gives the opprotunity for code reuse, whether it is Using a standard gives the opportunity for code reuse, whether it is
off-the-shelf microcode for processors, code modules that can be off-the-shelf microcode for processors, code modules that can be
purchased for real time operating systems, or open-source purchased for real-time operating systems, or open-source
implementations for Unix based systems. In addition, L2TP and GRE implementations for Unix-based systems. In addition, L2TP and GRE
are designed to encapsulate multiple data types, increasing are designed to encapsulate multiple data types, increasing
flexibility for supporting future wireless technologies. flexibility for supporting future wireless technologies.
10. References 10. Normative References
[802.11i] IEEE Standard 802.11i, "Medium Access Control (MAC)
Security Enhancements", July 2004.
[ARCH] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy [ARCH] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access for Control and Provisioning of Wireless Access Points
Points(CAPWAP)", November 2004. (CAPWAP)", RFC 4118, June 2005.
[OBJ] Govindan, S., Ed., Cheng, H., Yao, ZH., Zhou, WH., and L.
Yang, "Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
11. Informative References
[CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes , [CTP] Singh , I., Francisco, P., Pakulski , K., and F. Backes ,
"CAPWAP Tunneling Protocol (CTP)", April 2005. "CAPWAP Tunneling Protocol (CTP)", Work in Progress, April
2005.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[LWAPP] Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams, [LWAPP] Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams,
M., Hares, S., and N. Cam Winget, "Light Weight Access M., Hares, S., and N. Cam Winget, "Light Weight Access
Point Protocol (LWAPP)", March 2005. Point Protocol (LWAPP)", Work in Progress, March 2005.
[OBJ] Govindan, S., Yao, ZH., Zhou, WH., Yang, L., and H. Cheng,
"Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", June 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, [RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil,
B., Stevens, M., and B. Wolff, "Authentication, B., Stevens, M., and B. Wolff, "Authentication,
Authorization, and Accounting: Protocol Evaluation", Authorization, and Accounting: Protocol Evaluation", RFC
RFC 3127, June 2001. 3127, June 2001.
[SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP : [SLAPP] Narasimhan, P., Harkins, D., and S. Ponnuswamy, "SLAPP :
Secure Light Access Point Protocol", May 2005. Secure Light Access Point Protocol", Work in Progress, May
2005.
[WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng, [WICOP] Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
"Wireless LAN Control Protocol (WiCoP)", March 2005. "Wireless LAN Control Protocol (WiCoP)", Work in Progress,
March 2005.
Authors' Addresses Authors' Addresses
Darren P. Loher Darren P. Loher
Roving Planet, Inc. Envysion, Inc.
7237 Church Ranch Blvd. 2010 S. 8th Street
Westminster, CO 80021 Boulder, CO 80302
USA USA
Phone: +1.303.996.7560 Phone: +1.303.667.8761
Email: dloher@rovingplanet.com EMail: dplore@gmail.com
David B. Nelson David B. Nelson
Enterasys Networks, Inc. Enterasys Networks, Inc.
50 Minuteman Road 50 Minuteman Road
Anover, MA 01810-1008 Anover, MA 01810-1008
USA USA
Phone: +1.978.684.1330 Phone: +1.978.684.1330
Email: dnelson@enterasys.com EMail: dnelson@enterasys.com
Oleg Volinsky Oleg Volinsky
Colubris Networks, Inc. Colubris Networks, Inc.
200 West Street 200 West Street
Waltham, MA 02451 Waltham, MA 02451
USA USA
Phone: +1.781.547.0329 Phone: +1.781.547.0329
Email: ovolinsky@colubris.com EMail: ovolinsky@colubris.com
Behcet Sarikaya Behcet Sarikaya
UNBC Huawei USA
Computer Science Dept. 1700 Alma Dr. Suite 100
3333 University Way Plano, TX 75075
Prince George, BC V2N 4Z9 USA
Canada
Phone: +1.250.960.5551 Phone: +1.972.509.5599
Email: sarikaya@ieee.org EMail: sarikaya@ieee.org
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 34, line 29 skipping to change at page 31, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 171 change blocks. 
442 lines changed or deleted 464 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/