Skip to content
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

Support of CoAP Request-Tag option in Leshan ? #1506

Open
sbernard31 opened this issue Sep 5, 2023 · 0 comments
Open

Support of CoAP Request-Tag option in Leshan ? #1506

sbernard31 opened this issue Sep 5, 2023 · 0 comments
Labels
discussion Discussion about anything

Comments

@sbernard31
Copy link
Contributor

sbernard31 commented Sep 5, 2023

Specifications :

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

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

The CoAP Request-Tag Option SHOULD be used to detect interchange of blocks between different blockwise requests to the same resource over unreliable transport.

At LWM2M-v1.1.1@transport§5.5. Identification of Blockwise Requests :

The specification of Blockwise is vulnerable to interchange of blocks between different requests to the same resource. The attack may be performed when the replay window size of the the security protocol is greater than 1 even if the requests are not inverleaved and the attack applies both to DTLS and OSCORE. 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.

A solution is to use the CoAP Request-Tag Option for unique tagging of requests of a certain scope. The Request-Tag is analogous to the CoAP E-Tag Option, but tags requests instead of responses.

LwM2M Clients and LwM2M Servers supporting Blockwise SHOULD implement the CoAP Request-Tag Option.

The CoAP Request-Tag Option is defined in RFC9175§3.Protecting Message Bodies Using Request Tags

Attack preventing by CoAP Request-Tag Option are describe in : draft-ietf-core-attacks-on-coap§2.4.The Request Fragment Rearrangement Attack

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 this is mainly a CoAP library feature and so there is nothing special to do in Leshan.

What should be done at CoAP level ?
I guess straightforward solution is to always use Request-Tag option with blockwise transfer.
Maybe an more optimize (but overkill) way could be to use Request-Tag option only if :

  • there is concurrent blockwise transfer on same resource,
  • OR if previous blockwise request for same resource was lost.

Concerning Californium :
❌ Last Californium version (v3.9.0) doesn't support it
This is not planned to be added.
(As we are using transparent-blockwise transfer, I guess Californium should add Request-tag option transparently ?)

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)
(I don't know too much how block2 must be handle in java-coap. )

Compatibility with foreign peer which doesn't support it
Theoretically, if foreign peer doesn't support the option, it should just ignore it and so there is no compatibility issue.
If a peer doesn't know if the foreign peer supports request-tag, it should avoid to send concurrent request on same resource.
(My general advice is to avoid to send concurrent request on same resource anyway)

@sbernard31 sbernard31 added the discussion Discussion about anything label Sep 5, 2023
@sbernard31 sbernard31 changed the title Support of CoAP Request-Tag in Leshan Support of CoAP Request-Tag option in Leshan ? Sep 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion about anything
Projects
None yet
Development

No branches or pull requests

1 participant