[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/