Capwap Mailing List: Re: Issue 30: Inconsistent state tracking on AC priortoDTLSEstablishment (was: state machine issues)

[Pat Calhoun (pacalhou) (pcalhoun]

All,

we have agreement to close this issue and raise any issues during the WG
last call, so I will update the issue tracker accordingly.

PatC 

-----Original Message-----
From: Scott G. Kelly [mailto:s.kelly [at] ix.netcom.com] 
Sent: Friday, February 15, 2008 8:17 AM
To: Dorothy.Gellert [at] nokia.com; Pat Calhoun (pacalhou);
capwap [at] frascone.com
Cc: hartmans-ietf [at] mit.edu; clancy [at] ltsnet.net; rbonica [at] juniper.net
Subject: Re: [Capwap] Issue 30: Inconsistent state tracking on AC
priortoDTLSEstablishment (was: state machine issues)

Hi Dorothy,

I don't have any issues with publishing 09 first. Then, we'll all be
looking at the same pictures and text.

Scott


-----Original Message-----
>From: Dorothy.Gellert [at] nokia.com
>Sent: Feb 14, 2008 6:08 PM
>To: skelly [at] arubanetworks.com, pcalhoun [at] cisco.com, capwap [at] 
>frascone.com
>Cc: hartmans-ietf [at] mit.edu, clancy [at] ltsnet.net, rbonica [at] 
>juniper.net
>Subject: Re: [Capwap] Issue 30: Inconsistent state tracking on AC prior
toDTLSEstablishment (was: state machine issues)
>
>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
>
>
>> -----Original Message-----
>> From: ext Scott Kelly [mailto:skelly [at] arubanetworks.com]
>> 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)
>> 
>> > 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?
>> 
>> 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
>> 
>> 
>> 
>> 
>> > 
>> > 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
>> 
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap