Support of CoAP Echo option in Leshan

[sbernard31]

Specifications :

I recently see that the LWM2M specification (since v1.1.x) says :

At LWM2M-v1.1.1@transport§6.1. Features :

The CoAP Echo Option SHOULD be used to enable lightweight freshness verifications.

At LWM2M-v1.1.1@transport§5.7. Freshness :

A LwM2M Client and LwM2M Server MUST be able to verify the freshness of certain LwM2M operations.

LwM2M operations may have freshness requirements that are not possible to guarantee by protecting individual messages such as with DTLS Record Layer or OSCORE. This is accentuated with unreliable transport. Since datagram transport does not provide reliable or in-order delivery of data, DTLS and OSCORE preserves this property. Although duplicate messages are rejected through the use of anti-replay mechanisms, unordered delivery is still allowed, e.g. using a sliding receive window. As a consequence maliciously delayed message are accepted as long as they fall within the window.

For example, a Write operation, maliciously blocked from reaching the LwM2M Client at one time, may under these circumstances be successfully injected at a later time, potentially overwriting a more recent Write operation.

Operations protected by a security protocol with keys derived from a TLS/DTLS handshake are at least as fresh as the handshake. However, frequent use of the handshake protocols may be prohibitive in constrained environments. In order to avoid unnecessary processing, a more lightweight solution to verify freshness is provided by the CoAP Echo Option, illustrated with the example above: The LwM2M Client, receiving a Write operation of uncertain freshness may respond with an error message containing an Echo option including a random nonce as value. The LwM2M Server receiving the error response to a valid Write operation retransmits the request with the Echo option and value included. The LwM2M Client receiving a request with an Echo option verifies that the nonce corresponds to a recent request, and only in that case performs the operation (for details, see Section 2 of [CoAP_ERT]).

Applications need to understand the freshness requirements of the operations both in LwM2M Client and LwM2M server. The LwM2M implementation SHOULD enable timely freshness verifications to be performed without unnecessary overhead. For interoperability both LwM2M Client and LwM2M Server SHOULD implement the CoAP Echo option.

The attack does not apply when a connection-oriented transport, like CoAP over TCP is used, or when a replay window size of 1 is selected with DTLS.

The CoAP Echo Option is defined in RFC9175§ 2. Request Freshness and the Echo Option

Attack preventing by CoAP Echo Option are describe in :

• [email protected]. The Selective Blocking Attack
• [email protected]. The Request Delay Attack

Specific to OSCORE

At LWM2M-v1.1.1@transport§5.5.3. Bootstrapping

New OSCORE input parameters MAY be provisioned for use between endpoints having an existing OSCORE security context requiring the endpoints to derive new contexts. The Echo option MUST be used by the receiving endpoint when the OSCORE security context is used for the first time (e.g. Bootstrap-Request or Register) and SHOULD be used when the requested operation (e.g. Device Management Write) requires freshness that cannot be guaranteed by other means

At LWM2M-v1.1.1@transport§6.4.2. Bootstrap Interface

If OSCORE is used to secure Client Bootstrap then the Bootstrap-Server receiving the "Bootstrap-Request" operation MUST use the Echo Option.

At LWM2M-v1.1.1@transport§6.4.3. Registration Interface

If OSCORE is used to secure the Registration then the Echo Option MUST at least be used with the first operation.

What must we do in Leshan ?

This issue aims to discuss to know what should be done in Leshan regarding that part of the specification.

At first sight, It seems that one part is mainly a CoAP library feature which works transparently. I mean if one peer answers with Echo option, the other peer should repeat the request.
But this leads to the question who decide to ask for echoing a request. Should it be done transparently so application developer doesn't need to think too much about it ? If this is done transparently could it be done by LWM2M or CoAP stack ?

At least for OSCORE, there is more LWM2M specific work to do. 🤔
(But maybe for OSCORE we should use a dedicated issue)

What should be done at CoAP level ?

Some ideas at : open-coap/java-coap#65

Concerning Californium :
❌ Last Californium version (v3.9.0) doesn't support it
❌ This is not planned to be added.

Concerning java-coap :
❌ Last java-coap version (v6.16.1) doesn't seem to support it. (at least I find nothing about it)
✔️ Maintainers are interested to implement it. (open-coap/java-coap#65)

Compatibility with foreign peer which doesn't support it
(Note that a LWM2M server act as CoAP server and CoAP client and it's the same for a LWM2M client)
When a LWM2M peer acts as a CoAP server and want to use echooption , if the foreign peer doesn't support it, there is no way to communicate. So maybe a LWM2M server should be able to enable/disable echo option by client ? (idea was proposed at open-coap/java-coap#65 (comment))