Subject: Re: [Capwap] transition to join state

From: "sujay gupta" <[email-masked]>
Date: Wed, 8 Nov 2006 08:52:20 +0530

Hi Scott,
Just been through the reference material,
"The Design and Implementation of Datagram TLS"

It is right that the AC needs to create a session for the
WTP once it recvs the ClientHello with a valid cookie.
This session should continue if the association with that WTP
makes through to Run state.
The same session however may be terminated subsequent to
the ClientHello(w valid cookie) received, if the DTLSAuthenticateFail
or DTLSAuhorizeFail event is recvd.

Now from what I understand from the reference material on DTLS,
(a) if the I/O operations used by the app is blocking, the existing
implementation(i.e OpenSSL
+ DTLS modification)  does return errors for timeout's , retransmission
failures,
which may be in turn reported to CAPWAP as DTLSAuthenticate/Authorize-Fail.
of course apart from genuine Authentication/Authorization failures, which in
turn will
clear the sessions in CAPWAP.
but;
(b) if the I/O operations are non-blocking in nature, the app needs to
maintain a timer
for the catch.

Could we add some clause w.r.t to mode of operation (i.e. a or b ) and the
usage of
a WaitDTLSTimer?

Kindly correct me.

Thanks,
Sujay

On 10/31/06, Scott G. Kelly <[email-masked]> wrote:
>
> 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]>
> >Subject: RE: [Capwap] transition to join state
> >
> >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,
> >
> >       >
> >       >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.
> >
> >       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
> >
> >       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 G Kelly <[email-masked]>
Date: Sat, 11 Nov 2006 09:47:16 -0800

Hi Sujay,

Sorry to take so long to respond. Comments inline below...

sujay gupta wrote:
> of course apart from genuine Authentication/Authorization failures, 
> which in turn will
> Could we add some clause w.r.t to mode of operation (i.e. a or b ) and 
> the usage of
> a WaitDTLSTimer?

I suppose whether you choose blocking vs non-blocking is an 
implementation detail, but whatever you choose, it is important to note 
that the DTLS spec does not provide for handshake timeout in the event 
of lost packets. For that reason, a WaitDTLS timer is required in either 
case.

Now, it is possible that someone could provide this functionality in 
their DTLS implementation even though the DTLS spec doesn't call for it, 
and then, you could use that timer instead of an explicit capwap timer 
(and I think the current rev of openssl is a case in point).

I think it's important to note that much of what we specify regarding 
the DTLS API is conceptual. That is, the functionality must be provided 
*somehow*, but it is not critical to interpret the specification 
literally in all cases in order to accomplish this. I think we have one 
such case at hand.

Scott