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

[Achim Kraus]

To be frank:

Extending the initial timeouts for the "network registration" or "TAU" times, isn't a that good idea either ;-).

For cellular, a initial timeout of 3s does a better job, but it needs to start after registration and RRC active.

Otherwise you will need a timeout, which includes/covers those network times as well, e.g. 15s. But that comes then with other downs, You will find that out.

[samuel4]

Surely, I want to increase the initial timeout in the handshake, only. I don't want to change anything in network registration process or similar. The handshake timeouts also belong to a different domain: In mbedTLS there is a statemachine that retransmits the current handshake packet (client hello, client key exchange...) after the minimum timeout. This timeout is doubled on each retry until the timeout reaches its maximum. A similar statemachine is likely to run in the modem firmware. And I really hope that this timeouts aren't hard coded, but configuable.

[Achim Kraus]

samuel4 said:

I don't want to change anything in network registration process or similar.

The point will be, that the time for that handshake retransmission timeout needs to start once the modem is registered and RRC active. That doesn't change the "process" it just starts the timer, when the transport will be really available.

mbedtls itself uses

"void mbedtls_ssl_conf_handshake_timeout(mbedtls_ssl_config *conf, uint32_t min, uint32_t max);"

with the initial timeout in "min".

I don't know, If that is mapped to the modem's mbedtls socket opts. I don't use the DTLS implementation of the modem.