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

[Scott G. Kelly (s.kelly]

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