Missing peer identity/transport context checks ?

[sbernard31]

When you receive a request you can look to TransportContext to get "identifiication" of foreign peer.
But I can see nothing (let me know if I'm wrong) for ensuring identity of foreign peer when sending a request.

I give an example to better understand the issue.

Imagine 2 peer (A and B) which act both as coap server and client in a dynamic IP environment (e.g. peer A is behind a NAT)
Now imagine peer A initiates a (D)TLS handshake, then send a coap request to peer B.
Peer B check its identity and store its IP to send request later.
Now a Peer C which get same address IP than peer A (maybe because of NAT expiration), initiates an (D)TLS handshake with different authorized credentials.
Now Peer B want to send a request to peer A with current API the message will go to peer C.

If we could set a TransportContext constraint on outgoing request, it could be checked by transport layer.

I'm not sure I'm clear, let me know if this need more explanation. 🙏

Note that this kind of check should also probably be done to :

• match request and response
• match request and notification
• match blockwise request together

[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
• Clarify/revise language around epochs in section 9.1.1 core-wg/corrclar#9

And also some missing RFC statement about block transfer :

• RFC7959 - PUT/POST - DTLS - rules to apply for follow-up requests. 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 : Clarify/revise language around epochs in section 9.1.1 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