Network Working Group B. Sarikaya
Internet-Draft A. Lee
Expires: October 24, 2005 UNBC
April 22, 2005
Evaluation of Possible CAPWAP Protocols
draft-sarikaya-capwap-evaluate-00.txt
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
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This documents evaluates the protocols submitted to CAPWAP WG in
April 2005. The objectives document is used as the evaluation
criteria. All of the objectives are considered one by one and three
protocols (LWAPP, CTP and WiCoP) are evaluated vis-a-vis these
criteria. The results indicate conformance to most of the criteria
by all three protocols.
Sarikaya & Lee Expires October 24, 2005 [Page 1]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Submitted Protocols . . . . . . . . . . . . . . . . . . . . 5
3.1 Light Weight Access Point Protocol (LWAPP) . . . . . . . . 5
3.2 CAPWAP Tunneling Protocol (CTP) . . . . . . . . . . . . . 5
3.3 SLAPP : Secure Light Access Point Protocol . . . . . . . . 5
3.4 Wireless LAN Control Protocol (WiCoP) . . . . . . . . . . 5
4. Objectives and Evaluation . . . . . . . . . . . . . . . . . 6
4.1 Logical Groups . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Support for Traffic Separation . . . . . . . . . . . . . . 6
4.3 Wireless Terminal Transparency . . . . . . . . . . . . . . 7
4.4 Configuration Consistency . . . . . . . . . . . . . . . . 7
4.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . . . 8
4.6 Monitoring and Exchange of System-wide Resource State . . 9
4.7 Resource Control Objective . . . . . . . . . . . . . . . . 10
4.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . . . 10
4.9 System-wide Security . . . . . . . . . . . . . . . . . . . 11
4.10 IEEE 802.11i Considerations . . . . . . . . . . . . . . 11
4.11 Interoperability Objective . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . 13
6. Summary and Conclusions . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 16
Sarikaya & Lee Expires October 24, 2005 [Page 2]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
1. Definitions
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. [RFC2119]
1.2 Terminology
This document follows the terminologies of draft-ietf-capwap-arch
[draft-ietf-capwap-arch-06] and draft-ietf-capwap-objectives.
[draft-ietf-capwap-objectives-02]
Sarikaya & Lee Expires October 24, 2005 [Page 3]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
2. Introduction
There are many wireless solution offer by vendors. Solutions varies
from vendor to vendor. Since solutions varies from one another, wlan
management varies from solution to solution. This causes problems
when a wlan consists of many devices from different vendors.
To solve these problems, IETF created a group called CAPWAP group.
This group is responsible for defining a set of objectives a protocol
needs to meet to address these problems. CAPWAP groups also evaluate
submitted protocols to see if any protocol meets the objectives.
This documentation evaluates protocols submitted to the CAPWAP group.
Sarikaya & Lee Expires October 24, 2005 [Page 4]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
3. Submitted Protocols
Currently, there are four different protocols submitted to the CAPWAP
group. Each protocols tries to address the objectives differently.
3.1 Light Weight Access Point Protocol (LWAPP)
LWAPP is a protocol created by Airespace, NTT DoCoMo and Legra
System. LWAPP offers a centralized management system needed and is
developed specifically for 802.11. LWAPP is already deployed.
3.2 CAPWAP Tunneling Protocol (CTP)
Chantry Networks and Propagate submitted a solution to CAPWAP called
CTP. CTP can be used for many different radio technologies.
3.3 SLAPP : Secure Light Access Point Protocol
SLAPP, a protocol submitted by Aruba, offers a very different
protocol from others. To solve the WLAN management problem, Aruba
suggests to split the solution into two parts. The first part deals
with vendor specific issues. Second part is a solution to WTP and AC
authentication. The second part uses the first part to communicate
with vendor specific devices.
We decided not to evaluate SLAPP. The reason is that this protocol
does not offer any solution to MU management. It also does not
provide resource management. What SLAPP provides is WTP and AC
authentication.
3.4 Wireless LAN Control Protocol (WiCoP)
WiCoP is a protocol submitted by Panasonic. Like other protocols, it
offers a centralized management system. Unlike other protocols, it
offers logical group management using control tunnels.
Sarikaya & Lee Expires October 24, 2005 [Page 5]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
4. Objectives and Evaluation
CAPWAP group came up with with eleven mandatory objectives. In order
for CAPWAP to accept a protocol, many if not all objectives need to
be met.
In what follows, before evaluation of the protocols, in each section
we stated on how the protocols are being evaluated. Evaluation of
desirable objectives are not done in this document.
4.1 Logical Groups
For a protocol to meet this objective, a protocol need to provide a
way for a AC to manage MU in logical groups. A possible solutions is
to give AC control of MU session. This lets AC to create, modify and
delete a MU session. This allows AC to modify MU session based on
the logical group MU is in. This solution might not meet the
requirement of Logical Groups objective. Another solution is for the
protocol to provide a logical group management as part of the
protocol.
LWAPP
LWAPP provides a control message called "Mobile Config Request."
This message is used by AC to create, modify and delete MU session
with a WTP. Unless Logical Group needs to be built into the
protocol, LWAPP meets this objective.
CTP
CTP allows AC to connect and disconnect a MU. Unless logical groups
need to be built into the protocol, CTP meets this objective.
WiCoP
WiCoP provides control tunnels to manage logical groups. There is
one control tunnel for each a logical group. So, WiCoP meets this
objective.
4.2 Support for Traffic Separation
If a protocol distinguishes a data message from a control message,
then it meets this objective.
LWAPP
LWAPP separates control messages from data messages using "C-bit".
"C-bit" is defined in the LWAPP transport header. When C bit is
Sarikaya & Lee Expires October 24, 2005 [Page 6]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
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
CTP
In CTP message header, there is a field called "TYPE". If type is
equal to fifteen, then the message is a data message. Otherwise, it
should be a control message. So, CTP meets this objective.
Wireless LAN Control Protocol (WiCoP)
WiCoP uses 'C' Field in WiCoP header to distinguish between a control
message and a data message. 'C' field is one bit. Data message is
represent by zero and control message is represent by one. So, WiCoP
meets this objective.
4.3 Wireless Terminal Transparency
If a protocol does not indicate that MU needs to know about the
protocol, then this objective is met.
The protocol should not define any message formats between MU and
WTP/AC.
LWAPP
LWAPP does not require a terminal to know LWAPP. So, LWAPP meets
this objective.
CTP
CTP does not require a terminal to know CTP. So, CTP meets this
objective
WiCoP
WiCoP does not require a terminal to know WiCoP. So, WiCoP meets
this objective
4.4 Configuration Consistency
The protocol documentations does not state how WTP sends "state" info
mention in the objective. The objective as for "state" such as
processing load and memory utilization. If a protocol documentation
does mention state, it is about the "state" WTP is in. WTP could be
in "Active", "Idle" or "Reset" state. For the purpose of evaluating
protocols on this objective, statistics are used instead of states.
Sarikaya & Lee Expires October 24, 2005 [Page 7]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
Another requirement for this objective is to provide a way for AC to
configure WTP.
One of the requirements that should be part of this objective is WTP
should send out a capability message to AC. If AC knows WTP's
capability, it could configure WTP more effectively.
Light Weight Access Point Protocol (LWAPP)
After connection is established between WTP and AC, WTP sends out
configuration request message. This message states the capabilites
of WTP. WTP sends event request message to AC. These event request
messages can contain statistical infomation and can be sent
periodically. AC can send out configuration update request messages
to WTP. These messages are used to configure WTP. These messages
provide AC the infomation needed to configure WTPs consistently. So,
LWAPP meets this objective.
CAPWAP Tunneling Protocol (CTP)
CTP supports multiple control messages when configuring WTPs. CTP
has a control message that WTP sends to AC. This control message
states the capabilities of the WTP. Also, a WTP can send a control
message requesting configuration from AC. Lastly, CTP provides a
control message with which WTP can periodically send statistics to
AC. With these messages, AC can calculate and determine the best
possible configuration for all the WTPs. So, CTP meets this
objective.
Wireless LAN Control Protocol (WiCoP)
WiCoP has capability control message, configuration control message
and feedback control message. Feedback control message contains the
statistics of WTP. These three messages are sent by WTP to AC.
These messages allows AC to determine the configuration setup for
WTP. So, WiCoP meets this objective.
4.5 Firmware Trigger
If the protocol provides a way for WTP to realize that its firmware
is "out of date" or provides a way for AC to ask WTP to update its
firmware, then the protocol meets this objective.
Light Weight Access Point Protocol (LWAPP)
There is a control message called "Image Data Request". After
connection between WTP and AC is establish, WTP might notice the
firmware it uses is not the same as the firmware AC said to use. So,
Sarikaya & Lee Expires October 24, 2005 [Page 8]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
WTP sends this message to AC to update the firmware. So, LWAPP meets
this objective.
CAPWAP Tunneling Protocol (CTP)
WTP can send a "SW-Update-Req" message to ask AC if it should update
its software. AC can also send this message requesting that WTP to
stop operating and update its software. So, CTP meets this
objective.
Wireless LAN Control Protocol (WiCoP)
When WTP send a "Capability" control message, a firmware version is
included. This allows AC to determine if a firmware update is
needed. If a firmware update is needed, AC could send a "Firmware
Download" message to WTP to inform WTP to update its firmware. So,
WiCoP meets this objective.
4.6 Monitoring and Exchange of System-wide Resource State
In order for this objective to be met, a protocol needs to provide a
way for WTP to send statistics to AC.
Light Weight Access Point Protocol (LWAPP)
Statistics are sent by WTP using "Event Request" message. LWAPP does
not specify the statistics WTP needs to send. Statistics sent by WTP
is specific to the architecture WTP is designed. For example, WTP
can send 802.11 statistics message. This message contains a total of
thirty-eight different statistics. This allows the usage of WTP with
old 802.11 architecture. For the purposes of this evaluation, LWAPP
meets this objective.
CAPWAP Tunneling Protocol (CTP)
CTP has a control message called "CTP Stats-Notify". This control
message contains statistics and is sent by the WTP to AC. This
control message uses SNMP to send statistics. CTP recommends the use
of MIB to send statistics. If more information is required, an
extension to MIB can done. So, CTP meets this objective.
Wireless LAN Control Protocol (WiCoP)
The feedback control message sent by WTP contains many statistics.
WiCoP specifies fifteen statistics WTP needs to send to AC. New
versions of WiCoP can address any new statistics AC needs to monitor
WTP. For now, WiCoP meets this objective.
Sarikaya & Lee Expires October 24, 2005 [Page 9]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
4.7 Resource Control Objective
Resource control objective has been set forward to ensure system-wide
enforcement of the quality-of-service (QoS), in both the switching
segment and the wireless medium segment. In the latter, the
objective looks for 802.11e support for communication between WLAN
subscribers and WTP as well as appropriate control exchanges between
WTP and AC. In the switching segment, the objective is to provide
statistical QoS guarantees on the traffic between WTP and AC.
LWAPP
LWAPP allows the mobile station based QoS configuration in each Add
Mobile Requests sent by AC to WTP for each new mobile station that is
attached. Packet prioritization is left to individual WTPs. 4
different QoS policies for each station to enforce can be configured.
Update Mobile QoS message element can be used to change QoS policy at
the WTP for a given mobile station.
For the switching segment, LWAPP offers the support for DSCP tags and
802.1P precedence values to be configured.
Overall, LWAPP conforms to the resource control objective, it enables
QoS control based on the logical groups it also enables the traffic
to be QoS enabled using DiffServ in the switching segment.
CTP
CTP uses DiffServ markings as the only QoS support so in this respect
it has some support of the swicthing segment QoS control support.
CTP lacks any support for 802.11e in the wireless medium segment.
Due the the dependence of CTP on SNMP, this aspect may have been left
to configuring 802.11e protocol using 802.11e MIB.
WiCoP
WiCoP provides capabilities configuration by the AC for each WTP in
Cap to WTP message elements. 802.11e capabilities are part of these
message elements and allow setting of QoS capabilities for each
logical group. QoS value message elements are also provided for each
logical group which allow setting of QoS classes such as best effort,
video, voice traffic class, etc. for each terminal and this facility
is also the support for the switching segment for the traffic between
WTP and AC.
4.8 CAPWAP Protocol Security
LWAPP
Sarikaya & Lee Expires October 24, 2005 [Page 10]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
After authentication, all control messages between AC and WTP are
encrypted. So LWAPP meets this objective.
CTP
CTP provides mutual authentication between WTP and AC. WTP starts
the process by sending "Reg-Req" message to AC. AC then sends "Reg-
Rsp" message. In this message, AC will indicate if WTP can
authenticate. WTP will look at this message and decide whether or
not to authenticate with AC. If WTP decides to authenticate with AC,
then WTP sends "Auth-Req" message and AC replies with "Auth-Rsp"
message. After authentication, all control messages between AC and
WTP are encrypted.
CTP does not provide non-mutual authentication.
If non-mutual authentication is not a requirement, then CTP meets
this objective.
WiCoP
WiCoP has mutual authentication between WTP and AC. WTP sends
"Connection" message to AC. AC then responds with "Connection
Response" message. WiCoP does not specify security mechanism used
during authentication.
WiCoP header contains a bit called 'E' field. This bit is used to
indicate if the message is encrypted or not. WiCoP does not specify
when a message is encrypted, but it is safe to say that after a
successful authentication, all messages are encrypted.
WiCoP does not provide non-mutual authentication.
If non-mutual authentication is not a requirement then WiCoP meets
this objective.
4.9 System-wide Security
To satisfy this objective, a protocol must demonstrate that a rogue
MU cannot enter WLAN.
The protocols are not evaluated on this objective. The reason for
this is that there is not a definitive way to prevent PMK.
4.10 IEEE 802.11i Considerations
LWAPP
Sarikaya & Lee Expires October 24, 2005 [Page 11]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
LWAPP leaves 802.11i frame encryption under the responsibility of
WTP. But 802.11i Authentication and Key Exchange are handled by AC.
CTP
WiCoP
WiCoP provides support for 802.11i. Authentication requires a four-
way handshake. So, WiCoP meets this objective.
4.11 Interoperability Objective
To satisfy this objective, a protocol needs to provide a mechanism
for WTP to inform its capabilities to AC. The objective did not
indicate if the message needs to indicate if it is local-MAC or
split-MAC. For now, this is not a requirement a protocol needs to
satisfy. But, evaluation will note if a message indicates this.
LWAPP
WTP uses "Join Request" message to inform its capabilities to AC.
This message is sent when WTP decides to join a specific AC based on
AC's capabilities. This message includes WTP information and WTP
capabilities. So LWAPP meets this objective.
CTP
WTP can send out a "CTP Cap-Req" message. Using this message, WTP
can specify if it is local-MAC or split-MAC. WTP can also specify
the wireless technology it uses. CTP header does not have a field to
indicate if the exchange of message is between WTP and AC is split-
MAC or local-MAC. So CTP meets this objective.
WiCoP
WiCoP header contains a field called 'M' field. This field is used
to distinguishes between local-MAC WTPs and split-MAC WTPs. Zero
represent split-MAC and one represent local-MAC. When WTP is powered
on, it sends out a "Capability" message. This message contains WTP
infomation and WTP capabilities. Also, WiCoP uses separate control
tunnels for local-MAC and split-MAC when managing WTPs. So WiCoP
meets this objective.
Sarikaya & Lee Expires October 24, 2005 [Page 12]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
5. Security Considerations
None.
Sarikaya & Lee Expires October 24, 2005 [Page 13]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
6. Summary and Conclusions
We have included into our evaluation three protocols out of four
submitted to CAPWAP WG. The evaluation was based on the objectives
document. We stated the results of our evaluation item by item with
a justification for each.
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[draft-ietf-capwap-arch-06]
Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access
Points(CAPWAP)", November 2004.
[draft-ietf-capwap-objectives-02]
Govindan, S., Yao, ZH., Zhou, WH., Yang, L., and H. Cheng,
"Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", March 2005.
[draft-iino-capwap-wicop-00]
Iino, S., Govindan, S., Sugiura, M., and H. Cheng,
"Wireless LAN Control Protocol (WiCoP)", March 2005.
[draft-ohara-capwap-lwapp-02]
Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams,
M., Hares, S., and N. Cam Winget, "Light Weight Access
Point Protocol (LWAPP)", March 2005.
[draft-singh-capwap-ctp-01]
Singh , I., Francisco, P., Pakulski , K., and F. Backes ,
"CAPWAP Tunneling Protocol (CTP)", April 2005.
Authors' Addresses
Behcet Sarikaya
UNBC
3333 University Way
Prince George, BC V2N 4Z9
Canada
Phone: 1 250-960-5551
Email: sarikaya@unbc.ca
Sarikaya & Lee Expires October 24, 2005 [Page 14]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
Andy Lee
UNBC
Phone: 1 604 874 1526
Email: leea@unbc.ca
Sarikaya & Lee Expires October 24, 2005 [Page 15]
Internet-Draft Eval. of Possible CAPWAP Protocols April 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sarikaya & Lee Expires October 24, 2005 [Page 16]