-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the project status and what LwM2M versions are supported? #684
Comments
(edited your message so that I can reply to it more easier)
|
Concerning point 3) about DTLS, AFAIK, Wakaama core library doesn't depend directly to any DTLS library. At LWM2M level, the specification v1.0 and v1.1 doesn't mention DTLS v1.3. In a more general way, DTLS v1.3 is very young. Since 2022 we begin to see some implementation of it but not widely widespread. At Leshan side, we only support DTLS v1.2. |
Hi!
No, but LwM2M v1.2 is mentioned, while DTLS 1.3 in a maybe context. Seem to say that DTLS 1.2 is fully supported. DTLS 1.2 is also mentioned here, but that is not well defined weather, and it seem that DTLS 1.3 is optional.
It was released April 2022 (last year). The point being that nothing will ever be widespread before it's actually available! There are basically no FOSS server implementations (AFAIK) that supports DTLS 1.3 today. This at times when IoT development is going exponential. |
About DTLS 1.2 vs. DTLS 1.3 One of the main new features of DTLS 1.3, the Connection ID, is backported to DTLS 1.2 via RFC 9146. The left benefits of DTLS 1.3 are then.
(Maybe @hannestschofenig completes the comparison, he's for sure ways more engaged than I.) Overall my feeling is, that it's more important to demonstrate the benefits of UDP based protocols, and that could be done with CoAP/DTLS 1.2 CID. We will see, if "enough" products are build on that, so that a development of DTLS 1.3 will be possible in Eclipse/Californium. I don't expect to have time for that in the next 18 months. |
I will answer for Wakaama and for Leshan too. (as you post same kind of comment at eclipse-leshan/leshan#1386 (comment) ) @eabase, It seems to me that you try to convince us as much it's important to move to DTLS 1.3 and LWM2M 1.2. But currently, Concerning LWM2M 1.2 : AFAIK, Leshan and Wakaama project are focus on LWM2M v1.1. Concerning DTLS 1.3 : Wakaama and Leshan are LWM2M implementation, not DTLS / TLS implementation. So we are also limited by existing FOSS implementation of DTLS 1.3. For Wakaama, AFAIK, you "should" be able to use any DTLS library. (and so you can try with few library who supports DTLS 1.3 : mbedtls, wolfssl ?) For Leshan, AFAIK, there is no pure java implementation of DTLS 1.3 (Eventually, this binding https://github.com/open-coap/kotlin-mbedtls. If someone know others, please share 🙏 ) |
Hi Guys! Again, thanks for quick feedback.
There are several features in DTLS 1.3 that I believe will be regarded as must-haves in the very near future:
(And I'm not just saying this from opinion, but we have several large customers who are requesting these very functionalities today.) The future is now. 😉 The effect of lacking support, is that now a bunch of companies are hacking their own versions of LwM2M 1.1++ or 1.2++ in order to support some DTLS features here and there, further confusing and obscuring any standard compliance. These hacks are not FOSS, so detrimental to the community as a whole. To summarize, the differences, in a more clear way: Hope this helps. PS. Now, since April 2022, DTLS 1.3 is not longer a "draft", however, it's stated as "proposal", which I have asked to clarify here: |
@eabase wrote:
Correction: wolfSSL does support DTLS 1.3 since release 5.4.0 (July 11, 2022). @boaks wrote:
No, unfortunately there is no support for DTLS 1.3 in mbedTLS yet. Edit: corrected link (thanks) |
|
|
If you read the Eclipse Public License V2.0 and some articles about combining that with GPLv2, the main and essential difference is:
With that, please ensure with other users, that there is really a benefit in supporting GPLv2 stuff. There may be an alternative way, where wolfSSL is only one alternative and other alternatives without GPL are also supported, then AFAIK, it doesn't require CQ (process to include external dependencies in order to ensure the "usability according EPL v2.0".) ARMs mbedTLS comes also with DTLS 1.3 (and DTLS 1.2 CID) and uses a Apache 2.0 license, which fits the EPL v2.0 Just to mention: DTLS 1.2 Connection ID is implemented in Eclipse/Californium. Eclipse/tinydtls has currently a feature branch support DTLS 1.2 CID as well. |
(your comment on the 5. March with the table comparing DTLS 1.2 / DTLSS 1.3) I'm not sure, if you mix up things. In my experience, the very larges part of the power-saving stuff is the Connection ID (DTLS 1.3, RFC 9147 or DTLS 1.2, RFC 6347+DTLS 1.2 Connection ID, RFC9146), which eliminates the massive usage of handshakes caused by ip-address changes after sleeping. RFC9146 is implemented in Eclipse/Californium and Eclipse/tinydtls (feature branch). Also in my experience, it's not too unimportant, that an implementation works reliable. For both eclipse DTLS 1.2 Connection ID implementations I have in the meantime very good experience with mid/long term runtime stability. |
Hi @boaks
just to clarify, DTLS 1.3 is not supported in the mbedTLS development branch (https://github.com/Mbed-TLS/mbedtls/blob/development/library/ssl_tls.c#L1305). It is possible that it is being worked on in a fork but mainline mbedTLS does not yet support DTLS 1.3 Juliusz |
Thanks! |
I had written a prototype implementation of DTLS 1.3 for Mbed TLS. Unfortunately, the DTLS functionality had to be removed in order to get protype code incorporated into the mainstream Mbed TLS repo. The code was used for the performance measurements in this paper: https://arxiv.org/abs/2011.12035 I have to search where the code is; it shouldn't be too difficult to add the functionality to Mbed TLS again since the functionality of DTLS 1.3 is (intentionally) kept in sync with TLS 1.3. Needless to say that it would be important to add DTLS 1.3 also to OpenSSL. We have to check their plans. |
FWIW if someone is interested to help writing the DTLS 1.3 functionality, please let me know. |
I forgot to talk about the features of DTLS 1.3. As Achim mentioned, RFC 9147 brings DTLS inline with the TLS 1.3 developments. The list of new features in TLS 1.3 (compared to 1.2) is long. At a high-level the benefits are: improved security, better performance, and extra privacy protection. DTLS 1.3 adds extra over-the-wire improvements to TLS 1.3 with a new header format. Achim mentioned that the Connection ID feature was back-ported from DTLS 1.3 to DTLS 1.2. It significantly improves the energy efficiency of DTLS. The DTLS 1.3 CID version offers extra privacy protection. Going forward I believe DTLS 1.3 is unavoidable since the IETF TLS working group will continue the standardization of new features, which will only be available for (D)TLS 1.3. Of course, it takes time to implement the protocols and the protocol extensions. WolfSSL has been leading the development of commercial TLS/DTLS stacks. Congrats to their work. I hope others follow soon. |
It could very well be, as the table was produced by collecting the info I could find. In regard to CBOR that is still beyond my technical understanding. Perhaps @hannestschofenig can answer that?
This is really a collection of items that all help to reduce handshake and data transfers. Only a real world test with functioning libraries can give specific number of this reduction, but from spec's it seem pretty clear it should be more than significant, for sleeping devices with regular wakeups, that also require the highest reliability/connectivity.
That's a double negation.... :) |
It is the encoding of the coap-payload. It's something as "binary JSON". But as I wrote, I can't see
As I wrote, if you start to sort the things in DTLS 1.3 / DTLS 1.2 related and others (as CBOR), you will see, that pretty much of the benefits from DTLS 1.3 already comes with DTLS 1.2 CID.
Exactly, therefore I created zephyr - coaps-client, which demonstrates CoAP/DTLS 1.2 CID using a LTE-M/NB-IoT modem. A longterm test autumn 2022 showed the efficiency and pretty well reliability. That reliability has been improved since that, but 120 days wasn't that bad. So, those who like to have a look on what is available may check out DTLS 1.2 CID. |
You are right. Sorry for the confusion. The table I showed was originally based on a LwM2M comparison. So CBOR is not related to DTLS in this context. What is related is that LwM2M >= |
LwM2M v1.1
and/orv1.2
?)1.2
,1.3
)The text was updated successfully, but these errors were encountered: