Network Working Group S. Govindan Internet-Draft S. Iino Expires: October 2005 H. Cheng M. Sugiura Panasonic May 2005 Evaluation of Wireless LAN Control Protocol (WiCoP) draft-govindan-capwap-wicop-evaluation-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 2005 . Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Wireless LAN Control Protocol (WiCoP) enables control of WLANs made of different types of wireless termination points. It addresses an immediate concern for WLAN deployments. This draft presents an evaluation of WiCoP with respect to the CAPWAP Objectives. It also highlights WiCoP's advantges over other CAPWAP candidate protocols. Govindan, et al. Expires October 2005 [Page 1] Internet-Draft WiCoP Evaluation May 2005 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 4. WiCoP Evaluation . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Mandatory and Accepted Objectives . . . . . . . . . . . . 6 4.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 6 4.1.2 Support for Traffic Separation . . . . . . . . . . . . 6 4.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 7 4.1.4 Configuration Consistency . . . . . . . . . . . . . . 7 4.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 8 4.1.6 Monitoring and Exchange of System-wide Resource State . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.7 Resource Control Objective . . . . . . . . . . . . . . 8 4.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 9 4.1.9 System-wide Security . . . . . . . . . . . . . . . . . 9 4.1.10 IEEE 802.11i Considerations . . . . . . . . . . . . 9 4.1.11 Interoperability Objective . . . . . . . . . . . . . 10 4.1.12 Protocol Specifications . . . . . . . . . . . . . . 11 4.1.13 Vendor Independence . . . . . . . . . . . . . . . . 11 4.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 11 4.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 12 4.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 12 4.2.2 Support for Future Wireless Technologies . . . . . . . 12 4.2.3 Support for New IEEE Requirements . . . . . . . . . . 12 4.2.4 Interconnection Objective . . . . . . . . . . . . . . 13 4.2.5 Access Control . . . . . . . . . . . . . . . . . . . . 13 4.3 Non-objectives . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 13 4.3.2 Technical Specifications . . . . . . . . . . . . . . . 14 4.4 Operator Requirements . . . . . . . . . . . . . . . . . . 14 4.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 14 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . 19 Govindan, et al. Expires October 2005 [Page 2] Internet-Draft WiCoP Evaluation May 2005 1. Requirements notation 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 [RFC2119]. Govindan, et al. Expires October 2005 [Page 3] Internet-Draft WiCoP Evaluation May 2005 2. Terminology This draft follows the terminologies of [I-D.ietf-capwap-arch] and [I-D.ietf-capwap-objectives]. Govindan, et al. Expires October 2005 [Page 4] Internet-Draft WiCoP Evaluation May 2005 3. Introduction The Wireless LAN Control Protocol (WiCoP) [I-D.iino-capwap-wicop] addresses the most important issue for current WLANs - the ability to control and manage systems made up of different types of WTPs. WiCoP provides this ability and enables administrators to manage WLANs with a mix of local-MAC and split-MAC WTPs. This document evaluates WiCoP with respect to the CAPWAP Objectives [I-D.ietf-capwap-objectives] and indicates how the protocol realizes those requirements. Govindan, et al. Expires October 2005 [Page 5] Internet-Draft WiCoP Evaluation May 2005 4. WiCoP Evaluation The CAPWAP Objectives are being devised by the CAPWAP WG as the core set of requirements needed to control and provision large-scale WLANs. The following sections describe how WiCoP realizes all those requirements. 4.1 Mandatory and Accepted Objectives The Mandatory and Accepted Objectives represent those requirements that have been deemed of highest importance. WiCoP realizes all these requirements and in doing so, delivers an effective solution for managing large-scale WLANs. 4.1.1 Logical Groups The CAPWAP protocol MUST be capable of controlling and managing physical WTPs in terms of logical groups including BSSID-based groups. 4.1.1.1 Protocol Evaluation WiCoP establishes logical groups using BSSIDs for the wireless medium segment and VLANs for the switching segment [WiCoP Section 6.4.1]. The protocol maps the two logical groups using the BSSID-TunnelID item of the Conf WTP Data message element [WiCoP Section 5.2.2]. 4.1.1.2 Comparison The authors believe that CTP [I-D.singh-capwap-ctp] provides a feature that would enhance the realization of the Logical Groups objective in terms of QoS policy. For example, the CTP 'Policy' field may be integrated with WiCoP's logical BSSID-TunnelID configuration parameter to specify QoS attributes for the logical groups. 4.1.1.3 Compliance WiCoP completely satisfies this objective. 4.1.2 Support for Traffic Separation The CAPWAP Protocol MUST define transport control messages such that the transport of control messages is separate from the transport of data messages. Govindan, et al. Expires October 2005 [Page 6] Internet-Draft WiCoP Evaluation May 2005 4.1.2.1 Protocol Evaluation WiCoP uses separate tunnels for data and control traffic. Additionally, the protocol uses distinct VLAN tunnels for traffic from different logical groups [WiCoP Section 6.4.1]. This ensures that traffic flows are separated between WTPs and WLAN controller. Furthermore, WiCoP uses distinct messages for control and data traffic. The two are never combined. 4.1.2.2 Compliance WiCoP completely satisfies this objective. 4.1.3 Wireless Terminal Transparency Wireless terminals MUST NOT be required to recognize or be aware of the CAPWAP protocol. 4.1.3.1 Protocol Evaluation WiCoP does not mandate any changes to wireless terminals. The specifications only address the interface between WTPs and their WLAN controller. 4.1.3.2 Compliance WiCoP completely satisfies this objective. 4.1.4 Configuration Consistency The CAPWAP protocol MUST include support for regular exchanges of state information between WTPs and WLAN controller. Examples of state information include WTP processing load and memory utilization. 4.1.4.1 Protocol Evaluation WiCoP uses the Feedback Interval timer [WiCoP Section 5.4.2] to maintain regular exchanges of Feedback messages [WiCoP Section 5.2.3], which contain information on the configuration state of WTPs and WLAN controller. This helps the WLAN controller in effecting consistent configuration changes to all WTPs. 4.1.4.2 Compliance WiCoP completely satisfies this objective. Govindan, et al. Expires October 2005 [Page 7] Internet-Draft WiCoP Evaluation May 2005 4.1.5 Firmware Trigger The CAPWAP protocol MUST support a trigger for delivery of firmware updates. 4.1.5.1 Protocol Evaluation WiCoP activates Firmware Download message to initiate firmware check and download [WiCoP Section 5.2.3]. 4.1.5.2 Compliance WiCoP completely satisfies this objective. 4.1.6 Monitoring and Exchange of System-wide Resource State The CAPWAP protocol MUST allow for the exchange of statistics, congestion and other WLAN state information. 4.1.6.1 Protocol Evaluation WiCoP Feedback messages [WiCoP Section 5.2.3] together with QoS Value, Statistics, Interface Error and QoS Capability message elements to monitor configuration state of WTPs and WLAN Controller [WiCoP Section 5.2.2]. 4.1.6.2 Compliance WiCoP completely satisfies this objective. 4.1.7 Resource Control Objective The CAPWAP protocol MUST map the IEEE 802.11e QoS priorities to equivalent QoS priorities across the switching and wireless medium segments. 4.1.7.1 Protocol Evaluation The current specifications do not directly address this objective, however WiCoP can map IEEE 802.11e requirements to VLAN priority tags using the BSSID-TunnelID item of the Conf WTP Data message element [WiCoP Section 5.2.2]. 4.1.7.2 Compliance WiCoP partially satisfies this objective. Govindan, et al. Expires October 2005 [Page 8] Internet-Draft WiCoP Evaluation May 2005 4.1.8 CAPWAP Protocol Security The CAPWAP protocol MUST support mutual authentication of WTPs and the centralized controller. It must also ensure that information exchanges between them are secured. 4.1.8.1 Protocol Evaluation WiCoP makes use of IPSec based authentication and encryption mechanisms [WiCoP Section 6.3] to secure all exchanges. 4.1.8.2 Comparison The authors feel that the use of DTLS such as in SLAPP [I-D.narasimhan-ietf-slapp]is effective in addressing this objective. SLAPP describes an existing mechanism that can be reused in the CAPWAP context. It would be preferable for CAPWAP to use DTLS as opposed to adopting a new mechanism for key exchange and protocol security. 4.1.8.3 Compliance WiCoP partially satisfies this objective. 4.1.9 System-wide Security The design of the CAPWAP protocol MUST NOT allow for any compromises to the WLAN system by external entities. 4.1.9.1 Protocol Evaluation WiCoP does not yet address the issue of potential problems due to PMK sharing. 4.1.9.2 Compliance WiCoP does not satisfy this objective. 4.1.10 IEEE 802.11i Considerations The CAPWAP protocol MUST determine the exact structure of the centralized WLAN architecture in which authentication needs to be supported, i.e. the location of major authentication components. This may be achieved during WTP initialization where major capabilities are distinguished. The protocol must allow for the exchange of key information when authenticator and encryption roles are located in distinct entities. Govindan, et al. Expires October 2005 [Page 9] Internet-Draft WiCoP Evaluation May 2005 4.1.10.1 Protocol Evaluation This objective brings out the important architecture condition of the authenticator being located distinctly from the point of encryption. WiCoP addresses this condition with the use of the Key Config message [WiCoP Section 5.2.3]. Key Config is used to explicitly transport the 3rd message of the four-way handshake from the authenticator (WLAN controller) to the point of encryption (WTP) [WiCoP Section 6.5.6]. As a result of this feature, WiCoP allows the WTP to calculate the KeyMIC with its KeyRSC. 4.1.10.2 Comparison The authors believe that, based on prevailing specifications of the other candidate protocols, only WiCoP explicitly addresses this objective. 4.1.10.3 Compliance WiCoP completely satisfies this objective. 4.1.11 Interoperability Objective The CAPWAP protocol MUST include sufficient capabilities negotiations to distinguish between major types of WTPs. 4.1.11.1 Protocol Evaluation WiCoP realizes this objective of managing co-existence of WTPs of different MAC designs. The protocol uses the 'M' field of the WiCoP header to distinguish between local-MAC and split-MAC WTPs [WiCoP Section 5.1]. So for each WiCoP packet from a WTP, the WLAN controller simply parses the packet header and then processes it accordingly, i.e. for packets from local-MAC WTP certain MAC processing are bypassed. If however, the 'M' field is not used, then the WLAN controller must first parse incoming packet header and then use the parsed information to perform a lookup operation to determine the type of WTP and then determine how to process the packet. This is an extended procedure which will adversely affect WLAN operational performance. So using 'M' field, a WLAN controller can handle packets from different types of WTPs faster and with fewer processing steps. Govindan, et al. Expires October 2005 [Page 10] Internet-Draft WiCoP Evaluation May 2005 4.1.11.2 Comparison The authors believe that, based on prevalent specifications of alternative candidate protocols, WiCoP realizes the Interoperability Objective in the most efficient manner. 4.1.11.3 Compliance WiCoP completely satisfies this objective. 4.1.12 Protocol Specifications Any WTP or AC vendor or any person MUST be able to implement the CAPWAP protocol from the specification itself and by that it is required that all such implementations do interoperate. 4.1.12.1 Protocol Evaluation WiCoP is a complete specification and does not require any additional proprietary information to implement. 4.1.12.2 Compliance WiCoP completely satisfies this objective. 4.1.13 Vendor Independence A WTP vendor can make modifications to hardware without any AC vendor involvement. 4.1.13.1 Protocol Evaluation WiCoP is a complete specification and does not require any additional proprietary information to implement. 4.1.13.2 Compliance WiCoP completely satisfies this objective. 4.1.14 Vendor Flexibility WTP vendors must not be bound to a specific MAC. 4.1.14.1 Protocol Evaluation WiCoP is a complete specification and does not require any additional proprietary information to implement. Govindan, et al. Expires October 2005 [Page 11] Internet-Draft WiCoP Evaluation May 2005 4.1.14.2 Compliance WiCoP completely satisfies this objective. 4.2 Desirable Objectives The Desirable Objectives are those that are not crucial to a CAPWAP protocol but would be beneficial. WiCoP realizes all these requirements. 4.2.1 Multiple Authentication Mechanisms The CAPWAP protocol MUST support different authentication mechanisms in addition to IEEE 802.11i. 4.2.1.1 Protocol Evaluation WiCoP does not prevent the operation of any authentication mechanism. It is generic to support all types of authentication mechanisms. 4.2.1.2 Compliance WiCoP completely satisfy this objective. 4.2.2 Support for Future Wireless Technologies CAPWAP protocol messages MUST be designed to be extensible for specific layer 2 wireless technologies. It should not be limited to the transport of elements relating to IEEE 802.11. 4.2.2.1 Protocol Evaluation WiCoP is generic and extensible to support future developments in wireless technologies. 4.2.2.2 Compliance WiCoP completely satisfies this objective. 4.2.3 Support for New IEEE Requirements The CAPWAP protocol MUST be openly designed to support new IEEE 802.11 extensions. 4.2.3.1 Protocol Evaluation WiCoP is generic and extensible to support future developments in wireless technologies and standards. Govindan, et al. Expires October 2005 [Page 12] Internet-Draft WiCoP Evaluation May 2005 4.2.3.2 Compliance WiCoP completely satisfy this objective. 4.2.4 Interconnection Objective The CAPWAP protocol MUST NOT be constrained to specific underlying transport mechanisms. 4.2.4.1 Protocol Evaluation WiCoP does not rely of the specifics of underlying transport technologies. Although WiCoP uses UDP, it does not require any UDP- specific information for its operation. 4.2.4.2 Compliance WiCoP completely satisfies this objective. 4.2.5 Access Control The CAPWAP protocol MUST be capable of exchanging information required for access control of WTPs and wireless terminals. 4.2.5.1 Protocol Evaluation WiCoP uses the Terminal Data message element [WiCoP Section 5.2.2] to exchange association and authentication information on wireless terminals. This is used by the WLAN controller to supervise access control. 4.2.5.2 Compliance WiCoP completely satisfies this objective. 4.3 Non-objectives These objectives have been recognized by the CAPWAP WG as having relatively lower priorities for the current phase of CAPWAP. 4.3.1 Support for Non-CAPWAP WTPs The CAPWAP protocol SHOULD be capable of recognizing legacy WTPs and existing network management systems. 4.3.1.1 Protocol Evaluation WiCoP can configure local-MAC WTPs, which in some cases require Govindan, et al. Expires October 2005 [Page 13] Internet-Draft WiCoP Evaluation May 2005 limited management. This case is similar to those of legacy WTPs. 4.3.1.2 Compliance WiCoP completely satisfies this objective. 4.3.2 Technical Specifications WTP vendors SHOULD NOT have to share technical specifications for hardware and software to AC vendors in order for interoperability to be achieved. 4.3.2.1 Protocol Evaluation WiCoP is a complete specification and does not require any additional proprietary information to implement. 4.3.2.2 Compliance WiCoP completely satisfies this objective. 4.4 Operator Requirements The following objective addresses the concerns of WLAN service providers. 4.4.1 AP Fast Handoff The CAPWAP protocol operations MUST NOT impede or obstruct the efficacy of AP fast handoff procedures. 4.4.1.1 Protocol Evaluation Since WiCoP addresses the centralized WLAN architecture in which information can be managed across WTPs. Consequently, the protocol would only serve to enhance AP fast handoff procedures instead of impeding it. 4.4.1.2 Compliance WiCoP completely satisfies this objective. Govindan, et al. Expires October 2005 [Page 14] Internet-Draft WiCoP Evaluation May 2005 5. Summary The evaluation presented in this document indicates that WiCoP satisfies most of the crucial objectives. The authors also believe that WiCoP addresses some objectives in highly efficient and effective ways. Govindan, et al. Expires October 2005 [Page 15] Internet-Draft WiCoP Evaluation May 2005 +---------------------------------------------------------+------------+ | Objective | Compliance | +---------------------------------------------------------+------------+ | Logical Groups | C | | | | | Support for Traffic Separation | C | | | | | Wireless Terminal Transparency | C | | | | | Configuration Consistency | C | | | | | Firmware Trigger | C | | | | | Monitoring and Exchange of System-wide Resource State | C | | | | | Resource Control Objective | P | | | | | CAPWAP Protocol Security | P | | | | | System-wide Security | N | | | | | IEEE 802.11i Considerations | C | | | | | Interoperability Objective | C | | | | | Protocol Specifications | C | | | | | Vendor Independence | C | | | | | Vendor Flexibility | C | | | | | Multiple Authentication Mechanisms | C | | | | | Support for Future Wireless Technologies | C | | | | | Support for New IEEE Requirements | C | | | | | Interconnection Objective | C | | | | | Access Control | C | | | | | Support for Non-CAPWAP WTPs | C | | | | | Technical Specifications | C | | | | | AP Fast Handoff | C | +---------------------------------------------------------+------------+ Govindan, et al. Expires October 2005 [Page 16] Internet-Draft WiCoP Evaluation May 2005 6. Security Considerations The WiCoP evaluation does not constitue any new security considerations other than those addressed in the WiCoP specifications. 7. References [I-D.ietf-capwap-arch] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in progress), November 2004. [I-D.ietf-capwap-objectives] Govindan, S., "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", draft-ietf-capwap-objectives-02 (work in progress), April 2005. [I-D.ietf-capwap-problem-statement] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap-problem-statement-02 (work in progress), September 2004. [I-D.iino-capwap-wicop] Iino, S., "Wireless LAN Control Protocol (WiCoP)", draft-iino-capwap-wicop-00 (work in progress), March 2005. [I-D.narasimhan-ietf-slapp] Narasimhan, P., "SLAPP : Secure Light Access Point Protocol", draft-narasimhan-ietf-slapp-01 (work in progress), June 2005. [I-D.singh-capwap-ctp] Singh, I., "CAPWAP Tunneling Protocol (CTP)", draft-singh-capwap-ctp-01 (work in progress), April 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Govindan, et al. Expires October 2005 [Page 17] Internet-Draft WiCoP Evaluation May 2005 Authors' Addresses Saravanan Govindan Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore Phone: +65 6550 5441 Email: saravanan.govindan@sg.panasonic.com Satoshi Iino Panasonic Mobile Communications 600, Saedo-cho Tsuzuki-ku Yokohama 224 8539 Japan Phone: +81 45 938 3789 Email: iino.satoshi@jp.panasonic.com Hong Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534 415 Singapore Phone: +65 6550 5447 Email: hong.cheng@sg.panasonic.com Mikihito Sugiura Panasonic Mobile Communications 600, Saedo-cho Tsuzuki-ku Yokohama 224 8539 Japan Phone: +81 45 938 3789 Email: sugiura.mikihito@jp.panasonic.com Govindan, et al. Expires October 2005 [Page 18] Internet-Draft WiCoP Evaluation May 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. Govindan, et al. Expires October 2005 [Page 19]