Subject: [Capwap] Issue 30: Inconsistent state tracking on AC prior to DTLS Establishment

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 4 Dec 2007 11:16:53 -0800

I wanted to provide a follow-up based on the conversation during the
meeting yesterday. The issue that is being raised in this issue is that
the state machine doesn't really work well on the AC. There is text that
states that the AC has a different "state context" per WTP, but right
now this would require that the AC maintains state during the discovery,
etc. However, we have all agreed that the AC should not have to do so.
So we agreed that we needed to provide more clarity on the state machine
that allows for the AC to provide services such as responding to
Discovery Requests, without explicitely maintaining per WTP state. 
 
I am working on modifications to the state machine, and expect to have
this sent to the list later today.
 
PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 4 Dec 2007 15:27:34 -0800

All,

I wanted to send the new state machine in order to get as many eyes on
this one as possible. I have done what I believe is a very thorough
review, but this is a complex state machine. I will also include all of
the state machine text in order to make it simpler to review. Note that
other than the teardown, no changes were made from the join/config
states on (meaning, only the lower part of the state machine figure was
modified).

Since there is significant text here, I want to provide a little bit of
information on how this now works:
- The WTP behaves pretty much the same as before, meaning that it uses a
single state context. When a connection attempt fails, the state machine
goes back to the Idle state, unless some counters have hit a threshold,
in which case the state transitions to the Sulking state. As before the
WTP can do the Discovery phase, in which case either state (5) or (c) is
used. 
- The AC now defines two separate threads; Listener and Service. The
Listener is the main thread that handles the discovery messages. Once a
connection request is received, it spawns a Service thread to deal with
the WTP. You will notice that the new state machine uses numerals when
it applies either only to the WTP, or to the Listener thread. All state
transitions that use alphabetic, or symbols, is for the Service thread
or the WTP. The biggest difference in how the state machines work is
that on the AC, when a connection is being established, and fails, the
Service thread's state moves back to the DTLS Setup state, not Idle.
When the error thresholds are hit, the state moves to Sulking - the
quiet period. You will also notice a new Dead state, which is ONLY valid
for the Service thread, which is where the thread is terminated, and
resources are freed.
 
Comments welcomed,

PatC

<text>
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.

                            /-------------------------------------\
                            |          /-------------------------\|
                            |         w|                         ||
                            |    x+----------+ y +------------+  ||
                            |     |   Run    |-->|   Reset    |-\||
                            |     +----------+   +------------+ |||
                           u|  V      ^           ^     ^      z|||
                +------------+--------/           |     |       |||
                | Data Check |             /-------/    |       |||
                +------------+<-------\   |             |       |||
                                      |   |             |       |||
                       /------------------+--------\    |       |||
                      m|             t|  o|    q   v   r|       |||
               +--------+     +-----------+     +--------------+|||
               |  Join  |---->| Configure |     |  Image Data  ||||
               +--------+  n  +-----------+     +--------------+|||
                ^   |l                 p|                    s| |||
                |   |                   \-------------------\ | |||
                |   \--------------------------------------\| | |||
                \------------------------\                 || | |||
         /--------------<----------------+---------------\ || | |||
         | /------------<----------------+-------------\ | || | |||
         | |                      i      |k           8| | vv v vvv
         | |  d+----------------+<--+--------------+   +-----------+
       /-|-|---|   DTLS Setup   |   | DTLS Connect |-->|  DTLS TD  |
       | | |   +----------------+e  +--------------+ 7 +-----------+
       | | |   6|   ^      ^  |f         ^       j|      ^  |~
       v v v    |   |      |  |          |        |      |  |
       | | |    |   |      |  \-------\  |   /----+------/  |
       | | |    |   |      |          |  |   |    \---\     |
       | | |    v  c|  1   |5    2    v  |g  |h       v     v
       | | \->+------+-->+------+   +-----------+    +--------+
       | |    | Idle |   | Disc |   | Authorize |    |  Dead  |
       | |    +------+<--+------+   +-----------+    +--------+
       | |        ^    0      |3                         ^
       | |        |           |                          |b
       | |9       |4          |                          |
       | \->+---------+<------/                          |
       \--->| Sulking |----------------------------------/
            +---------+
                      a

                 Figure 3: 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 messages 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 two 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 the shared
      services, which includes receiving and responding to Discovery
      Requests.  The Listener thread handles the common tasks, up to the
      DTLS Setup state.  The state machine transitions in the above
      figure are represented by numerals.

   Service Thread -   The AC's Service thread handles the per WTP
      states, and one such thread exists per WTP connection.  This
      thread starts during the DTLS Setup state, which is when the
      DTLSListen command is invoked.  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.  The state machine transitions in the above
      figure are represented by alphabetic characters (including
      symbols).

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.

   Idle to Discovery (1):  This transition occurs once device
      initialization is complete.

      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 Listener
         thread, and occurs when a Discovery Request message is
         received.  The AC SHOULD respond with a Discovery Response
         message (see Section 5.2).  The AC SHOULD NOT maintain WTP
         state at this point (see Section 12 for more information).

   Discovery to Discovery (2):  In the Discovery state, the WTP
      determines which AC to connect to.

      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 (0):  This transition occurs on the AC's Listener
      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 Listener thread
         when it has transmitted the Discovery Response, in response to
         a Discovery Request.

   Discovery to Sulking (3):  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
         received MUST be ignored.

      AC:  This is an invalid state transition for the AC.

   Sulking to Idle (4):  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 (a):  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:  All packets receive from the WTP on the AC's Service thread,
         while in the sulking state, are ignored.

   Sulking to Dead (b):  This transition occurs on the AC when the quiet
      period expires.

      WTP:  This is an invalid state transition for the WTP.

      AC:  The AC enters this state when the SilentInterval timer (see
         Section 4.7) expires.  The AC must clean up all resources
         associated with the control plane DTLS session.  The data plane
         DTLS session is also shutdown, and all resources freed, 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.

   Idle to DTLS Setup (c):  This transition occurs to establish a secure
      DTLS session with the peer.

      WTP:  The WTP initiates this transition by invoking the DTLSStart
         command, which starts the DTLS session establishment with the
         chosen AC.  When the discovery phase is bypassed, it is assumed
         the WTP has locally configured ACs.

      AC:  The AC initiates this transition by invoking the DTLSListen
         command (see Section 2.3.2.1), which informs the DTLS stack
         that it is willing to listen for an incoming session.  The AC's
         Listener thread forks an instance of the Service thread, along
         with a copy of the state context.  If the AC had maintained WTP
         state information during the Discovery exchange, or through
         some other means that may include static configuration of WTPs,
         the AC MAY provide optional qualifiers in the DTLSListen
         command to only accept session requests a specific WTP.  Note
         that the AC SHOULD NOT maintain state information based on an
         unsecured Discovery Request message, as this can lead to a
         Denial of Service attack (see Section 12).  In such instances,
         the AC MUST ensure that this state information is freed after a
         period, which is implementation specific.

   Discovery to DTLS Setup (5):  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 which AC to
         connect to 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 (6):  This transition occurs when the DTLS
      connection setup has failed.

      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.

      AC:  This is an invalid state transition for the AC.

   DTLS Setup to Sulking (d):  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:  The AC enters this state with the specific WTP when the
         FailedDTLSSessionCount or the FailedDTLSAuthFailCount counter
         reaches MaxFailedDTLSSessionRetry variable (see Section 4.8).
         Upon entering this state, the AC's Service thread MUST start
         the SilentInterval timer, and ignore all CAPWAP and DTLS
         protocol messages received from the WTP.  The AC immediately
         transitions the state to Idle.

   DTLS Setup to DTLS Setup (e):  This transition occurs when the DTLS
      Session failed to be established.

      WTP:  This is an invalid state transition for the WTP.

      AC:  The AC initiates this state transition by the Service thread
         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.

   DTLS Setup to Authorize (f):  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 occurs when the AC receives the
         DTLSPeerAuthorize notification (see Section 2.3.2.2).  Upon
         entering this state, the AC performs an authorization check
         against the WTP credentials.  See Section 2.4.4 for more
         information on WTP authorization.

   Authorize to DTLS Connect (g):  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 (h):  This transition occurs to notify the
      DTLS stack that the session should be aborted.

      WTP:  This state transition occurs when the WTP was 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).

      AC:  This state transition occurs when the AC was 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).

   DTLS Connect to DTLS Teardown (7):  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.

      AC:  This is an invalid state transition for the AC.

   DTLS Connect to DTLS Setup (i):  This transition occurs when the DTLS
      Session failed to be established.

      WTP:  This is an invalid state transition for the WTP.

      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).

   DTLS Connect to Dead (j):  This transition occurs when the DTLS
      Session failed to be established.

      WTP:  This is an invalid state transition for the WTP.

      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 either the
         FailedDTLSAuthFailCount and FailedDTLSSessionCount counters
         have reached the value of the MaxFailedDTLSSessionRetry
         variable (see Section 4.8).

   DTLS Connect to Join (k):  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.

      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, and the WaitJoin timer is started (see
         Section 4.7).

   Join to DTLS Teardown (l):  This transition occurs when the join
      process failed.

      WTP:  This state transition occurs when the WTP receives a Join
         Response message with a Result Code message element containing
         an error, 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, or if the WaitDTLS timer expires.  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.

      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.

   Join to Image Data (m):  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 and the
         included 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.  The AC MUST transmit an
         Image Data Response message (see Section 9.1.2) to the WTP,
         which includes a portion of the firmware.  The AC MUST start
         the ImageDataStartTimer timer (see Section 4.7).

   Join to Configure (n):  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, and determines that the included
         Image Identifier message element is the same as its currently
         running image.  The WTP transmits the Configuration Status
         message (see Section 8.2) to the AC with message elements
         describing its current configuration.  The WTP also starts the
         ResponseTimeout timer (see Section 4.7).

      AC:  This state transition occurs immediately after the AC
         transmits the Join Response message to the WTP.  If the AC
         receives the Configuration Status message from the WTP, the AC
         MUST transmit a Configuration Status Response message (see
         Section 8.3) to the WTP, and MAY include specific message
         elements to override the WTP's configuration.  The AC also
         starts the ChangeStatePendingTimer timer (see Section 4.7).

   Configure to Reset (o):  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.

      WTP:  The WTP enters the Reset state when it receives a
         Configuration Status Response 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 (p):  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.

      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 WTP MAY tear down the DTLS session if it
         receives frequent DTLSDecapFailure notifications.

   Image Data to Image Data (q):  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.

      AC:  This state transition occurs when the AC receives the Image
         Data Request message from the WTP while already in the Image
         Data state.  The AC resets the ImageDataStartTimer timer.

   Image Data to Reset (r):  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, 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 when an error occurs during the
         image download process or if the ImageDataStartTimer timer
         expires.

   Image Data to DTLS Teardown (s):  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.

      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 WTP MAY tear down the DTLS session if it
         receives frequent DTLSDecapFailure notifications.

   Configure to Data Check (t):  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
         initializes the EchoInterval timer (see Section 4.7), and
         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 (see
         Section 4.7).

   Data Check to DTLS Teardown (u):  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 before a CAPWAP transmission
         timeout occurs.

      AC:  The AC enters this state when the DataCheckTimer timer
         expires (see Section 4.7).

   Data Check to Run (V):  This state transition occurs when the linkage
      between the control and data channels has occured, 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) and transmits a Data Channel Keep Alive packet
         (see Section 4.4.1).  The WTP then starts the
         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 (w):  This state transition occurs when an error
      has occured in the DTLS stack, causing the DTLS session to be
      torndown.

      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).

      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 WTP 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).

   Run to Run (x):  This is the normal state of operation.

      WTP:  This is the WTP's normal state of operation.  There are many
         events that result 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.

         Clear Config Request:  The WTP receives a Clear Configuration
            Request message (see Section 8.8).  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 message
            to the AC (see Section 9.6).  The WTP receives a Data
            Transfer Response message from the AC (see Section 9.7).

         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:

         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 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 receives a Data Transfer Request message
            from the WTP (see Section 9.6) and MUST generate a
            corresponding Data Transfer Response message (see
            Section 9.7).

         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 (y):  This state transition is used when either the AC
      or WTP tear 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 (z):  This transition occurs when the CAPWAP
      reset is complete, to terminate the DTLS session.

      WTP:  This state transition occurs when the WTP receives a Reset
         Response message.  This causes the WTP to initiate the
         DTLSShutdown command (see Section 2.3.2.1).

      AC:  This state transition occurs when the AC transmits a Reset
         Response message.  The AC does not invoke the DTLSShutdown
         command (see Section 2.3.2.1).

   DTLS Teardown to Idle (8):  This transition occurs when the DTLS
      session has been shutdown.

      WTP:  This state transition occurs when the WTP has successfully
         cleaned up all resources associated with the control plane DTLS
         session.  The data plane DTLS session is also shutdown, and all
         resources freed, 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 (9):  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 (~):  This transition occurs when the DTLS
      session has been shutdown.

      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.  The data plane DTLS session is also shutdown, and all
         resources freed, 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.

12.3.  Discovery Attacks
[...]
   Some implementations may wish to pass information about clients who
   have passed the discovery phase to the DTLS layer, authorizing only
   those clients to initiate a DTLS handshake.  Note that the impact of
   this on mitigating denial of service attacks against the DTLS layer
   is minimal, because DTLS already uses client-side cookies to minimize
   processor consumption attacks.  As a result, implementations SHOULD
   NOT maintain state between the discovery and DTLS handshake phases of
   the CAPWAP protocol initialization.

</text> 

PatC
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Tuesday, December 04, 2007 11:17 AM
To: capwap
Subject: [Capwap] Issue 30: Inconsistent state tracking on AC prior to
DTLSEstablishment

 
PatC

---

From: "Scott Kelly" <[email-masked]>
Date: Wed, 12 Dec 2007 09:17:09 -0800

We've had a private discussion on this topic off-list, but have not been
able to come to agreement, so I'll make my comments here. I don't think
we should (or need to) introduce these dramatic changes to the document
just prior to last call.

The "problem" we are trying to resolve resulted when someone added
language saying the AC MAY maintain discovery state. This change was
apparently introduced last January. There is no record of working group
or mailing list discussion -- the change just appeared in a document
update. 

On Oct 12, Pat posted a comment saying the state machine language
surrounding discovery state is inconsistent. I agree. It was made
inconsistent by the introduction of discovery state to the AC.

In the issue tracker, there is a comment from Charles which must have
been copied from a private email, as I cannot find it in the list
archives. Here is that comment:

----------------------------------------------
It seems to me that to be in any state at all assumes state is being 
maintained.  Describing a transition from one state to another with
behavior 
caveatted with "if state is being maintained" doesn't make any sense to
me.  
If we have no state, then we have no state transitions.

IIRC, don't we allow connections that don't do discovery first (it's
been a 
while, correct me if I'm wrong)?  In which case, DTLS on the AC should
always 
be listening, and transition "f" can be simply a WTP transition.  The AC

transition would be back to Idle rather than DTLS setup.  You could run 
discovery as its own subgraph of the AC state machine.  If you wanted to
share 
state information between the two, you could have an API to do that.
------------------------------------------------

I agree with what Charles says above.

The changes Pat is proposing do not fix the problem - they actually
introduce new problems and confusion. Since we have agreed that the AC
SHOULD NOT maintain discovery state, the discovery-idle-sulking
transitions make no sense in the context of the AC. However, fixing this
does not require separate state machines, or dramatic changes to the
existing state machine.

In draft-08, section 2.3, just below Figure 3, it says "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." 

This implies that we just need to make sure the state machine language
around AC discovery processing is clear. We can do this by adopting
three simple changes recommended in Pat's text below (with minor edits):

For Idle-to-Discovery it should say:

      AC:  This state transition is executed by the AC
         when a Discovery Request message is
         received.  The AC SHOULD respond with a Discovery Response
         message (see Section 5.2).  The AC SHOULD NOT maintain WTP
         state at this point (see Section 12 for more information).

For Discovery to Idle it should say:  

      AC:  This state transition is executed by the AC after processing
         a Discovery Request.

For Discovery to Sulking it says:
      AC:  This is an invalid state transition for the AC.

With these simple changes, the problem is solved. 

--Scott

> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Tuesday, December 04, 2007 3:28 PM
> To: capwap
> Subject: Re: [Capwap] Issue 30: Inconsistent state tracking 
> on AC prior toDTLSEstablishment
> 
> All,
> 
> The WTP also

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 13 Dec 2007 09:43:33 -0800

The reason why I like the new state machine is that it is very clear on
how the AC deals with the fact that it keeps multiple copies of state
machine context. The previous version really didn't make that clear at
all. As an implementer, I know that I just have to follow the
guidelines, which clearly state when a copy is made, and managed
independently, and when it is deleted.

I recognize this provides some implementation guidance, and some folks
don't like that. But it certainly is clear.

If the issue has to do with the Sulking state, then we can address that.
I would, however, be interested in Charles' take on that issue.

PatC 

-----Original Message-----
From: Scott Kelly [mailto:[email-masked]] 
Sent: Wednesday, December 12, 2007 9:17 AM
To: Pat Calhoun (pacalhou); capwap
Subject: RE: [Capwap] Issue 30: Inconsistent state tracking on AC prior
toDTLSEstablishment

behavior caveatted with "if state is being maintained" doesn't make any
sense to me.  

IIRC, don't we allow connections that don't do discovery first (it's
been a while, correct me if I'm wrong)?  In which case, DTLS on the AC
should always be listening, and transition "f" can be simply a WTP
transition.  The AC

transition would be back to Idle rather than DTLS setup.  You could run
discovery as its own subgraph of the AC state machine.  If you wanted to
share state information between the two, you could have an API to do
that.
------------------------------------------------

--Scott

> Subject: Re: [Capwap] Issue 30: Inconsistent state tracking on AC 
> prior toDTLSEstablishment
> 
> All,
> 

> review, but this is a complex state machine. I will also include all 
> of the state machine text in order to make it simpler to review.
> Note that
> states on (meaning, only the lower part of the state machine figure 
> was modified).
> 
> Since there is significant text here, I want to provide a little bit 
> of information on how this now works:
> - The WTP behaves pretty much the same as before, meaning that it uses

> a single state context. When a connection attempt fails, the state 
> machine goes back to the Idle state, unless some counters have hit a 
> threshold, in which case the state transitions to the Sulking state. 
> As before the WTP can do the Discovery phase, in which case either 
> state
> (5) or (c) is
> used. 
> Listener is the main thread that handles the discovery messages. Once 
> a connection request is received, it spawns a Service thread to deal 
> with the WTP. You will notice that the new state machine uses numerals

> when it applies either only to the WTP, or to the Listener thread.
> All state

> quiet period. You will also notice a new Dead state, which is ONLY 
> valid for the Service thread, which is where the thread is terminated,

> and resources are freed.
> thread
>          the AC MUST ensure that this state information is freed after

> Change

> meeting yesterday. The issue that is being raised in this issue is 
> that the state machine doesn't really work well on the AC. There is 
> text that states that the AC has a different "state context" per WTP, 
> but right now this would require that the AC maintains state during 
> the discovery, etc. However, we have all agreed that the AC should not

> have to do so.
> So we agreed that we needed to provide more clarity on the state 
> machine that allows for the AC to provide services such as responding 
> to Discovery Requests, without explicitely maintaining per WTP state.
>

---

From: Charles Clancy <[email-masked]>
Date: Sat, 15 Dec 2007 17:52:11 -0500

I'm trying to compare Pat and Scott's suggested changes.  Scott is 
suggesting removing (f) and adding a new transition from discovery to 
idle (at least those would be necessary for your proposed text to make 
sense).  Pat is also suggesting doing that, but is also suggesting some 
additional changes that deal with further separation of a logical global 
state machine in the AC and per-WTP state machines (by adding the "Dead" 
state and a rearranging a few more state transitions).

I think there are problems in the state machine if we only patch the 
idle/discovery transitions, as suggested by Scott.  In particular, 
there's no way to throttle failed DTLS connections when no discovery is 
performed (the only error exit from DTLS Setup is to Idle -- we need a 
way to get from DTLS Setup to sulking to prevent repeated crypto 
failures from causing Idle->DTLSSetup->Idle loops).

I'm not seeing Scott's issues with the new state machine (i.e. the "new 
problems and confusion").  The discovery-idle-sulking changes seem 
logically identical between the two proposals.  If there are text 
issues, I think those can be sorted out.

I think Scott's suggestions could work, but would need some additional 
transitions (i.e. DTLS Setup to Sulking for the WTP, among others) to 
make everything work right.

Whether Pat's changes are too drastic -- I guess that's for the WG to 
decide.  I do think Pat has a complete set of changes that solve all the 
issues raised in issue 30.

-- 
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 15 Dec 2007 22:44:07 -0500

<chair hat=off>

Expressing my opinion as an individual technical contributor...

It seems like there are two differences between Pat Calhoun's  
proposal to address Issue #30 and Scott Kelly's:

(1) In Pat's proposed changes, he changes both the state machine  
diagram and the text description of the state machine, while Scott  
proposes to only change the text.

(2) Pat's proposed technical changes to the specification are  
somewhat more extensive than Scott's.

Regarding (1), I generally prefer an approach that includes changing  
the state machine diagram and the text description, because I think  
it makes the changes clearer than just making changes to the text  
description.  While I realize that changing the state machine diagram  
results in changing more lines in the document,  I do not think that  
inherently represents a larger technical change (assuming the same  
changes are made in both cases), and I think the end result is clearer.

Regarding (2), I don't think I have enough understanding of the  
security issues involved to understand whether Scott's proposed  
changes are sufficient, or whether the full extent of Pat's changes  
are necessary.  Based on Charles CLancy's post, though, it looks like  
the set of changes that Pat has proposed would fully address Charles'  
issue, while Scott's proposed changes would not.

Given these two differences, I have a moderate preference for Pat's  
proposed changes.

Margaret

</chair>

On Dec 12, 2007, at 12:17 PM, Scott Kelly wrote:

>> Image
>> Image