[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Sharing DTLS session state among multiple nodes
|
On Do, 2016-09-22 at 07:45 +0000, Kraus Achim (INST/ESY1) wrote:
> Hi all,
>
> just to get me up to date: DTLS is still the focus, not TLS?
>
> >
> > 2)
> If we focus on DTLS, RFC 6347, 4.1.2.1 MAC, and 4.1.2.7 Invalid Record
> recommend to silently ignore (most) errors (at least as far as I read and
> understand it).
> Please also consider, that, caused by "spoofing" not any "error" should
> close the session,
> otherwise the devise may starve (DoS)
> So there will be only very rare cases, when a "fatal alert" will be send
> and the other side
> will trust that.
>
You are absolutely right and I think we already consider this in Scandium.
IMHO we would be safe if we purged the session from the SessionCache in those
cases where we are sending a fatal alert back to a client already.
> Mit freundlichen Grüßen / Best regards
>
> Achim Kraus
>
> Bosch Software Innovations GmbH
> Communications (INST/ESY1)
> Stuttgarter Straße 130
> 71332 Waiblingen
> GERMANY
> www.bosch-si.de
> www.blog.bosch-si.com
>
> Tel. +49 711 811-58139
> achim.kraus@xxxxxxxxxxxx
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B
> Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
>
>
> -----Ursprüngliche Nachricht-----
> Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Simon Bernard
> Gesendet: Mittwoch, 21. September 2016 18:04
> An: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
> Betreff: Re: [cf-dev] Sharing DTLS session state among multiple nodes
>
> This seems to me a better approach than the previous one :) (trying to
> persist ConnectionStore).
>
> Some remarks/questions below :
> 1) Why LeastRecentlyUsedCache.class is no more threadsafe ?
>
> 2) The TLS spec[1] say :
> "Error handling in the TLS Handshake protocol is very simple. When an
> error is detected, the detecting party sends a message to the other
> party. Upon transmission or receipt of a fatal alert message, both parties
> immediately close the connection. Servers and clients MUST forget any
> session-identifiers, keys, and secrets associated with a failed connection.
> Thus, any connection terminated with a fatal alert MUST NOT be resumed."
> Should we implement this ?
>
> 3) If we implement 2) the "InMemoryConnectionStore.find()" should always
> look in the shared store (SessionCache) and should not check before in the
> connections map in memory.
>
> 4) Not directly linked to this branch but the RF5077[2] is another way to
> resume session:
> "This mechanism is useful in the following situations:
> 1. servers that handle a large number of transactions from different
> users
> 2. servers that desire to cache sessions for a long time
> 3. ability to load balance requests across servers
> 4. embedded servers with little memory"
> Here[3][4] are interesting posts about session resumption and Forward
> Secrecy [3][4].
>
> Simon
>
> [1]https://tools.ietf.org/html/rfc5246#section-7.2.2
> [2]https://tools.ietf.org/html/rfc5077
> [3]https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-sess
> ion-resumption-implementations/
> [4]https://blog.twitter.com/2013/forward-secrecy-at-twitter-0
>
> Le 21/09/2016 à 12:04, Hudalla Kai (INST/ESY1) a écrit :
> >
> > Hi,
> >
> > some months ago I had started to work on introducing means to Scandium
> > to be able to share state of an established DTLS session (crypto
> > params) among multiple nodes.
> >
> > The idea is to allow for clients being able to resume a DTLS session
> > (using an abbreviated handshake) with another node than the one the
> > session has been originally been established with (e.g. after the
> > original node has crashed).
> >
> > I have added the code to the session_cache branch based on current
> > master [1]. There also has been a question raised around that topic [2].
> >
> > I would be interested in getting some feedback whether you think this
> > is a useful addition and you could put this to work in your environment.
> >
> > [1] https://github.com/eclipse/californium/tree/session_cache
> > [2] https://github.com/eclipse/californium/issues/89
> >
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev
