Re: [core] RFC 7252 - 8.2 - Multicast

Hello Achim,

(see also my response to Jim)
Using the UDP port number to detect a multicast request vs a unicast request sounds like a good use case. Just curious - I assume the security aspect requirements of RFC 7252 are taken care of in this use case?

That is, a proper client sends its multicast requests always to port :9999 and the server treats these as multicast requests (e.g. only allow the request for specific resources).
A malicious client may sends its multicast request to port :5683 to bypass the above checks. I assume the server doesn't respond to this request, because the multicast address is not bound to port 5683 but to say 9999 only.
If the CoAP server at port 5683 cannot distinguish between unicast/multicast that would be a bad situation and the security requirements of RFC 7252 are not met.

Esko

-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Achim Kraus
Sent: Wednesday, April 1, 2020 22:28
To: Thomas Fossati <tho.ietf@gmail.com>; Klaus Hartke <hartke@projectcool.de>
Cc: core@ietf.org
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi,

>> +---------------+                +-----------------+
>> |               |    request    _|_                |
>> |               |        .---> /   \   224.0.1.187 |
>> |              _|_      /      \___/ --.   :9999   |
>> | 192.168.0.1 /   \ ---´         |      \          |
>> |   :54321    \___/ <---.       _|_     /  rewrite |
>> |               |        \     /   \ <-´           |
>> |               |         `--- \___/ 192.168.0.100 |
>> |               |    response    |         :5683   |
>> +---------------+                +-----------------+
>>        Client                           Server

Nice diagram.

> Not sure why you would also want to rewrite the transport endpoint?

I tried to follow the discussion.
The idea to change the port as well enables java (and I guess some more)
to differentiate between multicast and unicast requests. Jim also
mentioned, that it enables the use of multiple servers on the same host.
I have not enough experience with multicast in different environments to
see, if that may cause more trouble (e.g. firewall etc.). I would guess,
that some  implementations will just offer that variant, at least as
configurable option (I would try do so for Californium).
So my favorite for now is just implement it and see, what the user's
feedback will be.

If that idea gets declined (may be by negative feedback of users), I
still think, that there is a demand for other means to distinguish
between multicast and unicast requests. Maybe, either the usage of the
uri-host option or a new option will help.

This maybe considered as "too pragmatically", but on the other side I
also don't see the "great benefit" in insist not to change the port.

best regards
Achim

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core