search

open-coap / java-coap

CoAP Java library
Apache License 2.0
18 stars 5 forks source link

Missing peer identity/transport context checks ? #84

Open sbernard31 opened 2 months ago

sbernard31 commented 2 months ago

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. :pray:

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

szysas commented 2 months ago

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

sbernard31 commented 2 months ago

:+1:

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 :

And also some missing RFC statement about block transfer :

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 : https://github.com/core-wg/corrclar/issues/9#issuecomment-1646653697)

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