Handling of stale handshakes

[boaks]

During the discussion of #335 I was pointed to the current handling of stale handshakes

#335 (comment)

FMPOV I agree, that there is no reason to remove a DTLS session from the LRU cache (ConnectionStore), until the storage is required for something else.

But for "incomplete handshakes" I have my doubts, if this would not introduce a vulnerability, because some could fill the ConnectionStore with entries without having credentials, and force so other "authorized" clients to handshake again. I would therefore propose to remove the incomplete handshakes actively earlier.

So any opinions on that?

[sbernard31]

some could fill the ConnectionStore with entries without having credentials, and force so other "authorized" clients to handshake again.

We have the staleConnectionThreshold to "limit" this issue. (default value 30 minutes)

I would therefore propose to remove the incomplete handshakes actively earlier.

What did you have in mind exactly ? When/how do we know we can remove an incomplete handshake ?

[boaks]

We have the staleConnectionThreshold to "limit" this issue. (default value 30 minutes)

I principally understood, that using the same staleConnectionThreshold and cleanup only when the cache is full, is a pretty simple implementation

My concern is, that if someone attacks using a lot of incomplete handshakes, the other connections based on successful handshakes, may be "garbage collected". With a shorter threshold for connections related to "ongoing handshakes" and switching to the longer threshold when the handshake gets successful would change the order of removing them and so lower the number of removed "connections based on successful handshakes".

What did you have in mind exactly ? When/how do we know we can remove an incomplete handshake ?

Define a second, shorter threshold and use that, when a new connection with an ongoing handshake was started.
Switch to the staleConnectionThreshold when the handshake get successfully completed.

I would also like to introduce a "active remove of connections with stale handshakes" but this would be more related to "feedback" for a triggering request and so not part of this issue. (So i remove the "actively" from my first post :-) )

[sbernard31]

My concern is, that if someone attacks using a lot of incomplete handshakes, the other connections based on successful handshakes, may be "garbage collected".

Only after staleConnectionThreshold seconds. While this timeframe, the connection is "immune". For use case where you are behind a NAT this timeframe should already be very low. (At sierra we set it at 10minutes but I think we can reduce it more than that.)

introduce an "active remove of connections with stale handshakes" but this would be more related to "feedback" for a triggering request and so not part of this issue.

FMPOV, this is the most valuable part.

[boaks]

Timeout for all handshakes implemented by PR #782