Subject: [Capwap] Proposed Text: Issue 40: State Machine inconsistency around Discovery being optional

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 12 Mar 2008 11:33:11 -0700

All,

Following up on issue 40, which was created as a result of the
presentation made during the face to face in Philadelphia, I am
including here the proposed text. The issue, as described by Scott, was
that the text was inconsistent when it came to whether Discovery
Requests should be optional. Of note, the Listener state was expected to
call DTLSListen() when an event would occur, but if no Discovery
Requests were received, no event would cause the function to be called,
and therefore no incoming DTLS sessions would be accepted.

The fix is to introduce a new thread, called Discovery. It is
responsible for the handling of the Discovery Requests on the AC. The
listener thread now sits in DTLSListen(), and when a ClientHello has
been validated, a notification is received causing the state transition
to move to the Authorized state, which is the trigger that causes the
Listener thread to for a WTP specific Service thread.

Note that I am only including the modified text. The state labels were
changed, and I did not include the modified text that reflects that
because it would be too complex to identify the changes for issue 40.

As we agreed during the meeting, the plan is to submit the -10 version
by week's end so the chairs can start the WG last call. I would
appreciate a quick review.

<text>
2.3.  CAPWAP State Machine Definition
[...]

                            /-------------------------------------\
                            |          /-------------------------\|
                            |         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 |
            +---------+&

[...]
   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 Figure 3 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 Figure 3 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 Figure 3 are represented by
      alphabetic characters.

2.3.1.  CAPWAP Protocol State Transitions
[...]

   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 Idle (2):  This transition occurs on the AC's Discovery
      thread when the Discovery processing is complete.

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

      AC:  This state transition is executed by the AC's Discovery
         thread when it has transmitted the Discovery Response, in
         response to a Discovery Request.
[...]

   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, 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:  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).
[...]

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

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

      AC:  The AC's Listener initiates this state transition when it
         receives a DTLSEstablishFail notification from DTLS (see
         Section 2.3.2.2).  This error notification aborts the secure
         DTLS session establishment.  When this notification is
         received, the FailedDTLSSessionCount counter is incremented.
         The Listener thread then invokes the DTLSListen command (see
         Section 2.3.2.1).

   DTLS Setup to Authorize (5):  This transition occurs when an incoming
      DTLS session is being established, and the DTLS stack needs
      authorization to proceed with the session establishment.

      WTP:  This state transition occurs when the WTP receives the
         DTLSPeerAuthorize notification (see Section 2.3.2.2).  Upon
         entering this state, the WTP performs an authorization check
         against the AC credentials.  See Section 2.4.4 for more
         information on AC authorization.

      AC:  This state transition is handled by the AC's Listener thread
         when the DTLS module initiates the DTLSPeerAuthorize
         notification (see Section 2.3.2.2).  The Listener thread forks
         an instance of the Service thread, along with a copy of the
         state context.  Once created, the Service thread performs an
         authorization check against the WTP credentials.  See
         Section 2.4.4 for more information on WTP authorization.

   Authorize to DTLS Setup (6):  This transition is executed by the
      Listener thread to enable it to listen for new incoming sessions.

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

      AC:  This state transition occurs when the AC's Listener thread
         has created the WTP context and the Service thread.  The
         Listener thread then invokes the DTLSListen command (see
         Section 2.3.2.1).
[...]

12.3.  Discovery or DTLS Setup Attacks
[...]
   Some CAPWAP implementations may wish to restrict the DTLS setup
   process to only those peers that have been configured in the access
   control list, 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.
</text>

Further, in the process of making this change, two state transitions
were removed (one of them was actually duplicative. Here is the removed
text from -09.

<removed text>
   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 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).
</removed text>

Comments?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 13 Mar 2008 11:20:35 -0700 (GMT-07:00)

This looks fine to me.

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Mar 12, 2008 11:33 AM
>To: [email-masked]
>Subject: [Capwap] Proposed Text: Issue 40: State Machine inconsistency	around Discovery being optional
>
>All,
>