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