Subject: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

From: Achim Kraus <[email-masked]>
Date: Fri, 27 Mar 2020 07:38:38 +0100

Hi list,

RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

"When matching a response to a multicast request, only the token MUST
match; the source endpoint of the response does not need to (and will
not) be the same as the destination endpoint of the original request."

(4.1. Messages and Endpoint, "With no security, the endpoint is solely
identified by an IP address and a UDP port number")

Though it is obvious, that the IP address part is changing (from
multicast destination to a unicast source), I 'm not sure, why the port
should be considered to change as well.

example:
192.168.1.50:15683 -> 224.0.1.187:5683   (multicast request)

192.168.1.50:15683 <- 192.168.1.40:5683  (unicast response, I would expect)

192.168.1.50:15683 <- 192.168.1.40:7843  (unicast response, the spec.
also allows)

So,

- was a change of the port (2. example response) considered when
writting that definition?
- if yes, what was the reason to do so?

best regards
Achim Kraus

---

From: Jim Schaad <[email-masked]>
Date: Fri, 27 Mar 2020 09:14:23 -0700

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Thursday, March 26, 2020 11:39 PM
To: [email-masked]
Subject: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page
67, top

Hi list,

"When matching a response to a multicast request, only the token MUST match;
the source endpoint of the response does not need to (and will
not) be the same as the destination endpoint of the original request."

Though it is obvious, that the IP address part is changing (from multicast
destination to a unicast source), I 'm not sure, why the port should be
considered to change as well.

example:

So,

- was a change of the port (2. example response) considered when writting
that definition?
- if yes, what was the reason to do so?

[JLS] My response would be that the answer is yes.  The unicast responder
does not need to be on the default COAP port number.  This would be
especially true if you had two different server running on the same piece of
hardware.   I find this to be very common for me in testing because I am
running 10 different CoAP servers on my laptop and while they can share the
multicast addresses, they need to end up on different unicast ports.

Jim Schaad

best regards
Achim Kraus

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Achim Kraus <[email-masked]>
Date: Fri, 27 Mar 2020 18:59:35 +0100

Hi Jim,

thanks for the fast answer!

 > The unicast responder does not need to be on the default COAP port
number.

It's more the destination port of the request than the default CoAP port.

 > This would be especially true if you had two different server running
 > on the same piece of hardware. I find this to be very common for me in
 > testing because I am running 10 different CoAP servers on my laptop
 > and while they can share the multicast addresses, they need to end up
 > on different unicast ports.

OK, I see. Interesting. Using  different ports for multicast and unicast
makes it also easier to distinguish multicast from unicast.

(On the other side, it kills somehow the idea of a "service, bound to a
port" and it makes tracking the traffic with wireshark harder :-).
I will see, when I can spend some time into adjust the server-side
according this idea in your answer.)

best regards
Achim

---

From: Esko Dijk <[email-masked]>
Date: Tue, 31 Mar 2020 10:32:24 +0000

Hi Achim, Jim,

CoAP did not define (for multicast) that the *matching* done on the client is based on the source endpoint of the response, you're right about this.
However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

In Section 2.1:
  The CoAP messaging model is based on the exchange of messages over UDP between endpoints.
[seems to hint at 2 endpoints. Although more would be possible.]

And Section 1.2:

  Endpoint
      An entity participating in the CoAP protocol.  Colloquially, an
      endpoint lives on a "Node", although "Host" would be more
      consistent with Internet standards usage, and is further
      identified by transport-layer multiplexing information that can
      include a UDP port number and a security association
      (Section 4.1).
[this defers to Section 4.1 and seems to hint that different UDP port numbers define different endpoints.]

   Server
      The destination endpoint of a request; the originating endpoint of
      a response.
[this seems intended as one endpoint on which the server lives; see below]

And in 4.1.  Messages and Endpoints:

   A CoAP endpoint is the source or destination of a CoAP message.  The
   specific definition of an endpoint depends on the transport being
   used for CoAP.  For the transports defined in this specification, the
   endpoint is identified depending on the security mode used (see
   Section 9): With no security, the endpoint is solely identified by an
   IP address and a UDP port number.  With other security modes, the
   endpoint is identified as defined by the security mode.
[this mentions UDP port number defines endpoints, in case of no-security mode i.e. multicast CoAP + UDP usage]

So what this tells me is that the server lives at a specific endpoint (identified by IP address and port) that receives a request, and will respond from that same endpoint. (Otherwise it would be a different server responding, living at a different endpoint!)
Or turning it around: if the server would be allowed to respond from another port number, it implies that there is one CoAP server residing on multiple endpoints.  And that seems to go against server as "destination endpoint of a request; the originating endpoint of a response" , or not?
I would interpret this as a server being on only one endpoint.  Because if not, then also for the unicast case  the server could be allowed to respond from a different endpoint because that server lives on multiple endpoints then.

Note there is slightly more information that adds to RFC 7252 in the draft section https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-00#section-2.3.1. But it does not explain the present issue, though, only details the matching at the client side.
Feel free to challenge my RFC 7252 interpretation, maybe I overlooked something.

Best regards
Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Achim Kraus
Sent: Friday, March 27, 2020 19:00
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi Jim,

number.

best regards
Achim

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 31 Mar 2020 13:46:27 +0200

> However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

Yes. In the simple CoAP-over-UDP unicast NoSec case, if a request
message is sent from an endpoint 192.168.0.1:54321 ("client") to an
endpoint 192.168.0.100:5683 ("server"), the response message must be
sent from the endpoint 192.168.0.100:5683 to the endpoint
192.168.0.1:54321.

The response message cannot be sent from any other endpoint, because
then the client couldn't match the incoming message to its pending
request (it would appear to come from a different server). The
response message also cannot be sent to any other endpoint, because
then the client wouldn't get the message (it would be sent to a
different client).

I view multicast messages basically like e-mail mailing lists. E.g.
(IMO): A request message is sent from the endpoint 192.168.0.1:54321
to the special endpoint 224.0.1.187:9999, the message magically shows
up as incoming message at the endpoint 192.168.0.100:5683, and the
response message must be sent from the endpoint 192.168.0.100:5683 to
the endpoint 192.168.0.1:54321.

Klaus

---

From: Jim Schaad <[email-masked]>
Date: Tue, 31 Mar 2020 09:52:02 -0700

-----Original Message-----
From: Klaus Hartke <[email-masked]> 
Sent: Tuesday, March 31, 2020 4:46 AM
To: Esko Dijk <[email-masked]>
Cc: Achim Kraus <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

> However CoAP does define that a Server responds from the same endpoint that received the request, I believe. See below text quotes and analysis.

Yes. In the simple CoAP-over-UDP unicast NoSec case, if a request message is sent from an endpoint 192.168.0.1:54321 ("client") to an endpoint 192.168.0.100:5683 ("server"), the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

The response message cannot be sent from any other endpoint, because then the client couldn't match the incoming message to its pending request (it would appear to come from a different server). The response message also cannot be sent to any other endpoint, because then the client wouldn't get the message (it would be sent to a different client).

I view multicast messages basically like e-mail mailing lists. E.g.
(IMO): A request message is sent from the endpoint 192.168.0.1:54321 to the special endpoint 224.0.1.187:9999, the message magically shows up as incoming message at the endpoint 192.168.0.100:5683, and the response message must be sent from the endpoint 192.168.0.100:5683 to the endpoint 192.168.0.1:54321.

[JLS] What he said.  And then after the first message comes in from 192.168.0.100:5683, all of the messages from that endpoint are correlated together so that you can do things like blockwise.

Klaus