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

[Dorothy.Gellert (Dorothy.Gellert]

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
>