Internet DRAFT - draft-gwee-capwap-comparative-analysis
draft-gwee-capwap-comparative-analysis
Network Working Group R. Gwee
Internet-Draft Republic Polytechnic
Expires: March 16, 2006 September 12, 2005
CAPWAP Comparative Analysis
draft-gwee-capwap-comparative-analysis-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 March 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The purpose of this document is to present a comparative evaluation
of the Control and Provisioning of Wireless Access Points (CAPWAP)
protocol proposals. To the date of this document, the following four
protocols have been proposed, namely CAPWAP Tunneling Protocol (CTP),
Light Weight Access Point Protocol (LWAPP), Secure Light Access Point
Protocol (SLAPP), Wireless LAN Control Protocol (WiCoP). Each of
these protocols has its own unique strengths in fulfilling the CAPWAP
Objectives through their own mechanisms and functionalities. The
final CAPWAP protocol should comprise all of these strengths. This
Gwee Expires March 16, 2006 [Page 1]
Internet-Draft Comparative Analysis September 2005
document gives a comparative study of the four proposed protocols
based on the CAPWAP Objectives and makes recommendations on the
combination of their strengths for the final CAPWAP protocol.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Comparative Evaluation . . . . . . . . . . . . . . . . . . . . 7
4.1. Mandatory Objectives . . . . . . . . . . . . . . . . . . . 7
4.1.1. Logical Groups . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Support for Traffic Separation . . . . . . . . . . . . 9
4.1.3. Wireless Terminal Transparency . . . . . . . . . . . . 10
4.1.4. Configuration Consistency . . . . . . . . . . . . . . 11
4.1.5. Firmware Trigger . . . . . . . . . . . . . . . . . . . 13
4.1.6. Monitoring and Exchange of System-wide Resource
State . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.7. Resource Control Objective . . . . . . . . . . . . . . 16
4.1.8. CAPWAP Protocol Security . . . . . . . . . . . . . . . 18
4.1.9. System-wide Security . . . . . . . . . . . . . . . . . 19
4.1.10. IEEE 802.11i Considerations . . . . . . . . . . . . . 20
4.1.11. Interoperability Objective . . . . . . . . . . . . . . 21
4.1.12. Protocol Specifications . . . . . . . . . . . . . . . 23
4.1.13. Vendor Independence . . . . . . . . . . . . . . . . . 24
4.1.14. Vendor Flexibility . . . . . . . . . . . . . . . . . . 25
4.1.15. NAT Traversal . . . . . . . . . . . . . . . . . . . . 25
4.2. Desirable Objectives . . . . . . . . . . . . . . . . . . . 26
4.2.1. Multiple Authentication Mechanisms . . . . . . . . . . 27
4.2.2. Support for Future Wireless Technologies . . . . . . . 28
4.2.3. Support for New IEEE Requirements . . . . . . . . . . 29
4.2.4. Interconnection Objective . . . . . . . . . . . . . . 30
4.2.5. Access Control . . . . . . . . . . . . . . . . . . . . 30
5. Comparative Analysis . . . . . . . . . . . . . . . . . . . . . 32
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
Gwee Expires March 16, 2006 [Page 2]
Internet-Draft Comparative Analysis September 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].
Gwee Expires March 16, 2006 [Page 3]
Internet-Draft Comparative Analysis September 2005
2. Terminology
This document follows the terminologies of [I-D.ietf-capwap-arch] and
[I-D.ietf-capwap-objectives].
Gwee Expires March 16, 2006 [Page 4]
Internet-Draft Comparative Analysis September 2005
3. Introduction
With the popularity of wireless connectivity in today's markets,
deployments of large number of wireless termination points (WTPs) in
large wireless local area networks (WLANs) have become relatively
common. The sheer size of such networks has led to scalability
issues that have been described in the CAPWAP Problem Statement
[I-D.ietf-capwap-problem-statement] . These issues can be summarized
as: possible misconfiguration and improper operation of the WLAN;
difficulty in distributing and maintaining a consistent configuration
throughout the entire WLAN; ineffective handling of the dynamic
nature of the wireless medium; challenges in ensuring security for
the entire WLAN. In view of these challenging issues, different
vendors have derived their own proprietary solutions. However, these
solutions are not interoperable and thus the CAPWAP standardization
is in process to provide an integral and interoperable solution to
the above problems.
The primary purpose of CAPWAP is to ensure effective handling of
large WLANs. The Architecture Taxonomy [I-D.ietf-capwap-arch] has
highlighted a centralized WLAN architecture in which an access
controller (AC) provides centralized control and management for a
group of WTPs. To achieve interoperability in the CAPWAP framework,
critical objectives have been identified [I-D.ietf-capwap-objectives]
and these will be used as the basis for the comparative evaluation in
this document. The comparative study will only focus on the
mandatory and desirable objectives for analysis. Non- objectives and
Operator Requirements are out of scope for this document. It is of
utmost importance that the final CAPWAP protocol will fulfill the
main requirements for addressing the Problem Statement and hence be
suitable for managing large WLANs effectively.
To the date of this document, four protocols, namely CTP, LWAPP,
SLAPP and WiCoP, have been proposed as candidate protocols for
CAPWAP.
CTP [I-D.singh-capwap-ctp] provides centralized control and
provisioning of large WLANs and improves scalability by minimizing
the configuration of the wired infrastructure. Its centralized
operation helps in providing centralized security and policy
management as well. As CTP assumes that the MAC layer of the
wireless technology is fully implemented in the WTP, it is able to
provide IP network services to users independent of the wireless
technology used. This is possible by making use of the control
channel binding between the WTP and AC to provide all the necessary
signaling required for proper operation.
LWAPP [I-D.ohara-capwap-lwapp] defines how the WTPs communicate with
Gwee Expires March 16, 2006 [Page 5]
Internet-Draft Comparative Analysis September 2005
AC by means of layer 2 protocols or a routed IP network. It
concentrates on three goals. The first goal is to provide
centralized control and functions for a wireless network. The second
goal is to shift the higher level protocol processing burden from the
WTP to the AC, resulting in lighter WTP. The third goal is to
provide a generic encapsulation and transport mechanism. LWAPP
claims to be independent of the layer 2 wireless technology.
SLAPP [I-D.narasimhan-ietf-slapp] is unique in terms of its protocol
design. It consists of a technology-independent component and a
technology-dependent component. The former will perform the core
functionalities of the protocol that is independent of the wireless
technology used. The latter component is dependent on the type of
wireless technology and provides control functionalities in the form
of a relevant control protocol. These two components will form a
complete solution. Through such a design, SLAPP is extensible to any
future technologies or new methods.
WiCoP [I-D.iino-capwap-wicop] provides a common platform for
accommodating WLAN entities of different architectural designs. It
allows interoperability between WTPs and ACs even if their
architectural designs are different. Thus, it is able to provide
cost-effective WLAN expansions and accommodate future development in
WLAN technologies. WiCoP can also be used on shared infrastructure
WLANs in which different logical groups are situated in a single
physical WLAN. In such cases, tunnels will be used to separate
traffic flows based on logical grouping.
It can be inferred that each of the above protocols have their own
strengths in certain aspects of WLAN management. It will be
beneficial for the industry to have an effective protocol capable of
addressing various aspects of WLAN management. Thus the final CAPWAP
protocol should have the sum of the strengths of individual
protocols. In this way, the industry can benefit by having the best
of available solutions. This document takes inspiration from
presentations made during IETF 63 and provides recommendations on the
various protocols mechanisms.
Gwee Expires March 16, 2006 [Page 6]
Internet-Draft Comparative Analysis September 2005
4. Comparative Evaluation
This section provides a comparative evaluation of the various
protocols mechanisms for each CAPWAP objectives. For this document,
only the Mandatory and Desirable Objectives are considered. The non-
Objectives are not considered as they are deemed not essential for
the final CAPWAP protocol.
4.1. Mandatory Objectives
According to the CAPWAP Objectives, mandatory objectives are
considered crucial for the control and provisioning of WTPs. They
directly address the Problem Statement and must be realized by the
final CAPWAP protocol. In the following, a comparison of the various
protocols' mechanisms is made against each mandatory objective. A
description of each objective and statements from the evaluation
draft of each protocol are stated for reference. A final analysis
and recommendation of the preferred mechanism among the four is given
at the end of each objective.
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. CTP Evaluation
In CTP, physical and logical associations are enumerated by means of
its discovery mechanism. Unique indices for the enumeration of radio
and network are provided using Radio-Index and Network-Index
respectively. Such enumerations are used in protocol exchange and
state machine to support logical grouping of physical WTPs.
4.1.1.2. LWAPP Evaluation
For LWAPP, BSSID/SSIDs are used to identify logical groups. Thus a
single WTP is assumed to support multiple SSIDs. Logical groups can
be created by the AC through the creation of WLANs. A WLAN will be
identified through the SSID and can have a separate security policy
and a unique BSSID. Thus each WLAN can be assumed as a separate
network. Specific rules are given on the BSSID to WLAN Identifier
mapping. One thing to note for Local MAC WTPs is that VLAN tags may
be used to allow for bridging of data frames to a specific VLAN.
This function will allow the support of logical groups in Local MAC
mode.
Gwee Expires March 16, 2006 [Page 7]
Internet-Draft Comparative Analysis September 2005
4.1.1.3. SLAPP Evaluation
The SLAPP protocol allows a WTP to define its logical groups
supported through the use of BSSIDs. On the AC side, a logical group
can be created by defining a WLAN with a specific BSSID, ESSID and
associated parameters. Each logical group can have its own set of
policies such as security, QoS etc.
4.1.1.4. WiCoP Evaluation
WiCoP makes use of BSSIDs to create logical groups for the wireless
medium segment and VLANs to create logical groups for the wired
segment. Both logical groups are then mapped together using the
BSSID-TunnelID. This mechanism supports both Split MAC and local MAC
architectures.
4.1.1.5. Analysis
From the objective statement, it is clear that logical groups must be
supported across both wired and wireless aspects of the network
regardless of the type of MAC architecture in WTP. Such grouping
will provide advantages in terms of easier traffic management, better
security. Thus it must be considered that the CAPWAP protocol should
be able to fulfill this objective in an effective and efficient
manner.
From the above descriptions, LWAPP and SLAPP work similarly in the
sense that they make use of BSSIDs and WLANs to define logical
groups. The difference between these two protocols lies in the
parameters used in the classifying of logical groups. However, SLAPP
does not specify the use of VLAN for support of logical groups in
Local MAC mode, unlike LWAPP. On the other hand, WiCoP makes use of
BSSIDs and VLANs for identifying logical groups while CTP supports
enumeration of logical association.
4.1.1.6. Recommendation
From the above evaluations, all the four protocols' mechanisms do
fulfill this objective in an effective manner. But in terms of
efficiency and simplicity, the mechanism in WiCoP does appear to have
an advantage in supporting the logical group objective. It
explicitly includes logical group information in the WTP
configuration phase and provides mappings for logical groups to cover
both wireless and wireline segments. This makes WiCoP's approach to
this objective highly structured.
Gwee Expires March 16, 2006 [Page 8]
Internet-Draft Comparative Analysis September 2005
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."
4.1.2.1. CTP Evaluation
For CTP, data packets are always enumerated as CTP_DATA type. In
addition, a logical WTP device has the option of transporting the
data traffic via tunneling or bridging locally onto the wired
network. On the other hand, control packets are handled separately
from data packets and always terminated at the controller.
4.1.2.2. LWAPP Evaluation
For LWAPP, a control packet is differentiated from a data packet by
the definition of a 'C' bit in the LWAPP header. If the bit is set,
the LWAPP frame is a control frame and if the bit is cleared, the
LWAPP frame is a data frame. In split MAC mode, the frame is
tunneled to the AC. However, in the local MAC mode, the frame can be
locally bridged at the WTP. Both mechanisms help in keeping the
control and data traffic separated.
4.1.2.3. SLAPP Evaluation
In the draft specification of SLAPP, the IEEE 802.11 control protocol
is used as an example. The IEEE 802.11 control protocol has two
components which caters for control packets and data packets
individually. Control packets will contain a SLAPP control protocol
header and transmitted as UDP packets to the AC. Data packets will
be tunneled via Generic Routing Encapsulation (GRE) to the AC. In
this way, both control and data packets are uniquely identified and
separated sufficiently.
4.1.2.4. WiCoP Evaluation
WiCoP makes use of tunnels to differentiate control and data traffic.
Control traffic is transmitted via a control tunnel while data
traffic from different logical groups is transmitted via distinct
VLAN tunnels. This ensures separation of traffic flows between the
WTPs and AC. In addition, a 'C' bit is used to differentiate a
control frame from a data frame.
4.1.2.5. Analysis
For CTP, although it has been clearly stated that CTP data messages
are used to tunnel user data between WTP and AC, it only meets this
Gwee Expires March 16, 2006 [Page 9]
Internet-Draft Comparative Analysis September 2005
objective partially as it does not specify how such a tunnel is
triggered. More information is required on the configuration of the
tunneling option in a WTP.
On the other hand, LWAPP does fulfill this objective through its
various mechanisms used in separating the control and data traffic.
It is able to meet this objective in both local and split MAC
architectures.
SLAPP is also able to fulfill this objective as it distinguishes
between control packets and data packets based on different
encapsulation of different packets. However, it should be noted that
the control protocol aspect of SLAPP is actually dependent on the
type of technologies used and thus attention must be paid in this
area for use with future technologies.
WiCoP is able to fulfill this objective as well based on its use of
separate data and control tunnels. Similarly to LWAPP, a 'C' bit is
used to differentiate the control and data packets. However, it is
interesting to find that WiCoP makes use of only one control tunnel
to transport control packets from all logical groups. This may be
deemed as a security issue and needs to be considered in that light.
4.1.2.6. Recommendation
From the descriptions above, CTP's mechanism does not explicitly
specify how a trigger for a user data tunnel is called. It will be
best if CTP can provide some specifications on the trigger issue. On
the other hand, WiCoP's design gives rise to some security concern
due to lack of separation of control packets from different logical
groups. It will also be beneficial for CAPWAP if WiCoP can provide
some form of separation for the control packets for logical groups.
For example, it can introduce distinct tunnels not only for data
packets but also for control packets for different logical groups.
In view of these issues, the mechanism stated in LWAPP and SLAPP
specifications are at a better position to meet this objective in an
equally effective manner.
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. CTP Evaluation
The operation of CTP is transparent to the wireless terminals.
Wireless terminals only interact with the WTPs' wireless MAC and
their traffic is bridged either to the controller or the local wired
Gwee Expires March 16, 2006 [Page 10]
Internet-Draft Comparative Analysis September 2005
infrastructure. Any encapsulation of traffic that took place will be
transparent to the wireless terminals as well.
4.1.3.2. LWAPP Evaluation
The LWAPP protocol only operates between the AC and WTP and thus does
not have any impact on the wireless terminals. Upon connection of a
WTP to an AC, it will be configured to provide service autonomously.
4.1.3.3. SLAPP Evaluation
SLAPP only operates between the AC and WTPs. SLAPP messages do not
travel on the IEEE 802.11 wireless links and thus are transparent to
the wireless terminals.
4.1.3.4. WiCoP Evaluation
WiCoP does not require any changes to the wireless terminals. Its
operations are confined between the AC and WTPs. Thus wireless
terminals are not aware of the WiCoP protocol.
4.1.3.5. Analysis
On analysis of the four proposed protocols, it can be observed that
these protocols are designed in such a way that their operations do
not extend to the wireless aspect or affect any wireless terminals.
4.1.3.6. Recommendation
The mechanisms stated in all the four proposed protocols realize this
objective in an equally effective manner.
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. CTP Evaluation
In its specification, CTP includes support for regular exchanges of
state information through its statistics messages. In this case, CTP
recommends the reuse of IEEE 802.11 MIBs for configuration and
statistics message payload. MIB extensions should be defined where
the corresponding MIBs are not sufficient.
Gwee Expires March 16, 2006 [Page 11]
Internet-Draft Comparative Analysis September 2005
4.1.4.2. LWAPP Evaluation
The LWAPP protocol provides two options in which a WTP manages its
configuration. WTPs can retain any configuration parameters provided
by the AC or let the AC maintain a record of all WTPs. If a WTP
saves configuration locally, it is able to provide such information
to any new AC in the event of failure and reconnection to a new AC.
Statistical information in LWAPP specification is bound to IEEE
802.11. Any new wireless technologies for LWAPP will need to define
their corresponding statistics report format.
4.1.4.3. SLAPP Evaluation
During the initialization process in SLAPP, a capability exchange
mechanism is performed between the WTPs and AC, allowing the AC to
have a consistent picture of the capabilities of the WTPs. After the
exchange, the AC configures the WTPs via configuration messages. WTP
statistics and status can also be obtained by an AC upon request to
the WTP.
4.1.4.4. WiCoP Evaluation
WiCoP makes use of Feedback messages which contain configuration
information of WTPs and ACs. The WTPs and AC regularly exchange
Feedback messages and this helps to provide a consistent
configuration for all the WTPs.
4.1.4.5. Analysis
It is important to understand the rationale behind this objective.
As a CAPWAP protocol is meant to support a large WLAN network
environment, proper maintenance of state information of all the nodes
is required for its effective operation. A deeper analysis indicates
that in addition to this function, the type of state information to
be exchanged is also important to for effective management with
minimum operation.
The above four protocols have focused on the fulfillment of the
objective through their own mechanisms but does not provide
sufficient information on the type of state information. Although
the latter part is implementation specific, it is useful to provide a
framework such that there will be fewer implementation issues arising
in the future.
4.1.4.6. Recommendation
The mechanisms stated in all the four protocols fulfill this
objective in an equally effective manner. However, LWAPP and CTP
Gwee Expires March 16, 2006 [Page 12]
Internet-Draft Comparative Analysis September 2005
specifications provide some recommendation of the use of IEEE 802.11
bound statistics and configuration in their specification. Thus in
terms of details, it is recommended to use the mechanisms of LWAPP or
CTP for this objective. It will be good if the final CAPWAP protocol
does consider this aspect in its specification, providing some
details of a framework.
4.1.5. Firmware Trigger
"The CAPWAP protocol MUST support a trigger for delivery of firmware
updates."
4.1.5.1. CTP Evaluation
A WTP image management system is out of scope in the CTP
specification. However, it does provide a trigger for software
upgrade in its control channel establishment phase. A WTP sends a
software update request/response message to the AC to confirm whether
it needs to update its firmware. CTP does not specify how the
firmware upgrade will be carried out but assumes the application of
standardized binary transport protocols (FTP/TFTP).
4.1.5.2. LWAPP Evaluation
LWAPP provides a trigger for firmware upgrade during the image-data
phase of its state machine. A WTP communicates with the AC to
determine whether it needs to upgrade its firmware. The WTP then
makes use of the Image Download message to download the required
files.
4.1.5.3. SLAPP Evaluation
SLAPP provides a trigger for firmware upgrade through its Image
Download protocol. In its specification, it mentions a method of
securing image download using DTLS. The image download protocol is
selected when a new image is determined to be available during the
SLAPP discovery phase. The WTP then downloads the new firmware from
AC for updating.
4.1.5.4. WiCoP Evaluation
WiCoP makes use of Firmware Download message to initiate firmware
check and download regularly. Such messages are sent out
periodically in order to ensure the most up-to-date firmware for the
WTPs.
Gwee Expires March 16, 2006 [Page 13]
Internet-Draft Comparative Analysis September 2005
4.1.5.5. Analysis
Among the four proposed protocols, WiCoP seem to be the only protocol
that specifies a firmware update periodically. For the rest of the
protocols, the trigger for the firmware update only occurs during the
setting up of a connection. Often, it is important that a WTP will
update its firmware regularly for effective operation. This is
especially true for operation within a large WLAN environment where
the are possibilities for WTPs to be reorganized frequently. It will
be better if a firmware update be triggered as and when there is an
available new update and not when a new connection is being set up.
4.1.5.6. Recommendation
As stated earlier, WiCoP is the only protocol that provides firmware
update during running operation mode. Such procedure is important if
consistent firmware version is to be found in all WTPs in a large
WLAN environment. In addition to updating firmware during the
setting up of new connections, frequent updates and firmware checks
are highly recommended for this objective. In view of this
perspective, the mechanism stated in WiCoP fulfills this objective in
the most effective manner.
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. CTP Evaluation
CTP makes use of the statistics request and statistics notification
messages to facilitate the periodic exchange of statistics. The
statistics payload is based on MIB definitions from the IEEE 802.11
standard and extensions. This protocol mechanism is agnostic to
wireless technologies and updates to existing wireless standards.
4.1.6.2. LWAPP Evaluation
LWAPP provides a mechanism for exchange of statistics and WLAN state
information between a WTP and AC. The type of statistics and state
information differs according to the aspect of the network
considered: wireless and wired.
Information collected on wired aspect includes firmware version,
number of radios, radio failures etc. In the event of failure, a WTP
may also provide reboot statistics and reason for previous failure.
On the other hand, information collected on wireless aspect includes
statistics such as signal strength based on AC's policy. The LWAPP
Gwee Expires March 16, 2006 [Page 14]
Internet-Draft Comparative Analysis September 2005
protocol also allows for unsolicited statistics collection.
4.1.6.3. SLAPP Evaluation
The SLAPP protocol allows for monitoring and exchange of system wide
resources through the definition of configuration, status, event and
statistics elements. It allows different types of statistics such as
transmit frame counters, receive frame counters etc to be exchanged
between a WTP and AC. Statistics collected can be in aggregated form
or instantaneous form. SLAPP allows an AC to configure specific
events at the WTP through the event mechanism. Using one of the
configuration elements, an AC may reconfigure or re-adjust its
parameters based on statistics, status or events collected from a
WTP.
4.1.6.4. WiCoP Evaluation
WiCoP makes use of Feedback messages together with QoS-Value,
Statistics, Interface-Error and QoS-Capability message elements to
monitor configuration state of the WTPs and AC. The Feedback
messages are sent regularly to the AC by the WTPs. This mechanism is
also combined with keepalive signaling to serve dual roles of
feedback and notification. WiCoP timers are configured to manage
these dual roles.
4.1.6.5. Analysis
From the objective statement, it should be noted that not only should
the final CAPWAP protocol provide a mechanism for monitoring and
exchange of system-wide resource state information, it is also
important for the protocol specification to list the state
information that are being monitored and exchanged by WTPs and ACs.
Furthermore, the final CAPWAP protocol should apply this objective
over the entire network and not focus on only a portion of the
network e.g. wireless portion.
From the above description, the four proposed protocols provide their
own unique mechanisms to exchange system-wide resource state
information. However, it seems that CTP has focused this objective
more on the wireless aspect of the network and thus may not be a
complete solution for this objective. The remaining three protocols
fulfill this objective effectively based on their specifications but
there is an interesting observation on WiCoP. The WiCoP protocol
allows a WTP and AC to exchange Feedback messages regularly as the
Feedback messages also serve as keepalive signals. The dual role of
such feedback system is crucial for operational efficiency especially
in a large WLAN environment. Furthermore, the QoS capability message
element in WiCoP provides a description of the network congestion
Gwee Expires March 16, 2006 [Page 15]
Internet-Draft Comparative Analysis September 2005
information which directly addresses the objective.
4.1.6.6. Recommendation
CTP focuses this objective more on the wireless aspect of the network
and thus may not be a complete solution for this objective. The
remaining protocols are able to fulfill this objective effectively
but it can be observed that the Feedback messages used in WiCoP play
a dual role in exchanging state information and acting as keepalive
signals. Such mechanism allow for high operational efficiency
especially in a large WLAN environment.
In view of this, it can be stated that the mechanisms stated in
LWAPP, SLAPP and WiCoP fulfill this objective effectively. But in
terms of operational efficiency, the mechanism in WiCoP certainly has
an advantage over the rest of the proposed protocols.
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. CTP Evaluation
CTP makes use of a two tiered mechanism to map QoS priorities on
packets on both wired and wireless aspects of the network. On the
wired aspect of the network, CTP defines an 8-bit field for carrying
QoS related information independently of the transport protocol.
Alternatively, IEEE 802.1p tags can be used on packets to carry QoS
information across the wired segment.
On the other hand, for the wireless aspect of the network, the
mapping of QoS information on the packets is carried out using the
IEEE 802.11e standard.
4.1.7.2. LWAPP Evaluation
In LWAPP, an IEEE 802.11 WTP QoS message element is defined which is
sent by the AC to the WTP to communicate quality of service
configuration information. This message element contains fields that
correspond to an access category in the IEEE 802.11e specifications
and specifies whether data frames are to be tagged using IEEE 802.1p
or DSCP.
When the AC creates a WLAN on the WTP through the Add WLAN command,
IEEE 802.11e information elements and the default QoS value may be
included as parameters to configure the WLAN. Such parameters will
Gwee Expires March 16, 2006 [Page 16]
Internet-Draft Comparative Analysis September 2005
be used to determine the access category queue to be used for all
packets for a particular user.
4.1.7.3. SLAPP Evaluation
SLAPP defines an IEEE 802.11e element for configuring the IEEE
802.11e functions at the WTP by the AC. The element allows the
support of WMM, WMM-SA and U-APSD. Thus the internal parameters to
be used follow that of the standard used. The mapping between IEEE
802.11e access category and DSCP or IEEE 802.1d tags are defined in
the WMM specification. It is expected that the AC and WTP follow
this standard mapping for QoS over the wired and wireless aspects of
the network.
4.1.7.4. WiCoP Evaluation
The current specifications do not directly address this objective,
although it is possible to implement a mapping of IEEE 802.11e AC to
VLAN priority tags using the BSSID-TunnelID item.
4.1.7.5. Analysis
Based on the description above, WiCoP does not directly address this
objective. CTP and SLAPP follow a model in which packets on the
wired aspect are tagged using a QoS policy and packets on the
wireless aspect are tagged using the IEEE 802.11e standard. Mapping
between the two QoS policies are performed on the WTP side. Although
this model may work well, there is a lack of control for the AC in
preserving the QoS requirements from the AC to the wireless terminal.
Thus the effectiveness of CTP and SLAPP in meeting this objective may
be undermined if the mapping is not done accurately. On the other
hand, LWAPP does allow an AC to determine the QoS policy of a
wireless terminal directly and thus is able to have more control on
the QoS preservation along both wired and wireless aspects of the
network.
4.1.7.6. Recommendation
WiCoP does not directly address this objective and thus may be
inappropriate to be considered for this objective. CTP and SLAPP
exhibit a lack of control by AC in preserving the QoS requirements on
both wired and wireless aspects of the network. LWAPP is able to
allow an AC to have more control in determining the QoS policy of a
wireless terminal directly. Thus in view of this advantage, the
mechanism in LWAPP meets this objective in a most effective manner.
Gwee Expires March 16, 2006 [Page 17]
Internet-Draft Comparative Analysis September 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. CTP Evaluation
CTP does not support a pre-shared key mechanism for mutual
authentication. It assumes the use of digital certificates for
mutual authentication between the WTP and AC. CTP also specifies
that the encryption key is to be generated by the AC and transported
securely to the WTP.
4.1.8.2. LWAPP Evaluation
LWAPP specifies two different methods of authentication between the
AC and WTP. The first method is asymmetric cryptography and makes
use of X.509 certificates on both AC and WTP. The second method
makes use of pre-shared keys that is predefined on both AC and WTP.
The exchange of session keys for encrypting control traffic has also
been specified in LWAPP. Session keys may be updated over time
through the key update mechanism for added security.
4.1.8.3. SLAPP Evaluation
SLAPP uses DTLS for the purpose of mutual authentication, key
management, and encryption. As DTLS provides a secure and
connectionless channel using a widely accepted and analyzed protocol,
it reduces the need for redefinition in these aspects of the
protocol.
4.1.8.4. WiCoP Evaluation
WiCoP makes use of IPSec based authentication and encryption
mechanisms to secure all exchanges.
4.1.8.5. Analysis
WiCoP does not seem to explicitly specify how IPSec is used in its
authentication and encryption mechanisms apart from mentioning that
it is being used. It will be best if WiCoP provides more information
on it.
CTP is different from the other protocols in the sense that it makes
use of digital certificates solely instead of pre-shared keys.
LWAPP is able to support both the use of digital certificates and
Gwee Expires March 16, 2006 [Page 18]
Internet-Draft Comparative Analysis September 2005
pre-shared keys, thus providing a comprehensive support in the area
of security.
SLAPP makes use of an existing protocol DTLS to meet its objectives.
The use of DTLS will certainly reduce review work required in the WG
as compared to the use of other security mechanisms in other
protocols.
4.1.8.6. Recommendation
It is important to remember that realizing this objective should not
involve any new work on security measures or the design of new
security mechanisms. The aim of this objective is to ensure
sufficient security for the protocol using existing and widely
accepted security mechanisms if possible. Involving new work or
excessive review on the various security mechanisms may hamper the
progress of the finalization of the CAPWAP protocol. Thus in view of
this, the mechanism used in SLAPP meets this objective in a most
practical manner as it involves the least review work.
4.1.9. System-wide Security
"According to the CAPWAP objectives, it states that "The design of
the CAPWAP protocol MUST NOT allow for any compromises to the WLAN
system by external entities."
4.1.9.1. CTP Evaluation
CTP does not define a data path encryption mechanism as it assumes
that there will be an end-to-end encrypted tunnel for sensitive data.
CTP control messages will be sent encrypted with AES-CCM.
4.1.9.2. LWAPP Evaluation
LWAPP control protocol is secured through a key exchange that is
protected either through a pre-shared key or via an X.509
certificate. For use of X.509 certificate, LWAPP specifies a
certificate profile that limits a certificate to a specific role.
PMK sharing is not permitted and the PMK is always held at the AC.
This arrangement is to facilitate support for future IEEE 802.11
extensions as well as detection and taking action against rouge
attacks.
4.1.9.3. SLAPP Evaluation
SLAPP uses DTLS to protect its communication. PMK sharing is not
permitted and SLAPP specifies that the PMK resides on the
authenticator.
Gwee Expires March 16, 2006 [Page 19]
Internet-Draft Comparative Analysis September 2005
4.1.9.4. WiCoP Evaluation
WiCoP does not yet address the issue of potential problems due to PMK
sharing.
4.1.9.5. Analysis
Similarly to the analysis provided in the earlier objective, LWAPP
and SLAPP provide sufficient security measures as compared to the
rest.
4.1.9.6. Recommendation
Similarly to the recommendations in the earlier objective, the
mechanism in SLAPP meets this objective in a most practical manner.
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."
4.1.10.1. CTP Evaluation
CTP considers the IEEE 802.11i security function in two components
namely EAP authenticator and key management. The two components can
be co-located or separate on the WTP or the AC. Any exchange of
security association information between the AC and the WTP is
protected either by IEEE 802.11i mechanisms or by CTP mechanisms.
4.1.10.2. LWAPP Evaluation
LWAPP defines both local and split MAC approaches for this objective.
For Split MAC mode, the authentication is centralized but encryption
is performed either at the AC or WTP. For local MAC mode, the
authentication lies in the AC but encryption occurs at the WTP. In
both modes, PMK is maintained in the AC.
4.1.10.3. SLAPP Evaluation
SLAPP supports both local MAC and split MAC architectures for this
objective. It takes a step further in defining a bridged and
tunneled version of the local MAC architecture, and a distinction
Gwee Expires March 16, 2006 [Page 20]
Internet-Draft Comparative Analysis September 2005
between L2 crypto being handled at the WTP versus L2 crypto being
handled at the AC for the split MAC architecture. The WTP and AC
agree on the type of architecture during the registration phase of
the SLAPP state machine.
When L2 crypto is performed at the AC, encrypted IEEE 802.11 frames
will be tunneled to the AC. If L2 crypto is performed at the WTP,
decrypted IEEE 802.3 frames will be tunneled. When the IEEE 802.1x
authenticator is located on the AC and L2 crypto is performed by the
WTP, the AC will send PTKs and GTKs to the WTP through a control
message that is protected by DTLS.
4.1.10.4. WiCoP Evaluation
WiCoP addresses a scenario in which the authenticator is separated
from the point of encryption for both Split MAC and Local MAC
architectures. In this case, a Key Config message is used to
explicitly transport the 3rd message of the four-way handshake from
the authenticator to the point of encryption. Thus the KeyMIC and
KeyRSC can be calculated.
4.1.10.5. Analysis
From the above description, all the four protocols consider this
objective in their design. All the protocols consider the specific
case in which the authenticator is separated from the point of
encryption and thus a possible solution to address this condition.
In accordance with this objective, it can be observed that WiCoP
reveals a specific scenario where the Key Config message is used.
However, this is not explicitly specified in other protocols. Thus
this mechanism in WiCoP satisfies the objective exactly with its Key
Config message. This message directly addresses the objective. But
it is also noted that the rest of the protocols are also compliant
with this objective.
4.1.10.6. Recommendation
WiCoP provides the greatest details in relation to this objective.
The specifications clearly describe how the Key Config message is
used to exchange counter information in designs where the
authentication function and encryption point are located in different
WLAN devices. So the WiCoP mechanism addresses this objective in the
most complete manner.
4.1.11. Interoperability Objective
"The CAPWAP protocol MUST include sufficient capabilities
negotiations to distinguish between major types of WTPs."
Gwee Expires March 16, 2006 [Page 21]
Internet-Draft Comparative Analysis September 2005
4.1.11.1. CTP Evaluation
In CTP, a capabilities exchange mechanism is specified that allows a
WTP and AC to negotiate their operational mode. In Split MAC mode,
the WTP will forward all wireless MAC management traffic to the AC.
In local MAC mode, the 802.11 management frames will be terminated at
the WTP.
In Split MAC mode, the WTP will forward all data traffic to the AC
with the format of the traffic to be IEEE 802.11 or IEEE 802.3
depending on the mode of the control channel.
In Local MAC mode, the data frames will be bridged locally by the WTP
to its switching segment. The switching segment may be present
locally at the WTP or at the AC. For AC handled bridged access, the
CTP protocol provides a tunneling method for IEEE 802.3 frame
encapsulation.
4.1.11.2. LWAPP Evaluation
The LWAPP protocol is capable of supporting both local and split MAC
approaches. It specifies the division of labour for both local and
split MAC architectures. A WTP advertises its mode of operation
through the WTP Mode and Type message element.
4.1.11.3. SLAPP Evaluation
SLAPP supports not only both the split-MAC and local-MAC
architecture, but also defines a set of sub-modes for each of these
architectures and appropriate split of AP functions between the AC
and the WTP for each of these sub-modes. A WTP indicates its support
of the CAPWAP modes defined in SLAPP during the registration phase.
The AC will then select a CAPWAP mode that it can operate with the
WTP.
4.1.11.4. WiCoP Evaluation
WiCoP makes use of a 'M' field in its header to distinguish between
local MAC and split MAC WTPs. The AC processes each WiCoP packet
accordingly based on this information.
So using 'M' field, an AC can handle packets from different types of
WTPs faster and with fewer processing steps.
4.1.11.5. Analysis
From the above description, the four proposed protocols have
sufficient capabilities to distinguish between major types of WTP.
Gwee Expires March 16, 2006 [Page 22]
Internet-Draft Comparative Analysis September 2005
The difference between these protocols lies in their form of
mechanisms and the complexity of these mechanisms. SLAPP supports
the widest range of WTP architecture modes but it also incurs a high
level of complexity. Although CTP and LWAPP supports this objective
with less complexity, but negotiation must takes place between the
WTP and AC beforehand in order to find out the types of architectures
of the WTP. WiCoP seem to offer a very practical and yet simple
solution in meeting this objective by making use a single 'M' field.
4.1.11.6. Recommendation
SLAPP supports the most number of modes of CAPWAP architectures
although it also incurs a high level of complexity on the protocol
design. CTP and LWAPP are less complex but an extra step is required
in both protocols to negotiate the types of architectures used in
WTPs. On the other hand, WiCoP offers a simple and practical
solution by making use of a 'M' field. Thus it can be inferred that
the mechanism used in WiCoP satisfies this objective the best with
its integrated approach to operability.
4.1.12. Protocol Specifications
"Any WTP or WLAN controller 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. CTP Evaluation
The CTP specification has provided full specification of the protocol
and its operation within WTPs and ACs. It also indicates the
configuration and statistics capabilities based on MIB specifications
from relevant IEEE standards.
4.1.12.2. LWAPP Evaluation
The LWAPP specification has provided full specification of the
protocol that ensures interoperability for any WTP or AC vendors.
4.1.12.3. SLAPP Evaluation
SLAPP does not any prior exchange of technical information between AC
and WTP vendors. By implementing just the protocol, interoperability
is achieved as long as both the WTP and AC can support the same mode
of CAPWAP architectures.
4.1.12.4. WiCoP Evaluation
WiCoP is a complete specification and does not require any additional
Gwee Expires March 16, 2006 [Page 23]
Internet-Draft Comparative Analysis September 2005
proprietary information to implement.
4.1.12.5. Analysis
From the objective, it mainly suggests a need for final protocol to
be as detailed as possible such that any implementation problems can
be minimized for interoperability.
4.1.12.6. Recommendation
Since all the specifications are complete, it can be stated that the
mechanisms used in all protocols meet this objective in an equally
effective manner.
4.1.13. Vendor Independence
"A WTP vendor SHOULD be able to make modifications to hardware
without any WLAN controller vendor involvement."
4.1.13.1. CTP Evaluation
CTP does not assume any reliance on hardware architectures for WTPs
and ACs in its specifications.
4.1.13.2. LWAPP Evaluation
As LWAPP is fully specified, it is assumed that any WTP vendors can
create the actual implementation of the protocol on their hardware.
This allows them to make any necessary changes without the need to
involve any AC vendor.
4.1.13.3. SLAPP Evaluation
Since SLAPP satisfies the earlier objective, it also satisfies this
objective.
4.1.13.4. WiCoP Evaluation
WiCoP is a complete specification and does not require any additional
proprietary information to implement.
4.1.13.5. Analysis
Analysis is rather straightforward in this case. From the design of
the four protocols, they do not require a WTP vendor to involve an AC
vendor in making modifications to its own products.
Gwee Expires March 16, 2006 [Page 24]
Internet-Draft Comparative Analysis September 2005
4.1.13.6. Recommendation
Based on the above analysis, the mechanisms used in all the four
protocols fulfill this objective effectively.
4.1.14. Vendor Flexibility
"The CAPWAP protocol MUST NOT limit WTP vendors in their choice of
local-MAC or split-MAC WTPs. It MUST be compatible with both types
of WTPs."
4.1.14.1. CTP Evaluation
Based on implementation, CTP has been found to be operable without
knowledge of underlying vendor hardware.
4.1.14.2. LWAPP Evaluation
Based on implementation, LWAPP supports both Local and MAC approaches
and allows for third party WTP vendors to work with both approaches
without restriction.
4.1.14.3. SLAPP Evaluation
SLAPP provides support for both local MAC and split MAC architectures
along with their sub-modes. Assuming a common mode supported by both
the WTP and AC, the AC can select this mode for operation with WTP.
4.1.14.4. WiCoP Evaluation
WiCoP is a complete specification and does not require any additional
proprietary information to implement.
4.1.14.5. Analysis
Based on the above description, the mechanisms used in all the four
protocols are able to meet this objective.
4.1.14.6. Recommendation
The mechanisms used in all the four protocols are able to meet this
objective in an equally effective manner.
4.1.15. NAT Traversal
"The CAPWAP protocol MUST NOT prevent the operation of established
methods of NAT traversal."
Gwee Expires March 16, 2006 [Page 25]
Internet-Draft Comparative Analysis September 2005
4.1.15.1. CTP Evaluation
In CTP, an authentication mechanism is defined to establish a secure
connection without depending on MAC or IP address. CTP packets are
normally transported via UDP. As CTP is transported above the IP
layer, it will work properly through NAT devices. The WTP can be
statically configured to discover the AC through a NAT segment.
4.1.15.2. LWAPP Evaluation
LWAPP considers two situations in which it may be used in conjunction
with LWAPP. The first scenario is where a WTP is behind a NAT
system. The second scenario is where the AC sits behind a NAT. For
the first scenario, the LWAPP protocol can easily traverses NAT
systems since all communications is performed over IP using UDP. For
the second scenario, there will a few issues which requires user
intervention and predefined configuration to be done for NAT
compliance.
4.1.15.3. SLAPP Evaluation
SLAPP does not provide any specifications on this objective.
4.1.15.4. WiCoP Evaluation
WiCoP does not provide any specifications on this objective.
4.1.15.5. Analysis
The aim of this objective is to ensure that the CAPWAP protocol
operates above the layer at which a NAT device operates. In general,
the four proposals are specified to operate above the IP layer. So
their operations should not affected by NATs. There may be some
instances in which protocol implementations will need to be adapted,
e.g. in terms of AC/WTP identifications.
4.1.15.6. Recommendation
All the four protocols have been specified to operate above the IP
layer. It is therefore considered that their operations will not be
affected by NAT traversals. So all four protocols are equally
applicable for this objective.
4.2. Desirable Objectives
In this section, a comparison of the various protocols is made
against each CAPWAP Desirable Objective. A description of each
Desirable Objective and statements from the evaluation draft of each
Gwee Expires March 16, 2006 [Page 26]
Internet-Draft Comparative Analysis September 2005
protocol are provided for reference. A final analysis is given at
the end of each objective.
4.2.1. Multiple Authentication Mechanisms
"The CAPWAP protocol MUST support different authentication mechanisms
in addition to IEEE 802.11i."
4.2.1.1. CTP Evaluation
CTP is wireless terminal agnostic and as the PMK key exchange is
generic, it does not prevent the operation of any other
authentication mechanisms.
4.2.1.2. LWAPP Evaluation
LWAPP allows for a separate security policy for every WLAN created.
The Encryption Policy field of the Add WLAN message element defines
static and dynamic WEP encryption, as well as TKIP and AES.
4.2.1.3. SLAPP Evaluation
SLAPP does not restrict the use of other authentication techniques
other than IEEE 802.11i. Typically different techniques are used on
separate SSIDs which can be based on one WTP.
4.2.1.4. WiCoP Evaluation
WiCoP does not prevent the operation of any authentication mechanism.
It is generic to support all types of authentication mechanisms.
4.2.1.5. Analysis
From the above description, all the four protocols provide some
support for use of different authentication techniques. However, it
is clear that LWAPP and SLAPP provide support for multiple
authentications in a more effective manner. The use of SSIDs in
determining the type of security policy used can help in ensuring a
standardized form of security measure for each logical network. This
helps to reduce implementation issues.
4.2.1.6. Recommendation
Based on the above analysis, the mechanisms used in both SLAPP and
LWAPP are the better candidates among the four to fulfill this
objective effectively.
Gwee Expires March 16, 2006 [Page 27]
Internet-Draft Comparative Analysis September 2005
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. CTP Evaluation
CTP specification considers other layer 2 wireless technologies in
its capabilities exchange phase. In the event that there are layer 2
wireless specific elements that need to be added, those can be easily
supported by extensions to the protocol.
4.2.2.2. LWAPP Evaluation
LWAPP specification describes the process that must be followed in
order to define a wireless technology binding for LWAPP. It also
defines the IEEE 802.11 binding in its specification for this
objective.
4.2.2.3. SLAPP Evaluation
SLAPP supports this objective by providing a mechanism to negotiate a
technology specific control protocol in its framework.
4.2.2.4. WiCoP Evaluation
WiCoP is generic and extensible to support future developments in
wireless technologies.
4.2.2.5. Analysis
Based on the specifications of the four protocols, it is clear that
these protocols do consider the possible use of other layer 2
wireless technologies in their design. Although LWAPP provides some
definition of the process of binding a wireless technology to the
protocol, it mainly describes the IEEE 802.11 binding in the rest of
the specifications. It will be best if more information can be
provided in the form of a generic technology binding process
framework. On the other hand, SLAPP does provide an excellent
framework that helps to extend its use to other future wireless
technologies. Its unique protocol design helps in providing some
form of modularity in the area of wireless technology used and thus
protocol redesign, if required, is restricted mainly to the
technology-dependent component only.
Gwee Expires March 16, 2006 [Page 28]
Internet-Draft Comparative Analysis September 2005
4.2.2.6. Recommendation
Although all the four protocols meet this objective, the mechanism
used in SLAPP does have an advantage over the rest by virtue of its
framework. In the event of protocol redesign or extension required
to accommodate any future development, only the technology-dependent
component is affected.
4.2.3. Support for New IEEE Requirements
"The CAPWAP protocol MUST be openly designed to support new IEEE
802.11 definitions and extensions."
4.2.3.1. CTP Evaluation
CTP defines an abstraction layer to accommodate any type of wireless
MAC technology. New IEEE 802.11 amendments can be easily
accommodated by the protocol although more work is required to
interpret the impact of the amendment on both the AC and the WTP.
4.2.3.2. LWAPP Evaluation
The LWAPP protocol was designed to be able to accommodate new IEEE
extensions defined, although it is possible that some future
extensions will require some additional IETF CAPWAP standardization
work.
4.2.3.3. SLAPP Evaluation
SLAPP defines a raw IEEE 802.11 frame support that allows any IEEE
802.11 frame to be transmitted to the AC, regardless of architecture.
Should there be a new IEEE 802.11 amendment that requires fundamental
changes to the current model, an additional technology dependent
protocol can be defined and negotiated between AC and WTP.
4.2.3.4. WiCoP Evaluation
WiCoP is generic and extensible to support future developments in
wireless technologies and standards.
4.2.3.5. Analysis
Based on the specifications of the four protocols, all the protocols
provide support for new IEEE 802.11 definitions. Among them, SLAPP
provides a favourable scheme to implement the addition of new IEEE
802.11 amendments easily. By virtue of its framework, it can retain
much of its technology independent component and add just a new
control protocol to include the new definition in its operation.
Gwee Expires March 16, 2006 [Page 29]
Internet-Draft Comparative Analysis September 2005
4.2.3.6. Recommendation
Based on the above analysis, the mechanism used in SLAPP has an
advantage over the rest in meeting this objective effectively.
4.2.4. Interconnection Objective
"The CAPWAP protocol MUST NOT be constrained to specific underlying
transport mechanisms."
4.2.4.1. CTP Evaluation
CTP is independent to the transport technology as it makes use of UDP
to transmit its packet.
4.2.4.2. LWAPP Evaluation
LWAPP packets are transported using UDP or Ethernet as transports.
Support for transport capabilities has been included within the LWAPP
protocol itself. Thus, it is expected that LWAPP is sufficiently
independent of the transport protocol used.
4.2.4.3. SLAPP Evaluation
SLAPP makes use of IPv4 to transport its packets and thus its
operation is independent of the L2 interconnection technologies. It
is expected that SLAPP will work over IPv6 as well.
4.2.4.4. WiCoP 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.5. Analysis
By virtue of their protocol design, the four protocols are not
constrained to specific underlying transport mechanisms.
4.2.4.6. Recommendation
From the specifications given, the mechanisms used in all the
protocol proposals are able to meet this objective in an equally
effective manner.
4.2.5. Access Control
"The CAPWAP protocol MUST be capable of exchanging information
Gwee Expires March 16, 2006 [Page 30]
Internet-Draft Comparative Analysis September 2005
required for access control of WTPs and wireless terminals."
4.2.5.1. CTP Evaluation
CTP defines connection, disconnection and authentication messages
that control the access of wireless terminals. Furthermore, during
the registration phase, the WTP have to provide an AP-ID field for
verification by the AC. This identification mechanism can be
considered as a means of access control of the WTP.
4.2.5.2. LWAPP Evaluation
As LWAPP tunnels 802.11 MAC management frames to the AC, the AC has
complete control over the behaviour of the network. In addition, an
AC performs authorization of WTPs before connection for security
reasons.
4.2.5.3. SLAPP Evaluation
As SLAPP supports multiple WTP authentication models, it allows the
AC to have full control over restricting WTPs based on the access
control policies. The access control functions for wireless
terminals consist of several components. For example, the
cryptographic and associated authentication requirements can be
configured per-logical group, which can be used to control access to
specific logical groups. Additional access control policies may be
enforced at the AC if tunneling of frames is required to the AC.
4.2.5.4. WiCoP Evaluation
WiCoP uses the Terminal Data message element to exchange association
and authentication information on wireless terminals. This is used
by the AC to supervise access control.
4.2.5.5. Analysis
Based on the above descriptions, the mechanisms used in all four
proposed protocols are able to meet this objective.
4.2.5.6. Recommendation
The mechanisms used in all four protocols are able to meet this
objective equally well.
Gwee Expires March 16, 2006 [Page 31]
Internet-Draft Comparative Analysis September 2005
5. Comparative Analysis
As mentioned in the introduction, this document contains a
comparative analysis of the four protocols. From all the analysis of
the various protocols for each objective, every protocol has its own
unique strengths in meeting the objectives. Ideally, the final
CAPWAP protocol should have a combination of all the best strengths
of the various protocols. The table below lists the various
protocols and their best strengths in meeting the CAPWAP objectives.
Gwee Expires March 16, 2006 [Page 32]
Internet-Draft Comparative Analysis September 2005
CAPWAP Objectives Recommended Protocol Mechanisms
Logical Groups WiCoP
Support for Traffic Separation LWAPP/SLAPP
Wireless Terminal Transparency All
Configuration Consistency LWAPP/CTP
Firmware Trigger WiCoP
Monitor System WiCoP
Resource Control LWAPP
Protocol Security SLAPP
System Security SLAPP
802.11i Considerations WiCoP
Interoperability WiCoP
Product Specifications All
Vendor Independence All
Vendor Flexibility All
NAT Traversal All
Multiple Authentication SLAPP/LWAPP
Future Wireless SLAPP
New IEEE Requirements SLAPP
Interconnection All
Access Control All
Table 1: Recommended mechanisms for CAPWAP Objectives
Thus it can be inferred that the ideal CAPWAP protocol should have a
combination of the best mechanisms from the various proposals. For
example, WiCoP has advantage for logical group objective while LWAPP
has advantage for resource control objective. Thus the final CAPWAP
Gwee Expires March 16, 2006 [Page 33]
Internet-Draft Comparative Analysis September 2005
protocol should make use of WiCoP's strength and combine it with
LWAPP's strength.
Gwee Expires March 16, 2006 [Page 34]
Internet-Draft Comparative Analysis September 2005
6. Conclusion
In conclusion, a comparative evaluation of the various proposed
protocols has been provided. Recommendations have been given on the
various strengths of the protocols. The final CAPWAP protocol should
contain a combination of these strengths. To do this, one suggestion
is to combine the mechanisms involved in these strengths into the
final CAPWAP protocol. However, this may involve some redesigning
work and careful analysis of the impact and interaction among these
mechanisms.
Gwee Expires March 16, 2006 [Page 35]
Internet-Draft Comparative Analysis September 2005
7. Security Considerations
Security aspects have been discussed in the four proposals.
Realizing the recommendations made in this document should not affect
the security considerations previously accounted for in the four
proposals. In addition, there should be no introduction of new
security threats due to realization of recommendations in this
document.
8. 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-03 (work in progress),
June 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-02 (work in progress), June 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.ohara-capwap-lwapp]
Calhoun, P., "Light Weight Access Point Protocol",
draft-ohara-capwap-lwapp-03 (work in progress), July 2005.
[I-D.singh-capwap-ctp]
Singh, I., "CAPWAP Tunneling Protocol (CTP)",
draft-singh-capwap-ctp-02 (work in progress), July 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Gwee Expires March 16, 2006 [Page 36]
Internet-Draft Comparative Analysis September 2005
Author's Address
Richard Choon Lim Gwee
Republic Polytechnic
Tanglin Campus
1, Kay Siang Road
Singapore 248922
Singapore
Phone: +65 6419 6244
Email: richard.gwee@rp.edu.sg
Gwee Expires March 16, 2006 [Page 37]
Internet-Draft Comparative Analysis September 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.
Gwee Expires March 16, 2006 [Page 38]
