idnits 2.17.1 draft-ietf-core-groupcomm-bis-04.txt: -(2049): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2223): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. 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 (12 July 2021) is 1017 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-12 ** 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 (-16) exists of draft-ietf-ace-key-groupcomm-oscore-11 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-43 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-03 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-01 == Outdated reference: A later version (-03) exists of draft-mattsson-core-coap-attacks-00 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-04 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-09 Summary: 1 error (**), 0 flaws (~~), 12 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: 13 January 2022 RISE AB 8 12 July 2021 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-ietf-core-groupcomm-bis-04 13 Abstract 15 This document specifies the use of the Constrained Application 16 Protocol (CoAP) for group communication, including the use of UDP/IP 17 multicast as the default underlying data transport. Both unsecured 18 and secured CoAP group communication are specified. Security is 19 achieved by use of the Group Object Security for Constrained RESTful 20 Environments (Group OSCORE) protocol. The target application area of 21 this specification is any group communication use cases that involve 22 resource-constrained devices or networks that support CoAP. This 23 document replaces RFC7390, while it updates RFC7252 and RFC7641. 25 Discussion Venues 27 This note is to be removed before publishing as an RFC. 29 Discussion of this document takes place on the CORE Working Group 30 mailing list (core@ietf.org), which is archived at 31 https://mailarchive.ietf.org/arch/browse/core/ 32 (https://mailarchive.ietf.org/arch/browse/core/). 34 Source for this draft and an issue tracker can be found at 35 https://github.com/core-wg/groupcomm-bis (https://github.com/core-wg/ 36 groupcomm-bis). 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 13 January 2022. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Group Definition and Group Configuration . . . . . . . . . . 6 75 2.1. Group Definition . . . . . . . . . . . . . . . . . . . . 6 76 2.1.1. CoAP Group . . . . . . . . . . . . . . . . . . . . . 6 77 2.1.2. Application Group . . . . . . . . . . . . . . . . . . 6 78 2.1.3. Security Group . . . . . . . . . . . . . . . . . . . 7 79 2.1.4. Relations Between Group Types . . . . . . . . . . . . 7 80 2.2. Group Configuration . . . . . . . . . . . . . . . . . . . 9 81 2.2.1. Group Naming . . . . . . . . . . . . . . . . . . . . 9 82 2.2.2. Group Creation and Membership . . . . . . . . . . . . 11 83 2.2.3. Group Discovery . . . . . . . . . . . . . . . . . . . 12 84 2.2.4. Group Maintenance . . . . . . . . . . . . . . . . . . 13 85 3. CoAP Usage in Group Communication . . . . . . . . . . . . . . 13 86 3.1. Request/Response Model . . . . . . . . . . . . . . . . . 13 87 3.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 88 3.1.2. Response Suppression . . . . . . . . . . . . . . . . 14 89 3.1.3. Repeating a Request . . . . . . . . . . . . . . . . . 14 90 3.1.4. Request/Response Matching and Distinguishing 91 Responses . . . . . . . . . . . . . . . . . . . . . . 15 92 3.1.5. Token Reuse . . . . . . . . . . . . . . . . . . . . . 15 93 3.1.6. Client Handling of Multiple Responses With Same 94 Token . . . . . . . . . . . . . . . . . . . . . . . . 16 95 3.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 3.2.1. Freshness Model . . . . . . . . . . . . . . . . . . . 18 97 3.2.2. Validation Model . . . . . . . . . . . . . . . . . . 18 98 3.3. URI Path Selection . . . . . . . . . . . . . . . . . . . 19 99 3.4. Port Selection for UDP Transport . . . . . . . . . . . . 20 100 3.5. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 20 101 3.5.1. Forward-Proxies . . . . . . . . . . . . . . . . . . . 21 102 3.5.2. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 22 103 3.6. Congestion Control . . . . . . . . . . . . . . . . . . . 24 104 3.7. Observing Resources . . . . . . . . . . . . . . . . . . . 25 105 3.8. Block-Wise Transfer . . . . . . . . . . . . . . . . . . . 27 106 3.9. Transport Protocols . . . . . . . . . . . . . . . . . . . 28 107 3.9.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 28 108 3.9.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 29 109 3.9.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 29 110 3.9.4. Other Transports . . . . . . . . . . . . . . . . . . 29 111 3.10. Interworking with Other Protocols . . . . . . . . . . . . 30 112 3.10.1. MLD/MLDv2/IGMP/IGMPv3 . . . . . . . . . . . . . . . 30 113 3.10.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . 30 114 3.10.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . 31 115 4. Unsecured Group Communication . . . . . . . . . . . . . . . . 32 116 5. Secured Group Communication using Group OSCORE . . . . . . . 32 117 5.1. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 32 118 5.2. Secure Group Maintenance . . . . . . . . . . . . . . . . 34 119 5.3. Proxy Security . . . . . . . . . . . . . . . . . . . . . 35 120 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 121 6.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 36 122 6.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 37 123 6.2.1. Group Key Management . . . . . . . . . . . . . . . . 37 124 6.2.2. Source Authentication . . . . . . . . . . . . . . . . 38 125 6.2.3. Countering Attacks . . . . . . . . . . . . . . . . . 38 126 6.3. Risk of Amplification . . . . . . . . . . . . . . . . . . 40 127 6.4. Replay of Non-Confirmable Messages . . . . . . . . . . . 42 128 6.5. Use of CoAP No-Response Option . . . . . . . . . . . . . 42 129 6.6. 6LoWPAN and MPL . . . . . . . . . . . . . . . . . . . . . 43 130 6.7. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 43 131 6.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 44 132 6.8.1. General Monitoring . . . . . . . . . . . . . . . . . 44 133 6.8.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 44 134 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 135 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 136 8.1. Normative References . . . . . . . . . . . . . . . . . . 45 137 8.2. Informative References . . . . . . . . . . . . . . . . . 47 138 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 50 139 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 50 140 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 51 141 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 51 142 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 52 143 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 52 144 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 52 145 A.2.2. Device Group Status Request . . . . . . . . . . . . . 52 146 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 53 147 A.2.4. Network-wide / Group Notification . . . . . . . . . . 53 148 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 53 149 Appendix B. Multi-ETag Option . . . . . . . . . . . . . . . . . 54 150 B.1. Option Definition . . . . . . . . . . . . . . . . . . . . 54 151 B.2. Encoding of Server Addressing Information . . . . . . . . 55 152 B.3. Processing on the Client Side . . . . . . . . . . . . . . 56 153 B.4. Processing on the Server Side . . . . . . . . . . . . . . 57 154 B.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 58 155 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 58 156 C.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 58 157 C.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 59 158 C.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 59 159 C.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 59 160 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 60 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 163 1. Introduction 165 This document specifies group communication using the Constrained 166 Application Protocol (CoAP) [RFC7252], together with UDP/IP multicast 167 as the default transport for CoAP group communication messages. CoAP 168 is a RESTful communication protocol that is used in resource- 169 constrained nodes, and in resource-constrained networks where packet 170 sizes should be small. This area of use is summarized as Constrained 171 RESTful Environments (CoRE). 173 One-to-many group communication can be achieved in CoAP, by a client 174 using UDP/IP multicast data transport to send multicast CoAP request 175 messages. In response, each server in the addressed group sends a 176 response message back to the client over UDP/IP unicast. Notable 177 CoAP implementations supporting group communication include the 178 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 179 Foundation and the "Implementation of CoAP Server & Client in Go" 180 [Go-OCF] from the Open Connectivity Foundation (OCF). 182 Both unsecured and secured CoAP group communication are specified in 183 this document. Security is achieved by using Group Object Security 184 for Constrained RESTful Environments (Group OSCORE) 185 [I-D.ietf-core-oscore-groupcomm], which in turn builds on Object 186 Security for Constrained Restful Environments (OSCORE) [RFC8613]. 187 This method provides end-to-end application-layer security protection 188 of CoAP messages, by using CBOR Object Signing and Encryption (COSE) 189 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 191 All guidelines in [RFC7390] are updated by this document, which 192 replaces and obsoletes [RFC7390]. Furthermore, this document updates 193 [RFC7252], by specifying: a group request/response model; a response 194 validation model for responses to group requests; and the use of 195 Group OSCORE [I-D.ietf-core-oscore-groupcomm] to achieve security for 196 CoAP group communication. Finally, this document also updates 197 [RFC7641], by defining the multicast usage of the CoAP Observe Option 198 for both the GET and FETCH methods. 200 All sections in the body of this document are normative, while 201 appendices are informative. For additional background about use 202 cases for CoAP group communication in resource-constrained devices 203 and networks, see Appendix A. 205 1.1. Scope 207 For group communication, only those solutions that use CoAP messages 208 over a "one-to-many" (i.e., non-unicast) transport protocol are in 209 the scope of this document. There are alternative methods to achieve 210 group communication using CoAP, using unicast only. One example is 211 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 212 broker server that CoAP clients access via unicast communication. 213 These alternative methods may be usable for the same or similar use 214 cases as the ones targeted in this document. 216 This document defines UDP/IP multicast as the default transport 217 protocol for CoAP group requests, as in [RFC7252]. Other transport 218 protocols (which may include broadcast, non-IP multicast, geocast, 219 etc.) are not described in detail and are left for future work. 220 Although UDP/IP multicast transport is assumed in most of the text in 221 this document, we expect many of the considerations for UDP/IP 222 multicast can be re-used for alternative transport protocols. 224 Furthermore, this document defines Group OSCORE 225 [I-D.ietf-core-oscore-groupcomm] as the default group communication 226 security solution for CoAP. Security solutions for group 227 communication and configuration other than Group OSCORE are left for 228 future work. General principles for secure group configuration are 229 in scope. 231 1.2. Terminology 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 This specification requires readers to be familiar with CoAP 240 terminology [RFC7252]. Terminology related to group communication is 241 defined in Section 2.1. 243 Furthermore, "Security material" refers to any security keys, 244 counters or parameters stored in a device that are required to 245 participate in secure group communication with other devices. 247 2. Group Definition and Group Configuration 249 In the following, different group types are first defined in 250 Section 2.1. Then, Group configuration, including group creation and 251 maintenance by an application, user or commissioning entity is 252 considered in Section 2.2. 254 2.1. Group Definition 256 Three types of groups and their mutual relations are defined in this 257 section: CoAP group, application group, and security group. 259 2.1.1. CoAP Group 261 A CoAP group is defined as a set of CoAP endpoints, where each 262 endpoint is configured to receive CoAP group messages that are sent 263 to the group's associated IP multicast address and UDP port. An 264 endpoint may be a member of multiple CoAP groups by subscribing to 265 multiple IP multicast groups and/or listening on multiple UDP ports. 266 Group membership(s) of an endpoint may dynamically change over time. 267 A device sending a CoAP group message to a CoAP group is not 268 necessarily itself a member of this CoAP group: it is a member only 269 if it also has a CoAP endpoint listening on the group's associated IP 270 multicast address and UDP port. A CoAP group can be encoded within a 271 Group URI. This is defined as a CoAP URI that has the "coap" scheme 272 and includes in the authority part either an IP multicast address or 273 a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN)) 274 that can be resolved to an IP multicast address. A Group URI also 275 contains an optional UDP port number in the authority part. Group 276 URIs follow the regular CoAP URI syntax (see Section 6 of [RFC7252]). 278 2.1.2. Application Group 280 Besides CoAP groups, that have relevance at the level of IP networks 281 and CoAP endpoints, there are also application groups. An 282 application group is a set of CoAP server endpoints that share a 283 common set of CoAP resources. An endpoint may be a member of 284 multiple application groups. An application group has relevance at 285 the application level -- for example an application group could 286 denote all lights in an office room or all sensors in a hallway. A 287 client endpoint that sends a group communication message to an 288 application group is not necessarily itself a member of this 289 application group. There can be a one-to-one or a one-to-many 290 relation between a CoAP group and application group(s). An 291 application group identifier is optionally encoded explicitly in the 292 CoAP request, for example as a name in the URI path. If not 293 explicitly encoded, the application group is implicitly derived by 294 the receiver, based on information in the CoAP request. See 295 Section 2.2.1 for more details on identifying the application group. 297 2.1.3. Security Group 299 For secure group communication, a security group is required. A 300 security group is a group of endpoints that each store group security 301 material, such that they can mutually exchange secured messages and 302 verify secured messages. So, a client endpoint needs to be a member 303 of a security group in order to send a valid secured group 304 communication message to this group. An endpoint may be a member of 305 multiple security groups. There can be a one-to-one or a one-to-many 306 relation between security groups and CoAP groups. Also, there can be 307 a one-to-one or a one-to-many relation between security groups and 308 application groups. A special security group named "NoSec" 309 identifies group communication without any security at the transport 310 layer nor at the CoAP layer. 312 2.1.4. Relations Between Group Types 314 Using the above group type definitions, a CoAP group communication 315 message sent by an endpoint can be represented as a tuple that 316 contains one instance of each group type: 318 (application group, CoAP group, security group) 320 A special note is appropriate about the possible relation between 321 security groups and application groups. 323 On one hand, multiple application groups may use the same security 324 group. Thus, the same group security material is used to protect the 325 messages targeting any of those application groups. This has the 326 benefit that typically less storage, configuration and updating are 327 required for security material. In this case, a CoAP endpoint is 328 supposed to know the exact application group to refer to for each 329 message that is sent or received, based on, e.g., the used server 330 port number, the targeted resource, or the content and structure of 331 the message payload. 333 On the other hand, a single application group may use multiple 334 security groups. Thus, different messages targeting the resources of 335 the application group can be protected with different security 336 material. This can be convenient, for example, if the security 337 groups differ with respect to the cryptographic algorithms and 338 related parameters they use. In this case, a CoAP client can join 339 just one of the security groups, based on what it supports and 340 prefers, while a CoAP server in the application group would rather 341 have to join all of them. 343 Beyond this particular case, applications should be careful in 344 associating a same application group to multiple security groups. In 345 particular, it is NOT RECOMMENDED to use different security groups to 346 reflect different access policies for resources in a same application 347 group. That is, being a member of a security group actually grants 348 access only to exchange secured messages and enables authentication 349 of group members, while access control (authorization) to use 350 resources in the application group belongs to a separate security 351 domain. It has to be separately enforced by leveraging the resource 352 properties or through dedicated access control credentials assessed 353 by separate means. 355 Figure 1 summarizes the relations between the different types of 356 groups described above in UML class diagram notation. The class 357 attributes in square brackets are optionally defined. 359 +------------------------+ +--------------------+ 360 | Application group | | CoAP group | 361 |........................| |....................| 362 | | | | 363 | [ - group name ] +-----------------+ - IP mcast address | 364 | [ - group identifier ] | 1...N 1 | - UDP port | 365 | | | | 366 | | | | 367 +-------------+----------+ +---------+----------+ 368 | 1...N | 1...N 369 | | 370 | | 371 | | 1...N 372 | +----------+------------+ 373 | | Security group | 374 | |.......................| 375 | | | 376 \---------------------------+ - Security group name | 377 1...N | - Security material | 378 | | 379 +-----------------------+ 381 Figure 1: Relations Among Different Group Types 383 Figure 2 provides a deployment example of the relations between the 384 different types of groups. It shows six CoAP servers (Srv1-Srv6) and 385 their respective resources hosted (/resX). There are three 386 application groups (1, 2, 3) and two security groups (1, 2). 387 Security Group 1 is used by both Application Group 1 and 2. Three 388 clients (Cli1, Cli2, Cli3) are configured with security material for 389 Security Group 1. Two clients (Cli2, Cli4) are configured with 390 security material for Security Group 2. All the shown application 391 groups use the same CoAP group (not shown in the figure), i.e., one 392 specific multicast IP address and UDP port on which all the shown 393 resources are hosted for each server. 395 ________________________________ _________________________________ 396 / \ / \ 397 | +---------------------+ | | +---------------------+ | 398 | | Application Group 1 | | | | Application Group 3 | Cli2 | 399 | | | | | | | | 400 | Cli1 | Srv1 Srv2 Srv3 | | | | Srv5 Srv6 | Cli4 | 401 | | /resA /resA /resA | | | | /resC /resC | | 402 | Cli2 +---------------------+ | | | /resD /resD | | 403 | | | +---------------------+ | 404 | Cli3 Security Group 1 | | | 405 | | | Security Group 2 | 406 | +---------------------+ | \_________________________________/ 407 | | Application Group 2 | | 408 | | | | 409 | | Srv1 Srv4 | | 410 | | /resB /resB | | 411 | +---------------------+ | 412 \________________________________/ 414 Figure 2: Deployment Example of Different Group Types 416 2.2. Group Configuration 418 The following defines how groups of different types are named, 419 created, discovered and maintained. 421 2.2.1. Group Naming 423 A CoAP group is identified and named by the authority component in 424 the Group URI, which includes host (possibly an IP multicast address 425 literal) and an optional UDP port number. It is recommended to 426 configure an endpoint with an IP multicast address literal, instead 427 of a hostname, when configuring a CoAP group membership. This is 428 because DNS infrastructure may not be deployed in many constrained 429 networks. In case a group hostname is configured, it can be uniquely 430 mapped to an IP multicast address via DNS resolution - if DNS client 431 functionality is available in the endpoint being configured and the 432 DNS service is supported in the network. Some examples of 433 hierarchical CoAP group FQDN naming (and scoping) for a building 434 control application were shown in Section 2.2 of [RFC7390]. 436 An application group can be named in many ways through different 437 types of identifiers, such as numbers, URIs or other strings. An 438 application group name or identifier, if explicitly encoded in a CoAP 439 request, is typically included in the path component or in the query 440 component of a Group URI. It may also be encoded using the Uri-Host 441 Option [RFC7252] in case application group members implement a 442 virtual CoAP server specific to that application group. The 443 application group can then be identified by the value of the Uri-Host 444 Option and each virtual server serves one specific application group. 445 However, encoding the application group in the Uri-Host Option is not 446 the preferred method because in this case the application group 447 cannot be encoded in a Group URI, and also the Uri-Host Option is 448 being used for another purpose than encoding the host part of a URI 449 as intended by [RFC7252] -- which is potentially confusing. 450 Appendix A of [I-D.ietf-core-resource-directory] shows an example 451 registration of an application group into a Resource Directory (RD), 452 along with the CoAP group it uses and the resources supported by the 453 application group. In this example an application group identifier 454 is not explicitly encoded in the RD nor in CoAP requests made to the 455 group, but it implicitly follows from the CoAP group used for the 456 request. So there is a one-to-one binding between the CoAP group and 457 the application group. The "NoSec" security group is used. 459 A best practice for encoding application group into a Group URI is to 460 use one URI path component to identify the application group and use 461 the following URI paths component(s) to identify the resource within 462 this application group. For example, //res1 or 463 /base//res1/res2 conform to this practice. An application 464 group identifier (like ) should be as short as possible 465 when used in constrained networks. 467 A security group is identified by a stable and invariant string used 468 as group name, which is generally not related with other kinds of 469 group identifiers, specific to the chosen security solution. The 470 "NoSec" security group name MUST be only used to represent the case 471 of group communication without any security. It is typically 472 characterized by the absence of any security group name, identifier, 473 or security-related data structures in the CoAP message. 475 2.2.2. Group Creation and Membership 477 To create a CoAP group, a configuring entity defines an IP multicast 478 address (or hostname) for the group and optionally a UDP port number 479 in case it differs from the default CoAP port 5683. Then, it 480 configures one or more devices as listeners to that IP multicast 481 address, with a CoAP endpoint listening on the group's associated UDP 482 port. These endpoints/devices are the group members. The 483 configuring entity can be, for example, a local application with pre- 484 configuration, a user, a software developer, a cloud service, or a 485 local commissioning tool. Also, the devices sending CoAP requests to 486 the group in the role of CoAP client need to be configured with the 487 same information, even though they are not necessarily group members. 488 One way to configure a client is to supply it with a CoAP Group URI. 489 The IETF does not define a mandatory protocol to accomplish CoAP 490 group creation. [RFC7390] defined an experimental protocol for 491 configuration of group membership for unsecured group communication, 492 based on JSON-formatted configuration resources. For IPv6 CoAP 493 groups, common multicast address ranges that are used to configure 494 group addresses from are ff1x::/16 and ff3x::/16. 496 To create an application group, a configuring entity may configure a 497 resource (name) or set of resources on CoAP endpoints, such that a 498 CoAP request with Group URI sent by a configured CoAP client will be 499 processed by one or more CoAP servers that have the matching URI path 500 configured. These servers are the application group members. 502 To create a security group, a configuring entity defines an initial 503 subset of the related security material. This comprises a set of 504 group properties including the cryptographic algorithms and 505 parameters used in the group, as well as additional information 506 relevant throughout the group life-cycle, such as the security group 507 name and description. This task MAY be entrusted to a dedicated 508 administrator, that interacts with a Group Manager as defined in 509 Section 5. After that, further security materials to protect group 510 communications have to be generated, compatible with the specified 511 group configuration. 513 To participate in a security group, CoAP endpoints have to be 514 configured with the group security material used to protect 515 communications in the associated application/CoAP groups. The part 516 of the process that involves secure distribution of group security 517 material MAY use standardized communication with a Group Manager as 518 defined in Section 5. For unsecure group communication using the 519 "NoSec" security group, any CoAP endpoint may become a group member 520 at any time: there is no configuring entity that needs to provide 521 security material for this group, as there is no security material 522 for it. This means that group creation and membership cannot be 523 tightly controlled for the "NoSec" group. 525 The configuration of groups and membership may be performed at 526 different moments in the life-cycle of a device; for example during 527 product (software) creation, in the factory, at a reseller, on-site 528 during first deployment, or on-site during a system reconfiguration 529 operation. 531 2.2.3. Group Discovery 533 It is possible for CoAP endpoints to discover application groups as 534 well as CoAP groups, by using the RD-Groups usage pattern of the CoRE 535 Resource Directory (RD), as defined in Appendix A of 536 [I-D.ietf-core-resource-directory]. In particular, an application 537 group can be registered to the RD, specifying the reference IP 538 multicast address, hence its associated CoAP group. The registration 539 is typically performed by a Commissioning Tool. Later on, CoAP 540 endpoints can discover the registered application groups and related 541 CoAP group, by using the lookup interface of the RD. 543 CoAP endpoints can also discover application groups by performing a 544 group discovery query using the /.well-known/core resource. Such a 545 request may be sent to a known CoAP group multicast address 546 associated to application group(s), or to the All CoAP Nodes 547 multicast address. 549 When secure communication is provided with Group OSCORE (see 550 Section 5), the approach described in 551 [I-D.tiloca-core-oscore-discovery] and also based on the RD can be 552 used, in order to discover the security group to join. 554 In particular, the responsible OSCORE Group Manager registers its own 555 security groups to the RD, as links to its own corresponding 556 resources for joining the security groups 557 [I-D.ietf-ace-key-groupcomm-oscore]. Later on, CoAP endpoints can 558 discover the registered security groups and related application 559 groups, by using the lookup interface of the RD, and then join the 560 security group through the respective Group Manager. 562 2.2.4. Group Maintenance 564 Maintenance of a group includes any necessary operations to cope with 565 changes in a system, such as: adding group members, removing group 566 members, changing group security material, reconfiguration of UDP 567 port and/or IP multicast address, reconfiguration of the Group URI, 568 renaming of application groups, splitting of groups, or merging of 569 groups. 571 For unsecured group communication (see Section 4) i.e., the "NoSec" 572 security group, addition/removal of CoAP group members is simply done 573 by configuring these devices to start/stop listening to the group IP 574 multicast address on the group's UDP port. 576 For secured group communication (see Section 5), the maintenance 577 operations of the protocol Group OSCORE 578 [I-D.ietf-core-oscore-groupcomm] MUST be implemented. When using 579 Group OSCORE, CoAP endpoints participating in group communication are 580 also members of a corresponding OSCORE security group, and thus share 581 common security material. Additional related maintenance operations 582 are discussed in Section 5.2. 584 3. CoAP Usage in Group Communication 586 This section specifies the usage of CoAP in group communication, both 587 unsecured and secured. This includes additional support for protocol 588 extensions, such as Observe (see Section 3.7) and block-wise transfer 589 (see Section 3.8). 591 How CoAP group messages are carried over various transport layers is 592 the subject of Section 3.9. Finally, Section 3.10 covers the 593 interworking of CoAP group communication with other protocols that 594 may operate in the same network. 596 3.1. Request/Response Model 598 3.1.1. General 600 A CoAP client is an endpoint able to transmit CoAP requests and 601 receive CoAP responses. Since the underlying UDP transport supports 602 multiplexing by means of UDP port number, there can be multiple 603 independent CoAP clients operational on a single host. On each UDP 604 port, an independent CoAP client can be hosted. Each independent 605 CoAP client sends requests that use the associated endpoint's UDP 606 port number as the UDP source port of the request. 608 All CoAP requests that are sent via IP multicast MUST be Non- 609 confirmable; see Section 8.1 of [RFC7252]. The Message ID in an IP 610 multicast CoAP message is used for optional message deduplication by 611 both clients and servers, as detailed in Section 4.5 of [RFC7252]. A 612 server sends back a unicast response to a CoAP group request. The 613 unicast responses received by the CoAP client may be a mixture of 614 success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found) 615 codes, depending on the individual server processing results. 617 3.1.2. Response Suppression 619 A server MAY suppress its response for various reasons given in 620 Section 8.2 of [RFC7252]. This document adds the requirement that a 621 server SHOULD suppress the response in case of error or in case there 622 is nothing useful to respond, unless the application related to a 623 particular resource requires such a response to be made for that 624 resource. 626 The CoAP No-Response Option [RFC7967] can be used by a client to 627 influence the default response suppression on the server side. It is 628 RECOMMENDED for a server to support this option only on selected 629 resources where it is useful in the application context. If the 630 option is supported on a resource, it MUST override the default 631 response suppression of that resource. 633 Any default response suppression by a server SHOULD be performed 634 consistently, as follows: if a request on a resource produces a 635 particular Response Code and this response is not suppressed, then 636 another request on the same resource that produces a response of the 637 same Response Code class is also not suppressed. For example, if a 638 4.05 Method Not Allowed error response code is suppressed by default 639 on a resource, then a 4.15 Unsupported Content-Format error response 640 code is also suppressed by default for that resource. 642 3.1.3. Repeating a Request 644 A CoAP client MAY repeat a group request using the same Token value 645 and same Message ID value, in order to ensure that enough (or all) 646 group members have been reached with the request. This is useful in 647 case a number of group members did not respond to the initial request 648 and the client suspects that the request did not reach these group 649 members. However, in case one or more servers did receive the 650 initial request but the response to that request was lost, this 651 repeat does not help to retrieve the lost response(s) if the 652 server(s) implement the optional Message ID based deduplication 653 (Section 4.5 of [RFC7252]). 655 A CoAP client MAY repeat a group request using the same Token value 656 and a different Message ID, in which case all servers that received 657 the initial request will again process the repeated request since it 658 appears within a new CoAP message. This is useful in case a client 659 suspects that one or more response(s) to its original request were 660 lost and the client needs to collect more, or even all, responses 661 from group members, even if this comes at the cost of the overhead of 662 certain group members responding twice (once to the original request, 663 and once to the repeated request with different Message ID). 665 3.1.4. Request/Response Matching and Distinguishing Responses 667 A CoAP client can distinguish the origin of multiple server responses 668 by the source IP address of the message containing the CoAP response 669 and/or any other available application-specific source identifiers 670 contained in the CoAP response payload or CoAP response options, such 671 as an application-level unique ID associated to the server. If 672 secure communication is provided with Group OSCORE (see Section 5), 673 additional security-related identifiers in the CoAP response enable 674 the client to retrieve the right security material for decrypting 675 each response and authenticating its source. 677 While processing a response on the client, the source endpoint of the 678 response is not matched to the destination endpoint of the request, 679 since for a group request these will never match. This is specified 680 in Section 8.2 of [RFC7252], with reference to IP multicast. Also, 681 when UDP transport is used, this implies that a server MAY respond 682 from a UDP port number that differs from the destination UDP port 683 number of the request, although a CoAP server normally SHOULD respond 684 from the UDP port number that equals the destination port of the 685 request -- following the convention for UDP-based protocols. In case 686 a single client has sent multiple group requests and concurrent CoAP 687 transactions are ongoing, the responses received by that client are 688 matched to an active request using only the Token value. Due to UDP 689 level multiplexing, the UDP destination port of the response MUST 690 match to the client endpoint's UDP port value, i.e., to the UDP 691 source port of the client's request. 693 3.1.5. Token Reuse 695 For CoAP group requests, there are additional constraints on the 696 reuse of Token values at the client, compared to the unicast case 697 defined in [RFC7252] and updated by [I-D.ietf-core-echo-request-tag]. 698 Since for CoAP group requests the number of responses is not bound a 699 priori, the client cannot use the reception of a response as a 700 trigger to "free up" a Token value for reuse. Reusing a Token value 701 too early could lead to incorrect response/request matching on the 702 client, and would be a protocol error. Therefore, the time between 703 reuse of Token values for different group requests MUST be greater 704 than: 706 MIN_TOKEN_REUSE_TIME = (NON_LIFETIME + MAX_LATENCY + 707 MAX_SERVER_RESPONSE_DELAY) 709 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 710 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 711 was done in [RFC7390], that is: the expected maximum response delay 712 over all servers that the client can send a CoAP group request to. 713 This delay includes the maximum Leisure time period as defined in 714 Section 8.2 of [RFC7252]. However, CoAP does not define a time limit 715 for the server response delay. Using the default CoAP parameters, 716 the Token reuse time MUST be greater than 250 seconds plus 717 MAX_SERVER_RESPONSE_DELAY. A preferred solution to meet this 718 requirement is to generate a new unique Token for every new group 719 request, such that a Token value is never reused. If a client has to 720 reuse Token values for some reason, and also 721 MAX_SERVER_RESPONSE_DELAY is unknown, then using 722 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 723 The time between Token reuses is in that case set to a value greater 724 than MIN_TOKEN_REUSE_TIME = 500 seconds. 726 When securing CoAP group communication with Group OSCORE 727 [I-D.ietf-core-oscore-groupcomm], secure binding between requests and 728 responses is ensured (see Section 5). Thus, a client may reuse a 729 Token value after it has been freed up, as discussed above and 730 considering a reuse time greater than MIN_TOKEN_REUSE_TIME. If an 731 alternative security protocol for CoAP group communication is used 732 which does not ensure secure binding between requests and responses, 733 a client MUST follow the Token processing requirements as defined in 734 [I-D.ietf-core-echo-request-tag]. 736 Another method to more easily meet the above constraint is to 737 instantiate multiple CoAP clients at multiple UDP ports on the same 738 host. The Token values only have to be unique within the context of 739 a single CoAP client, so using multiple clients can make it easier to 740 meet the constraint. 742 3.1.6. Client Handling of Multiple Responses With Same Token 744 Since a client sending a group request with a Token T will accept 745 multiple responses with the same Token T, it is possible in 746 particular that the same server sends multiple responses with the 747 same Token T back to the client. For example, this server might not 748 implement the optional CoAP message deduplication based on Message 749 ID; or it might be acting out of specification as a malicious, 750 compromised or faulty server. 752 When this happens, the client normally processes at the CoAP layer 753 each of those responses to the same request coming from the same 754 server. If the processing of a response is successful, the client 755 delivers this response to the application as usual. 757 Then, the application is in a better position to decide what to do, 758 depending on the available context information. For instance, it 759 might accept and process all the responses from the same server, even 760 if they are not Observe notifications (i.e., they do not include an 761 Observe option). Alternatively, the application might accept and 762 process only one of those responses, such as the most recent one from 763 that server, e.g., when this can trigger a change of state within the 764 application. 766 3.2. Caching 768 CoAP endpoints that are members of a CoAP group MAY cache responses 769 to a group request as defined in Section 5.6 of [RFC7252]. In 770 particular, these same rules apply to determine the set of request 771 options used as "Cache-Key". 773 Furthermore, building on what is defined in Section 8.2.1 of 774 [RFC7252]: 776 * A client sending a GET or FETCH group request MAY update a cache 777 with the responses from the servers in the CoAP group. Then, the 778 client uses both cached-still-fresh and new responses as the 779 result of the group request. 781 * A client sending a GET or FETCH group request MAY use a response 782 received from a server, to satisfy a subsequent sent request 783 intended to that server on the related unicast request URI. In 784 particular, the unicast request URI is obtained by replacing the 785 authority part of the request URI with the transport-layer source 786 address of the cached response message. 788 * A client MAY revalidate a cached response by making a GET or FETCH 789 request on the related unicast request URI. 791 Note that, in the presence of proxies, doing any of the above 792 (optional) unicast requests requires the client to distinguish the 793 different responses to a group request, as well as to distinguish the 794 different origin servers that responded. This in turn requires 795 additional means to provide the client with information about the 796 origin server of each response, e.g., using the forward-proxying 797 method defines in [I-D.tiloca-core-groupcomm-proxy]. 799 The following subsections define the freshness model and validation 800 model to use for cached responses, which update the models defined in 801 Sections 5.6.1 and 5.6.2 of [RFC7252], respectively. 803 3.2.1. Freshness Model 805 For caching of group communication responses at client endpoints, the 806 same freshness model relying on the Max-Age Option as defined in 807 Section 5.6.1 of [RFC7252] applies, and the multicast caching rules 808 of Section 8.2.1 of [RFC7252] apply except for the one discussed 809 below. 811 In Section 8.2.1 of [RFC7252] it is stated that, regardless of the 812 presence of cached responses to the group request, the client 813 endpoint will always send out a new group request onto the network 814 because new group members may have joined the group since the last 815 group request to the same group/resource. That is, a request is 816 never served from cached responses only. This document updates 817 [RFC7252] by adding the following exception case, where a client 818 endpoint MAY serve a request by using cached responses only, and not 819 send out a new group request onto the network: 821 * The client knows all current CoAP server group members; and, for 822 each group member, the client's cache currently stores a fresh 823 response. 825 How the client in the case above determines the current CoAP server 826 group members is out of scope for this document. It may be, for 827 example, via a group manager server, or by observing group join 828 requests, or observing IGMP/MLD multicast group join messages, etc. 830 For caching at proxies, the freshness model defined in 831 [I-D.tiloca-core-groupcomm-proxy] can be used. 833 3.2.2. Validation Model 835 For validation of cached group communication responses at client 836 endpoints, the multicast validation rules in Section 8.2.1 of 837 [RFC7252] apply, except for the last paragraph which states "A GET 838 request to a multicast group MUST NOT contain an ETag option". This 839 document updates [RFC7252] by allowing a group request to contain 840 ETag Options as specified below. 842 For validation at proxies, the validation model defined in 843 [I-D.tiloca-core-groupcomm-proxy] can be used. 845 3.2.2.1. ETag Option in a Group Request/Response 847 A client endpoint MAY include one or more ETag Options in a GET or 848 FETCH group request to validate one or more stored responses it has 849 cached. In case two or more servers in the group have responded to a 850 previous request to the same resource with an identical ETag value, 851 it is the responsibility of the client to handle this case. In 852 particular, if the client wishes to validate, using a group request, 853 a response from server 1 with an ETag value N, while it does not wish 854 to validate a response from server 2 with the same ETag value N, 855 there is no way to achieve this. In such cases of identical ETag 856 values returned by two or more servers, the client, by default, 857 SHOULD NOT include an ETag Option in a group request containing that 858 ETag value. 860 A server endpoint MUST process an ETag Option in a GET or FETCH group 861 request in the same way it processes an ETag Option for a unicast 862 request. A server endpoint that includes an ETag Option in a 863 response to a group request SHOULD construct the ETag Option value in 864 such a way that the value will be unique to this particular server 865 with a high probability. This can be done, for example, by embedding 866 a compact ID of the server within the ETag value, where the ID is 867 unique (or unique with a high probability) in the scope of the group. 869 Note: a legacy CoAP server might treat an ETag Option in a group 870 request as an unrecognized option per Sections 5.4 and 8.2.1 of 871 [RFC7252], causing it to ignore this (elective) ETag Option 872 regardless of its value, and process the request normally as if that 873 ETag Option was not included. 875 3.3. URI Path Selection 877 The URI Path used in a group request is preferably a path that is 878 known to be supported across all group members. However there are 879 valid use cases where a group request is known to be successful only 880 for a subset of the CoAP group, for example only members of a 881 specific application group, while those group members for which the 882 request is unsuccessful (for example because they are outside the 883 application group) either ignore the group request or respond with an 884 error status code. 886 3.4. Port Selection for UDP Transport 888 A server that is a member of a CoAP group listens for CoAP request 889 messages on the group's IP multicast address, usually on the CoAP 890 default UDP port 5683, or another non-default UDP port if configured. 891 Regardless of the method for selecting the port number, the same port 892 number MUST be used across all CoAP servers that are members of a 893 CoAP group and across all CoAP clients sending group requests to that 894 group. 896 One way to create multiple CoAP groups is using different UDP ports 897 with the same IP multicast address, in case the devices' network 898 stack only supports a limited number of multicast address 899 subscriptions. However, it must be taken into account that this 900 incurs additional processing overhead on each CoAP server 901 participating in at least one of these groups: messages to groups 902 that are not of interest to the node are only discarded at the higher 903 transport (UDP) layer instead of directly at the network (IP) layer. 904 Also, a constrained network may be additionally burdened in this case 905 with multicast traffic that is eventually discarded at the UDP layer 906 by most nodes. 908 Port 5684 is reserved for DTLS-secured unicast CoAP and MUST NOT be 909 used for any CoAP group communication. 911 For a CoAP server node that supports resource discovery as defined in 912 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 913 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 914 group as detailed in Section 3.9. 916 3.5. Proxy Operation 918 This section defines how proxies operate in a group communication 919 scenario. In particular, Section 3.5.1 defines operations of 920 forward-proxies, while Section 3.5.2 defines operations of reverse- 921 proxies. Security operations for a proxy are discussed later in 922 Section 5.3. 924 3.5.1. Forward-Proxies 926 CoAP enables a client to request a forward-proxy to process a CoAP 927 request on its behalf, as described in Sections 5.7.2 and 8.2.2 of 928 [RFC7252]. For this purpose, the client specifies either the request 929 group URI as a string in the Proxy-URI Option or it uses the Proxy- 930 Scheme Option with the group URI constructed from the usual Uri-* 931 Options. The forward-proxy then resolves the group URI to a 932 destination CoAP group, sends (e.g., multicasts) the CoAP group 933 request, receives the responses and forwards all the individual 934 (unicast) responses back to the client. 936 However, there are certain issues and limitations with this approach: 938 * The CoAP client component that sent a unicast CoAP request to the 939 proxy may be expecting only one (unicast) response, as usual for a 940 CoAP unicast request. Instead, it receives multiple (unicast) 941 responses, potentially leading to fault conditions in the 942 component or to discarding any received responses following the 943 first one. This issue may occur even if the application calling 944 the CoAP client component is aware that the forward-proxy is going 945 to execute a CoAP group URI request. 947 * Each individual CoAP response received by the client will appear 948 to originate (based on its IP source address) from the CoAP Proxy, 949 and not from the server that produced the response. This makes it 950 impossible for the client to identify the server that produced 951 each response, unless the server identity is contained as a part 952 of the response payload or inside a CoAP option in the response. 954 * The proxy does not necessarily know how many members there are in 955 the CoAP group or how many group members will actually respond. 956 Also, the proxy does not know for how long to collect responses 957 before it stops forwarding them to the client. A CoAP client that 958 is not using a Proxy might face the same problems in collecting 959 responses to a group request. However, the client itself would 960 typically have application-specific rules or knowledge on how to 961 handle this situation, while an application-agnostic CoAP Proxy 962 would typically not have this knowledge. For example, a CoAP 963 client could monitor incoming responses and use this information 964 to decide how long to continue collecting responses - which is 965 something a proxy cannot do. 967 A forward-proxying method using this approach and addressing the 968 issues raised above is defined in [I-D.tiloca-core-groupcomm-proxy]. 970 An alternative solution is for the proxy to collect all the 971 individual (unicast) responses to a CoAP group request and then send 972 back only a single (aggregated) response to the client. However, 973 this solution brings up new issues: 975 * Like for the approach discussed above, the proxy does not know for 976 how long to collect responses before sending back the aggregated 977 response to the client. Analogous considerations apply to this 978 approach too, both on the client and proxy side. 980 * There is no default format defined in CoAP for aggregation of 981 multiple responses into a single response. Such a format could be 982 standardized based on, for example, the multipart content-format 983 [RFC8710]. 985 Due to the above issues, it is RECOMMENDED that a CoAP Proxy only 986 processes a group URI request if it is explicitly enabled to do so. 987 The default response (if the function is not explicitly enabled) to a 988 group URI request is 5.01 Not Implemented. Furthermore, a proxy 989 SHOULD be explicitly configured (e.g., by allow-listing and/or client 990 authentication) to allow proxied CoAP group requests only from 991 specific client(s). 993 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 994 specified in Sections 8.4 and 10.1 of [RFC8075]. In this case, the 995 "application/http" media type is used to let the proxy return 996 multiple CoAP responses -- each translated to a HTTP response -- back 997 to the HTTP client. Of course, in this case the HTTP client sending 998 a group URI to the proxy needs to be aware that it is going to 999 receive this format, and needs to be able to decode it into the 1000 responses of multiple CoAP servers. Also, the IP source address of 1001 each CoAP response cannot be determined anymore from the 1002 "application/http" response. The HTTP client still identify the CoAP 1003 servers by other means such as application-specific information in 1004 the response payload. 1006 3.5.2. Reverse-Proxies 1008 CoAP enables the use of a reverse-proxy, as an endpoint that stands 1009 in for one or more other server(s), and satisfies requests on behalf 1010 of these, doing any necessary translations (see Section 5.7.3 of 1011 [RFC7252]). 1013 In a group communication scenario, a reverse-proxy can rely on its 1014 configuration and/or on information in a request from a client, in 1015 order to determine that a group request has to be sent to a group of 1016 servers over a one-to-many transport such as IP/UDP multicast. 1018 For example, specific resources on the reverse-proxy could be 1019 allocated, each to a specific application group and/or CoAP group. 1020 Or alternatively, the application group and/or CoAP group in question 1021 could be encoded as URI path segments. The URI path encodings for a 1022 reverse-proxy may also use a URI mapping template as described in 1023 Section 5.4 of [RFC8075]. 1025 Furthermore, the reverse-proxy can actually stand in for (and thus 1026 prevent to directly reach) only the whole set of servers in the 1027 group, or also for each of those individual servers (e.g., if acting 1028 as firewall). 1030 For a reverse-proxy that sends a request to a group of servers, the 1031 considerations as defined in Section 5.7.3 of [RFC7252] hold, with 1032 the following additions: 1034 * The three issues and limitations defined in Section 3.5.1 for a 1035 forward proxy apply to a reverse-proxy as well, and have to be 1036 addressed, e.g., using the signaling method defined in 1037 [I-D.tiloca-core-groupcomm-proxy] or other means. 1039 * A reverse-proxy MAY have preconfigured time duration(s) that are 1040 used for the collecting of server responses and forwarding these 1041 back to the client. These duration(s) may be set as global 1042 configuration or resource-specific configurations. If there is 1043 such preconfiguration, then an explicit signaling of the time 1044 period in the client's request as defined in 1045 [I-D.tiloca-core-groupcomm-proxy] is not necessarily needed. 1047 * A client that is configured to access a reverse-proxy resource 1048 (i.e., one that triggers a CoAP group communication request) 1049 SHOULD be configured also to handle potentially multiple responses 1050 with the same Token value caused by a single request. 1052 That is, the client needs to preserve the Token value used for the 1053 request also after the reception of the first response forwarded 1054 back by the proxy (see Section 3.1.6) and keep the request open to 1055 potential further responses with this Token. This requirement can 1056 be met by a combination of client implementation and proper 1057 proxied group communication configuration on the client. 1059 * A client might re-use a Token value in a valid new request to the 1060 reverse-proxy, while the reverse-proxy still has an ongoing group 1061 communication request for this client with the same Token value 1062 (i.e., its time period for response collection has not ended yet). 1064 If this happens, the reverse-proxy MUST stop the ongoing request 1065 and associated response forwarding, it MUST NOT forward the new 1066 request to the group of servers, and it MUST send a 4.00 Bad 1067 Request error response to the client. The diagnostic payload of 1068 the error response SHOULD indicate to the client that the resource 1069 is a reverse-proxy resource, and that for this reason immediate 1070 Token re-use is not possible. 1072 If the reverse-proxy supports the signalling protocol of 1073 [I-D.tiloca-core-groupcomm-proxy] it can include a Multicast- 1074 Signaling Option in the error response to convey the reason for 1075 the error in a machine-readable way. 1077 For the operation of HTTP-to-CoAP reverse proxies, see the last 1078 paragraph of Section 3.5.1 which applies also to the case of reverse- 1079 proxies. 1081 3.6. Congestion Control 1083 CoAP group requests may result in a multitude of responses from 1084 different nodes, potentially causing congestion. Therefore, both the 1085 sending of CoAP group requests and the sending of the unicast CoAP 1086 responses to these group requests should be conservatively 1087 controlled. 1089 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 1090 the following measures: 1092 * A server may choose not to respond to an IP multicast request if 1093 there is nothing useful to respond to, e.g., error or empty 1094 response (see Section 8.2 of [RFC7252]). 1096 * A server should limit the support for IP multicast requests to 1097 specific resources where multicast operation is required 1098 (Section 11.3 of [RFC7252]). 1100 * An IP multicast request MUST be Non-confirmable (Section 8.1 of 1101 [RFC7252]). 1103 * A response to an IP multicast request SHOULD be Non-confirmable 1104 (Section 5.2.3 of [RFC7252]). 1106 * A server does not respond immediately to an IP multicast request 1107 and should first wait for a time that is randomly picked within a 1108 predetermined time interval called the Leisure (Section 8.2 of 1109 [RFC7252]). 1111 This document also defines these measures to be applicable to 1112 alternative transports (other than IP multicast), if not defined 1113 otherwise. Additional guidelines to reduce congestion risks defined 1114 in this document are as follows: 1116 * A server in a constrained network SHOULD only support group 1117 requests for resources that have a small representation (where the 1118 representation may be retrieved via a GET, FETCH or POST method in 1119 the request). For example, "small" can be defined as a response 1120 payload limited to approximately 5% of the IP Maximum Transmit 1121 Unit (MTU) size, so that it fits into a single link-layer frame in 1122 case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, 1123 see Section 3.9.3) is used on the constrained network. 1125 * A server SHOULD minimize the payload size of a response to a group 1126 GET or FETCH request on "/.well-known/core" by using hierarchy in 1127 arranging link descriptions for the response. An example of this 1128 is given in Section 5 of [RFC6690]. 1130 * A server MAY minimize the payload size of a response to a group 1131 GET or FETCH request (e.g., on "/.well-known/core") by using CoAP 1132 block-wise transfers [RFC7959] in case the payload is long, 1133 returning only a first block of the CoRE Link Format description. 1134 For this reason, a CoAP client sending a CoAP group request to 1135 "/.well-known/core" SHOULD support block-wise transfers. See also 1136 Section 3.8. 1138 * A client SHOULD be configured to use CoAP groups with the smallest 1139 possible IP multicast scope that fulfills the application needs. 1140 As an example, site-local scope is always preferred over global 1141 scope IP multicast if this fulfills the application needs. 1142 Similarly, realm-local scope is always preferred over site-local 1143 scope if this fulfills the application needs. 1145 3.7. Observing Resources 1147 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 1148 that allows a CoAP client to retrieve a representation of a resource 1149 and automatically keep this representation up-to-date over a longer 1150 period of time. The client gets notified when the representation has 1151 changed. [RFC7641] does not mention whether the Observe Option can 1152 be combined with CoAP (multicast) group communication. 1154 This section updates [RFC7641] with the use of the Observe Option in 1155 a CoAP GET group request, and defines normative behavior for both 1156 client and server. Consistent with Section 2.4 of [RFC8132], it is 1157 also possible to use the Observe Option in a CoAP FETCH group 1158 request. 1160 Multicast Observe is a useful way to start observing a particular 1161 resource on all members of a CoAP group at the same time. Group 1162 members that do not have this particular resource or do not allow the 1163 GET or FETCH method on it will either respond with an error status -- 1164 4.04 Not Found or 4.05 Method Not Allowed, respectively -- or will 1165 silently suppress the response following the rules of Section 3.1.2, 1166 depending on server-specific configuration. 1168 A client that sends a group GET or FETCH request with the Observe 1169 Option MAY repeat this request using the same Token value and the 1170 same Observe Option value, in order to ensure that enough (or all) 1171 members of the CoAP group have been reached with the request. This 1172 is useful in case a number of group members did not respond to the 1173 initial request. The client MAY additionally use the same Message ID 1174 in the repeated request to avoid that group members that had already 1175 received the initial request would respond again. Note that using 1176 the same Message ID in a repeated request will not be helpful in case 1177 of loss of a response message, since the server that responded 1178 already will consider the repeated request as a duplicate message. 1179 On the other hand, if the client uses a different, fresh Message ID 1180 in the repeated request, then all the group members that receive this 1181 new message will typically respond again, which increases the network 1182 load. 1184 A client that has sent a group GET or FETCH request with the Observe 1185 Option MAY follow up by sending a new unicast CON request with the 1186 same Token value and same Observe Option value to a particular 1187 server, in order to ensure that the particular server receives the 1188 request. This is useful in case a specific group member, that was 1189 expected to respond to the initial group request, did not respond to 1190 the initial request. In this case, the client MUST use a Message ID 1191 that differs from the initial group request message. 1193 Furthermore, consistent with Section 3.3.1 of [RFC7641] and following 1194 its guidelines, a client MAY at any time send a new group/multicast 1195 GET or FETCH request with the same Token value and same Observe 1196 Option value as the original request. This allows the client to 1197 verify that it has an up-to-date representation of an observed 1198 resource and/or to re-register its interest to observe a resource. 1200 In the above client behaviors, the Token value is kept identical to 1201 the initial request to avoid that a client is included in more than 1202 one entry in the list of observers (Section 4.1 of [RFC7641]). 1204 Before repeating a request as specified above, the client SHOULD wait 1205 for at least the expected round-trip time plus the Leisure time 1206 period defined in Section 8.2 of [RFC7252], to give the server time 1207 to respond. 1209 A server that receives a GET or FETCH request with the Observe 1210 Option, for which request processing is successful, SHOULD respond to 1211 this request and not suppress the response. If a server adds a 1212 client (as a new entry) to the list of observers for a resource due 1213 to an Observe request, the server SHOULD respond to this request and 1214 SHOULD NOT suppress the response. An exception to the above is the 1215 overriding of response suppression according to a CoAP No-Response 1216 Option [RFC7967] specified by the client in the GET or FETCH request 1217 (see Section 3.1.2). 1219 A server SHOULD have a mechanism to verify liveness of its observing 1220 clients and the continued interest of these clients in receiving the 1221 observe notifications. This can be implemented by sending 1222 notifications occassionally using a Confirmable message. See 1223 Section 4.5 of [RFC7641] for details. This requirement overrides the 1224 regular behavior of sending Non-confirmable notifications in response 1225 to a Non-confirmable request. 1227 A client can use the unicast cancellation methods of Section 3.6 of 1228 [RFC7641] and stop the ongoing observation of a particular resource 1229 on members of a CoAP group. This can be used to remove specific 1230 observed servers, or even all servers in the group (using serial 1231 unicast to each known group member). In addition, a client MAY 1232 explicitly deregister from all those servers at once, by sending a 1233 group/multicast GET or FETCH request that includes the Token value of 1234 the observation to be cancelled and includes an Observe Option with 1235 the value set to 1 (deregister). In case not all the servers in the 1236 CoAP group received this deregistration request, either the unicast 1237 cancellation methods can be used at a later point in time or the 1238 group/multicast deregistration request MAY be repeated upon receiving 1239 another observe response from a server. 1241 For observing a group of servers through a CoAP-to-CoAP proxy, the 1242 limitations stated in Section 3.5 apply. The method defined in 1243 [I-D.tiloca-core-groupcomm-proxy] enables group communication 1244 including resource observation through proxies and addresses those 1245 limitations. 1247 3.8. Block-Wise Transfer 1249 Section 2.8 of [RFC7959] specifies how a client can use block-wise 1250 transfer (Block2 Option) in a multicast GET request to limit the size 1251 of the initial response of each server. Consistent with Section 2.5 1252 of [RFC8132], the same can be done with a multicast FETCH request. 1254 The client has to use unicast for any further request, separately 1255 addressing each different server, in order to retrieve more blocks of 1256 the resource from that server, if any. Also, a server (member of a 1257 targeted CoAP group) that needs to respond to a group request with a 1258 particularly large resource can use block-wise transfer (Block2 1259 Option) at its own initiative, to limit the size of the initial 1260 response. Again, a client would have to use unicast for any further 1261 requests to retrieve more blocks of the resource. 1263 A solution for group/multicast block-wise transfer using the Block1 1264 Option is not specified in [RFC7959] nor in the present document. 1265 Such a solution would be useful for group FETCH/PUT/POST/PATCH/iPATCH 1266 requests, to efficiently distribute a large request payload as 1267 multiple blocks to all members of a CoAP group. Multicast usage of 1268 Block1 is non-trivial due to potential message loss (leading to 1269 missing blocks or missing confirmations), and potential diverging 1270 block size preferences of different members of the CoAP group. 1272 [I-D.ietf-core-new-block] specifies an alternative method for CoAP 1273 block-wise transfer. It specifies that "servers MUST ignore 1274 multicast requests that contain the Q-Block2 Option". 1276 3.9. Transport Protocols 1278 In this document UDP, both over IPv4 and IPv6, is considered as the 1279 default transport protocol for CoAP group communication. 1281 3.9.1. UDP/IPv6 Multicast Transport 1283 CoAP group communication can use UDP over IPv6 as a transport 1284 protocol, provided that IPv6 multicast is enabled. IPv6 multicast 1285 MAY be supported in a network only for a limited scope. For example, 1286 Section 3.10.2 describes the potential limited support of RPL for 1287 multicast, depending on how the protocol is configured. 1289 For a CoAP server node that supports resource discovery as defined in 1290 Section 2.4 of [RFC7252], the default port 5683 MUST be supported as 1291 per Sections 7.1 and 12.8 of [RFC7252] for the "All CoAP Nodes" 1292 multicast group. An IPv6 CoAP server SHOULD support the "All CoAP 1293 Nodes" groups with at least link-local (2), admin-local (4) and site- 1294 local (5) scopes. An IPv6 CoAP server on a 6LoWPAN node (see 1295 Section 3.9.3) SHOULD also support the realm-local (3) scope. 1297 Note that a client sending an IPv6 multicast CoAP message to a port 1298 that is not supported by the server will not receive an ICMPv6 Port 1299 Unreachable error message from that server, because the server does 1300 not send it in this case, per Section 2.4 of [RFC4443]. 1302 3.9.2. UDP/IPv4 Multicast Transport 1304 CoAP group communication can use UDP over IPv4 as a transport 1305 protocol, provided that IPv4 multicast is enabled. For a CoAP server 1306 node that supports resource discovery as defined in Section 2.4 of 1307 [RFC7252], the default port 5683 MUST be supported as per Sections 1308 7.1 and 12.8 of [RFC7252], for the "All CoAP Nodes" IPv4 multicast 1309 group. 1311 Note that a client sending an IPv4 multicast CoAP message to a port 1312 that is not supported by the server will not receive an ICMP Port 1313 Unreachable error message from that server, because the server does 1314 not send it in this case, per Section 3.2.2 of [RFC1122]. 1316 3.9.3. 6LoWPAN 1318 In 6LoWPAN [RFC4944] [RFC6282] networks, IPv6 packets (up to 1280 1319 bytes) may be fragmented into smaller IEEE 802.15.4 MAC frames (up to 1320 127 bytes), if the packet size requires this. Every 6LoWPAN IPv6 1321 router that receives a multi-fragment packet reassembles the packet 1322 and refragments it upon transmission. Since the loss of a single 1323 fragment implies the loss of the entire IPv6 packet, the performance 1324 in terms of packet loss and throughput of multi-fragment multicast 1325 IPv6 packets is typically far worse than the performance of single- 1326 fragment IPv6 multicast packets. For this reason, a CoAP request 1327 sent over multicast in 6LoWPAN networks SHOULD be sized in such a way 1328 that it fits in a single IEEE 802.15.4 MAC frame, if possible. 1330 On 6LoWPAN networks, multicast groups can be defined with realm-local 1331 scope [RFC7346]. Such a realm-local group is restricted to the local 1332 6LoWPAN network/subnet. In other words, a multicast request to that 1333 group does not propagate beyond the 6LoWPAN network segment where the 1334 request originated. For example, a multicast discovery request can 1335 be sent to the realm-local "All CoAP Nodes" IPv6 multicast group (see 1336 Section 3.9.1) in order to discover only CoAP servers on the local 1337 6LoWPAN network. 1339 3.9.4. Other Transports 1341 CoAP group communication may be used over transports other than UDP/ 1342 IP multicast. For example broadcast, non-UDP multicast, geocast, 1343 serial unicast, etc. In such cases the particular considerations for 1344 UDP/IP multicast in this document may need to be applied to that 1345 particular transport. 1347 Because it supports unicast only, [RFC8323] (CoAP over TCP, TLS, and 1348 WebSockets) is not in scope as a transport for CoAP group 1349 communication. 1351 3.10. Interworking with Other Protocols 1353 3.10.1. MLD/MLDv2/IGMP/IGMPv3 1355 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1356 unaware of the specific IP multicast routing/forwarding protocol 1357 being used in their network. When such a host needs to join a 1358 specific (CoAP) multicast group, it requires a way to signal to IP 1359 multicast routers which IP multicast address(es) it needs to listen 1360 to. 1362 The MLDv2 protocol [RFC3810] is the standard IPv6 method to achieve 1363 this; therefore, this method SHOULD be used by members of a CoAP 1364 group to subscribe to its multicast IPv6 address, on IPv6 networks 1365 that support it. CoAP server nodes then act in the role of MLD 1366 Multicast Address Listener. MLDv2 uses link-local communication 1367 between Listeners and IP multicast routers. Constrained IPv6 1368 networks that implement either RPL (see Section 3.10.2) or MPL (see 1369 Section 3.10.3) typically do not support MLDv2 as they have their own 1370 mechanisms defined for subscribing to multicast groups. 1372 The IGMPv3 protocol [RFC3376] is the standard IPv4 method to signal 1373 multicast group subscriptions. This SHOULD be used by members of a 1374 CoAP group to subscribe to its multicast IPv4 address on IPv4 1375 networks. 1377 The guidelines from [RFC6636] on the tuning of MLD for mobile and 1378 wireless networks may be useful when implementing MLD in constrained 1379 networks. 1381 3.10.2. RPL 1383 RPL [RFC6550] is an IPv6 based routing protocol suitable for low- 1384 power, lossy networks (LLNs). In such a context, CoAP is often used 1385 as an application protocol. 1387 If only RPL is used in a network for routing and its optional 1388 multicast support is disabled, there will be no IP multicast routing 1389 available. Any IPv6 multicast packets in this case will not 1390 propagate beyond a single hop (to direct neighbors in the LLN). This 1391 implies that any CoAP group request will be delivered to link-local 1392 nodes only, for any scope value >= 2 used in the IPv6 destination 1393 address. 1395 RPL supports (see Section 12 of [RFC6550]) advertisement of IP 1396 multicast destinations using Destination Advertisement Object (DAO) 1397 messages and subsequent routing of multicast IPv6 packets based on 1398 this. It requires the RPL mode of operation to be 3 (Storing mode 1399 with multicast support). 1401 In this mode, RPL DAO can be used by a CoAP node that is either an 1402 RPL router or RPL Leaf Node, to advertise its CoAP group membership 1403 to parent RPL routers. Then, RPL will route any IP multicast CoAP 1404 requests over multiple hops to those CoAP servers that are group 1405 members. 1407 The same DAO mechanism can be used to convey CoAP group membership 1408 information to an edge router (e.g., 6LBR), in case the edge router 1409 is also the root of the RPL Destination-Oriented Directed Acyclic 1410 Graph (DODAG). This is useful because the edge router then learns 1411 which IP multicast traffic it needs to pass through from the backbone 1412 network into the LLN subnet, and which traffic not. In LLNs, such 1413 ingress filtering helps to avoid congestion of the resource- 1414 constrained network segment, due to IP multicast traffic from the 1415 high-speed backbone IP network. 1417 3.10.3. MPL 1419 The Multicast Protocol for Low-Power and Lossy Networks (MPL) 1420 [RFC7731] can be used for propagation of IPv6 multicast packets 1421 throughout a defined network domain, over multiple hops. MPL is 1422 designed to work in LLNs and can operate alone or in combination with 1423 RPL. The protocol involves a predefined group of MPL Forwarders to 1424 collectively distribute IPv6 multicast packets throughout their MPL 1425 Domain. An MPL Forwarder may be associated to multiple MPL Domains 1426 at the same time. Non-Forwarders will receive IPv6 multicast packets 1427 from one or more of their neighboring Forwarders. Therefore, MPL can 1428 be used to propagate a CoAP multicast group request to all group 1429 members. 1431 However, a CoAP multicast request to a group that originated outside 1432 of the MPL Domain will not be propagated by MPL - unless an MPL 1433 Forwarder is explicitly configured as an ingress point that 1434 introduces external multicast packets into the MPL Domain. Such an 1435 ingress point could be located on an edge router (e.g., 6LBR). 1436 Methods to configure which multicast groups are to be propagated into 1437 the MPL Domain could be: 1439 * Manual configuration on each ingress MPL Forwarder. 1441 * MLDv2 protocol, which works only in case all CoAP servers joining 1442 a group are in link-local communication range of an ingress MPL 1443 Forwarder. This is typically not the case on mesh networks. 1445 * A new/custom protocol to register multicast groups at an ingress 1446 MPL Forwarder. This could be for example a CoAP-based protocol 1447 offering multicast group subscription features similar to MLDv2. 1449 For security and performance reasons also other filtering criteria 1450 may be defined at an ingress MPL Forwarder. See Section 6.6 for more 1451 details. 1453 4. Unsecured Group Communication 1455 CoAP group communication can operate in CoAP NoSec (No Security) 1456 mode, without using application-layer and transport-layer security 1457 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 1458 Section 9 of [RFC7252]. The conceptual "NoSec" security group as 1459 defined in Section 2.1 is used for unsecured group communication. 1461 Before using this mode of operation, the security implications 1462 (Section 6.1) must be well understood, especially as to the risk and 1463 impact of amplification attacks (see Section 6.3). 1465 5. Secured Group Communication using Group OSCORE 1467 This section defines how CoAP group communication can be secured. In 1468 particular, Section 5.1 describes how the Group OSCORE security 1469 protocol [I-D.ietf-core-oscore-groupcomm] can be used to protect 1470 messages exchanged in a CoAP group, while Section 5.2 provides 1471 guidance on required maintenance operations for OSCORE groups used as 1472 security groups. 1474 5.1. Group OSCORE 1476 The application-layer protocol Object Security for Constrained 1477 RESTful Environments (OSCORE) [RFC8613] provides end-to-end 1478 encryption, integrity and replay protection of CoAP messages 1479 exchanged between two CoAP endpoints. These can act both as CoAP 1480 Client as well as CoAP Server, and share an OSCORE Security Context 1481 used to protect and verify exchanged messages. The use of OSCORE 1482 does not affect the URI scheme and OSCORE can therefore be used with 1483 any URI scheme defined for CoAP. 1485 OSCORE uses COSE [I-D.ietf-cose-rfc8152bis-struct] 1486 [I-D.ietf-cose-rfc8152bis-algs] to perform encryption operations and 1487 protect a CoAP message carried in a COSE object, by using an 1488 Authenticated Encryption with Associated Data (AEAD) algorithm. In 1489 particular, OSCORE takes as input an unprotected CoAP message and 1490 transforms it into a protected CoAP message transporting the COSE 1491 object. 1493 OSCORE makes it possible to selectively protect different parts of a 1494 CoAP message in different ways, while still allowing intermediaries 1495 (e.g., CoAP proxies) to perform their intended funtionalities. That 1496 is, some message parts are encrypted and integrity protected; other 1497 parts are only integrity protected to be accessible to, but not 1498 modifiable by, proxies; and some parts are kept as plain content to 1499 be both accessible to and modifiable by proxies. Such differences 1500 especially concern the CoAP options included in the unprotected 1501 message. 1503 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 1504 provides end-to-end security of CoAP messages exchanged between 1505 members of an OSCORE group, while fulfilling the same security 1506 requirements. 1508 In particular, Group OSCORE protects CoAP group requests sent by a 1509 CoAP client, e.g., over UDP/IP multicast, as well as multiple 1510 corresponding CoAP responses sent as (IP) unicast by different CoAP 1511 servers. However, the same security material can also be used to 1512 protect CoAP requests sent over (IP) unicast to a single CoAP server 1513 in the OSCORE group, as well as the corresponding responses. 1515 Group OSCORE ensures source authentication of all messages exchanged 1516 within the OSCORE group, by means of two possible methods. 1518 The first method, called group mode, relies on digital signatures. 1519 That is, sender devices sign their outgoing messages using their own 1520 private key, and embed the signature in the protected CoAP message. 1522 The second method, called pairwise mode, relies on a symmetric key, 1523 which is derived from a pairwise shared secret computed from the 1524 asymmetric keys of the message sender and recipient. This method is 1525 intended for one-to-one messages sent in the group, such as all 1526 responses individually sent by servers, as well as requests addressed 1527 to an individual server. 1529 A Group Manager is responsible for managing one or multiple OSCORE 1530 groups. In particular, the Group Manager acts as repository of 1531 public keys of group members; manages, renews and provides security 1532 material in the group; and handles the join process of new group 1533 members. 1535 As defined in [I-D.ietf-ace-oscore-gm-admin], an administrator entity 1536 can interact with the Group Manager to create OSCORE groups and 1537 specify their configuration (see Section 2.2.2). During the lifetime 1538 of the OSCORE group, the administrator can further interact with the 1539 Group Manager, in order to possibly update the group configuration 1540 and eventually delete the group. 1542 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 1543 can join an OSCORE group by using the method described in 1544 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 1545 for Authentication and Authorization in constrained environments 1546 [I-D.ietf-ace-oauth-authz]. 1548 A CoAP endpoint can discover OSCORE groups and retrieve information 1549 to join them through their respective Group Managers by using the 1550 method described in [I-D.tiloca-core-oscore-discovery] and based on 1551 the CoRE Resource Directory [I-D.ietf-core-resource-directory]. 1553 If security is required, CoAP group communication as described in 1554 this specification MUST use Group OSCORE. In particular, a CoAP 1555 group as defined in Section 2.1 and using secure group communication 1556 is associated to an OSCORE security group, which includes: 1558 * All members of the CoAP group, i.e., the CoAP endpoints configured 1559 to receive CoAP group messages sent to the particular group and -- 1560 in case of IP multicast transport -- are listening to the group's 1561 multicast IP address on the group's UDP port. 1563 * All further CoAP endpoints configured only as CoAP clients, that 1564 may send CoAP group requests to the CoAP group. 1566 5.2. Secure Group Maintenance 1568 As part of group maintenance operations (see Section 2.2.4), 1569 additional key management operations are required for an OSCORE 1570 group, also depending on the security requirements of the application 1571 (see Section 6.2). Specifically: 1573 * Adding new members to a CoAP group or enabling new client-only 1574 endpoints to interact with that group require also that each of 1575 such members/endpoints join the corresponding OSCORE group. By 1576 doing so, they are securely provided with the necessary 1577 cryptographic material. 1579 In case backward security is needed, this also requires to first 1580 renew such material and distribute it to the current members/ 1581 endpoints, before new ones are added and join the OSCORE group. 1582 This prevents the new group members to access secure group 1583 communications that occurred in the group before their joining. 1585 * Removing members from a CoAP group or stopping client-only 1586 endpoints from interacting with that group requires removing such 1587 members/endpoints from the corresponding OSCORE group. To this 1588 end, new cryptographic material is generated and securely 1589 distributed only to the remaining members/endpoints, together with 1590 the list of removed members/endpoints. 1592 This ensures that only the members/endpoints intended to remain 1593 are able to continue participating in secure group communication, 1594 while the evicted ones are not able to. Also, it ensures that the 1595 members/endpoints intended to remain are able to confidently 1596 assert the group membership of other sender nodes, when receiving 1597 protected messages in the group (see Section 3.2 of 1598 [I-D.ietf-core-oscore-groupcomm]). 1600 The key management operations mentioned above are entrusted to the 1601 Group Manager responsible for the OSCORE group 1602 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 1603 them according to the approach described in 1604 [I-D.ietf-ace-key-groupcomm-oscore]. 1606 5.3. Proxy Security 1608 Different solutions may be selected for secure group communication 1609 via a proxy depending on proxy type, use case and deployment 1610 requirements. In this section the options based on Group OSCORE are 1611 listed. 1613 For a client performing a group communication request via a forward- 1614 proxy, end-to-end security should be implemented. The client then 1615 creates a group request protected with Group OSCORE and unicasts this 1616 to the proxy. The proxy adapts the request from a forward-proxy 1617 request to a regular request and multicasts this adapted request to 1618 the indicated CoAP group. During the adaptation, the security 1619 provided by Group OSCORE persists, in either case of using the group 1620 mode or using the pairwise mode. The first leg of communication from 1621 client to proxy can optionally be further protected, e.g., by using 1622 (D)TLS and/or OSCORE. 1624 For a client performing a group communication request via a reverse- 1625 proxy, either end-to-end-security or hop-by-hop security can be 1626 implemented. The case of end-to-end security is the same as for the 1627 forward-proxy case. 1629 The case of hop-by-hop security is only possible if the proxy can be 1630 completely trusted and it is configured as a member of the OSCORE 1631 security group(s) that it needs to access, on behalf of clients. The 1632 first leg of communication between client and proxy is then protected 1633 with a security method for CoAP unicast, such as (D)TLS, OSCORE or a 1634 combination of such methods. The second leg between proxy and 1635 servers is protected using Group OSCORE. This can be useful in 1636 applications where for example the origin client does not implement 1637 Group OSCORE, or the group management operations are confined to a 1638 particular network domain and the client is outside this domain. 1640 For all the above cases, more details on using Group OSCORE are 1641 defined in [I-D.tiloca-core-groupcomm-proxy]. 1643 6. Security Considerations 1645 This section provides security considerations for CoAP group 1646 communication, in general and for the particular transport of IP 1647 multicast. 1649 6.1. CoAP NoSec Mode 1651 CoAP group communication, if not protected, is vulnerable to all the 1652 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 1654 Thus, for sensitive and mission-critical applications (e.g., health 1655 monitoring systems and alarm monitoring systems), it is NOT 1656 RECOMMENDED to deploy CoAP group communication in NoSec mode. 1658 Without application-layer security, CoAP group communication SHOULD 1659 only be deployed in applications that are non-critical, and that do 1660 not involve or may have an impact on sensitive data and personal 1661 sphere. These include, e.g., read-only temperature sensors deployed 1662 in non-sensitive environments, where the client reads out the values 1663 but does not use the data to control actuators or to base an 1664 important decision on. 1666 Early discovery of devices and resources is a typical use case where 1667 NoSec mode is applied, since the devices involved do not have yet 1668 configured any mutual security relations at the time the discovery 1669 takes place. 1671 If NoSec mode is used, amplification attacks 1672 [I-D.mattsson-core-coap-attacks] are especially feasible to perform 1673 and effective in their impact. Therefore, in order to prevent an 1674 easy proliferation of high-volume amplification attacks, it is 1675 generally NOT RECOMMENDED to use CoAP group communication in NoSec 1676 mode, as further discussed in Section 6.3. 1678 6.2. Group OSCORE 1680 Group OSCORE provides end-to-end application-level security. This 1681 has many desirable properties, including maintaining security 1682 assurances while forwarding traffic through intermediaries (proxies). 1683 Application-level security also tends to more cleanly separate 1684 security from the dynamics of group membership (e.g., the problem of 1685 distributing security keys across large groups with many members that 1686 come and go). 1688 For sensitive and mission-critical applications, CoAP group 1689 communication MUST be protected by using Group OSCORE as specified in 1690 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 1691 from Section 10 of [I-D.ietf-core-oscore-groupcomm] hold for this 1692 specification. 1694 6.2.1. Group Key Management 1696 A key management scheme for secure revocation and renewal of group 1697 security material, namely group rekeying, is required to be adopted 1698 in OSCORE groups. The key management scheme has to preserve forward 1699 security in the OSCORE group, as well as backward security if this is 1700 required by the application. In particular, the key management 1701 scheme MUST comply with the functional steps defined in Section 3.2 1702 of [I-D.ietf-core-oscore-groupcomm]. 1704 Group policies should also take into account the time that the key 1705 management scheme requires to rekey the group, on one hand, and the 1706 expected frequency of group membership changes, i.e., nodes' joining 1707 and leaving, on the other hand. 1709 That is, it may be desirable to not rekey the group upon every single 1710 membership change, in case members' joining and leaving are frequent, 1711 and at the same time a single group rekeying instance takes a non- 1712 negligible time to complete. 1714 In such a case, the Group Manager may cautiously consider to rekey 1715 the group, e.g., after a minimum number of nodes has joined or left 1716 the group within a pre-defined time interval, or according to 1717 communication patterns with predictable time intervals of network 1718 inactivity. This would prevent paralyzing communications in the 1719 group, when a slow rekeying scheme is used and frequently invoked. 1721 At the same, the security implications of delaying the rekeying 1722 process have to be carefully considered and understood, before 1723 enforcing such group policies. 1725 In fact, this comes at the cost of not continuously preserving 1726 backward and forward security, since group rekeying might not occur 1727 upon every single group membership change. That is, most recently 1728 joined nodes would have access to the security material used prior to 1729 their join, and thus be able to access past group communications 1730 protected with that security material. Similarly, until the group is 1731 rekeyed, most recently left nodes would preserve access to group 1732 communications protected with the retained security material. 1734 6.2.2. Source Authentication 1736 Both the group mode and the pairwise mode of Group OSCORE ensure 1737 source authentication of messages exchanged by CoAP endpoints through 1738 CoAP group communication. 1740 To this end, outgoing messages are either countersigned by the 1741 message sender endpoint with its own private key (group mode), or 1742 protected with a symmetric key, which is in turn derived using the 1743 asymmetric keys of the message sender and recipient (pairwise mode). 1745 Thus, both modes allow a recipient CoAP endpoint to verify that a 1746 message has actually been originated by a specific and identified 1747 member of the OSCORE group. 1749 6.2.3. Countering Attacks 1751 As discussed below, Group OSCORE addresses a number of security 1752 attacks mentioned in Section 11 of [RFC7252], with particular 1753 reference to their execution over IP multicast. 1755 * Since Group OSCORE provides end-to-end confidentiality and 1756 integrity of request/response messages, proxies capable of group 1757 communication cannot break message protection, and thus cannot act 1758 as man-in-the-middle beyond their legitimate duties (see 1759 Section 11.2 of [RFC7252]). In fact, intermediaries such as 1760 proxies are not assumed to have access to the OSCORE Security 1761 Context used by group members. Also, with the notable addition of 1762 signatures for the group mode, Group OSCORE protects messages 1763 using the same procedure as OSCORE (see Sections 8 and 9 of 1764 [I-D.ietf-core-oscore-groupcomm]), and especially processes CoAP 1765 options according to the same classification in U/I/E classes. 1767 * Group OSCORE limits the feasibility and impact of amplification 1768 attacks, see Section 6.3 of this document and Section 11.3 of 1769 [RFC7252]. 1771 In fact, upon receiving a request over IP multicast as protected 1772 with Group OSCORE in group mode, a server is able to verify 1773 whether the request is not a replay and originates from the 1774 alleged sender in the OSCORE group, by verifying the signature 1775 included in the request using the public key of that sender (see 1776 Section 8.2 of [I-D.ietf-core-oscore-groupcomm]). Furthermore, as 1777 also discussed in Section 8 of [I-D.ietf-core-oscore-groupcomm], 1778 it is recommended that servers failing to decrypt and verify an 1779 incoming message do not send back any error message. 1781 This limits an adversary to leveraging an intercepted group 1782 request protected with Group OSCORE, and then altering the source 1783 IP address to be the one of the intended amplification victim. 1785 As discussed in the next point, a server can also rely on the Echo 1786 Option for CoAP described in [I-D.ietf-core-echo-request-tag], and 1787 possibly use it to assert that the alleged sender of the group 1788 request (i.e., the CoAP client associated to a certain public key) 1789 is indeed reachable at the claimed source address, especially if 1790 this differs from the one used in previous group requests from the 1791 same CoAP client. Although responses including the Echo Option do 1792 result in amplification, this is limited in volume compared to 1793 when all servers reply with a full-fledged response. 1795 Furthermore, the adversary needs to consider a group request that 1796 specifically targets a resource for which the CoAP servers are 1797 configured to respond. While this can be often correctly assumed 1798 or inferrable from the application context, it is not explicit 1799 from the group request itself, since Group OSCORE protects the 1800 Uri-Path and Uri-Query CoAP Options conveying the respective 1801 components of the target URI. 1803 * Group OSCORE limits the impact of attacks based on IP spoofing 1804 also over IP multicast (see Section 11.4 of [RFC7252]). In fact, 1805 requests and corresponding responses sent in the OSCORE group can 1806 be correctly generated only by legitimate group members. 1808 Within an OSCORE group, the shared symmetric-key security material 1809 strictly provides only group-level authentication. However, 1810 source authentication of messages is also ensured, both in the 1811 group mode by means of signatures (see Sections 8.1 and 8.3 of 1812 [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by 1813 using additionally derived pairwise keys (see Sections 9.3 and 9.5 1814 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints 1815 can verify a message to be originated by the alleged, identifiable 1816 sender in the OSCORE group. 1818 Note that the server may additionally rely on the Echo Option for 1819 CoAP described in [I-D.ietf-core-echo-request-tag], in order to 1820 verify the aliveness and reachability of the client sending a 1821 request from a particular IP address. 1823 * Group OSCORE does not require group members to be equipped with a 1824 good source of entropy for generating security material (see 1825 Section 11.6 of [RFC7252]), and thus does not contribute to create 1826 an entropy-related attack vector against such (constrained) CoAP 1827 endpoints. In particular, the symmetric keys used for message 1828 encryption and decryption are derived through the same HMAC-based 1829 HKDF scheme used for OSCORE (see Section 3.2 of [RFC8613]). 1830 Besides, the OSCORE Master Secret used in such derivation is 1831 securely generated by the Group Manager responsible for the OSCORE 1832 group, and securely provided to the CoAP endpoints when they join 1833 the group. 1835 * Group OSCORE prevents to make any single group member a target for 1836 subverting security in the whole OSCORE group (see Section 11.6 of 1837 [RFC7252]), even though all group members share (and can derive) 1838 the same symmetric-key security material used in the OSCORE group. 1839 In fact, source authentication is always ensured for exchanged 1840 CoAP messages, as verifiable to be originated by the alleged, 1841 identifiable sender in the OSCORE group. This relies on including 1842 a signature computed with a node's individual private key (in the 1843 group mode), or on protecting messages with a pairwise symmetric 1844 key, which is in turn derived from the asymmetric keys of the 1845 sender and recipient CoAP endpoints (in the pairwise mode). 1847 6.3. Risk of Amplification 1849 Section 11.3 of [RFC7252] highlights that CoAP group requests may be 1850 used for accidentally or deliberately performing Denial of Service 1851 attacks, especially in the form of a high-volume amplification 1852 attack, by using all the servers in the CoAP group as attack vectors. 1853 Since potentially all the servers in the CoAP group may respond, the 1854 achieved amplification factor can be high, as multiple responses are 1855 sent and all are likely larger than the group request. 1857 Section 3 of [I-D.mattsson-core-coap-attacks] further discusses this 1858 attack, and notes how the amplification factor would become even 1859 higher when group communication is combined with resource observation 1860 [RFC7641]. That is, a single group request may result in multiple 1861 notification responses from each of the responding servers, 1862 throughout the observation lifetime. 1864 Consistently with Section 11.3 of [RFC7252], a CoAP server in a CoAP 1865 group SHOULD limit the support for CoAP group requests only to the 1866 group resources of the application group(s) using that CoAP group. 1868 It is especially easy to perform an amplification attack when NoSec 1869 mode is used. Therefore, in order to prevent an easy proliferation 1870 of high-volume amplification attacks, it is generally NOT RECOMMENDED 1871 to use CoAP group communication in NoSec mode. 1873 Exceptions should be carefully limited to use cases and accesses to a 1874 group resource that have a specific, narrow and well understood 1875 scope, and where only a few CoAP servers (or ideally only one) would 1876 possibly respond to a group request. 1878 A relevant example is a CoAP client performing the discovery of hosts 1879 such as a group manager or a Resource Directory 1880 [I-D.ietf-core-resource-directory], by probing for them through a 1881 group request sent to the CoAP group. This early, unprotected step 1882 is relevant for a CoAP client that does not know the address of such 1883 hosts in advance, and that does not have yet configured a mutual 1884 security relation with them. In this kind of deployments, such a 1885 discovery procedure does not result in a considerable and harmful 1886 amplification, since only the few CoAP servers object of discovery 1887 are going to respond to the group request targeting that specific 1888 resource. In particular, those hosts can be the only CoAP servers in 1889 that specific CoAP group (hence listening for group requests sent to 1890 that group), and/or the only CoAP servers explicitly configured to 1891 respond to group requests targeting specific group resources. 1893 In any other case, group communications MUST be secured using Group 1894 OSCORE [I-D.ietf-core-oscore-groupcomm], see Section 5. As discussed 1895 in Section 6.2.3, this limits the feasibility and impact of 1896 amplification attacks. 1898 6.4. Replay of Non-Confirmable Messages 1900 Since all requests sent over IP multicast are Non-confirmable, a 1901 client might not be able to know if an adversary has actually 1902 captured one of its transmitted requests and later re-injected it in 1903 the group as a replay to the server nodes. In fact, even if the 1904 servers sent back responses to the replayed request, the client would 1905 typically not have a valid matching request active anymore so this 1906 attack would not accomplish anything in the client. 1908 If Group OSCORE is used, such a replay attack on the servers is 1909 prevented, since a client protects every different request with a 1910 different Sequence Number value, which is in turn included as Partial 1911 IV in the protected message and takes part in the construction of the 1912 AEAD cipher nonce. Thus, a server would be able to detect the 1913 replayed request, by checking the conveyed Partial IV against its own 1914 replay window in the OSCORE Recipient Context associated to the 1915 client. 1917 This requires a server to have a synchronized, up to date view of the 1918 sequence number used by the client. If such synchronization is lost, 1919 e.g., due to a reboot, or suspected so, the server should use the 1920 challenge-response synchronization method described in Appendix E of 1921 [I-D.ietf-core-oscore-groupcomm] and based on the Echo Option for 1922 CoAP defined in [I-D.ietf-core-echo-request-tag], in order to 1923 (re-)synchronize with the client's sequence number. 1925 6.5. Use of CoAP No-Response Option 1927 When CoAP group communication is used in CoAP NoSec (No Security) 1928 mode (see Section 4), the CoAP No-Response Option [RFC7967] could be 1929 misused by a malicious client to evoke as much responses from servers 1930 to a group request as possible, by using the value '0' - Interested 1931 in all responses. This even overrides the default behaviour of a 1932 CoAP server to suppress the response in case there is nothing of 1933 interest to respond with. Therefore, this option can be used to 1934 perform an amplification attack (see Section 6.3). 1936 A proposed mitigation is to only allow this option to relax the 1937 standard suppression rules for a resource in case the option is sent 1938 by an authenticated client. If sent by an unauthenticated client, 1939 the option can be used to expand the classes of responses suppressed 1940 compared to the default rules but not to reduce the classes of 1941 responses suppressed. 1943 6.6. 6LoWPAN and MPL 1945 In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior 1946 to transmission. A 6LoWPAN Router that forwards a fragmented packet 1947 may have a relatively high impact on the occupation of the wireless 1948 channel and may locally experience high memory load due to packet 1949 buffering. For example, the MPL [RFC7731] protocol requires an MPL 1950 Forwarder to store the packet for a longer duration, to allow 1951 multiple forwarding transmissions to neighboring Forwarders. If one 1952 or more of the fragments are not received correctly by an MPL 1953 Forwarder during its packet reassembly time window, the Forwarder 1954 discards all received fragments and at a future point in time it 1955 needs to receive again all the packet fragments (this time, possibly 1956 from another neighboring MPL Forwarder). 1958 For these reasons, a fragmented IPv6 multicast packet is a possible 1959 attack vector in a Denial of Service (DoS) amplification attack. See 1960 Section 6.3 of this document and Section 11.3 of [RFC7252] for more 1961 details on amplification. To mitigate the risk, applications sending 1962 multicast IPv6 requests to 6LoWPAN hosted CoAP servers SHOULD limit 1963 the size of the request to avoid 6LoWPAN fragmentation of the request 1964 packet. A 6LoWPAN Router or (MPL) multicast forwarder SHOULD 1965 deprioritize forwarding for multi-fragment 6LoWPAN multicast packets. 1966 6LoWPAN Border Routers are typical ingress points where multicast 1967 traffic enters into a 6LoWPAN network. Specific MPL Forwarders 1968 (whether located on a 6LBR or not) may also be configured as ingress 1969 points. Any such ingress point SHOULD implement multicast packet 1970 filtering to prevent unwanted multicast traffic from entering a 1971 6LoWPAN network from the outside. For example, it could filter out 1972 all multicast packets for which there is no known multicast listener 1973 on the 6LoWPAN network. See Section 3.10 for protocols that allow 1974 multicast listeners to signal which groups they would like to listen 1975 to. As part of multicast packet filtering, the ingress point SHOULD 1976 implement a filtering criterium based on the size of the multicast 1977 packet. Ingress multicast packets above a defined size may then be 1978 dropped or deprioritized. 1980 6.7. Wi-Fi 1982 In a home automation scenario using Wi-Fi, Wi-Fi security should be 1983 enabled to prevent rogue nodes from joining. The Customer Premises 1984 Equipment (CPE) that enables access to the Internet should also have 1985 its IP multicast filters set so that it enforces multicast scope 1986 boundaries to isolate local multicast groups from the rest of the 1987 Internet (e.g., as per [RFC6092]). In addition, the scope of IP 1988 multicast transmissions and listeners should be site-local (5) or 1989 smaller. For site-local scope, the CPE will be an appropriate 1990 multicast scope boundary point. 1992 6.8. Monitoring 1994 6.8.1. General Monitoring 1996 CoAP group communication can be used to control a set of related 1997 devices: for example, simultaneously turn on all the lights in a 1998 room. This intrinsically exposes the group to some unique monitoring 1999 risks that devices not in a group are not as vulnerable to. For 2000 example, assume an attacker is able to physically see a set of lights 2001 turn on in a room. Then the attacker can correlate an observed CoAP 2002 group communication message to the observed coordinated group action 2003 -- even if the CoAP message is (partly) encrypted. This will give 2004 the attacker side-channel information to plan further attacks (e.g., 2005 by determining the members of the group some network topology 2006 information may be deduced). 2008 6.8.2. Pervasive Monitoring 2010 A key additional threat consideration for group communication is 2011 pervasive monitoring [RFC7258]. CoAP group communication solutions 2012 that are built on top of IP multicast need to pay particular heed to 2013 these dangers. This is because IP multicast is easier to intercept 2014 compared to IP unicast. Also, CoAP traffic is typically used for the 2015 Internet of Things. This means that CoAP (multicast) group 2016 communication may be used for the control and monitoring of critical 2017 infrastructure (e.g., lights, alarms, HVAC, electrical grid, etc.) 2018 that may be prime targets for attack. 2020 For example, an attacker may attempt to record all the CoAP traffic 2021 going over a smart grid (i.e., networked electrical utility) and try 2022 to determine critical nodes for further attacks. For example, the 2023 source node (controller) sends out CoAP group communication messages 2024 which easily identifies it as a controller. CoAP multicast traffic 2025 is inherently more vulnerable compared to unicast, as the same packet 2026 may be replicated over many more links, leading to a higher 2027 probability of packet capture by a pervasive monitoring system. 2029 One mitigation is to restrict the scope of IP multicast to the 2030 minimal scope that fulfills the application need. See the congestion 2031 control recommendations in the last bullet of Section 3.6 to minimize 2032 the scope. Thus, for example, realm-local IP multicast scope is 2033 always preferred over site-local scope IP multicast if this fulfills 2034 the application needs. 2036 Even if all CoAP multicast traffic is encrypted/protected, an 2037 attacker may still attempt to capture this traffic and perform an 2038 off-line attack in the future. 2040 7. IANA Considerations 2042 This document has no actions for IANA. 2044 8. References 2046 8.1. Normative References 2048 [I-D.ietf-core-echo-request-tag] 2049 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 2050 Request-Tag, and Token Processing", Work in Progress, 2051 Internet-Draft, draft-ietf-core-echo-request-tag-12, 1 2052 February 2021, . 2055 [I-D.ietf-core-oscore-groupcomm] 2056 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 2057 and J. Park, "Group OSCORE - Secure Group Communication 2058 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 2059 core-oscore-groupcomm-12, 12 July 2021, 2060 . 2063 [I-D.ietf-cose-rfc8152bis-algs] 2064 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2065 Initial Algorithms", Work in Progress, Internet-Draft, 2066 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2067 . 2070 [I-D.ietf-cose-rfc8152bis-struct] 2071 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2072 Structures and Process", Work in Progress, Internet-Draft, 2073 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2074 . 2077 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2078 Communication Layers", STD 3, RFC 1122, 2079 DOI 10.17487/RFC1122, October 1989, 2080 . 2082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2083 Requirement Levels", BCP 14, RFC 2119, 2084 DOI 10.17487/RFC2119, March 1997, 2085 . 2087 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2088 Thyagarajan, "Internet Group Management Protocol, Version 2089 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2090 . 2092 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2093 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2094 DOI 10.17487/RFC3810, June 2004, 2095 . 2097 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2098 Control Message Protocol (ICMPv6) for the Internet 2099 Protocol Version 6 (IPv6) Specification", STD 89, 2100 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2101 . 2103 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2104 "Transmission of IPv6 Packets over IEEE 802.15.4 2105 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2106 . 2108 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2109 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2110 DOI 10.17487/RFC6282, September 2011, 2111 . 2113 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2114 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2115 . 2117 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2118 Application Protocol (CoAP)", RFC 7252, 2119 DOI 10.17487/RFC7252, June 2014, 2120 . 2122 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2123 Application Protocol (CoAP)", RFC 7641, 2124 DOI 10.17487/RFC7641, September 2015, 2125 . 2127 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2128 the Constrained Application Protocol (CoAP)", RFC 7959, 2129 DOI 10.17487/RFC7959, August 2016, 2130 . 2132 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 2133 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 2134 the Constrained Application Protocol (CoAP)", RFC 8075, 2135 DOI 10.17487/RFC8075, February 2017, 2136 . 2138 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 2139 FETCH Methods for the Constrained Application Protocol 2140 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 2141 . 2143 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2144 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2145 May 2017, . 2147 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2148 Definition Language (CDDL): A Notational Convention to 2149 Express Concise Binary Object Representation (CBOR) and 2150 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2151 June 2019, . 2153 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2154 "Object Security for Constrained RESTful Environments 2155 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2156 . 2158 [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) 2159 Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, 2160 . 2162 8.2. Informative References 2164 [Californium] 2165 Eclipse Foundation, "Eclipse Californium", March 2019, 2166 . 2170 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 2171 CoAP Server & Client in Go", March 2019, 2172 . 2174 [I-D.ietf-ace-key-groupcomm-oscore] 2175 Tiloca, M., Park, J., and F. Palombini, "Key Management 2176 for OSCORE Groups in ACE", Work in Progress, Internet- 2177 Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July 2178 2021, . 2181 [I-D.ietf-ace-oauth-authz] 2182 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2183 H. Tschofenig, "Authentication and Authorization for 2184 Constrained Environments (ACE) using the OAuth 2.0 2185 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2186 draft-ietf-ace-oauth-authz-43, 10 July 2021, 2187 . 2190 [I-D.ietf-ace-oscore-gm-admin] 2191 Tiloca, M., Hoeglund, R., Stok, P. V. D., and F. 2192 Palombini, "Admin Interface for the OSCORE Group Manager", 2193 Work in Progress, Internet-Draft, draft-ietf-ace-oscore- 2194 gm-admin-03, 12 July 2021, 2195 . 2198 [I-D.ietf-core-coap-pubsub] 2199 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2200 Subscribe Broker for the Constrained Application Protocol 2201 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2202 core-coap-pubsub-09, 30 September 2019, 2203 . 2206 [I-D.ietf-core-new-block] 2207 Boucadair, M. and J. Shallow, "Constrained Application 2208 Protocol (CoAP) Block-Wise Transfer Options for Faster 2209 Transmission", Work in Progress, Internet-Draft, draft- 2210 ietf-core-new-block-14, 26 May 2021, 2211 . 2214 [I-D.ietf-core-observe-multicast-notifications] 2215 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 2216 "Observe Notifications as CoAP Multicast Responses", Work 2217 in Progress, Internet-Draft, draft-ietf-core-observe- 2218 multicast-notifications-01, 12 July 2021, 2219 . 2222 [I-D.ietf-core-resource-directory] 2223 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2224 D. Stok, "CoRE Resource Directory", Work in Progress, 2225 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2226 March 2021, . 2229 [I-D.mattsson-core-coap-attacks] 2230 Mattsson, J. P., Fornehed, J., Selander, G., Palombini, 2231 F., and C. Amsüss, "Summarizing Known Attacks on CoAP", 2232 Work in Progress, Internet-Draft, draft-mattsson-core- 2233 coap-attacks-00, 16 May 2021, 2234 . 2237 [I-D.tiloca-core-groupcomm-proxy] 2238 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 2239 Communication", Work in Progress, Internet-Draft, draft- 2240 tiloca-core-groupcomm-proxy-04, 12 July 2021, 2241 . 2244 [I-D.tiloca-core-oscore-discovery] 2245 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 2246 OSCORE Groups with the CoRE Resource Directory", Work in 2247 Progress, Internet-Draft, draft-tiloca-core-oscore- 2248 discovery-09, 12 July 2021, 2249 . 2252 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2253 Capabilities in Customer Premises Equipment (CPE) for 2254 Providing Residential IPv6 Internet Service", RFC 6092, 2255 DOI 10.17487/RFC6092, January 2011, 2256 . 2258 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2259 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2260 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2261 Low-Power and Lossy Networks", RFC 6550, 2262 DOI 10.17487/RFC6550, March 2012, 2263 . 2265 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 2266 the Internet Group Management Protocol (IGMP) and 2267 Multicast Listener Discovery (MLD) for Routers in Mobile 2268 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 2269 May 2012, . 2271 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2272 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2273 2014, . 2275 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 2276 DOI 10.17487/RFC7346, August 2014, 2277 . 2279 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 2280 the Constrained Application Protocol (CoAP)", RFC 7390, 2281 DOI 10.17487/RFC7390, October 2014, 2282 . 2284 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 2285 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 2286 February 2016, . 2288 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2289 Bose, "Constrained Application Protocol (CoAP) Option for 2290 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2291 August 2016, . 2293 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2294 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 2295 Application Protocol) over TCP, TLS, and WebSockets", 2296 RFC 8323, DOI 10.17487/RFC8323, February 2018, 2297 . 2299 [RFC8710] Fossati, T., Hartke, K., and C. Bormann, "Multipart 2300 Content-Format for the Constrained Application Protocol 2301 (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020, 2302 . 2304 Appendix A. Use Cases 2306 To illustrate where and how CoAP-based group communication can be 2307 used, this section summarizes the most common use cases. These use 2308 cases include both secured and non-secured CoAP usage. Each 2309 subsection below covers one particular category of use cases for 2310 CoRE. Within each category, a use case may cover multiple 2311 application areas such as home IoT, commercial building IoT (sensing 2312 and control), industrial IoT/control, or environmental sensing. 2314 A.1. Discovery 2316 Discovery of physical devices in a network, or discovery of 2317 information entities hosted on network devices, are operations that 2318 are usually required in a system during the phases of setup or 2319 (re)configuration. When a discovery use case involves devices that 2320 need to interact without having been configured previously with a 2321 common security context, unsecured CoAP communication is typically 2322 used. Discovery may involve a request to a directory server, which 2323 provides services to aid clients in the discovery process. One 2324 particular type of directory server is the CoRE Resource Directory 2325 [I-D.ietf-core-resource-directory]; and there may be other types of 2326 directories that can be used with CoAP. 2328 A.1.1. Distributed Device Discovery 2330 Device discovery is the discovery and identification of networked 2331 devices -- optionally only devices of a particular class, type, 2332 model, or brand. Group communication is used for distributed device 2333 discovery, if a central directory server is not used. Typically in 2334 distributed device discovery, a multicast request is sent to a 2335 particular address (or address range) and multicast scope of 2336 interest, and any devices configured to be discoverable will respond 2337 back. For the alternative solution of centralized device discovery a 2338 central directory server is accessed through unicast, in which case 2339 group communication is not needed. This requires that the address of 2340 the central directory is either preconfigured in each device or 2341 configured during operation using a protocol. 2343 In CoAP, device discovery can be implemented by CoAP resource 2344 discovery requesting (GET) a particular resource that the sought 2345 device class, type, model or brand is known to respond to. It can 2346 also be implemented using CoAP resource discovery (Section 7 of 2347 [RFC7252]) and the CoAP query interface defined in Section 4 of 2348 [RFC6690] to find these particular resources. Also, a multicast GET 2349 request to /.well-known/core can be used to discover all CoAP 2350 devices. 2352 A.1.2. Distributed Service Discovery 2354 Service discovery is the discovery and identification of particular 2355 services hosted on network devices. Services can be identified by 2356 one or more parameters such as ID, name, protocol, version and/or 2357 type. Distributed service discovery involves group communication to 2358 reach individual devices hosting a particular service; with a central 2359 directory server not being used. 2361 In CoAP, services are represented as resources and service discovery 2362 is implemented using resource discovery (Section 7 of [RFC7252]) and 2363 the CoAP query interface defined in Section 4 of [RFC6690]. 2365 A.1.3. Directory Discovery 2367 This use case is a specific sub-case of Distributed Service Discovery 2368 (Appendix A.1.2), in which a device needs to identify the location of 2369 a Directory on the network to which it can e.g., register its own 2370 offered services, or to which it can perform queries to identify and 2371 locate other devices/services it needs to access on the network. 2372 Section 3.3 of [RFC7390] showed an example of discovering a CoRE 2373 Resource Directory using CoAP group communication. As defined in 2374 [I-D.ietf-core-resource-directory], a resource directory is a web 2375 entity that stores information about web resources and implements 2376 REST interfaces for registration and lookup of those resources. For 2377 example, a device can register itself to a resource directory to let 2378 it be found by other devices and/or applications. 2380 A.2. Operational Phase 2382 Operational phase use cases describe those operations that occur most 2383 frequently in a networked system, during its operational lifetime and 2384 regular operation. Regular usage is when the applications on 2385 networked devices perform the tasks they were designed for and 2386 exchange of application-related data using group communication 2387 occurs. Processes like system reconfiguration, group changes, 2388 system/device setup, extra group security changes, etc. are not part 2389 of regular operation. 2391 A.2.1. Actuator Group Control 2393 Group communication can be beneficial to control actuators that need 2394 to act in synchrony, as a group, with strict timing (latency) 2395 requirements. Examples are office lighting, stage lighting, street 2396 lighting, or audio alert/Public Address systems. Sections 3.4 and 2397 3.5 of [RFC7390] showed examples of lighting control of a group of 2398 6LoWPAN-connected lights. 2400 A.2.2. Device Group Status Request 2402 To properly monitor the status of systems, there may be a need for 2403 ad-hoc, unplanned status updates. Group communication can be used to 2404 quickly send out a request to a (potentially large) number of devices 2405 for specific information. Each device then responds back with the 2406 requested data. Those devices that did not respond to the request 2407 can optionally be polled again via reliable unicast communication to 2408 complete the dataset. The device group may be defined e.g., as "all 2409 temperature sensors on floor 3", or "all lights in wing B". For 2410 example, it could be a status request for device temperature, most 2411 recent sensor event detected, firmware version, network load, and/or 2412 battery level. 2414 A.2.3. Network-wide Query 2416 In some cases a whole network or subnet of multiple IP devices needs 2417 to be queried for status or other information. This is similar to 2418 the previous use case except that the device group is not defined in 2419 terms of its function/type but in terms of its network location. 2420 Technically this is also similar to distributed service discovery 2421 (Appendix A.1.2) where a query is processed by all devices on a 2422 network - except that the query is not about services offered by the 2423 device, but rather specific operational data is requested. 2425 A.2.4. Network-wide / Group Notification 2427 In some cases a whole network, or subnet of multiple IP devices, or a 2428 specific target group needs to be notified of a status change or 2429 other information. This is similar to the previous two use cases 2430 except that the recipients are not expected to respond with some 2431 information. Unreliable notification can be acceptable in some use 2432 cases, in which a recipient does not respond with a confirmation of 2433 having received the notification. In such a case, the receiving CoAP 2434 server does not have to create a CoAP response. If the sender needs 2435 confirmation of reception, the CoAP servers can be configured for 2436 that resource to respond with a 2.xx success status after processing 2437 a notification request successfully. 2439 A.3. Software Update 2441 Group communication can be useful to efficiently distribute new 2442 software (firmware, image, application, etc.) to a group of multiple 2443 devices. In this case, the group is defined in terms of device type: 2444 all devices in the target group are known to be capable of installing 2445 and running the new software. The software is distributed as a 2446 series of smaller blocks that are collected by all devices and stored 2447 in memory. All devices in the target group are usually responsible 2448 for integrity verification of the received software; which can be 2449 done per-block or for the entire software image once all blocks have 2450 been received. Due to the inherent unreliability of CoAP multicast, 2451 there needs to be a backup mechanism (e.g., implemented using CoAP 2452 unicast) by which a device can individually request missing blocks of 2453 a whole software image/entity. Prior to a multicast software update, 2454 the group of recipients can be separately notified that there is new 2455 software available and coming, using the above network-wide or group 2456 notification. 2458 Appendix B. Multi-ETag Option 2460 Section 8.2.1 of [RFC7252] explicitly forbids using an ETag Option in 2461 requests sent over multicast, and leaves a mechanism to suppress 2462 responses for that case for further study. This appendix provides 2463 such a model to "validate" or "revalidate" responses that the client 2464 already has cached. In particular, the group request can indicate 2465 entity-tag values separately for each CoAP server from which the 2466 client wishes to get a response revalidation, together with 2467 addressing information identifying that server. It uses a new CoAP 2468 option, the Multi-ETag Option. Operations related to this validation 2469 model and using the new option are defined in Appendix B.3 for the 2470 client side, and in Appendix B.4 for the server side. 2472 B.1. Option Definition 2474 The Multi-ETag Option has the properties summarized in Figure 3, 2475 which extends Table 4 of [RFC7252]. The Multi-ETag Option is 2476 elective, safe to forward, part of the cache key, and repeatable. 2478 The option is intended only for group requests, as directly sent to a 2479 CoAP group or to a CoAP proxy that forwards it to the CoAP group (see 2480 Section 3.5). 2482 +------+---+---+---+---+------------+--------+--------+---------+ 2483 | No. | C | U | N | R | Name | Format | Length | Default | 2484 +------+---+---+---+---+------------+--------+--------+---------+ 2485 | | | | | | | | | | 2486 | TBD1 | | | | x | Multi-ETag | (*) | any | (none) | 2487 | | | | | | | | | | 2488 +------+---+---+---+---+------------+--------+--------+---------+ 2489 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 2491 (*) See below. 2493 Figure 3: The Multi-ETag Option. 2495 The Multi-ETag Option has the same properties of the ETag Option 2496 defined in Section 5.10.6 of [RFC7252], but it differs in the format 2497 and length, as well as having a different reason for its 2498 repeatability. 2500 Each occurrence of the Multi-ETag Option targets exactly one of the 2501 servers in the CoAP group, from which the client wishes to get a 2502 response revalidation. The option value is set to a CBOR sequence 2503 [RFC8742] composed of (1+M) elements, where: 2505 * The first element specifies the addressing information of the 2506 corresponding server, encoded as defined in Appendix B.2. 2508 This mirrors the format of the Response-Forwarding option defined 2509 in Section 3 of [I-D.tiloca-core-groupcomm-proxy]. Thus, in the 2510 presence of a forward proxy supporting the mechanism defined in 2511 [I-D.tiloca-core-groupcomm-proxy], the client can seamlessly use 2512 the server addressing information obtained from the proxy, when 2513 this forwards back a response to a group request from that server. 2515 * The following M elements are CBOR byte strings, each of which has 2516 as value an entity-tag value that the client wants to try against 2517 the corresponding server. 2519 The entity-tag values included in the Multi-ETag Option are 2520 subject to the same considerations for the entity-tag values used 2521 in an ETag Option (see Section 5.10.6 of [RFC7252]). 2523 The Multi-ETag Option is of class E in terms of OSCORE processing 2524 (see Section 4.1 of [RFC8613]). 2526 B.2. Encoding of Server Addressing Information 2528 The first element of the CBOR sequence in the Multi-ETag Option value 2529 is set to the byte serialization of the CBOR array 'tp_info' defined 2530 in Section 2.2.1 of [I-D.ietf-core-observe-multicast-notifications], 2531 including only the set of elements 'srv_addr'. 2533 In turn, the set includes the integer 'tp_id' identifying the used 2534 transport protocol, and further elements whose number, format and 2535 encoding depend on the value of 'tp_id'. 2537 When the Multi-ETag Option is used in group requests transported over 2538 UDP as in this specification, the 'tp_info' array includes the 2539 following elements, encoded as defined in Section 2.2.1.1 of 2540 [I-D.ietf-core-observe-multicast-notifications]. 2542 * 'tp_id': the CBOR integer with value 1 ("UDP"), from the "Value" 2543 column of the "CoAP Transport Information Registry" Registry 2544 defined in Section 14.4 of 2545 [I-D.ietf-core-observe-multicast-notifications] 2547 * 'srv_host': a CBOR byte string, with value the unicast IP address 2548 of the server. This element is tagged and identified by the CBOR 2549 tag 260 "Network Address (IPv4 or IPv6 or MAC Address)". 2551 * 'srv_port': as a CBOR unsigned integer or the CBOR simple value 2552 Null. If it is a CBOR integer, it has as value the destination 2553 port number where to send individual requests intended to the 2554 server. This element MAY be present. If not included, the 2555 default port number 5683 is assumed. 2557 The CDDL notation [RFC8610] provided below describes the 'tp_info' 2558 CBOR array using the format above. 2560 tp_info = [ 2561 tp_id : 1, ; UDP as transport protocol 2562 srv_host : #6.260(bstr), ; IP address where to reach the server 2563 srv_port : uint / null ; Port number where to reach the server 2564 ] 2566 B.3. Processing on the Client Side 2568 Similar to what is defined in Section 5.6.2 of [RFC7252], the client 2569 may have one or more stored responses for a GET or FETCH group 2570 request sent to the CoAP group, but cannot use any of them (e.g., 2571 because they are not fresh). 2573 In that case, the client can send a GET or FETCH group request, in 2574 order to give the origin servers an opportunity both to select a 2575 stored response to be used, and to update its freshness. As in 2576 [RFC7252], this process is known as "validating" or "revalidating" 2577 the stored response. 2579 When sending such a group request, the endpoint SHOULD include one 2580 Multi-ETag Option for each server it wishes to revalidate the 2581 corresponding response with. As defined in Section 3.2.2, the Multi- 2582 ETag Option can include multiple entity-tag values, each applicable 2583 to a stored response from the corresponding server for that group 2584 request. 2586 Specifically, in the same GET or FETCH group request: 2588 * The client MUST NOT include one or more ETag Option(s) together 2589 with one or more Multi-ETag Option(s). 2591 * The client MUST include only one Multi-ETag Option for each server 2592 it wishes to get a response revalidation from. 2594 * The client SHOULD limit the number of Multi-ETag Options, hence 2595 limiting the number of servers as intended target of the 2596 revalidation process, and SHOULD rather spread revalidation with 2597 different sets of servers over different group requests. Also, 2598 the client SHOULD limit the number of entity-tag values specified 2599 in each Multi-ETag Option, preferably indicating only one entity- 2600 tag value. 2602 This allows for limiting the overall size of the group request. 2603 As a guideline, the server addressing information can be 9-24 2604 bytes in size, while each entity-tag value can be 1-8 bytes in 2605 size. Thus, a single Multi-ETag Option can be up to (24 + 8 * M) 2606 bytes in size, where M is the number of entity-tag values it 2607 includes. 2609 A 2.03 (Valid) response indicates that the stored response identified 2610 by the entity-tag given in the response's ETag Option can be reused, 2611 after updating the stored response as described in Section 5.9.1.3 of 2612 [RFC7252]. So the client can determine if any one of the stored 2613 representations from that server is current, without need to transfer 2614 the current resource representation again. 2616 Any other Response Code indicates that none of the stored responses 2617 from that server, identified in the Multi-ETag Option of the group 2618 request, are suitable. Instead, such response SHOULD be used to 2619 satisfy the request and MAY replace the stored response. 2621 B.4. Processing on the Server Side 2623 If a GET or FETCH request includes both one or more ETag Options 2624 together with one or more Multi-ETag Options, then the server MUST 2625 ignore all the included ETag and Multi-ETag Options. 2627 The server MUST ignore any Multi-ETag Option which is malformed, or 2628 included in a request that is neither GET nor FETCH, or which 2629 specifies addressing information not matching with its own endpoint 2630 address. 2632 The server considers only its pertaining Multi-ETag Option, i.e., 2633 specifying addressing information associated to its own endpoint. 2634 The server MUST ignore any pertaining Multi-ETag Option that occurs 2635 more than once. 2637 If the pertaining Multi-ETag Option specifies the CBOR simple value 2638 Null for the 'srv_port' element of 'tp_info' (see Appendix B.2), the 2639 server MUST assume the default port number 5683. 2641 Then, the server can issue a 2.03 (Valid) response in place of a 2.05 2642 (Content) response, if one of the entity-tag values from the 2643 pertaining Multi-ETag Option is the entity-tag for the current 2644 resource representation, i.e., it is valid. The 2.03 (Valid) 2645 response echoes this specific entity-tag within an ETag Option 2646 included in the response. 2648 The inclusion of an ETag Option in a response works as defined in 2649 Section 5.6.10.1 of [RFC7252]. 2651 B.5. CoAP Option Numbers Registry 2653 IANA is asked to enter the following option numbers to the "CoAP 2654 Option Numbers" registry defined in [RFC7252] within the "CoRE 2655 Parameters" registry. 2657 +--------+-------------+-----------------+ 2658 | Number | Name | Reference | 2659 +--------+-------------+-----------------+ 2660 | TBD1 | Multi-ETag | [This document] | 2661 +--------+-------------+-----------------+ 2663 Appendix C. Document Updates 2665 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2667 C.1. Version -03 to -04 2669 * Multi-ETag Option for response revalidation moved to appendix. 2671 * ETag Option usage added. 2673 * Q-Block Options added in the block-wise transfer section. 2675 * Caching at proxies moved to draft-tiloca-core-groupcomm-proxy. 2677 * Client-Proxy response revalidation with the Group-ETag Option 2678 moved to draft-tiloca-core-groupcomm-proxy. 2680 * Security considerations on amplification attacks. 2682 * Generalized transport protocols to include others than UDP/IP 2683 multicast; and security protocols other than Group OSCORE. 2685 * Overview of security cases with proxies. 2687 * Editorial improvements. 2689 C.2. Version -02 to -03 2691 * Multiple responses from same server handled at the application. 2693 * Clarifications about issues with forward-proxies. 2695 * Operations for reverse-proxies. 2697 * Caching of responses at proxies. 2699 * Client-Server response revalidation, with Multi-ETag Option. 2701 * Client-Proxy response revalidation, with the Group-ETag Option. 2703 C.3. Version -01 to -02 2705 * Clarified relation between security groups and application groups. 2707 * Considered also FETCH for requests over IP multicast. 2709 * More details on Observe re-registration. 2711 * More details on Proxy intermediaries. 2713 * More details on servers changing port number in the response. 2715 * Usage of the Uri-Host Option to indicate an application group. 2717 * Response suppression based on classes of error codes. 2719 C.4. Version -00 to -01 2721 * Clarifications on group memberships for the different group types. 2723 * Simplified description of Token reusage, compared to the unicast 2724 case. 2726 * More details on the rationale for response suppression. 2728 * Clarifications of creation and management of security groups. 2730 * Clients more knowledgeable than proxies about stopping receiving 2731 responses. 2733 * Cancellation of group observations. 2735 * Clarification on multicast scope to use. 2737 * Both the group mode and pairwise mode of Group OSCORE are 2738 considered. 2740 * Updated security considerations. 2742 * Editorial improvements. 2744 Acknowledgments 2746 The authors sincerely thank Christian Amsuess, Carsten Bormann, 2747 Thomas Fossati, Rikard Hoeglund, John Mattsson and Jim Schaad for 2748 their comments and feedback. 2750 The work on this document has been partly supported by VINNOVA and 2751 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2752 (Grant agreement 952652). 2754 Authors' Addresses 2756 Esko Dijk 2757 IoTconsultancy.nl 2758 \________________\ 2759 Utrecht 2760 Netherlands 2762 Email: esko.dijk@iotconsultancy.nl 2764 Chonggang Wang 2765 InterDigital 2766 1001 E Hector St, Suite 300 2767 Conshohocken, PA 19428 2768 United States 2770 Email: Chonggang.Wang@InterDigital.com 2772 Marco Tiloca 2773 RISE AB 2774 Isafjordsgatan 22 2775 SE-16440 Stockholm Kista 2776 Sweden 2778 Email: marco.tiloca@ri.se