Capwap Mailing List: state machine issues

[Scott Kelly (skelly]

I've been trying to understand how the latest state machine proposals
got to be so far away from my understanding of the capwap world, and I
think I've finally sorted it out. 

Last January, there was a document update following the interim capwap
meeting (from version 03 to 04). I was very sick for several weeks
around that time, and I missed the update. There were dramatic changes
to the state machine introduced in that update (including addition of
discovery state in the AC, and use of that state to plumb DTLS listen
commands). Also, the client cookie (HelloVerifyRequest), while still
showing up in ladder diagrams, was no longer accommodated in the text or
the state machine.

At the Vancouver meeting we agreed that discovery state should not be
maintained, and Pat and Charles proposed some state machine changes
intended to better illustrate the differences between the AC and WTP.
However, the last proposal I saw did not fully address the
problems/inconsistencies resulting from the AC discovery state
dependencies introduced in 04.

Here's an example, from the working text for 09:

   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.


This text seems to have originally assumed that the AC would listen
*per-WTP* based on receipt of a discovery request from that WTP, but
this is inconsistent in multiple ways. Most importantly, discovery is
optional, so the AC must *always* be listening for incoming (DTLS)
ClientHello messages. A simple way to represent this is to say that the
AC is listening while in the Idle state, and receipt of an acceptable
ClientHello (e.g. with a valid cookie) causes it to transition from Idle
to DTLS Setup. You could also say the AC is always in DTLS Setup state,
but that complicates things in terms of representing discovery message
processing. I think using idle for this works best.

Before we go any further with this, we need to agree on whether use of
client cookies is required or optional. The protocol is simpler if they
are always required, but there are probably deployment scenarios in
which the potential for AC DoS attacks is minimal, so one might argue
that they shouldn't be strictly required for those scenarios. In the
interest of implementation simplicity, I would vote to simply make them
mandatory, but I will assume they are optional below with the
understanding that the proposed language will be simpler if they become
mandatory.

Another related decision might be a little more rat-hole prone (or not):
what are the state transitions required to implement the
HelloVerifyRequest? The simplest is to add a C next to the Idle state
(an Idle to Idle transition), with something resembling the following
text:

   Idle to Idle (b):  This transition may occur on the AC when it
receives
     a ClientHello

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

      AC:  When the WTP sends a ClientHello, the AC optionally sends
        a HelloVerifyRequest containing a unique cookie that the WTP
        must return in a subsequent HelloRequest. This transition also
        occurs if a ClientHello contains an invalid cookie.

Note that 3 things can happen when the AC receives a ClientHello; the AC

  1) drops the message, because it contains an invalid cookie, or
because
    the AC is rate limiting handshakes 

  2) it creates a cookie and sends a HelloVerifyRequest

  3) it deems the incoming HelloRequest acceptable (either because it
    contains a valid cookie or because client cookies are not required),

    and it transitions from Idle to DTLS Setup

Rather than idle to idle, we could add another AC-only state that it
transitions into to gen/send the cookie, and then back to Idle, but I
think Idle-Idle works okay and is simpler.

Other text that needs updating is the Idle to DTLS Setup transition:

   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 an alternative means for choosing an AC (e.g. DNS,
         DHCP option, or static configuration).

      AC:   The AC initiates this transition upon receipt of an
acceptable
         ClientHello message
------------------------------------------------------------

If we can fix the inconsistencies and artifacts resulting from the
introduction/removal of discovery state, I think that clears up the most
significant remaining state machine issues.

--Scott