Group Communication for the Constrained Application Protocol (CoAP)

1.1. Scope

For group communication, only those solutions that use CoAP messages over a "one-to-many" (i.e., non-unicast) transport protocol are in the scope of this document. There are alternative methods to achieve group communication using CoAP, using unicast only. One example is Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central broker server that CoAP clients access via unicast communication. These alternative methods may be usable for the same or similar use cases as the ones targeted in this document.¶

This document defines UDP/IP multicast as the default transport protocol for CoAP group requests, as in [RFC7252]. Other transport protocols (which may include broadcast, non-IP multicast, geocast, etc.) are not described in detail and are not considered. Although UDP/IP multicast transport is assumed in most of the text in this document, we expect many of the considerations for UDP/IP multicast can be re-used for alternative transport protocols.¶

Furthermore, this document defines Group OSCORE [I-D.ietf-core-oscore-groupcomm] as the default group communication security solution for CoAP. Security solutions for group communication and configuration other than Group OSCORE are not considered. General principles for secure group configuration are in scope.¶

1.2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This specification requires readers to be familiar with CoAP terminology [RFC7252]. Terminology related to group communication is defined in Section 2.1.¶

In addition, the following terms are extensively used.¶

• Group URI -- This is defined as a CoAP URI that has the "coap" scheme and includes in the authority component either an IP multicast address or a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN)) that can be resolved to an IP multicast address. A group URI also can contain a UDP port number in the authority component. Group URIs follow the regular CoAP URI syntax (see Section 6 of [RFC7252]).¶

• Security material -- This refers to any security keys, counters, or parameters stored in a device that are required to participate in secure group communication with other devices.¶

1.3. Changes to Other Documents

This document obsoletes and replaces [RFC7390] as follows.¶

• It provides separate definitions for CoAP groups, application groups, and security groups, together with high-level guidelines on their configuration (see Section 2).¶

• It defines the use of Group OSCORE [I-D.ietf-core-oscore-groupcomm] as the security protocol to protect group communication for CoAP, together with high-level guidelines on secure group maintenance (see Section 5).¶

• It updates all the guidelines about using group communication for CoAP (see Section 3).¶

• It strongly discourages unsecured group communication for CoAP based on the CoAP NoSec (No Security) mode (see Section 4 and Section 6.1), and highlights the risk of amplification attacks (see Section 6.3).¶

• It updates all sections on transport protocols and interworking with other protocols based on new IETF work done for these protocols.¶

This document updates [RFC7252] as follows.¶

• It updates the request/response model for group communication, as to response suppression (see Section 3.1.2) and token reuse time (see Section 3.1.5).¶

• It updates the freshness model and validation model to use for cached responses (see Section 3.2.1 and Section 3.2.2).¶

• It defines the measures against congestion risk specified in [RFC7252] to be applicable also to alternative transports other than IP multicast, and defines additional guidelines to reduce congestion risks (see Section 3.6).¶

• It explicitly admits the use of the IPv6 multicast address scopes realm-local (3), admin-local (4), and global (E). In particular, it recommends that an IPv6 CoAP server supports at least link-local (2), admin-local (4), and site-local (5) scopes with the "All CoAP Nodes" multicast CoAP group (see Section 3.9.1). Also, it recommends that the realm-local (3) scope is supported by an IPv6 CoAP server on a 6LoWPAN node (see Section 3.9.1).¶

This document updates [RFC7641] as follows.¶

• It defines the use of the CoAP Observe Option in group requests, for both the GET method and the FETCH method [RFC8132], together with normative behavior for both CoAP clients and CoAP servers (see Section 3.7).¶

2.1. Group Definition

Three types of groups and their mutual relations are defined in this section: CoAP group, application group, and security group.¶

(application group, CoAP group, security group)

+------------------------------+              +--------------------+
|   Application group          |              |    CoAP group      |
|..............................|              |....................|
|                              |              |                    |
| [ - Application group name ] +--------------+ - IP mcast address |
|                              |  1...N    1  | - UDP port number  |
| - Resource URI path(s)       |              |                    |
|                              |              |                    |
+-------------+----------------+              +---------+----------+
              |  1...N                                  |  1...N
              |                                         |
              |                                         |
              |                                         |  1...N
              |                            +------------+----------+
              |                            |   Security group      |
              |                            |.......................|
              |                            |                       |
              '----------------------------+ - Security group name |
                                    1...N  | - Security material   |
                                           |                       |
                                           +-----------------------+

 .------------------------------.   .-----------------------------.
|                                | |                               |
|       +---------------------+  | |  +---------------------+      |
|       | Application Group 1 |  | |  | Application Group 3 | Cli2 |
|       |                     |  | |  |                     |      |
| Cli1  | Srv1   Srv2   Srv3  |  | |  | Srv5   Srv6         | Cli4 |
|       | /resA  /resA  /resA |  | |  | /resC  /resC        |      |
| Cli2  +---------------------+  | |  | /resD  /resD        |      |
|                                | |  +---------------------+      |
| Cli3     Security Group 1      | |                               |
|                                | |        Security Group 2       |
|       +---------------------+  |  '-----------------------------'
|       | Application Group 2 |  |
|       |                     |  |
|       | Srv1   Srv4         |  |
|       | /resB  /resB        |  |
|       +---------------------+  |
 '------------------------------'

2.2. Group Configuration

The following defines how groups of different types are named, created, discovered, and maintained.¶

3.1. Request/Response Model

MIN_TOKEN_REUSE_TIME = (NON_LIFETIME + MAX_LATENCY +
                        MAX_SERVER_RESPONSE_DELAY)

3.2. Caching

CoAP endpoints that are members of a CoAP group MAY cache responses to a group request as defined in Section 5.6 of [RFC7252]. In particular, these same rules apply to determine the set of request options used as "Cache-Key".¶

Furthermore, building on what is defined in Section 8.2.1 of [RFC7252]:¶

• A client sending a GET or FETCH group request MAY update a cache with the responses from the servers in the CoAP group. Then, the client uses both cached-still-fresh and new responses as the result of the group request.¶

• A client sending a GET or FETCH group request MAY use a response received from a server, to satisfy a subsequent sent request intended to that server on the related unicast request URI. In particular, the unicast request URI is obtained by replacing the authority component of the request URI with the transport-layer source address of the cached response message.¶

• A client MAY revalidate a cached response by making a GET or FETCH request on the related unicast request URI.¶

Note that, in the presence of proxies, doing any of the above (optional) unicast requests requires the client to distinguish the different responses to a group request, as well as to distinguish the different origin servers that responded. This in turn requires additional means to provide the client with information about the origin server of each response, e.g., using the forward-proxying method defines in [I-D.ietf-core-groupcomm-proxy].¶

The following subsections define the freshness model and validation model to use for cached responses, which update the models defined in Sections 5.6.1 and 5.6.2 of [RFC7252], respectively.¶

3.3. URI Path Selection

The URI Path used in a group request is preferably a path that is known to be supported across all members of a CoAP group. However, there are valid use cases where a group request is known to be successful only for a subset of the CoAP group. For instance, the subset may include only members of a specific application group, while the members of the CoAP group for which the request is unsuccessful (for example because they are outside the target application group) either suppress a response as per the default behavior from Section 3.1.2, or reply with an error response, e.g., when the default behavior is overridden by a No-Response Option [RFC7967] included in the group request.¶

3.4. Port Selection for UDP Transport

A server that is a member of a CoAP group listens for CoAP request messages on the group's IP multicast address, usually on the CoAP default UDP port number 5683, or another non-default UDP port number 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 CoAP group and across all CoAP clients sending group requests to that group.¶

One way to create multiple CoAP groups is using different UDP ports with the same IP multicast address, in case the devices' network stack only supports a limited number of multicast address subscriptions. 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. Also, a constrained network may be additionally burdened in this case with multicast traffic that is eventually discarded at the UDP layer by most nodes.¶

The port number 5684 is reserved for DTLS-secured unicast 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 number 5683 MUST be supported (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" CoAP group as detailed in Section 3.9.¶

3.5. Proxy Operation

This section defines how proxies operate in a group communication scenario. In particular, Section 3.5.1 defines operations of forward-proxies, while Section 3.5.2 defines operations of reverse-proxies. Furthermore, Section 3.5.3 discusses the case where a client sends a group request to multiple proxies at once. Security operations for a proxy are discussed later in Section 5.3.¶

3.6. Congestion Control

CoAP group requests may result in a multitude of responses from different nodes, potentially causing congestion. Therefore, both the sending of CoAP group requests and the sending of the unicast CoAP responses to these group requests should be conservatively controlled.¶

CoAP [RFC7252] reduces IP multicast-specific congestion risks through the following measures:¶

• A server may choose not to respond to an IP multicast request if there is nothing useful to respond to, e.g., error or empty response (see Section 8.2 of [RFC7252]).¶

• A server should limit the support for IP multicast requests to specific resources where multicast operation is required (Section 11.3 of [RFC7252]).¶

• An IP multicast request MUST be Non-confirmable (Section 8.1 of [RFC7252]).¶

• The same rationale for enforcing congestion control based on the transmission parameter PROBING_RATE defined in Section 4.7 of [RFC7252] holds for CoAP group communication. In particular, group requests are the Non-confirmable requests in question, and an average data rate PROBING_RATE is not to be exceeded by a client that does not receive a response from any server in the targeted CoAP group.¶

• A response to an IP multicast request SHOULD be Non-confirmable (Section 5.2.3 of [RFC7252]).¶

• A server does not respond immediately to an IP multicast request and should first wait for a time that is randomly picked within a predetermined time interval called the Leisure (Section 8.2 of [RFC7252]).¶

This document also defines these measures to be applicable to alternative transports (other than IP multicast), if not defined otherwise.¶

Independently of the used transport, additional guidelines to reduce congestion risks defined in this document are as follows:¶

• A server in a constrained network SHOULD only support group requests for resources that have a small representation (where the representation may be retrieved via a GET, FETCH, or POST method in the request). For example, "small" can be defined as a response payload limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size, so that it fits into a single link-layer frame in case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, see Section 3.9.2) is used on the constrained network.¶

• A server SHOULD minimize the payload size of a response to a group GET or FETCH request on "/.well-known/core" by using hierarchy in arranging link descriptions for the response. An example of this is given in Section 5 of [RFC6690].¶

• A server MAY minimize the payload size of a response to a group GET or FETCH request (e.g., on "/.well-known/core") by using CoAP block-wise transfers [RFC7959] in case the payload is long, returning only a first block of the CoRE Link Format description. For this reason, a CoAP client sending a CoAP group request to "/.well-known/core" SHOULD support block-wise transfers. See also Section 3.8.¶

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

3.7. Observing Resources

The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, which allows a CoAP client to retrieve a representation of a resource and automatically keep this representation up-to-date over a longer period of time. The client gets notified when the representation has changed. [RFC7641] does not mention whether the Observe Option can be combined with CoAP (multicast) group communication.¶

This section updates [RFC7641] with the use of the Observe Option in a CoAP GET group request, and defines normative behavior for both client and server. Consistent with Section 2.4 of [RFC8132], the same rules apply when using the Observe Option in a CoAP FETCH group request.¶

Multicast Observe is a useful way to start observing a particular resource on all members of a CoAP group at the same time. If a group member does not have this particular resource or it does not allow the GET or FETCH method on that resource, then the group member will either suppress a response as per the default behavior from Section 3.1.2, or reply with an error response -- 4.04 (Not Found) or 4.05 (Method Not Allowed), respectively -- e.g., when the default behavior is overridden by a No-Response Option [RFC7967] included in the group request.¶

A client that sends a group GET or FETCH request with the Observe Option MAY repeat this request using the same Token value and the same Observe Option value, in order to ensure that enough (or all) members of the CoAP group have been reached with the request. This is useful in case a number of members of the CoAP group did not respond to the initial request. The client MAY additionally use the same Message ID in the repeated request, to avoid that members of the CoAP group that had already received the initial request would respond again. Note that using the same Message ID in a repeated request will not be helpful in case of loss of a response message, since the server that responded already will consider the repeated request as a duplicate message. On the other hand, if the client uses a different, fresh Message ID in the repeated request, then all the members of the CoAP group that receive this new message will typically respond again, which increases the network load.¶

A client that has sent a group GET or FETCH request with the Observe Option MAY follow up by sending a new unicast CON request with the same Token value and same Observe Option value to a particular server, in order to ensure that the particular server receives the request. This is useful in case a specific member of the CoAP group did not respond to the initial group request, although it was expected to. In this case, the client MUST use a Message ID that differs from that of the initial group request message.¶

Since the first Observe notification from a server can be lost, a client should be ready to start receiving the Observe notifications from a server long after the Non-confirmable group request with the Observe Option was sent.¶

At the same time, the loss of initial responses with the Observe Option from a server is less problematic than in the case where the group request is a regular request, i.e., when the request does not include the Observe Option. That is, as per Section 4.5 of [RFC7641], servers that have registered a client as an observer have to ensure that the client achieves eventual consistency with respect to the representation of the observed resource. This realistically relies on the sending of new Observe notifications, which are occasionally expected to be sent as Confirmable messages also in order to assess client aliveness (see below).¶

Furthermore, consistent with Section 3.3.1 of [RFC7641] and following its guidelines, a client MAY at any time send a new group/multicast GET or FETCH request with the same Token value and same Observe Option value as the original request. This allows the client to verify that it has an up-to-date representation of an observed resource and/or to re-register its interest to observe a resource.¶

In the above client behaviors, the Token value is kept identical to the initial request to avoid that a client is included in more than one entry in the list of observers (Section 4.1 of [RFC7641]).¶

Before repeating a request as specified above, the client SHOULD wait for at least the expected round-trip time plus the Leisure time period defined in Section 8.2 of [RFC7252], to give the server time to respond.¶

A server that receives a GET or FETCH request with the Observe Option, for which request processing is successful, SHOULD respond to this request and not suppress the response. If a server adds a client (as a new entry) to the list of observers for a resource due to an Observe request, the server SHOULD respond to this request and SHOULD NOT suppress the response. An exception to the above is the overriding of response suppression according to a CoAP No-Response Option [RFC7967] specified by the client in the GET or FETCH request (see Section 3.1.2).¶

A server SHOULD have a mechanism to verify the aliveness of its observing clients and the continued interest of these clients in receiving the Observe notifications. This can be implemented by sending notifications occasionally using a Confirmable message (see Section 4.5 of [RFC7641] for details). This requirement overrides the regular behavior of sending Non-confirmable notifications in response to a Non-confirmable request.¶

A client can use the unicast cancellation methods of Section 3.6 of [RFC7641] and stop the ongoing observation of a particular resource on members of a CoAP group. This can be used to remove specific observed servers, or even all servers in the CoAP group (using serial unicast to each known group member). In addition, a client MAY explicitly deregister from all those servers at once, by sending a group/multicast GET or FETCH request that includes the Token value of the observation to be canceled and includes an Observe Option with the value set to 1 (deregister). In case not all the servers in the CoAP group received this deregistration request, either the unicast cancellation methods can be used at a later point in time or the group/multicast deregistration request MAY be repeated upon receiving another observe response from a server.¶

For observing at servers that are members of a CoAP group through a CoAP-to-CoAP proxy, the limitations stated in Section 3.5 apply. The method defined in [I-D.ietf-core-groupcomm-proxy] enables group communication including resource observation through proxies and addresses those limitations.¶

3.8. Block-Wise Transfer

Section 2.8 of [RFC7959] specifies how a client can use block-wise transfer (Block2 Option) in a multicast GET request to limit the size of the initial response of each server. Consistent with Section 2.5 of [RFC8132], the same can be done with a multicast FETCH request.¶

To retrieve any further blocks of the resource from responding servers, the client can rely on two possible approaches.¶

1. The client uses unicast requests, separately addressing each different server.¶

2. The client uses follow-up group requests, if all the received responses from different servers specify the same block size SIZE in their Block2 Option. In particular, SIZE can have the same value specified in the Block2 Option of the first group request, or instead a different one. If the client relies on this approach, follow-up group requests MUST specify SIZE in their Block2 Option.¶

Furthermore, a server (member of a targeted CoAP group) that needs to respond to a group request with a particularly large resource can use block-wise transfer (Block2 Option) at its own initiative, to limit the size of the initial response. A client can rely on either of the two approaches above for any further requests to retrieve more blocks of the resource.¶

A solution for group/multicast block-wise transfer using the Block1 Option is not specified in [RFC7959] nor in the present document. Such a solution would be useful for group FETCH/PUT/POST/PATCH/iPATCH requests, to efficiently distribute a large request payload as multiple blocks to all members of a CoAP group. Multicast usage of Block1 is non-trivial due to potential message loss (leading to missing blocks or missing confirmations), and potential diverging block size preferences of different members of the CoAP group.¶

[RFC9177] specifies a specialized alternative method for CoAP block-wise transfer. It specifies that "servers MUST ignore multicast requests that contain the Q-Block2 Option".¶

3.9. Transport Protocols

In this document UDP, both over IPv4 and IPv6, is considered as the default transport protocol for CoAP group communication.¶

3.10. Interworking with Other Protocols

5.1. Group OSCORE

The application-layer protocol Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] provides end-to-end encryption, integrity, and replay protection of CoAP messages exchanged between two CoAP endpoints. These can act both as CoAP Client as well as CoAP Server, and share an OSCORE Security Context used to protect and verify exchanged messages. The use of OSCORE does not affect the URI scheme and OSCORE can therefore be used with any URI scheme defined for CoAP.¶

OSCORE uses COSE [RFC9052][RFC9053] to perform encryption operations and protect a CoAP message carried 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.¶

OSCORE makes it possible to selectively protect different parts of a CoAP message in different ways, while still allowing intermediaries (e.g., CoAP proxies) to perform their intended functionalities. That is, some message parts are encrypted and integrity protected; other parts are only integrity protected to be accessible to, but not modifiable by, proxies; and some parts are kept as plain content to be both accessible to and modifiable by proxies. Such differences especially concern the CoAP options included in the unprotected message.¶

Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and provides end-to-end security of CoAP messages exchanged between members of an OSCORE group, while fulfilling the same security requirements.¶

In particular, Group OSCORE protects CoAP group requests sent by a CoAP client, e.g., over UDP/IP multicast, as well as multiple corresponding CoAP responses sent as (IP) unicast by different CoAP servers. However, the same security material can also be used to protect CoAP requests sent over (IP) unicast to a single CoAP server in the OSCORE group, as well as the corresponding responses.¶

Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group. That is, the recipient of a CoAP message protected with Group OSCORE is able to securely verify whether the CoAP endpoint that has generated and sent the message is indeed the alleged one. This is achieved by means of two possible methods.¶

The first method, called group mode, relies on digital signatures. That is, sender devices sign their outgoing messages using their own private key, and embed the signature in the protected CoAP message.¶

The second method, called pairwise mode, relies on a symmetric key, which is derived from a pairwise shared secret computed from the asymmetric keys of the message sender and recipient. This method is intended for one-to-one messages sent in the security group, such as all responses individually sent by servers, as well as requests addressed to an individual server.¶

A Group Manager is responsible for managing one or multiple OSCORE groups. In particular, the Group Manager acts as repository of the security group members' authentication credentials including the corresponding public keys; manages, renews, and provides security material in the security group; and handles the join process of new members in the security group.¶

As defined in [I-D.ietf-ace-oscore-gm-admin], an administrator entity can interact with the Group Manager to create OSCORE groups and specify their configuration (see Section 2.2.2). During the lifetime of the OSCORE group, the administrator can further interact with the Group Manager, in order to possibly update the configuration of the security group and eventually delete the group.¶

As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint can join an OSCORE group by using the method described in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework for Authentication and Authorization in constrained environments [RFC9200].¶

A CoAP endpoint can discover OSCORE groups and retrieve information to join them through their respective Group Managers by using the method described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE Resource Directory [RFC9176].¶

If security is required, CoAP group communication as described in this specification MUST use Group OSCORE. In particular, a CoAP group as defined in Section 2.1 and using secure group communication is associated with an OSCORE security group, which includes:¶

• All members of the CoAP group, i.e., the CoAP endpoints that are configured to receive CoAP group messages sent to the particular CoAP group and -- in case of IP multicast transport -- that are listening to the group's multicast IP address on the group's UDP port.¶

• All further CoAP endpoints configured only as CoAP clients, that may send CoAP group requests to the CoAP group.¶

5.2. Secure Group Maintenance

As part of group maintenance operations (see Section 2.2.4), additional key management operations are required for an OSCORE group, also depending on the security requirements of the application (see Section 6.2.1). Specifically:¶

• Adding new members to a CoAP group or enabling new client-only endpoints to interact with that group require also that each of such members/endpoints join the corresponding OSCORE group. When this happens, they are securely provided with the security material to use in that OSCORE group.¶

  Applications may need backward security. That is, they may require that, after having joined an OSCORE group, a new member of that group cannot read the cleartext of messages exchanged in the group prior to its joining, even if it has recorded them.¶

  In such a case, new security material to use in the OSCORE group has first to be generated and distributed to the current members of that group, before new endpoints are also provided with that new security material upon their joining.¶

• Removing members from a CoAP group or stopping client-only endpoints from interacting with that group requires removing such members/endpoints from the corresponding OSCORE group. To this end, new security material is generated and securely distributed only to the remaining members of the OSCORE group, together with the list of former members removed from that group.¶

  This ensures forward security in the OSCORE group. That is, it ensures that only the members intended to remain in the OSCORE group are able to continue participating in the secure communications within that group, while the evicted ones are not able to participate after the distribution and installation of the new security material.¶

  Also, this ensures that the members intended to remain in the OSCORE group are able to confidently assert the group membership of other sender nodes, when receiving protected messages in the OSCORE group after the distribution and installation of the new security material (see Section 12.2 of [I-D.ietf-core-oscore-groupcomm]).¶

The key management operations mentioned above are entrusted to the Group Manager responsible for the OSCORE group [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform them as defined in [I-D.ietf-ace-key-groupcomm-oscore].¶

5.3. Proxy Security

Different solutions may be selected for secure group communication via a proxy depending on proxy type, use case and deployment requirements. In this section the options based on Group OSCORE are listed.¶

For a client performing a group communication request via a forward-proxy, end-to-end security should be implemented. The client then creates a group request protected with Group OSCORE and unicasts this to the proxy. The proxy adapts the request from a forward-proxy request to a regular request and multicasts this adapted request to the indicated CoAP group. During the adaptation, the security provided by Group OSCORE persists, in either case of using the group mode or using the pairwise mode. The first leg of communication from client to proxy can optionally be further protected, e.g., by using (D)TLS and/or OSCORE.¶

For a client performing a group communication request via a reverse-proxy, either end-to-end-security or hop-by-hop security can be implemented. The case of end-to-end security is the same as for the forward-proxy case.¶

The case of hop-by-hop security is only possible if the proxy can be completely trusted and it is configured as a member of the OSCORE security group(s) that it needs to access, when sending a group request on behalf of clients. As further clarified below, the first communication leg between the client and the proxy, on one hand, and the second communication leg between the proxy and the servers, on the other hand, are protected individually and independently from one another.¶

The first leg of communication between client and proxy is then protected with a security method for CoAP unicast, such as (D)TLS, OSCORE, or a combination of such methods. The second leg between proxy and servers is protected using Group OSCORE. This can be useful in applications where for example the origin client does not implement Group OSCORE, or the group management operations are confined to a particular network domain and the client is outside this domain.¶

For all the above cases, more details on using Group OSCORE are defined in [I-D.ietf-core-groupcomm-proxy].¶

6.1. CoAP NoSec Mode

CoAP group communication, if not protected, is vulnerable to all the attacks mentioned in Section 11 of [RFC7252] for IP multicast. Moreover, as also discussed in [I-D.irtf-t2trg-amplification-attacks], the NoSec mode is susceptible to source IP address spoofing, hence amplification attacks are especially feasible and greatly effective, since a single request can result in multiple responses from multiple servers (see Section 6.3).¶

Therefore, it is NOT RECOMMENDED to use CoAP group communication in NoSec mode, also in order to prevent proliferation of high-volume amplification attacks as further discussed in Section 6.3. The requirement in Section 4 on publically accessible CoAP servers also aims to prevent amplification attacks.¶

Exceptionally, and only after the security implications have been very well considered and understood, some applications may rely on a limited use of the NoSec mode, when performing specific, well-defined steps that are proven to not require security or to not be able to attain it.¶

For example, early link-local discovery of devices and resources as part of an onboarding protocol is a typical use case where the NoSec mode or equivalent unsecured mode is used. In such a discovery step, there may be a querying device that needs to discover nearby devices capable of helping it with the network onboarding process. But there are no mutual security relations configured on the querying device and its neighbor devices at the time it performs the early discovery. These relations are configured later in the process based on secure device identities. Alternatively, a new device to be onboarded may wait for advertisements of nearby devices able to help it do the network onboarding process. Also in this case, these messages cannot be secured initially because the new device does not yet have any security relation configured with devices that are already a member of the network. See [I-D.ietf-anima-constrained-voucher] for an example of an onboarding protocol that can use CoAP multicast for early link-local discovery.¶

As a further example, the NoSec mode may be useful in simple applications that neither involve nor may have an impact on sensitive data and personal information. These include, e.g., read-only temperature sensors deployed in an environment where a client reads temperature values but does not use this data to control actuators or to perform other automated actions.¶

In the exception cases where NoSec mode is used, high-volume and harmful amplifications need to be prevented through appropriate and conservative device configurations: taking the early discovery query as an example, only a few CoAP servers are expected to be configured for responding to multicast group requests that are sent for discovery. And the time window during which such unsecured requests are accepted, can be limited as well. Furthermore, the scope is also limited: only link-local requests are accepted.¶

Except for the class of applications discussed above, and all the more so in applications that obviously have hard security requirements (e.g., health monitoring systems and alarm monitoring systems), CoAP group communication MUST NOT be used in NoSec mode.¶

6.2. Group OSCORE

Group OSCORE provides end-to-end application-level security. This has many desirable properties, including maintaining security assurances while forwarding traffic through intermediaries (proxies). Application-level security also tends to more cleanly separate security from the specific dynamics of security group membership (e.g., the problem of distributing security keys across large groups with many members that come and go).¶

CoAP group communication MUST be protected by using Group OSCORE as specified in [I-D.ietf-core-oscore-groupcomm], with the possible exception of specific, well-defined steps that are proven to not require security or to not be able to attain it (e.g., early discovery).¶

The same security considerations from Section 13 of [I-D.ietf-core-oscore-groupcomm] hold for this specification.¶

6.3. Risk of Amplification

Section 11.3 of [RFC7252] highlights that CoAP group requests may be used for accidentally or deliberately performing Denial of Service attacks, especially in the form of a high-volume amplification attack, by using all the servers in the CoAP group as attack vectors.¶

That is, following a group request sent to a CoAP group, each of the servers in the group may reply with a response which is likely larger in size than the group request. Thus, an attacker sending a single group request may achieve a high amplification factor, i.e., a high ratio between the size of the group request and the total size of the corresponding responses intended to the attack victim.¶

Thus, consistently with Section 11.3 of [RFC7252], a server in a CoAP group:¶

• SHOULD limit the support for CoAP group requests only to the group resources of the application group(s) using that CoAP group;¶

• SHOULD NOT accept group requests that cannot be authenticated in some way, i.e., for which it is not possible to securely assert that they have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group;¶

• SHOULD NOT provide large amplification factors through its responses to a non-authenticated group request, possibly employing CoAP block-wise transfers [RFC7959] to reduce the amount of amplification.¶

Amplification attacks using CoAP are further discussed in [I-D.irtf-t2trg-amplification-attacks], which also highlights how the amplification factor would become even higher when CoAP group communication is combined with resource observation [RFC7641]. That is, a single group request may result in multiple notification responses from each of the responding servers, throughout the observation lifetime.¶

Thus, consistently with Section 7 of [RFC7641], a server in a CoAP group MUST strictly limit the number of notifications it sends between receiving acknowledgements that confirm the actual interest of the client in continuing the observation.¶

Moreover, it is especially easy to perform an amplification attack when the NoSec mode is used. Therefore, also in order to prevent an easy proliferation of high-volume amplification attacks, it is generally NOT RECOMMENDED to use CoAP group communication in NoSec mode (see Section 6.1).¶

Besides building on very well understood security implications and being limited to specific, well-defined steps that are proven to not require security or to not be able to attain it, possible exceptions should also be limited to use cases where accesses to a group resource have a specific, narrow, and well understood scope, and where only a few CoAP servers (or, ideally, only one) would possibly respond to a group request.¶

A relevant exceptional example is a CoAP client performing the discovery of hosts such as a group manager or a Resource Directory [RFC9176], by probing for them through a group request sent to the CoAP group. This early, unprotected step is relevant for a CoAP client that does not know the address of such hosts in advance, and that does not have yet configured a mutual security relation with them. In this kind of deployments, such a discovery procedure does not result in a considerable and harmful amplification, since only the few CoAP servers that are the object of discovery are going to respond to the group request targeting that specific resource. In particular, those hosts can be the only CoAP servers in that specific CoAP group (hence listening for group requests sent to that group), and/or the only CoAP servers explicitly configured to respond to group requests targeting specific group resources.¶

With the exception of such particular use cases, group communications MUST be secured using Group OSCORE [I-D.ietf-core-oscore-groupcomm], see Section 5. As discussed in Section 6.2.3, this limits the feasibility and impact of amplification attacks.¶

6.4. Replay of Non-Confirmable Messages

Since all requests sent over IP multicast are Non-confirmable, a client might not be able to know if an adversary has actually captured one of its transmitted requests and later re-injected it in the group as a replay to the server nodes. In fact, even if the servers sent back responses to the replayed request, the client would typically not have a valid matching request active anymore, so this attack would not accomplish anything in the client.¶

If Group OSCORE is used, such a replay attack on the servers is prevented, since a client protects each different request with a different Sequence Number value, which is in turn included as Partial IV in the protected message and takes part in the construction of the AEAD cipher nonce. Thus, a server would be able to detect the replayed request, by checking the conveyed Partial IV against its own replay window in the OSCORE Recipient Context associated with the client.¶

This requires a server to have a synchronized, up-to-date view of the sequence number used by the client. If such synchronization is lost, e.g., due to a reboot, or suspected so, the server should use the challenge-response synchronization method based on the Echo Option for CoAP defined in [RFC9175] as described in Section 10 of [I-D.ietf-core-oscore-groupcomm], in order to (re-)synchronize with the client's sequence number.¶

6.5. Use of CoAP No-Response Option

When CoAP group communication is used in CoAP NoSec (No Security) mode (see Section 4), the CoAP No-Response Option [RFC7967] could be misused by a malicious client to evoke as many responses from servers to a group request as possible, by using the value '0' -- Interested in all responses. This might even override the default behavior of a CoAP server to suppress the response in case there is nothing of interest to respond with. Therefore, this option can be used to perform an amplification attack (see Section 6.3).¶

A proposed mitigation is to only allow this option to relax the standard suppression rules for a resource in case the option is sent by an authenticated client. If sent by an unauthenticated client, the option can be used to expand the classes of responses suppressed compared to the default rules but not to reduce the classes of responses suppressed.¶

6.6. 6LoWPAN and MPL

In a 6LoWPAN network, the MPL [RFC7731] protocol may be used to forward multicast packets throughout the network. A 6LoWPAN Router that forwards a large IPv6 packet may have a relatively high impact on the occupation of the wireless channel because sending a large packet consists of the transmission of multiple link-layer IEEE 802.15.4 frames. Also, a constrained 6LoWPAN Router may experience a high memory load due to buffering of the large packet -- MPL requires an MPL Forwarder to store the packet for a longer duration, to allow multiple forwarding transmissions to neighboring Forwarders. This could allow an attacker on the 6LoWPAN network or outside the 6LoWPAN network to execute a Denial of Service (DoS) attack by sending large IPv6 multicast packets. This is also an amplification attack in general, because each of potentially multiple MPL Forwarder(s) repeats the transmission of the IPv6 packet potentially multiple times, hence amplifying the original amount of data sent by the attacker considerably.¶

The amplification factor may be even further increased by the loss of link-layer frames. If one or more of the fragments are not received correctly by an MPL Forwarder during its packet reassembly time window, the Forwarder discards all received fragments and it will likely at a future point in time trigger a neighboring MPL Forwarder to send the IPv6 packet (fragments) again, because its internal state marks this packet (that it failed to received previously) still as a "new" IPv6 packet. Hence, this leads to an MPL Forwarder signaling to neighbors its "old" state, triggering additional transmission(s) of all packet fragments.¶

For these reasons, a large IPv6 multicast packet is a possible attack vector in a Denial of Service (DoS) amplification attack on a 6LoWPAN network. See Section 6.3 of this document and Section 11.3 of [RFC7252] for more details on amplification. To mitigate the risk, applications sending multicast IPv6 requests to 6LoWPAN hosted CoAP servers SHOULD limit the size of the request to avoid 6LoWPAN fragmentation of the request packet. A 6LoWPAN Router or (MPL) multicast forwarder SHOULD deprioritize forwarding for multi-fragment 6LoWPAN multicast packets. 6LoWPAN Border Routers are typical ingress points where multicast traffic enters into a 6LoWPAN network. Specific MPL Forwarders (whether located on a 6LBR or not) may also be configured as ingress points. Any such ingress point SHOULD implement multicast packet filtering to prevent unwanted multicast traffic from entering a 6LoWPAN network from the outside. For example, it could filter out all multicast packets for which there is no known multicast listener on the 6LoWPAN network. See Section 3.10 for protocols that allow multicast listeners to signal which groups they would like to listen to. As part of multicast packet filtering, the ingress point SHOULD implement a filtering criterion based on the size of the multicast packet. Ingress multicast packets above a defined size may then be dropped or deprioritized.¶

6.7. Wi-Fi

In a home automation scenario using Wi-Fi, Wi-Fi security should be enabled to prevent rogue nodes from joining. The Customer Premises Equipment (CPE) that enables access to the Internet should also have its IP multicast filters set so that it enforces multicast scope boundaries to isolate local multicast groups from the rest of the Internet (e.g., as per [RFC6092]). In addition, the scope of IP multicast transmissions and listeners should be site-local (5) or smaller. For site-local scope, the CPE will be an appropriate multicast scope boundary point.¶

6.8. Monitoring

A.1. Discovery

Discovery of physical devices in a network, or discovery of information entities hosted on network devices, are operations that are usually required in a system during the phases of setup or (re)configuration. When a discovery use case involves devices that need to interact without having been configured previously with a common security context, unsecured CoAP communication is typically used. Discovery may involve a request to a directory server, which provides services to aid clients in the discovery process. One particular type of directory server is the CoRE Resource Directory [RFC9176]; and there may be other types of directories that can be used with CoAP.¶

A.2. Operational Phase

Operational phase use cases describe those operations that occur most frequently in a networked system, during its operational lifetime and regular operation. Regular usage is when the applications on networked devices perform the tasks they were designed for and exchange of application-related data using group communication occurs. Processes like system reconfiguration, group changes, system/device setup, extra group security changes, etc. are not part of regular operation.¶

A.3. Software Update

Group communication can be useful to efficiently distribute new software (firmware, image, application, etc.) to a set of multiple devices, e.g., by relying on the SUIT firmware update architecture [RFC9019] and its manifest information model [RFC9124]. In this case, a CoAP group can be defined in terms of the device type of its members: all devices in the target CoAP group are known to be capable of installing and running the new software. The software is distributed as a series of smaller blocks that are collected by all devices and stored in memory. All devices in the target CoAP group are usually responsible for integrity verification of the received software; which can be done per-block or for the entire software image once all blocks have been received. Due to the inherent unreliability of CoAP multicast, there needs to be a backup mechanism (e.g., implemented using CoAP unicast) by which a device can individually request missing blocks of a whole software image/entity. Prior to a multicast software update, the CoAP group of recipients can be separately notified that there is new software available and coming, using the above network-wide or group notification.¶

B.1. Group Naming using the URI Path Component

Figure 3 provides an example where the URI path component is used for naming application groups.¶

   Application group name: gp1

   Group URI: coap://grp.example:5685/gp/gp1/light?foo=bar

   CoAP group request
      Header: GET (T=NON, Code=0.01, MID=0x7d41)
      Uri-Host: "grp.example"
      Uri-Path: "gp"
      Uri-Path: "gp1"
      Uri-Path: "light"
      Uri-Query: "foo=bar"

Figure 4 provides a different example, where an IPv6 literal address and the default CoAP port number 5683 are used in the authority component, which yields a compact CoAP request. Also, the resource structure is different in this example.¶

   Application group name: gp1

   Group URI: coap://[ff35:30:2001:db8:f1::8000:1]/g/gp1/li

   CoAP group request
      Header: POST (T=NON, Code=0.02, MID=0x7d41)
      Uri-Path: "g"
      Uri-Path: "gp1"
      Uri-Path: "li"

B.2. Group Naming using the URI Query Component

Figure 5 provides an example where the URI query component is used for naming application groups. In particular, it considers the first alternative discussed in Section 2.2.1.2, where the URI query component consists of only one parameter, which has no value and has the name of the application group as its own identifier.¶

   Application group name: gp1

   Group URI: coap://grp.example:5685/light?gp1

   CoAP group request
      Header: GET (T=NON, Code=0.01, MID=0x7d41)
      Uri-Host: "grp.example"
      Uri-Path: "light"
      Uri-Query: "gp1"

Figure 6 provides another example, which considers the second alternative discussed in Section 2.2.1.2. In particular, the URI query component includes a query parameter "gp" as designated indicator, with value the name of the application group.¶

   Application group name: gp1

   Group URI: coap://grp.example:5685/light?foo=bar&gp=gp1

   CoAP group request
      Header: GET (T=NON, Code=0.01, MID=0x7d41)
      Uri-Host: "grp.example"
      Uri-Path: "light"
      Uri-Query: "foo=bar"
      Uri-Query: "gp=gp1"

B.3. Group Naming using the URI Authority Component

Figure 7 provides an example where the URI authority component as a whole is used for encoding the name of the application group. Note that, although the port information (5685) is not carried as a CoAP Option, it is still transported within the UDP message (in the UDP destination port field). So, effectively, the application group name is transported in the UDP message as two parts.¶

   Application group name: grp.example:5685

   Group URI: coap://grp.example:5685/light?foo=bar

   CoAP group request
      Header: GET (T=NON, Code=0.01, MID=0x7d41)
      Uri-Host: "grp.example"
      Uri-Path: "light"
      Uri-Query: "foo=bar"

Figure 8 provides an example where the URI host subcomponent of the URI authority component is used for encoding the name of the application group. Specifically, the first label of the DNS name is used.¶

   Application group name: grp42

   Group URI: coap://grp42.example:5685/light?foo=bar

   CoAP group request
      Header: GET (T=NON, Code=0.01, MID=0x7d41)
      Uri-Host: "grp42.example"
      Uri-Path: "light"
      Uri-Query: "foo=bar"

Figure 9 provides an example where the URI port subcomponent of the URI authority component is used for naming application groups. It uses a UDP port from the dynamic port range. Multiple application groups could be defined this way, each represented by a number and associated port in the dynamic port range.¶

   Application group name: 55685

   Group URI: coap://grp.example:55685/light?foo=bar

   CoAP group request
      Header: GET(T=NON, Code=0.01, MID=0x7d41)
      Uri-Host: "grp.example"
      Uri-Path: "light"
      Uri-Query: "foo=bar"

C.1. Application Groups Associated with a CoAP Group

Figure 10 provides an example where a CoAP client discovers all the application groups associated with a specific CoAP group.¶

As a result, the client gains knowledge of: i) the set of servers that are members of the specified CoAP group and member of any of the associated application groups; ii) for each of those servers, the name of the application groups where the server is a member and that are associated with the CoAP group.¶

Each of the servers S1 and S2 is identified by the IP source address of the CoAP response. If the client wishes to discover resources that a particular server hosts within a particular application group, it may use unicast discovery request(s) to this server, i.e., to its respective unicast IP address. Alternatively the client may use the discovered group resource type (e.g., rt=g.light) to infer which resources are present below the group resource.¶

The semantics "g.<GROUPTYPE>" for the values of the attribute "rt" is exclusively intended to support examples in this document. To be effectively usable, such Resource Type values have to be registered in the "Resource Type (rt=) Link Target Attribute Values" IANA registry [Resource.Type.Link.Target.Attribute.Values] within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

   // Request to all members of the CoAP group
   Req: GET coap://grp.example:5685/.well-known/core?rt=g.*

   // Response from server S1, as member of:
   //   - The CoAP group "grp.example:5685"
   //   - The application group "gp1"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   </gp/gp1>;rt=g.light

   // Response from server S2, as member of:
   // - The CoAP group "grp.example:5685"
   // - The application groups "gp1" and "gp2"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   </gp/gp1>;rt=g.light,
   </gp/gp2>;rt=g.temp

C.2. Members of a Given Application Group

Figure 11 provides an example where a CoAP client discovers the CoAP servers that are members of a specific application group and the CoAP group associated with the application group.¶

Note that, unlike in the example shown in Appendix C.1, now the servers need to respond with an absolute URI and not a relative URI. This is necessary because the responding CoAP endpoint serving the Link Format document (on port 5683) is a different CoAP endpoint from the one hosting the group resource "gp1" (on port 5685). Due to this situation, the responding server includes the full (absolute) URI in the Link Format response from which the client can conveniently gain knowledge of the CoAP group.¶

Also note that a server could equally well respond with the literal IPv6 multicast address within square brackets instead of the CoAP group name "grp.example". In that case, the client would still gain knowledge of the CoAP group, albeit in a different representation.¶

   // Request to realm-local members of the application group "gp1"
   Req: GET coap://[ff03::fd]/.well-known/core?href=/gp/gp1

   // CoAP response from server S1, as member of:
   //   - The CoAP group "grp.example:5685"
   //   - The application group "gp1"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=g.light

   // CoAP response from server S2, as member of:
   // - The CoAP group "grp.example:5685"
   // - The application groups "gp1"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=g.light

C.3. Members of any Application Group of a Given Type

Figure 12 provides an example where a CoAP client discovers the CoAP servers that are members of any application group of a specific type, and the CoAP group associated with those application groups.¶

   // Request to realm-local members of application groups
   // with group type "g.temp"
   Req: GET coap://[ff03::fd]/.well-known/core?rt=g.temp

   // Response from server S1, as member of:
   //   - The CoAP group "grp.example:5685"
   //   - The application group "gp1" of type "g.temp"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=g.temp

   // Response from server S2, as member of:
   //   - The CoAP group "grp.example:5685"
   //   - The application groups "gp1" and "gp2" of type "g.temp"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=g.temp,
   <coap://grp.example:5685/gp/gp2>;rt=g.temp

C.4. Members of any Application Group in the Network

Figure 13 provides an example where a CoAP client discovers the CoAP servers that are members of any application group configured in the 6LoWPAN wireless mesh network of the client, and the CoAP group associated with each application group. In this example, the scope is realm-local to address all servers in the current 6LoWPAN wireless mesh network of the client.¶

The semantics "g.<GROUPTYPE>" for the values of the attribute "rt" is exclusively intended to support examples in this document. To be effectively usable, such Resource Type values have to be registered in the "Resource Type (rt=) Link Target Attribute Values" IANA registry [Resource.Type.Link.Target.Attribute.Values] within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

   // Request to realm-local members of any application group
   Req: GET coap://[ff03::fd]/.well-known/core?rt=g.*

   // Response from server S1, as member of:
   //   - The CoAP groups "grp.example:5685" and "grp2.example"
   //   - The application groups "gp1" and "gp5"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=g.light,
   <coap://grp2.example/gp/gp5>;rt=g.lock

   // Response from server S2, as member of:
   //   - The CoAP group "grp.example:5685"
   //   - The application groups "gp1" and "gp2"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=g.light,
   <coap://grp.example:5685/gp/gp2>;rt=g.light

   // Response from server S3, as member of:
   //   - The CoAP group "grp2.example"
   //   - The application group "gp5"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp2.example/gp/gp5>;rt=g.lock

Alternatively, some applications may use the "rt" attribute on a parent resource to denote support for a particular REST API to access child resources.¶

For instance, Figure 14 provides a different example where a custom Link Format attribute "gpt" is used to denote the group type within the scope of the application/system. An alternative, shorter encoding (not shown in the figure) is to use only the value "1" for each "gpt" attribute, in order to denote that the resource is of type application group. In that case, information about the semantics/API of the group resource is disclosed only via the "rt" attribute as shown in the figure.¶

   // Request to realm-local members of any application group
   Req: GET coap://[ff03::fd]/.well-known/core?gpt=*

   // Response from server S1, as member of:
   //   - The CoAP groups "grp.example:5685" and "grp2.example"
   //   - The application groups "gp1" and "gp5"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=oic.d.light;gpt=light,
   <coap://grp2.example/gp/gp5>;rt=oic.d.smartlock;gpt=lock

   // Response from server S2, as member of:
   //   - The CoAP group "grp.example:5685"
   //   - The application groups "gp1" and "gp2"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp.example:5685/gp/gp1>;rt=oic.d.light;gpt=light,
   <coap://grp.example:5685/gp/gp2>;rt=oic.d.light;gpt=light

   // Response from server S3, as member of:
   //   - The CoAP group "grp2.example"
   //   - The application group "gp5"
   Res: 2.05 (Content)
   Content-Format: 40 (application/link-format)
   Payload:
   <coap://grp2.example/gp/gp5>;rt=oic.d.smartlock;gpt=lock

G.1. Version -11 to -12

• Clarified how a group name can be included in a URI path for reverse proxies; removed reference to URI templates for reverse proxies.¶

• Clarified the issue of identical ETags from multiple servers and added strategies to cope with this. Removed recommendation to not use such duplicate ETags.¶

• Simplified section on application group naming using URI authority and corresponding appendix examples; declaring new Option solution out of scope.¶

• Added application group resource URI path(s) in Figure 1.¶

• Clarified outcome of the RFC 7390 experiment on group membership configuration protocol.¶

• Clarified that rt=g.<GROUPTYPE> is used just as an example.¶

• Made RFC 7967 a normative reference.¶

• Generalized resending of a group request with different Message ID.¶

• Switched SHOULD to MAY on changing port number from group request to response.¶

• Further generalized the handling of multiple responses from the same server to the same request.¶

• Clarifications on response suppression.¶

• Issues and limitations with Forward-Proxies compiled in an appendix.¶

• Issues and limitations with Reverse-Proxies compiled in an appendix.¶

• Mentioned PROBING_RATE as a means to enforce congestion control.¶

• Consideration on how eventual consistency from Observe compensates for lost notifications.¶

• Admitted resource retrieval through consecutive group requests with the Block2 Option.¶

• Clarified relation with TCP/TLS/WebSockets.¶

• Clarified security on the different legs with a proxy.¶

• Editorial improvements.¶

G.2. Version -10 to -11

• Updated references.¶

• Editorial improvements.¶

G.3. Version -09 to -10

• Clarified use of NoSec for 'early discovery' and refer to cBRSKI.¶

• Clarified mandatory vs optional elements in CoAP group and CoAP group URI.¶

• Replaced "GROUPNAME" with "APPNAME".¶

• Explicitly mentioning of the type of group (CoAP/application/security).¶

• Use of .example for example hostnames.¶

• The name of a security group is not necessarily a string.¶

• Changed "has to" to "should" for enforcing access control based on membership to security groups.¶

• Used normative language for policies about group rekeying.¶

• Further stressed that group communication ought to be secured.¶

• Avoid calling applications as "(non-)sensitive" and "(non-)critical".¶

• Clarification on source authentication, source addresses, and Echo Option.¶

• Editorial fixes and improvements.¶

G.4. Version -08 to -09

• Multiple responses in long exchanges are non-traditional responses.¶

• Updated references.¶

G.5. Version -07 to -08

• Updated references.¶

G.6. Version -06 to -07

• Updated list of changes to other documents.¶

• Added real-life context and clarifications to examples.¶

• Clarified aliasing of CoAP group names.¶

• Clarified use of security group names.¶

• Clarified response suppression.¶

• Clarified response revalidation.¶

• Clarified limitations and peculiarities when using proxies.¶

• Discussed the case of group request sent to multiple proxies at once.¶

• Discussed limited use of reliable transports with block-wise transfer.¶

• Revised text on joining CoAP groups and multicast routing.¶

• Clarified use/avoidance of the CoAP NoSec mode.¶

• Moved examples of application group naming and group discovery to appendix sections.¶

• Revised list of references.¶

• Updated list of implementations supporting group communication.¶

• Editorial improvements.¶

G.7. Version -05 to -06

• Harmonized use of "group URI".¶

• Clarifications about different group types.¶

• Revised methods to perform group naming.¶

• Revised methods to discover application groups and CoAP groups.¶

• Explicit difference between "authentication credential" and "public key".¶

• Added examples of application group naming.¶

• Added examples of application/CoAP group discovery.¶

• Added examples of message exchanges.¶

• Reference to draft-mattsson-core-coap-attacks replaced with reference to draft-mattsson-t2trg-amplification-attacks.¶

• Editorial improvements.¶

G.8. Version -04 to -05

• Clarified changes to other documents.¶

• Clarified relation between different group types.¶

• Clarified discovery of application groups.¶

• Discussed methods to express application group names in requests.¶

• Revised and extended text on the NoSec mode and amplification attacks.¶

• Rephrased backward/forward security as properties.¶

• Removed appendix on Multi-ETag Option for response revalidation.¶

• Editorial improvements.¶

G.9. Version -03 to -04

• Multi-ETag Option for response revalidation moved to appendix.¶

• ETag Option usage added.¶

• Q-Block Options added in the block-wise transfer section.¶

• Caching at proxies moved to draft-tiloca-core-groupcomm-proxy.¶

• Client-Proxy response revalidation with the Group-ETag Option moved to draft-tiloca-core-groupcomm-proxy.¶

• Security considerations on amplification attacks.¶

• Generalized transport protocols to include others than UDP/IP multicast; and security protocols other than Group OSCORE.¶

• Overview of security cases with proxies.¶

• Editorial improvements.¶

G.10. Version -02 to -03

• Multiple responses from same server handled at the application.¶

• Clarifications about issues with forward-proxies.¶

• Operations for reverse-proxies.¶

• Caching of responses at proxies.¶

• Client-Server response revalidation, with Multi-ETag Option.¶

• Client-Proxy response revalidation, with the Group-ETag Option.¶

G.11. Version -01 to -02

• Clarified relation between security groups and application groups.¶

• Considered also FETCH for requests over IP multicast.¶

• More details on Observe re-registration.¶

• More details on Proxy intermediaries.¶

• More details on servers changing port number in the response.¶

• Usage of the Uri-Host Option to indicate an application group.¶

• Response suppression based on classes of error codes.¶

G.12. Version -00 to -01

• Clarifications on group memberships for the different group types.¶

• Simplified description of Token reusage, compared to the unicast case.¶

• More details on the rationale for response suppression.¶

• Clarifications of creation and management of security groups.¶

• Clients more knowledgeable than proxies about stopping receiving responses.¶

• Cancellation of group observations.¶

• Clarification on multicast scope to use.¶

• Both the group mode and pairwise mode of Group OSCORE are considered.¶

• Updated security considerations.¶

• Editorial improvements.¶