You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CoAP Request-Tag Option SHOULD be used to detect interchange of blocks between different blockwise requests to the same resource over unreliable transport.
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.
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)
The text was updated successfully, but these errors were encountered:
Specifications :
I recently see that the LWM2M specification (since v1.1.x) says :
At LWM2M-v1.1.1@transport§6.1. Features :
At LWM2M-v1.1.1@transport§5.5. Identification of Blockwise Requests :
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 :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)
The text was updated successfully, but these errors were encountered: