tech-invite   World Map     

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

RFC 5413

 
 
 

SLAPP: Secure Light Access Point Protocol

Part 3 of 3, p. 60 to 75
Prev RFC Part

 


prevText      Top      Up      ToC       Page 60 
6.1.4.  Protocol Operation

   The SLAPP 802.11 Control Protocol operation is described in this
   section.

Top      Up      ToC       Page 61 
6.1.4.1.  SLAPP 802.11 Control Protocol State Machine

6.1.4.1.1.  At the WTP

       +-------------+
       | discovering |<-------------------------------+<----+
       +-------------+                                |     |
         ^  ^                                         |     |
         |  |          +-----------+                  |     |
         |  |          | securing  |                  |     |
         |  |          +----+------+                  |     |
         |  |               |                         |     |
         |  |               v                         |     |
         |  |        +--------------+                 |     |
         |  |   +--->| Unregistered |                 |     |
         |  |   |    +------+-------+                 |     |
         |  |   |           |                         |     |
         |  |   |           |Registration             |     |
         |  |   |Timeout    |Request                  |     |
         |  |   |           |                         |     |
         |  |   |           v                         |     |
         |  |   |    +--------------+                 |     |
         |  |   +----+ Registration |                 |     |
         |  |        |              |                 |     |
         |  | Reject |              |                 |     |
         |  +--------+   Pending    |                 |     |
         | nTimeout>3|              |                 |     |
         |           |              |                 |     |
         |           +------+-------+                 |     |
         |                  |                         |     |
         |                  |Accept                   |     |
         |                  |                         |     |
         |                  |                         |     |
         |                  v                         |     |
         |           +------+-------+                 |     |
         |           |  Registered  |                 |     |
         |      +--->|              |                 |     |
         |      |    +------+-------+                 |     |
         |      |           |                         |     |
         |      |Timeout    |Config                   |     |
         |      |           |Request                  |     |
         |      |           |                         |     |
         |      |           v                         |     |
         |      |    +------+-------+                 |     |
         |      +----+              |           Reject|     |
         |           |Configuration |                 |     |
         |   Reject  | Pending      |                 |     |
         +-----------+              |                 |     |

Top      Up      ToC       Page 62 
         ^ nTimeout>3+------+-------+                 |     |
         |                  |                         |     |
         |                  |                         |     |
   De-reg|                  |    +----------------+   |     |
    resp |                  |    v     Accept     |   |     |
    +----+---+       +------+----+--+           +-+---+--+  |
    |        | De-reg|              |           | Update |  |
    |  De    +<------+ Configured   +-----------+        |  |
    |Register| req   |              |           | Pending|  |
    |        |       |              |           +----+---+  |
    +--------+       +------+-------+                       |
                            |                               |
                            |                               |
                            |                               |
                        Too |Many                           |
                        Keepalive                           |
                        Failures                            |
                            |                               |
                            |                               |
                            |   De-Register                 |
                            +-------------------------------+

   In Configured and/or Registered states, respond to
   Status Requests, Statistics Requests, Keepalives, Key Config

            Figure 26: SLAPP 802.11 Control Protocol at the WTP

6.1.4.1.1.1.  State Machine Explanation

   Unregistered: The transition into this state is from the securing
      state (Figure 3).  Send registration request message to move to
      Registration Pending state, set timer for registration response.

   Registration Pending: On a registration response from the AC, cancel
      registration timer.  If the response is successful, move to
      Registered state.  If not, move to discovering state (Figure 3).
      If timer expires, if nTimeout >3, then move to discovering state.
      If not, return to Unregistered state.

   Registered: Send Configuration Request message to AC to move to
      Configuration Pending state, and set timer for Configuration
      Response.  In this state, respond to status request, statistics
      request, and keepalive messages from the AC.

   Configuration Pending: If a Configuration Response is received from
      the AC, cancel the Configuration Response timer.  If the response
      is successful and the configuration is acceptable, then send the
      Configuration ACK message to AC, and move to Configured state.  If

Top      Up      ToC       Page 63 
      the Configuration Request is rejected or the configuration is not
      acceptable, then send a de-register request to the AC and move to
      discovering.  If the Configuration Response timer expires, move to
      Registered state unless nTimeout >3, in which case move to
      discovering state.

   Configured: In the Configured state, the WTP responds to the status
      request, statistics request, and keepalive messages from the AC.
      If it receives a de-register request message from the AC, then it
      sends a de-register response to the AC and moves to the
      discovering state.  If the WTP receives a Configuration Update
      message, then it moves to the Update Pending state.  If it
      receives too many consecutive keepalive failures (no responses
      from the AC to keepalive requests), then it sends a de-register
      message to the AC and moves to the discovering state.

   Update Pending: In the Update Pending state, the WTP analyzes the
      configuration information received in the Configuration Update
      message.  If the configuration is found to be acceptable, then it
      applies the configuration and returns to the Configured state.  If
      the WTP chooses to reject the configuration update, then it sends
      a de-register request to the AC and moves to the discovering
      state.

   De-register: From the Configured state, the WTP moves to the
      De-register state when it receives a de-register request message
      from the AC.  It sends a de-register response to the AC and moves
      to the discovering state.

Top      Up      ToC       Page 64 
6.1.4.1.2.  At the AC

            +----------+
            | securing |
            +----+-----+
                 |
                 |
                 |
                 v
            +--------------+
   +--------| Unregistered |
   |        +----+---------+
   |             |
   |Timeout      |Register
   |             |request
   |             v                   +-------------+
   |         +----------+   Accept   | Registration|
   |     +---+Register  +----------->|  Pending    |
   |     |   |Processing|            +-+-----+-----+
   |     |   +----------+              |     |
   |     |                             |     |
   |     |Reject                    Timeout  |
   |     |                             |     |Config
   |     |                             |     |Request
   |     |      +--------------+       |     |
   |     +----->|              |<------+     |
   |            |  discovering |             v
   +----------->|              |        +------------+
                +--------------+        | Registered |
                    ^     ^  ^          +----+-------+
                    |     |  |               |
                    |     |  |               |Config
                    |     |  |               |Response
                    |     |  |               v
                    |     |  | Timeout  +------------+
                    |     |  +----------| Config     |
                    |     |   or Reject | Pending    |
                    |     |             +----+-------+
                    |     |                  |
                    |     |                  |Config ACK
                    |     |                  v
                    |     |De-Register  +------------+
                    |     +-------------|            |
                    |     or Keepalive  | Configured |<--+
                    |        failures   |            |   |
                    |                   +----+-------+   |

Top      Up      ToC       Page 65 
              Reject|                        |           |
                  or|                        |           |
              Timeout     +-----------+      |Config     |
                    |     | Update    |      |Update     |
                    +-----| Pending   |<-----+           |
                          +----+------+                  |
                               |           Accept        |
                               +-------------------------+

            Figure 27: SLAPP 802.11 Control Protocol at the AC

6.1.4.1.2.1.  State Machine Explanation

   The states "securing" and "discovering" are described in Figure 3.

   Unregistered: This state is entered from the securing state described
      in Figure 3.  In this state, the AC is waiting for a registration
      request message from the WTP.  Upon receiving the registration
      request message, it moves into the Registration Processing state.

   Registration Processing: In this state, the AC must determine whether
      or not it can accept the new WTP.  If the AC decides to accept the
      WTP, it must pick a CAPWAP mode to operate in and send a
      registration response message with a success code and moves to the
      Registration Pending state.  If the AC chooses to reject the
      current registration request from the WTP, it must send a
      registration response with a failure code and move to the
      discovering state.

   Registration Pending: If the timer expires before a response from the
      WTP is received, then the AC destroys the registration state and
      moves to the discovering state.  If a Configuration Request
      message is received from the WTP, then the AC moves into the
      Registered state and processes the Configuration Request message.
      It sends a Configuration Response message to the WTP with the
      appropriate IEs and moves into the Configuration Pending state.

   Configuration Pending: If the timer expires before a response is
      received from the WTP, then the AC destroys the current
      registration and moves into the discovering state.  If a
      Configuration ACK is received from the WTP, but contains a failure
      code, then the AC again destroys the registration state and moves
      into the discovering state.  If the Configuration ACK from the WTP
      is successful, then the AC moves to the Configured state.

   Configured: In the Configured state, the AC can send a status
      request, statistics request, keepalive, and Key Configuration
      messages to the WTP.  Any response to these messages from the WTP

Top      Up      ToC       Page 66 
      that indicates an unknown SLAPP registration ID or an unknown AC
      causes the AC to destroy any registration or configuration state
      and move to the discovering state.  From the configured state, the
      AC can send a Configuration Update message and move into the
      Update Pending state.  If it receives a de-register request from
      the WTP, then it destroys all current registration and
      configuration state and moves into the discovering state.  If a
      number of successive keepalive messages go unacknowledged by the
      WTP, then the AC moves into the discovering state.

   Update Pending: When the AC receives a Configuration ACK message with
      a success code, then it returns to the Configured state.  If the
      status code is a failure or if the timer expires before the
      Configuration ACK is received from the WTP, the AC destroys all
      registration and configuration state for the WTP and moves into
      the discovering state.

6.2.  Image Download Protocol

   The Image Download protocol is a control protocol defined in this
   document that is generic enough to be agnostic to the underlying
   technology.

   In the Image Download protocol, the WTP obtains a bootable image from
   the AC by receiving a series of image transfer packets.  Missed image
   data packets are re-requested by the WTP by sending image data
   request packets indicating the missing packets.

   The image to download is divided into slices of equal size (except
   for the last slice, which can be less than the slice size provided,
   it is also greater than zero).  The size of each slice depends on the
   MTU determined by the DTLS exchange and SHOULD be the realized MTU
   minus the size of an Image Download Request (Figure 29).

   Note that the Image Download packet and Image Download Request is
   encapsulated in a DTLS header that secures the image download.

6.2.1  Image Download Packet

   The format of an Image Download packet is shown in Figure 28.

Top      Up      ToC       Page 67 
    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 = 3   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESERVED |M|R|            packet sequence number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                     image data slice                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 28: SLAPP Image Download Packet

   where:

   length: variable

   RESERVED: Unused in this version of SLAPP, MUST be zero (0) on
      transmission and ignored upon receipt.

   M: The "More" bit indicating that the current packet is not the final
      one.

   R: The "Request" bit.  This bit MUST be set to one (1) when the
      packet is the response to a request and zero (0) otherwise.

   packet sequence number: A monotonically increasing counter that
      assigns a unique number to each slice of the image.

   image data slice: A portion of the bootable image.

6.2.2.  Image Download Request

   The format of an Image Download Request is shown in Figure 29.

    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 = 3   |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESERVED |M|R|            packet sequence number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 29: SLAPP Image Download Request Packet

   where:

   length: eight (8) octets

Top      Up      ToC       Page 68 
   RESERVED: Unused in this version of SLAPP, MUST be zero on
      transmission and ignored upon receipt.

   M: The "More" bit.  This MUST be equal to the one (1) when negatively
      acknowledging a missed packet and set to zero (0) when indicating
      the end of the Image Download protocol.

   R: the "Request" bit.  This MUST be one in an Image Download Request.

   packet sequence number: The packet sequence number of the missing
      image data slice.

6.2.3.  Image Download Process

   The AC will divide the bootable image into a series of slices and
   send each slice as an Image Download packet.  The size of each image
   data slice (and therefore the size of each Image Download packet)
   depends on the MTU of the connection determined during the DTLS
   handshake.  With the transmission of each slice, the AC MUST
   increment the packet sequence number.

   Image Download packets are negatively ACK'd.  An AC MUST NOT assume
   anything about the reception of packets; it sends based upon negative
   ACKs.  One could naively assume that since the packets are sent
   sequentially, that all packets with a sequence number of "n - 1" are
   implicitly ack'd by the receipt of a request for the packet with
   sequence number "n" to be retransmitted.  Such an assumption would be
   incorrect since previous requests could, themselves, have been
   dropped.

   The Image Download process is initiated by the WTP requesting a
   packet with the packet sequence number of zero (0).  The AC sets the
   packet sequence counter for this WTP to one (1) and sends the first
   slice.  The "Request" bit for the first slice sent by the AC MUST be
   set to zero (0) since the first slice was technically not requested.

   The WTP sets a periodic timer that, when it fires, causes the WTP to
   send Image Download Requests for slices that have been missed since
   the last periodic timer had fired.  Since individual Image Download
   packets are not ack'd, the AC MUST NOT set a timer when each one is
   sent.

   If a WTP notices missed image transfer packets -- when the difference
   between the packet sequence number of a received image transfer
   packet and the packet sequence number of the last image transfer
   packet previously received is greater than one -- it will note that
   fact in a bitmask.  When the periodic timer fires, the WTP will
   request the slices that are absent from that bitmask.  Each slice

Top      Up      ToC       Page 69 
   will be requested by sending a Download Request with a length of
   eight (8) and indicating the sequence number of the packet requested.
   The AC MUST interleave these retransmissions with packets in the
   sequence.

   Since both sides implicitly agree upon the MTU of the link, the WTP
   will know the slice size that the AC will use during the Image
   Download process.  A dropped packet will therefore result in an
   internal buffer pointer on the WTP being incremented by the slice
   size and the lost packet requested.  When the lost packet is
   received, it can be inserted into the buffer in the space provided by
   the pointer increment when its loss was first detected.  That is,
   loss of packet <n> will result in packet <n> being re-requested and
   when received inserted into the buffer at an offset of <n-1> *
   <slicesize> from the start of the buffer.

   The final packet sent by the AC will not have the "more" bit set, and
   this indicates to the WTP that the end of the image has been
   received.  This final packet is acknowledged by the WTP indicating
   the end of the Image Download process.

   A lost final packet will result in the AC resending the final packet
   again (see Section 4.4).

6.2.4.  Image Download State Machine

   The Image Download protocol is a Negotiated Control Protocol defined
   for SLAPP.  Transitions to it come from the "secure" state and
   transitions out of it go to the "acquire" state.  See Figure 3.

6.2.4.1.  AC

   The AC's state machine for the Image Download protocol is shown in
   Figure 30.  The AC maintains the following variables for its state
   machine:

   seq_num: The current slice that is being sent.

   nslices: The total number of slices in the image.

   req_num: The number of the slice that was requested.

   more: Whether the "More bit" in the packet should be set.

   starved: A timer that sets the maximum amount of time in which an AC
      will attempt to download an image.

Top      Up      ToC       Page 70 
   Note: The symbol "C" indicates an event in a state that results in
   the state remaining the same.

                              |
                              v
                         +----------+
                         |  waiting |
                         +----------+
                              |
                              |   seq_num = 1, more = 1,
                              |   nslices = x, starved = t
                M bit         v
   +----------+  is 0  +-------------+
   | finished |<-------|  received   |<------\
   +----------+        |             |<----\ |
                       +-------------+     | |
    req_num = requested       |            | |
                 packet       | M bit is 1 | |
                              V            | |
                         +----------+      | |
             seq_num++, C|  sending |------/ |
             req_num=0   +----------+        |
                              |              |
                           |  |              |
       +-------------+     |  |              |
       | discovering |<----/  |              |
       |             |<----\  |              |
       +-------------+     |  |              |
                           |  v              v
                          +--------+         |
                          | idle   |---------/
                          +--------+

     Figure 30: SLAPP Image Download Protocol State Machine at the AC

   The following states are defined:

   Waiting: When the AC leaves the SLAPP state of "Secure", it enters
      the "Waiting" state of the Image Download protocol.  seq_num is
      set to one (1), more is set to one (1), nslices is set to the
      number of slices in the particular image to download, and starved
      is set to the maximum amount of time the AC will devote to
      downloading a particular image.

Top      Up      ToC       Page 71 
   Received: The AC enters this state when it has received an Image
      Download Request.  If the sequence number of the packet is zero
      (0), it sets seq_num to one (1) and transitions to Sending; else,
      if the M bit is set, it sets req_num to the sequence number of the
      request and transitions to Sending; else, (if the M bit is clear)
      it transitions to Finished.

   Sending: The AC is sending a slice to the WTP.  If req_num is equal
      to zero (0), it sends the slice indicated by seq_num and
      increments seq_num.  If req_num is greater than zero (0), it sends
      the slice indicated by req_num and sets req_num to zero (0).  The
      "More" bit in either case is set depending on the value of more.
      As long as no request packets are received Sending transitions to
      Sending.  When seq_num equals nslices "More" is set to zero (0)
      and the state transitions to Idle.  If the starved timer expires,
      the AC transitions to the SLAPP state of Discovering.

   Idle: The AC has sent all the slices in the image and is just waiting
      for requests.  If the starved timer expires the AC transitions to
      the SLAPP state of Discovering.

   Finished: The Image Download protocol has terminated.  The starved
      timer is canceled.

6.2.4.2.  WTP

   The WTP's state machine for the Image Download protocol is shown in
   Figure 31.  The WTP maintains the following variables for its state
   machine:

   recv_num: The sequence number of the last received slice.

   req: A bitmask whose length equals the number of slices in the image.

   retry: A timer.

   giveup: A timer.

   final: The sequence number of the last slice.

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

Top      Up      ToC       Page 72 
                               |
                               v
                          +----------+
                          |   init   |    recv_num = 0,
                          +----------+    final = 0, req = 0,
                               |          giveup = t
                               v
    +----------+         +-----------+
    | finished |<------- |  sending  |<-------\
    +----------+         +-----------+        |
                               |              | retry fires
                               v              |
                        +--------------+      |
      bit in req =     C|  receiving   |------/
   seq_num in packet    +--------------+
        is set                 |
                               | giveup fires
                               v
                        +-------------+
                        | discovering |
                        +-------------+

     Figure 31: SLAPP Image Download Protocol State Machine at the WTP

   The following states are defined:

   Init:

      When the WTP leaves the SLAPP state of "Secure", it enters the
      "Init" state of the Image Download protocol.  recv_num, final, and
      the req bitmask are set to zero (0), and the giveup timer is set
      to a suitably large number.  The WTP transitions directly to
      Sending.

   Sending:

      If recv_num is zero (0) the WTP sends a request for a packet with
      sequence number of zero (0) and the "More" bit set to one (1).
      Otherwise, for every unset bit in req between one (1) and
      recv_num, a request packet is sent with the sequence number
      corresponding to the unset bit in req and the "More" bit set to
      more.

      If there are no unset bits in req and final is non-zero, a request
      packet is sent for the sequence number represented by final with
      the "More" bit cleared, giveup is cleared and the state machine
      transitions to Finished.  Otherwise, retry is set to a suitable
      value and the WTP transitions to Receiving.

Top      Up      ToC       Page 73 
   Receiving:

      In this state, the WTP receives Image Download packets.  The bit
      in req corresponding to the sequence number in the received packet
      is set, indicating this packet has been received.  If the sequence
      number of the received packet has already been received, the
      packet is silently dropped; otherwise, the data in the packet is
      stored as the indicated slice in a file that represents the
      downloaded image.  If the received packet has the "More" bit
      cleared, final is set to the sequence number in that packet.  When
      the retry timer fires, the WTP transitions to Sending.  If the
      giveup timer fires, the WTP transitions to the SLAPP state of
      Discovering.

   Finished:

      The Image Download protocol has finished.

7.  Security Considerations

   This document describes a protocol, SLAPP, which uses a different
   protocol, DTLS, to provide for authentication, key exchange, and bulk
   data encryption of a Negotiated Control Protocol.  Its security
   considerations are therefore those of DTLS.

   The AC creates state upon receipt of an acceptable Discover Request.
   AC implementations of SLAPP SHOULD therefore take measures to protect
   themselves from denial-of-service attacks that attempt to exhaust
   resources on target machines.  These measures could take the form of
   randomly dropping connections when the number of open connections
   reaches a certain threshold.

   The WTP exposes information about itself during the discovery phase.
   Some of this information could not be gleaned by other means.

8.  Extensibility to Other Technologies

   The SLAPP protocol can be considered to be a technology-independent
   protocol that can be extended with technology-specific components to
   solve an interoperability problem where a central controller from one
   vendor is expected to control and manage network elements from a
   different vendor.

   While the description of the SLAPP protocol in this document assumes
   that it is meant to solve the multi-vendor interoperability problem,
   as defined in the CAPWAP problem statement [3], splitting the

Top      Up      ToC       Page 74 
   solution to two components where technology-dependent control
   protocols are negotiated using a technology-independent framework
   enables the use of SLAPP as the common framework for multiple
   underlying technologies that are vastly different from one another.

9.  Informative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for
         Control and Provisioning of Wireless Access Points (CAPWAP)",
         RFC 4118, June 2005.

   [3]   O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and
         Provisioning for Wireless Access Points (CAPWAP) Problem
         Statement", RFC 3990, February 2005.

   [4]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

   [5]   Braden, R., Ed., "Requirements for Internet Hosts -
         Communication Layers", STD 3, RFC 1122, October 1989.

   [6]   Rescorla, E. and N. Modadugu, "Datagram Transport Layer
         Security", RFC 4347, April 2006.

   [7]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.2", RFC 5246, August 2008.

   [8]   Modadugu, N. and E. Rescorla, "The Design and Implementation of
         Datagram TLS",
         <http://crypto.stanford.edu/~nagendra/papers/dtls.pdf>.

   [9]   Krishna, P. and D. Husak, "Simple Lightweight RFID Reader
         Protocol", Work in Progress, August 2005.

Top      Up      ToC       Page 75 
Authors' Addresses

   Partha Narasimhan
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   Phone: +1 408-480-4716
   EMail: partha@arubanetworks.com


   Dan Harkins
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   EMail: dharkins@arubanetworks.com


   Subbu Ponnuswamy
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   Phone: +1 408-754-1213
   EMail: subbu@arubanetworks.com