Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5413

SLAPP: Secure Light Access Point Protocol

Pages: 75
Historic
Part 3 of 3 – Pages 60 to 75
First   Prev   None

Top   ToC   RFC5413 - Page 60   prevText

6.1.4. Protocol Operation

The SLAPP 802.11 Control Protocol operation is described in this section.
Top   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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   ToC   RFC5413 - 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