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

[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. 

[Øyvind]

 samuel4 thanks for your patience. Our team provided the following answer:

NRF_SO_SEC_DTLS_HANDSHAKE_TIMEO is a configurable timeout for the whole handshake. 

For example if DTLS total timeout is 15 s then timeouts are 1 s, 2 s, 4 s, and 8 s.

 

We are also aware that 1s timeout for re-transmission in DTLS handshake is not optimal and leads to re-transmissions. There just never hasn't been time to optimize it. Also the RFC doesn't take into account low bandwidth technologies such as NB-IoT. 

Kind regards,
Øyvind

[Achim Kraus]

> We are also aware that 1s timeout for re-transmission in DTLS handshake is not optimal and leads to re-transmissions.

Yes.

> There just never hasn't been time to optimize it.

The configuration parameters are already available in mbedTLS, so the work to do is mainly to add them to the socket option API.

> Also the RFC doesn't take into account low bandwidth technologies such as NB-IoT.

The RFC is from 2012, AFAIK, NB-IoT was in 2012 just not available.

Even more, the IETF tls working group focus mainly on "web-usage" and that causes then recommendations as this 1s. The RFC refers to considering congestion and concludes, that for the web-usage, 1s will be better suited than 3s.

Under normal signal conditions, and maybe using PSK and not x509, that may also apply for modem communication. Means, it causes some retransmission, but doesn't harm more. But with low signals (that's the domain of NB-IoT), that may change and cause the handshake even to fail, especially with the more data of x509.

So all in all, maybe someone from your modem/dtls team has a look at that and is able to estimate, how much that additional socket option will cost. And then we will see, if that gets implemented once upon a day.

[samuel4]

I also think that the effort isn't too high. You already have a hard coded 1s minimum timeout that must be changed. A further reason to change this is that you can align to zephyr's socket API. Right now, there is the nrf socket option
- NRF_SO_SEC_DTLS_HANDSHAKE_TIMEO 

and zephyr's socket options

- TLS_DTLS_HANDSHAKE_TIMEOUT_MIN
- TLS_DTLS_HANDSHAKE_TIMEOUT_MAX

which is pretty annoying, when the same code base is used with different hardware architectures.

[Achim Kraus]

With the satellite ambitions this topic will get important as well. Unless Nordic's plan is not to support DTLS for NTN.