Missing peer identity/transport context checks ? about java-coap

[szysas]

Good point, I think I did got your point. We definitely should add those checks.

[sbernard31]

👍

We face same kind of issue a long time ago with Californium too.
And we discover there are some issues with CoAP RFCs too but for now AFAIK this issue are not solved in RFC.

I will try to share some information about that.

CoAP RFC says :

For coap,

The source endpoint of the response MUST be the same as the destination endpoint of the original request.

For coaps,

The following rules are added for matching a response to a request:
The DTLS session MUST be the same, and the epoch MUST be the same.

This means the response to a DTLS secured request MUST always be DTLS
secured using the same security session and epoch. Any attempt to
supply a NoSec response to a DTLS request simply does not match the
request and therefore MUST be rejected (unless it does match an
unrelated NoSec request).

The CoAP over DTLS matching rule is really unclear and lead to real production issue especially with Coap Observe.
Here some topic about that :

• https://github.com/eclipse-leshan/leshan/wiki/LWM2M-Observe#for-dtls
• core-wg/corrclar#9

And also some missing RFC statement about block transfer :

• core-wg/corrclar#19

It seems that the specifications are not yet clear on this and that there are probably many real-world implementations and use cases based on very different assumptions, so I guess :

1. this matching logic should be customizable.
2. Not sure but maybe there is 2 different kind of matching ? for short term exchange (e.g. request/response) and for long term exchange (e.g. notification). (see : core-wg/corrclar#9 (comment))

In my coap(s)+tcp java-coap transport based netty, I have a first try of this, see :

• CoapsTcpTransportResolver
• CoapTcpDecoder
• CoapTcpEncoder
• DefaultTransportContextMatcher
• NettyCoapTcpTransport