tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 5413

Historic
Pages: 75
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~proto

SLAPP: Secure Light Access Point Protocol

Part 1 of 3, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Independent Submission                                     P. Narasimhan
Request for Comments: 5413                                    D. Harkins
Category: Historic                                         S. Ponnuswamy
ISSN: 2070-1721                                           Aruba Networks
                                                           February 2010


               SLAPP: Secure Light Access Point Protocol

Abstract

   The Control and Provisioning of Wireless Access Points (CAPWAP)
   problem statement describes a problem that needs to be addressed
   before a wireless LAN (WLAN) network designer can construct a
   solution composed of Wireless Termination Points (WTP) and Access
   Controllers (AC) from multiple, different vendors.  One of the
   primary goals is to find a solution that solves the interoperability
   between the two classes of devices (WTPs and ACs) that then enables
   an AC from one vendor to control and manage a WTP from another.

   In this document, we present a protocol that forms the common
   technology-independent framework and the ability to negotiate and
   add, on top of this framework, a control protocol that contains a
   technology-dependent component to arrive at a complete solution.  We
   have also presented two such control protocols -- an 802.11 Control
   protocol, and another, more generic image download protocol, in this
   document.

   Even though the text in this document is written to specifically
   address the problem stated in RFC 3990, the solution can be applied
   to any problem that has a controller (equivalent to the AC) managing
   one or more network elements (equivalent to the WTP).

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for the historical record.

   This document defines a Historic Document for the Internet community.
   This is a contribution to the RFC Series, independently of any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

Page 2 
   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5413.

IESG Note

   This RFC documents the SLAPP protocol as it was when submitted to the
   IETF as a basis for further work in the CAPWAP Working Group, and
   therefore it may resemble the CAPWAP protocol specification in RFC
   5415 as well as other IETF work.  This RFC is being published solely
   for the historical record.  The protocol described in this RFC has
   not been thoroughly reviewed and may contain errors and omissions.

   RFC 5415 documents the standards track solution for the CAPWAP
   Working Group and obsoletes any and all mechanisms defined in this
   RFC.  This RFC is not a candidate for any level of Internet Standard
   and should not be used as a basis for any sort of Internet
   deployment.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http//:trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
   2. Definitions .....................................................7
      2.1. Conventions Used in This Document ..........................7
   3. Topology ........................................................7
   4. Protocol ........................................................8
      4.1. Protocol Description .......................................8
           4.1.1. State Machine Explanation ...........................9
      4.2. Format of a SLAPP Header ..................................10
      4.3. Version ...................................................11
      4.4. Retransmission ............................................12
      4.5. Discovery .................................................12
           4.5.1. SLAPP Discover Request .............................13
           4.5.2. SLAPP Discover Response ............................15
      4.6. SLAPP Discovery Process ...................................17
           4.6.1. WTP ................................................17
           4.6.2. AC .................................................19
   5. Security Association ...........................................19
      5.1. Example Authentication Models (Informative) ...............20
           5.1.1. Mutual Authentication ..............................20
           5.1.2. WTP-Only Authentication ............................21
           5.1.3. Anonymous Authentication ...........................21
   6. SLAPP Control Protocols ........................................21
      6.1. 802.11 Control Protocol for SLAPP .........................21
           6.1.1. Supported CAPWAP Architectures .....................21
           6.1.2. Transport ..........................................24
           6.1.3. Provisioning and Configuration of WTP ..............26
           6.1.4. Protocol Operation .................................60
      6.2. Image Download Protocol ...................................66
           6.2.1. Image Download Packet ..............................66
           6.2.2. Image Download Request .............................67
           6.2.3. Image Download Process .............................68
           6.2.4. Image Download State Machine .......................69
   7. Security Considerations ........................................73
   8. Extensibility to Other Technologies ............................73
   9. Informative References .........................................74

Top      ToC       Page 4 
1.  Introduction

   The need for a protocol by which wireless LAN (WLAN) Access
   Controllers (ACs) can control and manage Wireless Termination Points
   (WTPs) from a different vendor has been presented in the CAPWAP
   problem statement [3].  We believe that this problem is more general
   than as stated in [3] and can be found in any application, including
   non-wireless ones, that requires a central controller to control and
   manage one or more network elements from a different vendor.

   One way to solve the CAPWAP problem is to define a complete control
   protocol that enables an AC from one vendor to control and manage a
   WTP from a different vendor.  But a solution that is primarily
   focused towards solving the problem for one particular underlying
   technology (IEEE 802.11, in this case) may find it difficult to
   address other underlying technologies.  Different underlying
   technologies may differ on the set of configurable options, and
   different architectural choices that are specific to that underlying
   technology (similar to the Local Medium Access Control (MAC) versus
   Split MAC architectures in 802.11).  The architectural choices that
   are good for one underlying technology may not necessarily work for
   another.  Not to forget that there may be multiple architectural
   choices [2] even for the same underlying technology.  A monolithic
   control protocol that strives to solve this problem for multiple
   technologies runs the risk of adding too much complexity and not
   realizing the desired goals, or it runs the risk of being too rigid
   and hampering technological innovation.

   A different way to solve this problem is to split the solution space
   into two components -- one that is technology-agnostic or
   independent, and another that is specific to the underlying
   technology or even different approaches to the same underlying
   technology.  The technology-independent component would be a common
   framework that would be an important component of the solution to
   this class of problems without any dependency on the underlying
   technology (i.e., 802.11, 802.16, etc.) being used.  The technology-
   specific component would be a control protocol that would be
   negotiated using this common framework and can be easily defined to
   be relevant to that technology without the need for having any
   dependency on other underlying technologies.  This approach also
   lends itself easily to extend the solution as new technologies arise
   or as new innovative methods to solve the same problem for an
   existing technology present themselves in the future.

   In this document, we present secure light access point protocol
   (SLAPP), a technology-independent protocol by which network elements
   that are meant to be centrally managed by a controller can discover
   one or more controllers, perform a security association with one of

Top      ToC       Page 5 
   them, and negotiate a control protocol that they would use to perform
   the technology-specific components of the control and provisioning
   protocol.  We have also presented two control protocols in this
   document -- an 802.11 control protocol for provisioning and managing
   a set of 802.11 WTPs, and an image download protocol that is very
   generic and can be applied to any underlying technology.

   Figure 1 shows the model by which a technology-specific control
   protocol can be negotiated using SLAPP to complete a solution for a
   certain underlying technology.  The figure shows a control protocol
   for 802.11 and 802.16 technology components, but the SLAPP model does
   not preclude multiple control protocols within a certain technology
   segment.  For example, a certain technology-specific control protocol
   may choose to support only the Local MAC architecture [2] while
   deciding not to support the Split MAC architecture [2].  While the
   image download protocol is presented in this document, a SLAPP
   implementation MUST NOT assume that this control protocol is
   supported by other SLAPP implementations.

Top      ToC       Page 6 
                                              Negotiated
            SLAPP                             Control
                                              Protocol

   +-------------------------+              +------------+
   |                         |              |            |
   |         SLAPP           |              |  Image     |
   | (technology-independent +-------+----->|  Download  |
   |      framework)         |       |      |  protocol  |
   |                         |       |      |            |
   |  negotiate one control  |       |      +------------+
   |  protocol here          |       |
   +-------------------------+       |
                                     |      +------------+
                                     |      |            |
                                     |      |   802.11   |
                                     +----->|  control   |
                                     |      |  protocol  |
                                     |      |            |
                                     |      +------------+
                                     |
                                     |
                                     |      +------------+
                                     |      |            |
                                     |      |   802.16   |
                                     +----->|  control   |
                                     |      |  protocol  |
                                     |      |            |
                                     |      +------------+
                                     |
                                     |         .......

                      Figure 1: SLAPP Protocol Model

   The control protocols that are negotiable using SLAPP are expected to
   be published ones that have gone through a review process in
   standards bodies such as the IETF.  The control protocols can either
   re-use the security association created during SLAPP or have the
   option of clearing all SLAPP state and restarting with whatever
   mechanisms are defined in the control protocol.

   Recently, there was a significant amount of interest in a similar
   problem in the Radio Frequency Identification (RFID) space that has
   led to the definition of a simple lightweight RFID reader protocol
   (SLRRP) [9].  It is quite possible that SLRRP could be a
   technology-specific (RFID, in this case) control protocol negotiated
   during a common technology-independent framework.

Top      ToC       Page 7 
   All of the text in the document would seem to be written with a WLAN
   problem in mind.  Please note that while the letter of the document
   does position the solution to solve a CAPWAP-specific problem, the
   spirit of the document is to address the more general problem.

2.  Definitions

2.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].

3.  Topology

   The SLAPP protocol supports multiple topologies for interconnecting
   WTPs and ACs as indicated in Figure 2.

   In Figure 2, we have captured four different interconnection
   topologies:

   1.  The WTP is directly connected to the AC without any intermediate
       nodes.  Many WTPs are deployed in the plenum of buildings and are
       required to be powered over the Ethernet cable that is connecting
       it to the network.  Many ACs in the marketplace can supply power
       over Ethernet, and in the case where the AC is the one powering
       the WTP, the WTP is directly connected to the AC.

   2.  The WTP is not directly connected to the AC, but both the AC and
       the WTP are in the same Layer 2 (L2) (broadcast) domain.

   3.  The WTP is not directly connected to the AC, and they are not
       present in the same L2 (broadcast) domain.  They are on two
       different broadcast domains and have a node on the path that
       routes between two or more subnets.

   4.  The fourth case is a subset of the third one with the exception
       that the intermediate nodes on the path from the WTP to the AC
       may not necessarily be in the same administrative domain.  The
       intermediate network may also span one or more WAN links that may
       have lower capacity than if both the AC and the WTP are within
       the same building or campus.

Top      ToC       Page 8 
               +-----------------+            +-------+
               |                 |    (1)     |       |
               |       AC        +------------+  WTP  |
               |                 |            |       |
               +--------+--------+            +-------+
                        |
                        |
                        |
                    +---+---+
               (2)  |       |
             +------+  L2   +--------+
             |      |       |        |
             |      +---+---+        |
             |                       |
             |                       |
       +-----+-----+             +---+---+    +-------+
       |           |             |       | (3)|       |
       |    WTP    |             |   L3  +----+  WTP  |
       |           |             |       |    |       |
       +-----------+             +---+---+    +-------+
                                     |
                                     |
                                     |
                                 +---+----+    +-------+
                                 |        | (4)|       |
                                 |Internet+----+  WTP  |
                                 |        |    |       |
                                 +--------+    +-------+

                           Figure 2: SLAPP Topology

4.  Protocol

4.1.  Protocol Description

   The SLAPP state machine for both the WTP and AC is shown in Figure 3.
   Both the WTP and the AC discover each other, negotiate a control
   protocol, perform a secure handshake to establish a secure channel
   between them, and then use that secure channel to protect a
   Negotiated Control Protocol.

   The WTP maintains the following variable for its state machine:

   abandon: a timer that sets the maximum amount of time the WTP will
      wait for an acquired AC to begin the Datagram Transport Layer
      Security (DTLS) handshake.

Top      ToC       Page 9 
      /--------\  /-----------\
      |        |  |           |
      |        v  v           |
      |  +-------------+      |
      | C| discovering |<-\   |
      |  +-------------+  |   |
      |        |          |   |
      |        v          |   |
      |  +-----------+    |   |
      \--| acquiring |    |   |
         +-----------+    |   |
               |          |   |
               v          |   |
         +----------+     |   |
        C| securing |-----/   |
         +----------+         |
               |              |
               v              |
       +----------------+     |
       |  negotiated    |     |
      C|    control     |-----/
       |   protocol     |
       +----------------+

                        Figure 3: SLAPP State Machine

4.1.1.  State Machine Explanation

   Note: The symbol "C" indicates an event that results in the state
   remaining the same.

   Discovering

      AC: This is a quiescent state for the AC in which it waits for
          WTPs to request its acquisition.  When a request is received,
          the AC transitions to Acquiring.

     WTP: The WTP is actively discovering an AC.  When the WTP receives
          a response to its Discover Request, it transitions to
          Acquiring.

   Acquiring

      AC: A discover request from a WTP has been received.  If the
          request is invalid or the AC wishes to not acquire the WTP, it
          drops the packet and transitions back to Discovering.
          Otherwise, a Discover Response is sent and the AC transitions
          to Securing.

Top      ToC       Page 10 
     WTP: A discover response from an AC has been received.  If the
          response is not valid, the WTP transitions to Discovering;
          otherwise, it sets the abandon timer to a suitable value to
          await a DTLS exchange.  If the timer fires in Acquiring, the
          WTP transitions back to Discovering.  If a DTLS "client hello"
          is received, the WTP transitions to Securing and cancels the
          abandon timer.

   Securing

      AC: The AC performs the "client end" of the DTLS exchange.  Any
          error in the DTLS exchange results in the AC transitioning to
          Discovering.  When the DTLS exchange finishes, the AC
          transitions to the Negotiated Control Protocol.

     WTP: The WTP performs the "server end" of the DTLS exchange.  Any
          error in the DTLS exchange results in the WTP transitioning to
          Discovering.  When the DTLS exchange finishes, the WTP
          transitions to the Negotiated Control Protocol.

   Negotiated Control Protocol

      AC: The AC performs its side of the protocol agreed to during the
          discovery process.  Please refer to Section 6.1 for the SLAPP
          802.11 Control Protocol.  For the Image Download Protocol
          example, see Section 6.2.

     WTP: The WTP performs its side of the protocol agreed to during the
          discovery process.  Please refer to Section 6.1 for the SLAPP
          802.11 Control Protocol.  For the Image Download Protocol
          example, see Section 6.2.

4.2.  Format of a SLAPP Header

   All SLAPP packets begin with the same header as shown in Figure 4.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Maj  |  Min  |     Type      |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 4: SLAPP Header

   Where:

      Maj (4 bits): the major number of the SLAPP version

Top      ToC       Page 11 
      Min (4 bits): the minor number of the SLAPP version

      Type (1 octet): the type of SLAPP message

      Length (two octets): the length of the SLAPP message, including
      the entire SLAPP header

   The following types of SLAPP messages have been defined:

      name                     type
      -----                   ------
      discover request           1
      discover response          2
      image download control     3
      control protocol packet    4
      reserved                  5-255

4.3.  Version

   SLAPP messages include a version in the form of major.minor.  This
   document describes the 1.0 version of SLAPP, that is the major
   version is one (1) and the minor version is zero (0).

   Major versions are incremented when the format of a SLAPP message
   changes or the meaning of a SLAPP message changes such that it would
   not be properly parsed by an older, existing version of SLAPP.  Minor
   versions are incremented when some incremental additions have been
   made to SLAPP that enhance its capabilities or convey additional
   information in a way that does not change the format or meaning of
   the SLAPP message.

   Future versions of SLAPP MAY NOT mandate support for earlier major
   versions of SLAPP, so an implementation MUST NOT assume that a peer
   that supports version "n" will therefore support version "n - i"
   (where both "n" and "i" are non-zero integers and "n" is greater than
   "i").

   A SLAPP implementation that receives a SLAPP message with a higher
   major version number MUST drop that message.  A SLAPP implementation
   that receives a SLAPP message with a lower major version SHOULD drop
   down to the version of SLAPP the peer supports.  If that version of
   SLAPP is not supported, the message MUST be dropped.  However, there
   may be valid reasons for which a peer wishes to drop a SLAPP message
   with a supported major version.

   A SLAPP implementation that receives a SLAPP message with a higher
   minor version number MUST NOT drop that message.  It MUST respond
   with the minor version number that it supports and will necessarily

Top      ToC       Page 12 
   not support whatever incremental capabilities were added that
   justified the bump in the minor version.  A SLAPP implementation that
   receives a SLAPP message with a lower minor version MUST NOT drop
   that message.  It SHOULD revert back to the minor version that the
   peer supports and not include any incremental capabilities that were
   added that justified the bump in the minor version.

4.4.  Retransmission

   SLAPP is a request response protocol.  Discovery and security
   handshake requests are made by the WTP, and responses to them are
   made by the AC.  Image Download packets are initiated by the AC and
   acknowledged by the WTP (in a negative fashion, see Section 6.2).

   Retransmissions are handled solely by the initiator of the packet.
   After each packet for which a response is required is transmitted,
   the sender MUST set a retransmission timer and resend the packet upon
   its expiry.  The receiver MUST be capable of either regenerating a
   previous response upon receipt of a retransmitted packet or caching a
   previous response and resending upon receipt of a retransmitted
   packet.

   The retransmission timer MUST be configurable and default to one (1)
   second.  No maximum or minimum for the timer is specified by this
   version of SLAPP.

   Each time a retransmission is made, a counter SHOULD be incremented,
   and the number of retransmissions attempted by a sender before giving
   up and declaring a SLAPP failure SHOULD be four (4)-- that is, the
   number of attempts made for each packet before declaring failure is
   five (5).

   The exception to this rule is Image Download packets, which are not
   individually acknowledged by the WTP (see Section 6.2).  The final
   packet is acknowledged and lost packets are indicated through Image
   Download Requests.

4.5.  Discovery

   When a WTP boots up and wants to interoperate with an Access
   Controller so that it can be configured by the AC, one of the first
   things it needs to do is to discover one or more ACs in its network
   neighborhood.  This section contains the details of this discovery
   mechanism.

   As described in Section 3, an AC and a WTP could reside in the same
   Layer 2 domain, or be separated by a Layer 3 cloud including
   intermediate clouds that are not under the same administrative domain

Top      ToC       Page 13 
   (for example, an AC and a WTP separated by a wide-area public
   network).  So any proposed discovery mechanism should have provisions
   to enable a WTP to discover an AC across all these topologies.

   We assume that a WTP, prior to starting the discovery process, has
   already obtained an IP address on its wired segment.

4.5.1.  SLAPP Discover Request

   The SLAPP discovery process is initiated by sending a SLAPP discover
   request packet.  The packet can be addressed to the broadcast IP
   address, a well-known multicast address, or (if the IP address of an
   AC is either configured prior to the WTP booting up or is learned
   during the boot-up sequence) addressed to a unicast IP address.  Lack
   of a response to one method of discovery SHOULD result in the WTP
   trying another method of discovery.  The SLAPP discover request
   packet is a UDP packet addressed to port [TBD] designated as the
   SLAPP discovery port.  The source port can be any random port.  The
   payload of the SLAPP discover request packet is shown in Figure 5.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maj  |  Min  |    Type = 1   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Transaction ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         WTP Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    WTP Identifier (continued) |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      WTP Vendor ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      WTP HW Version                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      WTP SW Version                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | n controltypes| control type  |  .  .  .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 5: SLAPP Discover Request

4.5.1.1.  Transaction ID

   The transaction ID is a randomly generated, 32-bit number that is
   maintained during one phase of the SLAPP discovery process.  It is
   generated by a WTP starting a discovery process.  When one discovery
   method fails to find an AC and the WTP attempts another discovery

Top      ToC       Page 14 
   method it MUST NOT re-use the Transaction ID.  All ACs that intend to
   respond to a SLAPP discover request must use the same value for this
   field as in the request frame.

4.5.1.2.  WTP Identifier

   This field allows the WTP to specify a unique identifier for itself.
   This MAY be, for instance, its 48-bit MAC address or it could be any
   other string such as a serial number.

4.5.1.3.  Flags

   The Flags field is used to indicate certain things about the discover
   request.  For example, bit 0 in the Flags field indicates whether the
   discover request packet is being sent to the AC, if unicast, based on
   a configuration at the WTP or based on some other means of discovery.
   This bit should always be set to the discover mode if the SLAPP
   discover request packet is being sent to either a broadcast or
   multicast address.  Here are the valid values for various bits in the
   Flags field.

      Bit 0:
      0 - Configuration mode
      1 - Discover mode

      Bits 1-15:
      Must always be set to 0 by the transmitter
      Must be ignored by the receiver

4.5.1.4.  WTP Vendor ID

   This 32-bit field is the WTP vendor's Structure of Management
   Information (SMI) enterprise code in network octet order (these
   enterprise codes can be obtained from, and registered with, IANA).

4.5.1.5.  WTP HW Version

   This 32-bit field indicates the version of hardware present in the
   WTP.  This is a number that is totally left to the WTP vendor to
   choose.

4.5.1.6.  WTP SW Version

   This 32-bit field indicates the version of software present in the
   WTP.  This is a number that is totally left to the WTP vendor to
   choose.

Top      ToC       Page 15 
4.5.1.7.  Number of Control Types

   This 8-bit field indicates the number of 8-bit control protocol
   indicators that follow it and therefore implicitly indicates the
   number of different control protocols the WTP is capable of
   supporting.  This number MUST be at least one (1).

4.5.1.8.  Control Types

   This 8-bit field indicates the type of control protocol the WTP
   supports and is willing to use when communicating with an AC.  There
   MAY be multiple "control type" indicators in a single SLAPP Discover
   Request.

      Valid Control Types
      -------------------
      0      - RESERVED (MUST not be used)
      1      - Image Download Control Protocol
      2      - 802.11 SLAPP Control Protocol
      3-255  - RESERVED (to IANA)

4.5.2.  SLAPP Discover Response

   An AC that receives a SLAPP discover request packet from a WTP can
   choose to respond with a SLAPP discover response packet.  The format
   of the SLAPP discover response packet is shown in Figure 6.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maj  |  Min  |    Type = 2   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Transaction ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        WTP Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    WTP Identifier (continued) |             Flags             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      AC HW Vendor ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       AC HW Version                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       AC SW Version                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | control type  |
   +-+-+-+-+-+-+-+-+

                     Figure 6: SLAPP Discover Response

Top      ToC       Page 16 
   The SLAPP discover response packet is a UDP packet.  It is always
   unicast to the WTP's IP address.  The source IP address is that of
   the AC sending the response.  The source port is the SLAPP discover
   port [TBD] and the destination port is the same as the source port
   used in the SLAPP discover request.  The WTP's MAC address and the
   transaction ID must be identical to the values contained in the SLAPP
   discover request.  The Status field indicates to the WTP whether the
   AC is either accepting the discover request and is willing to allow
   the WTP to proceed to the next stage (ACK) or whether it is denying
   the WTP's earlier request (NACK).  The AC includes its own vendor ID,
   hardware, and software versions in the response.

4.5.2.1.  Transaction ID

   The value of the Transaction ID field should be identical to its
   value in the SLAPP discover request packet sent by the WTP.

4.5.2.2.  WTP Identifier

   The WTP Identifier that was sent in the corresponding SLAPP discover
   request frame.

4.5.2.3.  Flags

   This field is unused by this version of SLAPP.  It MUST be set to
   zero (0) on transmission and ignored upon receipt.

4.5.2.4.  AC Vendor ID

   If the value of the Status field is a 1, indicating that the AC is
   sending a successful response, then the values in this field and the
   following two are valid.  The 32-bit AC Vendor ID points to the
   vendor ID of the AC.  If the value of the Status field is not 1, then
   this field should be set to 0 by the AC and ignored by the WTP.

4.5.2.5.  AC HW Version

   If the value of the Status field is 1, then this 32-bit field
   contains the value of the AC's hardware version.  This value is
   chosen by the AC vendor.  If the value of the Status field is not 1,
   then this field should be set to 0 by the AC and ignored by the WTP.

4.5.2.6.  AC SW Version

   If the value of the Status field is 1, then this 32-bit field
   contains the value of the AC's software version.  This value is
   chosen by the AC vendor.  If the value of the Status field is not 1,
   then this field should be set to 0 by the AC and ignored by the WTP.

Top      ToC       Page 17 
4.5.2.7.  Control Type

   The control type that the AC will use to communicate with the WTP.
   This value MUST match one of the control types passed in the
   corresponding SLAPP Discover Request.

4.6.  SLAPP Discovery Process

4.6.1.  WTP

   There are multiple ways in which a WTP can discover an AC.

   1.  Static configuration: An administrator, prior to deploying a WTP,
       can configure an IP address of an AC on the WTP's non-volatile
       memory.  If this is the case, then the SLAPP discover request
       packet is addressed to the configured IP address.

   2.  DHCP options: As part of the DHCP response, the DHCP server could
       be configured to use option 43 to deliver the IP address of an AC
       to which the WTP should address the SLAPP discover request
       packet.  If the IP address of an AC is handed to the WTP as part
       of the DHCP response, then the WTP should address the SLAPP
       discover request packet to this IP address.

   3.  DNS configuration: Instead of configuring a static IP address on
       the WTP's non-volatile memory, an administrator can configure a
       Fully-Qualified Domain Name (FQDN) of an AC.  If the FQDN of an
       AC is configured, then the WTP queries its configured DNS server
       for the IP address associated with the configured FQDN of the AC.
       If the DNS query is successful and the WTP acquires the IP
       address of an AC from the DNS server, then the above discover
       request packet is addressed to the unicast address of the AC.

   4.  Broadcast: The WTP sends a discover request packet addressed to
       the broadcast IP address with the WTP's IP address as the source.
       A network administrator, if necessary, could configure the
       default router for the subnet that the WTP is on with a helper
       address and unicast it to any address on a different subnet.

   5.  IP Multicast: A WTP can send the above payload to a SLAPP IP
       multicast address [TBD].

   6.  DNS: If there is no DNS FQDN configured on the WTP, and the WTP
       is unable to discover an AC by any of the above methods, then it
       should attempt to query the DNS server for a well-known FQDN of
       an AC [TBD].  If this DNS query succeeds, then the WTP should
       address the SLAPP discover request packet to the unicast address
       of the AC.

Top      ToC       Page 18 
   The above process is summarized in the sequence shown in Figure 7.

   SLAPP discovery start:
      Static IP address config option:
        Is a static IP address for an AC configured?
          If yes, send SLAPP discover request to that unicast IP address
            SLAPP discover response within discovery_timer?
              If yes, go to "done"
              If not, go to "Static FQDN config option"
          If not, go to "Static FQDN config option"
      Static FQDN config option:
        Is a static FQDN configured?
          If yes, send a DNS query for the IP address for the FQDN.
          Is DNS query successful?
            If yes, send SLAPP discover request to that IP address
            SLAPP discover response within discovery timer?
              If yes, go to "done"
              If not, go to "DHCP options option"
            If not, go to "DHCP options option"
       DHCP options option:
         Is the IP address of an AC present in the DHCP response?
           If yes, send SLAPP discover request to the AC's IP address
           SLAPP discover response within discovery timer?
             If yes, go to "done"
             If not, go to "Broadcast option"
           If not, go to "Broadcast option"
       Broadcast option:
         Send SLAPP discover packet to the broadcast address
         SLAPP discover response within discovery timer?
           If yes, go to "done"
           If not, go to "Multicast option"
       Multicast option:
         Send SLAPP discover packet to the SLAPP multicast address
         SLAPP discover response within discovery timer?
           If yes, go to "done"
           If not, go to "DNS discovery option"
       DNS discovery option:
         Query the DNS server for a well-known DNS name
         Is the DNS discovery successful?
           If yes, send SLAPP discover request to that IP address
           SLAPP discover response within discovery timer?
             If yes, go to "done"
             If not, go to "SLAPP discovery restart"
           If not, go to "SLAPP discovery restart"

Top      ToC       Page 19 
       SLAPP discovery restart:
         Set timer for SLAPP discovery idle timer
         When timer expires, go to "SLAPP discovery start"
       done:
         Go to the next step

                                 Figure 7

4.6.2.  AC

   When an AC receives a SLAPP discover request, it must determine
   whether or not it wishes to acquire the WTP.  An AC MAY only agree to
   acquire those WTPs whose WTP Identifiers are statically configured in
   its configuration.  Or an AC that is willing to gratuitously acquire
   WTPs MAY accept any request pending authentication.  An AC MUST only
   choose to acquire WTPs that speak a common Negotiated Control
   Protocol, but other factors may influence its decision.  For
   instance, if the Negotiated Control Protocol is the Image Download
   protocol defined in this memo, the AC MUST NOT acquire a WTP for
   which it does not have a compatible image to download as determined
   by the WTP's HW Vendor ID, HW Version, and Software Version.
   Whatever its decision, the AC MUST respond one of two ways.

   1.  The AC sends a SLAPP discover response indicating its agreement
       to acquire the WTP.

   2.  The AC silently drops the SLAPP discover request and does not
       respond at all.

5.  Security Association

   Once an AC has been discovered by a WTP and agreed to acquire it (by
   sending a Discover Response), it will initiate a DTLS [6] [8]
   exchange with the WTP by assuming the role of the "client".  The WTP
   assumes the role of the "server".  The port used by both the WTP and
   AC for this exchange will be [TBD].

   An obvious question is "Why is the AC acting as a client?".  The
   reason is to allow for non-mutual authentication in which the WTP is
   authenticated by the AC (see Section 5.1.2).

   Informational note: DTLS is used because it provides a secure and
   connectionless channel using a widely accepted and analyzed protocol.
   In addition, 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 and certificate-based; asymmetric or non-
   mutual authentication; anonymous authentication, etc.  Furthermore,
   DTLS defines its own fragmentation and reassembly techniques as well

Top      ToC       Page 20 
   as ways in which peers agree on an effective MTU.  Using DTLS
   obviates the need to redefine these aspects of a protocol and
   therefore lessens code bloat as the same problem doesn't need to be
   solved yet again in another place.

   Failure of the DTLS handshake protocol will cause both parties to
   abandon the exchange.  The AC SHOULD blacklist this WTP for a period
   of time to prevent a misconfigured WTP from repeatedly discovering
   and failing authentication.  The WTP MUST return to the discovery
   state of SLAPP to locate another suitable AC with which it will
   initiate a DTLS exchange.

   Once the DTLS handshake has succeeded, the WTP and AP transition into
   "image download state" and protect all further SLAPP messages with
   the DTLS-negotiated cipher suite.

5.1.  Example Authentication Models (Informative)

   Any valid cipher suite in [7] can be used to authenticate the WTP
   and/or the AC.  Different scenarios require different authentication
   models.  The following examples are illustrative only and not meant
   to be exhaustive.

   Since neither side typically involves a human being, a username/
   password-based authentication is not possible.

   Zero-config requirements on certain WTP deployments can predicate
   certain authentication options and eliminate others.

5.1.1.  Mutual Authentication

   When mutually authenticating, the WTP authenticates the AC, thereby
   ensuring that the AC to which it is connecting is a trusted AC, and
   the AC authenticates the WTP, thereby ensuring that the WTP that is
   connecting is a trusted WTP.

   Mutual authentication is typically achieved by using certificates on
   the WTP and AC, which ensure public keys each party owns.  These
   certificates are digitally signed by a Certification Authority, a
   trusted third party.

   Enrolling each WTP in a Certification Authority is outside the scope
   of this document, but it should be noted that a manufacturing
   Certification Authority does not necessarily provide the level of
   assurance necessary as it will only guarantee that a WTP or AC was
   manufactured by a particular company and cannot distinguish between a
   trusted WTP and a WTP that is not trusted but was purchased from the
   same manufacturer as the AC.

Top      ToC       Page 21 
5.1.2.  WTP-Only Authentication

   Some deployments may only require the WTP to authenticate to the AC
   and not the other way around.

   In this case, the WTP has a keypair that can uniquely identify it
   (for example, using a certificate) and, that keypair is used in a
   "server-side authentication" [7] exchange.

   This authentication model does not authenticate the AC and a rogue AC
   could assert control of a valid WTP.  It should be noted, though,
   that this will only allow the WTP to provide service for networks
   made available by the rogue AC.  No unauthorized network access is
   possible.

5.1.3.  Anonymous Authentication

   In some deployments, it MAY just be necessary to foil the casual
   snooping of packets.  In this case, an unauthenticated, but
   encrypted, connection can suffice.  Typically a Diffie-Hellman
   exchange is performed between the AC and WTP and the resulting
   unauthenticated key is used to encrypt traffic between the AC and
   WTP.



(page 21 continued on part 2)

Next RFC Part