[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Sharing DTLS session state among multiple nodes
|
Thanks for the excellent feedback, Simon :-)
On Mi, 2016-09-21 at 18:04 +0200, Simon Bernard wrote:
> 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 ?
I thought that it would make sense to leave that to the context in which the
cache is used in case you find other ways of making sure that a cache is
always only accessed by a single thread.
>
> 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 ?
You mean that we need to make sure that a session is removed from the cache
in such cases, right? I guess we should do that.
>
> 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.
To make sure that we do not use a "stale" session that has been removed from
the cache by another node, right?
>
> 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].
>
Thanks for the links. I already had taken a look at RFC5077 but my concern is
that we will probably not find many client implementations supporting it,
right?
> 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
