2

I have an cluster that uses DTLS to communicate with clients
Which have some kind of safe distributed storage (...)

As we know DTLS state is rather long-lived. Thus in typical load balancing scenarios it would happen that encrypted packet will be forwarded to the server that cannot decrypt it

I'm not referring to situation that src ip has changed due to NAT binding change (this is something that we cannot control)

So I'm thinking...
In order not to incur some heavy constraints on load balancer (like: always forward this src ip to that server and hope for the best) and to preserve the DTLS state as long as possible how should I use the DTLS?

Is it (even) worth considering to extend some of the existing DTLS libraries (like scandium) with some distributed cache of DTLS session parameters (so that any node is able to decrypt the packet)?

Is it doable with JDK>=9 (it is hard to follow ssl code there...)

lakier
  • 495
  • 4
  • 13

1 Answers1

3

These are the links with some crumbs of info on this:

https://github.com/eclipse/leshan/wiki/Cluster

https://github.com/eclipse/leshan/wiki/Using-Leshan-server-in-a-cluster

Leshan project is based on Californium and Scandium so the issues with clustering are quite similar to yours. However there is not much info.

But basically it is too hard to say definitely. It depends on your use case/cluster config and implies some load testing. Otherwise, it is just guessing.

to preserve the DTLS state as long as possible


BTW the TLS 1.2 spec says:

An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired

So it's better to choose some reasonable lifetime.

eugene-nikolaev
  • 1,230
  • 1
  • 12
  • 21