idnits 2.17.1 draft-dijk-core-groupcomm-bis-00.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 updates RFC7390, 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 (March 10, 2019) is 1874 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-22 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-19 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group E. Dijk 3 Internet-Draft IoTconsultancy.nl 4 Updates: 7390, 7641 (if approved) C. Wang 5 Intended status: Standards Track InterDigital 6 Expires: September 11, 2019 M. Tiloca 7 RISE AB 8 March 10, 2019 10 Group Communication for the Constrained Application Protocol (CoAP) 11 draft-dijk-core-groupcomm-bis-00 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 the Group 19 Object Security for Constrained RESTful Environments (Group OSCORE) 20 protocol. The target application area of this specification is any 21 group communication use cases that involve resource-constrained 22 network nodes. The most common of such use cases are listed in this 23 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 September 11, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.1. Distributed Device Discovery . . . . . . . . . . . . 4 65 2.1.2. Distributed Service Discovery . . . . . . . . . . . . 5 66 2.1.3. Directory Discovery . . . . . . . . . . . . . . . . . 5 67 2.2. Operational . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2.1. Actuator Group Control . . . . . . . . . . . . . . . 6 69 2.2.2. Device Group Status Request . . . . . . . . . . . . . 6 70 2.2.3. Network-wide Query . . . . . . . . . . . . . . . . . 6 71 2.3. Software Update . . . . . . . . . . . . . . . . . . . . . 6 72 3. General Group Communication Operation . . . . . . . . . . . . 7 73 3.1. Group Configuration . . . . . . . . . . . . . . . . . . . 7 74 3.1.1. Group Definition . . . . . . . . . . . . . . . . . . 7 75 3.1.2. Group Naming (DNS) . . . . . . . . . . . . . . . . . 7 76 3.1.3. Group Creation and Membership . . . . . . . . . . . . 8 77 3.1.4. Group Maintenance . . . . . . . . . . . . . . . . . . 8 78 3.2. CoAP Usage . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.2.1. Request/Response Model . . . . . . . . . . . . . . . 9 80 3.2.2. Port and URI Path Selection . . . . . . . . . . . . . 10 81 3.2.3. Proxy Operation . . . . . . . . . . . . . . . . . . . 11 82 3.2.4. Congestion Control . . . . . . . . . . . . . . . . . 11 83 3.2.5. Observing Resources . . . . . . . . . . . . . . . . . 11 84 3.2.6. Block-Wise Transfer . . . . . . . . . . . . . . . . . 11 85 3.3. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.3.1. UDP/IPv6 Multicast Transport . . . . . . . . . . . . 12 87 3.3.2. UDP/IPv4 Multicast Transport . . . . . . . . . . . . 12 88 3.3.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . 12 89 3.4. Interworking with Other Protocols . . . . . . . . . . . . 12 90 3.4.1. MLD/MLDv2/IGMP . . . . . . . . . . . . . . . . . . . 12 91 3.4.2. RPL . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 3.4.3. MPL . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 4. Unsecured Group Communication . . . . . . . . . . . . . . . . 12 94 5. Secured Group Communication using Group OSCORE . . . . . . . 13 95 5.1. Secure Group Maintenance . . . . . . . . . . . . . . . . 14 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 97 6.1. CoAP NoSec Mode . . . . . . . . . . . . . . . . . . . . . 15 98 6.2. Group OSCORE . . . . . . . . . . . . . . . . . . . . . . 15 99 6.3. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 16 100 6.4. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 6.5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 17 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 105 8.2. Informative References . . . . . . . . . . . . . . . . . 18 106 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 109 1. Introduction 111 This document specifies the use of the Constrained Application 112 Protocol (CoAP) [RFC7252] for group communication [RFC7390]. CoAP is 113 a RESTful communication protocol that is suited for usage in 114 resource-constrained nodes, and in resource-constrained networks. 115 This area of use is summarized as Constrained RESTful Environments 116 (CoRE). 118 One-to-many group communication is achieved in CoAP by using UDP/IP 119 multicast, as the underlying data transport to send multicast request 120 messages. Multiple response messages to a single multicast request 121 message are sent over UDP/IP unicast. Notable CoAP implementations 122 supporting group communication include the framework "Eclipse 123 Californium" 2.0.x [Californium] from the Eclipse Foundation and the 124 "Implementation of CoAP Server & Client in Go" [Go-OCF] from the Open 125 Connectivity Foundation (OCF). 127 The most common use cases for group communication in resource- 128 constrained networks are listed first, in Section 2. Both unsecured 129 and secured CoAP group communication are specified in this document. 131 Security is achieved by using Group Object Security for Constrained 132 RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm], 133 which in turn builds on Object Security for Constrained Restful 134 Environments (OSCORE) [I-D.ietf-core-object-security]. This method 135 provides end-to-end application-layer security protection of CoAP 136 messages, by using CBOR Object Signing and Encryption (COSE) 137 [RFC8152] [RFC7049]. 139 1.1. Scope 141 The guidelines and experimental protocol of [RFC7390] are updated by 142 this document with the abovementioned security solution, and with 143 other recent protocol developments around CoAP such as Observe 144 [RFC7641] and Block-Wise Transfers [RFC7959]. 146 For group communication, only solutions that use CoAP over UDP/ 147 multicast (both IPv6 and IPv4) are considered. Security solutions 148 for group communication other than Group OSCORE are not in scope. 149 General principles for secure group configuration are in scope, 150 however a specific protocol for secure group configuration is not 151 mandated because this is often application-specific. 153 1.2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 This specification requires readers to be familiar with CoAP 162 [RFC7252] terminology. Section 5 requires readers to be familiar 163 with concepts and terminology from OSCORE 164 [I-D.ietf-core-object-security] and Group OSCORE 165 [I-D.ietf-core-oscore-groupcomm]. 167 2. Use Cases 169 To illustrate where and how CoAP-based group communication can be 170 used, this section summarizes the most common use cases. These use 171 cases include both secured and non-secured CoAP usage. Each 172 subsection below covers one particular technical category of use 173 cases for CoRE. Within each category, a use case may cover multiple 174 application areas such as home IoT, commercial building IoT (sensing 175 and control), industrial IoT/control, or environmental sensing. 177 2.1. Discovery 179 Discovery of physical devices in a network, or discovery of 180 information entities hosted on network devices, are operations that 181 are particularly required in a system during the phases of setup or 182 (re)configuration. When a discovery use case involves devices that 183 need to interact without having been configured previously with a 184 common security context, unsecured CoAP communication is typically 185 used. 187 2.1.1. Distributed Device Discovery 189 Device discovery is the discovery and identification of networked 190 devices of a particular class, type, model, or brand. Group 191 communication is used for distributed device discovery, where a 192 central directory service is not used. Typically in distributed 193 service discovery, a multicast request is sent to a particular 194 address (or address range) and multicast scope of interest, and any 195 devices configured to be discoverable will respond back. For the 196 alternative solution of centralized device discovery a central 197 directory service is accessed through unicast, in which case group 198 communication is not needed. 200 2.1.2. Distributed Service Discovery 202 Service discovery is the discovery and identification of particular 203 services hosted on network devices. Services can be identified by 204 one or more parameters such as ID, name, protocol, version and/or 205 type. Distributed service discovery involves group communication to 206 reach individual devices hosting a particular service; with a central 207 directory service not being used. Technically this is similar to the 208 above use case of distributed device discovery (Section 2.1.1). For 209 example, when using CoAP resource discovery (Section 7 of [RFC7252]) 210 there is no technical distinction between doing distributed device 211 discovery and distributed service discovery: both use the same CoAP 212 query interface defined in Section 4 of [RFC6690]. 214 2.1.3. Directory Discovery 216 This use case is a specific sub-case of Distributed Service Discovery 217 (Section 2.1.2), in which a device needs to identify the location of 218 a Directory on the network to which it can e.g. register its own 219 offered services, or to which it can perform queries to identify and 220 locate other devices/services it needs to access on the network. One 221 particular type of directory is the CoRE Resource Directory 222 [I-D.ietf-core-resource-directory]; and there may be other types of 223 directories that can be discovered using CoAP. Section 3.3 of 224 [RFC7390] shows an example of discovering a CoRE Resource Directory 225 using CoAP group communication. As defined in 226 [I-D.ietf-core-resource-directory], a resource directory is a web 227 entity that stores information about web resources and implements 228 REST interfaces for registration and lookup of those resources. For 229 example, a device can register itself to a resource directory to be 230 looked up by other devices and/or applications. 232 2.2. Operational 234 Operational use cases describe those operations that occur most 235 frequently in a networked system, during its operational lifetime and 236 normal usage. 238 2.2.1. Actuator Group Control 240 Group communication can be beneficial to control actuators that need 241 to act in synchrony, as a group, with strict timing (latency) 242 requirements. Examples are office lighting, stage lighting, street 243 lighting, or audio alert/Public Address systems. Sections 3.4 and 244 3.5 of [RFC7390] show examples of lighting control of a group of 245 6LoWPAN-connected lights. 247 2.2.2. Device Group Status Request 249 To properly monitor the status of systems, there may be a need for 250 ad-hoc, unplanned status updates. Group communication can be used to 251 quickly send out a request to a (potentially large) number of devices 252 for specific information. Each device then responds back with the 253 requested data. Those devices that did not respond to the request 254 can optionally be polled again via reliable unicast communication to 255 complete the dataset. The device group may be defined e.g. as "all 256 temperature sensors on floor 3", or "all lights in wing B". For 257 example, it could be a status request for device temperature, most 258 recent sensor event detected, firmware version, network load, and/or 259 battery level. 261 2.2.3. Network-wide Query 263 In some cases a whole network or subnet of multiple IP devices needs 264 to be queried for status or other information. This is similar to 265 the previous use case except that the device group is not defined in 266 terms of its function/type but in terms of its network location. 267 Technically this is also similar to distributed service discovery 268 (Section 2.1.2) where a query is processed by all devices on a 269 network - except that the query is not about services offered by the 270 device, but rather specific operational data is requested. 272 2.3. Software Update 274 Multicast can be useful to efficiently distribute new software 275 (firmware) to a group of multiple devices. In this case, the group 276 is defined in terms of device type: all devices in the target group 277 are known to be capable of installing and running the new software. 278 The software is distributed as a series of smaller blocks that are 279 collected by all devices and stored in memory. All devices in the 280 target group usually are responsible for integrity verification of 281 the received software; which can be done per-block or for the entire 282 software image once all blocks have been received. Due to the 283 inherent unreliability of CoAP multicast there needs to be a backup 284 mechanism (e.g. implemented using CoAP unicast) by which a device can 285 individually request missing software blocks. 287 3. General Group Communication Operation 289 The general operation of group communication, applicable for both 290 unsecured and secured operation, is specified in this section by 291 going through the stack from top to bottom. First, group 292 configuration (e.g. group creation and maintenance which are usually 293 done by an application, user or commissioning entity) is considered 294 in Section 3.1. Then the use of CoAP for group communication 295 including support for protocol extensions (Block-Wise, Observe, PATCH 296 method) follows in Section 3.2. How CoAP group messages are carried 297 over various transport layers is the subject of Section 3.3. 298 Finally, Section 3.4 covers the interworking of CoAP with other 299 protocols at the layers below it. 301 3.1. Group Configuration 303 3.1.1. Group Definition 305 Following [RFC7390], a CoAP group is defined here as a set of CoAP 306 endpoints, where each endpoint is configured to receive CoAP 307 multicast requests that are sent to the group's associated IP 308 multicast address. An endpoint may be a member of multiple groups. 309 Group membership(s) of an endpoint may dynamically change over time. 310 A device sending a CoAP request to a group is not necessarily itself 311 a member of this group: it is only a member if it also has a CoAP 312 server endpoint listening to requests for this group. 314 A CoAP Group URI has the scheme 'coap' and includes in the authority 315 part either an IP multicast address or a group hostname (e.g., Group 316 Fully Qualified Domain Name (FQDN)) that can be resolved to an IP 317 multicast address. A Group URI also contains an optional UDP port 318 number in the authority part. Group URIs follow the regular CoAP URI 319 syntax (Section 6 of [RFC7252]). 321 3.1.2. Group Naming (DNS) 323 For clients, it is RECOMMENDED to use by default an IP multicast 324 address literal in a configured Group URI, instead of a hostname. 325 This is because DNS infrastructure may not be deployed in many 326 constrained networks. In case a group hostname is used in the Group 327 URI, it can be uniquely mapped to an IP multicast address via DNS 328 resolution - if DNS client functionality is available in the clients 329 and the DNS service is supported in the network. Some examples of 330 hierarchical group FQDN naming (and scoping) for a building control 331 application are shown in Section 2.2 of [RFC7390]. 333 3.1.3. Group Creation and Membership 335 Group membership may be (factory-)preconfigured in devices or 336 dynamically configured in a system on-site. 338 To create a group, a configuring entity defines an IP multicast 339 address (or hostname) and a UDP port number for the group. Then it 340 configures one or more devices as listeners to that IP multicast 341 address, with a CoAP server listening on the specific port. These 342 devices are the group members. The configuring entity can be a local 343 application with preconfiguration, a user, a cloud service, or a 344 local commissioning tool for example. Also the devices sending 345 requests to the group in the role of CoAP clients need to be 346 configured with the same information, even though they are not 347 necessarily group members. One way to configure a client is to 348 supply it with a CoAP Group URI. 350 The IETF does not define a mandatory, standardized protocol to 351 accomplish these steps. For secure group communication, the part of 352 the process that involves secure distribution of group keys MAY use 353 standardized communication with a Group Manager as further defined in 354 Section 5. [RFC7390] defines an experimental protocol for 355 configuration of group membership for non-secured group 356 communication, based on JSON-formatted configuration resources. 358 3.1.4. Group Maintenance 360 Maintenance of a group includes necessary operations to cope with 361 changes in a system, such as: adding group members, removing group 362 members, reconfiguration of UDP port and/or IP multicast address, 363 reconfiguration of the Group URI, splitting of groups, or merging of 364 groups. 366 For unsecured group communication, addition/removal of group members 367 is simply done by configuring these devices to start/stop listening 368 to the group IP multicast address, and to start/stop the CoAP server 369 listening to the group IP multicast address and port. 371 When group communication is secured using Group OSCORE 372 [I-D.ietf-core-oscore-groupcomm] (see Section 5), all CoAP endpoints 373 participating to secure group communication MUST be members of a 374 corresponding OSCORE group, and thus share a common set of 375 cryptographic material. Additional maintenance operations are 376 discussed in Section 5.1. 378 3.2. CoAP Usage 380 3.2.1. Request/Response Model 382 Editor Note, TBD: this section is strongly based on Section 2.5 in 383 [RFC7390]. In case a reference to this section is preferred, we can 384 replace most of the following text in this section by a reference to 385 it. 387 All CoAP requests that are sent via IP multicast MUST be Non- 388 confirmable (Section 8.1 of [RFC7252]). The Message ID in an IP 389 multicast CoAP message is used for optional message deduplication as 390 detailed in Section 4.5 of [RFC7252]. 392 A server MAY send back a unicast response to the CoAP group 393 communication request - whether it does this or not is selected by 394 the server application. The unicast responses received by the CoAP 395 client may be a mixture of success (e.g., 2.05 Content) and failure 396 (e.g., 4.04 Not Found) codes depending on the individual server 397 processing results. 399 TBD: the CoAP Option for No Server Response [RFC7967] can be used by 400 the client to influence response suppression on the server side. 401 Possibly we can include this information here; it specifically 402 targets use for multicast use cases also. 404 The client can distinguish the origin of multiple server responses by 405 the source IP address of the UDP message containing the CoAP response 406 or any other available unique identifier (e.g., contained in the CoAP 407 response payload). In case a client has sent multiple group requests 408 with concurrent CoAP transactions ongoing, the responses are as usual 409 matched to a request using the Token. 411 For multicast CoAP requests, there are additional constraints on the 412 reuse of Token values, compared to the unicast case. In the unicast 413 case, receiving a response effectively frees up its Token value for 414 reuse since no more responses will follow. However, for multicast 415 CoAP, the number of responses is not bounded a priori. Therefore, 416 the reception of a response cannot be used as a trigger to "free up" 417 a Token value for reuse. Reusing a Token value too early could lead 418 to incorrect response/request matching in the client and would be a 419 protocol error. Therefore, the time between reuse of Token values 420 used in multicast requests MUST be greater than: 422 NON_LIFETIME + MAX_LATENCY + MAX_SERVER_RESPONSE_DELAY 424 where NON_LIFETIME and MAX_LATENCY are defined in Section 4.8 of 425 [RFC7252]. This specification defines MAX_SERVER_RESPONSE_DELAY as 426 in [RFC7390], that is: the expected maximum response delay over all 427 servers that the client can send a multicast request to. This delay 428 includes the maximum Leisure time period as defined in Section 8.2 of 429 [RFC7252]. However, CoAP does not define a time limit for the server 430 response delay. Using the default CoAP parameters, the Token reuse 431 time MUST be greater than 250 seconds plus MAX_SERVER_RESPONSE_DELAY. 432 A preferred solution to meet this requirement is to generate a new 433 unique Token for every multicast request, such that a Token value is 434 never reused. If a client has to reuse Token values for some reason, 435 and also MAX_SERVER_RESPONSE_DELAY is unknown, then using 436 MAX_SERVER_RESPONSE_DELAY = 250 seconds is a reasonable guideline. 437 The time between Token reuses is in that case set to a value greater 438 than 500 seconds. 440 3.2.2. Port and URI Path Selection 442 A CoAP server that is a member of a group listens for CoAP messages 443 on the group's IP multicast address, usually on the CoAP default UDP 444 port, 5683, or another non-default UDP port if configured. 445 Regardless of the method of selecting the port number, the same port 446 number MUST be used across all CoAP servers that are members of a 447 group and across all CoAP clients performing the group requests to 448 that group. The URI Path used in the request is preferably a path 449 that is known to be supported across all group members. However 450 there are use cases where a request only can be successful for a 451 subset of the group and errors are returned by those group members 452 for which the request was unsuccessful. 454 Using different ports with the same IP multicast address is an 455 efficient way to create multiple CoAP groups in constrained devices, 456 in case the device's stack only supports a limited number of IP 457 multicast group memberships. However, it must be taken into account 458 that this incurs additional processing overhead on each CoAP server 459 participating in at least one of these groups: messages to groups 460 that are not of interest to the node are only discarded at the higher 461 transport (UDP) layer instead of directly at the network (IP) layer. 463 Port 5684 is reserved for DTLS-secured CoAP and MUST NOT be used for 464 any CoAP group communication. 466 For a CoAP server node that supports resource discovery as defined in 467 Section 2.4 of [RFC7252], the default port 5683 MUST be supported 468 (see Section 7.1 of [RFC7252]) for the "All CoAP Nodes" multicast 469 group. 471 (TBD: consider if we should say that receiving node/server SHOULD NOT 472 send a "ICMP Destination Unreachable - Port Unreachable" in response 473 to such request.) 475 3.2.3. Proxy Operation 477 TBD: check if draft-ietf-core-multipart-ct-02 can solve the "multiple 478 answers" case when a Proxy sends back multiple CoAP responses to a 479 multicast request. Possibly a client may support this. Is there a 480 way to signal multipart support by the client? Can the multipart 481 parts signal the origin/IP address of their origin server? 483 3.2.4. Congestion Control 485 The measures to reduce network congestion risks are listed in 486 Section 2.8 of [RFC7390], including both mandatory protocol elements 487 as well as guidelines. This specification RECOMMENDS to apply the 488 guidelines specified in that section. 490 3.2.5. Observing Resources 492 The CoAP Observe Option [RFC7641] is a protocol extension of CoAP, 493 that allows a CoAP client to retrieve a representation of a resource 494 and automatically keep this representation up-to-date over a longer 495 period of time. The client gets notified when the representation has 496 changed. [RFC7641] does not mention whether the Observe Option can 497 be combined with CoAP multicast. 499 Using the Observe Option in a CoAP multicast GET request is 500 explicitly specified here as allowed; it is useful as a means to 501 start observing a particular resource on all members of a (multicast) 502 group at the same time. Group members that do not have this resource 503 or do not allow the GET method on it will respond with the usual 4.04 504 Not Found or 4.05 Method Not Allowed, respectively. 506 A client sending a multicast GET with Observe MAY repeat this request 507 using the same Token Option and Observe Option value, in order to 508 ensure that enough (or all) group members have been reached with the 509 request. 511 3.2.6. Block-Wise Transfer 513 Section 2.8 of [RFC7959] specifies how a server (group member), 514 responding to a multicast request with a large resource, can use 515 Block-Wise transfer to limit the size of the initial response. 517 TBD: investigate use of Block-Wise for PUT/POST/PATCH/iPATCH 518 operations e.g. to be used for distributing software blocks over 519 multicast. We can specify its use, or remark that this is undefined. 521 3.3. Transport 523 TBD: Mark [RFC8323] (TCP, TLS, WebSockets) as not applicable for this 524 form of groupcomm, as well as CoAP-over-SMS. 526 3.3.1. UDP/IPv6 Multicast Transport 528 TBD: include the "Exceptions" cases here of RFC 7390 Section 2.10. 529 State that IPv6 multicast is prerequisite. Also mention the All- 530 CoAP-nodes IPv6 addresses. 532 3.3.2. UDP/IPv4 Multicast Transport 534 TBD: includes the "Exceptions" cases here of RFC 7390 2.10. State 535 that IPv4 multicast is prerequisite. mention All-CoAP-nodes IPv4 536 addresses and the like 538 3.3.3. 6LoWPAN 540 TBD: 6lowpan-specific considerations to go here. Specifically, a 541 multicast request should preferably fit in one L2 frame to avoid the 542 strong performance drop that comes with 6LoWPAN-fragmentation and 543 reassembly. Also reference [RFC7346] for the realm-local scope. 545 3.4. Interworking with Other Protocols 547 3.4.1. MLD/MLDv2/IGMP 549 TBD: see Section 4.2 of [RFC7390] and include the content here or 550 refer to it. 552 3.4.2. RPL 554 TBD: see Section 4.3 of [RFC7390] and include the content here or 555 refer to it. 557 3.4.3. MPL 559 TBD: see Section 4.4. [RFC7390] and include the content here or 560 refer to it. 562 4. Unsecured Group Communication 564 CoAP group communication can operate in CoAP NoSec (No Security) 565 mode, without using application-layer and transport-layer security 566 mechanisms. The NoSec mode uses the "coap" scheme, and is defined in 567 Section 9 of [RFC7252]. Before using this mode of operation, the 568 security implications (Section 6.1) must be well understood. 570 5. Secured Group Communication using Group OSCORE 572 The application-layer protocol Object Security for Constrained 573 RESTful Environments (OSCORE) [I-D.ietf-core-object-security] 574 provides end-to-end encryption, integrity and replay protection of 575 CoAP messages exchanged between two CoAP endpoints. These can act 576 both as CoAP Client as well as CoAP Server, and share an OSCORE 577 Security Context used to protect and verify exchanged messages. The 578 use of OSCORE does not affect the URI scheme and OSCORE can therefore 579 be used with any URI scheme defined for CoAP. 581 OSCORE uses COSE [RFC8152] to perform encryption, signing and Message 582 Authentication Code operations, and to efficiently encode the result 583 as a COSE object. In particular, OSCORE takes as input an 584 unprotected CoAP message and transforms it into a protected CoAP 585 message, by using Authenticated Encryption Algorithms with Additional 586 Data (AEAD). 588 OSCORE makes it possible to selectively protect different parts of a 589 CoAP message in different ways, so still allowing intermediaries 590 (e.g., CoAP proxies) to perform their intended funtionalities. That 591 is, some message parts are encrypted and integrity protected; other 592 parts only integrity protected to be accessible to, but not 593 modifiable by, proxies; and some parts are kept as plain content to 594 be both accessible to and modifiable by proxies. Such differences 595 especially concern the CoAP options included in the unprotected 596 message. 598 Group OSCORE [I-D.ietf-core-oscore-groupcomm] builds on OSCORE, and 599 provides end-to-end security of CoAP messages exchanged between 600 members of an OSCORE group, while fulfilling the same security 601 requirements. 603 In particular, Group OSCORE protects CoAP requests sent over IP 604 multicast by a CoAP client, as well as multiple corresponding CoAP 605 responses sent over IP unicast by different CoAP servers. However, 606 the same keying material can also be used to protect CoAP requests 607 sent over IP unicast to a single CoAP server in the OSCORE group, as 608 well as the corresponding responses. 610 Group OSCORE uses digital signatures to ensure source authentication 611 of all messages exchanged within the OSCORE group. That is, sender 612 devices sign their outgoing messages by means of their own private 613 key, and embed the signature in the protected CoAP message. 615 A Group Manager is responsible for one or multiple OSCORE groups. In 616 particular, the Group Manager acts as repository of public keys of 617 group members; manages, renews and provides keying material in the 618 group; and drives the join process for new group members. 620 As RECOMMENDED in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 621 can join an OSCORE group by using the method described in 622 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 623 for Authentication and Authorization in constrained environments 624 [I-D.ietf-ace-oauth-authz]. 626 A CoAP endpoint can discover OSCORE groups and retrieve information 627 to join them through their Group Managers by using the method 628 described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE 629 Resource Directory [I-D.ietf-core-resource-directory]. 631 If security is required, CoAP group communication as described in 632 this specification MUST use Group OSCORE. In particular, a CoAP 633 group as defined in Section 3.1.1 and using secure group 634 communication is associated to an OSCORE group, which includes: 636 o All members of the CoAP group, i.e. the CoAP endpoints configured 637 (also) as CoAP servers and listening to the group's multicast IP 638 address. 640 o All further CoAP endpoints configured only as CoAP clients, that 641 send (multicast) CoAP requests to the CoAP group. 643 5.1. Secure Group Maintenance 645 Additional key management operations on the OSCORE group are 646 required, depending also on the security requirements of the 647 application (see Section 6.2). That is: 649 o Adding new members to a CoAP group or enabling new client-only 650 endpoints to interact with that group require also that each of 651 such members/endpoints join the corresponding OSCORE group. By 652 doing so, they are securely provided with the necessary 653 cryptographic material. In case backward security is needed, this 654 also requires to first renew such material and distribute it to 655 the current members/endpoints, before new ones are added and join 656 the OSCORE group. 658 o In case forward security is needed, removing members from a CoAP 659 group or stopping client-only endpoints from interacting with that 660 group requires removing such members/endpoints from the 661 corresponding OSCORE group. To this end, new cryptographic 662 material is generated and securely distributed only to the 663 remaining members/endpoints. This ensures that only the members/ 664 endpoints intended to remain are able to continue participating to 665 secure group communication, while the evicted ones are not able 666 to. 668 The key management operations mentioned above are entrusted to the 669 Group Manager responsible for the OSCORE group 670 [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform 671 them according to the approach described in 672 [I-D.ietf-ace-key-groupcomm-oscore]. 674 6. Security Considerations 676 This section provides security considerations for CoAP group 677 communication using IP multicast. 679 6.1. CoAP NoSec Mode 681 CoAP group communication, if not protected, is vulnerable to all the 682 attacks mentioned in Section 11 of [RFC7252] for IP multicast. 684 Thus, for sensitive and mission-critical applications (e.g., health 685 monitoring systems and alarm monitoring systems), it is NOT 686 RECOMMENDED to deploy CoAP group communication in NoSec mode. 688 Without application-layer security, CoAP group communication SHOULD 689 only be deployed in non-critical applications (e.g., read-only 690 temperature sensors where the client reading out the values does not 691 use the data to control actuators or to base an important decision 692 on). 694 Discovery of devices and resources is a typical use case where NoSec 695 mode is applied, since the devices involved do not have yet 696 configured any mutual security relations at the time the discovery 697 takes place. 699 6.2. Group OSCORE 701 Group OSCORE provides end-to-end application-level security. This 702 has many desirable properties, including maintaining security 703 properties while forwarding traffic through intermediaries (proxies). 704 Application-level security also tends to more cleanly separate 705 security from the dynamics of group membership (e.g., the problem of 706 distributing security keys across large groups with many members that 707 come and go). 709 For sensitive and mission-critical applications, CoAP group 710 communication MUST be protected by using Group OSCORE as specified in 711 [I-D.ietf-core-oscore-groupcomm]. The same security considerations 712 from Section 8 of [I-D.ietf-core-oscore-groupcomm] hold for this 713 specification. 715 A key management scheme for secure revocation and renewal of group 716 keying material should be adopted in OSCORE groups. Also, the key 717 management scheme should preserve backward and forward security in 718 the OSCORE group, if the application requires so (see Section 2.1 of 719 [I-D.ietf-core-oscore-groupcomm]). 721 CoAP endpoints using Group OSCORE countersign their outgoing 722 messages, by means of the countersignature algorithm used in the 723 OSCORE group. This ensures source authentication of messages 724 exchanged by CoAP endpoints through CoAP group communication. In 725 fact, it allows to verify that a received message has actually been 726 originated by a specific and identified member of the OSCORE group. 728 Appendix F of [I-D.ietf-core-oscore-groupcomm] discusses a number of 729 cases where a recipient CoAP endpoint may skip the verification of 730 countersignatures, possibly on a per-message basis. However, this is 731 NOT RECOMMENDED. That is, a CoAP endpoint receiving a message 732 secured with Group OSCORE SHOULD always verify the countersignature. 734 Group OSCORE addresses security attacks mentioned in Sections 735 11.2-11.6 of [RFC7252], with particular reference to their execution 736 over IP multicast. That is: it provides confidentiality and 737 integrity of request/response data through proxies also in multicast 738 settings; it prevents amplification attacks carried out through 739 responses to injected requests over IP multicast; it limits the 740 impact of attacks based on IP spoofing; it prevents cross-protocol 741 attacks; it derives the group key material from, among other things, 742 a Master Secret securely generated by the Group Manager and provided 743 to CoAP endpoints upon their joining of the OSCORE group; 744 countersignatures assure source authentication of exchanged CoAP 745 messages, and hence prevent a group member to be used for subverting 746 security in the whole group. 748 6.3. 6LoWPAN 750 Editor Note, TBD: identify if multi-fragment multicast requests have 751 a negative effect on security and, if so, advice here on trying to 752 avoid such requests. Also an attacker could use multi-fragment to 753 occupy reassembly buffers of many routing 6LoWPAN nodes. 755 6.4. Wi-Fi 757 TBD: Wi-Fi specific security considerations; see also Section 5.3.1 758 of [RFC7390]. 760 6.5. Monitoring 762 TBD: see Section 5.4 of [RFC7390]. 764 7. IANA Considerations 766 This document has no actions for IANA. 768 8. References 770 8.1. Normative References 772 [I-D.ietf-core-object-security] 773 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 774 "Object Security for Constrained RESTful Environments 775 (OSCORE)", draft-ietf-core-object-security-16 (work in 776 progress), March 2019. 778 [I-D.ietf-core-oscore-groupcomm] 779 Tiloca, M., Selander, G., Palombini, F., and J. Park, 780 "Group OSCORE - Secure Group Communication for CoAP", 781 draft-ietf-core-oscore-groupcomm-04 (work in progress), 782 March 2019. 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 790 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 791 . 793 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 794 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 795 October 2013, . 797 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 798 Application Protocol (CoAP)", RFC 7252, 799 DOI 10.17487/RFC7252, June 2014, 800 . 802 [RFC7641] Hartke, K., "Observing Resources in the Constrained 803 Application Protocol (CoAP)", RFC 7641, 804 DOI 10.17487/RFC7641, September 2015, 805 . 807 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 808 the Constrained Application Protocol (CoAP)", RFC 7959, 809 DOI 10.17487/RFC7959, August 2016, 810 . 812 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 813 RFC 8152, DOI 10.17487/RFC8152, July 2017, 814 . 816 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 817 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 818 May 2017, . 820 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 821 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 822 Application Protocol) over TCP, TLS, and WebSockets", 823 RFC 8323, DOI 10.17487/RFC8323, February 2018, 824 . 826 8.2. Informative References 828 [Californium] 829 Eclipse Foundation, "Eclipse Californium", March 2019, 830 . 834 [Go-OCF] Open Connectivity Foundation (OCF), "Implementation of 835 CoAP Server & Client in Go", March 2019, 836 . 838 [I-D.ietf-ace-key-groupcomm-oscore] 839 Tiloca, M., Park, J., and F. Palombini, "Key Management 840 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 841 oscore-01 (work in progress), March 2019. 843 [I-D.ietf-ace-oauth-authz] 844 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 845 H. Tschofenig, "Authentication and Authorization for 846 Constrained Environments (ACE) using the OAuth 2.0 847 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 848 (work in progress), March 2019. 850 [I-D.ietf-core-resource-directory] 851 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 852 Amsuess, "CoRE Resource Directory", draft-ietf-core- 853 resource-directory-19 (work in progress), January 2019. 855 [I-D.tiloca-core-oscore-discovery] 856 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 857 Groups with the CoRE Resource Directory", draft-tiloca- 858 core-oscore-discovery-01 (work in progress), January 2019. 860 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 861 DOI 10.17487/RFC7346, August 2014, 862 . 864 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 865 the Constrained Application Protocol (CoAP)", RFC 7390, 866 DOI 10.17487/RFC7390, October 2014, 867 . 869 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 870 Bose, "Constrained Application Protocol (CoAP) Option for 871 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 872 August 2016, . 874 Acknowledgments 876 The work on this document has been partly supported by VINNOVA and 877 the Celtic-Next project CRITISEC. 879 Authors' Addresses 881 Esko Dijk 882 IoTconsultancy.nl 883 ------- 884 Utrecht 885 The Netherlands 887 Email: esko.dijk@iotconsultancy.nl 889 Chonggang Wang 890 InterDigital 891 1001 E Hector St, Suite 300 892 Conshohocken PA 19428 893 United States 895 Email: Chonggang.Wang@InterDigital.com 896 Marco Tiloca 897 RISE AB 898 Isafjordsgatan 22 899 Kista SE-16440 Stockholm 900 Sweden 902 Email: marco.tiloca@ri.se