Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
Extracted elements (28)
CAPWAP separates control and data traffic onto distinct UDP ports (5246 and 5247 respectively) to allow different QoS treatment and independent security policies. DTLS protection is mandatory for control traffic but optional for data traffic, accommodating performance-sensitive forwarding scenarios.
DTLS was chosen as the CAPWAP security mechanism rather than IPsec because DTLS operates at the application layer, requires no kernel modifications, and is readily implementable alongside the CAPWAP stack. DTLS is based on TLS, which has been widely deployed, analyzed, and is available in hardware acceleration silicon.
The Sulking state with a mandatory SilentInterval was introduced after repeated discovery or DTLS failures to prevent the WTP from being used as a source of repeated connection floods against an AC. This silent period minimizes the WTP's contribution to DoS attacks on the network infrastructure.
CAPWAP is wireless-technology-independent; binding-specific functionality is provided through separate binding documents (e.g., RFC 5416 for IEEE 802.11). The WTP Radio Information message element advertises binding-specific capabilities in Discovery, Primary Discovery, and Join messages, ensuring WTP/AC interoperability across different technology types and binding versions.
A CAPWAP wireless binding MUST define at minimum: a binding-specific Statistics message element for use in WTP Event Request, a Station Configuration message element, and a WTP Radio Information message element carried in Discovery, Primary Discovery, and Join messages.
CAPWAP Control messages MUST be secured using DTLS. The WTP initiates DTLS session establishment toward the selected AC; the AC listens passively via DTLSListen. DTLS protection of data messages is optional.
The AC MUST transmit an Image Data Response message to the WTP when the WTP sends an Image Data Request, including a portion of the firmware. The AC starts the DataCheckTimer when it receives the Change State Event Request in the Data Check state.
The DTLS implementation used by CAPWAP MUST support TLS Session Resumption, which is typically used to establish the DTLS data channel. The WTP MUST provide an interface that allows session resumption across different port numbers, since the data channel uses ports distinct from the control channel.
The DTLS implementation used by CAPWAP MUST use replay detection per Section 3.3 of RFC 4347. Because CAPWAP retransmissions re-encrypt lost frames, any duplicate DTLS frames are either unintentional or malicious and must be silently discarded.
When a WTP enters the Sulking state due to failed AC discovery or repeated DTLS failures, it MUST start the SilentInterval timer. While sulking, the WTP MUST ignore all received CAPWAP and DTLS protocol messages to minimize DoS attack surface.
CAPWAP fragmentation applies when a control or data message exceeds the path MTU between WTP and AC. The CAPWAP Header Fragment ID and Fragment Offset fields identify fragment position; the Last Fragment bit marks the final fragment. MTU Discovery uses a padding message element to probe the maximum supported size.
Firmware Management allows the AC to provision WTPs with updated images. When the Join Response Image Identifier differs from the WTP's running image and the image is not cached locally, the WTP enters Image Data state and exchanges Image Data Request/Response messages to download the firmware before rebooting.
The CAPWAP Discovery phase allows WTPs to dynamically locate ACs by sending Discovery Request messages to known unicast addresses, multicast groups, or broadcast. Any AC receiving the request responds with a Discovery Response containing its capabilities, allowing the WTP to select an AC for DTLS session establishment.
The Data Channel Keep-Alive binds control and data channels. Upon entering Run state, the WTP starts the DataChannelKeepAlive timer and sends a Keep-Alive packet containing the Session ID. The AC transitions to Run state only upon receiving a Keep-Alive with a Session ID matching the one from the WTP's Join Request.
The Echo Request/Response messages serve as a control-channel keep-alive. The WTP sends Echo Requests based on the EchoInterval timer; if the retransmit count reaches MaxRetransmit without a response, the WTP tears down the DTLS session and re-enters discovery to find a new AC.
The Join operation is the first CAPWAP exchange after DTLS establishment. The WTP sends a Join Request containing its descriptor, name, board data, and location; the AC responds with a Join Response including the Image Identifier, which determines whether the WTP transitions to Configure state (image matches) or Image Data state (firmware download needed).
The Session ID is a 128-bit opaque value generated by the AC and delivered in the Join Response. It is used to bind the control and data channels and must be included in Data Channel Keep-Alive packets. The Session ID MUST be cryptographically random to prevent spoofing.
RFC 5415 creates or updates numerous IANA registries including: CAPWAP Message Types, CAPWAP Header Flags, Control Message Flags, Message Element Types, Wireless Binding Identifiers, AC Security Types, AC DTLS Policy, AC Information Type, Transport Protocol Types, Data Transfer Type and Mode, Discovery Types, ECN Support, Radio Admin and Operational State, Radio Failure Causes, Result Code, Returned Message Element Reason, WTP Board/Descriptor/Frame Tunnel/MAC/Radio Stats/Reboot Stats types, and WTP Fallback Mode.
CAPWAP fragmentation can be exploited in a resource exhaustion DoS attack: an attacker sends many initial fragments, consuming reassembly buffer memory. Implementations must limit the number of pending reassembly contexts and apply timeouts on incomplete fragment sets.
During Discovery and DTLS setup, messages are unauthenticated and susceptible to tampering. Attackers may inject forged Discovery Responses directing WTPs to rogue ACs or send crafted DTLS handshake messages. Implementations must protect against these attacks by enforcing pre-provisioned AC credentials.
Pre-shared keys (PSKs) MUST NOT be shared among multiple WTPs; compromise of one WTP would expose all WTPs using the same PSK. Certificate-based mutual authentication is preferred for deployments requiring strong security guarantees.
The 128-bit Session ID binding the control and data channels must be kept secret. An attacker who observes the Session ID can inject spurious Data Channel Keep-Alive packets, disrupting data channel establishment. The Session ID MUST be generated using a cryptographically strong random number generator.
The use of MD5 within CAPWAP is limited to non-security-critical functions. MD5 MUST NOT be used for any security-sensitive operations such as message authentication or key derivation, as its collision resistance is broken.
WTP firmware integrity is critical: a compromised firmware image could allow interception of wireless traffic or denial of service. The AC must validate firmware image authenticity before provisioning, and WTPs must validate images before executing them.
The CAPWAP integrated state machine governs the WTP-AC session lifecycle through states: Start, Idle, Discovery, Sulking, DTLS Setup, Authorize, DTLS Connect, DTLS Teardown, Dead, Join, Image Data, Configure, Data Check, Run, and Reset. Transitions are triggered by DTLS notifications (e.g., DTLSEstablished, DTLSAuthenticateFail), timer expirations, and protocol message exchanges. The AC uses three concurrent threads (Listener, Discovery, Service) while the WTP uses a single instance.
The CAPWAP Control Message body consists of a 4-byte Message Type, 1-byte Sequence Number, 2-byte Message Element Length, 1-byte Flags, followed by zero or more Message Elements. Each Message Element has a 2-byte Type, 2-byte Length, and variable-length Value field.
The CAPWAP Header contains: HLEN (5 bits, header length in 4-byte words), RID (5 bits, Radio ID), WBID (5 bits, Wireless Binding ID), Flags (9 bits: Type, Fragment, Last Fragment, Native Frame indicator, Radio MAC present, Wireless Specific Info present, and Reserved), Fragment ID (16 bits), Fragment Offset (13 bits), and Reserved (3 bits), optionally followed by Radio MAC Address and Wireless Specific Information fields.
The CAPWAP Preamble is a single octet: bits 0-3 carry the Version field (must be 0) and bits 4-7 carry the Type field (0 = plain CAPWAP, 1 = DTLS-protected CAPWAP). This preamble precedes either the CAPWAP DTLS Header or the CAPWAP Header.