Hi Farhad,
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().
I hope this answers your questions.
Regards, Manuel. ________________________________ 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
Hi,
Thank you for your prompt response. This means that we will be able to use DTLS (the mbed implementation) for communication in our project.
I have another question. There is a simple client/server example for TLS 1.2 in https://tls.mbed.org/kb/how-to/mbedtls-tutorial,. [1]
Can you help us change it to DTLS? What APIs should we add to this example?
Best regards,
Farhad
On 2020-12-11 09:34, Manuel Pegourie-Gonnard wrote:
Hi Farhad,
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().
I hope this answers your questions.
Regards, Manuel.
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
Links: ------ [1] https://tls.mbed.org/kb/how-to/mbedtls-tutorial,
Hi,
I there are simple client/server examples for DTLS in programs/ssl in our source tree, named dtls_client.c and dtls_server.c, which you can use as a starting point for developing your own:
https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/dtls_client... https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/dtls_server...
Best regards, Manuel
________________________________ From: saghili SeyedFarhad.Aghili@esat.kuleuven.be Sent: 11 December 2020 13:24 To: Manuel Pegourie-Gonnard Manuel.Pegourie-Gonnard@arm.com; mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: Re: [mbed-tls] "Reordering" in DTLS
Hi,
Thank you for your prompt response. This means that we will be able to use DTLS (the mbed implementation) for communication in our project.
I have another question. There is a simple client/server example for TLS 1.2 in https://tls.mbed.org/kb/how-to/mbedtls-tutorial,.https://tls.mbed.org/kb/how-to/mbedtls-tutorial,
Can you help us change it to DTLS? What APIs should we add to this example?
Best regards,
Farhad
On 2020-12-11 09:34, Manuel Pegourie-Gonnard wrote:
Hi Farhad,
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().
I hope this answers your questions.
Regards, Manuel.
________________________________ 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
mbed-tls@lists.trustedfirmware.org
-
Manuel Pegourie-Gonnard -
saghili