DTLS minimum handshake timeout

[samuel4]

Hi

It seems that the default minium DTLS handshake timeout is about 1 second. That means, there is a retransmission if a response isn't received within this timeout. In NB-IoT/LTE-M this leads to many unnecessary retransmission:

The server is configured to a higher timeout, but how can I configure the nRF9151 to be more patient during handshake? Since NB-IoT has latencies up to 10 seconds, retransmitting every second does barely make sense.

I have tried a lot of socket options so far, but none seem to work. Zephyr itself offers TLS_DTLS_HANDSHAKE_TIMEOUT_MIN, but this one is not supported on offloaded sockets. Am I missing something? It would be a pitty if I have to switch to mbedTLS, because of a missing handshake timeout.

NCS version: v3.0.2

Best regards
Samuel

[Øyvind]

Hi Samuel, 

Could you please provide more information on the DTLS solution that you are using? You are not using mbedTLS? What modem FW are you running on your device?

Looking through our documentation, there should be a socket option called SO_KEEPOPEN that will keep DTLS CID enabled sessions during network outages, i.e. from nrfxlib/nrf_modem/include/nrf_socket.h: Keep socket open when its PDN connection is lost.

Does this provide any solution to your issue?

Kind regards,
Øyvind

[samuel4]

Hi

I am using mfw_nrf91x1_2.0.2 modem firmware version and a modifed coap sample with CONFIG_NET_SOCKETS_OFFLOAD=y.

In my understanding, mbedTLS is linked and used with the application, but works in conjuntion with the modem. I don't use the mbedTLS implementation provided by zephyr, which is fully configurable, but does not use any hardware acceleration.

To clarify the problem: There is no problem with CID or established connections at all. But when I open the socket and connect to the server, the device is not patient and retransmit messages every second:

The handshake starts with:

Client Hello

Hello Verify Request

Client Hello

So far so good. After 1.5 seconds the server reponds with Server Hello. Meanwhile the Client suggested that the packet was lost and has retransmitted the Client Hello message. That's why there you see two Sever Hello. And that's also why there are three Certificate, Client Key Exchange... and three Change Cipher Spec... messages. The reason is, that the client retransmits messages after 1 second of timeout in the DTLS handshake.

In mbedTLS this can be configured using the mbedtls_ssl_conf_handshake_timeout function. In Zephyr you can use setsockopt(sock, SOL_TLS, TLS_DTLS_HANDSHAKE_TIMEOUT_MIN, min_hs_timeout_ms). But I don't find any option for offloaded sockets. I could use zephyr's mbedTLS with CONFIG_MBEDTLS_BUILTIN and do DLTS in software, but it probably will be much slower.

We will use CID in the end and there will be only few handshakes, but: Retransmitting delayed (but successful transmitted) packets lead to even more packets and roundtrips in the handshake. On one hand this consumes more energy, on the other hand it increases the risk of handshake failure in bad cellular coverage. Therefore there should be an option for the minimum retransmission timeout like mbedTLS and Californium offer. 

Best regards
Samuel

[samuel4]

Agreed, I will look into this, too. Right now, I focus on the first handshake after the modem is registered to network.

To ensure, we're all talking about the same: Here is the DTLS RFC about the retransmission scheme:

https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.4.1

They suggest a initial handshake timeout of 1 second "in order to improve latency for time-sensitive applications". However that's barely the case in NB-IoT. I don't think it's a good choice at the nRF91. Because of this short timeout I see avoidable retransmission on almost every handshake.

 Øyvind Could you check if I missed such a socket open etc. or if you plan to implement it? The best solution in my point of view would be implementing the existing zephyr socket options:

BSD Sockets — Zephyr Project Documentation

Best regards
Samuel

[Øyvind]

Hi Samuel, I have forwarded this discussion internally and will update as soon as I have more feedback.

Kind regards,
Øyvind

[Øyvind]

Hello again, 

our team informs me that due to high work load and vacation time they are not able to provide an answer to you until work week 32. 

Will get back to you when we have an answer.

Kind regards,
Øyvind

[Achim Kraus]

samuel4 said:

To ensure, we're all talking about the same: Here is the DTLS RFC about the retransmission scheme:

Yes, that's the timer values I'm talking about. But, I'm not a developer of mbedtls nor a Nordic employee, but I'm the project lead of eclipse/californium and I implemented the retransmission mechanism and configuration for Californium/Scandium. Mainly as outcome of some first NB-IoT experience a couple of years ago. I'm also a committer of Eclipse/tinydtls and so I use that for my own zephyr client in order to adjust the timers in a way adapted for NB-IoT.

About mbedtls there may be others more common and experienced, I just checked the mbedtls examples and that points to "void mbedtls_ssl_conf_handshake_timeout(mbedtls_ssl_config *conf, uint32_t min, uint32_t max);".

[Achim Kraus]

"work week 32"

samuel4 

Just in the case you're interested in testing, if other timings changes the behavior relevant, you may do some tests with my client in the meantime.