idnits 2.17.1 draft-ietf-core-observe-multicast-notifications-02.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2369): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-12 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-13 ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == 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 (-15) exists of draft-ietf-core-href-06 == Outdated reference: A later version (-09) exists of draft-ietf-cose-cbor-encoded-cert-02 == Outdated reference: A later version (-09) exists of draft-ietf-rats-uccs-01 == Outdated reference: A later version (-07) exists of draft-tiloca-core-oscore-capable-proxies-01 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-10 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 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. Höglund 4 Updates: 7252, 7641 (if approved) RISE AB 5 Intended status: Standards Track C. Amsüss 6 Expires: 28 April 2022 7 F. Palombini 8 Ericsson AB 9 25 October 2021 11 Observe Notifications as CoAP Multicast Responses 12 draft-ietf-core-observe-multicast-notifications-02 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 addressed to all the clients 21 observing a same target resource. This document updates RFC7252 and 22 RFC7641, and defines how a server sends observe notifications as 23 response messages over multicast, synchronizing all the observers of 24 a same resource on a same shared Token value. Besides, this document 25 defines how Group OSCORE can be used to protect multicast 26 notifications end-to-end between the server and the observer clients. 28 Discussion Venues 30 This note is to be removed before publishing as an RFC. 32 Discussion of this document takes place on the Constrained RESTful 33 Environments Working Group mailing list (core@ietf.org), which is 34 archived at https://mailarchive.ietf.org/arch/browse/core/. 36 Source for this draft and an issue tracker can be found at 37 https://github.com/core-wg/observe-multicast-notifications. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 28 April 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 6 75 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 77 2.2.1. Encoding of Transport-Specific Message Information . 9 78 2.2.2. Encoding of Transport-Independent Message 79 Information . . . . . . . . . . . . . . . . . . . . . 12 80 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 13 81 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 14 82 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 14 83 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 15 84 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 3.2. Informative Response . . . . . . . . . . . . . . . . . . 15 86 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 87 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 17 88 4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6. Rough Counting of Clients in the Group Observation . . . . . 20 91 6.1. Multicast-Response-Feedback-Divider Option . . . . . . . 20 92 6.2. Processing on the Client Side . . . . . . . . . . . . . . 21 93 6.3. Processing on the Server Side . . . . . . . . . . . . . . 22 94 6.3.1. Request for Feedback . . . . . . . . . . . . . . . . 22 95 6.3.2. Collection of Feedback . . . . . . . . . . . . . . . 23 96 6.3.3. Processing of Feedback . . . . . . . . . . . . . . . 23 98 7. Protection of Multicast Notifications with Group OSCORE . . . 25 99 7.1. Signaling the OSCORE Group in the Informative Response . 26 100 7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 28 101 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 28 102 7.2.2. Informative Response . . . . . . . . . . . . . . . . 29 103 7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 29 104 7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 30 105 7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 30 106 7.3.1. Informative Response . . . . . . . . . . . . . . . . 30 107 7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 31 108 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 32 109 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 36 110 10. Intermediaries Together with End-to-End Security . . . . . . 37 111 10.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 38 112 10.2. Message Processing . . . . . . . . . . . . . . . . . . . 39 113 11. Informative Response Parameters . . . . . . . . . . . . . . . 41 114 12. Transport Protocol Information . . . . . . . . . . . . . . . 42 115 13. Security Considerations . . . . . . . . . . . . . . . . . . . 42 116 13.1. Unsecured Multicast Notifications . . . . . . . . . . . 42 117 13.2. Secured Multicast Notifications . . . . . . . . . . . . 43 118 13.3. Listen-To-Multicast-Responses Option . . . . . . . . . . 43 119 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 120 14.1. Media Type Registrations . . . . . . . . . . . . . . . . 44 121 14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 45 122 14.3. CoAP Option Numbers Registry . . . . . . . . . . . . . . 46 123 14.4. Informative Response Parameters Registry . . . . . . . . 46 124 14.5. CoAP Transport Information Registry . . . . . . . . . . 47 125 14.6. Expert Review Instructions . . . . . . . . . . . . . . . 47 126 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 127 15.1. Normative References . . . . . . . . . . . . . . . . . . 48 128 15.2. Informative References . . . . . . . . . . . . . . . . . 50 129 Appendix A. Different Sources for Group Observation Data . . . . 53 130 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 53 131 A.2. Introspection at the Multicast Notification Sender . . . 54 132 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 55 133 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 55 134 B.2. Client Side - Optimized Version . . . . . . . . . . . . . 56 135 B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 57 136 Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 59 137 Appendix D. Phantom Request as Deterministic Request . . . . . . 62 138 Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 63 139 Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 65 140 Appendix G. Example with a Proxy and Deterministic Requests . . 71 141 G.1. Assumptions and Walkthrough . . . . . . . . . . . . . . . 71 142 G.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 73 143 Appendix H. Document Updates . . . . . . . . . . . . . . . . . . 78 144 H.1. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 78 145 H.2. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 78 147 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 79 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 150 1. Introduction 152 The Constrained Application Protocol (CoAP) [RFC7252] has been 153 extended with a number of mechanisms, including resource Observation 154 [RFC7641]. This enables CoAP clients to register at a CoAP server as 155 "observers" of a resource, and hence being automatically notified 156 with an unsolicited response upon changes of the resource state. 158 CoAP supports group communication over IP multicast 159 [I-D.ietf-core-groupcomm-bis]. This includes support for Observe 160 registration requests over multicast, in order for clients to 161 efficiently register as observers of a resource hosted at multiple 162 servers. 164 However, in a number of use cases, using multicast messages for 165 responses would also be desirable. That is, it would be useful that 166 a server sends observe notifications for a same target resource to 167 multiple observers as responses over IP multicast. 169 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 170 multiple clients can subscribe to a topic, by observing the related 171 resource hosted at the responsible broker. When a new value is 172 published on that topic, it would be convenient for the broker to 173 send a single multicast notification at once, to all the subscriber 174 clients observing that topic. 176 A different use case concerns clients observing a same registration 177 resource at the CoRE Resource Directory 178 [I-D.ietf-core-resource-directory]. For example, multiple clients 179 can benefit of observation for discovering (to-be-created) OSCORE 180 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 181 Resource Directory updated links and descriptions to join them 182 through the respective Group Manager 183 [I-D.tiloca-core-oscore-discovery]. 185 More in general, multicast notifications would be beneficial whenever 186 several CoAP clients observe a same target resource at a CoAP server, 187 and can be all notified at once by means of a single response 188 message. However, CoAP does not currently define response messages 189 over IP multicast. This document fills this gap and provides the 190 following twofold contribution. 192 First, it updates [RFC7252] and [RFC7641], by defining a method to 193 deliver Observe notifications as CoAP responses addressed to multiple 194 clients, e.g., over IP multicast. In the proposed method, the group 195 of potential observers entrusts the server to manage the Token space 196 for multicast notifications. By doing so, the server provides all 197 the observers of a target resource with the same Token value to bind 198 to their own observation. That Token value is then used in every 199 multicast notification for the target resource. This is achieved by 200 means of an informative unicast response sent by the server to each 201 observer client. 203 Second, this document defines how to use Group OSCORE 204 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 205 end-to-end between the server and the observer clients. This is also 206 achieved by means of the informative unicast response mentioned 207 above, which additionally includes parameter values used by the 208 server to protect every multicast notification for the target 209 resource by using Group OSCORE. This provides a secure binding 210 between each of such notifications and the observation of each of the 211 clients. 213 1.1. Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 Readers are expected to be familiar with terms and concepts described 222 in CoAP [RFC7252], group communication for CoAP 223 [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949], 224 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 226 This document additionally defines the following terminology. 228 * Traditional observation. A resource observation associated to a 229 single observer client, as defined in [RFC7641]. 231 * Group observation. A resource observation associated to a group 232 of clients. The server sends notifications for the group-observed 233 resource over IP multicast to all the observer clients. 235 * Phantom request. The CoAP request message that the server would 236 have received to start or cancel a group observation on one of its 237 resources. A phantom request is generated inside the server and 238 does not hit the wire. 240 * Informative response. A CoAP response message that the server 241 sends to a given client via unicast, providing the client with 242 information on a group observation. 244 2. Server-Side Requirements 246 The server can, at any time, start a group observation on one of its 247 resources. Practically, the server may want to do that under the 248 following circumstances. 250 * In the absence of observations for the target resource, the server 251 receives a registration request from a first client wishing to 252 start a traditional observation on that resource. 254 * When a certain amount of traditional observations has been 255 established on the target resource, the server decides to make 256 those clients part of a group observation on that resource. 258 The server maintains an observer counter for each group observation 259 to a target resource, as a rough estimation of the observers actively 260 taking part in the group observation. 262 The server initializes the counter to 0 when starting the group 263 observation, and increments it after a new client starts taking part 264 in that group observation. Also, the server should keep the counter 265 up-to-date over time, for instance by using the method described in 266 Section 6. This allows the server to possibly terminate a group 267 observation in case, at some point in time, not enough clients are 268 estimated to be still active and interested. 270 This document does not describe a way for the client to influence the 271 server's decision to start group observations. That is done on 272 purpose: the specified mechanism is expected to be used in situations 273 where sending individual notifications is not feasible, or not 274 preferred beyond a certain number of clients observing a target 275 resource. If applications arise where negotiation does make sense, 276 they are welcome to specify additional means to opt in to multicast 277 notifications. 279 2.1. Request 281 Assuming it is reachable at the address SRV_ADDR and port number 282 SRV_PORT, the server starts a group observation on one of its 283 resources as defined below. The server intends to send multicast 284 notifications for the target resource to the multicast IP address 285 GRP_ADDR and port number GRP_PORT. 287 1. The server builds a phantom observation request, i.e., a GET 288 request with an Observe option set to 0 (register). 290 2. The server selects an available value T, from the Token space of 291 a CoAP endpoint used for messages having: 293 * As source address and port number, the IP multicast address 294 GRP_ADDR and port number GRP_PORT. 296 * As destination address and port number, the server address 297 SRV_ADDR and port number SRV_PORT, intended for accessing the 298 target resource. 300 This Token space is under exclusive control of the server. 302 3. The server processes the phantom observation request above, 303 without transmitting it on the wire. The request is addressed to 304 the resource for which the server wants to start the group 305 observation, as if sent by the group of observers, i.e., with 306 GRP_ADDR as source address and GRP_PORT as source port. 308 4. Upon processing the self-generated phantom registration request, 309 the server interprets it as an observe registration received from 310 the group of potential observer clients. In particular, from 311 then on, the server MUST use T as its own local Token value 312 associated to that observation, with respect to the (previous hop 313 towards the) clients. 315 5. The server does not immediately respond to the phantom 316 observation request with a multicast notification sent on the 317 wire. The server stores the phantom observation request as is, 318 throughout the lifetime of the group observation. 320 6. The server builds a CoAP response message INIT_NOTIF as initial 321 multicast notification for the target resource, in response to 322 the phantom observation request. This message is formatted as 323 other multicast notifications (see Section 2.3) and MUST include 324 the current representation of the target resource as payload. 325 The server stores the message INIT_NOTIF and does not transmit 326 it. The server considers this message as the latest multicast 327 notification for the target resource, until it transmits a new 328 multicast notification for that resource as a CoAP message on the 329 wire. After that, the server deletes the message INIT_NOTIF. 331 2.2. Informative Response 333 After having started a group observation on a target resource, the 334 server proceeds as follows. 336 For each traditional observation ongoing on the target resource, the 337 server MAY cancel that observation. Then, the server considers the 338 corresponding clients as now taking part in the group observation, 339 for which it increases the corresponding observer counter 340 accordingly. 342 The server sends to each of such clients an informative response 343 message, encoded as a unicast response with response code 5.03 344 (Service Unavailable). As per [RFC7641], such a response does not 345 include an Observe option. The response MUST be Confirmable and MUST 346 NOT encode link-local addresses. 348 The Content-Format of the informative response is set to application/ 349 informative-response+cbor, defined in Section 14.2. The payload of 350 the informative response is a CBOR map including the following 351 parameters, whose CBOR labels are defined in Section 11. 353 * 'tp_info', with value a CBOR array. This includes the transport- 354 specific information required to correctly receive multicast 355 notifications bound to the phantom observation request. The CBOR 356 array is formatted as defined in Section 2.2.1. This parameter 357 MUST be included. 359 * 'ph_req', with value the byte serialization of the transport- 360 independent information of the phantom observation request (see 361 Section 2.1), encoded as a CBOR byte string. The value of the 362 CBOR byte string is formatted as defined in Section 2.2.2. 364 This parameter MAY be omitted, in case the phantom request is, in 365 terms of transport-independent information, identical to the 366 registration request from the client. Otherwise, this parameter 367 MUST be included. 369 Note that the registration request from the client may indeed 370 differ from the phantom observation request in terms of transport- 371 independent information, but still be acceptable for the server to 372 register the client as taking part in the group observation. 374 * 'last_notif', with value the byte serialization of the transport- 375 independent information of the latest multicast notification for 376 the target resource, encoded as a CBOR byte string. The value of 377 the CBOR byte string is formatted as defined in Section 2.2.2. 378 This parameter MAY be included. 380 * 'next_not_before', with value the amount of seconds that will 381 minimally elapse before the server sends the next multicast 382 notification for the group observation of the target resource, 383 encoded as a CBOR unsigned integer. This parameter MAY be 384 included. 386 This information can help a new client to align itself with the 387 server's timeline, especially in scenarios where multicast 388 notifications are regularly sent. Also, it can help synchronizing 389 different clients when orchestrating a content distribution 390 through multicast notifications. 392 The CDDL notation [RFC8610] provided below describes the payload of 393 the informative response. 395 informative_response_payload = { 396 0 => array, ; 'tp_info', i.e., transport-specific information 397 ? 1 => bstr, ; 'ph_req' (transport-independent information) 398 ? 2 => bstr ; 'last_notif' (transport-independent information) 399 ? 3 => uint ; 'next_not_before' 400 } 402 Figure 1: Format of the informative response payload 404 Upon receiving a registration request to observe the target resource, 405 the server does not create a corresponding individual observation for 406 the requesting client. Instead, the server considers that client as 407 now taking part in the group observation of the target resource, of 408 which it increments the observer counter by 1. Then, the server 409 replies to the client with the same informative response message 410 defined above, which MUST be Confirmable. 412 Note that this also applies when, with no ongoing traditional 413 observations on the target resource, the server receives a 414 registration request from a first client and decides to start a group 415 observation on the target resource. 417 2.2.1. Encoding of Transport-Specific Message Information 419 [ This encoding might be replaced by CRIs [I-D.ietf-core-href] in a 420 later version of this document. ] 422 The CBOR array specified in the 'tp_info' parameter is formatted 423 according to the following CDDL notation. 425 tp_info = [ 426 srv_addr ; Addressing information of the server 427 ? req_info ; Request data extension 428 ] 430 srv_addr = ( 431 tp_id : int, ; Identifier of the used transport protocol 432 + elements ; Number, format and encoding 433 ; based on the value of 'tp_id' 434 ) 436 req_info = ( 437 + elements ; Number, format and encoding based on 438 ; the value of 'tp_id' in 'srv_addr' 439 ) 441 Figure 2: General format of 'tp_info' 443 The 'srv_addr' element of 'tp_info' specifies the addressing 444 information of the server, and includes at least one element 'tp_id' 445 which is formatted as follows. 447 * 'tp_id' : this element is a CBOR integer, which specifies the 448 transport protocol used to transport the CoAP response from the 449 server, i.e., a multicast notification in this document. 451 This element takes value from the "Value" column of the "CoAP 452 Transport Information" registry defined in Section 14.5 of this 453 document. This element MUST be present. The value of this 454 element determines: 456 - How many elements are required to follow in 'srv_addr', as well 457 as what information they convey, their encoding and their 458 semantics. 460 - How many elements are required in the 'req_info' element of the 461 'tp_info' array, as well as what information they convey, their 462 encoding and their semantics. 464 This document registers the integer value 1 ("UDP") to be used as 465 value for the 'tp_id' element, when CoAP responses are transported 466 over UDP. In such a case, the full encoding of the 'tp_info' CBOR 467 array is as defined in Section 2.2.1.1. 469 Future specifications that consider CoAP multicast notifications 470 transported over different transport protocols MUST: 472 - Register an entry with an integer value to be used for 'tp_id', 473 in the "CoAP Transport Information" registry defined in 474 Section 14.5 of this document. 476 - Accordingly, define the elements of the 'tp_info' CBOR array, 477 i.e., the elements following 'tp_id' in 'srv_addr' as well as 478 the elements in 'req_info', as to what information they convey, 479 their encoding and their semantics. 481 The 'req_info' element of 'tp_info' specifies transport-specific 482 information related to a pertinent request message, i.e., the phantom 483 observation request in this document. The exact format of 'req_info' 484 depends on the value of 'tp_id'. 486 Given a specific value of 'tp_id', the complete set of elements 487 composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is 488 indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP 489 Transport Information" registry defined in Section 14.5, 490 respectively. 492 2.2.1.1. UDP Transport-Specific Information 494 When CoAP multicast notifications are transported over UDP as per 495 [RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the 496 integer value 1 ("UDP") as value of 'tp_id' in the 'srv_addr' element 497 of the 'tp_info' CBOR array in the error informative response. Then, 498 the rest of the 'tp_info' CBOR array is defined as follows. 500 * 'srv_addr' includes two more elements following 'tp_id': 502 - 'srv_host': this element is a CBOR byte string, with value the 503 destination IP address of the phantom observation request. 504 This parameter is tagged and identified by the CBOR tag 260 505 "Network Address (IPv4 or IPv6 or MAC Address)". That is, the 506 value of the CBOR byte string is the IP address SRV_ADDR of the 507 server hosting the target resource, from where the server will 508 send multicast notifications for the target resource. This 509 element MUST be present. 511 - 'srv_port': this element is a CBOR unsigned integer, with value 512 the destination port number of the phantom observation request. 513 That is, the specified value is the port number SRV_PORT, from 514 where the server will send multicast notifications for the 515 target resource. This element MUST be present. 517 * 'req_info' includes the following elements: 519 - 'token': this element is a CBOR byte string, with value the 520 Token value of the phantom observation request generated by the 521 server (see Section 2.1). Note that the same Token value is 522 used for the multicast notifications bound to that phantom 523 observation request (see Section 2.3). This element MUST be 524 present. 526 - 'cli_addr': this element is a CBOR byte string, with value the 527 source IP address of the phantom observation request. This 528 parameter is tagged and identified by the CBOR tag 260 "Network 529 Address (IPv4 or IPv6 or MAC Address)". That is, the value of 530 the CBOR byte string is the IP multicast address GRP_ADDR, 531 where the server will send multicast notifications for the 532 target resource. This element MUST be present. 534 - 'cli_port': this element is a CBOR unsigned integer, with value 535 the source port number of the phantom observation request. 536 That is, the specified value is the port number GRP_PORT, where 537 the server will send multicast notifications for the target 538 resource. This element is OPTIONAL. If not included, the 539 default port number 5683 is assumed. 541 The CDDL notation provided below describes the full 'tp_info' CBOR 542 array using the format above. 544 tp_info = [ 545 tp_id : 1, ; UDP as transport protocol 546 srv_host : #6.260(bstr), ; Src. address of multicast notifications 547 srv_port : uint, ; Src. port of multicast notifications 548 token : bstr, ; Token of the phantom request and 549 ; associated multicast notifications 550 cli_addr : #6.260(bstr), ; Dst. address of multicast notifications 551 ? cli_port : uint ; Dst. port of multicast notifications 552 ] 554 Figure 3: Format of 'tp_info' with UDP as transport protocol 556 2.2.2. Encoding of Transport-Independent Message Information 558 For both the parameters 'ph_req' and 'last_notif' in the informative 559 response, the value of the byte string is the concatenation of the 560 following components, in the order specified below. 562 When defining the value of each component, "CoAP message" refers to 563 the phantom observation request for the 'ph_req' parameter, and to 564 the corresponding latest multicast notification for the 'last_notif' 565 parameter. 567 * A single byte, with value the content of the Code field in the 568 CoAP message. 570 * The byte serialization of the complete sequence of CoAP options in 571 the CoAP message. 573 * If the CoAP message includes a non-zero length payload, the one- 574 byte Payload Marker (0xff) followed by the payload. 576 2.3. Notifications 578 Upon a change in the status of the target resource under group 579 observation, the server sends a multicast notification, intended to 580 all the clients taking part in the group observation of that 581 resource. In particular, each of such multicast notifications is 582 formatted as follows. 584 * It MUST be Non-confirmable. 586 * It MUST include an Observe option, as per [RFC7641]. 588 * It MUST have the same Token value T of the phantom registration 589 request that started the group observation. This Token value is 590 specified in the 'token' element of 'req_info' under the 'tp_info' 591 parameter, in the informative response message sent to all the 592 observer clients. 594 That is, every multicast notification for a target resource is not 595 bound to the observation requests from the different clients, but 596 rather to the phantom registration request associated to the whole 597 set of clients taking part in the group observation of that 598 resource. 600 * It MUST be sent from the same IP address SRV_ADDR and port number 601 SRV_PORT where: i) the original Observe registration requests are 602 sent to by the clients; and ii) the corresponding informative 603 responses are sent from by the server (see Section 2.2). These 604 are indicated to the observer clients as value of the 'srv_host' 605 and 'srv_port' elements of 'srv_addr' under the 'tp_info' 606 parameter, in the informative response message (see 607 Section 2.2.1.1). That is, redirection MUST NOT be used. 609 * It MUST be sent to the IP multicast address GRP_ADDR and port 610 number GRP_PORT. These are indicated to the observer clients as 611 value of the 'cli_addr' and 'cli_port' elements of 'req_info' 612 under the 'tp_info' parameter, in the informative response message 613 (see Section 2.2.1.1). 615 For each target resource with an active group observation, the server 616 MUST store the latest multicast notification. 618 2.4. Congestion Control 620 In order to not cause congestion, the server should conservatively 621 control the sending of multicast notifications. In particular: 623 * The multicast notifications MUST be Non-confirmable. 625 * In constrained environments such as low-power, lossy networks 626 (LLNs), the server should only support multicast notifications for 627 resources that are small. Following related guidelines from 628 Section 3.6 of [I-D.ietf-core-groupcomm-bis], this can consist, 629 for example, in having the payload of multicast notifications as 630 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 631 size, so that it fits into a single link-layer frame in case IPv6 632 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 633 Section 4 of [RFC4944]) is used. 635 * The server SHOULD provide multicast notifications with the 636 smallest possible IP multicast scope that fulfills the application 637 needs. For example, following related guidelines from Section 3.6 638 of [I-D.ietf-core-groupcomm-bis], site-local scope is always 639 preferred over global scope IP multicast, if this fulfills the 640 application needs. Similarly, realm-local scope is always 641 preferred over site-local scope, if this fulfills the application 642 needs. Ultimately, it is up to the server administrator to 643 explicitly configure the most appropriate IP multicast scope. 645 * Following related guidelines from Section 4.5.1 of [RFC7641], the 646 server SHOULD NOT send more than one multicast notification every 647 3 seconds, and SHOULD use an even less aggressive rate when 648 possible (see also Section 3.1.2 of [RFC8085]). The transmission 649 rate of multicast notifications should also take into account the 650 avoidance of a possible "broadcast storm" problem [MOBICOM99]. 651 This prevents a following, considerable increase of the channel 652 load, whose origin would be likely attributed to a router rather 653 than the server. 655 2.5. Cancellation 657 At any point in time, the server may want to cancel a group 658 observation of a target resource. For instance, the server may 659 realize that no clients or not enough clients are interested in 660 taking part in the group observation anymore. A possible approach 661 that the server can use to assess this is defined in Section 6. 663 In order to cancel the group observation, the server sends a 664 multicast response with response code 5.03 (Service Unavailable), 665 signaling that the group observation has been terminated. The 666 response has the same Token value T of the phantom registration 667 request, it has no payload, and it does not include an Observe 668 option. 670 The server sends the response to the same multicast IP address 671 GRP_ADDR and port number GRP_PORT used to send the multicast 672 notifications related to the target resource. Finally, the server 673 releases the resources allocated for the group observation, and 674 especially frees up the Token value T used at its CoAP endpoint. 676 3. Client-Side Requirements 678 3.1. Request 680 A client sends an observation request to the server as described in 681 [RFC7641], i.e., a GET request with an Observe option set to 0 682 (register). The request MUST NOT encode link-local addresses. If 683 the server is not configured to accept registrations on that target 684 resource with a group observation, this would still result in a 685 positive notification response to the client as described in 686 [RFC7641]. 688 3.2. Informative Response 690 Upon receiving the informative response defined in Section 2.2, the 691 client proceeds as follows. 693 1. The client configures an observation of the target resource. To 694 this end, it relies on a CoAP endpoint used for messages having: 696 * As source address and port number, the server address SRV_ADDR 697 and port number SRV_PORT intended for accessing the target 698 resource. These are specified as value of the 'srv_host' and 699 'srv_port' elements of 'srv_addr' under the 'tp_info' 700 parameter, in the informative response (see Section 2.2.1.1). 702 * As destination address and port number, the IP multicast 703 address GRP_ADDR and port number GRP_PORT. These are 704 specified as value of the 'cli_addr' and 'cli_port' elements 705 of 'req_info' under the 'tp_info' parameter, in the 706 informative response (see Section 2.2.1.1). If the 'cli_port' 707 element is omitted in 'req_info', the client MUST assume the 708 default port number 5683 as GRP_PORT. 710 2. The client rebuilds the phantom registration request as follows. 712 * The client uses the Token value T, specified in the 'token' 713 element of 'req_info' under the 'tp_info' parameter of the 714 informative response. 716 * If the 'ph_req' parameter is not present in the informative 717 response, the client uses the transport-independent 718 information from its original Observe registration request. 720 * If the 'ph_req' parameter is present in the informative 721 response, the client uses the transport-independent 722 information specified in the parameter. 724 If such transport-independent information differs from the one 725 in the original Observe registration request, the client 726 checks whether a response to the rebuilt phantom request can, 727 if available in a cache entry, be used to satisfy the original 728 observation request. Unless this is the case, the client 729 SHOULD explicitly withdraw from the group observation. 731 3. The client stores the phantom registration request, as associated 732 to the observation of the target resource. In particular, the 733 client MUST use the Token value T of this phantom registration 734 request as its own local Token value associated to that group 735 observation, with respect to the server. The particular way to 736 achieve this is implementation specific. 738 4. If the informative response includes the parameter 'last_notif', 739 the client rebuilds the latest multicast notification, by using: 741 * The transport-independent information, specified in the 742 'last_notif' parameter of the informative response. 744 * The Token value T, specified in the 'token' element of 745 'req_info' under the 'tp_info' parameter of the informative 746 response. 748 5. If the informative response includes the parameter 'last_notif', 749 the client processes the multicast notification rebuilt in step 4 750 as defined in Section 3.2 of [RFC7641]. In particular, the value 751 of the Observe option is used as initial baseline for 752 notification reordering in this group observation. 754 6. If a traditional observation to the target resource is ongoing, 755 the client MAY silently cancel it without notifying the server. 757 If any of the expected fields in the informative response are not 758 present or malformed, the client MAY try sending a new registration 759 request to the server (see Section 3.1). Otherwise, the client 760 SHOULD explicitly withdraw from the group observation. 762 Appendix A describes possible alternative ways for clients to 763 retrieve the phantom registration request and other information 764 related to a group observation. 766 3.3. Notifications 768 After having successfully processed the informative response as 769 defined in Section 3.2, the client will receive, accept and process 770 multicast notifications about the state of the target resource from 771 the server, as responses to the phantom registration request and with 772 Token value T. 774 The client relies on the value of the Observe option for notification 775 reordering, as defined in Section 3.4 of [RFC7641]. 777 3.4. Cancellation 779 At a certain point in time, a client may become not interested in 780 receiving further multicast notifications about a target resource. 781 When this happens, the client can simply "forget" about being part of 782 the group observation for that target resource, as per Section 3.6 of 783 [RFC7641]. 785 When, later on, the server sends the next multicast notification, the 786 client will not recognize the Token value T in the message. Since 787 the multicast notification is Non-confirmable, it is OPTIONAL for the 788 client to reject the multicast notification with a Reset message, as 789 defined in Section 3.5 of [RFC7641]. 791 In case the server has canceled a group observation as defined in 792 Section 2.5, the client simply forgets about the group observation 793 and frees up the used Token value T for that endpoint, upon receiving 794 the multicast error response defined in Section 2.5. 796 4. Web Linking 798 The possible use of multicast notifications in a group observation 799 may be indicated by a target "grp_obs" attribute in a web link 800 [RFC8288] to a resource, e.g., using a link-format document 801 [RFC6690]. 803 The "grp_obs" attribute is a hint, indicating that the server might 804 send multicast notifications for observations of the resource 805 targeted by the link. Note that this is simply a hint, i.e., it does 806 not include any information required to participate in a group 807 observation, and to receive and process multicast notifications. 809 A value MUST NOT be given for the "grp_obs" attribute; any present 810 value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT 811 appear more than once in a given link-value; occurrences after the 812 first MUST be ignored by parsers. 814 The example in Figure 4 shows a use of the "grp_obs" attribute: the 815 client does resource discovery on a server and gets back a list of 816 resources, one of which includes the "grp_obs" attribute indicating 817 that the server might send multicast notifications for observations 818 of that resource. The link-format notation (see Section 5 of 819 [RFC6690]) is used. 821 REQ: GET /.well-known/core 823 RES: 2.05 Content 824 ;grp_obs, 825 ;if="sensor" 827 Figure 4: The Web Link 829 5. Example 831 The following example refers to two clients C_1 and C_2 that register 832 to observe a resource /r at a Server S, which has address SRV_ADDR 833 and listens to the port number SRV_PORT. Before the following 834 exchanges occur, no clients are observing the resource /r , which has 835 value "1234". 837 The server S sends multicast notifications to the IP multicast 838 address GRP_ADDR and port number GRP_PORT, and starts the group 839 observation upon receiving a registration request from a first client 840 that wishes to start a traditional observation on the resource /r. 842 The following notation is used for the payload of the informative 843 responses: 845 * 'bstr(X)' denotes a CBOR byte string with value the byte 846 serialization of X, with '|' denoting byte concatenation. 848 * 'OPT' denotes a sequence of CoAP options. This refers to the 849 phantom registration request encoded by the 'ph_req' parameter, or 850 to the corresponding latest multicast notification encoded by the 851 'last_notif' parameter. 853 * 'PAYLOAD' denotes a CoAP payload. This refers to the latest 854 multicast notification encoded by the 'last_notif' parameter. 856 C_1 ----------------- [ Unicast ] ------------------------> S /r 857 | GET | 858 | Token: 0x4a | 859 | Observe: 0 (Register) | 860 | | 861 | | 862 | (S allocates the available Token value 0x7b .) | 863 | | 864 | (S sends to itself a phantom observation request PH_REQ | 865 | as coming from the IP multicast address GRP_ADDR .) | 866 | ------------------------------------------------ | 867 | / | 868 | \----------------------------------------------------> | /r 869 | GET | 870 | Token: 0x7b | 871 | Observe: 0 (Register) | 872 | | 873 | | 874 | (S creates a group observation of /r .) | 875 | | 876 | (S increments the observer counter | 877 | for the group observation of /r .) | 878 | | 879 C_1 <-------------------- [ Unicast ] --------------------- S 880 | 5.03 | 881 | Token: 0x4a | 882 | Content-Format: application/informative-response+cbor | 883 | Max-Age: 0 | 884 | | 885 | Payload: { | 886 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 887 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 888 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 889 | } | 890 | | 891 C_2 ----------------- [ Unicast ] ------------------------> S /r 892 | GET | 893 | Token: 0x01 | 894 | Observe: 0 (Register) | 895 | | 896 | | 897 | (S increments the observer counter | 898 | for the group observation of /r .) | 899 | | 900 C_2 <-------------------- [ Unicast ] --------------------- S 901 | 5.03 | 902 | Token: 0x01 | 903 | Content-Format: application/informative-response+cbor | 904 | Max-Age: 0 | 905 | | 906 | Payload: { | 907 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 908 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 909 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 910 | } | 911 | | 912 | (The value of the resource /r changes to "5678".) | 913 | | 914 C_1 | 915 + <------------------- [ Multicast ] -------------------- S 916 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 917 | 2.05 | 918 | Token: 0x7b | 919 | Observe: 11 | 920 | Content-Format: application/cbor | 921 | | 922 | Payload: : "5678" | 923 | | 925 Figure 5: Example of group observation 927 6. Rough Counting of Clients in the Group Observation 929 This section specifies a method that the server can use to keep an 930 estimate of still active and interested clients, without creating 931 undue traffic on the network. 933 6.1. Multicast-Response-Feedback-Divider Option 935 In order to enable the rough counting of still active and interested 936 clients, a new CoAP option is introduced, which SHOULD be supported 937 by clients that listen to multicast responses. 939 The option is called Multicast-Response-Feedback-Divider. As 940 summarized in Figure 6, the option is not Critical, not Safe-to- 941 Forward, and integer valued. Since the option is not Safe-to- 942 Forward, the column "N" indicates a dash for "not applicable". 944 +-----+---+---+---+---+---------------------+--------+------+---------+ 945 | No. | C | U | N | R | Name | Format | Len. | Default | 946 +-----+---+---+---+---+---------------------+--------+------+---------+ 947 | TBD | | x | - | | Multicast-Response- | uint | 0-1 | (none) | 948 | | | | | | Feedback-Divider | | | | 949 +-----+---+---+---+---+---------------------+--------+------+---------+ 951 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 953 Figure 6: Multicast-Response-Feedback-Divider 955 The Multicast-Response-Feedback-Divider option is of class E for 956 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 958 6.2. Processing on the Client Side 960 Upon receiving a response with a Multicast-Response-Feedback-Divider 961 option, a client SHOULD acknowledge its interest in continuing 962 receiving multicast notifications for the target resource, as 963 described below. 965 The client picks an integer random number I, from 0 inclusive to the 966 number Z = (2 ** Q) exclusive, where Q is the value specified in the 967 option and "**" is the exponentiation operator. If I is different 968 than 0, the client takes no further action. Otherwise, the client 969 should wait a random fraction of the Leisure time (see Section 8.2 of 970 [RFC7252]), and then registers a regular unicast observation on the 971 same target resource. 973 To this end, the client essentially follows the steps that got it 974 originally subscribed to group notifications for the target resource. 975 In particular, the client sends an observation request to the server, 976 i.e., a GET request with an Observe option set to 0 (register). The 977 request MUST be addressed to the same target resource, and MUST have 978 the same destination IP address and port number used for the original 979 registration request, regardless the source IP address and port 980 number of the received multicast notification. 982 Since the Observe registration is only done for its side effect of 983 showing as an attempted observation at the server, the client MUST 984 send the unicast request in a non confirmable way, and with the 985 maximum No-Response setting [RFC7967]. In the request, the client 986 MUST include a Multicast-Response-Feedback-Divider option, whose 987 value MUST be empty (Option Length = 0). The client does not need to 988 wait for responses, and can keep processing further notifications on 989 the same Token. 991 The client MUST ignore the Multicast-Response-Feedback-Divider 992 option, if the multicast notification is retrieved from the 993 'last_notif' parameter of an informative response (see Section 2.2). 994 A client includes the Multicast-Response-Feedback-Divider option only 995 in a re-registration request triggered by the server as described 996 above, and MUST NOT include it in any other request. 998 As the Multicast-Response-Feedback-Divider option is unsafe to 999 forward, a proxy needs to answer it on its own, and is later counted 1000 as a single client. 1002 Appendix B.1 and Appendix B.2 provide a description in pseudo-code of 1003 the operations above performed by the client. 1005 6.3. Processing on the Server Side 1007 In order to avoid needless use of network resources, a server SHOULD 1008 keep a rough, updated count of the number of clients taking part in 1009 the group observation of a target resource. To this end, the server 1010 updates the value COUNT of the associated observer counter (see 1011 Section 2), for instance by using the method described below. 1013 6.3.1. Request for Feedback 1015 When it wants to obtain a new estimated count, the server considers a 1016 number M of confirmations it would like to receive from the clients. 1017 It is up to applications to define policies about how the server 1018 determines and possibly adjusts the value of M. 1020 Then, the server computes the value Q = max(L, 0), where: 1022 * L is computed as L = ceil(log2(N / M)). 1024 * N is the current value of the observer counter, possibly rounded 1025 up to 1, i.e., N = max(COUNT, 1). 1027 Finally, the server sets Q as the value of the Multicast-Response- 1028 Feedback-Divider option, which is sent within a successful multicast 1029 notification. 1031 If several multicast notifications are sent in a burst fashion, it is 1032 RECOMMENDED for the server to include the Multicast-Response- 1033 Feedback-Divider option only in the first one of those notifications. 1035 6.3.2. Collection of Feedback 1037 The server collects unicast observation requests from the clients, 1038 for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this 1039 time, the server regularly increments the observer counter when 1040 adding a new client to the group observation (see Section 2.2). 1042 It is up to applications to define the value of 1043 MAX_CONFIRMATION_WAIT, which has to take into account the 1044 transmission time of the multicast notification and of unicast 1045 observation requests, as well as the leisure time of the clients, 1046 which may be hard to know or estimate for the server. 1048 If this information is not known to the server, it is recommended to 1049 define MAX_CONFIRMATION_WAIT as follows. 1051 MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY 1053 where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has 1054 default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is 1055 equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 3.1.5 of 1056 [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In 1057 the absence of more specific information, the server can thus 1058 consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. 1060 If more information is available in deployments, a much shorter 1061 MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic 1062 round trip time (replacing MAX_RTT) and on the largest leisure time 1063 configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g., 1064 DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to 1065 a few seconds. 1067 6.3.3. Processing of Feedback 1069 Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the 1070 R confirmations arrived as unicast observation requests to the target 1071 resource, since the multicast notification with the Multicast- 1072 Response-Feedback-Divider option has been sent. In particular, the 1073 server considers a unicast observation request as a confirmation from 1074 a client only if it includes a Multicast-Response-Feedback-Divider 1075 option with an empty value (Option Length = 0). 1077 Then, the server computes a feedback indicator as E = R * (2 ** Q), 1078 where "**" is the exponentiation operator. According to what defined 1079 by application policies, the server determines the next time when to 1080 ask clients for their confirmation, e.g., after a certain number of 1081 multicast notifications has been sent. For example, the decision can 1082 be influenced by the reception of no confirmations from the clients, 1083 i.e., R = 0, or by the value of the ratios (E/N) and (N/E). 1085 Finally, the server computes a new estimated count of the observers. 1086 To this end, the server first consider COUNT' as the current value of 1087 the observer counter at this point in time. Note that COUNT' may be 1088 greater than the value COUNT used at the beginning of this process, 1089 if the server has incremented the observer counter upon adding new 1090 clients to the group observation (see Section 2.2). 1092 In particular, the server computes the new estimated count value as 1093 COUNT' + ((E - N) / D), where D > 0 is an integer value used as 1094 dampener. This step has to be performed atomically. That is, until 1095 this step is completed, the server MUST hold the processing of an 1096 observation request for the same target resource from a new client. 1097 Finally, the server considers the result as the current observer 1098 counter, and assesses it for possibly canceling the group observation 1099 (see Section 2.5). 1101 This estimate is skewed by packet loss, but it gives the server a 1102 sufficiently good estimation for further counts and for deciding when 1103 to cancel the group observation. It is up to applications to define 1104 policies about how the server takes the newly updated estimate into 1105 account and determines whether to cancel the group observation. 1107 As an example, if the server currently estimates that N = COUNT = 32 1108 observers are active and considers a constant M = 8, it sends out a 1109 notification with Multicast-Response-Feedback-Divider: 2. Then, out 1110 of 18 actually active clients, 5 send a re-registration request based 1111 on their random draw, of which one request gets lost, thus leaving 4 1112 re-registration requests received by the server. Also, no new 1113 clients have been added to the group observation during this time, 1114 i.e., COUNT' is equal to COUNT. As a consequence, assuming that a 1115 dampener value D = 1 is used, the server computes the new estimated 1116 count value as 32 + (16 - 32) = 16, and keeps the group observation 1117 active. 1119 To produce a most accurate updated counter, a server can include a 1120 Multicast-Response-Feedback-Divider option with value Q = 0 in its 1121 multicast notifications, as if M is equal to N. This will trigger 1122 all the active clients to state their interest in continuing 1123 receiving notifications for the target resource. Thus, the amount R 1124 of arrived confirmations is affected only by possible packet loss. 1126 Appendix B.3 provides a description in pseudo-code of the operations 1127 above performed by the server, including example behaviors for 1128 scheduling the next count update and deciding whether to cancel the 1129 group observation. 1131 7. Protection of Multicast Notifications with Group OSCORE 1133 A server can protect multicast notifications by using Group OSCORE 1134 [I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected 1135 end-to-end with the observer clients. This requires that both the 1136 server and the clients interested in receiving multicast 1137 notifications from that server are members of the same OSCORE group. 1139 In some settings, the OSCORE group to refer to can be pre-configured 1140 on the clients and the server. In such a case, a server which is 1141 aware of such pre-configuration can simply assume a client to be 1142 already member of the correct OSCORE group. 1144 In any other case, the server MAY communicate to clients what OSCORE 1145 group they are required to join, by providing additional guidance in 1146 the informative response as described in Section 7.1. Note that 1147 clients can already be members of the right OSCORE group, in case 1148 they have previously joined it to securely communicate with the same 1149 server and/or with other servers to access their resources. 1151 Both the clients and the server MAY join the OSCORE group by using 1152 the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and 1153 based on the ACE framework for Authentication and Authorization in 1154 constrained environments [I-D.ietf-ace-oauth-authz]. Further details 1155 on how to discover the OSCORE group and join it are out of the scope 1156 of this document. 1158 If multicast notifications are protected using Group OSCORE, the 1159 original registration requests and related unicast (notification) 1160 responses MUST also be secured, including and especially the 1161 informative responses from the server. 1163 To this end, alternative security protocols than Group OSCORE, such 1164 as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can 1165 be used to protect other exchanges via unicast between the server and 1166 each client, including the original client registration (see 1167 Section 3). 1169 7.1. Signaling the OSCORE Group in the Informative Response 1171 This section describes a mechanism for the server to communicate to 1172 the client what OSCORE group to join in order to decrypt and verify 1173 the multicast notifications protected with Group OSCORE. The client 1174 MAY use the information provided by the server to start the ACE 1175 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 1176 This mechanism is OPTIONAL to support for the client and server. 1178 Additionally to what defined in Section 2, the CBOR map in the 1179 informative response payload contains the following fields, whose 1180 CBOR labels are defined in Section 11. 1182 * 'join_uri', with value the URI for joining the OSCORE group at the 1183 respective Group Manager, encoded as a CBOR text string. If the 1184 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 1185 for joining, this field specifically indicates the URI of the 1186 group-membership resource at the Group Manager. 1188 * 'sec_gp', with value the name of the OSCORE group, encoded as a 1189 CBOR text string. 1191 * Optionally, 'as_uri', with value the URI of the Authorization 1192 Server associated to the Group Manager for the OSCORE group, 1193 encoded as a CBOR text string. 1195 * Optionally, 'hkdf', with value the HKDF Algorithm used in the 1196 OSCORE group, encoded as a CBOR text string or integer. The value 1197 is taken from the 'Value' column of the "COSE Algorithms" registry 1198 [COSE.Algorithms]. 1200 * Optionally, 'pub_key_enc', with value the encoding of the public 1201 keys used in the OSCORE group, encoded as a CBOR integer. The 1202 value is taken from the 'Label' column of the "COSE Header 1203 Parameters" Registry [COSE.Header.Parameters]. Consistently with 1204 Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable values 1205 denote an encoding that MUST explicitly provide the full set of 1206 information related to the public key algorithm, including, e.g., 1207 the used elliptic curve (when applicable). 1209 At the time of writing this specification, acceptable public key 1210 encodings are CWTs [RFC8392], unprotected CWT claim sets 1211 [I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509 1212 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings 1213 may be available in the future, and would be acceptable to use as 1214 long as they comply with the criteria defined above. 1216 [ As to CWTs and unprotected CWT claim sets, there is a pending 1217 registration requested by draft-ietf-lake-edhoc. ] 1219 [ As to C509 certificates, there is a pending registration 1220 requested by draft-ietf-cose-cbor-encoded-cert. ] 1222 * Optionally, 'sign_enc_alg', with value the Signature Encryption 1223 Algorithm used in the OSCORE group to encrypt messages protected 1224 with the group mode, encoded as a CBOR text string or integer. 1225 The value is taken from the 'Value' column of the "COSE 1226 Algorithms" registry [COSE.Algorithms]. 1228 * Optionally, 'sign_alg', with value the Signature Algorithm used to 1229 sign messages in the OSCORE group, encoded as a CBOR text string 1230 or integer. The value is taken from the 'Value' column of the 1231 "COSE Algorithms" registry [COSE.Algorithms]. 1233 * Optionally, 'sign_params', encoded as a CBOR array and including 1234 the following two elements: 1236 - 'sign_alg_capab': a CBOR array, with the same format and value 1237 of the COSE capabilities array for the algorithm indicated in 1238 'sign_alg', as specified for that algorithm in the 1239 'Capabilities' column of the "COSE Algorithms" Registry 1240 [COSE.Algorithms]. 1242 - 'sign_key_type_capab': a CBOR array, with the same format and 1243 value of the COSE capabilities array for the COSE key type of 1244 the keys used with the algorithm indicated in 'sign_alg', as 1245 specified for that key type in the 'Capabilities' column of the 1246 "COSE Key Types" Registry [COSE.Key.Types]. 1248 The values of 'sign_alg', 'sign_params' and 'pub_key_enc' provide an 1249 early knowledge of the format and encoding of public keys used in the 1250 OSCORE group. Thus, the client does not need to ask the Group 1251 Manager for this information as a preliminary step before the (ACE) 1252 join process, or to perform a trial-and-error exchange with the Group 1253 Manager upon joining the group. Hence, the client is able to provide 1254 the Group Manager with its own public key in the correct expected 1255 format and encoding, at the very first step of the (ACE) join 1256 process. 1258 The values of 'hkdf', 'sign_enc_alg' and 'sign_alg' provide an early 1259 knowledge of the algorithms used in the OSCORE group. Thus, the 1260 client is able to decide whether to actually proceed with the (ACE) 1261 join process, depending on its support for the indicated algorithms. 1263 As mentioned above, since this mechanism is OPTIONAL, all the fields 1264 are OPTIONAL in the informative response. However, the 'join_uri' 1265 and 'sec_gp' fields MUST be present if the mechanism is implemented 1266 and used. If any of the fields are present without the 'join_uri' 1267 and 'sec_gp' fields present, the client MUST ignore these fields, 1268 since they would not be sufficient to start the (ACE) join procedure. 1269 When this happens, the client MAY try sending a new registration 1270 request to the server (see Section 3.1). Otherwise, the client 1271 SHOULD explicitly withdraw from the group observation. 1273 Appendix C describes a possible alternative approach, where the 1274 server self-manages the OSCORE group, and provides the observer 1275 clients with the necessary keying material in the informative 1276 response. The approach in Appendix C MUST NOT be used together with 1277 the mechanism defined in this section for indicating what OSCORE 1278 group to join. 1280 7.2. Server-Side Requirements 1282 When using Group OSCORE to protect multicast notifications, the 1283 server performs the operations described in Section 2, with the 1284 following differences. 1286 7.2.1. Registration 1288 The phantom registration request MUST be secured, by using Group 1289 OSCORE. In particular, the group mode of Group OSCORE defined in 1290 Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. 1292 The server protects the phantom registration request as defined in 1293 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the 1294 actual sender, i.e., by using its Sender Context. As a consequence, 1295 the server consumes the current value of its Sender Sequence Number 1296 SN in the OSCORE group, and hence updates it to SN* = (SN + 1). 1297 Consistently, the OSCORE option in the phantom registration request 1298 includes: 1300 * As 'kid', the Sender ID of the server in the OSCORE group. 1302 * As 'piv', the previously consumed Sender Sequence Number value SN 1303 of the server in the OSCORE group, i.e., (SN* - 1). 1305 7.2.2. Informative Response 1307 The value of the CBOR byte string in the 'ph_req' parameter encodes 1308 the phantom observation request as a message protected with Group 1309 OSCORE (see Section 7.2.1). As a consequence: the specified Code is 1310 always 0.05 (FETCH); the sequence of CoAP options will be limited to 1311 the outer, non encrypted options; a payload is always present, as the 1312 authenticated ciphertext followed by the signature. Note that, in 1313 terms of transport-independent information, the registration request 1314 from the client typically differs from the phantom request. Thus, 1315 the server has to include the 'ph_req' parameter in the informative 1316 response. An exception is the case discussed in Appendix D. 1318 Similarly, the value of the CBOR byte string in the 'last_notif' 1319 parameter encodes the latest multicast notification as a message 1320 protected with Group OSCORE (see Section 7.2.3). This applies also 1321 to the initial multicast notification INIT_NOTIF built in step 6 of 1322 Section 2.1. 1324 Optionally, the informative response includes information on the 1325 OSCORE group to join, as additional parameters (see Section 7.1). 1327 7.2.3. Notifications 1329 The server MUST protect every multicast notification for the target 1330 resource with Group OSCORE. In particular, the group mode of Group 1331 OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST 1332 be used. 1334 The process described in Section 8.3 of 1335 [I-D.ietf-core-oscore-groupcomm] applies, with the following 1336 additions when building the two OSCORE 'external_aad' to encrypt and 1337 sign the multicast notification (see Section 4.3 of 1338 [I-D.ietf-core-oscore-groupcomm]). 1340 * The 'request_kid' is the 'kid' value in the OSCORE option of the 1341 phantom registration request, i.e., the Sender ID of the server. 1343 * The 'request_piv' is the 'piv' value in the OSCORE option of the 1344 phantom registration request, i.e., the consumed Sender Sequence 1345 Number SN of the server. 1347 * The 'request_kid_context' is the 'kid context' value in the OSCORE 1348 option of the phantom registration request, i.e., the Group 1349 Identifier value (Gid) of the OSCORE group used as ID Context. 1351 Note that these same values are used to protect each and every 1352 multicast notification sent for the target resource under this group 1353 observation. 1355 7.2.4. Cancellation 1357 When canceling a group observation (see Section 2.5), the multicast 1358 response with error code 5.03 (Service Unavailable) is also protected 1359 with Group OSCORE, as per Section 8.3 of 1360 [I-D.ietf-core-oscore-groupcomm]. The server MUST use its own Sender 1361 Sequence Number as Partial IV to protect the error response, and 1362 include it as Partial IV in the OSCORE option of the response. 1364 7.3. Client-Side Requirements 1366 When using Group OSCORE to protect multicast notifications, the 1367 client performs as described in Section 3, with the following 1368 differences. 1370 7.3.1. Informative Response 1372 Upon receiving the informative response from the server, the client 1373 performs as described in Section 3.2, with the following additions. 1375 When performing step 2, the client expects the 'ph_req' parameter to 1376 be included in the informative response, which is otherwise 1377 considered malformed. An exception is the case discussed in 1378 Appendix D. 1380 Once completed step 2, the client decrypts and verifies the rebuilt 1381 phantom registration request as defined in Section 8.2 of 1382 [I-D.ietf-core-oscore-groupcomm], with the following differences. 1384 * The client MUST NOT perform any replay check. That is, the client 1385 skips step 3 in Section 8.2 of [RFC8613]. 1387 * If decryption and verification of the phantom registration request 1388 succeed: 1390 - The client MUST NOT update the Replay Window in the Recipient 1391 Context associated to the server. That is, the client skips 1392 the second bullet of step 6 in Section 8.2 of [RFC8613]. 1394 - The client MUST NOT take any further process as normally 1395 expected according to [RFC7252]. That is, the client skips 1396 step 8 in Section 8.2 of [RFC8613]. In particular, the client 1397 MUST NOT deliver the phantom registration request to the 1398 application, and MUST NOT take any action in the Token space of 1399 its unicast endpoint, where the informative response has been 1400 received. 1402 - The client stores the values of the 'kid', 'piv' and 'kid 1403 context' fields from the OSCORE option of the phantom 1404 registration request. 1406 * If decryption and verification of the phantom registration request 1407 fail, the client MAY try sending a new registration request to the 1408 server (see Section 3.1). Otherwise, the client SHOULD explicitly 1409 withdraw from the group observation. 1411 * If the informative response includes the parameter 'last_notif', 1412 the client also decrypts and verifies the latest multicast 1413 notification rebuilt in step 4, just like it would for the 1414 multicast notifications transmitted as CoAP messages on the wire 1415 (see Section 7.3.2). The client proceeds with step 5 if 1416 decryption and verification of the latest multicast notification 1417 succeed, or to step 6 otherwise. 1419 7.3.2. Notifications 1421 After having successfully processed the informative response as 1422 defined in Section 7.3.1, the client will decrypt and verify every 1423 multicast notification for the target resource as defined in 1424 Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following 1425 difference. 1427 For both decryption and signature verification, the client MUST set 1428 the 'external_aad' defined in Section 4.3 of 1429 [I-D.ietf-core-oscore-groupcomm] as follows. The particular way to 1430 achieve this is implementation specific. 1432 * 'request_kid' takes the value of the 'kid' field from the OSCORE 1433 option of the phantom registration request (see Section 7.3.1). 1435 * 'request_piv' takes the value of the 'piv' field from the OSCORE 1436 option of the phantom registration request (see Section 7.3.1). 1438 * 'request_kid_context' takes the value of the 'kid context' field 1439 from the OSCORE option of the phantom registration request (see 1440 Section 7.3.1). 1442 Note that these same values are used to decrypt and verify each and 1443 every multicast notification received for the target resource. 1445 The replay protection and checking of multicast notifications is 1446 performed as specified in Section 4.1.3.5.2 of [RFC8613]. 1448 8. Example with Group OSCORE 1450 The following example refers to two clients C_1 and C_2 that register 1451 to observe a resource /r at a Server S, which has address SRV_ADDR 1452 and listens to the port number SRV_PORT. Before the following 1453 exchanges occur, no clients are observing the resource /r , which has 1454 value "1234". 1456 The server S sends multicast notifications to the IP multicast 1457 address GRP_ADDR and port number GRP_PORT, and starts the group 1458 observation upon receiving a registration request from a first client 1459 that wishes to start a traditional observation on the resource /r. 1461 Pairwise communication over unicast is protected with OSCORE, while S 1462 protects multicast notifications with Group OSCORE. Specifically: 1464 * C_1 and S have a pairwise OSCORE Security Context. In particular, 1465 C_1 has 'kid' = 0x01 as Sender ID, and SN_1 = 101 as Sender 1466 Sequence Number. Also, S has 'kid' = 0x03 as Sender ID, and SN_3 1467 = 301 as Sender Sequence Number. 1469 * C_2 and S have a pairwise OSCORE Security Context. In particular, 1470 C_2 has 'kid' = 0x02 as Sender ID, and SN_2 = 201 as Sender 1471 Sequence Number. Also, S has 'kid' = 0x04 as Sender ID, and SN_4 1472 = 401 as Sender Sequence Number. 1474 * S is a member of the OSCORE group with name "myGroup", and 'kid 1475 context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' 1476 = 0x05 as Sender ID, and SN_5 = 501 as Sender Sequence Number. 1478 The following notation is used for the payload of the informative 1479 responses: 1481 * 'bstr(X)' denotes a CBOR byte string with value the byte 1482 serialization of X, with '|' denoting byte concatenation. 1484 * 'OPT' denotes a sequence of CoAP options. This refers to the 1485 phantom registration request encoded by the 'ph_req' parameter, or 1486 to the corresponding latest multicast notification encoded by the 1487 'last_notif' parameter. 1489 * 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the 1490 phantom registration request encoded by the 'ph_req' parameter, or 1491 to the corresponding latest multicast notification encoded by the 1492 'last_notif' parameter. 1494 * 'SIGN' denotes the signature appended to an encrypted CoAP 1495 payload. This refers to the phantom registration request encoded 1496 by the 'ph_req' parameter, or to the corresponding latest 1497 multicast notification encoded by the 'last_notif' parameter. 1499 C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1500 | 0.05 (FETCH) | 1501 | Token: 0x4a | 1502 | OSCORE: {kid: 0x01; piv: 101; ...} | 1503 | | 1504 | 0xff | 1505 | Encrypted_payload { | 1506 | 0x01 (GET), | 1507 | Observe: 0 (Register), | 1508 | | 1509 | } | 1510 | | 1511 | (S allocates the available Token value 0x7b .) | 1512 | | 1513 | (S sends to itself a phantom observation request PH_REQ | 1514 | as coming from the IP multicast address GRP_ADDR .) | 1515 | ------------------------------------------------------ | 1516 | / | 1517 | \-------------------------------------------------------> | /r 1518 | 0.05 (FETCH) | 1519 | Token: 0x7b | 1520 | OSCORE: {kid: 0x05 ; piv: 501; | 1521 | kid context: 0x57ab2e; ...} | 1522 | | 1523 | 0xff | 1524 | Encrypted_payload { | 1525 | 0x01 (GET), | 1526 | Observe: 0 (Register), | 1527 | | 1528 | } | 1529 | | 1530 | | 1531 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 1532 | | 1533 | (S creates a group observation of /r .) | 1534 | | 1535 | (S increments the observer counter | 1536 | for the group observation of /r .) | 1537 | | 1538 C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1539 | 2.05 (Content) | 1540 | Token: 0x4a | 1541 | OSCORE: {piv: 301; ...} | 1542 | Max-Age: 0 | 1543 | | 1544 | 0xff | 1545 | Encrypted_payload { | 1546 | 5.03 (Service Unavailable), | 1547 | Content-Format: application/informative-response+cbor, | 1548 | , | 1549 | 0xff, | 1550 | CBOR_payload { | 1551 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1552 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1553 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1554 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1555 | join_uri : "coap://myGM/ace-group/myGroup", | 1556 | sec_gp : "myGroup" | 1557 | } | 1558 | } | 1559 | | 1560 C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1561 | 0.05 (FETCH) | 1562 | Token: 0x01 | 1563 | OSCORE: {kid: 0x02; piv: 201; ...} | 1564 | | 1565 | 0xff | 1566 | Encrypted_payload { | 1567 | 0x01 (GET), | 1568 | Observe: 0 (Register), | 1569 | | 1570 | } | 1571 | | 1572 | (S increments the observer counter | 1573 | for the group observation of /r .) | 1574 | | 1575 C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1576 | 2.05 (Content) | 1577 | Token: 0x01 | 1578 | OSCORE: {piv: 401; ...} | 1579 | Max-Age: 0 | 1580 | | 1581 | 0xff, | 1582 | Encrypted_payload { | 1583 | 5.03 (Service Unavailable), | 1584 | Content-Format: application/informative-response+cbor, | 1585 | , | 1586 | 0xff, | 1587 | CBOR_payload { | 1588 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1589 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1590 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1591 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1592 | join_uri : "coap://myGM/ace-group/myGroup", | 1593 | sec_gp : "myGroup" | 1594 | } | 1595 | } | 1596 | | 1597 | (The value of the resource /r changes to "5678".) | 1598 | | 1599 C_1 | 1600 + <----------- [ Multicast w/ Group OSCORE ] ------------ S 1601 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 1602 | 2.05 (Content) | 1603 | Token: 0x7b | 1604 | OSCORE: {kid: 0x05; piv: 502; ...} | 1605 | | 1606 | 0xff | 1607 | Encrypted_payload { | 1608 | 2.05 (Content), | 1609 | Observe: [empty], | 1610 | Content-Format: application/cbor, | 1611 | , | 1612 | 0xff, | 1613 | CBOR_Payload: "5678" | 1614 | } | 1615 | | 1616 | | 1618 Figure 7: Example of group observation with Group OSCORE 1620 The two external_aad used to encrypt and sign the multicast 1621 notification above have 'request_kid' = 5, 'request_piv' = 501 and 1622 'request_kid_context' = 0x57ab2e. These values are specified in the 1623 'kid', 'piv' and 'kid context' field of the OSCORE option of the 1624 phantom observation request, which is encoded in the 'ph_req' 1625 parameter of the unicast informative response to the two clients. 1626 Thus, the two clients can build the two same external_aad for 1627 decrypting and verifying this multicast notification and the 1628 following ones. 1630 9. Intermediaries 1632 This section specifies how the approach presented in Section 2 and 1633 Section 3 works when a proxy is used between the clients and the 1634 server. In addition to what specified in Section 5.7 of [RFC7252] 1635 and Section 5 of [RFC7641], the following applies. 1637 A client sends its original observation request to the proxy. If the 1638 proxy is not already registered at the server for that target 1639 resource, the proxy forwards the observation request to the server, 1640 hence registering itself as an observer. If the server has an 1641 ongoing group observation for the target resource or decides to start 1642 one, the server considers the proxy as taking part in the group 1643 observation, and replies to the proxy with an informative response. 1645 Upon receiving an informative response, the proxy performs as 1646 specified for the client in Section 3, with the peculiarity that 1647 "consuming" the last notification (if present) means populating its 1648 cache. 1650 In particular, by using the information retrieved from the 1651 informative response, the proxy configures an observation of the 1652 target resource at the origin server, acting as a client directly 1653 taking part in the group observation. 1655 As a consequence, the proxy will listen to the IP multicast address 1656 and port number indicated by the server in the informative response, 1657 as 'cli_addr' and 'cli_port' element of 'req_info' under the 1658 'tp_info' parameter, respectively (see Section 2.2.1.1). 1659 Furthermore, multicast notifications will match the phantom request 1660 stored at the proxy, based on the Token value specified in the 1661 'token' element of 'req_info' under the 'tp_info' parameter in the 1662 informative response. 1664 Then, the proxy performs the following actions. 1666 * If the 'last_notif' field is not present, the proxy responds to 1667 the client with an Empty Acknowledgement (if indicated by the 1668 message type, and if it has not already done so). 1670 * If the 'last_notif' field is present, the proxy rebuilds the 1671 latest multicast notification, as defined in Section 3. Then, the 1672 proxy responds to the client, by forwarding back the latest 1673 multicast notification. 1675 When responding to an observation request from a client, the proxy 1676 also adds that client (and its Token) to the list of its registered 1677 observers for the target resource, next to the older observations. 1679 Upon receiving a multicast notification from the server, the proxy 1680 forwards it back separately to each observer client over unicast. 1681 Note that the notification forwarded back to a certain client has the 1682 same Token value of the original observation request sent by that 1683 client to the proxy. 1685 Note that the proxy configures the observation of the target resource 1686 at the server only once, when receiving the informative response 1687 associated to a (newly started) group observation for that target 1688 resource. 1690 After that, when receiving an observation request from a following 1691 new client to be added to the same group observation, the proxy does 1692 not take any further action with the server. Instead, the proxy 1693 responds to the client either with the latest multicast notification 1694 if available from its cache, or with an Empty Acknowledgement 1695 otherwise, as defined above. 1697 An example is provided in Appendix E. 1699 In the general case with a chain of two or more proxies, every proxy 1700 in the chain takes the role of client with the (next hop towards the) 1701 origin server. Note that the proxy adjacent to the origin server is 1702 the only one in the chain that receives informative responses and 1703 listens to an IP multicast address to receive notifications for the 1704 group observation. Furthermore, every proxy in the chain takes the 1705 role of server with the (previous hop towards the) origin client. 1707 10. Intermediaries Together with End-to-End Security 1709 As defined in Section 7, Group OSCORE can be used to protect 1710 multicast notifications end-to-end between the origin server and the 1711 clients. In such a case, additional actions are required when also 1712 the informative responses from the origin server are protected 1713 specifically end-to-end, by using OSCORE or Group OSCORE. 1715 In fact, the proxy adjacent to the origin server is not able to 1716 access the encrypted payload of such informative responses. Hence, 1717 the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters 1718 necessary to correctly receive multicast notifications and forward 1719 them back to the clients. 1721 Then, differently from what defined in Section 9, each proxy 1722 receiving an informative response simply forwards it back to the 1723 client that has sent the corresponding observation request. Note 1724 that the proxy does not even realize the message to be an actual 1725 informative response, since the outer Code field is set to 2.05 1726 (Content). 1728 Upon receiving the informative response, the client does not 1729 configure an observation of the target resource. Instead, the client 1730 performs a new observe registration request, by transmitting the re- 1731 built phantom request as intended to reach the proxy adjacent to the 1732 origin server. In particular, the client includes the new Listen-To- 1733 Multicast-Responses CoAP option defined in Section 10.1, to provide 1734 that proxy with the transport-specific information required for 1735 receiving multicast notifications for the group observation. 1737 Details on the additional message exchange and processing are defined 1738 in Section 10.2. 1740 10.1. Listen-To-Multicast-Responses Option 1742 In order to allow the proxy to listen to the multicast notifications 1743 sent by the server, a new CoAP option is introduced. This option 1744 MUST be supported by clients interested to take part in group 1745 observations through intermediaries, and by proxies that collect 1746 multicast notifications and forward them back to the observer 1747 clients. 1749 The option is called Listen-To-Multicast-Responses and is intended 1750 only for requests. As summarized in Figure 8, the option is critical 1751 and not Safe-to-Forward. Since the option is not Safe-to-Forward, 1752 the column "N" indicates a dash for "not applicable". 1754 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1755 | No. | C | U | N | R | Name | Format | Len. | Default | 1756 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1757 | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) | 1758 | | | | | | Multicast- | | | | 1759 | | | | | | Responses | | | | 1760 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1762 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 1763 (*) See below. 1765 Figure 8: Listen-To-Multicast-Responses 1767 The Listen-To-Multicast-Responses option includes the serialization 1768 of a CBOR array. This specifies transport-specific message 1769 information required for listening to the multicast notifications of 1770 a group observation, and intended to the proxy adjacent to the origin 1771 server sending those notifications. In particular, the serialized 1772 CBOR array has the same format specified in Section 2.2.1 for the 1773 'tp_info' parameter of the informative response (see Section 2.2). 1775 The Listen-To-Multicast-Responses option is of class U for OSCORE 1776 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1778 10.2. Message Processing 1780 Compared to Section 9, the following additions apply when informative 1781 responses are protected end-to-end between the origin server and the 1782 clients. 1784 After the origin server sends an informative response, each proxy 1785 simply forwards it back to the (previous hop towards the) origin 1786 client that has sent the observation request. 1788 Once received the informative response, the origin client proceeds in 1789 a different way than in Section 7.3.1: 1791 * The client performs all the additional decryption and verification 1792 steps of Section 7.3.1 on the phantom request specified in the 1793 'ph_req' parameter and on the last notification specified in the 1794 'last_notif' parameter (if present). 1796 * The client builds a ticket request (see Appendix B of 1797 [I-D.amsuess-core-cachable-oscore]), as intended to reach the 1798 proxy adjacent to the origin server. The ticket request is 1799 formatted as follows. 1801 - The Token is chosen as the client sees fit. In fact, there is 1802 no reason for this Token to be the same as the phantom 1803 request's. 1805 - The outer Code field, the outer CoAP options and the encrypted 1806 payload with AEAD tag (protecting the inner Code, the inner 1807 CoAP options and the possible plain CoAP payload) concatenated 1808 with the signature are the same of the phantom request used for 1809 the group observation. That is, they are as specified in the 1810 'ph_req' parameter of the received informative response. 1812 - An outer Observe option is included and set to 0 (Register). 1813 This will usually be set in the phantom request already. 1815 - The outer options Proxy-Scheme, Uri-Host and Uri-Port are 1816 included, and set to the same values they had in the original 1817 registration request sent by the client. 1819 - The new option Listen-To-Multicast-Responses is included as an 1820 outer option. The value is set to the serialization of the 1821 CBOR array specified by the 'tp_info' parameter of the 1822 informative response. 1824 Note that, except for transport-specific information such as 1825 the Token and Message ID values, every different client 1826 participating to the same group observation (hence rebuilding 1827 the same phantom request) will build the same ticket request. 1829 Note also that, identically to the phantom request, the ticket 1830 request is still protected with Group OSCORE, i.e., it has the 1831 same OSCORE option, encrypted payload and signature. 1833 Then, the client sends the ticket request to the next hop towards the 1834 origin server. Every proxy in the chain forwards the ticket request 1835 to the next hop towards the origin server, until the last proxy in 1836 the chain is reached. This last proxy, adjacent to the origin 1837 server, proceeds as follows. 1839 * The proxy MUST NOT further forward the ticket request to the 1840 origin server. 1842 * The proxy removes the Proxy-Scheme, Uri-Host and Uri-Port options 1843 from the ticket request. 1845 * The proxy removes the Listen-To-Multicast-Responses option from 1846 the ticket request, and extracts the conveyed transport-specific 1847 information. 1849 * The proxy rebuilds the phantom request associated to the group 1850 observation, by using the ticket request as directly providing the 1851 required transport-independent information. This includes the 1852 outer Code field, the outer CoAP options and the encrypted payload 1853 with AEAD tag concatenated with the signature. 1855 * The proxy configures an observation of the target resource at the 1856 origin server, acting as a client directly taking part in the 1857 group observation. To this end, the proxy uses the rebuilt 1858 phantom request and the transport-specific information retrieved 1859 from the Listen-To-Multicast-Responses Option. The particular way 1860 to achieve this is implementation specific. 1862 After that, the proxy will listen to the IP multicast address and 1863 port number indicated in the Listen-To-Multicast-Responses option, as 1864 'cli_addr' and 'cli_port' element of the serialized CBOR array, 1865 respectively. Furthermore, multicast notifications will match the 1866 phantom request stored at the proxy, based on the Token value 1867 specified in the 'token' element of the serialized CBOR array in the 1868 Listen-To-Multicast-Responses option. 1870 An example is provided in Appendix F. 1872 11. Informative Response Parameters 1874 This document defines a number of fields used in the informative 1875 response message defined in Section 2.2. 1877 The table below summarizes them and specifies the CBOR key to use 1878 instead of the full descriptive name. Note that the media type 1879 application/informative-response+cbor MUST be used when these fields 1880 are transported. 1882 +=================+==========+============+=============+ 1883 | Name | CBOR Key | CBOR Type | Reference | 1884 +=================+==========+============+=============+ 1885 | tp_info | 0 | array | Section 2.2 | 1886 +-----------------+----------+------------+-------------+ 1887 | ph_req | 1 | bstr | Section 2.2 | 1888 +-----------------+----------+------------+-------------+ 1889 | last_notif | 2 | bstr | Section 2.2 | 1890 +-----------------+----------+------------+-------------+ 1891 | next_not_before | 3 | uint | Section 2.2 | 1892 +-----------------+----------+------------+-------------+ 1893 | join_uri | 4 | tstr | Section 7.1 | 1894 +-----------------+----------+------------+-------------+ 1895 | sec_gp | 5 | tstr | Section 7.1 | 1896 +-----------------+----------+------------+-------------+ 1897 | as_uri | 6 | tstr | Section 7.1 | 1898 +-----------------+----------+------------+-------------+ 1899 | hkdf | 7 | int / tstr | Section 7.1 | 1900 +-----------------+----------+------------+-------------+ 1901 | pub_key_enc | 8 | int | Section 7.1 | 1902 +-----------------+----------+------------+-------------+ 1903 | sign_enc_alg | 9 | int / tstr | Section 7.1 | 1904 +-----------------+----------+------------+-------------+ 1905 | sign_alg | 10 | int / tstr | Section 7.1 | 1906 +-----------------+----------+------------+-------------+ 1907 | sign_params | 11 | array | Section 7.1 | 1908 +-----------------+----------+------------+-------------+ 1909 | gp_material | 12 | map | Appendix C | 1910 +-----------------+----------+------------+-------------+ 1911 | srv_pub_key | 13 | bstr | Appendix C | 1912 +-----------------+----------+------------+-------------+ 1913 | srv_identifier | 14 | bstr | Appendix C | 1914 +-----------------+----------+------------+-------------+ 1915 | exp | 15 | uint | Appendix C | 1916 +-----------------+----------+------------+-------------+ 1918 Table 1 1920 12. Transport Protocol Information 1922 This document defines some values of transport protocol identifiers 1923 to use within the 'tp_info' parameter of the informative response 1924 message defined in Section 2.2. 1926 According to the encoding specified in Section 2.2.1, these values 1927 are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' 1928 parameter. 1930 The table below summarizes them, specifies the integer value to use 1931 instead of the full descriptive name, and provides the corresponding 1932 full set of information elements to include in the 'tp_info' 1933 parameter. 1935 +-----------+-------------+-------+----------+-----------+-----------+ 1936 | Transport | Description | Value | Srv Addr | Req Info | Reference | 1937 | Protocol | | | | | | 1938 +-----------+-------------+-------+----------+-----------+-----------+ 1939 | Reserved | This value | 0 | | | [This | 1940 | | is reserved | | | | document] | 1941 | | | | | | | 1942 | UDP | UDP is used | 1 | tp_id | token | [This | 1943 | | as per | | srv_host | cli_host | document] | 1944 | | RFC7252 | | srv_port | ?cli_port | | 1945 +-----------+-------------+-------+----------+-----------+-----------+ 1947 Figure 9: Transport protocol information 1949 13. Security Considerations 1951 In addition to the security considerations from [RFC7252][RFC7641][I- 1952 D.ietf-core-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm], 1953 the following considerations hold for this document. 1955 13.1. Unsecured Multicast Notifications 1957 In case communications are not protected, the server might not be 1958 able to effectively authenticate a new client when it registers as an 1959 observer. Section 7 of [RFC7641] specifies how, in such a case, the 1960 server must strictly limit the number of notifications sent between 1961 receiving acknowledgements from the client, as confirming to be still 1962 interested in the observation; i.e., any notifications sent in Non- 1963 confirmable messages must be interspersed with confirmable messages. 1965 This is not possible to achieve by the same means when using the 1966 communication model defined in this document, since multicast 1967 notifications are sent as Non-confirmable messages. Nonetheless, the 1968 server might obtain such acknowledgements by other means. 1970 For instance, the method defined in Section 6 to perform the rough 1971 counting of still interested clients triggers (some of) them to 1972 explicitly send a new observation request to acknowledge their 1973 interest. Then, the server can decide to terminate the group 1974 observation altogether, in case not enough clients are estimated to 1975 be still active. If the method defined in Section 6 is used, the 1976 server SHOULD NOT send more than a strict number of multicast 1977 notifications for a given group observation, without having first 1978 performed a new rough counting of active clients. 1980 13.2. Secured Multicast Notifications 1982 If multicast notifications are protected using Group OSCORE as per 1983 Section 7, the following applies. 1985 * The original registration requests and related unicast 1986 (notification) responses MUST also be secured, including and 1987 especially the informative responses from the server. This 1988 prevents on-path active adversaries from altering the conveyed IP 1989 multicast address and serialized phantom registration request. 1990 Thus, it ensures secure binding between every multicast 1991 notification for a same observed resource and the phantom 1992 registration request that started the group observation of that 1993 resource. 1995 * A re-registration request, possibly including the Multicast- 1996 Response-Feedback-Divider option to support the rough counting of 1997 clients (see Section 6), MUST also be secured. 1999 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 2000 so ensuring that the secure binding above is enforced end-to-end 2001 between the server and each observing client. 2003 13.3. Listen-To-Multicast-Responses Option 2005 The CoAP option Listen-To-Multicast-Responses defined in Section 10.1 2006 is of class U for OSCORE and Group OSCORE 2007 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 2009 This allows the proxy adjacent to the origin server to access the 2010 option value conveyed in a ticket request (see Section 10.2), and to 2011 retrieve from it the transport-specific information about a phantom 2012 request. By doing so, the proxy becomes able to configure an 2013 observation of the target resource and to receive multicast 2014 notifications matching to the phantom request. 2016 Any proxy in the chain, as well as further possible intermediaries or 2017 on-path active adversaries, are thus able to remove the option or 2018 alter its content, before the ticket request reaches the proxy 2019 adjacent to the origin server. 2021 Removing the option would result in the proxy adjacent to the origin 2022 server to not configure the group observation, if that has not 2023 happened yet. In such a case, the proxy would not receive the 2024 corresponding multicast notifications to be forwarded back to the 2025 clients. 2027 Altering the option content would result in the proxy adjacent to the 2028 origin server to incorrectly configure a group observation (e.g., by 2029 indicating a wrong multicast IP address) hence preventing the correct 2030 reception of multicast notifications and their forwarding to the 2031 clients; or to configure bogus group observations that are currently 2032 not active on the origin server. 2034 In order to prevent what is described above, the ticket requests 2035 conveying the Listen-To-Multicast-Responses option can be 2036 additionally protected hop-by-hop. This can be achieved by the 2037 client protecting the ticket request sent to the proxy using OSCORE 2038 (see [I-D.tiloca-core-oscore-capable-proxies]) and/or DTLS 2039 [RFC6347][I-D.ietf-tls-dtls13]. 2041 14. IANA Considerations 2043 This document has the following actions for IANA. 2045 14.1. Media Type Registrations 2047 This document registers the media type 'application/informative- 2048 response+cbor' for error messages as informative response defined in 2049 Section 2.2, when carrying parameters encoded in CBOR. This 2050 registration follows the procedures specified in [RFC6838]. 2052 * Type name: application 2054 * Subtype name: informative-response+cbor 2056 * Required parameters: N/A 2057 * Optional parameters: N/A 2059 * Encoding considerations: Must be encoded as a CBOR map containing 2060 the parameters defined in Section 2.2 of [this document]. 2062 * Security considerations: See Section 13 of [this document]. 2064 * Interoperability considerations: N/A 2066 * Published specification: [this document] 2068 * Applications that use this media type: The type is used by CoAP 2069 servers and clients that support error messages as informative 2070 response defined in Section 2.2 of [this document]. 2072 * Fragment identifier considerations: N/A 2074 * Additional information: N/A 2076 * Person & email address to contact for further information: 2077 iesg@ietf.org (mailto:iesg@ietf.org) 2079 * Intended usage: COMMON 2081 * Restrictions on usage: None 2083 * Author: Marco Tiloca marco.tiloca@ri.se 2084 (mailto:marco.tiloca@ri.se) 2086 * Change controller: IESG 2088 * Provisional registration? No 2090 14.2. CoAP Content-Formats Registry 2092 IANA is asked to add the following entry to the "CoAP Content- 2093 Formats" registry within the "Constrained RESTful Environments (CoRE) 2094 Parameters" registry group. 2096 Media Type: application/informative-response+cbor 2098 Encoding: - 2100 ID: TBD 2102 Reference: [this document] 2104 14.3. CoAP Option Numbers Registry 2106 IANA is asked to enter the following option numbers to the "CoAP 2107 Option Numbers" registry within the "CoRE Parameters" registry group. 2109 +--------+--------------------------------------+-----------------+ 2110 | Number | Name | Reference | 2111 +--------+--------------------------------------+-----------------+ 2112 | TBD | Multicast-Response-Feedback-Divider | [This document] | 2113 +--------+--------------------------------------+-----------------+ 2114 | TBD | Listen-To-Multicast-Responses | [This document] | 2115 +--------+--------------------------------------+-----------------+ 2117 14.4. Informative Response Parameters Registry 2119 This document establishes the "Informative Response Parameters" 2120 registry. The registry has been created to use the "Expert Review 2121 Required" registration procedure [RFC8126]. Expert review guidelines 2122 are provided in Section 14.6. 2124 The columns of this registry are: 2126 * Name: This is a descriptive name that enables easier reference to 2127 the item. The name MUST be unique. It is not used in the 2128 encoding. 2130 * CBOR Key: This is the value used as CBOR key of the item. These 2131 values MUST be unique. The value can be a positive integer, a 2132 negative integer, or a string. 2134 * CBOR Type: This contains the CBOR type of the item, or a pointer 2135 to the registry that defines its type, when that depends on 2136 another item. 2138 * Reference: This contains a pointer to the public specification for 2139 the item. 2141 This registry has been initially populated by the values in 2142 Section 11. The "Reference" column for all of these entries refers 2143 to sections of this document. 2145 14.5. CoAP Transport Information Registry 2147 This document establishes the "CoAP Transport Information" registry 2148 within the "CoRE Parameters" registry group. The registry has been 2149 created to use the "Expert Review Required" registration procedure 2150 [RFC8126]. Expert review guidelines are provided in Section 14.6. 2151 It should be noted that, in addition to the expert review, some 2152 portions of the Registry require a specification, potentially a 2153 Standards Track RFC, to be supplied as well. 2155 The columns of this registry are: 2157 * Transport Protocol: This is a descriptive name that enables easier 2158 reference to the item. The name MUST be unique. It is not used 2159 in the encoding. 2161 * Description: Text giving an overview of the transport protocol 2162 referred by this item. 2164 * Value: CBOR abbreviation for the transport protocol referred by 2165 this item. Different ranges of values use different registration 2166 policies [RFC8126]. Integer values from -256 to 255 are 2167 designated as Standards Action. Integer values from -65536 to 2168 -257 and from 256 to 65535 are designated as Specification 2169 Required. Integer values greater than 65535 are designated as 2170 Expert Review. Integer values less than -65536 are marked as 2171 Private Use. 2173 * Server Addr: List of elements providing addressing information of 2174 the server. 2176 * Req Info: List of elements providing transport-specific 2177 information related to a pertinent CoAP request. Optional 2178 elements are prepended by '?'. 2180 * Reference: This contains a pointer to the public specification for 2181 the item. 2183 This registry has been initially populated by the values in 2184 Section 12. The "Reference" column for all of these entries refers 2185 to sections of this document. 2187 14.6. Expert Review Instructions 2189 The IANA registries established in this document are defined as 2190 expert review. This section gives some general guidelines for what 2191 the experts should be looking for, but they are being designated as 2192 experts for a reason so they should be given substantial latitude. 2194 Expert reviewers should take into consideration the following points: 2196 * Point squatting should be discouraged. Reviewers are encouraged 2197 to get sufficient information for registration requests to ensure 2198 that the usage is not going to duplicate one that is already 2199 registered and that the point is likely to be used in deployments. 2200 The zones tagged as private use are intended for testing purposes 2201 and closed environments, code points in other ranges should not be 2202 assigned for testing. 2204 * Specifications are required for the standards track range of point 2205 assignment. Specifications should exist for specification 2206 required ranges, but early assignment before a specification is 2207 available is considered to be permissible. Specifications are 2208 needed for the first-come, first-serve range if they are expected 2209 to be used outside of closed environments in an interoperable way. 2210 When specifications are not provided, the description provided 2211 needs to have sufficient information to identify what the point is 2212 being used for. 2214 * Experts should take into account the expected usage of fields when 2215 approving point assignment. The fact that there is a range for 2216 standards track documents does not mean that a standards track 2217 document cannot have points assigned outside of that range. The 2218 length of the encoded value should be weighed against how many 2219 code points of that length are left, the size of device it will be 2220 used on, and the number of code points left that encode to that 2221 size. 2223 15. References 2225 15.1. Normative References 2227 [COSE.Algorithms] 2228 IANA, "COSE Algorithms", 2229 . 2232 [COSE.Header.Parameters] 2233 IANA, "COSE Header Parameters", 2234 . 2237 [COSE.Key.Types] 2238 IANA, "COSE Key Types", 2239 . 2242 [I-D.ietf-ace-key-groupcomm-oscore] 2243 Tiloca, M., Park, J., and F. Palombini, "Key Management 2244 for OSCORE Groups in ACE", Work in Progress, Internet- 2245 Draft, draft-ietf-ace-key-groupcomm-oscore-12, 25 October 2246 2021, . 2249 [I-D.ietf-ace-oscore-profile] 2250 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2251 "OSCORE Profile of the Authentication and Authorization 2252 for Constrained Environments Framework", Work in Progress, 2253 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 2254 2021, . 2257 [I-D.ietf-core-groupcomm-bis] 2258 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2259 for the Constrained Application Protocol (CoAP)", Work in 2260 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 2261 05, 25 October 2021, . 2264 [I-D.ietf-core-oscore-groupcomm] 2265 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 2266 and J. Park, "Group OSCORE - Secure Group Communication 2267 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 2268 core-oscore-groupcomm-13, 25 October 2021, 2269 . 2272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2273 Requirement Levels", BCP 14, RFC 2119, 2274 DOI 10.17487/RFC2119, March 1997, 2275 . 2277 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2278 "Transmission of IPv6 Packets over IEEE 802.15.4 2279 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2280 . 2282 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2283 Specifications and Registration Procedures", BCP 13, 2284 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2285 . 2287 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2288 Application Protocol (CoAP)", RFC 7252, 2289 DOI 10.17487/RFC7252, June 2014, 2290 . 2292 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2293 Application Protocol (CoAP)", RFC 7641, 2294 DOI 10.17487/RFC7641, September 2015, 2295 . 2297 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2298 Bose, "Constrained Application Protocol (CoAP) Option for 2299 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2300 August 2016, . 2302 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2303 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2304 March 2017, . 2306 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2307 Writing an IANA Considerations Section in RFCs", BCP 26, 2308 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2309 . 2311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2313 May 2017, . 2315 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 2316 DOI 10.17487/RFC8288, October 2017, 2317 . 2319 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2320 "Object Security for Constrained RESTful Environments 2321 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2322 . 2324 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2325 Representation (CBOR)", STD 94, RFC 8949, 2326 DOI 10.17487/RFC8949, December 2020, 2327 . 2329 15.2. Informative References 2331 [I-D.amsuess-core-cachable-oscore] 2332 Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in 2333 Progress, Internet-Draft, draft-amsuess-core-cachable- 2334 oscore-02, 12 July 2021, . 2337 [I-D.ietf-ace-oauth-authz] 2338 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2339 H. Tschofenig, "Authentication and Authorization for 2340 Constrained Environments (ACE) using the OAuth 2.0 2341 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2342 draft-ietf-ace-oauth-authz-45, 29 August 2021, 2343 . 2346 [I-D.ietf-core-coap-pubsub] 2347 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2348 Subscribe Broker for the Constrained Application Protocol 2349 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2350 core-coap-pubsub-09, 30 September 2019, 2351 . 2354 [I-D.ietf-core-coral] 2355 Hartke, K., "The Constrained RESTful Application Language 2356 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 2357 core-coral-03, 9 March 2020, 2358 . 2361 [I-D.ietf-core-href] 2362 Bormann, C. and H. Birkholz, "Constrained Resource 2363 Identifiers", Work in Progress, Internet-Draft, draft- 2364 ietf-core-href-06, 25 July 2021, 2365 . 2368 [I-D.ietf-core-resource-directory] 2369 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2370 D. Stok, "CoRE Resource Directory", Work in Progress, 2371 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2372 March 2021, . 2375 [I-D.ietf-cose-cbor-encoded-cert] 2376 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 2377 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 2378 Certificates)", Work in Progress, Internet-Draft, draft- 2379 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 2380 . 2383 [I-D.ietf-rats-uccs] 2384 Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. 2385 Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", 2386 Work in Progress, Internet-Draft, draft-ietf-rats-uccs-01, 2387 12 July 2021, . 2390 [I-D.ietf-tls-dtls13] 2391 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2392 Datagram Transport Layer Security (DTLS) Protocol Version 2393 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2394 dtls13-43, 30 April 2021, . 2397 [I-D.tiloca-core-oscore-capable-proxies] 2398 Tiloca, M. and R. Hoeglund, "OSCORE-capable Proxies", Work 2399 in Progress, Internet-Draft, draft-tiloca-core-oscore- 2400 capable-proxies-01, 25 October 2021, 2401 . 2404 [I-D.tiloca-core-oscore-discovery] 2405 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 2406 OSCORE Groups with the CoRE Resource Directory", Work in 2407 Progress, Internet-Draft, draft-tiloca-core-oscore- 2408 discovery-10, 25 October 2021, 2409 . 2412 [MOBICOM99] 2413 Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The 2414 Broadcast Storm Problem in a Mobile Ad Hoc Network", 2415 Proceedings of the 5th annual ACM/IEEE international 2416 conference on Mobile computing and networking , August 2417 1999, . 2420 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2421 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2422 January 2012, . 2424 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2425 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2426 . 2428 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2429 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2430 . 2432 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 2433 Security (TLS) / Datagram Transport Layer Security (DTLS) 2434 Profiles for the Internet of Things", RFC 7925, 2435 DOI 10.17487/RFC7925, July 2016, 2436 . 2438 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2439 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2440 May 2018, . 2442 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2443 Definition Language (CDDL): A Notational Convention to 2444 Express Concise Binary Object Representation (CBOR) and 2445 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2446 June 2019, . 2448 Appendix A. Different Sources for Group Observation Data 2450 While the clients usually receive the phantom registration request 2451 and other information related to the group observation through an 2452 Informative Response, the same data can be made available through 2453 different services, such as the following ones. 2455 A.1. Topic Discovery in Publish-Subscribe Settings 2457 In a Publish-Subscribe scenario [I-D.ietf-core-coap-pubsub], a group 2458 observation can be discovered along with topic metadata. For 2459 instance, a discovery step can make the following metadata available. 2461 This example assumes a CoRAL namespace [I-D.ietf-core-coral], that 2462 contains properties analogous to those in the content-format 2463 application/informative-response+cbor. 2465 Request: 2467 GET 2468 Accept: CoRAL 2470 Response: 2472 2.05 Content 2473 Content-Format: CoRAL 2475 rdf:type 2476 topic { 2477 tp_info [1, h"7b", h"20010db80100..0001", 5683, 2478 h"ff35003020010db8..1234", 5683], 2479 ph_req h"0160..", 2480 last_notif h"256105.." 2481 } 2483 Figure 10: Group observation discovery in a Pub-Sub scenario 2485 With this information from the topic discovery step, the client can 2486 already set up its multicast address and start receiving multicast 2487 notifications. 2489 In heavily asymmetric networks like municipal notification services, 2490 discovery and notifications do not necessarily need to use the same 2491 network link. For example, a departure monitor could use its (costly 2492 and usually-off) cellular uplink to discover the topics it needs to 2493 update its display to, and then listen on a LoRA-WAN interface for 2494 receiving the actual multicast notifications. 2496 A.2. Introspection at the Multicast Notification Sender 2498 For network debugging purposes, it can be useful to query a server 2499 that sends multicast responses as matching a phantom registration 2500 request. 2502 Such an interface is left for other documents to specify on demand. 2503 As an example, a possible interface can be as follows, and rely on 2504 the already known Token value of intercepted multicast notifications, 2505 associated to a phantom registration request. 2507 Request: 2509 GET 2511 Response: 2513 2.05 Content 2514 Content-Format: application/informative-response+cbor 2516 { 2517 'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 2518 h"ff35003020010db8..1234", 5683], 2519 'ph_req': h"0160..", 2520 'last_notif' : h"256105.." 2521 } 2523 Figure 11: Group observation discovery with server introspection 2525 For example, a network sniffer could offer sending such a request 2526 when unknown multicast notifications are seen in a network. 2527 Consequently, it can associate those notifications with a URI, or 2528 decrypt them, if member of the correct OSCORE group. 2530 Appendix B. Pseudo-Code for Rough Counting of Clients 2532 This appendix provides a description in pseudo-code of the two 2533 algorithms used for the rough counting of active observers, as 2534 defined in Section 6. 2536 In particular, Appendix B.1 describes the algorithm for the client 2537 side, while Appendix B.2 describes an optimized version for 2538 constrained clients. Finally, Appendix B.3 describes the algorithm 2539 for the server side. 2541 B.1. Client Side 2542 input: int Q, // Value of the MRFD option 2543 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2544 // unless overridden 2546 output: None 2548 int RAND_MIN = 0; 2549 int RAND_MAX = (2**Q) - 1; 2550 int I = randomInteger(RAND_MIN, RAND_MAX); 2552 if (I == 0) { 2553 float fraction = randomFloat(0, 1); 2555 Timer t = new Timer(); 2556 t.setAndStart(fraction * LEISURE_TIME); 2557 while(!t.isExpired()); 2559 Request req = new Request(); 2560 // Initialize as NON and with maximum 2561 // No-Response settings, set options ... 2563 Option opt = new Option(OBSERVE); 2564 opt.set(0); 2565 req.setOption(opt); 2567 opt = new Option(MRFD); 2568 req.setOption(opt); 2570 req.send(SRV_ADDR, SRV_PORT); 2571 } 2573 B.2. Client Side - Optimized Version 2574 input: int Q, // Value of the MRFD option 2575 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2576 // unless overridden 2578 output: None 2580 const unsigned int UINT_BIT = CHAR_BIT * sizeof(unsigned int); 2582 if (respond_to(Q) == true) { 2583 float fraction = randomFloat(0, 1); 2585 Timer t = new Timer(); 2586 t.setAndStart(fraction * LEISURE_TIME); 2587 while(!t.isExpired()); 2589 Request req = new Request(); 2590 // Initialize as NON and with maximum 2591 // No-Response settings, set options ... 2593 Option opt = new Option(OBSERVE); 2594 opt.set(0); 2595 req.setOption(opt); 2597 opt = new Option(MRFD); 2598 req.setOption(opt); 2600 req.send(SRV_ADDR, SRV_PORT); 2601 } 2603 bool respond_to(int Q) { 2604 while (Q >= UINT_BIT) { 2605 if (rand() != 0) return false; 2606 Q -= UINT_BIT; 2607 } 2608 unsigned int mask = ~((~0u) << Q); 2609 unsigned int masked = mask & rand(); 2610 return masked == 0; 2611 } 2613 B.3. Server Side 2615 input: int COUNT, // Current observer counter 2616 int M, // Desired number of confirmations 2617 int MAX_CONFIRMATION_WAIT, 2618 Response notification, // Multicast notification to send 2620 output: int NEW_COUNT // Updated observer counter 2621 int D = 4; // Dampener value 2622 int RETRY_NEXT_THRESHOLD = 4; 2623 float CANCEL_THRESHOLD = 0.2; 2625 int N = max(COUNT, 1); 2626 int Q = max(ceil(log2(N / M)), 0); 2627 Option opt = new Option(MRFD); 2628 opt.set(Q); 2630 notification.setOption(opt); 2631 2632 notification.send(GRP_ADDR, GRP_PORT); 2634 Timer t = new Timer(); 2635 t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 2636 while(!t.isExpired()); 2638 // Time t2 2640 int R = ; 2643 int E = R * (2**Q); 2645 // Determine after how many multicast notifications 2646 // the next count update will be performed 2647 if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) { 2648 2649 } 2650 else { 2651 2652 } 2654 // Compute the new count estimate 2655 int COUNT_PRIME = ; 2656 int NEW_COUNT = COUNT_PRIME + ((E - N) / D); 2658 // Determine whether to cancel the group observation 2659 if (NEW_COUNT < CANCEL_THRESHOLD) { 2660 ; 2661 return 0; 2662 } 2664 return NEW_COUNT; 2666 Appendix C. OSCORE Group Self-Managed by the Server 2668 For simple settings, where no pre-arranged group with suitable 2669 memberships is available, the server can be responsible to setup and 2670 manage the OSCORE group used to protect the group observation. 2672 In such a case, a client would implicitly request to join the OSCORE 2673 group when sending the observe registration request to the server. 2674 When replying, the server includes the group keying material and 2675 related information in the informative response (see Section 2.2). 2677 Additionally to what defined in Section 2, the CBOR map in the 2678 informative response payload contains the following fields, whose 2679 CBOR labels are defined in Section 11. 2681 * 'gp_material': this element is a CBOR map, which includes what the 2682 client needs in order to set up the Group OSCORE Security Context. 2684 This parameter has as value a subset of the 2685 Group_OSCORE_Input_Material object, which is defined in 2686 Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the 2687 OSCORE_Input_Material object encoded in CBOR as defined in 2688 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 2690 In particular, the following elements of the 2691 Group_OSCORE_Input_Material object are included, using the same 2692 CBOR labels from the OSCORE Security Context Parameters Registry, 2693 as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 2695 - 'ms', 'contexId', 'pub_key_enc', 'sign_enc_alg', 'sign_alg' and 2696 'sign_params'. These elements MUST be included. 2698 - 'hkdf' and 'salt'. These elements MAY be included. 2700 The 'group_senderId' element of the Group_OSCORE_Input_Material 2701 object MUST NOT be included. 2703 * 'srv_pub_key': this element is a CBOR byte string, with value the 2704 original binary representation of the server's public key used in 2705 the OSCORE group. In particular, the original binary 2706 representation complies with the encoding specified by the 2707 'pub_key_enc' element of 'gp_material'. 2709 * 'srv_identifier': this element MUST be included and is encoded as 2710 a CBOR byte string, with value the Sender ID that the server has 2711 in the OSCORE group. 2713 * 'exp': with value the expiration time of the keying material of 2714 the OSCORE group specified in the 'gp_material' parameter, encoded 2715 as a CBOR unsigned integer. This field contains a numeric value 2716 representing the number of seconds from 1970-01-01T00:00:00Z UTC 2717 until the specified UTC date/time, ignoring leap seconds, 2718 analogous to what specified for NumericDate in Section 2 of 2719 [RFC7519]. 2721 Note that the informative response does not require to include an 2722 explicit proof-of-possession (PoP) of the server's private key. 2723 Although the server is also acting as Group Manager and a PoP 2724 evidence of the Group Manager's private key is included in a full- 2725 fledged Joining Response (see Section 6.4 of 2726 [I-D.ietf-ace-key-groupcomm-oscore]), such proof-of-possession will 2727 be achieved through every multicast notification, that the server 2728 sends as protected with the group mode of Group OSCORE and including 2729 a signature computed with its private key. 2731 A client receiving an informative response uses the information above 2732 to set up the Group OSCORE Security Context, as described in 2733 Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client 2734 does not obtain a Sender ID of its own, hence it installs a Security 2735 Context that a "silent server" would, i.e., without Sender Context. 2736 From then on, the client uses the received keying material to process 2737 the incoming multicast notifications from the server. 2739 Since the server is also acting as Group Manager, the public key of 2740 the server provided in the 'srv_pub_key' element of the informative 2741 response is also used in the 'gm_public_key' element of the 2742 external_aad for encrypting and signing the phantom request and 2743 multicast notifications (see Section 4.3 of 2744 [I-D.ietf-core-oscore-groupcomm]) 2746 Furthermore, the server complies with the following points. 2748 * The server MUST NOT self-manage OSCORE groups and provide the 2749 related keying material in the informative response for any other 2750 purpose than the protection of group observations, as defined in 2751 this document. 2753 The server MAY use the same self-managed OSCORE group to protect 2754 the phantom request and the multicast notifications of multiple 2755 group observations it hosts. 2757 * The server MUST NOT provide in the informative response the keying 2758 material of other OSCORE groups it is or has been a member of. 2760 After the time indicated in the 'exp' field: 2762 * The server MUST stop using the keying material and MUST cancel the 2763 group observations for which that keying material is used (see 2764 Section 2.5 and Section 7.2.4). If the server creates a new group 2765 observation as a replacement or follow-up using the same OSCORE 2766 group: 2768 - The server MUST update the Master Secret. 2770 - The server MUST update the ID Context used as Group Identifier 2771 (Gid), consistently with Section 3.2 of 2772 [I-D.ietf-core-oscore-groupcomm]. 2774 - The server MAY update the Master Salt. 2776 * The client MUST stop using the keying material and MAY re-register 2777 the observation at the server. 2779 Before the keying material has expired, the server can send a 2780 multicast response with response code 5.03 (Service Unavailable) to 2781 the observing clients, protected with the current keying material. 2782 In particular, this is an informative response (see Section 2.2), 2783 which: i) additionally contains the abovementioned parameters for the 2784 next group keying material to be used; and ii) MAY omit the 'tp_info' 2785 and 'ph_req' parameters, since the associated information is 2786 immutable throughout the observation lifetime. The response has the 2787 same Token value T of the phantom registration request and it does 2788 not include an Observe option. The server MUST use its own Sender 2789 Sequence Number as Partial IV to protect the error response, and 2790 include it as Partial IV in the OSCORE option of the response. 2792 When some clients leave the OSCORE group and forget about the group 2793 observation, the server does not have to provide the remaining 2794 clients with any stale Sender IDs, as normally required for Group 2795 OSCORE (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). In 2796 fact, only two entities in the group have a Sender ID, i.e., the 2797 server and possibly the Deterministic Client, if the optimization 2798 defined in this appendix is combined with the use of phantom requests 2799 as deterministic requests (see Appendix D). In particular, both of 2800 them never change their Sender ID during the group lifetime, while 2801 they both remain part of the group until the group ceases to exist. 2803 As an alternative to renewing the keying material before it expires, 2804 the server can simply cancel the group observation (see Section 2.5 2805 and Section 7.2.4), which results in the eventual re-registration of 2806 the clients that are still interested in the group observation. 2808 Applications requiring backward security and forward security are 2809 REQUIRED to use an actual group joining process (usually through a 2810 dedicated Group Manager), e.g., the ACE joining procedure defined in 2811 [I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the 2812 clients by providing them information about the OSCORE group to join, 2813 as described in Section 7.1. 2815 Appendix D. Phantom Request as Deterministic Request 2817 In some settings, the server can assume that all the approaching 2818 clients already have the exact phantom observation request to use. 2820 For instance, the clients can be pre-configured with the phantom 2821 observation request, or they may be expected to retrieve it through 2822 dedicated means (see Appendix A), before sending an observe 2823 registration request to the server. 2825 If Group OSCORE is used to protect the group observation (see 2826 Section 7), and the OSCORE group supports the concept of 2827 Deterministic Client [I-D.amsuess-core-cachable-oscore], then the 2828 server and each client in the OSCORE group can independently protect 2829 the phantom observation request possibly available as plain CoAP 2830 message. To this end, they use the approach defined in Section 2 of 2831 [I-D.amsuess-core-cachable-oscore] to compute a protected 2832 deterministic request, against which the protected multicast 2833 notifications will match for the group observation in question. 2835 Note that the same deterministic request sent by each client as 2836 registration request is, in terms of transport-independent 2837 information, identical to the phantom registration request. Thus, 2838 the informative response sent by the server may omit the 'ph_req' 2839 parameter (see Section 2.2). If a client receives an informative 2840 response that includes the 'ph_req' parameter, and this specifies 2841 transport-independent information different from the one of the sent 2842 deterministic request, then the client considers the informative 2843 response malformed. 2845 If the optimization defined in Appendix C is also used, the 2846 'gp_material' element in the error informative response from the 2847 server MUST also include the following elements from the 2848 Group_OSCORE_Input_Material object. 2850 * 'alg', 'ecdh_alg' and 'ecdh_params', as per Section 6.4 of 2851 [I-D.ietf-ace-key-groupcomm-oscore]. 2853 * 'det_senderId' and 'det_hash_alg', defined in Section 3 of 2854 [I-D.amsuess-core-cachable-oscore]. These specify the Sender ID 2855 of the Deterministic Client in the OSCORE group, and the hash 2856 algorithm used to compute the deterministic request (see 2857 Section 2.4.1 of [I-D.amsuess-core-cachable-oscore]). 2859 Appendix E. Example with a Proxy 2861 This section provides an example when a proxy P is used between the 2862 clients and the server. The same assumptions and notation used in 2863 Section 5 are used for this example. In addition, the proxy has 2864 address PRX_ADDR and listens to the port number PRX_PORT. 2866 Unless explicitly indicated, all messages transmitted on the wire are 2867 sent over unicast. 2869 C1 C2 P S 2870 | | | | 2871 | | | | (The value of the resource /r is "1234") 2872 | | | | 2873 +------------>| | Token: 0x4a 2874 | GET | | | Observe: 0 (Register) 2875 | | | | Proxy-Uri: coap://sensor.example/r 2876 | | | | 2877 | | +------->| Token: 0x5e 2878 | | | GET | Observe: 0 (Register) 2879 | | | | Uri-Host: sensor.example 2880 | | | | Uri-Path: r 2881 | | | | 2882 | | | | (S allocates the available Token value 0x7b) 2883 | | | | 2884 | | | | (S sends to itself a phantom observation 2885 | | | | request PH_REQ as coming from the 2886 | | | | IP multicast address GRP_ADDR) 2887 | | | | 2888 | | | ------+ 2889 | | | / | 2890 | | | \----->| Token: 0x7b 2891 | | | GET | Observe: 0 (Register) 2892 | | | | Uri-Host: sensor.example 2893 | | | | Uri-Path: r 2894 | | | | 2895 | | | | (S creates a group observation of /r) 2896 | | | | 2897 | | | | (S increments the observer counter 2898 | | | | for the group observation of /r) 2899 | | | | 2900 | | | | 2901 | | | | 2902 | | |<-------+ Token: 0x5e 2903 | | | 5.03 | Content-Format: application/ 2904 | | | | informative-response+cbor 2905 | | | | Max-Age: 0 2906 | | | | 2907 | | | | Payload: { 2908 | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, 2909 | | | | 0x7b, bstr(GRP_ADDR), 2910 | | | | GRP_PORT], 2911 | | | | last_notif : bstr(0x45 | OPT | 2912 | | | | 0xff | PAYLOAD) 2913 | | | | } 2914 | | | | 2915 | | | | (PAYLOAD in 'last_notif' : "1234") 2916 | | | | 2917 | | | | 2918 | | | | (The proxy starts listening to the 2919 | | | | GRP_ADDR address and the GRP_PORT port.) 2920 | | | | 2921 | | | | (The proxy adds C1 to its list of observers.) 2922 | | | | 2923 |<------------+ | Token: 0x4a 2924 | 2.05 | | | Observe: 54120 2925 | | | | Content-Format: application/cbor 2926 | | | | 2927 | | | | Payload: "1234" 2928 | | | | 2929 : : : : 2930 : : : : 2931 : : : : 2932 | | | | 2933 | +----->| | Token: 0x01 2934 | | GET | | Observe: 0 (Register) 2935 | | | | Proxy-Uri: coap://sensor.example/r 2936 | | | | 2937 | | | | (The proxy has a fresh cache representation) 2938 | | | | 2939 | |<-----+ | Token: 0x01 2940 | | 2.05 | | Observe: 54120 2941 | | | | Content-Format: application/cbor 2942 | | | | 2943 | | | | Payload: "1234" 2944 | | | | 2945 : : : : 2946 : : : : (The value of the resource 2947 : : : : /r changes to "5678".) 2948 : : : : 2950 | | | | 2951 | | | (*) | 2952 | | |<-------+ Token: 0x7b 2953 | | | 2.05 | Observe: 11 2954 | | | | Content-Format: application/cbor 2955 | | | | 2956 | | | | Payload: "5678" 2957 | | | | 2958 |<------------+ | Token: 0x4a 2959 | 2.05 | | | Observe: 54123 2960 | | | | Content-Format: application/cbor 2961 | | | | 2962 | | | | Payload: "5678" 2963 | | | | 2964 | |<-----+ | Token: 0x01 2965 | | 2.05 | | Observe: 54123 2966 | | | | Content-Format: application/cbor 2967 | | | | 2968 | | | | Payload: "5678" 2969 | | | | 2971 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT 2973 Figure 12: Example of group observation with a proxy 2975 Note that the proxy has all the information to understand the 2976 observation request from C2, and can immediately start to serve the 2977 still fresh values. 2979 This behavior is mandated by Section 5 of [RFC7641], i.e., the proxy 2980 registers itself only once with the next hop and fans out the 2981 notifications it receives to all registered clients. 2983 Appendix F. Example with a Proxy and Group OSCORE 2985 This section provides an example when a proxy P is used between the 2986 clients and the server, and Group OSCORE is used to protect multicast 2987 notifications end-to-end between the server and the clients. 2989 The same assumptions and notation used in Section 8 are used for this 2990 example. In addition, the proxy has address PRX_ADDR and listens to 2991 the port number PRX_PORT. 2993 Unless explicitly indicated, all messages transmitted on the wire are 2994 sent over unicast and protected with OSCORE end-to-end between a 2995 client and the server. 2997 C1 C2 P S 2998 | | | | 2999 | | | | (The value of the resource /r is "1234") 3000 | | | | 3001 +-------------->| | Token: 0x4a 3002 | FETCH | | | Observe: 0 (Register) 3003 | | | | OSCORE: {kid: 0x01; piv: 101; ...} 3004 | | | | Uri-Host: sensor.example 3005 | | | | Proxy-Scheme: coap 3006 | | | | 3007 | | | | 0xff 3008 | | | | Encrypted_payload { 3009 | | | | 0x01 (GET), 3010 | | | | Observe: 0 (Register), 3011 | | | | Uri-Path: r, 3012 | | | | 3013 | | | | } 3014 | | | | 3015 | | +-------->| Token: 0x5e 3016 | | | FETCH | Observe: 0 (Register) 3017 | | | | OSCORE: {kid: 0x01; piv: 101; ...} 3018 | | | | Uri-Host: sensor.example 3019 | | | | 3020 | | | | 0xff 3021 | | | | Encrypted_payload { 3022 | | | | 0x01 (GET), 3023 | | | | Observe: 0 (Register), 3024 | | | | Uri-Path: r, 3025 | | | | 3026 | | | | } 3027 | | | | 3028 | | | | 3029 | | | | (S allocates the available 3030 | | | | Token value 0x7b .) 3031 | | | | 3032 | | | | (S sends to itself a phantom observation 3033 | | | | request PH_REQ as coming from the 3034 | | | | IP multicast address GRP_ADDR) 3035 | | | | 3036 | | | -------+ 3037 | | | / | 3038 | | | \------>| Token: 0x7b 3039 | | | FETCH | Observe: 0 (Register) 3040 | | | | OSCORE: {kid: 0x05; piv: 501; 3041 | | | | kid context: 0x57ab2e; ...} 3042 | | | | Uri-Host: sensor.example 3043 | | | | 3044 | | | | 0xff 3045 | | | | Encrypted_payload { 3046 | | | | 0x01 (GET), 3047 | | | | Observe: 0 (Register), 3048 | | | | Uri-Path: r, 3049 | | | | 3050 | | | | } 3051 | | | | 3052 | | | | 3053 | | | | (S steps SN_5 in the Group OSCORE 3054 | | | | Security Context : SN_5 <== 502) 3055 | | | | 3056 | | | | (S creates a group observation of /r) 3057 | | | | 3058 | | | | 3059 | | | | (S increments the observer counter 3060 | | | | for the group observation of /r) 3061 | | | | 3062 | | |<--------+ Token: 0x5e 3063 | | | 2.05 | OSCORE: {piv: 301; ...} 3064 | | | | Max-Age: 0 3065 | | | | 3066 | | | | 0xff 3067 | | | | Encrypted_payload { 3068 | | | | 5.03 (Service Unavailable), 3069 | | | | Content-Format: application/ 3070 | | | | informative-response+cbor, 3071 | | | | , 3072 | | | | 0xff, 3073 | | | | CBOR_payload { 3074 | | | | tp_info : [1, bstr(SRV_ADDR), 3075 | | | | SRV_PORT, 0x7b, 3076 | | | | bstr(GRP_ADDR), GRP_PORT], 3077 | | | | ph_req : bstr(0x05 | OPT | 0xff | 3078 | | | | PAYLOAD | SIGN), 3079 | | | | last_notif : bstr(0x45 | OPT | 0xff | 3080 | | | | PAYLOAD | SIGN), 3081 | | | | join_uri : "coap://myGM/ 3082 | | | | ace-group/myGroup", 3083 | | | | sec_gp : "myGroup" 3084 | | | | } 3085 | | | | } 3086 | | | | 3087 |<--------------+ | Token: 0x4a 3088 | 2.05 | | | OSCORE: {piv: 301; ...} 3089 | | | | 3090 | | | | 0xff 3091 | | | | (Same Encrypted_payload) 3092 | | | | 3093 | | | | 3094 +-------------->| | Token: 0x4b 3095 | FETCH | | | Observe: 0 (Register) 3096 | | | | OSCORE: {kid: 0x05 ; piv: 501; 3097 | | | | kid context: 0x57ab2e; ...} 3098 | | | | Uri-Host: sensor.example 3099 | | | | Proxy-Scheme: coap 3100 | | | | Listen-To- 3101 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 3102 | | | | SRV_PORT, 0x7b, 3103 | | | | bstr(GRP_ADDR), 3104 | | | | GRP_PORT] 3105 | | | | } 3106 | | | | 3107 | | | | 0xff 3108 | | | | Encrypted_payload { 3109 | | | | 0x01 (GET), 3110 | | | | Observe: 0 (Register), 3111 | | | | Uri-Path: r 3112 | | | | 3113 | | | | } 3114 | | | | 3115 | | | | 3116 | | | | (The proxy starts listening to the 3117 | | | | GRP_ADDR address and the GRP_PORT port.) 3118 | | | | 3119 | | | | (The proxy adds C1 to 3120 | | | | its list of observers.) 3121 | | | | 3122 |<--------------| | 3123 | | ACK | | 3124 : : : : 3125 : : : : 3126 : : : : 3127 | | | | 3128 | +------>| | Token: 0x01 3129 | | FETCH | | Observe: 0 (Register) 3130 | | | | OSCORE: {kid: 0x02; piv: 201; ...} 3131 | | | | Uri-Host: sensor.example 3132 | | | | Proxy-Scheme: coap 3133 | | | | 3134 | | | | 0xff 3135 | | | | Encrypted_payload { 3136 | | | | 0x01 (GET), 3137 | | | | Observe: 0 (Register), 3138 | | | | Uri-Path: r, 3139 | | | | 3140 | | | | } 3141 | | | | 3142 | | +-------->| Token: 0x5f 3143 | | | FETCH | Observe: 0 (Register) 3144 | | | | OSCORE: {kid: 0x02; piv: 201; ...} 3145 | | | | Uri-Host: sensor.example 3146 | | | | 3147 | | | | 0xff 3148 | | | | Encrypted_payload { 3149 | | | | 0x01 (GET), 3150 | | | | Observe: 0 (Register), 3151 | | | | Uri-Path: r, 3152 | | | | 3153 | | | | } 3154 | | | | 3155 | | |<--------+ Token: 0x5f 3156 | | | 2.05 | OSCORE: {piv: 401; ...} 3157 | | | | Max-Age: 0 3158 | | | | 3159 | | | | 0xff 3160 | | | | Encrypted_payload { 3161 | | | | 5.03 (Service Unavailable), 3162 | | | | Content-Format: application/ 3163 | | | | informative-response+cbor, 3164 | | | | , 3165 | | | | 0xff, 3166 | | | | CBOR_payload { 3167 | | | | tp_info : [1, bstr(SRV_ADDR), 3168 | | | | SRV_PORT, 0x7b, 3169 | | | | bstr(GRP_ADDR), GRP_PORT], 3170 | | | | ph_req : bstr(0x05 | OPT | 0xff | 3171 | | | | PAYLOAD | SIGN), 3172 | | | | last_notif : bstr(0x45 | OPT | 0xff | 3173 | | | | PAYLOAD | SIGN), 3174 | | | | join_uri : "coap://myGM/ 3175 | | | | ace-group/myGroup", 3176 | | | | sec_gp : "myGroup" 3177 | | | | } 3178 | | | | } 3179 | | | | 3180 | |<------+ | Token: 0x01 3181 | | 2.05 | | OSCORE: {piv: 401; ...} 3182 | | | | 3183 | | | | 0xff 3184 | | | | (Same Encrypted_payload) 3185 | | | | 3186 | +------>| | Token: 0x02 3187 | | FETCH | | Observe: 0 (Register) 3188 | | | | OSCORE: {kid: 0x05; piv: 501; 3189 | | | | kid context: 57ab2e; ...} 3190 | | | | Uri-Host: sensor.example 3191 | | | | Proxy-Scheme: coap 3192 | | | | Listen-To- 3193 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 3194 | | | | SRV_PORT, 0x7b, 3195 | | | | bstr(GRP_ADDR), 3196 | | | | GRP_PORT] 3197 | | | | } 3198 | | | | 3199 | | | | 0xff 3200 | | | | Encrypted_payload { 3201 | | | | 0x01 (GET), 3202 | | | | Observe: 0 (Register), 3203 | | | | Uri-Path: r 3204 | | | | 3205 | | | | } 3206 | | | | 3207 | | | | 3208 | | | | (The proxy adds C2 to 3209 | | | | its list of observers.) 3210 | |<------| | 3211 | | ACK | | 3212 | | | | 3213 : : : : 3214 : : : : (The value of the resource 3215 : : : : /r changes to "5678".) 3216 : : : : 3217 | | | (*) | 3218 | | |<--------+ Token: 0x7b 3219 | | | 2.05 | Observe: 11 3220 | | | | OSCORE: {kid: 0x05; piv: 502; ...} 3221 | | | | 3222 | | | | 0xff 3223 | | | | Encrypted_payload { 3224 | | | | 2.05 (Content), 3225 | | | | Observe: [empty], 3226 | | | | Content-Format: application/cbor, 3227 | | | | , 3228 | | | | 0xff, 3229 | | | | CBOR_Payload: "5678" 3230 | | | | } 3231 | | | | 3232 | | | | 3233 |<--------------+ | Token: 0x4b 3234 | 2.05 | | | Observe: 54123 3235 | | | | OSCORE: {kid: 0x05; piv: 502; ...} 3236 | | | | 3237 | | | | 0xff 3238 | | | | (Same Encrypted_payload and Signature) 3239 | | | | 3240 | |<------+ | Token: 0x02 3241 | | 2.05 | | Observe: 54123 3242 | | | | OSCORE: {kid: 0x05; piv: 502; ...} 3243 | | | | 3244 | | | | 0xff 3245 | | | | (Same Encrypted_payload and signature) 3246 | | | | 3248 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 3249 with Group OSCORE end-to-end between the server and the clients. 3251 Figure 13: Example of group observation with a proxy and Group OSCORE 3253 Unlike in the unprotected example in Appendix E, the proxy does _not_ 3254 have all the information to perform request deduplication, and can 3255 only recognize the identical request once the client sends the ticket 3256 request. 3258 Appendix G. Example with a Proxy and Deterministic Requests 3260 This section provides an example when a proxy P is used between the 3261 clients and the server, and Group OSCORE is used to protect multicast 3262 notifications end-to-end between the server and the clients. 3264 In addition, the phantom request is especially a deterministic 3265 request (see Appendix D), which is protected with the pairwise mode 3266 of Group OSCORE as defined in [I-D.amsuess-core-cachable-oscore]. 3268 G.1. Assumptions and Walkthrough 3270 The example provided in this appendix as reflected by the message 3271 exchange shown in Appendix G.2 assumes the following. 3273 1. The OSCORE group supports deterministic requests. Thus, the 3274 server creates the phantom request as a deterministic request 3275 [I-D.amsuess-core-cachable-oscore], and stores it locally as one 3276 of its issued phantom requests, without starting the group 3277 observation yet. 3279 2. The server makes the phantom request available through other 3280 means, e.g., a pub-sub broker, together with the transport- 3281 specific information for listening to multicast notifications 3282 bound to the phantom request (see Appendix A). 3284 3. Since the phantom request is a deterministic request, the server 3285 can more efficiently make it available in its smaller, plain 3286 version. The clients can obtain it from the particular 3287 alternative source, and compute the protected version to use 3288 from the retrieved plain version. 3290 4. If the client does not rely on a proxy between itself and the 3291 server, it simply sets the group observation and starts 3292 listening to multicast notifications. Building on point (2) 3293 above, the same would happen if the phantom request would not be 3294 specifically a deterministic request. 3296 5. If the client relies on a proxy between itself and the server, 3297 it uses the phantom request as a ticket request. However, 3298 unlike the case considered in Section 10 when the ticket request 3299 is not deterministic, the client does not include a Listen-to- 3300 Multicast-Responses option in the phantom request sent to the 3301 proxy. 3303 6. Unlike for the case considered in Section 10, here the proxy 3304 does not know that the request is exactly a ticket request for 3305 subscribing to multicast notifications. Thus, the proxy simply 3306 forwards the ticket request to the server as it normally does 3307 for any request. 3309 7. The server receives the ticket request, which is a deviation 3310 from the case where the ticket request is not deterministic and 3311 stops at the proxy (see Section 10). Then, the server can 3312 clearly understand what is happening. In fact, as the result of 3313 an early check, the server recognizes the phantom request among 3314 the stored ones. This happens through a byte-by-byte comparison 3315 of the incoming message minus the transport-related fields, 3316 i.e., by considering only: i) the outer REST code; ii) the outer 3317 options; and iii) the ciphertext and signature from the message 3318 payload. 3320 8. Having recognized the incoming request as one of the self- 3321 generated deterministic phantom requests made available at 3322 external sources, the server does not perform any OSCORE 3323 processing on it. This opens for replying to the proxy with an 3324 unprotected response, although not signaling any OSCORE-related 3325 error. 3327 9. The server starts the group observation and replies with an 3328 error response, i.e., the usual 5.03 informative response, 3329 including: the transport information, the phantom request, and 3330 (optionally) the latest notification. 3332 10. From the received 5.03 response, the proxy retrieves everything 3333 needed to set itself as an observer in the group observation, 3334 and it starts listening to multicast notifications. If the 5.03 3335 response included a latest notification, the proxy caches it and 3336 forwards it back to the client, otherwise it replies with an 3337 empty ACK (if it has not done it already and the request from 3338 the client was Confirmable). 3340 11. Like in the case with a non-deterministic phantom request 3341 considered in Section 10, the proxy fans out the multicast 3342 notifications to the origin clients as they come. Also, as new 3343 clients following the first one contact the proxy, this does not 3344 have to contact the server again as in Section 10, since the 3345 deterministic phantom request would produce a cache hit as per 3346 [I-D.amsuess-core-cachable-oscore]. Thus, the proxy can serve 3347 such clients with the latest fresh multicast notification from 3348 its cache. 3350 G.2. Message Exchange 3352 The same assumptions and notation used in Section 8 are used for this 3353 example. As a recap of some specific value: 3355 * Two clients C_1 and C_2 register to observe a resource /r at a 3356 Server S, which has address SRV_ADDR and listens to the port 3357 number SRV_PORT. Before the following exchanges occur, no clients 3358 are observing the resource /r , which has value "1234". 3360 * The server S sends multicast notifications to the IP multicast 3361 address GRP_ADDR and port number GRP_PORT, and starts the group 3362 observation upon receiving a registration request from a first 3363 client that wishes to start a traditional observation on the 3364 resource /r. 3366 * S is a member of the OSCORE group with 'kid context' = 0x57ab2e as 3367 Group ID. In the OSCORE group, S has 'kid' = 0x05 as Sender ID, 3368 and SN_5 = 501 as Sender Sequence Number. 3370 In addition: 3372 * The proxy has address PRX_ADDR and listens to the port number 3373 PRX_PORT. 3375 * The deterministic client in the OSCORE group has 'kid' = 0x09. 3377 Unless explicitly indicated, all messages transmitted on the wire are 3378 sent over unicast and protected with Group OSCORE end-to-end between 3379 a client and the server. 3381 C1 C2 P S 3382 | | | | 3383 | | | | (The value of the resource /r is "1234") 3384 | | | | 3385 | | | | (The server prepares a deterministic 3386 | | | | phantom request PH_REQ. The server 3387 | | | | stores PH_REQ locally and makes it 3388 | | | | available at an external source) 3389 | | | | 3390 | | | | (C1 obtains PH_REQ and sends it to P) 3391 | | | | 3392 | | | | 3393 +-------------->| | Token: 0x4a 3394 | FETCH | | | Uri-Host: sensor.example 3395 | | | | Observe: 0 (Register) 3396 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3397 | | | | kid context: 0x57ab2e ; ... } 3398 | | | | Proxy-Scheme: coap 3399 | | | | 3400 | | | | 0xff 3401 | | | | Encrypted_payload { 3402 | | | | 0x01 (GET), 3403 | | | | Observe: 0 (Register), 3404 | | | | Uri-Path: r, 3405 | | | | 3406 | | | | } 3407 | | | | 3408 | | +-------->| Token: 0x5e 3409 | | | FETCH | Uri-Host: sensor.example 3410 | | | | Observe: 0 (Register) 3411 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3412 | | | | kid context: 0x57ab2e ; ... } 3413 | | | | 3414 | | | | 0xff 3415 | | | | Encrypted_payload { 3416 | | | | 0x01 (GET), 3417 | | | | Observe: 0 (Register), 3418 | | | | Uri-Path: r, 3419 | | | | 3420 | | | | } 3421 | | | | 3422 | | | | (S recognizes PH_REQ through byte-by-byte 3423 | | | | comparison against the stored one, and 3424 | | | | skips any OSCORE processing) 3425 | | | | 3426 | | | | (S allocates the available 3427 | | | | Token value 0x7b .) 3428 | | | | 3429 | | | | (S sends to itself PH_REQ, with Token 0x7b 3430 | | | | and as coming from the IP multicast 3431 | | | | address GRP_ADDR; now the OSCORE 3432 | | | | processing does happen, as specified 3433 | | | | for a deterministic request) 3434 | | | | 3435 | | | -------| 3436 | | | / | 3437 | | | \------>| Token: 0x7b 3438 | | | FETCH | Uri-Host: sensor.example 3439 | | | | Observe: 0 (Register) 3440 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3441 | | | | kid context: 0x57ab2e ; ... } 3442 | | | | 3443 | | | | 0xff 3444 | | | | Encrypted_payload { 3445 | | | | 0x01 (GET), 3446 | | | | Observe: 0 (Register), 3447 | | | | Uri-Path: r, 3448 | | | | 3449 | | | | } 3450 | | | | 3451 | | | | (S prepares the "last notification" 3452 | | | | response defined below) 3453 | | | | 3454 | | | | 0x45 (2.05 Content) 3455 | | | | Observe: 10 3456 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} 3457 | | | | Max-Age: 3000 3458 | | | | 3459 | | | | 0xff 3460 | | | | Encrypted_payload { 3461 | | | | 0x45 (2.05 Content), 3462 | | | | Observe: [empty], 3463 | | | | CBOR_Payload: "1234" 3464 | | | | } 3465 | | | | 3466 | | | | 3467 | | | | (S responds to the proxy with an 3468 | | | | unprotected informative response) 3469 | | | | 3470 | | |<--------| Token: 0x5e 3471 | | | 5.03 | Content-Format: application/ 3472 | | | | informative-response+cbor 3473 | | | | Max-Age: 0 3474 | | | | 0xff, 3475 | | | | CBOR_payload { 3476 | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, 3477 | | | | 0x7b, bstr(GRP_ADDR), 3478 | | | | GRP_PORT], 3479 | | | | last_notif : 3481 | | | | } 3482 | | | | } 3483 | | | | 3484 | | | | (P extracts PH_REQ and starts listening 3485 | | | | to multicast notifications with Token 3486 | | | | 0x7b at GRP_ADDR:GRP_PORT) 3487 | | | | 3488 | | | | (P extracts the "last notification" 3489 | | | | response, caches it and forwards 3490 | | | | it back to C1) 3491 | | | | 3492 |<--------------+ | Token: 0x4a 3493 | 2.05 | | | Observe: 54120 3494 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} 3495 | | | | Max-Age: 2995 3496 | | | | 3497 | | | | 0xff 3498 | | | | Encrypted_payload { 3499 | | | | 0x45 (2.05 Content), 3500 | | | | Observe: [empty], 3501 | | | | CBOR_Payload: "1234" 3502 | | | | } 3503 | | | | 3504 | | | | 3505 : : : | 3506 : : : | 3507 : : : | 3508 | | | | 3509 | | | | (C2 obtains PH_REQ and sends it to P) 3510 | | | | 3511 | +------>| | Token: 0x01 3512 | | FETCH | | Uri-Host: sensor.example 3513 | | | | Observe: 0 (Register) 3514 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3515 | | | | kid context: 0x57ab2e; ...} 3516 | | | | Proxy-Scheme: coap 3517 | | | | 3518 | | | | 0xff 3519 | | | | Encrypted_payload { 3520 | | | | 0x01 (GET), 3521 | | | | Observe: 0 (Register), 3522 | | | | Uri-Path: r, 3523 | | | | 3524 | | | | } 3525 | | | | 3526 | | | | (P serves C2 from it cache) 3527 | | | | 3528 | |<------+ | Token: 0x01 3529 | | 2.05 | | Observe: 54120 3530 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} 3531 | | | | Max-Age: 1800 3532 | | | | 3533 | | | | 0xff 3534 | | | | Encrypted_payload { 3535 | | | | 0x45 (2.05 Content), 3536 | | | | Observe: [empty], 3537 | | | | CBOR_Payload: "1234" 3538 | | | | } 3539 | | | | 3540 | | | | 3541 : : : | 3542 : : : | 3543 : : : | 3544 | | | | 3545 | | | | (The value of the resource 3546 | | | | /r changes to "5678".) 3547 | | | | 3548 | | | (*) | 3549 | | |<--------| Token: 0x7b 3550 | | | 2.05 | Observe: 11 3551 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} 3552 | | | | 3553 | | | | 0xff 3554 | | | | Encrypted_payload { 3555 | | | | 0x45 (2.05 Content), 3556 | | | | Observe: [empty], 3557 | | | | Content-Format: application/cbor, 3558 | | | | , 3559 | | | | 0xff, 3560 | | | | CBOR_Payload: "5678" 3561 | | | | } 3562 | | | | 3563 | | | | 3564 | | | | (P updates its cache entry 3565 | | | | with this notification) 3566 | | | | 3567 |<--------------+ | Token: 0x4a 3568 | 2.05 | | | Observe: 54123 3569 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} 3570 | | | | 3571 | | | | 0xff 3572 | | | | (Same Encrypted_payload and signature) 3573 | | | | 3574 | |<------+ | Token: 0x01 3575 | | 2.05 | | Observe: 54123 3576 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} 3577 | | | | 3578 | | | | 0xff 3579 | | | | (Same Encrypted_payload and signature) 3580 | | | | 3582 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 3583 with Group OSCORE end-to-end between the server and the clients. 3585 Appendix H. Document Updates 3587 RFC EDITOR: PLEASE REMOVE THIS SECTION. 3589 H.1. Version -01 to -02 3591 * Clarifications on client rough counting and IP multicast scope. 3593 * The 'ph_req' parameter is optional in the informative response. 3595 * New parameter 'next_not_before' for the informative response. 3597 * Optimization when rekeying the self-managed OSCORE group. 3599 * Security considerations on unsecured multicast notifications. 3601 * Protection of the ticket request sent to a proxy. 3603 * RFC8126 terminology in IANA considerations. 3605 * Editorial improvements. 3607 H.2. Version -00 to -01 3609 * Simplified cancellation of the group observation, without using a 3610 phantom cancellation request. 3612 * Aligned parameter semantics with core-oscore-groupcomm and ace- 3613 key-groupcomm-oscore. 3615 * Clarifications about self-managed OSCORE group and use of 3616 deterministic requests for cacheable OSCORE. 3618 * New example with a proxy, Group OSCORE and a deterministic phantom 3619 request. 3621 * Fixes in the examples and editorial improvements. 3623 Acknowledgments 3625 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 3626 Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander 3627 for their comments and feedback. 3629 The work on this document has been partly supported by VINNOVA and 3630 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 3631 (Grant agreement 952652). 3633 Authors' Addresses 3635 Marco Tiloca 3636 RISE AB 3637 Isafjordsgatan 22 3638 SE-16440 Stockholm Kista 3639 Sweden 3641 Email: marco.tiloca@ri.se 3643 Rikard Höglund 3644 RISE AB 3645 Isafjordsgatan 22 3646 SE-16440 Stockholm Kista 3647 Sweden 3649 Email: rikard.hoglund@ri.se 3651 Christian Amsüss 3652 Hollandstr. 12/4 3653 1020 Vienna 3654 Austria 3656 Email: christian@amsuess.com 3658 Francesca Palombini 3659 Ericsson AB 3660 Torshamnsgatan 23 3661 SE-16440 Stockholm Kista 3662 Sweden 3664 Email: francesca.palombini@ericsson.com