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]