tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 5415

 
 
 

Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification

Part 2 of 6, p. 11 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 11 
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.

Top      Up      ToC       Page 12 
   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.

Top      Up      ToC       Page 13 
   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
                 ------------------------------------>

Top      Up      ToC       Page 14 
                      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 --]

Top      Up      ToC       Page 15 
                        (-- 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.

Top      Up      ToC       Page 16 
                            /-------------------------------------\
                            |          /-------------------------\|
                            |         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

Top      Up      ToC       Page 17 
   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.

Top      Up      ToC       Page 18 
   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.

Top      Up      ToC       Page 19 
      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.

Top      Up      ToC       Page 20 
      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.

Top      Up      ToC       Page 21 
      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).

Top      Up      ToC       Page 22 
   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

Top      Up      ToC       Page 23 
            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

Top      Up      ToC       Page 24 
            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.

Top      Up      ToC       Page 25 
   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).

Top      Up      ToC       Page 26 
   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.

Top      Up      ToC       Page 27 
      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).

Top      Up      ToC       Page 28 
      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).

Top      Up      ToC       Page 29 
            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

Top      Up      ToC       Page 30 
                  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.

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
   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.)

Top      Up      ToC       Page 34 
           ============                         ============
               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.

Top      Up      ToC       Page 35 
   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

Top      Up      ToC       Page 36 
   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]

Top      Up      ToC       Page 37 
   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.

Top      Up      ToC       Page 38 
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.

Top      Up      ToC       Page 39 
   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 RFC Part