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

[Thomas Fossati <[e-mail]>]

Hi Esko, Marco, Chonggang,

On 01/11/2019, 09:46, "Esko Dijk" <[e-mail]> wrote:
> Our plan is to submit -02 by Monday Nov 4th. Meanwhile you can also have a
> look if you want at the current open issues we have in the tracker online
> https://gitlab.com/crimson84/draft-groupcomm-bis/issues Other CoRE members
> are also invited to raise issues, or comment on issues of course.
>
> Thanks in advance for your planned -02 review!

Thanks for the updates! Clearly *a lot* of serious work has gone into
this revision and it looks like all the important topics, the document
structure as well as the core concepts and the associated vocabulary are
all falling into place nicely.  There is obviously more legwork ahead,
but I reckon -02 is already in a state that could be considered for
adoption.

I have left a few comments inline -- as per tradition, grep for '^#' to
find them :-) -- and a few merely editorial fixes have been provided in
a MR to the Gitlab repo.

Cheers, and thanks again for all the great work!

=-=-=-=-=-=-

1.1.  Scope

   For group communication, only solutions that use CoAP over UDP/
   multicast are in the scope of this document.  There are alternative
   methods to achieve group communication using CoAP, for example
   Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central
   broker server that CoAP clients access via unicast communication.
   The alternative methods may be usable for the same or similar use
   cases as are targeted in this document.

   All guidelines in [RFC7390] are imported by this document which
   replaces [RFC7390] in this respect.

# what about the state of the API in 7390 section 2.6.2 ?

   Furthermore, this document adds:
   how to provide security by using Group OSCORE
   [I-D.ietf-core-oscore-groupcomm] as the default group communication
   security solution for CoAP; an updated request/response matching rule
   for multicast CoAP which updates [RFC7252]; the multicast use of CoAP
   Observe which updates [RFC7641]; and an extension of the multicast
   use of CoAP block-wise transfers, which updates [RFC7959].

   Security solutions for group communication and configuration other
   than Group OSCORE are not in scope.  General principles for secure
   group configuration are in scope.  The experimental group
   configuration protocol in Section 2.6.2 of [RFC7390] is not in the
   scope of this document; thus, that remains an experimental protocol.
   Since application protocols defined on top of CoAP often define their
   own specific method of group configuration, the experimental protocol
   of [RFC7390] has not been subject to enough experimentation to
   warrant a change of this status.

2.1.1.  Group Definition

   A CoAP group is defined as a set of CoAP endpoints, where each
   endpoint is configured to receive CoAP multicast requests that are
   sent to the group's associated IP multicast address and UDP port.  An
   endpoint may be a member of multiple CoAP groups.  Group
   membership(s) of an endpoint may dynamically change over time.  A
   device sending a CoAP request to a group is not necessarily itself a
   member of this group: it is only a member if it also has a CoAP
   server endpoint listening to requests for this CoAP group.  For
   secure group communication, a receiver also requires the security
   context to successfully decrypt and/or verify group messages in order
   to be a group member.

# Nice characterisation.  A picture here would be great :-)

   A CoAP Group URI has the scheme 'coap' and includes in the authority
   part either an IP multicast address or a group hostname (e.g., Group
   Fully Qualified Domain Name (FQDN)) that can be resolved to an IP
   multicast address.  A Group URI also contains an optional UDP port
   number in the authority part.  Group URIs follow the regular CoAP URI
   syntax (Section 6 of [RFC7252]).

   Besides CoAP groups, that have relevance at the level of networked
   devices, there can also be application groups defined.  An
   application group has relevance at the application level - for
   example an application group could denote all lights in an office
   room or all sensors in a hallway.  There can be a one-to-one or a
   one-to-many relation between CoAP groups and application groups.

2.1.2.  Group Naming

   For clients, it is RECOMMENDED to use by default an IP multicast
   address literal in a configured Group URI, instead of a hostname.
   This is because DNS infrastructure may not be deployed in many

# Not sure this deserves an RFC2119 keyword. The configuring entity is
# probably in a better position to determine whether DNS is available or
# not in the hosting network and therefore take the sensible decision?

   constrained networks.  In case a group hostname is used in the Group
   URI, it can be uniquely mapped to an IP multicast address via DNS
   resolution - if DNS client functionality is available in the clients
   and the DNS service is supported in the network.  Some examples of
   hierarchical group FQDN naming (and scoping) for a building control
   application are shown in Section 2.2 of [RFC7390].

   Application groups can be named in many ways, e.g. numbers, IDs,
   strings or URIs.  An application group identifier, if used, is

# I am confused by the "numbers, IDs, strings or URI" part here.  How do
# they differ (is not a URI a string and also an ID?).

   typically included in the path component or query component of a
   Group URI.  Appendix A of [I-D.ietf-core-resource-directory] shows
   registration of application groups into a Resource Directory, along
   with the CoAP group it maps to.

# I guess another strategy to name application groups could built on
# the URI-Host component in a "virtual hosting" fashion?

2.1.3.  Group Creation and Membership

   To create a CoAP group, a configuring entity defines an IP multicast
   address (or hostname) for the group and optionally a UDP port number
   in case it differs from the default CoAP port 5683.  Then, it
   configures one or more devices as listeners to that IP multicast
   address, with a CoAP server listening on the group's associated UDP
   port.  These devices are the group members.  The configuring entity
   can be, for example, a local application with preconfiguration, a
   user, a cloud service, or a local commissioning tool.  Also, the
   devices sending requests to the group in the role of CoAP clients
   need to be configured with the same information, even though they are
   not necessarily group members.  One way to configure a client is to
   supply it with a CoAP Group URI, possibly together with the required
   security material in case communication is secured in the group.

# What about dynamic discovery?

   For unsecure group communication, any CoAP endpoint may become a
   group member at any time: there is no (central) configuring entity
   that needs to provide the security material for the group.  This
   means that group creation and membership cannot be tightly
   controlled.

# Correct, but something can be done still (e.g., white-listing senders)

   The IETF does not define a mandatory, standardized protocol to
   accomplish these steps.  [RFC7390] defines an experimental protocol
   for configuration of group membership for unsecured group
   communication, based on JSON-formatted configuration resources.  This
   protocol remains experimental.  For secure group communication, the
   part of the process that involves secure distribution of group keys
   MAY use standardized communication with a Group Manager as defined in
   Section 4.

   The configuration of groups and membership may be performed at
   different moments in the lifecycle of a device; for example in the
   factory, at a reseller, on-site during first deployment, or on-site
   during a system reconfiguration operation.

2.2.1.  Request/Response Model

   A CoAP client is an endpoint able to transmit CoAP requests and
   receive CoAP responses.  Since the underlying UDP supports
   multiplexing by means of UDP port number, there can be multiple
   independent CoAP clients operational on a single host.  On each UDP
   port, an independent CoAP client can be hosted.  Each independent
   CoAP client sends requests that use the associated endpoint's UDP
   port number as the UDP source port of the request.

   All CoAP requests that are sent via IP multicast MUST be Non-
   confirmable (Section 8.1 of [RFC7252]).  The Message ID in an IP
   multicast CoAP message is used for optional message deduplication by
   both clients and servers, as detailed in Section 4.5 of [RFC7252].

   A server sends back a unicast response to the CoAP group
   communication request - but it MAY suppress this response if selected

# Maybe just "CoAP group request"?

   so by the server application and if permitted by the rules in this
   document.  The unicast responses received by the CoAP client may be a
   mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not
   Found) codes, depending on the individual server processing results.

   Response suppression controlled by a server SHOULD be performed in a
   consistent way, such that if a first request leads to a response that
   is not suppressed, then a second similar request on the same resource
   that leads to the same response code is also not suppressed.

   The CoAP Option for No Server Response [RFC7967] can be used by a
   client to influence the response suppression on the server side.  It
   is RECOMMENDED for a server to implement this option only on selected
   resources where it is useful in the application context.

   A CoAP client MAY repeat a multicast request using the same Token
   value and same Message ID value, in order to ensure that enough (or
   all) group members have been reached with the request.  This is
   useful in case a number of group members did not respond to the
   initial request.  However, in case one or more servers did receive
   the initial request but the response to that request was lost, this
   repeat may not help to retrieve the lost response(s) if the server
   implements the optional Message ID based deduplication.

   A CoAP client MAY also repeat a multicast request using the same
   Token value but a different Message ID, in which case all servers
   that received the initial request will again process the repeated
   request.  This is useful in case a client needs to collect more, or
   even all, responses from group members.

# What is the use case for this mechanism?  Is this for when the client
# suspects some responses were lost?  In any case, please make it
# explicit.

   The CoAP client can distinguish the origin of multiple server
   responses by the source IP address of the UDP message containing the
   CoAP response and/or any other available application-specific source
   identifiers contained in the CoAP response.

# Which "application-specific source identifiers" do you have in mind?
# Besides, in a secure group that provides origin authentication the
# receiver should in principle use crypto to determine who's the sender.

   While processing a
   response, the source endpoint of the response is not exactly matched
   to the destination endpoint of the request, since for a multicast
   request these will never match.  This is specified in Section 8.2 of
   [RFC7252].  In case a single client has sent multiple group requests
   and concurrent CoAP transactions are ongoing, the responses received
   by that client are matched to a request using the Token value.  Due
   to UDP level multiplexing, the UDP destination port of the response
   MUST match to the client endpoint's UDP port value, i.e. to the UDP
   source port of the client's request.

   For multicast CoAP requests, there are additional constraints on the
   reuse of Token values at the client, compared to the unicast case.
   In the unicast case, receiving a response effectively frees up its
   Token value for reuse, since no more responses to the same request
   will follow.  However, for multicast CoAP, the number of responses is
   not bound a priori.  Therefore, client cannot use the reception of a
   response as a trigger to "free up" a Token value for reuse.
   Moreover, reusing a Token value too early could lead to incorrect
   response/request matching on the client, and would be a protocol
   error.  Therefore, the time between reuse of Token values used in
   multicast requests MUST be greater than:

   NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY

   where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of
   [RFC7252].  This specification defines MAX_SERVER_RESPONSE_DELAY as
   in [RFC7390], that is: the expected maximum response delay over all
   servers that the client can send a multicast request to.  This delay
   includes the maximum Leisure time period as defined in Section 8.2 of
   [RFC7252].  However, CoAP does not define a time limit for the server
   response delay.  Using the default CoAP parameters, the Token reuse
   time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY.
   A preferred solution to meet this requirement is to generate a new
   unique Token for every new multicast request, such that a Token value
   is never reused.  If a client has to reuse Token values for some
   reason, and also MAX_SERVER_RESPONSE_DELAY is unknown, then using
   MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline.
   The time between Token reuses is in that case set to a value greater
   than 500 seconds.

   Another method to more easily meet the above constraint is to
   instantiate multiple CoAP clients at multiple UDP ports on the same
   host.  The Token values only have to be unique within the context of
   a single CoAP client, so using multiple clients can make it easier to
   meet the constraint.

   Since a client sending a multicast request with a Token T will accept
   multiple responses with the same Token T, there is a risk that a same
   server sends multiple responses with the same Token T back to the
   client.  For example, this server might not implement the optional
   CoAP message deduplication based on Message ID, or it might be a
   malicious/compromised server acting out of specification.  To
   mitigate issues with multiple responses from one server bound to a
   same multicast request, the client has to ensure that, as long as the
   the CoAP Token used for a multicast request is retained, at most one
   response to that request per server is accepted, with the exception
   of Observe notifications [RFC7641] (see Section 2.2.5).

   To this end, upon receiving a response corresponding to a multicast
   request, the client MUST perform the following actions.  First, the
   client checks whether it previously received a valid response to this
   request from the same originating server of the just-received
   response.  If the check yields a positive match and the response is
   not an Observe notification (i.e., it does not include an Observe
   option), the client SHALL stop processing the response.  Upon
   eventually freeing up the Token value of a multicast request for
   possible reuse, the client MUST also delete the list of responding
   servers associated to that request.

2.2.2.  Port and URI Path Selection

   A CoAP server that is a member of a group listens for CoAP messages

# Maybe "A server that is a member of a CoAP group ..." instead? Here as
# well as in the following.  It seems more coherent with 2.1.1.

   on the group's IP multicast address, usually on the CoAP default UDP
   port 5683, or another non-default UDP port if configured.  Regardless
   of the method for selecting the port number, the same port number
   MUST be used across all CoAP servers that are members of a group and
   across all CoAP clients performing the group requests to that group.

# s/group request/request/

   The URI Path used in the request is preferably a path that is known
   to be supported across all group members.  However there are valid
   use cases where a request is known to be successful for a subset of
   the group and those group members for which the request is
   unsuccessful either ignore the multicast request or respond with an
   error status code.

   Using different ports with the same IP multicast address is an
   efficient way to create multiple CoAP groups in constrained devices,

# "efficient" is not the best way to characterise this method -- in
# fact the reason why this is not the case is explained below.  Maybe just
# drop "efficient" and say "A way to create multiple CoAP groups [...]
# is using different ports [...]", and later: "However, [...]"

   in case the device's stack only supports a limited number of IP
   multicast group memberships.  However, it must be taken into account
   that this incurs additional processing overhead on each CoAP server
   participating in at least one of these groups: messages to groups
   that are not of interest to the node are only discarded at the higher
   transport (UDP) layer instead of directly at the network (IP) layer.

   Port 5684 is reserved for DTLS-secured CoAP and MUST NOT be used for
   any CoAP group communication.

   For a CoAP server node that supports resource discovery as defined in
   Section 2.4 of [RFC7252], the default port 5683 MUST be supported
   (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast
   group.

2.2.3.  Proxy Operation

   CoAP (Section 5.7.2 of [RFC7252]) allows a client to request a
   forward-proxy to process its CoAP request.  For this purpose, the
   client specifies either the request group URI as a string in the
   Proxy-URI option or alternatively it uses the Proxy-Scheme option
   with the group URI constructed from the usual Uri-* options.  This
   approach works well for unicast requests.  However, there are certain
   issues and limitations of processing the (unicast) responses to a
   CoAP group communication request made in this manner through a proxy.

   A proxy may buffer all the individual (unicast) responses to a CoAP
   group communication request and then send back only a single
   (aggregated) response to the client.  However, there are some issues
   with this aggregation approach:

   o  Aggregation of (unicast) responses to a CoAP group communication
      request in a proxy is difficult.  This is because the proxy does
      not know how many members there are in the group or how many group
      members will actually respond.  Also, the proxy does not know how
      long to wait before deciding to send back the aggregated response
      to the client.

   o  There is no default format defined in CoAP for aggregation of
      multiple responses into a single response.  Such a format could be
      defined based on the multipart content-format
      [I-D.ietf-core-multipart-ct] but is not standardized yet
      currently.

# This document looks to me like the right place to fix this gap?

   Alternatively, if a proxy does not aggregate responses and follows
   the CoAP Proxy specification (Section 5.7.2 of [RFC7252]), the proxy
   would forward all the individual (unicast) responses to a CoAP group
   communication request to the client.  There are also issues with this
   approach:

   o  The client may be confused as it may not have known that the
      Proxy-URI contained a group URI target.  That is, the client that
      sent a unicast CoAP request to the proxy may be expecting only one
      (unicast) response.  Instead, it receives multiple (unicast)
      responses, potentially leading to fault conditions in the
      application.

# Could this be solved by means of proxy-client Option signalling
# to be specified here?

   o  Each individual CoAP response will appear to originate (based on
      its IP source address) from the CoAP Proxy, and not from the
      server that produced the response.  This makes it impossible for
      the client to identify the server that produced each response,
      unless the server identity is contained as a part of the response
      payload.

# This and the above look like they could be addressed by one "Forwarded"
# Option?

   Due to the above issues, a CoAP Proxy SHOULD NOT support processing
   an IP multicast CoAP request but rather return a 501 (Not
   Implemented) response in such case.

# I'm not sure the above SHOULD NOT is the optimal conclusion: you do a
# very good job at working out all the gaps and it looks like
# the current CoRE toolbox should have all the pieces needed to assemble
# the missing mechanics.  Why not going a step further and put together
# the actual signalling protocol?

   The exception case here (i.e.,
   to support it) is when all the following conditions are met:

   o  The CoAP Proxy MUST be explicitly configured (whitelist) to allow
      proxied IP multicast requests by specific client(s).

   o  The proxy SHOULD return individual (unicast) CoAP responses to the
      client (i.e., not aggregated).  If a (future) standardized
      aggregation format is being used, then aggregated responses may be
      sent.

   o  It MUST be known to the person/entity doing the configuration of
      the proxy, or otherwise verified in some way, that the client
      configured in the whitelist supports receiving multiple responses
      to a proxied unicast CoAP request.

   The operation of HTTP-to-CoAP proxies for multicast CoAP requests is
   specified in Section 8.4 and 10.1 of [RFC8075].  In this case, the
   "application/http" media type can be used to let the proxy return
   multiple CoAP responses - each translated to a HTTP response - back
   to the HTTP client.  Of course, in this case the HTTP client needs to
   be aware that it is receiving this format and needs to be able to
   decode from it the responses of multiple servers.  The above
   restrictions listed for CoAP Proxies still apply to HTTP-to-CoAP
   proxies: specifically, the IP address of the sender of each CoAP
   response cannot be determined from the application/http response.


5.2.3.  Counteraction of Attacks

# I guess this section needs some TLC -- maybe starting from the title :-)
# One way to reorganise this material would be to describe which OSCORE
# properties are relevant in the multicast case and what security (in
# terms of resilience to certain attacks they provide.  (Just a
# suggestion...)

   Group OSCORE addresses security attacks mentioned in Sections
   11.2-11.6 of [RFC7252], with particular reference to their execution
   over IP multicast.  That is: it provides confidentiality and
   integrity of request/response data through proxies also in multicast
   settings; it prevents amplification attacks carried out through
   responses to injected requests over IP multicast; it limits the
   impact of attacks based on IP spoofing; it prevents cross-protocol
   attacks; it derives the group key material from, among other things,
   a Master Secret securely generated by the Group Manager and provided
   to CoAP endpoints upon their joining of the OSCORE group;
   countersignatures assure source authentication of exchanged CoAP
   messages, and hence prevent a group member to be used for subverting
   security in the whole group.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.