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]
