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

From: Esko Dijk <[email-masked]>
Date: Tue, 17 Mar 2020 15:33:25 +0000

Hello Thomas,

Thanks again for your review comments on the -02 version. See below for the authors' responses ("[GC]") on how these comments were addressed in -03.

Esko
 
> -----Original Message-----
> From: Thomas Fossati <[email-masked]> 
> Sent: Sunday, November 24, 2019 23:08
> To: Esko Dijk <[email-masked]>; [email-masked]
> Cc: [email-masked]; Thomas Fossati <[email-masked]>
> Subject: Re: Review of draft-dijk-core-groupcomm-bis-00
> 
> 
> Hi Esko, Marco, Chonggang,
> 
> On 01/11/2019, 09:46, "Esko Dijk" <[email-masked]> 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 ?

[GC] Based on the outcome from IETF 106, this document more practically obsoletes RFC 7390 entirely, including that experimental API.

> 
>    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 :-)

[GC] We have added two new figures (now in Section 2.1). Figure 1 shows the relation between the different group types. Figure 2 shows example where such group types are used and combined

> 
>    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?
> 

[GC] Done (now in Section 2.2.1).

>    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?).
> 

[GC] Indeed. Now rephrased as “Application groups can be named in many ways through different types of identifiers, such as numbers, URIs and other strings.”

>    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?
> 

[GC] Using URI-Host will select another (virtual) CoAP server that is located on the same endpoint (i.e. IP address and UDP port combination). So that means that in principle, selecting another virtual CoAP server will select another application group.
First we thought that it would select a different CoAP group, but Section 4.1 of RFC 7252 defines an endpoint mode solely by IP address and UDP port number. And since we define CoAP group as a set of endpoints, changing the Uri-Host Option to something else will not change the CoAP group if the CoAP request is still delivered to the same IP address and port. In other words, the use of Uri-Host Option influences the 'common set of resources' that can be reached by a request and hence it has direct impact on the (selection of) application group.

However the use of Uri-Host can be tricky:
1. if it is encoded in the CoAP group URI, then the information typically gets removed in the actual CoAP request sent over the wire. So that means the receiving server cannot use it.
2. it can be added to an outgoing CoAP request (for which the group URI was already resolved to IP address). In that case it influences the choice of application group, because each virtual server will have a different set of resources hosted.

But because the Uri-Host option value is not something that one can reliably encode in a Group URI we decided to , for now, not include this approach in the draft. It would make things quite complicated, possibly.

> 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?

[GC] Added new Section 2.2.3 on discovering application groups, CoAP groups and security groups.

> 
>    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)

[GC] If there is no security, white-listing is fragile as there is no way to enforce it in an authenticated manner. That is, membership just as “here to receive” cannot be prevented altogether.

> 
>    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"?

[GC] Yes, now done (current Section 2.3.1).

> 
>    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.

[GC] We have added more text to clarify.

> 
>    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.

[GC] We have now clarified about using application-level unique IDs, or, when Group OSCORE is used, relying on additional identifiers for retrieving security material to decrypt the message and authenticate its source.

> 
>    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.

[GC] Done (current Section 2.3.2).

> 
>    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/

[GC] Done.

> 
>    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, [...]"

[GC] Done.

> 
>    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?

[GC] We have better clarified the issues at hand and the two high-level approaches with their own issues (current Section 2.3.3).
Also, we have recently submitted a new document, detailing the approach where the proxy forwards back the different individual responses from the server.
https://tools.ietf.org/html/draft-tiloca-core-groupcomm-proxy-00

> 
>    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?

[GC] That’s essentially what we do in the new document, with the Multicast-Signaling option.
https://tools.ietf.org/html/draft-tiloca-core-groupcomm-proxy-00#section-2

> 
>    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?

[GC] That’s essentially what we do in the new document, with the Response-Forwarding option.
https://tools.ietf.org/html/draft-tiloca-core-groupcomm-proxy-00#section-3

> 
>    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?

[GC] We have rephrased the text as follows:

“Due to the above issues, it is RECOMMENDED that a CoAP Proxy only processes a group URI request if it is explicitly enabled to do so. The default response (if the function is not explicitly enabled) to a group URI request is 5.01 (Not Implemented). Furthermore, a proxy SHOULD be explicitly configured (e.g. by white-listing and/or client authentication) to allow proxied CoAP multicast requests only from specific client(s).”

Then, an actual signalling protocol is described in the new document
https://tools.ietf.org/html/draft-tiloca-core-groupcomm-proxy-00

> 
>    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...)

[GC] We have changed the titled to “Countering Attacks”, and made a major rewriting of the whole section.

> 
>    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.
>