idnits 2.17.1 draft-ietf-core-groupcomm-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7252], [RFC7641], [RFC7390]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-09 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-08 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-24 == Outdated reference: A later version (-02) exists of draft-tiloca-ace-oscore-gm-admin-01 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-00 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group E. Dijk 3 Internet-Draft IoTconsultancy.nl 4 Obsoletes: 7390 (if approved) C. Wang 5 Updates: 7252, 7641 (if approved) InterDigital 6 Intended status: Standards Track M. Tiloca 7 Expires: January 14, 2021 RISE AB 8 July 13, 2020 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-ietf-core-groupcomm-bis-01 13 Abstract 15 This document specifies the use of the Constrained Application 16 Protocol (CoAP) for group communication, using UDP/IP multicast as 17 the underlying data transport. Both unsecured and secured CoAP group 18 communication are specified. Security is achieved by use of the 19 Group Object Security for Constrained RESTful Environments (Group 20 OSCORE) protocol. The target application area of this specification 21 is any group communication use cases that involve resource- 22 constrained networks. The most common of such use cases are also 23 discussed. This document replaces [RFC7390] and updates [RFC7252] 24 and [RFC7641]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 14, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. General Group Communication Operation . . . . . . . . . . . . 5 64 2.1. Group Definition . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Group Configuration . . . . . . . . . . . . . . . . . . . 8 66 2.2.1. Group Naming . . . . . . . . . . . . . . . . . . . . 8 67 2.2.2. Group Creation and Membership . . . . . . . . . . . . 9 68 2.2.3. Group Discovery . . . . . . . . . . . . . . . . . . . 10 69 2.2.4. Group Maintenance . . . . . . . . . . . . . . . . . . 10 70 2.3. CoAP Usage . . . . . . . . . . . . . . . . . . . . . . . 11 71 2.3.1. Request/Response Model . . . . . . . . . . . . . . . 11 72 2.3.2. Port and URI Path Selection . . . . . . . . . . . . . 14 73 2.3.3. Proxy Operation . . . . . . . . . . . . . . . . . . . 15 74 2.3.4. Congestion Control . . . . . . . . . . . . . . . . . 16 75 2.3.5. Observing Resources . . . . . . . . . . . . . . . . . 18 76 2.3.6. Block-Wise Transfer . . . . . . . . . . . . . . . . . 19 77 2.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . 20 78 2.4.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 20 79 2.4.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 20 80 2.4.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 21 81 2.5. Interworking with Other Protocols . . . . . . . . . . . . 21 82 2.5.1. MLD/MLDv2/IGMP/IGMPv3 . . . . . . . . . . . . . . . . 21 83 2.5.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 2.5.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 3. Unsecured Group Communication . . . . . . . . . . . . . . . . 23 86 4. Secured Group Communication using Group OSCORE . . . . . . . 23 87 4.1. Secure Group Maintenance . . . . . . . . . . . . . . . . 25 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 89 5.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 26 90 5.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 26 91 5.2.1. Group Key Management . . . . . . . . . . . . . . . . 27 92 5.2.2. Source Authentication . . . . . . . . . . . . . . . . 27 93 5.2.3. Countering Attacks . . . . . . . . . . . . . . . . . 28 94 5.3. Replay of Non Confirmable Messages . . . . . . . . . . . 29 95 5.4. Use of CoAP No-Response Option . . . . . . . . . . . . . 30 96 5.5. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 5.6. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 5.7. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 31 99 5.7.1. General Monitoring . . . . . . . . . . . . . . . . . 31 100 5.7.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 31 101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 102 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 7.1. Normative References . . . . . . . . . . . . . . . . . . 32 104 7.2. Informative References . . . . . . . . . . . . . . . . . 34 105 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 36 106 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 36 107 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 37 108 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 37 109 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 38 110 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 38 111 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 38 112 A.2.2. Device Group Status Request . . . . . . . . . . . . . 38 113 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 39 114 A.2.4. Network-wide / Group Notification . . . . . . . . . . 39 115 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 39 116 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 40 117 B.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 40 118 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 121 1. Introduction 123 This document specifies group communication using the Constrained 124 Application Protocol (CoAP) [RFC7252] together with UDP/IP multicast. 125 CoAP is a RESTful communication protocol that is used in resource- 126 constrained nodes, and in resource-constrained networks where packet 127 sizes should be small. This area of use is summarized as Constrained 128 RESTful Environments (CoRE). 130 One-to-many group communication can be achieved in CoAP, by a client 131 using UDP/IP multicast data transport to send multicast CoAP request 132 messages. In response, each server in the addressed group sends a 133 response message back to the client over UDP/IP unicast. Notable 134 CoAP implementations supporting group communication include the 135 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 136 Foundation and the "Implementation of CoAP Server & Client in Go" 137 [Go-OCF] from the Open Connectivity Foundation (OCF). 139 Both unsecured and secured CoAP group communication over UDP/IP 140 multicast are specified in this document. Security is achieved by 141 using Group Object Security for Constrained RESTful Environments 142 (Group OSCORE) [I-D.ietf-core-oscore-groupcomm], which in turn builds 143 on Object Security for Constrained Restful Environments (OSCORE) 145 [RFC8613]. This method provides end-to-end application-layer 146 security protection of CoAP messages, by using CBOR Object Signing 147 and Encryption (COSE) [RFC7049][I-D.ietf-cose-rfc8152bis-struct][I-D. 148 ietf-cose-rfc8152bis-algs]. 150 All guidelines in [RFC7390] are updated by this document, which 151 replaces and obsoletes [RFC7390]. Furthermore, this document updates 152 [RFC7252], by adding security for CoAP group communication and 153 updates [RFC7641], by adding the multicast usage of CoAP Observe. 155 All sections in the body of this document are normative, while 156 appendices are informative. For additional background about use 157 cases for CoAP group communication in resource-constrained devices 158 and networks, see Appendix A. 160 1.1. Scope 162 For group communication, only solutions that use CoAP over UDP/IP 163 multicast are in the scope of this document. There are alternative 164 methods to achieve group communication using CoAP, for example 165 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 166 broker server that CoAP clients access via unicast communication. 167 These methods may be usable for the same or similar use cases as are 168 targeted in this document. 170 Furthermore, this document defines Group OSCORE 171 [I-D.ietf-core-oscore-groupcomm] as the default group communication 172 security solution for CoAP. Security solutions for group 173 communication and configuration other than Group OSCORE are not in 174 scope. General principles for secure group configuration are in 175 scope. 177 1.2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 This specification requires readers to be familiar with CoAP 186 terminology [RFC7252]. Terminology related to group communication is 187 defined in Section 2.1. 189 Furthermore, "Security material" refers to any security keys, 190 counters or parameters required to participate in secure group 191 communication with other devices that share the same security 192 material. 194 2. General Group Communication Operation 196 The general operation of group communication, applicable for both 197 unsecured and secured operation, is specified in this section by 198 going through the stack from top to bottom. First, different group 199 types are defined in Section 2.1. Group configuration (e.g. group 200 creation and maintenance which are usually done by an application, 201 user or commissioning entity) is considered next in Section 2.2. 202 Then the use of CoAP for group communication including support for 203 protocol extensions (block-wise transfer, Observe) follows in 204 Section 2.3. How CoAP group messages are carried over various 205 transport layers is the subject of Section 2.4. Finally, Section 2.5 206 covers the interworking of CoAP group communication with other 207 protocols that may operate in the same network. 209 2.1. Group Definition 211 Three types of groups and their mutual relations are defined in this 212 section: CoAP group, application group, and security group. 214 A CoAP group is defined as a set of CoAP endpoints, where each 215 endpoint is configured to receive CoAP multicast messages that are 216 sent to the group's associated IP multicast address and UDP port. An 217 endpoint may be a member of multiple CoAP groups by subscribing to 218 multiple IP multicast groups. Group membership(s) of an endpoint may 219 dynamically change over time. A device sending a CoAP multicast 220 message to a group is not necessarily itself a member of this group: 221 it is a member only if it also has a CoAP endpoint listening to the 222 group's associated IP multicast address and UDP port. A CoAP group 223 can be encoded within a Group URI, i.e. a CoAP URI that has the 224 "coap" scheme and includes in the authority part either an IP 225 multicast address or a group hostname (e.g., a Group Fully Qualified 226 Domain Name (FQDN)) that can be resolved to an IP multicast address. 227 A Group URI also contains an optional UDP port number in the 228 authority part. Group URIs follow the regular CoAP URI syntax (see 229 Section 6 of [RFC7252]). 231 Besides CoAP groups, that have relevance at the level of IP networks 232 and CoAP endpoints, there are also application groups. An 233 application group is a set of CoAP server endpoints that share a 234 common set of CoAP resources. An endpoint may be a member of 235 multiple application groups. An application group has relevance at 236 the application level - for example an application group could denote 237 all lights in an office room or all sensors in a hallway. A client 238 endpoint that sends a group communication message to an application 239 group is not necessarily itself a member of this application group. 240 There can be a one-to-one or a one-to-many relation between a CoAP 241 group and application group(s). An application group is optionally 242 identified explicitly in the path component or query component of a 243 Group URI. If not explicitly identified, the application group is 244 specified implicitly in a Group URI by choice of CoAP group and 245 resource path. 247 For secure group communication, a security group is required. A 248 security group is a group of endpoints that share the same security 249 material, such that they can mutually exchange secured messages and 250 verify secured messages. So, a client endpoint needs to be a member 251 of a security group in order to send a valid secured group 252 communication message to this group. An endpoint may be a member of 253 multiple security groups. There can be a one-to-one or a one-to-many 254 relation between security groups and CoAP groups. Also, there can be 255 a one-to-one or a one-to-many relation between security groups and 256 application groups. A special security group named "NoSec" 257 identifies group communication without any security at the transport 258 layer and/or application layer. 260 Using the above group type definitions, a CoAP group communication 261 message sent by an endpoint can be represented as a tuple that 262 contains one instance of each group type: 264 (application group, CoAP group, security group) 266 Figure 1 summarizes the relations between the different types of 267 groups described above in UML class diagram notation. The items in 268 square brackets are optionally defined. 270 +------------------------+ +------------------+ 271 | Application group | | CoAP group | 272 |........................| |..................| 273 | | | | 274 | URI path / resource(s) +-----------------+ IP mcast address | 275 | [ URI query string ] | 1...N 1 | UDP port | 276 | [ group name ] | | | 277 | | | | 278 +-------------+----------+ +---------+--------+ 279 | 1...N | 1...N 280 | | 281 | | 282 | | 1...N 283 | +----------+----------+ 284 | | Security group | 285 | |.....................| 286 | | | 287 \---------------------------+ Security group name | 288 1...N | Security material | 289 | | 290 +---------------------+ 292 Figure 1: Relation Among Different Group Types 294 Figure 2 provides a deployment example of the relations between the 295 different types of groups. It shows six CoAP servers (Srv1-Srv6) and 296 their respective resources hosted (/resX). There are three 297 application groups (1, 2, 3) and two security groups (1, 2). 298 Security Group 1 is used by both Application Group 1 and 2. Three 299 clients (Cli1, Cli2, Cli3) are configured with security material for 300 Security Group 1. One cient (Cli4) is configured with security 301 material for Security Group 2. All the shown application groups use 302 the same CoAP group (not shown in the figure), i.e. one specific 303 multicast IP address and UDP port on which all the shown resources 304 are hosted for each server. 306 _________________________________ _________________________________ 307 / \ / \ 308 | +---------------------+ | | +---------------------+ | 309 | | Application Group 1 | | | | Application Group 3 | Cli2 | 310 | | | | | | | | 311 | Cli1 | Srv1 Srv2 Srv3 | | | | Srv5 Srv6 | Cli4 | 312 | | /resA /resA /resA | | | | /resC /resC | | 313 | Cli2 +---------------------+ | | | /resD /resD | | 314 | | | +---------------------+ | 315 | Cli3 Security Group 1 | | | 316 | | | Security Group 2 | 317 | +---------------------+ | \_________________________________/ 318 | | Application Group 2 | | 319 | | | | 320 | | Srv1 Srv4 | | 321 | | /resB /resB | | 322 | +---------------------+ | 323 \_________________________________/ 325 Figure 2: Deployment Example of Different Group Types 327 2.2. Group Configuration 329 2.2.1. Group Naming 331 A CoAP group is identified and named by the authority component in 332 the Group URI, which includes host and optional port number. It is 333 recommended to configure an endpoint by default with an IP multicast 334 address literal, instead of a hostname. This is because DNS 335 infrastructure may not be deployed in many constrained networks. In 336 case a group hostname is configured, it can be uniquely mapped to an 337 IP multicast address via DNS resolution - if DNS client functionality 338 is available in the clients and the DNS service is supported in the 339 network. Some examples of hierarchical CoAP group FQDN naming (and 340 scoping) for a building control application are shown in Section 2.2 341 of [RFC7390]. 343 An application group can be named in many ways through different 344 types of identifiers, such as numbers, URIs or other strings. An 345 application group name or identifier, if explicitly encoded, is 346 typically included in the path component or query component of a 347 Group URI. Appendix A of [I-D.ietf-core-resource-directory] shows 348 registration of application groups into a Resource Directory, along 349 with the CoAP group it maps to. 351 A security group is identified by a stable and invariant string used 352 as group name, which is generally not related with other kind of 353 group identifiers, specific to the chosen security solution. The 354 "NoSec" security group is typically identified by the absence of any 355 name or identifier, and of any security-related data structures in 356 the CoAP message. 358 2.2.2. Group Creation and Membership 360 To create a CoAP group, a configuring entity defines an IP multicast 361 address (or hostname) for the group and optionally a UDP port number 362 in case it differs from the default CoAP port 5683. Then, it 363 configures one or more devices as listeners to that IP multicast 364 address, with a CoAP endpoint listening on the group's associated UDP 365 port. These endpoints/devices are the group members. The 366 configuring entity can be, for example, a local application with pre- 367 configuration, a user, a software developer, a cloud service, or a 368 local commissioning tool. Also, the devices sending CoAP requests to 369 the group in the role of CoAP client need to be configured with the 370 same information, even though they are not necessarily group members. 371 One way to configure a client is to supply it with a CoAP Group URI. 372 The IETF does not define a mandatory, standardized protocol to 373 accomplish CoAP group creation. [RFC7390] defines an experimental 374 protocol for configuration of group membership for unsecured group 375 communication, based on JSON-formatted configuration resources. 377 To create an application group, a configuring entity may configure a 378 resource (name) or set of resources on a CoAP endpoint, such that a 379 request sent by a configured CoAP client with a configured URI path 380 will be processed by one or more CoAP servers that have the same URI 381 path configured - i.e. the application group members. 383 To create a security group, a configuring entity defines a set of 384 group properties including the crytpographic algorithms and 385 parameters used in the group, as well as additional information 386 relevant throughout the group life-cycle, including the group name 387 and description. This task MAY be entrusted to a dedicated 388 administrator, that interacts with a Group Manager as defined in 389 Section 4. After that, security material to protect group 390 communications has to be generated, as compatible with the specified 391 group configuration. 393 To participate in a security group, CoAP endpoints have to be 394 configured with the group security material used to protect 395 communications in the associated application/CoAP groups. The part 396 of the process that involves secure distribution of group security 397 material MAY use standardized communication with a Group Manager as 398 defined in Section 4. For unsecure group communication using the 399 "NoSec" security group, any CoAP endpoint may become a group member 400 at any time: there is no (central) configuring entity that needs to 401 provide the security material for this group. This means that group 402 creation and membership cannot be tightly controlled for the "NoSec" 403 group. 405 The configuration of groups and membership may be performed at 406 different moments in the life-cycle of a device; for example during 407 product (software) creation, in the factory, at a reseller, on-site 408 during first deployment, or on-site during a system reconfiguration 409 operation. 411 2.2.3. Group Discovery 413 It is possible for CoAP endpoints to discover application groups as 414 well as CoAP groups, by using the RD-Groups usage pattern of the CoRE 415 Resource Directory (RD), as defined in Appendix A of 416 [I-D.ietf-core-resource-directory]. In particular, an application 417 group can be registered to the RD, specifying the reference IP 418 multicast address, hence its associated CoAP group. The registration 419 is typically performed by a Commissioning Tool. Later on, CoAP 420 endpoints can discover the registered application groups and related 421 CoAP group, by using the lookup interface of the RD. 423 CoAP endpoints can also discover application groups by performing a 424 multicast discovery query using the /.well-known/core resource. Such 425 a request may be sent to a known CoAP group multicast address 426 associated to application group(s), or to the All CoAP Nodes 427 multicast address. 429 When secure communication is provided with Group OSCORE (see 430 Section 4), the approach described in 431 [I-D.tiloca-core-oscore-discovery] and also based on the RD can be 432 used, in order to discover the security group to join. 434 In particular, the responsible OSCORE Group Manager registers its own 435 security groups to the RD, as links to its own corresponding 436 resources for joining the security groups 437 [I-D.ietf-ace-key-groupcomm-oscore]. Later on, CoAP endpoints can 438 discover the registered security groups and related application 439 groups, by using the lookup interface of the RD, and then join the 440 security group through the respective Group Manager. 442 2.2.4. Group Maintenance 444 Maintenance of a group includes any necessary operations to cope with 445 changes in a system, such as: adding group members, removing group 446 members, changing group security material, reconfiguration of UDP 447 port and/or IP multicast address, reconfiguration of the Group URI, 448 renaming of application groups, splitting of groups, or merging of 449 groups. 451 For unsecured group communication (see Section 3), addition/removal 452 of CoAP group members is simply done by configuring these devices to 453 start/stop listening to the group IP multicast address on the group's 454 UDP port. 456 For secured group communication (see Section 4), the protocol Group 457 OSCORE [I-D.ietf-core-oscore-groupcomm] is mandatory to implement. 458 When using Group OSCORE, CoAP endpoints participating in group 459 communication are also members of a corresponding OSCORE security 460 group, and thus share common security material. Additional related 461 maintenance operations are discussed in Section 4.1. 463 2.3. CoAP Usage 465 2.3.1. Request/Response Model 467 A CoAP client is an endpoint able to transmit CoAP requests and 468 receive CoAP responses. Since the underlying UDP transport supports 469 multiplexing by means of UDP port number, there can be multiple 470 independent CoAP clients operational on a single host. On each UDP 471 port, an independent CoAP client can be hosted. Each independent 472 CoAP client sends requests that use the associated endpoint's UDP 473 port number as the UDP source port of the request. 475 All CoAP requests that are sent via IP multicast MUST be Non- 476 confirmable (Section 8.1 of [RFC7252]). The Message ID in an IP 477 multicast CoAP message is used for optional message deduplication by 478 both clients and servers, as detailed in Section 4.5 of [RFC7252]. 480 A server sends back a unicast response to the CoAP group request - 481 but the server MAY suppress the response for various reasons 482 (Section 8.2 of [RFC7252]). This document adds the requirement that 483 a server SHOULD suppress the response in case of error or in case 484 there is nothing useful to respond, unless the application requires 485 such a response to be made. The unicast responses received by the 486 CoAP client may be a mixture of success (e.g., 2.05 Content) and 487 failure (e.g., 4.04 Not Found) codes, depending on the individual 488 server processing results. 490 The CoAP No-Response Option [RFC7967] can be used by a client to 491 influence the default response suppression on the server side. It is 492 RECOMMENDED for a server to implement this option only on selected 493 resources where it is useful in the application context. If the 494 Option is supported on a resource, it MUST override the default 495 response suppression of that resource. 497 Any default response suppression by a server SHOULD be performed in a 498 consistent way, such that if a request on a resource produces a 499 Response Code and this response is not suppressed, then a later 500 request on the same resource that produces a response with the same 501 Response Code is also not suppressed. 503 A CoAP client MAY repeat a multicast request using the same Token 504 value and same Message ID value, in order to ensure that enough (or 505 all) group members have been reached with the request. This is 506 useful in case a number of group members did not respond to the 507 initial request and the client suspects that the request did not 508 reach these group members. However, in case one or more servers did 509 receive the initial request but the response to that request was 510 lost, this repeat does not help to retrieve the lost response(s) if 511 the server(s) implement the optional Message ID based deduplication 512 (Section 4.5 of [RFC7252]). 514 A CoAP client MAY also repeat a multicast request using the same 515 Token value and a different Message ID, in which case all servers 516 that received the initial request will again process the repeated 517 request since it appears within a new CoAP message. This is useful 518 in case a client suspects that one or more response(s) to its 519 original request were lost and the client needs to collect more, or 520 even all, responses from group members, even if this comes at the 521 cost of the overhead of certain group members responding twice (once 522 to the original request, and once to the repeated request with 523 different Message ID). 525 The CoAP client can distinguish the origin of multiple server 526 responses by the source IP address of the UDP message containing the 527 CoAP response and/or any other available application-specific source 528 identifiers contained in the CoAP response, such as an application- 529 level unique ID associated to the server. If secure communication is 530 provided with Group OSCORE (see Section 4), additional security- 531 related identifiers enable the client to retrieve the right security 532 material for decrypting each response and authenticating its source. 534 While processing a response, the source endpoint of the response is 535 not exactly matched to the destination endpoint of the request, since 536 for a multicast request these will never match. This is specified in 537 Section 8.2 of [RFC7252]. In case a single client has sent multiple 538 group requests and concurrent CoAP transactions are ongoing, the 539 responses received by that client are matched to a request using the 540 Token value. Due to UDP level multiplexing, the UDP destination port 541 of the response MUST match to the client endpoint's UDP port value, 542 i.e. to the UDP source port of the client's request. 544 For multicast CoAP requests, there are additional constraints on the 545 reuse of Token values at the client, compared to the unicast case 546 defined in [RFC7252] and updated by [I-D.ietf-core-echo-request-tag]. 548 Since for multicast CoAP the number of responses is not bound a 549 priori, the client cannot use the reception of a response as a 550 trigger to "free up" a Token value for reuse. Reusing a Token value 551 too early could lead to incorrect response/request matching on the 552 client, and would be a protocol error. Therefore, the time between 553 reuse of Token values used in multicast requests MUST be greater 554 than: 556 MIN_TOKEN_REUSE_TIME = (NON_LIFETIME + MAX_LATENCY + 557 MAX_SERVER_RESPONSE_DELAY) 559 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 560 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 561 in [RFC7390], that is: the expected maximum response delay over all 562 servers that the client can send a multicast request to. This delay 563 includes the maximum Leisure time period as defined in Section 8.2 of 564 [RFC7252]. However, CoAP does not define a time limit for the server 565 response delay. Using the default CoAP parameters, the Token reuse 566 time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. 567 A preferred solution to meet this requirement is to generate a new 568 unique Token for every new multicast request, such that a Token value 569 is never reused. If a client has to reuse Token values for some 570 reason, and also MAX_SERVER_RESPONSE_DELAY is unknown, then using 571 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 572 The time between Token reuses is in that case set to a value greater 573 than 500 seconds. 575 When securing Group CoAP communications with Group OSCORE 576 [I-D.ietf-core-oscore-groupcomm], secure binding between requests and 577 responses is ensured (see Section 4). Thus, a client may reuse a 578 Token value after it has been freed up, as discussed above for the 579 multicast case and considering a reuse time greater than 580 MIN_TOKEN_REUSE_TIME. If an alternative security protocol for Group 581 CoAP is defined in the future and it does not ensure secure binding 582 between requests and responses, a client MUST follow the Token 583 processing requirements for the unicast case discussed above, as 584 defined in [I-D.ietf-core-echo-request-tag]. 586 Another method to more easily meet the above constraint is to 587 instantiate multiple CoAP clients at multiple UDP ports on the same 588 host. The Token values only have to be unique within the context of 589 a single CoAP client, so using multiple clients can make it easier to 590 meet the constraint. 592 Since a client sending a multicast request with a Token T will accept 593 multiple responses with the same Token T, there is a risk that the 594 same server sends multiple responses with the same Token T back to 595 the client. For example, this server might not implement the 596 optional CoAP message deduplication based on Message ID, or it might 597 be a malicious/compromised server acting out of specification. To 598 mitigate issues with multiple responses from one server bound to a 599 same multicast request, the client has to ensure that, as long as the 600 the CoAP Token used for a multicast request is retained, at most one 601 response to that request per server is accepted, with the exception 602 of Observe notifications [RFC7641] (see Section 2.3.5). 604 To this end, upon receiving a response corresponding to a multicast 605 request, the client MUST perform the following actions. First, the 606 client checks whether it previously received a valid response to this 607 request from the same originating server of the just-received 608 response. If the check yields a positive match and the response is 609 not an Observe notification (i.e., it does not include an Observe 610 option), the client SHALL stop processing the response. Upon 611 eventually freeing up the Token value of a multicast request for 612 possible reuse, the client MUST also delete the list of responding 613 servers associated to that request. 615 2.3.2. Port and URI Path Selection 617 A server that is a member of a CoAP group listens for CoAP messages 618 on the group's IP multicast address, usually on the CoAP default UDP 619 port 5683, or another non-default UDP port if configured. Regardless 620 of the method for selecting the port number, the same port number 621 MUST be used across all CoAP servers that are members of a CoAP group 622 and across all CoAP clients performing the requests to that group. 623 The URI Path used in the request is preferably a path that is known 624 to be supported across all group members. However there are valid 625 use cases where a request is known to be successful for a subset of 626 the CoAP group, for example only members of a specific application 627 group, while those group members for which the request is 628 unsuccessful (for example because they are outside the application 629 group) either ignore the multicast request or respond with an error 630 status code. 632 One way to create multiple CoAP groups is using different UDP ports 633 with the same IP multicast address, in case the devices' network 634 stack only supports a limited number of CoAP group memberships. 635 However, it must be taken into account that this incurs additional 636 processing overhead on each CoAP server participating in at least one 637 of these groups: messages to groups that are not of interest to the 638 node are only discarded at the higher transport (UDP) layer instead 639 of directly at the network (IP) layer. 641 Port 5684 is reserved for DTLS-secured CoAP and MUST NOT be used for 642 any CoAP group communication. 644 For a CoAP server node that supports resource discovery as defined in 645 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 646 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 647 group as detailed in Section 2.4. 649 2.3.3. Proxy Operation 651 CoAP enables a client to request a forward-proxy to process a CoAP 652 request on its behalf, as described in Section 5.7.2 and 8.2.2 of 653 [RFC7252]. For this purpose, the client specifies either the request 654 group URI as a string in the Proxy-URI option or it uses the Proxy- 655 Scheme option with the group URI constructed from the usual Uri-* 656 options. The forward-proxy then resolves the group URI to a 657 destination CoAP group, multicasts the CoAP request, receives the 658 responses and forwards all the individual (unicast) responses back to 659 the client. 661 However, there are certain issues and limitations with this approach: 663 o The CoAP client component that sent a unicast CoAP request to the 664 proxy may be expecting only one (unicast) response, as usual for a 665 CoAP unicast request. Instead, it receives multiple (unicast) 666 responses, potentially leading to fault conditions in the 667 component or to discarding any received responses following the 668 first one. This issue may occur even if the application calling 669 the CoAP client component is aware that the forward-proxy is going 670 to execute a CoAP group URI request. 672 o Each individual CoAP response received by the client will appear 673 to originate (based on its IP source address) from the CoAP Proxy, 674 and not from the server that produced the response. This makes it 675 impossible for the client to identify the server that produced 676 each response, unless the server identity is contained as a part 677 of the response payload or inside a CoAP Option in the response. 679 A method based on this approach and addressing the issues raised 680 above is defined in [I-D.tiloca-core-groupcomm-proxy]. 682 An alternative solution is for the proxy to collect all the 683 individual (unicast) responses to a CoAP group request and then send 684 back only a single (aggregated) response to the client. However, 685 this solution brings up new issues: 687 o The proxy does not know how many members there are in the CoAP 688 group or how many group members will actually respond. Also, the 689 proxy does not know for how long to collect responses before 690 sending back the aggregated response to the client. A CoAP client 691 that is not using a Proxy might face the same problems in 692 collecting responses to a multicast request. However, the client 693 itself would typically have application-specific rules or 694 knowledge on how to handle this situation, while an application- 695 agnostic CoAP Proxy would typically not have this knowledge. For 696 example, a CoAP client could monitor incoming responses and use 697 this information to decide how long to continue collecting 698 responses - which is something a proxy cannot do. 700 o There is no default format defined in CoAP for aggregation of 701 multiple responses into a single response. Such a format could be 702 standardized based on, for example, the multipart content-format 703 [RFC8710]. 705 Due to the above issues, it is RECOMMENDED that a CoAP Proxy only 706 processes a group URI request if it is explicitly enabled to do so. 707 The default response (if the function is not explicitly enabled) to a 708 group URI request is 5.01 (Not Implemented). Furthermore, a proxy 709 SHOULD be explicitly configured (e.g. by white-listing and/or client 710 authentication) to allow proxied CoAP multicast requests only from 711 specific client(s). 713 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 714 specified in Section 8.4 and 10.1 of [RFC8075]. In this case, the 715 "application/http" media type is used to let the proxy return 716 multiple CoAP responses - each translated to a HTTP response - back 717 to the HTTP client. Of course, in this case the HTTP client sending 718 a group URI to the proxy needs to be aware that it is going to 719 receive this format, and needs to be able to decode it into the 720 responses of multiple CoAP servers. Also, the IP source address of 721 each CoAP response cannot be determined anymore from the application/ 722 http response. 724 2.3.4. Congestion Control 726 CoAP group requests may result in a multitude of responses from 727 different nodes, potentially causing congestion. Therefore, both the 728 sending of IP multicast requests and the sending of the unicast CoAP 729 responses to these multicast requests should be conservatively 730 controlled. 732 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 733 the following measures: 735 o A server may choose not to respond to an IP multicast request if 736 there is nothing useful to respond to, e.g., error or empty 737 response (see Section 8.2 of [RFC7252]). 739 o A server should limit the support for IP multicast requests to 740 specific resources where multicast operation is required 741 (Section 11.3 of [RFC7252]). 743 o An IP multicast request MUST be Non-confirmable (Section 8.1 of 744 [RFC7252]). 746 o A response to an IP multicast request SHOULD be Non-confirmable 747 (Section 5.2.3 of [RFC7252]). 749 o A server does not respond immediately to an IP multicast request 750 and should first wait for a time that is randomly picked within a 751 predetermined time interval called the Leisure (Section 8.2 of 752 [RFC7252]). 754 Additional guidelines to reduce congestion risks defined in this 755 document are as follows: 757 o A server in a constrained network should only support group 758 communication GET for resources that are small. This can consist, 759 for example, in having the payload of the response as limited to 760 approximately 5% of the IP Maximum Transmit Unit (MTU) size, so 761 that it fits into a single link-layer frame in case IPv6 over Low- 762 Power Wireless Personal Area Networks (6LoWPAN) (see Section 4 of 763 [RFC4944]) is used. 765 o A server SHOULD minimize the payload size of a response to a 766 multicast GET on "/.well-known/core" by using hierarchy in 767 arranging link descriptions for the response. An example of this 768 is given in Section 5 of [RFC6690]. 770 o A server MAY minimize the payload size of a response to a 771 multicast GET (e.g., on "/.well-known/core") by using CoAP block- 772 wise transfers [RFC7959] in case the payload is long, returning 773 only a first block of the CoRE Link Format description. For this 774 reason, a CoAP client sending an IP multicast CoAP request to 775 "/.well-known/core" SHOULD support block-wise transfers. See also 776 Section 2.3.6. 778 o A client SHOULD be configured to use CoAP groups with the smallest 779 possible IP multicast scope that fulfills the application needs. 780 As an example, site-local scope is always preferred over global 781 scope IP multicast if this fulfills the application needs. 782 Similarly, realm-local scope is always preferred over site-local 783 scope if this fulfills the application needs. 785 2.3.5. Observing Resources 787 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 788 that allows a CoAP client to retrieve a representation of a resource 789 and automatically keep this representation up-to-date over a longer 790 period of time. The client gets notified when the representation has 791 changed. [RFC7641] does not mention whether the Observe Option can 792 be combined with CoAP multicast. This section updates [RFC7641] with 793 the use of the Observe Option in a CoAP multicast GET request and 794 defines normative behavior for both client and server. 796 Multicast Observe is a useful way to start observing a particular 797 resource on all members of a CoAP group at the same time. Group 798 members that do not have this particular resource or do not allow the 799 GET method on it will either respond with an error status - 4.04 Not 800 Found or 4.05 Method Not Allowed, respectively - or will silently 801 suppress the response following the rules of Section 2.3.1, depending 802 on server-specific configuration. 804 A client that sends a multicast GET request with the Observe Option 805 MAY repeat this request using the same Token value and the same 806 Observe Option value, in order to ensure that enough (or all) members 807 of the CoAP group have been reached with the request. This is useful 808 in case a number of group members did not respond to the initial 809 request. The client MAY additionally use the same Message ID in the 810 repeated request to avoid that group members that had already 811 received the initial request would respond again. Note that using 812 the same Message ID in a repeated request will not be helpful in case 813 of loss of a response message, since the server that responded 814 already will consider the repeated request as a duplicate message. 815 On the other hand, if the client uses a different, fresh Message ID 816 in the repeated request, then all the group members that receive this 817 new message will typically respond again, which increases the network 818 load. 820 A client that sent a multicast GET request with the Observe Option 821 MAY follow up by sending a new unicast CON request with the same 822 Token value and same Observe Option value to a particular server, in 823 order to ensure that the particular server receives the request. 824 This is useful in case a specific group member, that was expected to 825 respond to the initial group request, did not respond to the initial 826 request. The client in this case always uses a Message ID that 827 differs from the initial multicast message. 829 In the above client behaviors, the Token value is kept identical to 830 the initial request to avoid that a client is included in more than 831 one entry in the list of observers (Section 4.1 of [RFC7641]). 833 Before repeating a request as specified above, the client SHOULD wait 834 for at least the expected round-trip time plus the Leisure time 835 period defined in Section 8.2 of [RFC7252], to give the server time 836 to respond. 838 A server that receives a GET request with the Observe Option, for 839 which request processing is successful, SHOULD respond to this 840 request and not suppress the response. A server that adds a client 841 to the list of observers for a resource due to an Observe request 842 MUST respond to this request and not suppress it. 844 A server SHOULD have a mechanism to verify liveness of its observing 845 clients and the continued interest of these clients in receiving the 846 observe notifications. This can be implemented by sending 847 notifications occassionally using a Confirmable message. See 848 Section 4.5 of [RFC7641] for details. This requirement overrides the 849 regular behavior of sending Non-Confirmable notifications in response 850 to a Non-Confirmable request. 852 A client can use the unicast cancellation methods of Section 3.6 of 853 [RFC7641] and stop the ongoing observation of a particular resource 854 on members of a CoAP group. This can be used to remove specific 855 observed servers, or even all servers in the group. In addition, a 856 client MAY explicitly deregister from all those servers at once, by 857 sending a multicast GET request that includes the Token value of the 858 observation to be cancelled and includes an Observe Option with the 859 value set to 1 (deregister). In case not all the servers in the CoAP 860 group received this deregistration request, either the unicast 861 cancellation methods can be used or the multicast deregistration 862 request MAY be repeated upon receiving another observe response from 863 a server. 865 For observing a group of servers through a CoAP-to-CoAP proxy or 866 HTTP-CoAP proxy, the limitations stated in Section 2.3.3 apply. 868 2.3.6. Block-Wise Transfer 870 Section 2.8 of [RFC7959] specifies how a client can use block-wise 871 transfer (Block2 Option) in a multicast GET request to limit the size 872 of the initial response of each server. The client has to use 873 unicast for any further requests, separately addressing each 874 different server, in order to retrieve more blocks of the resource 875 from that server, if any. Also, a server (member of a targeted CoAP 876 group) that needs to respond to a multicast request with a 877 particularly large resource can use block-wise transfer (Block2 878 Option) at its own initiative, to limit the size of the initial 879 response. Again, a client would have to use unicast for any further 880 requests to retrieve more blocks of the resource. 882 A solution for multicast block-wise transfer using the Block1 Option 883 is not specified in [RFC7959] nor in the present document. Such a 884 solution would be useful for multicast PUT/POST/PATCH/iPATCH 885 requests, to efficiently distribute a large request payload as 886 multiple blocks to all members of a CoAP group. Multicast usage of 887 Block1 is non-trivial due to potential message loss (leading to 888 missing blocks or missing confirmations), and potential diverging 889 block size preferences of different members of the CoAP group. 891 2.4. Transport 893 In this document only UDP is considered as a transport protocol, both 894 over IPv4 and IPv6. Therefore, [RFC8323] (CoAP over TCP, TLS, and 895 WebSockets) is not in scope as a transport for group communication. 897 2.4.1. UDP/IPv6 Multicast Transport 899 CoAP group communication can use UDP over IPv6 as a transport 900 protocol, provided that IPv6 multicast is enabled. IPv6 multicast 901 MAY be supported in a network only for a limited scope. For example, 902 Section 2.5.2 describes the potential limited support of RPL for 903 multicast, depending on how the protocol is configured. 905 For a CoAP server node that supports resource discovery as defined in 906 Section 2.4 of [RFC7252], the default port 5683 MUST be supported as 907 per Section 7.1 and 12.8 of [RFC7252] for the "All CoAP Nodes" 908 multicast group. An IPv6 CoAP server SHOULD support the "All CoAP 909 Nodes" groups with at least link-local (2), admin-local (4) and site- 910 local (5) scopes. An IPv6 CoAP server on a 6LoWPAN node (see 911 Section 2.4.3) SHOULD also support the realm-local (3) scope. 913 Note that a client sending an IPv6 multicast CoAP message to a port 914 that is not supported by the server will not receive an ICMPv6 Port 915 Unreachable error message from that server, because the server does 916 not send it in this case, per Section 2.4 of [RFC4443]. 918 2.4.2. UDP/IPv4 Multicast Transport 920 CoAP group communication can use UDP over IPv4 as a transport 921 protocol, provided that IPv4 multicast is enabled. For a CoAP server 922 node that supports resource discovery as defined in Section 2.4 of 923 [RFC7252], the default port 5683 MUST be supported as per Section 7.1 924 and 12.8 of [RFC7252], for the "All CoAP Nodes" IPv4 multicast group. 926 Note that a client sending an IPv4 multicast CoAP message to a port 927 that is not supported by the server will not receive an ICMP Port 928 Unreachable error message from that server, because the server does 929 not send it in this case, per Section 3.2.2 of [RFC1122]. 931 2.4.3. 6LoWPAN 933 In 6LoWPAN [RFC4944] networks, IPv6 packets (up to 1280 bytes) may be 934 fragmented into smaller IEEE 802.15.4 MAC frames (up to 127 bytes), 935 if the packet size requires this. Every 6LoWPAN IPv6 router that 936 receives a multi-fragment packet reassembles the packet and 937 refragments it upon transmission. Since the loss of a single 938 fragment implies the loss of the entire IPv6 packet, the performance 939 in terms of packet loss and throughput of multi-fragment multicast 940 IPv6 packets is typically far worse than the performance of single- 941 fragment IPv6 multicast packets. For this reason, a CoAP request 942 sent over multicast in 6LoWPAN networks SHOULD be sized in such a way 943 that it fits in a single IEEE 802.15.4 MAC frame, if possible. 945 On 6LoWPAN networks, multicast groups can be defined with realm-local 946 scope [RFC7346]. Such a realm-local group is restricted to the local 947 6LoWPAN network/subnet. In other words, a multicast request to that 948 group does not propagate beyond the 6LoWPAN network segment where the 949 request originated. For example, a multicast discovery request can 950 be sent to the realm-local "All CoAP Nodes" IPv6 multicast group (see 951 Section 2.4.1) in order to discover only CoAP servers on the local 952 6LoWPAN network. 954 2.5. Interworking with Other Protocols 956 2.5.1. MLD/MLDv2/IGMP/IGMPv3 958 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 959 unaware of the specific IP multicast routing/forwarding protocol 960 being used in their network. When such a host needs to join a 961 specific (CoAP) multicast group, it requires a way to signal to IP 962 multicast routers which IP multicast address(es) it needs to listen 963 to. 965 The MLDv2 protocol [RFC3810] is the standard IPv6 method to achieve 966 this; therefore, this method SHOULD be used by members of a CoAP 967 group to subscribe to its multicast IPv6 address, on IPv6 networks 968 that support it. CoAP server nodes then act in the role of MLD 969 Multicast Address Listener. Constrained IPv6 networks that implement 970 either RPL (see Section 2.5.2) or MPL (see Section 2.5.3) typically 971 do not support MLD as they have their own mechanisms defined. 973 The IGMPv3 protocol [RFC3376] is the standard IPv4 method to signal 974 multicast group subscriptions. This SHOULD be used by members of a 975 CoAP group to subscribe to its multicast IPv4 address on IPv4 976 networks. 978 The guidelines from [RFC6636] on the tuning of MLD for mobile and 979 wireless networks may be useful when implementing MLD in constrained 980 networks. 982 2.5.2. RPL 984 RPL [RFC6550] is an IPv6 based routing protocol suitable for low- 985 power, lossy networks (LLNs). In such a context, CoAP is often used 986 as an application protocol. 988 If only RPL is used in a network for routing and its optional 989 multicast support is disabled, there will be no IP multicast routing 990 available. Any IPv6 multicast packets in this case will not 991 propagate beyond a single hop (to direct neighbors in the LLN). This 992 implies that any CoAP group request will be delivered to link-local 993 nodes only, for any scope value >= 2 used in the IPv6 destination 994 address. 996 RPL supports (see Section 12 of [RFC6550]) advertisement of IP 997 multicast destinations using Destination Advertisement Object (DAO) 998 messages and subsequent routing of multicast IPv6 packets based on 999 this. It requires the RPL mode of operation to be 3 (Storing mode 1000 with multicast support). 1002 In this mode, RPL DAO can be used by a CoAP node that is either an 1003 RPL router or RPL Leaf Node, to advertise its CoAP group membership 1004 to parent RPL routers. Then, RPL will route any IP multicast CoAP 1005 requests over multiple hops to those CoAP servers that are group 1006 members. 1008 The same DAO mechanism can be used to convey CoAP group membership 1009 information to an edge router (e.g., 6LBR), in case the edge router 1010 is also the root of the RPL Destination-Oriented Directed Acyclic 1011 Graph (DODAG). This is useful because the edge router then learns 1012 which IP multicast traffic it needs to pass through from the backbone 1013 network into the LLN subnet. In LLNs, such ingress filtering helps 1014 to avoid congestion of the resource-constrained network segment, due 1015 to IP multicast traffic from the high-speed backbone IP network. 1017 2.5.3. MPL 1019 The Multicast Protocol for Low-Power and Lossy Networks (MPL) 1020 [RFC7731] can be used for propagation of IPv6 multicast packets 1021 throughout a defined network domain, over multiple hops. MPL is 1022 designed to work in LLNs and can operate alone or in combination with 1023 RPL. The protocol involves a predefined group of MPL Forwarders to 1024 collectively distribute IPv6 multicast packets throughout their MPL 1025 Domain. An MPL Forwarder may be associated to multiple MPL Domains 1026 at the same time. Non-Forwarders will receive IPv6 multicast packets 1027 from one or more of their neighboring Forwarders. Therefore, MPL can 1028 be used to propagate a CoAP multicast request to all group members. 1030 However, a CoAP multicast request to a group that originated outside 1031 of the MPL Domain will not be propagated by MPL - unless an MPL 1032 Forwarder is explicitly configured as an ingress point that 1033 introduces external multicast packets into the MPL Domain. Such an 1034 ingress point could be located on an edge router (e.g., 6LBR). The 1035 method to configure which multicast groups are to be propagated into 1036 the MPL Domain could be: 1038 o Manual configuration on the ingress MPL Forwarder. 1040 o A protocol to register multicast groups at an ingress MPL 1041 Forwarder. This could be a protocol offering features similar to 1042 MLDv2. 1044 3. Unsecured Group Communication 1046 CoAP group communication can operate in CoAP NoSec (No Security) 1047 mode, without using application-layer and transport-layer security 1048 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 1049 Section 9 of [RFC7252]. The conceptual "NoSec" security group as 1050 defined in Section 2.1 is used for unsecured group communication. 1051 Before using this mode of operation, the security implications 1052 (Section 5.1) must be well understood. 1054 4. Secured Group Communication using Group OSCORE 1056 The application-layer protocol Object Security for Constrained 1057 RESTful Environments (OSCORE) [RFC8613] provides end-to-end 1058 encryption, integrity and replay protection of CoAP messages 1059 exchanged between two CoAP endpoints. These can act both as CoAP 1060 Client as well as CoAP Server, and share an OSCORE Security Context 1061 used to protect and verify exchanged messages. The use of OSCORE 1062 does not affect the URI scheme and OSCORE can therefore be used with 1063 any URI scheme defined for CoAP. 1065 OSCORE uses COSE 1066 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs] to 1067 perform encryption operations and protect a CoAP message in a COSE 1068 object, by using an Authenticated Encryption with Associated Data 1069 (AEAD) algorithm. In particular, OSCORE takes as input an 1070 unprotected CoAP message and transforms it into a protected CoAP 1071 message transporting the COSE object. 1073 OSCORE makes it possible to selectively protect different parts of a 1074 CoAP message in different ways, while still allowing intermediaries 1075 (e.g., CoAP proxies) to perform their intended funtionalities. That 1076 is, some message parts are encrypted and integrity protected; other 1077 parts are only integrity protected to be accessible to, but not 1078 modifiable by, proxies; and some parts are kept as plain content to 1079 be both accessible to and modifiable by proxies. Such differences 1080 especially concern the CoAP options included in the unprotected 1081 message. 1083 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 1084 provides end-to-end security of CoAP messages exchanged between 1085 members of an OSCORE group, while fulfilling the same security 1086 requirements. 1088 In particular, Group OSCORE protects CoAP requests sent over IP 1089 multicast by a CoAP client, as well as multiple corresponding CoAP 1090 responses sent over IP unicast by different CoAP servers. However, 1091 the same keying material can also be used to protect CoAP requests 1092 sent over IP unicast to a single CoAP server in the OSCORE group, as 1093 well as the corresponding responses. 1095 Group OSCORE ensures source authentication of all messages exchanged 1096 within the OSCORE group, by means of two possible methods. 1098 The first method, namely group mode, relies on digital signatures. 1099 That is, sender devices sign their outgoing messages using their own 1100 private key, and embed the signature in the protected CoAP message. 1102 The second method, namely pairwise mode, relies on a symmetric key, 1103 which is derived from a pairwise shared secret computed from the 1104 asymmetric keys of the message sender and recipient. This method is 1105 intended for one-to-one messages sent in the group, such as all 1106 responses as individually sent by servers, as well as requests 1107 addressed to an individual server. 1109 A Group Manager is responsible for one or multiple OSCORE groups. In 1110 particular, the Group Manager acts as repository of public keys of 1111 group members; manages, renews and provides keying material in the 1112 group; and handles the join process of new group members. 1114 As defined in [I-D.tiloca-ace-oscore-gm-admin], an administrator 1115 entity can interact with the Group Manager to create OSCORE groups 1116 and specify their configuration (see Section 2.2.2). During the 1117 lifetime of the OSCORE group, the administrator can further interact 1118 with the Group Manager, in order to possibly update the group 1119 configuration and eventually delete the group. 1121 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 1122 can join an OSCORE group by using the method described in 1123 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 1124 for Authentication and Authorization in constrained environments 1125 [I-D.ietf-ace-oauth-authz]. 1127 A CoAP endpoint can discover OSCORE groups and retrieve information 1128 to join them through their Group Managers by using the method 1129 described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE 1130 Resource Directory [I-D.ietf-core-resource-directory]. 1132 If security is required, CoAP group communication as described in 1133 this specification MUST use Group OSCORE. In particular, a CoAP 1134 group as defined in Section 2.1 and using secure group communication 1135 is associated to an OSCORE security group, which includes: 1137 o All members of the CoAP group, i.e. the CoAP endpoints configured 1138 (also) as CoAP servers and listening to the group's multicast IP 1139 address. 1141 o All further CoAP endpoints configured only as CoAP clients, that 1142 send (multicast) CoAP requests to the CoAP group. 1144 4.1. Secure Group Maintenance 1146 Additional key management operations on the OSCORE group are 1147 required, depending also on the security requirements of the 1148 application (see Section 5.2). That is: 1150 o Adding new members to a CoAP group or enabling new client-only 1151 endpoints to interact with that group require also that each of 1152 such members/endpoints join the corresponding OSCORE group. By 1153 doing so, they are securely provided with the necessary 1154 cryptographic material. In case backward security is needed, this 1155 also requires to first renew such material and distribute it to 1156 the current members/endpoints, before new ones are added and join 1157 the OSCORE group. 1159 o In case forward security is needed, removing members from a CoAP 1160 group or stopping client-only endpoints from interacting with that 1161 group requires removing such members/endpoints from the 1162 corresponding OSCORE group. To this end, new cryptographic 1163 material is generated and securely distributed only to the 1164 remaining members/endpoints. This ensures that only the members/ 1165 endpoints intended to remain are able to continue participating in 1166 secure group communication, while the evicted ones are not able 1167 to. 1169 The key management operations mentioned above are entrusted to the 1170 Group Manager responsible for the OSCORE group 1171 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 1172 them according to the approach described in 1173 [I-D.ietf-ace-key-groupcomm-oscore]. 1175 5. Security Considerations 1177 This section provides security considerations for CoAP group 1178 communication using IP multicast. 1180 5.1. CoAP NoSec Mode 1182 CoAP group communication, if not protected, is vulnerable to all the 1183 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 1185 Thus, for sensitive and mission-critical applications (e.g., health 1186 monitoring systems and alarm monitoring systems), it is NOT 1187 RECOMMENDED to deploy CoAP group communication in NoSec mode. 1189 Without application-layer security, CoAP group communication SHOULD 1190 only be deployed in applications that are non-critical, and that do 1191 not involve or may have an impact on sensitive data and personal 1192 sphere. These include, e.g., read-only temperature sensors deployed 1193 in non-sensitive environments, where the client reads out the values 1194 but does not use the data to control actuators or to base an 1195 important decision on. 1197 Discovery of devices and resources is a typical use case where NoSec 1198 mode is applied, since the devices involved do not have yet 1199 configured any mutual security relations at the time the discovery 1200 takes place. 1202 5.2. Group OSCORE 1204 Group OSCORE provides end-to-end application-level security. This 1205 has many desirable properties, including maintaining security 1206 assurances while forwarding traffic through intermediaries (proxies). 1207 Application-level security also tends to more cleanly separate 1208 security from the dynamics of group membership (e.g., the problem of 1209 distributing security keys across large groups with many members that 1210 come and go). 1212 For sensitive and mission-critical applications, CoAP group 1213 communication MUST be protected by using Group OSCORE as specified in 1214 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 1215 from Section 10 of [I-D.ietf-core-oscore-groupcomm] hold for this 1216 specification. 1218 5.2.1. Group Key Management 1220 A key management scheme for secure revocation and renewal of group 1221 keying material, namely group rekeying, should be adopted in OSCORE 1222 groups. In particular, the key management scheme should preserve 1223 backward and forward security in the OSCORE group, if the application 1224 requires so (see Section 3.1 of [I-D.ietf-core-oscore-groupcomm]). 1226 Group policies should also take into account the time that the key 1227 management scheme requires to rekey the group, on one hand, and the 1228 expected frequency of group membership changes, i.e. nodes' joining 1229 and leaving, on the other hand. 1231 In fact, it may be desirable to not rekey the group upon every single 1232 membership change, in case members' joining and leaving are frequent, 1233 and at the same time a single group rekeying instance takes a non 1234 negligible time to complete. 1236 In such a case, the Group Manager may consider to rekey the group, 1237 e.g., after a minimum number of nodes has joined or left the group 1238 within a pre-defined time interval, or according to communication 1239 patterns with predictable intervals of network inactivity. This 1240 would prevent paralyzing communications in the group, when a slow 1241 rekeying scheme is used and frequently invoked. 1243 This comes at the cost of not continuously preserving backward and 1244 forward security, since group rekeying might not occur upon every 1245 single group membership change. That is, most recently joined nodes 1246 would have access to the key material used prior to their join, and 1247 thus be able to access past group communications protected with that 1248 key material. Similarly, until the group is rekeyed, most recently 1249 left nodes would preserve access to group communications protected 1250 with the retained key material. 1252 5.2.2. Source Authentication 1254 Both the group mode and the pairwise mode of Group OSCORE ensure 1255 source authentication of messages exchanged by CoAP endpoints through 1256 CoAP group communication. 1258 To this end, outgoing messages are either countersigned by the 1259 message sender endpoint with its own private key (group mode), or 1260 protected with a symmetric key, which is in turn derived using the 1261 asymmetric keys of the message sender and recipient (pairwise mode). 1263 Thus, both modes allow a recipient CoAP endpoint to verify that a 1264 message has actually been originated by a specific and identified 1265 member of the OSCORE group. 1267 Appendix F of [I-D.ietf-core-oscore-groupcomm] discusses a number of 1268 cases where a recipient CoAP endpoint may skip the verification of 1269 countersignatures in messages protected with the group mode, possibly 1270 on a per-message basis. However, this is NOT RECOMMENDED. That is, 1271 a CoAP endpoint receiving a message secured with the group mode of 1272 Group OSCORE SHOULD always verify the countersignature. 1274 5.2.3. Countering Attacks 1276 As discussed below, Group OSCORE addresses a number of security 1277 attacks mentioned in Section 11 of [RFC7252], with particular 1278 reference to their execution over IP multicast. 1280 o Since Group OSCORE provides end-to-end confidentiality and 1281 integrity of request/response messages, proxies in multicast 1282 settings cannot break message protection, and thus cannot act as 1283 man-in-the-middle beyond their legitimate duties (see Section 11.2 1284 of [RFC7252]). In fact, intermediaries such as proxies are not 1285 assumed to have access to the OSCORE Security Context used by 1286 group members. Also, with the notable addition of 1287 countersignatures for the group mode, Group OSCORE protects 1288 messages using the same constructions of OSCORE (see Sections 8.1 1289 and 8.3 of [I-D.ietf-core-oscore-groupcomm]), and especially 1290 processes CoAP options according to the same classification in 1291 U/I/E classes. 1293 o Group OSCORE protects against amplification attacks (see 1294 Section 11.3 of [RFC7252]), which are made e.g. by injecting 1295 (small) requests over IP multicast from the (spoofed) IP address 1296 of a victim client, and thus triggering the transmission of 1297 several (much bigger) responses back to that client. In fact, 1298 upon receiving a request over IP multicast as protected with Group 1299 OSCORE in group mode, a server is able to verify whether the 1300 request is fresh and originates from the alleged sender in the 1301 OSCORE group, by verifying the countersignature included in the 1302 request using the public key of that sender (see Section 8.2 of 1303 [I-D.ietf-core-oscore-groupcomm]). Furthermore, as also discussed 1304 in Section 8 of [I-D.ietf-core-oscore-groupcomm], it is 1305 recommended that servers failing to decrypt and verify an incoming 1306 message do not send back any error message. 1308 o Group OSCORE limits the impact of attacks based on IP spoofing 1309 also over IP multicast (see Section 11.4 of [RFC7252]). In fact, 1310 requests and corresponding responses sent in the OSCORE group can 1311 be correctly generated only by legitimate group members. 1313 Within an OSCORE group, the shared symmetric key material strictly 1314 provides only group-level authentication (see Section 10.1 of 1316 [I-D.ietf-core-oscore-groupcomm]). However, source authentication 1317 of messages is also ensured, both in the group mode by means of 1318 countersignatures (see Sections 8.1 and 8.3 of 1319 [I-D.ietf-core-oscore-groupcomm]), and in the pairwise mode by 1320 using additionally derived pairwise keys (see Sections 9.1 and 9.3 1321 of [I-D.ietf-core-oscore-groupcomm]). Thus, recipient endpoints 1322 can verify a message to be originated by the alleged, identifiable 1323 sender in the OSCORE group. 1325 Note that the server may additionally rely on the Echo option for 1326 CoAP described in [I-D.ietf-core-echo-request-tag], in order to 1327 verify the aliveness and reachability of the client sending a 1328 request from a particular IP address. 1330 o Group OSCORE does not require group members to be equipped with a 1331 good source of entropy for generating key material (see 1332 Section 11.6 of [RFC7252]), and thus does not contribute to create 1333 an attack vector against such (constrained) CoAP endpoints. In 1334 particular, the symmetric keys used for message encryption and 1335 decryption are derived through the same HMAC-based HKDF scheme 1336 used for OSCORE (see Section 3.2 of [RFC8613]). Besides, the 1337 OSCORE Master Secret used in such derivation is securely generated 1338 by the Group Manager responsible for the OSCORE group, and 1339 securely provided to the CoAP endpoints when they join the group. 1341 o Group OSCORE prevents to make any single group member a target for 1342 subverting security in the whole OSCORE group (see Section 11.6 of 1343 [RFC7252]), even though all group members share (and can derive) 1344 the same symmetric key material used in the OSCORE group (see 1345 Section 10.1 of [I-D.ietf-core-oscore-groupcomm]). In fact, 1346 source authentication is always ensured for exchanged CoAP 1347 messages, as verifiable to be originated by the alleged, 1348 identifiable sender in the OSCORE group. This relies on including 1349 a countersignature computed with a node's individual private key 1350 (in the group mode), or on protecting messages with a pairwise 1351 symmetric key, which is in turn derived from the asymmetric keys 1352 of the sender and recipient CoAP endpoints (in the pairwise mode). 1354 5.3. Replay of Non Confirmable Messages 1356 Since all requests sent over IP multicast are Non-confirmable, a 1357 client might not be able to know if an adversary has actually 1358 captured one of its trasmitted requests and later re-injected it in 1359 the group as a replay to the server nodes. In fact, even if the 1360 servers sent back responses to the replayed request, the client would 1361 not have a valid matching request anymore to suspect of the attack. 1363 If Group OSCORE is used, such a replay attack on the servers is 1364 prevented, since a client protects every different request with a 1365 different Sequence Number value, which is in turn included as Partial 1366 IV in the protected message and takes part in the construction of the 1367 AEAD cipher nonce. Thus, a server would be able to detect the 1368 replayed request, by checking the conveyed Partial IV against its own 1369 replay window in the OSCORE Recipient Context associated to the 1370 client. 1372 This requires a server to have a synchronized, up to date view of the 1373 sequence number used by the client. If such synchronization is lost, 1374 e.g. due to a reboot, or suspected so, the server should use one of 1375 the methods described in Appendix E of 1376 [I-D.ietf-core-oscore-groupcomm], such as the one based on the Echo 1377 option for CoAP described in [I-D.ietf-core-echo-request-tag], in 1378 order to (re-)synchronize with the client's sequence number. 1380 5.4. Use of CoAP No-Response Option 1382 When CoAP group communication is used in CoAP NoSec (No Security) 1383 mode (see Section 3), the CoAP No-Response Option [RFC7967] could be 1384 misused by a malicious client to evoke as much responses from servers 1385 to a multicast request as possible, by using the value '0' - 1386 Interested in all responses. This even overrides the default 1387 behaviour of a CoAP server to suppress the response in case there is 1388 nothing of interest to respond with. Therefore, this option can be 1389 used to perform an amplification attack. 1391 A proposed mitigation is to only allow this Option to relax the 1392 standard suppression rules for a resource in case the Option is sent 1393 by an authenticated client. If sent by an unauthenticated client, 1394 the Option can be used to expand the classes of responses suppressed 1395 compared to the default rules but not to reduce the classes of 1396 responses suppressed. 1398 5.5. 6LoWPAN 1400 In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior 1401 to transmission. A 6LoWPAN Router that forwards a fragmented packet 1402 can have a relatively high impact on the occupation of the wireless 1403 channel and on the memory load of the local node due to packet buffer 1404 occupation. For example, the MPL [RFC7731] protocol requires an MPL 1405 Forwarder to store the packet for a longer duration, to allow 1406 multiple forwarding transmissions to neighboring Forwarders. If only 1407 one of the fragments is not received correctly by an MPL Forwarder, 1408 the receiver needs to discard all received fragments and it needs to 1409 receive all the packet fragments again on a future occasion. 1411 For these reasons, a fragmented IPv6 multicast packet is a possible 1412 attack vector in a Denial of Service (DoS) amplification attack. See 1413 Section 11.3 of [RFC7252] for more details on amplification. To 1414 mitigate the risk, applications sending multicast IPv6 requests to 1415 6LoWPAN hosted CoAP servers SHOULD limit the size of the request to 1416 avoid 6LoWPAN fragmentation. A 6LoWPAN Router or multicast forwarder 1417 SHOULD deprioritize forwarding for multi-fragment 6LoWPAN multicast 1418 packets. Also, a 6LoWPAN Border Router SHOULD implement multicast 1419 packet filtering to prevent unwanted multicast traffic from entering 1420 a 6LoWPAN network from the outside. For example, it could filter out 1421 all multicast packet for which there is no known multicast listener 1422 on the 6LoWPAN network. 1424 5.6. Wi-Fi 1426 In a home automation scenario using Wi-Fi, Wi-Fi security should be 1427 enabled to prevent rogue nodes from joining. The Customer Premises 1428 Equipment (CPE) that enables access to the Internet should also have 1429 its IP multicast filters set so that it enforces multicast scope 1430 boundaries to isolate local multicast groups from the rest of the 1431 Internet (e.g., as per [RFC6092]). In addition, the scope of IP 1432 multicast transmissions and listeners should be site-local (5) or 1433 smaller. For site-local scope, the CPE will be an appropriate 1434 multicast scope boundary point. 1436 5.7. Monitoring 1438 5.7.1. General Monitoring 1440 CoAP group communication can be used to control a set of related 1441 devices: for example, simultaneously turn on all the lights in a 1442 room. This intrinsically exposes the group to some unique monitoring 1443 risks that devices not in a group are not as vulnerable to. For 1444 example, assume an attacker is able to physically see a set of lights 1445 turn on in a room. Then the attacker can correlate an observed CoAP 1446 group communication message to the observed coordinated group action 1447 - even if the CoAP message is (partly) encrypted. 1448 This will give the attacker side-channel information to plan further 1449 attacks (e.g., by determining the members of the group some network 1450 topology information may be deduced). 1452 5.7.2. Pervasive Monitoring 1454 A key additional threat consideration for group communication is 1455 pervasive monitoring [RFC7258]. CoAP group communication solutions 1456 that are built on top of IP multicast need to pay particular heed to 1457 these dangers. This is because IP multicast is easier to intercept 1458 (and to secretly record) compared to IP unicast. Also, CoAP traffic 1459 is meant for the Internet of Things. This means that CoAP multicast 1460 may be used for the control and monitoring of critical infrastructure 1461 (e.g., lights, alarms, etc.) that may be prime targets for attack. 1463 For example, an attacker may attempt to record all the CoAP traffic 1464 going over a smart grid (i.e., networked electrical utility) and try 1465 to determine critical nodes for further attacks. For example, the 1466 source node (controller) sends out CoAP group communication messages 1467 which easily identifies it as a controller. 1468 CoAP multicast traffic is inherently more vulnerable (compared to 1469 unicast) as the same packet may be replicated over many links, 1470 leading to a higher probability of packet capture by a pervasive 1471 monitoring system. 1473 One mitigation is to restrict the scope of IP multicast to the 1474 minimal scope that fulfills the application need. Thus, for example, 1475 site-local IP multicast scope is always preferred over global scope 1476 IP multicast if this fulfills the application needs. 1478 Even if all CoAP multicast traffic is encrypted/protected, an 1479 attacker may still attempt to capture this traffic and perform an 1480 off-line attack in the future. 1482 6. IANA Considerations 1484 This document has no actions for IANA. 1486 7. References 1488 7.1. Normative References 1490 [I-D.ietf-core-echo-request-tag] 1491 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1492 Request-Tag, and Token Processing", draft-ietf-core-echo- 1493 request-tag-09 (work in progress), March 2020. 1495 [I-D.ietf-core-oscore-groupcomm] 1496 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1497 "Group OSCORE - Secure Group Communication for CoAP", 1498 draft-ietf-core-oscore-groupcomm-09 (work in progress), 1499 June 2020. 1501 [I-D.ietf-cose-rfc8152bis-algs] 1502 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1503 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-11 1504 (work in progress), July 2020. 1506 [I-D.ietf-cose-rfc8152bis-struct] 1507 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1508 Structures and Process", draft-ietf-cose-rfc8152bis- 1509 struct-11 (work in progress), July 2020. 1511 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1512 Communication Layers", STD 3, RFC 1122, 1513 DOI 10.17487/RFC1122, October 1989, 1514 . 1516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1517 Requirement Levels", BCP 14, RFC 2119, 1518 DOI 10.17487/RFC2119, March 1997, 1519 . 1521 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1522 Thyagarajan, "Internet Group Management Protocol, Version 1523 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1524 . 1526 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1527 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1528 DOI 10.17487/RFC3810, June 2004, 1529 . 1531 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1532 Control Message Protocol (ICMPv6) for the Internet 1533 Protocol Version 6 (IPv6) Specification", STD 89, 1534 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1535 . 1537 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1538 "Transmission of IPv6 Packets over IEEE 802.15.4 1539 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1540 . 1542 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1543 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1544 . 1546 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1547 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1548 October 2013, . 1550 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1551 Application Protocol (CoAP)", RFC 7252, 1552 DOI 10.17487/RFC7252, June 2014, 1553 . 1555 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1556 Application Protocol (CoAP)", RFC 7641, 1557 DOI 10.17487/RFC7641, September 2015, 1558 . 1560 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1561 the Constrained Application Protocol (CoAP)", RFC 7959, 1562 DOI 10.17487/RFC7959, August 2016, 1563 . 1565 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1566 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1567 the Constrained Application Protocol (CoAP)", RFC 8075, 1568 DOI 10.17487/RFC8075, February 2017, 1569 . 1571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1573 May 2017, . 1575 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1576 "Object Security for Constrained RESTful Environments 1577 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1578 . 1580 7.2. Informative References 1582 [Californium] 1583 Eclipse Foundation, "Eclipse Californium", March 2019, 1584 . 1588 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 1589 CoAP Server & Client in Go", March 2019, 1590 . 1592 [I-D.ietf-ace-key-groupcomm-oscore] 1593 Tiloca, M., Park, J., and F. Palombini, "Key Management 1594 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1595 oscore-08 (work in progress), July 2020. 1597 [I-D.ietf-ace-oauth-authz] 1598 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1599 H. Tschofenig, "Authentication and Authorization for 1600 Constrained Environments (ACE) using the OAuth 2.0 1601 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1602 (work in progress), June 2020. 1604 [I-D.ietf-core-coap-pubsub] 1605 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1606 Subscribe Broker for the Constrained Application Protocol 1607 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1608 progress), September 2019. 1610 [I-D.ietf-core-resource-directory] 1611 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1612 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1613 resource-directory-24 (work in progress), March 2020. 1615 [I-D.tiloca-ace-oscore-gm-admin] 1616 Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K. 1617 Hartke, "Admin Interface for the OSCORE Group Manager", 1618 draft-tiloca-ace-oscore-gm-admin-01 (work in progress), 1619 March 2020. 1621 [I-D.tiloca-core-groupcomm-proxy] 1622 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 1623 Communication", draft-tiloca-core-groupcomm-proxy-00 (work 1624 in progress), March 2020. 1626 [I-D.tiloca-core-oscore-discovery] 1627 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1628 Groups with the CoRE Resource Directory", draft-tiloca- 1629 core-oscore-discovery-05 (work in progress), March 2020. 1631 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1632 Capabilities in Customer Premises Equipment (CPE) for 1633 Providing Residential IPv6 Internet Service", RFC 6092, 1634 DOI 10.17487/RFC6092, January 2011, 1635 . 1637 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1638 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1639 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1640 Low-Power and Lossy Networks", RFC 6550, 1641 DOI 10.17487/RFC6550, March 2012, 1642 . 1644 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1645 the Internet Group Management Protocol (IGMP) and 1646 Multicast Listener Discovery (MLD) for Routers in Mobile 1647 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 1648 May 2012, . 1650 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1651 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1652 2014, . 1654 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1655 DOI 10.17487/RFC7346, August 2014, 1656 . 1658 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1659 the Constrained Application Protocol (CoAP)", RFC 7390, 1660 DOI 10.17487/RFC7390, October 2014, 1661 . 1663 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1664 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1665 February 2016, . 1667 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1668 Bose, "Constrained Application Protocol (CoAP) Option for 1669 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1670 August 2016, . 1672 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1673 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1674 Application Protocol) over TCP, TLS, and WebSockets", 1675 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1676 . 1678 [RFC8710] Fossati, T., Hartke, K., and C. Bormann, "Multipart 1679 Content-Format for the Constrained Application Protocol 1680 (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020, 1681 . 1683 Appendix A. Use Cases 1685 To illustrate where and how CoAP-based group communication can be 1686 used, this section summarizes the most common use cases. These use 1687 cases include both secured and non-secured CoAP usage. Each 1688 subsection below covers one particular category of use cases for 1689 CoRE. Within each category, a use case may cover multiple 1690 application areas such as home IoT, commercial building IoT (sensing 1691 and control), industrial IoT/control, or environmental sensing. 1693 A.1. Discovery 1695 Discovery of physical devices in a network, or discovery of 1696 information entities hosted on network devices, are operations that 1697 are usually required in a system during the phases of setup or 1698 (re)configuration. When a discovery use case involves devices that 1699 need to interact without having been configured previously with a 1700 common security context, unsecured CoAP communication is typically 1701 used. Discovery may involve a request to a directory server, which 1702 provides services to aid clients in the discovery process. One 1703 particular type of directory server is the CoRE Resource Directory 1704 [I-D.ietf-core-resource-directory]; and there may be other types of 1705 directories that can be used with CoAP. 1707 A.1.1. Distributed Device Discovery 1709 Device discovery is the discovery and identification of networked 1710 devices - optionally only devices of a particular class, type, model, 1711 or brand. Group communication is used for distributed device 1712 discovery, if a central directory server is not used. Typically in 1713 distributed device discovery, a multicast request is sent to a 1714 particular address (or address range) and multicast scope of 1715 interest, and any devices configured to be discoverable will respond 1716 back. For the alternative solution of centralized device discovery a 1717 central directory server is accessed through unicast, in which case 1718 group communication is not needed. This requires that the address of 1719 the central directory is either preconfigured in each device or 1720 configured during operation using a protocol. 1722 In CoAP, device discovery can be implemented by CoAP resource 1723 discovery requesting (GET) a particular resource that the sought 1724 device class, type, model or brand is known to respond to. It can 1725 also be implemented using CoAP resource discovery (Section 7 of 1726 [RFC7252]) and the CoAP query interface defined in Section 4 of 1727 [RFC6690] to find these particular resources. Also, a multicast GET 1728 request to /.well-known/core can be used to discover all CoAP 1729 devices. 1731 A.1.2. Distributed Service Discovery 1733 Service discovery is the discovery and identification of particular 1734 services hosted on network devices. Services can be identified by 1735 one or more parameters such as ID, name, protocol, version and/or 1736 type. Distributed service discovery involves group communication to 1737 reach individual devices hosting a particular service; with a central 1738 directory server not being used. 1740 In CoAP, services are represented as resources and service discovery 1741 is implemented using resource discovery (Section 7 of [RFC7252]) and 1742 the CoAP query interface defined in Section 4 of [RFC6690]. 1744 A.1.3. Directory Discovery 1746 This use case is a specific sub-case of Distributed Service Discovery 1747 (Appendix A.1.2), in which a device needs to identify the location of 1748 a Directory on the network to which it can e.g. register its own 1749 offered services, or to which it can perform queries to identify and 1750 locate other devices/services it needs to access on the network. 1751 Section 3.3 of [RFC7390] shows an example of discovering a CoRE 1752 Resource Directory using CoAP group communication. As defined in 1753 [I-D.ietf-core-resource-directory], a resource directory is a web 1754 entity that stores information about web resources and implements 1755 REST interfaces for registration and lookup of those resources. For 1756 example, a device can register itself to a resource directory to let 1757 it be found by other devices and/or applications. 1759 A.2. Operational Phase 1761 Operational phase use cases describe those operations that occur most 1762 frequently in a networked system, during its operational lifetime and 1763 regular operation. Regular usage is when the applications on 1764 networked devices perform the tasks they were designed for and 1765 exchange of application-related data using group communication 1766 occurs. Processes like system reconfiguration, group changes, 1767 system/device setup, extra group security changes, etc. are not part 1768 of regular operation. 1770 A.2.1. Actuator Group Control 1772 Group communication can be beneficial to control actuators that need 1773 to act in synchrony, as a group, with strict timing (latency) 1774 requirements. Examples are office lighting, stage lighting, street 1775 lighting, or audio alert/Public Address systems. Sections 3.4 and 1776 3.5 of [RFC7390] show examples of lighting control of a group of 1777 6LoWPAN-connected lights. 1779 A.2.2. Device Group Status Request 1781 To properly monitor the status of systems, there may be a need for 1782 ad-hoc, unplanned status updates. Group communication can be used to 1783 quickly send out a request to a (potentially large) number of devices 1784 for specific information. Each device then responds back with the 1785 requested data. Those devices that did not respond to the request 1786 can optionally be polled again via reliable unicast communication to 1787 complete the dataset. The device group may be defined e.g. as "all 1788 temperature sensors on floor 3", or "all lights in wing B". For 1789 example, it could be a status request for device temperature, most 1790 recent sensor event detected, firmware version, network load, and/or 1791 battery level. 1793 A.2.3. Network-wide Query 1795 In some cases a whole network or subnet of multiple IP devices needs 1796 to be queried for status or other information. This is similar to 1797 the previous use case except that the device group is not defined in 1798 terms of its function/type but in terms of its network location. 1799 Technically this is also similar to distributed service discovery 1800 (Appendix A.1.2) where a query is processed by all devices on a 1801 network - except that the query is not about services offered by the 1802 device, but rather specific operational data is requested. 1804 A.2.4. Network-wide / Group Notification 1806 In some cases a whole network, or subnet of multiple IP devices, or a 1807 specific target group needs to be notified of a status change or 1808 other information. This is similar to the previous two use cases 1809 except that the recipients are not expected to respond with some 1810 information. Unreliable notification can be acceptable in some use 1811 cases, in which a recipient does not respond with a confirmation of 1812 having received the notification. In such a case, the receiving CoAP 1813 server does not have to create a CoAP response. If the sender needs 1814 confirmation of reception, the CoAP servers can be configured for 1815 that resource to respond with a 2.xx success status after processing 1816 a notification request successfully. 1818 A.3. Software Update 1820 Multicast can be useful to efficiently distribute new software 1821 (firmware, image, application, etc.) to a group of multiple devices. 1822 In this case, the group is defined in terms of device type: all 1823 devices in the target group are known to be capable of installing and 1824 running the new software. The software is distributed as a series of 1825 smaller blocks that are collected by all devices and stored in 1826 memory. All devices in the target group are usually responsible for 1827 integrity verification of the received software; which can be done 1828 per-block or for the entire software image once all blocks have been 1829 received. Due to the inherent unreliability of CoAP multicast, there 1830 needs to be a backup mechanism (e.g. implemented using CoAP unicast) 1831 by which a device can individually request missing blocks of a whole 1832 software image/entity. Prior to multicast software update, the group 1833 of recipients can be separately notified that there is new software 1834 available and coming, using the above network-wide or group 1835 notification. 1837 Appendix B. Document Updates 1839 RFC EDITOR: PLEASE REMOVE THIS SECTION. 1841 B.1. Version -00 to -01 1843 o Clarifications on group memberships for the different group types. 1845 o Simplified description of Token reusage, compared to the unicast 1846 case. 1848 o More details on the rationale for response suppression. 1850 o Clarifications of creation and management of security groups. 1852 o Clients more knowledgeable than proxies about stopping receiving 1853 responses. 1855 o Cancellation of group observations. 1857 o Clarification on multicast scope to use. 1859 o Both the group mode and pairwise mode of Group OSCORE are 1860 considered. 1862 o Updated security considerations. 1864 o Editorial improvements. 1866 Acknowledgments 1868 The authors sincerely thank Thomas Fossati and Jim Schaad for their 1869 comments and feedback. 1871 The work on this document has been partly supported by VINNOVA and 1872 the Celtic-Next project CRITISEC. 1874 Authors' Addresses 1876 Esko Dijk 1877 IoTconsultancy.nl 1878 \________________\ 1879 Utrecht 1880 Netherlands 1882 Email: esko.dijk@iotconsultancy.nl 1883 Chonggang Wang 1884 InterDigital 1885 1001 E Hector St, Suite 300 1886 Conshohocken PA 19428 1887 United States 1889 Email: Chonggang.Wang@InterDigital.com 1891 Marco Tiloca 1892 RISE AB 1893 Isafjordsgatan 22 1894 Kista SE-16440 Stockholm 1895 Sweden 1897 Email: marco.tiloca@ri.se