RFC 5413
SLAPP: Secure Light Access Point Protocol
Pages: 75
Historic
Historic
Part 3 of 3 – Pages 60 to 75
6.1.4. Protocol Operation
The SLAPP 802.11 Control Protocol operation is described in this section.
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 | | | +-----------+ | | |
^ 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 WTP6.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
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.
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 | | | | +----+-------+ |
Reject| | | or| | | Timeout +-----------+ |Config | | | Update | |Update | +-----| Pending |<-----+ | +----+------+ | | Accept | +-------------------------+ Figure 27: SLAPP 802.11 Control Protocol at the AC6.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
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.
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
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
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.
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.
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.
| 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.
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
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.
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