Subject: [Capwap] Issue 30: Inconsistent state tracking on AC prior to DTLSEstablishment (was: state machine issues)

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 12 Feb 2008 21:13:23 -0800

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
_________________________________________________________________
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 Kelly" <[email-masked]>
Date: Thu, 14 Feb 2008 14:07:33 -0800

> Charles is comfortable with the change, can we consider this closed?

Let's not mistake malaise for assent.

There were changes introduced in 03 which are inconsistent with other
stated protocol objectives. In particular, 03 introduced discovery state
as an integral element of the protocol, and modified the text in such a
way as to remove the DoS protections afforded by the DTLS client cookie.

This protocol should be suitable for deployment by, among others,
service providers who are subject to the "Internet" threat model. The
exposure that results from the proposed design should be obvious. There
are certainly other deployment types that could be similarly harmed by
this introduction of discovery state, but SP's are a convenient
reference point for this discussion.

Agreeing that discovery state SHOULD NOT be kept, and then (wink, wink,
nudge, nudge) explaining how to maintain discovery state is a bit
disingenuous, if not irresponsible. I don't believe there is any
precedent for this in IETF standards documents.

So, no, I don't think this issue is closed. I proposed straightforward
changes to fix this (see
http://lists.frascone.com/pipermail/capwap/msg04621.html). I don't
understand what the problem is with adopting these proposed
clarifications.

--Scott

---

From: <[email-masked]>
Date: Thu, 14 Feb 2008 20:08:24 -0600

Hi Scott,

I'm not clear that there is a problem with issue 30 past the agreement
we had the last IETF f2f meeting, and I'm reluctant to over-ride the WG
consent.  

I'm not ignoring your comment regarding DOS protection, but since
Charles is not supporting this argument, and it wasn't raised in the f2f
meeting, my direction to the editors is to close issue 30 with the
changes agreed to at the last IETF meeting.   Granted, this may be rough
consensus, but my priority is to get this draft to WGLC and then IESG.  

Scott, if you care to stand behind the agrument you mention here, then
you need to open it as a new issue against the WGLC after we publish.  I
don't think its fair to hold up the draft under these circumstances.  

Sam Hartman has been giving us detailed security support and I will be
interested in his opinions of this issue as well as the few items he
brought up last month after he returns from family leave. 

Best Regards,
Dorothy

> From: ext Scott Kelly [mailto:[email-masked]] 
> Sent: Thursday, February 14, 2008 2:08 PM
> To: Pat Calhoun (pacalhou); capwap
> Subject: Re: [Capwap] Issue 30: Inconsistent state tracking 
> on AC prior toDTLSEstablishment (was: state machine issues)
> 
> There were changes introduced in 03 which are inconsistent 
> with other stated protocol objectives. In particular, 03 
> introduced discovery state as an integral element of the 
> protocol, and modified the text in such a way as to remove 
> the DoS protections afforded by the DTLS client cookie.
> 
> This protocol should be suitable for deployment by, among 
> others, service providers who are subject to the "Internet" 
> threat model. The exposure that results from the proposed 
> design should be obvious. There are certainly other 
> deployment types that could be similarly harmed by this 
> introduction of discovery state, but SP's are a convenient 
> Agreeing that discovery state SHOULD NOT be kept, and then 
> (wink, wink, nudge, nudge) explaining how to maintain 
> discovery state is a bit disingenuous, if not irresponsible. 
> I don't believe there is any precedent for this in IETF 
> standards documents.
> 
> So, no, I don't think this issue is closed. I proposed 
> straightforward changes to fix this (see 
> http://lists.frascone.com/pipermail/capwap/msg04621.html). I 
> don't understand what the problem is with adopting these 
> proposed clarifications.
> 
> 
> --Scott
> 
> 
> 
> 
> > 
> > PatC
> > 
> > Actually, the state machine does not require this, but 
> allows for it. 
> > If an AC wants to only accept connections from specific IP 
> addresses, 
> > At first glance, I don't think I have issues with your 
> proposal, but 
> > do not fully understand the possible impact of the changes.
> > 
> > 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"
> > 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