Repository navigation
Establish new associations with existing parameters #253
Description
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.
Activity
daenney commentedon May 6, 2020
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 commentedon May 6, 2020
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 commentedon May 7, 2020
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 commentedon May 10, 2020
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 commentedon May 11, 2020
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 commentedon May 11, 2020
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 commentedon May 11, 2020
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 commentedon Aug 24, 2021
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
dtlscan support RFC 6347, section 4.2.8.Thanks!
gordonklaus commentedon Aug 24, 2021
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
bindthe socket, or the socket will automatically be bound when you first callsendtoorconnect. Then you will be assigned a random available port automatically.swechencheng commentedon Aug 24, 2021
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/dtlsListenAndServeDTLS, how should I configure the server to accept a ephemeral port connection?gordonklaus commentedon Aug 24, 2021
@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 commentedon Aug 25, 2021
@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.8support inpion/dtls, but looking at the source code I feel it would be a bit contradictory to the currentreplay detectionimplementation.Sean-Der commentedon May 21, 2024
I am going to resolve this as 'Will not implement'. If people disagree please re-open. I am happy to re-consider.
pion/dtls. If you see a different CID or a handshake attempt you can restart