idnits 2.17.1 draft-ietf-core-groupcomm-bis-06.txt: -(2811): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2834): 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 3 instances 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 (7 March 2022) is 780 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-14 ** 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-13 == Outdated reference: A later version (-11) exists of draft-ietf-ace-oscore-gm-admin-05 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-01) exists of draft-mattsson-t2trg-amplification-attacks-00 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-06 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-11 Summary: 1 error (**), 0 flaws (~~), 10 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: 8 September 2022 RISE AB 8 7 March 2022 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-ietf-core-groupcomm-bis-06 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 8 September 2022. 55 Copyright Notice 57 Copyright (c) 2022 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 Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised 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 . . . . . . . . . . 7 76 2.1. Group Definition . . . . . . . . . . . . . . . . . . . . 7 77 2.1.1. CoAP Group . . . . . . . . . . . . . . . . . . . . . 7 78 2.1.2. Application Group . . . . . . . . . . . . . . . . . . 7 79 2.1.3. Security Group . . . . . . . . . . . . . . . . . . . 8 80 2.1.4. Relations Between Group Types . . . . . . . . . . . . 8 81 2.2. Group Configuration . . . . . . . . . . . . . . . . . . . 11 82 2.2.1. Group Naming . . . . . . . . . . . . . . . . . . . . 11 83 2.2.2. Group Creation and Membership . . . . . . . . . . . . 17 84 2.2.3. Group Discovery . . . . . . . . . . . . . . . . . . . 18 85 2.2.4. Group Maintenance . . . . . . . . . . . . . . . . . . 25 86 3. CoAP Usage in Group Communication . . . . . . . . . . . . . . 26 87 3.1. Request/Response Model . . . . . . . . . . . . . . . . . 26 88 3.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 26 89 3.1.2. Response Suppression . . . . . . . . . . . . . . . . 27 90 3.1.3. Repeating a Request . . . . . . . . . . . . . . . . . 27 91 3.1.4. Request/Response Matching and Distinguishing 92 Responses . . . . . . . . . . . . . . . . . . . . . . 28 93 3.1.5. Token Reuse . . . . . . . . . . . . . . . . . . . . . 28 94 3.1.6. Client Handling of Multiple Responses With Same 95 Token . . . . . . . . . . . . . . . . . . . . . . . . 29 97 3.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 30 98 3.2.1. Freshness Model . . . . . . . . . . . . . . . . . . . 31 99 3.2.2. Validation Model . . . . . . . . . . . . . . . . . . 31 100 3.3. URI Path Selection . . . . . . . . . . . . . . . . . . . 32 101 3.4. Port Selection for UDP Transport . . . . . . . . . . . . 33 102 3.5. Proxy Operation . . . . . . . . . . . . . . . . . . . . . 33 103 3.5.1. Forward-Proxies . . . . . . . . . . . . . . . . . . . 33 104 3.5.2. Reverse-Proxies . . . . . . . . . . . . . . . . . . . 35 105 3.6. Congestion Control . . . . . . . . . . . . . . . . . . . 37 106 3.7. Observing Resources . . . . . . . . . . . . . . . . . . . 38 107 3.8. Block-Wise Transfer . . . . . . . . . . . . . . . . . . . 40 108 3.9. Transport Protocols . . . . . . . . . . . . . . . . . . . 41 109 3.9.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 41 110 3.9.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 42 111 3.9.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 42 112 3.9.4. Other Transports . . . . . . . . . . . . . . . . . . 42 113 3.10. Interworking with Other Protocols . . . . . . . . . . . . 43 114 3.10.1. MLD/MLDv2/IGMP/IGMPv3 . . . . . . . . . . . . . . . 43 115 3.10.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . 43 116 3.10.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . 44 117 4. Unsecured Group Communication . . . . . . . . . . . . . . . . 45 118 5. Secured Group Communication using Group OSCORE . . . . . . . 45 119 5.1. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 45 120 5.2. Secure Group Maintenance . . . . . . . . . . . . . . . . 47 121 5.3. Proxy Security . . . . . . . . . . . . . . . . . . . . . 48 122 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 123 6.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 49 124 6.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 50 125 6.2.1. Group Key Management . . . . . . . . . . . . . . . . 51 126 6.2.2. Source Authentication . . . . . . . . . . . . . . . . 51 127 6.2.3. Countering Attacks . . . . . . . . . . . . . . . . . 52 128 6.3. Risk of Amplification . . . . . . . . . . . . . . . . . . 54 129 6.4. Replay of Non-Confirmable Messages . . . . . . . . . . . 55 130 6.5. Use of CoAP No-Response Option . . . . . . . . . . . . . 56 131 6.6. 6LoWPAN and MPL . . . . . . . . . . . . . . . . . . . . . 56 132 6.7. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 57 133 6.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 57 134 6.8.1. General Monitoring . . . . . . . . . . . . . . . . . 57 135 6.8.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 58 136 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 137 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 138 8.1. Normative References . . . . . . . . . . . . . . . . . . 58 139 8.2. Informative References . . . . . . . . . . . . . . . . . 61 140 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 64 141 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 64 142 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 64 143 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 65 144 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 65 146 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 65 147 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 65 148 A.2.2. Device Group Status Request . . . . . . . . . . . . . 66 149 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 66 150 A.2.4. Network-wide / Group Notification . . . . . . . . . . 66 151 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 66 152 Appendix B. Examples of Message Exchanges . . . . . . . . . . . 67 153 Appendix C. Document Updates . . . . . . . . . . . . . . . . . . 73 154 C.1. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 73 155 C.2. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 74 156 C.3. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 74 157 C.4. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 74 158 C.5. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 75 159 C.6. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 75 160 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 163 1. Introduction 165 This document specifies group communication using the Constrained 166 Application Protocol (CoAP) [RFC7252], together with UDP/IP multicast 167 as the default transport for CoAP group communication messages. CoAP 168 is a RESTful communication protocol that is used in resource- 169 constrained nodes, and in resource-constrained networks where packet 170 sizes should be small. This area of use is summarized as Constrained 171 RESTful Environments (CoRE). 173 One-to-many group communication can be achieved in CoAP, by a client 174 using UDP/IP multicast data transport to send multicast CoAP request 175 messages. In response, each server in the addressed group sends a 176 response message back to the client over UDP/IP unicast. Notable 177 CoAP implementations supporting group communication include the 178 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 179 Foundation and the "Implementation of CoAP Server & Client in Go" 180 [Go-OCF] from the Open Connectivity Foundation (OCF). 182 Both unsecured and secured CoAP group communication are specified in 183 this document. Security is achieved by using Group Object Security 184 for Constrained RESTful Environments (Group OSCORE) 185 [I-D.ietf-core-oscore-groupcomm], which in turn builds on Object 186 Security for Constrained Restful Environments (OSCORE) [RFC8613]. 187 This method provides end-to-end application-layer security protection 188 of CoAP messages, by using CBOR Object Signing and Encryption (COSE) 189 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs]. 191 This documents replaces and obsoletes [RFC7390], while it updates 192 both [RFC7252] and [RFC7641]. A summary of the changes and additions 193 to these documents is provided in Section 1.3. 195 All sections in the body of this document are normative, while 196 appendices are informative. For additional background about use 197 cases for CoAP group communication in resource-constrained devices 198 and networks, see Appendix A. 200 1.1. Scope 202 For group communication, only those solutions that use CoAP messages 203 over a "one-to-many" (i.e., non-unicast) transport protocol are in 204 the scope of this document. There are alternative methods to achieve 205 group communication using CoAP, using unicast only. One example is 206 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 207 broker server that CoAP clients access via unicast communication. 208 These alternative methods may be usable for the same or similar use 209 cases as the ones targeted in this document. 211 This document defines UDP/IP multicast as the default transport 212 protocol for CoAP group requests, as in [RFC7252]. Other transport 213 protocols (which may include broadcast, non-IP multicast, geocast, 214 etc.) are not described in detail and are left for future work. 215 Although UDP/IP multicast transport is assumed in most of the text in 216 this document, we expect many of the considerations for UDP/IP 217 multicast can be re-used for alternative transport protocols. 219 Furthermore, this document defines Group OSCORE 220 [I-D.ietf-core-oscore-groupcomm] as the default group communication 221 security solution for CoAP. Security solutions for group 222 communication and configuration other than Group OSCORE are left for 223 future work. General principles for secure group configuration are 224 in scope. 226 1.2. Terminology 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 230 "OPTIONAL" in this document are to be interpreted as described in BCP 231 14 [RFC2119] [RFC8174] when, and only when, they appear in all 232 capitals, as shown here. 234 This specification requires readers to be familiar with CoAP 235 terminology [RFC7252]. Terminology related to group communication is 236 defined in Section 2.1. 238 In addition, the following terms are extensively used. 240 * Group URI - This is defined as a CoAP URI that has the "coap" 241 scheme and includes in the authority component either an IP 242 multicast address or a group hostname (e.g., a Group Fully 243 Qualified Domain Name (FQDN)) that can be resolved to an IP 244 multicast address. A group URI also contains an optional UDP port 245 number in the authority component. Group URIs follow the regular 246 CoAP URI syntax (see Section 6 of [RFC7252]). 248 * Security material - This refers to any security keys, counters or 249 parameters stored in a device that are required to participate in 250 secure group communication with other devices. 252 1.3. Changes to Other Documents 254 This document obsoletes and replaces [RFC7390] as follows. 256 * It defines separate definitions for CoAP groups, application 257 groups and security groups, together with high-level guidelines on 258 their configuration (see Section 2). 260 * It defines the use of Group OSCORE 261 [I-D.ietf-core-oscore-groupcomm] as the security protocol to 262 protect group communication for CoAP, together with high-level 263 guidelines on secure group maintenance (see Section 5). 265 * It updates all the guidelines about using group communication for 266 CoAP (see Section 3). 268 * It strongly discourages unsecured group communication for CoAP 269 based on the "NoSec" mode (see Section 4 and Section 6.1) and 270 highlights the risk of amplification attacks (see Section 6.3). 272 This document updates [RFC7252] as follows. 274 * It updates the request/response model for group communication, as 275 to response suppression (see Section 3.1.2) and token reuse time 276 (see Section 3.1.5). 278 * It updates the freshness model and validation model to use for 279 cached responses (see Section 3.2.1 and Section 3.2.2). 281 This document updates [RFC7641] as follows. 283 * It defines the use of the CoAP Observe Option in group requests, 284 for both the GET method and the FETCH method [RFC8132], together 285 with normative behavior for both CoAP clients and CoAP servers 286 (see Section 3.7). 288 2. Group Definition and Group Configuration 290 In the following, different group types are first defined in 291 Section 2.1. Then, Group configuration, including group creation and 292 maintenance by an application, user or commissioning entity is 293 considered in Section 2.2. 295 2.1. Group Definition 297 Three types of groups and their mutual relations are defined in this 298 section: CoAP group, application group, and security group. 300 2.1.1. CoAP Group 302 A CoAP group is defined as a set of CoAP endpoints, where each 303 endpoint is configured to receive CoAP group messages that are sent 304 to the group's associated IP multicast address and UDP port. That 305 is, CoAP groups have relevance at the level of IP networks and CoAP 306 endpoints. 308 An endpoint may be a member of multiple CoAP groups, by subscribing 309 to multiple IP multicast addresses. A node may be a member of 310 multiple CoAP groups, by hosting multiple CoAP server endpoints on 311 different UDP ports. Group membership(s) of an endpoint or node may 312 dynamically change over time. A node or endpoint sending a CoAP 313 group message to a CoAP group is not necessarily itself a member of 314 this CoAP group: it is a member only if it also has a CoAP endpoint 315 listening on the group's associated IP multicast address and UDP 316 port. 318 A CoAP group is identified by information encoded within a group URI. 319 Further details on identifying a CoAP group are provided in 320 Section 2.2.1.1. 322 2.1.2. Application Group 324 An application group is a set of CoAP server endpoints (hosted on 325 different nodes) that share a common set of CoAP resources. That is, 326 an application group has relevance at the application level. For 327 example, an application group could denote all lights in an office 328 room or all sensors in a hallway. 330 An endpoint may be a member of multiple application groups. A client 331 endpoint that sends a group communication message to an application 332 group is not necessarily itself a member of this application group. 334 There can be a one-to-one or a one-to-many relation between a CoAP 335 group and application group(s). Such relations are discussed in more 336 detail in Section 2.1.4. 338 An application group name may be explicitly encoded in the group URI 339 of a CoAP request, for example in the URI path component. If this is 340 not the case, the application group is implicitly derived by the 341 receiver, e.g., based on information in the CoAP request or other 342 contextual information. Further details on identifying an 343 application group are provided in Section 2.2.1.2. 345 2.1.3. Security Group 347 For secure group communication, a security group is required. A 348 security group comprises endpoints storing shared group security 349 material, such that they can use it to protect and verify mutually 350 exchanged messages. 352 That is, a client endpoint needs to be a member of a security group 353 in order to send a valid secured group communication message to that 354 group. A server endpoint needs to be a member of a security group in 355 order to receive and correctly verify a secured group communication 356 message sent to that group. An endpoint may be a member of multiple 357 security groups. 359 There can be a many-to-many relation between security groups and CoAP 360 groups, but often it is one-to-one. Also, there can be a many-to- 361 many relation between security groups and application groups, but 362 often it is one-to-one. Such relations are discussed in more detail 363 in Section 2.1.4. 365 A special security group named "NoSec" identifies group communication 366 without any security at the transport layer nor at the CoAP layer. 367 Further details on identifying a security group are provided in 368 Section 2.2.1.3. 370 2.1.4. Relations Between Group Types 372 Using the above group type definitions, a CoAP group communication 373 message sent by an endpoint can be represented as a tuple that 374 contains one instance of each group type: 376 (application group, CoAP group, security group) 378 A special note is appropriate about the possible relation between 379 security groups and application groups. 381 On one hand, multiple application groups may use the same security 382 group. Thus, the same group security material is used to protect the 383 messages targeting any of those application groups. This has the 384 benefit that typically less storage, configuration and updating are 385 required for security material. In this case, a CoAP endpoint is 386 supposed to know the exact application group to refer to for each 387 message that is sent or received, based on, e.g., the used server 388 port number, the targeted resource, or the content and structure of 389 the message payload. 391 On the other hand, a single application group may use multiple 392 security groups. Thus, different messages targeting the resources of 393 the application group can be protected with different security 394 material. This can be convenient, for example, if the security 395 groups differ with respect to the cryptographic algorithms and 396 related parameters they use. In this case, a CoAP client can join 397 just one of the security groups, based on what it supports and 398 prefers, while a CoAP server in the application group would rather 399 have to join all of them. 401 Beyond this particular case, applications should be careful in 402 associating a same application group to multiple security groups. In 403 particular, it is NOT RECOMMENDED to use different security groups to 404 reflect different access policies for resources in a same application 405 group. That is, being a member of a security group actually grants 406 access only to exchange secured messages and enables authentication 407 of group members, while access control (authorization) to use 408 resources in the application group belongs to a separate security 409 domain. It has to be separately enforced by leveraging the resource 410 properties or through dedicated access control credentials assessed 411 by separate means. 413 Figure 1 summarizes the relations between the different types of 414 groups described above in UML class diagram notation. The class 415 attributes in square brackets are optionally defined. 417 +------------------------+ +--------------------+ 418 | Application group | | CoAP group | 419 |........................| |....................| 420 | | | | 421 | [ - group name ] +-----------------+ - IP mcast address | 422 | | 1...N 1 | - UDP port number | 423 | | | | 424 | | | | 425 +-------------+----------+ +---------+----------+ 426 | 1...N | 1...N 427 | | 428 | | 429 | | 1...N 430 | +----------+------------+ 431 | | Security group | 432 | |.......................| 433 | | | 434 \---------------------------+ - Security group name | 435 1...N | - Security material | 436 | | 437 +-----------------------+ 439 Figure 1: Relations Among Different Group Types 441 Figure 2 provides a deployment example of the relations between the 442 different types of groups. It shows six CoAP servers (Srv1-Srv6) and 443 their respective resources hosted (/resX). There are three 444 application groups (1, 2, 3) and two security groups (1, 2). 445 Security Group 1 is used by both Application Group 1 and 2. Three 446 clients (Cli1, Cli2, Cli3) are configured with security material for 447 Security Group 1. Two clients (Cli2, Cli4) are configured with 448 security material for Security Group 2. All the shown application 449 groups use the same CoAP group (not shown in the figure), i.e., one 450 specific multicast IP address and UDP port number on which all the 451 shown resources are hosted for each server. 453 ________________________________ _________________________________ 454 / \ / \ 455 | +---------------------+ | | +---------------------+ | 456 | | Application Group 1 | | | | Application Group 3 | Cli2 | 457 | | | | | | | | 458 | Cli1 | Srv1 Srv2 Srv3 | | | | Srv5 Srv6 | Cli4 | 459 | | /resA /resA /resA | | | | /resC /resC | | 460 | Cli2 +---------------------+ | | | /resD /resD | | 461 | | | +---------------------+ | 462 | Cli3 Security Group 1 | | | 463 | | | Security Group 2 | 464 | +---------------------+ | \_________________________________/ 465 | | Application Group 2 | | 466 | | | | 467 | | Srv1 Srv4 | | 468 | | /resB /resB | | 469 | +---------------------+ | 470 \________________________________/ 472 Figure 2: Deployment Example of Different Group Types 474 2.2. Group Configuration 476 The following defines how groups of different types are named, 477 created, discovered and maintained. 479 2.2.1. Group Naming 481 Different types of group are named as specified below, separately for 482 CoAP groups, application groups and security groups. 484 2.2.1.1. CoAP Groups 486 A CoAP group is identified and named by the authority component in 487 the group URI (see Section 2.1.1), which includes the host 488 subcomponent (possibly an IP multicast address literal) and an 489 optional UDP port number. Note that the two authority components 490 and :5683 both identify the same CoAP group, whose 491 members listen to the CoAP default port number 5683. 493 When configuring a CoAP group membership, it is recommended to 494 configure an endpoint with an IP multicast address literal, instead 495 of a group hostname. This is because DNS infrastructure may not be 496 deployed in many constrained networks. In case a group hostname is 497 configured, it can be uniquely mapped to an IP multicast address via 498 DNS resolution, if DNS client functionality is available in the 499 endpoint being configured and the DNS service is supported in the 500 network. 502 Examples of hierarchical CoAP group FQDN naming (and scoping) for a 503 building control application were shown in Section 2.2 of [RFC7390]. 505 2.2.1.2. Application Groups 507 An application group can be named in many ways through different 508 types of identifiers, such as name string, (integer) number, URI or 509 other types of string. The decision of whether and how exactly an 510 application group name is encoded and transported is application 511 specific. 513 The following defines a number of possible methods to use. The shown 514 examples consider a CoAP group identified by the group hostname 515 grp.example.org. Its members are CoAP servers listening to the 516 associated IP multicast address ff35:30:2001:db8:f1::8000:1 and port 517 number 5685. Note that a group hostname is used here to have better- 518 readable examples: in practice, an implementation would likely use an 519 IP address literal as the host component of the Group URI in order to 520 reduce the size of the CoAP request. In particular, the Uri-Host 521 Option can be fully elided in this case. Also note that the Uri-Port 522 Option does not appear in the examples, since the port number 5685 is 523 already included in the CoAP request's UDP header (which is not shown 524 in the examples). 526 An application group name can be explicitly encoded in a group URI. 527 In such a case, it can be encoded within one of the following URI 528 components. 530 * URI path component - This is the most common and RECOMMENDED 531 method to encode the application group name. When using this 532 method in constrained networks, an application group name 533 GROUPNAME should be as short as possible. 535 A best practice for doing so is to use a URI path component such 536 that: i) it includes a path segment as delimiter with a designated 537 value, e.g., "gp", followed by ii) a path segment with value the 538 name of the application group, followed by iii) the path 539 segment(s) that identify the targeted resource within the 540 application group. For example, both /gp/GROUPNAME/res1 and 541 /base/gp/GROUPNAME/res1/res2 conform to this practice. Just like 542 application group names, the path segment used as delimiter should 543 be as short as possible in constrained networks. 545 A full-fledged example is provided in Figure 3. Another example 546 of a compact CoAP request is provided in Figure 4, in which an 547 IPv6 literal address and the default CoAP port number 5683 are 548 used in the authority component. Also the resource structure is 549 different in this example. 551 Application group name: gp1 553 Group URI: coap://grp.example.org:5685/gp/gp1/light?foo=bar 555 CoAP group request 556 Header: GET (T=NON, Code=0.01, MID=0x7d41) 557 Uri-Host: grp.example.org 558 Uri-Path: gp 559 Uri-Path: gp1 560 Uri-Path: light 561 Uri-Query: foo=bar 563 Figure 3: Example of application group name in URI path 1/2 565 Application group name: gp1 567 Group URI: coap://[ff35:30:2001:db8:f1::8000:1]/g/gp1/li 569 CoAP group request 570 Header: POST (T=NON, Code=0.02, MID=0x7d41) 571 Uri-Path: g 572 Uri-Path: gp1 573 Uri-Path: li 575 Figure 4: Example of application group name in URI path 2/2 577 * URI query component - This method can use the following formats. 578 In either case, when using this method in constrained networks, an 579 application group name GROUPNAME should be as short as possible. 581 - As a first alternative, the URI query component consists of 582 only one parameter, which has no value and has the name of the 583 application group as its own idenfier. That is, the query 584 component ?GROUPNAME conforms to this format. 586 A full-fledged example is provided in Figure 5. 588 - As a second alternative, the URI query component includes a 589 query parameter as designated indicator, e.g., "gp", with value 590 the name of the application group. That is, assuming "gp" to 591 be used as designated indicator, both the query components 592 ?gp=GROUPNAME and ?par1=v1&gp=GROUPNAME conform to this format. 594 A full-fledged example is provided in Figure 6. 596 Application group name: gp1 598 Group URI: coap://grp.example.org:5685/light?gp1 600 CoAP group request 601 Header: GET (T=NON, Code=0.01, MID=0x7d41) 602 Uri-Host: grp.example.org 603 Uri-Path: light 604 Uri-Query: gp1 606 Figure 5: Example of application group name in URI query (1/2) 608 Application group name: gp1 610 Group URI: coap://grp.example.org:5685/light?foo=bar&gp=gp1 612 CoAP group request 613 Header: GET (T=NON, Code=0.01, MID=0x7d41) 614 Uri-Host: grp.example.org 615 Uri-Path: light 616 Uri-Query: foo=bar 617 Uri-Query: gp=gp1 619 Figure 6: Example of application group name in URI query (2/2) 621 * URI authority component - If this method is used, the application 622 group is identified by the authority component as a whole. 624 In particular, the application group has the same name of the CoAP 625 group expressed by the group URI (see Section 2.2.1.1). Thus, 626 this method can only be used if there is a one-to-one mapping 627 between CoAP groups and application groups (see Section 2.1.4). 629 A full-fledged example is provided in Figure 7. 631 Application group name: grp.example.org:5685 633 Group URI: coap://grp.example.org:5685/light?foo=bar 635 CoAP group request 636 Header: GET (T=NON, Code=0.01, MID=0x7d41) 637 Uri-Host: grp.example.org 638 Uri-Path: light 639 Uri-Query: foo=bar 641 Figure 7: Example of application group name in URI authority 643 * URI host subcomponent - If this method is used, the application 644 group is identified solely by the host subcomponent of the 645 authority component. 647 Since an application group can be associated with only one CoAP 648 group (see Section 2.1.4), using this method implies that any two 649 CoAP groups cannot differ only by the port subcomponent of the URI 650 authority component. 652 A full-fledged example is provided in Figure 8. 654 Application group name: grp.example.org 656 Group URI: coap://grp.example.org:5685/light?foo=bar 658 CoAP group request 659 Header: GET (T=NON, Code=0.01, MID=0x7d41) 660 Uri-Host: grp.example.org 661 Uri-Path: light 662 Uri-Query: foo=bar 664 Figure 8: Example of application group name in URI host 666 * URI port subcomponent - By using this method, the application 667 group is uniquely identified by the destination port number 668 encoded in the port subcomponent of the authority component. 670 Since an application group can be associated with only one CoAP 671 group (see Section 2.1.4), using this method implies that any two 672 CoAP groups cannot differ only by their host subcomponent of the 673 URI authority component. 675 A full-fledged example is provided in Figure 9. 677 Application group name: grp1, as inferable from port number 5685 679 Group URI: coap://grp.example.org:5685/light?foo=bar 681 CoAP group request 682 Header: GET(T=NON, Code=0.01, MID=0x7d41) 683 Uri-Host: grp.example.org 684 Uri-Path: light 685 Uri-Query: foo=bar 687 Figure 9: Example of application group name in URI port 689 Alternatively, there are also methods to encode the application group 690 name within the CoAP request, even though it is not encoded within 691 the group URI. An example of such method is summarized below. 693 * The application group name can be encoded in a new (e.g., custom, 694 application-specific) CoAP Option, which the client adds to the 695 CoAP request before sending it out. 697 Upon receiving the request as a member of the targeted CoAP group, 698 each CoAP server would, by design, understand this Option, decode 699 it and treat the result as an application group name. 701 A full-fledged example is provided in Figure 10. 703 Application group name: grp1 705 Group URI: coap://grp.example.org:5685/light?foo=bar 707 CoAP group request 708 Header: GET (T=NON, Code=0.01, MID=0x7d41) 709 Uri-Host: grp.example.org 710 Uri-Path: light 711 Uri-Query: foo=bar 712 App-Group-Name: grp1 // new (e.g., custom) CoAP option 714 Figure 10: Example of application group name in a new CoAP Option 716 Furthermore, it is possible to encode the application group name 717 neither in the group URI nor within a CoAP request, thus yielding the 718 most compact representation on the wire. In this case, each CoAP 719 server needs to determine the right application group based on 720 contextual information, such as the client identity and/or the target 721 resource. For example, each application group on a server could 722 support a unique set of resources, such that it does not overlap with 723 the set of resources of any other application group. 725 Finally, Appendix A of [I-D.ietf-core-resource-directory] provides an 726 example of application group registered to a Resource Directory (RD), 727 along with the CoAP group it uses and the resources it supports. In 728 that example, an application group name "lights" is encoded in the 729 "ep" (endpoint) attribute of the RD registration entry. At the same 730 time, the CoAP group is ff35:30:2001:db8:f1::8000:1 and the "NoSec" 731 security group is used. 733 2.2.1.3. Security Groups 735 A security group is identified by a stable and invariant string used 736 as group name. This is generally not related with other kinds of 737 group identifiers that may be specific of the used security solution. 739 The "NoSec" security group name MUST be only used to represent the 740 case of group communication without any security. This typically 741 results in CoAP messages that do not include any security group name, 742 identifier, or security-related data structures. 744 2.2.2. Group Creation and Membership 746 To create a CoAP group, a configuring entity defines an IP multicast 747 address (or hostname) for the group and optionally a UDP port number 748 in case it differs from the default CoAP port number 5683. Then, it 749 configures one or more devices as listeners to that IP multicast 750 address, with a CoAP endpoint listening on the group's associated UDP 751 port. These endpoints/devices are the group members. The 752 configuring entity can be, for example, a local application with pre- 753 configuration, a user, a software developer, a cloud service, or a 754 local commissioning tool. Also, the devices sending CoAP requests to 755 the group in the role of CoAP client need to be configured with the 756 same information, even though they are not necessarily group members. 757 One way to configure a client is to supply it with a group URI. The 758 IETF does not define a mandatory protocol to accomplish CoAP group 759 creation. [RFC7390] defined an experimental protocol for 760 configuration of group membership for unsecured group communication, 761 based on JSON-formatted configuration resources. For IPv6 CoAP 762 groups, common multicast address ranges that are used to configure 763 group addresses from are ff1x::/16 and ff3x::/16. 765 To create an application group, a configuring entity may configure a 766 resource (name) or a set of resources on CoAP endpoints, such that a 767 CoAP request sent to a group URI by a configured CoAP client will be 768 processed by one or more CoAP servers that have the matching URI path 769 configured. These servers are the members of the application group. 771 To create a security group, a configuring entity defines an initial 772 subset of the related security material. This comprises a set of 773 group properties including the cryptographic algorithms and 774 parameters used in the group, as well as additional information 775 relevant throughout the group life-cycle, such as the security group 776 name and description. This task MAY be entrusted to a dedicated 777 administrator, that interacts with a Group Manager as defined in 778 Section 5. After that, further security materials to protect group 779 communications have to be generated, compatible with the specified 780 group configuration. 782 To participate in a security group, CoAP endpoints have to be 783 configured with the group security material used to protect 784 communications in the associated application/CoAP groups. The part 785 of the process that involves secure distribution of group security 786 material MAY use standardized communication with a Group Manager as 787 defined in Section 5. For unsecure group communication using the 788 "NoSec" security group, any CoAP endpoint may become a group member 789 at any time: there is no configuring entity that needs to provide 790 security material for this group, as there is no security material 791 for it. This means that group creation and membership cannot be 792 tightly controlled for the "NoSec" group. 794 The configuration of groups and membership may be performed at 795 different moments in the life-cycle of a device; for example during 796 product (software) creation, in the factory, at a reseller, on-site 797 during first deployment, or on-site during a system reconfiguration 798 operation. 800 2.2.3. Group Discovery 802 The following describes how a CoAP endpoint can discover groups by 803 different means, i.e., by using a Resource Directory or directly from 804 the CoAP servers that are members of such groups. 806 2.2.3.1. Discovery through a Resource Directory 808 It is possible for CoAP endpoints to discover application groups as 809 well as CoAP groups, by using the RD-Groups usage pattern of the CoRE 810 Resource Directory (RD), as defined in Appendix A of 811 [I-D.ietf-core-resource-directory]. 813 In particular, an application group can be registered to the RD, 814 specifying the reference IP multicast address of its associated CoAP 815 group. The registration of groups to the RD is typically performed 816 by a Commissioning Tool. Later on, CoAP endpoints can discover the 817 registered application groups and related CoAP group(s), by using the 818 lookup interface of the RD. 820 When secure communication is provided with Group OSCORE (see 821 Section 5), the approach described in 822 [I-D.tiloca-core-oscore-discovery] also based on the RD can be used, 823 in order to discover the security group to join. 825 In particular, the responsible OSCORE Group Manager registers its 826 security groups to the RD, as links to its own corresponding 827 resources for joining the security groups 828 [I-D.ietf-ace-key-groupcomm-oscore]. Later on, CoAP endpoints can 829 discover the registered security groups and related application 830 groups, by using the lookup interface of the RD, and then join the 831 security group through the respective Group Manager. 833 2.2.3.2. Discovery from the CoAP Servers 835 It is possible for CoAP endpoints to discover application groups and 836 CoAP groups from the CoAP servers that are members of such groups, by 837 using a GET request targeting the /.well-known/core resource. 839 As shown below, such a GET request may be sent to the IP multicast 840 address of an already known CoAP group associated with one or more 841 application groups; or to the "All CoAP Nodes" multicast address, 842 thus targeting all reachable CoAP servers in any CoAP group. Also, 843 the GET request may specify a query component, in order to filter the 844 application groups of interest. 846 These particular details concerning the GET request depend on the 847 specific discovery action intended by the client and on application- 848 specific means used to encode names of application groups and CoAP 849 groups, e.g., in group URIs and/or CoRE target attributes used with 850 resource links. 852 The following provides examples of methods to discover application 853 groups and CoAP groups, building on the following assumptions. 854 First, application group names are encoded in the path component of 855 Group URIs (see Section 2.2.1.2), using the path segment "gp" as 856 designated delimiter. Second, the type of an application group is 857 encoded in the CoRE Link Format attribute "rt" of a group resource 858 with a value "g.". Third, a CoAP group is used and is 859 identified by the URI authority grp.example.org:5685. 861 * A CoAP client can discover all the application groups associated 862 with a specific CoAP group. 864 This is achieved by sending the GET request above to the IP 865 multicast address of the CoAP group, and specifying a wildcarded 866 group type "g._" as resource type in the URI query parameter "rt". 867 For example, the request can use a Group URI with path and query 868 components "/.well-known/core?rt=g._", so that the query matches 869 any application group resource type. Alternatively, the request 870 can use a Group URI with path and query components "/.well-known/ 871 core?href=/gp/*", so that the query matches any application group 872 resources and also matches any sub-resources of those. 874 Through the corresponding responses, the query result is a list of 875 resources at CoAP servers that are members of the specified CoAP 876 group and have at least one application group associated with the 877 CoAP group. That is, the client gains knowledge of: i) the set of 878 servers that are members of the specified CoAP group and member of 879 any of the associated application groups; ii) for each of those 880 servers, the name of the application groups where the server is a 881 member and that are associated with the CoAP group. 883 A full-fledged example is provided in Figure 11. 885 Each of the servers S1 and S2 is identified by the IP source 886 address of the CoAP response. If the client wishes to discover 887 resources that a particular server hosts within a particular 888 application group, it may use unicast discovery request(s) to this 889 server i.e., to its respective unicast IP address. Alternatively 890 the client may use the discovered group resource type (e.g., 891 rt=g.light) to infer which resources are present below the group 892 resource. 894 // Request to all members of the CoAP group 895 Req: GET coap://grp.example.org:5685/.well-known/core?rt=g.* 897 // Response from server S1, as member of: 898 // - The CoAP group "grp.example.org:5685" 899 // - The application group "gp1" 900 Res: 2.05 Content 901 Content-Format: 40 902 Payload: 903 ;rt=g.light 905 // Response from server S2, as member of: 906 // - The CoAP group "grp.example.org:5685" 907 // - The application groups "gp1" and "gp2" 908 Res: 2.05 Content 909 Content-Format: 40 910 Payload: 911 ;rt=g.light, 912 ;rt=g.temp 914 Figure 11: Discovery of application groups associated with a CoAP 915 group 917 * A CoAP client can discover the CoAP servers that are members of a 918 specific application group, the CoAP group associated with the 919 application group, and optionally the resources that those servers 920 host for each application group. 922 This is achieved by sending the GET request above to the "All CoAP 923 Nodes" IP multicast address (see Section 12.8 of [RFC7252]), with 924 a particular chosen scope (e.g., site-local or realm-local) if 925 IPv6 is used. Also, the request specifies the application group 926 name of interest in the URI query component, as defined in 927 Section 2.2.1.2. For example, the request can use a Group URI 928 with path and query components "/.well-known/core?href=/gp/gp1" to 929 specify the application group with name "gp1". 931 Through the corresponding responses, the query result is a list of 932 resources at CoAP servers that are members of the specified 933 application group and for each application group the associated 934 CoAP group. That is, the client gains knowledge of: i) the set of 935 servers that are members of the specified application group and of 936 the associated CoAP group; ii) for each of those servers, 937 optionally the resources it hosts within the application group. 939 A full-fledged example is provided in Figure 12. Note that the 940 servers need to respond now with an absolute URI and not a 941 relative URI like in the previous example, because the group 942 resource "gp1" is hosted at the authority indicated by the CoAP 943 group (grp.example.org:5685) and not by the authority that is 944 serving the Link Format document (which is [ff03::fd]:5683). 946 If the client wishes to discover resources that a particular 947 server hosts within a particular application group, it may use 948 unicast discovery request(s) to this server. 950 // Request to realm-local members of the application group "gp1" 951 Req: GET coap://[ff03::fd]/.well-known/core?href=/gp/gp1 953 // CoAP response from server S1, as member of: 954 // - The CoAP group "grp.example.org:5685" 955 // - The application group "gp1" 956 Res: 2.05 Content 957 Content-Format: 40 958 Payload: 959 ;rt=g.light 961 // CoAP response from server S2, as member of: 962 // - The CoAP group "grp.example.org:5685" 963 // - The application groups "gp1" 964 Res: 2.05 Content 965 Content-Format: 40 966 Payload: 967 ;rt=g.light 969 Figure 12: Discovery of members of an application group, together 970 with the associated CoAP group 972 * A CoAP client can discover the CoAP servers that are members of 973 any application group of a specific type, the CoAP group 974 associated with those application groups, and optionally the 975 resources that those servers host as members of those application 976 groups. 978 This is achieved by sending the GET request above to the "All CoAP 979 Nodes" IP multicast address (see Section 12.8 of [RFC7252]), with 980 a particular chosen scope (e.g., site-local or realm-local) if 981 IPv6 is used. Also, the request can specify the application group 982 type of interest in the URI query component as value of a query 983 parameter "rt". For example, the request can use a Group URI with 984 path and query components "/.well-known/core?rt=TypeA" to specify 985 the application group type "TypeA". 987 Through the corresponding responses, the query result is a list of 988 resources at CoAP servers that are members of any application 989 group of the specified type and of the CoAP group associated with 990 each of those application groups. That is, the client gains 991 knowledge of: i) the set of servers that are members of the 992 application groups of the specified type and of the associated 993 CoAP group; ii) optionally for each of those servers, the 994 resources it hosts within each of those application groups. 996 A full-fledged example is provided in Figure 13. 998 If the client wishes to discover resources that a particular 999 server hosts within a particular application group, it may use 1000 unicast discovery request(s) to this server. 1002 // Request to realm-local members of application groups 1003 // with group type "g.temp" 1004 Req: GET coap://[ff03::fd]/.well-known/core?rt=g.temp 1006 // Response from server S1, as member of: 1007 // - The CoAP group "grp.example.org:5685" 1008 // - The application group "gp1" of type "g.temp" 1009 Res: 2.05 Content 1010 Content-Format: 40 1011 Payload: 1012 ;rt=g.temp 1014 // Response from server S2, as member of: 1015 // - The CoAP group "grp.example.org:5685" 1016 // - The application groups "gp1" and "gp2" of type "g.temp" 1017 Res: 2.05 Content 1018 Content-Format: 40 1019 Payload: 1020 ;rt=g.temp, 1021 ;rt=g.temp 1023 Figure 13: Discovery of members of application groups of a 1024 specified type, and of the associated CoAP group 1026 * A CoAP client can discover the CoAP servers that are members of 1027 any application group configured in the 6LoWPAN wireless mesh 1028 network of the client, the CoAP group associated with each 1029 application group, and optionally the resources that those servers 1030 host as members of the application group. 1032 This is achieved by sending the GET request above with a query 1033 specifying a wildcarded group type in the URI query parameter for 1034 "rt". For example, a Group URI with path and query components 1035 "/.well-known/core?rt=g.*", so that the query matches any 1036 application group type. The request is sent to the "All CoAP 1037 Nodes" IP multicast address (see Section 12.8 of [RFC7252]), with 1038 a particular chosen scope if IPv6 is used. In this example the 1039 scope is realm-local to address all servers in the current 6LoWPAN 1040 wireless mesh network of the client. 1042 Through the corresponding responses, the query result is a list of 1043 group resources hosted by any server in the mesh network. Each 1044 group resource denotes one application group membership of a 1045 server. The CoAP group per application group is obtained as the 1046 authority of each returned link. 1048 A full-fledged example is provided in Figure 14. 1050 If the client wishes to discover resources that a particular 1051 server hosts within a particular application group, it may use 1052 unicast discovery request(s) to this server. 1054 // Request to realm-local members of any application group 1055 Req: GET coap://[ff03::fd]/.well-known/core?rt=g.* 1057 // Response from server S1, as member of: 1058 // - The CoAP groups "grp.example.org:5685" and "grp2.example.org" 1059 // - The application groups "gp1" and "gp5" 1060 Res: 2.05 Content 1061 Content-Format: 40 1062 Payload: 1063 ;rt=g.light, 1064 ;rt=g.lock 1066 // Response from server S2, as member of: 1067 // - The CoAP group "grp.example.org:5685" 1068 // - The application groups "gp1" and "gp2" 1069 Res: 2.05 Content 1070 Content-Format: 40 1071 Payload: 1072 ;rt=g.light, 1073 ;rt=g.light 1075 // Response from server S3, as member of: 1076 // - The CoAP group "grp2.example.org" 1077 // - The application group "gp5" 1078 Res: 2.05 Content 1079 Content-Format: 40 1080 Payload: 1081 ;rt=g.lock 1083 Figure 14: Discovery of the resources and members of any 1084 application group, and of the associated CoAP group 1086 Note that all the above examples are application-specific. That is, 1087 there is currently no standard way of encoding names of application 1088 groups and CoAP groups in group URIs and/or CoRE target attributes 1089 used with resource links. In particular, the discovery of groups 1090 through the RD mentioned in Section 2.2.3.1 is only defined for use 1091 with an RD, i.e., not directly with CoAP servers as group members. 1093 For example, some applications may use the "rt" attribute on a parent 1094 resource to denote support for a particular REST API to access child 1095 resources, as detailed in the example in Figure 15. In this example 1096 a custom Link Format attribute "gpt" is used to denote the group type 1097 within the scope of the application/system. An alternative, shorter 1098 encoding (not shown in the figure) is to use only the value "1" for 1099 each "gpt" attribute, to denote that the resource is of type 1100 application group. In that case information about the semantics/API 1101 of the group resource is disclosed only via the "rt" attribute as 1102 shown in the figure. 1104 // Request to realm-local members of any application group 1105 Req: GET coap://[ff03::fd]/.well-known/core?gpt=* 1107 // Response from server S1, as member of: 1108 // - The CoAP groups "grp.example.org:5685" and "grp2.example.org" 1109 // - The application groups "gp1" and "gp5" 1110 Res: 2.05 Content 1111 Content-Format: 40 1112 Payload: 1113 ;rt=oic.d.light;gpt=light, 1114 ;rt=oic.d.smartlock;gpt=lock 1116 // Response from server S2, as member of: 1117 // - The CoAP group "grp.example.org:5685" 1118 // - The application groups "gp1" and "gp2" 1119 Res: 2.05 Content 1120 Content-Format: 40 1121 Payload: 1122 ;rt=oic.d.light;gpt=light, 1123 ;rt=oic.d.light;gpt=light 1125 // Response from server S3, as member of: 1126 // - The CoAP group "grp2.example.org" 1127 // - The application group "gp5" 1128 Res: 2.05 Content 1129 Content-Format: 40 1130 Payload: 1131 ;rt=oic.d.smartlock;gpt=lock 1133 Figure 15: Example of using a custom 'gpt' link attribute to 1134 denote group type 1136 2.2.4. Group Maintenance 1138 Maintenance of a group includes any necessary operations to cope with 1139 changes in a system, such as: adding group members, removing group 1140 members, changing group security material, reconfiguration of UDP 1141 port number and/or IP multicast address, reconfiguration of the group 1142 URI, renaming of application groups, splitting of groups, or merging 1143 of groups. 1145 For unsecured group communication (see Section 4) i.e., the "NoSec" 1146 security group, addition/removal of CoAP group members is simply done 1147 by configuring these devices to start/stop listening to the group IP 1148 multicast address on the group's UDP port. 1150 For secured group communication (see Section 5), the maintenance 1151 operations of the protocol Group OSCORE 1152 [I-D.ietf-core-oscore-groupcomm] MUST be implemented. When using 1153 Group OSCORE, CoAP endpoints participating in group communication are 1154 also members of a corresponding OSCORE security group, and thus share 1155 common security material. Additional related maintenance operations 1156 are discussed in Section 5.2. 1158 3. CoAP Usage in Group Communication 1160 This section specifies the usage of CoAP in group communication, both 1161 unsecured and secured. This includes additional support for protocol 1162 extensions, such as Observe (see Section 3.7) and block-wise transfer 1163 (see Section 3.8). 1165 How CoAP group messages are carried over various transport layers is 1166 the subject of Section 3.9. Finally, Section 3.10 covers the 1167 interworking of CoAP group communication with other protocols that 1168 may operate in the same network. 1170 3.1. Request/Response Model 1172 3.1.1. General 1174 A CoAP client is an endpoint able to transmit CoAP requests and 1175 receive CoAP responses. Since the underlying UDP transport supports 1176 multiplexing by means of UDP port number, there can be multiple 1177 independent CoAP clients operational on a single host. On each UDP 1178 port, an independent CoAP client can be hosted. Each independent 1179 CoAP client sends requests that use the associated endpoint's UDP 1180 port number as the UDP source port number of the request. 1182 All CoAP requests that are sent via IP multicast MUST be Non- 1183 confirmable, see Section 8.1 of [RFC7252]. The Message ID in an IP 1184 multicast CoAP message is used for optional message deduplication by 1185 both clients and servers, as detailed in Section 4.5 of [RFC7252]. A 1186 server sends back a unicast response to a CoAP group request. The 1187 unicast responses received by the CoAP client may be a mixture of 1188 success (e.g., 2.05 Content) and failure (e.g., 4.04 Not Found) 1189 codes, depending on the individual server processing results. 1191 3.1.2. Response Suppression 1193 A server MAY suppress its response for various reasons given in 1194 Section 8.2 of [RFC7252]. This document adds the requirement that a 1195 server SHOULD suppress the response in case of error or in case there 1196 is nothing useful to respond, unless the application related to a 1197 particular resource requires such a response to be made for that 1198 resource. 1200 The CoAP No-Response Option [RFC7967] can be used by a client to 1201 influence the default response suppression on the server side. It is 1202 RECOMMENDED for a server to support this option only on selected 1203 resources where it is useful in the application context. If the 1204 option is supported on a resource, it MUST override the default 1205 response suppression of that resource. 1207 Any default response suppression by a server SHOULD be performed 1208 consistently, as follows: if a request on a resource produces a 1209 particular Response Code and this response is not suppressed, then 1210 another request on the same resource that produces a response of the 1211 same Response Code class is also not suppressed. For example, if a 1212 4.05 Method Not Allowed error response code is suppressed by default 1213 on a resource, then a 4.15 Unsupported Content-Format error response 1214 code is also suppressed by default for that resource. 1216 3.1.3. Repeating a Request 1218 A CoAP client MAY repeat a group request using the same Token value 1219 and same Message ID value, in order to ensure that enough (or all) 1220 group members have been reached with the request. This is useful in 1221 case a number of group members did not respond to the initial request 1222 and the client suspects that the request did not reach these group 1223 members. However, in case one or more servers did receive the 1224 initial request but the response to that request was lost, this 1225 repeat does not help to retrieve the lost response(s) if the 1226 server(s) implement the optional Message ID based deduplication 1227 (Section 4.5 of [RFC7252]). 1229 A CoAP client MAY repeat a group request using the same Token value 1230 and a different Message ID, in which case all servers that received 1231 the initial request will again process the repeated request since it 1232 appears within a new CoAP message. This is useful in case a client 1233 suspects that one or more response(s) to its original request were 1234 lost and the client needs to collect more, or even all, responses 1235 from group members, even if this comes at the cost of the overhead of 1236 certain group members responding twice (once to the original request, 1237 and once to the repeated request with different Message ID). 1239 3.1.4. Request/Response Matching and Distinguishing Responses 1241 A CoAP client can distinguish the origin of multiple server responses 1242 by the source IP address of the message containing the CoAP response 1243 and/or any other available application-specific source identifiers 1244 contained in the CoAP response payload or CoAP response options, such 1245 as an application-level unique ID associated with the server. If 1246 secure communication is provided with Group OSCORE (see Section 5), 1247 additional security-related identifiers in the CoAP response enable 1248 the client to retrieve the right security material for decrypting 1249 each response and authenticating its source. 1251 While processing a response on the client, the source endpoint of the 1252 response is not matched to the destination endpoint of the request, 1253 since for a group request these will never match. This is specified 1254 in Section 8.2 of [RFC7252], with reference to IP multicast. 1256 Also, when UDP transport is used, this implies that a server MAY 1257 respond from a UDP port number that differs from the destination UDP 1258 port number of the request, although a CoAP server normally SHOULD 1259 respond from the UDP port number that equals the destination port 1260 number of the request -- following the convention for UDP-based 1261 protocols. 1263 In case a single client has sent multiple group requests and 1264 concurrent CoAP transactions are ongoing, the responses received by 1265 that client are matched to an active request using only the Token 1266 value. Due to UDP level multiplexing, the UDP destination port 1267 number of the response MUST match to the client endpoint's UDP port 1268 number, i.e., to the UDP source port number of the client's request. 1270 3.1.5. Token Reuse 1272 For CoAP group requests, there are additional constraints on the 1273 reuse of Token values at the client, compared to the unicast case 1274 defined in [RFC7252] and updated by [RFC9175]. Since for CoAP group 1275 requests the number of responses is not bound a priori, the client 1276 cannot use the reception of a response as a trigger to "free up" a 1277 Token value for reuse. 1279 Reusing a Token value too early could lead to incorrect response/ 1280 request matching on the client, and would be a protocol error. 1281 Therefore, the time between reuse of Token values for different group 1282 requests MUST be greater than: 1284 MIN_TOKEN_REUSE_TIME = (NON_LIFETIME + MAX_LATENCY + 1285 MAX_SERVER_RESPONSE_DELAY) 1287 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 1288 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 1289 was done in [RFC7390], that is: the expected maximum response delay 1290 over all servers that the client can send a CoAP group request to. 1291 This delay includes the maximum Leisure time period as defined in 1292 Section 8.2 of [RFC7252]. However, CoAP does not define a time limit 1293 for the server response delay. Using the default CoAP parameters, 1294 the Token reuse time MUST be greater than 250 seconds plus 1295 MAX_SERVER_RESPONSE_DELAY. 1297 A preferred solution to meet this requirement is to generate a new 1298 unique Token for every new group request, such that a Token value is 1299 never reused. If a client has to reuse Token values for some reason, 1300 and also MAX_SERVER_RESPONSE_DELAY is unknown, then using 1301 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 1302 The time between Token reuses is in that case set to a value greater 1303 than MIN_TOKEN_REUSE_TIME = 500 seconds. 1305 When securing CoAP group communication with Group OSCORE 1306 [I-D.ietf-core-oscore-groupcomm], secure binding between requests and 1307 responses is ensured (see Section 5). Thus, a client may reuse a 1308 Token value after it has been freed up, as discussed above and 1309 considering a reuse time greater than MIN_TOKEN_REUSE_TIME. If an 1310 alternative security protocol for CoAP group communication is used 1311 which does not ensure secure binding between requests and responses, 1312 a client MUST follow the Token processing requirements as defined in 1313 [RFC9175]. 1315 Another method to more easily meet the above constraint is to 1316 instantiate multiple CoAP clients at multiple UDP ports on the same 1317 host. The Token values only have to be unique within the context of 1318 a single CoAP client, so using multiple clients can make it easier to 1319 meet the constraint. 1321 3.1.6. Client Handling of Multiple Responses With Same Token 1323 Since a client sending a group request with a Token T will accept 1324 multiple responses with the same Token T, it is possible in 1325 particular that the same server sends multiple responses with the 1326 same Token T back to the client. For example, this server might not 1327 implement the optional CoAP message deduplication based on Message 1328 ID; or it might be acting out of specification as a malicious, 1329 compromised or faulty server. 1331 When this happens, the client normally processes at the CoAP layer 1332 each of those responses to the same request coming from the same 1333 server. If the processing of a response is successful, the client 1334 delivers this response to the application as usual. 1336 Then, the application is in a better position to decide what to do, 1337 depending on the available context information. For instance, it 1338 might accept and process all the responses from the same server, even 1339 if they are not Observe notifications (i.e., they do not include an 1340 Observe option). Alternatively, the application might accept and 1341 process only one of those responses, such as the most recent one from 1342 that server, e.g., when this can trigger a change of state within the 1343 application. 1345 3.2. Caching 1347 CoAP endpoints that are members of a CoAP group MAY cache responses 1348 to a group request as defined in Section 5.6 of [RFC7252]. In 1349 particular, these same rules apply to determine the set of request 1350 options used as "Cache-Key". 1352 Furthermore, building on what is defined in Section 8.2.1 of 1353 [RFC7252]: 1355 * A client sending a GET or FETCH group request MAY update a cache 1356 with the responses from the servers in the CoAP group. Then, the 1357 client uses both cached-still-fresh and new responses as the 1358 result of the group request. 1360 * A client sending a GET or FETCH group request MAY use a response 1361 received from a server, to satisfy a subsequent sent request 1362 intended to that server on the related unicast request URI. In 1363 particular, the unicast request URI is obtained by replacing the 1364 authority component of the request URI with the transport-layer 1365 source address of the cached response message. 1367 * A client MAY revalidate a cached response by making a GET or FETCH 1368 request on the related unicast request URI. 1370 Note that, in the presence of proxies, doing any of the above 1371 (optional) unicast requests requires the client to distinguish the 1372 different responses to a group request, as well as to distinguish the 1373 different origin servers that responded. This in turn requires 1374 additional means to provide the client with information about the 1375 origin server of each response, e.g., using the forward-proxying 1376 method defines in [I-D.tiloca-core-groupcomm-proxy]. 1378 The following subsections define the freshness model and validation 1379 model to use for cached responses, which update the models defined in 1380 Sections 5.6.1 and 5.6.2 of [RFC7252], respectively. 1382 3.2.1. Freshness Model 1384 For caching of group communication responses at client endpoints, the 1385 same freshness model relying on the Max-Age Option as defined in 1386 Section 5.6.1 of [RFC7252] applies, and the multicast caching rules 1387 of Section 8.2.1 of [RFC7252] apply except for the one discussed 1388 below. 1390 In Section 8.2.1 of [RFC7252] it is stated that, regardless of the 1391 presence of cached responses to the group request, the client 1392 endpoint will always send out a new group request onto the network 1393 because new group members may have joined the group since the last 1394 group request to the same group/resource. That is, a request is 1395 never served from cached responses only. This document updates 1396 [RFC7252] by adding the following exception case, where a client 1397 endpoint MAY serve a request by using cached responses only, and not 1398 send out a new group request onto the network: 1400 * The client knows all current CoAP server group members; and, for 1401 each group member, the client's cache currently stores a fresh 1402 response. 1404 How the client in the case above determines the current CoAP server 1405 group members is out of scope for this document. It may be, for 1406 example, via a group manager server, or by observing group join 1407 requests, or observing IGMP/MLD multicast group join messages, etc. 1409 For caching at proxies, the freshness model defined in 1410 [I-D.tiloca-core-groupcomm-proxy] can be used. 1412 3.2.2. Validation Model 1414 For validation of cached group communication responses at client 1415 endpoints, the multicast validation rules in Section 8.2.1 of 1416 [RFC7252] apply, except for the last paragraph which states "A GET 1417 request to a multicast group MUST NOT contain an ETag option". This 1418 document updates [RFC7252] by allowing a group request to contain 1419 ETag Options as specified below. 1421 For validation at proxies, the validation model defined in 1422 [I-D.tiloca-core-groupcomm-proxy] can be used. 1424 3.2.2.1. ETag Option in a Group Request/Response 1426 A client endpoint MAY include one or more ETag Options in a GET or 1427 FETCH group request to validate one or more stored responses it has 1428 cached. In case two or more servers in the group have responded to a 1429 previous request to the same resource with an identical ETag value, 1430 it is the responsibility of the client to handle this case. In 1431 particular, if the client wishes to validate, using a group request, 1432 a response from server 1 with an ETag value N, while it does not wish 1433 to validate a response from server 2 with the same ETag value N, 1434 there is no way to achieve this. In such cases of identical ETag 1435 values returned by two or more servers, the client, by default, 1436 SHOULD NOT include an ETag Option in a group request containing that 1437 ETag value. 1439 A server endpoint MUST process an ETag Option in a GET or FETCH group 1440 request in the same way it processes an ETag Option for a unicast 1441 request. A server endpoint that includes an ETag Option in a 1442 response to a group request SHOULD construct the ETag Option value in 1443 such a way that the value will be unique to this particular server 1444 with a high probability. This can be done, for example, by embedding 1445 a compact ID of the server within the ETag value, where the ID is 1446 unique (or unique with a high probability) in the scope of the group. 1448 Note: a legacy CoAP server might treat an ETag Option in a group 1449 request as an unrecognized option per Sections 5.4 and 8.2.1 of 1450 [RFC7252], causing it to ignore this (elective) ETag Option 1451 regardless of its value, and process the request normally as if that 1452 ETag Option was not included. 1454 3.3. URI Path Selection 1456 The URI Path used in a group request is preferably a path that is 1457 known to be supported across all group members. However there are 1458 valid use cases where a group request is known to be successful only 1459 for a subset of the CoAP group, for example only members of a 1460 specific application group, while those group members for which the 1461 request is unsuccessful (for example because they are outside the 1462 application group) either ignore the group request or respond with an 1463 error status code. 1465 3.4. Port Selection for UDP Transport 1467 A server that is a member of a CoAP group listens for CoAP request 1468 messages on the group's IP multicast address, usually on the CoAP 1469 default UDP port number 5683, or another non-default UDP port number 1470 if configured. Regardless of the method for selecting the port 1471 number, the same port number MUST be used across all CoAP servers 1472 that are members of a CoAP group and across all CoAP clients sending 1473 group requests to that group. 1475 One way to create multiple CoAP groups is using different UDP ports 1476 with the same IP multicast address, in case the devices' network 1477 stack only supports a limited number of multicast address 1478 subscriptions. However, it must be taken into account that this 1479 incurs additional processing overhead on each CoAP server 1480 participating in at least one of these groups: messages to groups 1481 that are not of interest to the node are only discarded at the higher 1482 transport (UDP) layer instead of directly at the network (IP) layer. 1483 Also, a constrained network may be additionally burdened in this case 1484 with multicast traffic that is eventually discarded at the UDP layer 1485 by most nodes. 1487 The port number 5684 is reserved for DTLS-secured unicast CoAP and 1488 MUST NOT be used for any CoAP group communication. 1490 For a CoAP server node that supports resource discovery as defined in 1491 Section 2.4 of [RFC7252], the default port number 5683 MUST be 1492 supported (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" 1493 multicast group as detailed in Section 3.9. 1495 3.5. Proxy Operation 1497 This section defines how proxies operate in a group communication 1498 scenario. In particular, Section 3.5.1 defines operations of 1499 forward-proxies, while Section 3.5.2 defines operations of reverse- 1500 proxies. Security operations for a proxy are discussed later in 1501 Section 5.3. 1503 3.5.1. Forward-Proxies 1505 CoAP enables a client to request a forward-proxy to process a CoAP 1506 request on its behalf, as described in Sections 5.7.2 and 8.2.2 of 1507 [RFC7252]. 1509 When intending to reach a CoAP group through a proxy, the client 1510 sends a unicast CoAP group request to the proxy. This request 1511 specifies the group URI where the request has to be forwarded to, 1512 either as a string in the Proxy-URI Option, or through the Proxy- 1513 Scheme Option with the group URI constructed from the usual Uri-* 1514 Options. Then, the forward-proxy resolves the group URI to a 1515 destination CoAP group, i.e., it sends (e.g., multicasts) the CoAP 1516 group request to the group URI, receives the responses and forwards 1517 all the individual (unicast) responses back to the client. 1519 However, there are certain issues and limitations with this approach: 1521 * The CoAP client component that has sent the unicast CoAP group 1522 request to the proxy may be expecting only one (unicast) response, 1523 as usual for a CoAP unicast request. Instead, it receives 1524 multiple (unicast) responses, potentially leading to fault 1525 conditions in the component or to discarding any received 1526 responses following the first one. This issue may occur even if 1527 the application calling the CoAP client component is aware that 1528 the forward-proxy is going to forward the CoAP group request to 1529 the group URI. 1531 * Each individual CoAP response received by the client will appear 1532 to originate (based on its IP source address) from the CoAP Proxy, 1533 and not from the server that produced the response. This makes it 1534 impossible for the client to identify the server that produced 1535 each response, unless the server identity is contained as a part 1536 of the response payload or inside a CoAP option in the response. 1538 * The proxy does not necessarily know how many members there are in 1539 the CoAP group or how many group members will actually respond. 1540 Also, the proxy does not know for how long to collect responses 1541 before it stops forwarding them to the client. A CoAP client that 1542 is not using a Proxy might face the same problems in collecting 1543 responses to a group request. However, the client itself would 1544 typically have application-specific rules or knowledge on how to 1545 handle this situation, while an application-agnostic CoAP Proxy 1546 would typically not have this knowledge. For example, a CoAP 1547 client could monitor incoming responses and use this information 1548 to decide how long to continue collecting responses - which is 1549 something a proxy cannot do. 1551 A forward-proxying method using this approach and addressing the 1552 issues raised above is defined in [I-D.tiloca-core-groupcomm-proxy]. 1554 An alternative solution is for the proxy to collect all the 1555 individual (unicast) responses to a CoAP group request and then send 1556 back only a single (aggregated) response to the client. However, 1557 this solution brings up new issues: 1559 * Like for the approach discussed above, the proxy does not know for 1560 how long to collect responses before sending back the aggregated 1561 response to the client. Analogous considerations apply to this 1562 approach too, both on the client and proxy side. 1564 * There is no default format defined in CoAP for aggregation of 1565 multiple responses into a single response. Such a format could be 1566 standardized based on, for example, the multipart content-format 1567 [RFC8710]. 1569 Due to the above issues, it is RECOMMENDED that a CoAP Proxy 1570 processes a request to be forwarded to a group URI only if it is 1571 explicitly enabled to do so. If such functionality is not explicitly 1572 enabled, the default response returned to the client is 5.01 Not 1573 Implemented. Furthermore, a proxy SHOULD be explicitly configured 1574 (e.g., by allow-listing and/or client authentication) to allow 1575 proxied CoAP group requests only from specific client(s). 1577 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 1578 specified in Sections 8.4 and 10.1 of [RFC8075]. In this case, the 1579 "application/http" media type is used to let the proxy return 1580 multiple CoAP responses -- each translated to a HTTP response -- back 1581 to the HTTP client. Of course, in this case the HTTP client sending 1582 a group URI to the proxy needs to be aware that it is going to 1583 receive this format, and needs to be able to decode it into the 1584 responses of multiple CoAP servers. Also, the IP source address of 1585 each CoAP response cannot be determined anymore from the 1586 "application/http" response. The HTTP client still identify the CoAP 1587 servers by other means such as application-specific information in 1588 the response payload. 1590 3.5.2. Reverse-Proxies 1592 CoAP enables the use of a reverse-proxy, as an endpoint that stands 1593 in for one or more other server(s), and satisfies requests on behalf 1594 of these, doing any necessary translations (see Section 5.7.3 of 1595 [RFC7252]). 1597 In a group communication scenario, a reverse-proxy can rely on its 1598 configuration and/or on information in a request from a client, in 1599 order to determine that a group request has to be sent to a group of 1600 servers over a one-to-many transport such as IP/UDP multicast. 1602 For example, specific resources on the reverse-proxy could be 1603 allocated, each to a specific application group and/or CoAP group. 1604 Or alternatively, the application group and/or CoAP group in question 1605 could be encoded as URI path segments. The URI path encodings for a 1606 reverse-proxy may also use a URI mapping template as described in 1607 Section 5.4 of [RFC8075]. 1609 Furthermore, the reverse-proxy can actually stand in for (and thus 1610 prevent to directly reach) only the whole set of servers in the 1611 group, or also for each of those individual servers (e.g., if acting 1612 as firewall). 1614 For a reverse-proxy that sends a request to a group of servers, the 1615 considerations as defined in Section 5.7.3 of [RFC7252] hold, with 1616 the following additions: 1618 * The three issues and limitations defined in Section 3.5.1 for a 1619 forward proxy apply to a reverse-proxy as well, and have to be 1620 addressed, e.g., using the signaling method defined in 1621 [I-D.tiloca-core-groupcomm-proxy] or other means. 1623 * A reverse-proxy MAY have preconfigured time duration(s) that are 1624 used for the collecting of server responses and forwarding these 1625 back to the client. These duration(s) may be set as global 1626 configuration or resource-specific configurations. If there is 1627 such preconfiguration, then an explicit signaling of the time 1628 period in the client's request as defined in 1629 [I-D.tiloca-core-groupcomm-proxy] is not necessarily needed. 1631 * A client that is configured to access a reverse-proxy resource 1632 (i.e., one that triggers a CoAP group communication request) 1633 SHOULD be configured also to handle potentially multiple responses 1634 with the same Token value caused by a single request. 1636 That is, the client needs to preserve the Token value used for the 1637 request also after the reception of the first response forwarded 1638 back by the proxy (see Section 3.1.6) and keep the request open to 1639 potential further responses with this Token. This requirement can 1640 be met by a combination of client implementation and proper 1641 proxied group communication configuration on the client. 1643 * A client might re-use a Token value in a valid new request to the 1644 reverse-proxy, while the reverse-proxy still has an ongoing group 1645 communication request for this client with the same Token value 1646 (i.e., its time period for response collection has not ended yet). 1648 If this happens, the reverse-proxy MUST stop the ongoing request 1649 and associated response forwarding, it MUST NOT forward the new 1650 request to the group of servers, and it MUST send a 4.00 Bad 1651 Request error response to the client. The diagnostic payload of 1652 the error response SHOULD indicate to the client that the resource 1653 is a reverse-proxy resource, and that for this reason immediate 1654 Token re-use is not possible. 1656 If the reverse-proxy supports the signalling protocol of 1657 [I-D.tiloca-core-groupcomm-proxy] it can include a Multicast- 1658 Signaling Option in the error response to convey the reason for 1659 the error in a machine-readable way. 1661 For the operation of HTTP-to-CoAP reverse proxies, see the last 1662 paragraph of Section 3.5.1 which applies also to the case of reverse- 1663 proxies. 1665 3.6. Congestion Control 1667 CoAP group requests may result in a multitude of responses from 1668 different nodes, potentially causing congestion. Therefore, both the 1669 sending of CoAP group requests and the sending of the unicast CoAP 1670 responses to these group requests should be conservatively 1671 controlled. 1673 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 1674 the following measures: 1676 * A server may choose not to respond to an IP multicast request if 1677 there is nothing useful to respond to, e.g., error or empty 1678 response (see Section 8.2 of [RFC7252]). 1680 * A server should limit the support for IP multicast requests to 1681 specific resources where multicast operation is required 1682 (Section 11.3 of [RFC7252]). 1684 * An IP multicast request MUST be Non-confirmable (Section 8.1 of 1685 [RFC7252]). 1687 * A response to an IP multicast request SHOULD be Non-confirmable 1688 (Section 5.2.3 of [RFC7252]). 1690 * A server does not respond immediately to an IP multicast request 1691 and should first wait for a time that is randomly picked within a 1692 predetermined time interval called the Leisure (Section 8.2 of 1693 [RFC7252]). 1695 This document also defines these measures to be applicable to 1696 alternative transports (other than IP multicast), if not defined 1697 otherwise. Additional guidelines to reduce congestion risks defined 1698 in this document are as follows: 1700 * A server in a constrained network SHOULD only support group 1701 requests for resources that have a small representation (where the 1702 representation may be retrieved via a GET, FETCH or POST method in 1703 the request). For example, "small" can be defined as a response 1704 payload limited to approximately 5% of the IP Maximum Transmit 1705 Unit (MTU) size, so that it fits into a single link-layer frame in 1706 case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, 1707 see Section 3.9.3) is used on the constrained network. 1709 * A server SHOULD minimize the payload size of a response to a group 1710 GET or FETCH request on "/.well-known/core" by using hierarchy in 1711 arranging link descriptions for the response. An example of this 1712 is given in Section 5 of [RFC6690]. 1714 * A server MAY minimize the payload size of a response to a group 1715 GET or FETCH request (e.g., on "/.well-known/core") by using CoAP 1716 block-wise transfers [RFC7959] in case the payload is long, 1717 returning only a first block of the CoRE Link Format description. 1718 For this reason, a CoAP client sending a CoAP group request to 1719 "/.well-known/core" SHOULD support block-wise transfers. See also 1720 Section 3.8. 1722 * A client SHOULD be configured to use CoAP groups with the smallest 1723 possible IP multicast scope that fulfills the application needs. 1724 As an example, site-local scope is always preferred over global 1725 scope IP multicast if this fulfills the application needs. 1726 Similarly, realm-local scope is always preferred over site-local 1727 scope if this fulfills the application needs. 1729 3.7. Observing Resources 1731 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 1732 that allows a CoAP client to retrieve a representation of a resource 1733 and automatically keep this representation up-to-date over a longer 1734 period of time. The client gets notified when the representation has 1735 changed. [RFC7641] does not mention whether the Observe Option can 1736 be combined with CoAP (multicast) group communication. 1738 This section updates [RFC7641] with the use of the Observe Option in 1739 a CoAP GET group request, and defines normative behavior for both 1740 client and server. Consistent with Section 2.4 of [RFC8132], it is 1741 also possible to use the Observe Option in a CoAP FETCH group 1742 request. 1744 Multicast Observe is a useful way to start observing a particular 1745 resource on all members of a CoAP group at the same time. Group 1746 members that do not have this particular resource or do not allow the 1747 GET or FETCH method on it will either respond with an error status -- 1748 4.04 Not Found or 4.05 Method Not Allowed, respectively -- or will 1749 silently suppress the response following the rules of Section 3.1.2, 1750 depending on server-specific configuration. 1752 A client that sends a group GET or FETCH request with the Observe 1753 Option MAY repeat this request using the same Token value and the 1754 same Observe Option value, in order to ensure that enough (or all) 1755 members of the CoAP group have been reached with the request. This 1756 is useful in case a number of group members did not respond to the 1757 initial request. The client MAY additionally use the same Message ID 1758 in the repeated request to avoid that group members that had already 1759 received the initial request would respond again. Note that using 1760 the same Message ID in a repeated request will not be helpful in case 1761 of loss of a response message, since the server that responded 1762 already will consider the repeated request as a duplicate message. 1763 On the other hand, if the client uses a different, fresh Message ID 1764 in the repeated request, then all the group members that receive this 1765 new message will typically respond again, which increases the network 1766 load. 1768 A client that has sent a group GET or FETCH request with the Observe 1769 Option MAY follow up by sending a new unicast CON request with the 1770 same Token value and same Observe Option value to a particular 1771 server, in order to ensure that the particular server receives the 1772 request. This is useful in case a specific group member, that was 1773 expected to respond to the initial group request, did not respond to 1774 the initial request. In this case, the client MUST use a Message ID 1775 that differs from the initial group request message. 1777 Furthermore, consistent with Section 3.3.1 of [RFC7641] and following 1778 its guidelines, a client MAY at any time send a new group/multicast 1779 GET or FETCH request with the same Token value and same Observe 1780 Option value as the original request. This allows the client to 1781 verify that it has an up-to-date representation of an observed 1782 resource and/or to re-register its interest to observe a resource. 1784 In the above client behaviors, the Token value is kept identical to 1785 the initial request to avoid that a client is included in more than 1786 one entry in the list of observers (Section 4.1 of [RFC7641]). 1788 Before repeating a request as specified above, the client SHOULD wait 1789 for at least the expected round-trip time plus the Leisure time 1790 period defined in Section 8.2 of [RFC7252], to give the server time 1791 to respond. 1793 A server that receives a GET or FETCH request with the Observe 1794 Option, for which request processing is successful, SHOULD respond to 1795 this request and not suppress the response. If a server adds a 1796 client (as a new entry) to the list of observers for a resource due 1797 to an Observe request, the server SHOULD respond to this request and 1798 SHOULD NOT suppress the response. An exception to the above is the 1799 overriding of response suppression according to a CoAP No-Response 1800 Option [RFC7967] specified by the client in the GET or FETCH request 1801 (see Section 3.1.2). 1803 A server SHOULD have a mechanism to verify liveness of its observing 1804 clients and the continued interest of these clients in receiving the 1805 observe notifications. This can be implemented by sending 1806 notifications occasionally using a Confirmable message (see 1807 Section 4.5 of [RFC7641] for details). This requirement overrides 1808 the regular behavior of sending Non-confirmable notifications in 1809 response to a Non-confirmable request. 1811 A client can use the unicast cancellation methods of Section 3.6 of 1812 [RFC7641] and stop the ongoing observation of a particular resource 1813 on members of a CoAP group. This can be used to remove specific 1814 observed servers, or even all servers in the group (using serial 1815 unicast to each known group member). In addition, a client MAY 1816 explicitly deregister from all those servers at once, by sending a 1817 group/multicast GET or FETCH request that includes the Token value of 1818 the observation to be cancelled and includes an Observe Option with 1819 the value set to 1 (deregister). In case not all the servers in the 1820 CoAP group received this deregistration request, either the unicast 1821 cancellation methods can be used at a later point in time or the 1822 group/multicast deregistration request MAY be repeated upon receiving 1823 another observe response from a server. 1825 For observing a group of servers through a CoAP-to-CoAP proxy, the 1826 limitations stated in Section 3.5 apply. The method defined in 1827 [I-D.tiloca-core-groupcomm-proxy] enables group communication 1828 including resource observation through proxies and addresses those 1829 limitations. 1831 3.8. Block-Wise Transfer 1833 Section 2.8 of [RFC7959] specifies how a client can use block-wise 1834 transfer (Block2 Option) in a multicast GET request to limit the size 1835 of the initial response of each server. Consistent with Section 2.5 1836 of [RFC8132], the same can be done with a multicast FETCH request. 1838 The client has to use unicast for any further request, separately 1839 addressing each different server, in order to retrieve more blocks of 1840 the resource from that server, if any. Also, a server (member of a 1841 targeted CoAP group) that needs to respond to a group request with a 1842 particularly large resource can use block-wise transfer (Block2 1843 Option) at its own initiative, to limit the size of the initial 1844 response. Again, a client would have to use unicast for any further 1845 requests to retrieve more blocks of the resource. 1847 A solution for group/multicast block-wise transfer using the Block1 1848 Option is not specified in [RFC7959] nor in the present document. 1849 Such a solution would be useful for group FETCH/PUT/POST/PATCH/iPATCH 1850 requests, to efficiently distribute a large request payload as 1851 multiple blocks to all members of a CoAP group. Multicast usage of 1852 Block1 is non-trivial due to potential message loss (leading to 1853 missing blocks or missing confirmations), and potential diverging 1854 block size preferences of different members of the CoAP group. 1856 [I-D.ietf-core-new-block] specifies an alternative method for CoAP 1857 block-wise transfer. It specifies that "servers MUST ignore 1858 multicast requests that contain the Q-Block2 Option". 1860 3.9. Transport Protocols 1862 In this document UDP, both over IPv4 and IPv6, is considered as the 1863 default transport protocol for CoAP group communication. 1865 3.9.1. UDP/IPv6 Multicast Transport 1867 CoAP group communication can use UDP over IPv6 as a transport 1868 protocol, provided that IPv6 multicast is enabled. IPv6 multicast 1869 MAY be supported in a network only for a limited scope. For example, 1870 Section 3.10.2 describes the potential limited support of RPL for 1871 multicast, depending on how the protocol is configured. 1873 For a CoAP server node that supports resource discovery as defined in 1874 Section 2.4 of [RFC7252], the default port number 5683 MUST be 1875 supported as per Sections 7.1 and 12.8 of [RFC7252] for the "All CoAP 1876 Nodes" multicast group. An IPv6 CoAP server SHOULD support the "All 1877 CoAP Nodes" groups with at least link-local (2), admin-local (4) and 1878 site-local (5) scopes. An IPv6 CoAP server on a 6LoWPAN node (see 1879 Section 3.9.3) SHOULD also support the realm-local (3) scope. 1881 Note that a client sending an IPv6 multicast CoAP message to a port 1882 number that is not supported by the server will not receive an ICMPv6 1883 Port Unreachable error message from that server, because the server 1884 does not send it in this case, per Section 2.4 of [RFC4443]. 1886 3.9.2. UDP/IPv4 Multicast Transport 1888 CoAP group communication can use UDP over IPv4 as a transport 1889 protocol, provided that IPv4 multicast is enabled. For a CoAP server 1890 node that supports resource discovery as defined in Section 2.4 of 1891 [RFC7252], the default port number 5683 MUST be supported as per 1892 Sections 7.1 and 12.8 of [RFC7252], for the "All CoAP Nodes" IPv4 1893 multicast group. 1895 Note that a client sending an IPv4 multicast CoAP message to a port 1896 number that is not supported by the server will not receive an ICMP 1897 Port Unreachable error message from that server, because the server 1898 does not send it in this case, per Section 3.2.2 of [RFC1122]. 1900 3.9.3. 6LoWPAN 1902 In 6LoWPAN [RFC4944] [RFC6282] networks, IPv6 packets (up to 1280 1903 bytes) may be fragmented into smaller IEEE 802.15.4 MAC frames (up to 1904 127 bytes), if the packet size requires this. Every 6LoWPAN IPv6 1905 router that receives a multi-fragment packet reassembles the packet 1906 and refragments it upon transmission. Since the loss of a single 1907 fragment implies the loss of the entire IPv6 packet, the performance 1908 in terms of packet loss and throughput of multi-fragment multicast 1909 IPv6 packets is typically far worse than the performance of single- 1910 fragment IPv6 multicast packets. For this reason, a CoAP request 1911 sent over multicast in 6LoWPAN networks SHOULD be sized in such a way 1912 that it fits in a single IEEE 802.15.4 MAC frame, if possible. 1914 On 6LoWPAN networks, multicast groups can be defined with realm-local 1915 scope [RFC7346]. Such a realm-local group is restricted to the local 1916 6LoWPAN network/subnet. In other words, a multicast request to that 1917 group does not propagate beyond the 6LoWPAN network segment where the 1918 request originated. For example, a multicast discovery request can 1919 be sent to the realm-local "All CoAP Nodes" IPv6 multicast group (see 1920 Section 3.9.1) in order to discover only CoAP servers on the local 1921 6LoWPAN network. 1923 3.9.4. Other Transports 1925 CoAP group communication may be used over transports other than UDP/ 1926 IP multicast. For example broadcast, non-UDP multicast, geocast, 1927 serial unicast, etc. In such cases the particular considerations for 1928 UDP/IP multicast in this document may need to be applied to that 1929 particular transport. 1931 Because it supports unicast only, [RFC8323] (CoAP over TCP, TLS, and 1932 WebSockets) is not in scope as a transport for CoAP group 1933 communication. 1935 3.10. Interworking with Other Protocols 1937 3.10.1. MLD/MLDv2/IGMP/IGMPv3 1939 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 1940 unaware of the specific IP multicast routing/forwarding protocol 1941 being used in their network. When such a host needs to join a 1942 specific (CoAP) multicast group, it requires a way to signal to IP 1943 multicast routers which IP multicast address(es) it needs to listen 1944 to. 1946 The MLDv2 protocol [RFC3810] is the standard IPv6 method to achieve 1947 this; therefore, this method SHOULD be used by members of a CoAP 1948 group to subscribe to its multicast IPv6 address, on IPv6 networks 1949 that support it. CoAP server nodes then act in the role of MLD 1950 Multicast Address Listener. MLDv2 uses link-local communication 1951 between Listeners and IP multicast routers. Constrained IPv6 1952 networks that implement either RPL (see Section 3.10.2) or MPL (see 1953 Section 3.10.3) typically do not support MLDv2 as they have their own 1954 mechanisms defined for subscribing to multicast groups. 1956 The IGMPv3 protocol [RFC3376] is the standard IPv4 method to signal 1957 multicast group subscriptions. This SHOULD be used by members of a 1958 CoAP group to subscribe to its multicast IPv4 address on IPv4 1959 networks. 1961 The guidelines from [RFC6636] on the tuning of MLD for mobile and 1962 wireless networks may be useful when implementing MLD in constrained 1963 networks. 1965 3.10.2. RPL 1967 RPL [RFC6550] is an IPv6 based routing protocol suitable for low- 1968 power, lossy networks (LLNs). In such a context, CoAP is often used 1969 as an application protocol. 1971 If only RPL is used in a network for routing and its optional 1972 multicast support is disabled, there will be no IP multicast routing 1973 available. Any IPv6 multicast packets in this case will not 1974 propagate beyond a single hop (to direct neighbors in the LLN). This 1975 implies that any CoAP group request will be delivered to link-local 1976 nodes only, for any scope value >= 2 used in the IPv6 destination 1977 address. 1979 RPL supports (see Section 12 of [RFC6550]) advertisement of IP 1980 multicast destinations using Destination Advertisement Object (DAO) 1981 messages and subsequent routing of multicast IPv6 packets based on 1982 this. It requires the RPL mode of operation to be 3 (Storing mode 1983 with multicast support). 1985 In this mode, RPL DAO can be used by a CoAP node that is either an 1986 RPL router or RPL Leaf Node, to advertise its CoAP group membership 1987 to parent RPL routers. Then, RPL will route any IP multicast CoAP 1988 requests over multiple hops to those CoAP servers that are group 1989 members. 1991 The same DAO mechanism can be used to convey CoAP group membership 1992 information to an edge router (e.g., 6LBR), in case the edge router 1993 is also the root of the RPL Destination-Oriented Directed Acyclic 1994 Graph (DODAG). This is useful because the edge router then learns 1995 which IP multicast traffic it needs to pass through from the backbone 1996 network into the LLN subnet, and which traffic not. In LLNs, such 1997 ingress filtering helps to avoid congestion of the resource- 1998 constrained network segment, due to IP multicast traffic from the 1999 high-speed backbone IP network. 2001 3.10.3. MPL 2003 The Multicast Protocol for Low-Power and Lossy Networks (MPL) 2004 [RFC7731] can be used for propagation of IPv6 multicast packets 2005 throughout a defined network domain, over multiple hops. MPL is 2006 designed to work in LLNs and can operate alone or in combination with 2007 RPL. The protocol involves a predefined group of MPL Forwarders to 2008 collectively distribute IPv6 multicast packets throughout their MPL 2009 Domain. An MPL Forwarder may be associated with multiple MPL Domains 2010 at the same time. Non-Forwarders will receive IPv6 multicast packets 2011 from one or more of their neighboring Forwarders. Therefore, MPL can 2012 be used to propagate a CoAP multicast group request to all group 2013 members. 2015 However, a CoAP multicast request to a group that originated outside 2016 of the MPL Domain will not be propagated by MPL - unless an MPL 2017 Forwarder is explicitly configured as an ingress point that 2018 introduces external multicast packets into the MPL Domain. Such an 2019 ingress point could be located on an edge router (e.g., 6LBR). 2020 Methods to configure which multicast groups are to be propagated into 2021 the MPL Domain could be: 2023 * Manual configuration on each ingress MPL Forwarder. 2025 * MLDv2 protocol, which works only in case all CoAP servers joining 2026 a group are in link-local communication range of an ingress MPL 2027 Forwarder. This is typically not the case on mesh networks. 2029 * A new/custom protocol to register multicast groups at an ingress 2030 MPL Forwarder. This could be for example a CoAP-based protocol 2031 offering multicast group subscription features similar to MLDv2. 2033 For security and performance reasons also other filtering criteria 2034 may be defined at an ingress MPL Forwarder. See Section 6.6 for more 2035 details. 2037 4. Unsecured Group Communication 2039 CoAP group communication can operate in CoAP NoSec (No Security) 2040 mode, without using application-layer and transport-layer security 2041 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 2042 Section 9 of [RFC7252]. The conceptual "NoSec" security group as 2043 defined in Section 2.1 is used for unsecured group communication. 2045 It is NOT RECOMMENDED to use CoAP group communication in NoSec mode, 2046 even in case of non-sensitive and non-critical applications. 2048 Before possibly and exceptionally using the NoSec mode, the security 2049 implications in Section 6.1 must be very well considered and 2050 understood, especially as to the risk and impact of amplification 2051 attacks (see Section 6.3). 2053 5. Secured Group Communication using Group OSCORE 2055 This section defines how CoAP group communication can be secured. In 2056 particular, Section 5.1 describes how the Group OSCORE security 2057 protocol [I-D.ietf-core-oscore-groupcomm] can be used to protect 2058 messages exchanged in a CoAP group, while Section 5.2 provides 2059 guidance on required maintenance operations for OSCORE groups used as 2060 security groups. 2062 5.1. Group OSCORE 2064 The application-layer protocol Object Security for Constrained 2065 RESTful Environments (OSCORE) [RFC8613] provides end-to-end 2066 encryption, integrity and replay protection of CoAP messages 2067 exchanged between two CoAP endpoints. These can act both as CoAP 2068 Client as well as CoAP Server, and share an OSCORE Security Context 2069 used to protect and verify exchanged messages. The use of OSCORE 2070 does not affect the URI scheme and OSCORE can therefore be used with 2071 any URI scheme defined for CoAP. 2073 OSCORE uses COSE [I-D.ietf-cose-rfc8152bis-struct] 2074 [I-D.ietf-cose-rfc8152bis-algs] to perform encryption operations and 2075 protect a CoAP message carried in a COSE object, by using an 2076 Authenticated Encryption with Associated Data (AEAD) algorithm. In 2077 particular, OSCORE takes as input an unprotected CoAP message and 2078 transforms it into a protected CoAP message transporting the COSE 2079 object. 2081 OSCORE makes it possible to selectively protect different parts of a 2082 CoAP message in different ways, while still allowing intermediaries 2083 (e.g., CoAP proxies) to perform their intended functionalities. That 2084 is, some message parts are encrypted and integrity protected; other 2085 parts are only integrity protected to be accessible to, but not 2086 modifiable by, proxies; and some parts are kept as plain content to 2087 be both accessible to and modifiable by proxies. Such differences 2088 especially concern the CoAP options included in the unprotected 2089 message. 2091 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 2092 provides end-to-end security of CoAP messages exchanged between 2093 members of an OSCORE group, while fulfilling the same security 2094 requirements. 2096 In particular, Group OSCORE protects CoAP group requests sent by a 2097 CoAP client, e.g., over UDP/IP multicast, as well as multiple 2098 corresponding CoAP responses sent as (IP) unicast by different CoAP 2099 servers. However, the same security material can also be used to 2100 protect CoAP requests sent over (IP) unicast to a single CoAP server 2101 in the OSCORE group, as well as the corresponding responses. 2103 Group OSCORE ensures source authentication of all messages exchanged 2104 within the OSCORE group, by means of two possible methods. 2106 The first method, called group mode, relies on digital signatures. 2107 That is, sender devices sign their outgoing messages using their own 2108 private key, and embed the signature in the protected CoAP message. 2110 The second method, called pairwise mode, relies on a symmetric key, 2111 which is derived from a pairwise shared secret computed from the 2112 asymmetric keys of the message sender and recipient. This method is 2113 intended for one-to-one messages sent in the group, such as all 2114 responses individually sent by servers, as well as requests addressed 2115 to an individual server. 2117 A Group Manager is responsible for managing one or multiple OSCORE 2118 groups. In particular, the Group Manager acts as repository of the 2119 group members' authentication credentials including the corresponding 2120 public keys; manages, renews and provides security material in the 2121 group; and handles the join process of new group members. 2123 As defined in [I-D.ietf-ace-oscore-gm-admin], an administrator entity 2124 can interact with the Group Manager to create OSCORE groups and 2125 specify their configuration (see Section 2.2.2). During the lifetime 2126 of the OSCORE group, the administrator can further interact with the 2127 Group Manager, in order to possibly update the group configuration 2128 and eventually delete the group. 2130 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 2131 can join an OSCORE group by using the method described in 2132 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 2133 for Authentication and Authorization in constrained environments 2134 [I-D.ietf-ace-oauth-authz]. 2136 A CoAP endpoint can discover OSCORE groups and retrieve information 2137 to join them through their respective Group Managers by using the 2138 method described in [I-D.tiloca-core-oscore-discovery] and based on 2139 the CoRE Resource Directory [I-D.ietf-core-resource-directory]. 2141 If security is required, CoAP group communication as described in 2142 this specification MUST use Group OSCORE. In particular, a CoAP 2143 group as defined in Section 2.1 and using secure group communication 2144 is associated with an OSCORE security group, which includes: 2146 * All members of the CoAP group, i.e., the CoAP endpoints configured 2147 to receive CoAP group messages sent to the particular group and -- 2148 in case of IP multicast transport -- are listening to the group's 2149 multicast IP address on the group's UDP port. 2151 * All further CoAP endpoints configured only as CoAP clients, that 2152 may send CoAP group requests to the CoAP group. 2154 5.2. Secure Group Maintenance 2156 As part of group maintenance operations (see Section 2.2.4), 2157 additional key management operations are required for an OSCORE 2158 group, also depending on the security requirements of the application 2159 (see Section 6.2.1). Specifically: 2161 * Adding new members to a CoAP group or enabling new client-only 2162 endpoints to interact with that group require also that each of 2163 such members/endpoints join the corresponding OSCORE group. When 2164 this happens, they are securely provided with the security 2165 material to use in that OSCORE group. 2167 Applications may need backward security. That is, they may 2168 require that, after having joined an OSCORE group, a new group 2169 member cannot access messages exchanged in the group prior to its 2170 joining, even if it has recorded them. 2172 In such a case, new security material to use in the OSCORE group 2173 has first to be generated and distributed to the current members 2174 of that group, before new endpoints are also provided with that 2175 new security material upon their joining. 2177 * Removing members from a CoAP group or stopping client-only 2178 endpoints from interacting with that group requires removing such 2179 members/endpoints from the corresponding OSCORE group. To this 2180 end, new security material is generated and securely distributed 2181 only to the remaining members of the OSCORE group, together with 2182 the list of former members removed from that group. 2184 This ensures forward security in the OSCORE group. That is, it 2185 ensures that only the members intended to remain in the OSCORE 2186 group are able to continue participating in the secure 2187 communications within that group, while the evicted ones are not 2188 able to after the distribution and installation of the new 2189 security material. 2191 Also, this ensures that the members intended to remain in the 2192 OSCORE group are able to confidently assert the group membership 2193 of other sender nodes, when receiving protected messages in the 2194 OSCORE group after the distribution and installation of the new 2195 security material (see Section 3.2 of 2196 [I-D.ietf-core-oscore-groupcomm]). 2198 The key management operations mentioned above are entrusted to the 2199 Group Manager responsible for the OSCORE group 2200 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 2201 them as defined in [I-D.ietf-ace-key-groupcomm-oscore]. 2203 5.3. Proxy Security 2205 Different solutions may be selected for secure group communication 2206 via a proxy depending on proxy type, use case and deployment 2207 requirements. In this section the options based on Group OSCORE are 2208 listed. 2210 For a client performing a group communication request via a forward- 2211 proxy, end-to-end security should be implemented. The client then 2212 creates a group request protected with Group OSCORE and unicasts this 2213 to the proxy. The proxy adapts the request from a forward-proxy 2214 request to a regular request and multicasts this adapted request to 2215 the indicated CoAP group. During the adaptation, the security 2216 provided by Group OSCORE persists, in either case of using the group 2217 mode or using the pairwise mode. The first leg of communication from 2218 client to proxy can optionally be further protected, e.g., by using 2219 (D)TLS and/or OSCORE. 2221 For a client performing a group communication request via a reverse- 2222 proxy, either end-to-end-security or hop-by-hop security can be 2223 implemented. The case of end-to-end security is the same as for the 2224 forward-proxy case. 2226 The case of hop-by-hop security is only possible if the proxy can be 2227 completely trusted and it is configured as a member of the OSCORE 2228 security group(s) that it needs to access, on behalf of clients. The 2229 first leg of communication between client and proxy is then protected 2230 with a security method for CoAP unicast, such as (D)TLS, OSCORE or a 2231 combination of such methods. The second leg between proxy and 2232 servers is protected using Group OSCORE. This can be useful in 2233 applications where for example the origin client does not implement 2234 Group OSCORE, or the group management operations are confined to a 2235 particular network domain and the client is outside this domain. 2237 For all the above cases, more details on using Group OSCORE are 2238 defined in [I-D.tiloca-core-groupcomm-proxy]. 2240 6. Security Considerations 2242 This section provides security considerations for CoAP group 2243 communication, in general and for the particular transport of IP 2244 multicast. 2246 6.1. CoAP NoSec Mode 2248 CoAP group communication, if not protected, is vulnerable to all the 2249 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 2250 Moreover, as also discussed in 2251 [I-D.mattsson-t2trg-amplification-attacks], the NoSec mode is 2252 susceptible to source IP address spoofing, hence amplification 2253 attacks are especially feasible to perform and greatly effective in 2254 their impact, since a single request can result in multiple responses 2255 from multiple servers (see Section 6.3). 2257 Therefore, even in case of non-sensitive and non-critical 2258 applications, it is generally NOT RECOMMENDED to use CoAP group 2259 communication in NoSec mode, also in order to prevent an easy 2260 proliferation of high-volume amplification attacks as further 2261 discussed in Section 6.3. 2263 Exceptionally, early discovery of devices and resources is a typical 2264 use case where NoSec mode is applied. In such a situation, the 2265 querying devices do not have yet configured any mutual security 2266 relations at the time they perform the discovery. Also, high-volume 2267 and harmful amplifications can be prevented through appropriate and 2268 conservative configurations, since only a few CoAP servers are 2269 expected to be configured for responding to the group requests sent 2270 for discovery (see Section 6.3). 2272 CoAP group communication in NoSec mode SHOULD NOT be deployed for 2273 sensitive and mission-critical applications (e.g., health monitoring 2274 systems and alarm monitoring systems). 2276 CoAP group communication without application-layer security SHOULD be 2277 deployed only in applications that are non-critical and that do not 2278 involve or may have an impact on sensitive data and personal sphere. 2279 These include, e.g., read-only temperature sensors deployed in non- 2280 sensitive environments, where the client reads out the values but 2281 does not use the data to control actuators or to base an important 2282 decision on. 2284 6.2. Group OSCORE 2286 Group OSCORE provides end-to-end application-level security. This 2287 has many desirable properties, including maintaining security 2288 assurances while forwarding traffic through intermediaries (proxies). 2289 Application-level security also tends to more cleanly separate 2290 security from the dynamics of group membership (e.g., the problem of 2291 distributing security keys across large groups with many members that 2292 come and go). 2294 For sensitive and mission-critical applications, CoAP group 2295 communication MUST be protected by using Group OSCORE as specified in 2296 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 2297 from Section 11 of [I-D.ietf-core-oscore-groupcomm] hold for this 2298 specification. 2300 6.2.1. Group Key Management 2302 A key management scheme for secure revocation and renewal of group 2303 security material, namely group rekeying, is required to be adopted 2304 in OSCORE groups. The key management scheme has to preserve forward 2305 security in the OSCORE group, as well as backward security if this is 2306 required by the application (see Section 5.2). In particular, the 2307 key management scheme MUST comply with the functional steps defined 2308 in Section 3.2 of [I-D.ietf-core-oscore-groupcomm]. 2310 Group policies should also take into account the time that the key 2311 management scheme requires to rekey the group, on one hand, and the 2312 expected frequency of group membership changes, i.e., nodes' joining 2313 and leaving, on the other hand. 2315 That is, it may be desirable to not rekey the group upon every single 2316 membership change, in case members' joining and leaving are frequent, 2317 and at the same time a single group rekeying instance takes a non- 2318 negligible time to complete. 2320 In such a case, the Group Manager may cautiously consider to rekey 2321 the group, e.g., after a minimum number of nodes has joined or left 2322 the group within a pre-defined time interval, or according to 2323 communication patterns with predictable time intervals of network 2324 inactivity. This would prevent paralyzing communications in the 2325 group, when a slow rekeying scheme is used and frequently invoked. 2327 At the same, the security implications of delaying the rekeying 2328 process have to be carefully considered and understood, before 2329 enforcing such group policies. 2331 In fact, this comes at the cost of not continuously preserving 2332 backward and forward security, since group rekeying might not occur 2333 upon every single group membership change. That is, most recently 2334 joined nodes would have access to the security material used prior to 2335 their joining, and thus be able to access past group communications 2336 protected with that security material. Similarly, until the group is 2337 rekeyed, most recently left nodes would preserve access to group 2338 communications protected with the retained security material. 2340 6.2.2. Source Authentication 2342 Both the group mode and the pairwise mode of Group OSCORE ensure 2343 source authentication of messages exchanged by CoAP endpoints through 2344 CoAP group communication. 2346 To this end, outgoing messages are either countersigned by the 2347 message sender endpoint with its own private key (group mode), or 2348 protected with a symmetric key, which is in turn derived using the 2349 asymmetric keys of the message sender and recipient (pairwise mode). 2351 Thus, both modes allow a recipient CoAP endpoint to verify that a 2352 message has actually been originated by a specific and identified 2353 member of the OSCORE group. 2355 6.2.3. Countering Attacks 2357 As discussed below, Group OSCORE addresses a number of security 2358 attacks mentioned in Section 11 of [RFC7252], with particular 2359 reference to their execution over IP multicast. 2361 * Since Group OSCORE provides end-to-end confidentiality and 2362 integrity of request/response messages, proxies capable of group 2363 communication cannot break message protection, and thus cannot act 2364 as man-in-the-middle beyond their legitimate duties (see 2365 Section 11.2 of [RFC7252]). In fact, intermediaries such as 2366 proxies are not assumed to have access to the OSCORE Security 2367 Context used by group members. Also, with the notable addition of 2368 signatures for the group mode, Group OSCORE protects messages 2369 using the same procedure as OSCORE (see Sections 8 and 9 of 2370 [I-D.ietf-core-oscore-groupcomm]), and especially processes CoAP 2371 options according to the same classification in U/I/E classes. 2373 * Group OSCORE limits the feasibility and impact of amplification 2374 attacks, see Section 6.3 of this document and Section 11.3 of 2375 [RFC7252]. 2377 In fact, upon receiving a group request protected with Group 2378 OSCORE in group mode, a server is able to verify whether the 2379 request is not a replay and originates from the alleged sender in 2380 the OSCORE group, by verifying the signature included in the 2381 request using the public key of that sender (see Section 8.2 of 2382 [I-D.ietf-core-oscore-groupcomm]). Furthermore, as also discussed 2383 in Section 8 of [I-D.ietf-core-oscore-groupcomm], it is 2384 recommended that servers failing to decrypt and verify an incoming 2385 message do not send back any error message. 2387 This limits an adversary to leveraging an intercepted group 2388 request protected with Group OSCORE, and then altering the source 2389 address to be the one of the intended amplification victim. 2391 Furthermore, the adversary needs to consider a group request that 2392 specifically targets a resource for which the CoAP servers are 2393 configured to respond. While this can be often correctly assumed 2394 or inferable from the application context, it is not explicit from 2395 the group request itself, since Group OSCORE protects the Uri-Path 2396 and Uri-Query CoAP Options conveying the respective components of 2397 the target URI. 2399 As a further mitigation against amplification attacks, a server 2400 can also rely on the Echo Option for CoAP defined in [RFC9175] and 2401 include it in a response to a group request. By doing so, the 2402 server can assert that the alleged sender of the group request 2403 (i.e., the CoAP client associated with a certain authentication 2404 credential including the corresponding public key) is indeed 2405 reachable at the claimed source address, especially if this 2406 differs from the one used in previous group requests from the same 2407 CoAP client. Although responses including the Echo Option do 2408 still result in amplification, this is limited in volume compared 2409 to when all servers reply with a full-fledged response. 2411 * Group OSCORE limits the impact of attacks based on IP spoofing 2412 also over IP multicast (see Section 11.4 of [RFC7252]). In fact, 2413 requests and corresponding responses sent in the OSCORE group can 2414 be correctly generated only by legitimate group members. 2416 Within an OSCORE group, the shared symmetric-key security material 2417 strictly provides only group-level authentication. However, 2418 source authentication of messages is also ensured, both in the 2419 group mode by means of signatures (see Sections 8.1 and 8.3 of 2420 [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by 2421 using additionally derived pairwise keys (see Sections 9.3 and 9.5 2422 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints 2423 can verify a message to be originated by the alleged, identifiable 2424 sender in the OSCORE group. 2426 As noted above, the server may additionally rely on the Echo 2427 Option for CoAP defined in [RFC9175], in order to verify the 2428 aliveness and reachability of the client sending a request from a 2429 particular IP address. 2431 * Group OSCORE does not require group members to be equipped with a 2432 good source of entropy for generating security material (see 2433 Section 11.6 of [RFC7252]), and thus does not contribute to create 2434 an entropy-related attack vector against such (constrained) CoAP 2435 endpoints. In particular, the symmetric keys used for message 2436 encryption and decryption are derived through the same HMAC-based 2437 HKDF scheme used for OSCORE (see Section 3.2 of [RFC8613]). 2438 Besides, the OSCORE Master Secret used in such derivation is 2439 securely generated by the Group Manager responsible for the OSCORE 2440 group, and securely provided to the CoAP endpoints when they join 2441 the group. 2443 * Group OSCORE prevents to make any single group member a target for 2444 subverting security in the whole OSCORE group (see Section 11.6 of 2445 [RFC7252]), even though all group members share (and can derive) 2446 the same symmetric-key security material used in the OSCORE group. 2447 In fact, source authentication is always ensured for exchanged 2448 CoAP messages, as verifiable to be originated by the alleged, 2449 identifiable sender in the OSCORE group. This relies on including 2450 a signature computed with a node's individual private key (in the 2451 group mode), or on protecting messages with a pairwise symmetric 2452 key, which is in turn derived from the asymmetric keys of the 2453 sender and recipient CoAP endpoints (in the pairwise mode). 2455 6.3. Risk of Amplification 2457 Section 11.3 of [RFC7252] highlights that CoAP group requests may be 2458 used for accidentally or deliberately performing Denial of Service 2459 attacks, especially in the form of a high-volume amplification 2460 attack, by using all the servers in the CoAP group as attack vectors. 2462 That is, following a group request sent to a CoAP group, each of the 2463 servers in the group may reply with a response which is likely larger 2464 in size than the group request. Thus, an attacker sending a single 2465 group request may achieve a high amplification factor, i.e., a high 2466 ratio between the size of the group request and the total size of the 2467 corresponding responses intended to the attack victim. 2469 Thus, consistently with Section 11.3 of [RFC7252], a server in a CoAP 2470 group: 2472 * SHOULD limit the support for CoAP group requests only to the group 2473 resources of the application group(s) using that CoAP group; 2475 * SHOULD NOT accept group requests that can not be authenticated in 2476 some way; 2478 * SHOULD NOT provide large amplification factors through its 2479 responses to a non-authenticated group request, and can possibly 2480 rely on CoAP block-wise transfers [RFC7959] to reduce the amount 2481 of amplification. 2483 Amplifications attacks using CoAP are further discussed in 2484 [I-D.mattsson-t2trg-amplification-attacks], which also highlights how 2485 the amplification factor would become even higher when CoAP group 2486 communication is combined with resource observation [RFC7641]. That 2487 is, a single group request may result in multiple notification 2488 responses from each of the responding servers, throughout the 2489 observation lifetime. 2491 Thus, consistently with Section 7 of [RFC7641], a server in a CoAP 2492 group MUST strictly limit the number of notifications it sends 2493 between receiving acknowledgments that confirm the actual interest of 2494 the client in continuing the observation. 2496 Moreover, it is especially easy to perform an amplification attack 2497 when the NoSec mode is used. Therefore, even in case of non- 2498 sensitive and non-critical applications, it is generally NOT 2499 RECOMMENDED to use CoAP group communication in NoSec mode, in order 2500 to prevent an easy proliferation of high-volume amplification 2501 attacks. 2503 Exceptions should be carefully limited to use cases and accesses to a 2504 group resource that have a specific, narrow and well understood 2505 scope, and where only a few CoAP servers (or, ideally, only one) 2506 would possibly respond to a group request. 2508 A relevant exceptional example is a CoAP client performing the 2509 discovery of hosts such as a group manager or a Resource Directory 2510 [I-D.ietf-core-resource-directory], by probing for them through a 2511 group request sent to the CoAP group. This early, unprotected step 2512 is relevant for a CoAP client that does not know the address of such 2513 hosts in advance, and that does not have yet configured a mutual 2514 security relation with them. In this kind of deployments, such a 2515 discovery procedure does not result in a considerable and harmful 2516 amplification, since only the few CoAP servers object of discovery 2517 are going to respond to the group request targeting that specific 2518 resource. In particular, those hosts can be the only CoAP servers in 2519 that specific CoAP group (hence listening for group requests sent to 2520 that group), and/or the only CoAP servers explicitly configured to 2521 respond to group requests targeting specific group resources. 2523 With the exception of such particular use cases, group communications 2524 MUST be secured using Group OSCORE [I-D.ietf-core-oscore-groupcomm], 2525 see Section 5. As discussed in Section 6.2.3, this limits the 2526 feasibility and impact of amplification attacks. 2528 6.4. Replay of Non-Confirmable Messages 2530 Since all requests sent over IP multicast are Non-confirmable, a 2531 client might not be able to know if an adversary has actually 2532 captured one of its transmitted requests and later re-injected it in 2533 the group as a replay to the server nodes. In fact, even if the 2534 servers sent back responses to the replayed request, the client would 2535 typically not have a valid matching request active anymore so this 2536 attack would not accomplish anything in the client. 2538 If Group OSCORE is used, such a replay attack on the servers is 2539 prevented, since a client protects every different request with a 2540 different Sequence Number value, which is in turn included as Partial 2541 IV in the protected message and takes part in the construction of the 2542 AEAD cipher nonce. Thus, a server would be able to detect the 2543 replayed request, by checking the conveyed Partial IV against its own 2544 replay window in the OSCORE Recipient Context associated with the 2545 client. 2547 This requires a server to have a synchronized, up to date view of the 2548 sequence number used by the client. If such synchronization is lost, 2549 e.g., due to a reboot, or suspected so, the server should use the 2550 challenge-response synchronization method described in Appendix E of 2551 [I-D.ietf-core-oscore-groupcomm] and based on the Echo Option for 2552 CoAP defined in [RFC9175], in order to (re-)synchronize with the 2553 client's sequence number. 2555 6.5. Use of CoAP No-Response Option 2557 When CoAP group communication is used in CoAP NoSec (No Security) 2558 mode (see Section 4), the CoAP No-Response Option [RFC7967] could be 2559 misused by a malicious client to evoke as much responses from servers 2560 to a group request as possible, by using the value '0' - Interested 2561 in all responses. This even overrides the default behavior of a CoAP 2562 server to suppress the response in case there is nothing of interest 2563 to respond with. Therefore, this option can be used to perform an 2564 amplification attack (see Section 6.3). 2566 A proposed mitigation is to only allow this option to relax the 2567 standard suppression rules for a resource in case the option is sent 2568 by an authenticated client. If sent by an unauthenticated client, 2569 the option can be used to expand the classes of responses suppressed 2570 compared to the default rules but not to reduce the classes of 2571 responses suppressed. 2573 6.6. 6LoWPAN and MPL 2575 In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior 2576 to transmission. A 6LoWPAN Router that forwards a fragmented packet 2577 may have a relatively high impact on the occupation of the wireless 2578 channel and may locally experience high memory load due to packet 2579 buffering. For example, the MPL [RFC7731] protocol requires an MPL 2580 Forwarder to store the packet for a longer duration, to allow 2581 multiple forwarding transmissions to neighboring Forwarders. If one 2582 or more of the fragments are not received correctly by an MPL 2583 Forwarder during its packet reassembly time window, the Forwarder 2584 discards all received fragments and at a future point in time it 2585 needs to receive again all the packet fragments (this time, possibly 2586 from another neighboring MPL Forwarder). 2588 For these reasons, a fragmented IPv6 multicast packet is a possible 2589 attack vector in a Denial of Service (DoS) amplification attack. See 2590 Section 6.3 of this document and Section 11.3 of [RFC7252] for more 2591 details on amplification. To mitigate the risk, applications sending 2592 multicast IPv6 requests to 6LoWPAN hosted CoAP servers SHOULD limit 2593 the size of the request to avoid 6LoWPAN fragmentation of the request 2594 packet. A 6LoWPAN Router or (MPL) multicast forwarder SHOULD 2595 deprioritize forwarding for multi-fragment 6LoWPAN multicast packets. 2596 6LoWPAN Border Routers are typical ingress points where multicast 2597 traffic enters into a 6LoWPAN network. Specific MPL Forwarders 2598 (whether located on a 6LBR or not) may also be configured as ingress 2599 points. Any such ingress point SHOULD implement multicast packet 2600 filtering to prevent unwanted multicast traffic from entering a 2601 6LoWPAN network from the outside. For example, it could filter out 2602 all multicast packets for which there is no known multicast listener 2603 on the 6LoWPAN network. See Section 3.10 for protocols that allow 2604 multicast listeners to signal which groups they would like to listen 2605 to. As part of multicast packet filtering, the ingress point SHOULD 2606 implement a filtering criterium based on the size of the multicast 2607 packet. Ingress multicast packets above a defined size may then be 2608 dropped or deprioritized. 2610 6.7. Wi-Fi 2612 In a home automation scenario using Wi-Fi, Wi-Fi security should be 2613 enabled to prevent rogue nodes from joining. The Customer Premises 2614 Equipment (CPE) that enables access to the Internet should also have 2615 its IP multicast filters set so that it enforces multicast scope 2616 boundaries to isolate local multicast groups from the rest of the 2617 Internet (e.g., as per [RFC6092]). In addition, the scope of IP 2618 multicast transmissions and listeners should be site-local (5) or 2619 smaller. For site-local scope, the CPE will be an appropriate 2620 multicast scope boundary point. 2622 6.8. Monitoring 2624 6.8.1. General Monitoring 2626 CoAP group communication can be used to control a set of related 2627 devices: for example, simultaneously turn on all the lights in a 2628 room. This intrinsically exposes the group to some unique monitoring 2629 risks that devices not in a group are not as vulnerable to. For 2630 example, assume an attacker is able to physically see a set of lights 2631 turn on in a room. Then the attacker can correlate an observed CoAP 2632 group communication message to the observed coordinated group action 2633 -- even if the CoAP message is (partly) encrypted. 2635 This will give the attacker side-channel information to plan further 2636 attacks (e.g., by determining the members of the group some network 2637 topology information may be deduced). 2639 6.8.2. Pervasive Monitoring 2641 A key additional threat consideration for group communication is 2642 pervasive monitoring [RFC7258]. CoAP group communication solutions 2643 that are built on top of IP multicast need to pay particular heed to 2644 these dangers. This is because IP multicast is easier to intercept 2645 compared to IP unicast. Also, CoAP traffic is typically used for the 2646 Internet of Things. This means that CoAP (multicast) group 2647 communication may be used for the control and monitoring of critical 2648 infrastructure (e.g., lights, alarms, HVAC, electrical grid, etc.) 2649 that may be prime targets for attack. 2651 For example, an attacker may attempt to record all the CoAP traffic 2652 going over a smart grid (i.e., networked electrical utility) and try 2653 to determine critical nodes for further attacks. For example, the 2654 source node (controller) sends out CoAP group communication messages 2655 which easily identifies it as a controller. CoAP multicast traffic 2656 is inherently more vulnerable compared to unicast, as the same packet 2657 may be replicated over many more links, leading to a higher 2658 probability of packet capture by a pervasive monitoring system. 2660 One mitigation is to restrict the scope of IP multicast to the 2661 minimal scope that fulfills the application need. See the congestion 2662 control recommendations in the last bullet of 2663 Section 3.6 to minimize the scope. Thus, for example, realm-local IP 2664 multicast scope is always preferred over site-local scope IP 2665 multicast if this fulfills the application needs. 2667 Even if all CoAP multicast traffic is encrypted/protected, an 2668 attacker may still attempt to capture this traffic and perform an 2669 off-line attack in the future. 2671 7. IANA Considerations 2673 This document has no actions for IANA. 2675 8. References 2677 8.1. Normative References 2679 [I-D.ietf-core-oscore-groupcomm] 2680 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 2681 and J. Park, "Group OSCORE - Secure Group Communication 2682 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 2683 core-oscore-groupcomm-14, 7 March 2022, 2684 . 2687 [I-D.ietf-cose-rfc8152bis-algs] 2688 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2689 Initial Algorithms", Work in Progress, Internet-Draft, 2690 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2691 . 2694 [I-D.ietf-cose-rfc8152bis-struct] 2695 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2696 Structures and Process", Work in Progress, Internet-Draft, 2697 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 2698 . 2701 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2702 Communication Layers", STD 3, RFC 1122, 2703 DOI 10.17487/RFC1122, October 1989, 2704 . 2706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2707 Requirement Levels", BCP 14, RFC 2119, 2708 DOI 10.17487/RFC2119, March 1997, 2709 . 2711 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2712 Thyagarajan, "Internet Group Management Protocol, Version 2713 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 2714 . 2716 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 2717 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 2718 DOI 10.17487/RFC3810, June 2004, 2719 . 2721 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2722 Control Message Protocol (ICMPv6) for the Internet 2723 Protocol Version 6 (IPv6) Specification", STD 89, 2724 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2725 . 2727 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2728 "Transmission of IPv6 Packets over IEEE 802.15.4 2729 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2730 . 2732 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2733 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2734 DOI 10.17487/RFC6282, September 2011, 2735 . 2737 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2738 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2739 . 2741 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2742 Application Protocol (CoAP)", RFC 7252, 2743 DOI 10.17487/RFC7252, June 2014, 2744 . 2746 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2747 Application Protocol (CoAP)", RFC 7641, 2748 DOI 10.17487/RFC7641, September 2015, 2749 . 2751 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 2752 the Constrained Application Protocol (CoAP)", RFC 7959, 2753 DOI 10.17487/RFC7959, August 2016, 2754 . 2756 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 2757 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 2758 the Constrained Application Protocol (CoAP)", RFC 8075, 2759 DOI 10.17487/RFC8075, February 2017, 2760 . 2762 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 2763 FETCH Methods for the Constrained Application Protocol 2764 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 2765 . 2767 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2768 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2769 May 2017, . 2771 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2772 "Object Security for Constrained RESTful Environments 2773 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2774 . 2776 [RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander, 2777 "Constrained Application Protocol (CoAP): Echo, Request- 2778 Tag, and Token Processing", RFC 9175, 2779 DOI 10.17487/RFC9175, February 2022, 2780 . 2782 8.2. Informative References 2784 [Californium] 2785 Eclipse Foundation, "Eclipse Californium", March 2019, 2786 . 2790 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 2791 CoAP Server & Client in Go", March 2019, 2792 . 2794 [I-D.ietf-ace-key-groupcomm-oscore] 2795 Tiloca, M., Park, J., and F. Palombini, "Key Management 2796 for OSCORE Groups in ACE", Work in Progress, Internet- 2797 Draft, draft-ietf-ace-key-groupcomm-oscore-13, 7 March 2798 2022, . 2801 [I-D.ietf-ace-oauth-authz] 2802 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2803 H. Tschofenig, "Authentication and Authorization for 2804 Constrained Environments (ACE) using the OAuth 2.0 2805 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2806 draft-ietf-ace-oauth-authz-46, 8 November 2021, 2807 . 2810 [I-D.ietf-ace-oscore-gm-admin] 2811 Tiloca, M., Höglund, R., Stok, P. V. D., and F. Palombini, 2812 "Admin Interface for the OSCORE Group Manager", Work in 2813 Progress, Internet-Draft, draft-ietf-ace-oscore-gm-admin- 2814 05, 7 March 2022, . 2817 [I-D.ietf-core-coap-pubsub] 2818 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2819 Subscribe Broker for the Constrained Application Protocol 2820 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2821 core-coap-pubsub-09, 30 September 2019, 2822 . 2825 [I-D.ietf-core-new-block] 2826 Boucadair, M. and J. Shallow, "Constrained Application 2827 Protocol (CoAP) Block-Wise Transfer Options Supporting 2828 Robust Transmission", Work in Progress, Internet-Draft, 2829 draft-ietf-core-new-block-14, 26 May 2021, 2830 . 2833 [I-D.ietf-core-resource-directory] 2834 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2835 D. Stok, "CoRE Resource Directory", Work in Progress, 2836 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2837 March 2021, . 2840 [I-D.mattsson-t2trg-amplification-attacks] 2841 Mattsson, J. P., Selander, G., and C. Amsüss, 2842 "Amplification Attacks Using the Constrained Application 2843 Protocol (CoAP)", Work in Progress, Internet-Draft, draft- 2844 mattsson-t2trg-amplification-attacks-00, 11 February 2022, 2845 . 2848 [I-D.tiloca-core-groupcomm-proxy] 2849 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 2850 Communication", Work in Progress, Internet-Draft, draft- 2851 tiloca-core-groupcomm-proxy-06, 7 March 2022, 2852 . 2855 [I-D.tiloca-core-oscore-discovery] 2856 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 2857 OSCORE Groups with the CoRE Resource Directory", Work in 2858 Progress, Internet-Draft, draft-tiloca-core-oscore- 2859 discovery-11, 7 March 2022, 2860 . 2863 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2864 Capabilities in Customer Premises Equipment (CPE) for 2865 Providing Residential IPv6 Internet Service", RFC 6092, 2866 DOI 10.17487/RFC6092, January 2011, 2867 . 2869 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2870 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2871 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2872 Low-Power and Lossy Networks", RFC 6550, 2873 DOI 10.17487/RFC6550, March 2012, 2874 . 2876 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 2877 the Internet Group Management Protocol (IGMP) and 2878 Multicast Listener Discovery (MLD) for Routers in Mobile 2879 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 2880 May 2012, . 2882 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2883 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2884 2014, . 2886 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 2887 DOI 10.17487/RFC7346, August 2014, 2888 . 2890 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 2891 the Constrained Application Protocol (CoAP)", RFC 7390, 2892 DOI 10.17487/RFC7390, October 2014, 2893 . 2895 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 2896 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 2897 February 2016, . 2899 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2900 Bose, "Constrained Application Protocol (CoAP) Option for 2901 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2902 August 2016, . 2904 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 2905 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 2906 Application Protocol) over TCP, TLS, and WebSockets", 2907 RFC 8323, DOI 10.17487/RFC8323, February 2018, 2908 . 2910 [RFC8710] Fossati, T., Hartke, K., and C. Bormann, "Multipart 2911 Content-Format for the Constrained Application Protocol 2912 (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020, 2913 . 2915 Appendix A. Use Cases 2917 To illustrate where and how CoAP-based group communication can be 2918 used, this section summarizes the most common use cases. These use 2919 cases include both secured and non-secured CoAP usage. Each 2920 subsection below covers one particular category of use cases for 2921 CoRE. Within each category, a use case may cover multiple 2922 application areas such as home IoT, commercial building IoT (sensing 2923 and control), industrial IoT/control, or environmental sensing. 2925 A.1. Discovery 2927 Discovery of physical devices in a network, or discovery of 2928 information entities hosted on network devices, are operations that 2929 are usually required in a system during the phases of setup or 2930 (re)configuration. When a discovery use case involves devices that 2931 need to interact without having been configured previously with a 2932 common security context, unsecured CoAP communication is typically 2933 used. Discovery may involve a request to a directory server, which 2934 provides services to aid clients in the discovery process. One 2935 particular type of directory server is the CoRE Resource Directory 2936 [I-D.ietf-core-resource-directory]; and there may be other types of 2937 directories that can be used with CoAP. 2939 A.1.1. Distributed Device Discovery 2941 Device discovery is the discovery and identification of networked 2942 devices -- optionally only devices of a particular class, type, 2943 model, or brand. Group communication is used for distributed device 2944 discovery, if a central directory server is not used. Typically in 2945 distributed device discovery, a multicast request is sent to a 2946 particular address (or address range) and multicast scope of 2947 interest, and any devices configured to be discoverable will respond 2948 back. For the alternative solution of centralized device discovery a 2949 central directory server is accessed through unicast, in which case 2950 group communication is not needed. This requires that the address of 2951 the central directory is either preconfigured in each device or 2952 configured during operation using a protocol. 2954 In CoAP, device discovery can be implemented by CoAP resource 2955 discovery requesting (GET) a particular resource that the sought 2956 device class, type, model or brand is known to respond to. It can 2957 also be implemented using CoAP resource discovery (Section 7 of 2958 [RFC7252]) and the CoAP query interface defined in Section 4 of 2959 [RFC6690] to find these particular resources. Also, a multicast GET 2960 request to /.well-known/core can be used to discover all CoAP 2961 devices. 2963 A.1.2. Distributed Service Discovery 2965 Service discovery is the discovery and identification of particular 2966 services hosted on network devices. Services can be identified by 2967 one or more parameters such as ID, name, protocol, version and/or 2968 type. Distributed service discovery involves group communication to 2969 reach individual devices hosting a particular service; with a central 2970 directory server not being used. 2972 In CoAP, services are represented as resources and service discovery 2973 is implemented using resource discovery (Section 7 of [RFC7252]) and 2974 the CoAP query interface defined in Section 4 of [RFC6690]. 2976 A.1.3. Directory Discovery 2978 This use case is a specific sub-case of Distributed Service Discovery 2979 (Appendix A.1.2), in which a device needs to identify the location of 2980 a Directory on the network to which it can e.g., register its own 2981 offered services, or to which it can perform queries to identify and 2982 locate other devices/services it needs to access on the network. 2983 Section 3.3 of [RFC7390] showed an example of discovering a CoRE 2984 Resource Directory using CoAP group communication. As defined in 2985 [I-D.ietf-core-resource-directory], a resource directory is a web 2986 entity that stores information about web resources and implements 2987 REST interfaces for registration and lookup of those resources. For 2988 example, a device can register itself to a resource directory to let 2989 it be found by other devices and/or applications. 2991 A.2. Operational Phase 2993 Operational phase use cases describe those operations that occur most 2994 frequently in a networked system, during its operational lifetime and 2995 regular operation. Regular usage is when the applications on 2996 networked devices perform the tasks they were designed for and 2997 exchange of application-related data using group communication 2998 occurs. Processes like system reconfiguration, group changes, 2999 system/device setup, extra group security changes, etc. are not part 3000 of regular operation. 3002 A.2.1. Actuator Group Control 3004 Group communication can be beneficial to control actuators that need 3005 to act in synchrony, as a group, with strict timing (latency) 3006 requirements. Examples are office lighting, stage lighting, street 3007 lighting, or audio alert/Public Address systems. Sections 3.4 and 3008 3.5 of [RFC7390] showed examples of lighting control of a group of 3009 6LoWPAN-connected lights. 3011 A.2.2. Device Group Status Request 3013 To properly monitor the status of systems, there may be a need for 3014 ad-hoc, unplanned status updates. Group communication can be used to 3015 quickly send out a request to a (potentially large) number of devices 3016 for specific information. Each device then responds back with the 3017 requested data. Those devices that did not respond to the request 3018 can optionally be polled again via reliable unicast communication to 3019 complete the dataset. The device group may be defined e.g., as "all 3020 temperature sensors on floor 3", or "all lights in wing B". For 3021 example, it could be a status request for device temperature, most 3022 recent sensor event detected, firmware version, network load, and/or 3023 battery level. 3025 A.2.3. Network-wide Query 3027 In some cases a whole network or subnet of multiple IP devices needs 3028 to be queried for status or other information. This is similar to 3029 the previous use case except that the device group is not defined in 3030 terms of its function/type but in terms of its network location. 3031 Technically this is also similar to distributed service discovery 3032 (Appendix A.1.2) where a query is processed by all devices on a 3033 network - except that the query is not about services offered by the 3034 device, but rather specific operational data is requested. 3036 A.2.4. Network-wide / Group Notification 3038 In some cases a whole network, or subnet of multiple IP devices, or a 3039 specific target group needs to be notified of a status change or 3040 other information. This is similar to the previous two use cases 3041 except that the recipients are not expected to respond with some 3042 information. Unreliable notification can be acceptable in some use 3043 cases, in which a recipient does not respond with a confirmation of 3044 having received the notification. In such a case, the receiving CoAP 3045 server does not have to create a CoAP response. If the sender needs 3046 confirmation of reception, the CoAP servers can be configured for 3047 that resource to respond with a 2.xx success status after processing 3048 a notification request successfully. 3050 A.3. Software Update 3052 Group communication can be useful to efficiently distribute new 3053 software (firmware, image, application, etc.) to a group of multiple 3054 devices. In this case, the group is defined in terms of device type: 3055 all devices in the target group are known to be capable of installing 3056 and running the new software. The software is distributed as a 3057 series of smaller blocks that are collected by all devices and stored 3058 in memory. All devices in the target group are usually responsible 3059 for integrity verification of the received software; which can be 3060 done per-block or for the entire software image once all blocks have 3061 been received. Due to the inherent unreliability of CoAP multicast, 3062 there needs to be a backup mechanism (e.g., implemented using CoAP 3063 unicast) by which a device can individually request missing blocks of 3064 a whole software image/entity. Prior to a multicast software update, 3065 the group of recipients can be separately notified that there is new 3066 software available and coming, using the above network-wide or group 3067 notification. 3069 Appendix B. Examples of Message Exchanges 3071 This section provides examples of different message exchanges when 3072 CoAP is used with group communication. The examples consider: 3074 * A client with address ADDR_CLIENT and port number PORT_CLIENT. 3076 * A CoAP group associated with the IP multicast address ADDR_GRP and 3077 port number PORT_GRP. 3079 * An application group "gp1" associated with the CoAP group above. 3081 * Three servers A, B and C, all of which are members of the CoAP 3082 group above and of the application group "gp1". Each server X 3083 (with X equal to A, B or C): listens to its own address ADDR_X and 3084 port number PORT_X; and listens to the address ADDR_GRP and port 3085 number PORT_GRP. For each server its PORT_X may be different from 3086 PORT_GRP or may be equal to it, in general. 3088 In Figure 16, the client sends a Non-confirmable GET request to the 3089 CoAP group, targeting the resource "temperature" in the application 3090 group "gp1". All servers reply with a 2.05 Content response, 3091 although the response from server B is lost. As source port number 3092 of their response, servers A and B use the destination port number of 3093 the request, i.e, PORT_GRP. Instead, server C uses its own port 3094 number PORT_C. 3096 Client A B C 3097 | | | | 3098 | GET | | | 3099 +-------+------->| | | Source: ADDR_CLIENT:PORT_CLIENT 3100 | \ | | | Destination: ADDR_GRP:PORT_GRP 3101 | `.------->| | Header: GET (T=NON, Code=0.01, MID=0x7d41) 3102 | `. | | | Token: 0x86 3103 | `------->| Uri-Path: "gp" 3104 | | | | Uri-Path: "gp1" 3105 | | | | Uri-Path: "temperature" 3106 | | | | 3107 |<---------------+ | | Source: ADDR_A:PORT_GRP 3108 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3109 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1) 3110 | | | | Token: 0x86 3111 | | | | Payload: "22.3 C" 3112 | | | | 3113 | X---------------+ | Source: ADDR_B:PORT_GRP 3114 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3115 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0) 3116 | | | | Token: 0x86 3117 | | | | Payload: "20.9 C" 3118 | | | | 3119 | | | | 3120 |<---------------------+ Source: ADDR_C:PORT_C 3121 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3122 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x952a) 3123 | | | | Token: 0x86 3124 | | | | Payload: "21.0 C" 3125 | | | | 3127 Figure 16: Example of Non-confirmable group request, followed by 3128 Non-confirmable Responses 3130 In Figure 17, the client sends a Non-confirmable GET request to the 3131 CoAP group, targeting and requesting to observe the resource 3132 "temperature" in the application group "gp1". All servers reply with 3133 a 2.05 Content notification response. As source port number of their 3134 response, servers A and B use the destination port number of the 3135 request, i.e, PORT_GRP. Instead, server C uses its own port number 3136 PORT_C. Some time later, all servers send a 2.05 Content 3137 notification response, with payload the new representation of the 3138 "temperature" resource. 3140 Client A B C 3141 | | | | 3142 | GET | | | 3143 +-------+------->| | | Source: ADDR_CLIENT:PORT_CLIENT 3144 | \ | | | Destination: ADDR_GRP:PORT_GRP 3145 | `.------->| | Header: GET (T=NON, Code=0.01, MID=0x7d41) 3146 | `. | | | Token: 0x86 3147 | `------->| Observe: 0 (register) 3148 | | | | Uri-Path: "gp" 3149 | | | | Uri-Path: "gp1" 3150 | | | | Uri-Path: "temperature" 3151 | | | | 3152 |<---------------+ | | Source: ADDR_A:PORT_GRP 3153 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3154 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1) 3155 | | | | Token: 0x86 3156 | | | | Observe: 3 3157 | | | | Payload: "22.3 C" 3158 | | | | 3159 |<------------------+ | Source: ADDR_B:PORT_GRP 3160 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3161 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0) 3162 | | | | Token: 0x86 3163 | | | | Observe: 13 3164 | | | | Payload: "20.9 C" 3165 | | | | 3166 |<---------------------+ Source: ADDR_C:PORT_C 3167 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3168 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x952a) 3169 | | | | Token: 0x86 3170 | | | | Observe: 23 3171 | | | | Payload: "21.0 C" 3172 | | | | 3174 // The temperature changes ... 3176 | | | | 3177 |<---------------+ | | Source: ADDR_A:PORT_GRP 3178 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3179 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b2) 3180 | | | | Token: 0x86 3181 | | | | Observe: 7 3182 | | | | Payload: "32.3 C" 3183 | | | | 3184 |<------------------+ | Source: ADDR_B:PORT_GRP 3185 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3186 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x01a1) 3187 | | | | Token: 0x86 3188 | | | | Observe: 18 3189 | | | | Payload: "30.9 C" 3190 | | | | 3191 |<---------------------+ Source: ADDR_C:PORT_C 3192 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3193 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x952b) 3194 | | | | Token: 0x86 3195 | | | | Observe: 29 3196 | | | | Payload: "31.0 C" 3197 | | | | 3199 Figure 17: Example of Non-confirmable Observe group request, 3200 followed by Non- confirmable Responses as Observe notifications 3202 In Figure 18, the client sends a Non-confirmable GET request to the 3203 CoAP group, targeting the resource "log" in the application group 3204 "gp1", and requesting a blockwise transfer. All servers reply with a 3205 2.05 Content response including the first block. As source port 3206 number of its response, each server uses its own port number. After 3207 obtaining the first block, the client requests the following blocks 3208 separately from each server, by means of unicast exchanges. 3210 Client A B C 3211 | | | | 3212 | GET | | | 3213 +-------+------->| | | Source: ADDR_CLIENT:PORT_CLIENT 3214 | \ | | | Destination: ADDR_GRP:PORT_GRP 3215 | `.------->| | Header: GET (T=NON, Code=0.01, MID=0x7d41) 3216 | `. | | | Token: 0x86 3217 | `------->| Uri-Path: "gp" 3218 | | | | Uri-Path: "gp1" 3219 | | | | Uri-Path: "log" 3220 | | | | Block2: 0/0/64 3221 | | | | 3222 |<---------------+ | | Source: ADDR_A:PORT_A 3223 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3224 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1) 3225 | | | | Token: 0x86 3226 | | | | Block2: 0/1/64 3227 | | | | Payload: 0x0a00 ... 3228 | | | | 3229 |<------------------+ | Source: ADDR_B:PORT_B 3230 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3231 | | | | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0) 3232 | | | | Token: 0x86 3233 | | | | Block2: 0/1/64 3234 | | | | Payload: 0x0b00 ... 3235 | | | | 3236 |<---------------------+ Source: ADDR_C:PORT_C 3237 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3238 | | | | Header: 2.05 (T=NON, Code=4.04, MID=0x952a) 3239 | | | | Token: 0x86 3240 | | | | Block2: 0/1/64 3241 | | | | Payload: 0x0c00 ... 3242 | | | | 3243 | GET | | | 3244 +--------------->| | | Source: ADDR_CLIENT:PORT_CLIENT 3245 | | | | Destination: ADDR_A:PORT_A 3246 | | | | Header: GET (T=CON, Code=0.01, MID=0x7d42) 3247 | | | | Token: 0xa6 3248 | | | | Uri-Path: "gp" 3249 | | | | Uri-Path: "gp1" 3250 | | | | Uri-Path: "log" 3251 | | | | Block2: 1/0/64 3252 | | | | 3253 |<---------------+ | | Source: ADDR_A:PORT_A 3254 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3255 | | | | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d42) 3256 | | | | Token: 0xa6 3257 | | | | Block2: 1/1/64 3258 | | | | Payload: 0x0a01 ... 3259 | | | | 3260 | GET | | | 3261 +--------------->| | | Source: ADDR_CLIENT:PORT_CLIENT 3262 | | | | Destination: ADDR_A:PORT_A 3263 | | | | Header: GET (T=CON, Code=0.01, MID=0x7d43) 3264 | | | | Token: 0xa7 3265 | | | | Uri-Path: "gp" 3266 | | | | Uri-Path: "gp1" 3267 | | | | Uri-Path: "log" 3268 | | | | Block2: 2/0/64 3269 | | | | 3270 |<---------------+ | | Source: ADDR_A:PORT_A 3271 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3272 | | | | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d43) 3273 | | | | Token: 0xa7 3274 | | | | Block2: 2/0/64 3275 | | | | Payload: 0x0a02 ... 3276 | | | | 3277 | GET | | | 3278 +------------------>| | Source: ADDR_CLIENT:PORT_CLIENT 3279 | | | | Destination: ADDR_B:PORT_B 3280 | | | | Header: GET (T=CON, Code=0.01, MID=0x7d44) 3281 | | | | Token: 0xb6 3282 | | | | Uri-Path: "gp" 3283 | | | | Uri-Path: "gp1" 3284 | | | | Uri-Path: "log" 3285 | | | | Block2: 1/0/64 3286 | | | | 3287 |<------------------+ | Source: ADDR_B:PORT_B 3288 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3289 | | | | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d44) 3290 | | | | Token: 0xb6 3291 | | | | Block2: 1/1/64 3292 | | | | Payload: 0x0b01 ... 3293 | | | | 3294 | GET | | | 3295 +------------------>| | Source: ADDR_CLIENT:PORT_CLIENT 3296 | | | | Destination: ADDR_C:PORT_B 3297 | | | | Header: GET (T=CON, Code=0.01, MID=0x7d45) 3298 | | | | Token: 0xb7 3299 | | | | Uri-Path: "gp" 3300 | | | | Uri-Path: "gp1" 3301 | | | | Uri-Path: "log" 3302 | | | | Block2: 2/0/64 3303 | | | | 3304 |<------------------+ | Source: ADDR_B:PORT_B 3305 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3306 | | | | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d45) 3307 | | | | Token: 0xb7 3308 | | | | Block2: 2/0/64 3309 | | | | Payload: 0x0b02 ... 3310 | | | | 3311 | GET | | | 3312 +--------------------->| Source: ADDR_CLIENT:PORT_CLIENT 3313 | | | | Destination: ADDR_C:PORT_C 3314 | | | | Header: GET (T=CON, Code=0.01, MID=0x7d46) 3315 | | | | Token: 0xc6 3316 | | | | Uri-Path: "gp" 3317 | | | | Uri-Path: "gp1" 3318 | | | | Uri-Path: "log" 3319 | | | | Block2: 1/0/64 3320 | | | | 3321 |<---------------------+ Source: ADDR_C:PORT_C 3322 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3323 | | | | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d46) 3324 | | | | Token: 0xc6 3325 | | | | Block2: 1/1/64 3326 | | | | Payload: 0x0c01 ... 3327 | | | | 3328 | GET | | | 3329 +--------------------->| Source: ADDR_CLIENT:PORT_CLIENT 3330 | | | | Destination: ADDR_C:PORT_C 3331 | | | | Header: GET (T=CON, Code=0.01, MID=0x7d47) 3332 | | | | Token: 0xc7 3333 | | | | Uri-Path: "gp" 3334 | | | | Uri-Path: "gp1" 3335 | | | | Uri-Path: "log" 3336 | | | | Block2: 2/0/64 3337 | | | | 3338 |<---------------------+ Source: ADDR_C:PORT_C 3339 | 2.05 | | | Destination: ADDR_CLIENT:PORT_CLIENT 3340 | | | | Header: 2.05 (T=ACK, Code=2.05, MID=0x7d47) 3341 | | | | Token: 0xc7 3342 | | | | Block2: 2/0/64 3343 | | | | Payload: 0x0c02 ... 3344 | | | | 3346 Figure 18: Example of Non-confirmable group request starting a 3347 blockwise transfer, followed by Non-confirmable Responses with 3348 the first block. The transfer continues over confirmable unicast 3349 exchanges 3351 Appendix C. Document Updates 3353 RFC EDITOR: PLEASE REMOVE THIS SECTION. 3355 C.1. Version -05 to -06 3357 * Harmonized use of "group URI". 3359 * Clarifications about different group types. 3361 * Revised methods to perform group naming. 3363 * Revised methods to discover application groups and CoAP groups. 3365 * Explicit difference between "authentication credential" and 3366 "public key". 3368 * Added examples of application group naming. 3370 * Added examples of application/CoAP group discovery. 3372 * Added examples of message exchanges. 3374 * Reference to draft-mattsson-core-coap-attacks replaced with 3375 reference to draft-mattsson-t2trg-amplification-attacks. 3377 * Editorial improvements. 3379 C.2. Version -04 to -05 3381 * Clarified changes to other documents. 3383 * Clarified relation between different group types. 3385 * Clarified discovery of application groups. 3387 * Discussed methods to express application group names in requests. 3389 * Revised and extended text on the NoSec mode and amplification 3390 attacks. 3392 * Rephrased backward/forward security as properties. 3394 * Removed appendix on Multi-ETag Option for response revalidation. 3396 * Editorial improvements. 3398 C.3. Version -03 to -04 3400 * Multi-ETag Option for response revalidation moved to appendix. 3402 * ETag Option usage added. 3404 * Q-Block Options added in the block-wise transfer section. 3406 * Caching at proxies moved to draft-tiloca-core-groupcomm-proxy. 3408 * Client-Proxy response revalidation with the Group-ETag Option 3409 moved to draft-tiloca-core-groupcomm-proxy. 3411 * Security considerations on amplification attacks. 3413 * Generalized transport protocols to include others than UDP/IP 3414 multicast; and security protocols other than Group OSCORE. 3416 * Overview of security cases with proxies. 3418 * Editorial improvements. 3420 C.4. Version -02 to -03 3422 * Multiple responses from same server handled at the application. 3424 * Clarifications about issues with forward-proxies. 3426 * Operations for reverse-proxies. 3428 * Caching of responses at proxies. 3430 * Client-Server response revalidation, with Multi-ETag Option. 3432 * Client-Proxy response revalidation, with the Group-ETag Option. 3434 C.5. Version -01 to -02 3436 * Clarified relation between security groups and application groups. 3438 * Considered also FETCH for requests over IP multicast. 3440 * More details on Observe re-registration. 3442 * More details on Proxy intermediaries. 3444 * More details on servers changing port number in the response. 3446 * Usage of the Uri-Host Option to indicate an application group. 3448 * Response suppression based on classes of error codes. 3450 C.6. Version -00 to -01 3452 * Clarifications on group memberships for the different group types. 3454 * Simplified description of Token reusage, compared to the unicast 3455 case. 3457 * More details on the rationale for response suppression. 3459 * Clarifications of creation and management of security groups. 3461 * Clients more knowledgeable than proxies about stopping receiving 3462 responses. 3464 * Cancellation of group observations. 3466 * Clarification on multicast scope to use. 3468 * Both the group mode and pairwise mode of Group OSCORE are 3469 considered. 3471 * Updated security considerations. 3473 * Editorial improvements. 3475 Acknowledgments 3477 The authors sincerely thank Christian Amsuess, Carsten Bormann, 3478 Thomas Fossati, Rikard Hoeglund, Jaime Jimenez, John Mattsson and Jim 3479 Schaad for their comments and feedback. 3481 The work on this document has been partly supported by VINNOVA and 3482 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 3483 (Grant agreement 952652). 3485 Authors' Addresses 3487 Esko Dijk 3488 IoTconsultancy.nl 3489 \________________\ 3490 Utrecht 3491 Netherlands 3492 Email: esko.dijk@iotconsultancy.nl 3494 Chonggang Wang 3495 InterDigital 3496 1001 E Hector St, Suite 300 3497 Conshohocken, PA 19428 3498 United States 3499 Email: Chonggang.Wang@InterDigital.com 3501 Marco Tiloca 3502 RISE AB 3503 Isafjordsgatan 22 3504 SE-16440 Stockholm Kista 3505 Sweden 3506 Email: marco.tiloca@ri.se