RFC 5415
Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
Pages: 155
Proposed Standard
→ Errata
Obsoletes: 5414
Updated by: 8553 8996
Proposed Standard
→ Errata
Obsoletes: 5414
Updated by: 8553 8996
Part 2 of 6 – Pages 11 to 39
2. Protocol Overview
The CAPWAP protocol is a generic protocol defining AC and WTP control and data plane communication via a CAPWAP protocol transport mechanism. CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using Datagram Transport Layer Security (DTLS) [RFC4347]. DTLS is a standards-track IETF protocol based upon TLS. The underlying security-related protocol mechanisms of TLS have been successfully deployed for many years. The CAPWAP protocol transport layer carries two types of payload, CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data messages encapsulate forwarded wireless frames. CAPWAP protocol Control messages are management messages exchanged between a WTP and an AC. The CAPWAP Data and Control packets are sent over separate UDP ports. Since both data and control packets can exceed the Maximum Transmission Unit (MTU) length, the payload of a CAPWAP Data or Control message can be fragmented. The fragmentation behavior is defined in Section 3. The CAPWAP Protocol begins with a Discovery phase. The WTPs send a Discovery Request message, causing any Access Controller (AC) receiving the message to respond with a Discovery Response message. From the Discovery Response messages received, a WTP selects an AC with which to establish a secure DTLS session. In order to establish the secure DTLS connection, the WTP will need some amount of pre- provisioning, which is specified in Section 12.5. CAPWAP protocol messages will be fragmented to the maximum length discovered to be supported by the network.
Once the WTP and the AC have completed DTLS session establishment, a configuration exchange occurs in which both devices agree on version information. During this exchange, the WTP may receive provisioning settings. The WTP is then enabled for operation. When the WTP and AC have completed the version and provision exchange and the WTP is enabled, the CAPWAP protocol is used to encapsulate the wireless data frames sent between the WTP and AC. The CAPWAP protocol will fragment the L2 frames if the size of the encapsulated wireless user data (Data) or protocol control (Management) frames causes the resulting CAPWAP protocol packet to exceed the MTU supported between the WTP and AC. Fragmented CAPWAP packets are reassembled to reconstitute the original encapsulated payload. MTU Discovery and Fragmentation are described in Section 3. The CAPWAP protocol provides for the delivery of commands from the AC to the WTP for the management of stations that are communicating with the WTP. This may include the creation of local data structures in the WTP for the stations and the collection of statistical information about the communication between the WTP and the stations. The CAPWAP protocol provides a mechanism for the AC to obtain statistical information collected by the WTP. The CAPWAP protocol provides for a keep-alive feature that preserves the communication channel between the WTP and AC. If the AC fails to appear alive, the WTP will try to discover a new AC.2.1. Wireless Binding Definition
The CAPWAP protocol is independent of a specific WTP radio technology, as well its associated wireless link layer protocol. Elements of the CAPWAP protocol are designed to accommodate the specific needs of each wireless technology in a standard way. Implementation of the CAPWAP protocol for a particular wireless technology MUST follow the binding requirements defined for that technology. When defining a binding for wireless technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. At a minimum, a binding MUST provide: 1. The definition for a binding-specific Statistics message element, carried in the WTP Event Request message. 2. A message element carried in the Station Configuration Request message to configure station information on the WTP.
3. A WTP Radio Information message element carried in the Discovery,
Primary Discovery, and Join Request and Response messages,
indicating the binding-specific radio types supported at the WTP
and AC.
If technology-specific message elements are required for any of the
existing CAPWAP messages defined in this specification, they MUST
also be defined in the technology binding document.
The naming of binding-specific message elements MUST begin with the
name of the technology type, e.g., the binding for IEEE 802.11,
provided in [RFC5416], begins with "IEEE 802.11".
The CAPWAP binding concept MUST also be used in any future
specifications that add functionality to either the base CAPWAP
protocol specification, or any published CAPWAP binding
specification. A separate WTP Radio Information message element MUST
be created to properly advertise support for the specification. This
mechanism allows for future protocol extensibility, while providing
the necessary capabilities advertisement, through the WTP Radio
Information message element, to ensure WTP/AC interoperability.
2.2. CAPWAP Session Establishment Overview
This section describes the session establishment process message
exchanges between a CAPWAP WTP and AC. The annotated ladder diagram
shows the AC on the right, the WTP on the left, and assumes the use
of certificates for DTLS authentication. The CAPWAP protocol state
machine is described in detail in Section 2.3. Note that DTLS allows
certain messages to be aggregated into a single frame, which is
denoted via an asterisk in Figure 3.
============ ============
WTP AC
============ ============
[----------- begin optional discovery ------------]
Discover Request
------------------------------------>
Discover Response
<------------------------------------
[----------- end optional discovery ------------]
(-- begin DTLS handshake --)
ClientHello
------------------------------------>
HelloVerifyRequest (with cookie)
<------------------------------------
ClientHello (with cookie)
------------------------------------>
ServerHello,
Certificate,
ServerHelloDone*
<------------------------------------
(-- WTP callout for AC authorization --)
Certificate (optional),
ClientKeyExchange,
CertificateVerify (optional),
ChangeCipherSpec,
Finished*
------------------------------------>
(-- AC callout for WTP authorization --)
ChangeCipherSpec,
Finished*
<------------------------------------
(-- DTLS session is established now --)
Join Request
------------------------------------>
Join Response
<------------------------------------
[-- Join State Complete --]
(-- assume image is up to date --)
Configuration Status Request
------------------------------------>
Configuration Status Response
<------------------------------------
[-- Configure State Complete --]
Change State Event Request
------------------------------------>
Change State Event Response
<------------------------------------
[-- Data Check State Complete --]
(-- enter RUN state --) : : Echo Request ------------------------------------> Echo Response <------------------------------------ : : Event Request ------------------------------------> Event Response <------------------------------------ : : Figure 3: CAPWAP Control Protocol Exchange At the end of the illustrated CAPWAP message exchange, the AC and WTP are securely exchanging CAPWAP Control messages. This illustration is provided to clarify protocol operation, and does not include any possible error conditions. Section 2.3 provides a detailed description of the corresponding state machine.2.3. CAPWAP State Machine Definition
The following state diagram represents the lifecycle of a WTP-AC session. Use of DTLS by the CAPWAP protocol results in the juxtaposition of two nominally separate yet tightly bound state machines. The DTLS and CAPWAP state machines are coupled through an API consisting of commands (see Section 2.3.2.1) and notifications (see Section 2.3.2.2). Certain transitions in the DTLS state machine are triggered by commands from the CAPWAP state machine, while certain transitions in the CAPWAP state machine are triggered by notifications from the DTLS state machine.
/-------------------------------------\ | /-------------------------\| | p| || | q+----------+ r +------------+ || | | Run |-->| Reset |-\|| | +----------+ +------------+ ||| n| o ^ ^ ^ s||| +------------+--------/ | | ||| | Data Check | /-------/ | ||| +------------+<-------\ | | ||| | | | ||| /------------------+--------\ | ||| f| m| h| j v k| ||| +--------+ +-----------+ +--------------+||| | Join |---->| Configure | | Image Data |||| +--------+ n +-----------+ +--------------+||| ^ |g i| l| ||| | | \-------------------\ | ||| | \--------------------------------------\| | ||| \------------------------\ || | ||| /--------------<----------------+---------------\ || | ||| | /------------<----------------+-------------\ | || | ||| | | 4 |d t| | vv v vvv | | +----------------+ +--------------+ +-----------+ | | | DTLS Setup | | DTLS Connect |-->| DTLS TD | /-|-|---+----------------+ +--------------+ e +-----------+ | | | |$ ^ ^ |5 ^6 ^ ^ |w v v v | | | | \-------\ | | | | | | | | | \---------\ | | /-----------/ | | | | | | \--\ | | | | | | | | | | | | | | | | | | | v 3| 1 |% # v | |a |b v | | \->+------+-->+------+ +-----------+ +--------+ | | | Idle | | Disc | | Authorize | | Dead | | | +------+<--+------+ +-----------+ +--------+ | | ^ 0^ 2 |! | | | | | +-------+ *| |u | \---------+---| Start | | | |@ | +-------+ | \->+---------+<------/ \--->| Sulking | +---------+& Figure 4: CAPWAP Integrated State Machine The CAPWAP protocol state machine, depicted above, is used by both the AC and the WTP. In cases where states are not shared (i.e., not implemented in one or the other of the AC or WTP), this is explicitly
called out in the transition descriptions below. For every state
defined, only certain messages are permitted to be sent and received.
The CAPWAP Control message definitions specify the state(s) in which
each message is valid.
Since the WTP only communicates with a single AC, it only has a
single instance of the CAPWAP state machine. The state machine works
differently on the AC since it communicates with many WTPs. The AC
uses the concept of three threads. Note that the term thread used
here does not necessarily imply that implementers must use threads,
but it is one possible way of implementing the AC's state machine.
Listener Thread: The AC's Listener thread handles inbound DTLS
session establishment requests, through the DTLSListen command.
Upon creation, the Listener thread starts in the DTLS Setup state.
Once a DTLS session has been validated, which occurs when the
state machine enters the "Authorize" state, the Listener thread
creates a WTP session-specific Service thread and state context.
The state machine transitions in Figure 4 are represented by
numerals. It is necessary for the AC to protect itself against
various attacks that exist with non-authenticated frames. See
Section 12 for more information.
Discovery Thread: The AC's Discovery thread is responsible for
receiving, and responding to, Discovery Request messages. The
state machine transitions in Figure 4 are represented by numerals.
Note that the Discovery thread does not maintain any per-WTP-
specific context information, and a single state context exists.
It is necessary for the AC to protect itself against various
attacks that exist with non-authenticated frames. See Section 12
for more information.
Service Thread: The AC's Service thread handles the per-WTP states,
and one such thread exists per-WTP connection. This thread is
created by the Listener thread when the Authorize state is
reached. When created, the Service thread inherits a copy of the
state machine context from the Listener thread. When
communication with the WTP is complete, the Service thread is
terminated and all associated resources are released. The state
machine transitions in Figure 4 are represented by alphabetic and
punctuation characters.
2.3.1. CAPWAP Protocol State Transitions
This section describes the various state transitions, and the events
that cause them. This section does not discuss interactions between
DTLS- and CAPWAP-specific states. Those interactions, and DTLS-
specific states and transitions, are discussed in Section 2.3.2.
Start to Idle (0): This transition occurs once device initialization
is complete.
WTP: This state transition is used to start the WTP's CAPWAP
state machine.
AC: The AC creates the Discovery and Listener threads and starts
the CAPWAP state machine.
Idle to Discovery (1): This transition occurs to support the CAPWAP
discovery process.
WTP: The WTP enters the Discovery state prior to transmitting the
first Discovery Request message (see Section 5.1). Upon
entering this state, the WTP sets the DiscoveryInterval
timer (see Section 4.7). The WTP resets the DiscoveryCount
counter to zero (0) (see Section 4.8). The WTP also clears
all information from ACs it may have received during a
previous Discovery phase.
AC: This state transition is executed by the AC's Discovery
thread, and occurs when a Discovery Request message is
received. The AC SHOULD respond with a Discovery Response
message (see Section 5.2).
Discovery to Discovery (#): In the Discovery state, the WTP
determines to which AC to connect.
WTP: This transition occurs when the DiscoveryInterval timer
expires. If the WTP is configured with a list of ACs, it
transmits a Discovery Request message to every AC from which
it has not received a Discovery Response message. For every
transition to this event, the WTP increments the
DiscoveryCount counter. See Section 5.1 for more
information on how the WTP knows the ACs to which it should
transmit the Discovery Request messages. The WTP restarts
the DiscoveryInterval timer whenever it transmits Discovery
Request messages.
AC: This is an invalid state transition for the AC.
Discovery to Idle (2): This transition occurs on the AC's Discovery
thread when the Discovery processing is complete.
WTP: This is an invalid state transition for the WTP.
AC: This state transition is executed by the AC's Discovery
thread when it has transmitted the Discovery Response, in
response to a Discovery Request.
Discovery to Sulking (!): This transition occurs on a WTP when AC
Discovery fails.
WTP: The WTP enters this state when the DiscoveryInterval timer
expires and the DiscoveryCount variable is equal to the
MaxDiscoveries variable (see Section 4.8). Upon entering
this state, the WTP MUST start the SilentInterval timer.
While in the Sulking state, all received CAPWAP protocol
messages MUST be ignored.
AC: This is an invalid state transition for the AC.
Sulking to Idle (@): This transition occurs on a WTP when it must
restart the Discovery phase.
WTP: The WTP enters this state when the SilentInterval timer (see
Section 4.7) expires. The FailedDTLSSessionCount,
DiscoveryCount, and FailedDTLSAuthFailCount counters are
reset to zero.
AC: This is an invalid state transition for the AC.
Sulking to Sulking (&): The Sulking state provides the silent
period, minimizing the possibility for Denial-of-Service (DoS)
attacks.
WTP: All packets received from the AC while in the sulking state
are ignored.
AC: This is an invalid state transition for the AC.
Idle to DTLS Setup (3): This transition occurs to establish a secure
DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart
command (see Section 2.3.2.1), which starts the DTLS session
establishment with the chosen AC and the WaitDTLS timer is
started (see Section 4.7). When the Discovery phase is
bypassed, it is assumed the WTP has locally configured ACs.
AC: Upon entering the Idle state from the Start state, the newly
created Listener thread automatically transitions to the
DTLS Setup and invokes the DTLSListen command (see
Section 2.3.2.1), and the WaitDTLS timer is started (see
Section 4.7).
Discovery to DTLS Setup (%): This transition occurs to establish a
secure DTLS session with the peer.
WTP: The WTP initiates this transition by invoking the DTLSStart
command (see Section 2.3.2.1), which starts the DTLS session
establishment with the chosen AC. The decision of to which
AC to connect is the result of the Discovery phase, which is
described in Section 3.3.
AC: This is an invalid state transition for the AC.
DTLS Setup to Idle ($): This transition occurs when the DTLS
connection setup fails.
WTP: The WTP initiates this state transition when it receives a
DTLSEstablishFail notification from DTLS (see
Section 2.3.2.2), and the FailedDTLSSessionCount or the
FailedDTLSAuthFailCount counter have not reached the value
of the MaxFailedDTLSSessionRetry variable (see Section 4.8).
This error notification aborts the secure DTLS session
establishment. When this notification is received, the
FailedDTLSSessionCount counter is incremented. This state
transition also occurs if the WaitDTLS timer has expired.
AC: This is an invalid state transition for the AC.
DTLS Setup to Sulking (*): This transition occurs when repeated
attempts to set up the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the
MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
entering this state, the WTP MUST start the SilentInterval
timer. While in the Sulking state, all received CAPWAP and
DTLS protocol messages received MUST be ignored.
AC: This is an invalid state transition for the AC.
DTLS Setup to DTLS Setup (4): This transition occurs when the DTLS
Session failed to be established.
WTP: This is an invalid state transition for the WTP.
AC: The AC's Listener initiates this state transition when it
receives a DTLSEstablishFail notification from DTLS (see
Section 2.3.2.2). This error notification aborts the secure
DTLS session establishment. When this notification is
received, the FailedDTLSSessionCount counter is incremented.
The Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
DTLS Setup to Authorize (5): This transition occurs when an incoming
DTLS session is being established, and the DTLS stack needs
authorization to proceed with the session establishment.
WTP: This state transition occurs when the WTP receives the
DTLSPeerAuthorize notification (see Section 2.3.2.2). Upon
entering this state, the WTP performs an authorization check
against the AC credentials. See Section 2.4.4 for more
information on AC authorization.
AC: This state transition is handled by the AC's Listener thread
when the DTLS module initiates the DTLSPeerAuthorize
notification (see Section 2.3.2.2). The Listener thread
forks an instance of the Service thread, along with a copy
of the state context. Once created, the Service thread
performs an authorization check against the WTP credentials.
See Section 2.4.4 for more information on WTP authorization.
Authorize to DTLS Setup (6): This transition is executed by the
Listener thread to enable it to listen for new incoming sessions.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC's Listener thread
has created the WTP context and the Service thread. The
Listener thread then invokes the DTLSListen command (see
Section 2.3.2.1).
Authorize to DTLS Connect (a): This transition occurs to notify the
DTLS stack that the session should be established.
WTP: This state transition occurs when the WTP has successfully
authorized the AC's credentials (see Section 2.4.4). This
is done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1).
AC: This state transition occurs when the AC has successfully
authorized the WTP's credentials (see Section 2.4.4). This
is done by invoking the DTLSAccept DTLS command (see
Section 2.3.2.1).
Authorize to DTLS Teardown (b): This transition occurs to notify the
DTLS stack that the session should be aborted.
WTP: This state transition occurs when the WTP has been unable to
authorize the AC, using the AC credentials. The WTP then
aborts the DTLS session by invoking the DTLSAbortSession
command (see Section 2.3.2.1). This state transition also
occurs if the WaitDTLS timer has expired. The WTP starts
the DTLSSessionDelete timer (see Section 4.7.6).
AC: This state transition occurs when the AC has been unable to
authorize the WTP, using the WTP credentials. The AC then
aborts the DTLS session by invoking the DTLSAbortSession
command (see Section 2.3.2.1). This state transition also
occurs if the WaitDTLS timer has expired. The AC starts the
DTLSSessionDelete timer (see Section 4.7.6).
DTLS Connect to DTLS Teardown (c): This transition occurs when the
DTLS Session failed to be established.
WTP: This state transition occurs when the WTP receives either a
DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not
successfully established. When this transition occurs due
to the DTLSAuthenticateFail notification, the
FailedDTLSAuthFailCount is incremented; otherwise, the
FailedDTLSSessionCount counter is incremented. This state
transition also occurs if the WaitDTLS timer has expired.
The WTP starts the DTLSSessionDelete timer (see
Section 4.7.6).
AC: This state transition occurs when the AC receives either a
DTLSAborted or DTLSAuthenticateFail notification (see
Section 2.3.2.2), indicating that the DTLS session was not
successfully established, and both of the
FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
have not reached the value of the MaxFailedDTLSSessionRetry
variable (see Section 4.8). This state transition also
occurs if the WaitDTLS timer has expired. The AC starts the
DTLSSessionDelete timer (see Section 4.7.6).
DTLS Connect to Join (d): This transition occurs when the DTLS
Session is successfully established.
WTP: This state transition occurs when the WTP receives the
DTLSEstablished notification (see Section 2.3.2.2),
indicating that the DTLS session was successfully
established. When this notification is received, the
FailedDTLSSessionCount counter is set to zero. The WTP
enters the Join state by transmitting the Join Request to
the AC. The WTP stops the WaitDTLS timer.
AC: This state transition occurs when the AC receives the
DTLSEstablished notification (see Section 2.3.2.2),
indicating that the DTLS session was successfully
established. When this notification is received, the
FailedDTLSSessionCount counter is set to zero. The AC stops
the WaitDTLS timer, and starts the WaitJoin timer.
Join to DTLS Teardown (e): This transition occurs when the join
process has failed.
WTP: This state transition occurs when the WTP receives a Join
Response message with a Result Code message element
containing an error, or if the Image Identifier provided by
the AC in the Join Response message differs from the WTP's
currently running firmware version and the WTP has the
requested image in its non-volatile memory. This causes the
WTP to initiate the DTLSShutdown command (see
Section 2.3.2.1). This transition also occurs if the WTP
receives one of the following DTLS notifications:
DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect.
The WTP starts the DTLSSessionDelete timer (see
Section 4.7.6).
AC: This state transition occurs either if the WaitJoin timer
expires or if the AC transmits a Join Response message with
a Result Code message element containing an error. This
causes the AC to initiate the DTLSShutdown command (see
Section 2.3.2.1). This transition also occurs if the AC
receives one of the following DTLS notifications:
DTLSAborted, DTLSReassemblyFailure, or DTLSPeerDisconnect.
The AC starts the DTLSSessionDelete timer (see
Section 4.7.6).
Join to Image Data (f): This state transition is used by the WTP and
the AC to download executable firmware.
WTP: The WTP enters the Image Data state when it receives a
successful Join Response message and determines that the
software version in the Image Identifier message element is
not the same as its currently running image. The WTP also
detects that the requested image version is not currently
available in the WTP's non-volatile storage (see Section 9.1
for a full description of the firmware download process).
The WTP initializes the EchoInterval timer (see
Section 4.7), and transmits the Image Data Request message
(see Section 9.1.1) requesting the start of the firmware
download.
AC: This state transition occurs when the AC receives the Image
Data Request message from the WTP, after having sent its
Join Response to the WTP. The AC stops the WaitJoin timer.
The AC MUST transmit an Image Data Response message (see
Section 9.1.2) to the WTP, which includes a portion of the
firmware.
Join to Configure (g): This state transition is used by the WTP and
the AC to exchange configuration information.
WTP: The WTP enters the Configure state when it receives a
successful Join Response message, and determines that the
included Image Identifier message element is the same as its
currently running image. The WTP transmits the
Configuration Status Request message (see Section 8.2) to
the AC with message elements describing its current
configuration.
AC: This state transition occurs when it receives the
Configuration Status Request message from the WTP (see
Section 8.2), which MAY include specific message elements to
override the WTP's configuration. The AC stops the WaitJoin
timer. The AC transmits the Configuration Status Response
message (see Section 8.3) and starts the
ChangeStatePendingTimer timer (see Section 4.7).
Configure to Reset (h): This state transition is used to reset the
connection either due to an error during the configuration phase,
or when the WTP determines it needs to reset in order for the new
configuration to take effect. The CAPWAP Reset command is used to
indicate to the peer that it will initiate a DTLS teardown.
WTP: The WTP enters the Reset state when it receives a
Configuration Status Response message indicating an error or
when it determines that a reset of the WTP is required, due
to the characteristics of a new configuration.
AC: The AC transitions to the Reset state when it receives a
Change State Event message from the WTP that contains an
error for which AC policy does not permit the WTP to provide
service. This state transition also occurs when the AC
ChangeStatePendingTimer timer expires.
Configure to DTLS Teardown (i): This transition occurs when the
configuration process aborts due to a DTLS error.
WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure, or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The
WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure, or DTLSPeerDisconnect (see
Section 2.3.2.2). The AC MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6).
Image Data to Image Data (j): The Image Data state is used by the
WTP and the AC during the firmware download phase.
WTP: The WTP enters the Image Data state when it receives an
Image Data Response message indicating that the AC has more
data to send. This state transition also occurs when the
WTP receives the subsequent Image Data Requests, at which
time it resets the ImageDataStartTimer time to ensure it
receives the next expected Image Data Request from the AC.
This state transition can also occur when the WTP's
EchoInterval timer (see Section 4.7.7) expires, in which
case the WTP transmits an Echo Request message (see
Section 7.1), and resets its EchoInterval timer. The state
transition also occurs when the WTP receives an Echo
Response from the AC (see Section 7.2).
AC: This state transition occurs when the AC receives the Image
Data Response message from the WTP while already in the
Image Data state. This state transition also occurs when
the AC receives an Echo Request (see Section 7.1) from the
WTP, in which case it responds with an Echo Response (see
Section 7.2), and resets its EchoInterval timer (see
Section 4.7.7).
Image Data to Reset (k): This state transition is used to reset the
DTLS connection prior to restarting the WTP after an image
download.
WTP: When an image download completes, or if the
ImageDataStartTimer timer expires, the WTP enters the Reset
state. The WTP MAY also transition to this state upon
receiving an Image Data Response message from the AC (see
Section 9.1.2) indicating a failure.
AC: The AC enters the Reset state either when the image transfer
has successfully completed or an error occurs during the
image download process.
Image Data to DTLS Teardown (l): This transition occurs when the
firmware download process aborts due to a DTLS error.
WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure, or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The
WTP starts the DTLSSessionDelete timer (see Section 4.7.6).
AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure, or DTLSPeerDisconnect (see
Section 2.3.2.2). The AC MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The AC
starts the DTLSSessionDelete timer (see Section 4.7.6).
Configure to Data Check (m): This state transition occurs when the
WTP and AC confirm the configuration.
WTP: The WTP enters this state when it receives a successful
Configuration Status Response message from the AC. The WTP
transmits the Change State Event Request message (see
Section 8.6).
AC: This state transition occurs when the AC receives the Change
State Event Request message (see Section 8.6) from the WTP.
The AC responds with a Change State Event Response message
(see Section 8.7). The AC MUST start the DataCheckTimer
timer and stops the ChangeStatePendingTimer timer (see
Section 4.7).
Data Check to DTLS Teardown (n): This transition occurs when the WTP
does not complete the Data Check exchange.
WTP: This state transition occurs if the WTP does not receive the
Change State Event Response message before a CAPWAP
retransmission timeout occurs. The WTP also transitions to
this state if the underlying reliable transport's
RetransmitCount counter has reached the MaxRetransmit
variable (see Section 4.7). The WTP starts the
DTLSSessionDelete timer (see Section 4.7.6).
AC: The AC enters this state when the DataCheckTimer timer
expires (see Section 4.7). The AC starts the
DTLSSessionDelete timer (see Section 4.7.6).
Data Check to Run (o): This state transition occurs when the linkage
between the control and data channels is established, causing the
WTP and AC to enter their normal state of operation.
WTP: The WTP enters this state when it receives a successful
Change State Event Response message from the AC. The WTP
initiates the data channel, which MAY require the
establishment of a DTLS session, starts the
DataChannelKeepAlive timer (see Section 4.7.2) and transmits
a Data Channel Keep-Alive packet (see Section 4.4.1). The
WTP then starts the EchoInterval timer and
DataChannelDeadInterval timer (see Section 4.7).
AC: This state transition occurs when the AC receives the Data
Channel Keep-Alive packet (see Section 4.4.1), with a
Session ID message element matching that included by the WTP
in the Join Request message. The AC disables the
DataCheckTimer timer. Note that if AC policy is to require
the data channel to be encrypted, this process would also
require the establishment of a data channel DTLS session.
Upon receiving the Data Channel Keep-Alive packet, the AC
transmits its own Data Channel Keep Alive packet.
Run to DTLS Teardown (p): This state transition occurs when an error
has occurred in the DTLS stack, causing the DTLS session to be
torn down.
WTP: The WTP enters this state when it receives one of the
following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure, or DTLSPeerDisconnect (see
Section 2.3.2.2). The WTP MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The
WTP also transitions to this state if the underlying
reliable transport's RetransmitCount counter has reached the
MaxRetransmit variable (see Section 4.7). The WTP starts
the DTLSSessionDelete timer (see Section 4.7.6).
AC: The AC enters this state when it receives one of the
following DTLS notifications: DTLSAborted,
DTLSReassemblyFailure, or DTLSPeerDisconnect (see
Section 2.3.2.2). The AC MAY tear down the DTLS session if
it receives frequent DTLSDecapFailure notifications. The AC
transitions to this state if the underlying reliable
transport's RetransmitCount counter has reached the
MaxRetransmit variable (see Section 4.7). This state
transition also occurs when the AC's EchoInterval timer (see
Section 4.7.7) expires. The AC starts the DTLSSessionDelete
timer (see Section 4.7.6).
Run to Run (q): This is the normal state of operation.
WTP: This is the WTP's normal state of operation. The WTP resets
its EchoInterval timer whenever it transmits a request to
the AC. There are many events that result in this state
transition:
Configuration Update: The WTP receives a Configuration
Update Request message (see Section 8.4). The WTP
MUST respond with a Configuration Update Response
message (see Section 8.5).
Change State Event: The WTP receives a Change State Event
Response message, or determines that it must initiate
a Change State Event Request message, as a result of a
failure or change in the state of a radio.
Echo Request: The WTP sends an Echo Request message
(Section 7.1) or receives the corresponding Echo
Response message, (see Section 7.2) from the AC. When
the WTP receives the Echo Response, it resets its
EchoInterval timer (see Section 4.7.7).
Clear Config Request: The WTP receives a Clear
Configuration Request message (see Section 8.8) and
MUST generate a corresponding Clear Configuration
Response message (see Section 8.9). The WTP MUST
reset its configuration back to manufacturer defaults.
WTP Event: The WTP sends a WTP Event Request message,
delivering information to the AC (see Section 9.4).
The WTP receives a WTP Event Response message from the
AC (see Section 9.5).
Data Transfer: The WTP sends a Data Transfer Request or
Data Transfer Response message to the AC (see
Section 9.6). The WTP receives a Data Transfer
Request or Data Transfer Response message from the AC
(see Section 9.6). Upon receipt of a Data Transfer
Request, the WTP transmits a Data Transfer Response to
the AC.
Station Configuration Request: The WTP receives a Station
Configuration Request message (see Section 10.1), to
which it MUST respond with a Station Configuration
Response message (see Section 10.2).
AC: This is the AC's normal state of operation. Note that the
receipt of any Request from the WTP causes the AC to reset
its EchoInterval timer (see Section 4.7.7).
Configuration Update: The AC sends a Configuration Update
Request message (see Section 8.4) to the WTP to update
its configuration. The AC receives a Configuration
Update Response message (see Section 8.5) from the
WTP.
Change State Event: The AC receives a Change State Event
Request message (see Section 8.6), to which it MUST
respond with the Change State Event Response message
(see Section 8.7).
Echo Request: The AC receives an Echo Request message (see
Section 7.1), to which it MUST respond with an Echo
Response message (see Section 7.2).
Clear Config Response: The AC sends a Clear Configuration
Request message (see Section 8.8) to the WTP to clear
its configuration. The AC receives a Clear
Configuration Response message from the WTP (see
Section 8.9).
WTP Event: The AC receives a WTP Event Request message from
the WTP (see Section 9.4) and MUST generate a
corresponding WTP Event Response message (see
Section 9.5).
Data Transfer: The AC sends a Data Transfer Request or Data
Transfer Response message to the WTP (see
Section 9.6). The AC receives a Data Transfer Request
or Data Transfer Response message from the WTP (see
Section 9.6). Upon receipt of a Data Transfer
Request, the AC transmits a Data Transfer Response to
the WTP.
Station Configuration Request: The AC sends a Station
Configuration Request message (see Section 10.1) or
receives the corresponding Station Configuration
Response message (see Section 10.2) from the WTP.
Run to Reset (r): This state transition is used when either the AC
or WTP tears down the connection. This may occur as part of
normal operation, or due to error conditions.
WTP: The WTP enters the Reset state when it receives a Reset
Request message from the AC.
AC: The AC enters the Reset state when it transmits a Reset
Request message to the WTP.
Reset to DTLS Teardown (s): This transition occurs when the CAPWAP
reset is complete to terminate the DTLS session.
WTP: This state transition occurs when the WTP transmits a Reset
Response message. The WTP does not invoke the DTLSShutdown
command (see Section 2.3.2.1). The WTP starts the
DTLSSessionDelete timer (see Section 4.7.6).
AC: This state transition occurs when the AC receives a Reset
Response message. This causes the AC to initiate the
DTLSShutdown command (see Section 2.3.2.1). The AC starts
the DTLSSessionDelete timer (see Section 4.7.6).
DTLS Teardown to Idle (t): This transition occurs when the DTLS
session has been shut down.
WTP: This state transition occurs when the WTP has successfully
cleaned up all resources associated with the control plane
DTLS session, or if the DTLSSessionDelete timer (see
Section 4.7.6) expires. The data plane DTLS session is also
shut down, and all resources released, if a DTLS session was
established for the data plane. Any timers set for the
current instance of the state machine are also cleared.
AC: This is an invalid state transition for the AC.
DTLS Teardown to Sulking (u): This transition occurs when repeated
attempts to setup the DTLS connection have failed.
WTP: The WTP enters this state when the FailedDTLSSessionCount or
the FailedDTLSAuthFailCount counter reaches the value of the
MaxFailedDTLSSessionRetry variable (see Section 4.8). Upon
entering this state, the WTP MUST start the SilentInterval
timer. While in the Sulking state, all received CAPWAP and
DTLS protocol messages received MUST be ignored.
AC: This is an invalid state transition for the AC.
DTLS Teardown to Dead (w): This transition occurs when the DTLS
session has been shut down.
WTP: This is an invalid state transition for the WTP.
AC: This state transition occurs when the AC has successfully
cleaned up all resources associated with the control plane
DTLS session , or if the DTLSSessionDelete timer (see
Section 4.7.6) expires. The data plane DTLS session is also
shut down, and all resources released, if a DTLS session was
established for the data plane. Any timers set for the
current instance of the state machine are also cleared. The
AC's Service thread is terminated.
2.3.2. CAPWAP/DTLS Interface
This section describes the DTLS Commands used by CAPWAP, and the
notifications received from DTLS to the CAPWAP protocol stack.
2.3.2.1. CAPWAP to DTLS Commands
Six commands are defined for the CAPWAP to DTLS API. These
"commands" are conceptual, and may be implemented as one or more
function calls. This API definition is provided to clarify
interactions between the DTLS and CAPWAP components of the integrated
CAPWAP state machine.
Below is a list of the minimal command APIs:
o DTLSStart is sent to the DTLS component to cause a DTLS session to
be established. Upon invoking the DTLSStart command, the WaitDTLS
timer is started. The WTP initiates this DTLS command, as the AC
does not initiate DTLS sessions.
o DTLSListen is sent to the DTLS component to allow the DTLS
component to listen for incoming DTLS session requests.
o DTLSAccept is sent to the DTLS component to allow the DTLS session
establishment to continue successfully.
o DTLSAbortSession is sent to the DTLS component to cause the
session that is in the process of being established to be aborted.
This command is also sent when the WaitDTLS timer expires. When
this command is executed, the FailedDTLSSessionCount counter is
incremented.
o DTLSShutdown is sent to the DTLS component to cause session
teardown.
o DTLSMtuUpdate is sent by the CAPWAP component to modify the MTU
size used by the DTLS component. See Section 3.5 for more
information on MTU Discovery. The default size is 1468 bytes.
2.3.2.2. DTLS to CAPWAP Notifications
DTLS notifications are defined for the DTLS to CAPWAP API. These
"notifications" are conceptual and may be implemented in numerous
ways (e.g., as function return values). This API definition is
provided to clarify interactions between the DTLS and CAPWAP
components of the integrated CAPWAP state machine. It is important
to note that the notifications listed below MAY cause the CAPWAP
state machine to jump from one state to another using a state
transition not listed in Section 2.3.1. When a notification listed
below occurs, the target CAPWAP state shown in Figure 4 becomes the
current state.
Below is a list of the API notifications:
o DTLSPeerAuthorize is sent to the CAPWAP component during DTLS
session establishment once the peer's identity has been received.
This notification MAY be used by the CAPWAP component to authorize
the session, based on the peer's identity. The authorization
process will lead to the CAPWAP component initiating either the
DTLSAccept or DTLSAbortSession commands.
o DTLSEstablished is sent to the CAPWAP component to indicate that a
secure channel now exists, using the parameters provided during
the DTLS initialization process. When this notification is
received, the FailedDTLSSessionCount counter is reset to zero.
When this notification is received, the WaitDTLS timer is stopped.
o DTLSEstablishFail is sent when the DTLS session establishment has
failed, either due to a local error or due to the peer rejecting
the session establishment. When this notification is received,
the FailedDTLSSessionCount counter is incremented.
o DTLSAuthenticateFail is sent when DTLS session establishment has
failed due to an authentication error. When this notification is
received, the FailedDTLSAuthFailCount counter is incremented.
o DTLSAborted is sent to the CAPWAP component to indicate that
session abort (as requested by CAPWAP) is complete; this occurs to
confirm a DTLS session abort or when the WaitDTLS timer expires.
When this notification is received, the WaitDTLS timer is stopped.
o DTLSReassemblyFailure MAY be sent to the CAPWAP component to
indicate DTLS fragment reassembly failure.
o DTLSDecapFailure MAY be sent to the CAPWAP module to indicate a
decapsulation failure. DTLSDecapFailure MAY be sent to the CAPWAP
module to indicate an encryption/authentication failure. This
notification is intended for informative purposes only, and is not
intended to cause a change in the CAPWAP state machine (see
Section 12.4).
o DTLSPeerDisconnect is sent to the CAPWAP component to indicate the
DTLS session has been torn down. Note that this notification is
only received if the DTLS session has been established.
2.4. Use of DTLS in the CAPWAP Protocol
DTLS is used as a tightly integrated, secure wrapper for the CAPWAP
protocol. In this document, DTLS and CAPWAP are discussed as
nominally distinct entities; however, they are very closely coupled,
and may even be implemented inseparably. Since there are DTLS
library implementations currently available, and since security
protocols (e.g., IPsec, TLS) are often implemented in widely
available acceleration hardware, it is both convenient and forward-
looking to maintain a modular distinction in this document.
This section describes a detailed walk-through of the interactions
between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP
to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be
encountered during the normal course of operation.
2.4.1. DTLS Handshake Processing
Details of the DTLS handshake process are specified in [RFC4347].
This section describes the interactions between the DTLS session
establishment process and the CAPWAP protocol. Note that the
conceptual DTLS state is shown below to help understand the point at
which the DTLS states transition. In the normal case, the DTLS
handshake will proceed as shown in Figure 5. (NOTE: this example
uses certificates, but pre-shared keys are also supported.)
============ ============ WTP AC ============ ============ ClientHello ------> <------ HelloVerifyRequest (with cookie) ClientHello ------> (with cookie) <------ ServerHello <------ Certificate <------ ServerHelloDone (WTP callout for AC authorization occurs in CAPWAP Auth state) Certificate* ClientKeyExchange CertificateVerify* ChangeCipherSpec Finished ------> (AC callout for WTP authorization occurs in CAPWAP Auth state) ChangeCipherSpec <------ Finished Figure 5: DTLS Handshake DTLS, as specified, provides its own retransmit timers with an exponential back-off. [RFC4347] does not specify how long retransmissions should continue. Consequently, timing out incomplete DTLS handshakes is entirely the responsibility of the CAPWAP module. The DTLS implementation used by CAPWAP MUST support TLS Session Resumption. Session resumption is typically used to establish the DTLS session used for the data channel. Since the data channel uses different port numbers than the control channel, the DTLS implementation on the WTP MUST provide an interface that allows the CAPWAP module to request session resumption despite the use of the different port numbers (TLS implementations usually attempt session resumption only when connecting to the same IP address and port number). Note that session resumption is not guaranteed to occur, and a full DTLS handshake may occur instead.
The DTLS implementation used by CAPWAP MUST use replay detection, per Section 3.3 of [RFC4347]. Since the CAPWAP protocol handles retransmissions by re-encrypting lost frames, any duplicate DTLS frames are either unintentional or malicious and should be silently discarded.2.4.2. DTLS Session Establishment
The WTP, either through the Discovery process or through pre- configuration, determines to which AC to connect. The WTP uses the DTLSStart command to request that a secure connection be established to the selected AC. Prior to initiation of the DTLS handshake, the WTP sets the WaitDTLS timer. Upon invoking the DTLSStart or DTLSListen commands, the WTP and AC, respectively, set the WaitDTLS timer. If the DTLSEstablished notification is not received prior to timer expiration, the DTLS session is aborted by issuing the DTLSAbortSession DTLS command. This notification causes the CAPWAP module to transition to the Idle state. Upon receiving a DTLSEstablished notification, the WaitDTLS timer is deactivated.2.4.3. DTLS Error Handling
If the AC or WTP does not respond to any DTLS handshake messages sent by its peer, the DTLS specification calls for the message to be retransmitted. Note that during the handshake, when both the AC and the WTP are expecting additional handshake messages, they both retransmit if an expected message has not been received (note that retransmissions for CAPWAP Control messages work differently: all CAPWAP Control messages are either requests or responses, and the peer who sent the request is responsible for retransmissions). If the WTP or the AC does not receive an expected DTLS handshake message despite of retransmissions, the WaitDTLS timer will eventually expire, and the session will be terminated. This can happen if communication between the peers has completely failed, or if one of the peers sent a DTLS Alert message that was lost in transit (DTLS does not retransmit Alert messages). If a cookie fails to validate, this could represent a WTP error, or it could represent a DoS attack. Hence, AC resource utilization SHOULD be minimized. The AC MAY log a message indicating the failure, and SHOULD treat the message as though no cookie were present. Since DTLS Handshake messages are potentially larger than the maximum record size, DTLS supports fragmenting of Handshake messages across multiple records. There are several potential causes of re-assembly
errors, including overlapping and/or lost fragments. The DTLS component MUST send a DTLSReassemblyFailure notification to the CAPWAP component. Whether precise information is given along with notification is an implementation issue, and hence is beyond the scope of this document. Upon receipt of such an error, the CAPWAP component SHOULD log an appropriate error message. Whether processing continues or the DTLS session is terminated is implementation dependent. DTLS decapsulation errors consist of three types: decryption errors, authentication errors, and malformed DTLS record headers. Since DTLS authenticates the data prior to encapsulation, if decryption fails, it is difficult to detect this without first attempting to authenticate the packet. If authentication fails, a decryption error is also likely, but not guaranteed. Rather than attempt to derive (and require the implementation of) algorithms for detecting decryption failures, decryption failures are reported as authentication failures. The DTLS component MUST provide a DTLSDecapFailure notification to the CAPWAP component when such errors occur. If a malformed DTLS record header is detected, the packets SHOULD be silently discarded, and the receiver MAY log an error message. There is currently only one encapsulation error defined: MTU exceeded. As part of DTLS session establishment, the CAPWAP component informs the DTLS component of the MTU size. This may be dynamically modified at any time when the CAPWAP component sends the DTLSMtuUpdate command to the DTLS component (see Section 2.3.2.1). The value provided to the DTLS stack is the result of the MTU Discovery process, which is described in Section 3.5. The DTLS component returns this notification to the CAPWAP component whenever a transmission request will result in a packet that exceeds the MTU.2.4.4. DTLS Endpoint Authentication and Authorization
DTLS supports endpoint authentication with certificates or pre-shared keys. The TLS algorithm suites for each endpoint authentication method are described below.2.4.4.1. Authenticating with Certificates
CAPWAP implementations only use cipher suites that are recommended for use with DTLS, see [DTLS-DESIGN]. At present, the following algorithms MUST be supported when using certificates for CAPWAP authentication: o TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
The following algorithms SHOULD be supported when using certificates: o TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246] The following algorithms MAY be supported when using certificates: o TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246] o TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC5246] Additional ciphers MAY be defined in subsequent CAPWAP specifications.2.4.4.2. Authenticating with Pre-Shared Keys
Pre-shared keys present significant challenges from a security perspective, and for that reason, their use is strongly discouraged. Several methods for authenticating with pre-shared keys are defined [RFC4279], and we focus on the following two: o Pre-Shared Key (PSK) key exchange algorithm - simplest method, ciphersuites use only symmetric key algorithms. o DHE_PSK key exchange algorithm - use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). The first approach (plain PSK) is susceptible to passive dictionary attacks; hence, while this algorithm MUST be supported, special care should be taken when choosing that method. In particular, user- readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD be strongly discouraged. The following cryptographic algorithms MUST be supported when using pre-shared keys: o TLS_PSK_WITH_AES_128_CBC_SHA [RFC5246] o TLS_DHE_PSK_WITH_AES_128_CBC_SHA [RFC5246] The following algorithms MAY be supported when using pre-shared keys: o TLS_PSK_WITH_AES_256_CBC_SHA [RFC5246] o TLS_DHE_PSK_WITH_AES_256_CBC_SHA [RFC5246] Additional ciphers MAY be defined in following CAPWAP specifications.
2.4.4.3. Certificate Usage
Certificate authorization by the AC and WTP is required so that only an AC may perform the functions of an AC and that only a WTP may perform the functions of a WTP. This restriction of functions to the AC or WTP requires that the certificates used by the AC MUST be distinguishable from the certificate used by the WTP. To accomplish this differentiation, the x.509 certificates MUST include the Extended Key Usage (EKU) certificate extension [RFC5280]. The EKU field indicates one or more purposes for which a certificate may be used. It is an essential part in authorization. Its syntax is described in [RFC5280] and [ISO.9834-1.1993] and is as follows: ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER Here we define two KeyPurposeId values, one for the WTP and one for the AC. Inclusion of one of these two values indicates a certificate is authorized for use by a WTP or AC, respectively. These values are formatted as id-kp fields. id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } All capwap devices MUST support the ExtendedKeyUsage certificate extension if it is present in a certificate. If the extension is present, then the certificate MUST have either the id-kp-capwapAC or the id-kp-anyExtendedKeyUsage keyPurposeID to act as an AC. Similarly, if the extension is present, a device MUST have the id-kp- capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP. Part of the CAPWAP certificate validation process includes ensuring that the proper EKU is included and allowing the CAPWAP session to be established only if the extension properly represents the device. For instance, an AC SHOULD NOT accept a connection request from another AC, and therefore MUST verify that the id-kp-capwapWTP EKU is present in the certificate. CAPWAP implementations MUST support certificates where the common name (CN) for both the WTP and AC is the MAC address of that device.
The MAC address MUST be encoded in the PrintableString format, using the well-recognized MAC address format of 01:23:45:67:89:ab. The CN field MAY contain either of the EUI-48 [EUI-48] or EUI-64 [EUI-64] MAC Address formats. This seemingly unconventional use of the CN field is consistent with other standards that rely on device certificates that are provisioned during the manufacturing process, such as Packet Cable [PacketCable], Cable Labs [CableLabs], and WiMAX [WiMAX]. See Section 12.8 for more information on the use of the MAC address in the CN field. ACs and WTPs MUST authorize (e.g., through access control lists) certificates of devices to which they are connecting, e.g., based on the issuer, MAC address, or organizational information specified in the certificate. The identities specified in the certificates bind a particular DTLS session to a specific pair of mutually authenticated and authorized MAC addresses. The particulars of authorization filter construction are implementation details which are, for the most part, not within the scope of this specification. However, at minimum, all devices MUST verify that the appropriate EKU bit is set according to the role of the peer device (AC versus WTP), and that the issuer of the certificate is appropriate for the domain in question.2.4.4.4. PSK Usage
When DTLS uses PSK Ciphersuites, the ServerKeyExchange message MUST contain the "PSK identity hint" field and the ClientKeyExchange message MUST contain the "PSK identity" field. These fields are used to help the WTP select the appropriate PSK for use with the AC, and then indicate to the AC which key is being used. When PSKs are provisioned to WTPs and ACs, both the PSK Hint and PSK Identity for the key MUST be specified. The PSK Hint SHOULD uniquely identify the AC and the PSK Identity SHOULD uniquely identify the WTP. It is RECOMMENDED that these hints and identities be the ASCII HEX-formatted MAC addresses of the respective devices, since each pairwise combination of WTP and AC SHOULD have a unique PSK. The PSK Hint and Identity SHOULD be sufficient to perform authorization, as simply having knowledge of a PSK does not necessarily imply authorization. If a single PSK is being used for multiple devices on a CAPWAP network, which is NOT RECOMMENDED, the PSK Hint and Identity can no longer be a MAC address, so appropriate hints and identities SHOULD be selected to identify the group of devices to which the PSK is provisioned.
(next page on part 3)