Capwap Mailing List: Issue 30: Inconsistent state tracking on AC prior to DTLSEstablishment (was: state machine issues)

[Pat Calhoun (pacalhou) (pcalhoun]

Scott, given that no one else seems to object to the change, and that
Charles is comfortable with the change, can we consider this closed?

PatC 

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Tuesday, January 15, 2008 4:55 PM
To: Scott Kelly; capwap
Subject: Re: [Capwap] state machine issues

My apologies for the latency. Responses below.

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

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.

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

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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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