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