idnits 2.17.1 draft-dijk-core-groupcomm-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 (July 08, 2019) is 1725 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-04 ** 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-01 == 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-08 == Outdated reference: A later version (-04) exists of draft-ietf-core-multipart-ct-03 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-22 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-02 Summary: 2 errors (**), 0 flaws (~~), 8 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: January 9, 2020 RISE AB 8 July 08, 2019 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-dijk-core-groupcomm-bis-01 13 Abstract 15 This document specifies the use of the Constrained Application 16 Protocol (CoAP) for group communication, using UDP/IP multicast as 17 the underlying data transport. The target application area is any 18 group communication use cases in resource-constrained networks. Both 19 unsecured and secured CoAP group communication are specified. 20 Security is achieved by use of the Group Object Security for 21 Constrained RESTful Environments (Group OSCORE) protocol. Aspects of 22 operation of using multicast CoAP in combination with CoAP block-wise 23 transfers and CoAP observe are also specified. 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 January 9, 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 . . . . . . . . . . . . . . . . . . 6 68 2.2. CoAP Usage . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Request/Response Model . . . . . . . . . . . . . . . 7 70 2.2.2. Port and URI Path Selection . . . . . . . . . . . . . 8 71 2.2.3. Proxy Operation . . . . . . . . . . . . . . . . . . . 9 72 2.2.4. Congestion Control . . . . . . . . . . . . . . . . . 11 73 2.2.5. Observing Resources . . . . . . . . . . . . . . . . . 12 74 2.2.6. Block-Wise Transfer . . . . . . . . . . . . . . . . . 13 75 2.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 15 76 2.3.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 15 77 2.3.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 15 78 2.3.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 15 79 2.4. Interworking with Other Protocols . . . . . . . . . . . . 15 80 2.4.1. MLD/MLDv2/IGMP . . . . . . . . . . . . . . . . . . . 15 81 2.4.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 2.4.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 3. Unsecured Group Communication . . . . . . . . . . . . . . . . 15 84 4. Secured Group Communication using Group OSCORE . . . . . . . 16 85 4.1. Secure Group Maintenance . . . . . . . . . . . . . . . . 17 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 5.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 18 88 5.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 18 89 5.2.1. Group Key Management . . . . . . . . . . . . . . . . 19 90 5.2.2. Source Authentication . . . . . . . . . . . . . . . . 19 91 5.2.3. Counteraction of Attacks . . . . . . . . . . . . . . 20 92 5.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 5.4. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 5.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 98 7.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Appendix A. Use Cases . . . . . . . . . . . . . . . . . . . . . 23 100 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 24 101 A.1.1. Distributed Device Discovery . . . . . . . . . . . . 24 102 A.1.2. Distributed Service Discovery . . . . . . . . . . . . 24 103 A.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 25 104 A.2. Operational Phase . . . . . . . . . . . . . . . . . . . . 25 105 A.2.1. Actuator Group Control . . . . . . . . . . . . . . . 25 106 A.2.2. Device Group Status Request . . . . . . . . . . . . . 25 107 A.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 26 108 A.2.4. Network-wide / Group Notification . . . . . . . . . . 26 109 A.3. Software Update . . . . . . . . . . . . . . . . . . . . . 26 110 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 113 1. Introduction 115 This document specifies group communication using the Constrained 116 Application Protocol (CoAP) [RFC7252] together with UDP/IP multicast. 117 CoAP is a RESTful communication protocol that is used in resource- 118 constrained nodes, and in resource-constrained networks where packet 119 sizes should be small. This area of use is summarized as Constrained 120 RESTful Environments (CoRE). 122 One-to-many group communication can be achieved in CoAP, by a client 123 using UDP/IP multicast data transport to send multicast CoAP request 124 messages. In response, each server in the addressed group sends a 125 response message back to the client over UDP/IP unicast. Notable 126 CoAP implementations supporting group communication include the 127 framework "Eclipse Californium" 2.0.x [Californium] from the Eclipse 128 Foundation and the "Implementation of CoAP Server & Client in Go" 129 [Go-OCF] from the Open Connectivity Foundation (OCF). 131 Both unsecured and secured CoAP group communication over UDP/IP 132 multicast are specified in this document. Security is achieved by 133 using Group Object Security for Constrained RESTful Environments 134 (Group OSCORE) [I-D.ietf-core-oscore-groupcomm], which in turn builds 135 on Object Security for Constrained Restful Environments (OSCORE) 136 [I-D.ietf-core-object-security]. This method provides end-to-end 137 application-layer security protection of CoAP messages, by using CBOR 138 Object Signing and Encryption (COSE) [RFC8152] [RFC7049]. 140 All sections in the body of this document are normative, while 141 appendices are informative. For additional background about use 142 cases for CoAP group communication in resource-constrained devices 143 and networks, see Appendix A. 145 1.1. Scope 147 For group communication, only solutions that use CoAP over UDP/ 148 multicast (both IPv6 and IPv4) are in scope. There are alternative 149 methods to achieve group communication using CoAP, for example 150 Publish-Subscribe [I-D.ietf-core-coap-pubsub] which uses a central 151 broker server that CoAP clients access via unicast communication. 152 The alternative methods may be usable for the same or similar use 153 cases as are targeted in this document. 155 All guidelines in [RFC7390] are imported by this document which 156 replaces [RFC7390] in this respect. This document furthermore adds 157 the security solution using Group OSCORE as the default group 158 communication security solution for CoAP, an updated request/response 159 matching rule for multicast CoAP which updates [RFC7252], multicast 160 use of CoAP Observe which updates [RFC7641] and extension of 161 multicast use of CoAP block-wise transfers which updates [RFC7959]. 163 Security solutions for group communication and configuration other 164 than Group OSCORE are not in scope. General principles for secure 165 group configuration are in scope. The experimental group 166 configuration protocol in Section 2.6.2 of [RFC7390] is not in the 167 scope of this document; thus, it remains an experimental protocol. 168 Since application protocols defined on top of CoAP often define their 169 own specific method of group configuration, the experimental protocol 170 of [RFC7390] has not been subject to enough experimentation to 171 warrant a change of this status. 173 1.2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 This specification requires readers to be familiar with CoAP 182 [RFC7252] terminology. 184 2. General Group Communication Operation 186 The general operation of group communication, applicable for both 187 unsecured and secured operation, is specified in this section by 188 going through the stack from top to bottom. First, group 189 configuration (e.g. group creation and maintenance which are usually 190 done by an application, user or commissioning entity) is considered 191 in Section 2.1. Then the use of CoAP for group communication 192 including support for protocol extensions (block-wise, Observe, PATCH 193 method) follows in Section 2.2. How CoAP group messages are carried 194 over various transport layers is the subject of Section 2.3. 195 Finally, Section 2.4 covers the interworking of CoAP with other 196 protocols at the layers below it. 198 2.1. Group Configuration 200 2.1.1. Group Definition 202 A CoAP group is defined as a set of CoAP endpoints, where each 203 endpoint is configured to receive CoAP multicast requests that are 204 sent to the group's associated IP multicast address and UDP port. An 205 endpoint may be a member of multiple CoAP groups. Group 206 membership(s) of an endpoint may dynamically change over time. A 207 device sending a CoAP request to a group is not necessarily itself a 208 member of this group: it is only a member if it also has a CoAP 209 server endpoint listening to requests for this CoAP group. For 210 secure group communication, a receiver also requires the security 211 context to decrypt and/or verify group messages in order to be a 212 group member. 214 A CoAP Group URI has the scheme 'coap' and includes in the authority 215 part either an IP multicast address or a group hostname (e.g., Group 216 Fully Qualified Domain Name (FQDN)) that can be resolved to an IP 217 multicast address. A Group URI also contains an optional UDP port 218 number in the authority part. Group URIs follow the regular CoAP URI 219 syntax (Section 6 of [RFC7252]). 221 Besides CoAP groups, that have relevance at the level of networked 222 devices, there can also be application groups defined. An 223 application group has relevance at the application level - for 224 example an application group could denote all lights in an office 225 room or all sensors in a hallway. There can be a one-to-one or a 226 one-to-many relation between CoAP groups and application groups. 228 2.1.2. Group Naming 230 For clients, it is RECOMMENDED to use by default an IP multicast 231 address literal in a configured Group URI, instead of a hostname. 232 This is because DNS infrastructure may not be deployed in many 233 constrained networks. In case a group hostname is used in the Group 234 URI, it can be uniquely mapped to an IP multicast address via DNS 235 resolution - if DNS client functionality is available in the clients 236 and the DNS service is supported in the network. Some examples of 237 hierarchical group FQDN naming (and scoping) for a building control 238 application are shown in Section 2.2 of [RFC7390]. 240 Application groups can be named in many ways, e.g. numbers, IDs, 241 strings or URIs. An application group identifier, if used, is 242 typically included in the path component or query component of a 243 Group URI. Appendix A of [I-D.ietf-core-resource-directory] shows 244 registration of application groups into a Resource Directory, along 245 with the CoAP group it maps to. 247 2.1.3. Group Creation and Membership 249 Group membership may be (factory-)preconfigured in devices or 250 dynamically configured in a system on-site. 252 To create a CoAP group, a configuring entity defines an IP multicast 253 address (or hostname) for the group and optionally a UDP port number 254 in case it differs from the default CoAP port 5683. Then, it 255 configures one or more devices as listeners to that IP multicast 256 address, with a CoAP server listening on the specific port. These 257 devices are the group members. The configuring entity can be a local 258 application with preconfiguration, a user, a cloud service, or a 259 local commissioning tool for example. Also, the devices sending 260 requests to the group in the role of CoAP clients need to be 261 configured with the same information, even though they are not 262 necessarily group members. One way to configure a client is to 263 supply it with a CoAP Group URI. 265 For unsecure group communication, any CoAP endpoint may become a 266 group member at any time: there is no (central) configuring entity 267 that needs to provide the security material for the group. This 268 means that group creation and membership cannot be tightly 269 controlled. 271 The IETF does not define a mandatory, standardized protocol to 272 accomplish these steps. For secure group communication, the part of 273 the process that involves secure distribution of group keys MAY use 274 standardized communication with a Group Manager as defined in 275 Section 4. [RFC7390] defines an experimental protocol for 276 configuration of group membership for unsecured group communication, 277 based on JSON-formatted configuration resources. This protocol 278 remains experimental. 280 2.1.4. Group Maintenance 282 Maintenance of a group includes necessary operations to cope with 283 changes in a system, such as: adding group members, removing group 284 members, reconfiguration of UDP port and/or IP multicast address, 285 reconfiguration of the Group URI, splitting of groups, or merging of 286 groups. 288 For unsecured group communication (see Section 3), addition/removal 289 of group members is simply done by configuring these devices to 290 start/stop listening to the group IP multicast address, and to start/ 291 stop the CoAP server listening to the group IP multicast address and 292 port. 294 For secured group communication (see Section 4), the protocol Group 295 OSCORE [I-D.ietf-core-oscore-groupcomm] is mandatory to implement. 296 When using Group OSCORE, CoAP endpoints participating to group 297 communication are also members of a corresponding OSCORE group, and 298 thus share a common set of cryptographic material. Additional 299 maintenance operations are discussed in Section 4.1. 301 2.2. CoAP Usage 303 2.2.1. Request/Response Model 305 All CoAP requests that are sent via IP multicast MUST be Non- 306 confirmable (Section 8.1 of [RFC7252]). The Message ID in an IP 307 multicast CoAP message is used for optional message deduplication as 308 detailed in Section 4.5 of [RFC7252]. 310 A server MAY send back a unicast response to the CoAP group 311 communication request - whether it does this or not is selected by 312 the server application. The unicast responses received by the CoAP 313 client may be a mixture of success (e.g., 2.05 Content) and failure 314 (e.g., 4.04 Not Found) codes depending on the individual server 315 processing results. 317 TBD: the CoAP Option for No Server Response [RFC7967] can be used by 318 the client to influence response suppression on the server side. 319 Possibly we can include this information here; it specifically 320 targets use for multicast use cases also. 322 The client can distinguish the origin of multiple server responses by 323 the source IP address of the UDP message containing the CoAP response 324 or any other available unique identifier (e.g., contained in the CoAP 325 response payload). In case a client has sent multiple group requests 326 with concurrent CoAP transactions ongoing, the responses are matched 327 to a request using the Token value. The source endpoint of the 328 response is not matched to the destination endpoint of the request, 329 since for a multicast request these will never match. This is also 330 specified in Section 8.2 of [RFC7252]. As an update to the [RFC7252] 331 matching rule, a client MAY, in addition to the Token, match the 332 source port of the request to the destination port of the response, 333 since these will match in any correctly formatted CoAP response. 334 This can help a client to more easily meet the below constraint on 335 Token reuse or to more efficiently filter received responses. 337 For multicast CoAP requests, there are additional constraints on the 338 reuse of Token values, compared to the unicast case. In the unicast 339 case, if the Observe Option [RFC7641] is not used in a request, 340 receiving a response effectively frees up its Token value for reuse 341 since no more responses will follow. However, for multicast CoAP, 342 the number of responses is not bounded a priori. Therefore, the 343 reception of a response cannot be used as a trigger to "free up" a 344 Token value for reuse. Reusing a Token value too early could lead to 345 incorrect response/request matching in the client and would be a 346 protocol error. Therefore, the time between reuse of Token values 347 used in multicast requests MUST be greater than: 349 NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY 351 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 352 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 353 in [RFC7390], that is: the expected maximum response delay over all 354 servers that the client can send a multicast request to. This delay 355 includes the maximum Leisure time period as defined in Section 8.2 of 356 [RFC7252]. However, CoAP does not define a time limit for the server 357 response delay. Using the default CoAP parameters, the Token reuse 358 time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. 359 A preferred solution to meet this requirement is to generate a new 360 unique Token for every multicast request, such that a Token value is 361 never reused. If a client has to reuse Token values for some reason, 362 and also MAX_SERVER_RESPONSE_DELAY is unknown, then using 363 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 364 The time between Token reuses is in that case set to a value greater 365 than 500 seconds. 367 2.2.2. Port and URI Path Selection 369 A CoAP server that is a member of a group listens for CoAP messages 370 on the group's IP multicast address, usually on the CoAP default UDP 371 port 5683, or another non-default UDP port if configured. Regardless 372 of the method for selecting the port number, the same port number 373 MUST be used across all CoAP servers that are members of a group and 374 across all CoAP clients performing the group requests to that group. 375 The URI Path used in the request is preferably a path that is known 376 to be supported across all group members. However there are valid 377 use cases where a request is known to be successful for a subset of 378 the group and those group members for which the request is 379 unsuccessful either ignore the multicast request or respond with an 380 error status code. 382 Using different ports with the same IP multicast address is an 383 efficient way to create multiple CoAP groups in constrained devices, 384 in case the device's stack only supports a limited number of IP 385 multicast group memberships. However, it must be taken into account 386 that this incurs additional processing overhead on each CoAP server 387 participating in at least one of these groups: messages to groups 388 that are not of interest to the node are only discarded at the higher 389 transport (UDP) layer instead of directly at the network (IP) layer. 391 Port 5684 is reserved for DTLS-secured CoAP and MUST NOT be used for 392 any CoAP group communication. 394 For a CoAP server node that supports resource discovery as defined in 395 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 396 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 397 group. THis implies that the receiving server when correctly 398 operating does not send a "ICMP Destination Unreachable - Port 399 Unreachable" in response to a resource discovery request. 401 2.2.3. Proxy Operation 403 CoAP (Section 5.7.2 of [RFC7252]) allows a client to request a 404 forward-proxy to process its CoAP request. For this purpose, the 405 client specifies either the request group URI as a string in the 406 Proxy-URI option or alternatively it uses the Proxy-Scheme option 407 with the group URI constructed from the usual Uri-* options. This 408 approach works well for unicast requests. However, there are certain 409 issues and limitations of processing the (unicast) responses to a 410 CoAP group communication request made in this manner through a proxy. 412 A proxy may buffer all the individual (unicast) responses to a CoAP 413 group communication request and then send back only a single 414 (aggregated) response to the client. However, there are some issues 415 with this aggregation approach: 417 o Aggregation of (unicast) responses to a CoAP group communication 418 request in a proxy is difficult. This is because the proxy does 419 not know how many members there are in the group or how many group 420 members will actually respond. Also, the proxy does not know how 421 long to wait before deciding to send back the aggregated response 422 to the client. 424 o There is no default format defined in CoAP for aggregation of 425 multiple responses into a single response. Such a format could be 426 defined based on the multipart content-format 427 [I-D.ietf-core-multipart-ct] but is not standardized yet 428 currently. 430 Alternatively, if a proxy does not aggregate responses and follows 431 the CoAP Proxy specification (Section 5.7.2 of [RFC7252]), the proxy 432 would forward all the individual (unicast) responses to a CoAP group 433 communication request to the client. There are also issues with this 434 approach: 436 o The client may be confused as it may not have known that the 437 Proxy-URI contained a group URI target. That is, the client that 438 sent a unicast CoAP request to the proxy may be expecting only one 439 (unicast) response. Instead, it receives multiple (unicast) 440 responses, potentially leading to fault conditions in the 441 application. 443 o Each individual CoAP response will appear to originate (based on 444 its IP source address) from the CoAP Proxy, and not from the 445 server that produced the response. This makes it impossible for 446 the client to identify the server that produced each response, 447 unless the server identity is contained as a part of the response 448 payload. 450 Due to the above issues, a CoAP Proxy SHOULD NOT support processing 451 an IP multicast CoAP request but rather return a 501 (Not 452 Implemented) response in such case. The exception case here (i.e., 453 to support it) is when all the following conditions are met: 455 o The CoAP Proxy MUST be explicitly configured (whitelist) to allow 456 proxied IP multicast requests by specific client(s). 458 o The proxy SHOULD return individual (unicast) CoAP responses to the 459 client (i.e., not aggregated). If a (future) standardized 460 aggregation format is being used, then aggregated responses may be 461 sent. 463 o It MUST be known to the person/entity doing the configuration of 464 the proxy, or otherwise verified in some way, that the client 465 configured in the whitelist supports receiving multiple responses 466 to a proxied unicast CoAP request. 468 The operation of HTTP-to-CoAP proxies for multicast CoAP requests is 469 specified in Section 8.4 and 10.1 of [RFC8075]. In this case, the 470 "application/http" media type can be used to let the proxy return 471 multiple CoAP responses - each translated to a HTTP response - back 472 to the HTTP client. Of course the HTTP client in this case needs to 473 be aware that it is receiving this format and needs to be able to 474 decode from it the responses of multiple servers. The above 475 restrictions listed for CoAP Proxies still apply to HTTP-to-CoAP 476 proxies: specifically, the IP address of the sender of each CoAP 477 response cannot be determined from the application/http response. 479 2.2.4. Congestion Control 481 CoAP group communication requests may result in a multitude of 482 responses from different nodes, potentially causing congestion. 483 Therefore, both the sending of IP multicast requests and the sending 484 of the unicast CoAP responses to these multicast requests should be 485 conservatively controlled. 487 CoAP [RFC7252] reduces IP multicast-specific congestion risks through 488 the following measures: 490 o A server may choose not to respond to an IP multicast request if 491 there's nothing useful to respond to (e.g., error or empty 492 response); see Section 8.2 of [RFC7252]. 494 o A server should limit the support for IP multicast requests to 495 specific resources where multicast operation is required 496 (Section 11.3 of [RFC7252]). 498 o An IP multicast request MUST be Non-confirmable (Section 8.1 of 499 [RFC7252]). 501 o A response to an IP multicast request SHOULD be Non-confirmable 502 (Section 5.2.3 of [RFC7252]). 504 o A server does not respond immediately to an IP multicast request 505 and should first wait for a time that is randomly picked within a 506 predetermined time interval called the Leisure (Section 8.2 of 507 [RFC7252]). 509 Additional guidelines to reduce congestion risks defined in this 510 document are as follows: 512 o A server in an LLN should only support group communication GET for 513 resources that are small. For example, the payload of the 514 response is limited to approximately 5% of the IP Maximum Transmit 515 Unit (MTU) size, so it fits into a single link-layer frame in case 516 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 517 Section 4 of [RFC4944]) is used. 519 o A server SHOULD minimize the payload length in response to a 520 multicast GET on "/.well-known/core" by using hierarchy in 521 arranging link descriptions for the response. An example of this 522 is given in Section 5 of [RFC6690]. 524 o A server MAY minimize the payload length of a response to a 525 multicast GET (e.g., on "/.well-known/core") using CoAP block-wise 526 transfers [RFC7959] in case the payload is long, returning only a 527 first block of the CoRE Link Format description. For this reason, 528 a CoAP client sending an IP multicast CoAP request to "/.well- 529 known/core" SHOULD support block-wise transfers. 531 o A client SHOULD use CoAP group communication with the smallest 532 possible IP multicast scope that fulfills the application needs. 533 As an example, site-local scope is always preferred over global 534 scope IP multicast if this fulfills the application needs. 535 Similarly, realm-local scope is always preferred over site-local 536 scope if this fulfills the application needs. 538 2.2.5. Observing Resources 540 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 541 that allows a CoAP client to retrieve a representation of a resource 542 and automatically keep this representation up-to-date over a longer 543 period of time. The client gets notified when the representation has 544 changed. [RFC7641] does not mention whether the Observe Option can 545 be combined with CoAP multicast. 547 This section updates [RFC7641] with the use of the Observe Option in 548 a CoAP multicast GET request. This is a useful way to start 549 observing a particular resource on all members of a (multicast) group 550 at the same time. Group members that do not have this resource or do 551 not allow the GET method on it will either respond with an error 552 status - 4.04 Not Found or 4.05 Method Not Allowed respectively - or 553 will silently ignore the request, depending on server-specific 554 configuration. 556 A client that sends a multicast GET request with the Observe Option 557 MAY repeat this request using the same Token value and same Observe 558 Option value, in order to ensure that enough (or all) group members 559 have been reached with the request. This is useful in case a number 560 of group members did not respond to the initial request. This client 561 MAY also use the same Message ID to avoid that group members that had 562 already received the initial request would respond again. If the 563 client uses a different, fresh Message ID then all group members that 564 receive this new message will respond again. 566 A client that sends a multicast GET request with the Observe Option 567 MAY send a new unicast request with the same Token value and same 568 Observe Option value, in order to ensure that the specific server 569 receives the request. This is useful in case a specific group 570 member, that was expected to respond to the initial group request, 571 did not respond to the initial request. The client in this case 572 always uses a Message ID that differs from the initial message. 574 In the above client behaviors, the Token value is kept identical to 575 the initial request to avoid that the client is included in more than 576 one entry in the list of observers (Section 4.1 of [RFC7641]). While 577 a Token value is in use for observing a group, this Token value 578 cannot be reused by the same client endpoint for other purposes. 579 Another endpoint on the client i.e. using a different UDP source port 580 MAY re-use the Token value but only if the client implements the 581 optional updated matching rule of Section 2.2.1. 583 Before repeating a request as specified above, the client SHOULD wait 584 for at least the expected round-trip time plus the Leisure time 585 period defined in Section 8.2 of [RFC7252] to allow the server the 586 time to respond. 588 For observing a group of servers through a CoAP-to-CoAP proxy or 589 HTTP-CoAP proxy, the limitations stated in Section 2.2.3 apply. 591 2.2.6. Block-Wise Transfer 593 Section 2.8 of [RFC7959] specifies how a client can use block-wise 594 transfer (Block2 Option) in a multicast GET request to limit the size 595 of the initial response of each server. The client has to use 596 unicast for any further requests to retrieve more blocks of the 597 resource. Also, a server (group member) that needs to respond to a 598 multicast request with a particularly large resource can use block- 599 wise transfer (Block2 Option) at its own initiative to limit the size 600 of the initial response. Again, a client would have to use unicast 601 for any further requests to retrieve more blocks of the resource. 603 TBD: below solution for multicast block-wise Block1 is used e.g. for 604 efficiently distributing large data/software updates using multicast. 605 It is non-trivial to do right and needs testing. For this reason, we 606 may decide to move this into a separate draft. 608 This section specifies in addition the use of CoAP block-wise 609 transfers for multicast PUT/POST/PATCH/iPATCH requests in order to 610 efficiently distribute a large request payload as multiple blocks to 611 all members of a CoAP group. The Block1 Option [RFC7959] is then 612 used by the client in each block-wise request and a server uses the 613 Block1 Option in its response to confirm reception of a block and 614 optionally to indicate in the first block-wise response that it 615 prefers a smaller block size. 617 Prior to starting a block-wise multicast request, the client SHOULD 618 already store a list of those members of the CoAP group that need to 619 properly receive the request payload. These members are expected to 620 support block-wise CoAP and are also expected to support the specific 621 resource to which the request will be sent. Obtaining such list can 622 be achieved in various ways such as by group configuration, and/or 623 CoAP discovery, and/or first sending one or more non-block-wise 624 multicast requests to the same group and collect the responses. 626 The reason that the client should be aware of these group members is 627 the following: after sending the first block (0), the client SHOULD 628 first collect all group member responses to the first block before 629 proceeding with further blocks. One or more of the group members MAY 630 indicate a preference for a smaller block size in the Block1 Option 631 in its first response. The client SHOULD use the smallest value over 632 all collected responses as the block size to use for the remaining 633 block-wise messages. 635 Since not all group member responses may be received, due to message 636 loss, the client MAY resend the multicast request (with the same 637 Message ID and Token) to collect the missing responses, or it MAY 638 resend the block 0 request as a Confirmable or Non-Confirmable 639 unicast request (with the same Message ID and Token) directly to the 640 non-responsive group member(s), or it uses a combination of these. 641 The reason to use the same Message ID here is to avoid that a group 642 member server processes the request more than once. 644 TBD: open point - the server needs to treat a unicast message (with 645 token T and MID M) as a duplicate of a prior multicast message (with 646 token T and MID M). The deduplication rules allow this; however to 647 be checked if a practical implementation also allows this? 649 TBD: open point - the time that the process takes to collect all 650 "missing" responses for the first block (0), might take longer than 651 the "operation timeout time" of the entire blockwise request per 652 [RFC7959]. So for this case, the operation timeout time needs to be 653 set longer than usual, or alternatively, the stateless-server mode of 654 update needs to be mandated. In this case each block that is written 655 produces a 2.04 not 2.31. First block with PUT may respond a 2.01. 657 TBD: if strict order of blocks is required by a server, the protocol 658 must wait and collect again all responses after each block. 660 TBD: a protocol may be more efficient that first sends all blocks 661 (without waiting for all responses every step) and then later checks 662 which blocks are missing with all servers individually. These can be 663 resent then (in unicast or multicast if many servers miss that 664 block). 666 2.3. Transport 668 TBD: Mark [RFC8323] (TCP, TLS, WebSockets) as not applicable for this 669 form of groupcomm, as well as CoAP-over-SMS. 671 2.3.1. UDP/IPv6 Multicast Transport 673 TBD: include the "Exceptions" cases here of RFC 7390 Section 2.10. 674 State that IPv6 multicast is prerequisite. Also mention the All- 675 CoAP-nodes IPv6 addresses. 677 2.3.2. UDP/IPv4 Multicast Transport 679 TBD: includes the "Exceptions" cases here of RFC 7390 2.10. State 680 that IPv4 multicast is prerequisite. mention All-CoAP-nodes IPv4 681 addresses and the like 683 2.3.3. 6LoWPAN 685 TBD: 6lowpan-specific considerations to go here. Specifically, a 686 multicast request should preferably fit in one L2 frame to avoid the 687 strong performance drop that comes with 6LoWPAN-fragmentation and 688 reassembly. Also reference [RFC7346] for the realm-local scope. 690 2.4. Interworking with Other Protocols 692 2.4.1. MLD/MLDv2/IGMP 694 TBD: see Section 4.2 of [RFC7390] and include the content here or 695 refer to it. 697 2.4.2. RPL 699 TBD: see Section 4.3 of [RFC7390] and include the content here or 700 refer to it. 702 2.4.3. MPL 704 TBD: see Section 4.4. [RFC7390] and include the content here or 705 refer to it. 707 3. Unsecured Group Communication 709 CoAP group communication can operate in CoAP NoSec (No Security) 710 mode, without using application-layer and transport-layer security 711 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 712 Section 9 of [RFC7252]. Before using this mode of operation, the 713 security implications (Section 5.1) must be well understood. 715 4. Secured Group Communication using Group OSCORE 717 The application-layer protocol Object Security for Constrained 718 RESTful Environments (OSCORE) [I-D.ietf-core-object-security] 719 provides end-to-end encryption, integrity and replay protection of 720 CoAP messages exchanged between two CoAP endpoints. These can act 721 both as CoAP Client as well as CoAP Server, and share an OSCORE 722 Security Context used to protect and verify exchanged messages. The 723 use of OSCORE does not affect the URI scheme and OSCORE can therefore 724 be used with any URI scheme defined for CoAP. 726 OSCORE uses COSE [RFC8152] to perform encryption, signing and Message 727 Authentication Code operations, and to efficiently encode the result 728 as a COSE object. In particular, OSCORE takes as input an 729 unprotected CoAP message and transforms it into a protected CoAP 730 message, by using Authenticated Encryption Algorithms with Additional 731 Data (AEAD). 733 OSCORE makes it possible to selectively protect different parts of a 734 CoAP message in different ways, so still allowing intermediaries 735 (e.g., CoAP proxies) to perform their intended funtionalities. That 736 is, some message parts are encrypted and integrity protected; other 737 parts only integrity protected to be accessible to, but not 738 modifiable by, proxies; and some parts are kept as plain content to 739 be both accessible to and modifiable by proxies. Such differences 740 especially concern the CoAP options included in the unprotected 741 message. 743 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 744 provides end-to-end security of CoAP messages exchanged between 745 members of an OSCORE group, while fulfilling the same security 746 requirements. 748 In particular, Group OSCORE protects CoAP requests sent over IP 749 multicast by a CoAP client, as well as multiple corresponding CoAP 750 responses sent over IP unicast by different CoAP servers. However, 751 the same keying material can also be used to protect CoAP requests 752 sent over IP unicast to a single CoAP server in the OSCORE group, as 753 well as the corresponding responses. 755 Group OSCORE uses digital signatures to ensure source authentication 756 of all messages exchanged within the OSCORE group. That is, sender 757 devices sign their outgoing messages by means of their own private 758 key, and embed the signature in the protected CoAP message. 760 A Group Manager is responsible for one or multiple OSCORE groups. In 761 particular, the Group Manager acts as repository of public keys of 762 group members; manages, renews and provides keying material in the 763 group; and drives the join process for new group members. 765 As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 766 can join an OSCORE group by using the method described in 767 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 768 for Authentication and Authorization in constrained environments 769 [I-D.ietf-ace-oauth-authz]. 771 A CoAP endpoint can discover OSCORE groups and retrieve information 772 to join them through their Group Managers by using the method 773 described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE 774 Resource Directory [I-D.ietf-core-resource-directory]. 776 If security is required, CoAP group communication as described in 777 this specification MUST use Group OSCORE. In particular, a CoAP 778 group as defined in Section 2.1.1 and using secure group 779 communication is associated to an OSCORE group, which includes: 781 o All members of the CoAP group, i.e. the CoAP endpoints configured 782 (also) as CoAP servers and listening to the group's multicast IP 783 address. 785 o All further CoAP endpoints configured only as CoAP clients, that 786 send (multicast) CoAP requests to the CoAP group. 788 4.1. Secure Group Maintenance 790 Additional key management operations on the OSCORE group are 791 required, depending also on the security requirements of the 792 application (see Section 5.2). That is: 794 o Adding new members to a CoAP group or enabling new client-only 795 endpoints to interact with that group require also that each of 796 such members/endpoints join the corresponding OSCORE group. By 797 doing so, they are securely provided with the necessary 798 cryptographic material. In case backward security is needed, this 799 also requires to first renew such material and distribute it to 800 the current members/endpoints, before new ones are added and join 801 the OSCORE group. 803 o In case forward security is needed, removing members from a CoAP 804 group or stopping client-only endpoints from interacting with that 805 group requires removing such members/endpoints from the 806 corresponding OSCORE group. To this end, new cryptographic 807 material is generated and securely distributed only to the 808 remaining members/endpoints. This ensures that only the members/ 809 endpoints intended to remain are able to continue participating to 810 secure group communication, while the evicted ones are not able 811 to. 813 The key management operations mentioned above are entrusted to the 814 Group Manager responsible for the OSCORE group 815 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 816 them according to the approach described in 817 [I-D.ietf-ace-key-groupcomm-oscore]. 819 5. Security Considerations 821 This section provides security considerations for CoAP group 822 communication using IP multicast. 824 5.1. CoAP NoSec Mode 826 CoAP group communication, if not protected, is vulnerable to all the 827 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 829 Thus, for sensitive and mission-critical applications (e.g., health 830 monitoring systems and alarm monitoring systems), it is NOT 831 RECOMMENDED to deploy CoAP group communication in NoSec mode. 833 Without application-layer security, CoAP group communication SHOULD 834 only be deployed in applications that are non-critical, and that do 835 not involve or may have an impact on sensitive data and personal 836 sphere. These include, e.g., read-only temperature sensors deployed 837 in non-sensitive environments, where the client reads out the values 838 but does not use the data to control actuators or to base an 839 important decision on. 841 Discovery of devices and resources is a typical use case where NoSec 842 mode is applied, since the devices involved do not have yet 843 configured any mutual security relations at the time the discovery 844 takes place. 846 5.2. Group OSCORE 848 Group OSCORE provides end-to-end application-level security. This 849 has many desirable properties, including maintaining security 850 assurances while forwarding traffic through intermediaries (proxies). 851 Application-level security also tends to more cleanly separate 852 security from the dynamics of group membership (e.g., the problem of 853 distributing security keys across large groups with many members that 854 come and go). 856 For sensitive and mission-critical applications, CoAP group 857 communication MUST be protected by using Group OSCORE as specified in 859 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 860 from Section 8 of [I-D.ietf-core-oscore-groupcomm] hold for this 861 specification. 863 5.2.1. Group Key Management 865 A key management scheme for secure revocation and renewal of group 866 keying material, namely group rekeying, should be adopted in OSCORE 867 groups. In particular, the key management scheme should preserve 868 backward and forward security in the OSCORE group, if the application 869 requires so (see Section 2.1 of [I-D.ietf-core-oscore-groupcomm]). 871 Group policies should also take into account the time that the key 872 management scheme requires to rekey the group, on one hand, and the 873 expected frequency of group membership changes, i.e. nodes' joining 874 and leaving, on the other hand. 876 In fact, it may be desirable to not rekey the group upon every single 877 membership change, in case members' joining and leaving are frequent, 878 and at the same time a single group rekeying instance takes a non 879 negligible time to complete. 881 In such a case, the Group Manager may consider to rekey the group, 882 e.g., after a minum number of nodes have joined or left the group 883 within a pre-defined time interval, or according to communication 884 patterns with predictable intervals of network inactivity. This 885 would prevent paralizing communications in the group, when a slow 886 rekeying scheme is used and frequently invoked. 888 This comes at the cost of not continuously preserving backward and 889 forward security, since group rekeying might not occur upon every 890 single group membership change. That is, latest joined nodes would 891 have access to the key material used prior to their join, and thus be 892 able to access past group communications protected with that key 893 material. Similarly, until the group is rekeyed, latest left nodes 894 would preserve access to group communications protected with the 895 retained key material. 897 5.2.2. Source Authentication 899 CoAP endpoints using Group OSCORE countersign their outgoing 900 messages, by means of the countersignature algorithm used in the 901 OSCORE group. This ensures source authentication of messages 902 exchanged by CoAP endpoints through CoAP group communication. In 903 fact, it allows to verify that a received message has actually been 904 originated by a specific and identified member of the OSCORE group. 906 Appendix F of [I-D.ietf-core-oscore-groupcomm] discusses a number of 907 cases where a recipient CoAP endpoint may skip the verification of 908 countersignatures, possibly on a per-message basis. However, this is 909 NOT RECOMMENDED. That is, a CoAP endpoint receiving a message 910 secured with Group OSCORE SHOULD always verify the countersignature. 912 5.2.3. Counteraction of Attacks 914 Group OSCORE addresses security attacks mentioned in Sections 915 11.2-11.6 of [RFC7252], with particular reference to their execution 916 over IP multicast. That is: it provides confidentiality and 917 integrity of request/response data through proxies also in multicast 918 settings; it prevents amplification attacks carried out through 919 responses to injected requests over IP multicast; it limits the 920 impact of attacks based on IP spoofing; it prevents cross-protocol 921 attacks; it derives the group key material from, among other things, 922 a Master Secret securely generated by the Group Manager and provided 923 to CoAP endpoints upon their joining of the OSCORE group; 924 countersignatures assure source authentication of exchanged CoAP 925 messages, and hence prevent a group member to be used for subverting 926 security in the whole group. 928 5.3. 6LoWPAN 930 Editor Note, TBD: identify if multi-fragment multicast requests have 931 a negative effect on security and, if so, advice here on trying to 932 avoid such requests. Also an attacker could use multi-fragment to 933 occupy reassembly buffers of many routing 6LoWPAN nodes. 935 5.4. Wi-Fi 937 TBD: Wi-Fi specific security considerations; see also Section 5.3.1 938 of [RFC7390]. 940 5.5. Monitoring 942 TBD: see Section 5.4 of [RFC7390]. 944 6. IANA Considerations 946 This document has no actions for IANA. 948 7. References 949 7.1. Normative References 951 [I-D.ietf-core-object-security] 952 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 953 "Object Security for Constrained RESTful Environments 954 (OSCORE)", draft-ietf-core-object-security-16 (work in 955 progress), March 2019. 957 [I-D.ietf-core-oscore-groupcomm] 958 Tiloca, M., Selander, G., Palombini, F., and J. Park, 959 "Group OSCORE - Secure Group Communication for CoAP", 960 draft-ietf-core-oscore-groupcomm-04 (work in progress), 961 March 2019. 963 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 964 Requirement Levels", BCP 14, RFC 2119, 965 DOI 10.17487/RFC2119, March 1997, 966 . 968 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 969 "Transmission of IPv6 Packets over IEEE 802.15.4 970 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 971 . 973 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 974 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 975 . 977 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 978 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 979 October 2013, . 981 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 982 Application Protocol (CoAP)", RFC 7252, 983 DOI 10.17487/RFC7252, June 2014, 984 . 986 [RFC7641] Hartke, K., "Observing Resources in the Constrained 987 Application Protocol (CoAP)", RFC 7641, 988 DOI 10.17487/RFC7641, September 2015, 989 . 991 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 992 the Constrained Application Protocol (CoAP)", RFC 7959, 993 DOI 10.17487/RFC7959, August 2016, 994 . 996 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 997 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 998 the Constrained Application Protocol (CoAP)", RFC 8075, 999 DOI 10.17487/RFC8075, February 2017, 1000 . 1002 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1003 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1004 . 1006 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1007 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1008 May 2017, . 1010 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1011 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1012 Application Protocol) over TCP, TLS, and WebSockets", 1013 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1014 . 1016 7.2. Informative References 1018 [Californium] 1019 Eclipse Foundation, "Eclipse Californium", March 2019, 1020 . 1024 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 1025 CoAP Server & Client in Go", March 2019, 1026 . 1028 [I-D.ietf-ace-key-groupcomm-oscore] 1029 Tiloca, M., Park, J., and F. Palombini, "Key Management 1030 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1031 oscore-01 (work in progress), March 2019. 1033 [I-D.ietf-ace-oauth-authz] 1034 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1035 H. Tschofenig, "Authentication and Authorization for 1036 Constrained Environments (ACE) using the OAuth 2.0 1037 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 1038 (work in progress), March 2019. 1040 [I-D.ietf-core-coap-pubsub] 1041 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1042 Subscribe Broker for the Constrained Application Protocol 1043 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in 1044 progress), March 2019. 1046 [I-D.ietf-core-multipart-ct] 1047 Fossati, T., Hartke, K., and C. Bormann, "Multipart 1048 Content-Format for CoAP", draft-ietf-core-multipart-ct-03 1049 (work in progress), March 2019. 1051 [I-D.ietf-core-resource-directory] 1052 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1053 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1054 resource-directory-22 (work in progress), July 2019. 1056 [I-D.tiloca-core-oscore-discovery] 1057 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1058 Groups with the CoRE Resource Directory", draft-tiloca- 1059 core-oscore-discovery-02 (work in progress), March 2019. 1061 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 1062 DOI 10.17487/RFC7346, August 2014, 1063 . 1065 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 1066 the Constrained Application Protocol (CoAP)", RFC 7390, 1067 DOI 10.17487/RFC7390, October 2014, 1068 . 1070 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1071 Bose, "Constrained Application Protocol (CoAP) Option for 1072 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1073 August 2016, . 1075 Appendix A. Use Cases 1077 To illustrate where and how CoAP-based group communication can be 1078 used, this section summarizes the most common use cases. These use 1079 cases include both secured and non-secured CoAP usage. Each 1080 subsection below covers one particular category of use cases for 1081 CoRE. Within each category, a use case may cover multiple 1082 application areas such as home IoT, commercial building IoT (sensing 1083 and control), industrial IoT/control, or environmental sensing. 1085 A.1. Discovery 1087 Discovery of physical devices in a network, or discovery of 1088 information entities hosted on network devices, are operations that 1089 are usually required in a system during the phases of setup or 1090 (re)configuration. When a discovery use case involves devices that 1091 need to interact without having been configured previously with a 1092 common security context, unsecured CoAP communication is typically 1093 used. Discovery may involve a request to a directory server, which 1094 provides services to aid clients in the discovery process. One 1095 particular type of directory server is the CoRE Resource Directory 1096 [I-D.ietf-core-resource-directory]; and there may be other types of 1097 directories that can be used with CoAP. 1099 A.1.1. Distributed Device Discovery 1101 Device discovery is the discovery and identification of networked 1102 devices - optionally only devices of a particular class, type, model, 1103 or brand. Group communication is used for distributed device 1104 discovery, if a central directory server is not used. Typically in 1105 distributed device discovery, a multicast request is sent to a 1106 particular address (or address range) and multicast scope of 1107 interest, and any devices configured to be discoverable will respond 1108 back. For the alternative solution of centralized device discovery a 1109 central directory server is accessed through unicast, in which case 1110 group communication is not needed. This requires that the address of 1111 the central directory is either preconfigured in each device or 1112 configured during operation using a protocol. 1114 In CoAP, device discovery can be implemented by CoAP resource 1115 discovery requesting (GET) a particular resource that the sought 1116 device class, type, model or brand is known to respond to. It can 1117 also be implemented using CoAP resource discovery (Section 7 of 1118 [RFC7252]) and the CoAP query interface defined in Section 4 of 1119 [RFC6690] to find these particular resources. Also, a multicast GET 1120 request to /.well-known/core can be used to discover all CoAP 1121 devices. 1123 A.1.2. Distributed Service Discovery 1125 Service discovery is the discovery and identification of particular 1126 services hosted on network devices. Services can be identified by 1127 one or more parameters such as ID, name, protocol, version and/or 1128 type. Distributed service discovery involves group communication to 1129 reach individual devices hosting a particular service; with a central 1130 directory server not being used. 1132 In CoAP, services are represented as resources and service discovery 1133 is implemented using resource discovery (Section 7 of [RFC7252]) and 1134 the CoAP query interface defined in Section 4 of [RFC6690]. 1136 A.1.3. Directory Discovery 1138 This use case is a specific sub-case of Distributed Service Discovery 1139 (Appendix A.1.2), in which a device needs to identify the location of 1140 a Directory on the network to which it can e.g. register its own 1141 offered services, or to which it can perform queries to identify and 1142 locate other devices/services it needs to access on the network. 1143 Section 3.3 of [RFC7390] shows an example of discovering a CoRE 1144 Resource Directory using CoAP group communication. As defined in 1145 [I-D.ietf-core-resource-directory], a resource directory is a web 1146 entity that stores information about web resources and implements 1147 REST interfaces for registration and lookup of those resources. For 1148 example, a device can register itself to a resource directory to let 1149 it be found by other devices and/or applications. 1151 A.2. Operational Phase 1153 Operational phase use cases describe those operations that occur most 1154 frequently in a networked system, during its operational lifetime and 1155 regular operation. Regular usage is when the applications on 1156 networked devices perform the tasks they were designed for and 1157 exchange of application-related data using group communication 1158 occurs. Processes like system reconfiguration, group changes, 1159 system/device setup, extra group security changes, etc. are not part 1160 of regular operation. 1162 A.2.1. Actuator Group Control 1164 Group communication can be beneficial to control actuators that need 1165 to act in synchrony, as a group, with strict timing (latency) 1166 requirements. Examples are office lighting, stage lighting, street 1167 lighting, or audio alert/Public Address systems. Sections 3.4 and 1168 3.5 of [RFC7390] show examples of lighting control of a group of 1169 6LoWPAN-connected lights. 1171 A.2.2. Device Group Status Request 1173 To properly monitor the status of systems, there may be a need for 1174 ad-hoc, unplanned status updates. Group communication can be used to 1175 quickly send out a request to a (potentially large) number of devices 1176 for specific information. Each device then responds back with the 1177 requested data. Those devices that did not respond to the request 1178 can optionally be polled again via reliable unicast communication to 1179 complete the dataset. The device group may be defined e.g. as "all 1180 temperature sensors on floor 3", or "all lights in wing B". For 1181 example, it could be a status request for device temperature, most 1182 recent sensor event detected, firmware version, network load, and/or 1183 battery level. 1185 A.2.3. Network-wide Query 1187 In some cases a whole network or subnet of multiple IP devices needs 1188 to be queried for status or other information. This is similar to 1189 the previous use case except that the device group is not defined in 1190 terms of its function/type but in terms of its network location. 1191 Technically this is also similar to distributed service discovery 1192 (Appendix A.1.2) where a query is processed by all devices on a 1193 network - except that the query is not about services offered by the 1194 device, but rather specific operational data is requested. 1196 A.2.4. Network-wide / Group Notification 1198 In some cases a whole network, or subnet of multiple IP devices, or a 1199 specific target group needs to be notified of a status change or 1200 other information. This is similar to the previous two use cases 1201 except that the recipients are not expected to respond with some 1202 information. Unreliable notification can be acceptable in some use 1203 cases, in which a recipient does not respond with a confirmation of 1204 having received the notification. In such a case, the receiving CoAP 1205 server does not have to create a CoAP response. If the sender needs 1206 confirmation of reception, the CoAP servers can be configured for 1207 that resource to respond with a 2.xx success status after processing 1208 a notification request successfully. 1210 A.3. Software Update 1212 Multicast can be useful to efficiently distribute new software 1213 (firmware, image, application, etc.) to a group of multiple devices. 1214 In this case, the group is defined in terms of device type: all 1215 devices in the target group are known to be capable of installing and 1216 running the new software. The software is distributed as a series of 1217 smaller blocks that are collected by all devices and stored in 1218 memory. All devices in the target group are usually responsible for 1219 integrity verification of the received software; which can be done 1220 per-block or for the entire software image once all blocks have been 1221 received. Due to the inherent unreliability of CoAP multicast, there 1222 needs to be a backup mechanism (e.g. implemented using CoAP unicast) 1223 by which a device can individually request missing blocks of a whole 1224 software image/entity. Prior to multicast software update, the group 1225 of recipients can be separately notified that there is new software 1226 available and coming, using the above network-wide or group 1227 notification. 1229 Acknowledgments 1231 The authors sincerely thank Thomas Fossati and Jim Schaad for their 1232 comments and feedback. 1234 The work on this document has been partly supported by VINNOVA and 1235 the Celtic-Next project CRITISEC. 1237 Authors' Addresses 1239 Esko Dijk 1240 IoTconsultancy.nl 1241 ------- 1242 Utrecht 1243 The Netherlands 1245 Email: esko.dijk@iotconsultancy.nl 1247 Chonggang Wang 1248 InterDigital 1249 1001 E Hector St, Suite 300 1250 Conshohocken PA 19428 1251 United States 1253 Email: Chonggang.Wang@InterDigital.com 1255 Marco Tiloca 1256 RISE AB 1257 Isafjordsgatan 22 1258 Kista SE-16440 Stockholm 1259 Sweden 1261 Email: marco.tiloca@ri.se