Subject: [Capwap] state machine issues

From: "Scott Kelly" <[email-masked]>
Date: Fri, 4 Jan 2008 14:28:46 -0800

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
_________________________________________________________________
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, 15 Jan 2008 16:55:15 -0800

My apologies for the latency. Responses below.

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

Actually, the state machine does not require this, but allows for it. If
an AC wants to only accept connections from specific IP addresses,
whether the list was generated from discovery, or through a
pre-configured list, this is possible. It is not recommended, are the
text states.

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

At first glance, I don't think I have issues with your proposal, but do
not fully understand the possible impact of the changes.

> 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

receives

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

It seems to me like we really aren't changing anything because
ultimately, the state machine still has a state transition prior to the
setup of DTLS, so the same confusion about whether the AC maintains
state prior to DTLS setup still exists. I continue to believe that the
current draft does not make this necessary since the "listener thread"
operates on a separate context that is global - not per WTP.

So it seems to me like the current draft already defines the API between
DTLS and CAPWAP, and therefore addresses the other requirement we once
had about not wanting CAPWAP to have to parse and understand the DTLS
state machine. I continue to believe this should be a design goal. In
your proposed model, CAPWAP needs to validate whether the cookie is
valid (or at least since the state machine description includes this,
then I presume it does). I would prefer let the DTLS engine do this and
simply report back on what's working/not working.

PatC