Internet DRAFT - draft-narasimhan-capwap-slapp-evaluation
draft-narasimhan-capwap-slapp-evaluation
CAPWAP Working Group P. Narasimhan
Internet-Draft Aruba Networks
Expires: December 8, 2005 D. Harkins
Trapeze Networks
S. Ponnuswamy
Aruba Networks
S. Hares
NextHop
June 6, 2005
SLAPP Evaluation
draft-narasimhan-capwap-slapp-evaluation-00
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 December 8, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The CAPWAP Working Group (WG) is currently looking into defining a
protocol that would enable interoperability in an IEEE 802.11 based
wireless local area network (WLAN) comprised of Wireless Termination
Narasimhan, et al. Expires December 8, 2005 [Page 1]
Internet-Draft SLAPP Evaluation June 2005
Points (WTP) and Access Controllers (AC) belonging to different
vendors.
This document presents a self-review of Simple Light Access Point
Protocol (SLAPP), one of the candidate protocol proposals submitted
to the CAPWAP WG for consideration as a CAPWAP protocol. The WG has
requested that the authors of all candidate proposals to provide a
document which evaluates how their submission meets the objectives,
taxonomy, and problem statement.
Narasimhan, et al. Expires December 8, 2005 [Page 2]
Internet-Draft SLAPP Evaluation June 2005
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Conventions used in this document . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 SLAPP Highlights . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Extensible Architecture . . . . . . . . . . . . . . . 4
2.1.2 Reuse Existing Standards and Protocols . . . . . . . . 5
2.1.3 Simple Control Protocol for 802.11 . . . . . . . . . . 5
3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Mandatory Objectives . . . . . . . . . . . . . . . . . . . 6
3.1.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Support for Traffic Separation . . . . . . . . . . . . 7
3.1.3 Wireless Terminal Transparency . . . . . . . . . . . . 7
3.1.4 Configuration Consistency . . . . . . . . . . . . . . 8
3.1.5 Firmware Trigger . . . . . . . . . . . . . . . . . . . 9
3.1.6 Monitoring and Exchange of System-Wide Resource
State . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.7 Resource Control Objective . . . . . . . . . . . . . . 11
3.1.8 CAPWAP Protocol Security . . . . . . . . . . . . . . . 12
3.1.9 System-Wide Security . . . . . . . . . . . . . . . . . 13
3.1.10 802.11i Considerations . . . . . . . . . . . . . . . 14
3.1.11 Interoperability Objective . . . . . . . . . . . . . 15
3.1.12 Protocol Specifications . . . . . . . . . . . . . . 15
3.1.13 Vendor Independence . . . . . . . . . . . . . . . . 16
3.1.14 Vendor Flexibility . . . . . . . . . . . . . . . . . 16
3.2 Desirable Objectives . . . . . . . . . . . . . . . . . . . 17
3.2.1 Multiple Authentication Mechanisms . . . . . . . . . . 17
3.2.2 Support for Future Technologies . . . . . . . . . . . 17
3.2.3 Support for New IEEE Requirements . . . . . . . . . . 18
3.2.4 Interconnection Objective . . . . . . . . . . . . . . 19
3.2.5 WTP Access Control . . . . . . . . . . . . . . . . . . 19
3.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 20
3.3.1 Support for Non-CAPWAP WTPs . . . . . . . . . . . . . 20
3.4 Operator Requirements . . . . . . . . . . . . . . . . . . 20
3.4.1 AP Fast Handoff . . . . . . . . . . . . . . . . . . . 20
3.5 Compliance table . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . 22
5. IANA considerations . . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . 25
Narasimhan, et al. Expires December 8, 2005 [Page 3]
Internet-Draft SLAPP Evaluation June 2005
1. Definitions
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
2. Introduction
The IETF CAPWAP Working Group is working towards defining a protocol
aimed at addressing the interoperability between IEEE 802.11 Wireless
Termination Points (WTP) and Access Controllers (AC) belonging to
different vendors as stated in the CAPWAP problem statement [4]. The
CAPWAP architecture taxonomy document [3] documents the multiple
architectural choices present in the industry based on inputs from
WLAN vendors and others.
The CAPWAP objectives draft [7] documents the list of requirements
that a CAPWAP protocol must satisfy in order to enable multi-vendor
interoperability between WTPs and ACs. The CAPWAP WG invited
proposals for a candidate CAPWAP protocol and requested that the
authors of each candidate proposal submit another draft evaluating
their submission against the requirements in the CAPWAP objectives
draft [7].
The SLAPP protocol draft [2] was submitted to the CAPWAP WG for
consideration as a candidate proposal for a CAPWAP protocol. This
document is a self-evaluation by the authors of the SLAPP draft of
their submission.
2.1 SLAPP Highlights
The highlights of the SLAPP protocol draft as presented below.
2.1.1 Extensible Architecture
SLAPP provides a solution to the CAPWAP problem that is explicitly
separated into two components - a technology-independent component to
enable a WTP to discover and authenticate an AC, and to negotiate a
technology-dependent control protocol during the discovery phase.
This decoupling of the technology-dependent components from the
technology-independent base provides us with extensibility to other
technologies as they mature without having to explicitly build it in
today.
The interoperability issues within WLANs using IEEE 802.11 are
reasonably well understood today. So the CAPWAP WG can focus on
Narasimhan, et al. Expires December 8, 2005 [Page 4]
Internet-Draft SLAPP Evaluation June 2005
solving these issues of today while not worrying about similar issues
facing technologies that could mature in the future.
The base SLAPP protocol is also useful for secure discovery and
authentication for more generic applications, including non-wireless
ones, that require a central controller to control and manage one or
more network elements from a different vendor. For example, the base
SLAPP protocol could be used for secure discovery and authentication
in SLRRP [12].
2.1.2 Reuse Existing Standards and Protocols
The authors of the SLAPP draft strongly believe that a CAPWAP
protocol should use existing methods, wherever such methods are
readily available, without re-inventing the wheel on what are major
components of a 802.11 control protocol. As a result of this, SLAPP
inherits the benefits of public reviews and implementations of these
existing methods over a period of time enhancing the robustness of
the protocol and the reusability of existing implementations.
For example, the security component of SLAPP uses DTLS [8], which is
a connection-less (datagram) version of the TLS protocol [9] whose
security has been reviewed by competent and professional
cryptographers and is believed to be secure [11]. DTLS, as TLS, can
operate over IPv4 or IPv6. The myriad of authentication options in
DTLS allows for a wide array of options with which to secure the
channel between the WTP and the AC -- mutual or certificate based,
symmetric, asymmetric, or non-mutual, anonymous, etc. Using DTLS
lessens the need for the CAPWAP WG to go through additional reviews
of the security aspects of the protocol, thus speeding up the work of
the WG.
For the tunneling of frames between a WTP and an AC, SLAPP uses
Generic Routing Encapsulation (GRE) [5] which has been extensively
deployed. This removes the need to define a new tunneling mechanism
for a CAPWAP protocol.
Both TLS and GRE have been used extensively over the last decade or
so. Given the tight schedule that the CAPWAP WG is operating under,
sparing the group the additional chore of reviews on security and
tunneling mechanisms is a highly desirable goal. The authors of the
SLAPP draft believe that their submission achieves this goal.
2.1.3 Simple Control Protocol for 802.11
The SLAPP control protocol for 802.11 defines a simple state machine
and a list of operating modes that have been chosen based on the
architectural choices prevalent in the market place today. The
Narasimhan, et al. Expires December 8, 2005 [Page 5]
Internet-Draft SLAPP Evaluation June 2005
control protocol closely aligns itself with the specifications
present in the IEEE 802.11 standard while avoiding extraneous
operating modes not currently defined by 802.11.
The SLAPP proposal reflects the collective experience of the authors
in deploying large WLANs covering all the architectural variants
described in the submission.
3. Objectives
SLAPP is a simple light-weight protocol that supports communication
between Wireless Termination Points and Access Controllers. The
communication between the Wireless Termination points and the Access
Controllers occurs over a DTLS connection.
3.1 Mandatory Objectives
This section contains all of the objectives that have been considered
as being mandatory in order for a protocol to be consider.
3.1.1 Logical Groups
Classification: Architecture
3.1.1.1 Protocol Requirement
"WLAN deployment trends require CAPWAP protocol to be capable of
controlling and managing physical WTPS in terms of logical groups."
This is being interpreted as stating that a protocol must allow for
the WTP to provide service for multiple SSIDs (or WLANs), each with a
distinct BSSID.
3.1.1.2 Protocol Evaluation
In SLAPP, the WTPs may support one or more BSSIDS. The WTPs indicate
the number of BSSIDs supported to the AC using a specific message
(Section 6.1.3.1.12). This in turn defines the number of logical
groups supported by that specific WTP. The AC may choose to
configure any number of logical groups per WTP, subject to the
maximum number indicated by the WTPs. The BSSID index element
defined in SLAPP (Section 6.1.3.1.13) is used to configure all BSSID-
specific parameters. The WTPs may use the same element to convey
BSSID-specific status to the AC.
The SLAPP protocol allows the AC to create a logical group by
defining a WLAN with a specific BSSID, ESSID and associated
parameters. Each logical group can have a separate set of security
Narasimhan, et al. Expires December 8, 2005 [Page 6]
Internet-Draft SLAPP Evaluation June 2005
policies, QoS policies and any other policies that can be defined
using the configuration parameters specified in Section 6.1.3.2.6 of
the SLAPP draft. The data between AC and WTP or between an 802.11
STA and WTP can also be identified per logical group, based on the
BSSID and associated identifiers.
3.1.1.3 Compliance
SLAPP satisfies this requirement.
3.1.2 Support for Traffic Separation
Classification: Operations
3.1.2.1 Protocol Requirement
"In order to maintain the separation of control and data traffic, the
CAPWAP protocol is required to define control messages such that they
do not involve piggybacking or other combination with data traffic."
This requirement specifies that a strict separation between control
and data traffic must be established and maintained and that it is
not possible to mix the two or somehow carry traffic for one in the
other.
3.1.2.2 Protocol Evaluation
SLAPP has an 802.11 Control Protocol as an option decided upon during
WTP and AC discovery. This protocol has two components, one for
sending control and provisioning messages between the WTP and AC, and
another for tunneling data traffic between the WTP and AC.
Control traffic has its own SLAPP Control Protocol header and is sent
as UDP traffic to the AC. Data traffic is tunneled via GRE. Control
and data are uniquely identified and separation between the two is
maintained by SLAPP. It is not possible to send a data frame as a
Control message and vice versa.
3.1.2.3 Compliance
SLAPP satisfies this requirement.
3.1.3 Wireless Terminal Transparency
Classification: Operations
Narasimhan, et al. Expires December 8, 2005 [Page 7]
Internet-Draft SLAPP Evaluation June 2005
3.1.3.1 Protocol Requirement
"Wireless Terminals should not be required to recognize or be aware
of the CAPWAP protocol."
The use of SLAPP between the WTPs and ACs should be transparent to
the 802.11 stations.
3.1.3.2 Protocol Evaluation
SLAPP is a protocol defined between ACs and WTPs that enable an AC to
configure and manage one or more WTPs. SLAPP messages are addressed
between ACs and WTPs. They do not extend to the 802.11 wireless link
and hence are transparent to the 802.11 stations. Once a BSS is
configured by an AC on a WTP, the 802.11 stations do not see a
difference between an WTP managed using SLAPP (using any of the
CAPWAP modes defined in Section 6.1.3 of the SLAPP draft) and an
autonomous WTP (as defined in the CAPWAP architecture taxonomy
document [3]).
3.1.3.3 Compliance
SLAPP satisfies this requirement.
3.1.4 Configuration Consistency
Classification: Operations
3.1.4.1 Protocol Requirement
"The CAPWAP protocol must allow for regular exchange of state
information between WTPs and WLAN controller. Examples of State
information include WTP processing load and memory utilization."
Our interpretation of this requirement is that the CAPWAP protocol
must support a mechanism to transport WTP capability information so
that an AC can make consistent configuration decisions for the WTPs
under its control. In addition, we interpret that the WTP must be
capable of sending periodic status information to the AC so that the
AC can perform dynamic and run-time re-configuration to optimize the
overall WLAN performance.
We also enhanced this understanding to allow different configurations
based on the type of sub-protocol.
3.1.4.2 Protocol Evaluation
SLAPP requires that the WTPs communicate their capabilities during
Narasimhan, et al. Expires December 8, 2005 [Page 8]
Internet-Draft SLAPP Evaluation June 2005
the initialization process. The capability of a WTP may be limited
by the regulatory domain as well as by the WTP hardware and software.
The capability exchange mechanism allows AC to have a consistent
picture of the capabilities of the WTPs.
After the capability exchange, the AC is responsible for sending
configuration information to the WTPs. Some configuration parameters
have default values and need not be explicitly configured. The
defaults can be overridden by the AC with an explicit configuration
message. SLAPP also defines a set of mandatory configuration
parameters that MUST be explicitly configured by an AC for the WLAN
to be operational. This ensures consistency across WTPs, where
certain parameters have to be configured and optimized globally
(across WTPs).
The event mechanism defined in SLAPP (6.1.3.1.27) allows the AC to
configure events at the WTP with different importance levels.
Specific events such as radar detection and excessive retry and a
generic 802.11 management and action event are currently defined in
SLAPP. Additional events can be easily added. The event mechanism
provides the AC with instantaneous report of specific events so that
the AC can make corrective actions if necessary.
The WTP statistics and status may be obtained by an AC at any time by
sending a request to the WTP. If desired, the AC may periodically
send statistics or status requests such as those related to load
(e.g., transmit, receive and association statistics) and
instantaneous status such as Noise Floor. The AC may also configure
the WTP to generate an event for Noise Floor, when the Noise Floor
exceeds a specific value.
The capability, configuration, statistics, status and event
mechanisms defined in SLAPP are fully extensible and additional
elements can be easily added, if desired, as the IEEE standards
evolve.
3.1.4.3 Compliance
SLAPP satisfies this requirement.
3.1.5 Firmware Trigger
Classification: Operations
Protocol Evaluation: The CAPWAP protocol must support a trigger for
delivery of firmware updates.
Narasimhan, et al. Expires December 8, 2005 [Page 9]
Internet-Draft SLAPP Evaluation June 2005
3.1.5.1 Protocol Evaluation
SLAPP has an firmware download mechanism defined in the form of an
Image Download protocol. The image download process uses the
security context negotiated between an AC and a WTP using DTLS.
Other mechanisms such as TFTP would be outside the context of the
DTLS session and hence would not be secure for downloading firmware
to the WTPs.
During SLAPP discovery phase, a WTP identifies its hardware and
current software version numbers. If the AC determines that a new
image is available for this WTP, then it selects the Image Download
protocol so that the new version of the firmware can be transferred
to the WTP.
The authors of the SLAPP draft recognize that a simpler trigger is
possible to include in the 802.11 control protocol state machine to
initiate the image download protocol. This will be added in the next
version of the SLAPP draft to fully satisfy the requirement.
3.1.5.2 Compliance
SLAPP partially satisfies this requirement
3.1.6 Monitoring and Exchange of System-Wide Resource State
Classification: Operations
3.1.6.1 Protocol Requirement
"The CAPWAP protocol must allow for the exchange of statistics,
congestion and other WLAN state information."
Our interpretation of this requirement includes statistics for any
type of media define: 802.11, 802.15, or 802.16.
3.1.6.2 Protocol Evaluation
The SLAPP protocol defines a set of capability, configuration,
statistics, status and event elements that can be used to monitor and
exchange the system-wide resource state. SLAPP supports an extensive
set of statistics (6.1.3.1.30, 6.1.3.1.31, 6.1.3.1.32, and
6.1.3.1.33) that can be used by the AC to request specific class of
statistics. In addition to the aggregate statistics, the status
(6.1.3.1.34) element defined in SLAPP can be used to obtain the
instantaneous status.
The event mechanism (See 6.1.3.1.35-39) defined in SLAPP allows the
Narasimhan, et al. Expires December 8, 2005 [Page 10]
Internet-Draft SLAPP Evaluation June 2005
AC to configure specific events at the WTP for notification. The AC
may choose to re-configure or re-adjust system-wide parameters based
on statistics, status or events received from a WTP, using one of the
configuration elements. Additional capability, configuration,
statistics, status or event elements can be easily added to the SLAPP
protocol, if required.
3.1.6.3 Compliance
SLAPP satisfies this requirement.
3.1.7 Resource Control Objective
Classification: Operations
3.1.7.1 Protocol Requirement
"The CAPWAP protocol must maintain IEEE 802.11e mappings across the
switching and the wireless segment."
802.11e is one of the first wireless standards to support QoS. While
802.16 supports QoS over wireless, we also anticipate other emerging
standards such as 802.15x and 802.20 to have specific QoS
requirements. We interpret this objective as allowing all sub-
protocols to handle QoS information. In addition, this objective
requires the protocol to support emerging 802.11x standards such as
802.11k, 802.11v and 802.11u. While 802.11k is well-defined, both
802.11v and 802.11u are at early stages of standards development.
3.1.7.2 Protocol Evaluation
The SLAPP protocol defines the capability element that is used by the
WTP to indicate its support for various 802.11 standards extensions.
For example, the 802.11e and WiFi Alliance defined interoperability
subsets of 802.11e such as WMM, WMM-SA and U-APSD are leveraged using
indications in the element (6.1.3.1.10). The future standards such
as 802.11k and 802.11v may be added to this element as and when they
are available and supported by the WTPs.
The IEEE 802.11e element (6.1.3.1.29) defines a mechanism for the AC
to configure these functions at the WTP, if they are supported. The
internal parameters of the 802.11e functions such as the window size,
back-off and AIFS are well defined in the standard (e.g., IEEE
802.11e, WMM and WMM-SA). An WTP claiming a specific 802.11e
capability is expected to implement the same as specified in the
standard or specification.
The transmit and receive frame statistics can also be specified per
Narasimhan, et al. Expires December 8, 2005 [Page 11]
Internet-Draft SLAPP Evaluation June 2005
Access Category, if the WTP is 802.11e capable. The WMM
specification also defines the mapping between 802.11e traffic
identifier/access category and DSCP or 802.1d tags. The AC and WTP
are expected to follow these standard mappings to enforce QoS over
the wired and wireless links. If overriding of these default or
standard behaviors is desired by CAPWAP working group, the existing
SLAPP configuration elements can be modified to support these
functions.
For 802.11k and other emerging IEEE 802.11 amendments such as 802.11v
and 802.11u, the raw 802.11 frame option (6.1.3.1.39) defined in
SLAPP can be used to forward any 802.11 frame such as a management
frame or action frame to the AC. This allows SLAPP to support future
802.11 extensions, without having to re-define existing elements.
However, the capability, configuration, statistics, status and event
elements can be easily extend future IEEE 802.11 amendments.
3.1.7.3 Compliance
SLAPP satisfies this requirement.
3.1.8 CAPWAP Protocol Security
Classification: Security
3.1.8.1 Protocol Requirement
"The CAPWAP protocol must support mutual authentication of WTPs and
the centralized controller. It must also ensure that information
exchanges between them are secured."
This requirement specifies a minimum support for security. The key
exchange and authentication protocol must support authentication of
the AC to the WTP and of the WTP to the AC. The resulting key(s)
must be used to secure messages sent between the two. Implied in
this requirement is that it is not possible for a third party to
forge SLAPP messages between the authenticated AC and WTP nor is it
possible to replay valid messages sent between the AC and WTP.
3.1.8.2 Protocol Evaluation
SLAPP uses DTLS for authentication, key management, and bulk data
protection. The DTLS protocol provides for mutual authentication as
well as asymmetric authentication. Keys are derived from the DTLS
exchange and are used to protect bulk data, in this case SLAPP
messages. DTLS provides data integrity protection, confidentiality,
and anti-replay protection to SLAPP messages.
Narasimhan, et al. Expires December 8, 2005 [Page 12]
Internet-Draft SLAPP Evaluation June 2005
DTLS is a connection-less (datagram) version of the TLS protocol
whose security has been reviewed by competent and professional
cryptographers and is believed to be secure. Using DTLS lessens the
need for the CAPWAP WG to go through additional reviews of the
security aspects of the protocol.
3.1.8.3 Compliance
SLAPP satisfies this requirement.
3.1.9 System-Wide Security
Classification: Security
3.1.9.1 Protocol Requirement
"The design of the CAPWAP protocol should not allow for any
compromises to the WLAN system by external entities."
This requirement generally states that the CAPWAP protocol should not
introduce any new points of attack for a network.
3.1.9.2 Protocol Evaluation
SLAPP uses DTLS to protect its communication. There are no known
ways to forge, alter, or replay SLAPP messages protected by DTLS.
The SLAPP protocol does not introduce any new vulnerabilities to a
system.
The Security Considerations of SLAPP note that state is created on
the AC upon receipt of Discovery Requests from a WTP. SLAPP
recommends a technique to prevent a denial of service attacks from
being launched because of this. Other techniques to foil such an
attack are possible but SLAPP does recommend one.
From a system-wide perspective though SLAPP is only as secure as the
system that speaks it.
This section of in CAPWAP Objectives memo mentions PMK sharing and
that rogue clients should not be able to take advantage of a shared
PMK (how that could happen is not mentioned). With SLAPP the PMK
resides on the authenticator. There is no defined message to allow
the PMK to be sent to any other entity. Therefore SLAPP does not
provide for a way to share a PMK.
3.1.9.3 Compliance
SLAPP satisfies this requirement.
Narasimhan, et al. Expires December 8, 2005 [Page 13]
Internet-Draft SLAPP Evaluation June 2005
3.1.10 802.11i Considerations
Classification: Security
3.1.10.1 Protocol Requirement
"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.
This requirement highlights the fact that different architectures
were defined in the CAPWAP taxonomy memo and that major components of
a WLAN architecture can reside in different places. It is necessary
for SLAPP to allow an AC and WTP to identify their capabilities and
come to an agreement on where architectural components-- e.g. the
802.11i authenticator and 802.11i data encryption/decryption points--
will reside once the WTP is controlled and provisioned by the AC.
3.1.10.2 Protocol Evaluation
As noted in section 6.1.1 of the SLAPP memo both local MAC and split
MAC architectures are supported. These are further refined in SLAPP
to allow for a bridged and tunneled version of the local MAC
architecture, and a distinction between L2 crypto being handled at
the WTP versus L2 crypto being handled at the AC for the split MAC
architecture.
During the registration phase of SLAPP the WTP and AC agree on what
architecture and what specific refinement of that architecture will
be provisioned.
SLAPP provides for tunneling encrypted 802.11 frames to the AC when
L2 crypto is performed at the AC. It also provides the ability to
tunnel decrypted 802.3 frames when L2 crypto is performed at the WTP.
When the 802.1x authenticator is located on the AC and L2 crypto is
performed by the WTP, it is necessary for the AC to send PTKs and
GTKs to the WTP. SLAPP includes a control message to do just that.
This message is, like all SLAPP control messages, protected by DTLS.
3.1.10.3 Compliance
SLAPP satisfies this requirement.
Narasimhan, et al. Expires December 8, 2005 [Page 14]
Internet-Draft SLAPP Evaluation June 2005
3.1.11 Interoperability Objective
Classification: General
3.1.11.1 Protocol Requirement
"The CAPWAP protocol must include sufficient capabilities
negotiations to distinguish between major types of WTPs."
3.1.11.2 Protocol Evaluation
SLAPP supports both the split-MAC and local-MAC architecture. The
protocol 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.
Even though there are more possibilities for splitting functions
between an AC and a WTP, the authors used market data and their own
experience in large WLAN deployments to narrow down the choices to 5
major CAPWAP modes.
During the SLAPP registration phase, a WTP announces its support for
one or more of the CAPWAP modes defined in SLAPP. If the set of
modes supported by the AC overlaps with the set announced by the WTP,
then the AC selects a CAPWAP mode that the AC and the WTP will
operate in. If these two sets do not intersect, then the AC rejects
the registration request from the WTP.
3.1.11.3 Compliance
SLAPP satisfies this requirement.
3.1.12 Protocol Specifications
Classification : General
3.1.12.1 Protocol Requirement
"Any WTP or AC vendor or any person can implement the CAPWAP protocol
from the specification itself and by that it is required that all
such implementations do interoperate."
3.1.12.2 Protocol Evaluation
SLAPP does not require any a priori exchange of technical information
between AC and WTP vendors. SLAPP requires that the individual
vendors simply implement the protocol. Interoperability is achieved
as long as the set of CAPWAP modes implemented by a WTP overlaps with
Narasimhan, et al. Expires December 8, 2005 [Page 15]
Internet-Draft SLAPP Evaluation June 2005
the set supported by an AC. If the two sets do not overlap (i.e., a
WTP that only supports the split MAC modes attempts to register with
an AC that only supports the local MAC modes), then the AC will be
unable to configure and manage the WTP.
3.1.12.3 Compliance
SLAPP satisfies this requirement.
3.1.13 Vendor Independence
Classification: General
3.1.13.1 Protocol Requirement
"A WTP vendor can make modifications to hardware without any AC
vendor involvement."
The SLAPP authors feel that this requirement is already covered by
the requirement in Section 3.1.12 and is redundant. Any protocol
satisfies the "Vendor Independence" requirement if it satisfies the
"Protocol Specifications" requirement in Section 3.1.12.
3.1.13.2 Protocol Evaluation
Since SLAPP satisfies the requirement in Section 3.1.12, it also
satisfies the requirement in this section.
3.1.13.3 Compliance
SLAPP satisfies this requirement.
3.1.14 Vendor Flexibility
Classification: General
3.1.14.1 Protocol Requirement
"WTP Vendors must not be bound to a specific MAC."
This requirement is a bit ambiguous since the objectives draft [7]
states that the CAPWAP protocol should satisfy both local-MAC and
split-MAC architectures. First, this is already covered by the
requirement in Section 3.1.11. Second, if this is the motivation
behind this requirement then it is not clear if it is complete when
required only of the WTP.
Narasimhan, et al. Expires December 8, 2005 [Page 16]
Internet-Draft SLAPP Evaluation June 2005
3.1.14.2 Protocol Evaluation
SLAPP provides support for both local-MAC and split-MAC
architectures, including a short list of submodes for each of these
architectures. During the SLAPP registration phase, the WTP signals
its list of supported CAPWAP modes and the AC selects an operating
mode for the WTP assuming there is a common mode supported both by
the WTP and the AC.
3.1.14.3 Compliance
SLAPP satisfies this requirement.
3.2 Desirable Objectives
3.2.1 Multiple Authentication Mechanisms
Classification: Architecture
3.2.1.1 Protocol Requirement
"The CAPWAP protocol must support different authentication mechanisms
in addition to IEEE 802.11i."
This is a desired but not mandatory objective. This requirement
states that the CAPWAP protocol must be flexible in supporting not
only 802.11i but other existing techniques such as web
authentication.
3.2.1.2 Protocol Evaluation
SLAPP allows for but does not require 802.11i to be configured. It
does not constrain other authentication techniques from being
deployed. Typically this is done by using separate SSIDs to denote
the different techniques. SLAPP supports the configuration of
multiple SSIDs on a WTP. How a particular authentication is
performed-- MAC address lookup in a local database, directing a
client to a captive portal, etc-- is outside the scope of SLAPP.
3.2.1.3 Compliance
SLAPP satisfies this requirement.
3.2.2 Support for Future Technologies
Classification: Architecture
Narasimhan, et al. Expires December 8, 2005 [Page 17]
Internet-Draft SLAPP Evaluation June 2005
3.2.2.1 Protocol Requirement
"The 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 relation to 802.11."
3.2.2.2 Protocol Evaluation
SLAPP strongly supports this by providing a common technology-
independent framework that can be used to negotiate a control
protocol which may contain a technology dependent component (See
Figure 1 of the SLAPP draft). Since it is not practical to define a
control protocol that can be used with any future wireless
technology, the SLAPP framework provides a mechanism to negotiate a
technology specific control protocol after initial discovery.
3.2.2.3 Compliance
SLAPP satisfies this requirement.
3.2.3 Support for New IEEE Requirements
Classification: Architecture
3.2.3.1 Protocol Requirement
"The CAPWAP protocol must be openly designed to support new IEEE
extensions."
3.2.3.2 Protocol Evaluation
The raw 802.11 frame support defined in SLAPP (See 6.1.3.1.39) allows
any 802.11 frame (e.g., management, action or control) to be
transported to the AC, irrespective of the MAC split (i.e., local MAC
vs. split MAC). The authors believe that this simple mechanism
allows SLAPP to support all the IEEE 802.11 standards currently under
development, though many frame formats are not yet known.
In the event of a significantly different IEEE 802.11 amendment that
requires fundamental changes to the configuration and management
model, an additional technology dependent protocol (Figure 1 in the
SLAPP draft) can be defined and negotiated between AC and WTP.
3.2.3.3 Compliance
SLAPP satisfies this requirement.
Narasimhan, et al. Expires December 8, 2005 [Page 18]
Internet-Draft SLAPP Evaluation June 2005
3.2.4 Interconnection Objective
Classification: Architecture
3.2.4.1 Protocol Requirement
"The CAPWAP protocol must not be constrained to specific underlying
transport mechanisms."
3.2.4.2 Protocol Evaluation
SLAPP has been designed to operate over IPv4. It is independent of
the underlying L2 interconnection technologies as long as IPv4 is at
L3. The authors of the SLAPP draft believe that SLAPP will work over
IPv6 too, but they intend to update the draft to include an analysis
of SLAPP over IPv6 in the next version. TLS has been known to work
over IPv6 and, hence, DTLS will too.
The authors of the SLAPP draft did not see a need to define
mechanisms in the protocol to transport SLAPP control messages and
tunneled data frames over a L2 link.
3.2.4.3 Compliance
SLAPP satisfies this requirement.
3.2.5 WTP Access Control
Classification: Operations
3.2.5.1 Protocol Requirement
"The CAPWAP protocol must be capable of exchanging information
required for access control of WTPs and wireless terminals."
3.2.5.2 Protocol Evaluation
The SLAPP protocol supports multiple WTP authentication models as
described in Section 3.2.1.2. The AC has full control over
restricting WTPs that are capable of a specific type(s) of
authorization based on the defined access control policies at the AC.
The access control functions for the wireless terminal consist of
multiple components. The cryptographic and associated authentication
requirements can be configured per-logical group, which can be used
to control access to specific logical groups. The ESSID announcement
policy, as defined in the SLAPP draft, can also be used to restrict
association of wireless terminals by controlling beacons and probe
Narasimhan, et al. Expires December 8, 2005 [Page 19]
Internet-Draft SLAPP Evaluation June 2005
responses.
In addition, when the selected CAPWAP mode requires tunneling of
802.3 or 802.11 frames to the AC, additional access control policies
may be enforced at the AC per-wireless terminal.
3.2.5.3 Compliance
SLAPP satisfies this requirement.
3.3 Rejected Objectives
3.3.1 Support for Non-CAPWAP WTPs
Classification: Architectures
3.3.1.1 Protocol Requirement
"The CAPWAP protocol should be capable of recognizing legacy WTPs and
existing network management systems."
3.3.1.2 Protocol Evaluation
SLAPP includes an image download option and a control and
provisioning protocol. Using the image download option it is
possible for an image, which supports legacy or proprietary network
management systems, to be downloaded to a WTP. The WTP would boot
that image and communicate in the legacy or proprietary protocol with
the AC.
SLAPP's image download protocol uniquely qualifies it for support of
this requirement.
3.3.1.3 Compliance
SLAPP satisfies this requirement.
3.4 Operator Requirements
3.4.1 AP Fast Handoff
Classification: Operators
3.4.1.1 Protocol Requirement
"The CAPWAP protocol operations must not impede or obstruct the
efficiency of AP fast handoff procedures."
Narasimhan, et al. Expires December 8, 2005 [Page 20]
Internet-Draft SLAPP Evaluation June 2005
There is nothing in CAPWAP that governs AP fast handoffs. It is
desirable that CAPWAP not preclude it from happening or impose any
constraints on solutions that provide it.
3.4.1.2 Protocol Evaluation
SLAPP is a secure discovery and control protocol. There is nothing
in SLAPP that would impede or obstruct fast handoffs between APs.
Architectures in which the 802.1x authenticator resides on a central
controller - e.g. split MAC architectures - may be more conducive to
AP fast handoffs because they can take advantage of the PMK caching
support currently in 802.11i. While other architectures - e.g. local
MAC - may not be able to take advantage of this, it is not due to
SLAPP, it is due to the location of the 802.1x authenticator and the
prohibition of sharing a PMK among 802.1x authenticators.
The 802.11r task group is currently working on fast handoff
techniques. SLAPP is congruent with the requirement of,
architectures in, and the terminology used by 802.11r.
3.4.1.3 Compliance
SLAPP satisfies this requirement.
3.5 Compliance table
Compliance Rating
Logical Groups S
Support for Traffic Separation S
Wireless Terminal Transparency S
Configuration Consistency S
Firmware Trigger P
Monitoring and Exchange of
System-wide Resource state S
Resource Control objective S
IEEE 802.11i Considerations S
Interoperability Objective S
Protocol Specifications S
Vendor independence S
Vendor Flexibility S
Multiple Authentication Mechanisms S
Support for Future Wireless
Technologies S
Support for new IEEE Requirements S
Interconnection Objective S
Narasimhan, et al. Expires December 8, 2005 [Page 21]
Internet-Draft SLAPP Evaluation June 2005
Access Control S
Support for Non-CAPWAP WTPs S
AP Fast Handoff S
4. Security Considerations
This document simply lists how SLAPP protocol conforms to the
requirements listed in the CAPWAP objectives document. The SLAPP
specification utilizes the DTLS protocol.
5. IANA considerations
This document requires no action by IANA.
6. Acknowledgments
The authors wish to acknowledge the comments and input received from
Merwyn Andrade.
7. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
[2] "SLAPP : Simple Light Access Point Protocol", May 2005, <ftp://
ftp.ietf.org/internet-drafts/
draft-narasimhan-ietf-slapp-01.txt>.
[3] "Architecture Taxonomy for Control and Provisioning of Wireless
Access Points(CAPWAP)", August 2004, <ftp://ftp.isi.edu/
internet-drafts/draft-ietf-capwap-arch-06.txt>.
[4] "Configuration and Provisioning for Wireless Access Points
(CAPWAP) Problem Statement", February 2005,
<http://www.ietf.org/rfc/rfc3990.txt>.
[5] "Generic Routing Encapsulation", March 2000,
<http://www.ietf.org/rfc/rfc2784.txt>.
[6] "Requirements for Internet Hosts - Communication Layers",
October 1989, <http://www.ietf.org/rfc/rfc1122.txt>.
[7] Govindan, S., "Objectives for Control and Provisioning of
Wireless Access Points (CAPWAP)", November 2004, <http://
www.ietf.org/internet-drafts/
draft-ietf-capwap-objectives-00.txt>.
[8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Narasimhan, et al. Expires December 8, 2005 [Page 22]
Internet-Draft SLAPP Evaluation June 2005
Security", April 2004, <http://www.ietf.org/internet-drafts/
draft-rescorla-dtls-04.txt>.
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999,
<ftp://ftp.isi.edu/in-notes/rfc2246.txt>.
[10] Modadugu, N. and E. Rescorla, "The Design and Implementation of
Datagram TLS",
<http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>.
[11] Cheswick, W. and S. Bellovin, "Firewalls and Internet
Security".
[12] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader
Protocol", March 2005, <http://www.ietf.org/internet-drafts/
draft-krishna-slrrp-01.txt>.
Authors' Addresses
Partha Narasimhan
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
Phone: +1 408-480-4716
Email: partha@arubanetworks.com
Dan Harkins
Trapeze Networks
5753 W. Las Positas Blvd
Pleasanton, CA 94588
Phone: +1-925-474-2212
Email: dharkins@trpz.com
Subbu Ponnuswamy
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
Phone: +1 408-754-1213
Email: subbu@arubanetworks.com
Narasimhan, et al. Expires December 8, 2005 [Page 23]
Internet-Draft SLAPP Evaluation June 2005
Susan Hares
NextHop
825 Victors Way
Ann Arbor, MI 48108
Phone: +1 734 222 1610
Email: shares@nexthop.com
Narasimhan, et al. Expires December 8, 2005 [Page 24]
Internet-Draft SLAPP Evaluation June 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.
Narasimhan, et al. Expires December 8, 2005 [Page 25]
