Establish new associations with existing parameters

[gordonklaus]

Summary

RFC 6347, section 4.2.8 describes how a server can allow a client that has silently abandoned its connection to re-establish its association with the server.

Motivation

The motivation is to support clients that silently abandon their connections with a pion/dtls server and then initiate new connections, e.g. after a reboot. My specific use case is when my device (an nRF9160) is forcibly reset and is then unable to make a new connection.

Describe alternatives you've considered

I've considered never forcibly resetting my device 😄 But these things are sometimes out of one's control, e.g. if a device deployed in the field loses power. And during development, resetting the device is part of the normal development workflow.

[daenney]

I'm not a 100% sure I'm following. Are you saying that after a reboot your client is not able to reconnect to a server?

[gordonklaus]

That's right. It's a hard reset, i.e., the client doesn't get a chance to send a CloseNotify alert.

I've enabled logging in the server and it reports discarded duplicated packet (epoch: 0, seq: 0) when the client tries to reconnect.

The linked RFC section says the server should proceed with a new handshake in this case.

[gordonklaus]

This issue is a blocker for my project. I imagine it is relevant for others, as well.

An unsatisfactory workaround is to close the server after a timeout has expired. The problem with this solution is that the timeout needs to be sufficiently large to avoid rehandshaking on every transmission. But such a large timeout will mean reconnections after silently abandoning a connection will have significant delay. For my application that delay would be several hours.

I will look into solving this issue. If anyone more familiar with the code has any tips, I'd be glad to hear them 😄

By the way, thanks for the great library!

[gordonklaus]

I'd like to get a confirmation of whether or not this feature would be accepted into the package before I put any work into implementing it. Can you give some feedback, @daenney?

This feature feels a bit like renegotiation, but the RFC doesn't describe it that way. Renegotiation is an explicitly excluded feature from this package, hence my uncertainty about acceptance.

I had a look at the code and I think it shouldn't be too painful. I only worry that there might be code that assumes once a handshake is complete that it won't start again.

[daenney]

I don't have any issue with it, though it's worth noting the RFC said "should", not "must", when it comes to supporting this feature. This would indicate to me clients should be able to somehow cope with the server not supporting this, but there's no information in the RFC as to what that would look like.

@at-wat @Sean-Der either of you have an idea?

[gordonklaus]

I did a little research and found that OpenSSL does not support this and Mbed TLS does.

Also from reading the discussions there I realized that a much easier workaround is to use an ephemeral source port in my client. So this may end up being a non-issue for me after all.

[gordonklaus]

Indeed, using an ephemeral source port worked for me. Why didn't I think of that before? 😆

I leave it up to you guys whether this is something you want.

[swechencheng]

I did a little research and found that OpenSSL does not support this and Mbed TLS does.

Also from reading the discussions there I realized that a much easier workaround is to use an ephemeral source port in my client. So this may end up being a non-issue for me after all.

Hi @gordonklaus ,
I have exactly the same issue as yours (though not nRF device).
Could you elaborate more how a client can use an ephemeral source?
I'd also be very much appreciated if dtls can support RFC 6347, section 4.2.8.
Thanks!

[gordonklaus]

Hi @rtechencheng . You can read about ephemeral ports here. To obtain an ephemeral source port, you can either specify the port of the local address to be zero when you bind the socket, or the socket will automatically be bound when you first call sendto or connect. Then you will be assigned a random available port automatically.

[swechencheng]

Hi @gordonklaus . Thanks for your reply!
As for a client-server connection, the server has to be able to accept an ephemeral port connection right?
When using this pion/dtls ListenAndServeDTLS, how should I configure the server to accept a ephemeral port connection?

[gordonklaus]

@rtechencheng The server doesn't have to do anything special. An ephemeral port is just like any other port; it's just that the port number is chosen randomly.

[swechencheng]

@gordonklaus Thanks a lot. But I confirmed in my project that we are not going to use an ephemeral port in our client.
Well, it would be super nice if we have RFC 6347, section 4.2.8 support in pion/dtls, but looking at the source code I feel it would be a bit contradictory to the current replay detection implementation.

[Sean-Der]

I am going to resolve this as 'Will not implement'. If people disagree please re-open. I am happy to re-consider.

• Users can process packets before they reach pion/dtls. If you see a different CID or a handshake attempt you can restart
• This allows us to keep the replay detection
• Less code/corner cases to worry about