Hybrid DTLS client: server goes down

[igolaizola]

Summary

Hybrid DTLS client connection that acts also as a server. It can accept a client hello, perform a full handshake and override the previous DTLS state with the new negotiated one.

Motivation

DTLS doesn't have a way to detect that a connection went down on the other side. If a client goes down it can always start a new handshake against the server. However, if the server goes down it can do nothing to restart the connection.

The client must then implement an application level feature (such as a request/response timeout) to restart a new connection. This adds latency and/or complexity to the arquitecture.

This "hybrid client" approach allows the server part to restart the DTLS connection.

Describe alternatives you've considered

• Application level timeouts
• Application level ping/pong
• Monitoring the underlying connection

Additional context

Some related issues: #151 #132

PoC implementation of the feature inclusing test cases: https://gist.github.com/igolaizola/98a39856c2413565f59371fe68fa8863

Questions

What do yo think of adding a feature like this to the library? Perhaps on a subpackage.

What security implications could have?

@Sean-Der @daenney @at-wat

[Sean-Der]

Sorry I didn't respond to this sooner @igolaizola

I think this is a great idea. Lots of people have struggled with this/asked questions. It should also be easier to do now with DTLS v1.3

I am hesitant to add any more code into pion/dtls though. It's nice that this library is just implementing a IETF standard, no subjectivity to it. I would love to recommend a library owned by you though that does this!