RFC 5413
SLAPP: Secure Light Access Point Protocol
RFC 5413: SLAPP: Secure Light Access Point Protocol 💖
Okay bestie, let's start with the basics 🎀 This is RFC 5413, and it's titled SLAPP: Secure Light Access Point Protocol. It's an Independent Submission, which means it's a contribution to the RFC Series that's independent of any other RFC stream. The category is Historic, it was published in February 2010, and it has ISSN 2070-1721. Three people wrote it, P. Narasimhan, D. Harkins, and S. Ponnuswamy, all from Aruba Networks 🧚. The title block doesn't list anything it obsoletes or updates.
Abstract ✨
So the CAPWAP problem statement describes a problem that needs fixing before a wireless LAN (WLAN) network designer can build a solution out of Wireless Termination Points (WTP) and Access Controllers (AC) from lots of different vendors 🫶 One of the big goals is solving interoperability between those two kinds of devices, so an AC from one vendor can control and manage a WTP from another. Iconic, right? 💅
This document presents a protocol that forms a common, technology-independent framework. On top of that framework, you can negotiate and add a control protocol that has a technology-dependent component, and together that gets you a complete solution 🦋 The document also presents two control protocols: an 802.11 Control protocol, and a more generic image download protocol.
Even though this text is written to specifically address the problem stated in RFC 3990, the solution can be used for any problem where there's a controller (the equivalent of the AC) managing one or more network elements (the equivalent of the WTP). Main character energy ⭐
Status of This Memo 🌸
This document is not an Internet Standards Track specification. It's published for the historical record.
This document defines a Historic Document for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that 💅
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc5413.
IESG Note 🙈
This RFC documents the SLAPP protocol as it was when it was submitted to the IETF as a basis for further work in the CAPWAP Working Group. That means it may look like 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 here has not been thoroughly reviewed, so it may contain errors and omissions.
Heads up! RFC 5415 documents the standards track solution for the CAPWAP Working Group, and it obsoletes any and all mechanisms defined in this RFC. This RFC is not a candidate for any level of Internet Standard, and it 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, because they describe your rights and restrictions with respect to this document 🎀
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 .........................................74Part 1 of 13 is done! 🦋 Part 2 picks up with Section 1, the Introduction, so stay tuned 💜
1. Introduction ✨
okay so the CAPWAP problem statement [3] is basically about wireless LAN (WLAN) Access Controllers (ACs) needing to run and manage Wireless Termination Points (WTPs) that come from a different vendor 🫶 but honestly this problem is bigger than they made it sound. it shows up in any app, even non-wireless ones, where one central controller has to manage one or more network elements from another vendor 💅
one way to fix it is to write one giant complete control protocol so an AC from vendor A can run a WTP from vendor B 🎀 but here's the tea: a solution that's only built for one technology (IEEE 802.11, in this case) can struggle with everything else 💀 different technologies have different config options and different architecture choices (like Local Medium Access Control (MAC) vs Split MAC in 802.11). what's good for one tech might not work for another, and even the same tech can have multiple architecture choices [2] 🙈 a monolithic protocol trying to cover all of that is giving "too much complexity and nothing works" OR "too rigid and nobody can innovate" 😭 neither is it
so the other move is to split the solution space into two parts 🦋 one part is technology-agnostic (doesn't care what tech it is), and the other part is specific to the underlying tech, or to different approaches within the same tech. the technology-independent piece is a common framework that doesn't depend on whatever tech is underneath (802.11, 802.16, etc.) ✨ the technology-specific piece is a control protocol that gets negotiated through that common framework, and it can be defined just for its tech without depending on any other tech 🌸 bonus: this also makes it easy to extend when new technologies show up or when someone comes up with a new method for an existing tech 🚀
in this document, we present the secure light access point protocol (SLAPP) 💖 it's the technology-independent protocol where network elements that are meant to be centrally managed can discover one or more controllers, set up a security association with one of them, and negotiate the control protocol they'll use for the technology-specific parts of control and provisioning 🧚 we also include two control protocols here: an 802.11 control protocol for provisioning and managing a set of 802.11 WTPs, and an image download protocol that's super generic and works with any underlying tech 👑
Figure 1 shows how a technology-specific control protocol gets negotiated using SLAPP to finish a solution for a given underlying tech 🍓 the figure shows control protocols for 802.11 and 802.16 components, but SLAPP doesn't rule out having multiple control protocols inside one tech segment ⭐ for example, a tech-specific control protocol could choose to support only the Local MAC architecture [2] and skip the Split MAC architecture [2] 🦋 the image download protocol is included in this document, BUT a SLAPP implementation MUST NOT assume that other SLAPP implementations support this control protocol 🚫 (careful with that one bestie!)
Negotiated
SLAPP Control
Protocol
+-------------------------+ +------------+
| | | |
| SLAPP | | Image |
| (technology-independent +-------+----->| Download |
| framework) | | | protocol |
| | | | |
| negotiate one control | | +------------+
| protocol here | |
+-------------------------+ |
| +------------+
| | |
| | 802.11 |
+----->| control |
| | protocol |
| | |
| +------------+
|
|
| +------------+
| | |
| | 802.16 |
+----->| control |
| | protocol |
| | |
| +------------+
|
| .......
Figure 1: SLAPP Protocol Modelthe control protocols you can negotiate with SLAPP are expected to be published ones that went through a review process in standards bodies like the IETF 📚 they can either re-use the security association SLAPP created, OR they have the option to clear all SLAPP state and restart using whatever mechanisms that control protocol defines 💅
recently there was a lot of interest in a similar problem in the Radio Frequency Identification (RFID) space, which led to the simple lightweight RFID reader protocol (SLRRP) [9] 🎀 SLRRP could totally be a technology-specific (RFID, in this case) control protocol negotiated during a common technology-independent framework 😍
ngl the whole document reads like it was written with WLAN in mind 🙈 but while the letter of the document does frame the solution around a CAPWAP-specific problem, the spirit of the document is to tackle the bigger, more general problem 🌈💜
2. Definitions
2.1. Conventions Used in This Document
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 🤓 bestie, these are the official requirement words, so read them carefully 🫶
3. Topology
the SLAPP protocol supports multiple topologies for interconnecting WTPs and ACs, as shown in Figure 2 🗺️✨
in Figure 2, we've captured four different interconnection topologies 🦋
- the WTP is directly connected to the AC with no intermediate nodes in between 💖 a lot of WTPs live in the plenum of buildings and have to be powered over the Ethernet cable that connects them to the network ⚡ plenty of ACs on the market can supply power over Ethernet, so when the AC is the one powering the WTP, the WTP is directly connected to the AC 🔌
- 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 🌸
- the WTP is NOT directly connected to the AC, and they are NOT in the same L2 (broadcast) domain 🙅♀️ they sit on two different broadcast domains, and there's a node on the path that routes between two or more subnets 🧭
- the fourth case is basically a subset of the third one, with one twist: 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 with lower capacity than if the AC and WTP were in the same building or campus 🐢💀
+-----------------+ +-------+
| | (1) | |
| AC +------------+ WTP |
| | | |
+--------+--------+ +-------+
|
|
|
+---+---+
(2) | |
+------+ L2 +--------+
| | | |
| +---+---+ |
| |
| |
+-----+-----+ +---+---+ +-------+
| | | | (3)| |
| WTP | | L3 +----+ WTP |
| | | | | |
+-----------+ +---+---+ +-------+
|
|
|
+---+----+ +-------+
| | (4)| |
|Internet+----+ WTP |
| | | |
+--------+ +-------+
Figure 2: SLAPP Topology4. Protocol
4.1. Protocol Description
okay the SLAPP state machine for both the WTP and the AC is in Figure 3 💅 both of them discover each other, negotiate a control protocol, do a secure handshake to set up a secure channel between them, and then use that secure channel to protect a Negotiated Control Protocol 🔐✨
the WTP keeps track of 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 ⏰ (this is the "give up if nothing happens" clock, bestie 😭)
/--------\ /-----------\
| | | |
| v v |
| +-------------+ |
| C| discovering |<-\ |
| +-------------+ | |
| | | |
| v | |
| +-----------+ | |
\--| acquiring | | |
+-----------+ | |
| | |
v | |
+----------+ | |
C| securing |-----/ |
+----------+ |
| |
v |
+----------------+ |
| negotiated | |
C| control |-----/
| protocol |
+----------------+
Figure 3: SLAPP State Machine4.1.1. State Machine Explanation ✨
Okay so quick heads up: the letter C just means "this event happens, but the state stays exactly where it is" 🫶
Discovering 🔍
AC: this is the quiet, chill state for the AC, where it just waits for WTPs to request to be acquired 🌸. Once a request comes in, the AC moves on to Acquiring.
WTP: the WTP is actively hunting for an AC 🕵️♀️. When it gets a response to its Discover Request, it moves to Acquiring.
Acquiring 💌
AC: the AC has received a discover request from a WTP. If that request is invalid, or the AC doesn't want to acquire this WTP, it drops the packet and goes back to Discovering 🙅♀️. Otherwise, it sends a Discover Response and moves to Securing.
WTP: the WTP has received a discover response from an AC. If that response isn't valid, the WTP goes back to Discovering. If it is valid, the WTP sets the abandon timer to a suitable value so it can wait for a DTLS exchange ⏰. If the timer goes off while the WTP is in Acquiring, it goes back to Discovering. If a DTLS "client hello" shows up, the WTP moves to Securing and cancels the abandon timer 💫.
Securing 🔐
AC: the AC does the "client end" of the DTLS exchange 🤝. If anything goes wrong in the DTLS exchange, the AC drops back to Discovering. When the DTLS exchange finishes, the AC moves on to the Negotiated Control Protocol.
WTP: the WTP does the "server end" of the DTLS exchange 🛡️. If anything goes wrong in the DTLS exchange, the WTP drops back to Discovering. When the DTLS exchange finishes, the WTP moves on to the Negotiated Control Protocol.
Negotiated Control Protocol 👑
AC: the AC does its side of the protocol that was agreed on during the discovery process 💅. For the SLAPP 802.11 Control Protocol, check out Section 6.1. For the Image Download Protocol example, see Section 6.2.
WTP: the WTP does its side of the protocol that was agreed on during the discovery process 💖. For the SLAPP 802.11 Control Protocol, check out Section 6.1. For the Image Download Protocol example, see Section 6.2.
4.2. Format of a SLAPP Header 🎀
Every single SLAPP packet starts with the same header, shown in Figure 4 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SLAPP HeaderHere's what's inside 🍓
- Maj (4 bits): the major number of the SLAPP version
- Min (4 bits): the minor number of the SLAPP version
- Type (1 octet): the type of SLAPP message
- Length (two octets): the length of the SLAPP message, including the entire SLAPP header
These are the types of SLAPP messages that have been defined 📋
name type
----- ------
discover request 1
discover response 2
image download control 3
control protocol packet 4
reserved 5-2554.3. Version 🦋
SLAPP messages carry a version written as major.minor. This document describes version 1.0 of SLAPP, so the major version is one (1) and the minor version is zero (0) ✨
Major versions go up when the format of a SLAPP message changes, or when its meaning changes so much that an older, existing version of SLAPP couldn't parse it properly. Minor versions go up when some incremental additions have been made to SLAPP that boost its capabilities or pass along extra info, without changing the format or meaning of the SLAPP message 🌈
Future versions of SLAPP MAY NOT have to support earlier major versions of SLAPP, so an implementation MUST NOT assume that a peer which supports version "n" will also support version "n - i" (where both "n" and "i" are non-zero integers and "n" is greater than "i") 🙈
A SLAPP implementation that gets a SLAPP message with a higher major version number MUST drop that message 🚫. A SLAPP implementation that gets a SLAPP message with a lower major version SHOULD drop down to the version of SLAPP the peer supports. If that version of SLAPP isn't supported, the message MUST be dropped. Still, there may be valid reasons a peer wants to drop a SLAPP message even when its major version is supported 🤷♀️
A SLAPP implementation that gets 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 it will necessarily not support whatever incremental capabilities were added to justify the bump in the minor version 🫠. A SLAPP implementation that gets a SLAPP message with a lower minor version MUST NOT drop that message either. It SHOULD revert back to the minor version the peer supports, and it should not include any of the incremental capabilities that were added to justify the bump in the minor version 💅
4.4. Retransmission 🔁
SLAPP is a request response protocol 💬. Discovery and security handshake requests come from the WTP, and the AC sends the responses. Image Download packets are started by the AC and acknowledged by the WTP (in a negative fashion, see Section 6.2) 🫶
Only the initiator of a packet handles retransmissions 🙌. After each packet that needs a response is sent, the sender MUST set a retransmission timer and resend the packet when it expires. The receiver MUST be able to either regenerate a previous response when it gets a retransmitted packet, or cache a previous response and resend it when it gets a retransmitted packet 💖
The retransmission timer MUST be configurable and default to one (1) second ⏱️. This version of SLAPP doesn't specify any maximum or minimum for the timer.
Each time a retransmission happens, a counter SHOULD be incremented 🔢. The number of retransmissions a sender tries before giving up and declaring a SLAPP failure SHOULD be four (4). In other words, the number of attempts made for each packet before declaring failure is five (5) 💅
The exception to all this is Image Download packets, since the WTP doesn't acknowledge each one individually (see Section 6.2). The final packet gets acknowledged, and lost packets are reported through Image Download Requests 🌸
4.5. Discovery 🔎
When a WTP boots up and wants to work with an Access Controller so the AC can configure it, one of the very first things it has to do is discover one or more ACs in its network neighborhood 🏘️. This section has all the details on that discovery mechanism.
As described in Section 3, an AC and a WTP could live 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 (like an AC and a WTP separated by a wide-area public network 🌍). So any proposed discovery mechanism should have provisions that let a WTP discover an AC across all of these topologies ✨
We assume that a WTP, before it starts the discovery process, has already obtained an IP address on its wired segment 🔌
4.5.1. SLAPP Discover Request 📡
The SLAPP discovery process starts 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 before the WTP boots up or learned during the boot-up sequence) a unicast IP address. If there's no response to one discovery method, the WTP SHOULD try another method of discovery 🔄. The SLAPP discover request packet is a UDP packet addressed to port [TBD], which is designated as the SLAPP discovery port. The source port can be any random port 🎲. The payload of the SLAPP discover request packet is shown in Figure 5 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maj | Min | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Identifier (continued) | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP HW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP SW Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n controltypes| control type | . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SLAPP Discover Request4.5.1.1. Transaction ID 🪪
The transaction ID is a randomly generated, 32-bit number that stays the same during one phase of the SLAPP discovery process 🎰. A WTP generates it when it starts a discovery process. If one discovery method fails to find an AC and the WTP tries a different one, it MUST NOT re-use the Transaction ID 🚫. Every AC that intends to respond to a SLAPP discover request must use the same value for this field as in the request frame 💜.
4.5.1.2. WTP Identifier 🏷️
This field lets the WTP give itself a unique identifier. It MAY be, for instance, its 48-bit MAC address, or it could be any other string, like a serial number ✨
4.5.1.3. Flags 🚩
The Flags field indicates certain things about the discover request. For example, bit 0 in the Flags field shows 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 discover mode if the SLAPP discover request packet is being sent to a broadcast or multicast address. Here are the valid values for the 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 receiver4.5.1.4. WTP Vendor ID 🏢
This 32-bit field is the WTP vendor's Structure of Management Information (SMI) enterprise code, in network octet order. These enterprise codes can be obtained from, and registered with, IANA 🌐
4.5.1.5. WTP HW Version 🛠️
This 32-bit field indicates the version of hardware present in the WTP. The WTP vendor gets to decide this number completely 🎀
4.5.1.6. WTP SW Version 💻
This 32-bit field indicates the version of software present in the WTP. The WTP vendor gets to decide this number completely too 🦄
4.5.1.7. Number of Control Types 🧚
This 8-bit field tells you how many 8-bit control protocol indicators come right after it, so it basically counts how many different control protocols the WTP can handle 💅. This number MUST be at least one (1).
4.5.1.8. Control Types 🎀
This 8-bit field says which control protocol the WTP supports and is willing to use when it talks to an AC. There MAY be multiple "control type" indicators in a single SLAPP Discover Request ✨
Valid Control Types
-------------------
0 - RESERVED (MUST not be used)
1 - Image Download Control Protocol
2 - 802.11 SLAPP Control Protocol
3-255 - RESERVED (to IANA)4.5.2. SLAPP Discover Response 🦋
An AC that gets a SLAPP discover request packet from a WTP can choose to answer with a SLAPP discover response packet. Here's what that packet looks like, 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 ResponseThe SLAPP discover response is a UDP packet, and it's always unicast to the WTP's IP address 📮 The source IP address is the AC's, since the AC is the one sending it. 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 in the SLAPP discover request. The Status field tells the WTP whether the AC is accepting the discover request and is willing to let the WTP move on to the next stage (ACK), or whether it's turning down the WTP's earlier request (NACK) 🙈 The AC also puts its own vendor ID, hardware version, and software version in the response 💜
4.5.2.1. Transaction ID 🌸
The Transaction ID field should be identical to what was in the SLAPP discover request packet the WTP sent.
4.5.2.2. WTP Identifier 🍓
This is the WTP Identifier that was sent in the matching SLAPP discover request frame.
4.5.2.3. Flags 🫶
This field isn't used by this version of SLAPP 🙃 It MUST be set to zero (0) when it's sent, and it gets ignored when it's received.
4.5.2.4. AC Vendor ID 🔥
If the Status field is a 1, meaning the AC is sending a successful response, then this field and the next two are valid. The 32-bit AC Vendor ID points to the AC's vendor ID. If the Status field is not 1, this field should be set to 0 by the AC and ignored by the WTP.
4.5.2.5. AC HW Version 🌈
If the Status field is 1, this 32-bit field holds the AC's hardware version, which the AC vendor picks. If the Status field is not 1, this field should be set to 0 by the AC and ignored by the WTP.
4.5.2.6. AC SW Version 🍓
If the Status field is 1, this 32-bit field holds the AC's software version, which the AC vendor picks. If the Status field is not 1, this field should be set to 0 by the AC and ignored by the WTP.
4.5.2.7. Control Type 👑
This is the control type the AC will use to talk to the WTP. This value MUST match one of the control types passed in the matching SLAPP Discover Request. No mixing and matching 🙅♀️
4.6. SLAPP Discovery Process 🧭
4.6.1. WTP 🛜
There are a few different ways a WTP can find an AC, and it's giving options 😭
- Static configuration: An administrator can set an AC's IP address in the WTP's non-volatile memory before the WTP gets deployed. If that's the case, the SLAPP discover request packet is sent to that configured IP address.
- DHCP options: As part of the DHCP response, the DHCP server could be set up to use option 43 to hand over the IP address of an AC that the WTP should send its SLAPP discover request packet to. If the DHCP response gives the WTP an AC's IP address, then the WTP should address the SLAPP discover request packet to that IP address.
- DNS configuration: Instead of putting a static IP address in the WTP's non-volatile memory, an administrator can set up a Fully-Qualified Domain Name (FQDN) for an AC. If an AC's FQDN is configured, the WTP asks its configured DNS server for the IP address that goes with that FQDN. If the DNS query works and the WTP gets an AC's IP address from the DNS server, then the discover request packet above is addressed to that AC's unicast address 🌐
- Broadcast: The WTP sends a discover request packet to the broadcast IP address, with the WTP's own IP address as the source. If necessary, a network administrator could set up the default router for the WTP's subnet with a helper address, which unicasts it to any address on a different subnet 📡
- IP Multicast: A WTP can send the payload above to a SLAPP IP multicast address [TBD] 🎶
- DNS: If no DNS FQDN is configured on the WTP, and the WTP can't find an AC using any of the methods above, then it should try asking the DNS server for a well-known FQDN for an AC [TBD]. If that DNS query succeeds, then the WTP should address the SLAPP discover request packet to the AC's unicast address 🧚
The whole process goes in the order 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"
SLAPP discovery restart:
Set timer for SLAPP discovery idle timer
When timer expires, go to "SLAPP discovery start"
done:
Go to the next step
Figure 74.6.2. AC 🤝
When an AC gets a SLAPP discover request, it has to decide whether it wants to acquire the WTP. An AC MAY only agree to acquire WTPs whose WTP Identifiers are statically configured in its configuration. Or, an AC that's happy to acquire WTPs gratuitously MAY accept any request that's waiting on authentication. An AC MUST only choose to acquire WTPs that speak a common Negotiated Control Protocol, but other factors can influence its decision too 🌟 For instance, if the Negotiated Control Protocol is the Image Download protocol defined in this memo, the AC MUST NOT acquire a WTP that it doesn't have a compatible image for to download, as determined by the WTP's HW Vendor ID, HW Version, and Software Version. Whatever it decides, the AC MUST respond one of two ways:
- The AC sends a SLAPP discover response indicating its agreement to acquire the WTP 🎉
- The AC silently drops the SLAPP discover request and doesn't respond at all 🙈
5. Security Association ✨
Once an AC has been discovered by a WTP and has agreed to acquire it (by sending a Discover Response), it will start a DTLS [6] [8] exchange with the WTP by taking on the role of the "client". The WTP takes on the role of the "server". The port used by both the WTP and the 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, where 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 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 make both parties abandon the exchange 💀 The AC SHOULD blacklist this WTP for a period of time, so a misconfigured WTP can't keep discovering and failing authentication over and over. The WTP MUST return to the SLAPP discovery state to find another suitable AC to start a DTLS exchange with.
Once the DTLS handshake has succeeded, the WTP and AP move into "image download state" and protect all further SLAPP messages with the DTLS-negotiated cipher suite 🦋
5.1. Example Authentication Models (Informative) ✨
okay so any valid cipher suite from [7] can be used to authenticate the WTP and/or the AC 🔐 different situations need different auth models, and the examples here are just illustrations, not a complete list 💅
neither side usually has a human sitting there, so username/password auth is a no-go 🙅♀️ and zero-config WTP deployments can narrow down which auth options are even on the table 🫶
5.1.1. Mutual Authentication
mutual auth means the WTP checks the AC, so it knows it's connecting to a trusted AC 🛡️ and the AC checks the WTP, so it knows the WTP that's connecting is a trusted one ✨
this is usually done with certificates on both the WTP and the AC 📜 they prove each party owns its public key, and a Certification Authority (a trusted third party) signs them 🖋️
enrolling each WTP with a Certification Authority is outside the scope of this doc 🙈 but heads up, a manufacturer's Certification Authority isn't always enough 😬 it only proves a WTP or AC came from a certain company, and it can't tell a trusted WTP apart from an untrusted WTP that was bought from the same maker as the AC 💀
5.1.2. WTP-Only Authentication
some deployments only need the WTP to authenticate to the AC, not the other way around 🎀
here the WTP has a keypair that uniquely identifies it (a certificate, for example) 🪪 and that keypair gets used in a "server-side authentication" [7] exchange ✨
this model doesn't authenticate the AC, so a rogue AC could claim control of a valid WTP 😱 but it's lowkey not the end of the world, since the WTP can only provide service for networks that the rogue AC makes available 🌸 no unauthorized network access is possible 🙌
5.1.3. Anonymous Authentication
in some deployments, it MAY just be necessary to stop casual snooping of packets 👀 in that case, an unauthenticated but encrypted connection can be enough 🔒 usually a Diffie-Hellman exchange happens between the AC and WTP, and the resulting unauthenticated key is used to encrypt the traffic between them 🦋
6. SLAPP Control Protocols 🧚
in this section we go over two extensions for SLAPP 💜 one is specific to 802.11 WLANs, and the other is a technology-neutral protocol that lets an AC download a bootable image to a WTP 💾
6.1. 802.11 Control Protocol for SLAPP 📡
this section covers a SLAPP extension aimed at WTPs and ACs that implement the IEEE 802.11 WLAN standard 📶 it holds all the technology-specific bits an AC needs to control and manage 802.11 WTPs 🎀
6.1.1. Supported CAPWAP Architectures
the CAPWAP architecture taxonomy document [2] describes several architectures used in the WLAN industry today 🏗️ there's a huge range of variation in those architectures, but supporting every single variation or choice would make the protocol and negotiation phase way too complex 😵💫 so to keep the 802.11 part manageable, the negotiation is limited to four architectural choices, listed below:
- Local MAC, bridged mode: this falls under the Local MAC architecture 🌉 the 802.11 MAC is terminated at the WTP, and the WTP runs an L2 bridge that forwards packets between its WLAN interface and its Ethernet interface 🔁
- Local MAC, tunneled mode: this is also Local MAC, with the 802.11 MAC terminated at the WTP 🏠 the difference from the previous mode is that here 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 falls under the Split MAC architecture ✂️ the 802.11 MAC is split between the WTP and the AC, and the exact split is described in Section 6.1.1.2 🧩 the L2 crypto functions are the ones the WTP implements to handle this function, whether or not the AC can also do it 🔐 the WTP tunnels L2 frames to the AC using the mechanisms defined in Section 6.1.2 🫶
- Split MAC, L2 crypto at AC: this is also Split MAC 💫 the difference from the previous one is that the L2 crypto functions in the AC are used for this function, no matter whether those functions are also available at the WTP 👑 the WTP tunnels L2 frames to the AC using the mechanisms defined in Section 6.1.2 🦋
6.1.1.1. Local MAC
the Local MAC architecture, as documented in the CAPWAP architecture taxonomy document [2], does all 802.11 frame processing at the WTP 🖥️ the conversion from 802.11 to 802.3 and back also happens at the WTP 🔄 that means other jobs like fragmentation/reassembly of 802.11 frames and encryption/decryption of 802.11 frames are handled at the WTP too 💪
6.1.1.1.1. Bridged Mode
in this sub-mode of Local MAC, 802.11 frames get converted to 802.3 frames and bridged onto the WTP's Ethernet interface 🌈 these frames may carry 802.1Q VLAN tags assigned by the AC 🏷️
6.1.1.1.2. Tunneled Mode
in this sub-mode of Local MAC, 802.11 frames get converted to 802.3 frames and tunneled (using the tunneling mechanism in Section 6.1.2) to the AC the WTP is attached to 🚇 these frames may carry 802.1Q VLAN tags assigned by the AC 🎀
6.1.1.2. Split MAC
in Split MAC, the MAC functions of an 802.11 AP are split between the WTP and the AC ✂️ the exact split depends on the sub-modes covered in this section 🧩 either way, frames get tunneled to the AC using the mechanism in Section 6.1.2 🚇
some Split MAC setups convert 802.11 frames into 802.3 frames, which may be 802.1Q-tagged with tags the AC assigns 🏷️ others tunnel the whole 802.11 frame to the AC 📦 the AC and WTP agree on which type of frame gets tunneled during control protocol registration in Section 6.1.3 🤝
6.1.1.2.1. L2 Crypto at the WTP
for this sub-mode of Split MAC, the 802.11 AP functions are split like this 🍰
at the WTP:
802.11 control frame processing
802.11 encryption and decryption
802.11 fragmentation and reassembly
Rate Adaptation
802.11 beacon generation
Power-save buffering and Traffic Indication Map (TIM) processingat the AC:
802.11 Management frame processing
802.11 DS and portalSplit MAC implementations of this kind may tunnel either 802.11 or 802.3 frames between the AC and the WTP 🔀
6.1.1.2.2. L2 Crypto at the AC
for this sub-mode of Split MAC, the 802.11 AP functions are split like this 🧁
at the WTP:
802.11 control frame processing
Rate Adaptation
802.11 beacon generation
Power-save buffering and TIM processingat the AC:
802.11 Management frame processing
802.11 encryption and decryption
802.11 fragmentation and reassembly
802.11 DS and portalSplit MAC implementations of this kind tunnel 802.11 frames between the AC and the WTP 🫧
6.1.2. Transport 🚚
the 802.11 Control Protocol has two parts: one carries the specific control and provisioning messages, and the other tunnels data traffic from the WTP to the AC 📬
the SLAPP 802.11 Control Protocol uses Generic Routing Encapsulation (GRE) [4] to encapsulate L2 frames 🎁 depending on whether and how an architecture splits its MAC, some architectures tunnel 802.11 frames straight to the AC while others tunnel 802.3 frames, which may optionally be 802.1Q-tagged with tags the AC assigns 🏷️
IP is the delivery mechanism for these GRE packets 🌐 so the IP protocol number of the outer packet is 47, which tells you 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 the issues around fragmentation and reassembly are handled by [5] 🧩
6.1.2.1. SLAPP 802.11 Control Protocol Header 📋
when using the 802.11 Control Protocol, the SLAPP message type is four (4), which means "control protocol packet" 🎯 in this case, a two (2) octet field gets appended to the SLAPP header to show the control protocol type, as in Figure 8 ✨ the SLAPP 802.11 Control Protocol happens in the "Negotiated Control Protocol" phase of Section 4.1, so all its messages are secured by the security association created right before entering that phase 🔐
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 Control Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SLAPP Control Protocol Headerthe valid 802.11 Control Protocol Types are below, and yes, every single one matters 👑
1 : Registration Request - sent from WTP to AC
2 : Registration Response - sent from AC to WTP
3 : De-Registration Request - sent by either WTP or AC
4 : De-Registration Response - sent by the recipient of the
corresponding request
5 : Configuration Request - sent by WTP to AC
6 : Configuration Response - sent by AC to WTP
7 : Configuration Update - sent by AC to WTP
8 : Configuration Acknowledgment - sent by the WTP to AC
9 : Status Request - sent by the AC to the WTP
10 : Status Response - sent by the WTP to the AC
11 : Statistics Request - sent by the AC to the WTP
12 : Statistics Response - sent by the WTP to the AC
13 : Event - sent by the WTP to the AC
14 : Keepalive - sent either way
15 : Key Config Request - sent by the AC to the WTP
16 : Key Config Response - sent by the WTP to the AC6.1.3. Provisioning and Configuration of WTP 🎀
Okay bestie, so all the basic config stuff happens per ESSID, per radio in a WTP 💖 Some WTPs MAY support more than one ESSID per radio, but every WTP MUST support at least one ESSID per radio, and that one can be treated as the primary ESSID if there are several 👑 All the per-WTP stuff, like how many radios it has, gets sorted out during discovery and initialization ✨
Provisioning the regulatory domain is totally out of scope for this doc 🙈 Once a WTP is provisioned for a specific regulatory domain, it MUST restrict its operational modes, channel, transmit power, and any other necessary limits based on what its software image and hardware can do 💅 The WTP MUST also tell the AC what it can do, limited by both the regulatory domain and its hardware (if any), during the capability exchange 🫶
Assigning BSSIDs to the primary interface and to the virtual access point (AP) interfaces, if supported, is also outside the scope of this document 🦋
6.1.3.1. Information Elements
Information elements (IEs) are how the AC and the WTP share capability, configuration, status, and statistics info 📦
6.1.3.1.1. Structure of an Information Element
Here's how an information element is laid out 🧩 It starts with an element ID octet, then a 1-octet length, then the value, whose length is whatever the Length field says. An element can be at most 255 octets 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.1.3.1.2. CAPWAP Mode
This element defines the MAC architecture modes (Section 6.1.1) 🌈
Element ID : 1
Length : 1
Value : The following values are defined.
Bit 0 : CAPWAP mode 1 - Local MAC, bridged mode
Bit 1 : CAPWAP mode 2 - Local MAC, tunneled mode
Bit 2 : CAPWAP mode 3 - Split MAC, WTP encryption, 802.3 tunneling
Bit 3 : CAPWAP mode 4 - Split MAC, WTP encryption, 802.11
tunneling
Bit 4 : CAPWAP mode 5 - Split MAC, AC encryption, 802.11 tunneling
Bits 5-7 : Set to 0When this element shows up in the capabilities message, a set bit means the WTP supports that CAPWAP mode 🍓 When it's used in configuration and status messages, then exactly one of bits 0-4 MUST be set 🎯
6.1.3.1.3. Number of WLAN Interfaces
This element tells you how many 802.11 WLANs the WTP has 📶
Element ID : 2
Length : 1
Value : 0-2556.1.3.1.4. WLAN Interface Index
This one points at a particular WLAN interface when it's used in configuration and status messages 🧭 When it's inside a recursion element, the elements nested in it line up with the WLAN interface named here 🪆
Element ID : 3
Length : 1
Value : 0 - (Number of WLAN interfaces - 1)6.1.3.1.5. WLAN Interface Hardware Vendor ID
This is the WLAN interface hardware vendor's SMI enterprise code, in network octet order (you can get these codes from IANA and register them there too) 🏷️ It shows up once for each WLAN interface on the WTP 🔁
Element ID : 4
Length : 4
Value : 32-bit value6.1.3.1.6. WLAN Interface Type ID
This is an ID that the WLAN interface hardware vendor assigns to say what type of WLAN interface it is 🛠️ The vendor controls it, and the range of possible values is beyond the scope of this document 🙃 It appears once for each WLAN interface on the WTP 💫
Element ID : 5
Length : 46.1.3.1.7. Regulatory Domain
If the WTP has a regulatory domain provisioned, it says so by including this element in the capabilities list 🌍 If that info isn't available at the WTP, then this element SHOULD not be included in the capabilities list 🤷♀️ How the info gets provisioned into the WTP is beyond the scope of this document 🚫
Element ID : 6
Length : 4
Value : ISO code assigned to the regulatory domain6.1.3.1.8. 802.11 PHY Mode and Channel Information
This element lists the 802.11 Physical Layer (PHY) modes the WTP supports, along with the channels and maximum power level for each mode 📡 It shows up once per WLAN interface on the WTP, and there can be several copies if that 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:
0 : Radio Disabled/Inactive
1 : IEEE 802.11b
2 : IEEE 802.11g
3 : IEEE 802.11a
4-255 : Reserved
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 gives the desired or current operating power level 🔋 The Channel field has exactly one 2-octet value for the desired or current operating frequency 📻
6.1.3.1.9. Cryptographic Capability
In the capabilities message, this element lists the cryptographic algorithms the WTP supports 🔐 It shows up once for each WLAN interface on the WTP 🔑 In configuration and status messages, it shows the cryptographic capabilities that are configured at the WTP ⚙️
Element ID : 8
Length : 1
Value : The following bits are defined:
Bit 0 : WEP
Bit 1 : TKIP
Bit 2 : AES-CCMP
Bits 3-7 : Reserved6.1.3.1.10. Other IEEE 802.11 Standards Support
This element is a bitmap showing which IEEE 802.11 standards the WTP supports 🧃
Element ID : 9
Length : 4
Value : A bitmap as follows:
Bit 0 : WPA
Bit 1 : 802.11i
Bit 2 : WMM
Bit 3 : WMM-SA
Bit 4 : U-APSD
Bits 5-32 : Reserved6.1.3.1.11. Antenna Information Element
In the capabilities message, this element is formatted like this 📶✨
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 : ReservedIn configuration and status messages, this element is formatted like this instead 🎛️
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.
Bits 9-31 : Reserved6.1.3.1.12. Number of BSSIDs
This element tells you how many BSSIDs the WLAN interface supports 🪪 It's optional in the capabilities part of the registration request message, and if it's missing, the number of BSSIDs is set to 1 🙌 It appears once for each WLAN interface on the WTP 🔁
Element ID : 11
Length : 1
Value : The number of BSSIDs that the WLAN interface is capable of
supporting.6.1.3.1.13. BSSID Index
This one is used when you're sending config or status for one specific BSSID on the WTP 🎯
Element ID : 12
Length : 1
Valid values are from 0 to (Number of BSSIDs -1)6.1.3.1.14. ESSID
This element is used in configuration and status messages, either to set the ESSID on a certain BSSID or to report the value it's currently operating with 📣
Element ID : 13
Length : Variable, between 0 and 32 both inclusive.
Value : Variable, contains ASCII characters.There is no default value for this parameter 🫥
6.1.3.1.15. ESSID Announcement Policy
This element is used in configuration and status messages to control whether the ESSID gets announced in 802.11 beacons 📢 For the Local MAC modes of operation, this field also controls 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.
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.
Bit 2-7 : Reserved6.1.3.1.16. Beacon Interval
This element configures the beacon interval on a BSSID on the WTP ⏰
Element ID : 15
Length : 2
Value : Valid values for the beacon interval as allowed by IEEE
802.11The default value for this parameter is 100 💯
6.1.3.1.17. DTIM period
This element configures the DTIM period on a BSSID that's present on the WTP 🕰️
Element ID : 16
Length : 2
Value : Valid values for the DTIM period as allowed by IEEE
802.11.The default value for this parameter is 1 🌟
6.1.3.1.18. Basic Rates
This element configures, or reports, the 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.
Bit 0 : 1 Mbps
Bit 1 : 2 Mbps
Bit 2 : 5.5 Mbps
Bit 3 : 11 Mbps
Bit 4 : 6 Mbps
Bit 5 : 9 Mbps
Bit 6 : 12 Mbps
Bit 7 : 18 Mbps
Bit 8 : 24 Mbps
Bit 9 : 36 Mbps
Bit 10 : 48 Mbps
Bit 11 : 54 Mbps
Bits 12-31 : Reserved6.1.3.1.19. Supported Rates ✨
Okay so this one is all about configuring the set of basic rates 🎀 (the title says Supported Rates, but the purpose line says basic rates, iykyk 💅). It can also be used to report the configured set back.
Element ID : 18 Length : 4
The value is a bitmap, and each bit maps to one rate. If a bit is set, that rate gets configured as a supported rate. If it's reset, the rate does NOT get configured as a supported rate. Here's the lineup:
Bit 0 : 1 Mbps
Bit 1 : 2 Mbps
Bit 2 : 5.5 Mbps
Bit 3 : 11 Mbps
Bit 4 : 6 Mbps
Bit 5 : 9 Mbps
Bit 6 : 12 Mbps
Bit 7 : 18 Mbps
Bit 8 : 24 Mbps
Bit 9 : 36 Mbps
Bit 10 : 48 Mbps
Bit 11 : 54 Mbps
Bits 12-31 : Reserved6.1.3.1.20. 802.11 Retry Count 🔁
This element configures the long and short retries for each BSSID on the WTP. Every BSSID gets its own settings, so it's giving organized 🦋
Element ID : 19 Length : 2
Bits 0-7 : Short retry count, default value is 3.
Bits 8-15 : Long retry count, default value is 3.6.1.3.1.21. Fragmentation Threshold 🧩
This one sets the fragmentation threshold on a BSSID that's on the WTP. Simple, but it matters 💖
Element ID : 20 Length : 2
The value is whatever the fragmentation threshold can be according to IEEE 802.11. The default is 2346.
6.1.3.1.22. RTS Threshold 🚦
This element configures the Request to Send (RTS) threshold on a BSSID that's on the WTP. Main character energy for the RTS threshold, honestly 👑
Element ID : 21 Length : 2
The value is any valid RTS threshold allowed by IEEE 802.11. The default is 2346.
6.1.3.1.23. Short/Long Preamble 🌙
This one picks the preamble type used for transmission in 802.11b mode.
Element ID : 22 Length : 1
0 : Disable Short preamble
1 : Enable Short preamble
2-255 : ReservedThe default for this parameter is 0.
6.1.3.1.24. 802.1Q Tag 🏷️
This element configures the tagging for packets that belong to a particular SSID. The tagging happens when traffic moves 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 it's in CAPWAP mode 1. Tagging is so important, bestie 🫶
Element ID : 23 Length : 2 Value : 802.1Q tag
If this element is absent from the configuration, the WTP MUST assume that no tagging is required. It should still expect to receive untagged frames on frames destined towards the wireless interface.
6.1.3.1.25. SLAPP Registration ID 🪪
A successful registration response from an AC to a WTP MUST contain this element. The WTP and the AC use it in messages between them for every other message while the registration is active. It's the ID card of the registration, no cap 😭
Element ID : 24 Length : 4 Value : A 32-bit unsigned number allocated by the AC
6.1.3.1.26. WTP Name 📛
The AC uses this element to give the WTP a string of ASCII characters as its name. Cute name energy 🌈
Element ID : 25 Length : Variable, between 0 and 64 both inclusive Value : A variable length string of ASCII characters
6.1.3.1.27. Event Filter 🎯
The AC uses this element to decide how important events are, to turn notifications on or off, and to set the global notification policy. When the Event Identifier is 0, this element acts as a global notification policy message, and the bitmap says which kinds of events need the WTP to generate a notification. When the Event Identifier is non-zero, the element configures one specific event and its importance level. Exactly one bit in the bitmap sets that importance level. If none of the bits are set, the element should be interpreted as a cancellation request, and the WTP should stop sending notifications for the event named in the Element Identifier. Lowkey a whole mood 💜
Element ID : 26 Length : 4 Value : Defined as follows:
Bits 0 - 15: Event Identifier
Bit 16: Fatal - The system is not usable.
Bit 17: Alert - Immediate action is required.
Bit 18: Critical
Bit 19: Error
Bit 20: Warning
Bit 21: Notification
Bit 22: Informational
Bit 23: Debug
Bits 24 - 31: Reserved6.1.3.1.28. Radio Mode 📡
The AC uses this element to say what mode the radio is in for each WLAN interface. On or off, basically 💅
Element ID : 27 Length : 1 Value : The following are valid values:
0 : Radio is disabled
1 : Radio is enabled
2-255 : Reserved6.1.3.1.29. IEEE 802.11e Element 🎶
The AC uses this element to configure 802.11e functions at the WTP. The value is a bitmap, and the bits are these:
Element ID : 28 Length : 4 Value : A bitmap as follows:
Bit 0 : WMM
Bit 1 : WMM-SA
Bit 2 : U-APSD
Bits 3-32 : Reserved6.1.3.1.30. Configuration Statistics 📊
This element reports the statistics for configuration and registration events as the WTP sees them. It's the receipts for everything that happened during setup 🧾
Element ID : 29 Length : 32 Value : The value is as follows:
- Configuration Requests : 4 octets - Number of Configuration Request messages sent by the WTP since the last reboot or reset of the counters.
- Configuration Responses : 4 octets
- Configuration Updates : 4 octets
- Configuration ACKs : 4 octets
- Registration Requests : 4 octets
- Registration Responses : 4 octets
- De-Registration Requests : 4 octets
- De-Registration Responses : 4 octets
6.1.3.1.31. Transmit Frame Counters 📤
This information element holds a set of counters for the transmit side of the wireless link at the WTP. The counters apply to either a BSS or an Access Category, but the Access Category part only happens if Wireless Multimedia (WMM) is enabled. Lots of numbers, lots of tea ☕
Element ID : 30 Length : 112 octets Value : The value of this element is defined as follows:
- Total received from the network : 4 octets
- Successfully transmitted frames (total) : 4 octets
- Successfully transmitted 802.11 Mgmt frames : 4 octets
- 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
- Frames dropped due to other reasons : 4 octets
- Fragments transmitted : 4 octets
- Fragments dropped : 4 octets
- Power-save multicast frames : 4 octets
- Power-save unicast frames : 4 octets
6.1.3.1.32. Received Frame Counters 📥
This information element covers all the statistics for frames the WTP receives. Like the transmit counters, these apply to either a BSS or an Access Category, with the Access Category part only if WMM is enabled. Receiving is the new sending 🦋
Element ID : 31 Length : 108 octets Value : The value of this element is defined as follows:
- Total Frames received : 4 octets
- 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
- Frames dropped due to other reasons : 4 octets
6.1.3.1.33. Association Statistics 👯
This element is about the stations that are currently associated with the BSS. Who's in the group chat right now? 👀
Element ID : 32 Length : Variable Value : The value is defined as follows:
- Total association requests : 4 octets
- Total associations accepted : 4 octets
- Total associations rejected : 4 octets
- Current associations : 4 octets
- For each associated station,
- Station MAC address : 6 octets
- Power save state : 1 octet
- Current Tx rate : 1 octet
- Rate of last packet : 1 octet
- Preamble type : 1 octet
- WMM/U-APSD state : 1 octet
6.1.3.1.34. Status Element 🚨
The status IE goes in the status response message the WTP sends to the AC. It has a set of fields that show the status of various states at the WTP, or at each BSS configured on the WTP. Status check, bestie ✅
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.
Noise Floor : 1 octetIf the ERP element doesn't apply, this field MUST be set to 0. Don't skip it, periodt 💀
6.1.3.1.35. Event Configuration 🎛️
The AC uses this element to pick which events it wants the WTP to notify it about. Customize your notifs, babe 💖
Element ID : 34 Length : 4 octets Value : The value is defined as follows:
- Radar Detection - 1 octet
- Bit 0 : 1 = notify on detecting radar interference, 0 otherwise.
- Bit 1 : 1 = notify of channel change due to radar interference, 0 otherwise.
- All other bits are reserved.
- Excessive Retry Event - 1 octet. Number of successive frames that have not been acknowledged by a client. A value of 0 disables notification.
- Noise Floor Threshold - 1 octet. Defines the threshold above which an event would be generated by the WTP.
- 802.11 Management and Action Frame Notification - 1 octet.
- Bit 0 : If set, notify the AC of Probe Requests from stations (please use with caution). If reset, then no Probe Response notification is needed.
- Bit 1 : If set, the WTP should notify the AC of all other management frames from stations.
- All other bits are reserved.
6.1.3.1.36. Radar Detection Event 📡⚡
The WTP uses this element to tell the AC that it detected radar interference, along with any channel changes that happened because of that detection. Radar drama 😭
Element ID : 35 Length : 10 octets Value : Defined as follows:
- BSSID : 6 octets. The BSSID of the WLAN interface that detected the radar interference.
- Channel : 2 octets. The channel on which radar interference was detected.
- New Channel : 2 octets. The new channel to which the WTP moved as a result of the detection of radar interference.
6.1.3.1.37. Excessive Retry Event 🔄
The WTP uses this element to flag excessive retry events on transmissions to an associated station. Not the retry drama again 🙈
Element ID : 36 Length : 14 octets Value : Defined as follows:
- Station MAC : 6 octets
- Associated BSSID : 6 octets
- Length of last burst of excessive retries : 2 octets.
6.1.3.1.38. Noise Floor Event 📡
Okay bestie, this one is how the WTP lets the AC know that the noise floor on one of its WLAN interfaces has gone over the noise floor threshold someone configured. The noise is literally too loud 🔊💀
Element ID : 37
Length : 10 octets
Value : Defined as follows:
BSSID : 6 octets
Current Channel : 2 octets
Current Noise Floor : 2 octets6.1.3.1.39. Raw 802.11 Frame 🦋
This one is giving generic capability. Either the WTP or the AC can send a raw 802.11 frame to the other side. For example, it can tell the AC about station association and disassociation events when you're running Local MAC architectures. Iconic 🫶
Element ID : 252
Length : Variable
Value : A raw 802.11 frame6.1.3.1.40. Vendor-Specific Element 🎀
Vendor-specific info gets passed between the WTP and the AC through this element. The value starts with a 3-octet Organizationally Unique Identifier (OUI), then comes a bunch of octets that belong to whichever vendor that OUI stands for 💅
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.6.1.3.1.41. Recursion Element 🧚
Main character energy: this element can define itself recursively, so it's a variable-length element that gets read as a series of other elements from this section. It's how you bundle a set of elements together and treat them as one unit 🌈
Element ID : 254
Length : Variable
Value : A variable length element that contains a set of one or
more elements defined in this section.6.1.3.1.42. Pad Element 🫶
This is the generic padding element, used to pad packets when it's needed. Here's the tea: it MUST be filled with all 0s at the source and it MUST be ignored at the destination 🙈
Element ID : 255
Length : Variable
Value : A variable-length element that MUST be filled with all 0s
at the source and MUST be ignored at the destination.6.1.3.2. SLAPP 802.11 Control Protocol Messages 🌸
6.1.3.2.1. Registration Request 💌
Okay so, when the SLAPP 802.11 Control Protocol starts, the WTP sends a registration request to whichever AC it authenticated with. The request carries a list of information elements that show the WTP's capabilities to the AC. The message starts with the SLAPP 802.11 Control Protocol header (Figure 8), and its SLAPP Control Protocol message type is 1 ✨
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: SLAPP 802.11 Registration RequestFlags : 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.These 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 supportThese information elements may optionally be included in the registration request:
For each WLAN interface:
4 : WLAN Interface HW Vendor ID
5 : WLAN Interface Type ID
6 : Regulatory Domain
10 : Antenna Information Element
11 : Number of BSSIDs
253 : Vendor-Specific Element6.1.3.2.2. Registration Response 🦋
Once the AC gets a registration request, it may either accept the WTP or reject its registration request. Your call, AC 👑
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Elements ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SLAPP 802.11 Registration ResponseFlags :
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:
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.These 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.
24 : SLAPP registration ID6.1.3.2.3. De-Registration Request 🌷
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SLAPP 802.11 De-Registration RequestFlags : Reserved
SLAPP Registration ID : The registration ID assigned by the AC
upon successful registration.
Reason Code : The following are valid values:
0 : Unspecified reason
1 : The device that is the source of the frame is going down.
All other values are reserved.6.1.3.2.4. De-Registration Response 🍓
This is basically a simple ACK from whoever gets the De-Registration Request 🫶
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SLAPP 802.11 De-Registration ResponseFlags : Reserved
SLAPP Registration ID : The registration ID assigned by the AC
upon successful registration.
Reason Code : The same reason code used in the corresponding
request.6.1.3.2.5. Configuration Request 🔥
The Configuration Request is how the WTP asks for a set of configurations for each BSS that the AC wants to configure at the WTP 🙌
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: SLAPP 802.11 Configuration RequestThe Information Element ID list field holds the list of IEs that the WTP wants configuration info for 🧚
6.1.3.2.6. Configuration Response 💜
The AC uses the Configuration Response to answer a Configuration Request from the WTP 💅
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SLAPP 802.11 Configuration ResponseThese information elements are mandatory in the Configuration Response:
01: CAPWAP mode
For each WLAN interface:
03: WLAN Interface Index
27: Radio Mode
07: 802.11 PHY mode and Channel Selection
For each BSSID:
12: BSSID Index
13: ESSID
08: Cryptographic SelectionThese information elements may optionally be included in the Configuration Response:
10: Antenna Information Element
25: WTP Name
For each WLAN interface:
For each BSSID:
14: ESSID Announcement Policy
15: Beacon Interval
16: DTIM Period
17: Basic Rates
18: Supported Rates
19: Retry Count
20: Fragmentation Threshold
21: RTS Threshold
22: Short/Long Preamble
23: 802.1Q Tag
253: Vendor-Specific ElementIf any of the optional IEs is absent from the Configuration Response, the WTP applies their default values 🌈
6.1.3.2.7. Configuration Update 💌
Okay so the Configuration Update is how the AC pushes new or updated config down to the WTP 💅 It's giving Configuration Response energy, same format, same vibe ✨
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: SLAPP 802.11 Configuration Update
The mandatory and optional IEs for this message are the same as the ones for the Configuration Response, so no re-learning needed 🫶
6.1.3.2.8. Configuration Acknowledgment 🙌
The Configuration Acknowledgment is how the WTP tells the AC whether it accepted the previous Configuration Update or Configuration Response 💖 The WTP can totally reject what the AC sent, and if it does, it MUST return to the discovery state 😭
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: SLAPP 802.11 Configuration ACK
The Status Code field can be one of these:
0: Success 🎉 The WTP accepts the configuration the AC pushed and has applied it.1: Failure 💀 The WTP did not accept the configuration the AC pushed, and it MUST be de-registered at the AC.
6.1.3.2.9. Status Request 🔍
The Status Request is how the AC asks the WTP for its configuration and operational status. Main character energy, no cap 👑
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element ID list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 17: SLAPP 802.11 Status Request
The Information Element ID list is the list of IEs the AC wants status for 📋
6.1.3.2.10. Status Response 📬
The Status Response is the WTP answering a status request from the AC 🫶
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 18: SLAPP 802.11 Status Response
The Flags field can be one of these:
- Bit 0 🚩 If set, it means Unknown AC or SLAPP registration ID. If this bit is reset, the response is a successful one.
- Bit 1 🚩 If set, the WTP is saying it hasn't been configured yet. Otherwise, the WTP is in a configured state.
All other values are reserved.
The status IE is mandatory in a status response message 💅
6.1.3.2.11. Statistics Request 📊
The Statistics Request is how the AC asks the WTP for statistics info 🦋
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 19: SLAPP 802.11 Statistics Request
The Flags field contains these bits:
- Bit 0 🔄 If set to 1, the WTP should reset the counters after sending the statistics response message.
All other bits are reserved and MUST be set to 0 by the source and ignored by the destination.
6.1.3.2.12. Statistics Response 📈
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 12 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Information Element list ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 20: SLAPP 802.11 Statistics Response
The Flags field contains these bits:
- Bit 0 ✅ If set, the counters have been reset as the AC requested.
- Bit 1 ❌ If set, the WTP ran into a statistics request from either an unknown AC or one with an unknown SLAPP registration ID.
- Bit 2 🌙 If set, the WTP is saying it hasn't been configured yet. Otherwise, the WTP is in a configured state.
All other bits are reserved.
6.1.3.2.13. Keepalive 💓
Keepalives can be started by either the WTP or the AC. They're how you check if the other party is still around and if the path between you two is working 🦋 The first message is the keepalive request, and the reply is the keepalive response.
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 21: SLAPP Keepalive Packet
The Flags field has these values:
- Bit 0 💫 Set to 0 in a keepalive request message, and set to 1 in a keepalive response message.
- Bit 1 💫 Set to 0 in a keepalive request message. In a keepalive response message, set to 1 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.
6.1.3.2.14. Key Configuration 🔐
In CAPWAP mode 5, the 802.11 crypto functions are done at the AC, so there's 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, the AC does need to send both unicast and broadcast/multicast keys to the WTP. This happens after the 802.1x authenticator (which lives on the AC) has successfully authenticated the supplicant 🛡️
Key Configuration Requests are split into unicast or broadcast by setting or clearing the high-order bit of the "Flags" field 🎀 That bit decides what goes in the Key Configuration Request after the SLAPP Registration ID.
6.1.3.2.14.1. Unicast Key Configuration Request 🗝️
The Unicast Key Configuration Request is how the AC tells the WTP which key to use when protecting unicast frames to and from a given supplicant 💜
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast key length | unicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 22: Unicast Key Configuration Request
Note that the high-order bit of the "Flags" field is cleared to show a unicast key is being sent 🌸 The 802.1Q tag field tells the WTP which VLAN this supplicant is in, and which broadcast/multicast key to use when talking to it with broadcast/multicast frames ✨
6.1.3.2.14.2. Broadcast/Multicast Key Configuration Request ✨
Okay bestie, this is the group-chat key drop 🔑. The AC sends the shared broadcast/multicast key out to everyone in the room. Here's the layout 🎀
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 15 |1| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD | broadcast/multicast key length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ broadcast/multicast key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23: Group Key Configuration Request
Notice the high-order bit of the Flags field is set 🔥, which tells you 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 💅.
6.1.3.2.14.3. Unicast Key Configuration Response 🦋
So the WTP acknowledges a Unicast Key Configuration Request by sending back a Unicast Key Configuration Response 🫶. It mirrors the request, but it does not send back the key length or the key itself. (The RSVD bits are only returned for alignment purposes, and they MUST be set to zero by the WTP and ignored by the AC 🙈.)
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant MAC address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| supplicant mac address (cont) | Supp 802.1Q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 24: Unicast Key Configuration Response
6.1.3.2.14.4. Multicast Key Configuration Response 🌸
The WTP acknowledges a Multicast Key Configuration Request by sending a Multicast Key Configuration Response 💜. Same vibe as before: it 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 ✨.)
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 | 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16 |0| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLAPP Registration ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 801.1q tag | RSVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 25: Group Key Configuration Response
6.1.3.3. Monitoring and Statistics 📊
Okay so an AC might want to keep checking how healthy a WTP is 🩺, grab diagnostic info, and get pinged whenever certain predefined events happen at the WTP. This section defines a set of WTP statistics and events, and walks through how the AC collects those stats and sets up event notifications at the WTP. What the AC does with all that info is out of scope for this document, so that's a whole other slay 💅.
6.1.3.3.1. Statistics Collection Procedure 📈
This simple collection procedure is giving low-maintenance 💤. The WTP doesn't need to run any timers or anything similar. It's only responsible for keeping the statistics defined in Information Elements 29, 30, 31, and 32. When the AC sends a statistics request message, the WTP also has to answer by delivering those stats in a statistics response message 📬. If the AC wants periodic stats on something specific, the AC is the one who has to poll the WTP at the right intervals ⏰.
6.1.3.3.2. Events Procedure 🔔
The event notification process has two parts. First is Event Registration, where the AC registers the events it cares about at the WTP. Second is Notification, where the WTP sends the event-related info to the AC whenever the conditions for a registered event happen 🚨. The events a WTP supports, plus the event-specific parameters that can be configured as part of an event registration, are listed in Section 6.1.3.3.3 💖.
6.1.3.3.3. WTP Events 🌈
This section defines a set of WTP events, along with the event-specific parameters ACs can configure and the event-related info WTPs should deliver to ACs when a configured event's conditions occur 🎀.
- Radar Detection Event: Configure whether the AC wants a notification every time a radar event is detected 📡. The WTP may tell the AC about the type of radar interference and the new channel it moved to because of it (if any), using the Radar Detection Event Element (element ID: 35).
- Excessive Retry Event: Configure the number of consecutive transmission failures before a notification gets generated 🔁. The WTP may tell the AC 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 the WTP would generate an event notification 📶. The WTP may tell the AC the most recent measured noise floor that went over the configured threshold, using the Noise Floor Event Element (element ID : 37).
- De-Authentication Event: Configure whether the AC wants a notification whenever the WTP de-authenticates a station 👋. The WTP may tell the AC 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 🏚️.
6.1.4. Protocol Operation 🧠
Now for how the whole SLAPP 802.11 Control Protocol actually operates 🎬.
6.1.4.1. SLAPP 802.11 Control Protocol State Machine 🗺️
6.1.4.1.1. At the WTP 🛰️
Here's the WTP's state machine. Lowkey the most iconic diagram in the whole doc 😭.
+-------------+
| 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 ConfigFigure 26: SLAPP 802.11 Control Protocol at the WTP
6.1.4.1.1.1. State Machine Explanation 💅
okay so let's walk through the WTP's states one by one, bestie 🫶
Unregistered: we get here from the securing state (Figure 3) 🦋. The WTP sends a registration request message to move into the Registration Pending state, and sets a timer for the registration response ⏰.
Registration Pending: when a registration response comes back from the AC, the WTP cancels the registration timer ✨. If the response is successful, it moves to the Registered state 🎀. If not, it moves to the discovering state (Figure 3). If the timer expires, the WTP checks nTimeout. If nTimeout >3, it moves to the discovering state. If not, it goes back to the Unregistered state 🙈.
Registered: the WTP sends a Configuration Request message to the AC to move into the Configuration Pending state, and sets a timer for the Configuration Response 💜. While it's in this state, the WTP responds to status request, statistics request, and keepalive messages from the AC 🌸.
Configuration Pending: if a Configuration Response arrives from the AC, the WTP cancels the Configuration Response timer 🧚. If the response is successful and the configuration is acceptable, the WTP sends the Configuration ACK message to the AC and moves into the Configured state 👑. If the Configuration Request is rejected, or the configuration isn't acceptable, the WTP sends a de-register request to the AC and moves to the discovering state 💀. If the Configuration Response timer expires, the WTP moves to the Registered state, unless nTimeout >3, in which case it moves to the 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, it sends a de-register response to the AC and moves to the discovering state 😭. If the WTP receives a Configuration Update message, it moves to the Update Pending state ✨. If it gets too many consecutive keepalive failures (no responses from the AC to keepalive requests), it sends a de-register message to the AC and moves to the discovering state 🥀.
Update Pending: in this state, the WTP analyzes the configuration information it received in the Configuration Update message 🔍. If the configuration is acceptable, the WTP applies it and returns to the Configured state 🎀. If the WTP chooses to reject the configuration update, it sends a de-register request to the AC and moves to the discovering state 🙅♀️.
De-register: from the Configured state, the WTP moves into 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 AC 🧠
6.1.4.1.2.1. State Machine Explanation 🌈
the "securing" and "discovering" states are described in Figure 3, so check that out for those 👀
Unregistered: this state is entered from the securing state described in Figure 3 🌷. Here the AC is just waiting for a registration request message from the WTP. When it gets one, it moves into the Registration Processing state 📬.
Registration Processing: in this state, the AC has to decide whether or not it can accept the new WTP 🤔. If it does accept the WTP, it must pick a CAPWAP mode to operate in, send a registration response message with a success code, and move 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 arrives, the AC destroys the registration state and moves to the discovering state ⏳. If a Configuration Request message comes in from the WTP, the AC moves into the Registered state and processes that Configuration Request 🧃. It then 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 arrives from the WTP, 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, the AC again destroys the registration state and moves into the discovering state 😤. If the Configuration ACK from the WTP is successful, 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 🔑. If any response to these messages from the WTP indicates an unknown SLAPP registration ID or an unknown AC, the AC destroys any registration or configuration state and moves 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, 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, the AC moves into the discovering state 📉.
Update Pending: when the AC receives a Configuration ACK message with a success code, it returns to the Configured state 💅. If the status code is a failure, or if the timer expires before the Configuration ACK arrives 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 gets a bootable image from the AC by receiving a series of image transfer packets 📦. If the WTP misses any image data packets, it re-requests them by sending image data request packets that indicate the missing packets 🔁.
The image to download is divided into slices of equal size, except for the last slice. The last slice can be smaller than the slice size provided, but it's still 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 are 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: variableRESERVED: unused in this version of SLAPP. It 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) octetsRESERVED: unused in this version of SLAPP. It MUST be zero on transmission and ignored upon receipt 🫧.M: the "More" bit. This MUST be equal to 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 🍰
okay so the AC chops the bootable image into a bunch of slices and sends each slice in its own Image Download packet 📦. How big each slice is (and so how big each packet is) depends on the MTU of the connection, which gets sorted out during the DTLS handshake 🤝. Every time a slice goes out, the AC MUST increment the packet sequence number 🔢.
Image Download packets are negatively ACK'd, which is such a vibe 🙃. The AC MUST NOT assume anything about whether packets arrived ❌. It just sends, then reacts to negative ACKs.
now, you might think that since the packets go out in order, a request to resend packet "n" means everything before it, "n - 1" and down, got ACK'd implicitly 🤔. Nope, bestie! Earlier retransmission requests could have been dropped too 💀.
The Image Download process kicks off when the WTP asks for the packet with sequence number zero (0) 🚀. The AC sets the packet sequence counter for that WTP to one (1) and sends the first slice. The "Request" bit on that first slice MUST be set to zero (0), because technically nobody asked for it 🙈.
The WTP runs a periodic timer ⏰. Whenever it fires, the WTP sends Image Download Requests for slices that went missing since the last time it fired. Since individual Image Download packets aren't ack'd, the AC MUST NOT set a timer for each one it sends 🙅♀️.
If a WTP spots missed packets (when the sequence number of a received packet is more than one bigger than the last one it got), it jots the gap down in a bitmask 📝. When the timer fires, it requests every slice missing from that bitmask. Each request is a Download Request with a length of eight (8) that names the sequence number it wants 🎯. The AC MUST interleave these retransmissions with the packets in the sequence 🧵.
Since both sides agree on the MTU, the WTP already knows the slice size 🧠. So when a packet gets dropped, the WTP bumps its internal buffer pointer forward by one slice size and requests the lost packet. When it finally shows up, it slots right into the gap that was left open 🧩. Losing packet <n> means packet <n> gets re-requested and, once it arrives, goes into the buffer at offset <n-1> * <slicesize> from the start.
The last packet from the AC doesn't have the "more" bit set, which tells the WTP the whole image has arrived 🎉. The WTP ACKs that final packet, and that's the end of the Image Download process 🥳.
If the final packet gets lost, the AC just resends it again (see Section 4.4) 🔁.
6.2.4. Image Download State Machine 🧩
The Image Download protocol is a Negotiated Control Protocol defined for SLAPP ✨. You get into it from the "secure" state and leave it heading for 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 keeps track of these variables:
seq_num: the current slice 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 gets switched on.starved: a timer for the maximum amount of time the AC will spend trying to download an image.
Quick note: a C means that an event happens in a state and the state just stays put 💅.
|
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
These are the states 👑:
- Waiting: When the AC leaves the SLAPP state of "Secure", it lands in the "Waiting" state of the Image Download protocol.
seq_numgets set to one (1),moregets set to one (1),nslicesgets set to the number of slices in the image being downloaded, andstarvedgets set to the maximum amount of time the AC will put into downloading that particular image ⏳. - Received: The AC enters this state once it has received an Image Download Request 📩. If the sequence number of the packet is zero (0), it sets
seq_numto one (1) and moves to Sending. Otherwise, if the M bit is set, it setsreq_numto the sequence number of the request and moves to Sending. Otherwise (if the M bit is clear), it moves to Finished. - Sending: The AC is sending a slice to the WTP 📤. If
req_numis equal to zero (0), it sends the slice indicated byseq_numand incrementsseq_num. Ifreq_numis greater than zero (0), it sends the slice indicated byreq_numand setsreq_numback to zero (0). The "More" bit in either case is set based on the value ofmore. As long as no request packets come in, Sending keeps looping back to itself 🔄. Whenseq_numequalsnslices, "More" is set to zero (0) and the state moves to Idle. If thestarvedtimer expires, the AC moves to the SLAPP state of Discovering 😢. - Idle: The AC has sent every slice in the image and is just hanging out, waiting for requests 🛋️. If the
starvedtimer expires, the AC moves to the SLAPP state of Discovering. - Finished: The Image Download protocol has wrapped up 🎀. The
starvedtimer gets canceled.
6.2.4.2. WTP 🌸
The WTP's state machine for the Image Download protocol is shown in Figure 31 📈. The WTP keeps track of these variables:
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.
Quick note: a C means that an event happens in a state and the state just stays put 💅.
|
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
These are the states 👑:
- Init: When the WTP leaves the SLAPP state of "Secure", it enters the "Init" state of the Image Download protocol 🌱.
recv_num,final, and thereqbitmask all get set to zero (0), and thegiveuptimer gets set to a suitably large number. The WTP goes straight to Sending. - Sending: If
recv_numis zero (0), the WTP sends a request for the packet with sequence number zero (0) and the "More" bit set to one (1) 🙋♀️. Otherwise, for every unset bit inreqbetween one (1) andrecv_num, a request packet goes out with the sequence number that matches the unset bit and the "More" bit set tomore.
If there are no unset bits in req and final is non-zero, a request packet goes out for the sequence number represented by final with the "More" bit cleared 🏁. Then giveup gets cleared and the state machine moves to Finished. Otherwise, retry is set to a suitable value and the WTP moves to Receiving.
- Receiving: In this state, the WTP receives Image Download packets 📥. The bit in
reqthat matches the sequence number of the received packet gets set, which marks that packet as received ✅. If that sequence number was already received, the packet gets silently dropped 🤫. Otherwise, the data in the packet gets stored as the indicated slice in a file that represents the downloaded image 💾. If the received packet has the "More" bit cleared,finalis set to the sequence number in that packet. When theretrytimer fires, the WTP moves to Sending. If thegiveuptimer fires, the WTP moves to the SLAPP state of Discovering 😵. - Finished: The Image Download protocol has finished 🎉.
7. Security Considerations 🔐
Okay, security time, and it's serious 😤. This document describes a protocol, SLAPP, which uses a different protocol, DTLS, to handle authentication, key exchange, and bulk data encryption for a Negotiated Control Protocol 🔒. So its security considerations are basically DTLS's security considerations 🫶.
The AC creates state as soon as it receives an acceptable Discover Request 🧱. That's why AC implementations of SLAPP SHOULD take measures to protect themselves from denial-of-service attacks that try to exhaust resources on target machines 🚨. Those measures could look like randomly dropping connections once the number of open connections hits a certain threshold 🌊.
The WTP exposes information about itself during the discovery phase 👀. Some of that information couldn't be gleaned any other way 😳.
8. Extensibility to Other Technologies 🧚
okay bestie, so SLAPP is basically a technology-independent protocol 💖 that can get extra technology-specific pieces added on top. The whole goal is to fix the interop problem where a central controller from one vendor has to control and manage network elements from a totally different vendor 🫶
This doc assumes SLAPP is solving that multi-vendor interop problem, the one defined in the CAPWAP problem statement [3]. But splitting the solution into two components is giving main character energy 👑. The technology-dependent control protocols get negotiated through a technology-independent framework, so SLAPP can be the common framework for multiple underlying technologies that are vastly different from one another 🌈 iykyk.
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 💅
Here's who wrote this, with their contact info, so you know exactly who to slide into the DMs 🎀
Partha Narasimhan
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
Phone: +1 408-480-4716
EMail: partha@arubanetworks.comDan Harkins
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
EMail: dharkins@arubanetworks.comSubbu Ponnuswamy
Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
Phone: +1 408-754-1213
EMail: subbu@arubanetworks.com📦 where this page comes from
- ietf: rfc5413 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms