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.
Narasimhan, et al. Historic [Page 1]
RFC 5413 SLAPP February 2010
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.
Narasimhan, et al. Historic [Page 2]
RFC 5413 SLAPP February 2010
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
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
Narasimhan, et al. Historic [Page 4]
RFC 5413 SLAPP February 2010
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.
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.
Narasimhan, et al. Historic [Page 6]
RFC 5413 SLAPP February 2010
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.
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].
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.
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.
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.
Narasimhan, et al. Historic [Page 9]
RFC 5413 SLAPP February 2010
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.
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
Narasimhan, et al. Historic [Page 11]
RFC 5413 SLAPP February 2010
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.
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.
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
Narasimhan, et al. Historic [Page 12]
RFC 5413 SLAPP February 2010
(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.
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 | . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Narasimhan, et al. Historic [Page 13]
RFC 5413 SLAPP February 2010
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.
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.
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
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).
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).
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)
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
Narasimhan, et al. Historic [Page 15]
RFC 5413 SLAPP February 2010
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.
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.
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.
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.
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.
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.
Narasimhan, et al. Historic [Page 17]
RFC 5413 SLAPP February 2010
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"
Narasimhan, et al. Historic [Page 18]
RFC 5413 SLAPP February 2010
SLAPP discovery restart: Set timer for SLAPP discovery idle timer When timer expires, go to "SLAPP discovery start" done: Go to the next step
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
Narasimhan, et al. Historic [Page 19]
RFC 5413 SLAPP February 2010
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.
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.
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.
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.
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.
In this section, we describe two extensions for SLAPP -- one that is specific to 802.11 WLANs and another that is a technology-neutral protocol by which an AC can download a bootable image to a WTP.
This section describes a SLAPP extension that is targeted towards WTPs and ACs implementing the IEEE 802.11 WLAN standard. This extension contains all the technology-specific components that will be used by an AC to control and manage 802.11 WTPs.
The CAPWAP architecture taxonomy document [2] describes multiple architectures that are in use today in the WLAN industry. While there is a wide spectrum of variability present in these documented architectures, supporting every single variation or choice would lead to a complex protocol and negotiation phase. In the interest of limiting the complexity of the 802.11 component, we have limited the negotiation to four different architectural choices as listed below:
Narasimhan, et al. Historic [Page 21]
RFC 5413 SLAPP February 2010
Local MAC, bridged mode: This mode of operation falls under the Local MAC architecture. The 802.11 MAC is terminated at the WTP. The WTP implements an L2 bridge that forwards packets between its WLAN interface and its Ethernet interface.
Local MAC, tunneled mode: This mode of operation also falls under the Local MAC architecture where the 802.11 MAC is terminated at the WTP. The difference between this mode and the previous one is that in this mode, the WTP tunnels 802.3 frames to the AC using the mechanisms defined in Section 6.1.2.
Split MAC, L2 crypto at WTP: This mode of operation falls under the Split MAC architecture. The 802.11 MAC is split between the WTP and the AC, the exact nature of the split is described in Section 6.1.1.2. The L2 crypto functions are implemented in the WTP are the ones used to satisfy this function irrespective of whether or not the AC is also capable of this function. The WTP tunnels L2 frames to the AC using mechanisms defined in Section 6.1.2.
Split MAC, L2 crypto at AC: This mode of operation also falls under the Split MAC architecture. The difference between this one and the previous one is that the L2 crypto functions implemented in the AC are used to satisfy this function irrespective of whether or not these functions are also available at the WTP. The WTP tunnels L2 frames to the AC using mechanisms defined in Section 6.1.2.
The Local MAC architecture as documented in the CAPWAP architecture taxonomy document [2] performs all 802.11 frame processing at the WTP. The conversion from 802.11 to 802.3 and vice versa is also implemented at the WTP. This would mean that other functions like fragmentation/reassembly of 802.11 frames, and encryption/decryption of 802.11 frames is implemented at the WTP.
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and bridged onto the Ethernet interface of the WTP. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
In this sub-mode of the Local MAC architecture, the 802.11 frames are converted to 802.3 frames and are tunneled (using the tunneling mechanism defined in Section 6.1.2) to the AC to which the WTP is attached. These frames may be tagged with 802.1Q VLAN tags assigned by the AC.
In the Split MAC architecture, the MAC functions of an 802.11 AP are split between the WTP and the AC. The exact nature of the split is dependent upon the sub-modes listed in this section. In both cases, frames are tunneled to the AC using the mechanism defined in Section 6.1.2.
Some of these Split MAC architectures convert the 802.11 frames into 802.3 frames, which may be 802.1Q-tagged using tags assigned by the AC, while other of these Split MAC architectures will tunnel the entire 802.11 frame to the AC. The AC and WTP agree on what type of frame will be tunneled during the control protocol registration in Section 6.1.3
The 802.11 Control Protocol has two components, one for transporting the specific control and provisioning messages and another to tunnel data traffic from the WTP to the AC.
The SLAPP 802.11 Control Protocol uses the Generic Routing Encapsulation (GRE) [4] to encapsulate L2 frames. Depending on whether and how an architecture splits its MAC, some architectures may tunnel 802.11 frames directly to the AC while others may tunnel 802.3 frames, which may be optionally 802.1Q-tagged using tags assigned by the AC.
Narasimhan, et al. Historic [Page 24]
RFC 5413 SLAPP February 2010
The delivery mechanism of these GRE packets is IP. Therefore, the IP protocol of the outer packet is 47, indicating a GRE header follows. When GRE encapsulates 802.11 frames, the ether type in the GRE header is TBD; when GRE encapsulates 802.3 frames, the ether type in the GRE header is TBD2.
Since IP is the delivery mechanism, all issues governing fragmentation and reassembly are handled by [5].
When using the 802.11 Control Protocol, the type of SLAPP message is four (4), "control protocol packet". In this case, a two (2) octet field is appended to the SLAPP header to indicate the control protocol type as shown in Figure 8. The SLAPP 802.11 Control Protocol takes place in the "Negotiated Control Protocol" phase of Section 4.1, and all SLAPP 802.11 Control Protocol messages are therefore secured by the security association created immediately prior to entering that phase.
All basic configuration functions are applicable per-Extended Service Set Identifier (ESSID) per-radio in a WTP. Some WTPs MAY support more than one ESSID per-radio, while all WTPs MUST support at least one ESSID per-radio, which may be considered the primary ESSID in case of multiple ESSID support. All per-WTP configurations and capabilities (e.g., number of radios) are handled as part of the discovery and initialization process.
The provisioning of the regulatory domain of a WTP is beyond the scope of this document. A WTP, once provisioned for a specific regulatory domain, MUST restrict the operational modes, channel, transmit power, and any other necessary limits based on the knowledge contained within its software image and hardware capabilities. The WTP MUST communicate its capabilities limited by the regulatory domain as well as by the WTP hardware, if any, to the AC during the capability exchange.
The allocation and assignment of Basic Service Set Identifiers (BSSIDs) to the primary interface and to the virtual access point (AP) interfaces, if supported, are outside the scope of this document.
The structure of an information element is show below. The element ID starts with an element ID octet, followed by a 1-octet length, and the value of the element ID whose length is indicated in the Length field. The maximum length of an element is 255 octets.
Bit 4 : CAPWAP mode 5 - Split MAC, AC encryption, 802.11 tunneling
Bits 5-7 : Set to 0
When this element is included in the capabilities message, then the setting of a bit indicates the support for this CAPWAP mode at the WTP. When this element is used in configuration and status messages, then exactly one of bits 0-4 MUST be set.
This element is used to refer to a particular instance of a WLAN interface when used in configuration and status messages. When used within a recursion element, the elements within the recursion element correspond to the WLAN interface specified in this element.
This element is the WLAN Interface hardware vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). This field appears once for each instance of WLAN interface present in the WTP.
This element is an ID assigned by the WLAN Interface hardware vendor to indicate the type of the WLAN interface. It is controlled by the hardware vendor and the range of possible values is beyond the scope of this document. This field appears once for each instance of a WLAN interface present in the WTP.
If a regulatory domain is provisioned in the WTP, then the WTP indicates this by including this element in the capabilities list. If this information is not available at the WTP, then this element SHOULD not be included in the capabilities list. The process by which this information is provisioned into the WTP is beyond the scope of this document.
Narasimhan, et al. Historic [Page 28]
RFC 5413 SLAPP February 2010
Element ID : 6
Length : 4
Value : ISO code assigned to the regulatory domain
6.1.3.1.8. 802.11 PHY Mode and Channel Information
This element indicates the list of 802.11 Physical Layer (PHY) modes supported by the WTP along with a list of channels and maximum power level supported for this mode. This element appears once for each instance of WLAN interface at the WTP. There could be multiple instances of this element if the WLAN interface supports multiple PHY types.
Element ID : 7
Length : Variable
Valid : This field consists of
PHY mode : With a length of 1 octet with values as follows:
Power Level : In the capabilities messages, this indicates the maximum power level supported in this mode by the WTP; while in the configuration and status messages, this field indicates the desired power level or the current power level that the WTP is operating at. The field has a length of 1 octet and the power level is indicated in dBm.
Channel Information : A variable number of 2-octet values that indicate the center frequencies (in KHz) of all supported channels in this PHY mode.
When this element is used in configuration and status messages, the Power Level field indicates the desired or current operating power level. The Channel field has exactly one 2-octet value indicating the desired or current operating frequency.
In the capabilities message, this element contains the list of cryptographic algorithms that are supported by the WTP. This appears once for each instance of the WLAN interface present in the WTP. In configuration and status messages, this element is used to indicate the configured cryptographic capabilities at the WTP.
In the capabilities message, this element is formatted as follows
Element ID : 10
Length : 4
Value : Formatted as follows:
Bits 0-7 : Number of Antennae
Bit 8 : Individually Configurable, 0 = No, 1 = Yes
Bit 9 : Diversity support, 0 = No, 1 = Yes
Bit 10 : 0 = Internal, 1 = External
Bits 11-31 : Reserved
In configuration and status messages, this element is formatted as follows:
Element ID : 10
Length : 4
Value : Formatted as follows:
Bits 0-7 : Antenna Number - is a number between 0 and the number of antennae indicated by the WTP. The value is valid only if Bit 8 is set; otherwise, it MUST be ignored.
Bit 8 : Antenna Select - if this bit is reset, then the antenna selection is left to the algorithm on the WTP. If this bit is set, then the Antenna Number field indicates the antenna that should be used for transmit and receive.
This element indicates the number of BSSIDs supported by the WLAN interface. This element is optional in the capabilities part of the registration request message, and if it is absent, then the number of BSSIDs is set to 1. This element appears once for each instance of a WLAN interface present in the WTP.
Narasimhan, et al. Historic [Page 31]
RFC 5413 SLAPP February 2010
Element ID : 11
Length : 1
Value : The number of BSSIDs that the WLAN interface is capable of supporting.
This element is used in configuration and status messages to control the announcement of the ESSID in 802.11 beacons. For the Local MAC modes of operation, this field is also used to control whether the WTP should respond to Probe Requests that have a NULL ESSID in them.
Element ID : 14
Length : 1
Value : Defined as follows:
Bit 0 : ESSID announcement, 0 = Hide ESSID, 1 = Display ESSID in 802.11 beacons. The default value for this bit is 1.
Narasimhan, et al. Historic [Page 32]
RFC 5413 SLAPP February 2010
Bit 1 : Probe Response policy, 0 = Respond to Probe Requests that contain a NULL ESSID, 1 = Respond only to Probe Requests that match the configured ESSID. The default value for this bit is 0.
Configure or report the configured set of basic rates.
Element ID : 17
Length : 4
Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a basic rate. If the bit is reset, then the rate is not to be configured as a basic rate.
Configure or report the configured set of basic rates.
Element ID : 18
Length : 4
Value : Each of the bits in the following list is interpreted as follows. If the bit is set, then that particular rate is to be configured as a supported rate. If the bit is reset, then the rate is not to be configured as a supported rate.
This element is used to configure the tagging of packets belonging to a particular SSID when transferred between the AC and the WTP in CAPWAP modes 2-3, or before the WTP bridges the 802.3 frame to its wired interface when operating in CAPWAP mode 1.
Element ID : 23
Length : 2
Value : 802.1Q tag
If this element is absent in the configuration, then the WTP MUST assume that no tagging is required and should expect to receive untagged frames on frames destined towards the wireless interface.
A successful registration response from an AC to a WTP MUST contain this element. It is used in messages between the WTP and the AC on all other messages during the duration for which the registration is active.
Element ID : 24
Length : 4
Value : A 32-bit unsigned number allocated by the AC
The AC uses this element to assign importance to events, enable or disable notification, and to configure the global event notification policy. When the Event Identifier is 0, this element serves as a global notification policy message. The bitmap indicates the types of events that require the WTP to generate a notification. When the Event Identifier is non-zero, this element is used to configure a specific event for notification and its importance level. The importance level is specified by setting exactly one bit in the bitmap. If none of the bits are set in the bitmap, the element should be interpreted as a cancellation request. The WTP should stop sending notifications for the corresponding event specified in the Element Identifier.
This information element contains a set of counters relating to the transmit side of the wireless link at the WTP. These counters apply to either a BSS or an Access Category (if Wireless Multimedia (WMM) is enabled).
Element ID : 30
Length : 112 octets
Value : The value of this element is defined as follows:
* Successfully transmitted 802.11 Data frames : 4 octets
* Transmitted 802.11 Control frames : 4 octets
* Frames that reached max-retry limit : 4 octets
* Transmitted frames with 1 retry attempt : 4 octets
* Transmitted frames with 2 retry attempts : 4 octets
* Transmitted frames with more than 2 retry attempts : 4 octets
* Frames transmitted at each 802.11 PHY rate : 12*4 octets - The counters indicate the number of frames at each of the following rates, respectively: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mbps.
* Total frame dropped : 4 octets
* Frames dropped due to insufficient resources : 4 octets
* Frames dropped due to power-save timeouts : 4 octets
This information element includes all statistics related to the reception of the frames by WTP. These counters apply to either a BSS or an Access Category (if WMM is enabled).
Element ID : 31
Length : 108 octets
Value : The value of this element is defined as follows:
* Total Frames received : 4 octets
Narasimhan, et al. Historic [Page 40]
RFC 5413 SLAPP February 2010
* Frames with the retry bit set : 4 octets
* 802.11 Data frames received : 4 octets
* 802.11 Mgmt frames received : 4 octets
* 802.11 Control frames received : 4 octets
* Cyclic Redundancy Check (CRC) errors : 4 octets
* PHY errors : 4 octets
* Total Fragments received : 4 octets
* Reassembled frames : 4 octets
* Reassembly failures : 4 octets
* Successful Decryption : 4 octets
* Decryption failures : 4 octets
* Rate statistics : 48 octets - The number of frames received at each of the 802.11 PHY rates, respectively - 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 49, 54 Mbps.
* Total frames dropped : 4 octets
* Frames dropped due to insufficient resources : 4 octets
The status IE is included in the status response message sent by the WTP to the AC. It contains a set of fields that are used to indicate the status of various states at the WTP or each BSS configured in the WTP.
Element ID : 33
Length : 2 octets
Value : The value is defined as follows:
Enterprise Resource Planning (ERP) element, if applicable. If not applicable, then this field MUST be set to 0.
This element is used by the WTP to notify the AC of the current noise floor at one of the WLAN interfaces exceeding the configured noise floor threshold.
This element provides a generic capability for either a WTP or an AC to send a raw 802.11 frame to the other party. For example, it can be used to notify the AC of station association/disassociation events in the case of Local MAC architectures.
This element is used to transfer vendor-specific information between the WTP and the AC.
Element ID : 253
Length : Variable, > 3
Value : This variable-length element starts with a 3-octet Organizationally Unique Identifier (OUI), followed by a series of octets that are specific to the vendor represented by the OUI.
This element type can be used to recursively define a variable-length element that should be interpreted as a series of other elements defined in this section. It can be used to bound a set of elements as a unit.
Element ID : 254
Length : Variable
Value : A variable length element that contains a set of one or more elements defined in this section.
At the start of the SLAPP 802.11 Control Protocol, the WTP sends a registration request to the AC that it authenticated with. The registration request carries a list of information elements indicating the WTP's capabilities to the AC. The message starts with the SLAPP 802.11 Control Protocol header (Figure 8) with a SLAPP Control Protocol message type of 1.
Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request.
The following information elements are mandatory in the capabilities exchange:
1 : CAPWAP mode
2 : Number of WLAN interfaces
For each WLAN interface:
7 : 802.11 PHY mode and Channel Information
8 : Cryptographic Capability
9 : Other 802.11 standards support
Narasimhan, et al. Historic [Page 46]
RFC 5413 SLAPP February 2010
The following information elements may be optionally included in the registration request:
Bit 0 : Indicates the status of the transaction, 0 = successful response from the AC, 1 = the registration request is being rejected by the AC.
Bits 1-7 : Reserved
Bits 8-15 : If bit 0 = 1 (i.e., the registration request is being rejected by the AC), then this field contains a reason code. Otherwise, these bits are currently set to 0. The following reason codes are currently defined:
Narasimhan, et al. Historic [Page 47]
RFC 5413 SLAPP February 2010
0 : Reserved
1 : Unspecified reason
2 : Unable to handle more WTPs
3 : Incompatible capabilities
4-255 : Reserved
Transaction ID : A 32-bit random number chosen by the WTP at the start of a new registration phase. This number is used in the registration response by the AC to match the response to the corresponding request.
The following information elements are mandatory if the transaction is successful:
1 : CAPWAP mode - the mode that the AC chooses from among the list of supported modes sent by the WTP in the registration request.
The Configuration Update message is initiated by the AC to push modified or updated configuration to the WTP. It has a format similar to that of the Configuration Response message defined above.
The Configuration Acknowledgment message is used by the WTP to inform the AC whether it has accepted the prior Configuration Update or Configuration Response message. The WTP can reject the configuration sent by the AC, in which case it MUST return to the discovery state.
The keepalive messages can be initiated by either the WTP or the AC. It is used to probe the availability of the other party and the path between them. The initial message is termed the keepalive request, while the response to that message is termed the keepalive response.
Bit 0 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message.
Bit 1 : Set to 0 in a keepalive request message, set to 1 in a keepalive response message if the initiator of the keepalive request is unknown or the SLAPP registration ID is incorrect, and set to 0 otherwise.
All other bits are reserved and must be set to 0 by the source and ignored at the destination.
In CAPWAP mode 5, the 802.11 crypto functions are performed at the AC. So there is no need for the AC to send PTKs/GTKs to the WTP. When one of the CAPWAP Modes 1-4 has been negotiated between the AC and WTP, it is necessary for the AC to send both unicast and broadcast/multicast keys to the WTP. This is accomplished after the 802.1x authenticator (which resides on the AC) has successfully authenticated the supplicant. Key Configuration Requests are differentiated -- unicast or broadcast -- by setting or clearing the high-order bit of the "Flags" field. The setting of this bit determines the contents of the Key Configuration Request following the SLAPP Registration ID.
The Unicast Key Configuration Request is used by the AC to inform the WTP of the key to use when protecting unicast frames to and from a specified supplicant.
Note the high-order bit of the "Flags" field is cleared to indicate a unicast key is being sent. The 802.1Q tag field is used to indicate to the WTP which VLAN this supplicant is in and which broadcast/ multicast key to use when communicating to it with broadcast/ multicast frames.
Note the high-order bit of the "Flags" field is set, indicating a broadcast/multicast key is being sent. The bits marked "RSVD" are reserved and MUST be set to zero by the AC and ignored by the WTP.
The WTP acknowledges receipt of a Unicast Key Configuration Request by sending a Unicast Key Configuration Response. This response mirrors the request but does not send back the key length or the key itself. (The RSVD bits are returned for alignment purposes and MUST be set to zero by the WTP and ignored by the AC.)
The WTP acknowledges receipt of a Multicast Key Configuration Request by sending a Multicast Key Configuration Response. This response mirrors the request, but it does not send back the key length or the key itself. (The RSVD bits are returned for alignment purposes and MUST be set to zero by the WTP and ignored by the AC.)
An AC may want to periodically monitor the health of a WTP, collect the necessary information for diagnostics, and get notifications on pre-defined events at the WTP that may be of interest. This section defines a set of WTP statistics and events and describes the process of collecting statistics from WTPs and configuring the event notification mechanism at the WTP. It is beyond the scope of this document to describe what should/could be done with the collected information.
The simple statistics collection procedure defined here does not require the WTP to maintain any timers or any similar mechanisms. A WTP is responsible only for maintaining the statistics defined in Information Elements 29, 30, 31, and 32. The WTP must also respond to a statistics request message from the AC by delivering the appropriate statistics to the AC using a statistics response message. For example, if an AC is interested in gathering periodic statistics about some specific statistics, it is the responsibility of the AC to poll the WTP at the appropriate intervals.
The event notification process includes the following: 1) Event Registration: the registration of events of interest at the WTP by the AC and 2) Notification: The communication of event-related information by the WTP to the AC whenever the conditions for a specific registered event has occurred. The set of events supported by a WTP and the event-specific parameters that may be configured as part of a event registration are given in Section 6.1.3.3.3.
This section defines a set of WTP events along with the event- specific parameters that may be configured by ACs and the event- related information that should be delivered to the ACs by WTPs when the conditions for a particular configured event have occurred.
Radar Detection Event: Configure whether the AC is interested in receiving a notification whenever a radar event is detected. The WTP may notify the AC about the type of radar interference and the new channel that the WTP has moved to as a result, if any, using the Radar Detection Event Element (element ID: 35).
Excessive Retry Event: Configure the number of consecutive transmission failures before a notification is generated. The WTP may notify the MAC address of the station (STA) and the number of consecutive unacknowledged frames so far using the Excessive Retry Event Element (element ID : 36).
Noise Floor Event: Configure the noise floor threshold above which an event notification would be generated by the WTP. The WTP may notify the AC with the most recent measured noise floor that exceeded the configured threshold using the Noise Floor Event Element (element ID : 37).
De-Authentication Event: Configure whether the AC is interested in receiving a notification whenever a station has been de- authenticated by the WTP. The WTP may notify the AC with the MAC address of the STA along with a reason code (inactivity, etc.).
Association Event: Needed in Local MAC architecture.
Disassociation Event: Needed in Local MAC architecture.
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
Narasimhan, et al. Historic [Page 62]
RFC 5413 SLAPP February 2010
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.
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
Narasimhan, et al. Historic [Page 65]
RFC 5413 SLAPP February 2010
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.
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.
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.
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
Narasimhan, et al. Historic [Page 68]
RFC 5413 SLAPP February 2010
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).
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.
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.
Narasimhan, et al. Historic [Page 69]
RFC 5413 SLAPP February 2010
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.
Narasimhan, et al. Historic [Page 70]
RFC 5413 SLAPP February 2010
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.
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.
Narasimhan, et al. Historic [Page 71]
RFC 5413 SLAPP February 2010
| 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.
Narasimhan, et al. Historic [Page 72]
RFC 5413 SLAPP February 2010
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
Narasimhan, et al. Historic [Page 73]
RFC 5413 SLAPP February 2010
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.