CoAP Request-Tag option Support

[sbernard31]

Since LWM2M v1.1.1, "CoAP Request-Tag option SHOULD be used to detect interchange of blocks between different blockwise requests to the same resource over unreliable transport." (See for more details : eclipse-leshan/leshan#1506))

I understand this is mainly to protect against draft-ietf-core-attacks-on-coap§2.4.The Request Fragment Rearrangement Attack.

So I try get more information about that.

1. I understand this is not supported by Californium for now, right ?
2. Is there plan to add support about it ?
3. Even if this is not planned, I would like to understand what could means to support of it ?
   1. At server side, this is pretty much defined in the specification, I mean we use Request-Tag to match several request block together.
   2. At client side, this is less clear
      1. Should we have a mode (maybe the default one) where this option is used on every block request automatically ?
      2. OR should it be smarter than that and be used only when previous block was lost ?

Some behavior description are available at draft-ietf-core-attacks-on-coap§ 2.4.1. Completing an Operation with an Earlier Final Block

Remedy: If a client starts new block-wise operations on a security context that has lost packets, it needs to label the fragments in such a way that the server will not mix them up.

A mechanism to that effect is described as Request-Tag [RFC9175]. Had it been in place in the example and used for body integrity protection, the client would have set the Request-Tag option in the "promote" request. Depending on the server's capabilities and setup, either of four outcomes could have occurred:

1. The server could have processed the reinjected POST "valjean" as belonging to the original "incarcerate" block; that's the expected case when the server can handle simultaneous block transfers.
2. The server could respond 5.03 Service Unavailable, including a Max-Age option indicating how long it prefers not to take any requests that force it to overwrite the state kept for the "incarcerate" request.
3. The server could decide to drop the state kept for the "incarcerate" request's state, and process the "promote" request. The reinjected POST "valjean" will then fail with 4.08 Request Entity incomplete, indicating that the server does not have the start of the operation anymore.

[boaks]

1. yes, Californium hasn't implemented it.
2. from my side there are no plans
3. I guess ii.a. Others, which have already implemented it may know it better.

[sbernard31]

About 3., obgm/libcoap#786 is a partial answer.

[boaks]

About the server-side:
Simply adding that option to the KeyUri is simple, I consider to do that.
But gathering experience with that RFC in the wild requires then someone else spending time in it.