Subject: [Capwap] transition to join state

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Tue, 24 Oct 2006 21:21:41 +0530

All,
 
The spec talks about AC transitioning to Join state on receiving DTLS
Client Hello with a valid cookie. Should this really be the case? 
The AC should transition to Join state on receiving a Join Request.
 
Thanks
Smitha
 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 24 Oct 2006 08:55:39 -0700

I'm not so sure. If that were the case we would need a "join ready" state. We clearly need to transition to a new (non-DTLS) state when the DTLS channel is open.

PatC

 -----Original Message-----
From: 	Smitha Smitha (ssmitha)
Sent:	Tuesday, October 24, 2006 08:52 AM Pacific Standard Time
To:	capwap
Subject:	[Capwap] transition to join state

All,

Thanks
Smitha

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Wed, 25 Oct 2006 07:07:24 +0530

Pat,

The spec talks about transitioning to join state from idle - (Idle to
Join (aa)). This would make it necessary for CAPWAP to know of the
various DTLS packets are being received during handshake. Why is it
necessary to have a "join ready" state?

Thanks
Smitha

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Tuesday, October 24, 2006 9:26 PM
To: Smitha Smitha (ssmitha); 'capwap'
Subject: RE: [Capwap] transition to join state

I'm not so sure. If that were the case we would need a "join ready"
state. We clearly need to transition to a new (non-DTLS) state when the
DTLS channel is open.

PatC

 -----Original Message-----
From: 	Smitha Smitha (ssmitha)
Sent:	Tuesday, October 24, 2006 08:52 AM Pacific Standard Time
To:	capwap
Subject:	[Capwap] transition to join state

All,

Thanks
Smitha

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 03:44:03 -0700

I see your point. Clearly, some interim CAPWAP state is needed between
idle and join, which we could call "DTLS Establishment".

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> Sent: Tuesday, October 24, 2006 6:37 PM
> To: Pat Calhoun (pacalhou); 'capwap'
> The spec talks about transitioning to join state from idle - 
> (Idle to Join (aa)). This would make it necessary for CAPWAP 
> to know of the various DTLS packets are being received during 
> handshake. Why is it necessary to have a "join ready" state?
> 
> Thanks
> Smitha
> 
> I'm not so sure. If that were the case we would need a "join 
> ready" state. We clearly need to transition to a new 
> (non-DTLS) state when the DTLS channel is open.
> 
> PatC
> 
> The spec talks about AC transitioning to Join state on 
> receiving DTLS Client Hello with a valid cookie. Should this 
> really be the case?

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Thu, 26 Oct 2006 16:52:47 +0530

Pat,

I think we should have this additional state and have the following
transitions on the AC and WTP.

Discovery to "DTLS Establishment":

WTP: Occurs when WTP sends DTLSStart command after figuring out which AC
to join.
AC: Nop

"DTLS Establishment" to Join:
WTP: Occurs when DTLSSessionEstablished command is received from DTLS. 
WTP sends a Join Request and starts the WaitJoin timer.
AC:Occurs when DTLSSessionEstablished command is received from DTLS. 
AC allocates state for this WTP and starts the WaitJoin timer.

Thanks
Smitha 
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Thursday, October 26, 2006 4:14 PM
To: Smitha Smitha (ssmitha); 'capwap'
Subject: RE: [Capwap] transition to join state

Pat Calhoun

> state. We clearly need to transition to a new

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 26 Oct 2006 09:54:23 -0700 (GMT-07:00)

One other issue with this:

> From: Smitha Smitha (ssmitha) [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 4:34 AM
> To: Pat Calhoun (pacalhou); capwap
> Subject: Re: [Capwap] transition to join state
> 
> One correction to the transitions. 
> 
> Idle to "DTLS Establishment"
> WTP: Nop

The AC needs to transition when it receives a DTLS ClientHello (with cookie) and set a timer (WaitDTLS).

--Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 10:05:03 -0700

Issue 226 created.

Pat Calhoun

> From: Scott G Kelly [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 5:04 AM
> To: Smitha Smitha (ssmitha)
> Cc: Pat Calhoun (pacalhou); capwap
> If you add this state, you must also add a WaitDTLS timer.
> 
> Smitha Smitha (ssmitha) wrote:
> > WTP: Occurs when WTP sends DTLSStart command after figuring 
> out which 
> > AC to join.
> > AC: Nop
> > 
> > Sent: Thursday, October 26, 2006 4:53 PM
> > WTP: Occurs when WTP sends DTLSStart command after figuring 
> out which 
> > AC to join.
> > AC: Nop
> > 
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> >  
> > 
> receiving DTLS

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Thu, 26 Oct 2006 22:32:21 +0530

Scott,

The idea was to isolate details of DTLS handshake from CAPWAP. If we
need to keep track of DTLS Client Hello (with a valid cookie), then the
earlier transitions were OK. 

Why do we need a CAPWAP transition based on DTLS packets (unless a
session is established) and a WaitDTLS timer that CAPWAP needs to
maintain? That would be part of DTLS.

Thanks
Smitha

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 10:24 PM
To: Smitha Smitha (ssmitha); capwap
Subject: RE: [Capwap] transition to join state

 One other issue with this:

> WTP: Occurs when WTP sends DTLSStart command after figuring out which 
> AC to join.
> AC: Nop
> 

The AC needs to transition when it receives a DTLS ClientHello (with
cookie) and set a timer (WaitDTLS).

--Scott

---

From: "Smitha Smitha (ssmitha)" <[email-masked]>
Date: Tue, 31 Oct 2006 22:32:02 +0530

Scott,
 
I agree with Sujay. Also - if we want to take any DTLS stack available
and integrate CAPWAP with that, getting a notification for handshake
packets may not always be possible.
 
Thanks
Smitha

________________________________

From: sujay gupta [mailto:[email-masked]] 
Sent: Tuesday, October 31, 2006 5:04 PM
To: Scott G. Kelly
Cc: Smitha Smitha (ssmitha); capwap
Subject: Re: [Capwap] transition to join state

Hi Scott,
Good point, but shouldn't this timer(WaitDTLS) be a part of the 
DTLS implementation, probably an add-on, if not present.

For if we are to separate the CAPWAP transitions from the DTLS
handshake messages, a WaitDTLS timer doesn't make sense there. 
Regds,
Sujay

On 10/26/06, Scott G. Kelly <[email-masked]> wrote: 

	Hi Smitha,
	
	>maintain? That would be part of DTLS.
	
	You need this because DTLS provides no timeout of its own. It
provides an exponential back-off timer, but this never terminates (I
know, sounds like a major foobar in the protocol design, but they
probably had their reasons...) 
	
	If we don't add the timer, resource-exhaustion DoS (from a bunch
of half-open sessions) is trivial to mount.
	
	Scott

_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit: 
	http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 31 Oct 2006 10:04:24 -0800 (GMT-08:00)

Hi Smitha,

I've sent inquiries to the DTLS RFC authors to get the full explanation for why the maximum number of retries (which is another way to indicate the handshake timeout) is not configurable (i.e. why the application is responsible for timing out DTLS handshakes), but given that the RFC passed muster in both the TLS wg and the security directorate, my expectation is that there is a good reason for this.

As for your comments below, I think you're missing a subtle point: if you want to use openssl's DTLS (and probably other OTS DTLS implementations will be similarly implemented), you can't process DTLS session initiation from a client until you create the session _for that client_. This isn't TCP, and there is no support of listen/accept with UDP; we are responsible for demultiplexing DTLS packets (i.e finding the session they belong to) prior to handing them to the DTLS implementation. This means the AC has to explicitly create state (i.e. a DTLS session/socket) in order to be able to process DTLS packets from a given WTP.

Here's how this currently works with openssl: 

- a WTP optionally goes through discovery (no state at AC)

- the WTP sends a ClientHello 

- the AC replies with the HelloVerifyRequest (no state at AC)

- the WTP sends ClientHello with cookie

- the AC validates the cookie; if it's a good cookie (e.g. chocolate chip! :-)), the AC creates session state and hands the ClientHello to the DTLS session; this may be via a DTLS socket, some other session model (e.g. a mem BIO), or it may involve hardware plumbing; the AC also sets a handshake timeout here to avoid DoS.

I'm not clear on why you two object to setting this timer. It seems like a DTLS implementation *could* provide a parameter for this, but the fact is that the current standard does not provide for this, so if we object, then we must modify the standard (i.e. produce a new DTLS RFC which rectifies this). Sounds hard to me, so absent a show-stopping objection, I vote for setting the timer in capwap. Am I missing something here?

--Scott

-----Original Message-----
>From: "Smitha Smitha (ssmitha)" <[email-masked]>
>Sent: Oct 31, 2006 9:02 AM
>To: sujay gupta <[email-masked]>, "Scott G. Kelly" <[email-masked]>
>Cc: capwap <[email-masked]>