COAP Client Server communication over OpenThread

[Nikhil Komalan]

I would like to know the approach to be taken on the application level when a COAP client device needs to send data to COAP server. In general if i have a single COAP client i can update the data on single URI path on the server. But what happens if the COAP client increase like in my case.

In my case I have multiple COAP clients (interfaced with different sensor) devices updating data on COAP server using single URI path. All this COAP client devices will be connected to different machines and sending sensor data to COAP server.

Currently the code written by my ex-colleagues is such that all FTD COAP client devices are using multicast address to update sensor data (at rate 200ms) on COAP server using same URI path. On COAP server, i am just printing out the data on terminal and rest processing will be done on the back-end. 

So is that a right approach to use single URI path for all the client devices ? Or i should create multiple URI paths for each sensor/machine/devices.

[Stuart Longland]

On Tue, 20 Jul 2021 23:37:29 -0700 (PDT)
Nikhil Komalan <nkoma...@gmail.com> wrote:

> So is that a right approach to use single URI path for all the client
> devices ? Or i should create multiple URI paths for each
> sensor/machine/devices.

There's probably no "right" approach here. If you don't care to know
which sensor is which, the current solution is fine.

If you wish to identify a sensor individually, you have to either
assign (maybe the installer assigns one using a set of DIP switches) or
generate some sort of unique token that each can submit somewhere
in the request.

The token could be based on the EUI64 of the node (maybe as-is, or
maybe hashed, up to you and your needs), or it could be the node "logs
in" and receives a "session token" which is valid for a limited
life-time.

Devices I've written code for use the latter approach:
- on commissioning, nodes use their EUI64 to "register" with the server
- server generates authentication credentials, sends those to the node
- when a node needs to send something, it first logs in (if not already
logged in) to get a session token. (A short opaque one.)
- session token in our case is given as a URI-Query option in the CoAP
request. (/some/path/?t=<token>)

(Sort-of like poor man's OAuth2.)

Other options for where you could put it:
- a field in the request body ({value: 1234, token: <token>})
- URI-Path (/some/path/<token>)

Sadly, there's no "Authorization" option in CoAP that I know of,
otherwise I'd have suggested (and used) that.

Another option is to use a private key to digitally sign the request
body before transmission. After commissioning, the node would generate
a private/public key pair, and send the public key to the server. That
has the advantage that it'd prevent spoofing and be very secure, but
also highly CPU-intensive for the node.

Diffie-Hellman Key agreement with a shared secret key could also work
for this; such a key could generate a Message Authentication Code from
the message body. Generating a MAC is likely to be less CPU-intensive
than asymmetric cryptography. The DH negotiation though would have to
be done after commissioning, and would be quite CPU-intensive.

Both the cryptography approaches would need you to tell the server which
key is being used, effectively that would be your "token".

Anyway, those are some ideas. I'm sure others have possibly better
ideas that might work in your scenario. :-)

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

[Nikhil Komalan]

Currently i am using unique ID for each sensor. All sensors (x2) will multicast transmit data (UID+sensor data) to COAP server on single URI. COAP server is connected to a RPi, so with python i will be reading the data and do further processing.