I think for this question as well as the "packets lost" question, it's important to distinguish two phases of a DTLS connection: initially there's a handshake (to negotiate and establish security parameters and session keys), and then application data can be exchanged. Application data is what's passed to `mbedtls_ssl_write()` or written by `mbedtls_ssl_read()` (depending on whether you're the sender or receiver) - this can only happen once the handshake is completed.

During the handshake, there are indeed mechanisms to re-order packets that were received out of order and also retransmit packets that were lost. But that's only during the handshake (because it's a lockstep process where everything needs to happen in order), and only for data that's purely internal to the DTLS protocol and never seen by the application.

Once the handshake is completed and application data starts to be exchanged, there is no longer any kind of re-ordering or retransmission mechanism. The reason is, as you guessed, DTLS aims to provide similar properties to UDP - with cryptographic security in addition. So, if you send something with `mbedtls_ssl_write()` and the record gets lost, the DTLS protocol won't even know about it, and no retransmission will happen. If record N+1 arrives before record N, the DTLS protocol will know but do nothing, and just deliver the records in the order they arrived. Again, as you said, doing otherwise would introduce latency and be contrary to the goals of DTLS - people who want reliability at the expense of latency should use TLS.

The main exception to that principle that you can expect DTLS to behave like UDP is duplicated records: the DTLS protocol provide optional replay protection (that is, if record N arrives twice, the second occurrence is dropped). In Mbed TLS, this mechanism is enabled by default but can be disabled at compile-time by not defining MBEDTLS_SSL_DTLS_ANTI_REPLAY in config.h, or at runtime by calling mbedtls_ssl_conf_dtls_anti_replay().

From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.org> on behalf of saghili via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: 10 December 2020 18:31
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] "Reordering" in DTLS

Hello,

I have a question about DTLS.
One thing that is not entirely clear to me from the RFC is this: suppose
2 records are received within a "short" period, e.g. seq# N+1 followed
by seq# N. In this case, what does DTLS do? My understanding is that it
will pass on packets in the order it was received (i.e. out of order).
But it can (should?) re-order at the DTLS layer and pass them on to the
upper layer in the right order. HOWEVER, this implies that the DTLS
"wait" for a certain window to see if the seq#=N packet arrives or not.
But doing so introduces additional delay at DTLS layer and also
contradicts with the UDP principle (i.e. no concept of order). Could you
please give me a hint regarding this issue?

Best regards,
Farhad
--
mbed-tls mailing list
mbed-tls@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls