idnits 2.17.1 draft-tiloca-core-observe-multicast-notifications-04.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 (November 02, 2020) is 1270 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 2152 -- Looks like a reference, but probably isn't: '2' on line 2154 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-10 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-00 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-09 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-25 == 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-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 8 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: May 6, 2021 7 F. Palombini 8 Ericsson AB 9 November 02, 2020 11 Observe Notifications as CoAP Multicast Responses 12 draft-tiloca-core-observe-multicast-notifications-04 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 May 6, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 65 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 67 2.2.1. Encoding of Transport-Independent Message Information 8 68 2.2.2. Encoding of Transport-Specific Message Information . 9 69 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 70 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 11 71 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 12 72 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 13 73 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 3.2. Informative Response . . . . . . . . . . . . . . . . . . 13 75 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 14 76 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 14 77 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5. Rough Counting of Clients in the Group Observation . . . . . 17 79 5.1. Processing on the Client Side . . . . . . . . . . . . . . 17 80 5.2. Processing on the Server Side . . . . . . . . . . . . . . 18 81 5.2.1. Request for Feedback . . . . . . . . . . . . . . . . 19 82 5.2.2. Collection of Feedback . . . . . . . . . . . . . . . 19 83 5.2.3. Processing of Feedback . . . . . . . . . . . . . . . 20 84 6. Protection of Multicast Notifications with Group OSCORE . . . 21 85 6.1. Signaling the OSCORE Group in the Informative Response . 22 86 6.2. Server-Side Requirements . . . . . . . . . . . . . . . . 24 87 6.2.1. Registration . . . . . . . . . . . . . . . . . . . . 24 88 6.2.2. Informative Response . . . . . . . . . . . . . . . . 24 89 6.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 25 90 6.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 25 91 6.3. Client-Side Requirements . . . . . . . . . . . . . . . . 26 92 6.3.1. Informative Response . . . . . . . . . . . . . . . . 26 93 6.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 27 94 7. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 27 95 8. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 31 96 9. Intermediaries Together with End-to-End Security . . . . . . 33 97 9.1. The Listen-To-Multicast-Responses Option . . . . . . . . 34 98 9.2. Message Processing . . . . . . . . . . . . . . . . . . . 35 99 10. Informative Response Parameters . . . . . . . . . . . . . . . 36 100 11. Transport Protocol Identifiers . . . . . . . . . . . . . . . 37 101 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 102 12.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 38 103 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 104 13.1. Media Type Registrations . . . . . . . . . . . . . . . . 39 105 13.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 40 106 13.3. Informative Response Parameters Registry . . . . . . . . 40 107 13.4. Transport Protocol Identifiers Registry . . . . . . . . 41 108 13.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 42 109 13.6. Expert Review Instructions . . . . . . . . . . . . . . . 42 110 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 111 14.1. Normative References . . . . . . . . . . . . . . . . . . 43 112 14.2. Informative References . . . . . . . . . . . . . . . . . 45 113 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 46 114 Appendix A. Different Sources for Group Observation Data . . . . 46 115 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 46 116 A.2. Introspection at the Multicast Notification Sender . . . 47 117 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 48 118 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 48 119 B.2. Client Side - Optimized Version . . . . . . . . . . . . . 49 120 B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 50 121 Appendix C. Example with a Proxy . . . . . . . . . . . . . . . . 52 122 Appendix D. Example with a Proxy and Group OSCORE . . . . . . . 55 123 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 61 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 126 1. Introduction 128 The Constrained Application Protocol (CoAP) [RFC7252] has been 129 extended with a number of mechanisms, including resource Observation 130 [RFC7641]. This enables CoAP clients to register at a CoAP server as 131 "observers" of a resource, and hence being automatically notified 132 with an unsolicited response upon changes of the resource state. 134 CoAP supports group communication over IP multicast 135 [I-D.ietf-core-groupcomm-bis]. This includes support for Observe 136 registration requests over multicast, in order for clients to 137 efficiently register as observers of a resource hosted at multiple 138 servers. 140 However, in a number of use cases, using multicast messages for 141 responses would also be desirable. That is, it would be useful that 142 a server sends observe notifications for a same target resource to 143 multiple observers as responses over IP multicast. 145 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 146 multiple clients can subscribe to a topic, by observing the related 147 resource hosted at the responsible broker. When a new value is 148 published on that topic, it would be convenient for the broker to 149 send a single multicast notification at once, to all the subscriber 150 clients observing that topic. 152 A different use case concerns clients observing a same registration 153 resource at the CoRE Resource Directory 154 [I-D.ietf-core-resource-directory]. For example, multiple clients 155 can benefit of observation for discovering (to-be-created) OSCORE 156 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 157 Resource Directory updated links and descriptions to join them 158 through the respective Group Manager 159 [I-D.tiloca-core-oscore-discovery]. 161 More in general, multicast notifications would be beneficial whenever 162 several CoAP clients observe a same target resource at a CoAP server, 163 and can be all notified at once by means of a single response 164 message. However, CoAP does not currently define response messages 165 over IP multicast. This specification fills this gap and provides 166 the following twofold contribution. 168 First, it defines a method to deliver Observe notifications as CoAP 169 responses over IP multicast. In the proposed method, the group of 170 potential observers entrusts the server to manage the Token space for 171 multicast notifications. By doing so, the server provides all the 172 observers of a target resource with the same Token value to bind to 173 their own observation. That Token value is then used in every 174 multicast notification for the target resource. This is achieved by 175 means of an informative unicast response sent by the server to each 176 observer client. 178 Second, this specification defines how to use Group OSCORE 179 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 180 end-to-end between the server and the observer clients. This is also 181 achieved by means of the informative unicast response mentioned 182 above, which additionally includes parameter values used by the 183 server to protect every multicast notification for the target 184 resource by using Group OSCORE. This provides a secure binding 185 between each of such notifications and the observation of each of the 186 clients. 188 1.1. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in BCP 193 14 [RFC2119] [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 Readers are expected to be familiar with terms and concepts described 197 in CoAP [RFC7252], group communication for CoAP 198 [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR 199 [I-D.ietf-cbor-7049bis], OSCORE [RFC8613], and Group OSCORE 200 [I-D.ietf-core-oscore-groupcomm]. 202 This specification additionally defines the following terminology. 204 o Traditional observation. A resource observation associated to a 205 single observer client, as defined in [RFC7641]. 207 o Group observation. A resource observation associated to a group 208 of clients. The server sends notifications for the group-observed 209 resource over IP multicast to all the observer clients. 211 o Phantom request. The CoAP request message that the server would 212 have received to start or cancel a group observation on one of its 213 resources. A phantom request is generated inside the server and 214 does not hit the wire. 216 o Informative response. A CoAP response message that the server 217 sends to a given client via unicast, providing the client with 218 information on a group observation. 220 2. Server-Side Requirements 222 The server can, at any time, start a group observation on one of its 223 resources. Practically, the server may want to do that under the 224 following circumstances. 226 o In the absence of observations for the target resource, the server 227 receives a registration request from a first client wishing to 228 start a traditional observation on that resource. 230 o When a certain amount of traditional observations has been 231 established on the target resource, the server decides to make 232 those clients part of a group observation on that resource. 234 The server maintains an observer counter for each group observation 235 to a target resource, as a rough estimation of the observers actively 236 taking part in the group observation. 238 The server initializes the counter to 0 when starting the group 239 observation, and increments it after a new client starts taking part 240 in that group observation. Also, the server should keep the counter 241 up-to-date over time, for instance by using the method described in 242 Section 5. 244 2.1. Request 246 Assuming it is reachable at the address SRV_ADDR and port number 247 SRV_PORT, the server starts a group observation on one of its 248 resources as defined below. The server intends to send multicast 249 notifications for the target resource to the multicast IP address 250 GRP_ADDR and port number GRP_PORT. 252 1. The server builds a phantom observation request, i.e. a GET 253 request with an Observe option set to 0 (register). 255 2. The server selects an available value T, from the Token space of 256 a CoAP endpoint used for messages having: 258 * As source address and port number, the IP multicast address 259 GRP_ADDR and port number GRP_PORT. 261 * As destination address and port number, the server address 262 SRV_ADDR and port number SRV_PORT, intended for accessing the 263 target resource. 265 This Token space is under exclusive control of the server. 267 3. The server processes the phantom observation request above, 268 without transmitting it on the wire. The request is addressed to 269 the resource for which the server wants to start the group 270 observation, as if sent by the group of observers, i.e. with 271 GRP_ADDR as source address and GRP_PORT as source port. 273 4. Upon processing the self-generated phantom registration request, 274 the server interprets it as an observe registration received from 275 the group of potential observer clients. In particular, from 276 then on, the server MUST use T as its own local Token value 277 associated to that observation, with respect to the (previous hop 278 towards the) clients. 280 5. The server does not immediately respond to the phantom 281 observation request with a multicast notification sent on the 282 wire. The server stores the phantom observation request as is, 283 throughout the lifetime of the group observation. 285 6. The server builds a CoAP response message INIT_NOTIF as initial 286 multicast notification for the target resource, in response to 287 the phantom observation request. This message is formatted as 288 other multicast notifications (see Section 2.3) and MUST include 289 the current representation of the target resource as payload. 290 The server stores the message INIT_NOTIF and does not transmit 291 it. The server considers this message as the latest multicast 292 notification for the target resource, until it transmits a new 293 multicast notification for that resource as a CoAP message on the 294 wire. After that, the server deletes the message INIT_NOTIF. 296 2.2. Informative Response 298 After having started a group observation on a target resource, the 299 server proceeds as follows. 301 For each traditional observation ongoing on the target resource, the 302 server MAY cancel that observation. Then, the server considers the 303 corresponding clients as now taking part in the group observation, 304 for which it increases the corresponding observer counter 305 accordingly. 307 The server sends to each of such clients an informative response 308 message, encoded as a unicast response with response code 5.03 309 (Service Unavailable). As per [RFC7641], such a response does not 310 include an Observe option. The response MUST be Confirmable and MUST 311 NOT encode link-local addresses. 313 The Content-Format of the informative response is set to application/ 314 informative-response+cbor, as defined in Section 13.2. The payload 315 of the informative response is a CBOR map which MUST include all the 316 following parameters, whose CBOR labels are defined in Section 10. 318 o 'ph_req', with value the byte serialization of the transport- 319 independent information of the phantom observation request (see 320 Section 2.1), encoded as a CBOR byte string. The value of the 321 CBOR byte string is formatted as defined in Section 2.2.1. 323 o 'last_notif', with value the byte serialization of the transport- 324 independent information of the latest multicast notification for 325 the target resource, encoded as a CBOR byte string. The value of 326 the CBOR byte string is formatted as defined in Section 2.2.1. 328 o 'tp_info', with value a CBOR array. This includes the transport- 329 specific information required to correctly receive multicast 330 notifications bound to the phantom observation request. The CBOR 331 array is formatted as defined in Section 2.2.2. 333 The CDDL notation [RFC8610] provided below describes the payload of 334 the informative response. 336 informative_response_payload = { 337 1 => bstr, ; phantom request (transport-independent information) 338 2 => bstr, ; latest notification (transport-independent information) 339 3 => array ; transport-specific information 340 } 342 Upon receiving a registration request to observe the target resource, 343 the server does not create a corresponding individual observation for 344 the requesting client. Instead, the server considers that client as 345 now taking part in the group observation of the target resource, of 346 which it increments the observer counter by 1. Then, the server 347 replies to the client with the same informative response message 348 defined above, which MUST be Confirmable. 350 Note that this also applies when, with no ongoing traditional 351 observations on the target resource, the server receives a 352 registration request from a first client and decides to start a group 353 observation on the target resource. 355 2.2.1. Encoding of Transport-Independent Message Information 357 For both the parameters 'ph_req' and 'last_notif' in the informative 358 response, the value of the byte string is the concatenation of the 359 following components, in the order specified below. 361 When defining the value of each component, "CoAP message" refers to 362 the phantom observation request for the 'ph_req' parameter, and to 363 the corresponding latest multicast notification for the 'last_notif' 364 parameter. 366 o A single byte, with value the content of the Code field in the 367 CoAP message. 369 o The byte serialization of the complete sequence of CoAP options in 370 the CoAP message. 372 o If the CoAP message includes a non-zero length payload, the one- 373 byte Payload Marker (0xff) followed by the payload. 375 2.2.2. Encoding of Transport-Specific Message Information 377 The CBOR array specified in the 'tp_info' parameter includes at least 378 one element and is formatted as follows. 380 o 'tp_id' : this element is a CBOR integer, which specifies the 381 transport protocol used to transport the CoAP multicast 382 notifications from the server. This element takes value from the 383 "Transport Protocol Identifiers" sub-registry defined in 384 Section 13.4 of this specification. This element MUST be present. 385 The value of this element determines how many elements are 386 required to follow in the CBOR array, as well as what information 387 they convey, their encoding and their semantics. 389 This specification registers the integer value 1 ("UDP") to be 390 used as value for the 'tp_id' element, when CoAP multicast 391 notifications are transported over UDP as per [RFC7252] and 392 [I-D.ietf-core-groupcomm-bis]. In such a case, the full encoding 393 of the 'tp_info' CBOR array is as defined in Section 2.2.2.1. 395 Future specifications that consider CoAP multicast notifications 396 transported over different transport protocols MUST: 398 * Register an integer value to be used as value for the 'tp_id' 399 array element, in the "Transport Protocol Identifiers" sub- 400 registry defined in Section 13.4 of this specification. 402 * Accordingly, define the elements of the 'tp_info' CBOR array 403 following the 'tp_id' element, as to what information they 404 convey, their encoding and their semantics. 406 2.2.2.1. UDP Transport-Specific Information 408 When CoAP multicast notifications are transported over UDP as per 409 [RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the 410 integer value 1 ("UDP") as value of the 'tp_id' element of the 411 'tp_info' CBOR array in the error informative response. 413 Then, following the 'tp_id' element, the rest of the 'tp_info' CBOR 414 array is defined as follows. 416 o 'token': this element is a CBOR byte string, with value the Token 417 value of the phantom observation request generated by the server 418 (see Section 2.1). Note that the same Token value is used for the 419 multicast notifications bound to that phantom observation request 420 (see Section 2.3). This element MUST be present. 422 o 'srv_addr': this element is a CBOR byte string, with value the 423 destination IP address of the phantom observation request. This 424 parameter is tagged and identified by the CBOR tag 260 "Network 425 Address (IPv4 or IPv6 or MAC Address)". That is, the value of the 426 CBOR byte string is the IP address SRV_ADDR of the server hosting 427 the target resource, from where the server will send multicast 428 notifications for the target resource. This element MUST be 429 present. 431 o 'srv_port': this element is a CBOR unsigned integer, with value 432 the destination port number of the phantom observation request. 433 That is, the specified value is the port number SRV_PORT, from 434 where the server will send multicast notifications for the target 435 resource. This element MUST be present. 437 o 'cli_addr': this element is a CBOR byte string, with value the 438 source IP address of the phantom observation request. This 439 parameter is tagged and identified by the CBOR tag 260 "Network 440 Address (IPv4 or IPv6 or MAC Address)". That is, the value of the 441 CBOR byte string is the IP multicast address GRP_ADDR, where the 442 server will send multicast notifications for the target resource. 443 This element MUST be present. 445 o 'cli_port': this element is a CBOR unsigned integer, with value 446 the source port number of the phantom observation request. That 447 is, the specified value is the port number GRP_PORT, where the 448 server will send multicast notifications for the target resource. 449 This element is OPTIONAL. If not included, the default port 450 number 5683 is assumed. 452 The CDDL notation [RFC8610] provided below describes the full 453 'tp_info' CBOR array using the format above. 455 tp_info = [ 456 tp_id : 1, ; UDP as transport protocol 457 token : bstr, ; Token of phantom request and multicast notifications 458 srv_addr : #6.260(bstr), ; Src. address of multicast notifications 459 srv_port : uint, ; Src. port of multicast notifications 460 cli_addr : #6.260(bstr), ; Dst. address of multicast notifications 461 ? cli_port : uint ; Dst. port of multicast notifications 462 ] 464 2.3. Notifications 466 Upon a change in the status of the target resource under group 467 observation, the server sends a multicast notification, intended to 468 all the clients taking part in the group observation of that 469 resource. In particular, each of such multicast notifications is 470 formatted as follows. 472 o It MUST be Non-confirmable. 474 o It MUST include an Observe option, as per [RFC7641]. 476 o It MUST have the same Token value T of the phantom registration 477 request that started the group observation. This Token value is 478 specified in the 'token' element of the 'tp_info' parameter, in 479 the informative response message sent to all the observer clients. 481 That is, every multicast notification for a target resource is not 482 bound to the observation requests from the different clients, but 483 rather to the phantom registration request associated to the whole 484 set of clients taking part in the group observation of that 485 resource. 487 o It MUST be sent from the same IP address SRV_ADDR and port number 488 SRV_PORT where: i) the original Observe registration requests are 489 sent to by the clients; and ii) the corresponding informative 490 responses are sent from by the server (see Section 2.2). These 491 are indicated to the observer clients as value of the 'srv_addr' 492 and 'srv_port' elements of the 'tp_info' parameter, in the 493 informative response message (see Section 2.2.2.1). That is, 494 redirection MUST NOT be used. 496 o It MUST be sent to the IP multicast address GRP_ADDR and port 497 number GRP_PORT. These are indicated to the observer clients as 498 value of the 'cli_addr' and 'cli_port' elements of the 'tp_info' 499 parameter, in the informative response message (see 500 Section 2.2.2.1). 502 For each target resource with an active group observation, the server 503 MUST store the latest multicast notification. 505 2.4. Congestion Control 507 In order to not cause congestion, the server should conservatively 508 control the sending of multicast notifications. In particular: 510 o The multicast notifications MUST be Non-confirmable. 512 o In constrained environments such as low-power, lossy networks 513 (LLNs), the server should only support multicast notifications for 514 resources that are small. Following related guidelines from 515 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], this can consist, 516 for example, in having the payload of multicast notifications as 517 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 518 size, so that it fits into a single link-layer frame in case IPv6 519 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 520 Section 4 of [RFC4944]) is used. 522 o The server SHOULD provide multicast notifications with the 523 smallest possible IP multicast scope that fulfills the application 524 needs. For example, following related guidelines from 525 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], site-local scope 526 is always preferred over global scope IP multicast, if this 527 fulfills the application needs. Similarly, realm-local scope is 528 always preferred over site-local scope, if this fulfills the 529 application needs. 531 o Following related guidelines from Section 4.5.1 of [RFC7641], the 532 server SHOULD NOT send more than one multicast notification every 533 3 seconds, and SHOULD use an even less aggressive rate when 534 possible (see also Section 3.1.2 of [RFC8085]). The transmission 535 rate of multicast notifications should also take into account the 536 avoidance of a possible "broadcast storm" problem [MOBICOM99]. 537 This prevents a following, considerable increase of the channel 538 load, whose origin would be likely attributed to a router rather 539 than the server. 541 2.5. Cancellation 543 At any point in time, the server may want to cancel a group 544 observation of a target resource. For instance, the server may 545 realize that no clients or not enough clients are interested in 546 taking part in the group observation anymore. A possible approach 547 that the server can use to assess this is defined in Section 5. 549 In order to cancel the group observation, the server sends to itself 550 a phantom cancellation request, i.e. a GET request with an Observe 551 option set to 1 (deregister), without transmitting it on the wire. 552 As per Section 3.6 of [RFC7641], all other options MUST be identical 553 to those in the phantom registration request, except for the set of 554 ETag Options. This request has the same Token value T of the phantom 555 registration request, and is addressed to the resource for which the 556 server wants to end the group observation, as if sent by the group of 557 observers, i.e. with the multicast IP address GRP_ADDR as source 558 address and the port number GRP_PORT as source port. 560 After that, the server sends a multicast response with response code 561 5.03 (Service Unavailable), signaling that the group observation has 562 been terminated. The response has no payload, and is sent to the 563 same multicast IP address GRP_ADDR and port number GRP_PORT used to 564 send the multicast notifications related to the target resource. As 565 per [RFC7641], this response does not include an Observe option. 566 Finally, the server releases the resources allocated for the group 567 observation, and especially frees up the Token value T used at its 568 CoAP endpoint. 570 3. Client-Side Requirements 572 3.1. Request 574 A client sends an observation request to the server as described in 575 [RFC7641], i.e. a GET request with an Observe option set to 0 576 (register). The request MUST NOT encode link-local addresses. If 577 the server is not configured to accept registrations on that target 578 resource with a group observation, this would still result in a 579 positive notification response to the client as described in 580 [RFC7641]. 582 3.2. Informative Response 584 Upon receiving the informative response defined in Section 2.2, the 585 client proceeds as follows. 587 1. The client configures an observation of the target resource. To 588 this end, it relies on a CoAP endpoint used for messages having: 590 * As source address and port number, the server address SRV_ADDR 591 and port number SRV_PORT intended for accessing the target 592 resource. These are specified as value of the 'srv_addr' and 593 'srv_port' elements of the 'tp_info' parameter, in the 594 informative response (see Section 2.2.2.1). 596 * As destination address and port number, the IP multicast 597 address GRP_ADDR and port number GRP_PORT. These are 598 specified as value of the 'cli_addr' and 'cli_port' elements 599 of the 'tp_info' parameter, in the informative response (see 600 Section 2.2.2.1). If the 'cli_port' element is omitted in the 601 'tp_info' parameter, the client MUST assume the default port 602 number 5683 as GRP_PORT. 604 2. The client rebuilds the phantom registration request, by using: 606 * The transport-independent information, specified in the 607 'ph_req' parameter of the informative response. 609 * The Token value T, specified in the 'token' element of the 610 'tp_info' parameter of the informative response. 612 3. The client stores the phantom registration request, as associated 613 to the observation of the target resource. In particular, the 614 client MUST use the Token value T of this phantom registration 615 request as its own local Token value associated to that group 616 observation, with respect to the server. The particular way to 617 achieve this is implementation specific. 619 4. The client rebuilds the latest multicast notification, by using: 621 * The transport-independent information, specified in the 622 'last_notif' parameter of the informative response. 624 * The Token value T, specified in the 'token' element of the 625 'tp_info' parameter of the informative response. 627 5. Then, the client processes the latest multicast notification as 628 defined in Section 3.2 of [RFC7641]. In particular, the value of 629 the Observe option is used as initial baseline for notification 630 reordering in this group observation. 632 6. If a traditional observation to the target resource is ongoing, 633 the client MAY silently cancel it without notifying the server. 635 If any of the expected fields in the informative response are not 636 present or malformed, the client MAY try sending a new registration 637 request to the server (see Section 3.1). Otherwise, the client 638 SHOULD explicitly withdraw from the group observation. 640 Appendix A describes possible alternative ways for clients to 641 retrieve the phantom registration request and other information 642 related to a group observation. 644 3.3. Notifications 646 After having successfully processed the informative response as 647 defined in Section 3.2, the client will receive, accept and process 648 multicast notifications about the state of the target resource from 649 the server, as responses to the phantom registration request and with 650 Token value T. 652 The client relies on the value of the Observe option for notification 653 reordering, as defined in Section 3.4 of [RFC7641]. 655 3.4. Cancellation 657 At a certain point in time, a client may become not interested in 658 receiving further multicast notifications about a target resource. 659 When this happens, the client can simply "forget" about being part of 660 the group observation for that target resource, as per Section 3.6 of 661 [RFC7641]. 663 When, later on, the server sends the next multicast notification, the 664 client will not recognize the Token value T in the message. Since 665 the multicast notification is Non-confirmable, it is OPTIONAL for the 666 client to reject the multicast notification with a Reset message, as 667 defined in Section 3.5 of [RFC7641]. 669 In case the server has cancelled a group observation as defined in 670 Section 2.5, the client simply forgets about the group observation 671 and frees up the used Token value T for that endpoint, upon receiving 672 the multicast error response defined in Section 2.5. 674 4. Example 676 The following example refers to two clients C_1 and C_2 that register 677 to observe a resource /r at a Server S, which has address SRV_ADDR 678 and listens to the port number SRV_PORT. Before the following 679 exchanges occur, no clients are observing the resource /r , which has 680 value "1234". 682 The server S sends multicast notifications to the IP multicast 683 address GRP_ADDR and port number GRP_PORT, and starts the group 684 observation upon receiving a registration request from a first client 685 that wishes to start a traditional observation on the resource /r. 687 The following notation is used for the payload of the informative 688 responses: 690 o 'bstr(X)' denotes a CBOR byte string with value the byte 691 serialization of X, with '|' denoting byte concatenation. 693 o 'OPT' denotes a sequence of CoAP options. This refers to the 694 phantom registration request encoded by the 'ph_req' parameter, or 695 to the corresponding latest multicast notification encoded by the 696 'last_notif' parameter. 698 o 'PAYLOAD' denotes a CoAP payload. This refers to the latest 699 multicast notification encoded by the 'last_notif' parameter. 701 C_1 ----------------- [ Unicast ] ------------------------> S /r 702 | GET | 703 | Token: 0x4a | 704 | Observe: 0 (Register) | 705 | | 706 | | 707 | (S allocates the available Token value 0x7b .) | 708 | | 709 | | 710 | | 711 | (S sends to itself a phantom observation request PH_REQ | 712 | as coming from the IP multicast address GRP_ADDR .) | 713 | ------------------------------------------------ | 714 | / | 715 | \----------------------------------------------------> | /r 716 | GET | 717 | Token: 0x7b | 718 | Observe: 0 (Register) | 719 | | 720 | | 721 | (S creates a group observation of /r .) | 722 | | 723 | (S increments the observer counter | 724 | for the group observation of /r .) | 725 | | 726 C_1 <-------------------- [ Unicast ] --------------------- S 727 | 5.03 | 728 | Token: 0x4a | 729 | Content-Format: application/informative-response+cbor | 730 | | 731 | Payload: { | 732 | ph_req : bstr(0x01 | OPT), | 733 | last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD), | 734 | tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, | 735 | bstr(GRP_ADDR), GRP_PORT] | 736 | } | 737 | | 738 C_2 ----------------- [ Unicast ] ------------------------> S /r 739 | GET | 740 | Token: 0x01 | 741 | Observe: 0 (Register) | 742 | | 743 | | 744 | (S increments the observer counter | 745 | for the group observation of /r .) | 746 | | 747 C_2 <-------------------- [ Unicast ] --------------------- S 748 | 5.03 | 749 | Token: 0x01 | 750 | Content-Format: application/informative-response+cbor | 751 | | 752 | Payload: { | 753 | ph_req : bstr(0x01 | OPT), | 754 | last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD), | 755 | tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, | 756 | bstr(GRP_ADDR), GRP_PORT] | 757 | } | 758 | | 759 | (The value of the resource /r changes to "5678".) | 760 | | 761 C_1 | 762 + <------------------- [ Multicast ] -------------------- S 763 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 764 | 2.05 | 765 | Token: 0x7b | 766 | Observe: 11 | 767 | Content-Format: application/cbor | 768 | | 769 | Payload: : "5678" | 770 | | 772 5. Rough Counting of Clients in the Group Observation 774 To allow the server to keep an estimate of interested clients without 775 creating undue traffic on the network, a new CoAP option is 776 introduced, which SHOULD be supported by clients that listen to 777 multicast responses. 779 The option is called Multicast-Response-Feedback-Divider. As 780 summarized in Figure 1, the option is not critical but proxy-unsafe, 781 and integer valued. 783 +-----+---+---+---+---+---------------------+--------+------+---------+ 784 | No. | C | U | N | R | Name | Format | Len. | Default | 785 +-----+---+---+---+---+---------------------+--------+------+---------+ 786 | TBD | | x | | | Multicast-Response- | uint | 0-1 | (none) | 787 | | | | | | Feedback-Divider | | | | 788 +-----+---+---+---+---+---------------------+--------+------+---------+ 790 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 792 Figure 1: Multicast-Response-Feedback-Divider 794 The Multicast-Response-Feedback-Divider option is of class E for 795 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 797 5.1. Processing on the Client Side 799 Upon receiving a response with a Multicast-Response-Feedback-Divider 800 option, a client SHOULD acknowledge its interest in continuing 801 receiving multicast notifications for the target resource, as 802 described below. 804 The client picks an integer random number I, from 0 inclusive to the 805 number Z = (2 ** Q) exclusive, where Q is the value specified in the 806 option and "**" is the exponentiation operator. If I is different 807 than 0, the client takes no further action. Otherwise, the client 808 should wait a random fraction of the Leisure time (see Section 8.2 of 809 [RFC7252]), and then registers a regular unicast observation on the 810 same target resource. 812 To this end, the client essentially follows the steps that got it 813 originally subscribed to group notifications for the target resource. 814 In particular, the client sends an observation request to the server, 815 i.e. a GET request with an Observe option set to 0 (register). The 816 request MUST be addressed to the same target resource, and MUST have 817 the same destination IP address and port number used for the original 818 registration request, regardless the source IP address and port 819 number of the received multicast notification. 821 Since the observation registration is only done for its side effect 822 of showing as an attempted observation at the server, the client MUST 823 send the unicast request in a non confirmable way, and with the 824 maximum No-Response setting [RFC7967]. In the request, the client 825 MUST include a Multicast-Response-Feedback-Divider option, whose 826 value MUST be empty (Option Length = 0). The client does not need to 827 wait for responses, and can keep processing further notifications on 828 the same token. 830 The client MUST ignore the Multicast-Response-Feedback-Divider 831 option, if the multicast notification is retrieved from the 832 'last_notif' parameter of an informative response (see Section 2.2). 833 A client includes the Multicast-Response-Feedback-Divider option only 834 in a re-registration request triggered by the server as described 835 above, and MUST NOT include it in any other request. 837 As the Multicast-Response-Feedback-Divider option is unsafe to 838 forward, a proxy needs to answer it on its own, and is later counted 839 as a single client. 841 Appendix B.1 provides a description in pseudo-code of the operations 842 above performed by the client. 844 5.2. Processing on the Server Side 846 In order to avoid needless use of network resources, a server SHOULD 847 keep a rough, updated count of the number of clients taking part in 848 the group observation of a target resource. To this end, the server 849 updates the value COUNT of the associated observer counter (see 850 Section 2), for instance by using the method described below. 852 5.2.1. Request for Feedback 854 When it wants to obtain a new estimated count, the server considers a 855 number M of confirmations it would like to receive from the clients. 856 It is up to applications to define policies about how the server 857 determines and possibly adjusts the value of M. 859 Then, the server computes the value Q = max(L, 0), where: 861 o L is computed as L = ceil(log2(N / M)). 863 o N is the current value of the observer counter, possibly rounded 864 up to 1, i.e. N = max(COUNT, 1). 866 Finally, the server sets Q as the value of the Multicast-Response- 867 Feedback-Divider option, which is sent within a successful multicast 868 notification. 870 If several multicast notifications are sent in a burst fashion, it is 871 RECOMMENDED for the server to include the Multicast-Response- 872 Feedback-Divider option only in the first one of those notifications. 874 5.2.2. Collection of Feedback 876 The server collects unicast observation requests from the clients, 877 for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this 878 time, the server regularly increments the observer counter when 879 adding a new client to the group observation (see Section 2.2). 881 It is up to applications to define the value of 882 MAX_CONFIRMATION_WAIT, which has to take into account the 883 transmission time of the multicast notification and of unicast 884 observation requests, as well as the leisure time of the clients, 885 which may be hard to know or estimate for the server. 887 If this information is not known to the server, it is recommended to 888 define MAX_CONFIRMATION_WAIT as follows. 890 MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY 892 where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has 893 default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is 894 equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 2.3.1 of 895 [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In 896 the absence of more specific information, the server can thus 897 consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. 899 If more information is available in deployments, a much shorter 900 MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic 901 round trip time (replacing MAX_RTT) and on the largest leisure time 902 configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g. 903 DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to 904 a few seconds. 906 5.2.3. Processing of Feedback 908 Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the 909 R confirmations arrived as unicast observation requests to the target 910 resource, since the multicast notification with the Multicast- 911 Response-Feedback-Divider option has been sent. In particular, the 912 server considers a unicast observation request as a confirmation from 913 a client only if it includes a Multicast-Response-Feedback-Divider 914 option with an empty value (Option Length = 0). 916 Then, the server computes a feedback indicator as F = R * (2 ** Q), 917 where "**" is the exponentiation operator. According to what defined 918 by application policies, the server determines the next time when to 919 ask clients for their confirmation, e.g. after a certain number of 920 multicast notifications has been sent. For example, the decision can 921 be influenced by the reception of no confirmations from the clients, 922 i.e. R = 0, or by the value of the ratios (F/N) and (N/F). 924 Finally, the server computes a new estimated count of the observers. 925 To this end the server first consider COUNT' as the current value of 926 the observer counter at this point in time. Note that COUNT' may be 927 greater than the value COUNT used at the beginning of this process, 928 if the server has incremented the observer counter upon adding new 929 clients to the group observation (see Section 2.2). 931 In particular, the server computes the new estimated count value as 932 COUNT' + ((E - N) / D), where D > 0 is an integer value used as 933 dampener. This step has to be performed atomically. That is, until 934 this step is completed, the server MUST hold the processing of an 935 observation request for the same target resource from a new client. 936 Finally, the server considers the result as the current observer 937 counter, and assesses it for possibly cancelling the group 938 observation (see Section 2.5). 940 This estimate is skewed by packet loss, but it gives the server a 941 sufficiently good estimation for further counts and for deciding when 942 to cancel the group observation. It is up to applications to define 943 policies about how the server takes the newly updated estimate into 944 account and determines whether to cancel the group observation. 946 As an example, if the server currently estimates that N = COUNT = 32 947 observers are active and considers a constant M = 8, it sends out a 948 notification with Multicast-Response-Feedback-Divider: 2. Then, out 949 of 18 actually active clients, 5 send a re-registration request based 950 on their random draw, of which one request gets lost, thus leaving 4 951 re-registration requests received by the server. Also, no new 952 clients have been added to the group observation during this time, 953 i.e. COUNT' is equal to COUNT. As a consequence, assuming that a 954 dampener value D = 1 is used, the server computes the new estimated 955 count value as 32 + (16 - 32) = 16, and keeps the group observation 956 active. 958 To produce a most accurate updated counter, a server can include a 959 Multicast-Response-Feedback-Divider option with value Q = 0 in its 960 multicast notifications, as if M is equal to N. This will trigger 961 all the active clients to state their interest in continuing 962 receiving notifications for the target resource. Thus, the amount R 963 of arrived confirmations is affected only by possible packet loss. 965 Appendix B.3 provides a description in pseudo-code of the operations 966 above performed by the server, including example behaviors for 967 scheduling the next count update and deciding whether to cancel the 968 group observation. 970 6. Protection of Multicast Notifications with Group OSCORE 972 A server can protect multicast notifications by using Group OSCORE 973 [I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected 974 end-to-end with the observer clients. This requires that both the 975 server and the clients interested in receiving multicast 976 notifications from that server are members of the same OSCORE group. 978 In some settings, the OSCORE group to refer to can be pre-configured 979 on the clients and the server. In such a case, a server which is 980 aware of such pre-configuration can simply assume a client to be 981 already member of the correct OSCORE group. 983 In any other case, the server MAY communicate to clients what OSCORE 984 group they are required to join, by providing additional guidance in 985 the informative response as described in Section 6.1. Note that 986 clients can already be members of the right OSCORE group, in case 987 they have previously joined it to securely communicate with the same 988 and/or other servers to access their resources. 990 Both the clients and the server MAY join the OSCORE group by using 991 the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and 992 based on the ACE framework for Authentication and Authorization in 993 constrained environments [I-D.ietf-ace-oauth-authz]. Further details 994 on how to discover the OSCORE group and join it are out of the scope 995 of this specification. 997 If multicast notifications are protected using Group OSCORE, the 998 original registration requests and related unicast (notification) 999 responses MUST also be secured, including and especially the 1000 informative responses from the server. 1002 To this end, alternative security protocols than Group OSCORE, such 1003 as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can 1004 be used to protect other exchanges via unicast between the server and 1005 each client, including the original client registration (see 1006 Section 3). 1008 6.1. Signaling the OSCORE Group in the Informative Response 1010 This section describes a mechanism for the server to communicate to 1011 the client what OSCORE group to join in order to decrypt and verify 1012 the multicast notifications protected with group OSCORE. The client 1013 MAY use the information provided by the server to start the ACE 1014 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 1015 This mechanism is OPTIONAL to support for the client and server. 1017 Additionally to what defined in Section 2, the CBOR map in the 1018 informative response payload contains the following fields, whose 1019 CBOR labels are defined in Section 10. 1021 o 'join_uri', with value the URI for joining the OSCORE group at the 1022 respective Group Manager, encoded as a CBOR text string. If the 1023 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 1024 for joining, this field specifically indicates the URI of the 1025 group-membership resource at the Group Manager. 1027 o 'sec_gp', with value the name of the OSCORE group, encoded as a 1028 CBOR text string. 1030 o Optionally, 'as_uri', with value the URI of the Authorization 1031 Server associated to the Group Manager for the OSCORE group, 1032 encoded as a CBOR text string. 1034 o Optionally, 'cs_alg', with value the COSE algorithm 1035 [I-D.ietf-cose-rfc8152bis-algs] used to countersign messages in 1036 the OSCORE group, encoded as a CBOR text string or integer. The 1037 value is taken from the 'Value' column of the "COSE Algorithms" 1038 registry [COSE.Algorithms]. 1040 o Optionally, 'cs_alg_crv', with value the elliptic curve (if 1041 applicable) for the COSE algorithm [I-D.ietf-cose-rfc8152bis-algs] 1042 used to countersign messages in the OSCORE group, encoded as a 1043 CBOR text string or integer. The value is taken from the 'Value' 1044 column of the "COSE Elliptic Curve" registry 1045 [COSE.Elliptic.Curves]. 1047 o Optionally, 'cs_key_kty', with value the COSE key type 1048 [I-D.ietf-cose-rfc8152bis-struct] of countersignature keys used to 1049 countersign messages in the OSCORE group, encoded as a CBOR text 1050 string or an integer. The value is taken from the 'Value' column 1051 of the "COSE Key Types" registry [COSE.Key.Types]. 1053 o Optionally, 'cs_key_crv', with value the elliptic curve (if 1054 applicable) of countersignature keys used to countersign messages 1055 in the OSCORE group, encoded as a CBOR text string or integer. 1056 The value is taken from the 'Value' column of the "COSE Elliptic 1057 Curve" registry [COSE.Elliptic.Curves]. 1059 o Optionally, 'cs_kenc', with value the encoding of the public keys 1060 used in the OSCORE group, encoded as a CBOR integer. The value is 1061 taken from the 'Confirmation Key' column of the "CWT Confirmation 1062 Method" registry defined in [RFC8747]. Future specifications may 1063 define additional values for this parameter. 1065 o Optionally, 'alg', with value the COSE AEAD algorithm 1066 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 1067 integer. The value is taken from the 'Value' column of the "COSE 1068 Algorithms" registry [COSE.Algorithms]. 1070 o Optionally, 'hkdf', with value the COSE HKDF algorithm 1071 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 1072 integer. The value is taken from the 'Value' column of the "COSE 1073 Algorithms" registry [COSE.Algorithms]. 1075 The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' and 1076 'cs_key_kenc' provide an early knowledge of the format and encoding 1077 of public keys used in the OSCORE group. Thus, the client does not 1078 need to ask the Group Manager for this information as a preliminary 1079 step before the (ACE) join process, or to perform a trial-and-error 1080 exchange with the Group Manager upon joining the group. Hence, the 1081 client is able to provide the Group Manager with its own public key 1082 in the correct expected format and encoding, at the very first step 1083 of the (ACE) join process. 1085 The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge 1086 of the algorithms used in the OSCORE group. Thus, the client is able 1087 to decide whether to actually proceed with the (ACE) join process, 1088 depending on its support for the indicated algorithms. 1090 As mentioned above, since this mechanism is OPTIONAL, all the fields 1091 are OPTIONAL in the informative response. However, the 'join_uri' 1092 and 'sec_gp' fields MUST be present if the mechanism is implemented 1093 and used. If any of the fields are present without the 'join_uri' 1094 and 'sec_gp' fields present, the client MUST ignore these fields, 1095 since they would not be sufficient to start the (ACE) join procedure. 1096 When this happens, the client MAY try sending a new registration 1097 request to the server (see Section 3.1). Otherwise, the client 1098 SHOULD explicitly withdraw from the group observation. 1100 6.2. Server-Side Requirements 1102 When using Group OSCORE to protect multicast notifications, the 1103 server performs the operations described in Section 2, with the 1104 following differences. 1106 6.2.1. Registration 1108 The phantom registration request MUST be secured, by using Group 1109 OSCORE. In particular, the group mode of Group OSCORE defined in 1110 Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. 1112 The server protects the phantom registration request as defined in 1113 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the 1114 actual sender, i.e. by using its Sender Context. As a consequence, 1115 the server consumes the current value of its Sender Sequence Number 1116 SN in the OSCORE group, and hence updates it to SN* = (SN + 1). 1117 Consistently, the OSCORE option in the phantom registration request 1118 includes: 1120 o As 'kid', the Sender ID of the server in the OSCORE group. 1122 o As 'piv', the previously consumed Sender Sequence Number value SN 1123 of the server in the OSCORE group, i.e. (SN* - 1). 1125 6.2.2. Informative Response 1127 The value of the CBOR byte string in the 'ph_req' parameter encodes 1128 the phantom observation request as a message protected with Group 1129 OSCORE (see Section 6.2.1). As a consequence: the specified Code is 1130 always 0.05 (FETCH); the sequence of CoAP options will be limited to 1131 the outer, non encrypted options; a payload is always present, as the 1132 authenticated ciphertext followed by the counter signature. 1134 Similarly, the value of the CBOR byte string in the 'last_notif' 1135 parameter encodes the latest multicast notification as a message 1136 protected with Group OSCORE (see Section 6.2.3). This applies also 1137 to the initial multicast notification INIT_NOTIF built in step 6 of 1138 Section 2.1. 1140 Optionally, the informative response includes information on the 1141 OSCORE group to join, as additional parameters (see Section 6.1). 1143 6.2.3. Notifications 1145 The server MUST protect every multicast notification for the target 1146 resource with Group OSCORE. In particular, the group mode of Group 1147 OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST 1148 be used. 1150 The process described in Section 8.3 of 1151 [I-D.ietf-core-oscore-groupcomm] applies, with the following 1152 additions when building the two OSCORE 'external_aad' to encrypt and 1153 countersign the multicast notification (see Sections 4.3.1 and 4.3.2 1154 of [I-D.ietf-core-oscore-groupcomm]). 1156 o The 'request_kid' is the 'kid' value in the OSCORE option of the 1157 phantom registration request, i.e. the Sender ID of the server. 1159 o The 'request_piv' is the 'piv' value in the OSCORE option of the 1160 phantom registration request, i.e. the consumed Sender Sequence 1161 Number SN of the server. 1163 o The 'request_kid_context' is the 'kid context' value in the OSCORE 1164 option of the phantom registration request, i.e. the Group 1165 Identifier value (Gid) of the OSCORE group used as ID Context. 1167 Note that these same values are used to protect each and every 1168 multicast notification sent for the target resource under this group 1169 observation. 1171 6.2.4. Cancellation 1173 When cancelling a group observation (see Section 2.5), the phantom 1174 cancellation request MUST be secured, by using Group OSCORE. In 1175 particular, the group mode of Group OSCORE defined in Section 8 of 1176 [I-D.ietf-core-oscore-groupcomm] MUST be used. 1178 Like defined in Section 6.2.1 for the phantom registration request, 1179 the server protects the phantom cancellation request as per 1180 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender 1181 Context and consuming its current Sender Sequence number in the 1182 OSCORE group, from its Sender Context. The following, corresponding 1183 multicast error response defined in Section 2.5 is also protected 1184 with Group OSCORE, as per Section 8.3 of 1185 [I-D.ietf-core-oscore-groupcomm]. 1187 Note that, differently from the multicast notifications, this 1188 multicast error response will be the only one securely paired with 1189 the phantom cancellation request. 1191 6.3. Client-Side Requirements 1193 When using Group OSCORE to protect multicast notifications, the 1194 client performs as described in Section 3, with the following 1195 differences. 1197 6.3.1. Informative Response 1199 Upon receiving the informative response from the server, the client 1200 performs as described in Section 3.2, with the following additions. 1202 Once completed step 2, the client decrypts and verifies the rebuilt 1203 phantom registration request as defined in Section 8.2 of 1204 [I-D.ietf-core-oscore-groupcomm], with the following differences. 1206 o The client MUST NOT perform any replay check. That is, the client 1207 skips step 3 in Section 8.2 of [RFC8613]. 1209 o If decryption and verification of the phantom registration request 1210 succeed: 1212 * The client MUST NOT update the Replay Window in the Recipient 1213 Context associated to the server. That is, the client skips 1214 the second bullet of step 6 in Section 8.2 of [RFC8613]. 1216 * The client MUST NOT take any further process as normally 1217 expected according to [RFC7252]. That is, the client skips 1218 step 8 in Section 8.2 of [RFC8613]. In particular, the client 1219 MUST NOT deliver the phantom registration request to the 1220 application, and MUST NOT take any action in the Token space of 1221 its unicast endpoint, where the informative response has been 1222 received. 1224 * The client stores the values of the 'kid', 'piv' and 'kid 1225 context' fields from the OSCORE option of the phantom 1226 registration request. 1228 o If decryption and verification of the phantom registration request 1229 fail, the client MAY try sending a new registration request to the 1230 server (see Section 3.1). Otherwise, the client SHOULD explicitly 1231 withdraw from the group observation. 1233 Once completed step 4, the client also decrypts and verifies the 1234 rebuilt latest multicast notification, just like it would for the 1235 multicast notifications transmitted as CoAP messages on the wire (see 1236 Section 6.3.2). The client proceeds with step 5 if decryption and 1237 verification of the latest multicast notification succeed, or to step 1238 6 otherwise. 1240 6.3.2. Notifications 1242 After having successfully processed the informative response as 1243 defined in Section 6.3.1, the client will decrypt and verify every 1244 multicast notification for the target resource as defined in 1245 Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following 1246 difference. 1248 The client MUST set the two 'external_aad' defined in Sections 4.3.1 1249 and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The 1250 particular way to achieve this is implementation specific. 1252 o 'request_kid' takes the value of the 'kid' field from the OSCORE 1253 option of the phantom registration request (see Section 6.3.1). 1255 o 'request_piv' takes the value of the 'piv' field from the OSCORE 1256 option of the phantom registration request (see Section 6.3.1). 1258 o 'request_kid_context' takes the value of the 'kid context' field 1259 from the OSCORE option of the phantom registration request (see 1260 Section 6.3.1). 1262 Note that these same values are used to decrypt and verify each and 1263 every multicast notification received for the target resource. 1265 The replay protection and checking of multicast notifications is 1266 performed as specified in Section 4.1.3.5.2 of [RFC8613]. 1268 7. Example with Group OSCORE 1270 The following example refers to two clients C_1 and C_2 that register 1271 to observe a resource /r at a Server S, which has address SRV_ADDR 1272 and listens to the port number SRV_PORT. Before the following 1273 exchanges occur, no clients are observing the resource /r , which has 1274 value "1234". 1276 The server S sends multicast notifications to the IP multicast 1277 address GRP_ADDR and port number GRP_PORT, and starts the group 1278 observation upon receiving a registration request from a first client 1279 that wishes to start a traditional observation on the resource /r. 1281 Pairwise communication over unicast are protected with OSCORE, while 1282 S protects multicast notifications with Group OSCORE. Specifically: 1284 o C_1 and S have a pairwise OSCORE Security Context. In particular, 1285 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sender Sequence 1286 Number. Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as 1287 Sender Sequence Number. 1289 o C_2 and S have a pairwise OSCORE Security Context. In particular, 1290 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sender Sequence 1291 Number. Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as 1292 Sender Sequence Number. 1294 o S is a member of the OSCORE group with name "myGroup", and 'kid 1295 context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' 1296 = 5 as Sender ID, and SN_5 = 501 as Sender Sequence Number. 1298 The following notation is used for the payload of the informative 1299 responses: 1301 o 'bstr(X)' denotes a CBOR byte string with value the byte 1302 serialization of X, with '|' denoting byte concatenation. 1304 o 'OPT' denotes a sequence of CoAP options. This refers to the 1305 phantom registration request encoded by the 'ph_req' parameter, or 1306 to the corresponding latest multicast notification encoded by the 1307 'last_notif' parameter. 1309 o 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the 1310 phantom registration request encoded by the 'ph_req' parameter, or 1311 to the corresponding latest multicast notification encoded by the 1312 'last_notif' parameter. 1314 o 'SIGN' denotes the counter signature appended to an encrypted CoAP 1315 payload. This refers to the phantom registration request encoded 1316 by the 'ph_req' parameter, or to the corresponding latest 1317 multicast notification encoded by the 'last_notif' parameter. 1319 C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1320 | 0.05 (FETCH) | 1321 | Token: 0x4a | 1322 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 1323 | | 1324 | 0xff | 1325 | Encrypted_payload { | 1326 | 0x01 (GET), | 1327 | Observe: 0 (Register), | 1328 | | 1329 | } | 1330 | | 1331 | (S allocates the available Token value 0x7b .) | 1332 | | 1333 | (S sends to itself a phantom observation request PH_REQ | 1334 | as coming from the IP multicast address GRP_ADDR .) | 1335 | ------------------------------------------------------ | 1336 | / | 1337 | \-------------------------------------------------------> | /r 1338 | 0.05 (FETCH) | 1339 | Token: 0x7b | 1340 | OSCORE: {kid: 5 ; piv: 501 ; | 1341 | kid context: 57ab2e; ...} | 1342 | | 1343 | 0xff | 1344 | Encrypted_payload { | 1345 | 0x01 (GET), | 1346 | Observe: 0 (Register), | 1347 | | 1348 | } | 1349 | | 1350 | | 1351 | | 1352 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 1353 | | 1354 | (S creates a group observation of /r .) | 1355 | | 1356 | (S increments the observer counter | 1357 | for the group observation of /r .) | 1358 | | 1359 | | 1360 C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1361 | 2.05 (Content) | 1362 | Token: 0x4a | 1363 | OSCORE: {piv: 301; ...} | 1364 | | 1365 | 0xff | 1366 | Encrypted_payload { | 1367 | 5.03 (Service Unavailable), | 1368 | Content-Format: application/informative-response+cbor, | 1369 | , | 1370 | 0xff, | 1371 | CBOR_payload { | 1372 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1373 | last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD | SIGN), | 1374 | tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, | 1375 | bstr(GRP_ADDR), GRP_PORT], | 1376 | join_uri : "coap://myGM/ace-group/myGroup", | 1377 | sec_gp : "myGroup" | 1378 | } | 1379 | } | 1380 | | 1381 | | 1382 C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1383 | 0.05 (FETCH) | 1384 | Token: 0x01 | 1385 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 1386 | | 1387 | 0xff | 1388 | Encrypted_payload { | 1389 | 0x01 (GET), | 1390 | Observe: 0 (Register), | 1391 | | 1392 | } | 1393 | | 1394 | (S increments the observer counter | 1395 | for the group observation of /r .) | 1396 | | 1397 C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1398 | 2.05 (Content) | 1399 | Token: 0x01 | 1400 | OSCORE: {piv: 401; ...} | 1401 | | 1402 | 0xff, | 1403 | Encrypted_payload { | 1404 | 5.03 (Service Unavailable), | 1405 | Content-Format: application/informative-response+cbor, | 1406 | , | 1407 | 0xff, | 1408 | CBOR_payload { | 1409 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1410 | last_notif : bstr(0x25 | OPT | 0xff | PAYLOAD | SIGN), | 1411 | tp_info : [1, 0x7b, bstr(SRV_ADDR), SRV_PORT, | 1412 | bstr(GRP_ADDR), GRP_PORT], | 1413 | join_uri : "coap://myGM/ace-group/myGroup", | 1414 | sec_gp : "myGroup" | 1415 | } | 1416 | } | 1417 | | 1418 | | 1419 | (The value of the resource /r changes to "5678".) | 1420 | | 1421 C_1 | 1422 + <----------- [ Multicast w/ Group OSCORE ] ------------ S 1423 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 1424 | 2.05 (Content) | 1425 | Token: 0x7b | 1426 | OSCORE: {kid: 5; piv: 502 ; | 1427 | kid context: 57ab2e; ...} | 1428 | | 1429 | 0xff | 1430 | Encrypted_payload { | 1431 | 2.05 (Content), | 1432 | Observe: 11, | 1433 | Content-Format: application/cbor, | 1434 | , | 1435 | 0xff, | 1436 | CBOR_Payload : "5678" | 1437 | } | 1438 | | 1439 | | 1441 The two external_aad used to encrypt and countersign the multicast 1442 notification above have 'request_kid' = 5, 'request_piv' = 501 and 1443 'request_kid_context' = 0x57ab2e. These values are specified in the 1444 'kid', 'piv' and 'kid context' field of the OSCORE option of the 1445 phantom observation request, which is encoded in the 'ph_req' 1446 parameter of the unicast informative response to the two clients. 1447 Thus, the two clients can build the two same external_aad for 1448 decrypting and verifying this multicast notification and the 1449 following ones. 1451 8. Intermediaries 1453 This section specifies how the approach presented in Section 2 and 1454 Section 3 works when a proxy is used between the clients and the 1455 server. In addition to what specified in Section 5.7 of [RFC7252] 1456 and Section 5 of [RFC7641], the following applies. 1458 o A client sends its original observation request to the proxy, 1459 which forwards it to the server. The server considers the proxy 1460 as taking part in the group observation for that target resource, 1461 or takes it as a confirmation of interest if it is already the 1462 case from previously forwarded observation requests. Then, the 1463 server sends the informative response to the proxy, to be 1464 forwarded back to the client. 1466 o Upon receiving an informative response, the proxy performs as 1467 specified in Section 3, with the difference that it does not 1468 consider the latest multicast notification encoded in the 1469 'last_notif' field. In particular, by using the information 1470 retrieved from the informative response, the proxy configures an 1471 observation of the target resource at the origin server, acting as 1472 a client directly taking part in the group observation. The proxy 1473 MUST NOT cache the informative response. 1475 As a consequence, the proxy will listen to the IP multicast 1476 address and port number indicated by the server in the informative 1477 response, as 'cli_addr' and 'cli_port' element of the 'tp_info' 1478 parameter, respectively (see Section 2.2.2.1). Furthermore, 1479 multicast notifications will match the phantom request stored at 1480 the proxy, based on the Token value specified in the 'token' 1481 element of the 'tp_info' parameter in the informative response. 1483 Note that the proxy configures the observation of the target 1484 resource at the server only once, when receiving the first 1485 informative response associated to a newly started group 1486 observation. That is, after forwarding observation requests from 1487 a following new client to be added to the same group observation, 1488 the proxy does not take any action other than forwarding the 1489 informative response back to that client. 1491 o When forwarding the informative response back to a client, the 1492 proxy adds that client to the list of its registered observers for 1493 the target resource, consistently with the previously received 1494 observation request. In particular, the Token value associated to 1495 this observation and to use with the client is the same Token 1496 value used in the original registration request that the client 1497 has sent to the proxy. 1499 o Upon receiving an informative response from the proxy, a client 1500 performs as defined in Section 3, with the following differences. 1502 * In step 1, the client relies on a CoAP endpoint used for 1503 messages having: 1505 + As source address and port number, the IP address and port 1506 number used by the proxy, i.e. the source address and port 1507 number of the informative response received from the proxy. 1509 + As destination address and port number, the IP address and 1510 port number used by the client, i.e. the destination address 1511 and port number of the informative response received from 1512 the proxy. 1514 * In step 2, the Token value used when rebuilding the phantom 1515 registration request is the same Token value used in the 1516 original registration request sent to the proxy. The client 1517 MUST use that Token value as its own local Token value 1518 associated to that group observation, with respect to the 1519 proxy. The particular way to achieve this is implementation 1520 specific. The client does not consider the transport-specific 1521 information specified in the 'tp_info' parameter of the 1522 informative response. 1524 * In step 4, the Token value used when rebuilding the latest 1525 multicast notification is the same Token value used to rebuild 1526 the phantom registration request, as explained above. 1528 o Upon receiving a multicast notification from the server, the proxy 1529 forwards it back separately to each observer client over unicast. 1530 Note that the notification forwarded back to a certain client has 1531 the same Token value of the original observation request sent by 1532 that client to the proxy. 1534 An example is provided in Appendix C. 1536 In the general case with a chain of two or more proxies, every proxy 1537 in the chain takes the role of client with the (next hop towards the) 1538 origin server. Note that the proxy adjacent to the origin server is 1539 the only one in the chain that listens to an IP multicast address to 1540 receive notifications for the group observation. Furthermore, every 1541 proxy in the chain takes the role of server with the (previous hop 1542 towards the) origin client. 1544 9. Intermediaries Together with End-to-End Security 1546 As defined in Section 6, Group OSCORE can be used to protect 1547 multicast notifications end-to-end between the origin server and the 1548 clients. In such a case, additional actions are required when also 1549 the informative responses from the origin server are protected 1550 specifically end-to-end, by using OSCORE or Group OSCORE. 1552 In fact, the proxy adjacent to the origin server is not able to 1553 access the encrypted payload of such informative responses. Hence, 1554 the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters 1555 necessary to correctly receive multicast notifications and forward 1556 them back to the clients. 1558 Then, differently from what defined in Section 8, each proxy 1559 receiving an informative response simply forwards it back to the 1560 client that has sent the corresponding observation request. Note 1561 that the proxy does not even realize the message to be an actual 1562 informative response, since the outer Code field is set to 2.05 1563 (Content). 1565 Once a client receives the informative response, it not only 1566 configures an observation of the target resource at the origin 1567 server. In addition, the client transmits the re-built phantom 1568 request as intended to reach the proxy adjacent to the origin server. 1569 In particular, the client includes the new Listen-To-Multicast- 1570 Responses CoAP option defined in Section 9.1, to provide that proxy 1571 with the transport-specific information required for receiving 1572 multicast notifications for the group observation. 1574 Details on the additional message exchange and processing are defined 1575 in Section 9.2. 1577 9.1. The Listen-To-Multicast-Responses Option 1579 To allow the proxy to listen to the multicast notifications sent by 1580 the server, a new CoAP option is introduced. This option MUST be 1581 supported by clients interested to take part in group observations 1582 through intermediaries, and by proxies that collect multicast 1583 notifications and forward them back to the observer clients. 1585 The option is called Listen-To-Multicast-Responses and is intended 1586 only for requests. As summarized in Figure 2, the option is critical 1587 and proxy-unsafe. 1589 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1590 | No. | C | U | N | R | Name | Format | Len. | Default | 1591 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1592 | TBD | x | x | | | Listen-To- | (*) | 3-1024 | (none) | 1593 | | | | | | Multicast- | | | | 1594 | | | | | | Responses | | | | 1595 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1597 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 1598 (*) See below. 1600 Figure 2: Listen-To-Multicast-Responses 1602 The Listen-To-Multicast-Responses option includes the serialization 1603 of a CBOR array. This specifies transport-specific message 1604 information required for listening to the multicast notifications of 1605 a group observation, and intended to the proxy adjacent to the origin 1606 server sending those notifications. In particular, the serialized 1607 CBOR array has the same format specified in Section 2.2.2 for the 1608 'tp_info' parameter of the informative response (see Section 2.2). 1610 The Listen-To-Multicast-Responses option is of class U for OSCORE 1611 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1613 9.2. Message Processing 1615 Compared to Section 8, the following additions apply when informative 1616 responses are protected end-to-end between the origin server and the 1617 clients. 1619 After the origin server sends an informative response, each proxy 1620 simply forwards it back to the (previous hop towards the) origin 1621 client that has sent the observation request. 1623 Once received the informative response, the origin client rebuilds 1624 the phantom request and accordingly configures an observation of the 1625 target resource, just as defined in Section 8. Then, before 1626 rebuilding the latest multicast notification from the 'last_notif' 1627 parameter of the informative response, the client performs the 1628 following additional actions. 1630 o The client builds a ticket request (see Section 3 of 1631 [I-D.amsuess-core-cachable-oscore]), as intended to reach the 1632 proxy adjacent to the origin server. The ticket request is 1633 formatted as follows. 1635 * The Code field, the outer CoAP options and the encrypted 1636 payload concatenated with the counter signature are the same of 1637 the phantom request used for the group observation. That is, 1638 they are as specified in the 'ph_req' parameter of the received 1639 informative response. 1641 * An outer Observe option is included and set to 0 (Register). 1643 * The outer options Proxy-Scheme, Uri-Host and Uri-Port are 1644 included, and set to the same values they had in the original 1645 registration request sent by the client. 1647 * The new option Listen-To-Multicast-Responses is included as an 1648 outer option. The value is set to the serialization of the 1649 CBOR array specified by the 'tp_info' parameter of the 1650 informative response. 1652 Note that, except for transport-specific information such as 1653 the Token and Message ID values, every different client 1654 participating to the same group observation (hence rebuilding 1655 the same phantom request) will build the same ticket request. 1657 Note also that, identically to the phantom request, the ticket 1658 request is still protected with Group OSCORE, i.e. it has the 1659 same OSCORE option, encrypted payload and counter signature. 1661 Then, the client sends the ticket request to the next hop towards the 1662 origin server. Every proxy in the chain forwards the ticket request 1663 to the next hop towards the origin server, until the last proxy in 1664 the chain is reached. This last proxy, adjacent to the origin 1665 server, proceeds as follows. 1667 o The proxy MUST NOT further forward the ticket request to the 1668 origin server. 1670 o The proxy removes the Proxy-Scheme, Uri-Host and Uri-Port options 1671 from the ticket request. 1673 o The proxy removes the Listen-To-Multicast-Responses option from 1674 the ticket request, and extracts the conveyed transport-specific 1675 information. 1677 o The proxy rebuilds the phantom request associated to the group 1678 observation, by using the ticket request as directly providing the 1679 required transport-independent information. This includes the 1680 outer Code field, the outer CoAP options and the encrypted payload 1681 concatenated with the counter signature. 1683 o The proxy configures an observation of the target resource at the 1684 origin server, acting as a client directly taking part in the 1685 group observation. To this end, the proxy uses the rebuilt 1686 phantom request and the transport-specific information retrieved 1687 from the Listen-To-Multicast-Responses Option. The particular way 1688 to achieve this is implementation specific. 1690 After that, the proxy will listen to the IP multicast address and 1691 port number indicated in the Listen-To-Multicast-Responses option, as 1692 'cli_addr' and 'cli_port' element of the serialized CBOR array, 1693 respectively. Furthermore, multicast notifications will match the 1694 phantom request stored at the proxy, based on the Token value 1695 specified in the 'token' element of the serialized CBOR array in the 1696 Listen-To-Multicast-Responses option. 1698 An example is provided in Appendix D. 1700 10. Informative Response Parameters 1702 This specification defines a number of fields used in the informative 1703 response message defined in Section 2.2. 1705 The table below summarizes them and specifies the CBOR key to use 1706 instead of the full descriptive name. Note that the media type 1707 application/informative-response+cbor MUST be used when these fields 1708 are transported. 1710 +------------+----------+-------------------+-------------+ 1711 | Name | CBOR Key | CBOR Type | Reference | 1712 +------------+----------+-------------------+-------------+ 1713 | ph_req | 1 | byte string | Section 2.2 | 1714 | | | | | 1715 | last_notif | 2 | byte string | Section 2.2 | 1716 | | | | | 1717 | tp_info | 3 | array | Section 2.2 | 1718 | | | | | 1719 | join_uri | 4 | text string | Section 6.1 | 1720 | | | | | 1721 | sec_gp | 5 | text string | Section 6.1 | 1722 | | | | | 1723 | as_uri | 6 | text string | Section 6.1 | 1724 | | | | | 1725 | cs_alg | 7 | int / text string | Section 6.1 | 1726 | | | | | 1727 | cs_crv | 8 | int / text string | Section 6.1 | 1728 | | | | | 1729 | cs_kty | 9 | int / text string | Section 6.1 | 1730 | | | | | 1731 | cs_kenc | 10 | int | Section 6.1 | 1732 | | | | | 1733 | alg | 11 | int / text string | Section 6.1 | 1734 | | | | | 1735 | hkdf | 12 | int / text string | Section 6.1 | 1736 +------------+----------+-------------------+-------------+ 1738 11. Transport Protocol Identifiers 1740 This specification defines some values of transport protocol 1741 identifiers used in the 'tp_info' parameter of the informative 1742 response message defined in Section 2.2 of this specification. 1744 According to the encoding specified in Section 2.2.2, these values 1745 are used as first element of the CBOR array 'tp_info' of an 1746 informative response message. 1748 The table below summarizes them, and specifies the integer value to 1749 use instead of the full descriptive name. 1751 +----------+------------------------------------+-------+-----------+ 1752 | Name | Description | Value | Reference | 1753 +----------+------------------------------------+-------+-----------+ 1754 | Reserved | This value is reserved | 0 | | 1755 | | | | | 1756 | UDP | UDP is used to transport CoAP | 1 | Section 2 | 1757 | | messages, as per [RFC7252] and | | .2.2.1 | 1758 | | [I-D.ietf-core-groupcomm-bis] | | | 1759 +----------+------------------------------------+-------+-----------+ 1761 12. Security Considerations 1763 The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor 1764 e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for 1765 this document. 1767 If multicast notifications are protected using Group OSCORE, the 1768 original registration requests and related unicast (notification) 1769 responses MUST also be secured, including and especially the 1770 informative responses from the server. This prevents on-path active 1771 adversaries from altering the conveyed IP multicast address and 1772 serialized phantom registration request. Thus, it ensures secure 1773 binding between every multicast notification for a same observed 1774 resource and the phantom registration request that started the group 1775 observation of that resource. 1777 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 1778 so ensuring that the secure binding above is enforced end-to-end 1779 between the server and each observing client. 1781 12.1. Listen-To-Multicast-Responses Option 1783 The CoAP option Listen-To-Multicast-Responses defined in Section 9.1 1784 is of class U for OSCORE and Group OSCORE 1785 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1787 This allows the proxy adjacent to the origin server to access the 1788 option value conveyed in a ticket request (see Section 9.2), and to 1789 retrieve from it the transport-specific information about a phantom 1790 request. By doing so, the proxy becomes able to configure an 1791 observation of the target resource and to receive multicast 1792 notifications matching to the phantom request. 1794 Any proxy in the chain, as well as further possible intermediaries or 1795 on-path active adversaries, are thus able to remove the option or 1796 alter its content, before the ticket request reaches the proxy 1797 adjacent to the origin server. 1799 Removing the option would result in the proxy adjacent to the origin 1800 server to not configure the group observation, if that has not 1801 happened yet. In such a case, the proxy would not receive the 1802 corresponding multicast notifications to be forwarded back to the 1803 clients. 1805 Altering the option content would result in the proxy adjacent to the 1806 origin server to incorrectly configure a group observation (e.g., by 1807 indicating a wrong multicast IP address) hence preventing the correct 1808 reception of multicast notifications and their forwarding to the 1809 clients; or to configure bogus group observations that are currently 1810 not active on the origin server. 1812 In order to prevent what described above, the ticket requests 1813 conveying the Listen-To-Multicast-Responses option can be 1814 additionally protected hop-by-hop. 1816 13. IANA Considerations 1818 This document has the following actions for IANA. 1820 13.1. Media Type Registrations 1822 This specification registers the media type 'application/informative- 1823 response+cbor' for error messages as informative response defined in 1824 Section 2.2 of this specification, when carrying parameters encoded 1825 in CBOR. This registration follows the procedures specified in 1826 [RFC6838]. 1828 o Type name: application 1830 o Subtype name: informative-response+cbor 1832 o Required parameters: none 1834 o Optional parameters: none 1836 o Encoding considerations: Must be encoded as a CBOR map containing 1837 the parameters defined in Section 2.2 of [this document]. 1839 o Security considerations: See Section 12 of [this document]. 1841 o Interoperability considerations: n/a 1843 o Published specification: [this document] 1844 o Applications that use this media type: The type is used by CoAP 1845 servers and clients that support error messages as informative 1846 response defined in Section 2.2 of [this document]. 1848 o Additional information: n/a 1850 o Person & email address to contact for further information: 1851 iesg@ietf.org [1] 1853 o Intended usage: COMMON 1855 o Restrictions on usage: None 1857 o Author: Marco Tiloca marco.tiloca@ri.se [2] 1859 o Change controller: IESG 1861 13.2. CoAP Content-Formats Registry 1863 IANA is asked to add the following entry to the "CoAP Content- 1864 Formats" sub-registry defined in Section 12.3 of [RFC7252], within 1865 the "Constrained RESTful Environments (CoRE) Parameters" registry. 1867 Media Type: application/informative-response+cbor 1869 Encoding: - 1871 ID: TBD 1873 Reference: [this document] 1875 13.3. Informative Response Parameters Registry 1877 This specification establishes the "Informative Response Parameters" 1878 IANA registry. The registry has been created to use the "Expert 1879 Review Required" registration procedure [RFC8126]. Expert review 1880 guidelines are provided in Section 13.6. 1882 The columns of this registry are: 1884 o Name: This is a descriptive name that enables easier reference to 1885 the item. The name MUST be unique. It is not used in the 1886 encoding. 1888 o CBOR Key: This is the value used as CBOR key of the item. These 1889 values MUST be unique. The value can be a positive integer, a 1890 negative integer, or a string. 1892 o CBOR Type: This contains the CBOR type of the item, or a pointer 1893 to the registry that defines its type, when that depends on 1894 another item. 1896 o Reference: This contains a pointer to the public specification for 1897 the item. 1899 This registry has been initially populated by the values in 1900 Section 10. The "Reference" column for all of these entries refers 1901 to sections of this document. 1903 13.4. Transport Protocol Identifiers Registry 1905 This specification establishes the "Transport Protocol Identifiers" 1906 IANA sub-registry, within the "Informative Response Parameters" 1907 registry defined in Section 13.3 of this specification. The sub- 1908 registry has been created to use the "Expert Review Required" 1909 registration procedure [RFC8126]. Expert review guidelines are 1910 provided in Section 13.6. 1912 The columns of this sub-registry are: 1914 o Name: This is a descriptive name that enables easier reference to 1915 the item. The name MUST be unique. It is not used in the 1916 encoding. 1918 o Description: Text giving an overview of the transport protocol 1919 referred by this item. 1921 o Value: CBOR abbreviation for the name of this transport protocol. 1922 Different ranges of values use different registration policies 1923 [RFC8126]. Integer values from -256 to 255 are designated as 1924 Standards Action. Integer values from -65536 to -257 and from 256 1925 to 65535 are designated as Specification Required. Integer values 1926 greater than 65535 are designated as Expert Review. Integer 1927 values less than -65536 are marked as Private Use. 1929 o Reference: This contains a pointer to the public specification for 1930 the item. 1932 This registry has been initially populated by the values in 1933 Section 11. The "Reference" column for all of these entries refers 1934 to sections of this document. 1936 13.5. CoAP Option Numbers Registry 1938 IANA is asked to enter the following option numbers to the "CoAP 1939 Option Numbers" registry defined in [RFC7252] within the "CoRE 1940 Parameters" registry. 1942 +--------+--------------------------------------+-------------------+ 1943 | Number | Name | Reference | 1944 +--------+--------------------------------------+-------------------+ 1945 | TBD | Multicast-Response-Feedback-Divider | [[this document]] | 1946 +--------+--------------------------------------+-------------------+ 1947 | TBD | Listen-To-Multicast-Responses | [[this document]] | 1948 +--------+--------------------------------------+-------------------+ 1950 13.6. Expert Review Instructions 1952 The IANA registries established in this document are defined as 1953 expert review. This section gives some general guidelines for what 1954 the experts should be looking for, but they are being designated as 1955 experts for a reason so they should be given substantial latitude. 1957 Expert reviewers should take into consideration the following points: 1959 o Point squatting should be discouraged. Reviewers are encouraged 1960 to get sufficient information for registration requests to ensure 1961 that the usage is not going to duplicate one that is already 1962 registered and that the point is likely to be used in deployments. 1963 The zones tagged as private use are intended for testing purposes 1964 and closed environments, code points in other ranges should not be 1965 assigned for testing. 1967 o Specifications are required for the standards track range of point 1968 assignment. Specifications should exist for specification 1969 required ranges, but early assignment before a specification is 1970 available is considered to be permissible. Specifications are 1971 needed for the first-come, first-serve range if they are expected 1972 to be used outside of closed environments in an interoperable way. 1973 When specifications are not provided, the description provided 1974 needs to have sufficient information to identify what the point is 1975 being used for. 1977 o Experts should take into account the expected usage of fields when 1978 approving point assignment. The fact that there is a range for 1979 standards track documents does not mean that a standards track 1980 document cannot have points assigned outside of that range. The 1981 length of the encoded value should be weighed against how many 1982 code points of that length are left, the size of device it will be 1983 used on, and the number of code points left that encode to that 1984 size. 1986 14. References 1988 14.1. Normative References 1990 [COSE.Algorithms] 1991 IANA, "COSE Algorithms", 1992 . 1995 [COSE.Elliptic.Curves] 1996 IANA, "COSE Elliptic Curves", 1997 . 2000 [COSE.Key.Types] 2001 IANA, "COSE Key Types", 2002 . 2005 [I-D.ietf-cbor-7049bis] 2006 Bormann, C. and P. Hoffman, "Concise Binary Object 2007 Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work 2008 in progress), September 2020. 2010 [I-D.ietf-core-groupcomm-bis] 2011 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2012 for the Constrained Application Protocol (CoAP)", draft- 2013 ietf-core-groupcomm-bis-02 (work in progress), November 2014 2020. 2016 [I-D.ietf-core-oscore-groupcomm] 2017 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2018 "Group OSCORE - Secure Group Communication for CoAP", 2019 draft-ietf-core-oscore-groupcomm-10 (work in progress), 2020 November 2020. 2022 [I-D.ietf-cose-rfc8152bis-algs] 2023 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2024 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 2025 (work in progress), September 2020. 2027 [I-D.ietf-cose-rfc8152bis-struct] 2028 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2029 Structures and Process", draft-ietf-cose-rfc8152bis- 2030 struct-14 (work in progress), September 2020. 2032 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2033 Requirement Levels", BCP 14, RFC 2119, 2034 DOI 10.17487/RFC2119, March 1997, 2035 . 2037 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2038 "Transmission of IPv6 Packets over IEEE 802.15.4 2039 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2040 . 2042 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2043 Specifications and Registration Procedures", BCP 13, 2044 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2045 . 2047 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2048 Application Protocol (CoAP)", RFC 7252, 2049 DOI 10.17487/RFC7252, June 2014, 2050 . 2052 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2053 Application Protocol (CoAP)", RFC 7641, 2054 DOI 10.17487/RFC7641, September 2015, 2055 . 2057 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2058 Bose, "Constrained Application Protocol (CoAP) Option for 2059 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2060 August 2016, . 2062 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2063 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2064 March 2017, . 2066 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2067 Writing an IANA Considerations Section in RFCs", BCP 26, 2068 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2069 . 2071 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2072 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2073 May 2017, . 2075 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2076 "Object Security for Constrained RESTful Environments 2077 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2078 . 2080 14.2. Informative References 2082 [I-D.amsuess-core-cachable-oscore] 2083 Amsuess, C. and M. Tiloca, "Cachable OSCORE", draft- 2084 amsuess-core-cachable-oscore-00 (work in progress), July 2085 2020. 2087 [I-D.ietf-ace-key-groupcomm-oscore] 2088 Tiloca, M., Park, J., and F. Palombini, "Key Management 2089 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 2090 oscore-09 (work in progress), November 2020. 2092 [I-D.ietf-ace-oauth-authz] 2093 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2094 H. Tschofenig, "Authentication and Authorization for 2095 Constrained Environments (ACE) using the OAuth 2.0 2096 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 2097 (work in progress), June 2020. 2099 [I-D.ietf-core-coap-pubsub] 2100 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2101 Subscribe Broker for the Constrained Application Protocol 2102 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 2103 progress), September 2019. 2105 [I-D.ietf-core-coral] 2106 Hartke, K., "The Constrained RESTful Application Language 2107 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 2108 March 2020. 2110 [I-D.ietf-core-resource-directory] 2111 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 2112 Amsuess, "CoRE Resource Directory", draft-ietf-core- 2113 resource-directory-25 (work in progress), July 2020. 2115 [I-D.ietf-tls-dtls13] 2116 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2117 Datagram Transport Layer Security (DTLS) Protocol Version 2118 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 2119 2020. 2121 [I-D.tiloca-core-oscore-discovery] 2122 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 2123 Groups with the CoRE Resource Directory", draft-tiloca- 2124 core-oscore-discovery-07 (work in progress), November 2125 2020. 2127 [MOBICOM99] 2128 Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast 2129 Storm Problem in a Mobile Ad Hoc Network", Proceedings of 2130 the 5th annual ACM/IEEE international conference on Mobile 2131 computing and networking , August 1999, 2132 . 2135 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2136 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2137 January 2012, . 2139 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2140 Definition Language (CDDL): A Notational Convention to 2141 Express Concise Binary Object Representation (CBOR) and 2142 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2143 June 2019, . 2145 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2146 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2147 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2148 2020, . 2150 14.3. URIs 2152 [1] mailto:iesg@ietf.org 2154 [2] mailto:marco.tiloca@ri.se 2156 Appendix A. Different Sources for Group Observation Data 2158 While the clients usually receive the phantom registration request 2159 and other information related to the group observation through an 2160 Informative Response, the same data can be made available through 2161 different services, such as the following ones. 2163 A.1. Topic Discovery in Publish-Subscribe Settings 2165 In a Publish-Subscribe scenario ([I-D.ietf-core-coap-pubsub]), a 2166 group observation can be discovered along with topic metadata. For 2167 instance, a discovery step can make the following metadata available. 2169 This example assumes a CoRAL namespace [I-D.ietf-core-coral], that 2170 contains properties analogous to those in the content-format 2171 application/informative-response+cbor. 2173 Request: 2175 GET 2176 Accept: CoRAL 2178 Response: 2180 2.05 Content 2181 Content-Format: CoRAL 2183 rdf:type 2184 topic { 2185 ph_req h"0160.." 2186 last_notif h"256105.." 2187 tp_info [1, h"7b", h"20010db80100..0001", 5683, 2188 h"ff35003020010db8..1234", 5683] 2189 } 2191 With this information from the topic discovery step, the client can 2192 already set up its multicast address and start receiving multicast 2193 notifications. 2195 In heavily asymmetric networks like municipal notification services, 2196 discovery and notifications do not necessarily need to use the same 2197 network link. For example, a departure monitor could use its (costly 2198 and usually-off) cellular uplink to discover the topics it needs to 2199 update its display to, and then listen on a LoRA-WAN interface for 2200 receiving the actual multicast notifications. 2202 A.2. Introspection at the Multicast Notification Sender 2204 For network debugging purposes, it can be useful to query a server 2205 that sends multicast responses as matching a phantom registration 2206 request. 2208 Such an interface is left for other documents to specify on demand. 2209 As an example, a possible interface can be as follows, and rely on 2210 the already known Token value of intercepted multicast notifications, 2211 associated to a phantom registration request. 2213 Request: 2215 GET 2217 Response: 2219 2.05 Content 2220 Content-Format: application/informative-response+cbor 2222 { 2223 'ph_req': h"0160..", 2224 'last_notif' : h"256105..", 2225 'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 2226 h"ff35003020010db8..1234", 5683] 2227 } 2229 For example, a network sniffer could offer sending such a request 2230 when unknown multicast notifications are seen on a network. 2231 Consequently, it can associate those notifications with a URI, or 2232 decrypt them, if member of the correct OSCORE group. 2234 Appendix B. Pseudo-Code for Rough Counting of Clients 2236 This appendix provides a description in pseudo-code of the two 2237 algorithms used for the rough counting of active observers, as 2238 defined in Section 5. 2240 In particular, Appendix B.1 describes the algorithm for the client 2241 side, while Appendix B.2 describes an optimized version for 2242 constrained clients. Finally, Appendix B.3 describes the algorithm 2243 for the server side. 2245 B.1. Client Side 2246 input: int Q, // Value of the MRFD option 2247 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2248 // unless overridden 2250 output: None 2252 int RAND_MIN = 0; 2253 int RAND_MAX = (2**Q) - 1; 2254 int I = randomInteger(RAND_MIN, RAND_MAX); 2256 if (I == 0) { 2257 float fraction = randomFloat(0, 1); 2259 Timer t = new Timer(); 2260 t.setAndStart(fraction * LEISURE_TIME); 2261 while(!t.isExpired()); 2263 Request req = new Request(); 2264 // Initialize as NON and with maximum 2265 // No-Response settings, set options ... 2267 Option opt = new Option(OBSERVE); 2268 opt.set(0); 2269 req.setOption(opt); 2271 opt = new Option(MRFD); 2272 req.setOption(opt); 2274 req.send(SRV_ADDR, SRV_PORT); 2275 } 2277 B.2. Client Side - Optimized Version 2278 input: int Q, // Value of the MRFD option 2279 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2280 // unless overridden 2282 output: None 2284 const unsigned int UINT_BIT = CHAR_BIT * sizeof(unsigned int); 2286 if (respond_to(Q) == true) { 2287 float fraction = randomFloat(0, 1); 2289 Timer t = new Timer(); 2290 t.setAndStart(fraction * LEISURE_TIME); 2291 while(!t.isExpired()); 2293 Request req = new Request(); 2294 // Initialize as NON and with maximum 2295 // No-Response settings, set options ... 2297 Option opt = new Option(OBSERVE); 2298 opt.set(0); 2299 req.setOption(opt); 2301 opt = new Option(MRFD); 2302 req.setOption(opt); 2304 req.send(SRV_ADDR, SRV_PORT); 2305 } 2307 bool respond_to(int Q) { 2308 while (Q >= UINT_BIT) { 2309 if (rand() != 0) return false; 2310 Q -= UINT_BIT; 2311 } 2312 unsigned int mask = ~((~0u) << Q); 2313 unsigned int masked = mask & rand(); 2314 return masked == 0; 2315 } 2317 B.3. Server Side 2319 input: int COUNT, // Current observer counter 2320 int M, // Desired number of confirmations 2321 int MAX_CONFIRMATION_WAIT, 2322 Response notification, // Multicast notification to send 2324 output: int NEW_COUNT // Updated observer counter 2325 int D = 4; // Dampener value 2326 int RETRY_NEXT_THRESHOLD = 4; 2327 float CANCEL_THRESHOLD = 0.2; 2329 int N = max(COUNT, 1); 2330 int Q = max(ceil(log2(N / M)), 0); 2331 Option opt = new Option(MRFD); 2332 opt.set(Q); 2334 notification.setOption(opt); 2335 2336 notification.send(GRP_ADDR, GRP_PORT); 2338 Timer t = new Timer(); 2339 t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 2340 while(!t.isExpired()); 2342 // Time t2 2344 int R = ; 2347 int E = R * (2**Q); 2349 // Determine after how many multicast notifications 2350 // the next count update will be performed 2351 if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) { 2352 2353 } 2354 else { 2355 2356 } 2358 // Compute the new count estimate 2359 int COUNT_PRIME = ; 2360 int NEW_COUNT = COUNT_PRIME + ((E - N) / D); 2362 // Determine whether to cancel the group observation 2363 if (NEW_COUNT < CANCEL_THRESHOLD) { 2364 ; 2365 return 0; 2366 } 2368 return NEW_COUNT; 2370 Appendix C. Example with a Proxy 2372 This section provides an example when a proxy P is used between the 2373 clients and the server. The same assumptions and notation used in 2374 Section 4 are used for this example. In addition, the proxy has 2375 address PRX_ADDR and listens to the port number PRX_PORT. 2377 Unless explicitly indicated, all messages transmitted on the wire are 2378 sent over unicast. 2380 C1 C2 P S 2381 | | | | 2382 +------------>| | Token: 0x4a 2383 | GET | | | Observe: 0 (Register) 2384 | | | | Proxy-Uri: coap://sensor.example/r 2385 | | | | 2386 | | +------->| Token: 0x5e 2387 | | | GET | Observe: 0 (Register) 2388 | | | | Uri-Host: sensor.example 2389 | | | | Uri-Path: r 2390 | | | | 2391 | | | | (S allocates the available Token value 0x7b) 2392 | | | | 2393 | | | | (S sends to itself a phantom observation 2394 | | | | request PH_REQ as coming from the 2395 | | | | IP multicast address GRP_ADDR) 2396 | | | | 2397 | | | ------+ 2398 | | | / | 2399 | | | \----->| Token: 0x7b 2400 | | | GET | Observe: 0 (Register) 2401 | | | | Uri-Host: sensor.example 2402 | | | | Uri-Path: r 2403 | | | | 2404 | | | | 2405 | | | | (S creates a group observation of /r) 2406 | | | | 2407 | | | | (S increments the observer counter 2408 | | | | for the group observation of /r) 2409 | | | | 2410 | | | | 2411 | | |<-------+ Token: 0x5e 2412 | | | 5.03 | Content-Format: application/ 2413 | | | | informative-response+cbor 2414 | | | | 2415 | | | | Payload: { 2416 | | | | ph_req : bstr(0x01 | OPT), 2417 | | | | last_notif : bstr(0x25 | OPT | 2418 | | | | 0xff | PAYLOAD), 2419 | | | | tp_info : [1, 0x7b, 2420 | | | | bstr(SRV_ADDR), SRV_PORT, 2421 | | | | bstr(GRP_ADDR), GRP_PORT] 2422 | | | | } 2423 | | | | 2424 | | | | 2425 | | | | (The proxy starts listening to the 2426 | | | | GRP_ADDR address and the GRP_PORT port.) 2427 | | | | 2428 | | | | (The proxy adds C1 to its list of observers.) 2429 | | | | 2430 | | | | 2431 |<------------+ | Token: 0x4a 2432 | 5.03 | | | Content-Format: application/ 2433 | | | | informative-response+cbor 2434 | | | | 2435 | | | | Payload: { 2436 | | | | ph_req : bstr(0x01 | OPT), 2437 | | | | last_notif : bstr(0x25 | OPT | 2438 | | | | 0xff | PAYLOAD), 2439 | | | | tp_info : [1, 0x7b, 2440 | | | | bstr(SRV_ADDR), SRV_PORT, 2441 | | | | bstr(GRP_ADDR), GRP_PORT] 2442 | | | | } 2443 | | | | 2444 | +----->| | Token: 0x01 2445 | | GET | | Observe: 0 (Register) 2446 | | | | Proxy-Uri: coap://sensor.example/r 2447 | | | | 2448 | | +------->| Token: 0x5e 2449 | | | GET | Observe: 0 (Register) 2450 | | | | Uri-Host: sensor.example 2451 | | | | Uri-Path: r 2452 | | | | 2453 | | |<-------+ Token: 0x5e 2454 | | | 5.03 | Content-Format: application/ 2455 | | | | informative-response+cbor 2456 | | | | 2457 | | | | Payload: { 2458 | | | | ph_req : bstr(0x01 | OPT), 2459 | | | | last_notif : bstr(0x25 | OPT | 2460 | | | | 0xff | PAYLOAD), 2461 | | | | tp_info : [1, 0x7b, 2462 | | | | bstr(SRV_ADDR), SRV_PORT, 2463 | | | | bstr(GRP_ADDR), GRP_PORT] 2464 | | | | } 2465 | | | | 2466 | | | | (The proxy adds C2 to its list of observers.) 2467 | | | | 2468 | | | | 2469 | |<-----+ | Token: 0x4a 2470 | | 5.03 | | Content-Format: application/ 2471 | | | | informative-response+cbor 2472 | | | | 2473 | | | | Payload: { 2474 | | | | ph_req : bstr(0x01 | OPT), 2475 | | | | last_notif : bstr(0x25 | OPT | 2476 | | | | 0xff | PAYLOAD), 2477 | | | | tp_info : [1, 0x7b, 2478 | | | | bstr(SRV_ADDR), SRV_PORT, 2479 | | | | bstr(GRP_ADDR), GRP_PORT] 2480 | | | | } 2481 | | | | 2482 | | | | (The value of the resource 2483 | | | | /r changes to "5678".) 2484 | | | | 2485 | | | (*) | 2486 | | |<-------+ Token: 0x7b 2487 | | | 2.05 | Observe: 11 2488 | | | | Content-Format: application/ 2489 | | | | informative-response+cbor 2490 | | | | 2491 | | | | Payload: "5678" 2492 | | | | 2493 |<------------+ | Token: 0x4a 2494 | 2.05 | | | Observe: 54123 2495 | | | | Content-Format: application/ 2496 | | | | informative-response+cbor 2497 | | | | 2498 | | | | Payload: "5678" 2499 | | | | 2500 | |<-----+ | Token: 0x01 2501 | | 2.05 | | Observe: 54123 2502 | | | | Content-Format: application/ 2503 | | | | informative-response+cbor 2504 | | | | 2505 | | | | Payload: "5678" 2507 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT 2509 Appendix D. Example with a Proxy and Group OSCORE 2511 This section provides an example when a proxy P is used between the 2512 clients and the server, and Group OSCORE is used to protect multicast 2513 notifications end-to-end between the server and the clients. 2515 The same assumptions and notation used in Section 7 are used for this 2516 example. In addition, the proxy has address PRX_ADDR and listens to 2517 the port number PRX_PORT. 2519 Unless explicitly indicated, all messages transmitted on the wire are 2520 sent over unicast and protected with OSCORE end-to-end between a 2521 client and the server. 2523 C1 C2 P S 2524 | | | | 2525 +-------------->| | Token: 0x4a 2526 | FETCH | | | Observe: 0 (Register) 2527 | | | | OSCORE: {kid: 1 ; piv: 101 ; ...} 2528 | | | | Uri-Host: sensor.example 2529 | | | | Proxy-Scheme: coap 2530 | | | | 2531 | | | | 0xff 2532 | | | | Encrypted_payload { 2533 | | | | 0x01 (GET), 2534 | | | | Observe: 0 (Register), 2535 | | | | Uri-Path: r, 2536 | | | | 2537 | | | | } 2538 | | | | 2539 | | +-------->| Token: 0x5e 2540 | | | FETCH | Observe: 0 (Register) 2541 | | | | OSCORE: {kid: 1 ; piv: 101 ; ...} 2542 | | | | Uri-Host: sensor.example 2543 | | | | 2544 | | | | 0xff 2545 | | | | Encrypted_payload { 2546 | | | | 0x01 (GET), 2547 | | | | Observe: 0 (Register), 2548 | | | | Uri-Path: r, 2549 | | | | 2550 | | | | } 2551 | | | | 2552 | | | | 2553 | | | | (S allocates the available 2554 | | | | Token value 0x7b .) 2555 | | | | 2556 | | | | (S sends to itself a phantom observation 2557 | | | | request PH_REQ as coming from the 2558 | | | | IP multicast address GRP_ADDR) 2559 | | | | 2560 | | | | 2561 | | | -------+ 2562 | | | / | 2563 | | | \------>| Token: 0x7b 2564 | | | FETCH | Observe: 0 (Register) 2565 | | | | OSCORE: {kid: 5 ; piv: 501 ; 2566 | | | | kid context: 57ab2e; ...} 2567 | | | | Uri-Host: sensor.example 2568 | | | | 2569 | | | | 0xff 2570 | | | | Encrypted_payload { 2571 | | | | 0x01 (GET), 2572 | | | | Observe: 0 (Register), 2573 | | | | Uri-Path: r 2574 | | | | 2575 | | | | } 2576 | | | | 2577 | | | | 2578 | | | | 2579 | | | | (S steps SN_5 in the Group OSCORE 2580 | | | | Security Context : SN_5 <== 502) 2581 | | | | 2582 | | | | (S creates a group observation of /r) 2583 | | | | 2584 | | | | (S increments the observer counter 2585 | | | | for the group observation of /r) 2586 | | | | 2587 | | | | 2588 | | |<--------+ Token: 0x5e 2589 | | | 2.05 | OSCORE: {piv: 301 ; ...} 2590 | | | | 2591 | | | | 0xff 2592 | | | | Encrypted_payload { 2593 | | | | 5.03 (Service Unavailable), 2594 | | | | Content-Format: application/ 2595 | | | | informative-response+cbor, 2596 | | | | , 2597 | | | | 0xff, 2598 | | | | CBOR_payload { 2599 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2600 | | | | PAYLOAD | SIGN), 2601 | | | | last_notif : bstr(0x25 | OPT | 0xff | 2602 | | | | PAYLOAD | SIGN), 2603 | | | | tp_info : [1, 0x7b, bstr(SRV_ADDR), 2604 | | | | SRV_PORT, bstr(GRP_ADDR), 2605 | | | | GRP_PORT] 2606 | | | | join_uri : "coap://myGM/ 2607 | | | | ace-group/myGroup", 2608 | | | | sec_gp : "myGroup" 2609 | | | | } 2610 | | | | } 2611 | | | | 2612 |<--------------+ | Token: 0x4a 2613 | 2.05 | | | OSCORE: {piv: 301 ; ...} 2614 | | | | 2615 | | | | 0xff 2616 | | | | Encrypted_payload { 2617 | | | | 5.03 (Service Unavailable), 2618 | | | | Content-Format: application/ 2619 | | | | informative-response+cbor, 2620 | | | | , 2621 | | | | 0xff, 2622 | | | | CBOR_payload { 2623 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2624 | | | | PAYLOAD | SIGN), 2625 | | | | last_notif : bstr(0x25 | OPT | 0xff | 2626 | | | | PAYLOAD | SIGN), 2627 | | | | tp_info : [1, 0x7b, bstr(SRV_ADDR), 2628 | | | | SRV_PORT, bstr(GRP_ADDR), 2629 | | | | GRP_PORT] 2630 | | | | join_uri : "coap://myGM/ 2631 | | | | ace-group/myGroup", 2632 | | | | sec_gp : "myGroup" 2633 | | | | } 2634 | | | | } 2635 | | | | 2636 +-------------->| | Token: 0x4b 2637 | FETCH | | | Observe: 0 (Register) 2638 | | | | OSCORE: {kid: 5 ; piv: 501 ; ...} 2639 | | | | Uri-Host: sensor.example 2640 | | | | Proxy-Scheme: coap 2641 | | | | Listen-To- 2642 | | | | Multicast-Responses: {[0x7b, 1, 2643 | | | | bstr(SRV_ADDR), 2644 | | | | SRV_PORT, 2645 | | | | bstr(GRP_ADDR), 2646 | | | | GRP_PORT] 2647 | | | | } 2648 | | | | 2649 | | | | 0xff 2650 | | | | Encrypted_payload { 2651 | | | | 0x01 (GET), 2652 | | | | Observe: 0 (Register), 2653 | | | | Uri-Path: r 2654 | | | | 2655 | | | | } 2656 | | | | 2657 | | | | 2658 | | | | 2659 | | | | (The proxy starts listening to the 2660 | | | | GRP_ADDR address and the GRP_PORT port.) 2661 | | | | 2662 | | | | (The proxy adds C1 to 2663 | | | | its list of observers.) 2664 | | | | 2665 | | | | 2666 | +------>| | Token: 0x01 2667 | | FETCH | | Observe: 0 (Register) 2668 | | | | OSCORE: {kid: 2 ; piv: 201 ; ...} 2669 | | | | Uri-Host: sensor.example 2670 | | | | Proxy-Scheme: coap 2671 | | | | 2672 | | | | 0xff 2673 | | | | Encrypted_payload { 2674 | | | | 0x01 (GET), 2675 | | | | Observe: 0 (Register), 2676 | | | | Uri-Path: r, 2677 | | | | 2678 | | | | } 2679 | | | | 2680 | | +-------->| Token: 0x5e 2681 | | | FETCH | Observe: 0 (Register) 2682 | | | | OSCORE: {kid: 2 ; piv: 201 ; ...} 2683 | | | | Uri-Host: sensor.example 2684 | | | | 2685 | | | | 0xff 2686 | | | | Encrypted_payload { 2687 | | | | 0x01 (GET), 2688 | | | | Observe: 0 (Register), 2689 | | | | Uri-Path: r, 2690 | | | | 2691 | | | | } 2692 | | | | 2693 | | |<--------+ Token: 0x5e 2694 | | | 2.05 | OSCORE: {piv: 401 ; ...} 2695 | | | | 2696 | | | | 0xff 2697 | | | | Encrypted_payload { 2698 | | | | 5.03 (Service Unavailable), 2699 | | | | Content-Format: application/ 2700 | | | | informative-response+cbor, 2701 | | | | , 2702 | | | | 0xff, 2703 | | | | CBOR_payload { 2704 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2705 | | | | PAYLOAD | SIGN), 2706 | | | | last_notif : bstr(0x25 | OPT | 0xff | 2707 | | | | PAYLOAD | SIGN), 2708 | | | | tp_info : [1, 0x7b, bstr(SRV_ADDR), 2709 | | | | SRV_PORT, bstr(GRP_ADDR), 2710 | | | | GRP_PORT] 2711 | | | | join_uri : "coap://myGM/ 2712 | | | | ace-group/myGroup", 2713 | | | | sec_gp : "myGroup" 2714 | | | | } 2715 | | | | } 2716 | | | | 2717 | |<------+ | Token: 0x01 2718 | | 2.05 | | OSCORE: {piv: 401 ; ...} 2719 | | | | 2720 | | | | 0xff 2721 | | | | Encrypted_payload { 2722 | | | | 5.03 (Service Unavailable), 2723 | | | | Content-Format: application/ 2724 | | | | informative-response+cbor, 2725 | | | | , 2726 | | | | 0xff, 2727 | | | | CBOR_payload { 2728 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2729 | | | | PAYLOAD | SIGN), 2730 | | | | last_notif : bstr(0x25 | OPT | 0xff | 2731 | | | | PAYLOAD | SIGN), 2732 | | | | tp_info : [1, 0x7b, bstr(SRV_ADDR), 2733 | | | | SRV_PORT, bstr(GRP_ADDR), 2734 | | | | GRP_PORT] 2735 | | | | join_uri : "coap://myGM/ 2736 | | | | ace-group/myGroup", 2737 | | | | sec_gp : "myGroup" 2738 | | | | } 2739 | | | | } 2740 | | | | 2741 | +------>| | Token: 0x02 2742 | | FETCH | | Observe: 0 (Register) 2743 | | | | OSCORE: {kid: 5 ; piv: 501 ; ...} 2744 | | | | Uri-Host: sensor.example 2745 | | | | Proxy-Scheme: coap 2746 | | | | Listen-To- 2747 | | | | Multicast-Responses: {[0x7b, 1, 2748 | | | | bstr(SRV_ADDR), 2749 | | | | SRV_PORT, 2750 | | | | bstr(GRP_ADDR), 2751 | | | | GRP_PORT] 2752 | | | | } 2753 | | | | 2754 | | | | 0xff 2755 | | | | Encrypted_payload { 2756 | | | | 0x01 (GET), 2757 | | | | Observe: 0 (Register), 2758 | | | | Uri-Path: r 2759 | | | | 2760 | | | | } 2761 | | | | 2762 | | | | 2763 | | | | 2764 | | | | (The proxy adds C2 to 2765 | | | | its list of observers.) 2766 | | | | 2767 | | | | 2768 | | | | (The value of the resource 2769 | | | | /r changes to "5678".) 2770 | | | | 2771 | | | | 2772 | | | (*) | 2773 | | |<--------+ Token: 0x7b 2774 | | | 2.05 | Observe: 11 2775 | | | | OSCORE: {kid: 5; piv: 502 ; 2776 | | | | kid context: 57ab2e; ...} 2777 | | | | 2778 | | | | 0xff 2779 | | | | Encrypted_payload { 2780 | | | | 2.05 (Content), 2781 | | | | Observe: 11, 2782 | | | | Content-Format: application/cbor, 2783 | | | | , 2784 | | | | 0xff, 2785 | | | | CBOR_Payload : "5678" 2786 | | | | } 2787 | | | | 2788 | | | | 2789 | | | | 2790 | | | | 2791 |<--------------+ | Token: 0x4b 2792 | 2.05 | | | Observe: 54123 2793 | | | | OSCORE: {kid: 5; piv: 502 ; 2794 | | | | kid context: 57ab2e; ...} 2795 | | | | 2796 | | | | 0xff 2797 | | | | Encrypted_payload { 2798 | | | | 2.05 (Content), 2799 | | | | Observe: 11, 2800 | | | | Content-Format: application/cbor, 2801 | | | | , 2802 | | | | 0xff, 2803 | | | | CBOR_Payload : "5678" 2804 | | | | } 2805 | | | | 2806 | | | | 2807 | |<------+ | Token: 0x02 2808 | | 2.05 | | Observe: 54123 2809 | | | | OSCORE: {kid: 5; piv: 502 ; 2810 | | | | kid context: 57ab2e; ...} 2811 | | | | 2812 | | | | 0xff 2813 | | | | Encrypted_payload { 2814 | | | | 2.05 (Content), 2815 | | | | Observe: 11, 2816 | | | | Content-Format: application/cbor, 2817 | | | | , 2818 | | | | 0xff, 2819 | | | | CBOR_Payload : "5678" 2820 | | | | } 2821 | | | | 2823 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 2824 with Group OSCORE end-to-end between the server and the clients. 2826 Acknowledgments 2828 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 2829 Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander 2830 for their comments and feedback. 2832 The work on this document has been partly supported by VINNOVA and 2833 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 2834 (Grant agreement 952652). 2836 Authors' Addresses 2837 Marco Tiloca 2838 RISE AB 2839 Isafjordsgatan 22 2840 Kista SE-16440 Stockholm 2841 Sweden 2843 Email: marco.tiloca@ri.se 2845 Rikard Hoeglund 2846 RISE AB 2847 Isafjordsgatan 22 2848 Kista SE-16440 Stockholm 2849 Sweden 2851 Email: rikard.hoglund@ri.se 2853 Christian Amsuess 2854 Hollandstr. 12/4 2855 Vienna 1020 2856 Austria 2858 Email: christian@amsuess.com 2860 Francesca Palombini 2861 Ericsson AB 2862 Torshamnsgatan 23 2863 Kista SE-16440 Stockholm 2864 Sweden 2866 Email: francesca.palombini@ericsson.com