idnits 2.17.1 draft-ietf-core-groupcomm-bis-05.txt: -(2221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2353): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2376): 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 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 915 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-21) exists of draft-ietf-core-oscore-groupcomm-13 ** 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-12 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-04 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-03) exists of draft-mattsson-core-coap-attacks-01 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-05 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-10 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 3 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: 28 April 2022 RISE AB 8 25 October 2021 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-ietf-core-groupcomm-bis-05 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 RFC 7390, while it updates RFC 7252 and RFC 7641. 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 28 April 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 1.3. Changes to Other Documents . . . . . . . . . . . . . . . 6 75 2. Group Definition and Group Configuration . . . . . . . . . . 6 76 2.1. Group Definition . . . . . . . . . . . . . . . . . . . . 6 77 2.1.1. CoAP Group . . . . . . . . . . . . . . . . . . . . . 7 78 2.1.2. Application Group . . . . . . . . . . . . . . . . . . 7 79 2.1.3. Security Group . . . . . . . . . . . . . . . . . . . 7 80 2.1.4. Relations Between Group Types . . . . . . . . . . . . 8 81 2.2. Group Configuration . . . . . . . . . . . . . . . . . . . 10 82 2.2.1. Group Naming . . . . . . . . . . . . . . . . . . . . 10 83 2.2.2. Group Creation and Membership . . . . . . . . . . . . 12 84 2.2.3. Group Discovery . . . . . . . . . . . . . . . . . . . 13 85 2.2.4. Group Maintenance . . . . . . . . . . . . . . . . . . 15 86 3. CoAP Usage in Group Communication . . . . . . . . . . . . . . 16 87 3.1. Request/Response Model . . . . . . . . . . . . . . . . . 16 88 3.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 16 89 3.1.2. Response Suppression . . . . . . . . . . . . . . . . 17 90 3.1.3. Repeating a Request . . . . . . . . . . . . . . . . . 17 91 3.1.4. Request/Response Matching and Distinguishing 92 Responses . . . . . . . . . . . . . . . . . . . . . . 18 93 3.1.5. Token Reuse . . . . . . . . . . . . . . . . . . . . . 18 94 3.1.6. Client Handling of Multiple Responses With Same 95 Token . . . . . . . . . . . . . . . . . . . . . . . . 19 97 3.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 3.2.1. Freshness Model . . . . . . . . . . . . . . . . . . . 21 99 3.2.2. Validation Model . . . . . . . . . . . . . . . . . . 21 100 3.3. URI Path Selection . . . . . . . . . . . . . . . . . . . 22 101 3.4. Port Selection for UDP Transport . . . . . . . . . . . . 23 102 3.5. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 23 103 3.5.1. Forward-Proxies . . . . . . . . . . . . . . . . . . . 24 104 3.5.2. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 25 105 3.6. Congestion Control . . . . . . . . . . . . . . . . . . . 27 106 3.7. Observing Resources . . . . . . . . . . . . . . . . . . . 28 107 3.8. Block-Wise Transfer . . . . . . . . . . . . . . . . . . . 30 108 3.9. Transport Protocols . . . . . . . . . . . . . . . . . . . 31 109 3.9.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 31 110 3.9.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 32 111 3.9.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 32 112 3.9.4. Other Transports . . . . . . . . . . . . . . . . . . 32 113 3.10. Interworking with Other Protocols . . . . . . . . . . . . 33 114 3.10.1. MLD/MLDv2/IGMP/IGMPv3 . . . . . . . . . . . . . . . 33 115 3.10.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . 33 116 3.10.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . 34 117 4. Unsecured Group Communication . . . . . . . . . . . . . . . . 35 118 5. Secured Group Communication using Group OSCORE . . . . . . . 35 119 5.1. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 35 120 5.2. Secure Group Maintenance . . . . . . . . . . . . . . . . 37 121 5.3. Proxy Security . . . . . . . . . . . . . . . . . . . . . 38 122 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 123 6.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 39 124 6.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 40 125 6.2.1. Group Key Management . . . . . . . . . . . . . . . . 41 126 6.2.2. Source Authentication . . . . . . . . . . . . . . . . 41 127 6.2.3. Countering Attacks . . . . . . . . . . . . . . . . . 42 128 6.3. Risk of Amplification . . . . . . . . . . . . . . . . . . 44 129 6.4. Replay of Non-Confirmable Messages . . . . . . . . . . . 45 130 6.5. Use of CoAP No-Response Option . . . . . . . . . . . . . 46 131 6.6. 6LoWPAN and MPL . . . . . . . . . . . . . . . . . . . . . 47 132 6.7. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 47 133 6.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 48 134 6.8.1. General Monitoring . . . . . . . . . . . . . . . . . 48 135 6.8.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 48 136 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 137 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 138 8.1. Normative References . . . . . . . . . . . . . . . . . . 49 139 8.2. Informative References . . . . . . . . . . . . . . . . . 51 140 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 54 141 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 54 142 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 55 143 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 55 144 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 55 146 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 56 147 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 56 148 A.2.2. Device Group Status Request . . . . . . . . . . . . . 56 149 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 56 150 A.2.4. Network-wide / Group Notification . . . . . . . . . . 57 151 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 57 152 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 57 153 B.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 57 154 B.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 58 155 B.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 58 156 B.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 59 157 B.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 59 158 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 59 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 161 1. Introduction 163 This document specifies group communication using the Constrained 164 Application Protocol (CoAP) [RFC7252], together with UDP/IP multicast 165 as the default transport for CoAP group communication messages. CoAP 166 is a RESTful communication protocol that is used in resource- 167 constrained nodes, and in resource-constrained networks where packet 168 sizes should be small. This area of use is summarized as Constrained 169 RESTful Environments (CoRE). 171 One-to-many group communication can be achieved in CoAP, by a client 172 using UDP/IP multicast data transport to send multicast CoAP request 173 messages. In response, each server in the addressed group sends a 174 response message back to the client over UDP/IP unicast. Notable 175 CoAP implementations supporting group communication include the 176 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 177 Foundation and the "Implementation of CoAP Server & Client in Go" 178 [Go-OCF] from the Open Connectivity Foundation (OCF). 180 Both unsecured and secured CoAP group communication are specified in 181 this document. Security is achieved by using Group Object Security 182 for Constrained RESTful Environments (Group OSCORE) 183 [I-D.ietf-core-oscore-groupcomm], which in turn builds on Object 184 Security for Constrained Restful Environments (OSCORE) [RFC8613]. 185 This method provides end-to-end application-layer security protection 186 of CoAP messages, by using CBOR Object Signing and Encryption (COSE) 187 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 189 This documents replaces and obsoletes [RFC7390], while it updates 190 both [RFC7252] and [RFC7641]. A summary of the changes and additions 191 to these documents is provided in Section 1.3. 193 All sections in the body of this document are normative, while 194 appendices are informative. For additional background about use 195 cases for CoAP group communication in resource-constrained devices 196 and networks, see Appendix A. 198 1.1. Scope 200 For group communication, only those solutions that use CoAP messages 201 over a "one-to-many" (i.e., non-unicast) transport protocol are in 202 the scope of this document. There are alternative methods to achieve 203 group communication using CoAP, using unicast only. One example is 204 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 205 broker server that CoAP clients access via unicast communication. 206 These alternative methods may be usable for the same or similar use 207 cases as the ones targeted in this document. 209 This document defines UDP/IP multicast as the default transport 210 protocol for CoAP group requests, as in [RFC7252]. Other transport 211 protocols (which may include broadcast, non-IP multicast, geocast, 212 etc.) are not described in detail and are left for future work. 213 Although UDP/IP multicast transport is assumed in most of the text in 214 this document, we expect many of the considerations for UDP/IP 215 multicast can be re-used for alternative transport protocols. 217 Furthermore, this document defines Group OSCORE 218 [I-D.ietf-core-oscore-groupcomm] as the default group communication 219 security solution for CoAP. Security solutions for group 220 communication and configuration other than Group OSCORE are left for 221 future work. General principles for secure group configuration are 222 in scope. 224 1.2. Terminology 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 228 "OPTIONAL" in this document are to be interpreted as described in BCP 229 14 [RFC2119] [RFC8174] when, and only when, they appear in all 230 capitals, as shown here. 232 This specification requires readers to be familiar with CoAP 233 terminology [RFC7252]. Terminology related to group communication is 234 defined in Section 2.1. 236 Furthermore, "Security material" refers to any security keys, 237 counters or parameters stored in a device that are required to 238 participate in secure group communication with other devices. 240 1.3. Changes to Other Documents 242 This document obsoletes and replaces [RFC7390] as follows. 244 * It defines separate definitions for CoAP groups, application 245 groups and security groups, together with high-level guidelines on 246 their configuration (see Section 2). 248 * It defines the use of Group OSCORE 249 [I-D.ietf-core-oscore-groupcomm] as the security protocol to 250 protect group communication for CoAP, together with high-level 251 guidelines on secure group maintenance (see Section 5). 253 * It updates all the guidelines about using group communication for 254 CoAP (see Section 3). 256 * It strongly discourages unsecured group communication for CoAP 257 based on the "NoSec" mode (see Section 4 and Section 6.1) and 258 highlights the risk of amplification attacks (see Section 6.3). 260 This document updates [RFC7252] as follows. 262 * It updates the request/response model for group communication, as 263 to response suppression (see Section 3.1.2) and token reuse time 264 (see Section 3.1.5). 266 * It updates the freshness model and validation model to use for 267 cached responses (see Section 3.2.1 and Section 3.2.2). 269 This document updates [RFC7641] as follows. 271 * It defines the use of the CoAP Observe Option in group requests, 272 for both the GET method and the FETCH method [RFC8132], together 273 with normative behavior for both CoAP clients and CoAP servers 274 (see Section 3.7). 276 2. Group Definition and Group Configuration 278 In the following, different group types are first defined in 279 Section 2.1. Then, Group configuration, including group creation and 280 maintenance by an application, user or commissioning entity is 281 considered in Section 2.2. 283 2.1. Group Definition 285 Three types of groups and their mutual relations are defined in this 286 section: CoAP group, application group, and security group. 288 2.1.1. CoAP Group 290 A CoAP group is defined as a set of CoAP endpoints, where each 291 endpoint is configured to receive CoAP group messages that are sent 292 to the group's associated IP multicast address and UDP port. An 293 endpoint may be a member of multiple CoAP groups by subscribing to 294 multiple IP multicast groups and/or listening on multiple UDP ports. 295 Group membership(s) of an endpoint may dynamically change over time. 296 A device sending a CoAP group message to a CoAP group is not 297 necessarily itself a member of this CoAP group: it is a member only 298 if it also has a CoAP endpoint listening on the group's associated IP 299 multicast address and UDP port. A CoAP group can be encoded within a 300 Group URI. This is defined as a CoAP URI that has the "coap" scheme 301 and includes in the authority part either an IP multicast address or 302 a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN)) 303 that can be resolved to an IP multicast address. A Group URI also 304 contains an optional UDP port number in the authority part. Group 305 URIs follow the regular CoAP URI syntax (see Section 6 of [RFC7252]). 307 2.1.2. Application Group 309 Besides CoAP groups, that have relevance at the level of IP networks 310 and CoAP endpoints, there are also application groups. An 311 application group is a set of CoAP server endpoints that share a 312 common set of CoAP resources. An endpoint may be a member of 313 multiple application groups. An application group has relevance at 314 the application level -- for example an application group could 315 denote all lights in an office room or all sensors in a hallway. A 316 client endpoint that sends a group communication message to an 317 application group is not necessarily itself a member of this 318 application group. There can be a one-to-one or a one-to-many 319 relation between a CoAP group and application group(s). An 320 application group name is optionally encoded explicitly in the CoAP 321 request, for example in the URI path. If not explicitly encoded, the 322 application group is implicitly derived by the receiver, based on 323 information in the CoAP request. See Section 2.2.1 for more details 324 on identifying the application group. 326 2.1.3. Security Group 328 For secure group communication, a security group is required. A 329 security group is a group of endpoints that each store group security 330 material, such that they can mutually exchange secured messages and 331 verify secured messages. So, a client endpoint needs to be a member 332 of a security group in order to send a valid secured group 333 communication message to this group. An endpoint may be a member of 334 multiple security groups. There can be a many-to-many relation 335 between security groups and CoAP groups, but often it is one-to-one. 337 Also, there can be a many-to-many relation between security groups 338 and application groups, but often it is one-to-one. A special 339 security group named "NoSec" identifies group communication without 340 any security at the transport layer nor at the CoAP layer. 342 2.1.4. Relations Between Group Types 344 Using the above group type definitions, a CoAP group communication 345 message sent by an endpoint can be represented as a tuple that 346 contains one instance of each group type: 348 (application group, CoAP group, security group) 350 A special note is appropriate about the possible relation between 351 security groups and application groups. 353 On one hand, multiple application groups may use the same security 354 group. Thus, the same group security material is used to protect the 355 messages targeting any of those application groups. This has the 356 benefit that typically less storage, configuration and updating are 357 required for security material. In this case, a CoAP endpoint is 358 supposed to know the exact application group to refer to for each 359 message that is sent or received, based on, e.g., the used server 360 port number, the targeted resource, or the content and structure of 361 the message payload. 363 On the other hand, a single application group may use multiple 364 security groups. Thus, different messages targeting the resources of 365 the application group can be protected with different security 366 material. This can be convenient, for example, if the security 367 groups differ with respect to the cryptographic algorithms and 368 related parameters they use. In this case, a CoAP client can join 369 just one of the security groups, based on what it supports and 370 prefers, while a CoAP server in the application group would rather 371 have to join all of them. 373 Beyond this particular case, applications should be careful in 374 associating a same application group to multiple security groups. In 375 particular, it is NOT RECOMMENDED to use different security groups to 376 reflect different access policies for resources in a same application 377 group. That is, being a member of a security group actually grants 378 access only to exchange secured messages and enables authentication 379 of group members, while access control (authorization) to use 380 resources in the application group belongs to a separate security 381 domain. It has to be separately enforced by leveraging the resource 382 properties or through dedicated access control credentials assessed 383 by separate means. 385 Figure 1 summarizes the relations between the different types of 386 groups described above in UML class diagram notation. The class 387 attributes in square brackets are optionally defined. 389 +------------------------+ +--------------------+ 390 | Application group | | CoAP group | 391 |........................| |....................| 392 | | | | 393 | [ - group name ] +-----------------+ - IP mcast address | 394 | | 1...N 1 | - UDP port | 395 | | | | 396 | | | | 397 +-------------+----------+ +---------+----------+ 398 | 1...N | 1...N 399 | | 400 | | 401 | | 1...N 402 | +----------+------------+ 403 | | Security group | 404 | |.......................| 405 | | | 406 \---------------------------+ - Security group name | 407 1...N | - Security material | 408 | | 409 +-----------------------+ 411 Figure 1: Relations Among Different Group Types 413 Figure 2 provides a deployment example of the relations between the 414 different types of groups. It shows six CoAP servers (Srv1-Srv6) and 415 their respective resources hosted (/resX). There are three 416 application groups (1, 2, 3) and two security groups (1, 2). 417 Security Group 1 is used by both Application Group 1 and 2. Three 418 clients (Cli1, Cli2, Cli3) are configured with security material for 419 Security Group 1. Two clients (Cli2, Cli4) are configured with 420 security material for Security Group 2. All the shown application 421 groups use the same CoAP group (not shown in the figure), i.e., one 422 specific multicast IP address and UDP port on which all the shown 423 resources are hosted for each server. 425 ________________________________ _________________________________ 426 / \ / \ 427 | +---------------------+ | | +---------------------+ | 428 | | Application Group 1 | | | | Application Group 3 | Cli2 | 429 | | | | | | | | 430 | Cli1 | Srv1 Srv2 Srv3 | | | | Srv5 Srv6 | Cli4 | 431 | | /resA /resA /resA | | | | /resC /resC | | 432 | Cli2 +---------------------+ | | | /resD /resD | | 433 | | | +---------------------+ | 434 | Cli3 Security Group 1 | | | 435 | | | Security Group 2 | 436 | +---------------------+ | \_________________________________/ 437 | | Application Group 2 | | 438 | | | | 439 | | Srv1 Srv4 | | 440 | | /resB /resB | | 441 | +---------------------+ | 442 \________________________________/ 444 Figure 2: Deployment Example of Different Group Types 446 2.2. Group Configuration 448 The following defines how groups of different types are named, 449 created, discovered and maintained. 451 2.2.1. Group Naming 453 A CoAP group is identified and named by the authority component in 454 the Group URI, which includes host (possibly an IP multicast address 455 literal) and an optional UDP port number. It is recommended to 456 configure an endpoint with an IP multicast address literal, instead 457 of a hostname, when configuring a CoAP group membership. This is 458 because DNS infrastructure may not be deployed in many constrained 459 networks. In case a group hostname is configured, it can be uniquely 460 mapped to an IP multicast address via DNS resolution - if DNS client 461 functionality is available in the endpoint being configured and the 462 DNS service is supported in the network. Some examples of 463 hierarchical CoAP group FQDN naming (and scoping) for a building 464 control application were shown in Section 2.2 of [RFC7390]. 466 An application group can be named in many ways through different 467 types of identifiers, such as name string, (integer) number, URI or 468 other type of string. An application group name may be explicitly 469 encoded in a CoAP Group URI, or it may be not included in the Group 470 URI. This is an implementation-specific decision. If the 471 application group name is explicitly encoded in a CoAP Group URI, it 472 can be encoded within one of the 473 * URI path component: this is the most common and RECOMMENDED method 474 to encode the application group name. A best practice for 475 encoding application group into a Group URI is to use one URI path 476 component to identify the application group and use the following 477 URI paths component(s) to identify the resource within this 478 application group. For example, //res1 or 479 /base//res1/res2 conform to this practice. An 480 application group name (like ) should be as short as 481 possible when used in constrained networks. 483 * URI query component: using this method, the query may consist of 484 the group name (?) or it may be one parameter of the 485 query (?g= or ?param1=value1&gn=). 487 * URI host subcomponent: using this method, the application group 488 becomes equal to the CoAP group. This can only be used if there 489 is a one-to-one mapping between CoAP groups and application 490 groups. 492 * URI port subcomponent: using this method, the application group is 493 identified by a number that is encoded in some way in the 494 destination port. 496 There are also methods to encode the application group name within 497 the CoAP request even though it is not encoded within the Group URI. 498 Examples of such methods are: 500 * encode in a Uri-Host Option [RFC7252] which is added to the CoAP 501 request by the client before sending it out. Each CoAP server 502 that is part of the CoAP group, receiving this request, decodes 503 the Uri-Host Option and treats it as an application group name. 504 (It can also treat the application group name in this Option as a 505 "virtual CoAP server" specific to that application group, exactly 506 in the same way that the Uri-Host Option was intended to allow 507 support for multiple virtual servers hosted on the same port. The 508 net effect of both treatments is the same.) 510 * encode in a new (custom/application-specific) CoAP Option which is 511 added to the CoAP request by the client before sending it out. 512 Each CoAP server that is part of the CoAP group, receiving this 513 request, would by design understand this Option, would decode it, 514 and treat it as an application group name. 516 Finally, it is possible to not encode the application group name at 517 all within the CoAP request. This yields the most compact 518 representation on the wire. In this case, each CoAP server needs to 519 determine the application group based on contextual information, such 520 as client identity and/or target resource. For example, each 521 application group on a server could have a unique set of resources 522 that does not overlap with any resources of other application groups. 524 Appendix A of [I-D.ietf-core-resource-directory] shows an example 525 registration of an application group into a Resource Directory (RD), 526 along with the CoAP group it uses and the resources supported by the 527 application group. In this example an application group name 528 "lights" is encoded in the "ep" (endpoint) attribute of the RD 529 registration entry. The CoAP group is ff35:30:2001:db8:f1::8000:1 530 and the "NoSec" security group is used. 532 A security group is identified by a stable and invariant string used 533 as group name, which is generally not related with other kinds of 534 group identifiers, specific to the chosen security solution. The 535 "NoSec" security group name MUST be only used to represent the case 536 of group communication without any security. It is typically 537 characterized by the absence of any security group name, identifier, 538 or security-related data structures in the CoAP message. 540 2.2.2. Group Creation and Membership 542 To create a CoAP group, a configuring entity defines an IP multicast 543 address (or hostname) for the group and optionally a UDP port number 544 in case it differs from the default CoAP port 5683. Then, it 545 configures one or more devices as listeners to that IP multicast 546 address, with a CoAP endpoint listening on the group's associated UDP 547 port. These endpoints/devices are the group members. The 548 configuring entity can be, for example, a local application with pre- 549 configuration, a user, a software developer, a cloud service, or a 550 local commissioning tool. Also, the devices sending CoAP requests to 551 the group in the role of CoAP client need to be configured with the 552 same information, even though they are not necessarily group members. 553 One way to configure a client is to supply it with a CoAP Group URI. 554 The IETF does not define a mandatory protocol to accomplish CoAP 555 group creation. [RFC7390] defined an experimental protocol for 556 configuration of group membership for unsecured group communication, 557 based on JSON-formatted configuration resources. For IPv6 CoAP 558 groups, common multicast address ranges that are used to configure 559 group addresses from are ff1x::/16 and ff3x::/16. 561 To create an application group, a configuring entity may configure a 562 resource (name) or set of resources on CoAP endpoints, such that a 563 CoAP request with Group URI sent by a configured CoAP client will be 564 processed by one or more CoAP servers that have the matching URI path 565 configured. These servers are the application group members. 567 To create a security group, a configuring entity defines an initial 568 subset of the related security material. This comprises a set of 569 group properties including the cryptographic algorithms and 570 parameters used in the group, as well as additional information 571 relevant throughout the group life-cycle, such as the security group 572 name and description. This task MAY be entrusted to a dedicated 573 administrator, that interacts with a Group Manager as defined in 574 Section 5. After that, further security materials to protect group 575 communications have to be generated, compatible with the specified 576 group configuration. 578 To participate in a security group, CoAP endpoints have to be 579 configured with the group security material used to protect 580 communications in the associated application/CoAP groups. The part 581 of the process that involves secure distribution of group security 582 material MAY use standardized communication with a Group Manager as 583 defined in Section 5. For unsecure group communication using the 584 "NoSec" security group, any CoAP endpoint may become a group member 585 at any time: there is no configuring entity that needs to provide 586 security material for this group, as there is no security material 587 for it. This means that group creation and membership cannot be 588 tightly controlled for the "NoSec" group. 590 The configuration of groups and membership may be performed at 591 different moments in the life-cycle of a device; for example during 592 product (software) creation, in the factory, at a reseller, on-site 593 during first deployment, or on-site during a system reconfiguration 594 operation. 596 2.2.3. Group Discovery 598 It is possible for CoAP endpoints to discover application groups as 599 well as CoAP groups, by using the RD-Groups usage pattern of the CoRE 600 Resource Directory (RD), as defined in Appendix A of 601 [I-D.ietf-core-resource-directory]. In particular, an application 602 group can be registered to the RD, specifying the reference IP 603 multicast address of its associated CoAP group. The registration of 604 groups is typically performed by a Commissioning Tool. Later on, 605 CoAP endpoints can discover the registered application groups and 606 related CoAP group(s), by using the lookup interface of the RD. 608 CoAP endpoints can also discover application groups and/or CoAP 609 groups using a GET request on the /.well-known/core resource. Such a 610 request may be sent to a known CoAP group multicast address that is 611 associated to one or more application group(s), or to the All CoAP 612 Nodes multicast address; and the request may be sent with or without 613 a query component. These particular details of the request are 614 selected depending on the intented discovery action of the client and 615 on the particular encoding of group names in names and/or attributes 616 of resources which is application-specific. The following types of 617 request may typically be used: 619 * Discovery of all application groups that are part of a CoAP group. 620 For example, in case the application group name is encoded in the 621 URI path as "/grp/" then the discovery query may use 622 URI "/.well-known/core?href=/grp/*" and it is sent to the IP 623 multicast address of the CoAP group. The query matches any 624 application group name. The result of this query is a list of 625 resources at CoAP servers that are a member of at least one 626 application group associated to the CoAP group. Each resource 627 represents an application group membership at one CoAP server. 629 * Discovery of a particular application group with a known name. 630 For example, in case the known application group name is 631 "mygroup1" and is encoded in the URI path as "/grp/" 632 then the discovery query may use URI "/.well-known/core?href=/grp/ 633 mygroup1" and it is sent to the IPv6 All CoAP Nodes multicast 634 address of a particular chosen scope (e.g. site-local, or realm- 635 local). The result of this query is a list of resources at CoAP 636 servers that are a member of "mygroup1". Each resource represents 637 the membership of the responding server to the application group 638 "mygroup1". 640 * Discovery of all application groups of a particular type. For 641 example, in case the application group type is "mytype1" and is 642 encoded as a resource type (rt) attribute of the application group 643 resource, and the application group resource is "/grp/" 644 then the discovery query may use URI "/.well-known/ 645 core?rt=mytype1" and it is sent to the All CoAP Nodes multicast 646 address. The query result is a list of resources at CoAP servers 647 that have at least one application group of type "mytype1"; each 648 server response identifies the membership to one or more 649 application group(s) of type "mytype1" for that server. Each 650 resource in the list represents one membership of a server to one 651 application group of type "mytype1". 653 * Discovery of all application groups that are configured on the 654 client's 6LoWPAN wireless mesh network. In the following example 655 a request without query is used. So, the URI "/.well-known/core" 656 is used and the request is sent to the IPv6 All CoAP Nodes 657 multicast address of realm-local scope. Each CoAP server 658 (including any application group members) will return a list of 659 its resources, which in this example includes the resources used 660 to encode the application group name. If each application group 661 resource is known to be "/g/" then the client marks 662 each returned resource under the root resource "/g" as a 663 discovered application group. Not using a query has the 664 disadvantage that potentially a lot of response traffic will be 665 generated on the mesh network, including responses from servers 666 that are not a member of any application group. But it may be 667 needed in particular use cases, e.g. if some of the CoAP servers 668 do not support the optional link format query functionality (as 669 mentioned in Section 4.1 of [RFC6690]). 671 Note that all the above examples are application-specific; there is 672 currently no standard way of encoding application group names or CoAP 673 group names in CoAP resources and/or CoRE link attributes at the CoAP 674 server. (The aforementioned registration and discovery of groups in 675 the RD is only defined for use with an RD, not for discovery on CoAP 676 servers without using an RD.) 678 When secure communication is provided with Group OSCORE (see 679 Section 5), the approach described in 680 [I-D.tiloca-core-oscore-discovery] also based on the RD can be used, 681 in order to discover the security group to join. 683 In particular, the responsible OSCORE Group Manager registers its own 684 security groups to the RD, as links to its own corresponding 685 resources for joining the security groups 686 [I-D.ietf-ace-key-groupcomm-oscore]. Later on, CoAP endpoints can 687 discover the registered security groups and related application 688 groups, by using the lookup interface of the RD, and then join the 689 security group through the respective Group Manager. 691 2.2.4. Group Maintenance 693 Maintenance of a group includes any necessary operations to cope with 694 changes in a system, such as: adding group members, removing group 695 members, changing group security material, reconfiguration of UDP 696 port and/or IP multicast address, reconfiguration of the Group URI, 697 renaming of application groups, splitting of groups, or merging of 698 groups. 700 For unsecured group communication (see Section 4) i.e., the "NoSec" 701 security group, addition/removal of CoAP group members is simply done 702 by configuring these devices to start/stop listening to the group IP 703 multicast address on the group's UDP port. 705 For secured group communication (see Section 5), the maintenance 706 operations of the protocol Group OSCORE 707 [I-D.ietf-core-oscore-groupcomm] MUST be implemented. When using 708 Group OSCORE, CoAP endpoints participating in group communication are 709 also members of a corresponding OSCORE security group, and thus share 710 common security material. Additional related maintenance operations 711 are discussed in Section 5.2. 713 3. CoAP Usage in Group Communication 715 This section specifies the usage of CoAP in group communication, both 716 unsecured and secured. This includes additional support for protocol 717 extensions, such as Observe (see Section 3.7) and block-wise transfer 718 (see Section 3.8). 720 How CoAP group messages are carried over various transport layers is 721 the subject of Section 3.9. Finally, Section 3.10 covers the 722 interworking of CoAP group communication with other protocols that 723 may operate in the same network. 725 3.1. Request/Response Model 727 3.1.1. General 729 A CoAP client is an endpoint able to transmit CoAP requests and 730 receive CoAP responses. Since the underlying UDP transport supports 731 multiplexing by means of UDP port number, there can be multiple 732 independent CoAP clients operational on a single host. On each UDP 733 port, an independent CoAP client can be hosted. Each independent 734 CoAP client sends requests that use the associated endpoint's UDP 735 port number as the UDP source port of the request. 737 All CoAP requests that are sent via IP multicast MUST be Non- 738 confirmable; see Section 8.1 of [RFC7252]. The Message ID in an IP 739 multicast CoAP message is used for optional message deduplication by 740 both clients and servers, as detailed in Section 4.5 of [RFC7252]. A 741 server sends back a unicast response to a CoAP group request. The 742 unicast responses received by the CoAP client may be a mixture of 743 success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found) 744 codes, depending on the individual server processing results. 746 3.1.2. Response Suppression 748 A server MAY suppress its response for various reasons given in 749 Section 8.2 of [RFC7252]. This document adds the requirement that a 750 server SHOULD suppress the response in case of error or in case there 751 is nothing useful to respond, unless the application related to a 752 particular resource requires such a response to be made for that 753 resource. 755 The CoAP No-Response Option [RFC7967] can be used by a client to 756 influence the default response suppression on the server side. It is 757 RECOMMENDED for a server to support this option only on selected 758 resources where it is useful in the application context. If the 759 option is supported on a resource, it MUST override the default 760 response suppression of that resource. 762 Any default response suppression by a server SHOULD be performed 763 consistently, as follows: if a request on a resource produces a 764 particular Response Code and this response is not suppressed, then 765 another request on the same resource that produces a response of the 766 same Response Code class is also not suppressed. For example, if a 767 4.05 Method Not Allowed error response code is suppressed by default 768 on a resource, then a 4.15 Unsupported Content-Format error response 769 code is also suppressed by default for that resource. 771 3.1.3. Repeating a Request 773 A CoAP client MAY repeat a group request using the same Token value 774 and same Message ID value, in order to ensure that enough (or all) 775 group members have been reached with the request. This is useful in 776 case a number of group members did not respond to the initial request 777 and the client suspects that the request did not reach these group 778 members. However, in case one or more servers did receive the 779 initial request but the response to that request was lost, this 780 repeat does not help to retrieve the lost response(s) if the 781 server(s) implement the optional Message ID based deduplication 782 (Section 4.5 of [RFC7252]). 784 A CoAP client MAY repeat a group request using the same Token value 785 and a different Message ID, in which case all servers that received 786 the initial request will again process the repeated request since it 787 appears within a new CoAP message. This is useful in case a client 788 suspects that one or more response(s) to its original request were 789 lost and the client needs to collect more, or even all, responses 790 from group members, even if this comes at the cost of the overhead of 791 certain group members responding twice (once to the original request, 792 and once to the repeated request with different Message ID). 794 3.1.4. Request/Response Matching and Distinguishing Responses 796 A CoAP client can distinguish the origin of multiple server responses 797 by the source IP address of the message containing the CoAP response 798 and/or any other available application-specific source identifiers 799 contained in the CoAP response payload or CoAP response options, such 800 as an application-level unique ID associated to the server. If 801 secure communication is provided with Group OSCORE (see Section 5), 802 additional security-related identifiers in the CoAP response enable 803 the client to retrieve the right security material for decrypting 804 each response and authenticating its source. 806 While processing a response on the client, the source endpoint of the 807 response is not matched to the destination endpoint of the request, 808 since for a group request these will never match. This is specified 809 in Section 8.2 of [RFC7252], with reference to IP multicast. Also, 810 when UDP transport is used, this implies that a server MAY respond 811 from a UDP port number that differs from the destination UDP port 812 number of the request, although a CoAP server normally SHOULD respond 813 from the UDP port number that equals the destination port of the 814 request -- following the convention for UDP-based protocols. In case 815 a single client has sent multiple group requests and concurrent CoAP 816 transactions are ongoing, the responses received by that client are 817 matched to an active request using only the Token value. Due to UDP 818 level multiplexing, the UDP destination port of the response MUST 819 match to the client endpoint's UDP port value, i.e., to the UDP 820 source port of the client's request. 822 3.1.5. Token Reuse 824 For CoAP group requests, there are additional constraints on the 825 reuse of Token values at the client, compared to the unicast case 826 defined in [RFC7252] and updated by [I-D.ietf-core-echo-request-tag]. 827 Since for CoAP group requests the number of responses is not bound a 828 priori, the client cannot use the reception of a response as a 829 trigger to "free up" a Token value for reuse. Reusing a Token value 830 too early could lead to incorrect response/request matching on the 831 client, and would be a protocol error. Therefore, the time between 832 reuse of Token values for different group requests MUST be greater 833 than: 835 MIN_TOKEN_REUSE_TIME = (NON_LIFETIME + MAX_LATENCY + 836 MAX_SERVER_RESPONSE_DELAY) 838 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 839 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 840 was done in [RFC7390], that is: the expected maximum response delay 841 over all servers that the client can send a CoAP group request to. 843 This delay includes the maximum Leisure time period as defined in 844 Section 8.2 of [RFC7252]. However, CoAP does not define a time limit 845 for the server response delay. Using the default CoAP parameters, 846 the Token reuse time MUST be greater than 250 seconds plus 847 MAX_SERVER_RESPONSE_DELAY. A preferred solution to meet this 848 requirement is to generate a new unique Token for every new group 849 request, such that a Token value is never reused. If a client has to 850 reuse Token values for some reason, and also 851 MAX_SERVER_RESPONSE_DELAY is unknown, then using 852 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 853 The time between Token reuses is in that case set to a value greater 854 than MIN_TOKEN_REUSE_TIME = 500 seconds. 856 When securing CoAP group communication with Group OSCORE 857 [I-D.ietf-core-oscore-groupcomm], secure binding between requests and 858 responses is ensured (see Section 5). Thus, a client may reuse a 859 Token value after it has been freed up, as discussed above and 860 considering a reuse time greater than MIN_TOKEN_REUSE_TIME. If an 861 alternative security protocol for CoAP group communication is used 862 which does not ensure secure binding between requests and responses, 863 a client MUST follow the Token processing requirements as defined in 864 [I-D.ietf-core-echo-request-tag]. 866 Another method to more easily meet the above constraint is to 867 instantiate multiple CoAP clients at multiple UDP ports on the same 868 host. The Token values only have to be unique within the context of 869 a single CoAP client, so using multiple clients can make it easier to 870 meet the constraint. 872 3.1.6. Client Handling of Multiple Responses With Same Token 874 Since a client sending a group request with a Token T will accept 875 multiple responses with the same Token T, it is possible in 876 particular that the same server sends multiple responses with the 877 same Token T back to the client. For example, this server might not 878 implement the optional CoAP message deduplication based on Message 879 ID; or it might be acting out of specification as a malicious, 880 compromised or faulty server. 882 When this happens, the client normally processes at the CoAP layer 883 each of those responses to the same request coming from the same 884 server. If the processing of a response is successful, the client 885 delivers this response to the application as usual. 887 Then, the application is in a better position to decide what to do, 888 depending on the available context information. For instance, it 889 might accept and process all the responses from the same server, even 890 if they are not Observe notifications (i.e., they do not include an 891 Observe option). Alternatively, the application might accept and 892 process only one of those responses, such as the most recent one from 893 that server, e.g., when this can trigger a change of state within the 894 application. 896 3.2. Caching 898 CoAP endpoints that are members of a CoAP group MAY cache responses 899 to a group request as defined in Section 5.6 of [RFC7252]. In 900 particular, these same rules apply to determine the set of request 901 options used as "Cache-Key". 903 Furthermore, building on what is defined in Section 8.2.1 of 904 [RFC7252]: 906 * A client sending a GET or FETCH group request MAY update a cache 907 with the responses from the servers in the CoAP group. Then, the 908 client uses both cached-still-fresh and new responses as the 909 result of the group request. 911 * A client sending a GET or FETCH group request MAY use a response 912 received from a server, to satisfy a subsequent sent request 913 intended to that server on the related unicast request URI. In 914 particular, the unicast request URI is obtained by replacing the 915 authority part of the request URI with the transport-layer source 916 address of the cached response message. 918 * A client MAY revalidate a cached response by making a GET or FETCH 919 request on the related unicast request URI. 921 Note that, in the presence of proxies, doing any of the above 922 (optional) unicast requests requires the client to distinguish the 923 different responses to a group request, as well as to distinguish the 924 different origin servers that responded. This in turn requires 925 additional means to provide the client with information about the 926 origin server of each response, e.g., using the forward-proxying 927 method defines in [I-D.tiloca-core-groupcomm-proxy]. 929 The following subsections define the freshness model and validation 930 model to use for cached responses, which update the models defined in 931 Sections 5.6.1 and 5.6.2 of [RFC7252], respectively. 933 3.2.1. Freshness Model 935 For caching of group communication responses at client endpoints, the 936 same freshness model relying on the Max-Age Option as defined in 937 Section 5.6.1 of [RFC7252] applies, and the multicast caching rules 938 of Section 8.2.1 of [RFC7252] apply except for the one discussed 939 below. 941 In Section 8.2.1 of [RFC7252] it is stated that, regardless of the 942 presence of cached responses to the group request, the client 943 endpoint will always send out a new group request onto the network 944 because new group members may have joined the group since the last 945 group request to the same group/resource. That is, a request is 946 never served from cached responses only. This document updates 947 [RFC7252] by adding the following exception case, where a client 948 endpoint MAY serve a request by using cached responses only, and not 949 send out a new group request onto the network: 951 * The client knows all current CoAP server group members; and, for 952 each group member, the client's cache currently stores a fresh 953 response. 955 How the client in the case above determines the current CoAP server 956 group members is out of scope for this document. It may be, for 957 example, via a group manager server, or by observing group join 958 requests, or observing IGMP/MLD multicast group join messages, etc. 960 For caching at proxies, the freshness model defined in 961 [I-D.tiloca-core-groupcomm-proxy] can be used. 963 3.2.2. Validation Model 965 For validation of cached group communication responses at client 966 endpoints, the multicast validation rules in Section 8.2.1 of 967 [RFC7252] apply, except for the last paragraph which states "A GET 968 request to a multicast group MUST NOT contain an ETag option". This 969 document updates [RFC7252] by allowing a group request to contain 970 ETag Options as specified below. 972 For validation at proxies, the validation model defined in 973 [I-D.tiloca-core-groupcomm-proxy] can be used. 975 3.2.2.1. ETag Option in a Group Request/Response 977 A client endpoint MAY include one or more ETag Options in a GET or 978 FETCH group request to validate one or more stored responses it has 979 cached. In case two or more servers in the group have responded to a 980 previous request to the same resource with an identical ETag value, 981 it is the responsibility of the client to handle this case. In 982 particular, if the client wishes to validate, using a group request, 983 a response from server 1 with an ETag value N, while it does not wish 984 to validate a response from server 2 with the same ETag value N, 985 there is no way to achieve this. In such cases of identical ETag 986 values returned by two or more servers, the client, by default, 987 SHOULD NOT include an ETag Option in a group request containing that 988 ETag value. 990 A server endpoint MUST process an ETag Option in a GET or FETCH group 991 request in the same way it processes an ETag Option for a unicast 992 request. A server endpoint that includes an ETag Option in a 993 response to a group request SHOULD construct the ETag Option value in 994 such a way that the value will be unique to this particular server 995 with a high probability. This can be done, for example, by embedding 996 a compact ID of the server within the ETag value, where the ID is 997 unique (or unique with a high probability) in the scope of the group. 999 Note: a legacy CoAP server might treat an ETag Option in a group 1000 request as an unrecognized option per Sections 5.4 and 8.2.1 of 1001 [RFC7252], causing it to ignore this (elective) ETag Option 1002 regardless of its value, and process the request normally as if that 1003 ETag Option was not included. 1005 3.3. URI Path Selection 1007 The URI Path used in a group request is preferably a path that is 1008 known to be supported across all group members. However there are 1009 valid use cases where a group request is known to be successful only 1010 for a subset of the CoAP group, for example only members of a 1011 specific application group, while those group members for which the 1012 request is unsuccessful (for example because they are outside the 1013 application group) either ignore the group request or respond with an 1014 error status code. 1016 3.4. Port Selection for UDP Transport 1018 A server that is a member of a CoAP group listens for CoAP request 1019 messages on the group's IP multicast address, usually on the CoAP 1020 default UDP port 5683, or another non-default UDP port if configured. 1021 Regardless of the method for selecting the port number, the same port 1022 number MUST be used across all CoAP servers that are members of a 1023 CoAP group and across all CoAP clients sending group requests to that 1024 group. 1026 One way to create multiple CoAP groups is using different UDP ports 1027 with the same IP multicast address, in case the devices' network 1028 stack only supports a limited number of multicast address 1029 subscriptions. However, it must be taken into account that this 1030 incurs additional processing overhead on each CoAP server 1031 participating in at least one of these groups: messages to groups 1032 that are not of interest to the node are only discarded at the higher 1033 transport (UDP) layer instead of directly at the network (IP) layer. 1034 Also, a constrained network may be additionally burdened in this case 1035 with multicast traffic that is eventually discarded at the UDP layer 1036 by most nodes. 1038 Port 5684 is reserved for DTLS-secured unicast CoAP and MUST NOT be 1039 used for any CoAP group communication. 1041 For a CoAP server node that supports resource discovery as defined in 1042 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 1043 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 1044 group as detailed in Section 3.9. 1046 3.5. Proxy Operation 1048 This section defines how proxies operate in a group communication 1049 scenario. In particular, Section 3.5.1 defines operations of 1050 forward-proxies, while Section 3.5.2 defines operations of reverse- 1051 proxies. Security operations for a proxy are discussed later in 1052 Section 5.3. 1054 3.5.1. Forward-Proxies 1056 CoAP enables a client to request a forward-proxy to process a CoAP 1057 request on its behalf, as described in Sections 5.7.2 and 8.2.2 of 1058 [RFC7252]. For this purpose, the client specifies either the request 1059 group URI as a string in the Proxy-URI Option or it uses the Proxy- 1060 Scheme Option with the group URI constructed from the usual Uri-* 1061 Options. The forward-proxy then resolves the group URI to a 1062 destination CoAP group, sends (e.g., multicasts) the CoAP group 1063 request, receives the responses and forwards all the individual 1064 (unicast) responses back to the client. 1066 However, there are certain issues and limitations with this approach: 1068 * The CoAP client component that sent a unicast CoAP request to the 1069 proxy may be expecting only one (unicast) response, as usual for a 1070 CoAP unicast request. Instead, it receives multiple (unicast) 1071 responses, potentially leading to fault conditions in the 1072 component or to discarding any received responses following the 1073 first one. This issue may occur even if the application calling 1074 the CoAP client component is aware that the forward-proxy is going 1075 to execute a CoAP group URI request. 1077 * Each individual CoAP response received by the client will appear 1078 to originate (based on its IP source address) from the CoAP Proxy, 1079 and not from the server that produced the response. This makes it 1080 impossible for the client to identify the server that produced 1081 each response, unless the server identity is contained as a part 1082 of the response payload or inside a CoAP option in the response. 1084 * The proxy does not necessarily know how many members there are in 1085 the CoAP group or how many group members will actually respond. 1086 Also, the proxy does not know for how long to collect responses 1087 before it stops forwarding them to the client. A CoAP client that 1088 is not using a Proxy might face the same problems in collecting 1089 responses to a group request. However, the client itself would 1090 typically have application-specific rules or knowledge on how to 1091 handle this situation, while an application-agnostic CoAP Proxy 1092 would typically not have this knowledge. For example, a CoAP 1093 client could monitor incoming responses and use this information 1094 to decide how long to continue collecting responses - which is 1095 something a proxy cannot do. 1097 A forward-proxying method using this approach and addressing the 1098 issues raised above is defined in [I-D.tiloca-core-groupcomm-proxy]. 1100 An alternative solution is for the proxy to collect all the 1101 individual (unicast) responses to a CoAP group request and then send 1102 back only a single (aggregated) response to the client. However, 1103 this solution brings up new issues: 1105 * Like for the approach discussed above, the proxy does not know for 1106 how long to collect responses before sending back the aggregated 1107 response to the client. Analogous considerations apply to this 1108 approach too, both on the client and proxy side. 1110 * There is no default format defined in CoAP for aggregation of 1111 multiple responses into a single response. Such a format could be 1112 standardized based on, for example, the multipart content-format 1113 [RFC8710]. 1115 Due to the above issues, it is RECOMMENDED that a CoAP Proxy only 1116 processes a group URI request if it is explicitly enabled to do so. 1117 The default response (if the function is not explicitly enabled) to a 1118 group URI request is 5.01 Not Implemented. Furthermore, a proxy 1119 SHOULD be explicitly configured (e.g., by allow-listing and/or client 1120 authentication) to allow proxied CoAP group requests only from 1121 specific client(s). 1123 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 1124 specified in Sections 8.4 and 10.1 of [RFC8075]. In this case, the 1125 "application/http" media type is used to let the proxy return 1126 multiple CoAP responses -- each translated to a HTTP response -- back 1127 to the HTTP client. Of course, in this case the HTTP client sending 1128 a group URI to the proxy needs to be aware that it is going to 1129 receive this format, and needs to be able to decode it into the 1130 responses of multiple CoAP servers. Also, the IP source address of 1131 each CoAP response cannot be determined anymore from the 1132 "application/http" response. The HTTP client still identify the CoAP 1133 servers by other means such as application-specific information in 1134 the response payload. 1136 3.5.2. Reverse-Proxies 1138 CoAP enables the use of a reverse-proxy, as an endpoint that stands 1139 in for one or more other server(s), and satisfies requests on behalf 1140 of these, doing any necessary translations (see Section 5.7.3 of 1141 [RFC7252]). 1143 In a group communication scenario, a reverse-proxy can rely on its 1144 configuration and/or on information in a request from a client, in 1145 order to determine that a group request has to be sent to a group of 1146 servers over a one-to-many transport such as IP/UDP multicast. 1148 For example, specific resources on the reverse-proxy could be 1149 allocated, each to a specific application group and/or CoAP group. 1150 Or alternatively, the application group and/or CoAP group in question 1151 could be encoded as URI path segments. The URI path encodings for a 1152 reverse-proxy may also use a URI mapping template as described in 1153 Section 5.4 of [RFC8075]. 1155 Furthermore, the reverse-proxy can actually stand in for (and thus 1156 prevent to directly reach) only the whole set of servers in the 1157 group, or also for each of those individual servers (e.g., if acting 1158 as firewall). 1160 For a reverse-proxy that sends a request to a group of servers, the 1161 considerations as defined in Section 5.7.3 of [RFC7252] hold, with 1162 the following additions: 1164 * The three issues and limitations defined in Section 3.5.1 for a 1165 forward proxy apply to a reverse-proxy as well, and have to be 1166 addressed, e.g., using the signaling method defined in 1167 [I-D.tiloca-core-groupcomm-proxy] or other means. 1169 * A reverse-proxy MAY have preconfigured time duration(s) that are 1170 used for the collecting of server responses and forwarding these 1171 back to the client. These duration(s) may be set as global 1172 configuration or resource-specific configurations. If there is 1173 such preconfiguration, then an explicit signaling of the time 1174 period in the client's request as defined in 1175 [I-D.tiloca-core-groupcomm-proxy] is not necessarily needed. 1177 * A client that is configured to access a reverse-proxy resource 1178 (i.e., one that triggers a CoAP group communication request) 1179 SHOULD be configured also to handle potentially multiple responses 1180 with the same Token value caused by a single request. 1182 That is, the client needs to preserve the Token value used for the 1183 request also after the reception of the first response forwarded 1184 back by the proxy (see Section 3.1.6) and keep the request open to 1185 potential further responses with this Token. This requirement can 1186 be met by a combination of client implementation and proper 1187 proxied group communication configuration on the client. 1189 * A client might re-use a Token value in a valid new request to the 1190 reverse-proxy, while the reverse-proxy still has an ongoing group 1191 communication request for this client with the same Token value 1192 (i.e., its time period for response collection has not ended yet). 1194 If this happens, the reverse-proxy MUST stop the ongoing request 1195 and associated response forwarding, it MUST NOT forward the new 1196 request to the group of servers, and it MUST send a 4.00 Bad 1197 Request error response to the client. The diagnostic payload of 1198 the error response SHOULD indicate to the client that the resource 1199 is a reverse-proxy resource, and that for this reason immediate 1200 Token re-use is not possible. 1202 If the reverse-proxy supports the signalling protocol of 1203 [I-D.tiloca-core-groupcomm-proxy] it can include a Multicast- 1204 Signaling Option in the error response to convey the reason for 1205 the error in a machine-readable way. 1207 For the operation of HTTP-to-CoAP reverse proxies, see the last 1208 paragraph of Section 3.5.1 which applies also to the case of reverse- 1209 proxies. 1211 3.6. Congestion Control 1213 CoAP group requests may result in a multitude of responses from 1214 different nodes, potentially causing congestion. Therefore, both the 1215 sending of CoAP group requests and the sending of the unicast CoAP 1216 responses to these group requests should be conservatively 1217 controlled. 1219 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 1220 the following measures: 1222 * A server may choose not to respond to an IP multicast request if 1223 there is nothing useful to respond to, e.g., error or empty 1224 response (see Section 8.2 of [RFC7252]). 1226 * A server should limit the support for IP multicast requests to 1227 specific resources where multicast operation is required 1228 (Section 11.3 of [RFC7252]). 1230 * An IP multicast request MUST be Non-confirmable (Section 8.1 of 1231 [RFC7252]). 1233 * A response to an IP multicast request SHOULD be Non-confirmable 1234 (Section 5.2.3 of [RFC7252]). 1236 * A server does not respond immediately to an IP multicast request 1237 and should first wait for a time that is randomly picked within a 1238 predetermined time interval called the Leisure (Section 8.2 of 1239 [RFC7252]). 1241 This document also defines these measures to be applicable to 1242 alternative transports (other than IP multicast), if not defined 1243 otherwise. Additional guidelines to reduce congestion risks defined 1244 in this document are as follows: 1246 * A server in a constrained network SHOULD only support group 1247 requests for resources that have a small representation (where the 1248 representation may be retrieved via a GET, FETCH or POST method in 1249 the request). For example, "small" can be defined as a response 1250 payload limited to approximately 5% of the IP Maximum Transmit 1251 Unit (MTU) size, so that it fits into a single link-layer frame in 1252 case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, 1253 see Section 3.9.3) is used on the constrained network. 1255 * A server SHOULD minimize the payload size of a response to a group 1256 GET or FETCH request on "/.well-known/core" by using hierarchy in 1257 arranging link descriptions for the response. An example of this 1258 is given in Section 5 of [RFC6690]. 1260 * A server MAY minimize the payload size of a response to a group 1261 GET or FETCH request (e.g., on "/.well-known/core") by using CoAP 1262 block-wise transfers [RFC7959] in case the payload is long, 1263 returning only a first block of the CoRE Link Format description. 1264 For this reason, a CoAP client sending a CoAP group request to 1265 "/.well-known/core" SHOULD support block-wise transfers. See also 1266 Section 3.8. 1268 * A client SHOULD be configured to use CoAP groups with the smallest 1269 possible IP multicast scope that fulfills the application needs. 1270 As an example, site-local scope is always preferred over global 1271 scope IP multicast if this fulfills the application needs. 1272 Similarly, realm-local scope is always preferred over site-local 1273 scope if this fulfills the application needs. 1275 3.7. Observing Resources 1277 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 1278 that allows a CoAP client to retrieve a representation of a resource 1279 and automatically keep this representation up-to-date over a longer 1280 period of time. The client gets notified when the representation has 1281 changed. [RFC7641] does not mention whether the Observe Option can 1282 be combined with CoAP (multicast) group communication. 1284 This section updates [RFC7641] with the use of the Observe Option in 1285 a CoAP GET group request, and defines normative behavior for both 1286 client and server. Consistent with Section 2.4 of [RFC8132], it is 1287 also possible to use the Observe Option in a CoAP FETCH group 1288 request. 1290 Multicast Observe is a useful way to start observing a particular 1291 resource on all members of a CoAP group at the same time. Group 1292 members that do not have this particular resource or do not allow the 1293 GET or FETCH method on it will either respond with an error status -- 1294 4.04 Not Found or 4.05 Method Not Allowed, respectively -- or will 1295 silently suppress the response following the rules of Section 3.1.2, 1296 depending on server-specific configuration. 1298 A client that sends a group GET or FETCH request with the Observe 1299 Option MAY repeat this request using the same Token value and the 1300 same Observe Option value, in order to ensure that enough (or all) 1301 members of the CoAP group have been reached with the request. This 1302 is useful in case a number of group members did not respond to the 1303 initial request. The client MAY additionally use the same Message ID 1304 in the repeated request to avoid that group members that had already 1305 received the initial request would respond again. Note that using 1306 the same Message ID in a repeated request will not be helpful in case 1307 of loss of a response message, since the server that responded 1308 already will consider the repeated request as a duplicate message. 1309 On the other hand, if the client uses a different, fresh Message ID 1310 in the repeated request, then all the group members that receive this 1311 new message will typically respond again, which increases the network 1312 load. 1314 A client that has sent a group GET or FETCH request with the Observe 1315 Option MAY follow up by sending a new unicast CON request with the 1316 same Token value and same Observe Option value to a particular 1317 server, in order to ensure that the particular server receives the 1318 request. This is useful in case a specific group member, that was 1319 expected to respond to the initial group request, did not respond to 1320 the initial request. In this case, the client MUST use a Message ID 1321 that differs from the initial group request message. 1323 Furthermore, consistent with Section 3.3.1 of [RFC7641] and following 1324 its guidelines, a client MAY at any time send a new group/multicast 1325 GET or FETCH request with the same Token value and same Observe 1326 Option value as the original request. This allows the client to 1327 verify that it has an up-to-date representation of an observed 1328 resource and/or to re-register its interest to observe a resource. 1330 In the above client behaviors, the Token value is kept identical to 1331 the initial request to avoid that a client is included in more than 1332 one entry in the list of observers (Section 4.1 of [RFC7641]). 1334 Before repeating a request as specified above, the client SHOULD wait 1335 for at least the expected round-trip time plus the Leisure time 1336 period defined in Section 8.2 of [RFC7252], to give the server time 1337 to respond. 1339 A server that receives a GET or FETCH request with the Observe 1340 Option, for which request processing is successful, SHOULD respond to 1341 this request and not suppress the response. If a server adds a 1342 client (as a new entry) to the list of observers for a resource due 1343 to an Observe request, the server SHOULD respond to this request and 1344 SHOULD NOT suppress the response. An exception to the above is the 1345 overriding of response suppression according to a CoAP No-Response 1346 Option [RFC7967] specified by the client in the GET or FETCH request 1347 (see Section 3.1.2). 1349 A server SHOULD have a mechanism to verify liveness of its observing 1350 clients and the continued interest of these clients in receiving the 1351 observe notifications. This can be implemented by sending 1352 notifications occasionally using a Confirmable message (see 1353 Section 4.5 of [RFC7641] for details). This requirement overrides 1354 the regular behavior of sending Non-confirmable notifications in 1355 response to a Non-confirmable request. 1357 A client can use the unicast cancellation methods of Section 3.6 of 1358 [RFC7641] and stop the ongoing observation of a particular resource 1359 on members of a CoAP group. This can be used to remove specific 1360 observed servers, or even all servers in the group (using serial 1361 unicast to each known group member). In addition, a client MAY 1362 explicitly deregister from all those servers at once, by sending a 1363 group/multicast GET or FETCH request that includes the Token value of 1364 the observation to be cancelled and includes an Observe Option with 1365 the value set to 1 (deregister). In case not all the servers in the 1366 CoAP group received this deregistration request, either the unicast 1367 cancellation methods can be used at a later point in time or the 1368 group/multicast deregistration request MAY be repeated upon receiving 1369 another observe response from a server. 1371 For observing a group of servers through a CoAP-to-CoAP proxy, the 1372 limitations stated in Section 3.5 apply. The method defined in 1373 [I-D.tiloca-core-groupcomm-proxy] enables group communication 1374 including resource observation through proxies and addresses those 1375 limitations. 1377 3.8. Block-Wise Transfer 1379 Section 2.8 of [RFC7959] specifies how a client can use block-wise 1380 transfer (Block2 Option) in a multicast GET request to limit the size 1381 of the initial response of each server. Consistent with Section 2.5 1382 of [RFC8132], the same can be done with a multicast FETCH request. 1384 The client has to use unicast for any further request, separately 1385 addressing each different server, in order to retrieve more blocks of 1386 the resource from that server, if any. Also, a server (member of a 1387 targeted CoAP group) that needs to respond to a group request with a 1388 particularly large resource can use block-wise transfer (Block2 1389 Option) at its own initiative, to limit the size of the initial 1390 response. Again, a client would have to use unicast for any further 1391 requests to retrieve more blocks of the resource. 1393 A solution for group/multicast block-wise transfer using the Block1 1394 Option is not specified in [RFC7959] nor in the present document. 1395 Such a solution would be useful for group FETCH/PUT/POST/PATCH/iPATCH 1396 requests, to efficiently distribute a large request payload as 1397 multiple blocks to all members of a CoAP group. Multicast usage of 1398 Block1 is non-trivial due to potential message loss (leading to 1399 missing blocks or missing confirmations), and potential diverging 1400 block size preferences of different members of the CoAP group. 1402 [I-D.ietf-core-new-block] specifies an alternative method for CoAP 1403 block-wise transfer. It specifies that "servers MUST ignore 1404 multicast requests that contain the Q-Block2 Option". 1406 3.9. Transport Protocols 1408 In this document UDP, both over IPv4 and IPv6, is considered as the 1409 default transport protocol for CoAP group communication. 1411 3.9.1. UDP/IPv6 Multicast Transport 1413 CoAP group communication can use UDP over IPv6 as a transport 1414 protocol, provided that IPv6 multicast is enabled. IPv6 multicast 1415 MAY be supported in a network only for a limited scope. For example, 1416 Section 3.10.2 describes the potential limited support of RPL for 1417 multicast, depending on how the protocol is configured. 1419 For a CoAP server node that supports resource discovery as defined in 1420 Section 2.4 of [RFC7252], the default port 5683 MUST be supported as 1421 per Sections 7.1 and 12.8 of [RFC7252] for the "All CoAP Nodes" 1422 multicast group. An IPv6 CoAP server SHOULD support the "All CoAP 1423 Nodes" groups with at least link-local (2), admin-local (4) and site- 1424 local (5) scopes. An IPv6 CoAP server on a 6LoWPAN node (see 1425 Section 3.9.3) SHOULD also support the realm-local (3) scope. 1427 Note that a client sending an IPv6 multicast CoAP message to a port 1428 that is not supported by the server will not receive an ICMPv6 Port 1429 Unreachable error message from that server, because the server does 1430 not send it in this case, per Section 2.4 of [RFC4443]. 1432 3.9.2. UDP/IPv4 Multicast Transport 1434 CoAP group communication can use UDP over IPv4 as a transport 1435 protocol, provided that IPv4 multicast is enabled. For a CoAP server 1436 node that supports resource discovery as defined in Section 2.4 of 1437 [RFC7252], the default port 5683 MUST be supported as per Sections 1438 7.1 and 12.8 of [RFC7252], for the "All CoAP Nodes" IPv4 multicast 1439 group. 1441 Note that a client sending an IPv4 multicast CoAP message to a port 1442 that is not supported by the server will not receive an ICMP Port 1443 Unreachable error message from that server, because the server does 1444 not send it in this case, per Section 3.2.2 of [RFC1122]. 1446 3.9.3. 6LoWPAN 1448 In 6LoWPAN [RFC4944] [RFC6282] networks, IPv6 packets (up to 1280 1449 bytes) may be fragmented into smaller IEEE 802.15.4 MAC frames (up to 1450 127 bytes), if the packet size requires this. Every 6LoWPAN IPv6 1451 router that receives a multi-fragment packet reassembles the packet 1452 and refragments it upon transmission. Since the loss of a single 1453 fragment implies the loss of the entire IPv6 packet, the performance 1454 in terms of packet loss and throughput of multi-fragment multicast 1455 IPv6 packets is typically far worse than the performance of single- 1456 fragment IPv6 multicast packets. For this reason, a CoAP request 1457 sent over multicast in 6LoWPAN networks SHOULD be sized in such a way 1458 that it fits in a single IEEE 802.15.4 MAC frame, if possible. 1460 On 6LoWPAN networks, multicast groups can be defined with realm-local 1461 scope [RFC7346]. Such a realm-local group is restricted to the local 1462 6LoWPAN network/subnet. In other words, a multicast request to that 1463 group does not propagate beyond the 6LoWPAN network segment where the 1464 request originated. For example, a multicast discovery request can 1465 be sent to the realm-local "All CoAP Nodes" IPv6 multicast group (see 1466 Section 3.9.1) in order to discover only CoAP servers on the local 1467 6LoWPAN network. 1469 3.9.4. Other Transports 1471 CoAP group communication may be used over transports other than UDP/ 1472 IP multicast. For example broadcast, non-UDP multicast, geocast, 1473 serial unicast, etc. In such cases the particular considerations for 1474 UDP/IP multicast in this document may need to be applied to that 1475 particular transport. 1477 Because it supports unicast only, [RFC8323] (CoAP over TCP, TLS, and 1478 WebSockets) is not in scope as a transport for CoAP group 1479 communication. 1481 3.10. Interworking with Other Protocols 1483 3.10.1. MLD/MLDv2/IGMP/IGMPv3 1485 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1486 unaware of the specific IP multicast routing/forwarding protocol 1487 being used in their network. When such a host needs to join a 1488 specific (CoAP) multicast group, it requires a way to signal to IP 1489 multicast routers which IP multicast address(es) it needs to listen 1490 to. 1492 The MLDv2 protocol [RFC3810] is the standard IPv6 method to achieve 1493 this; therefore, this method SHOULD be used by members of a CoAP 1494 group to subscribe to its multicast IPv6 address, on IPv6 networks 1495 that support it. CoAP server nodes then act in the role of MLD 1496 Multicast Address Listener. MLDv2 uses link-local communication 1497 between Listeners and IP multicast routers. Constrained IPv6 1498 networks that implement either RPL (see Section 3.10.2) or MPL (see 1499 Section 3.10.3) typically do not support MLDv2 as they have their own 1500 mechanisms defined for subscribing to multicast groups. 1502 The IGMPv3 protocol [RFC3376] is the standard IPv4 method to signal 1503 multicast group subscriptions. This SHOULD be used by members of a 1504 CoAP group to subscribe to its multicast IPv4 address on IPv4 1505 networks. 1507 The guidelines from [RFC6636] on the tuning of MLD for mobile and 1508 wireless networks may be useful when implementing MLD in constrained 1509 networks. 1511 3.10.2. RPL 1513 RPL [RFC6550] is an IPv6 based routing protocol suitable for low- 1514 power, lossy networks (LLNs). In such a context, CoAP is often used 1515 as an application protocol. 1517 If only RPL is used in a network for routing and its optional 1518 multicast support is disabled, there will be no IP multicast routing 1519 available. Any IPv6 multicast packets in this case will not 1520 propagate beyond a single hop (to direct neighbors in the LLN). This 1521 implies that any CoAP group request will be delivered to link-local 1522 nodes only, for any scope value >= 2 used in the IPv6 destination 1523 address. 1525 RPL supports (see Section 12 of [RFC6550]) advertisement of IP 1526 multicast destinations using Destination Advertisement Object (DAO) 1527 messages and subsequent routing of multicast IPv6 packets based on 1528 this. It requires the RPL mode of operation to be 3 (Storing mode 1529 with multicast support). 1531 In this mode, RPL DAO can be used by a CoAP node that is either an 1532 RPL router or RPL Leaf Node, to advertise its CoAP group membership 1533 to parent RPL routers. Then, RPL will route any IP multicast CoAP 1534 requests over multiple hops to those CoAP servers that are group 1535 members. 1537 The same DAO mechanism can be used to convey CoAP group membership 1538 information to an edge router (e.g., 6LBR), in case the edge router 1539 is also the root of the RPL Destination-Oriented Directed Acyclic 1540 Graph (DODAG). This is useful because the edge router then learns 1541 which IP multicast traffic it needs to pass through from the backbone 1542 network into the LLN subnet, and which traffic not. In LLNs, such 1543 ingress filtering helps to avoid congestion of the resource- 1544 constrained network segment, due to IP multicast traffic from the 1545 high-speed backbone IP network. 1547 3.10.3. MPL 1549 The Multicast Protocol for Low-Power and Lossy Networks (MPL) 1550 [RFC7731] can be used for propagation of IPv6 multicast packets 1551 throughout a defined network domain, over multiple hops. MPL is 1552 designed to work in LLNs and can operate alone or in combination with 1553 RPL. The protocol involves a predefined group of MPL Forwarders to 1554 collectively distribute IPv6 multicast packets throughout their MPL 1555 Domain. An MPL Forwarder may be associated to multiple MPL Domains 1556 at the same time. Non-Forwarders will receive IPv6 multicast packets 1557 from one or more of their neighboring Forwarders. Therefore, MPL can 1558 be used to propagate a CoAP multicast group request to all group 1559 members. 1561 However, a CoAP multicast request to a group that originated outside 1562 of the MPL Domain will not be propagated by MPL - unless an MPL 1563 Forwarder is explicitly configured as an ingress point that 1564 introduces external multicast packets into the MPL Domain. Such an 1565 ingress point could be located on an edge router (e.g., 6LBR). 1566 Methods to configure which multicast groups are to be propagated into 1567 the MPL Domain could be: 1569 * Manual configuration on each ingress MPL Forwarder. 1571 * MLDv2 protocol, which works only in case all CoAP servers joining 1572 a group are in link-local communication range of an ingress MPL 1573 Forwarder. This is typically not the case on mesh networks. 1575 * A new/custom protocol to register multicast groups at an ingress 1576 MPL Forwarder. This could be for example a CoAP-based protocol 1577 offering multicast group subscription features similar to MLDv2. 1579 For security and performance reasons also other filtering criteria 1580 may be defined at an ingress MPL Forwarder. See Section 6.6 for more 1581 details. 1583 4. Unsecured Group Communication 1585 CoAP group communication can operate in CoAP NoSec (No Security) 1586 mode, without using application-layer and transport-layer security 1587 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 1588 Section 9 of [RFC7252]. The conceptual "NoSec" security group as 1589 defined in Section 2.1 is used for unsecured group communication. 1591 It is NOT RECOMMENDED to use CoAP group communication in NoSec mode, 1592 even in case of non-sensitive and non-critical applications. 1594 Before possibly and exceptionally using the NoSec mode, the security 1595 implications in Section 6.1 must be very well considered and 1596 understood, especially as to the risk and impact of amplification 1597 attacks (see Section 6.3). 1599 5. Secured Group Communication using Group OSCORE 1601 This section defines how CoAP group communication can be secured. In 1602 particular, Section 5.1 describes how the Group OSCORE security 1603 protocol [I-D.ietf-core-oscore-groupcomm] can be used to protect 1604 messages exchanged in a CoAP group, while Section 5.2 provides 1605 guidance on required maintenance operations for OSCORE groups used as 1606 security groups. 1608 5.1. Group OSCORE 1610 The application-layer protocol Object Security for Constrained 1611 RESTful Environments (OSCORE) [RFC8613] provides end-to-end 1612 encryption, integrity and replay protection of CoAP messages 1613 exchanged between two CoAP endpoints. These can act both as CoAP 1614 Client as well as CoAP Server, and share an OSCORE Security Context 1615 used to protect and verify exchanged messages. The use of OSCORE 1616 does not affect the URI scheme and OSCORE can therefore be used with 1617 any URI scheme defined for CoAP. 1619 OSCORE uses COSE [I-D.ietf-cose-rfc8152bis-struct] 1620 [I-D.ietf-cose-rfc8152bis-algs] to perform encryption operations and 1621 protect a CoAP message carried in a COSE object, by using an 1622 Authenticated Encryption with Associated Data (AEAD) algorithm. In 1623 particular, OSCORE takes as input an unprotected CoAP message and 1624 transforms it into a protected CoAP message transporting the COSE 1625 object. 1627 OSCORE makes it possible to selectively protect different parts of a 1628 CoAP message in different ways, while still allowing intermediaries 1629 (e.g., CoAP proxies) to perform their intended funtionalities. That 1630 is, some message parts are encrypted and integrity protected; other 1631 parts are only integrity protected to be accessible to, but not 1632 modifiable by, proxies; and some parts are kept as plain content to 1633 be both accessible to and modifiable by proxies. Such differences 1634 especially concern the CoAP options included in the unprotected 1635 message. 1637 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 1638 provides end-to-end security of CoAP messages exchanged between 1639 members of an OSCORE group, while fulfilling the same security 1640 requirements. 1642 In particular, Group OSCORE protects CoAP group requests sent by a 1643 CoAP client, e.g., over UDP/IP multicast, as well as multiple 1644 corresponding CoAP responses sent as (IP) unicast by different CoAP 1645 servers. However, the same security material can also be used to 1646 protect CoAP requests sent over (IP) unicast to a single CoAP server 1647 in the OSCORE group, as well as the corresponding responses. 1649 Group OSCORE ensures source authentication of all messages exchanged 1650 within the OSCORE group, by means of two possible methods. 1652 The first method, called group mode, relies on digital signatures. 1653 That is, sender devices sign their outgoing messages using their own 1654 private key, and embed the signature in the protected CoAP message. 1656 The second method, called pairwise mode, relies on a symmetric key, 1657 which is derived from a pairwise shared secret computed from the 1658 asymmetric keys of the message sender and recipient. This method is 1659 intended for one-to-one messages sent in the group, such as all 1660 responses individually sent by servers, as well as requests addressed 1661 to an individual server. 1663 A Group Manager is responsible for managing one or multiple OSCORE 1664 groups. In particular, the Group Manager acts as repository of 1665 public keys of group members; manages, renews and provides security 1666 material in the group; and handles the join process of new group 1667 members. 1669 As defined in [I-D.ietf-ace-oscore-gm-admin], an administrator entity 1670 can interact with the Group Manager to create OSCORE groups and 1671 specify their configuration (see Section 2.2.2). During the lifetime 1672 of the OSCORE group, the administrator can further interact with the 1673 Group Manager, in order to possibly update the group configuration 1674 and eventually delete the group. 1676 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 1677 can join an OSCORE group by using the method described in 1678 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 1679 for Authentication and Authorization in constrained environments 1680 [I-D.ietf-ace-oauth-authz]. 1682 A CoAP endpoint can discover OSCORE groups and retrieve information 1683 to join them through their respective Group Managers by using the 1684 method described in [I-D.tiloca-core-oscore-discovery] and based on 1685 the CoRE Resource Directory [I-D.ietf-core-resource-directory]. 1687 If security is required, CoAP group communication as described in 1688 this specification MUST use Group OSCORE. In particular, a CoAP 1689 group as defined in Section 2.1 and using secure group communication 1690 is associated to an OSCORE security group, which includes: 1692 * All members of the CoAP group, i.e., the CoAP endpoints configured 1693 to receive CoAP group messages sent to the particular group and -- 1694 in case of IP multicast transport -- are listening to the group's 1695 multicast IP address on the group's UDP port. 1697 * All further CoAP endpoints configured only as CoAP clients, that 1698 may send CoAP group requests to the CoAP group. 1700 5.2. Secure Group Maintenance 1702 As part of group maintenance operations (see Section 2.2.4), 1703 additional key management operations are required for an OSCORE 1704 group, also depending on the security requirements of the application 1705 (see Section 6.2.1). Specifically: 1707 * Adding new members to a CoAP group or enabling new client-only 1708 endpoints to interact with that group require also that each of 1709 such members/endpoints join the corresponding OSCORE group. When 1710 this happens, they are securely provided with the security 1711 material to use in that OSCORE group. 1713 Applications may need backward security. That is, they may 1714 require that, after having joined an OSCORE group, a new group 1715 member cannot access messages exchanged in the group prior to its 1716 joining, even if it has recorded them. 1718 In such a case, new security material to use in the OSCORE group 1719 has first to be generated and distributed to the current members 1720 of that group, before new endpoints are also provided with that 1721 new security material upon their joining. 1723 * Removing members from a CoAP group or stopping client-only 1724 endpoints from interacting with that group requires removing such 1725 members/endpoints from the corresponding OSCORE group. To this 1726 end, new security material is generated and securely distributed 1727 only to the remaining members of the OSCORE group, together with 1728 the list of former members removed from that group. 1730 This ensures forward security in the OSCORE group. That is, it 1731 ensures that only the members intended to remain in the OSCORE 1732 group are able to continue participating in the secure 1733 communications within that group, while the evicted ones are not 1734 able to after the distribution and installation of the new 1735 security material. 1737 Also, this ensures that the members intended to remain in the 1738 OSCORE group are able to confidently assert the group membership 1739 of other sender nodes, when receiving protected messages in the 1740 OSCORE group after the distribution and installation of the new 1741 security material (see Section 3.2 of 1742 [I-D.ietf-core-oscore-groupcomm]). 1744 The key management operations mentioned above are entrusted to the 1745 Group Manager responsible for the OSCORE group 1746 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 1747 them as defined in [I-D.ietf-ace-key-groupcomm-oscore]. 1749 5.3. Proxy Security 1751 Different solutions may be selected for secure group communication 1752 via a proxy depending on proxy type, use case and deployment 1753 requirements. In this section the options based on Group OSCORE are 1754 listed. 1756 For a client performing a group communication request via a forward- 1757 proxy, end-to-end security should be implemented. The client then 1758 creates a group request protected with Group OSCORE and unicasts this 1759 to the proxy. The proxy adapts the request from a forward-proxy 1760 request to a regular request and multicasts this adapted request to 1761 the indicated CoAP group. During the adaptation, the security 1762 provided by Group OSCORE persists, in either case of using the group 1763 mode or using the pairwise mode. The first leg of communication from 1764 client to proxy can optionally be further protected, e.g., by using 1765 (D)TLS and/or OSCORE. 1767 For a client performing a group communication request via a reverse- 1768 proxy, either end-to-end-security or hop-by-hop security can be 1769 implemented. The case of end-to-end security is the same as for the 1770 forward-proxy case. 1772 The case of hop-by-hop security is only possible if the proxy can be 1773 completely trusted and it is configured as a member of the OSCORE 1774 security group(s) that it needs to access, on behalf of clients. The 1775 first leg of communication between client and proxy is then protected 1776 with a security method for CoAP unicast, such as (D)TLS, OSCORE or a 1777 combination of such methods. The second leg between proxy and 1778 servers is protected using Group OSCORE. This can be useful in 1779 applications where for example the origin client does not implement 1780 Group OSCORE, or the group management operations are confined to a 1781 particular network domain and the client is outside this domain. 1783 For all the above cases, more details on using Group OSCORE are 1784 defined in [I-D.tiloca-core-groupcomm-proxy]. 1786 6. Security Considerations 1788 This section provides security considerations for CoAP group 1789 communication, in general and for the particular transport of IP 1790 multicast. 1792 6.1. CoAP NoSec Mode 1794 CoAP group communication, if not protected, is vulnerable to all the 1795 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 1796 Moreover, if the NoSec mode is used, amplification attacks are 1797 especially feasible to perform and greatly effective in their impact 1798 [I-D.mattsson-core-coap-attacks]. 1800 Therefore, even in case of non-sensitive and non-critical 1801 applications, it is generally NOT RECOMMENDED to use CoAP group 1802 communication in NoSec mode, also in order to prevent an easy 1803 proliferation of high-volume amplification attacks as further 1804 discussed in Section 6.3. 1806 Exceptionally, early discovery of devices and resources is a typical 1807 use case where NoSec mode is applied. In such a situation, the 1808 querying devices do not have yet configured any mutual security 1809 relations at the time they perform the discovery. Also, high-volume 1810 and harmful amplifications can be prevented through appropriate and 1811 conservative configurations, since only a few CoAP servers are 1812 expected to be configured for responding to the group requests sent 1813 for discovery (see Section 6.3). 1815 CoAP group communication in NoSec mode SHOULD NOT be deployed for 1816 sensitive and mission-critical applications (e.g., health monitoring 1817 systems and alarm monitoring systems). 1819 CoAP group communication without application-layer security SHOULD be 1820 deployed only in applications that are non-critical and that do not 1821 involve or may have an impact on sensitive data and personal sphere. 1822 These include, e.g., read-only temperature sensors deployed in non- 1823 sensitive environments, where the client reads out the values but 1824 does not use the data to control actuators or to base an important 1825 decision on. 1827 6.2. Group OSCORE 1829 Group OSCORE provides end-to-end application-level security. This 1830 has many desirable properties, including maintaining security 1831 assurances while forwarding traffic through intermediaries (proxies). 1832 Application-level security also tends to more cleanly separate 1833 security from the dynamics of group membership (e.g., the problem of 1834 distributing security keys across large groups with many members that 1835 come and go). 1837 For sensitive and mission-critical applications, CoAP group 1838 communication MUST be protected by using Group OSCORE as specified in 1839 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 1840 from Section 11 of [I-D.ietf-core-oscore-groupcomm] hold for this 1841 specification. 1843 6.2.1. Group Key Management 1845 A key management scheme for secure revocation and renewal of group 1846 security material, namely group rekeying, is required to be adopted 1847 in OSCORE groups. The key management scheme has to preserve forward 1848 security in the OSCORE group, as well as backward security if this is 1849 required by the application (see Section 5.2). In particular, the 1850 key management scheme MUST comply with the functional steps defined 1851 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 1853 Group policies should also take into account the time that the key 1854 management scheme requires to rekey the group, on one hand, and the 1855 expected frequency of group membership changes, i.e., nodes' joining 1856 and leaving, on the other hand. 1858 That is, it may be desirable to not rekey the group upon every single 1859 membership change, in case members' joining and leaving are frequent, 1860 and at the same time a single group rekeying instance takes a non- 1861 negligible time to complete. 1863 In such a case, the Group Manager may cautiously consider to rekey 1864 the group, e.g., after a minimum number of nodes has joined or left 1865 the group within a pre-defined time interval, or according to 1866 communication patterns with predictable time intervals of network 1867 inactivity. This would prevent paralyzing communications in the 1868 group, when a slow rekeying scheme is used and frequently invoked. 1870 At the same, the security implications of delaying the rekeying 1871 process have to be carefully considered and understood, before 1872 enforcing such group policies. 1874 In fact, this comes at the cost of not continuously preserving 1875 backward and forward security, since group rekeying might not occur 1876 upon every single group membership change. That is, most recently 1877 joined nodes would have access to the security material used prior to 1878 their joining, and thus be able to access past group communications 1879 protected with that security material. Similarly, until the group is 1880 rekeyed, most recently left nodes would preserve access to group 1881 communications protected with the retained security material. 1883 6.2.2. Source Authentication 1885 Both the group mode and the pairwise mode of Group OSCORE ensure 1886 source authentication of messages exchanged by CoAP endpoints through 1887 CoAP group communication. 1889 To this end, outgoing messages are either countersigned by the 1890 message sender endpoint with its own private key (group mode), or 1891 protected with a symmetric key, which is in turn derived using the 1892 asymmetric keys of the message sender and recipient (pairwise mode). 1894 Thus, both modes allow a recipient CoAP endpoint to verify that a 1895 message has actually been originated by a specific and identified 1896 member of the OSCORE group. 1898 6.2.3. Countering Attacks 1900 As discussed below, Group OSCORE addresses a number of security 1901 attacks mentioned in Section 11 of [RFC7252], with particular 1902 reference to their execution over IP multicast. 1904 * Since Group OSCORE provides end-to-end confidentiality and 1905 integrity of request/response messages, proxies capable of group 1906 communication cannot break message protection, and thus cannot act 1907 as man-in-the-middle beyond their legitimate duties (see 1908 Section 11.2 of [RFC7252]). In fact, intermediaries such as 1909 proxies are not assumed to have access to the OSCORE Security 1910 Context used by group members. Also, with the notable addition of 1911 signatures for the group mode, Group OSCORE protects messages 1912 using the same procedure as OSCORE (see Sections 8 and 9 of 1913 [I-D.ietf-core-oscore-groupcomm]), and especially processes CoAP 1914 options according to the same classification in U/I/E classes. 1916 * Group OSCORE limits the feasibility and impact of amplification 1917 attacks, see Section 6.3 of this document and Section 11.3 of 1918 [RFC7252]. 1920 In fact, upon receiving a group request protected with Group 1921 OSCORE in group mode, a server is able to verify whether the 1922 request is not a replay and originates from the alleged sender in 1923 the OSCORE group, by verifying the signature included in the 1924 request using the public key of that sender (see Section 8.2 of 1925 [I-D.ietf-core-oscore-groupcomm]). Furthermore, as also discussed 1926 in Section 8 of [I-D.ietf-core-oscore-groupcomm], it is 1927 recommended that servers failing to decrypt and verify an incoming 1928 message do not send back any error message. 1930 This limits an adversary to leveraging an intercepted group 1931 request protected with Group OSCORE, and then altering the source 1932 address to be the one of the intended amplification victim. 1934 Furthermore, the adversary needs to consider a group request that 1935 specifically targets a resource for which the CoAP servers are 1936 configured to respond. While this can be often correctly assumed 1937 or inferrable from the application context, it is not explicit 1938 from the group request itself, since Group OSCORE protects the 1939 Uri-Path and Uri-Query CoAP Options conveying the respective 1940 components of the target URI. 1942 As a further mitigation against amplification attacks, a server 1943 can also rely on the Echo Option for CoAP defined in 1944 [I-D.ietf-core-echo-request-tag] and include it in a response to a 1945 group request. By doing so, the server can assert that the 1946 alleged sender of the group request (i.e., the CoAP client 1947 associated to a certain public key) is indeed reachable at the 1948 claimed source address, especially if this differs from the one 1949 used in previous group requests from the same CoAP client. 1950 Although responses including the Echo Option do still result in 1951 amplification, this is limited in volume compared to when all 1952 servers reply with a full-fledged response. 1954 * Group OSCORE limits the impact of attacks based on IP spoofing 1955 also over IP multicast (see Section 11.4 of [RFC7252]). In fact, 1956 requests and corresponding responses sent in the OSCORE group can 1957 be correctly generated only by legitimate group members. 1959 Within an OSCORE group, the shared symmetric-key security material 1960 strictly provides only group-level authentication. However, 1961 source authentication of messages is also ensured, both in the 1962 group mode by means of signatures (see Sections 8.1 and 8.3 of 1963 [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by 1964 using additionally derived pairwise keys (see Sections 9.3 and 9.5 1965 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints 1966 can verify a message to be originated by the alleged, identifiable 1967 sender in the OSCORE group. 1969 As noted above, the server may additionally rely on the Echo 1970 Option for CoAP defined in [I-D.ietf-core-echo-request-tag], in 1971 order to verify the aliveness and reachability of the client 1972 sending a request from a particular IP address. 1974 * Group OSCORE does not require group members to be equipped with a 1975 good source of entropy for generating security material (see 1976 Section 11.6 of [RFC7252]), and thus does not contribute to create 1977 an entropy-related attack vector against such (constrained) CoAP 1978 endpoints. In particular, the symmetric keys used for message 1979 encryption and decryption are derived through the same HMAC-based 1980 HKDF scheme used for OSCORE (see Section 3.2 of [RFC8613]). 1981 Besides, the OSCORE Master Secret used in such derivation is 1982 securely generated by the Group Manager responsible for the OSCORE 1983 group, and securely provided to the CoAP endpoints when they join 1984 the group. 1986 * Group OSCORE prevents to make any single group member a target for 1987 subverting security in the whole OSCORE group (see Section 11.6 of 1988 [RFC7252]), even though all group members share (and can derive) 1989 the same symmetric-key security material used in the OSCORE group. 1990 In fact, source authentication is always ensured for exchanged 1991 CoAP messages, as verifiable to be originated by the alleged, 1992 identifiable sender in the OSCORE group. This relies on including 1993 a signature computed with a node's individual private key (in the 1994 group mode), or on protecting messages with a pairwise symmetric 1995 key, which is in turn derived from the asymmetric keys of the 1996 sender and recipient CoAP endpoints (in the pairwise mode). 1998 6.3. Risk of Amplification 2000 Section 11.3 of [RFC7252] highlights that CoAP group requests may be 2001 used for accidentally or deliberately performing Denial of Service 2002 attacks, especially in the form of a high-volume amplification 2003 attack, by using all the servers in the CoAP group as attack vectors. 2005 That is, following a group request sent to a CoAP group, each of the 2006 servers in the group may reply with a response which is likely larger 2007 in size than the group request. Thus, an attacker sending a single 2008 group request may achieve a high amplification factor, i.e., a high 2009 ratio between the size of the group request and the total size of the 2010 corresponding responses intended to the attack victim. 2012 Thus, consistently with Section 11.3 of [RFC7252], a server in a CoAP 2013 group: 2015 * SHOULD limit the support for CoAP group requests only to the group 2016 resources of the application group(s) using that CoAP group; 2018 * SHOULD NOT accept group requests that can not be authenticated in 2019 some way; 2021 * SHOULD NOT provide large amplification factors through its 2022 responses to a non-authenticated group request, and can possibly 2023 rely on CoAP block-wise transfers [RFC7959] to reduce the amount 2024 of amplification. 2026 Section 3.1 of [I-D.mattsson-core-coap-attacks] further discusses 2027 amplification attacks, and also notes how the amplification factor 2028 would become even higher when CoAP group communication is combined 2029 with resource observation [RFC7641]. That is, a single group request 2030 may result in multiple notification responses from each of the 2031 responding servers, throughout the observation lifetime. 2033 Thus, consistently with Section 7 of [RFC7641], a server in a CoAP 2034 group MUST strictly limit the number of notifications it sends 2035 between receiving acknowledgements that confirm the actual interest 2036 of the client in continuing the observation. 2038 Moreover, it is especially easy to perform an amplification attack 2039 when the NoSec mode is used. Therefore, even in case of non- 2040 sensitive and non-critical applications, it is generally NOT 2041 RECOMMENDED to use CoAP group communication in NoSec mode, in order 2042 to prevent an easy proliferation of high-volume amplification 2043 attacks. 2045 Exceptions should be carefully limited to use cases and accesses to a 2046 group resource that have a specific, narrow and well understood 2047 scope, and where only a few CoAP servers (or, ideally, only one) 2048 would possibly respond to a group request. 2050 A relevant exceptional example is a CoAP client performing the 2051 discovery of hosts such as a group manager or a Resource Directory 2052 [I-D.ietf-core-resource-directory], by probing for them through a 2053 group request sent to the CoAP group. This early, unprotected step 2054 is relevant for a CoAP client that does not know the address of such 2055 hosts in advance, and that does not have yet configured a mutual 2056 security relation with them. In this kind of deployments, such a 2057 discovery procedure does not result in a considerable and harmful 2058 amplification, since only the few CoAP servers object of discovery 2059 are going to respond to the group request targeting that specific 2060 resource. In particular, those hosts can be the only CoAP servers in 2061 that specific CoAP group (hence listening for group requests sent to 2062 that group), and/or the only CoAP servers explicitly configured to 2063 respond to group requests targeting specific group resources. 2065 With the exception of such particular use cases, group communications 2066 MUST be secured using Group OSCORE [I-D.ietf-core-oscore-groupcomm], 2067 see Section 5. As discussed in Section 6.2.3, this limits the 2068 feasibility and impact of amplification attacks. 2070 6.4. Replay of Non-Confirmable Messages 2072 Since all requests sent over IP multicast are Non-confirmable, a 2073 client might not be able to know if an adversary has actually 2074 captured one of its transmitted requests and later re-injected it in 2075 the group as a replay to the server nodes. In fact, even if the 2076 servers sent back responses to the replayed request, the client would 2077 typically not have a valid matching request active anymore so this 2078 attack would not accomplish anything in the client. 2080 If Group OSCORE is used, such a replay attack on the servers is 2081 prevented, since a client protects every different request with a 2082 different Sequence Number value, which is in turn included as Partial 2083 IV in the protected message and takes part in the construction of the 2084 AEAD cipher nonce. Thus, a server would be able to detect the 2085 replayed request, by checking the conveyed Partial IV against its own 2086 replay window in the OSCORE Recipient Context associated to the 2087 client. 2089 This requires a server to have a synchronized, up to date view of the 2090 sequence number used by the client. If such synchronization is lost, 2091 e.g., due to a reboot, or suspected so, the server should use the 2092 challenge-response synchronization method described in Appendix E of 2093 [I-D.ietf-core-oscore-groupcomm] and based on the Echo Option for 2094 CoAP defined in [I-D.ietf-core-echo-request-tag], in order to 2095 (re-)synchronize with the client's sequence number. 2097 6.5. Use of CoAP No-Response Option 2099 When CoAP group communication is used in CoAP NoSec (No Security) 2100 mode (see Section 4), the CoAP No-Response Option [RFC7967] could be 2101 misused by a malicious client to evoke as much responses from servers 2102 to a group request as possible, by using the value '0' - Interested 2103 in all responses. This even overrides the default behaviour of a 2104 CoAP server to suppress the response in case there is nothing of 2105 interest to respond with. Therefore, this option can be used to 2106 perform an amplification attack (see Section 6.3). 2108 A proposed mitigation is to only allow this option to relax the 2109 standard suppression rules for a resource in case the option is sent 2110 by an authenticated client. If sent by an unauthenticated client, 2111 the option can be used to expand the classes of responses suppressed 2112 compared to the default rules but not to reduce the classes of 2113 responses suppressed. 2115 6.6. 6LoWPAN and MPL 2117 In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior 2118 to transmission. A 6LoWPAN Router that forwards a fragmented packet 2119 may have a relatively high impact on the occupation of the wireless 2120 channel and may locally experience high memory load due to packet 2121 buffering. For example, the MPL [RFC7731] protocol requires an MPL 2122 Forwarder to store the packet for a longer duration, to allow 2123 multiple forwarding transmissions to neighboring Forwarders. If one 2124 or more of the fragments are not received correctly by an MPL 2125 Forwarder during its packet reassembly time window, the Forwarder 2126 discards all received fragments and at a future point in time it 2127 needs to receive again all the packet fragments (this time, possibly 2128 from another neighboring MPL Forwarder). 2130 For these reasons, a fragmented IPv6 multicast packet is a possible 2131 attack vector in a Denial of Service (DoS) amplification attack. See 2132 Section 6.3 of this document and Section 11.3 of [RFC7252] for more 2133 details on amplification. To mitigate the risk, applications sending 2134 multicast IPv6 requests to 6LoWPAN hosted CoAP servers SHOULD limit 2135 the size of the request to avoid 6LoWPAN fragmentation of the request 2136 packet. A 6LoWPAN Router or (MPL) multicast forwarder SHOULD 2137 deprioritize forwarding for multi-fragment 6LoWPAN multicast packets. 2138 6LoWPAN Border Routers are typical ingress points where multicast 2139 traffic enters into a 6LoWPAN network. Specific MPL Forwarders 2140 (whether located on a 6LBR or not) may also be configured as ingress 2141 points. Any such ingress point SHOULD implement multicast packet 2142 filtering to prevent unwanted multicast traffic from entering a 2143 6LoWPAN network from the outside. For example, it could filter out 2144 all multicast packets for which there is no known multicast listener 2145 on the 6LoWPAN network. See Section 3.10 for protocols that allow 2146 multicast listeners to signal which groups they would like to listen 2147 to. As part of multicast packet filtering, the ingress point SHOULD 2148 implement a filtering criterium based on the size of the multicast 2149 packet. Ingress multicast packets above a defined size may then be 2150 dropped or deprioritized. 2152 6.7. Wi-Fi 2154 In a home automation scenario using Wi-Fi, Wi-Fi security should be 2155 enabled to prevent rogue nodes from joining. The Customer Premises 2156 Equipment (CPE) that enables access to the Internet should also have 2157 its IP multicast filters set so that it enforces multicast scope 2158 boundaries to isolate local multicast groups from the rest of the 2159 Internet (e.g., as per [RFC6092]). In addition, the scope of IP 2160 multicast transmissions and listeners should be site-local (5) or 2161 smaller. For site-local scope, the CPE will be an appropriate 2162 multicast scope boundary point. 2164 6.8. Monitoring 2166 6.8.1. General Monitoring 2168 CoAP group communication can be used to control a set of related 2169 devices: for example, simultaneously turn on all the lights in a 2170 room. This intrinsically exposes the group to some unique monitoring 2171 risks that devices not in a group are not as vulnerable to. For 2172 example, assume an attacker is able to physically see a set of lights 2173 turn on in a room. Then the attacker can correlate an observed CoAP 2174 group communication message to the observed coordinated group action 2175 -- even if the CoAP message is (partly) encrypted. 2176 This will give the attacker side-channel information to plan further 2177 attacks (e.g., by determining the members of the group some network 2178 topology information may be deduced). 2180 6.8.2. Pervasive Monitoring 2182 A key additional threat consideration for group communication is 2183 pervasive monitoring [RFC7258]. CoAP group communication solutions 2184 that are built on top of IP multicast need to pay particular heed to 2185 these dangers. This is because IP multicast is easier to intercept 2186 compared to IP unicast. Also, CoAP traffic is typically used for the 2187 Internet of Things. This means that CoAP (multicast) group 2188 communication may be used for the control and monitoring of critical 2189 infrastructure (e.g., lights, alarms, HVAC, electrical grid, etc.) 2190 that may be prime targets for attack. 2192 For example, an attacker may attempt to record all the CoAP traffic 2193 going over a smart grid (i.e., networked electrical utility) and try 2194 to determine critical nodes for further attacks. For example, the 2195 source node (controller) sends out CoAP group communication messages 2196 which easily identifies it as a controller. CoAP multicast traffic 2197 is inherently more vulnerable compared to unicast, as the same packet 2198 may be replicated over many more links, leading to a higher 2199 probability of packet capture by a pervasive monitoring system. 2201 One mitigation is to restrict the scope of IP multicast to the 2202 minimal scope that fulfills the application need. See the congestion 2203 control recommendations in the last bullet of 2204 Section 3.6 to minimize the scope. Thus, for example, realm-local IP 2205 multicast scope is always preferred over site-local scope IP 2206 multicast if this fulfills the application needs. 2208 Even if all CoAP multicast traffic is encrypted/protected, an 2209 attacker may still attempt to capture this traffic and perform an 2210 off-line attack in the future. 2212 7. IANA Considerations 2214 This document has no actions for IANA. 2216 8. References 2218 8.1. Normative References 2220 [I-D.ietf-core-echo-request-tag] 2221 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 2222 Request-Tag, and Token Processing", Work in Progress, 2223 Internet-Draft, draft-ietf-core-echo-request-tag-14, 4 2224 October 2021, . 2227 [I-D.ietf-core-oscore-groupcomm] 2228 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 2229 and J. Park, "Group OSCORE - Secure Group Communication 2230 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 2231 core-oscore-groupcomm-13, 25 October 2021, 2232 . 2235 [I-D.ietf-cose-rfc8152bis-algs] 2236 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2237 Initial Algorithms", Work in Progress, Internet-Draft, 2238 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2239 . 2242 [I-D.ietf-cose-rfc8152bis-struct] 2243 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2244 Structures and Process", Work in Progress, Internet-Draft, 2245 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2246 . 2249 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2250 Communication Layers", STD 3, RFC 1122, 2251 DOI 10.17487/RFC1122, October 1989, 2252 . 2254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2255 Requirement Levels", BCP 14, RFC 2119, 2256 DOI 10.17487/RFC2119, March 1997, 2257 . 2259 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2260 Thyagarajan, "Internet Group Management Protocol, Version 2261 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2262 . 2264 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2265 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2266 DOI 10.17487/RFC3810, June 2004, 2267 . 2269 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2270 Control Message Protocol (ICMPv6) for the Internet 2271 Protocol Version 6 (IPv6) Specification", STD 89, 2272 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2273 . 2275 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2276 "Transmission of IPv6 Packets over IEEE 802.15.4 2277 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2278 . 2280 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2281 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2282 DOI 10.17487/RFC6282, September 2011, 2283 . 2285 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2286 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2287 . 2289 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2290 Application Protocol (CoAP)", RFC 7252, 2291 DOI 10.17487/RFC7252, June 2014, 2292 . 2294 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2295 Application Protocol (CoAP)", RFC 7641, 2296 DOI 10.17487/RFC7641, September 2015, 2297 . 2299 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2300 the Constrained Application Protocol (CoAP)", RFC 7959, 2301 DOI 10.17487/RFC7959, August 2016, 2302 . 2304 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 2305 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 2306 the Constrained Application Protocol (CoAP)", RFC 8075, 2307 DOI 10.17487/RFC8075, February 2017, 2308 . 2310 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 2311 FETCH Methods for the Constrained Application Protocol 2312 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 2313 . 2315 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2316 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2317 May 2017, . 2319 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2320 "Object Security for Constrained RESTful Environments 2321 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2322 . 2324 8.2. Informative References 2326 [Californium] 2327 Eclipse Foundation, "Eclipse Californium", March 2019, 2328 . 2332 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 2333 CoAP Server & Client in Go", March 2019, 2334 . 2336 [I-D.ietf-ace-key-groupcomm-oscore] 2337 Tiloca, M., Park, J., and F. Palombini, "Key Management 2338 for OSCORE Groups in ACE", Work in Progress, Internet- 2339 Draft, draft-ietf-ace-key-groupcomm-oscore-12, 25 October 2340 2021, . 2343 [I-D.ietf-ace-oauth-authz] 2344 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2345 H. Tschofenig, "Authentication and Authorization for 2346 Constrained Environments (ACE) using the OAuth 2.0 2347 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2348 draft-ietf-ace-oauth-authz-45, 29 August 2021, 2349 . 2352 [I-D.ietf-ace-oscore-gm-admin] 2353 Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, 2354 "Admin Interface for the OSCORE Group Manager", Work in 2355 Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- 2356 04, 25 October 2021, . 2359 [I-D.ietf-core-coap-pubsub] 2360 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2361 Subscribe Broker for the Constrained Application Protocol 2362 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2363 core-coap-pubsub-09, 30 September 2019, 2364 . 2367 [I-D.ietf-core-new-block] 2368 Boucadair, M. and J. Shallow, "Constrained Application 2369 Protocol (CoAP) Block-Wise Transfer Options Supporting 2370 Robust Transmission", Work in Progress, Internet-Draft, 2371 draft-ietf-core-new-block-14, 26 May 2021, 2372 . 2375 [I-D.ietf-core-resource-directory] 2376 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2377 D. Stok, "CoRE Resource Directory", Work in Progress, 2378 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2379 March 2021, . 2382 [I-D.mattsson-core-coap-attacks] 2383 Mattsson, J. P., Fornehed, J., Selander, G., Palombini, 2384 F., and C. Amsüss, "CoAP Attacks", Work in Progress, 2385 Internet-Draft, draft-mattsson-core-coap-attacks-01, 27 2386 July 2021, . 2389 [I-D.tiloca-core-groupcomm-proxy] 2390 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 2391 Communication", Work in Progress, Internet-Draft, draft- 2392 tiloca-core-groupcomm-proxy-05, 25 October 2021, 2393 . 2396 [I-D.tiloca-core-oscore-discovery] 2397 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 2398 OSCORE Groups with the CoRE Resource Directory", Work in 2399 Progress, Internet-Draft, draft-tiloca-core-oscore- 2400 discovery-10, 25 October 2021, 2401 . 2404 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2405 Capabilities in Customer Premises Equipment (CPE) for 2406 Providing Residential IPv6 Internet Service", RFC 6092, 2407 DOI 10.17487/RFC6092, January 2011, 2408 . 2410 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2411 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2412 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2413 Low-Power and Lossy Networks", RFC 6550, 2414 DOI 10.17487/RFC6550, March 2012, 2415 . 2417 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 2418 the Internet Group Management Protocol (IGMP) and 2419 Multicast Listener Discovery (MLD) for Routers in Mobile 2420 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 2421 May 2012, . 2423 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2424 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2425 2014, . 2427 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 2428 DOI 10.17487/RFC7346, August 2014, 2429 . 2431 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 2432 the Constrained Application Protocol (CoAP)", RFC 7390, 2433 DOI 10.17487/RFC7390, October 2014, 2434 . 2436 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 2437 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 2438 February 2016, . 2440 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2441 Bose, "Constrained Application Protocol (CoAP) Option for 2442 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2443 August 2016, . 2445 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2446 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 2447 Application Protocol) over TCP, TLS, and WebSockets", 2448 RFC 8323, DOI 10.17487/RFC8323, February 2018, 2449 . 2451 [RFC8710] Fossati, T., Hartke, K., and C. Bormann, "Multipart 2452 Content-Format for the Constrained Application Protocol 2453 (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020, 2454 . 2456 Appendix A. Use Cases 2458 To illustrate where and how CoAP-based group communication can be 2459 used, this section summarizes the most common use cases. These use 2460 cases include both secured and non-secured CoAP usage. Each 2461 subsection below covers one particular category of use cases for 2462 CoRE. Within each category, a use case may cover multiple 2463 application areas such as home IoT, commercial building IoT (sensing 2464 and control), industrial IoT/control, or environmental sensing. 2466 A.1. Discovery 2468 Discovery of physical devices in a network, or discovery of 2469 information entities hosted on network devices, are operations that 2470 are usually required in a system during the phases of setup or 2471 (re)configuration. When a discovery use case involves devices that 2472 need to interact without having been configured previously with a 2473 common security context, unsecured CoAP communication is typically 2474 used. Discovery may involve a request to a directory server, which 2475 provides services to aid clients in the discovery process. One 2476 particular type of directory server is the CoRE Resource Directory 2477 [I-D.ietf-core-resource-directory]; and there may be other types of 2478 directories that can be used with CoAP. 2480 A.1.1. Distributed Device Discovery 2482 Device discovery is the discovery and identification of networked 2483 devices -- optionally only devices of a particular class, type, 2484 model, or brand. Group communication is used for distributed device 2485 discovery, if a central directory server is not used. Typically in 2486 distributed device discovery, a multicast request is sent to a 2487 particular address (or address range) and multicast scope of 2488 interest, and any devices configured to be discoverable will respond 2489 back. For the alternative solution of centralized device discovery a 2490 central directory server is accessed through unicast, in which case 2491 group communication is not needed. This requires that the address of 2492 the central directory is either preconfigured in each device or 2493 configured during operation using a protocol. 2495 In CoAP, device discovery can be implemented by CoAP resource 2496 discovery requesting (GET) a particular resource that the sought 2497 device class, type, model or brand is known to respond to. It can 2498 also be implemented using CoAP resource discovery (Section 7 of 2499 [RFC7252]) and the CoAP query interface defined in Section 4 of 2500 [RFC6690] to find these particular resources. Also, a multicast GET 2501 request to /.well-known/core can be used to discover all CoAP 2502 devices. 2504 A.1.2. Distributed Service Discovery 2506 Service discovery is the discovery and identification of particular 2507 services hosted on network devices. Services can be identified by 2508 one or more parameters such as ID, name, protocol, version and/or 2509 type. Distributed service discovery involves group communication to 2510 reach individual devices hosting a particular service; with a central 2511 directory server not being used. 2513 In CoAP, services are represented as resources and service discovery 2514 is implemented using resource discovery (Section 7 of [RFC7252]) and 2515 the CoAP query interface defined in Section 4 of [RFC6690]. 2517 A.1.3. Directory Discovery 2519 This use case is a specific sub-case of Distributed Service Discovery 2520 (Appendix A.1.2), in which a device needs to identify the location of 2521 a Directory on the network to which it can e.g., register its own 2522 offered services, or to which it can perform queries to identify and 2523 locate other devices/services it needs to access on the network. 2524 Section 3.3 of [RFC7390] showed an example of discovering a CoRE 2525 Resource Directory using CoAP group communication. As defined in 2526 [I-D.ietf-core-resource-directory], a resource directory is a web 2527 entity that stores information about web resources and implements 2528 REST interfaces for registration and lookup of those resources. For 2529 example, a device can register itself to a resource directory to let 2530 it be found by other devices and/or applications. 2532 A.2. Operational Phase 2534 Operational phase use cases describe those operations that occur most 2535 frequently in a networked system, during its operational lifetime and 2536 regular operation. Regular usage is when the applications on 2537 networked devices perform the tasks they were designed for and 2538 exchange of application-related data using group communication 2539 occurs. Processes like system reconfiguration, group changes, 2540 system/device setup, extra group security changes, etc. are not part 2541 of regular operation. 2543 A.2.1. Actuator Group Control 2545 Group communication can be beneficial to control actuators that need 2546 to act in synchrony, as a group, with strict timing (latency) 2547 requirements. Examples are office lighting, stage lighting, street 2548 lighting, or audio alert/Public Address systems. Sections 3.4 and 2549 3.5 of [RFC7390] showed examples of lighting control of a group of 2550 6LoWPAN-connected lights. 2552 A.2.2. Device Group Status Request 2554 To properly monitor the status of systems, there may be a need for 2555 ad-hoc, unplanned status updates. Group communication can be used to 2556 quickly send out a request to a (potentially large) number of devices 2557 for specific information. Each device then responds back with the 2558 requested data. Those devices that did not respond to the request 2559 can optionally be polled again via reliable unicast communication to 2560 complete the dataset. The device group may be defined e.g., as "all 2561 temperature sensors on floor 3", or "all lights in wing B". For 2562 example, it could be a status request for device temperature, most 2563 recent sensor event detected, firmware version, network load, and/or 2564 battery level. 2566 A.2.3. Network-wide Query 2568 In some cases a whole network or subnet of multiple IP devices needs 2569 to be queried for status or other information. This is similar to 2570 the previous use case except that the device group is not defined in 2571 terms of its function/type but in terms of its network location. 2572 Technically this is also similar to distributed service discovery 2573 (Appendix A.1.2) where a query is processed by all devices on a 2574 network - except that the query is not about services offered by the 2575 device, but rather specific operational data is requested. 2577 A.2.4. Network-wide / Group Notification 2579 In some cases a whole network, or subnet of multiple IP devices, or a 2580 specific target group needs to be notified of a status change or 2581 other information. This is similar to the previous two use cases 2582 except that the recipients are not expected to respond with some 2583 information. Unreliable notification can be acceptable in some use 2584 cases, in which a recipient does not respond with a confirmation of 2585 having received the notification. In such a case, the receiving CoAP 2586 server does not have to create a CoAP response. If the sender needs 2587 confirmation of reception, the CoAP servers can be configured for 2588 that resource to respond with a 2.xx success status after processing 2589 a notification request successfully. 2591 A.3. Software Update 2593 Group communication can be useful to efficiently distribute new 2594 software (firmware, image, application, etc.) to a group of multiple 2595 devices. In this case, the group is defined in terms of device type: 2596 all devices in the target group are known to be capable of installing 2597 and running the new software. The software is distributed as a 2598 series of smaller blocks that are collected by all devices and stored 2599 in memory. All devices in the target group are usually responsible 2600 for integrity verification of the received software; which can be 2601 done per-block or for the entire software image once all blocks have 2602 been received. Due to the inherent unreliability of CoAP multicast, 2603 there needs to be a backup mechanism (e.g., implemented using CoAP 2604 unicast) by which a device can individually request missing blocks of 2605 a whole software image/entity. Prior to a multicast software update, 2606 the group of recipients can be separately notified that there is new 2607 software available and coming, using the above network-wide or group 2608 notification. 2610 Appendix B. Document Updates 2612 RFC EDITOR: PLEASE REMOVE THIS SECTION. 2614 B.1. Version -04 to -05 2616 * Clarified changes to other documents. 2618 * Clarified relation between different group types. 2620 * Clarified discovery of application groups. 2622 * Discussed methods to express application group names in requests. 2624 * Revised and extended text on the NoSec mode and amplification 2625 attacks. 2627 * Rephrased backward/forward security as properties. 2629 * Removed appendix on Multi-ETag Option for response revalidation. 2631 * Editorial improvements. 2633 B.2. Version -03 to -04 2635 * Multi-ETag Option for response revalidation moved to appendix. 2637 * ETag Option usage added. 2639 * Q-Block Options added in the block-wise transfer section. 2641 * Caching at proxies moved to draft-tiloca-core-groupcomm-proxy. 2643 * Client-Proxy response revalidation with the Group-ETag Option 2644 moved to draft-tiloca-core-groupcomm-proxy. 2646 * Security considerations on amplification attacks. 2648 * Generalized transport protocols to include others than UDP/IP 2649 multicast; and security protocols other than Group OSCORE. 2651 * Overview of security cases with proxies. 2653 * Editorial improvements. 2655 B.3. Version -02 to -03 2657 * Multiple responses from same server handled at the application. 2659 * Clarifications about issues with forward-proxies. 2661 * Operations for reverse-proxies. 2663 * Caching of responses at proxies. 2665 * Client-Server response revalidation, with Multi-ETag Option. 2667 * Client-Proxy response revalidation, with the Group-ETag Option. 2669 B.4. Version -01 to -02 2671 * Clarified relation between security groups and application groups. 2673 * Considered also FETCH for requests over IP multicast. 2675 * More details on Observe re-registration. 2677 * More details on Proxy intermediaries. 2679 * More details on servers changing port number in the response. 2681 * Usage of the Uri-Host Option to indicate an application group. 2683 * Response suppression based on classes of error codes. 2685 B.5. Version -00 to -01 2687 * Clarifications on group memberships for the different group types. 2689 * Simplified description of Token reusage, compared to the unicast 2690 case. 2692 * More details on the rationale for response suppression. 2694 * Clarifications of creation and management of security groups. 2696 * Clients more knowledgeable than proxies about stopping receiving 2697 responses. 2699 * Cancellation of group observations. 2701 * Clarification on multicast scope to use. 2703 * Both the group mode and pairwise mode of Group OSCORE are 2704 considered. 2706 * Updated security considerations. 2708 * Editorial improvements. 2710 Acknowledgments 2712 The authors sincerely thank Christian Amsuess, Carsten Bormann, 2713 Thomas Fossati, Rikard Hoeglund, John Mattsson and Jim Schaad for 2714 their comments and feedback. 2716 The work on this document has been partly supported by VINNOVA and 2717 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2718 (Grant agreement 952652). 2720 Authors' Addresses 2722 Esko Dijk 2723 IoTconsultancy.nl 2724 \________________\ 2725 Utrecht 2726 Netherlands 2728 Email: esko.dijk@iotconsultancy.nl 2730 Chonggang Wang 2731 InterDigital 2732 1001 E Hector St, Suite 300 2733 Conshohocken, PA 19428 2734 United States 2736 Email: Chonggang.Wang@InterDigital.com 2738 Marco Tiloca 2739 RISE AB 2740 Isafjordsgatan 22 2741 SE-16440 Stockholm Kista 2742 Sweden 2744 Email: marco.tiloca@ri.se