idnits 2.17.1 draft-ietf-core-groupcomm-bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-12 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-01 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-10 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-37 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-02 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-26 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-03 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-08 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group E. Dijk 3 Internet-Draft IoTconsultancy.nl 4 Obsoletes: 7390 (if approved) C. Wang 5 Updates: 7252, 7641 (if approved) InterDigital 6 Intended status: Standards Track M. Tiloca 7 Expires: August 26, 2021 RISE AB 8 February 22, 2021 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-ietf-core-groupcomm-bis-03 13 Abstract 15 This document specifies the use of the Constrained Application 16 Protocol (CoAP) for group communication, using UDP/IP multicast as 17 the underlying data transport. Both unsecured and secured CoAP group 18 communication are specified. Security is achieved by use of the 19 Group Object Security for Constrained RESTful Environments (Group 20 OSCORE) protocol. The target application area of this specification 21 is any group communication use cases that involve resource- 22 constrained devices or networks. This document replaces RFC7390, 23 while it updates RFC7252 and RFC7641. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 26, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Group Definition and Group Configuration . . . . . . . . . . 5 63 2.1. Group Definition . . . . . . . . . . . . . . . . . . . . 5 64 2.1.1. CoAP Group . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.2. Application Group . . . . . . . . . . . . . . . . . . 6 66 2.1.3. Security Group . . . . . . . . . . . . . . . . . . . 6 67 2.1.4. Relations Between Group Types . . . . . . . . . . . . 6 68 2.2. Group Configuration . . . . . . . . . . . . . . . . . . . 9 69 2.2.1. Group Naming . . . . . . . . . . . . . . . . . . . . 9 70 2.2.2. Group Creation and Membership . . . . . . . . . . . . 10 71 2.2.3. Group Discovery . . . . . . . . . . . . . . . . . . . 11 72 2.2.4. Group Maintenance . . . . . . . . . . . . . . . . . . 12 73 3. CoAP Usage in Group Communication . . . . . . . . . . . . . . 13 74 3.1. Request/Response Model . . . . . . . . . . . . . . . . . 13 75 3.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 3.2.1. Freshness Model . . . . . . . . . . . . . . . . . . . 17 77 3.2.2. Validation Model . . . . . . . . . . . . . . . . . . 17 78 3.3. Port and URI Path Selection . . . . . . . . . . . . . . . 21 79 3.4. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 22 80 3.4.1. Forward-Proxies . . . . . . . . . . . . . . . . . . . 22 81 3.4.2. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 24 82 3.4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . 25 83 3.5. Congestion Control . . . . . . . . . . . . . . . . . . . 30 84 3.6. Observing Resources . . . . . . . . . . . . . . . . . . . 31 85 3.7. Block-Wise Transfer . . . . . . . . . . . . . . . . . . . 33 86 3.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 34 87 3.8.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 34 88 3.8.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 34 89 3.8.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 34 90 3.9. Interworking with Other Protocols . . . . . . . . . . . . 35 91 3.9.1. MLD/MLDv2/IGMP/IGMPv3 . . . . . . . . . . . . . . . . 35 92 3.9.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . . 36 93 3.9.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . . 36 94 4. Unsecured Group Communication . . . . . . . . . . . . . . . . 37 95 5. Secured Group Communication using Group OSCORE . . . . . . . 37 96 5.1. Secure Group Maintenance . . . . . . . . . . . . . . . . 39 97 5.2. Caching of Responses at Proxies . . . . . . . . . . . . . 40 98 5.2.1. Using Deterministic Requests to Achieve Cachability . 40 99 5.2.2. Validation of Responses . . . . . . . . . . . . . . . 41 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 41 101 6.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 41 102 6.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 42 103 6.2.1. Group Key Management . . . . . . . . . . . . . . . . 42 104 6.2.2. Source Authentication . . . . . . . . . . . . . . . . 43 105 6.2.3. Countering Attacks . . . . . . . . . . . . . . . . . 43 106 6.3. Replay of Non-Confirmable Messages . . . . . . . . . . . 45 107 6.4. Use of CoAP No-Response Option . . . . . . . . . . . . . 45 108 6.5. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 46 109 6.6. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 46 110 6.7. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 47 111 6.7.1. General Monitoring . . . . . . . . . . . . . . . . . 47 112 6.7.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 47 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 114 7.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 48 115 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 116 8.1. Normative References . . . . . . . . . . . . . . . . . . 48 117 8.2. Informative References . . . . . . . . . . . . . . . . . 51 118 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 53 119 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 53 120 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 53 121 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 54 122 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 54 123 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 55 124 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 55 125 A.2.2. Device Group Status Request . . . . . . . . . . . . . 55 126 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 55 127 A.2.4. Network-wide / Group Notification . . . . . . . . . . 56 128 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 56 129 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 56 130 B.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 56 131 B.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 57 132 B.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 57 133 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 136 1. Introduction 138 This document specifies group communication using the Constrained 139 Application Protocol (CoAP) [RFC7252] together with UDP/IP multicast. 140 CoAP is a RESTful communication protocol that is used in resource- 141 constrained nodes, and in resource-constrained networks where packet 142 sizes should be small. This area of use is summarized as Constrained 143 RESTful Environments (CoRE). 145 One-to-many group communication can be achieved in CoAP, by a client 146 using UDP/IP multicast data transport to send multicast CoAP request 147 messages. In response, each server in the addressed group sends a 148 response message back to the client over UDP/IP unicast. Notable 149 CoAP implementations supporting group communication include the 150 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 151 Foundation and the "Implementation of CoAP Server & Client in Go" 152 [Go-OCF] from the Open Connectivity Foundation (OCF). 154 Both unsecured and secured CoAP group communication over UDP/IP 155 multicast are specified in this document. Security is achieved by 156 using Group Object Security for Constrained RESTful Environments 157 (Group OSCORE) [I-D.ietf-core-oscore-groupcomm], which in turn builds 158 on Object Security for Constrained Restful Environments (OSCORE) 159 [RFC8613]. This method provides end-to-end application-layer 160 security protection of CoAP messages, by using CBOR Object Signing 161 and Encryption (COSE) 162 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 164 All guidelines in [RFC7390] are updated by this document, which 165 replaces and obsoletes [RFC7390]. Furthermore, this document updates 166 [RFC7252], by specifying: a group request/response model; cachability 167 of responses to group requests at proxies; a response validation 168 model for responses to group requests; and the use of Group OSCORE 169 [I-D.ietf-core-oscore-groupcomm] to achieve security for CoAP group 170 communication. Finally, this document also updates [RFC7641], by 171 defining the multicast usage of the CoAP Observe Option for both the 172 GET and FETCH methods. 174 All sections in the body of this document are normative, while 175 appendices are informative. For additional background about use 176 cases for CoAP group communication in resource-constrained devices 177 and networks, see Appendix A. 179 1.1. Scope 181 For group communication, only solutions that use CoAP over UDP/IP 182 multicast are in the scope of this document. There are alternative 183 methods to achieve group communication using CoAP, for example 184 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 185 broker server that CoAP clients access via unicast communication. 186 These methods may be usable for the same or similar use cases as are 187 targeted in this document. 189 Furthermore, this document defines Group OSCORE 190 [I-D.ietf-core-oscore-groupcomm] as the default group communication 191 security solution for CoAP. Security solutions for group 192 communication and configuration other than Group OSCORE are not in 193 scope. General principles for secure group configuration are in 194 scope. 196 1.2. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 This specification requires readers to be familiar with CoAP 205 terminology [RFC7252]. Terminology related to group communication is 206 defined in Section 2.1. 208 Furthermore, "Security material" refers to any security keys, 209 counters or parameters stored in a device that are required to 210 participate in secure group communication with other devices. 212 2. Group Definition and Group Configuration 214 In the following, different group types are first defined in 215 Section 2.1. Then, Group configuration, including group creation and 216 maintenance by an application, user or commissioning entity is 217 considered in Section 2.2. 219 2.1. Group Definition 221 Three types of groups and their mutual relations are defined in this 222 section: CoAP group, application group, and security group. 224 2.1.1. CoAP Group 226 A CoAP group is defined as a set of CoAP endpoints, where each 227 endpoint is configured to receive CoAP multicast messages that are 228 sent to the group's associated IP multicast address and UDP port. An 229 endpoint may be a member of multiple CoAP groups by subscribing to 230 multiple IP multicast groups and/or listening on multiple UDP ports. 231 Group membership(s) of an endpoint may dynamically change over time. 232 A device sending a CoAP multicast message to a CoAP group is not 233 necessarily itself a member of this CoAP group: it is a member only 234 if it also has a CoAP endpoint listening on the group's associated IP 235 multicast address and UDP port. A CoAP group can be encoded within a 236 Group URI. This is defined as a CoAP URI that has the "coap" scheme 237 and includes in the authority part either an IP multicast address or 238 a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN)) 239 that can be resolved to an IP multicast address. A Group URI also 240 contains an optional UDP port number in the authority part. Group 241 URIs follow the regular CoAP URI syntax (see Section 6 of [RFC7252]). 243 2.1.2. Application Group 245 Besides CoAP groups, that have relevance at the level of IP networks 246 and CoAP endpoints, there are also application groups. An 247 application group is a set of CoAP server endpoints that share a 248 common set of CoAP resources. An endpoint may be a member of 249 multiple application groups. An application group has relevance at 250 the application level - for example an application group could denote 251 all lights in an office room or all sensors in a hallway. A client 252 endpoint that sends a group communication message to an application 253 group is not necessarily itself a member of this application group. 254 There can be a one-to-one or a one-to-many relation between a CoAP 255 group and application group(s). An application group identifier is 256 optionally encoded explicitly in the CoAP request, for example as a 257 name in the URI path. If not explicitly encoded, the application 258 group is implicitly derived by the receiver, based on information in 259 the CoAP request. See Section 2.2.1 for more details on identifying 260 the application group. 262 2.1.3. Security Group 264 For secure group communication, a security group is required. A 265 security group is a group of endpoints that each store group security 266 material, such that they can mutually exchange secured messages and 267 verify secured messages. So, a client endpoint needs to be a member 268 of a security group in order to send a valid secured group 269 communication message to this group. An endpoint may be a member of 270 multiple security groups. There can be a one-to-one or a one-to-many 271 relation between security groups and CoAP groups. Also, there can be 272 a one-to-one or a one-to-many relation between security groups and 273 application groups. A special security group named "NoSec" 274 identifies group communication without any security at the transport 275 layer nor at the CoAP layer. 277 2.1.4. Relations Between Group Types 279 Using the above group type definitions, a CoAP group communication 280 message sent by an endpoint can be represented as a tuple that 281 contains one instance of each group type: 283 (application group, CoAP group, security group) 285 A special note is appropriate about the possible relation between 286 security groups and application groups. 288 On one hand, multiple application groups may use the same security 289 group. Thus, the same group security material is used to protect the 290 messages targeting any of those application groups. This has the 291 benefit that typically less storage, configuration and updating are 292 required for security material. In this case, a CoAP endpoint is 293 supposed to know the exact application group to refer to for each 294 message that is sent or received, based on, e.g., the used server 295 port number, the targeted resource, or the content and structure of 296 the message payload. 298 On the other hand, a single application group may use multiple 299 security groups. Thus, different messages targeting the resources of 300 the application group can be protected with different security 301 material. This can be convenient, for example, if the security 302 groups differ with respect to the cryptographic algorithms and 303 related parameters they use. In this case, a CoAP client can join 304 just one of the security groups, based on what it supports and 305 prefers, while a CoAP server in the application group would rather 306 have to join all of them. 308 Beyond this particular case, applications should be careful in 309 associating a same application group to multiple security groups. In 310 particular, it is NOT RECOMMENDED to use different security groups to 311 reflect different access policies for resources in a same application 312 group. That is, being a member of a security group actually grants 313 access only to exchange secured messages and enables authentication 314 of group members, while access control (authorization) to use 315 resources in the application group belongs to a separate security 316 domain. It has to be separately enforced by leveraging the resource 317 properties or through dedicated access control credentials assessed 318 by separate means. 320 Figure 1 summarizes the relations between the different types of 321 groups described above in UML class diagram notation. The class 322 attributes in square brackets are optionally defined. 324 +------------------------+ +--------------------+ 325 | Application group | | CoAP group | 326 |........................| |....................| 327 | | | | 328 | [ - group name ] +-----------------+ - IP mcast address | 329 | [ - group identifier ] | 1...N 1 | - UDP port | 330 | | | | 331 | | | | 332 +-------------+----------+ +---------+----------+ 333 | 1...N | 1...N 334 | | 335 | | 336 | | 1...N 337 | +----------+------------+ 338 | | Security group | 339 | |.......................| 340 | | | 341 \---------------------------+ - Security group name | 342 1...N | - Security material | 343 | | 344 +-----------------------+ 346 Figure 1: Relations Among Different Group Types 348 Figure 2 provides a deployment example of the relations between the 349 different types of groups. It shows six CoAP servers (Srv1-Srv6) and 350 their respective resources hosted (/resX). There are three 351 application groups (1, 2, 3) and two security groups (1, 2). 352 Security Group 1 is used by both Application Group 1 and 2. Three 353 clients (Cli1, Cli2, Cli3) are configured with security material for 354 Security Group 1. Two clients (Cli2, Cli4) are configured with 355 security material for Security Group 2. All the shown application 356 groups use the same CoAP group (not shown in the figure), i.e. one 357 specific multicast IP address and UDP port on which all the shown 358 resources are hosted for each server. 360 ________________________________ _________________________________ 361 / \ / \ 362 | +---------------------+ | | +---------------------+ | 363 | | Application Group 1 | | | | Application Group 3 | Cli2 | 364 | | | | | | | | 365 | Cli1 | Srv1 Srv2 Srv3 | | | | Srv5 Srv6 | Cli4 | 366 | | /resA /resA /resA | | | | /resC /resC | | 367 | Cli2 +---------------------+ | | | /resD /resD | | 368 | | | +---------------------+ | 369 | Cli3 Security Group 1 | | | 370 | | | Security Group 2 | 371 | +---------------------+ | \_________________________________/ 372 | | Application Group 2 | | 373 | | | | 374 | | Srv1 Srv4 | | 375 | | /resB /resB | | 376 | +---------------------+ | 377 \________________________________/ 379 Figure 2: Deployment Example of Different Group Types 381 2.2. Group Configuration 383 The following defines how groups of different types are named, 384 created, discovered and maintained. 386 2.2.1. Group Naming 388 A CoAP group is identified and named by the authority component in 389 the Group URI, which includes host (possibly an IP multicast address 390 literal) and an optional UDP port number. It is recommended to 391 configure an endpoint with an IP multicast address literal, instead 392 of a hostname, when configuring a CoAP group membership. This is 393 because DNS infrastructure may not be deployed in many constrained 394 networks. In case a group hostname is configured, it can be uniquely 395 mapped to an IP multicast address via DNS resolution - if DNS client 396 functionality is available in the endpoint being configured and the 397 DNS service is supported in the network. Some examples of 398 hierarchical CoAP group FQDN naming (and scoping) for a building 399 control application are shown in Section 2.2 of [RFC7390]. 401 An application group can be named in many ways through different 402 types of identifiers, such as numbers, URIs or other strings. An 403 application group name or identifier, if explicitly encoded in a CoAP 404 request, is typically included in the path component or in the query 405 component of a Group URI. It may also be encoded using the Uri-Host 406 Option [RFC7252] in case application group members implement a 407 virtual CoAP server specific to that application group. The 408 application group can then be identified by the value of the Uri-Host 409 Option and each virtual server serves one specific application group. 410 However, encoding the application group in the Uri-Host Option is not 411 the preferred method because in this case the application group 412 cannot be encoded in a Group URI, and also the Uri-Host Option is 413 being used for another purpose than encoding the host part of a URI 414 as intended by [RFC7252] - which is potentially confusing. 415 Appendix A of [I-D.ietf-core-resource-directory] shows an example 416 registration of an application group into a Resource Directory (RD), 417 along with the CoAP group it uses and the resources supported by the 418 application group. In this example an application group identifier 419 is not explicitly encoded in the RD nor in CoAP requests made to the 420 group, but it implicitly follows from the CoAP group used for the 421 request. So there is a one-to-one binding between the CoAP group and 422 the application group. The "NoSec" security group is used. 424 A best practice for encoding application group into a Group URI is to 425 use one URI path component to identify the application group and use 426 the following URI paths component(s) to identify the resource within 427 this application group. For example, //res1 or 428 /base//res1/res2 conform to this practice. An application 429 group identifier (like ) should be as short as possible 430 when used in constrained networks. 432 A security group is identified by a stable and invariant string used 433 as group name, which is generally not related with other kinds of 434 group identifiers, specific to the chosen security solution. The 435 "NoSec" security group name MUST be only used to represent the case 436 of group communication without any security. It is typically 437 characterized by the absence of any security group name, identifier, 438 or security-related data structures in the CoAP message. 440 2.2.2. Group Creation and Membership 442 To create a CoAP group, a configuring entity defines an IP multicast 443 address (or hostname) for the group and optionally a UDP port number 444 in case it differs from the default CoAP port 5683. Then, it 445 configures one or more devices as listeners to that IP multicast 446 address, with a CoAP endpoint listening on the group's associated UDP 447 port. These endpoints/devices are the group members. The 448 configuring entity can be, for example, a local application with pre- 449 configuration, a user, a software developer, a cloud service, or a 450 local commissioning tool. Also, the devices sending CoAP requests to 451 the group in the role of CoAP client need to be configured with the 452 same information, even though they are not necessarily group members. 453 One way to configure a client is to supply it with a CoAP Group URI. 454 The IETF does not define a mandatory, standardized protocol to 455 accomplish CoAP group creation. [RFC7390] defines an experimental 456 protocol for configuration of group membership for unsecured group 457 communication, based on JSON-formatted configuration resources. For 458 IPv6 CoAP groups, common multicast address ranges that are used to 459 configure group addresses from are ff1x::/16 and ff3x::/16. 461 To create an application group, a configuring entity may configure a 462 resource (name) or set of resources on CoAP endpoints, such that a 463 CoAP request with Group URI sent by a configured CoAP client will be 464 processed by one or more CoAP servers that have the matching URI path 465 configured. These servers are the application group members. 467 To create a security group, a configuring entity defines an initial 468 subset of the related security material. This comprises a set of 469 group properties including the cryptographic algorithms and 470 parameters used in the group, as well as additional information 471 relevant throughout the group life-cycle, such as the security group 472 name and description. This task MAY be entrusted to a dedicated 473 administrator, that interacts with a Group Manager as defined in 474 Section 5. After that, further security materials to protect group 475 communications have to be generated, compatible with the specified 476 group configuration. 478 To participate in a security group, CoAP endpoints have to be 479 configured with the group security material used to protect 480 communications in the associated application/CoAP groups. The part 481 of the process that involves secure distribution of group security 482 material MAY use standardized communication with a Group Manager as 483 defined in Section 5. For unsecure group communication using the 484 "NoSec" security group, any CoAP endpoint may become a group member 485 at any time: there is no configuring entity that needs to provide 486 security material for this group, as there is no security material 487 for it. This means that group creation and membership cannot be 488 tightly controlled for the "NoSec" group. 490 The configuration of groups and membership may be performed at 491 different moments in the life-cycle of a device; for example during 492 product (software) creation, in the factory, at a reseller, on-site 493 during first deployment, or on-site during a system reconfiguration 494 operation. 496 2.2.3. Group Discovery 498 It is possible for CoAP endpoints to discover application groups as 499 well as CoAP groups, by using the RD-Groups usage pattern of the CoRE 500 Resource Directory (RD), as defined in Appendix A of 501 [I-D.ietf-core-resource-directory]. In particular, an application 502 group can be registered to the RD, specifying the reference IP 503 multicast address, hence its associated CoAP group. The registration 504 is typically performed by a Commissioning Tool. Later on, CoAP 505 endpoints can discover the registered application groups and related 506 CoAP group, by using the lookup interface of the RD. 508 CoAP endpoints can also discover application groups by performing a 509 multicast discovery query using the /.well-known/core resource. Such 510 a request may be sent to a known CoAP group multicast address 511 associated to application group(s), or to the All CoAP Nodes 512 multicast address. 514 When secure communication is provided with Group OSCORE (see 515 Section 5), the approach described in 516 [I-D.tiloca-core-oscore-discovery] and also based on the RD can be 517 used, in order to discover the security group to join. 519 In particular, the responsible OSCORE Group Manager registers its own 520 security groups to the RD, as links to its own corresponding 521 resources for joining the security groups 522 [I-D.ietf-ace-key-groupcomm-oscore]. Later on, CoAP endpoints can 523 discover the registered security groups and related application 524 groups, by using the lookup interface of the RD, and then join the 525 security group through the respective Group Manager. 527 2.2.4. Group Maintenance 529 Maintenance of a group includes any necessary operations to cope with 530 changes in a system, such as: adding group members, removing group 531 members, changing group security material, reconfiguration of UDP 532 port and/or IP multicast address, reconfiguration of the Group URI, 533 renaming of application groups, splitting of groups, or merging of 534 groups. 536 For unsecured group communication (see Section 4) i.e. the "NoSec" 537 security group, addition/removal of CoAP group members is simply done 538 by configuring these devices to start/stop listening to the group IP 539 multicast address on the group's UDP port. 541 For secured group communication (see Section 5), the maintenance 542 operations of the protocol Group OSCORE 543 [I-D.ietf-core-oscore-groupcomm] MUST be implemented. When using 544 Group OSCORE, CoAP endpoints participating in group communication are 545 also members of a corresponding OSCORE security group, and thus share 546 common security material. Additional related maintenance operations 547 are discussed in Section 5.1. 549 3. CoAP Usage in Group Communication 551 This section specifies the usage of CoAP in group communication, both 552 unsecured and secured. This includes additional support for protocol 553 extensions, such as Observe (see Section 3.6) and block-wise transfer 554 (see Section 3.7). 556 How CoAP group messages are carried over various transport layers is 557 the subject of Section 3.8. Finally, Section 3.9 covers the 558 interworking of CoAP group communication with other protocols that 559 may operate in the same network. 561 3.1. Request/Response Model 563 A CoAP client is an endpoint able to transmit CoAP requests and 564 receive CoAP responses. Since the underlying UDP transport supports 565 multiplexing by means of UDP port number, there can be multiple 566 independent CoAP clients operational on a single host. On each UDP 567 port, an independent CoAP client can be hosted. Each independent 568 CoAP client sends requests that use the associated endpoint's UDP 569 port number as the UDP source port of the request. 571 All CoAP requests that are sent via IP multicast MUST be Non- 572 confirmable; see Section 8.1 of [RFC7252]. The Message ID in an IP 573 multicast CoAP message is used for optional message deduplication by 574 both clients and servers, as detailed in Section 4.5 of [RFC7252]. 576 A server sends back a unicast response to the CoAP group request - 577 but the server MAY suppress the response for various reasons given in 578 Section 8.2 of [RFC7252]. This document adds the requirement that a 579 server SHOULD suppress the response in case of error or in case there 580 is nothing useful to respond, unless the application related to a 581 particular resource requires such a response to be made for that 582 resource. The unicast responses received by the CoAP client may be a 583 mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not 584 Found) codes, depending on the individual server processing results. 586 The CoAP No-Response Option [RFC7967] can be used by a client to 587 influence the default response suppression on the server side. It is 588 RECOMMENDED for a server to support this option only on selected 589 resources where it is useful in the application context. If the 590 option is supported on a resource, it MUST override the default 591 response suppression of that resource. 593 Any default response suppression by a server SHOULD be performed 594 consistently, as follows: if a request on a resource produces a 595 particular Response Code and this response is not suppressed, then 596 another request on the same resource that produces a response of the 597 same Response Code class is also not suppressed. For example, if a 598 4.05 Method Not Allowed error response code is suppressed by default 599 on a resource, then a 4.15 Unsupported Content-Format error response 600 code is also suppressed by default for that resource. 602 A CoAP client MAY repeat a multicast request using the same Token 603 value and same Message ID value, in order to ensure that enough (or 604 all) group members have been reached with the request. This is 605 useful in case a number of group members did not respond to the 606 initial request and the client suspects that the request did not 607 reach these group members. However, in case one or more servers did 608 receive the initial request but the response to that request was 609 lost, this repeat does not help to retrieve the lost response(s) if 610 the server(s) implement the optional Message ID based deduplication 611 (Section 4.5 of [RFC7252]). 613 A CoAP client MAY repeat a multicast request using the same Token 614 value and a different Message ID, in which case all servers that 615 received the initial request will again process the repeated request 616 since it appears within a new CoAP message. This is useful in case a 617 client suspects that one or more response(s) to its original request 618 were lost and the client needs to collect more, or even all, 619 responses from group members, even if this comes at the cost of the 620 overhead of certain group members responding twice (once to the 621 original request, and once to the repeated request with different 622 Message ID). 624 The CoAP client can distinguish the origin of multiple server 625 responses by the source IP address of the UDP message containing the 626 CoAP response and/or any other available application-specific source 627 identifiers contained in the CoAP response payload or CoAP response 628 options, such as an application-level unique ID associated to the 629 server. If secure communication is provided with Group OSCORE (see 630 Section 5), additional security-related identifiers in the CoAP 631 response enable the client to retrieve the right security material 632 for decrypting each response and authenticating its source. 634 While processing a response on the client, the source endpoint of the 635 response is not matched to the destination endpoint of the request, 636 since for a multicast request these will never match. This is 637 specified in Section 8.2 of [RFC7252]. It implies also that a server 638 MAY respond from a UDP port number that differs from the destination 639 UDP port number of the request, although a CoAP server normally 640 SHOULD respond from the UDP port number that equals the destination 641 port of the request - following the convention for UDP-based 642 protocols. In case a single client has sent multiple group requests 643 and concurrent CoAP transactions are ongoing, the responses received 644 by that client are matched to an active request using only the Token 645 value. Due to UDP level multiplexing, the UDP destination port of 646 the response MUST match to the client endpoint's UDP port value, i.e. 647 to the UDP source port of the client's request. 649 For multicast CoAP requests, there are additional constraints on the 650 reuse of Token values at the client, compared to the unicast case 651 defined in [RFC7252] and updated by [I-D.ietf-core-echo-request-tag]. 652 Since for multicast CoAP the number of responses is not bound a 653 priori, the client cannot use the reception of a response as a 654 trigger to "free up" a Token value for reuse. Reusing a Token value 655 too early could lead to incorrect response/request matching on the 656 client, and would be a protocol error. Therefore, the time between 657 reuse of Token values for different multicast requests MUST be 658 greater than: 660 MIN_TOKEN_REUSE_TIME = (NON_LIFETIME + MAX_LATENCY + 661 MAX_SERVER_RESPONSE_DELAY) 663 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 664 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 665 in [RFC7390], that is: the expected maximum response delay over all 666 servers that the client can send a multicast request to. This delay 667 includes the maximum Leisure time period as defined in Section 8.2 of 668 [RFC7252]. However, CoAP does not define a time limit for the server 669 response delay. Using the default CoAP parameters, the Token reuse 670 time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. 671 A preferred solution to meet this requirement is to generate a new 672 unique Token for every new multicast request, such that a Token value 673 is never reused. If a client has to reuse Token values for some 674 reason, and also MAX_SERVER_RESPONSE_DELAY is unknown, then using 675 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 676 The time between Token reuses is in that case set to a value greater 677 than MIN_TOKEN_REUSE_TIME = 500 seconds. 679 When securing CoAP group communication with Group OSCORE 680 [I-D.ietf-core-oscore-groupcomm], secure binding between requests and 681 responses is ensured (see Section 5). Thus, a client may reuse a 682 Token value after it has been freed up, as discussed above for the 683 multicast case and considering a reuse time greater than 684 MIN_TOKEN_REUSE_TIME. If an alternative security protocol for CoAP 685 group communication is defined in the future which does not ensure 686 secure binding between requests and responses, a client MUST follow 687 the Token processing requirements as defined in 688 [I-D.ietf-core-echo-request-tag]. 690 Another method to more easily meet the above constraint is to 691 instantiate multiple CoAP clients at multiple UDP ports on the same 692 host. The Token values only have to be unique within the context of 693 a single CoAP client, so using multiple clients can make it easier to 694 meet the constraint. 696 Since a client sending a multicast request with a Token T will accept 697 multiple responses with the same Token T, it is possible in 698 particular that the same server sends multiple responses with the 699 same Token T back to the client. For example, this server might not 700 implement the optional CoAP message deduplication based on Message 701 ID; or it might be acting out of specification as a malicious, 702 compromised or faulty server. 704 When this happens, the client normally processes at the CoAP layer 705 each of those responses to the same request coming from the same 706 server. If the processing of a response is successful, the client 707 delivers this response to the application as usual. 709 Then, the application is in a better position to decide what to do, 710 depending on the available context information. For instance, it 711 might accept and process all the responses from the same server, even 712 if they are not Observe notifications (i.e., they do not include an 713 Observe option). Alternatively, the application might accept and 714 process only one of those responses, such as the most recent one from 715 that server, e.g. when this can trigger a change of state within the 716 application. 718 3.2. Caching 720 CoAP endpoints that are members of a CoAP group MAY cache responses 721 to a group request as defined in Section 5.6 of [RFC7252]. In 722 particular, these same rules apply to determine the set of request 723 options used as "Cache-Key". 725 Furthermore, building on what is defined in Section 8.2.1 of 726 [RFC7252]: 728 o A client sending a GET or FETCH group request over multicast MAY 729 update a cache with the responses from the servers in the CoAP 730 group. Then, the client uses both cached-still-fresh and new 731 responses as the result of the group request. 733 o A client sending a GET or FETCH group request over multicast MAY 734 use a response received from a server, to satisfy a subsequent 735 sent request intended to that server on the related unicast 736 request URI. In particular, the unicast request URI is obtained 737 by replacing the authority part of the request URI with the 738 transport-layer source address of the cached response message. 740 o A client MAY revalidate a cached response by making a GET or FETCH 741 request on the related unicast request URI. 743 Note that, in the presence of proxies, doing any of the above 744 (optional) unicast requests requires the client to distinguish the 745 different responses to a group request, as well as to distinguish the 746 different origin servers that responded. This in turn requires 747 additional means to provide the client with information about the 748 origin server of each response, as discussed in Section 3.4.3. 750 The following subsections define the freshness model and validation 751 model to use for cached responses, which update the models defined in 752 Section 5.6.1 and Section 5.6.2 of [RFC7252], respectively. 754 3.2.1. Freshness Model 756 For caching at endpoints, the same freshness model relying on the 757 Max-Age Option as defined in Section 5.6.1 of [RFC7252] applies. 759 For caching at proxies, the freshness model defined in Section 3.4.3 760 of this specification applies. 762 3.2.2. Validation Model 764 Section 5.6.2 of [RFC7252] defines a model to "validate" or 765 "revalidate" responses stored in cache, hence enabling the 766 suppression of responses that the client already has. 768 This relies on the ETag Option defined in Section 5.10.6 of 769 [RFC7252], with its usage limited to exchanges between a CoAP client 770 and one CoAP server. That is, Section 8.2.1 of [RFC7252] explicitly 771 forbids using an ETag Option in requests sent over multicast, and 772 leaves a mechanism to suppress responses for that case for further 773 study. 775 This section provides such a model to "validate" or "revalidate" 776 responses that the client already has cached. In particular, the 777 group request can indicate entity-tag values separately for each CoAP 778 server from which the client wishes to get a response revalidation, 779 together with addressing information identifying that server. 781 To this end, this specification defines the new Multi-ETag Option. 782 Operations related to this validation model and using the new option 783 are defined in Section 3.2.2.2 for the client side, and in 784 Section 3.2.2.3 for the server side. 786 The Multi-ETag Option has the properties summarized in Figure 3, 787 which extends Table 4 of [RFC7252]. The Multi-ETag Option is 788 elective, safe to forward, part of the cache key, and repeatable. 790 The option is intended only for group requests, as directly sent to a 791 CoAP group or to a CoAP proxy that forwards it to the CoAP group (see 792 Section 3.4). 794 +------+---+---+---+---+------------+--------+--------+---------+ 795 | No. | C | U | N | R | Name | Format | Length | Default | 796 +------+---+---+---+---+------------+--------+--------+---------+ 797 | | | | | | | | | | 798 | TBD1 | | | | x | Multi-ETag | (*) | any | (none) | 799 | | | | | | | | | | 800 +------+---+---+---+---+------------+--------+--------+---------+ 801 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 803 (*) See below. 805 Figure 3: The Multi-ETag Option. 807 The Multi-ETag Option has the same properties of the ETag Option 808 defined in Section 5.10.6 of [RFC7252], but it differs in the format 809 and length, as well as having a different reason for its 810 repeatability. 812 Each occurrence of the Multi-ETag Option targets exactly one of the 813 servers in the CoAP group, from which the client wishes to get a 814 response revalidation. The option value is set to a CBOR sequence 815 [RFC8742] composed of (1+M) elements, where: 817 o The first element specifies the addressing information of the 818 corresponding server, encoded as defined in Section 3.2.2.1. 820 This mirrors the format of the Multicast-Signaling option defined 821 in Section 3 of [I-D.tiloca-core-groupcomm-proxy]. Thus, in the 822 presence of a forward proxy supporting the mechanism defined in 823 [I-D.tiloca-core-groupcomm-proxy], the client can seamlessly use 824 the server addressing information obtained from the proxy, when 825 this forwards back a response to a group request from that server. 827 o The following M elements are CBOR byte strings, each of which has 828 as value an entity-tag value that the client wants to try against 829 the corresponding server. 831 The entity-tag values included in the Multi-ETag Option are 832 subject to the same considerations for the entity-tag values used 833 in an ETag Option (see Section 5.10.6 of [RFC7252]). 835 The Multi-ETag Option is of class E in terms of OSCORE processing 836 (see Section 4.1 of [RFC8613]). 838 3.2.2.1. Encoding of Server Addressing Information 840 The first element of the CBOR sequence in the Multi-ETag Option value 841 is set to the byte serialization of the CBOR array 'tp_info' defined 842 in Section 2.2.1 of 843 [I-D.tiloca-core-observe-multicast-notifications], including only the 844 set of elements 'srv_addr'. 846 In turn, the set includes the integer 'tp_id' identifying the used 847 transport protocol, and further elements whose number, format and 848 encoding depend on the value of 'tp_id'. 850 When the Multi-ETag Option is used in group requests transported over 851 UDP as in this specification, the 'tp_info' array includes the 852 following elements, encoded as defined in Section 2.2.1.1 of 853 [I-D.tiloca-core-observe-multicast-notifications]. 855 o 'tp_id': the CBOR integer with value 1 ("UDP"), from the "Value" 856 column of the "Transport Protocol Identifiers" Registry defined in 857 Section 14.4 of [I-D.tiloca-core-observe-multicast-notifications] 859 o 'srv_host': a CBOR byte string, with value the unicast IP address 860 of the server. This element is tagged and identified by the CBOR 861 tag 260 "Network Address (IPv4 or IPv6 or MAC Address)". 863 o 'srv_port': as a CBOR unsigned integer or the CBOR simple value 864 Null. If it is a CBOR integer, it has as value the destination 865 port number where to send individual requests intended to the 866 server. This element MAY be present. If not included, the 867 default port number 5683 is assumed. 869 The CDDL notation [RFC8610] provided below describes the 'tp_info' 870 CBOR array using the format above. 872 tp_info = [ 873 tp_id : 1, ; UDP as transport protocol 874 srv_host : #6.260(bstr), ; IP address where to reach the server 875 srv_port : uint / null ; Port number where to reach the server 876 ] 878 3.2.2.2. Processing on the Client Side 880 Similar to what is defined in Section 5.6.2 of [RFC7252], the client 881 may have one or more stored responses for a GET or FETCH group 882 request sent to the CoAP group, but cannot use any of them (e.g. 883 because they are not fresh). 885 In that case, the client can send a GET or FETCH group request, in 886 order to give the origin servers an opportunity both to select a 887 stored response to be used, and to update its freshness. As in 888 [RFC7252], this process is known as "validating" or "revalidating" 889 the stored response. 891 When sending such a group request, the endpoint SHOULD include one 892 Multi-ETag Option for each server it wishes to revalidate the 893 corresponding response with. As defined in Section 3.2.2, the Multi- 894 ETag Option can include multiple entity-tag values, each applicable 895 to a stored response from the corresponding server for that group 896 request. 898 Specifically, in the same GET or FETCH group request: 900 o The client MUST NOT include one or more ETag Option(s) together 901 with one or more Multi-ETag Option(s). 903 o The client MUST include only one Multi-ETag Option for each server 904 it wishes to get a response revalidation from. 906 o The client SHOULD limit the number of Multi-ETag Options, hence 907 limiting the number of servers as intended target of the 908 revalidation process, and SHOULD rather spread revalidation with 909 different sets of servers over different group requests. Also, 910 the client SHOULD limit the number of entity-tag values specified 911 in each Multi-ETag Option, preferably indicating only one entity- 912 tag value. 914 This allows for limiting the overall size of the group request. 915 As a guideline, the server addressing information can be 9-24 916 bytes in size, while each entity-tag value can be 1-8 bytes in 917 size. Thus, a single Multi-ETag Option can be up to (24 + 8 * M) 918 bytes in size, where M is the number of entity-tag values it 919 includes. 921 A 2.03 (Valid) response indicates that the stored response identified 922 by the entity-tag given in the response's ETag Option can be reused, 923 after updating the stored response as described in Section 5.9.1.3 of 924 [RFC7252]. So the client can determine if any one of the stored 925 representations from that server is current, without need to transfer 926 the current resource representation again. 928 Any other Response Code indicates that none of the stored responses 929 from that server, identified in the Multi-ETag Option of the group 930 request, are suitable. Instead, such response SHOULD be used to 931 satisfy the request and MAY replace the stored response. 933 3.2.2.3. Processing on the Server Side 935 If a GET or FETCH request includes both one or more ETag Options 936 together with one or more Multi-ETag Options, then the server MUST 937 ignore all the included ETag and Multi-ETag Options. 939 The server MUST ignore any Multi-ETag Option which is malformed, or 940 included in a request that is neither GET nor FETCH, or which 941 specifies addressing information not matching with its own endpoint 942 address. 944 The server considers only its pertaining Multi-ETag Option, i.e. 945 specifying addressing information associated to its own endpoint. 946 The server MUST ignore any pertaining Multi-ETag Option that occurs 947 more than once. 949 If the pertaining Multi-ETag Option specifies the CBOR simple value 950 Null for the 'srv_port' element of 'tp_info' (see Section 3.2.2.1), 951 the server MUST assume the default port number 5683. 953 Then, the server can issue a 2.03 (Valid) response in place of a 2.05 954 (Content) response, if one of the entity-tag values from the 955 pertaining Multi-ETag Option is the entity-tag for the current 956 resource representation, i.e. it is valid. The 2.03 (Valid) response 957 echoes this specific entity-tag within an ETag Option included in the 958 response. 960 The inclusion of an ETag Option in a response works as defined in 961 Section 5.6.10.1 of [RFC7252]. 963 3.3. Port and URI Path Selection 965 A server that is a member of a CoAP group listens for CoAP messages 966 on the group's IP multicast address, usually on the CoAP default UDP 967 port 5683, or another non-default UDP port if configured. Regardless 968 of the method for selecting the port number, the same port number 969 MUST be used across all CoAP servers that are members of a CoAP group 970 and across all CoAP clients performing the requests to that group. 972 The URI Path used in the request is preferably a path that is known 973 to be supported across all group members. However there are valid 974 use cases where a request is known to be successful only for a subset 975 of the CoAP group, for example only members of a specific application 976 group, while those group members for which the request is 977 unsuccessful (for example because they are outside the application 978 group) either ignore the multicast request or respond with an error 979 status code. 981 One way to create multiple CoAP groups is using different UDP ports 982 with the same IP multicast address, in case the devices' network 983 stack only supports a limited number of multicast address 984 subscriptions. However, it must be taken into account that this 985 incurs additional processing overhead on each CoAP server 986 participating in at least one of these groups: messages to groups 987 that are not of interest to the node are only discarded at the higher 988 transport (UDP) layer instead of directly at the network (IP) layer. 989 Also, a constrained network may be additionally burdened in this case 990 with multicast traffic that is eventually discarded at the UDP layer 991 by most nodes. 993 Port 5684 is reserved for DTLS-secured unicast CoAP and MUST NOT be 994 used for any CoAP group communication. 996 For a CoAP server node that supports resource discovery as defined in 997 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 998 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 999 group as detailed in Section 3.8. 1001 3.4. Proxy Operation 1003 This section defines how proxies operate in a group communication 1004 scenario. In particular, Section 3.4.1 defines operations of 1005 forward-proxies, Section 3.4.2 defines operations of reverse-proxies, 1006 and Section 3.4.3 defines operations of proxies that employ a cache 1007 for responses to group requests. 1009 3.4.1. Forward-Proxies 1011 CoAP enables a client to request a forward-proxy to process a CoAP 1012 request on its behalf, as described in Section 5.7.2 and 8.2.2 of 1013 [RFC7252]. For this purpose, the client specifies either the request 1014 group URI as a string in the Proxy-URI Option or it uses the Proxy- 1015 Scheme Option with the group URI constructed from the usual Uri-* 1016 Options. The forward-proxy then resolves the group URI to a 1017 destination CoAP group, multicasts the CoAP request, receives the 1018 responses and forwards all the individual (unicast) responses back to 1019 the client. 1021 However, there are certain issues and limitations with this approach: 1023 o The CoAP client component that sent a unicast CoAP request to the 1024 proxy may be expecting only one (unicast) response, as usual for a 1025 CoAP unicast request. Instead, it receives multiple (unicast) 1026 responses, potentially leading to fault conditions in the 1027 component or to discarding any received responses following the 1028 first one. This issue may occur even if the application calling 1029 the CoAP client component is aware that the forward-proxy is going 1030 to execute a CoAP group URI request. 1032 o Each individual CoAP response received by the client will appear 1033 to originate (based on its IP source address) from the CoAP Proxy, 1034 and not from the server that produced the response. This makes it 1035 impossible for the client to identify the server that produced 1036 each response, unless the server identity is contained as a part 1037 of the response payload or inside a CoAP option in the response. 1039 o The proxy does not know how many members there are in the CoAP 1040 group or how many group members will actually respond. Also, the 1041 proxy does not know for how long to collect responses before it 1042 stops forwarding them to the client. A CoAP client that is not 1043 using a Proxy might face the same problems in collecting responses 1044 to a multicast request. However, the client itself would 1045 typically have application-specific rules or knowledge on how to 1046 handle this situation, while an application-agnostic CoAP Proxy 1047 would typically not have this knowledge. For example, a CoAP 1048 client could monitor incoming responses and use this information 1049 to decide how long to continue collecting responses - which is 1050 something a proxy cannot do. 1052 A forward-proxying method using this approach and addressing the 1053 issues raised above is defined in [I-D.tiloca-core-groupcomm-proxy]. 1055 An alternative solution is for the proxy to collect all the 1056 individual (unicast) responses to a CoAP group request and then send 1057 back only a single (aggregated) response to the client. However, 1058 this solution brings up new issues: 1060 o Like for the approach discussed above, the proxy does not know for 1061 how long to collect responses before sending back the aggregated 1062 response to the client. Analogous considerations apply to this 1063 approach too, both on the client and proxy side. 1065 o There is no default format defined in CoAP for aggregation of 1066 multiple responses into a single response. Such a format could be 1067 standardized based on, for example, the multipart content-format 1068 [RFC8710]. 1070 Due to the above issues, it is RECOMMENDED that a CoAP Proxy only 1071 processes a group URI request if it is explicitly enabled to do so. 1072 The default response (if the function is not explicitly enabled) to a 1073 group URI request is 5.01 Not Implemented. Furthermore, a proxy 1074 SHOULD be explicitly configured (e.g. by allow-listing and/or client 1075 authentication) to allow proxied CoAP multicast requests only from 1076 specific client(s). 1078 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 1079 specified in Section 8.4 and 10.1 of [RFC8075]. In this case, the 1080 "application/http" media type is used to let the proxy return 1081 multiple CoAP responses - each translated to a HTTP response - back 1082 to the HTTP client. Of course, in this case the HTTP client sending 1083 a group URI to the proxy needs to be aware that it is going to 1084 receive this format, and needs to be able to decode it into the 1085 responses of multiple CoAP servers. Also, the IP source address of 1086 each CoAP response cannot be determined anymore from the 1087 "application/http" response. The HTTP client still identify the CoAP 1088 servers by other means such as application-specific information in 1089 the response payload. 1091 3.4.2. Reverse-Proxies 1093 CoAP enables the use of a reverse-proxy, as an endpoint that stands 1094 in for one or more other server(s), and satisfies requests on behalf 1095 of these, doing any necessary translations (see Section 5.7.3 of 1096 [RFC7252]). 1098 In a group communication scenario, a reverse-proxy can rely on its 1099 configuration and/or on information in a request from a client, in 1100 order to determine that the request has to be forwarded to a group of 1101 servers over IP multicast. For example, specific resources on the 1102 reverse-proxy could be allocated, each to a specific application 1103 group and/or CoAP group. Or alternatively, the application group 1104 and/or CoAP group in question could be encoded as URI path segments. 1105 The URI path encodings for a reverse-proxy may also use a URI mapping 1106 template as described in Section 5.4 of [RFC8075]. 1108 Furthermore, the reverse-proxy can actually stand in for (and thus 1109 prevent to directly reach) only the whole set of servers in the 1110 group, or also for each of those individual servers (e.g. if acting 1111 as firewall). 1113 For a reverse-proxy that forwards a request to a group of servers 1114 over IP multicast, the same considerations as defined in 1115 Section 5.7.3 of [RFC7252] hold, with the following additions: 1117 o The three issues and limitations defined in Section 3.4.1 for a 1118 forward proxy apply to a reverse-proxy as well, and have to be 1119 addressed, e.g. using the signaling method defined in 1120 [I-D.tiloca-core-groupcomm-proxy] or other means. 1122 o A reverse-proxy MAY have preconfigured time duration(s) that are 1123 used for the collecting of server responses and forwarding these 1124 back to the client. These duration(s) may be set as global 1125 configuration or resource-specific configurations. If there is 1126 such preconfiguration, then an explicit signaling of the time 1127 period in the client's request as defined in 1128 [I-D.tiloca-core-groupcomm-proxy] is not necessarily needed. 1130 o A client that is configured to access a reverse-proxy resource 1131 (i.e. one that triggers a CoAP group communication request) SHOULD 1132 be configured also to handle potentially multiple responses with 1133 the same Token value caused by a single request. 1135 That is,the client needs to preserve the Token value used for the 1136 request also after the reception of the first response forwarded 1137 back by the proxy (see Section 3.1) and keep the request open to 1138 potential further responses with this Token. This requirement can 1139 be met by a combination of client implementation and proper 1140 proxied group communication configuration on the client. 1142 o A client might re-use a Token value in a valid new request to the 1143 reverse-proxy, while the reverse-proxy still has an ongoing group 1144 communication request for this client with the same Token value 1145 (i.e. its time period for response collection has not ended yet). 1147 If this happens, the reverse-proxy MUST stop the ongoing request 1148 and associated response forwarding, it MUST NOT forward the new 1149 request to the group of servers, and it MUST send a 4.00 Bad 1150 Request error response to the client. The diagnostic payload of 1151 the error response SHOULD indicate to the client that the resource 1152 is a reverse-proxy resource, and that for this reason immediate 1153 Token re-use is not possible. 1155 If the reverse-proxy supports the signalling protocol of 1156 [I-D.tiloca-core-groupcomm-proxy] it can include a Multicast- 1157 Signaling Option in the error response to convey the reason for 1158 the error in a machine-readable way. 1160 For the operation of HTTP-to-CoAP reverse proxies, see the last 1161 paragraph of Section 3.4.1 which applies also to this case. 1163 3.4.3. Caching 1165 A proxy that supports forwarding of group requests and that employs a 1166 cache maintains the following two types of cache entry. 1168 o The first type, "individual" cache entry, is associated to one 1169 server and stores one response from that server, regardless 1170 whether it is a response to a unicast request or to a group 1171 request. 1173 A hit to this entry would be produced by a matching request 1174 intended to that server, i.e. to the corresponding unicast URI. 1176 When the response is a response to a unicast request to the 1177 server, the unicast URI is the same target URI used for the 1178 request. 1180 When the response is a response to a group request to the CoAP 1181 group, the unicast URI is obtained by replacing the authority part 1182 of the group URI in the group request with the transport-layer 1183 source address and port number of the response message. 1185 o The second type, "aggregated" cache entry, is associated to the 1186 CoAP group, and stores all the responses that: the proxy has 1187 received as a response to a group request to that group; and that 1188 have been also forwarded back to the client that sent the group 1189 request. 1191 A hit to this entry would be produced by a matching group request 1192 intended to the CoAP group, i.e. to the corresponding group URI. 1194 When forwarding a group request to a CoAP group using the request's 1195 group URI and processing the responses, the proxy handles its cache 1196 entries as follows. The same applies if the proxy spontaneously re- 1197 sends a group request to the CoAP group, in order to refresh an 1198 aggregated cache entry after its expiration or invalidation. 1200 1. For each response to the group request which is received and also 1201 forwarded back to the client: 1203 * The proxy creates or refreshes the individual cache entry 1204 associated to the origin server and for that response. That 1205 is, the response is stored in the individual cache entry, and 1206 the lifetime of the cache entry is set to the lifetime of the 1207 response, as indicated by the Max-Age Option if present, or as 1208 the default value of 60 seconds otherwise (see Section 5.6.1 1209 of [RFC7252]). This cache entry becomes immediately usable to 1210 serve requests from clients. 1212 * The proxy adds the response to a temporary list L. 1214 2. After stopping to forward the received responses back to the 1215 client: 1217 * The proxy creates an aggregated cache entry associated to the 1218 group for that group request, if not existing yet. In case of 1219 an existing entry to be refreshed, the proxy deletes all the 1220 responses stored in the entry. 1222 * The proxy stores all the responses from the list L in the 1223 aggregated cache entry. 1225 * The proxy sets the lifetime of the cache entry to the smallest 1226 lifetime among all the responses stored in the entry, 1227 determined in the same way as defined in step 1 above. 1229 * The proxy sets the aggregated cache entry as usable to serve 1230 group requests from clients. 1232 When forwarding a request to an individual server using the 1233 associated unicast URI and processing its response, the proxy handles 1234 its cache entries as follows. The same applies if the proxy 1235 spontaneously re-sends a unicast request to a single server, in order 1236 to refresh an individual cache entry after its expiration or 1237 invalidation. 1239 1. The proxy creates or refreshes the individual cache entry 1240 associated to the origin server and for that response. That is, 1241 the response is stored in the cache entry, and the lifetime of 1242 the cache entry is set to the lifetime of the response, as 1243 indicated by the Max-Age Option if present, or as the default 1244 value of 60 seconds otherwise (see Section 5.6.1 of [RFC7252]). 1245 This cache entry becomes immediately usable to serve requests 1246 from clients. 1248 2. The proxy checks whether it has a non-expired and valid 1249 aggregated cache entry, such that a hit would be produced by a 1250 group request analogous to the forwarded unicast request. 1252 That is, such group request would be intended to the group URI of 1253 the CoAP group associated to the aggregated cache entry, rather 1254 than intended to the unicast URI of the forwarded request. 1256 3. If an aggregated cache entry is found at the previous step: 1258 * The proxy stores the received response in the aggregated cache 1259 entry, possibly replacing an already stored instance of that 1260 response from that origin server. 1262 * The proxy sets as new lifetime of the aggregated cache entry 1263 the minimum value between the current lifetime of the cache 1264 entry and the lifetime of the just-stored response, as 1265 indicated by the Max-Age Option if present, or as the default 1266 value of 60 seconds otherwise (see Section 5.6.1 of 1267 [RFC7252]). 1269 Note that a proxy embedded in a router can monitor network control 1270 messages, hence learning when a new server has joined a CoAP group 1271 and is listening to the multicast IP address of that CoAP group. 1272 This information could be used to guide the proxy in refreshing an 1273 aggregated cache entry, by sending a request to the CoAP group over 1274 the group URI before the entry expires, and thus storing also a 1275 response from the newly joined server. 1277 Following the expiration or invalidation of a cache entry, as well as 1278 if wishing to refresh a cache entry, the proxy can directly interact 1279 with the servers in the CoAP group. To this end, it takes the role 1280 of a CoAP client as defined in Section 3.2. In particular, the proxy 1281 can perform revalidation of responses to group requests by using the 1282 Multi-ETag Option, as defined in Section 3.2.2. 1284 As further discussed in Section 5.2, additional means are required to 1285 enable cachability of responses at the proxy when communications in 1286 the group are secured with Group OSCORE 1287 [I-D.ietf-core-oscore-groupcomm]. 1289 3.4.3.1. Validation of Responses to a Group Request 1291 A client can revalidate the full set of responses to a group request 1292 from the corresponding aggregated cache entry at the proxy. To this 1293 end, this specification defines the new Group-ETag Option. 1295 The Group-ETag Option has the properties summarized in Figure 4, 1296 which extends Table 4 of [RFC7252]. The Group-ETag Option is 1297 elective, safe to forward, part of the cache key, and repeatable. 1299 The option is intended for group requests sent to a Forward-Proxy, as 1300 well as for the associated responses retrieved from the corresponding 1301 aggregated cache entry at the proxy. 1303 +------+---+---+---+---+------------+--------+--------+---------+ 1304 | No. | C | U | N | R | Name | Format | Length | Default | 1305 +------+---+---+---+---+------------+--------+--------+---------+ 1306 | | | | | | | | | | 1307 | TBD2 | | | | x | Group-ETag | opaque | 1-8 | (none) | 1308 | | | | | | | | | | 1309 +------+---+---+---+---+------------+--------+--------+---------+ 1310 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 1312 Figure 4: The Group-ETag Option. 1314 The Group-ETag Option has the same properties of the ETag Option 1315 defined in Section 5.10.6 of [RFC7252]. 1317 The Group-ETag Option is of class U in terms of OSCORE processing 1318 (see Section 4.1 of [RFC8613]). 1320 When providing 2.05 (Content) responses to a GET or FETCH group 1321 request from an aggregated cache entry, the proxy can include one 1322 Group-ETag Option, specifying the current entity-tag value associated 1323 to that cache entry. Each of such responses MUST NOT include more 1324 than one Group-ETag Option. 1326 If the proxy supports this form of response revalidation, it MUST 1327 update the current entity-tag value associated to an aggregated cache 1328 entry, every time a response is added to that cache entry or replaces 1329 an already included response. 1331 When sending a GET or FETCH group request to the proxy, to be 1332 forwarded to a CoAP group, the client can include one or more Group- 1333 ETag Option(s). Each option specifies one entity-tag value, as 1334 applicable to the aggregated cache entry for that group request. 1336 In case the group request hits an aggregated cache entry and its 1337 current entity-tag value matches with one of the entity-tag value(s) 1338 specified in the Group-ETag option(s), then the proxy replies with a 1339 single 2.03 (Valid) response. This response has no payload and MUST 1340 include one Group-ETag Option, specifying the current entity-tag 1341 value of the aggregated cache entry. 1343 That is, the 2.03 (Valid) response from the proxy indicates that the 1344 stored responses idenfied by the entity-tag given in the response's 1345 Group-ETag Option can be reused, after updating each of them as 1346 described in Section 5.9.1.3 of [RFC7252]. In effect, the client can 1347 determine if any of the stored set of representations from the 1348 aggregated cache entry at the proxy is current, without needing to 1349 transfer any of them again. 1351 Note that, if a client triggers the proxy to perform forwarding of a 1352 group request (i.e., there is no hit of an aggregated cache entry), 1353 this will result in a new aggregated cache entry created at the 1354 proxy. Then, the client cannot obtain an entity-tag value through a 1355 Group-ETag Option in any of the responses forwarded back by the 1356 proxy. 1358 In fact, the proxy will only have an assigned entity-tag value to 1359 provide after all responses have been forwarded back to that client, 1360 which is the moment that the new aggregated cache entry is eventually 1361 created. However, when follow-up group requests from the same client 1362 or different clients are served from this aggregated cache entry, the 1363 proxy can include a Group-ETag Option in each returned response, 1364 specifying the current entity-tag for the aggregated cache entry. 1366 3.5. Congestion Control 1368 CoAP group requests may result in a multitude of responses from 1369 different nodes, potentially causing congestion. Therefore, both the 1370 sending of IP multicast requests and the sending of the unicast CoAP 1371 responses to these multicast requests should be conservatively 1372 controlled. 1374 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 1375 the following measures: 1377 o A server may choose not to respond to an IP multicast request if 1378 there is nothing useful to respond to, e.g., error or empty 1379 response (see Section 8.2 of [RFC7252]). 1381 o A server should limit the support for IP multicast requests to 1382 specific resources where multicast operation is required 1383 (Section 11.3 of [RFC7252]). 1385 o An IP multicast request MUST be Non-confirmable (Section 8.1 of 1386 [RFC7252]). 1388 o A response to an IP multicast request SHOULD be Non-confirmable 1389 (Section 5.2.3 of [RFC7252]). 1391 o A server does not respond immediately to an IP multicast request 1392 and should first wait for a time that is randomly picked within a 1393 predetermined time interval called the Leisure (Section 8.2 of 1394 [RFC7252]). 1396 Additional guidelines to reduce congestion risks defined in this 1397 document are as follows: 1399 o A server in a constrained network SHOULD only support group 1400 communication for resources that have a small representation 1401 (where the representation may be retrieved via a GET, FETCH or 1402 POST method in the request). For example, "small" can be defined 1403 as a response payload limited to approximately 5% of the IP 1404 Maximum Transmit Unit (MTU) size, so that it fits into a single 1405 link-layer frame in case IPv6 over Low-Power Wireless Personal 1406 Area Networks (6LoWPAN, see Section 3.8.3) is used on the 1407 constrained network. 1409 o A server SHOULD minimize the payload size of a response to a 1410 multicast GET or FETCH on "/.well-known/core" by using hierarchy 1411 in arranging link descriptions for the response. An example of 1412 this is given in Section 5 of [RFC6690]. 1414 o A server MAY minimize the payload size of a response to a 1415 multicast GET or FETCH (e.g., on "/.well-known/core") by using 1416 CoAP block-wise transfers [RFC7959] in case the payload is long, 1417 returning only a first block of the CoRE Link Format description. 1418 For this reason, a CoAP client sending an IP multicast CoAP 1419 request to "/.well-known/core" SHOULD support block-wise 1420 transfers. See also Section 3.7. 1422 o A client SHOULD be configured to use CoAP groups with the smallest 1423 possible IP multicast scope that fulfills the application needs. 1424 As an example, site-local scope is always preferred over global 1425 scope IP multicast if this fulfills the application needs. 1426 Similarly, realm-local scope is always preferred over site-local 1427 scope if this fulfills the application needs. 1429 3.6. Observing Resources 1431 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 1432 that allows a CoAP client to retrieve a representation of a resource 1433 and automatically keep this representation up-to-date over a longer 1434 period of time. The client gets notified when the representation has 1435 changed. [RFC7641] does not mention whether the Observe Option can 1436 be combined with CoAP multicast. 1438 This section updates [RFC7641] with the use of the Observe Option in 1439 a CoAP multicast GET request, and defines normative behavior for both 1440 client and server. Consistent with Section 2.4 of [RFC8132], it is 1441 also possible to use the Observe Option in a CoAP multicast FETCH 1442 request. 1444 Multicast Observe is a useful way to start observing a particular 1445 resource on all members of a CoAP group at the same time. Group 1446 members that do not have this particular resource or do not allow the 1447 GET or FETCH method on it will either respond with an error status - 1448 4.04 Not Found or 4.05 Method Not Allowed, respectively - or will 1449 silently suppress the response following the rules of Section 3.1, 1450 depending on server-specific configuration. 1452 A client that sends a multicast GET or FETCH request with the Observe 1453 Option MAY repeat this request using the same Token value and the 1454 same Observe Option value, in order to ensure that enough (or all) 1455 members of the CoAP group have been reached with the request. This 1456 is useful in case a number of group members did not respond to the 1457 initial request. The client MAY additionally use the same Message ID 1458 in the repeated request to avoid that group members that had already 1459 received the initial request would respond again. Note that using 1460 the same Message ID in a repeated request will not be helpful in case 1461 of loss of a response message, since the server that responded 1462 already will consider the repeated request as a duplicate message. 1463 On the other hand, if the client uses a different, fresh Message ID 1464 in the repeated request, then all the group members that receive this 1465 new message will typically respond again, which increases the network 1466 load. 1468 A client that has sent a multicast GET or FETCH request with the 1469 Observe Option MAY follow up by sending a new unicast CON request 1470 with the same Token value and same Observe Option value to a 1471 particular server, in order to ensure that the particular server 1472 receives the request. This is useful in case a specific group 1473 member, that was expected to respond to the initial group request, 1474 did not respond to the initial request. In this case, the client 1475 MUST use a Message ID that differs from the initial multicast 1476 message. 1478 Furthermore, consistent with Section 3.3.1 of [RFC7641] and following 1479 its guidelines, a client MAY at any time send a new multicast GET or 1480 FETCH request with the same Token value and same Observe Option value 1481 as the original request. This allows the client to verify that it 1482 has an up-to-date representation of an observed resource and/or to 1483 re-register its interest to observe a resource. 1485 In the above client behaviors, the Token value is kept identical to 1486 the initial request to avoid that a client is included in more than 1487 one entry in the list of observers (Section 4.1 of [RFC7641]). 1489 Before repeating a request as specified above, the client SHOULD wait 1490 for at least the expected round-trip time plus the Leisure time 1491 period defined in Section 8.2 of [RFC7252], to give the server time 1492 to respond. 1494 A server that receives a GET or FETCH request with the Observe 1495 Option, for which request processing is successful, SHOULD respond to 1496 this request and not suppress the response. A server that adds a 1497 client to the list (as a new entry) of observers for a resource due 1498 to an Observe request MUST respond to this request and not suppress 1499 it. 1501 A server SHOULD have a mechanism to verify liveness of its observing 1502 clients and the continued interest of these clients in receiving the 1503 observe notifications. This can be implemented by sending 1504 notifications occassionally using a Confirmable message. See 1505 Section 4.5 of [RFC7641] for details. This requirement overrides the 1506 regular behavior of sending Non-Confirmable notifications in response 1507 to a Non-Confirmable request. 1509 A client can use the unicast cancellation methods of Section 3.6 of 1510 [RFC7641] and stop the ongoing observation of a particular resource 1511 on members of a CoAP group. This can be used to remove specific 1512 observed servers, or even all servers in the group (using serial 1513 unicast to each known group member). In addition, a client MAY 1514 explicitly deregister from all those servers at once, by sending a 1515 multicast GET or FETCH request that includes the Token value of the 1516 observation to be cancelled and includes an Observe Option with the 1517 value set to 1 (deregister). In case not all the servers in the CoAP 1518 group received this deregistration request, either the unicast 1519 cancellation methods can be used at a later point in time or the 1520 multicast deregistration request MAY be repeated upon receiving 1521 another observe response from a server. 1523 For observing a group of servers through a CoAP-to-CoAP proxy, the 1524 limitations stated in Section 3.4 apply. The method defined in 1525 [I-D.tiloca-core-groupcomm-proxy] enables group communication 1526 including resource observation through proxies and addresses those 1527 limitations. 1529 3.7. Block-Wise Transfer 1531 Section 2.8 of [RFC7959] specifies how a client can use block-wise 1532 transfer (Block2 Option) in a multicast GET request to limit the size 1533 of the initial response of each server. Consistent with Section 2.5 1534 of [RFC8132], the same can be done with a multicast FETCH request. 1536 The client has to use unicast for any further request, separately 1537 addressing each different server, in order to retrieve more blocks of 1538 the resource from that server, if any. Also, a server (member of a 1539 targeted CoAP group) that needs to respond to a multicast request 1540 with a particularly large resource can use block-wise transfer 1541 (Block2 Option) at its own initiative, to limit the size of the 1542 initial response. Again, a client would have to use unicast for any 1543 further requests to retrieve more blocks of the resource. 1545 A solution for multicast block-wise transfer using the Block1 Option 1546 is not specified in [RFC7959] nor in the present document. Such a 1547 solution would be useful for multicast FETCH/PUT/POST/PATCH/iPATCH 1548 requests, to efficiently distribute a large request payload as 1549 multiple blocks to all members of a CoAP group. Multicast usage of 1550 Block1 is non-trivial due to potential message loss (leading to 1551 missing blocks or missing confirmations), and potential diverging 1552 block size preferences of different members of the CoAP group. 1554 3.8. Transport 1556 In this document only UDP is considered as a transport protocol, both 1557 over IPv4 and IPv6. Therefore, [RFC8323] (CoAP over TCP, TLS, and 1558 WebSockets) is not in scope as a transport for group communication. 1560 3.8.1. UDP/IPv6 Multicast Transport 1562 CoAP group communication can use UDP over IPv6 as a transport 1563 protocol, provided that IPv6 multicast is enabled. IPv6 multicast 1564 MAY be supported in a network only for a limited scope. For example, 1565 Section 3.9.2 describes the potential limited support of RPL for 1566 multicast, depending on how the protocol is configured. 1568 For a CoAP server node that supports resource discovery as defined in 1569 Section 2.4 of [RFC7252], the default port 5683 MUST be supported as 1570 per Section 7.1 and 12.8 of [RFC7252] for the "All CoAP Nodes" 1571 multicast group. An IPv6 CoAP server SHOULD support the "All CoAP 1572 Nodes" groups with at least link-local (2), admin-local (4) and site- 1573 local (5) scopes. An IPv6 CoAP server on a 6LoWPAN node (see 1574 Section 3.8.3) SHOULD also support the realm-local (3) scope. 1576 Note that a client sending an IPv6 multicast CoAP message to a port 1577 that is not supported by the server will not receive an ICMPv6 Port 1578 Unreachable error message from that server, because the server does 1579 not send it in this case, per Section 2.4 of [RFC4443]. 1581 3.8.2. UDP/IPv4 Multicast Transport 1583 CoAP group communication can use UDP over IPv4 as a transport 1584 protocol, provided that IPv4 multicast is enabled. For a CoAP server 1585 node that supports resource discovery as defined in Section 2.4 of 1586 [RFC7252], the default port 5683 MUST be supported as per Section 7.1 1587 and 12.8 of [RFC7252], for the "All CoAP Nodes" IPv4 multicast group. 1589 Note that a client sending an IPv4 multicast CoAP message to a port 1590 that is not supported by the server will not receive an ICMP Port 1591 Unreachable error message from that server, because the server does 1592 not send it in this case, per Section 3.2.2 of [RFC1122]. 1594 3.8.3. 6LoWPAN 1596 In 6LoWPAN [RFC4944] [RFC6282] networks, IPv6 packets (up to 1280 1597 bytes) may be fragmented into smaller IEEE 802.15.4 MAC frames (up to 1598 127 bytes), if the packet size requires this. Every 6LoWPAN IPv6 1599 router that receives a multi-fragment packet reassembles the packet 1600 and refragments it upon transmission. Since the loss of a single 1601 fragment implies the loss of the entire IPv6 packet, the performance 1602 in terms of packet loss and throughput of multi-fragment multicast 1603 IPv6 packets is typically far worse than the performance of single- 1604 fragment IPv6 multicast packets. For this reason, a CoAP request 1605 sent over multicast in 6LoWPAN networks SHOULD be sized in such a way 1606 that it fits in a single IEEE 802.15.4 MAC frame, if possible. 1608 On 6LoWPAN networks, multicast groups can be defined with realm-local 1609 scope [RFC7346]. Such a realm-local group is restricted to the local 1610 6LoWPAN network/subnet. In other words, a multicast request to that 1611 group does not propagate beyond the 6LoWPAN network segment where the 1612 request originated. For example, a multicast discovery request can 1613 be sent to the realm-local "All CoAP Nodes" IPv6 multicast group (see 1614 Section 3.8.1) in order to discover only CoAP servers on the local 1615 6LoWPAN network. 1617 3.9. Interworking with Other Protocols 1619 3.9.1. MLD/MLDv2/IGMP/IGMPv3 1621 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1622 unaware of the specific IP multicast routing/forwarding protocol 1623 being used in their network. When such a host needs to join a 1624 specific (CoAP) multicast group, it requires a way to signal to IP 1625 multicast routers which IP multicast address(es) it needs to listen 1626 to. 1628 The MLDv2 protocol [RFC3810] is the standard IPv6 method to achieve 1629 this; therefore, this method SHOULD be used by members of a CoAP 1630 group to subscribe to its multicast IPv6 address, on IPv6 networks 1631 that support it. CoAP server nodes then act in the role of MLD 1632 Multicast Address Listener. MLDv2 uses link-local communication 1633 between Listeners and IP multicast routers. Constrained IPv6 1634 networks that implement either RPL (see Section 3.9.2) or MPL (see 1635 Section 3.9.3) typically do not support MLDv2 as they have their own 1636 mechanisms defined for subscribing to multicast groups. 1638 The IGMPv3 protocol [RFC3376] is the standard IPv4 method to signal 1639 multicast group subscriptions. This SHOULD be used by members of a 1640 CoAP group to subscribe to its multicast IPv4 address on IPv4 1641 networks. 1643 The guidelines from [RFC6636] on the tuning of MLD for mobile and 1644 wireless networks may be useful when implementing MLD in constrained 1645 networks. 1647 3.9.2. RPL 1649 RPL [RFC6550] is an IPv6 based routing protocol suitable for low- 1650 power, lossy networks (LLNs). In such a context, CoAP is often used 1651 as an application protocol. 1653 If only RPL is used in a network for routing and its optional 1654 multicast support is disabled, there will be no IP multicast routing 1655 available. Any IPv6 multicast packets in this case will not 1656 propagate beyond a single hop (to direct neighbors in the LLN). This 1657 implies that any CoAP group request will be delivered to link-local 1658 nodes only, for any scope value >= 2 used in the IPv6 destination 1659 address. 1661 RPL supports (see Section 12 of [RFC6550]) advertisement of IP 1662 multicast destinations using Destination Advertisement Object (DAO) 1663 messages and subsequent routing of multicast IPv6 packets based on 1664 this. It requires the RPL mode of operation to be 3 (Storing mode 1665 with multicast support). 1667 In this mode, RPL DAO can be used by a CoAP node that is either an 1668 RPL router or RPL Leaf Node, to advertise its CoAP group membership 1669 to parent RPL routers. Then, RPL will route any IP multicast CoAP 1670 requests over multiple hops to those CoAP servers that are group 1671 members. 1673 The same DAO mechanism can be used to convey CoAP group membership 1674 information to an edge router (e.g., 6LBR), in case the edge router 1675 is also the root of the RPL Destination-Oriented Directed Acyclic 1676 Graph (DODAG). This is useful because the edge router then learns 1677 which IP multicast traffic it needs to pass through from the backbone 1678 network into the LLN subnet, and which traffic not. In LLNs, such 1679 ingress filtering helps to avoid congestion of the resource- 1680 constrained network segment, due to IP multicast traffic from the 1681 high-speed backbone IP network. 1683 3.9.3. MPL 1685 The Multicast Protocol for Low-Power and Lossy Networks (MPL) 1686 [RFC7731] can be used for propagation of IPv6 multicast packets 1687 throughout a defined network domain, over multiple hops. MPL is 1688 designed to work in LLNs and can operate alone or in combination with 1689 RPL. The protocol involves a predefined group of MPL Forwarders to 1690 collectively distribute IPv6 multicast packets throughout their MPL 1691 Domain. An MPL Forwarder may be associated to multiple MPL Domains 1692 at the same time. Non-Forwarders will receive IPv6 multicast packets 1693 from one or more of their neighboring Forwarders. Therefore, MPL can 1694 be used to propagate a CoAP multicast request to all group members. 1696 However, a CoAP multicast request to a group that originated outside 1697 of the MPL Domain will not be propagated by MPL - unless an MPL 1698 Forwarder is explicitly configured as an ingress point that 1699 introduces external multicast packets into the MPL Domain. Such an 1700 ingress point could be located on an edge router (e.g., 6LBR). 1701 Methods to configure which multicast groups are to be propagated into 1702 the MPL Domain could be: 1704 o Manual configuration on each ingress MPL Forwarder. 1706 o MLDv2 protocol, which works only in case all CoAP servers joining 1707 a group are in link-local communication range of an ingress MPL 1708 Forwarder. This is typically not the case on mesh networks. 1710 o A new/custom protocol to register multicast groups at an ingress 1711 MPL Forwarder. This could be for example a CoAP-based protocol 1712 offering multicast group subscription features similar to MLDv2. 1714 4. Unsecured Group Communication 1716 CoAP group communication can operate in CoAP NoSec (No Security) 1717 mode, without using application-layer and transport-layer security 1718 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 1719 Section 9 of [RFC7252]. The conceptual "NoSec" security group as 1720 defined in Section 2.1 is used for unsecured group communication. 1721 Before using this mode of operation, the security implications 1722 (Section 6.1) must be well understood. 1724 5. Secured Group Communication using Group OSCORE 1726 The application-layer protocol Object Security for Constrained 1727 RESTful Environments (OSCORE) [RFC8613] provides end-to-end 1728 encryption, integrity and replay protection of CoAP messages 1729 exchanged between two CoAP endpoints. These can act both as CoAP 1730 Client as well as CoAP Server, and share an OSCORE Security Context 1731 used to protect and verify exchanged messages. The use of OSCORE 1732 does not affect the URI scheme and OSCORE can therefore be used with 1733 any URI scheme defined for CoAP. 1735 OSCORE uses COSE 1736 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 1737 perform encryption operations and protect a CoAP message carried in a 1738 COSE object, by using an Authenticated Encryption with Associated 1739 Data (AEAD) algorithm. In particular, OSCORE takes as input an 1740 unprotected CoAP message and transforms it into a protected CoAP 1741 message transporting the COSE object. 1743 OSCORE makes it possible to selectively protect different parts of a 1744 CoAP message in different ways, while still allowing intermediaries 1745 (e.g., CoAP proxies) to perform their intended funtionalities. That 1746 is, some message parts are encrypted and integrity protected; other 1747 parts are only integrity protected to be accessible to, but not 1748 modifiable by, proxies; and some parts are kept as plain content to 1749 be both accessible to and modifiable by proxies. Such differences 1750 especially concern the CoAP options included in the unprotected 1751 message. 1753 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 1754 provides end-to-end security of CoAP messages exchanged between 1755 members of an OSCORE group, while fulfilling the same security 1756 requirements. 1758 In particular, Group OSCORE protects CoAP requests sent over IP 1759 multicast by a CoAP client, as well as multiple corresponding CoAP 1760 responses sent over IP unicast by different CoAP servers. However, 1761 the same security material can also be used to protect CoAP requests 1762 sent over IP unicast to a single CoAP server in the OSCORE group, as 1763 well as the corresponding responses. 1765 Group OSCORE ensures source authentication of all messages exchanged 1766 within the OSCORE group, by means of two possible methods. 1768 The first method, called group mode, relies on digital signatures. 1769 That is, sender devices sign their outgoing messages using their own 1770 private key, and embed the signature in the protected CoAP message. 1772 The second method, called pairwise mode, relies on a symmetric key, 1773 which is derived from a pairwise shared secret computed from the 1774 asymmetric keys of the message sender and recipient. This method is 1775 intended for one-to-one messages sent in the group, such as all 1776 responses individually sent by servers, as well as requests addressed 1777 to an individual server. 1779 A Group Manager is responsible for managing one or multiple OSCORE 1780 groups. In particular, the Group Manager acts as repository of 1781 public keys of group members; manages, renews and provides security 1782 material in the group; and handles the join process of new group 1783 members. 1785 As defined in [I-D.ietf-ace-oscore-gm-admin], an administrator entity 1786 can interact with the Group Manager to create OSCORE groups and 1787 specify their configuration (see Section 2.2.2). During the lifetime 1788 of the OSCORE group, the administrator can further interact with the 1789 Group Manager, in order to possibly update the group configuration 1790 and eventually delete the group. 1792 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 1793 can join an OSCORE group by using the method described in 1794 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 1795 for Authentication and Authorization in constrained environments 1796 [I-D.ietf-ace-oauth-authz]. 1798 A CoAP endpoint can discover OSCORE groups and retrieve information 1799 to join them through their respective Group Managers by using the 1800 method described in [I-D.tiloca-core-oscore-discovery] and based on 1801 the CoRE Resource Directory [I-D.ietf-core-resource-directory]. 1803 If security is required, CoAP group communication as described in 1804 this specification MUST use Group OSCORE. In particular, a CoAP 1805 group as defined in Section 2.1 and using secure group communication 1806 is associated to an OSCORE security group, which includes: 1808 o All members of the CoAP group, i.e. the CoAP endpoints configured 1809 (also) as CoAP servers and listening to the group's multicast IP 1810 address on the group's UDP port. 1812 o All further CoAP endpoints configured only as CoAP clients, that 1813 send (multicast) CoAP requests to the CoAP group. 1815 5.1. Secure Group Maintenance 1817 As part of group maintenance operations (see Section 2.2.4), 1818 additional key management operations are required for an OSCORE 1819 group, depending on the security requirements of the application (see 1820 Section 6.2). Specifically: 1822 o Adding new members to a CoAP group or enabling new client-only 1823 endpoints to interact with that group require also that each of 1824 such members/endpoints join the corresponding OSCORE group. By 1825 doing so, they are securely provided with the necessary 1826 cryptographic material. In case backward security is needed, this 1827 also requires to first renew such material and distribute it to 1828 the current members/endpoints, before new ones are added and join 1829 the OSCORE group. 1831 o In case forward security is needed, removing members from a CoAP 1832 group or stopping client-only endpoints from interacting with that 1833 group requires removing such members/endpoints from the 1834 corresponding OSCORE group. To this end, new cryptographic 1835 material is generated and securely distributed only to the 1836 remaining members/endpoints. This ensures that only the members/ 1837 endpoints intended to remain are able to continue participating in 1838 secure group communication, while the evicted ones are not able 1839 to. 1841 The key management operations mentioned above are entrusted to the 1842 Group Manager responsible for the OSCORE group 1843 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 1844 them according to the approach described in 1845 [I-D.ietf-ace-key-groupcomm-oscore]. 1847 5.2. Caching of Responses at Proxies 1849 When using Group OSCORE to protect communications end-to-end between 1850 a client and multiple servers in the group, it is normally not 1851 possible for an intermediary proxy to cache protected responses. 1853 In fact, when starting from the same plain CoAP message, different 1854 clients generate different protected requests to send on the wire. 1855 This prevents different clients to generate potential cache hits, and 1856 thus makes response caching at the proxy pointless. 1858 5.2.1. Using Deterministic Requests to Achieve Cachability 1860 For application scenarios that require secure group communication, it 1861 is still possible to achieve cachability of responses at proxies, by 1862 using the approach defined in [I-D.amsuess-core-cachable-oscore] 1863 which is based on Deterministic Requests protected with the pairwise 1864 mode of Group OSCORE. This approach is limited to group requests 1865 that are safe (in the RESTful sense) to process and do not yield side 1866 effects at the server. As for any protected group request, it 1867 requires the clients and all the servers in the CoAP group to have 1868 already joined the correct OSCORE group. 1870 Starting from the same plain CoAP request, this allows different 1871 clients in the OSCORE group to deterministically generate a same 1872 request protected with Group OSCORE, which is sent to the proxy for 1873 being forwarded to the CoAP group. The proxy can now effectively 1874 cache the resulting responses from the servers in the CoAP group, 1875 since the same plain CoAP request will result again in the same 1876 Deterministic Request and thus will produce a cache hit. 1878 When caching of Group OSCORE secured responses is enabled at the 1879 proxy, the same as defined in Section 3.4.3 applies, with respect to 1880 cache entries and their lifetimes. 1882 Note that different Deterministic Requests result in different cache 1883 entries at the proxy. This includes the case where different plain 1884 group requests differ only in their set of Multi-ETag Options. 1886 That is, even though the servers would produce the same plain CoAP 1887 responses in reply to the different Deterministic Requests, those 1888 will result in different protected responses to each respective 1889 Deterministic Request, and hence in different cache entries at the 1890 proxy. 1892 Thus, given a plain group request, a client needs to reuse the same 1893 set of Multi-ETag Options, in order to send that group request as a 1894 Deterministic Request that can actually produce a cache hit at the 1895 proxy. However, while this would prevent the caching at the proxy to 1896 be inefficient and unnecessarily redundant, it would also limit the 1897 flexibility of end-to-end response revalidation for a client. 1899 5.2.2. Validation of Responses 1901 When directly interacting with the servers in the CoAP group to 1902 refresh its cache entries, the proxy cannot rely on response 1903 revalidation anymore. In fact, responses protected with Group OSCORE 1904 cannot have 2.03 (Valid) as Outer Code. Response revalidation 1905 remains possible end-to-end between the client and the servers in the 1906 group, by means of including inner ETag Option(s) or inner Multi-ETag 1907 Option(s). 1909 Finally, it is not possible for a client to revalidate responses to a 1910 group request from an aggregated cache entry at the proxy, by using 1911 the outer Group-ETag Option as defined in Section 3.4.3.1. In fact, 1912 that would require the proxy to respond with an unprotected 2.03 1913 (Valid) response potentially. However, success responses have to be 1914 protected with Group OSCORE, so cannot have 2.03 (Valid) as Outer 1915 Code. 1917 6. Security Considerations 1919 This section provides security considerations for CoAP group 1920 communication using IP multicast. 1922 6.1. CoAP NoSec Mode 1924 CoAP group communication, if not protected, is vulnerable to all the 1925 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 1927 Thus, for sensitive and mission-critical applications (e.g., health 1928 monitoring systems and alarm monitoring systems), it is NOT 1929 RECOMMENDED to deploy CoAP group communication in NoSec mode. 1931 Without application-layer security, CoAP group communication SHOULD 1932 only be deployed in applications that are non-critical, and that do 1933 not involve or may have an impact on sensitive data and personal 1934 sphere. These include, e.g., read-only temperature sensors deployed 1935 in non-sensitive environments, where the client reads out the values 1936 but does not use the data to control actuators or to base an 1937 important decision on. 1939 Discovery of devices and resources is a typical use case where NoSec 1940 mode is applied, since the devices involved do not have yet 1941 configured any mutual security relations at the time the discovery 1942 takes place. 1944 6.2. Group OSCORE 1946 Group OSCORE provides end-to-end application-level security. This 1947 has many desirable properties, including maintaining security 1948 assurances while forwarding traffic through intermediaries (proxies). 1949 Application-level security also tends to more cleanly separate 1950 security from the dynamics of group membership (e.g., the problem of 1951 distributing security keys across large groups with many members that 1952 come and go). 1954 For sensitive and mission-critical applications, CoAP group 1955 communication MUST be protected by using Group OSCORE as specified in 1956 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 1957 from Section 10 of [I-D.ietf-core-oscore-groupcomm] hold for this 1958 specification. 1960 6.2.1. Group Key Management 1962 A key management scheme for secure revocation and renewal of group 1963 security material, namely group rekeying, should be adopted in OSCORE 1964 groups. In particular, the key management scheme should preserve 1965 backward and forward security in the OSCORE group, if the application 1966 requires so (see Section 3.1 of [I-D.ietf-core-oscore-groupcomm]). 1968 Group policies should also take into account the time that the key 1969 management scheme requires to rekey the group, on one hand, and the 1970 expected frequency of group membership changes, i.e. nodes' joining 1971 and leaving, on the other hand. 1973 In fact, it may be desirable to not rekey the group upon every single 1974 membership change, in case members' joining and leaving are frequent, 1975 and at the same time a single group rekeying instance takes a non- 1976 negligible time to complete. 1978 In such a case, the Group Manager may consider to rekey the group, 1979 e.g., after a minimum number of nodes has joined or left the group 1980 within a pre-defined time interval, or according to communication 1981 patterns with predictable time intervals of network inactivity. This 1982 would prevent paralyzing communications in the group, when a slow 1983 rekeying scheme is used and frequently invoked. 1985 This comes at the cost of not continuously preserving backward and 1986 forward security, since group rekeying might not occur upon every 1987 single group membership change. That is, most recently joined nodes 1988 would have access to the security material used prior to their join, 1989 and thus be able to access past group communications protected with 1990 that security material. Similarly, until the group is rekeyed, most 1991 recently left nodes would preserve access to group communications 1992 protected with the retained security material. 1994 6.2.2. Source Authentication 1996 Both the group mode and the pairwise mode of Group OSCORE ensure 1997 source authentication of messages exchanged by CoAP endpoints through 1998 CoAP group communication. 2000 To this end, outgoing messages are either countersigned by the 2001 message sender endpoint with its own private key (group mode), or 2002 protected with a symmetric key, which is in turn derived using the 2003 asymmetric keys of the message sender and recipient (pairwise mode). 2005 Thus, both modes allow a recipient CoAP endpoint to verify that a 2006 message has actually been originated by a specific and identified 2007 member of the OSCORE group. 2009 Appendix F of [I-D.ietf-core-oscore-groupcomm] discusses a number of 2010 cases where a recipient CoAP endpoint may skip the verification of 2011 countersignatures in messages protected with the group mode, possibly 2012 on a per-message basis. However, this is NOT RECOMMENDED. That is, 2013 a CoAP endpoint receiving a message secured with the group mode of 2014 Group OSCORE SHOULD always verify the countersignature. 2016 6.2.3. Countering Attacks 2018 As discussed below, Group OSCORE addresses a number of security 2019 attacks mentioned in Section 11 of [RFC7252], with particular 2020 reference to their execution over IP multicast. 2022 o Since Group OSCORE provides end-to-end confidentiality and 2023 integrity of request/response messages, proxies in multicast 2024 settings cannot break message protection, and thus cannot act as 2025 man-in-the-middle beyond their legitimate duties (see Section 11.2 2026 of [RFC7252]). In fact, intermediaries such as proxies are not 2027 assumed to have access to the OSCORE Security Context used by 2028 group members. Also, with the notable addition of 2029 countersignatures for the group mode, Group OSCORE protects 2030 messages using the same procedure as OSCORE (see Sections 8.1 and 2031 8.3 of [I-D.ietf-core-oscore-groupcomm]), and especially processes 2032 CoAP options according to the same classification in U/I/E 2033 classes. 2035 o Group OSCORE protects against amplification attacks (see 2036 Section 11.3 of [RFC7252]), which are made e.g. by injecting 2037 (small) requests over IP multicast from the (spoofed) IP address 2038 of a victim client, and thus triggering the transmission of 2039 several (much bigger) responses back to that client. In fact, 2040 upon receiving a request over IP multicast as protected with Group 2041 OSCORE in group mode, a server is able to verify whether the 2042 request is fresh and originates from the alleged sender in the 2043 OSCORE group, by verifying the countersignature included in the 2044 request using the public key of that sender (see Section 8.2 of 2045 [I-D.ietf-core-oscore-groupcomm]). Furthermore, as also discussed 2046 in Section 8 of [I-D.ietf-core-oscore-groupcomm], it is 2047 recommended that servers failing to decrypt and verify an incoming 2048 message do not send back any error message. 2050 o Group OSCORE limits the impact of attacks based on IP spoofing 2051 also over IP multicast (see Section 11.4 of [RFC7252]). In fact, 2052 requests and corresponding responses sent in the OSCORE group can 2053 be correctly generated only by legitimate group members. 2055 Within an OSCORE group, the shared symmetric-key security material 2056 strictly provides only group-level authentication (see 2057 Section 10.1 of [I-D.ietf-core-oscore-groupcomm]). However, 2058 source authentication of messages is also ensured, both in the 2059 group mode by means of countersignatures (see Sections 8.1 and 8.3 2060 of [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by 2061 using additionally derived pairwise keys (see Sections 9.1 and 9.3 2062 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints 2063 can verify a message to be originated by the alleged, identifiable 2064 sender in the OSCORE group. 2066 Note that the server may additionally rely on the Echo Option for 2067 CoAP described in [I-D.ietf-core-echo-request-tag], in order to 2068 verify the aliveness and reachability of the client sending a 2069 request from a particular IP address. 2071 o Group OSCORE does not require group members to be equipped with a 2072 good source of entropy for generating security material (see 2073 Section 11.6 of [RFC7252]), and thus does not contribute to create 2074 an entropy-related attack vector against such (constrained) CoAP 2075 endpoints. In particular, the symmetric keys used for message 2076 encryption and decryption are derived through the same HMAC-based 2077 HKDF scheme used for OSCORE (see Section 3.2 of [RFC8613]). 2078 Besides, the OSCORE Master Secret used in such derivation is 2079 securely generated by the Group Manager responsible for the OSCORE 2080 group, and securely provided to the CoAP endpoints when they join 2081 the group. 2083 o Group OSCORE prevents to make any single group member a target for 2084 subverting security in the whole OSCORE group (see Section 11.6 of 2085 [RFC7252]), even though all group members share (and can derive) 2086 the same symmetric-key security material used in the OSCORE group 2087 (see Section 10.1 of [I-D.ietf-core-oscore-groupcomm]). In fact, 2088 source authentication is always ensured for exchanged CoAP 2089 messages, as verifiable to be originated by the alleged, 2090 identifiable sender in the OSCORE group. This relies on including 2091 a countersignature computed with a node's individual private key 2092 (in the group mode), or on protecting messages with a pairwise 2093 symmetric key, which is in turn derived from the asymmetric keys 2094 of the sender and recipient CoAP endpoints (in the pairwise mode). 2096 6.3. Replay of Non-Confirmable Messages 2098 Since all requests sent over IP multicast are Non-confirmable, a 2099 client might not be able to know if an adversary has actually 2100 captured one of its transmitted requests and later re-injected it in 2101 the group as a replay to the server nodes. In fact, even if the 2102 servers sent back responses to the replayed request, the client would 2103 typically not have a valid matching request active anymore so this 2104 attack would not accomplish anything in the client. 2106 If Group OSCORE is used, such a replay attack on the servers is 2107 prevented, since a client protects every different request with a 2108 different Sequence Number value, which is in turn included as Partial 2109 IV in the protected message and takes part in the construction of the 2110 AEAD cipher nonce. Thus, a server would be able to detect the 2111 replayed request, by checking the conveyed Partial IV against its own 2112 replay window in the OSCORE Recipient Context associated to the 2113 client. 2115 This requires a server to have a synchronized, up to date view of the 2116 sequence number used by the client. If such synchronization is lost, 2117 e.g. due to a reboot, or suspected so, the server should use one of 2118 the methods described in Appendix E of 2119 [I-D.ietf-core-oscore-groupcomm], such as the one based on the Echo 2120 Option for CoAP described in [I-D.ietf-core-echo-request-tag], in 2121 order to (re-)synchronize with the client's sequence number. 2123 6.4. Use of CoAP No-Response Option 2125 When CoAP group communication is used in CoAP NoSec (No Security) 2126 mode (see Section 4), the CoAP No-Response Option [RFC7967] could be 2127 misused by a malicious client to evoke as much responses from servers 2128 to a multicast request as possible, by using the value '0' - 2129 Interested in all responses. This even overrides the default 2130 behaviour of a CoAP server to suppress the response in case there is 2131 nothing of interest to respond with. Therefore, this option can be 2132 used to perform an amplification attack. 2134 A proposed mitigation is to only allow this option to relax the 2135 standard suppression rules for a resource in case the option is sent 2136 by an authenticated client. If sent by an unauthenticated client, 2137 the option can be used to expand the classes of responses suppressed 2138 compared to the default rules but not to reduce the classes of 2139 responses suppressed. 2141 6.5. 6LoWPAN 2143 In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior 2144 to transmission. A 6LoWPAN Router that forwards a fragmented packet 2145 may have a relatively high impact on the occupation of the wireless 2146 channel and may locally experience high memory load due to packet 2147 buffering. For example, the MPL [RFC7731] protocol requires an MPL 2148 Forwarder to store the packet for a longer duration, to allow 2149 multiple forwarding transmissions to neighboring Forwarders. If one 2150 or more of the fragments are not received correctly by an MPL 2151 Forwarder during its packet reassembly time window, the Forwarder 2152 discards all received fragments and at a future point in time it 2153 needs to receive again all the packet fragments (this time, possibly 2154 from another neighboring MPL Forwarder). 2156 For these reasons, a fragmented IPv6 multicast packet is a possible 2157 attack vector in a Denial of Service (DoS) amplification attack. See 2158 Section 11.3 of [RFC7252] for more details on amplification. To 2159 mitigate the risk, applications sending multicast IPv6 requests to 2160 6LoWPAN hosted CoAP servers SHOULD limit the size of the request to 2161 avoid 6LoWPAN fragmentation of the request packet. A 6LoWPAN Router 2162 or multicast forwarder SHOULD deprioritize forwarding for multi- 2163 fragment 6LoWPAN multicast packets. Also, a 6LoWPAN Border Router 2164 SHOULD implement multicast packet filtering to prevent unwanted 2165 multicast traffic from entering a 6LoWPAN network from the outside. 2166 For example, it could filter out all multicast packet for which there 2167 is no known multicast listener on the 6LoWPAN network. See 2168 Section 3.9 for protocols that allow multicast listeners to signal 2169 which groups they would like to listen to. 2171 6.6. Wi-Fi 2173 In a home automation scenario using Wi-Fi, Wi-Fi security should be 2174 enabled to prevent rogue nodes from joining. The Customer Premises 2175 Equipment (CPE) that enables access to the Internet should also have 2176 its IP multicast filters set so that it enforces multicast scope 2177 boundaries to isolate local multicast groups from the rest of the 2178 Internet (e.g., as per [RFC6092]). In addition, the scope of IP 2179 multicast transmissions and listeners should be site-local (5) or 2180 smaller. For site-local scope, the CPE will be an appropriate 2181 multicast scope boundary point. 2183 6.7. Monitoring 2185 6.7.1. General Monitoring 2187 CoAP group communication can be used to control a set of related 2188 devices: for example, simultaneously turn on all the lights in a 2189 room. This intrinsically exposes the group to some unique monitoring 2190 risks that devices not in a group are not as vulnerable to. For 2191 example, assume an attacker is able to physically see a set of lights 2192 turn on in a room. Then the attacker can correlate an observed CoAP 2193 group communication message to the observed coordinated group action 2194 - even if the CoAP message is (partly) encrypted. 2195 This will give the attacker side-channel information to plan further 2196 attacks (e.g., by determining the members of the group some network 2197 topology information may be deduced). 2199 6.7.2. Pervasive Monitoring 2201 A key additional threat consideration for group communication is 2202 pervasive monitoring [RFC7258]. CoAP group communication solutions 2203 that are built on top of IP multicast need to pay particular heed to 2204 these dangers. This is because IP multicast is easier to intercept 2205 compared to IP unicast. Also, CoAP traffic is typically used for the 2206 Internet of Things. This means that CoAP multicast may be used for 2207 the control and monitoring of critical infrastructure (e.g., lights, 2208 alarms, HVAC, electrical grid, etc.) that may be prime targets for 2209 attack. 2211 For example, an attacker may attempt to record all the CoAP traffic 2212 going over a smart grid (i.e., networked electrical utility) and try 2213 to determine critical nodes for further attacks. For example, the 2214 source node (controller) sends out CoAP group communication messages 2215 which easily identifies it as a controller. CoAP multicast traffic 2216 is inherently more vulnerable compared to unicast, as the same packet 2217 may be replicated over many more links, leading to a higher 2218 probability of packet capture by a pervasive monitoring system. 2220 One mitigation is to restrict the scope of IP multicast to the 2221 minimal scope that fulfills the application need. See the congestion 2222 control recommendations in the last bullet of 2223 Section 3.5 to minimize the scope. Thus, for example, realm-local IP 2224 multicast scope is always preferred over site-local scope IP 2225 multicast if this fulfills the application needs. 2227 Even if all CoAP multicast traffic is encrypted/protected, an 2228 attacker may still attempt to capture this traffic and perform an 2229 off-line attack in the future. 2231 7. IANA Considerations 2233 This document has the following actions for IANA. 2235 7.1. CoAP Option Numbers Registry 2237 IANA is asked to enter the following option numbers to the "CoAP 2238 Option Numbers" registry defined in [RFC7252] within the "CoRE 2239 Parameters" registry. 2241 +--------+-------------+-----------------+ 2242 | Number | Name | Reference | 2243 +--------+-------------+-----------------+ 2244 | TBD1 | Multi-ETag | [This document] | 2245 +--------+-------------+-----------------+ 2246 | TBD2 | Group-ETag | [This document] | 2247 +--------+-------------+-----------------+ 2249 8. References 2251 8.1. Normative References 2253 [I-D.ietf-core-echo-request-tag] 2254 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 2255 Request-Tag, and Token Processing", draft-ietf-core-echo- 2256 request-tag-12 (work in progress), February 2021. 2258 [I-D.ietf-core-oscore-groupcomm] 2259 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 2260 J. Park, "Group OSCORE - Secure Group Communication for 2261 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 2262 progress), February 2021. 2264 [I-D.ietf-cose-rfc8152bis-algs] 2265 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2266 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 2267 (work in progress), September 2020. 2269 [I-D.ietf-cose-rfc8152bis-struct] 2270 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2271 Structures and Process", draft-ietf-cose-rfc8152bis- 2272 struct-15 (work in progress), February 2021. 2274 [I-D.tiloca-core-observe-multicast-notifications] 2275 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 2276 "Observe Notifications as CoAP Multicast Responses", 2277 draft-tiloca-core-observe-multicast-notifications-05 (work 2278 in progress), February 2021. 2280 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2281 Communication Layers", STD 3, RFC 1122, 2282 DOI 10.17487/RFC1122, October 1989, 2283 . 2285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2286 Requirement Levels", BCP 14, RFC 2119, 2287 DOI 10.17487/RFC2119, March 1997, 2288 . 2290 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2291 Thyagarajan, "Internet Group Management Protocol, Version 2292 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2293 . 2295 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2296 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2297 DOI 10.17487/RFC3810, June 2004, 2298 . 2300 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2301 Control Message Protocol (ICMPv6) for the Internet 2302 Protocol Version 6 (IPv6) Specification", STD 89, 2303 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2304 . 2306 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2307 "Transmission of IPv6 Packets over IEEE 802.15.4 2308 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2309 . 2311 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2312 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2313 DOI 10.17487/RFC6282, September 2011, 2314 . 2316 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2317 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2318 . 2320 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2321 Application Protocol (CoAP)", RFC 7252, 2322 DOI 10.17487/RFC7252, June 2014, 2323 . 2325 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2326 Application Protocol (CoAP)", RFC 7641, 2327 DOI 10.17487/RFC7641, September 2015, 2328 . 2330 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2331 the Constrained Application Protocol (CoAP)", RFC 7959, 2332 DOI 10.17487/RFC7959, August 2016, 2333 . 2335 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 2336 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 2337 the Constrained Application Protocol (CoAP)", RFC 8075, 2338 DOI 10.17487/RFC8075, February 2017, 2339 . 2341 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 2342 FETCH Methods for the Constrained Application Protocol 2343 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 2344 . 2346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2348 May 2017, . 2350 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2351 Definition Language (CDDL): A Notational Convention to 2352 Express Concise Binary Object Representation (CBOR) and 2353 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2354 June 2019, . 2356 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2357 "Object Security for Constrained RESTful Environments 2358 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2359 . 2361 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2362 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2363 . 2365 8.2. Informative References 2367 [Californium] 2368 Eclipse Foundation, "Eclipse Californium", March 2019, 2369 . 2373 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 2374 CoAP Server & Client in Go", March 2019, 2375 . 2377 [I-D.amsuess-core-cachable-oscore] 2378 Amsuess, C. and M. Tiloca, "Cachable OSCORE", draft- 2379 amsuess-core-cachable-oscore-01 (work in progress), 2380 February 2021. 2382 [I-D.ietf-ace-key-groupcomm-oscore] 2383 Tiloca, M., Park, J., and F. Palombini, "Key Management 2384 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 2385 oscore-10 (work in progress), February 2021. 2387 [I-D.ietf-ace-oauth-authz] 2388 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2389 H. Tschofenig, "Authentication and Authorization for 2390 Constrained Environments (ACE) using the OAuth 2.0 2391 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 2392 (work in progress), February 2021. 2394 [I-D.ietf-ace-oscore-gm-admin] 2395 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 2396 Hartke, "Admin Interface for the OSCORE Group Manager", 2397 draft-ietf-ace-oscore-gm-admin-02 (work in progress), 2398 February 2021. 2400 [I-D.ietf-core-coap-pubsub] 2401 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2402 Subscribe Broker for the Constrained Application Protocol 2403 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 2404 progress), September 2019. 2406 [I-D.ietf-core-resource-directory] 2407 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 2408 Stok, "CoRE Resource Directory", draft-ietf-core-resource- 2409 directory-26 (work in progress), November 2020. 2411 [I-D.tiloca-core-groupcomm-proxy] 2412 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 2413 Communication", draft-tiloca-core-groupcomm-proxy-03 (work 2414 in progress), February 2021. 2416 [I-D.tiloca-core-oscore-discovery] 2417 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 2418 Groups with the CoRE Resource Directory", draft-tiloca- 2419 core-oscore-discovery-08 (work in progress), February 2420 2020. 2422 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2423 Capabilities in Customer Premises Equipment (CPE) for 2424 Providing Residential IPv6 Internet Service", RFC 6092, 2425 DOI 10.17487/RFC6092, January 2011, 2426 . 2428 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2429 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2430 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2431 Low-Power and Lossy Networks", RFC 6550, 2432 DOI 10.17487/RFC6550, March 2012, 2433 . 2435 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 2436 the Internet Group Management Protocol (IGMP) and 2437 Multicast Listener Discovery (MLD) for Routers in Mobile 2438 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 2439 May 2012, . 2441 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2442 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2443 2014, . 2445 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 2446 DOI 10.17487/RFC7346, August 2014, 2447 . 2449 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 2450 the Constrained Application Protocol (CoAP)", RFC 7390, 2451 DOI 10.17487/RFC7390, October 2014, 2452 . 2454 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 2455 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 2456 February 2016, . 2458 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2459 Bose, "Constrained Application Protocol (CoAP) Option for 2460 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2461 August 2016, . 2463 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2464 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 2465 Application Protocol) over TCP, TLS, and WebSockets", 2466 RFC 8323, DOI 10.17487/RFC8323, February 2018, 2467 . 2469 [RFC8710] Fossati, T., Hartke, K., and C. Bormann, "Multipart 2470 Content-Format for the Constrained Application Protocol 2471 (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020, 2472 . 2474 Appendix A. Use Cases 2476 To illustrate where and how CoAP-based group communication can be 2477 used, this section summarizes the most common use cases. These use 2478 cases include both secured and non-secured CoAP usage. Each 2479 subsection below covers one particular category of use cases for 2480 CoRE. Within each category, a use case may cover multiple 2481 application areas such as home IoT, commercial building IoT (sensing 2482 and control), industrial IoT/control, or environmental sensing. 2484 A.1. Discovery 2486 Discovery of physical devices in a network, or discovery of 2487 information entities hosted on network devices, are operations that 2488 are usually required in a system during the phases of setup or 2489 (re)configuration. When a discovery use case involves devices that 2490 need to interact without having been configured previously with a 2491 common security context, unsecured CoAP communication is typically 2492 used. Discovery may involve a request to a directory server, which 2493 provides services to aid clients in the discovery process. One 2494 particular type of directory server is the CoRE Resource Directory 2495 [I-D.ietf-core-resource-directory]; and there may be other types of 2496 directories that can be used with CoAP. 2498 A.1.1. Distributed Device Discovery 2500 Device discovery is the discovery and identification of networked 2501 devices - optionally only devices of a particular class, type, model, 2502 or brand. Group communication is used for distributed device 2503 discovery, if a central directory server is not used. Typically in 2504 distributed device discovery, a multicast request is sent to a 2505 particular address (or address range) and multicast scope of 2506 interest, and any devices configured to be discoverable will respond 2507 back. For the alternative solution of centralized device discovery a 2508 central directory server is accessed through unicast, in which case 2509 group communication is not needed. This requires that the address of 2510 the central directory is either preconfigured in each device or 2511 configured during operation using a protocol. 2513 In CoAP, device discovery can be implemented by CoAP resource 2514 discovery requesting (GET) a particular resource that the sought 2515 device class, type, model or brand is known to respond to. It can 2516 also be implemented using CoAP resource discovery (Section 7 of 2517 [RFC7252]) and the CoAP query interface defined in Section 4 of 2518 [RFC6690] to find these particular resources. Also, a multicast GET 2519 request to /.well-known/core can be used to discover all CoAP 2520 devices. 2522 A.1.2. Distributed Service Discovery 2524 Service discovery is the discovery and identification of particular 2525 services hosted on network devices. Services can be identified by 2526 one or more parameters such as ID, name, protocol, version and/or 2527 type. Distributed service discovery involves group communication to 2528 reach individual devices hosting a particular service; with a central 2529 directory server not being used. 2531 In CoAP, services are represented as resources and service discovery 2532 is implemented using resource discovery (Section 7 of [RFC7252]) and 2533 the CoAP query interface defined in Section 4 of [RFC6690]. 2535 A.1.3. Directory Discovery 2537 This use case is a specific sub-case of Distributed Service Discovery 2538 (Appendix A.1.2), in which a device needs to identify the location of 2539 a Directory on the network to which it can e.g. register its own 2540 offered services, or to which it can perform queries to identify and 2541 locate other devices/services it needs to access on the network. 2542 Section 3.3 of [RFC7390] shows an example of discovering a CoRE 2543 Resource Directory using CoAP group communication. As defined in 2544 [I-D.ietf-core-resource-directory], a resource directory is a web 2545 entity that stores information about web resources and implements 2546 REST interfaces for registration and lookup of those resources. For 2547 example, a device can register itself to a resource directory to let 2548 it be found by other devices and/or applications. 2550 A.2. Operational Phase 2552 Operational phase use cases describe those operations that occur most 2553 frequently in a networked system, during its operational lifetime and 2554 regular operation. Regular usage is when the applications on 2555 networked devices perform the tasks they were designed for and 2556 exchange of application-related data using group communication 2557 occurs. Processes like system reconfiguration, group changes, 2558 system/device setup, extra group security changes, etc. are not part 2559 of regular operation. 2561 A.2.1. Actuator Group Control 2563 Group communication can be beneficial to control actuators that need 2564 to act in synchrony, as a group, with strict timing (latency) 2565 requirements. Examples are office lighting, stage lighting, street 2566 lighting, or audio alert/Public Address systems. Sections 3.4 and 2567 3.5 of [RFC7390] show examples of lighting control of a group of 2568 6LoWPAN-connected lights. 2570 A.2.2. Device Group Status Request 2572 To properly monitor the status of systems, there may be a need for 2573 ad-hoc, unplanned status updates. Group communication can be used to 2574 quickly send out a request to a (potentially large) number of devices 2575 for specific information. Each device then responds back with the 2576 requested data. Those devices that did not respond to the request 2577 can optionally be polled again via reliable unicast communication to 2578 complete the dataset. The device group may be defined e.g. as "all 2579 temperature sensors on floor 3", or "all lights in wing B". For 2580 example, it could be a status request for device temperature, most 2581 recent sensor event detected, firmware version, network load, and/or 2582 battery level. 2584 A.2.3. Network-wide Query 2586 In some cases a whole network or subnet of multiple IP devices needs 2587 to be queried for status or other information. This is similar to 2588 the previous use case except that the device group is not defined in 2589 terms of its function/type but in terms of its network location. 2590 Technically this is also similar to distributed service discovery 2591 (Appendix A.1.2) where a query is processed by all devices on a 2592 network - except that the query is not about services offered by the 2593 device, but rather specific operational data is requested. 2595 A.2.4. Network-wide / Group Notification 2597 In some cases a whole network, or subnet of multiple IP devices, or a 2598 specific target group needs to be notified of a status change or 2599 other information. This is similar to the previous two use cases 2600 except that the recipients are not expected to respond with some 2601 information. Unreliable notification can be acceptable in some use 2602 cases, in which a recipient does not respond with a confirmation of 2603 having received the notification. In such a case, the receiving CoAP 2604 server does not have to create a CoAP response. If the sender needs 2605 confirmation of reception, the CoAP servers can be configured for 2606 that resource to respond with a 2.xx success status after processing 2607 a notification request successfully. 2609 A.3. Software Update 2611 Multicast can be useful to efficiently distribute new software 2612 (firmware, image, application, etc.) to a group of multiple devices. 2613 In this case, the group is defined in terms of device type: all 2614 devices in the target group are known to be capable of installing and 2615 running the new software. The software is distributed as a series of 2616 smaller blocks that are collected by all devices and stored in 2617 memory. All devices in the target group are usually responsible for 2618 integrity verification of the received software; which can be done 2619 per-block or for the entire software image once all blocks have been 2620 received. Due to the inherent unreliability of CoAP multicast, there 2621 needs to be a backup mechanism (e.g. implemented using CoAP unicast) 2622 by which a device can individually request missing blocks of a whole 2623 software image/entity. Prior to multicast software update, the group 2624 of recipients can be separately notified that there is new software 2625 available and coming, using the above network-wide or group 2626 notification. 2628 Appendix B. Document Updates 2630 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2632 B.1. Version -02 to -03 2634 o Multiple responses from same server handled at the application. 2636 o Clarifications about issues with forward-proxies. 2638 o Operations for reverse-proxies. 2640 o Caching of responses at proxies. 2642 o Client-Server response revalidation, with Multi-ETag Option. 2644 o Client-Proxy response revalidation, with the Group-ETag Option. 2646 B.2. Version -01 to -02 2648 o Clarified relation between security groups and application groups. 2650 o Considered also FETCH for requests over IP multicast. 2652 o More details on Observe re-registration. 2654 o More details on Proxy intermediaries. 2656 o More details on servers changing port number in the response. 2658 o Usage of the Uri-Host Option to indicate an application group. 2660 o Response suppression based on classes of error codes. 2662 B.3. Version -00 to -01 2664 o Clarifications on group memberships for the different group types. 2666 o Simplified description of Token reusage, compared to the unicast 2667 case. 2669 o More details on the rationale for response suppression. 2671 o Clarifications of creation and management of security groups. 2673 o Clients more knowledgeable than proxies about stopping receiving 2674 responses. 2676 o Cancellation of group observations. 2678 o Clarification on multicast scope to use. 2680 o Both the group mode and pairwise mode of Group OSCORE are 2681 considered. 2683 o Updated security considerations. 2685 o Editorial improvements. 2687 Acknowledgments 2689 The authors sincerely thank Christian Amsuess, Carsten Bormann, 2690 Thomas Fossati, Rikard Hoeglund and Jim Schaad for their comments and 2691 feedback. 2693 The work on this document has been partly supported by VINNOVA and 2694 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2695 (Grant agreement 952652). 2697 Authors' Addresses 2699 Esko Dijk 2700 IoTconsultancy.nl 2701 \________________\ 2702 Utrecht 2703 Netherlands 2705 Email: esko.dijk@iotconsultancy.nl 2707 Chonggang Wang 2708 InterDigital 2709 1001 E Hector St, Suite 300 2710 Conshohocken PA 19428 2711 United States 2713 Email: Chonggang.Wang@InterDigital.com 2715 Marco Tiloca 2716 RISE AB 2717 Isafjordsgatan 22 2718 Kista SE-16440 Stockholm 2719 Sweden 2721 Email: marco.tiloca@ri.se