idnits 2.17.1 draft-dijk-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 draft header indicates that this document obsoletes RFC7390, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7959, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1625 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-05 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-03 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 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, 7959 (if approved) InterDigital 6 Intended status: Standards Track M. Tiloca 7 Expires: May 7, 2020 RISE AB 8 November 04, 2019 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-dijk-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 network nodes. The most common of such use cases are 23 listed in this document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 7, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. General Group Communication Operation . . . . . . . . . . . . 4 63 2.1. Group Configuration . . . . . . . . . . . . . . . . . . . 5 64 2.1.1. Group Definition . . . . . . . . . . . . . . . . . . 5 65 2.1.2. Group Naming . . . . . . . . . . . . . . . . . . . . 5 66 2.1.3. Group Creation and Membership . . . . . . . . . . . . 6 67 2.1.4. Group Maintenance . . . . . . . . . . . . . . . . . . 7 68 2.2. CoAP Usage . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Request/Response Model . . . . . . . . . . . . . . . 7 70 2.2.2. Port and URI Path Selection . . . . . . . . . . . . . 10 71 2.2.3. Proxy Operation . . . . . . . . . . . . . . . . . . . 10 72 2.2.4. Congestion Control . . . . . . . . . . . . . . . . . 12 73 2.2.5. Observing Resources . . . . . . . . . . . . . . . . . 13 74 2.2.6. Block-Wise Transfer . . . . . . . . . . . . . . . . . 15 75 2.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 15 76 2.3.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 15 77 2.3.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 16 78 2.3.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 16 79 2.4. Interworking with Other Protocols . . . . . . . . . . . . 16 80 2.4.1. MLD/MLDv2/IGMP/IGMPv3 . . . . . . . . . . . . . . . . 16 81 2.4.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 2.4.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 3. Unsecured Group Communication . . . . . . . . . . . . . . . . 18 84 4. Secured Group Communication using Group OSCORE . . . . . . . 18 85 4.1. Secure Group Maintenance . . . . . . . . . . . . . . . . 20 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 5.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 21 88 5.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 21 89 5.2.1. Group Key Management . . . . . . . . . . . . . . . . 22 90 5.2.2. Source Authentication . . . . . . . . . . . . . . . . 22 91 5.2.3. Counteraction of Attacks . . . . . . . . . . . . . . 23 92 5.3. Use of CoAP No Response Option . . . . . . . . . . . . . 23 93 5.4. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 5.5. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 5.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 24 96 5.6.1. General Monitoring . . . . . . . . . . . . . . . . . 24 97 5.6.2. Pervasive Monitoring . . . . . . . . . . . . . . . . 24 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 99 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 7.1. Normative References . . . . . . . . . . . . . . . . . . 25 101 7.2. Informative References . . . . . . . . . . . . . . . . . 27 102 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 29 103 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 29 104 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 29 105 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 30 106 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 30 107 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 30 108 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 31 109 A.2.2. Device Group Status Request . . . . . . . . . . . . . 31 110 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 31 111 A.2.4. Network-wide / Group Notification . . . . . . . . . . 31 112 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 32 113 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Introduction 118 This document specifies group communication using the Constrained 119 Application Protocol (CoAP) [RFC7252] together with UDP/IP multicast. 120 CoAP is a RESTful communication protocol that is used in resource- 121 constrained nodes, and in resource-constrained networks where packet 122 sizes should be small. This area of use is summarized as Constrained 123 RESTful Environments (CoRE). 125 One-to-many group communication can be achieved in CoAP, by a client 126 using UDP/IP multicast data transport to send multicast CoAP request 127 messages. In response, each server in the addressed group sends a 128 response message back to the client over UDP/IP unicast. Notable 129 CoAP implementations supporting group communication include the 130 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 131 Foundation and the "Implementation of CoAP Server & Client in Go" 132 [Go-OCF] from the Open Connectivity Foundation (OCF). 134 Both unsecured and secured CoAP group communication over UDP/IP 135 multicast are specified in this document. Security is achieved by 136 using Group Object Security for Constrained RESTful Environments 137 (Group OSCORE) [I-D.ietf-core-oscore-groupcomm], which in turn builds 138 on Object Security for Constrained Restful Environments (OSCORE) 139 [RFC8613]. This method provides end-to-end application-layer 140 security protection of CoAP messages, by using CBOR Object Signing 141 and Encryption (COSE) [RFC7049][RFC8152]. 143 All sections in the body of this document are normative, while 144 appendices are informative. For additional background about use 145 cases for CoAP group communication in resource-constrained devices 146 and networks, see Appendix A. 148 1.1. Scope 150 For group communication, only solutions that use CoAP over UDP/ 151 multicast are in the scope of this document. There are alternative 152 methods to achieve group communication using CoAP, for example 153 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 154 broker server that CoAP clients access via unicast communication. 155 The alternative methods may be usable for the same or similar use 156 cases as are targeted in this document. 158 All guidelines in [RFC7390] are imported by this document which 159 replaces [RFC7390] in this respect. Furthermore, this document adds: 160 how to provide security by using Group OSCORE 161 [I-D.ietf-core-oscore-groupcomm] as the default group communication 162 security solution for CoAP; an updated request/response matching rule 163 for multicast CoAP which updates [RFC7252]; the multicast use of CoAP 164 Observe which updates [RFC7641]; and an extension of the multicast 165 use of CoAP block-wise transfers, which updates [RFC7959]. 167 Security solutions for group communication and configuration other 168 than Group OSCORE are not in scope. General principles for secure 169 group configuration are in scope. The experimental group 170 configuration protocol in Section 2.6.2 of [RFC7390] is not in the 171 scope of this document; thus, that remains an experimental protocol. 172 Since application protocols defined on top of CoAP often define their 173 own specific method of group configuration, the experimental protocol 174 of [RFC7390] has not been subject to enough experimentation to 175 warrant a change of this status. 177 1.2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 This specification requires readers to be familiar with CoAP 186 [RFC7252] terminology. 188 2. General Group Communication Operation 190 The general operation of group communication, applicable for both 191 unsecured and secured operation, is specified in this section by 192 going through the stack from top to bottom. First, group 193 configuration (e.g. group creation and maintenance which are usually 194 done by an application, user or commissioning entity) is considered 195 in Section 2.1. Then the use of CoAP for group communication 196 including support for protocol extensions (block-wise, Observe, PATCH 197 method) follows in Section 2.2. How CoAP group messages are carried 198 over various transport layers is the subject of Section 2.3. 199 Finally, Section 2.4 covers the interworking of CoAP group 200 communication with other protocols that may operate in the same 201 network. 203 2.1. Group Configuration 205 2.1.1. Group Definition 207 A CoAP group is defined as a set of CoAP endpoints, where each 208 endpoint is configured to receive CoAP multicast requests that are 209 sent to the group's associated IP multicast address and UDP port. An 210 endpoint may be a member of multiple CoAP groups. Group 211 membership(s) of an endpoint may dynamically change over time. A 212 device sending a CoAP request to a group is not necessarily itself a 213 member of this group: it is only a member if it also has a CoAP 214 server endpoint listening to requests for this CoAP group. For 215 secure group communication, a receiver also requires the security 216 context to successfully decrypt and/or verify group messages in order 217 to be a group member. 219 A CoAP Group URI has the scheme 'coap' and includes in the authority 220 part either an IP multicast address or a group hostname (e.g., Group 221 Fully Qualified Domain Name (FQDN)) that can be resolved to an IP 222 multicast address. A Group URI also contains an optional UDP port 223 number in the authority part. Group URIs follow the regular CoAP URI 224 syntax (Section 6 of [RFC7252]). 226 Besides CoAP groups, that have relevance at the level of networked 227 devices, there can also be application groups defined. An 228 application group has relevance at the application level - for 229 example an application group could denote all lights in an office 230 room or all sensors in a hallway. There can be a one-to-one or a 231 one-to-many relation between CoAP groups and application groups. 233 2.1.2. Group Naming 235 For clients, it is RECOMMENDED to use by default an IP multicast 236 address literal in a configured Group URI, instead of a hostname. 237 This is because DNS infrastructure may not be deployed in many 238 constrained networks. In case a group hostname is used in the Group 239 URI, it can be uniquely mapped to an IP multicast address via DNS 240 resolution - if DNS client functionality is available in the clients 241 and the DNS service is supported in the network. Some examples of 242 hierarchical group FQDN naming (and scoping) for a building control 243 application are shown in Section 2.2 of [RFC7390]. 245 Application groups can be named in many ways, e.g. numbers, IDs, 246 strings or URIs. An application group identifier, if used, is 247 typically included in the path component or query component of a 248 Group URI. Appendix A of [I-D.ietf-core-resource-directory] shows 249 registration of application groups into a Resource Directory, along 250 with the CoAP group it maps to. 252 2.1.3. Group Creation and Membership 254 To create a CoAP group, a configuring entity defines an IP multicast 255 address (or hostname) for the group and optionally a UDP port number 256 in case it differs from the default CoAP port 5683. Then, it 257 configures one or more devices as listeners to that IP multicast 258 address, with a CoAP server listening on the group's associated UDP 259 port. These devices are the group members. The configuring entity 260 can be, for example, a local application with preconfiguration, a 261 user, a cloud service, or a local commissioning tool. Also, the 262 devices sending requests to the group in the role of CoAP clients 263 need to be configured with the same information, even though they are 264 not necessarily group members. One way to configure a client is to 265 supply it with a CoAP Group URI, possibly together with the required 266 security material in case communication is secured in the group. 268 For unsecure group communication, any CoAP endpoint may become a 269 group member at any time: there is no (central) configuring entity 270 that needs to provide the security material for the group. This 271 means that group creation and membership cannot be tightly 272 controlled. 274 The IETF does not define a mandatory, standardized protocol to 275 accomplish these steps. [RFC7390] defines an experimental protocol 276 for configuration of group membership for unsecured group 277 communication, based on JSON-formatted configuration resources. This 278 protocol remains experimental. For secure group communication, the 279 part of the process that involves secure distribution of group keys 280 MAY use standardized communication with a Group Manager as defined in 281 Section 4. 283 The configuration of groups and membership may be performed at 284 different moments in the lifecycle of a device; for example in the 285 factory, at a reseller, on-site during first deployment, or on-site 286 during a system reconfiguration operation. 288 2.1.4. Group Maintenance 290 Maintenance of a group includes necessary operations to cope with 291 changes in a system, such as: adding group members, removing group 292 members, reconfiguration of UDP port and/or IP multicast address, 293 reconfiguration of the Group URI, splitting of groups, or merging of 294 groups. 296 For unsecured group communication (see Section 3), addition/removal 297 of group members is simply done by configuring these devices to 298 start/stop listening to the group IP multicast address, and to start/ 299 stop the CoAP server listening to the group IP multicast address and 300 port. 302 For secured group communication (see Section 4), the protocol Group 303 OSCORE [I-D.ietf-core-oscore-groupcomm] is mandatory to implement. 304 When using Group OSCORE, CoAP endpoints participating to group 305 communication are also members of a corresponding OSCORE group, and 306 thus share a common set of cryptographic material. Additional 307 related maintenance operations are discussed in Section 4.1. 309 2.2. CoAP Usage 311 2.2.1. Request/Response Model 313 A CoAP client is an endpoint able to transmit CoAP requests and 314 receive CoAP responses. Since the underlying UDP supports 315 multiplexing by means of UDP port number, there can be multiple 316 independent CoAP clients operational on a single host. On each UDP 317 port, an independent CoAP client can be hosted. Each independent 318 CoAP client sends requests that use the associated endpoint's UDP 319 port number as the UDP source port of the request. 321 All CoAP requests that are sent via IP multicast MUST be Non- 322 confirmable (Section 8.1 of [RFC7252]). The Message ID in an IP 323 multicast CoAP message is used for optional message deduplication by 324 both clients and servers, as detailed in Section 4.5 of [RFC7252]. 326 A server sends back a unicast response to the CoAP group 327 communication request - but it MAY suppress this response if selected 328 so by the server application and if permitted by the rules in this 329 document. The unicast responses received by the CoAP client may be a 330 mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not 331 Found) codes, depending on the individual server processing results. 333 Response suppression controlled by a server SHOULD be performed in a 334 consistent way, such that if a first request leads to a response that 335 is not suppressed, then a second similar request on the same resource 336 that leads to the same response code is also not suppressed. 338 The CoAP Option for No Server Response [RFC7967] can be used by a 339 client to influence the response suppression on the server side. It 340 is RECOMMENDED for a server to implement this option only on selected 341 resources where it is useful in the application context. 343 A CoAP client MAY repeat a multicast request using the same Token 344 value and same Message ID value, in order to ensure that enough (or 345 all) group members have been reached with the request. This is 346 useful in case a number of group members did not respond to the 347 initial request. However, in case one or more servers did receive 348 the initial request but the response to that request was lost, this 349 repeat may not help to retrieve the lost response(s) if the server 350 implements the optional Message ID based deduplication. 352 A CoAP client MAY also repeat a multicast request using the same 353 Token value but a different Message ID, in which case all servers 354 that received the initial request will again process the repeated 355 request. This is useful in case a client needs to collect more, or 356 even all, responses from group members. 358 The CoAP client can distinguish the origin of multiple server 359 responses by the source IP address of the UDP message containing the 360 CoAP response and/or any other available application-specific source 361 identifiers contained in the CoAP response. While processing a 362 response, the source endpoint of the response is not exactly matched 363 to the destination endpoint of the request, since for a multicast 364 request these will never match. This is specified in Section 8.2 of 365 [RFC7252]. In case a single client has sent multiple group requests 366 and concurrent CoAP transactions are ongoing, the responses received 367 by that client are matched to a request using the Token value. Due 368 to UDP level multiplexing, the UDP destination port of the response 369 MUST match to the client endpoint's UDP port value, i.e. to the UDP 370 source port of the client's request. 372 For multicast CoAP requests, there are additional constraints on the 373 reuse of Token values at the client, compared to the unicast case. 374 In the unicast case, receiving a response effectively frees up its 375 Token value for reuse, since no more responses to the same request 376 will follow. However, for multicast CoAP, the number of responses is 377 not bound a priori. Therefore, client cannot use the reception of a 378 response as a trigger to "free up" a Token value for reuse. 379 Moreover, reusing a Token value too early could lead to incorrect 380 response/request matching on the client, and would be a protocol 381 error. Therefore, the time between reuse of Token values used in 382 multicast requests MUST be greater than: 384 NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY 386 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 387 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 388 in [RFC7390], that is: the expected maximum response delay over all 389 servers that the client can send a multicast request to. This delay 390 includes the maximum Leisure time period as defined in Section 8.2 of 391 [RFC7252]. However, CoAP does not define a time limit for the server 392 response delay. Using the default CoAP parameters, the Token reuse 393 time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. 394 A preferred solution to meet this requirement is to generate a new 395 unique Token for every new multicast request, such that a Token value 396 is never reused. If a client has to reuse Token values for some 397 reason, and also MAX_SERVER_RESPONSE_DELAY is unknown, then using 398 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 399 The time between Token reuses is in that case set to a value greater 400 than 500 seconds. 402 Another method to more easily meet the above constraint is to 403 instantiate multiple CoAP clients at multiple UDP ports on the same 404 host. The Token values only have to be unique within the context of 405 a single CoAP client, so using multiple clients can make it easier to 406 meet the constraint. 408 Since a client sending a multicast request with a Token T will accept 409 multiple responses with the same Token T, there is a risk that a same 410 server sends multiple responses with the same Token T back to the 411 client. For example, this server might not implement the optional 412 CoAP message deduplication based on Message ID, or it might be a 413 malicious/compromised server acting out of specification. To 414 mitigate issues with multiple responses from one server bound to a 415 same multicast request, the client has to ensure that, as long as the 416 the CoAP Token used for a multicast request is retained, at most one 417 response to that request per server is accepted, with the exception 418 of Observe notifications [RFC7641] (see Section 2.2.5). 420 To this end, upon receiving a response corresponding to a multicast 421 request, the client MUST perform the following actions. First, the 422 client checks whether it previously received a valid response to this 423 request from the same originating server of the just-received 424 response. If the check yields a positive match and the response is 425 not an Observe notification (i.e., it does not include an Observe 426 option), the client SHALL stop processing the response. Upon 427 eventually freeing up the Token value of a multicast request for 428 possible reuse, the client MUST also delete the list of responding 429 servers associated to that request. 431 2.2.2. Port and URI Path Selection 433 A CoAP server that is a member of a group listens for CoAP messages 434 on the group's IP multicast address, usually on the CoAP default UDP 435 port 5683, or another non-default UDP port if configured. Regardless 436 of the method for selecting the port number, the same port number 437 MUST be used across all CoAP servers that are members of a group and 438 across all CoAP clients performing the group requests to that group. 439 The URI Path used in the request is preferably a path that is known 440 to be supported across all group members. However there are valid 441 use cases where a request is known to be successful for a subset of 442 the group and those group members for which the request is 443 unsuccessful either ignore the multicast request or respond with an 444 error status code. 446 Using different ports with the same IP multicast address is an 447 efficient way to create multiple CoAP groups in constrained devices, 448 in case the device's stack only supports a limited number of IP 449 multicast group memberships. However, it must be taken into account 450 that this incurs additional processing overhead on each CoAP server 451 participating in at least one of these groups: messages to groups 452 that are not of interest to the node are only discarded at the higher 453 transport (UDP) layer instead of directly at the network (IP) layer. 455 Port 5684 is reserved for DTLS-secured CoAP and MUST NOT be used for 456 any CoAP group communication. 458 For a CoAP server node that supports resource discovery as defined in 459 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 460 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 461 group. 463 2.2.3. Proxy Operation 465 CoAP (Section 5.7.2 of [RFC7252]) allows a client to request a 466 forward-proxy to process its CoAP request. For this purpose, the 467 client specifies either the request group URI as a string in the 468 Proxy-URI option or alternatively it uses the Proxy-Scheme option 469 with the group URI constructed from the usual Uri-* options. This 470 approach works well for unicast requests. However, there are certain 471 issues and limitations of processing the (unicast) responses to a 472 CoAP group communication request made in this manner through a proxy. 474 A proxy may buffer all the individual (unicast) responses to a CoAP 475 group communication request and then send back only a single 476 (aggregated) response to the client. However, there are some issues 477 with this aggregation approach: 479 o Aggregation of (unicast) responses to a CoAP group communication 480 request in a proxy is difficult. This is because the proxy does 481 not know how many members there are in the group or how many group 482 members will actually respond. Also, the proxy does not know how 483 long to wait before deciding to send back the aggregated response 484 to the client. 486 o There is no default format defined in CoAP for aggregation of 487 multiple responses into a single response. Such a format could be 488 defined based on the multipart content-format 489 [I-D.ietf-core-multipart-ct] but is not standardized yet 490 currently. 492 Alternatively, if a proxy does not aggregate responses and follows 493 the CoAP Proxy specification (Section 5.7.2 of [RFC7252]), the proxy 494 would forward all the individual (unicast) responses to a CoAP group 495 communication request to the client. There are also issues with this 496 approach: 498 o The client may be confused as it may not have known that the 499 Proxy-URI contained a group URI target. That is, the client that 500 sent a unicast CoAP request to the proxy may be expecting only one 501 (unicast) response. Instead, it receives multiple (unicast) 502 responses, potentially leading to fault conditions in the 503 application. 505 o Each individual CoAP response will appear to originate (based on 506 its IP source address) from the CoAP Proxy, and not from the 507 server that produced the response. This makes it impossible for 508 the client to identify the server that produced each response, 509 unless the server identity is contained as a part of the response 510 payload. 512 Due to the above issues, a CoAP Proxy SHOULD NOT support processing 513 an IP multicast CoAP request but rather return a 501 (Not 514 Implemented) response in such case. The exception case here (i.e., 515 to support it) is when all the following conditions are met: 517 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 518 proxied IP multicast requests by specific client(s). 520 o The proxy SHOULD return individual (unicast) CoAP responses to the 521 client (i.e., not aggregated). If a (future) standardized 522 aggregation format is being used, then aggregated responses may be 523 sent. 525 o It MUST be known to the person/entity doing the configuration of 526 the proxy, or otherwise verified in some way, that the client 527 configured in the whitelist supports receiving multiple responses 528 to a proxied unicast CoAP request. 530 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 531 specified in Section 8.4 and 10.1 of [RFC8075]. In this case, the 532 "application/http" media type can be used to let the proxy return 533 multiple CoAP responses - each translated to a HTTP response - back 534 to the HTTP client. Of course, in this case the HTTP client needs to 535 be aware that it is receiving this format and needs to be able to 536 decode from it the responses of multiple servers. The above 537 restrictions listed for CoAP Proxies still apply to HTTP-to-CoAP 538 proxies: specifically, the IP address of the sender of each CoAP 539 response cannot be determined from the application/http response. 541 2.2.4. Congestion Control 543 CoAP group communication requests may result in a multitude of 544 responses from different nodes, potentially causing congestion. 545 Therefore, both the sending of IP multicast requests and the sending 546 of the unicast CoAP responses to these multicast requests should be 547 conservatively controlled. 549 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 550 the following measures: 552 o A server may choose not to respond to an IP multicast request if 553 there is nothing useful to respond to, e.g., error or empty 554 response (see Section 8.2 of [RFC7252]). 556 o A server should limit the support for IP multicast requests to 557 specific resources where multicast operation is required 558 (Section 11.3 of [RFC7252]). 560 o An IP multicast request MUST be Non-confirmable (Section 8.1 of 561 [RFC7252]). 563 o A response to an IP multicast request SHOULD be Non-confirmable 564 (Section 5.2.3 of [RFC7252]). 566 o A server does not respond immediately to an IP multicast request 567 and should first wait for a time that is randomly picked within a 568 predetermined time interval called the Leisure (Section 8.2 of 569 [RFC7252]). 571 Additional guidelines to reduce congestion risks defined in this 572 document are as follows: 574 o A server in an LLN should only support group communication GET for 575 resources that are small. This can consist, for example, in 576 having the payload of the response as limited to approximately 5% 577 of the IP Maximum Transmit Unit (MTU) size, so that it fits into a 578 single link-layer frame in case IPv6 over Low-Power Wireless 579 Personal Area Networks (6LoWPAN) (see Section 4 of [RFC4944]) is 580 used. 582 o A server SHOULD minimize the payload length of a response to a 583 multicast GET on "/.well-known/core" by using hierarchy in 584 arranging link descriptions for the response. An example of this 585 is given in Section 5 of [RFC6690]. 587 o A server MAY minimize the payload length of a response to a 588 multicast GET (e.g., on "/.well-known/core") by using CoAP block- 589 wise transfers [RFC7959] in case the payload is long, returning 590 only a first block of the CoRE Link Format description. For this 591 reason, a CoAP client sending an IP multicast CoAP request to 592 "/.well-known/core" SHOULD support block-wise transfers. 594 o A client SHOULD use CoAP group communication with the smallest 595 possible IP multicast scope that fulfills the application needs. 596 As an example, site-local scope is always preferred over global 597 scope IP multicast if this fulfills the application needs. 598 Similarly, realm-local scope is always preferred over site-local 599 scope if this fulfills the application needs. 601 2.2.5. Observing Resources 603 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 604 that allows a CoAP client to retrieve a representation of a resource 605 and automatically keep this representation up-to-date over a longer 606 period of time. The client gets notified when the representation has 607 changed. [RFC7641] does not mention whether the Observe Option can 608 be combined with CoAP multicast. This section updates [RFC7641] with 609 the use of the Observe Option in a CoAP multicast GET request and 610 defines normative behavior for both client and server. 612 Multicast Observe is a useful way to start observing a particular 613 resource on all members of a (multicast) group at the same time. 614 Group members that do not have this particular resource or do not 615 allow the GET method on it will either respond with an error status - 616 4.04 Not Found or 4.05 Method Not Allowed, respectively - or will 617 silently suppress the response following the rules of Section 2.2.1, 618 depending on server-specific configuration. 620 A client that sends a multicast GET request with the Observe Option 621 MAY repeat this request using the same Token value and the same 622 Observe Option value, in order to ensure that enough (or all) group 623 members have been reached with the request. This is useful in case a 624 number of group members did not respond to the initial request. The 625 client MAY additionally use the same Message ID in the repeated 626 request to avoid that group members that had already received the 627 initial request would respond again. Note that using the same 628 Message ID in a repeated request will not be helpful in case of loss 629 of a response message, since the server that responded already will 630 consider the repeated request as a duplicate message. On the other 631 hand, if the client uses a different, fresh Message ID in the 632 repeated request, then all the group members that receive this new 633 message will typically respond again, which increases the network 634 load. 636 A client that sent a multicast GET request with the Observe Option 637 MAY follow up by sending a new unicast CON request with the same 638 Token value and same Observe Option value to a particular server, in 639 order to ensure that the particular server receives the request. 640 This is useful in case a specific group member, that was expected to 641 respond to the initial group request, did not respond to the initial 642 request. The client in this case always uses a Message ID that 643 differs from the initial multicast message. 645 In the above client behaviors, the Token value is kept identical to 646 the initial request to avoid that a client is included in more than 647 one entry in the list of observers (Section 4.1 of [RFC7641]). 649 Before repeating a request as specified above, the client SHOULD wait 650 for at least the expected round-trip time plus the Leisure time 651 period defined in Section 8.2 of [RFC7252], to give the server time 652 to respond. 654 A server that receives a legitimate GET request with the Observe 655 Option, for which request processing is successful, SHOULD NOT 656 suppress the response to this request, because the client is 657 obviously interested in the resource representation. A server that 658 adds a client to the list of observers for a resource due to an 659 Observe request MUST NOT suppress the response to this request. 661 A server SHOULD have a mechanism to verify liveness of its observing 662 clients and the continued interest of these clients in receiving the 663 observe notifications. This can be implemented by sending 664 notifications occassionally using a Confirmable message. See 665 Section 4.5 of [RFC7641] for details. This requirement overrides the 666 regular behavior of sending Non-Confirmable notifications in response 667 to a Non-Confirmable request. 669 For observing a group of servers through a CoAP-to-CoAP proxy or 670 HTTP-CoAP proxy, the limitations stated in Section 2.2.3 apply. 672 2.2.6. Block-Wise Transfer 674 Section 2.8 of [RFC7959] specifies how a client can use block-wise 675 transfer (Block2 Option) in a multicast GET request to limit the size 676 of the initial response of each server. The client has to use 677 unicast for any further requests, separately addressing each 678 different server, in order to retrieve more blocks of the resource 679 from that server, if any. Also, a server (group member) that needs 680 to respond to a multicast request with a particularly large resource 681 can use block-wise transfer (Block2 Option) at its own initiative, to 682 limit the size of the initial response. Again, a client would have 683 to use unicast for any further requests to retrieve more blocks of 684 the resource. 686 A solution for multicast block-wise transfer using the Block1 Option 687 is not specified in [RFC7959] nor in the present document. Such a 688 solution would be useful for multicast PUT/POST/PATCH/iPATCH 689 requests, to efficiently distribute a large request payload as 690 multiple blocks to all members of a CoAP group. Multicast usage of 691 Block1 is non-trivial due to potential message loss (leading to 692 missing blocks or missing confirmations), and potential diverging 693 block size preferences of different members of the multicast group. 695 2.3. Transport 697 In this document only UDP is considered as a transport protocol, both 698 over IPv4 and IPv6. Therefore, [RFC8323] (CoAP over TCP, TLS, and 699 WebSockets) is not in scope as a transport for group communication. 701 2.3.1. UDP/IPv6 Multicast Transport 703 CoAP group communication can use UDP over IPv6 as a transport 704 protocol, provided that IPv6 multicast is enabled. IPv6 multicast 705 MAY be supported in a network only for a limited scope. For example, 706 Section 2.4.2 describes the potential limited support of RPL for 707 multicast, depending on how the protocol is configured. 709 For a CoAP server node that supports resource discovery as defined in 710 Section 2.4 of [RFC7252], the default port 5683 MUST be supported as 711 per Section 7.1 and 12.8 of [RFC7252] for the "All CoAP Nodes" 712 multicast group. An IPv6 CoAP server SHOULD support the "All CoAP 713 Nodes" groups with at least link-local (2), admin-local (4) and site- 714 local (5) scopes. An IPv6 CoAP server on a 6LoWPAN node (see 715 Section 2.3.3) SHOULD also support the realm-local (3) scope. 717 Note that a client sending an IPv4 multicast CoAP message to a port 718 that is not supported by the server will not receive an ICMP Port 719 Unreachable error message from that server, because the server does 720 not send it in this case, per Section 3.2.2 of [RFC1122]. 722 2.3.2. UDP/IPv4 Multicast Transport 724 CoAP group communication can use UDP over IPv4 as a transport 725 protocol, provided that IPv4 multicast is enabled. For a CoAP server 726 node that supports resource discovery as defined in Section 2.4 of 727 [RFC7252], the default port 5683 MUST be supported as per Section 7.1 728 and 12.8 of [RFC7252], for the "All CoAP Nodes" IPv4 multicast group. 730 Note that a client sending an IPv6 multicast CoAP message to a port 731 that is not supported by the server will not receive an ICMPv6 Port 732 Unreachable error message from that server, because the server does 733 not send it in this case, per Section 2.4 of [RFC4443]. 735 2.3.3. 6LoWPAN 737 In 6LoWPAN [RFC4944] networks, IPv6 packets (up to 1280 bytes) may be 738 fragmented into smaller IEEE 802.15.4 MAC frames (up to 127 bytes), 739 if the packet size requires this. Every 6LoWPAN IPv6 router that 740 receives a multi-fragment packet reassembles the packet and 741 refragments it upon transmission. Since the loss of a single 742 fragment implies the loss of the entire IPv6 packet, the performance 743 in terms of packet loss and throughput of multi-fragment multicast 744 IPv6 packets is typically far worse than the performance of single- 745 fragment IPv6 multicast packets. For this reason, a CoAP request 746 sent over multicast in 6LoWPAN networks SHOULD be sized in such a way 747 that it fits in a single IEEE 802.15.4 MAC frame, if possible. 749 On 6LoWPAN networks, multicast groups can be defined with realm-local 750 scope [RFC7346]. Such a realm-local group is restricted to the local 751 6LoWPAN network/subnet. In other words, a multicast request to that 752 group does not propagate beyond the 6LoWPAN network segment where the 753 request originated. For example, a multicast discovery request can 754 be sent to the realm-local "All CoAP Nodes" IPv6 multicast group (see 755 Section 2.3.1) in order to discover only CoAP servers on the local 756 6LoWPAN network. 758 2.4. Interworking with Other Protocols 760 2.4.1. MLD/MLDv2/IGMP/IGMPv3 762 CoAP nodes that are IP hosts (i.e., not IP routers) are generally 763 unaware of the specific IP multicast routing/forwarding protocol 764 being used in their network. When such a host needs to join a 765 specific (CoAP) multicast group, it requires a way to signal to IP 766 multicast routers which IP multicast address(es) it needs to listen 767 to. 769 The MLDv2 protocol [RFC3810] is the standard IPv6 method to achieve 770 this; therefore, this method SHOULD be used by group members to 771 subscribe to the multicast group IPv6 address, on IPv6 networks that 772 support it. CoAP server nodes then act in the role of MLD Multicast 773 Address Listener. Constrained IPv6 networks that implement either 774 RPL (see Section 2.4.2) or MPL (see Section 2.4.3) typically do not 775 support MLD as they have their own mechanisms defined. 777 The IGMPv3 protocol [RFC3376] is the standard IPv4 method to signal 778 multicast group subscriptions. This SHOULD be used by group members 779 to subscribe to their multicast group IPv4 address on IPv4 networks. 781 The guidelines from [RFC6636] on the tuning of MLD for mobile and 782 wireless networks may be useful when implementing MLD in LLNs. 784 2.4.2. RPL 786 RPL [RFC6550] is an IPv6 based routing protocol suitable for low- 787 power, lossy networks (LLNs). In such a context, CoAP is often used 788 as an application protocol. 790 If RPL is used in a network for routing and its optional multicast 791 support is disabled, there will be no IP multicast routing available. 792 Any IPv6 multicast packets in this case will not propagate beyond a 793 single hop (to direct neighbors in the LLN). This implies that any 794 CoAP group communication request will be delivered to link-local 795 nodes only, for any scope value >= 2 used in the IPv6 destination 796 address. 798 RPL supports (see Section 12 of [RFC6550]) advertisement of IP 799 multicast destinations using Destination Advertisement Object (DAO) 800 messages and subsequent routing of multicast IPv6 packets based on 801 this. It requires the RPL mode of operation to be 3 (Storing mode 802 with multicast support). 804 In this mode, RPL DAO can be used by a CoAP node that is either an 805 RPL router or RPL Leaf Node, to advertise its IP multicast group 806 membership to parent RPL routers. Then, RPL will route any IP 807 multicast CoAP requests over multiple hops to those CoAP servers that 808 are group members. 810 The same DAO mechanism can be used to convey IP multicast group 811 membership information to an edge router (e.g., 6LBR), in case the 812 edge router is also the root of the RPL Destination-Oriented Directed 813 Acyclic Graph (DODAG). This is useful because the edge router then 814 learns which IP multicast traffic it needs to pass through from the 815 backbone network into the LLN subnet. In LLNs, such ingress 816 filtering helps to avoid congestion of the resource-constrained 817 network segment, due to IP multicast traffic from the high-speed 818 backbone IP network. 820 2.4.3. MPL 822 The Multicast Protocol for Low-Power and Lossy Networks (MPL) 823 [RFC7731] can be used for propagation of IPv6 multicast packets 824 throughout a defined network domain, over multiple hops. MPL is 825 designed to work in LLNs. MPL defines the protocol for a predefined 826 group of MPL Forwarders to collectively distribute IPv6 multicast 827 packets throughout their MPL Domain. An MPL Forwarder may be 828 associated to multiple MPL Domains at the same time. Non-Forwarders 829 will receive IPv6 multicast packets from one or more of their 830 neighboring Forwarders. Therefore, MPL can be used to propagate a 831 CoAP multicast request to all group members. 833 However, a CoAP multicast request to a group that originated outside 834 of the MPL Domain will not be propagated by MPL - unless an MPL 835 Forwarder is explicitly configured as an ingress point that 836 introduces external multicast packets into the MPL Domain. Such an 837 ingress point could be located on an edge router (e.g., 6LBR). The 838 method to configure which multicast groups are to be propagated into 839 the MPL Domain could be: 841 o Manual configuration on the ingress MPL Forwarder. 843 o A protocol to register multicast groups at an ingress MPL 844 Forwarder. This could be a protocol offering features similar to 845 MLDv2. 847 3. Unsecured Group Communication 849 CoAP group communication can operate in CoAP NoSec (No Security) 850 mode, without using application-layer and transport-layer security 851 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 852 Section 9 of [RFC7252]. Before using this mode of operation, the 853 security implications (Section 5.1) must be well understood. 855 4. Secured Group Communication using Group OSCORE 857 The application-layer protocol Object Security for Constrained 858 RESTful Environments (OSCORE) [RFC8613] provides end-to-end 859 encryption, integrity and replay protection of CoAP messages 860 exchanged between two CoAP endpoints. These can act both as CoAP 861 Client as well as CoAP Server, and share an OSCORE Security Context 862 used to protect and verify exchanged messages. The use of OSCORE 863 does not affect the URI scheme and OSCORE can therefore be used with 864 any URI scheme defined for CoAP. 866 OSCORE uses COSE [RFC8152] to perform encryption, signing and Message 867 Authentication Code operations, and to efficiently encode the result 868 as a COSE object. In particular, OSCORE takes as input an 869 unprotected CoAP message and transforms it into a protected CoAP 870 message, by using an Authenticated Encryption with Associated Data 871 (AEAD) algorithm. 873 OSCORE makes it possible to selectively protect different parts of a 874 CoAP message in different ways, so still allowing intermediaries 875 (e.g., CoAP proxies) to perform their intended funtionalities. That 876 is, some message parts are encrypted and integrity protected; other 877 parts are only integrity protected to be accessible to, but not 878 modifiable by, proxies; and some parts are kept as plain content to 879 be both accessible to and modifiable by proxies. Such differences 880 especially concern the CoAP options included in the unprotected 881 message. 883 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 884 provides end-to-end security of CoAP messages exchanged between 885 members of an OSCORE group, while fulfilling the same security 886 requirements. 888 In particular, Group OSCORE protects CoAP requests sent over IP 889 multicast by a CoAP client, as well as multiple corresponding CoAP 890 responses sent over IP unicast by different CoAP servers. However, 891 the same keying material can also be used to protect CoAP requests 892 sent over IP unicast to a single CoAP server in the OSCORE group, as 893 well as the corresponding responses. 895 Group OSCORE uses digital signatures to ensure source authentication 896 of all messages exchanged within the OSCORE group. That is, sender 897 devices sign their outgoing messages by means of their own private 898 key, and embed the signature in the protected CoAP message. 900 A Group Manager is responsible for one or multiple OSCORE groups. In 901 particular, the Group Manager acts as repository of public keys of 902 group members; manages, renews and provides keying material in the 903 group; and handles the join process of new group members. 905 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 906 can join an OSCORE group by using the method described in 907 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 908 for Authentication and Authorization in constrained environments 909 [I-D.ietf-ace-oauth-authz]. 911 A CoAP endpoint can discover OSCORE groups and retrieve information 912 to join them through their Group Managers by using the method 913 described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE 914 Resource Directory [I-D.ietf-core-resource-directory]. 916 If security is required, CoAP group communication as described in 917 this specification MUST use Group OSCORE. In particular, a CoAP 918 group as defined in Section 2.1.1 and using secure group 919 communication is associated to an OSCORE group, which includes: 921 o All members of the CoAP group, i.e. the CoAP endpoints configured 922 (also) as CoAP servers and listening to the group's multicast IP 923 address. 925 o All further CoAP endpoints configured only as CoAP clients, that 926 send (multicast) CoAP requests to the CoAP group. 928 4.1. Secure Group Maintenance 930 Additional key management operations on the OSCORE group are 931 required, depending also on the security requirements of the 932 application (see Section 5.2). That is: 934 o Adding new members to a CoAP group or enabling new client-only 935 endpoints to interact with that group require also that each of 936 such members/endpoints join the corresponding OSCORE group. By 937 doing so, they are securely provided with the necessary 938 cryptographic material. In case backward security is needed, this 939 also requires to first renew such material and distribute it to 940 the current members/endpoints, before new ones are added and join 941 the OSCORE group. 943 o In case forward security is needed, removing members from a CoAP 944 group or stopping client-only endpoints from interacting with that 945 group requires removing such members/endpoints from the 946 corresponding OSCORE group. To this end, new cryptographic 947 material is generated and securely distributed only to the 948 remaining members/endpoints. This ensures that only the members/ 949 endpoints intended to remain are able to continue participating to 950 secure group communication, while the evicted ones are not able 951 to. 953 The key management operations mentioned above are entrusted to the 954 Group Manager responsible for the OSCORE group 955 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 956 them according to the approach described in 957 [I-D.ietf-ace-key-groupcomm-oscore]. 959 5. Security Considerations 961 This section provides security considerations for CoAP group 962 communication using IP multicast. 964 5.1. CoAP NoSec Mode 966 CoAP group communication, if not protected, is vulnerable to all the 967 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 969 Thus, for sensitive and mission-critical applications (e.g., health 970 monitoring systems and alarm monitoring systems), it is NOT 971 RECOMMENDED to deploy CoAP group communication in NoSec mode. 973 Without application-layer security, CoAP group communication SHOULD 974 only be deployed in applications that are non-critical, and that do 975 not involve or may have an impact on sensitive data and personal 976 sphere. These include, e.g., read-only temperature sensors deployed 977 in non-sensitive environments, where the client reads out the values 978 but does not use the data to control actuators or to base an 979 important decision on. 981 Discovery of devices and resources is a typical use case where NoSec 982 mode is applied, since the devices involved do not have yet 983 configured any mutual security relations at the time the discovery 984 takes place. 986 5.2. Group OSCORE 988 Group OSCORE provides end-to-end application-level security. This 989 has many desirable properties, including maintaining security 990 assurances while forwarding traffic through intermediaries (proxies). 991 Application-level security also tends to more cleanly separate 992 security from the dynamics of group membership (e.g., the problem of 993 distributing security keys across large groups with many members that 994 come and go). 996 For sensitive and mission-critical applications, CoAP group 997 communication MUST be protected by using Group OSCORE as specified in 998 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 999 from Section 8 of [I-D.ietf-core-oscore-groupcomm] hold for this 1000 specification. 1002 5.2.1. Group Key Management 1004 A key management scheme for secure revocation and renewal of group 1005 keying material, namely group rekeying, should be adopted in OSCORE 1006 groups. In particular, the key management scheme should preserve 1007 backward and forward security in the OSCORE group, if the application 1008 requires so (see Section 2.1 of [I-D.ietf-core-oscore-groupcomm]). 1010 Group policies should also take into account the time that the key 1011 management scheme requires to rekey the group, on one hand, and the 1012 expected frequency of group membership changes, i.e. nodes' joining 1013 and leaving, on the other hand. 1015 In fact, it may be desirable to not rekey the group upon every single 1016 membership change, in case members' joining and leaving are frequent, 1017 and at the same time a single group rekeying instance takes a non 1018 negligible time to complete. 1020 In such a case, the Group Manager may consider to rekey the group, 1021 e.g., after a minimum number of nodes has joined or left the group 1022 within a pre-defined time interval, or according to communication 1023 patterns with predictable intervals of network inactivity. This 1024 would prevent paralizing communications in the group, when a slow 1025 rekeying scheme is used and frequently invoked. 1027 This comes at the cost of not continuously preserving backward and 1028 forward security, since group rekeying might not occur upon every 1029 single group membership change. That is, latest joined nodes would 1030 have access to the key material used prior to their join, and thus be 1031 able to access past group communications protected with that key 1032 material. Similarly, until the group is rekeyed, latest left nodes 1033 would preserve access to group communications protected with the 1034 retained key material. 1036 5.2.2. Source Authentication 1038 CoAP endpoints using Group OSCORE countersign their outgoing 1039 messages, by means of the countersignature algorithm used in the 1040 OSCORE group. This ensures source authentication of messages 1041 exchanged by CoAP endpoints through CoAP group communication. In 1042 fact, it allows to verify that a received message has actually been 1043 originated by a specific and identified member of the OSCORE group. 1045 Appendix F of [I-D.ietf-core-oscore-groupcomm] discusses a number of 1046 cases where a recipient CoAP endpoint may skip the verification of 1047 countersignatures, possibly on a per-message basis. However, this is 1048 NOT RECOMMENDED. That is, a CoAP endpoint receiving a message 1049 secured with Group OSCORE SHOULD always verify the countersignature. 1051 5.2.3. Counteraction of Attacks 1053 Group OSCORE addresses security attacks mentioned in Sections 1054 11.2-11.6 of [RFC7252], with particular reference to their execution 1055 over IP multicast. That is: it provides confidentiality and 1056 integrity of request/response data through proxies also in multicast 1057 settings; it prevents amplification attacks carried out through 1058 responses to injected requests over IP multicast; it limits the 1059 impact of attacks based on IP spoofing; it prevents cross-protocol 1060 attacks; it derives the group key material from, among other things, 1061 a Master Secret securely generated by the Group Manager and provided 1062 to CoAP endpoints upon their joining of the OSCORE group; 1063 countersignatures assure source authentication of exchanged CoAP 1064 messages, and hence prevent a group member to be used for subverting 1065 security in the whole group. 1067 5.3. Use of CoAP No Response Option 1069 The CoAP No Server Response Option [RFC7967] could be misused by a 1070 malicious client to evoke as much responses from servers to a 1071 multicast request as possible, by using the value '0' - Interested in 1072 all responses. This can even override the default behaviour of a 1073 CoAP server to suppress the response in case there is nothing of 1074 interest to respond with. Therefore, this option can be used to 1075 perform an amplification attack. A proposed mitigation is to only 1076 allow this Option to relax the standard suppression rules for a 1077 resource in case the Option is sent by an authenticated client. If 1078 sent by an unauthenticated client, the Option can be used to expand 1079 the classes of responses suppressed compared to the default rules but 1080 not to reduce the classes of responses suppressed. 1082 5.4. 6LoWPAN 1084 In a 6LoWPAN network, a multicast IPv6 packet may be fragmented prior 1085 to transmission. A 6LoWPAN Router that forwards a fragmented packet 1086 can have a relatively high impact on the occupation of the wireless 1087 channel and on the memory load of the local node due to packet buffer 1088 occupation. For example, the MPL [RFC7731] protocol requires an MPL 1089 Forwarder to store the packet for a longer duration, to allow 1090 multiple forwarding transmissions to neighboring Forwarders. If only 1091 one of the fragments is not received correctly by an MPL Forwarder, 1092 the receiver needs to discard all received fragments and it needs to 1093 receive all the packet fragments again on a future occasion. 1095 For these reasons, a fragmented IPv6 multicast packet is a possible 1096 attack vector in a Denial of Service (DoS) amplification attack. See 1097 Section 11.3 of [RFC7252] for more details on amplification. To 1098 mitigate the risk, applications sending multicast IPv6 requests to 1099 6LoWPAN hosted CoAP servers SHOULD limit the size of the request to 1100 avoid 6LoWPAN fragmentation. A 6LoWPAN Router or multicast forwarder 1101 SHOULD deprioritize forwarding for multi-fragment 6LoWPAN multicast 1102 packets. Also, a 6LoWPAN Border Router SHOULD implement multicast 1103 packet filtering to prevent unwanted multicast traffic from entering 1104 a 6LoWPAN network from the outside. For example, it could filter out 1105 all multicast packet for which there is no known multicast listener 1106 on the 6LoWPAN network. 1108 5.5. Wi-Fi 1110 In a home automation scenario using Wi-Fi, Wi-Fi security should be 1111 enabled to prevent rogue nodes from joining. The Customer Premises 1112 Equipment (CPE) that enables access to the Internet should also have 1113 its IP multicast filters set so that it enforces multicast scope 1114 boundaries to isolate local multicast groups from the rest of the 1115 Internet (e.g., as per [RFC6092]). In addition, the scope of IP 1116 multicast transmissions and listeners should be site-local (5) or 1117 smaller. For site-local scope, the CPE will be an appropriate 1118 multicast scope boundary point. 1120 5.6. Monitoring 1122 5.6.1. General Monitoring 1124 CoAP group communication can be used to control a set of related 1125 devices: for example, simultaneously turn on all the lights in a 1126 room. This intrinsically exposes the group to some unique monitoring 1127 risks that devices not in a group are not as vulnerable to. For 1128 example, assume an attacker is able to physically see a set of lights 1129 turn on in a room. Then the attacker can correlate an observed CoAP 1130 group communication message to the observed coordinated group action 1131 - even if the CoAP message is (partly) encrypted. 1132 This will give the attacker side-channel information to plan further 1133 attacks (e.g., by determining the members of the group some network 1134 topology information may be deduced). 1136 5.6.2. Pervasive Monitoring 1138 A key additional threat consideration for group communication is 1139 pervasive monitoring [RFC7258]. CoAP group communication solutions 1140 that are built on top of IP multicast need to pay particular heed to 1141 these dangers. This is because IP multicast is easier to intercept 1142 (and to secretly record) compared to IP unicast. Also, CoAP traffic 1143 is meant for the Internet of Things. This means that CoAP multicast 1144 may be used for the control and monitoring of critical infrastructure 1145 (e.g., lights, alarms, etc.) that may be prime targets for attack. 1147 For example, an attacker may attempt to record all the CoAP traffic 1148 going over a smart grid (i.e., networked electrical utility) and try 1149 to determine critical nodes for further attacks. For example, the 1150 source node (controller) sends out CoAP group communication messages 1151 which easily identifies it as a controller. 1152 CoAP multicast traffic is inherently more vulnerable (compared to 1153 unicast) as the same packet may be replicated over many links, 1154 leading to a higher probability of packet capture by a pervasive 1155 monitoring system. 1157 One mitigation is to restrict the scope of IP multicast to the 1158 minimal scope that fulfills the application need. Thus, for example, 1159 site-local IP multicast scope is always preferred over global scope 1160 IP multicast if this fulfills the application needs. 1162 Even if all CoAP multicast traffic is encrypted/protected, an 1163 attacker may still attempt to capture this traffic and perform an 1164 off-line attack in the future. 1166 6. IANA Considerations 1168 This document has no actions for IANA. 1170 7. References 1172 7.1. Normative References 1174 [I-D.ietf-core-oscore-groupcomm] 1175 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1176 "Group OSCORE - Secure Group Communication for CoAP", 1177 draft-ietf-core-oscore-groupcomm-05 (work in progress), 1178 July 2019. 1180 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1181 Communication Layers", STD 3, RFC 1122, 1182 DOI 10.17487/RFC1122, October 1989, 1183 . 1185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1186 Requirement Levels", BCP 14, RFC 2119, 1187 DOI 10.17487/RFC2119, March 1997, 1188 . 1190 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1191 Thyagarajan, "Internet Group Management Protocol, Version 1192 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1193 . 1195 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1196 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1197 DOI 10.17487/RFC3810, June 2004, 1198 . 1200 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1201 Control Message Protocol (ICMPv6) for the Internet 1202 Protocol Version 6 (IPv6) Specification", STD 89, 1203 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1204 . 1206 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1207 "Transmission of IPv6 Packets over IEEE 802.15.4 1208 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1209 . 1211 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1212 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1213 . 1215 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1216 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1217 October 2013, . 1219 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1220 Application Protocol (CoAP)", RFC 7252, 1221 DOI 10.17487/RFC7252, June 2014, 1222 . 1224 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1225 Application Protocol (CoAP)", RFC 7641, 1226 DOI 10.17487/RFC7641, September 2015, 1227 . 1229 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1230 the Constrained Application Protocol (CoAP)", RFC 7959, 1231 DOI 10.17487/RFC7959, August 2016, 1232 . 1234 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1235 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1236 the Constrained Application Protocol (CoAP)", RFC 8075, 1237 DOI 10.17487/RFC8075, February 2017, 1238 . 1240 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1241 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1242 . 1244 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1245 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1246 May 2017, . 1248 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1249 "Object Security for Constrained RESTful Environments 1250 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1251 . 1253 7.2. Informative References 1255 [Californium] 1256 Eclipse Foundation, "Eclipse Californium", March 2019, 1257 . 1261 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 1262 CoAP Server & Client in Go", March 2019, 1263 . 1265 [I-D.ietf-ace-key-groupcomm-oscore] 1266 Tiloca, M., Park, J., and F. Palombini, "Key Management 1267 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1268 oscore-02 (work in progress), July 2019. 1270 [I-D.ietf-ace-oauth-authz] 1271 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1272 H. Tschofenig, "Authentication and Authorization for 1273 Constrained Environments (ACE) using the OAuth 2.0 1274 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 1275 (work in progress), March 2019. 1277 [I-D.ietf-core-coap-pubsub] 1278 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1279 Subscribe Broker for the Constrained Application Protocol 1280 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1281 progress), September 2019. 1283 [I-D.ietf-core-multipart-ct] 1284 Fossati, T., Hartke, K., and C. Bormann, "Multipart 1285 Content-Format for CoAP", draft-ietf-core-multipart-ct-04 1286 (work in progress), August 2019. 1288 [I-D.ietf-core-resource-directory] 1289 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1290 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1291 resource-directory-23 (work in progress), July 2019. 1293 [I-D.tiloca-core-oscore-discovery] 1294 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1295 Groups with the CoRE Resource Directory", draft-tiloca- 1296 core-oscore-discovery-03 (work in progress), July 2019. 1298 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1299 Capabilities in Customer Premises Equipment (CPE) for 1300 Providing Residential IPv6 Internet Service", RFC 6092, 1301 DOI 10.17487/RFC6092, January 2011, 1302 . 1304 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1305 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1306 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1307 Low-Power and Lossy Networks", RFC 6550, 1308 DOI 10.17487/RFC6550, March 2012, 1309 . 1311 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1312 the Internet Group Management Protocol (IGMP) and 1313 Multicast Listener Discovery (MLD) for Routers in Mobile 1314 and Wireless Networks", RFC 6636, DOI 10.17487/RFC6636, 1315 May 2012, . 1317 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1318 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1319 2014, . 1321 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1322 DOI 10.17487/RFC7346, August 2014, 1323 . 1325 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1326 the Constrained Application Protocol (CoAP)", RFC 7390, 1327 DOI 10.17487/RFC7390, October 2014, 1328 . 1330 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1331 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1332 February 2016, . 1334 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1335 Bose, "Constrained Application Protocol (CoAP) Option for 1336 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1337 August 2016, . 1339 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1340 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1341 Application Protocol) over TCP, TLS, and WebSockets", 1342 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1343 . 1345 Appendix A. Use Cases 1347 To illustrate where and how CoAP-based group communication can be 1348 used, this section summarizes the most common use cases. These use 1349 cases include both secured and non-secured CoAP usage. Each 1350 subsection below covers one particular category of use cases for 1351 CoRE. Within each category, a use case may cover multiple 1352 application areas such as home IoT, commercial building IoT (sensing 1353 and control), industrial IoT/control, or environmental sensing. 1355 A.1. Discovery 1357 Discovery of physical devices in a network, or discovery of 1358 information entities hosted on network devices, are operations that 1359 are usually required in a system during the phases of setup or 1360 (re)configuration. When a discovery use case involves devices that 1361 need to interact without having been configured previously with a 1362 common security context, unsecured CoAP communication is typically 1363 used. Discovery may involve a request to a directory server, which 1364 provides services to aid clients in the discovery process. One 1365 particular type of directory server is the CoRE Resource Directory 1366 [I-D.ietf-core-resource-directory]; and there may be other types of 1367 directories that can be used with CoAP. 1369 A.1.1. Distributed Device Discovery 1371 Device discovery is the discovery and identification of networked 1372 devices - optionally only devices of a particular class, type, model, 1373 or brand. Group communication is used for distributed device 1374 discovery, if a central directory server is not used. Typically in 1375 distributed device discovery, a multicast request is sent to a 1376 particular address (or address range) and multicast scope of 1377 interest, and any devices configured to be discoverable will respond 1378 back. For the alternative solution of centralized device discovery a 1379 central directory server is accessed through unicast, in which case 1380 group communication is not needed. This requires that the address of 1381 the central directory is either preconfigured in each device or 1382 configured during operation using a protocol. 1384 In CoAP, device discovery can be implemented by CoAP resource 1385 discovery requesting (GET) a particular resource that the sought 1386 device class, type, model or brand is known to respond to. It can 1387 also be implemented using CoAP resource discovery (Section 7 of 1388 [RFC7252]) and the CoAP query interface defined in Section 4 of 1389 [RFC6690] to find these particular resources. Also, a multicast GET 1390 request to /.well-known/core can be used to discover all CoAP 1391 devices. 1393 A.1.2. Distributed Service Discovery 1395 Service discovery is the discovery and identification of particular 1396 services hosted on network devices. Services can be identified by 1397 one or more parameters such as ID, name, protocol, version and/or 1398 type. Distributed service discovery involves group communication to 1399 reach individual devices hosting a particular service; with a central 1400 directory server not being used. 1402 In CoAP, services are represented as resources and service discovery 1403 is implemented using resource discovery (Section 7 of [RFC7252]) and 1404 the CoAP query interface defined in Section 4 of [RFC6690]. 1406 A.1.3. Directory Discovery 1408 This use case is a specific sub-case of Distributed Service Discovery 1409 (Appendix A.1.2), in which a device needs to identify the location of 1410 a Directory on the network to which it can e.g. register its own 1411 offered services, or to which it can perform queries to identify and 1412 locate other devices/services it needs to access on the network. 1413 Section 3.3 of [RFC7390] shows an example of discovering a CoRE 1414 Resource Directory using CoAP group communication. As defined in 1415 [I-D.ietf-core-resource-directory], a resource directory is a web 1416 entity that stores information about web resources and implements 1417 REST interfaces for registration and lookup of those resources. For 1418 example, a device can register itself to a resource directory to let 1419 it be found by other devices and/or applications. 1421 A.2. Operational Phase 1423 Operational phase use cases describe those operations that occur most 1424 frequently in a networked system, during its operational lifetime and 1425 regular operation. Regular usage is when the applications on 1426 networked devices perform the tasks they were designed for and 1427 exchange of application-related data using group communication 1428 occurs. Processes like system reconfiguration, group changes, 1429 system/device setup, extra group security changes, etc. are not part 1430 of regular operation. 1432 A.2.1. Actuator Group Control 1434 Group communication can be beneficial to control actuators that need 1435 to act in synchrony, as a group, with strict timing (latency) 1436 requirements. Examples are office lighting, stage lighting, street 1437 lighting, or audio alert/Public Address systems. Sections 3.4 and 1438 3.5 of [RFC7390] show examples of lighting control of a group of 1439 6LoWPAN-connected lights. 1441 A.2.2. Device Group Status Request 1443 To properly monitor the status of systems, there may be a need for 1444 ad-hoc, unplanned status updates. Group communication can be used to 1445 quickly send out a request to a (potentially large) number of devices 1446 for specific information. Each device then responds back with the 1447 requested data. Those devices that did not respond to the request 1448 can optionally be polled again via reliable unicast communication to 1449 complete the dataset. The device group may be defined e.g. as "all 1450 temperature sensors on floor 3", or "all lights in wing B". For 1451 example, it could be a status request for device temperature, most 1452 recent sensor event detected, firmware version, network load, and/or 1453 battery level. 1455 A.2.3. Network-wide Query 1457 In some cases a whole network or subnet of multiple IP devices needs 1458 to be queried for status or other information. This is similar to 1459 the previous use case except that the device group is not defined in 1460 terms of its function/type but in terms of its network location. 1461 Technically this is also similar to distributed service discovery 1462 (Appendix A.1.2) where a query is processed by all devices on a 1463 network - except that the query is not about services offered by the 1464 device, but rather specific operational data is requested. 1466 A.2.4. Network-wide / Group Notification 1468 In some cases a whole network, or subnet of multiple IP devices, or a 1469 specific target group needs to be notified of a status change or 1470 other information. This is similar to the previous two use cases 1471 except that the recipients are not expected to respond with some 1472 information. Unreliable notification can be acceptable in some use 1473 cases, in which a recipient does not respond with a confirmation of 1474 having received the notification. In such a case, the receiving CoAP 1475 server does not have to create a CoAP response. If the sender needs 1476 confirmation of reception, the CoAP servers can be configured for 1477 that resource to respond with a 2.xx success status after processing 1478 a notification request successfully. 1480 A.3. Software Update 1482 Multicast can be useful to efficiently distribute new software 1483 (firmware, image, application, etc.) to a group of multiple devices. 1484 In this case, the group is defined in terms of device type: all 1485 devices in the target group are known to be capable of installing and 1486 running the new software. The software is distributed as a series of 1487 smaller blocks that are collected by all devices and stored in 1488 memory. All devices in the target group are usually responsible for 1489 integrity verification of the received software; which can be done 1490 per-block or for the entire software image once all blocks have been 1491 received. Due to the inherent unreliability of CoAP multicast, there 1492 needs to be a backup mechanism (e.g. implemented using CoAP unicast) 1493 by which a device can individually request missing blocks of a whole 1494 software image/entity. Prior to multicast software update, the group 1495 of recipients can be separately notified that there is new software 1496 available and coming, using the above network-wide or group 1497 notification. 1499 Acknowledgments 1501 The authors sincerely thank Thomas Fossati and Jim Schaad for their 1502 comments and feedback. 1504 The work on this document has been partly supported by VINNOVA and 1505 the Celtic-Next project CRITISEC. 1507 Authors' Addresses 1509 Esko Dijk 1510 IoTconsultancy.nl 1511 \________________\ 1512 Utrecht 1513 The Netherlands 1515 Email: esko.dijk@iotconsultancy.nl 1517 Chonggang Wang 1518 InterDigital 1519 1001 E Hector St, Suite 300 1520 Conshohocken PA 19428 1521 United States 1523 Email: Chonggang.Wang@InterDigital.com 1524 Marco Tiloca 1525 RISE AB 1526 Isafjordsgatan 22 1527 Kista SE-16440 Stockholm 1528 Sweden 1530 Email: marco.tiloca@ri.se