Re: [core] Review of draft-ietf-core-groupcomm-bis-00

[Marco Tiloca <[e-mail]>]

Hi Jim,

Thanks for this review!

We have addressed most comments in the latest version -01.

Please, see our replies in line, with two points marked as "[OPEN]".

Best,
/Marco

On 2020-06-04 22:22, Jim Schaad wrote:
> I can't see that I have an outstanding review on this document so here is a
> new one.
>
> * Section 2.1 - Please make it clear of a client sending a message is part
> of an application group.  It is not part of a CoAP group but it is not clear
> for an application group.  (It might be useful to just define these things
> in terms of CoAP servers except for security groups.)

==>MT
We have added the sentence:

"A client endpoint that sends a group communication message to an
application group is not necessarily itself a member of this application
group."
<==

>
> * Section 2.1 - I believe that a client endpoint is part of a security
> group.  Please make this clear either true or false.

==>MT
We have added the sentence:

"So, a client endpoint needs to be a member of a security group in order
to send a valid secured group communication message to this group."
<==

>
> * Section 2.1 - s/do not share any resource/do not share any resources/

==>MT
Done.
<==

>
> * Section 2.1 - I still do not like the above statement.  If a resource maps
> to a URI-path, /.well-known/core could be part of multiple security groups.
> I don't know if this means it is a different application group or what. The
> fact that URI-path is not part of the tuple leads me to not know how to deal
> with this.

==>MT
We have removed the sentence.
<==

>
> * Figure 1:  I think that you have the grouping in reverse on the
> Application Group <-> CoAP group link.  I will admit that I do not use these
> a lot so I could be wrong.

==>MT
The diagram states:

"one Application group is associated to exactly one CoAP group"

which we believe to be correct. Also it states: "one CoAP group is
associated to one or more Application groups."
<==

>
> * Section 2.2.3 - I don't know that this needs to be included in the
> document because I think it might be more of a corner case, but it seems to
> me that application groups might also be discovered by doing a query to
> /.well-known/core on the multicast address.  That information might be part
> of the NoSec security group and thus if the RS knows the answer it could
> return it to the client.

==>MT
We have added the sentence:

"CoAP endpoints can also discover application groups by performing a
multicast discovery query using the /.well-known/core resource. Such a
request may be sent to a known CoAP group multicast address associated
to application group(s), or to the All CoAP Nodes multicast address."
<==

>
> * Section 2.2.4 - It looks like you are doing the start/stop of listening
> twice.

==>MT
Indeed, fixed now.
<==

>
> * Section 2.3.1 - I think we might need to have a discussion if the MAY in
> paragraph 3 ought to be upgraded to a SHOULD for traffic purposes.  I.e.
> don't send an answer if you don't have anything to say (error) unless you
> are required to do so by the application.

==>MT
We have updated the text now as follows:

“A server sends back a unicast response to the CoAP group request - but
the server MAY suppress the response for various reasons (Section 8.2 of
{{RFC7252}}). This document adds the requirement that a server SHOULD
suppress the response in case of error or in case there is nothing
useful to respond, unless the application requires such a response to be
made.”

Note that the next paragraph indicates that the No-Response Option if
supported by the server can override this behavior.
<==

> * Section 2.3.1 - In the paragraph starting "For multicast CoAP requests", I
> got confused when reading this paragraph because it starts dealing with
> multicast processing of tokens and then seems for some unknown reason starts
> talking about DTLS and TLS which seems to be extraneous.  I think that this
> extra information can just be deleted.  (By the way, I don't agree that you
> can immediately free up the token after getting a response.  You might end
> up sending a request with that token and getting the original response
> replayed to you and incorrectly associating things.  I believe that there is
> a time out before doing the re-use but I would need to check this in the
> CoAP document.  Additionally, this is not a true statement for things like
> observe.)

==>MT
We have updated the text to focus on the multicast case.
<==

> * Section 2.3.1 - " The Token values only have to be unique within the
> context of a single CoAP client"  This should really be the context of a
> single client - or depending on the implementation - a single source
> UDP/Port pair if token processing is different for each port used by a
> single client.

==>MT
[OPEN]

Could you please clarify your point?
<==

>
> * Section 2.3.3 - Bullet 1 in second list - Another difference for a CoAP
> client rather than a proxy is that the client can process responses as they
> show up and that can also be used as input to the decision of how long to
> wait for responses or if a new request needs to be made for additional
> responses.

==>MT
We have added the following final sentence to that bullet:

"For example, a CoAP client could monitor incoming responses and use
this information to decide how long to continue collecting responses -
which is something a proxy cannot do."
<==

> * Section 2.3.3 - Does it make sense to define a new HTTP header for the
> purpose of returning the address of the server?

==>MT
Yes, that can possibly be in draft-tiloca-core-groupcomm-proxy , for
both new options defined there, one of which has the purpose to return
the address of the server.
<==

>
> * Section 2.3.3 - Last bullet point - I do not believe that the multicast
> scope is something that the client gets to choose.  I think it is part of
> choosing what the multicast address is for the CoAP group.  If multiple
> addresses are assigned to a CoAP group then the client would have the
> ability to choose which address to use.  It is not clear to me how a RD
> would return this, but I have not thought about it at all.  Given that you
> cannot say FF0X::FD as the address.

==>MT
We have updated to advice for the designer/configurator of the system.
Now it reads:

"A client SHOULD be configured to use CoAP groups with the smallest
possible IP multicast scope that fulfills the application needs. As an
example, site-local scope is always preferred over global scope IP
multicast if this fulfills the application needs. Similarly, realm-local
scope is always preferred over site-local scope if this fulfills the
application needs."
<==

>
> * Section 2.3.5 - I think you need to have a paragraph dealing with
> unsubscribing to an observe relationship.  I believe that this is always
> going to be done via unicast but it would seem that this could be done in
> multicast instead.

==>MT
We have added a paragraph on cancellation, covering both
unicast/multicast and also a combination of both.
<==

>
> * Section 2.4.1 - I think you need to justify the addition of admin-local to
> the list of supported scopes as this is not part of RFC 7252.

==>MT
[OPEN]

In Section 3.3 of RFC 7390, admin-local is mentioned when discussing
resource/service discovery.

We can gather opinions if this is useful, or otherwise remove it.
<==

>
> * Section 4 - Reference to COSE needs to be updated to point to the IDs.

==>MT
Now we refer to draft-ietf-cose-rfc8152bis-struct  and 
draft-ietf-cose-rfc8152bis-algs
<==

>
> * Section 4 - Off the top of my head I don't remember an MAC operations done
> by OSCORE, it just uses encryption and signing (for group)

==>MT
Right, that was a mistake. Now it reads: “OSCORE uses COSE
[I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to
perform encryption operations and protect ..."
<==

>
> * Section 4 - I think this is a mistake, para 2 says that the result is
> encoded as a COSE object, but I am not sure that this should not be a CORE
> object.

==>MT
We have rephrased the paragraph as follows:

"OSCORE uses COSE
[I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to
perform encryption operations and protect a CoAP message in a COSE
object, by using an Authenticated Encryption with Associated Data (AEAD)
algorithm.  In particular, OSCORE takes as input an unprotected CoAP
message and transforms it into a protected CoAP message transporting the
COSE object."
<==

>
> * Section 5.2.1 - last paragraph - I think that "most recently" is better
> than "latest"

==>MT
Done.
<==

> * Section 5.2.3 - Bullet 2 - I think that you need some expansion in this
> topic.  My first reading was that the alleged sender was tied to the IP
> address and not tied to the signature key.  

==>MT
Now expanded as follows:

"the alleged sender in the OSCORE group, by verifying the
countersignature included in the request using the public key of that
sender."
<==

>
> * Section 5.4 - when used with security, I do not believe that this can do
> an amplification attack because the No-Response option is an inner option.

==>MT
Done.


Thanks a lot again!
<==

>
> Jim
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se