Совместное использование состояния DTLS

Question

У меня есть кластер, который использует DTLS для связи с клиентами
У которого есть какое-то безопасное распределенное хранилище (...)

Как мы знаем, состояние DTLS довольно долгое.Таким образом, в типичных сценариях балансировки нагрузки может случиться так, что зашифрованный пакет будет перенаправлен на сервер, который не может его расшифровать

Я не имею в виду ситуацию, когда src ip изменился из-за изменения привязки NAT (это то, чтомы не можем контролировать)

Так что я думаю ...
Чтобы не налагать какие-либо серьезные ограничения на балансировщик нагрузки (например: всегда пересылать этот src ip на этот сервер инадеюсь на лучшее) и как можно дольше сохранять состояние DTLS как мне использовать DTLS?

Стоит (даже) рассмотреть вопрос о расширении некоторых из существующих библиотек DTLS (как scandium ) с некоторым распределенным кешем параметров сеанса DTLS (чтобы любой узел мог расшифровать пакет)?

Это выполнимо с JDK> = 9 (трудно следоватьssl код есть ...)

Answer 1

Это ссылки с некоторыми крошками информации по этому вопросу:

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

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

Проект Leshan основан на Калифорнии и Scandium, поэтому проблемыс кластеризацией довольно похожи на ваши.Однако информации не так много.

Но, в принципе, это слишком сложно сказать однозначно.Это зависит от вашего варианта использования / конфигурации кластера и подразумевает некоторое нагрузочное тестирование.В противном случае это просто предположение.

, чтобы сохранить состояние DTLS как можно дольше

Кстати, спецификация TLS 1.2 гласит:

Для времени жизни идентификатора сеанса предлагается верхний предел в 24 часа, поскольку злоумышленник, получивший master_secret, может выдать себя за скомпрометированную сторону до тех пор, пока соответствующий идентификатор сеанса не будет удален

Так что лучшевыбрать разумный срок службы.