idnits 2.17.1 draft-tiloca-core-observe-multicast-notifications-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 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 13, 2020) is 1382 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) -- Looks like a reference, but probably isn't: '1' on line 1511 -- Looks like a reference, but probably isn't: '2' on line 1513 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-12) exists of draft-ietf-cose-rfc8152bis-algs-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-07 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-24 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft R. Hoeglund 4 Updates: 7252, 7641 (if approved) RISE AB 5 Intended status: Standards Track C. Amsuess 6 Expires: January 14, 2021 7 F. Palombini 8 Ericsson AB 9 July 13, 2020 11 Observe Notifications as CoAP Multicast Responses 12 draft-tiloca-core-observe-multicast-notifications-03 14 Abstract 16 The Constrained Application Protocol (CoAP) allows clients to 17 "observe" resources at a server, and receive notifications as unicast 18 responses upon changes of the resource state. In some use cases, 19 such as based on publish-subscribe, it would be convenient for the 20 server to send a single notification to all the clients observing a 21 same target resource. This document defines how a CoAP server sends 22 observe notifications as response messages over multicast, by 23 synchronizing all the observers of a same resource on a same shared 24 Token value. Besides, this document defines how Group OSCORE can be 25 used to protect multicast notifications end-to-end from the CoAP 26 server to the multiple observer clients. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 14, 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 65 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Informative Response . . . . . . . . . . . . . . . . . . 6 67 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 8 68 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 9 69 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 9 70 2.5.1. Rough Counting of Clients in the Group Observation . 10 71 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 13 72 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 3.2. Informative Response . . . . . . . . . . . . . . . . . . 14 74 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 14 75 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 15 76 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 5. Protection of Multicast Notifications with Group OSCORE . . . 17 78 5.1. Signaling the OSCORE Group in the Informative Response . 17 79 5.2. Server-Side Requirements . . . . . . . . . . . . . . . . 19 80 5.2.1. Registration . . . . . . . . . . . . . . . . . . . . 19 81 5.2.2. Informative Response . . . . . . . . . . . . . . . . 20 82 5.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 20 83 5.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 21 84 5.3. Client-Side Requirements . . . . . . . . . . . . . . . . 21 85 5.3.1. Informative Response . . . . . . . . . . . . . . . . 21 86 5.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 22 87 6. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 22 88 7. Informative Response Parameters . . . . . . . . . . . . . . . 25 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 91 9.1. Media Type Registrations . . . . . . . . . . . . . . . . 27 92 9.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 28 93 9.3. Informative Response Parameters Registry . . . . . . . . 28 94 9.4. CoAP Option Numbers Registry . . . . . . . . . . . . . . 29 95 9.5. Expert Review Instructions . . . . . . . . . . . . . . . 29 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 98 10.2. Informative References . . . . . . . . . . . . . . . . . 32 99 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 Appendix A. Pseudo-Code for Rough Counting of Clients . . . . . 33 101 A.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 33 102 A.2. Server Side . . . . . . . . . . . . . . . . . . . . . . . 34 103 Appendix B. Different Sources for Group Observation Data . . . . 35 104 B.1. PubSub . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 B.2. Sender Introspection . . . . . . . . . . . . . . . . . . 36 106 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 109 1. Introduction 111 The Constrained Application Protocol (CoAP) [RFC7252] has been 112 extended with a number of mechanisms, including resource Observation 113 [RFC7641]. This enables CoAP clients to register at a CoAP server as 114 "observers" of a resource, and hence being automatically notified 115 with an unsolicited response upon changes of the resource state. 117 CoAP supports group communication over IP multicast 118 [I-D.ietf-core-groupcomm-bis]. This includes support for Observe 119 registration requests over multicast, in order for clients to 120 efficiently register as observers of a resource hosted at multiple 121 servers. 123 However, in a number of use cases, using multicast messages for 124 responses would also be desirable. That is, it would be useful that 125 a server sends observe notifications for a same target resource to 126 multiple observers as responses over IP multicast. 128 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 129 multiple clients can subscribe to a topic, by observing the related 130 resource hosted at the responsible broker. When a new value is 131 published on that topic, it would be convenient for the broker to 132 send a single multicast notification at once, to all the subscriber 133 clients observing that topic. 135 A different use case concerns clients observing a same registration 136 resource at the CoRE Resource Directory 137 [I-D.ietf-core-resource-directory]. For example, multiple clients 138 can benefit of observation for discovering (to-be-created) OSCORE 139 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 140 Resource Directory updated links and descriptions to join them 141 through the respective Group Manager 142 [I-D.tiloca-core-oscore-discovery]. 144 More in general, multicast notifications would be beneficial whenever 145 several CoAP clients observe a same target resource at a CoAP server, 146 and can be all notified at once by means of a single response 147 message. However, CoAP does not currently define response messages 148 over IP multicast. This specification fills this gap and provides 149 the following twofold contribution. 151 First, it defines a method to deliver Observe notifications as CoAP 152 responses over IP multicast. In the proposed method, the group of 153 potential observers entrusts the server to manage the Token space for 154 multicast notifications. By doing so, the server provides all the 155 observers of a target resource with the same Token value to bind to 156 their own observation. That Token value is then used in every 157 multicast notification for the target resource. This is achieved by 158 means of an informative unicast response sent by the server to each 159 observer client. 161 Second, this specification defines how to use Group OSCORE 162 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 163 end-to-end between the server and the observer clients. This is also 164 achieved by means of the informative unicast response mentioned 165 above, which additionally includes parameter values used by the 166 server to protect every multicast notification for the target 167 resource by using Group OSCORE. This provides a secure binding 168 between each of such notifications and the observation of each of the 169 clients. 171 1.1. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 Readers are expected to be familiar with terms and concepts described 180 in CoAP [RFC7252], group communication for CoAP 181 [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC7049], 182 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 184 This specification additionally defines the following terminology. 186 o Traditional observation. A resource observation associated to a 187 single observer client, as defined in [RFC7641]. 189 o Group observation. A resource observation associated to a group 190 of clients. The server sends notifications for the group-observed 191 resource over IP multicast to all the observer clients. 193 o Phantom request. The CoAP request message that the server would 194 have received to generate a group observation on one of its 195 resources. The phantom request is generated inside the server and 196 does not hit the wire. 198 o Informative response. A CoAP response message that the server 199 sends to a given client via unicast, providing the client with 200 information on a group observation. 202 2. Server-Side Requirements 204 The server can, at any time, start a group observation on one of its 205 resources. Practically, the server may want to do that under the 206 following circumstances. 208 o In the absence of observations for the target resource, the server 209 receives a registration request from a first client wishing to 210 start a traditional observation on that resource. 212 o When a certain amount of traditional observations has been 213 established on the target resource, the server decides to make 214 those clients part of a group observation on that resource. 216 The server maintains an observer counter for each group observation 217 to a target resource, as a rough estimation of the observers actively 218 taking part in the group observation. 220 The server initializes the counter to 0 when starting the group 221 observation, and increments it after a new client starts taking part 222 in that group observation. Also, the server should keep the counter 223 up-to-date over time, for instance by using the method described in 224 Section 2.5.1. 226 2.1. Request 228 Assuming it is reachable at the address SERVER_ADDR and port number 229 SERVER_PORT, the server starts a group observation on one of its 230 resources as defined below. The server intends to send multicast 231 notifications for the target resource to the multicast IP address 232 GROUP_ADDR and port number GROUP_PORT. 234 1. The server builds a phantom observation request, i.e. a GET 235 request with an Observe option set to 0 (register). 237 2. The server selects an available value T, from the Token space of 238 a CoAP endpoint used for messages having: 240 * As source address and port number, the IP multicast address 241 GROUP_ADDR and port number GROUP_PORT. 243 * As destination address and port number, the server address 244 SERVER_ADDR and port number SERVER_PORT, intended for 245 accessing the target resource. 247 This Token space is under exclusive control of the server. 249 3. The server processes the phantom observation request above, 250 without transmitting it on the wire. The request is addressed to 251 the resource for which the server wants to start the group 252 observation, as if sent from the group of observers, i.e. with 253 GROUP_ADDR as source address and GROUP_PORT as source port. 255 4. Upon processing the self-generated phantom request, the server 256 interprets it as an observe registration received from the group 257 of potential observer clients. In particular, from then on, the 258 server MUST use T as its own local Token value associated to that 259 observation, with respect to the (next hop towards the) clients. 261 5. The server does not immediately respond to the phantom 262 observation request with a multicast notification sent on the 263 wire. The server stores the phantom observation request as is, 264 throughout the lifetime of the group observation. 266 6. The server builds a CoAP response message INIT_NOTIF as initial 267 multicast notification for the target resource, in response to 268 the phantom observation request. This message is formatted as 269 other multicast notifications (see Section 2.3) and MUST include 270 the current representation of the target resource as payload. 271 The server stores the message INIT_NOTIF and does not transmit 272 it. The server considers this message as the latest multicast 273 notification for the target resource, until it transmits a new 274 multicast notification for that resource as a CoAP message on the 275 wire. After that, the server deletes the message INIT_NOTIF. 277 2.2. Informative Response 279 After having started a group observation on a target resource, the 280 server proceeds as follows. 282 For each traditional observation ongoing on the target resource, the 283 server MAY cancel that observation. Then, the server considers the N 284 corresponding clients as now taking part in the group observation, of 285 which it increases the corresponding observer counter by N. 287 The server sends to each of such clients an informative response 288 message, encoded as a unicast response with response code 5.03 289 (Service Unavailable). As per [RFC7641], such a response does not 290 include an Observe option. The response MUST be Confirmable and MUST 291 NOT encode link-local addresses. 293 The Content-Format of the informative response is set to application/ 294 informative-response+cbor, as defined in Section 9.2. The payload of 295 the informative response is a CBOR map which MUST include all the 296 following parameters, whose CBOR labels are defined in Section 7. 298 o 'ph_req', with value the byte serialization of the CoAP message 299 received by the server as phantom observation request (see 300 Section 2.1), encoded as a CBOR byte string. Specifically, the 301 value of the byte string is the byte serialization of what 302 intended as payload for the transport layer underlying CoAP. 304 o 'last_notif', with value the byte serialization of the CoAP 305 message stored by the server as the latest multicast notification 306 for the target resource, encoded as a CBOR byte string. 307 Specifically, the value of the byte string is the byte 308 serialization of what intended as payload for the transport layer 309 underlying CoAP. 311 o 'cli_addr', with value the source IP address of the phantom 312 observation request, encoded as a CBOR byte string. This 313 parameter is tagged and identified by the CBOR tag 260 "Network 314 Address (IPv4 or IPv6 or MAC Address)". The specified value is 315 the IP multicast address GROUP_ADDR, where the server will send 316 multicast notifications for the target resource. 318 o 'cli_port', with value the source port number of the phantom 319 observation request, encoded as a CBOR unsigned integer. The 320 specified value is the port number GROUP_PORT, where the server 321 will send multicast notifications for the target resource. 323 o 'srv_addr', with value the destination IP address of the phantom 324 observation request, encoded as a CBOR byte string. This 325 parameter is tagged and identified by the CBOR tag 260 "Network 326 Address (IPv4 or IPv6 or MAC Address)". The specified value is 327 the IP address SERVER_ADDR of the server hosting the target 328 resource. 330 o 'srv_port', with value the destination port number of the phantom 331 observation request, encoded as a CBOR unsigned integer. The 332 specified value is the port number SERVER_PORT of the server 333 hosting the target resource has been listening to. 335 Upon receiving a registration request to observe the target resource, 336 the server does not create a corresponding individual observation for 337 the requesting client. Instead, the server considers that client as 338 now taking part in the group observation of the target resource, of 339 which it increments the observer counter by 1. Then, the server 340 replies to the client with the same informative response message 341 defined above, which MUST be Confirmable and MUST include also the 342 'last_notif' parameter. 344 Note that this also applies when, with no ongoing traditional 345 observations on the target resource, the server receives a 346 registration request from a first client and decides to start a group 347 observation on the target resource. 349 2.3. Notifications 351 Upon a change of the status of the target resource under group 352 observation, the server sends a multicast notification, intended to 353 all the clients taking part in the group observation of that 354 resource. In particular, each of such multicast notifications is 355 formatted as follows. 357 o It MUST be Non-confirmable. 359 o It MUST include an Observe option, as per [RFC7641]. 361 o It MUST have the same Token value T of the phantom registration 362 request that started the group observation, also specified in the 363 'ph_req' parameter of the informative response message to the 364 observer clients. That is, every multicast notification for a 365 target resource is not bound to the observation requests from the 366 different clients, but rather to the phantom registration request 367 associated to the whole set of clients taking part in the group 368 observation of that resource. 370 The server sends a multicast notification to the IP multicast address 371 GROUP_ADDR and port number GROUP_PORT indicated to the observer 372 clients, as value of the 'cli_addr' and 'cli_port' parameters of the 373 informative response message (see Section 2.2). 375 For each target resource with an active group observation, the server 376 MUST store the latest multicast notification. 378 2.4. Congestion Control 380 In order to not cause congestion, the server should conservatively 381 control the sending of multicast notifications. In particular: 383 o The multicast notifications MUST be Non-confirmable. 385 o In constrained environments such as low-power, lossy networks 386 (LLNs), the server should only support multicast notifications for 387 resources that are small. Following related guidelines from 388 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], this can consist, 389 for example, in having the payload of multicast notifications as 390 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 391 size, so that it fits into a single link-layer frame in case IPv6 392 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 393 Section 4 of [RFC4944]) is used. 395 o The server SHOULD provide multicast notifications with the 396 smallest possible IP multicast scope that fulfills the application 397 needs. For example, following related guidelines from 398 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], site-local scope 399 is always preferred over global scope IP multicast, if this 400 fulfills the application needs. Similarly, realm-local scope is 401 always preferred over site-local scope, if this fulfills the 402 application needs. 404 o Following related guidelines from Section 4.5.1 of [RFC7641], the 405 server SHOULD NOT send more than one multicast notification every 406 3 seconds, and SHOULD use an even less aggressive rate when 407 possible (see also Section 3.1.2 of [RFC8085]). The transmission 408 rate of multicast notifications should also take into account the 409 avoidance of a possible "broadcast storm" problem [MOBICOM99]. 410 This prevents a following, considerable increase of the channel 411 load, whose origin would be likely attributed to a router rather 412 than the server. 414 2.5. Cancellation 416 At any point in time, the server may want to cancel a group 417 observation of a target resource. For instance, the server may 418 realize that no clients or not enough clients are interested in 419 taking part in the group observation anymore. A possible approach 420 that the server can use to assess this is defined in Section 2.5.1. 422 In order to cancel the group observation, the server sends to itself 423 a phantom cancellation request, i.e. a GET request with an Observe 424 option set to 1 (deregister), without transmitting it on the wire. 425 As per Section 3.6 of [RFC7641], all other options MUST be identical 426 to those in the phantom registration request, except for the set of 427 ETag Options. This request has the same Token value T of the phantom 428 registration request, and is addressed to the resource for which the 429 server wants to end the group observation, as if sent from the group 430 of observers, i.e. with the multicast IP address GROUP_ADDR as source 431 address and the port number GROUP_PORT as source port. 433 After that, the server sends a multicast response with response code 434 5.03 (Service Unavailable), signaling that the group observation has 435 been terminated. The response has no payload, and is sent to the 436 same multicast IP address GROUP_ADDR and port number GROUP_PORT used 437 to send the multicast notifications related to the target resource. 438 As per [RFC7641], this response does not include an Observe option. 439 Finally, the server releases the resources allocated for the group 440 observation, and especially frees up the Token value T used at its 441 CoAP endpoint. 443 2.5.1. Rough Counting of Clients in the Group Observation 445 To allow the server to keep an estimate of interested clients without 446 creating undue traffic on the network, a new CoAP option is 447 introduced, which SHOULD be supported by clients that listen to 448 multicast responses. 450 The option is called Multicast-Response-Feedback-Divider, and is only 451 used in responses. As summarized in Figure 1, the option is not 452 critical but proxy-unsafe, and integer valued. 454 +-----+---+---+---+---+---------------------+--------+-------+---------+ 455 | No. | C | U | N | R | Name | Format | Len. | Default | 456 +-----+---+---+---+---+---------------------+--------+-------+---------+ 457 | TBD | | x | | | Multicast-Response- | uint | 0-8 B | (none) | 458 | | | | | | Feedback-Divider | | | | 459 +-----+---+---+---+---+---------------------+--------+-------+---------+ 461 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 463 Figure 1: Multicast-Response-Feedback-Divider 465 The Multicast-Response-Feedback-Divider option is of class E for 466 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 468 2.5.1.1. Client Processing 470 Upon receiving a response with a Multicast-Response-Feedback-Divider 471 option, a client SHOULD acknowledge its interest in continuing 472 receiving multicast notifications for the target resource, as 473 described below. 475 The client picks an integer random number I, from 0 inclusive to the 476 number Q given in the option exclusive. If I is different than 0, 477 the client takes no further action. Otherwise, the client should 478 wait a random fraction of the Leisure time (see Section 8.2 of 479 [RFC7252]), and then registers a regular unicast observation on the 480 same target resource. 482 To this end, the client essentially follows the steps that got it 483 originally subscribed to group notifications for the target resource. 484 In particular, the client sends an observation request to the server, 485 i.e. a GET request with an Observe option set to 0 (register). The 486 request MUST be addressed to the same target resource, and MUST have 487 the same destination IP address and port number used for the original 488 registration request, regardless the source IP address and port 489 number of the received multicast notification. 491 As the observation registration is only done for its side effect of 492 showing as an attempted observation at the server, the client MUST 493 send the unicast request in a non confirmable way, and with the 494 maximum No-Response setting [RFC7967]. In the request, the client 495 MUST include a Multicast-Response-Feedback-Divider option, whose 496 value MUST be empty (Option Length = 0). The client does not need to 497 wait for responses, and can keep processing further notifications on 498 the same token. 500 The client MUST ignore the Multicast-Response-Feedback-Divider 501 option, if the multicast notification is retrieved from the 502 'last_notif' parameter of an informative response (see Section 2.2). 503 A client includes the Multicast-Response-Feedback-Divider option only 504 in a re-registration request triggered by the server as described 505 above, and MUST NOT include it in any other request. 507 As the Multicast-Response-Feedback-Divider option is unsafe to 508 forward, a proxy needs to answer it on its own, and is later counted 509 as a single client. 511 Appendix A.1 provides a description in pseudo-code of the operations 512 above performed by the client. 514 2.5.1.2. Client Counting 516 In order to avoid needless use of network resources, a server SHOULD 517 keep a rough count of the number of clients taking part in the group 518 observation of a target resource. To this end, the server updates 519 the associated observer counter (see Section 2), for instance by 520 using the method described below. 522 When it wants to obtain a new estimated count, the server picks a 523 number M of confirmations it would like to receive from the clients. 524 It is up to applications to define policies about how the server 525 determines and adjusts the value of M. The following example will be 526 done with M = 5. 528 Then, the server considers its current estimate of listeners N, and 529 divides it by M. The resulting quotient Q = ceil(N / M) is set as 530 value in the Multicast-Response-Feedback-Divider option, which is 531 sent within a successful multicast notification. If several 532 multicast notifications are sent in a burst fashion, it is 533 RECOMMENDED for the server to include the Multicast-Response- 534 Feedback-Divider option only in the first one of those notifications. 536 The server collects unicast observation requests from the clients, 537 for an amount of time of MAX_CONFIRMATION_WAIT seconds. The server 538 MUST NOT update the observer counter N associated to the group 539 observation, until MAX_CONFIRMATION_WAIT seconds have elapsed. 541 It is up to applications to define the value of 542 MAX_CONFIRMATION_WAIT, which has to take into account the 543 transmission time of the multicast notification and of unicast 544 observation requests, as well as the leisure time of the clients, 545 which may be hard to know or estimate for the server. 547 If this information is not known to the server, it is recommended to 548 define MAX_CONFIRMATION_WAIT as follows. 550 MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY 552 where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has 553 default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is 554 equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 2.3.1 of 555 [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In 556 the absence of more specific information, the server can thus 557 consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. 559 If more information is available in deployments, a much shorter 560 MAX_CONFIRMATION_WAIT can be set, based on a realistic round trip 561 time (replacing MAX_RTT) and on the largest leisure time configured 562 on the clients (e.g. DEFAULT_LEISURE = 5 replacing 563 MAX_CLIENT_REQUEST_DELAY), thus shortening MAX_CONFIRMATION_WAIT to a 564 few seconds. 566 Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the 567 R confirmations arrived as unicast observation requests to the target 568 resource, after the multicast notification has been sent. In 569 particular, the server considers a unicast observation request as a 570 confirmation from a client only if it includes a Multicast-Response- 571 Feedback-Divider option with an empty value (Option Length = 0). 572 Then, the server multiplies R by the original Multicast-Response- 573 Feedback-Divider value Q, to get an updated client estimate. 575 If X new clients are added to the group observation while the process 576 above is occurring, the server MUST first complete the counting 577 process and update N based on the received re-registration requests. 578 Only after that, the server further increments N by X, and considers 579 the result as the current observer counter to assess for possibly 580 cancelling the group observation (see Section 2.5). 582 This estimate is skewed by packet loss, but it gives the server a 583 sufficiently good estimation for further counts and for deciding when 584 to cancel the group observation. It is up to applications to define 585 policies about how the server takes the updated value of N into 586 account and determines whether to cancel the group observation. 588 As an example, if the server currently estimates that N = 20 589 observers are active, it sends a notification out with Multicast- 590 Response-Feedback-Divider: 4. Then, out of 18 actually active 591 clients, 5 send a re-registration request based on their random draw, 592 of which one request gets lost, thus leaving four re-registration 593 requests received by the server. Also, no new clients have been 594 added to the group observation in the meanwhile. As a consequence, 595 the server updates the observer counter to N = (4 * 4) + 0 = 16, and 596 continues sending notifications to the group of observers. 598 Note that a server can send Multicast-Response-Feedback-Divider: 1 in 599 the last notifications, before cancelling a group observation. This 600 will trigger all the active clients to state their interest in 601 continuing receiving notifications for the target resource. 603 Appendix A.2 provides a description in pseudo-code of the operations 604 above performed by the server. 606 3. Client-Side Requirements 608 3.1. Request 610 A client sends an observation request to the server as described in 611 [RFC7641], i.e. a GET request with an Observe option set to 0 612 (register). The request MUST NOT encode link-local addresses. If 613 the server is not configured to accept registrations on that target 614 resource with a group observation, this would still result in a 615 positive notification response to the client as described in 616 [RFC7641]. 618 3.2. Informative Response 620 Upon receiving the informative response defined in Section 2.2, the 621 client proceeds as follows. 623 1. The client configures an observation of the target resource. To 624 this end, it relies on a CoAP endpoint used for messages having: 626 * As source address and port number, the server address 627 SERVER_ADDR and port number SERVER_PORT intended for accessing 628 the target resource. 630 * As destination address and port number, the IP multicast 631 address GROUP_ADDR and port number GROUP_PORT, specified in 632 the 'cli_addr' and 'cli_port' parameter. 634 2. The client retrieves and stores the phantom registration request 635 specified in the 'ph_req' parameter. The group observation is 636 bound to this phantom registration request. In particular, the 637 client MUST use its Token value T as its own local Token value 638 associated to that group observation, with respect to the (next 639 hop towards the) server. The particular way to achieve this is 640 implementation specific. 642 3. The client retrieves the multicast notification specified in the 643 'last_notif' parameter, and processes it as defined in 644 Section 3.2 of [RFC7641]. In particular, the value of the 645 Observe option is used as initial baseline for notification 646 reordering in this group observation. 648 4. If a traditional observation to the target resource is ongoing, 649 the client MAY silently cancel it without notifying the server. 651 If any of the expected fields are not present, the client MAY try 652 sending a new registration request to the server (see Section 3.1). 653 Otherwise, the client SHOULD explicitly withdraw from the group 654 observation. 656 Appendix B describes possible alternative ways for clients to 657 retrieve the phantom request and other information related to a group 658 observation. 660 3.3. Notifications 662 After having successfully processed the informative response as 663 defined in Section 3.2, the client will receive, accept and process 664 multicast notifications about the state of the target resource from 665 the server, as responses to the phantom registration request and with 666 Token value T. 668 The client relies on the value of the Observe option for notification 669 reordering, as defined in Section 3.4 of [RFC7641]. 671 3.4. Cancellation 673 At a certain point in time, a client may become not interested in 674 receiving further multicast notifications about a target resource. 675 When this happens, the client can simply "forget" about being part of 676 the group observation for that target resource, as per Section 3.6 of 677 [RFC7641]. 679 When, later on, the server sends the next multicast notification, the 680 client will not recognize the Token value T in the message. Since 681 the multicast notification is Non-confirmable, it is OPTIONAL for the 682 client to reject the multicast notification with a Reset message, as 683 defined in Section 3.5 of [RFC7641]. 685 In case the server has cancelled a group observation as defined in 686 Section 2.5, the client simply forgets about the group observation 687 and frees up the used Token value T for that endpoint, upon receiving 688 the multicast error response defined in Section 2.5. 690 4. Example 692 The following example refers to two clients C_1 and C_2 that register 693 to observe a resource /r at a Server S with address SERVER_ADDR and 694 listening to the port number SERVER_PORT. Before the following 695 exchanges occur, no clients are observing the resource /r , which has 696 value "1234". 698 In the informative responses, 'bstr(X)' denotes a byte string with 699 value the byte serialization of X. Also, the notation Y.CoAP denotes 700 the CoAP-layer part of a message Y, i.e. the part of Y that becomes 701 payload for the transport layer underlying CoAP. 703 The server S sends multicast notifications to the IP multicast 704 address GROUP_ADDR and port number GROUP_PORT, and starts the group 705 observation upon receiving a registration request from a first client 706 that wishes to start a traditional observation on the resource /r. 708 C_1 ------------------ [ Unicast ] --------------------> S /r 709 | GET | 710 | Token: 0x4a | 711 | Observe: 0 (Register) | 712 | | 713 | (S allocates the available Token value 0xff .) | 714 | | 715 | | 716 | | 717 | (S sends to itself a phantom observation request PH_REQ | 718 | as coming from the IP multicast address GROUP_ADDR .) | 719 | ------------------------------------------------- | 720 | / | 721 | \----------------------------------------------------> | /r 722 | GET | 723 | Token: 0xff | 724 | Observe: 0 (Register) | 725 | | 726 | (S creates a group observation of /r .) | 727 | | 728 | (S increments the observer counter | 729 | for the group observation of /r .) | 730 | | 731 C_1 <--------------------- [ Unicast ] ----------------- S 732 | 5.03 | 733 | Token: 0x4a | 734 | Payload: { ph_req : bstr(PH_REQ.CoAP), | 735 | last_notif : bstr(LAST_NOTIF.CoAP) | 736 | cl_addr : bstr(GROUP_ADDR), | 737 | cl_port : GROUP_PORT, | 738 | srv_addr : bstr(SERVER_ADDR), | 739 | srv_port : SERVER_PORT, | 740 | } | 741 | | 742 C_2 ------------------ [ Unicast ] --------------------> S /r 743 | GET | 744 | Token: 0x01 | 745 | Observe: 0 (Register) | 746 | | 747 | (S increments the observer counter | 748 | for the group observation of /r .) | 749 | | 750 C_2 <--------------------- [ Unicast ] ----------------- S 751 | 5.03 | 752 | Token: 0x01 | 753 | Payload: { ph_req : bstr(PH_REQ.CoAP), | 754 | last_notif : bstr(LAST_NOTIF.CoAP) | 755 | cl_addr : bstr(GROUP_ADDR), | 756 | cl_port : GROUP_PORT, | 757 | srv_addr : bstr(SERVER_ADDR), | 758 | srv_port : SERVER_PORT, | 759 | } | 760 | | 761 | (The value of the resource /r changes to "5678".) | 762 | | 763 C_1 | 764 + <-------------------- [ Multicast ] ---------------- S 765 C_2 (Destination address/port: GROUP_ADDR/GROUP_PORT) | 766 | 2.05 | 767 | Token: 0xff | 768 | Observe: 11 | 769 | Payload: "5678" | 770 | | 772 5. Protection of Multicast Notifications with Group OSCORE 774 A server can protect multicast notifications by using Group OSCORE 775 [I-D.ietf-core-oscore-groupcomm]. Both the server and the clients 776 interested in receiving multicast notifications from that server have 777 to be members of the same OSCORE group. 779 Clients MAY discover the OSCORE group to refer to by using the method 780 in [I-D.tiloca-core-oscore-discovery], based on the CoRE Resource 781 Directory (RD) [I-D.ietf-core-resource-directory]. Alternatively, 782 the server MAY communicate to the client what OSCORE group to join, 783 as described in Section 5.1. Furthermore, both the clients and the 784 server MAY join the OSCORE group by using the approach described in 785 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 786 for Authentication and Authorization in constrained environments 787 [I-D.ietf-ace-oauth-authz]. Further details on how to discover the 788 OSCORE group and join it are out of the scope of this specification. 790 Alternative security protocols than Group OSCORE, such as OSCORE 791 [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can be used to 792 protect other exchanges via unicast between the server and each 793 client, including the original client registration (see Section 3). 795 5.1. Signaling the OSCORE Group in the Informative Response 797 This section describes a mechanism for the server to communicate to 798 the client what OSCORE group to join in order to decrypt and verify 799 the multicast notifications protected with group OSCORE. The client 800 MAY use the information provided by the server to start the ACE 801 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 802 This mechanism is OPTIONAL to support for the client and server. 804 Additionally to what defined in Section 2, the CBOR map in the 805 informative response payload contains the following fields, whose 806 CBOR labels are defined in Section 7. 808 o 'join_uri', with value the URI for joining the OSCORE group at the 809 respective Group Manager, encoded as a CBOR text string. If the 810 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 811 for joining, this field specifically indicates the URI of the 812 group-membership resource at the Group Manager. 814 o 'sec_gp', with value the name of the OSCORE group, encoded as a 815 CBOR text string. 817 o Optionally, 'as_uri', with value the URI of the Authorization 818 Server associated to the Group Manager for the OSCORE group, 819 encoded as a CBOR text string. 821 o Optionally, 'cs_alg', with value the COSE algorithm 822 [I-D.ietf-cose-rfc8152bis-algs] used to countersign messages in 823 the OSCORE group, encoded as a CBOR text string or integer. The 824 value is taken from the 'Value' column of the "COSE Algorithms" 825 Registry [COSE.Algorithms]. 827 o Optionally, 'cs_alg_crv', with value the elliptic curve (if 828 applicable) for the COSE algorithm [I-D.ietf-cose-rfc8152bis-algs] 829 used to countersign messages in the OSCORE group, encoded as a 830 CBOR text string or integer. The value is taken from the 'Value' 831 column of the "COSE Elliptic Curve" Registry 832 [COSE.Elliptic.Curves]. 834 o Optionally, 'cs_key_kty', with value the COSE key type 835 [I-D.ietf-cose-rfc8152bis-struct] of countersignature keys used to 836 countersign messages in the OSCORE group, encoded as a CBOR text 837 string or a integer. The value is taken from the 'Value' column 838 of the "COSE Key Types" Registry [COSE.Key.Types]. 840 o Optionally, 'cs_key_crv', with value the elliptic curve (if 841 applicable) of countersignature keys used to countersign messages 842 in the OSCORE group, encoded as a CBOR text string or integer. 843 The value is taken from the 'Value' column of the "COSE Elliptic 844 Curve" Registry [COSE.Elliptic.Curves]. 846 o Optionally, 'cs_kenc', with value the encoding of the public keys 847 used in the OSCORE group, encoded as a CBOR integer. The value is 848 taken from the 'Confirmation Key' column of the "CWT Confirmation 849 Method" registry defined in [RFC8747]. Future specifications may 850 define additional values for this parameter. 852 o Optionally, 'alg', with value the COSE AEAD algorithm 853 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 854 integer. The value is taken from the 'Value' column of the "COSE 855 Algorithms" Registry [COSE.Algorithms]. 857 o Optionally, 'hkdf', with value the COSE HKDF algorithm 858 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 859 integer. The value is taken from the 'Value' column of the "COSE 860 Algorithms" Registry [COSE.Algorithms]. 862 The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' and 863 'cs_key_kenc' provide an early knowledge of the format and encoding 864 of public keys used in the OSCORE group. Thus, the client does not 865 need to ask the Group Manager for this information as a preliminary 866 step before the (ACE) join process, or to perform a trial-and-error 867 exchange with the Group Manager upon joining the group. Hence, the 868 client is able to provide the Group Manager with its own public key 869 in the correct expected format and encoding, at the very first step 870 of the (ACE) join process. 872 The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge 873 of the algorithms used in the OSCORE group. Thus, the client is able 874 to decide whether to actually proceed with the (ACE) join process, 875 depending on its support for the indicated algorithms. 877 As mentioned above, since this mechanism is OPTIONAL, all the fields 878 are OPTIONAL in the informative response. However, the 'join_uri' 879 and 'sec_gp' fields MUST be present if the mechanism is implemented 880 and used. If any of the fields are present without the 'join_uri' 881 and 'sec_gp' fields present, the client MUST ignore these fields, 882 since they would not be sufficient to start the (ACE) join procedure. 883 When this happens, the client MAY try sending a new registration 884 request to the server (see Section 3.1). Otherwise, the client 885 SHOULD explicitly withdraw from the group observation. 887 5.2. Server-Side Requirements 889 When using Group OSCORE to protect multicast notifications, the 890 server performs the operations described in Section 2, with the 891 following differences. 893 5.2.1. Registration 895 The phantom registration request MUST be secured, by using Group 896 OSCORE. In particular, the group mode of Group OSCORE defined in 897 Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. 899 The server protects the phantom registration request as defined in 900 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the 901 actual sender, i.e. by using its Sender Context. As a consequence, 902 the server consumes the current value of its Sender Sequence Number 903 SN in the OSCORE group, and hence updates it to SN* = (SN + 1). 904 Consistently, the OSCORE option in the phantom registration request 905 includes: 907 o As 'kid', the Sender ID of the server in the OSCORE group. 909 o As 'piv', the previously consumed sender sequence number value SN 910 of the server in the OSCORE group, i.e. (SN* - 1). 912 5.2.2. Informative Response 914 The phantom observation request specified in the 'ph_req' parameter 915 is protected with Group OSCORE (see Section 5.2.1). 917 The multicast notification specified in the 'last_notif' parameter is 918 also protected with Group OSCORE, just like for the multicast 919 notifications transmitted as CoAP messages on the wire (see 920 Section 5.2.3). This applies also to the initial multicast 921 notification INIT_NOTIF built in step 6 of Section 2.1. 923 Optionally, the informative response includes information on the 924 OSCORE group to join, as additional parameters (see Section 5.1). 926 5.2.3. Notifications 928 The server MUST protect every multicast notification for the target 929 resource with Group OSCORE. In particular, the group mode of Group 930 OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST 931 be used. 933 The process described in Section 8.3 of 934 [I-D.ietf-core-oscore-groupcomm] applies, with the following 935 additions when building the two OSCORE 'external_aad' to encrypt and 936 countersign the multicast notification (see Sections 4.3.1 and 4.3.2 937 of [I-D.ietf-core-oscore-groupcomm]). 939 o The 'request_kid' is the 'kid' value in the OSCORE option of the 940 phantom registration request, i.e. the Sender ID of the server. 942 o The 'request_piv' is the 'piv' value in the OSCORE option of the 943 phantom registration request, i.e. the consumed sender sequence 944 number SN of the server. 946 Note that these same values are used to protect each and every 947 multicast notification sent for the target resource. 949 5.2.4. Cancellation 951 When cancelling a group observation (see Section 2.5), the phantom 952 cancellation request MUST be secured, by using Group OSCORE. In 953 particular, the group mode of Group OSCORE defined in Section 8 of 954 [I-D.ietf-core-oscore-groupcomm] MUST be used. 956 Like defined in Section 5.2.1 for the phantom registration request, 957 the server protects the phantom cancellation request as per 958 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender 959 Context and consuming its current Sender Sequence number in the 960 OSCORE group, from its Sender Context. The following, corresponding 961 multicast error response defined in Section 2.5 is also protected 962 with Group OSCORE, as per Section 8.3 of 963 [I-D.ietf-core-oscore-groupcomm]. 965 Note that, differently from the multicast notifications, this 966 multicast error response will be the only one securely paired with 967 the phantom cancellation request. 969 5.3. Client-Side Requirements 971 When using Group OSCORE to protect multicast notifications, the 972 client performs as described in Section 3, with the following 973 differences. 975 5.3.1. Informative Response 977 Upon receiving the informative response from the server, the client 978 retrieves the phantom registration request specified in the 'ph_req' 979 parameter. 981 Then, the client decrypts and verifies the phantom registration 982 request as defined in Section 8.2 of 983 [I-D.ietf-core-oscore-groupcomm], with the following differences. 985 o The client MUST NOT perform any replay check. That is, the client 986 skips step 3 in Section 8.2 of [RFC8613]. 988 o If decryption and verification of the phantom registration request 989 succeed: 991 * The client MUST NOT update the Replay Window in the Recipient 992 Context associated to the server. That is, the client skips 993 the second bullet of step 6 in Section 8.2 of [RFC8613]. 995 * The client MUST NOT take any further process as normally 996 expected according to [RFC7252]. That is, the client skips 997 step 8 in Section 8.2 of [RFC8613]. In particular, the client 998 MUST NOT deliver the phantom registration request to the 999 application, and MUST NOT take any action in the Token space of 1000 its unicast endpoint, where the informative response has been 1001 received. 1003 * The client stores the values of the 'kid' and 'piv' fields from 1004 the OSCORE option of the phantom registration request. 1006 The client also decrypts and verifies the multicast notification 1007 specified in the 'last_notif' parameter, just like for the multicast 1008 notifications transmitted as CoAP messages on the wire (see 1009 Section 5.3.2). 1011 5.3.2. Notifications 1013 After having successfully processed the informative response as 1014 defined in Section 5.3.1, the client will decrypt and verify every 1015 multicast notification for the target resource as defined in 1016 Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following 1017 difference. 1019 The client MUST set the two 'external_aad' defined in Sections 4.3.1 1020 and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The 1021 particular way to achieve this is implementation specific. 1023 o 'request_kid' takes the value of the 'kid' field from the OSCORE 1024 option of the phantom registration request (see Section 5.3.1). 1026 o 'request_piv' takes the value of the 'piv' field from the OSCORE 1027 option of the phantom registration request (see Section 5.3.1). 1029 Note that these same values are used to decrypt and verify each and 1030 every multicast notification received for the target resource. 1032 The replay protection and checking of multicast notifications is 1033 performed as specified in Section 4.1.3.5.2 of [RFC8613]. 1035 6. Example with Group OSCORE 1037 The following example refers to two clients C_1 and C_2 that register 1038 to observe a resource /r at a Server S with address SERVER_ADDR and 1039 listening to the port number SERVER_PORT. Before the following 1040 exchanges occur, no clients are observing the resource /r , which has 1041 value "1234". 1043 In the informative responses, 'bstr(X)' denotes a byte string with 1044 value the byte serialization of X. Also, the notation Y.CoAP denotes 1045 the CoAP-layer part of a message Y, i.e. the part of Y that becomes 1046 payload for the transport layer underlying CoAP. 1048 The server S sends multicast notifications to the IP multicast 1049 address GROUP_ADDR and port number GROUP_PORT, and starts the group 1050 observation upon receiving a registration request from a first client 1051 that wishes to start a traditional observation on the resource /r. 1053 Pairwise communication over unicast are protected with OSCORE, while 1054 S protects multicast notifications with Group OSCORE. Specifically: 1056 o C_1 and S have a pairwise OSCORE Security Context. In particular, 1057 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sequence Number. 1058 Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Sequence 1059 Number. 1061 o C_2 and S have a pairwise OSCORE Security Context. In particular, 1062 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sequence Number. 1063 Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Sequence 1064 Number. 1066 o S is a member of the OSCORE group with name "myGroup", and 1067 'kid_context' = "feedca57ab2e" as Group ID. In the OSCORE group, 1068 S has 'kid' = 5 as Sender ID, and SN_5 = 501 as Sequence Number. 1070 C_1 --------------- [ Unicast w/ OSCORE ] ----------------> S /r 1071 | GET | 1072 | Token: 0x4a | 1073 | Observe: 0 (Register) | 1074 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 1075 | | 1076 | (S allocates the available Token value 0xff .) | 1077 | | 1078 | (S sends to itself a phantom observation request PH_REQ | 1079 | as coming from the IP multicast address GROUP_ADDR .) | 1080 | ------------------------------------------------------- | 1081 | / | 1082 | \--------------------------------------------------------> | /r 1083 | GET | 1084 | Token: 0xff | 1085 | Observe: 0 (Register) | 1086 | OSCORE: {kid: 5 ; piv: 501 ; ...} | 1087 | | 1088 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 1089 | | 1090 | (S creates a group observation of /r .) | 1091 | | 1092 | (S increments the observer counter | 1093 | for the group observation of /r .) | 1094 | | 1095 | | 1096 C_1 <---------------- [ Unicast w/ OSCORE ] ---------------- S 1097 | 5.03 | 1098 | Token: 0x4a | 1099 | OSCORE: {piv: 301; ...} | 1100 | Payload: { ph_req : bstr(PH_REQ.CoAP), | 1101 | last_notif : bstr(LAST_NOTIF.CoAP) | 1102 | cl_addr : bstr(GROUP_ADDR), | 1103 | cl_port : GROUP_PORT, | 1104 | srv_addr : bstr(SERVER_ADDR), | 1105 | srv_port : SERVER_PORT, | 1106 | join_uri : "coap://myGM/group-oscore/myGroup", | 1107 | sec_gp : "myGroup" | 1108 | } | 1109 | | 1110 | | 1111 C_2 --------------- [ Unicast w/ OSCORE ] ----------------> S /r 1112 | GET | 1113 | Token: 0x01 | 1114 | Observe: 0 (Register) | 1115 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 1116 | | 1117 | (S increments the observer counter | 1118 | for the group observation of /r .) | 1119 | | 1120 C_2 <------------------ [ Unicast w/ OSCORE ] -------------- S 1121 | 5.03 | 1122 | Token: 0x01 | 1123 | OSCORE: {piv: 401; ...} | 1124 | Payload: { ph_req : bstr(PH_REQ.CoAP), | 1125 | last_notif : bstr(LAST_NOTIF.CoAP) | 1126 | cl_addr : bstr(GROUP_ADDR), | 1127 | cl_port : GROUP_PORT, | 1128 | srv_addr : bstr(SERVER_ADDR), | 1129 | srv_port : SERVER_PORT, | 1130 | join_uri : "coap://myGM/group-oscore/myGroup", | 1131 | sec_gp : "myGroup" | 1132 | } | 1133 | | 1134 | | 1135 | (The value of the resource /r changes to "5678".) | 1136 | | 1137 C_1 | 1138 + <-------------- [ Multicast w/ Group OSCORE ] ---------- S 1140 C_2 (Destination address/port: GROUP_ADDR/GROUP_PORT) | 1141 | 2.05 | 1142 | Token: 0xff | 1143 | Observe: 11 | 1144 | OSCORE: {kid: 5; piv: 502 ; ...} | 1145 | Payload: "5678" | 1146 | | 1148 The two external_aad used to encrypt and countersign the multicast 1149 notification above have 'req_kid' = 5 and 'req_iv' = 501. These are 1150 indicated in the 'kid' and 'iv' field of the OSCORE option of the 1151 phantom observation request, which is included in the 'ph_req' 1152 parameter of the unicast informative response to the two clients. 1153 Thus, the two clients can build the two same external_aad for 1154 decrypting and verifying this multicast notification and the 1155 following ones. 1157 7. Informative Response Parameters 1159 This specification defines a number of fields used in error messages 1160 as informative response defined in Section 2.2 of this specification. 1162 The table below summarizes them, and specifies the CBOR key to use 1163 instead of the full descriptive name. Note that the media type 1164 application/informative-response+cbor MUST be used when these fields 1165 are transported. 1167 +------------+----------+-------------------+-------------+ 1168 | Name | CBOR Key | CBOR Type | Reference | 1169 +------------+----------+-------------------+-------------+ 1170 | ph_req | TBD | byte string | Section 2.2 | 1171 | | | | | 1172 | last_notif | TBD | byte string | Section 2.2 | 1173 | | | | | 1174 | cli_addr | TBD | byte string | Section 2.2 | 1175 | | | | | 1176 | cli_port | TBD | unsigned int | Section 2.2 | 1177 | | | | | 1178 | srv_addr | TBD | byte string | Section 2.2 | 1179 | | | | | 1180 | srv_port | TBD | unsigned int | Section 2.2 | 1181 | | | | | 1182 | join_uri | TBD | text string | Section 5.1 | 1183 | | | | | 1184 | sec_gp | TBD | text string | Section 5.1 | 1185 | | | | | 1186 | as_uri | TBD | text string | Section 5.1 | 1187 | | | | | 1188 | cs_alg | TBD | int / text string | Section 5.1 | 1189 | | | | | 1190 | cs_crv | TBD | int / text string | Section 5.1 | 1191 | | | | | 1192 | cs_kty | TBD | int / text string | Section 5.1 | 1193 | | | | | 1194 | cs_kenc | TBD | int | Section 5.1 | 1195 | | | | | 1196 | alg | TBD | int / text string | Section 5.1 | 1197 | | | | | 1198 | hkdf | TBD | int / text string | Section 5.1 | 1199 +------------+----------+-------------------+-------------+ 1201 8. Security Considerations 1203 The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor 1204 e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for 1205 this document. 1207 If multicast notifications are protected using Group OSCORE, the 1208 original registration requests and related unicast (notification) 1209 responses MUST also be secured, including and especially the 1210 informative responses from the server. This prevents on-path active 1211 adversaries from altering the conveyed IP multicast address and 1212 serialized phantom request. Thus, it ensures secure binding between 1213 every multicast notification for a same observed resource and the 1214 phantom request that started the group observation of that resource. 1216 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 1217 so ensuring that the secure binding above is enforced end-to-end 1218 between the server and each observing client. 1220 9. IANA Considerations 1222 This document has the following actions for IANA. 1224 9.1. Media Type Registrations 1226 This specification registers the media type 'application/informative- 1227 response+cbor' for error messages as informative response defined in 1228 Section 2.2 of this specification, when carrying parameters encoded 1229 in CBOR. This registration follows the procedures specified in 1230 [RFC6838]. 1232 o Type name: application 1234 o Subtype name: informative-response+cbor 1236 o Required parameters: none 1238 o Optional parameters: none 1240 o Encoding considerations: Must be encoded as a CBOR map containing 1241 the parameters defined in Section 2.2 of [this document]. 1243 o Security considerations: See Section 8 of [this document]. 1245 o Interoperability considerations: n/a 1247 o Published specification: [this document] 1249 o Applications that use this media type: The type is used by CoAP 1250 servers and clients that support error messages as informative 1251 response defined in Section 2.2 of [this document]. 1253 o Additional information: 1255 * Magic number(s): n/a 1257 * File extension(s): .informative-response 1259 * Macintosh file type code(s): n/a 1261 o Person & email address to contact for further information: 1262 iesg@ietf.org [1] 1264 o Intended usage: COMMON 1266 o Restrictions on usage: None 1268 o Author: Marco Tiloca marco.tiloca@ri.se [2] 1270 o Change controller: IESG 1272 o Provisional registration? (standards tree only): No 1274 9.2. CoAP Content-Formats Registry 1276 IANA is asked to add the following entry to the "CoAP Content- 1277 Formats" subregistry defined in Section 12.3 of [RFC7252], within the 1278 "Constrained RESTful Environments (CoRE) Parameters" registry. 1280 Media Type: application/informative-response+cbor 1282 Encoding: - 1284 ID: TBD 1286 Reference: [this document] 1288 9.3. Informative Response Parameters Registry 1290 This specification establishes the "Informative Response Parameters" 1291 IANA Registry. The Registry has been created to use the "Expert 1292 Review Required" registration procedure [RFC8126]. Expert review 1293 guidelines are provided in Section 9.5. 1295 The columns of this Registry are: 1297 o Name: This is a descriptive name that enables easier reference to 1298 the item. The name MUST be unique. It is not used in the 1299 encoding. 1301 o CBOR Key: This is the value used as CBOR key of the item. These 1302 values MUST be unique. The value can be a positive integer, a 1303 negative integer, or a string. 1305 o CBOR Type: This contains the CBOR type of the item, or a pointer 1306 to the registry that defines its type, when that depends on 1307 another item. 1309 o Reference: This contains a pointer to the public specification for 1310 the item. 1312 This Registry has been initially populated by the values in 1313 Section 7. The "Reference" column for all of these entries refers to 1314 sections of this document. 1316 9.4. CoAP Option Numbers Registry 1318 IANA is asked to enter the following option numbers to the "CoAP 1319 Option Numbers" registry defined in [RFC7252] within the "CoRE 1320 Parameters" registry. 1322 +--------+--------------------------------------+-------------------+ 1323 | Number | Name | Reference | 1324 +--------+--------------------------------------+-------------------+ 1325 | TBD | Multicast-Response-Feedback-Divider | [[this document]] | 1326 +--------+--------------------------------------+-------------------+ 1328 9.5. Expert Review Instructions 1330 The IANA Registries established in this document are defined as 1331 expert review. This section gives some general guidelines for what 1332 the experts should be looking for, but they are being designated as 1333 experts for a reason so they should be given substantial latitude. 1335 Expert reviewers should take into consideration the following points: 1337 o Point squatting should be discouraged. Reviewers are encouraged 1338 to get sufficient information for registration requests to ensure 1339 that the usage is not going to duplicate one that is already 1340 registered and that the point is likely to be used in deployments. 1341 The zones tagged as private use are intended for testing purposes 1342 and closed environments, code points in other ranges should not be 1343 assigned for testing. 1345 o Specifications are required for the standards track range of point 1346 assignment. Specifications should exist for specification 1347 required ranges, but early assignment before a specification is 1348 available is considered to be permissible. Specifications are 1349 needed for the first-come, first-serve range if they are expected 1350 to be used outside of closed environments in an interoperable way. 1351 When specifications are not provided, the description provided 1352 needs to have sufficient information to identify what the point is 1353 being used for. 1355 o Experts should take into account the expected usage of fields when 1356 approving point assignment. The fact that there is a range for 1357 standards track documents does not mean that a standards track 1358 document cannot have points assigned outside of that range. The 1359 length of the encoded value should be weighed against how many 1360 code points of that length are left, the size of device it will be 1361 used on, and the number of code points left that encode to that 1362 size. 1364 10. References 1366 10.1. Normative References 1368 [COSE.Algorithms] 1369 IANA, "COSE Algorithms", 1370 . 1373 [COSE.Elliptic.Curves] 1374 IANA, "COSE Elliptic Curves", 1375 . 1378 [COSE.Key.Types] 1379 IANA, "COSE Key Types", 1380 . 1383 [I-D.ietf-core-groupcomm-bis] 1384 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1385 for the Constrained Application Protocol (CoAP)", draft- 1386 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 1388 [I-D.ietf-core-oscore-groupcomm] 1389 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1390 "Group OSCORE - Secure Group Communication for CoAP", 1391 draft-ietf-core-oscore-groupcomm-09 (work in progress), 1392 June 2020. 1394 [I-D.ietf-cose-rfc8152bis-algs] 1395 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1396 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-11 1397 (work in progress), July 2020. 1399 [I-D.ietf-cose-rfc8152bis-struct] 1400 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1401 Structures and Process", draft-ietf-cose-rfc8152bis- 1402 struct-11 (work in progress), July 2020. 1404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1405 Requirement Levels", BCP 14, RFC 2119, 1406 DOI 10.17487/RFC2119, March 1997, 1407 . 1409 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1410 "Transmission of IPv6 Packets over IEEE 802.15.4 1411 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1412 . 1414 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1415 Specifications and Registration Procedures", BCP 13, 1416 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1417 . 1419 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1420 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1421 October 2013, . 1423 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1424 Application Protocol (CoAP)", RFC 7252, 1425 DOI 10.17487/RFC7252, June 2014, 1426 . 1428 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1429 Application Protocol (CoAP)", RFC 7641, 1430 DOI 10.17487/RFC7641, September 2015, 1431 . 1433 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1434 Bose, "Constrained Application Protocol (CoAP) Option for 1435 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1436 August 2016, . 1438 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1439 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1440 March 2017, . 1442 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1443 Writing an IANA Considerations Section in RFCs", BCP 26, 1444 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1445 . 1447 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1448 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1449 May 2017, . 1451 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1452 "Object Security for Constrained RESTful Environments 1453 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1454 . 1456 10.2. Informative References 1458 [I-D.ietf-ace-key-groupcomm-oscore] 1459 Tiloca, M., Park, J., and F. Palombini, "Key Management 1460 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1461 oscore-07 (work in progress), June 2020. 1463 [I-D.ietf-ace-oauth-authz] 1464 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1465 H. Tschofenig, "Authentication and Authorization for 1466 Constrained Environments (ACE) using the OAuth 2.0 1467 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1468 (work in progress), June 2020. 1470 [I-D.ietf-core-coap-pubsub] 1471 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1472 Subscribe Broker for the Constrained Application Protocol 1473 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1474 progress), September 2019. 1476 [I-D.ietf-core-resource-directory] 1477 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1478 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1479 resource-directory-24 (work in progress), March 2020. 1481 [I-D.ietf-tls-dtls13] 1482 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1483 Datagram Transport Layer Security (DTLS) Protocol Version 1484 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1485 2020. 1487 [I-D.tiloca-core-oscore-discovery] 1488 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1489 Groups with the CoRE Resource Directory", draft-tiloca- 1490 core-oscore-discovery-05 (work in progress), March 2020. 1492 [MOBICOM99] 1493 Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast 1494 Storm Problem in a Mobile Ad Hoc Network", Proceedings of 1495 the 5th annual ACM/IEEE international conference on Mobile 1496 computing and networking , August 1999, 1497 . 1500 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1501 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1502 January 2012, . 1504 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1505 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1506 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1507 2020, . 1509 10.3. URIs 1511 [1] mailto:iesg@ietf.org 1513 [2] mailto:marco.tiloca@ri.se 1515 Appendix A. Pseudo-Code for Rough Counting of Clients 1517 This appendix provides a description in pseudo-code of the two 1518 algorithms used for the rough counting of active observers, as 1519 defined in Section 2.5.1. 1521 A.1. Client Side 1522 input: int Q, // Value of the MRFD option 1523 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 1524 // unless overridden 1526 output: None 1528 int RAND_MIN = 0; 1529 int RAND_MAX = Q - 1; 1530 int I = randomInteger(RAND_MIN, RAND_MAX); 1532 if (I == 0) { 1533 float fraction = randomFloat(0, 1); 1535 Timer t = new Timer(); 1536 t.setAndStart(fraction * LEISURE_TIME); 1537 while(!t.isExpired()); 1539 Request req = new Request(); 1540 // Initialize as NON and with maximum 1541 // No-Response settings, set options ... 1543 Option opt = new Option(OBSERVE); 1544 opt.set(0); 1545 req.setOption(opt); 1547 opt = new Option(MRFD); 1548 req.setOption(opt); 1550 req.send(SERVER_ADDR, SERVER_PORT); 1551 } 1553 A.2. Server Side 1554 input: int N, // Current observer counter 1555 int M, // Desired number of confirmations 1556 int MAX_CONFIRMATION_WAIT, 1557 Response notification, // Multicast notification to send 1559 output: int N // Updated observer counter 1561 int Q = ceil(N / M); 1562 Option opt = new Option(MRFD); 1563 opt.set(Q); 1565 notification.setOption(opt); 1566 1567 notification.send(GROUP_ADDR, GROUP_PORT); 1569 Timer t = new Timer(); 1570 t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 1571 while(!t.isExpired()); 1573 // Time t2 1575 int R = ; 1577 int X = ; 1580 int N = (R * Q) + X; 1581 return N; 1583 Appendix B. Different Sources for Group Observation Data 1585 While the clients usually receive the phantom request and other 1586 information related to the group observation through an Informative 1587 Response, the same data can be made available through different 1588 services, such as the following ones. 1590 B.1. PubSub 1592 In a pubsub case ([I-D.ietf-core-coap-pubsub]), a group observation 1593 can be discovered, along with topic metadata. For instance, a 1594 discovery step can make the following metadata available. 1596 This examples assumes a CoRAL namespace that contains properties 1597 analogous to those in the content-format application/informative- 1598 response+cbor. 1600 Request: 1602 GET 1603 Accept: CoRAL 1605 Response: 1607 2.05 Content 1608 Content-Format: CoRAL 1610 rdf:type 1611 topic { 1612 ph_req h"120100006464b431323334" 1613 last_notif h"120100006464b431324321" 1614 cli_addr h"ff35003020010db8..1234" 1615 cli_port 5683 1616 srv_addr h"20010db80100..0001" 1617 srv_port 5683 1618 } 1620 With this information from the topic discovery step, the client can 1621 already set up its multicast address and start receiving multicast 1622 notifications. 1624 In heavily asymmetric networks like municipal notification services, 1625 discovery and notifications do not necessarily need to use the same 1626 network link. For example, a departure monitor could use its (costly 1627 and usually-off) cellular uplink to discover the topics it needs to 1628 update its display to, and then listen on a LoRA-WAN interface for 1629 receiving the actual multicast notifications. 1631 B.2. Sender Introspection 1633 For network debugging purposes, it can be useful to query a server 1634 that sends multicast responses as matching a phantom request. 1636 Such an interface is left for other documents to specify on demand, 1637 but could look like this as relying on the already known token value 1638 of multicast notifications associated to a phantom request: 1640 Request: 1642 GET 1644 Response: 1646 2.05 Content 1647 Content-Format: application/informative-response+cbor 1649 { 1650 'ph_req': h"120100006464b431323334" 1651 'last_notif' : h"120100006464b431324321" 1652 'cli_addr': h"ff35003020010db8..1234" 1653 'cli_port': 5683 1654 'srv_addr': h"20010db80100..0001" 1655 'srv_port': 5683 1656 } 1658 For example, a network sniffer could offer sending such a request 1659 when unknown multicast notifications are seen on a network. 1660 Consequently, it can associate those notifications with a URI, or 1661 decrypt them, if member of the correct OSCORE group. 1663 Acknowledgments 1665 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 1666 Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander 1667 for their comments and feedback. 1669 The work on this document has been partly supported by VINNOVA and 1670 the Celtic-Next project CRITISEC. 1672 Authors' Addresses 1674 Marco Tiloca 1675 RISE AB 1676 Isafjordsgatan 22 1677 Kista SE-16440 Stockholm 1678 Sweden 1680 Email: marco.tiloca@ri.se 1681 Rikard Hoeglund 1682 RISE AB 1683 Isafjordsgatan 22 1684 Kista SE-16440 Stockholm 1685 Sweden 1687 Email: rikard.hoglund@ri.se 1689 Christian Amsuess 1690 Hollandstr. 12/4 1691 Vienna 1020 1692 Austria 1694 Email: christian@amsuess.com 1696 Francesca Palombini 1697 Ericsson AB 1698 Torshamnsgatan 23 1699 Kista SE-16440 Stockholm 1700 Sweden 1702 Email: francesca.palombini@ericsson.com