Skip to content

External Challenge for Leshan project

Simon edited this page Sep 27, 2024 · 10 revisions

The purpose of this page is to list all known challenges outside the Leshan project itself, but which have an impact (could have an impact in the future ) on it. If you want to discuss about one of this point, please create a dedicated issue. For general comment about the page you can use #1591.

If your are concerned by some point and have a different point of view, let me know, then we will fix this page OR add your point of view.

Rely on not so active CoAP library

Leshan 1.x is totally dependent of Californium 2.x which is a coap implementation in Java.
Since Leshan 2.x, we refactor Leshan by adding a new Transport Layer Abstraction but our first class coap(s) endpoints are still based on Californium 3.x.

Is it really an issue ?

For now, not really as the library is still maintained, is largely used and works well.
But at mid/long term it could become an issue because AFAWK Californium :

In other words, good to use now, hard to make evolve and uncertain future.

How to mitigate that ?

Transport Layer Abstraction is a first step.

Currently, there is not so much alternative. After some investigations only open-coap/java-coap seems to be an possible alternative. So we also try to provide a coap endpoint based on it.

java-coap pro :

  • Currently maintained by a small team, during their job time at Nordic Semiconductor which is using that library in their nRFCloud platform.
  • More simple code and more limited scope (only focus on implementing a coap java library)
  • Support coap+tcp,
  • Friendly maintainer, seems to be open about changes.

java-coap con :

  • probably less used than californium
  • not hosted by an open-source foundation.

In an Ideal world :

We need a good, well-maintained, very active, open-source, CoAP only library for Java, managed by a friendly team (ideally with some RFC authors in it).

Rely on not so active DTLS library.

For DTLS support of coap(s) protocol we rely on Scandium which part of Californium project. Theoretically it should be possible to use it with something else than Californium but it was mainly created to add coaps support to Californium.

Is it really an issue ?

So we can make same answer than above 👆 (coap section).

In addition :

  • DTLS 1.3 is clearly not planned.
  • for a security protocol implementation the "only 1 maintainer" issue is maybe even more an issue.

How to mitigate that ?

Here also the Transport Layer Abstraction is a first step.

But I don't know if there is viable alternative for DTLS...
Some tracks :

Note that java-coap are using the mbedtls binding. Main maintainers says : "mbedtls is an actively developed, with many security experts (I happend to work with them in my previous work)."

That repository is an attempt to collect information and find a solution about that.

In an Ideal world :

Full feature (D)TLS support in OpenJDK OR a good, well-maintained, very active, open-source, DTLS only library for Java, managed by a friendly team (ideally with some security expert and RFC authors).

Then this could be reused either with Californium or java-coap or for others coap library or even other use case.

It should also be created with cluster use case in mind.

No Java CoAP library with production ready support of OSCORE

Currently Leshan uses Californium OR java-coap to support CoAP protocol.

java-coap has no support of OSCORE at all. (but project is open to contribution)

Californium has ongoing development but this move very very slowly.
The code is done by 1 external contributor which have very few time to invest on it. Once Minimal Viable Feature will be ready, I'm not sure this contributor will continue to maintain the code in the long term. This could be an issue especially for Security Feature.

Is it really an issue ?

If OSCORE become a MUST-HAVE feature for Leshan it will be an issue.

How to mitigate that ?

🤷‍♀️

In an Ideal world :

coap library supports OSCORE.

I ask myself if it could be possible to have small library with very limited scope which will be OSCORE only. Then this library could be reuse by other coap library to add support of it. (Probably doesn't make sense 🤔)

Specification Issues

We regularly face miss-interpretation / ambiguity / inconsistency or design issue in specification/RFC we try to implement.

As we mainly implement LWM2M specification most of our "specification" issues comes from LWM2M and it's really difficult to get clarification OR answer from OMA (LWM2M authors). Some reason of that :

An other issue with LWM2M is that they doesn't provide fix for old version of the specification. Only for the latest.

Is it really an issue ?

This slows down development and could lead to some interoperability issue. Some "design" issue can strongly impact real production use case.

How to mitigate that ?

We create a page where we explain how to deal with specification issue.

If we could have a Leshan's Friend or a teammate participating to LWM2M meeting as OMA Member, we could get answer quickly ? 🤷‍♀️

In an Ideal world :

LWM2M specification would be written in an open manner and authors would take time to discuss with the Community.

Community could propose contribution (like PR) to modify/fix the specification.

Contributors could grant author right not based on how much he paid but on much he contributes to the specification.

Leshan would implement the version of the specification which is in progress and could give feedback before release of stable LWM2M version.

Like said Eric Allman :

Perhaps the best situation of all is where the standards and implementations are being developed in parallel. ... ... Ambiguities in the standard were exposed quickly, as were well-meaning features that were unnecessarily difficult to implement.

(Source : The robustness principle reconsidered - Eric Allman)