idnits 2.17.00 (12 Aug 2021) /tmp/idnits30118/draft-ietf-core-observe-multicast-notifications-03.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 -(2406): 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 9 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 document date (7 March 2022) is 68 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 (-14) exists of draft-ietf-ace-key-groupcomm-oscore-13 ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-10) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-05) exists of draft-ietf-core-coral-04 == Outdated reference: A later version (-10) exists of draft-ietf-core-href-09 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 7 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: 8 September 2022 7 F. Palombini 8 Ericsson AB 9 7 March 2022 11 Observe Notifications as CoAP Multicast Responses 12 draft-ietf-core-observe-multicast-notifications-03 14 Abstract 16 The Constrained Application Protocol (CoAP) allows clients to 17 "observe" resources at a server, and receive notifications as unicast 18 responses upon changes of the resource state. In some use cases, 19 such as based on publish-subscribe, it would be convenient for the 20 server to send a single notification 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 8 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 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 Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . 16 86 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 87 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 18 88 4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 6. Rough Counting of Clients in the Group Observation . . . . . 21 91 6.1. Multicast-Response-Feedback-Divider Option . . . . . . . 21 92 6.2. Processing on the Client Side . . . . . . . . . . . . . . 22 93 6.3. Processing on the Server Side . . . . . . . . . . . . . . 23 94 6.3.1. Request for Feedback . . . . . . . . . . . . . . . . 23 95 6.3.2. Collection of Feedback . . . . . . . . . . . . . . . 23 96 6.3.3. Processing of Feedback . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . 29 101 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 29 102 7.2.2. Informative Response . . . . . . . . . . . . . . . . 29 103 7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . . . . 32 108 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 32 109 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 36 110 10. Intermediaries Together with End-to-End Security . . . . . . 38 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 . . . . . . . . . . . . . . . . . . . 43 116 13.1. Unsecured Multicast Notifications . . . . . . . . . . . 43 117 13.2. Secured Multicast Notifications . . . . . . . . . . . . 44 118 13.3. Listen-To-Multicast-Responses Option . . . . . . . . . . 44 119 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 120 14.1. Media Type Registrations . . . . . . . . . . . . . . . . 45 121 14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 46 122 14.3. CoAP Option Numbers Registry . . . . . . . . . . . . . . 46 123 14.4. Informative Response Parameters Registry . . . . . . . . 47 124 14.5. CoAP Transport Information Registry . . . . . . . . . . 47 125 14.6. Expert Review Instructions . . . . . . . . . . . . . . . 48 126 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 127 15.1. Normative References . . . . . . . . . . . . . . . . . . 49 128 15.2. Informative References . . . . . . . . . . . . . . . . . 51 129 Appendix A. Different Sources for Group Observation Data . . . . 54 130 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 54 131 A.2. Introspection at the Multicast Notification Sender . . . 55 132 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 56 133 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 56 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 -02 to -03 . . . . . . . . . . . . . . . . . . . 78 145 H.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 78 146 H.3. 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 with a 229 single observer client, as defined in [RFC7641]. 231 * Group observation. A resource observation associated with 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 with that observation, with respect to the (previous 313 hop 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. 356 Typically, this comprises the Token value associated with the 357 group observation, as well as the source and destination 358 addressing information of the related multicast notifications. 359 The CBOR array is formatted as defined in Section 2.2.1. This 360 parameter MUST be included. 362 * 'ph_req', with value the byte serialization of the transport- 363 independent information of the phantom observation request (see 364 Section 2.1), encoded as a CBOR byte string. The value of the 365 CBOR byte string is formatted as defined in Section 2.2.2. 367 This parameter MAY be omitted, in case the phantom request is, in 368 terms of transport-independent information, identical to the 369 registration request from the client. Otherwise, this parameter 370 MUST be included. 372 Note that the registration request from the client may indeed 373 differ from the phantom observation request in terms of transport- 374 independent information, but still be acceptable for the server to 375 register the client as taking part in the group observation. 377 * 'last_notif', with value the byte serialization of the transport- 378 independent information of the latest multicast notification for 379 the target resource, encoded as a CBOR byte string. The value of 380 the CBOR byte string is formatted as defined in Section 2.2.2. 381 This parameter MAY be included. 383 * 'next_not_before', with value the amount of seconds that will 384 minimally elapse before the server sends the next multicast 385 notification for the group observation of the target resource, 386 encoded as a CBOR unsigned integer. This parameter MAY be 387 included. 389 This information can help a new client to align itself with the 390 server's timeline, especially in scenarios where multicast 391 notifications are regularly sent. Also, it can help synchronizing 392 different clients when orchestrating a content distribution 393 through multicast notifications. 395 The CDDL notation [RFC8610] provided below describes the payload of 396 the informative response. 398 informative_response_payload = { 399 0 => array, ; 'tp_info', i.e., transport-specific information 400 ? 1 => bstr, ; 'ph_req' (transport-independent information) 401 ? 2 => bstr ; 'last_notif' (transport-independent information) 402 ? 3 => uint ; 'next_not_before' 403 } 405 Figure 1: Format of the informative response payload 407 Upon receiving a registration request to observe the target resource, 408 the server does not create a corresponding individual observation for 409 the requesting client. Instead, the server considers that client as 410 now taking part in the group observation of the target resource, of 411 which it increments the observer counter by 1. Then, the server 412 replies to the client with the same informative response message 413 defined above, which MUST be Confirmable. 415 Note that this also applies when, with no ongoing traditional 416 observations on the target resource, the server receives a 417 registration request from a first client and decides to start a group 418 observation on the target resource. 420 2.2.1. Encoding of Transport-Specific Message Information 422 [ This encoding might be replaced by CRIs [I-D.ietf-core-href] in a 423 later version of this document. ] 425 The CBOR array specified in the 'tp_info' parameter is formatted 426 according to the following CDDL notation. 428 tp_info = [ 429 srv_addr ; Addressing information of the server 430 ? req_info ; Request data extension 431 ] 433 srv_addr = ( 434 tp_id : int, ; Identifier of the used transport protocol 435 + elements ; Number, format and encoding 436 ; based on the value of 'tp_id' 437 ) 439 req_info = ( 440 + elements ; Number, format and encoding based on 441 ; the value of 'tp_id' in 'srv_addr' 442 ) 444 Figure 2: General format of 'tp_info' 446 The 'srv_addr' element of 'tp_info' specifies the addressing 447 information of the server, and includes at least one element 'tp_id' 448 which is formatted as follows. 450 * 'tp_id' : this element is a CBOR integer, which specifies the 451 transport protocol used to transport the CoAP response from the 452 server, i.e., a multicast notification in this document. 454 This element takes value from the "Value" column of the "CoAP 455 Transport Information" registry defined in Section 14.5 of this 456 document. This element MUST be present. The value of this 457 element determines: 459 - How many elements are required to follow in 'srv_addr', as well 460 as what information they convey, their encoding and their 461 semantics. 463 - How many elements are required in the 'req_info' element of the 464 'tp_info' array, as well as what information they convey, their 465 encoding and their semantics. 467 This document registers the integer value 1 ("UDP") to be used as 468 value for the 'tp_id' element, when CoAP responses are transported 469 over UDP. In such a case, the full encoding of the 'tp_info' CBOR 470 array is as defined in Section 2.2.1.1. 472 Future specifications that consider CoAP multicast notifications 473 transported over different transport protocols MUST: 475 - Register an entry with an integer value to be used for 'tp_id', 476 in the "CoAP Transport Information" registry defined in 477 Section 14.5 of this document. 479 - Accordingly, define the elements of the 'tp_info' CBOR array, 480 i.e., the elements following 'tp_id' in 'srv_addr' as well as 481 the elements in 'req_info', as to what information they convey, 482 their encoding and their semantics. 484 The 'req_info' element of 'tp_info' specifies transport-specific 485 information related to a pertinent request message, i.e., the phantom 486 observation request in this document. The exact format of 'req_info' 487 depends on the value of 'tp_id'. 489 Given a specific value of 'tp_id', the complete set of elements 490 composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is 491 indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP 492 Transport Information" registry defined in Section 14.5, 493 respectively. 495 2.2.1.1. UDP Transport-Specific Information 497 When CoAP multicast notifications are transported over UDP as per 498 [RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the 499 integer value 1 ("UDP") as value of 'tp_id' in the 'srv_addr' element 500 of the 'tp_info' CBOR array in the error informative response. Then, 501 the rest of the 'tp_info' CBOR array is defined as follows. 503 * 'srv_addr' includes two more elements following 'tp_id': 505 - 'srv_host': this element is a CBOR byte string, with value the 506 destination IP address of the phantom observation request. 507 This parameter is tagged and identified by the CBOR tag 260 508 "Network Address (IPv4 or IPv6 or MAC Address)". That is, the 509 value of the CBOR byte string is the IP address SRV_ADDR of the 510 server hosting the target resource, from where the server will 511 send multicast notifications for the target resource. This 512 element MUST be present. 514 - 'srv_port': this element is a CBOR unsigned integer, with value 515 the destination port number of the phantom observation request. 516 That is, the specified value is the port number SRV_PORT, from 517 where the server will send multicast notifications for the 518 target resource. This element MUST be present. 520 * 'req_info' includes the following elements: 522 - 'token': this element is a CBOR byte string, with value the 523 Token value of the phantom observation request generated by the 524 server (see Section 2.1). Note that the same Token value is 525 used for the multicast notifications bound to that phantom 526 observation request (see Section 2.3). This element MUST be 527 present. 529 - 'cli_addr': this element is a CBOR byte string, with value the 530 source IP address of the phantom observation request. This 531 parameter is tagged and identified by the CBOR tag 260 "Network 532 Address (IPv4 or IPv6 or MAC Address)". That is, the value of 533 the CBOR byte string is the IP multicast address GRP_ADDR, 534 where the server will send multicast notifications for the 535 target resource. This element MUST be present. 537 - 'cli_port': this element is a CBOR unsigned integer, with value 538 the source port number of the phantom observation request. 539 That is, the specified value is the port number GRP_PORT, where 540 the server will send multicast notifications for the target 541 resource. This element is OPTIONAL. If not included, the 542 default port number 5683 is assumed. 544 The CDDL notation provided below describes the full 'tp_info' CBOR 545 array using the format above. 547 tp_info = [ 548 tp_id : 1, ; UDP as transport protocol 549 srv_host : #6.260(bstr), ; Src. address of multicast notifications 550 srv_port : uint, ; Src. port of multicast notifications 551 token : bstr, ; Token of the phantom request and 552 ; associated multicast notifications 553 cli_addr : #6.260(bstr), ; Dst. address of multicast notifications 554 ? cli_port : uint ; Dst. port of multicast notifications 555 ] 557 Figure 3: Format of 'tp_info' with UDP as transport protocol 559 2.2.2. Encoding of Transport-Independent Message Information 561 For both the parameters 'ph_req' and 'last_notif' in the informative 562 response, the value of the byte string is the concatenation of the 563 following components, in the order specified below. 565 When defining the value of each component, "CoAP message" refers to 566 the phantom observation request for the 'ph_req' parameter, and to 567 the corresponding latest multicast notification for the 'last_notif' 568 parameter. 570 * A single byte, with value the content of the Code field in the 571 CoAP message. 573 * The byte serialization of the complete sequence of CoAP options in 574 the CoAP message. 576 * If the CoAP message includes a non-zero length payload, the one- 577 byte Payload Marker (0xff) followed by the payload. 579 2.3. Notifications 581 Upon a change in the status of the target resource under group 582 observation, the server sends a multicast notification, intended to 583 all the clients taking part in the group observation of that 584 resource. In particular, each of such multicast notifications is 585 formatted as follows. 587 * It MUST be Non-confirmable. 589 * It MUST include an Observe option, as per [RFC7641]. 591 * It MUST have the same Token value T of the phantom registration 592 request that started the group observation. This Token value is 593 specified in the 'token' element of 'req_info' under the 'tp_info' 594 parameter, in the informative response message sent to all the 595 observer clients. 597 That is, every multicast notification for a target resource is not 598 bound to the observation requests from the different clients, but 599 rather to the phantom registration request associated with the 600 whole set of clients taking part in the group observation of that 601 resource. 603 * It MUST be sent from the same IP address SRV_ADDR and port number 604 SRV_PORT where: i) the original Observe registration requests are 605 sent to by the clients; and ii) the corresponding informative 606 responses are sent from by the server (see Section 2.2). These 607 are indicated to the observer clients as value of the 'srv_host' 608 and 'srv_port' elements of 'srv_addr' under the 'tp_info' 609 parameter, in the informative response message (see 610 Section 2.2.1.1). That is, redirection MUST NOT be used. 612 * It MUST be sent to the IP multicast address GRP_ADDR and port 613 number GRP_PORT. These are indicated to the observer clients as 614 value of the 'cli_addr' and 'cli_port' elements of 'req_info' 615 under the 'tp_info' parameter, in the informative response message 616 (see Section 2.2.1.1). 618 For each target resource with an active group observation, the server 619 MUST store the latest multicast notification. 621 2.4. Congestion Control 623 In order to not cause congestion, the server should conservatively 624 control the sending of multicast notifications. In particular: 626 * The multicast notifications MUST be Non-confirmable. 628 * In constrained environments such as low-power, lossy networks 629 (LLNs), the server should only support multicast notifications for 630 resources that are small. Following related guidelines from 631 Section 3.6 of [I-D.ietf-core-groupcomm-bis], this can consist, 632 for example, in having the payload of multicast notifications as 633 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 634 size, so that it fits into a single link-layer frame in case IPv6 635 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 636 Section 4 of [RFC4944]) is used. 638 * The server SHOULD provide multicast notifications with the 639 smallest possible IP multicast scope that fulfills the application 640 needs. For example, following related guidelines from Section 3.6 641 of [I-D.ietf-core-groupcomm-bis], site-local scope is always 642 preferred over global scope IP multicast, if this fulfills the 643 application needs. Similarly, realm-local scope is always 644 preferred over site-local scope, if this fulfills the application 645 needs. Ultimately, it is up to the server administrator to 646 explicitly configure the most appropriate IP multicast scope. 648 * Following related guidelines from Section 4.5.1 of [RFC7641], the 649 server SHOULD NOT send more than one multicast notification every 650 3 seconds, and SHOULD use an even less aggressive rate when 651 possible (see also Section 3.1.2 of [RFC8085]). The transmission 652 rate of multicast notifications should also take into account the 653 avoidance of a possible "broadcast storm" problem [MOBICOM99]. 654 This prevents a following, considerable increase of the channel 655 load, whose origin would be likely attributed to a router rather 656 than the server. 658 2.5. Cancellation 660 At any point in time, the server may want to cancel a group 661 observation of a target resource. For instance, the server may 662 realize that no clients or not enough clients are interested in 663 taking part in the group observation anymore. A possible approach 664 that the server can use to assess this is defined in Section 6. 666 In order to cancel the group observation, the server sends a 667 multicast response with response code 5.03 (Service Unavailable), 668 signaling that the group observation has been terminated. The 669 response has the same Token value T of the phantom registration 670 request, it has no payload, and it does not include an Observe 671 option. 673 The server sends the response to the same multicast IP address 674 GRP_ADDR and port number GRP_PORT used to send the multicast 675 notifications related to the target resource. Finally, the server 676 releases the resources allocated for the group observation, and 677 especially frees up the Token value T used at its CoAP endpoint. 679 3. Client-Side Requirements 681 3.1. Request 683 A client sends an observation request to the server as described in 684 [RFC7641], i.e., a GET request with an Observe option set to 0 685 (register). The request MUST NOT encode link-local addresses. If 686 the server is not configured to accept registrations on that target 687 resource with a group observation, this would still result in a 688 positive notification response to the client as described in 689 [RFC7641]. 691 In a particular setup, the information typically specified in the 692 'tp_info' parameter of the informative response (see Section 2.2) can 693 be preconfigured on the server and the clients. For example, the 694 destination multicast address and port number where to send multicast 695 notifications for a group observation, as well as the associated 696 Token value to use, can be set aside for particular tasks (e.g., 697 enforcing observations of a specific resource). Alternative 698 mechanisms can rely on using some bytes from the hash of the 699 observation request as the last bytes of the multicast address or as 700 part of the Token value. 702 In such a particular setup, the client may also have an early 703 knowledge of the phantom request, i.e., it will be possible for the 704 server to safely omit the parameter 'ph_req' from the informative 705 response to the observation request (see Section 2.2). In this case, 706 the client can include a No-Response option [RFC7967] with value 16 707 in its Observe registration request, which results in the server 708 suppressing the informative response. As a consequence, the 709 observation request only informs the server that there is one 710 additional client interested to take part in the group observation. 711 This still helps the server to assess the current number of clients 712 interested in a group observation (e.g., by using the method defined 713 in Section 6), which in turn can play a role in deciding to cancel 714 the group observation. 716 3.2. Informative Response 718 Upon receiving the informative response defined in Section 2.2, the 719 client proceeds as follows. 721 1. The client configures an observation of the target resource. To 722 this end, it relies on a CoAP endpoint used for messages having: 724 * As source address and port number, the server address SRV_ADDR 725 and port number SRV_PORT intended for accessing the target 726 resource. These are specified as value of the 'srv_host' and 727 'srv_port' elements of 'srv_addr' under the 'tp_info' 728 parameter, in the informative response (see Section 2.2.1.1). 730 * As destination address and port number, the IP multicast 731 address GRP_ADDR and port number GRP_PORT. These are 732 specified as value of the 'cli_addr' and 'cli_port' elements 733 of 'req_info' under the 'tp_info' parameter, in the 734 informative response (see Section 2.2.1.1). If the 'cli_port' 735 element is omitted in 'req_info', the client MUST assume the 736 default port number 5683 as GRP_PORT. 738 2. The client rebuilds the phantom registration request as follows. 740 * The client uses the Token value T, specified in the 'token' 741 element of 'req_info' under the 'tp_info' parameter of the 742 informative response. 744 * If the 'ph_req' parameter is not present in the informative 745 response, the client uses the transport-independent 746 information from its original Observe registration request. 748 * If the 'ph_req' parameter is present in the informative 749 response, the client uses the transport-independent 750 information specified in the parameter. 752 3. If the informative response includes the parameter 'ph_req', and 753 the transport-independent information specified therein differs 754 from the one in the original Observe registration request, then 755 the client checks whether a response to the rebuilt phantom 756 request can, if available in a cache entry, be used to satisfy 757 the original observation request. In case no such response is 758 available, the client SHOULD explicitly withdraw from the group 759 observation. 761 4. The client stores the phantom registration request, as associated 762 with the observation of the target resource. In particular, the 763 client MUST use the Token value T of this phantom registration 764 request as its own local Token value associated with that group 765 observation, with respect to the server. The particular way to 766 achieve this is implementation specific. 768 5. If the informative response includes the parameter 'last_notif', 769 the client rebuilds the latest multicast notification, by using: 771 * The transport-independent information, specified in the 772 'last_notif' parameter of the informative response. 774 * The Token value T, specified in the 'token' element of 775 'req_info' under the 'tp_info' parameter of the informative 776 response. 778 6. If the informative response includes the parameter 'last_notif', 779 the client processes the multicast notification rebuilt at step 5 780 as defined in Section 3.2 of [RFC7641]. In particular, the value 781 of the Observe option is used as initial baseline for 782 notification reordering in this group observation. 784 7. If a traditional observation to the target resource is ongoing, 785 the client MAY silently cancel it without notifying the server. 787 If any of the expected fields in the informative response are not 788 present or malformed, the client MAY try sending a new registration 789 request to the server (see Section 3.1). Otherwise, the client 790 SHOULD explicitly withdraw from the group observation. 792 Appendix A describes possible alternative ways for clients to 793 retrieve the phantom registration request and other information 794 related to a group observation. 796 3.3. Notifications 798 After having successfully processed the informative response as 799 defined in Section 3.2, the client will receive, accept and process 800 multicast notifications about the state of the target resource from 801 the server, as responses to the phantom registration request and with 802 Token value T. 804 The client relies on the value of the Observe option for notification 805 reordering, as defined in Section 3.4 of [RFC7641]. 807 3.4. Cancellation 809 At a certain point in time, a client may become not interested in 810 receiving further multicast notifications about a target resource. 811 When this happens, the client can simply "forget" about being part of 812 the group observation for that target resource, as per Section 3.6 of 813 [RFC7641]. 815 When, later on, the server sends the next multicast notification, the 816 client will not recognize the Token value T in the message. Since 817 the multicast notification is Non-confirmable, it is OPTIONAL for the 818 client to reject the multicast notification with a Reset message, as 819 defined in Section 3.5 of [RFC7641]. 821 In case the server has canceled a group observation as defined in 822 Section 2.5, the client simply forgets about the group observation 823 and frees up the used Token value T for that endpoint, upon receiving 824 the multicast error response defined in Section 2.5. 826 4. Web Linking 828 The possible use of multicast notifications in a group observation 829 may be indicated by a target "grp_obs" attribute in a web link 830 [RFC8288] to a resource, e.g., using a link-format document 831 [RFC6690]. 833 The "grp_obs" attribute is a hint, indicating that the server might 834 send multicast notifications for observations of the resource 835 targeted by the link. Note that this is simply a hint, i.e., it does 836 not include any information required to participate in a group 837 observation, and to receive and process multicast notifications. 839 A value MUST NOT be given for the "grp_obs" attribute; any present 840 value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT 841 appear more than once in a given link-value; occurrences after the 842 first MUST be ignored by parsers. 844 The example in Figure 4 shows a use of the "grp_obs" attribute: the 845 client does resource discovery on a server and gets back a list of 846 resources, one of which includes the "grp_obs" attribute indicating 847 that the server might send multicast notifications for observations 848 of that resource. The link-format notation (see Section 5 of 849 [RFC6690]) is used. 851 REQ: GET /.well-known/core 853 RES: 2.05 Content 854 ;grp_obs, 855 ;if="sensor" 857 Figure 4: The Web Link 859 5. Example 861 The following example refers to two clients C_1 and C_2 that register 862 to observe a resource /r at a Server S, which has address SRV_ADDR 863 and listens to the port number SRV_PORT. Before the following 864 exchanges occur, no clients are observing the resource /r , which has 865 value "1234". 867 The server S sends multicast notifications to the IP multicast 868 address GRP_ADDR and port number GRP_PORT, and starts the group 869 observation upon receiving a registration request from a first client 870 that wishes to start a traditional observation on the resource /r. 872 The following notation is used for the payload of the informative 873 responses: 875 * 'bstr(X)' denotes a CBOR byte string with value the byte 876 serialization of X, with '|' denoting byte concatenation. 878 * 'OPT' denotes a sequence of CoAP options. This refers to the 879 phantom registration request encoded by the 'ph_req' parameter, or 880 to the corresponding latest multicast notification encoded by the 881 'last_notif' parameter. 883 * 'PAYLOAD' denotes a CoAP payload. This refers to the latest 884 multicast notification encoded by the 'last_notif' parameter. 886 C_1 ----------------- [ Unicast ] ------------------------> S /r 887 | GET | 888 | Token: 0x4a | 889 | Observe: 0 (Register) | 890 | | 891 | | 892 | (S allocates the available Token value 0x7b .) | 893 | | 894 | (S sends to itself a phantom observation request PH_REQ | 895 | as coming from the IP multicast address GRP_ADDR .) | 896 | ------------------------------------------------ | 897 | / | 898 | \----------------------------------------------------> | /r 899 | GET | 900 | Token: 0x7b | 901 | Observe: 0 (Register) | 902 | | 903 | | 904 | (S creates a group observation of /r .) | 905 | | 906 | (S increments the observer counter | 907 | for the group observation of /r .) | 908 | | 909 C_1 <-------------------- [ Unicast ] --------------------- S 910 | 5.03 | 911 | Token: 0x4a | 912 | Content-Format: application/informative-response+cbor | 913 | Max-Age: 0 | 914 | | 915 | Payload: { | 916 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 917 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 918 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 919 | } | 920 | | 921 C_2 ----------------- [ Unicast ] ------------------------> S /r 922 | GET | 923 | Token: 0x01 | 924 | Observe: 0 (Register) | 925 | | 926 | | 927 | (S increments the observer counter | 928 | for the group observation of /r .) | 929 | | 930 C_2 <-------------------- [ Unicast ] --------------------- S 931 | 5.03 | 932 | Token: 0x01 | 933 | Content-Format: application/informative-response+cbor | 934 | Max-Age: 0 | 935 | | 936 | Payload: { | 937 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 938 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 939 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 940 | } | 941 | | 942 | (The value of the resource /r changes to "5678".) | 943 | | 944 C_1 | 945 + <------------------- [ Multicast ] -------------------- S 946 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 947 | 2.05 | 948 | Token: 0x7b | 949 | Observe: 11 | 950 | Content-Format: application/cbor | 951 | | 952 | Payload: : "5678" | 953 | | 955 Figure 5: Example of group observation 957 6. Rough Counting of Clients in the Group Observation 959 This section specifies a method that the server can use to keep an 960 estimate of still active and interested clients, without creating 961 undue traffic on the network. 963 6.1. Multicast-Response-Feedback-Divider Option 965 In order to enable the rough counting of still active and interested 966 clients, a new CoAP option is introduced, which SHOULD be supported 967 by clients that listen to multicast responses. 969 The option is called Multicast-Response-Feedback-Divider. As 970 summarized in Figure 6, the option is not Critical, not Safe-to- 971 Forward, and integer valued. Since the option is not Safe-to- 972 Forward, the column "N" indicates a dash for "not applicable". 974 +-----+---+---+---+---+---------------------+--------+------+---------+ 975 | No. | C | U | N | R | Name | Format | Len. | Default | 976 +-----+---+---+---+---+---------------------+--------+------+---------+ 977 | TBD | | x | - | | Multicast-Response- | uint | 0-1 | (none) | 978 | | | | | | Feedback-Divider | | | | 979 +-----+---+---+---+---+---------------------+--------+------+---------+ 981 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 983 Figure 6: Multicast-Response-Feedback-Divider 985 The Multicast-Response-Feedback-Divider option is of class E for 986 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 988 6.2. Processing on the Client Side 990 Upon receiving a response with a Multicast-Response-Feedback-Divider 991 option, a client SHOULD acknowledge its interest in continuing 992 receiving multicast notifications for the target resource, as 993 described below. 995 The client picks an integer random number I, from 0 inclusive to the 996 number Z = (2 ** Q) exclusive, where Q is the value specified in the 997 option and "**" is the exponentiation operator. If I is different 998 than 0, the client takes no further action. Otherwise, the client 999 should wait a random fraction of the Leisure time (see Section 8.2 of 1000 [RFC7252]), and then registers a regular unicast observation on the 1001 same target resource. 1003 To this end, the client essentially follows the steps that got it 1004 originally subscribed to group notifications for the target resource. 1005 In particular, the client sends an observation request to the server, 1006 i.e., a GET request with an Observe option set to 0 (register). The 1007 request MUST be addressed to the same target resource, and MUST have 1008 the same destination IP address and port number used for the original 1009 registration request, regardless the source IP address and port 1010 number of the received multicast notification. 1012 Since the Observe registration is only done for its side effect of 1013 showing as an attempted observation at the server, the client MUST 1014 send the unicast request in a non confirmable way, and with the 1015 maximum No-Response setting [RFC7967]. In the request, the client 1016 MUST include a Multicast-Response-Feedback-Divider option, whose 1017 value MUST be empty (Option Length = 0). The client does not need to 1018 wait for responses, and can keep processing further notifications on 1019 the same Token. 1021 The client MUST ignore the Multicast-Response-Feedback-Divider 1022 option, if the multicast notification is retrieved from the 1023 'last_notif' parameter of an informative response (see Section 2.2). 1024 A client includes the Multicast-Response-Feedback-Divider option only 1025 in a re-registration request triggered by the server as described 1026 above, and MUST NOT include it in any other request. 1028 As the Multicast-Response-Feedback-Divider option is unsafe to 1029 forward, a proxy needs to answer it on its own, and is later counted 1030 as a single client. 1032 Appendix B.1 and Appendix B.2 provide a description in pseudo-code of 1033 the operations above performed by the client. 1035 6.3. Processing on the Server Side 1037 In order to avoid needless use of network resources, a server SHOULD 1038 keep a rough, updated count of the number of clients taking part in 1039 the group observation of a target resource. To this end, the server 1040 updates the value COUNT of the associated observer counter (see 1041 Section 2), for instance by using the method described below. 1043 6.3.1. Request for Feedback 1045 When it wants to obtain a new estimated count, the server considers a 1046 number M of confirmations it would like to receive from the clients. 1047 It is up to applications to define policies about how the server 1048 determines and possibly adjusts the value of M. 1050 Then, the server computes the value Q = max(L, 0), where: 1052 * L is computed as L = ceil(log2(N / M)). 1054 * N is the current value of the observer counter, possibly rounded 1055 up to 1, i.e., N = max(COUNT, 1). 1057 Finally, the server sets Q as the value of the Multicast-Response- 1058 Feedback-Divider option, which is sent within a successful multicast 1059 notification. 1061 If several multicast notifications are sent in a burst fashion, it is 1062 RECOMMENDED for the server to include the Multicast-Response- 1063 Feedback-Divider option only in the first one of those notifications. 1065 6.3.2. Collection of Feedback 1067 The server collects unicast observation requests from the clients, 1068 for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this 1069 time, the server regularly increments the observer counter when 1070 adding a new client to the group observation (see Section 2.2). 1072 It is up to applications to define the value of 1073 MAX_CONFIRMATION_WAIT, which has to take into account the 1074 transmission time of the multicast notification and of unicast 1075 observation requests, as well as the leisure time of the clients, 1076 which may be hard to know or estimate for the server. 1078 If this information is not known to the server, it is recommended to 1079 define MAX_CONFIRMATION_WAIT as follows. 1081 MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY 1082 where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has 1083 default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is 1084 equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 3.1.5 of 1085 [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In 1086 the absence of more specific information, the server can thus 1087 consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. 1089 If more information is available in deployments, a much shorter 1090 MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic 1091 round trip time (replacing MAX_RTT) and on the largest leisure time 1092 configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g., 1093 DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to 1094 a few seconds. 1096 6.3.3. Processing of Feedback 1098 Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the 1099 R confirmations arrived as unicast observation requests to the target 1100 resource, since the multicast notification with the Multicast- 1101 Response-Feedback-Divider option has been sent. In particular, the 1102 server considers a unicast observation request as a confirmation from 1103 a client only if it includes a Multicast-Response-Feedback-Divider 1104 option with an empty value (Option Length = 0). 1106 Then, the server computes a feedback indicator as E = R * (2 ** Q), 1107 where "**" is the exponentiation operator. According to what defined 1108 by application policies, the server determines the next time when to 1109 ask clients for their confirmation, e.g., after a certain number of 1110 multicast notifications has been sent. For example, the decision can 1111 be influenced by the reception of no confirmations from the clients, 1112 i.e., R = 0, or by the value of the ratios (E/N) and (N/E). 1114 Finally, the server computes a new estimated count of the observers. 1115 To this end, the server first consider COUNT' as the current value of 1116 the observer counter at this point in time. Note that COUNT' may be 1117 greater than the value COUNT used at the beginning of this process, 1118 if the server has incremented the observer counter upon adding new 1119 clients to the group observation (see Section 2.2). 1121 In particular, the server computes the new estimated count value as 1122 COUNT' + ((E - N) / D), where D > 0 is an integer value used as 1123 dampener. This step has to be performed atomically. That is, until 1124 this step is completed, the server MUST hold the processing of an 1125 observation request for the same target resource from a new client. 1126 Finally, the server considers the result as the current observer 1127 counter, and assesses it for possibly canceling the group observation 1128 (see Section 2.5). 1130 This estimate is skewed by packet loss, but it gives the server a 1131 sufficiently good estimation for further counts and for deciding when 1132 to cancel the group observation. It is up to applications to define 1133 policies about how the server takes the newly updated estimate into 1134 account and determines whether to cancel the group observation. 1136 As an example, if the server currently estimates that N = COUNT = 32 1137 observers are active and considers a constant M = 8, it sends out a 1138 notification with Multicast-Response-Feedback-Divider: 2. Then, out 1139 of 18 actually active clients, 5 send a re-registration request based 1140 on their random draw, of which one request gets lost, thus leaving 4 1141 re-registration requests received by the server. Also, no new 1142 clients have been added to the group observation during this time, 1143 i.e., COUNT' is equal to COUNT. As a consequence, assuming that a 1144 dampener value D = 1 is used, the server computes the new estimated 1145 count value as 32 + (16 - 32) = 16, and keeps the group observation 1146 active. 1148 To produce a most accurate updated counter, a server can include a 1149 Multicast-Response-Feedback-Divider option with value Q = 0 in its 1150 multicast notifications, as if M is equal to N. This will trigger 1151 all the active clients to state their interest in continuing 1152 receiving notifications for the target resource. Thus, the amount R 1153 of arrived confirmations is affected only by possible packet loss. 1155 Appendix B.3 provides a description in pseudo-code of the operations 1156 above performed by the server, including example behaviors for 1157 scheduling the next count update and deciding whether to cancel the 1158 group observation. 1160 7. Protection of Multicast Notifications with Group OSCORE 1162 A server can protect multicast notifications by using Group OSCORE 1163 [I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected 1164 end-to-end with the observer clients. This requires that both the 1165 server and the clients interested in receiving multicast 1166 notifications from that server are members of the same OSCORE group. 1168 In some settings, the OSCORE group to refer to can be pre-configured 1169 on the clients and the server. In such a case, a server which is 1170 aware of such pre-configuration can simply assume a client to be 1171 already member of the correct OSCORE group. 1173 In any other case, the server MAY communicate to clients what OSCORE 1174 group they are required to join, by providing additional guidance in 1175 the informative response as described in Section 7.1. Note that 1176 clients can already be members of the right OSCORE group, in case 1177 they have previously joined it to securely communicate with the same 1178 server and/or with other servers to access their resources. 1180 Both the clients and the server MAY join the OSCORE group by using 1181 the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and 1182 based on the ACE framework for Authentication and Authorization in 1183 constrained environments [I-D.ietf-ace-oauth-authz]. Further details 1184 on how to discover the OSCORE group and join it are out of the scope 1185 of this document. 1187 If multicast notifications are protected using Group OSCORE, the 1188 original registration requests and related unicast (notification) 1189 responses MUST also be secured, including and especially the 1190 informative responses from the server. 1192 To this end, alternative security protocols than Group OSCORE, such 1193 as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can 1194 be used to protect other exchanges via unicast between the server and 1195 each client, including the original client registration (see 1196 Section 3). 1198 7.1. Signaling the OSCORE Group in the Informative Response 1200 This section describes a mechanism for the server to communicate to 1201 the client what OSCORE group to join in order to decrypt and verify 1202 the multicast notifications protected with Group OSCORE. The client 1203 MAY use the information provided by the server to start the ACE 1204 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 1205 This mechanism is OPTIONAL to support for the client and server. 1207 Additionally to what defined in Section 2, the CBOR map in the 1208 informative response payload contains the following fields, whose 1209 CBOR labels are defined in Section 11. 1211 * 'join_uri', with value the URI for joining the OSCORE group at the 1212 respective Group Manager, encoded as a CBOR text string. If the 1213 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 1214 for joining, this field specifically indicates the URI of the 1215 group-membership resource at the Group Manager. 1217 * 'sec_gp', with value the name of the OSCORE group, encoded as a 1218 CBOR text string. 1220 * Optionally, 'as_uri', with value the URI of the Authorization 1221 Server associated with the Group Manager for the OSCORE group, 1222 encoded as a CBOR text string. 1224 * Optionally, 'hkdf', with value the HKDF Algorithm used in the 1225 OSCORE group, encoded as a CBOR text string or integer. The value 1226 is taken from the 'Value' column of the "COSE Algorithms" registry 1227 [COSE.Algorithms]. 1229 * Optionally, 'cred_fmt', with value the format of the 1230 authentication credentials used in the OSCORE group, encoded as a 1231 CBOR integer. The value is taken from the 'Label' column of the 1232 "COSE Header Parameters" Registry [COSE.Header.Parameters]. 1233 Consistently with Section 2.3 of [I-D.ietf-core-oscore-groupcomm], 1234 acceptable values denote a format that MUST explicitly provide the 1235 comprehensive set of information related to the public key 1236 algorithm, including, e.g., the used elliptic curve (when 1237 applicable). 1239 At the time of writing this specification, acceptable formats of 1240 authentication credentials are CBOR Web Tokens (CWTs) and CWT 1241 Claim Sets (CCSs) [RFC8392], X.509 certificates [RFC7925] and C509 1242 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further formats 1243 may be available in the future, and would be acceptable to use as 1244 long as they comply with the criteria defined above. 1246 [ As to CWTs and unprotected CWT claim sets, there is a pending 1247 registration requested by draft-ietf-lake-edhoc. ] 1249 [ As to C509 certificates, there is a pending registration 1250 requested by draft-ietf-cose-cbor-encoded-cert. ] 1252 * Optionally, 'sign_enc_alg', with value the Signature Encryption 1253 Algorithm used in the OSCORE group to encrypt messages protected 1254 with the group mode, encoded as a CBOR text string or integer. 1255 The value is taken from the 'Value' column of the "COSE 1256 Algorithms" registry [COSE.Algorithms]. 1258 * Optionally, 'sign_alg', with value the Signature Algorithm used to 1259 sign messages in the OSCORE group, encoded as a CBOR text string 1260 or integer. The value is taken from the 'Value' column of the 1261 "COSE Algorithms" registry [COSE.Algorithms]. 1263 * Optionally, 'sign_params', encoded as a CBOR array and including 1264 the following two elements: 1266 - 'sign_alg_capab': a CBOR array, with the same format and value 1267 of the COSE capabilities array for the algorithm indicated in 1268 'sign_alg', as specified for that algorithm in the 1269 'Capabilities' column of the "COSE Algorithms" Registry 1270 [COSE.Algorithms]. 1272 - 'sign_key_type_capab': a CBOR array, with the same format and 1273 value of the COSE capabilities array for the COSE key type of 1274 the keys used with the algorithm indicated in 'sign_alg', as 1275 specified for that key type in the 'Capabilities' column of the 1276 "COSE Key Types" Registry [COSE.Key.Types]. 1278 The values of 'sign_alg', 'sign_params' and 'cred_fmt' provide an 1279 early knowledge of the format of authentication credentials as well 1280 as of the type of public keys used in the OSCORE group. Thus, the 1281 client does not need to ask the Group Manager for this information as 1282 a preliminary step before the (ACE) join process, or to perform a 1283 trial-and-error exchange with the Group Manager upon joining the 1284 group. Hence, the client is able to provide the Group Manager with 1285 its own authentication credential in the correct expected format and 1286 including a public key of the correct expected type, at the very 1287 first step of the (ACE) join process. 1289 The values of 'hkdf', 'sign_enc_alg' and 'sign_alg' provide an early 1290 knowledge of the algorithms used in the OSCORE group. Thus, the 1291 client is able to decide whether to actually proceed with the (ACE) 1292 join process, depending on its support for the indicated algorithms. 1294 As mentioned above, since this mechanism is OPTIONAL, all the fields 1295 are OPTIONAL in the informative response. However, the 'join_uri' 1296 and 'sec_gp' fields MUST be present if the mechanism is implemented 1297 and used. If any of the fields are present without the 'join_uri' 1298 and 'sec_gp' fields present, the client MUST ignore these fields, 1299 since they would not be sufficient to start the (ACE) join procedure. 1300 When this happens, the client MAY try sending a new registration 1301 request to the server (see Section 3.1). Otherwise, the client 1302 SHOULD explicitly withdraw from the group observation. 1304 Appendix C describes a possible alternative approach, where the 1305 server self-manages the OSCORE group, and provides the observer 1306 clients with the necessary keying material in the informative 1307 response. The approach in Appendix C MUST NOT be used together with 1308 the mechanism defined in this section for indicating what OSCORE 1309 group to join. 1311 7.2. Server-Side Requirements 1313 When using Group OSCORE to protect multicast notifications, the 1314 server performs the operations described in Section 2, with the 1315 following differences. 1317 7.2.1. Registration 1319 The phantom registration request MUST be secured, by using Group 1320 OSCORE. In particular, the group mode of Group OSCORE defined in 1321 Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. 1323 The server protects the phantom registration request as defined in 1324 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the 1325 actual sender, i.e., by using its Sender Context. As a consequence, 1326 the server consumes the current value of its Sender Sequence Number 1327 SN in the OSCORE group, and hence updates it to SN* = (SN + 1). 1328 Consistently, the OSCORE option in the phantom registration request 1329 includes: 1331 * As 'kid', the Sender ID of the server in the OSCORE group. 1333 * As 'piv', the previously consumed Sender Sequence Number value SN 1334 of the server in the OSCORE group, i.e., (SN* - 1). 1336 7.2.2. Informative Response 1338 The value of the CBOR byte string in the 'ph_req' parameter encodes 1339 the phantom observation request as a message protected with Group 1340 OSCORE (see Section 7.2.1). As a consequence: the specified Code is 1341 always 0.05 (FETCH); the sequence of CoAP options will be limited to 1342 the outer, non encrypted options; a payload is always present, as the 1343 authenticated ciphertext followed by the signature. Note that, in 1344 terms of transport-independent information, the registration request 1345 from the client typically differs from the phantom request. Thus, 1346 the server has to include the 'ph_req' parameter in the informative 1347 response. An exception is the case discussed in Appendix D. 1349 Similarly, the value of the CBOR byte string in the 'last_notif' 1350 parameter encodes the latest multicast notification as a message 1351 protected with Group OSCORE (see Section 7.2.3). This applies also 1352 to the initial multicast notification INIT_NOTIF built in step 6 of 1353 Section 2.1. 1355 Optionally, the informative response includes information on the 1356 OSCORE group to join, as additional parameters (see Section 7.1). 1358 7.2.3. Notifications 1360 The server MUST protect every multicast notification for the target 1361 resource with Group OSCORE. In particular, the group mode of Group 1362 OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST 1363 be used. 1365 The process described in Section 8.3 of 1366 [I-D.ietf-core-oscore-groupcomm] applies, with the following 1367 additions when building the two OSCORE 'external_aad' to encrypt and 1368 sign the multicast notification (see Section 4.3 of 1369 [I-D.ietf-core-oscore-groupcomm]). 1371 * The 'request_kid' is the 'kid' value in the OSCORE option of the 1372 phantom registration request, i.e., the Sender ID of the server. 1374 * The 'request_piv' is the 'piv' value in the OSCORE option of the 1375 phantom registration request, i.e., the consumed Sender Sequence 1376 Number SN of the server. 1378 * The 'request_kid_context' is the 'kid context' value in the OSCORE 1379 option of the phantom registration request, i.e., the Group 1380 Identifier value (Gid) of the OSCORE group used as ID Context. 1382 Note that these same values are used to protect each and every 1383 multicast notification sent for the target resource under this group 1384 observation. 1386 7.2.4. Cancellation 1388 When canceling a group observation (see Section 2.5), the multicast 1389 response with error code 5.03 (Service Unavailable) is also protected 1390 with Group OSCORE, as per Section 8.3 of 1391 [I-D.ietf-core-oscore-groupcomm]. The server MUST use its own Sender 1392 Sequence Number as Partial IV to protect the error response, and 1393 include it as Partial IV in the OSCORE option of the response. 1395 7.3. Client-Side Requirements 1397 When using Group OSCORE to protect multicast notifications, the 1398 client performs as described in Section 3, with the following 1399 differences. 1401 7.3.1. Informative Response 1403 Upon receiving the informative response from the server, the client 1404 performs as described in Section 3.2, with the following additions. 1406 When performing step 2, the client expects the 'ph_req' parameter to 1407 be included in the informative response, which is otherwise 1408 considered malformed. An exception is the case discussed in 1409 Appendix D. 1411 Once completed step 2, the client decrypts and verifies the rebuilt 1412 phantom registration request as defined in Section 8.2 of 1413 [I-D.ietf-core-oscore-groupcomm], with the following differences. 1415 * The client MUST NOT perform any replay check. That is, the client 1416 skips step 3 in Section 8.2 of [RFC8613]. 1418 * If decryption and verification of the phantom registration request 1419 succeed: 1421 - The client MUST NOT update the Replay Window in the Recipient 1422 Context associated with the server. That is, the client skips 1423 the second bullet of step 6 in Section 8.2 of [RFC8613]. 1425 - The client MUST NOT take any further process as normally 1426 expected according to [RFC7252]. That is, the client skips 1427 step 8 in Section 8.2 of [RFC8613]. In particular, the client 1428 MUST NOT deliver the phantom registration request to the 1429 application, and MUST NOT take any action in the Token space of 1430 its unicast endpoint, where the informative response has been 1431 received. 1433 - The client stores the values of the 'kid', 'piv' and 'kid 1434 context' fields from the OSCORE option of the phantom 1435 registration request. 1437 * If decryption and verification of the phantom registration request 1438 fail, the client MAY try sending a new registration request to the 1439 server (see Section 3.1). Otherwise, the client SHOULD explicitly 1440 withdraw from the group observation. 1442 After successful decryption and verification, the client performs 1443 step 3 in Section 3.2, considering the decrypted phantom registration 1444 request. 1446 If the informative response includes the parameter 'last_notif', the 1447 client also decrypts and verifies the latest multicast notification 1448 rebuilt at step 5 in Section 3.2, just like it would for the 1449 multicast notifications transmitted as CoAP messages on the wire (see 1450 Section 7.3.2). If decryption and verification succeed, the client 1451 proceeds with step 6, considering the decrypted latest multicast 1452 notification. Otherwise, the client proceeds to step 7. 1454 7.3.2. Notifications 1456 After having successfully processed the informative response as 1457 defined in Section 7.3.1, the client will decrypt and verify every 1458 multicast notification for the target resource as defined in 1459 Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following 1460 difference. 1462 For both decryption and signature verification, the client MUST set 1463 the 'external_aad' defined in Section 4.3 of 1464 [I-D.ietf-core-oscore-groupcomm] as follows. The particular way to 1465 achieve this is implementation specific. 1467 * 'request_kid' takes the value of the 'kid' field from the OSCORE 1468 option of the phantom registration request (see Section 7.3.1). 1470 * 'request_piv' takes the value of the 'piv' field from the OSCORE 1471 option of the phantom registration request (see Section 7.3.1). 1473 * 'request_kid_context' takes the value of the 'kid context' field 1474 from the OSCORE option of the phantom registration request (see 1475 Section 7.3.1). 1477 Note that these same values are used to decrypt and verify each and 1478 every multicast notification received for the target resource. 1480 The replay protection and checking of multicast notifications is 1481 performed as specified in Section 4.1.3.5.2 of [RFC8613]. 1483 8. Example with Group OSCORE 1485 The following example refers to two clients C_1 and C_2 that register 1486 to observe a resource /r at a Server S, which has address SRV_ADDR 1487 and listens to the port number SRV_PORT. Before the following 1488 exchanges occur, no clients are observing the resource /r , which has 1489 value "1234". 1491 The server S sends multicast notifications to the IP multicast 1492 address GRP_ADDR and port number GRP_PORT, and starts the group 1493 observation upon receiving a registration request from a first client 1494 that wishes to start a traditional observation on the resource /r. 1496 Pairwise communication over unicast is protected with OSCORE, while S 1497 protects multicast notifications with Group OSCORE. Specifically: 1499 * C_1 and S have a pairwise OSCORE Security Context. In particular, 1500 C_1 has 'kid' = 0x01 as Sender ID, and SN_1 = 101 as Sender 1501 Sequence Number. Also, S has 'kid' = 0x03 as Sender ID, and SN_3 1502 = 301 as Sender Sequence Number. 1504 * C_2 and S have a pairwise OSCORE Security Context. In particular, 1505 C_2 has 'kid' = 0x02 as Sender ID, and SN_2 = 201 as Sender 1506 Sequence Number. Also, S has 'kid' = 0x04 as Sender ID, and SN_4 1507 = 401 as Sender Sequence Number. 1509 * S is a member of the OSCORE group with name "myGroup", and 'kid 1510 context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' 1511 = 0x05 as Sender ID, and SN_5 = 501 as Sender Sequence Number. 1513 The following notation is used for the payload of the informative 1514 responses: 1516 * 'bstr(X)' denotes a CBOR byte string with value the byte 1517 serialization of X, with '|' denoting byte concatenation. 1519 * 'OPT' denotes a sequence of CoAP options. This refers to the 1520 phantom registration request encoded by the 'ph_req' parameter, or 1521 to the corresponding latest multicast notification encoded by the 1522 'last_notif' parameter. 1524 * 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the 1525 phantom registration request encoded by the 'ph_req' parameter, or 1526 to the corresponding latest multicast notification encoded by the 1527 'last_notif' parameter. 1529 * 'SIGN' denotes the signature appended to an encrypted CoAP 1530 payload. This refers to the phantom registration request encoded 1531 by the 'ph_req' parameter, or to the corresponding latest 1532 multicast notification encoded by the 'last_notif' parameter. 1534 C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1535 | 0.05 (FETCH) | 1536 | Token: 0x4a | 1537 | OSCORE: {kid: 0x01; piv: 101; ...} | 1538 | | 1539 | 0xff | 1540 | Encrypted_payload { | 1541 | 0x01 (GET), | 1542 | Observe: 0 (Register), | 1543 | | 1544 | } | 1545 | | 1546 | (S allocates the available Token value 0x7b .) | 1547 | | 1548 | (S sends to itself a phantom observation request PH_REQ | 1549 | as coming from the IP multicast address GRP_ADDR .) | 1550 | ------------------------------------------------------ | 1551 | / | 1552 | \-------------------------------------------------------> | /r 1553 | 0.05 (FETCH) | 1554 | Token: 0x7b | 1555 | OSCORE: {kid: 0x05 ; piv: 501; | 1556 | kid context: 0x57ab2e; ...} | 1557 | | 1558 | 0xff | 1559 | Encrypted_payload { | 1560 | 0x01 (GET), | 1561 | Observe: 0 (Register), | 1562 | | 1563 | } | 1564 | | 1565 | | 1566 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 1567 | | 1568 | (S creates a group observation of /r .) | 1569 | | 1570 | (S increments the observer counter | 1571 | for the group observation of /r .) | 1572 | | 1573 C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1574 | 2.05 (Content) | 1575 | Token: 0x4a | 1576 | OSCORE: {piv: 301; ...} | 1577 | Max-Age: 0 | 1578 | | 1579 | 0xff | 1580 | Encrypted_payload { | 1581 | 5.03 (Service Unavailable), | 1582 | Content-Format: application/informative-response+cbor, | 1583 | , | 1584 | 0xff, | 1585 | CBOR_payload { | 1586 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1587 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1588 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1589 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1590 | join_uri : "coap://myGM/ace-group/myGroup", | 1591 | sec_gp : "myGroup" | 1592 | } | 1593 | } | 1594 | | 1596 C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1597 | 0.05 (FETCH) | 1598 | Token: 0x01 | 1599 | OSCORE: {kid: 0x02; piv: 201; ...} | 1600 | | 1601 | 0xff | 1602 | Encrypted_payload { | 1603 | 0x01 (GET), | 1604 | Observe: 0 (Register), | 1605 | | 1606 | } | 1607 | | 1608 | (S increments the observer counter | 1609 | for the group observation of /r .) | 1610 | | 1611 C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1612 | 2.05 (Content) | 1613 | Token: 0x01 | 1614 | OSCORE: {piv: 401; ...} | 1615 | Max-Age: 0 | 1616 | | 1617 | 0xff, | 1618 | Encrypted_payload { | 1619 | 5.03 (Service Unavailable), | 1620 | Content-Format: application/informative-response+cbor, | 1621 | , | 1622 | 0xff, | 1623 | CBOR_payload { | 1624 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1625 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1626 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1627 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1628 | join_uri : "coap://myGM/ace-group/myGroup", | 1629 | sec_gp : "myGroup" | 1630 | } | 1631 | } | 1632 | | 1633 | (The value of the resource /r changes to "5678".) | 1634 | | 1635 C_1 | 1636 + <----------- [ Multicast w/ Group OSCORE ] ------------ S 1637 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 1638 | 2.05 (Content) | 1639 | Token: 0x7b | 1640 | OSCORE: {kid: 0x05; piv: 502; ...} | 1641 | | 1642 | 0xff | 1643 | Encrypted_payload { | 1644 | 2.05 (Content), | 1645 | Observe: [empty], | 1646 | Content-Format: application/cbor, | 1647 | , | 1648 | 0xff, | 1649 | CBOR_Payload: "5678" | 1650 | } | 1651 | | 1652 | | 1654 Figure 7: Example of group observation with Group OSCORE 1656 The two external_aad used to encrypt and sign the multicast 1657 notification above have 'request_kid' = 5, 'request_piv' = 501 and 1658 'request_kid_context' = 0x57ab2e. These values are specified in the 1659 'kid', 'piv' and 'kid context' field of the OSCORE option of the 1660 phantom observation request, which is encoded in the 'ph_req' 1661 parameter of the unicast informative response to the two clients. 1662 Thus, the two clients can build the two same external_aad for 1663 decrypting and verifying this multicast notification and the 1664 following ones. 1666 9. Intermediaries 1668 This section specifies how the approach presented in Section 2 and 1669 Section 3 works when a proxy is used between the clients and the 1670 server. In addition to what specified in Section 5.7 of [RFC7252] 1671 and Section 5 of [RFC7641], the following applies. 1673 A client sends its original observation request to the proxy. If the 1674 proxy is not already registered at the server for that target 1675 resource, the proxy forwards the observation request to the server, 1676 hence registering itself as an observer. If the server has an 1677 ongoing group observation for the target resource or decides to start 1678 one, the server considers the proxy as taking part in the group 1679 observation, and replies to the proxy with an informative response. 1681 Upon receiving an informative response, the proxy performs as 1682 specified for the client in Section 3, with the peculiarity that 1683 "consuming" the last notification (if present) means populating its 1684 cache. 1686 In particular, by using the information retrieved from the 1687 informative response, the proxy configures an observation of the 1688 target resource at the origin server, acting as a client directly 1689 taking part in the group observation. 1691 As a consequence, the proxy will listen to the IP multicast address 1692 and port number indicated by the server in the informative response, 1693 as 'cli_addr' and 'cli_port' element of 'req_info' under the 1694 'tp_info' parameter, respectively (see Section 2.2.1.1). 1695 Furthermore, multicast notifications will match the phantom request 1696 stored at the proxy, based on the Token value specified in the 1697 'token' element of 'req_info' under the 'tp_info' parameter in the 1698 informative response. 1700 Then, the proxy performs the following actions. 1702 * If the 'last_notif' field is not present, the proxy responds to 1703 the client with an Empty Acknowledgement (if indicated by the 1704 message type, and if it has not already done so). 1706 * If the 'last_notif' field is present, the proxy rebuilds the 1707 latest multicast notification, as defined in Section 3. Then, the 1708 proxy responds to the client, by forwarding back the latest 1709 multicast notification. 1711 When responding to an observation request from a client, the proxy 1712 also adds that client (and its Token) to the list of its registered 1713 observers for the target resource, next to the older observations. 1715 Upon receiving a multicast notification from the server, the proxy 1716 forwards it back separately to each observer client over unicast. 1717 Note that the notification forwarded back to a certain client has the 1718 same Token value of the original observation request sent by that 1719 client to the proxy. 1721 Note that the proxy configures the observation of the target resource 1722 at the server only once, when receiving the informative response 1723 associated with a (newly started) group observation for that target 1724 resource. 1726 After that, when receiving an observation request from a following 1727 new client to be added to the same group observation, the proxy does 1728 not take any further action with the server. Instead, the proxy 1729 responds to the client either with the latest multicast notification 1730 if available from its cache, or with an Empty Acknowledgement 1731 otherwise, as defined above. 1733 An example is provided in Appendix E. 1735 In the general case with a chain of two or more proxies, every proxy 1736 in the chain takes the role of client with the (next hop towards the) 1737 origin server. Note that the proxy adjacent to the origin server is 1738 the only one in the chain that receives informative responses and 1739 listens to an IP multicast address to receive notifications for the 1740 group observation. Furthermore, every proxy in the chain takes the 1741 role of server with the (previous hop towards the) origin client. 1743 10. Intermediaries Together with End-to-End Security 1745 As defined in Section 7, Group OSCORE can be used to protect 1746 multicast notifications end-to-end between the origin server and the 1747 clients. In such a case, additional actions are required when also 1748 the informative responses from the origin server are protected 1749 specifically end-to-end, by using OSCORE or Group OSCORE. 1751 In fact, the proxy adjacent to the origin server is not able to 1752 access the encrypted payload of such informative responses. Hence, 1753 the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters 1754 necessary to correctly receive multicast notifications and forward 1755 them back to the clients. 1757 Then, differently from what defined in Section 9, each proxy 1758 receiving an informative response simply forwards it back to the 1759 client that has sent the corresponding observation request. Note 1760 that the proxy does not even realize the message to be an actual 1761 informative response, since the outer Code field is set to 2.05 1762 (Content). 1764 Upon receiving the informative response, the client does not 1765 configure an observation of the target resource. Instead, the client 1766 performs a new observe registration request, by transmitting the re- 1767 built phantom request as intended to reach the proxy adjacent to the 1768 origin server. In particular, the client includes the new Listen-To- 1769 Multicast-Responses CoAP option defined in Section 10.1, to provide 1770 that proxy with the transport-specific information required for 1771 receiving multicast notifications for the group observation. 1773 Details on the additional message exchange and processing are defined 1774 in Section 10.2. 1776 10.1. Listen-To-Multicast-Responses Option 1778 In order to allow the proxy to listen to the multicast notifications 1779 sent by the server, a new CoAP option is introduced. This option 1780 MUST be supported by clients interested to take part in group 1781 observations through intermediaries, and by proxies that collect 1782 multicast notifications and forward them back to the observer 1783 clients. 1785 The option is called Listen-To-Multicast-Responses and is intended 1786 only for requests. As summarized in Figure 8, the option is critical 1787 and not Safe-to-Forward. Since the option is not Safe-to-Forward, 1788 the column "N" indicates a dash for "not applicable". 1790 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1791 | No. | C | U | N | R | Name | Format | Len. | Default | 1792 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1793 | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) | 1794 | | | | | | Multicast- | | | | 1795 | | | | | | Responses | | | | 1796 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1798 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 1799 (*) See below. 1801 Figure 8: Listen-To-Multicast-Responses 1803 The Listen-To-Multicast-Responses option includes the serialization 1804 of a CBOR array. This specifies transport-specific message 1805 information required for listening to the multicast notifications of 1806 a group observation, and intended to the proxy adjacent to the origin 1807 server sending those notifications. In particular, the serialized 1808 CBOR array has the same format specified in Section 2.2.1 for the 1809 'tp_info' parameter of the informative response (see Section 2.2). 1811 The Listen-To-Multicast-Responses option is of class U for OSCORE 1812 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1814 10.2. Message Processing 1816 Compared to Section 9, the following additions apply when informative 1817 responses are protected end-to-end between the origin server and the 1818 clients. 1820 After the origin server sends an informative response, each proxy 1821 simply forwards it back to the (previous hop towards the) origin 1822 client that has sent the observation request. 1824 Once received the informative response, the origin client proceeds in 1825 a different way than in Section 7.3.1: 1827 * The client performs all the additional decryption and verification 1828 steps of Section 7.3.1 on the phantom request specified in the 1829 'ph_req' parameter and on the last notification specified in the 1830 'last_notif' parameter (if present). 1832 * The client builds a ticket request (see Appendix B of 1833 [I-D.amsuess-core-cachable-oscore]), as intended to reach the 1834 proxy adjacent to the origin server. The ticket request is 1835 formatted as follows. 1837 - The Token is chosen as the client sees fit. In fact, there is 1838 no reason for this Token to be the same as the phantom 1839 request's. 1841 - The outer Code field, the outer CoAP options and the encrypted 1842 payload with AEAD tag (protecting the inner Code, the inner 1843 CoAP options and the possible plain CoAP payload) concatenated 1844 with the signature are the same of the phantom request used for 1845 the group observation. That is, they are as specified in the 1846 'ph_req' parameter of the received informative response. 1848 - An outer Observe option is included and set to 0 (Register). 1849 This will usually be set in the phantom request already. 1851 - The outer options Proxy-Scheme, Uri-Host and Uri-Port are 1852 included, and set to the same values they had in the original 1853 registration request sent by the client. 1855 - The new option Listen-To-Multicast-Responses is included as an 1856 outer option. The value is set to the serialization of the 1857 CBOR array specified by the 'tp_info' parameter of the 1858 informative response. 1860 Note that, except for transport-specific information such as 1861 the Token and Message ID values, every different client 1862 participating to the same group observation (hence rebuilding 1863 the same phantom request) will build the same ticket request. 1865 Note also that, identically to the phantom request, the ticket 1866 request is still protected with Group OSCORE, i.e., it has the 1867 same OSCORE option, encrypted payload and signature. 1869 Then, the client sends the ticket request to the next hop towards the 1870 origin server. Every proxy in the chain forwards the ticket request 1871 to the next hop towards the origin server, until the last proxy in 1872 the chain is reached. This last proxy, adjacent to the origin 1873 server, proceeds as follows. 1875 * The proxy MUST NOT further forward the ticket request to the 1876 origin server. 1878 * The proxy removes the Proxy-Scheme, Uri-Host and Uri-Port options 1879 from the ticket request. 1881 * The proxy removes the Listen-To-Multicast-Responses option from 1882 the ticket request, and extracts the conveyed transport-specific 1883 information. 1885 * The proxy rebuilds the phantom request associated with the group 1886 observation, by using the ticket request as directly providing the 1887 required transport-independent information. This includes the 1888 outer Code field, the outer CoAP options and the encrypted payload 1889 with AEAD tag concatenated with the signature. 1891 * The proxy configures an observation of the target resource at the 1892 origin server, acting as a client directly taking part in the 1893 group observation. To this end, the proxy uses the rebuilt 1894 phantom request and the transport-specific information retrieved 1895 from the Listen-To-Multicast-Responses Option. The particular way 1896 to achieve this is implementation specific. 1898 After that, the proxy will listen to the IP multicast address and 1899 port number indicated in the Listen-To-Multicast-Responses option, as 1900 'cli_addr' and 'cli_port' element of the serialized CBOR array, 1901 respectively. Furthermore, multicast notifications will match the 1902 phantom request stored at the proxy, based on the Token value 1903 specified in the 'token' element of the serialized CBOR array in the 1904 Listen-To-Multicast-Responses option. 1906 An example is provided in Appendix F. 1908 11. Informative Response Parameters 1910 This document defines a number of fields used in the informative 1911 response message defined in Section 2.2. 1913 The table below summarizes them and specifies the CBOR key to use 1914 instead of the full descriptive name. Note that the media type 1915 application/informative-response+cbor MUST be used when these fields 1916 are transported. 1918 +=================+==========+============+=============+ 1919 | Name | CBOR Key | CBOR Type | Reference | 1920 +=================+==========+============+=============+ 1921 | tp_info | 0 | array | Section 2.2 | 1922 +-----------------+----------+------------+-------------+ 1923 | ph_req | 1 | bstr | Section 2.2 | 1924 +-----------------+----------+------------+-------------+ 1925 | last_notif | 2 | bstr | Section 2.2 | 1926 +-----------------+----------+------------+-------------+ 1927 | next_not_before | 3 | uint | Section 2.2 | 1928 +-----------------+----------+------------+-------------+ 1929 | join_uri | 4 | tstr | Section 7.1 | 1930 +-----------------+----------+------------+-------------+ 1931 | sec_gp | 5 | tstr | Section 7.1 | 1932 +-----------------+----------+------------+-------------+ 1933 | as_uri | 6 | tstr | Section 7.1 | 1934 +-----------------+----------+------------+-------------+ 1935 | hkdf | 7 | int / tstr | Section 7.1 | 1936 +-----------------+----------+------------+-------------+ 1937 | cred_fmt | 8 | int | Section 7.1 | 1938 +-----------------+----------+------------+-------------+ 1939 | sign_enc_alg | 9 | int / tstr | Section 7.1 | 1940 +-----------------+----------+------------+-------------+ 1941 | sign_alg | 10 | int / tstr | Section 7.1 | 1942 +-----------------+----------+------------+-------------+ 1943 | sign_params | 11 | array | Section 7.1 | 1944 +-----------------+----------+------------+-------------+ 1945 | gp_material | 12 | map | Appendix C | 1946 +-----------------+----------+------------+-------------+ 1947 | srv_cred | 13 | bstr | Appendix C | 1948 +-----------------+----------+------------+-------------+ 1949 | srv_identifier | 14 | bstr | Appendix C | 1950 +-----------------+----------+------------+-------------+ 1951 | exp | 15 | uint | Appendix C | 1952 +-----------------+----------+------------+-------------+ 1954 Table 1 1956 12. Transport Protocol Information 1958 This document defines some values of transport protocol identifiers 1959 to use within the 'tp_info' parameter of the informative response 1960 message defined in Section 2.2. 1962 According to the encoding specified in Section 2.2.1, these values 1963 are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' 1964 parameter. 1966 The table below summarizes them, specifies the integer value to use 1967 instead of the full descriptive name, and provides the corresponding 1968 comprehensive set of information elements to include in the 'tp_info' 1969 parameter. 1971 +-----------+-------------+-------+----------+-----------+-----------+ 1972 | Transport | Description | Value | Srv Addr | Req Info | Reference | 1973 | Protocol | | | | | | 1974 +-----------+-------------+-------+----------+-----------+-----------+ 1975 | Reserved | This value | 0 | | | [This | 1976 | | is reserved | | | | document] | 1977 | | | | | | | 1978 | UDP | UDP is used | 1 | tp_id | token | [This | 1979 | | as per | | srv_host | cli_host | document] | 1980 | | RFC7252 | | srv_port | ?cli_port | | 1981 +-----------+-------------+-------+----------+-----------+-----------+ 1983 Figure 9: Transport protocol information 1985 13. Security Considerations 1987 In addition to the security considerations from [RFC7252][RFC7641][I- 1988 D.ietf-core-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm], 1989 the following considerations hold for this document. 1991 13.1. Unsecured Multicast Notifications 1993 In case communications are not protected, the server might not be 1994 able to effectively authenticate a new client when it registers as an 1995 observer. Section 7 of [RFC7641] specifies how, in such a case, the 1996 server must strictly limit the number of notifications sent between 1997 receiving acknowledgements from the client, as confirming to be still 1998 interested in the observation; i.e., any notifications sent in Non- 1999 confirmable messages must be interspersed with confirmable messages. 2001 This is not possible to achieve by the same means when using the 2002 communication model defined in this document, since multicast 2003 notifications are sent as Non-confirmable messages. Nonetheless, the 2004 server might obtain such acknowledgements by other means. 2006 For instance, the method defined in Section 6 to perform the rough 2007 counting of still interested clients triggers (some of) them to 2008 explicitly send a new observation request to acknowledge their 2009 interest. Then, the server can decide to terminate the group 2010 observation altogether, in case not enough clients are estimated to 2011 be still active. If the method defined in Section 6 is used, the 2012 server SHOULD NOT send more than a strict number of multicast 2013 notifications for a given group observation, without having first 2014 performed a new rough counting of active clients. 2016 13.2. Secured Multicast Notifications 2018 If multicast notifications are protected using Group OSCORE as per 2019 Section 7, the following applies. 2021 * The original registration requests and related unicast 2022 (notification) responses MUST also be secured, including and 2023 especially the informative responses from the server. This 2024 prevents on-path active adversaries from altering the conveyed IP 2025 multicast address and serialized phantom registration request. 2026 Thus, it ensures secure binding between every multicast 2027 notification for a same observed resource and the phantom 2028 registration request that started the group observation of that 2029 resource. 2031 * A re-registration request, possibly including the Multicast- 2032 Response-Feedback-Divider option to support the rough counting of 2033 clients (see Section 6), MUST also be secured. 2035 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 2036 so ensuring that the secure binding above is enforced end-to-end 2037 between the server and each observing client. 2039 13.3. Listen-To-Multicast-Responses Option 2041 The CoAP option Listen-To-Multicast-Responses defined in Section 10.1 2042 is of class U for OSCORE and Group OSCORE 2043 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 2045 This allows the proxy adjacent to the origin server to access the 2046 option value conveyed in a ticket request (see Section 10.2), and to 2047 retrieve from it the transport-specific information about a phantom 2048 request. By doing so, the proxy becomes able to configure an 2049 observation of the target resource and to receive multicast 2050 notifications matching to the phantom request. 2052 Any proxy in the chain, as well as further possible intermediaries or 2053 on-path active adversaries, are thus able to remove the option or 2054 alter its content, before the ticket request reaches the proxy 2055 adjacent to the origin server. 2057 Removing the option would result in the proxy adjacent to the origin 2058 server to not configure the group observation, if that has not 2059 happened yet. In such a case, the proxy would not receive the 2060 corresponding multicast notifications to be forwarded back to the 2061 clients. 2063 Altering the option content would result in the proxy adjacent to the 2064 origin server to incorrectly configure a group observation (e.g., by 2065 indicating a wrong multicast IP address) hence preventing the correct 2066 reception of multicast notifications and their forwarding to the 2067 clients; or to configure bogus group observations that are currently 2068 not active on the origin server. 2070 In order to prevent what is described above, the ticket requests 2071 conveying the Listen-To-Multicast-Responses option can be 2072 additionally protected hop-by-hop. This can be achieved by the 2073 client protecting the ticket request sent to the proxy using OSCORE 2074 (see [I-D.tiloca-core-oscore-capable-proxies]) and/or DTLS 2075 [RFC6347][I-D.ietf-tls-dtls13]. 2077 14. IANA Considerations 2079 This document has the following actions for IANA. 2081 14.1. Media Type Registrations 2083 This document registers the media type 'application/informative- 2084 response+cbor' for error messages as informative response defined in 2085 Section 2.2, when carrying parameters encoded in CBOR. This 2086 registration follows the procedures specified in [RFC6838]. 2088 * Type name: application 2090 * Subtype name: informative-response+cbor 2092 * Required parameters: N/A 2094 * Optional parameters: N/A 2096 * Encoding considerations: Must be encoded as a CBOR map containing 2097 the parameters defined in Section 2.2 of [this document]. 2099 * Security considerations: See Section 13 of [this document]. 2101 * Interoperability considerations: N/A 2103 * Published specification: [this document] 2105 * Applications that use this media type: The type is used by CoAP 2106 servers and clients that support error messages as informative 2107 response defined in Section 2.2 of [this document]. 2109 * Fragment identifier considerations: N/A 2111 * Additional information: N/A 2113 * Person & email address to contact for further information: 2114 iesg@ietf.org (mailto:iesg@ietf.org) 2116 * Intended usage: COMMON 2118 * Restrictions on usage: None 2120 * Author: Marco Tiloca marco.tiloca@ri.se 2121 (mailto:marco.tiloca@ri.se) 2123 * Change controller: IESG 2125 * Provisional registration? No 2127 14.2. CoAP Content-Formats Registry 2129 IANA is asked to add the following entry to the "CoAP Content- 2130 Formats" registry within the "Constrained RESTful Environments (CoRE) 2131 Parameters" registry group. 2133 Media Type: application/informative-response+cbor 2135 Encoding: - 2137 ID: TBD 2139 Reference: [this document] 2141 14.3. CoAP Option Numbers Registry 2143 IANA is asked to enter the following option numbers to the "CoAP 2144 Option Numbers" registry within the "CoRE Parameters" registry group. 2146 +--------+--------------------------------------+-----------------+ 2147 | Number | Name | Reference | 2148 +--------+--------------------------------------+-----------------+ 2149 | TBD | Multicast-Response-Feedback-Divider | [This document] | 2150 +--------+--------------------------------------+-----------------+ 2151 | TBD | Listen-To-Multicast-Responses | [This document] | 2152 +--------+--------------------------------------+-----------------+ 2154 14.4. Informative Response Parameters Registry 2156 This document establishes the "Informative Response Parameters" 2157 registry. The registry has been created to use the "Expert Review 2158 Required" registration procedure [RFC8126]. Expert review guidelines 2159 are provided in Section 14.6. 2161 The columns of this registry are: 2163 * Name: This is a descriptive name that enables easier reference to 2164 the item. The name MUST be unique. It is not used in the 2165 encoding. 2167 * CBOR Key: This is the value used as CBOR key of the item. These 2168 values MUST be unique. The value can be a positive integer, a 2169 negative integer, or a string. 2171 * CBOR Type: This contains the CBOR type of the item, or a pointer 2172 to the registry that defines its type, when that depends on 2173 another item. 2175 * Reference: This contains a pointer to the public specification for 2176 the item. 2178 This registry has been initially populated by the values in 2179 Section 11. The "Reference" column for all of these entries refers 2180 to sections of this document. 2182 14.5. CoAP Transport Information Registry 2184 This document establishes the "CoAP Transport Information" registry 2185 within the "CoRE Parameters" registry group. The registry has been 2186 created to use the "Expert Review Required" registration procedure 2187 [RFC8126]. Expert review guidelines are provided in Section 14.6. 2188 It should be noted that, in addition to the expert review, some 2189 portions of the Registry require a specification, potentially a 2190 Standards Track RFC, to be supplied as well. 2192 The columns of this registry are: 2194 * Transport Protocol: This is a descriptive name that enables easier 2195 reference to the item. The name MUST be unique. It is not used 2196 in the encoding. 2198 * Description: Text giving an overview of the transport protocol 2199 referred by this item. 2201 * Value: CBOR abbreviation for the transport protocol referred by 2202 this item. Different ranges of values use different registration 2203 policies [RFC8126]. Integer values from -256 to 255 are 2204 designated as Standards Action. Integer values from -65536 to 2205 -257 and from 256 to 65535 are designated as Specification 2206 Required. Integer values greater than 65535 are designated as 2207 Expert Review. Integer values less than -65536 are marked as 2208 Private Use. 2210 * Server Addr: List of elements providing addressing information of 2211 the server. 2213 * Req Info: List of elements providing transport-specific 2214 information related to a pertinent CoAP request. Optional 2215 elements are prepended by '?'. 2217 * Reference: This contains a pointer to the public specification for 2218 the item. 2220 This registry has been initially populated by the values in 2221 Section 12. The "Reference" column for all of these entries refers 2222 to sections of this document. 2224 14.6. Expert Review Instructions 2226 The IANA registries established in this document are defined as 2227 expert review. This section gives some general guidelines for what 2228 the experts should be looking for, but they are being designated as 2229 experts for a reason so they should be given substantial latitude. 2231 Expert reviewers should take into consideration the following points: 2233 * Point squatting should be discouraged. Reviewers are encouraged 2234 to get sufficient information for registration requests to ensure 2235 that the usage is not going to duplicate one that is already 2236 registered and that the point is likely to be used in deployments. 2237 The zones tagged as private use are intended for testing purposes 2238 and closed environments, code points in other ranges should not be 2239 assigned for testing. 2241 * Specifications are required for the standards track range of point 2242 assignment. Specifications should exist for specification 2243 required ranges, but early assignment before a specification is 2244 available is considered to be permissible. Specifications are 2245 needed for the first-come, first-serve range if they are expected 2246 to be used outside of closed environments in an interoperable way. 2247 When specifications are not provided, the description provided 2248 needs to have sufficient information to identify what the point is 2249 being used for. 2251 * Experts should take into account the expected usage of fields when 2252 approving point assignment. The fact that there is a range for 2253 standards track documents does not mean that a standards track 2254 document cannot have points assigned outside of that range. The 2255 length of the encoded value should be weighed against how many 2256 code points of that length are left, the size of device it will be 2257 used on, and the number of code points left that encode to that 2258 size. 2260 15. References 2262 15.1. Normative References 2264 [COSE.Algorithms] 2265 IANA, "COSE Algorithms", 2266 . 2269 [COSE.Header.Parameters] 2270 IANA, "COSE Header Parameters", 2271 . 2274 [COSE.Key.Types] 2275 IANA, "COSE Key Types", 2276 . 2279 [I-D.ietf-ace-key-groupcomm-oscore] 2280 Tiloca, M., Park, J., and F. Palombini, "Key Management 2281 for OSCORE Groups in ACE", Work in Progress, Internet- 2282 Draft, draft-ietf-ace-key-groupcomm-oscore-13, 7 March 2283 2022, . 2286 [I-D.ietf-ace-oscore-profile] 2287 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2288 "OSCORE Profile of the Authentication and Authorization 2289 for Constrained Environments Framework", Work in Progress, 2290 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 2291 2021, . 2294 [I-D.ietf-core-groupcomm-bis] 2295 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2296 for the Constrained Application Protocol (CoAP)", Work in 2297 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 2298 06, 7 March 2022, . 2301 [I-D.ietf-core-oscore-groupcomm] 2302 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 2303 and J. Park, "Group OSCORE - Secure Group Communication 2304 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 2305 core-oscore-groupcomm-14, 7 March 2022, 2306 . 2309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2310 Requirement Levels", BCP 14, RFC 2119, 2311 DOI 10.17487/RFC2119, March 1997, 2312 . 2314 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2315 "Transmission of IPv6 Packets over IEEE 802.15.4 2316 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2317 . 2319 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2320 Specifications and Registration Procedures", BCP 13, 2321 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2322 . 2324 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2325 Application Protocol (CoAP)", RFC 7252, 2326 DOI 10.17487/RFC7252, June 2014, 2327 . 2329 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2330 Application Protocol (CoAP)", RFC 7641, 2331 DOI 10.17487/RFC7641, September 2015, 2332 . 2334 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2335 Bose, "Constrained Application Protocol (CoAP) Option for 2336 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2337 August 2016, . 2339 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2340 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2341 March 2017, . 2343 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2344 Writing an IANA Considerations Section in RFCs", BCP 26, 2345 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2346 . 2348 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2349 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2350 May 2017, . 2352 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 2353 DOI 10.17487/RFC8288, October 2017, 2354 . 2356 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2357 "Object Security for Constrained RESTful Environments 2358 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2359 . 2361 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2362 Representation (CBOR)", STD 94, RFC 8949, 2363 DOI 10.17487/RFC8949, December 2020, 2364 . 2366 15.2. Informative References 2368 [I-D.amsuess-core-cachable-oscore] 2369 Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in 2370 Progress, Internet-Draft, draft-amsuess-core-cachable- 2371 oscore-04, 6 March 2022, . 2374 [I-D.ietf-ace-oauth-authz] 2375 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2376 H. Tschofenig, "Authentication and Authorization for 2377 Constrained Environments (ACE) using the OAuth 2.0 2378 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2379 draft-ietf-ace-oauth-authz-46, 8 November 2021, 2380 . 2383 [I-D.ietf-core-coap-pubsub] 2384 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2385 Subscribe Broker for the Constrained Application Protocol 2386 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2387 core-coap-pubsub-09, 30 September 2019, 2388 . 2391 [I-D.ietf-core-coral] 2392 Amsüss, C. and T. Fossati, "The Constrained RESTful 2393 Application Language (CoRAL)", Work in Progress, Internet- 2394 Draft, draft-ietf-core-coral-04, 25 October 2021, 2395 . 2398 [I-D.ietf-core-href] 2399 Bormann, C. and H. Birkholz, "Constrained Resource 2400 Identifiers", Work in Progress, Internet-Draft, draft- 2401 ietf-core-href-09, 15 January 2022, 2402 . 2405 [I-D.ietf-core-resource-directory] 2406 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 2407 D. Stok, "CoRE Resource Directory", Work in Progress, 2408 Internet-Draft, draft-ietf-core-resource-directory-28, 7 2409 March 2021, . 2412 [I-D.ietf-cose-cbor-encoded-cert] 2413 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 2414 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 2415 Certificates)", Work in Progress, Internet-Draft, draft- 2416 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 2417 . 2420 [I-D.ietf-tls-dtls13] 2421 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2422 Datagram Transport Layer Security (DTLS) Protocol Version 2423 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2424 dtls13-43, 30 April 2021, . 2427 [I-D.tiloca-core-oscore-capable-proxies] 2428 Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work 2429 in Progress, Internet-Draft, draft-tiloca-core-oscore- 2430 capable-proxies-02, 7 March 2022, 2431 . 2434 [I-D.tiloca-core-oscore-discovery] 2435 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 2436 OSCORE Groups with the CoRE Resource Directory", Work in 2437 Progress, Internet-Draft, draft-tiloca-core-oscore- 2438 discovery-11, 7 March 2022, 2439 . 2442 [MOBICOM99] 2443 Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The 2444 Broadcast Storm Problem in a Mobile Ad Hoc Network", 2445 Proceedings of the 5th annual ACM/IEEE international 2446 conference on Mobile computing and networking , August 2447 1999, . 2450 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2451 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2452 January 2012, . 2454 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2455 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2456 . 2458 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2459 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2460 . 2462 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 2463 Security (TLS) / Datagram Transport Layer Security (DTLS) 2464 Profiles for the Internet of Things", RFC 7925, 2465 DOI 10.17487/RFC7925, July 2016, 2466 . 2468 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 2469 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 2470 May 2018, . 2472 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2473 Definition Language (CDDL): A Notational Convention to 2474 Express Concise Binary Object Representation (CBOR) and 2475 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2476 June 2019, . 2478 Appendix A. Different Sources for Group Observation Data 2480 While the clients usually receive the phantom registration request 2481 and other information related to the group observation through an 2482 Informative Response, the same data can be made available through 2483 different services, such as the following ones. 2485 A.1. Topic Discovery in Publish-Subscribe Settings 2487 In a Publish-Subscribe scenario [I-D.ietf-core-coap-pubsub], a group 2488 observation can be discovered along with topic metadata. For 2489 instance, a discovery step can make the following metadata available. 2491 This example assumes a CoRAL namespace [I-D.ietf-core-coral], that 2492 contains properties analogous to those in the content-format 2493 application/informative-response+cbor. 2495 [ The reported CoRAL example is based on the textual representation 2496 used until version -03 of [I-D.ietf-core-coral]. This will be 2497 revised to use the CBOR diagnostic notation instead. ] 2499 Request: 2501 GET 2502 Accept: CoRAL 2504 Response: 2506 2.05 Content 2507 Content-Format: CoRAL 2509 rdf:type 2510 topic { 2511 tp_info [1, h"7b", h"20010db80100..0001", 5683, 2512 h"ff35003020010db8..1234", 5683], 2513 ph_req h"0160..", 2514 last_notif h"256105.." 2515 } 2517 Figure 10: Group observation discovery in a Pub-Sub scenario 2519 With this information from the topic discovery step, the client can 2520 already set up its multicast address and start receiving multicast 2521 notifications. 2523 In heavily asymmetric networks like municipal notification services, 2524 discovery and notifications do not necessarily need to use the same 2525 network link. For example, a departure monitor could use its (costly 2526 and usually-off) cellular uplink to discover the topics it needs to 2527 update its display to, and then listen on a LoRA-WAN interface for 2528 receiving the actual multicast notifications. 2530 A.2. Introspection at the Multicast Notification Sender 2532 For network debugging purposes, it can be useful to query a server 2533 that sends multicast responses as matching a phantom registration 2534 request. 2536 Such an interface is left for other documents to specify on demand. 2537 As an example, a possible interface can be as follows, and rely on 2538 the already known Token value of intercepted multicast notifications, 2539 associated with a phantom registration request. 2541 Request: 2543 GET 2545 Response: 2547 2.05 Content 2548 Content-Format: application/informative-response+cbor 2550 { 2551 'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 2552 h"ff35003020010db8..1234", 5683], 2553 'ph_req': h"0160..", 2554 'last_notif' : h"256105.." 2555 } 2557 Figure 11: Group observation discovery with server introspection 2559 For example, a network sniffer could offer sending such a request 2560 when unknown multicast notifications are seen in a network. 2561 Consequently, it can associate those notifications with a URI, or 2562 decrypt them, if member of the correct OSCORE group. 2564 Appendix B. Pseudo-Code for Rough Counting of Clients 2566 This appendix provides a description in pseudo-code of the two 2567 algorithms used for the rough counting of active observers, as 2568 defined in Section 6. 2570 In particular, Appendix B.1 describes the algorithm for the client 2571 side, while Appendix B.2 describes an optimized version for 2572 constrained clients. Finally, Appendix B.3 describes the algorithm 2573 for the server side. 2575 B.1. Client Side 2577 input: int Q, // Value of the MRFD option 2578 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2579 // unless overridden 2581 output: None 2583 int RAND_MIN = 0; 2584 int RAND_MAX = (2**Q) - 1; 2585 int I = randomInteger(RAND_MIN, RAND_MAX); 2587 if (I == 0) { 2588 float fraction = randomFloat(0, 1); 2590 Timer t = new Timer(); 2591 t.setAndStart(fraction * LEISURE_TIME); 2592 while(!t.isExpired()); 2594 Request req = new Request(); 2595 // Initialize as NON and with maximum 2596 // No-Response settings, set options ... 2598 Option opt = new Option(OBSERVE); 2599 opt.set(0); 2600 req.setOption(opt); 2602 opt = new Option(MRFD); 2603 req.setOption(opt); 2605 req.send(SRV_ADDR, SRV_PORT); 2606 } 2608 B.2. Client Side - Optimized Version 2609 input: int Q, // Value of the MRFD option 2610 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2611 // unless overridden 2613 output: None 2615 const unsigned int UINT_BIT = CHAR_BIT * sizeof(unsigned int); 2617 if (respond_to(Q) == true) { 2618 float fraction = randomFloat(0, 1); 2620 Timer t = new Timer(); 2621 t.setAndStart(fraction * LEISURE_TIME); 2622 while(!t.isExpired()); 2624 Request req = new Request(); 2625 // Initialize as NON and with maximum 2626 // No-Response settings, set options ... 2628 Option opt = new Option(OBSERVE); 2629 opt.set(0); 2630 req.setOption(opt); 2632 opt = new Option(MRFD); 2633 req.setOption(opt); 2635 req.send(SRV_ADDR, SRV_PORT); 2636 } 2638 bool respond_to(int Q) { 2639 while (Q >= UINT_BIT) { 2640 if (rand() != 0) return false; 2641 Q -= UINT_BIT; 2642 } 2643 unsigned int mask = ~((~0u) << Q); 2644 unsigned int masked = mask & rand(); 2645 return masked == 0; 2646 } 2648 B.3. Server Side 2650 input: int COUNT, // Current observer counter 2651 int M, // Desired number of confirmations 2652 int MAX_CONFIRMATION_WAIT, 2653 Response notification, // Multicast notification to send 2655 output: int NEW_COUNT // Updated observer counter 2656 int D = 4; // Dampener value 2657 int RETRY_NEXT_THRESHOLD = 4; 2658 float CANCEL_THRESHOLD = 0.2; 2660 int N = max(COUNT, 1); 2661 int Q = max(ceil(log2(N / M)), 0); 2662 Option opt = new Option(MRFD); 2663 opt.set(Q); 2665 notification.setOption(opt); 2666 2667 notification.send(GRP_ADDR, GRP_PORT); 2669 Timer t = new Timer(); 2670 t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 2671 while(!t.isExpired()); 2673 // Time t2 2675 int R = ; 2678 int E = R * (2**Q); 2680 // Determine after how many multicast notifications 2681 // the next count update will be performed 2682 if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) { 2683 2684 } 2685 else { 2686 2687 } 2689 // Compute the new count estimate 2690 int COUNT_PRIME = ; 2691 int NEW_COUNT = COUNT_PRIME + ((E - N) / D); 2693 // Determine whether to cancel the group observation 2694 if (NEW_COUNT < CANCEL_THRESHOLD) { 2695 ; 2696 return 0; 2697 } 2699 return NEW_COUNT; 2701 Appendix C. OSCORE Group Self-Managed by the Server 2703 For simple settings, where no pre-arranged group with suitable 2704 memberships is available, the server can be responsible to setup and 2705 manage the OSCORE group used to protect the group observation. 2707 In such a case, a client would implicitly request to join the OSCORE 2708 group when sending the observe registration request to the server. 2709 When replying, the server includes the group keying material and 2710 related information in the informative response (see Section 2.2). 2712 Additionally to what defined in Section 2, the CBOR map in the 2713 informative response payload contains the following fields, whose 2714 CBOR labels are defined in Section 11. 2716 * 'gp_material': this element is a CBOR map, which includes what the 2717 client needs in order to set up the Group OSCORE Security Context. 2719 This parameter has as value a subset of the 2720 Group_OSCORE_Input_Material object, which is defined in 2721 Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the 2722 OSCORE_Input_Material object encoded in CBOR as defined in 2723 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 2725 In particular, the following elements of the 2726 Group_OSCORE_Input_Material object are included, using the same 2727 CBOR labels from the OSCORE Security Context Parameters Registry, 2728 as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 2730 - 'ms', 'contexId', 'cred_fmt', 'sign_enc_alg', 'sign_alg' and 2731 'sign_params'. These elements MUST be included. 2733 - 'hkdf' and 'salt'. These elements MAY be included. 2735 The 'group_senderId' element of the Group_OSCORE_Input_Material 2736 object MUST NOT be included. 2738 * 'srv_cred': this element is a CBOR byte string, with value the 2739 original binary representation of the server's authentication 2740 credential used in the OSCORE group. In particular, the original 2741 binary representation complies with the format specified by the 2742 'cred_fmt' element of 'gp_material'. 2744 * 'srv_identifier': this element MUST be included and is encoded as 2745 a CBOR byte string, with value the Sender ID that the server has 2746 in the OSCORE group. 2748 * 'exp': with value the expiration time of the keying material of 2749 the OSCORE group specified in the 'gp_material' parameter, encoded 2750 as a CBOR unsigned integer. This field contains a numeric value 2751 representing the number of seconds from 1970-01-01T00:00:00Z UTC 2752 until the specified UTC date/time, ignoring leap seconds, 2753 analogous to what specified for NumericDate in Section 2 of 2754 [RFC7519]. 2756 Note that the informative response does not require to include an 2757 explicit proof-of-possession (PoP) of the server's private key. 2758 Although the server is also acting as Group Manager and a PoP 2759 evidence of the Group Manager's private key is included in a full- 2760 fledged Joining Response (see Section 6.4 of 2761 [I-D.ietf-ace-key-groupcomm-oscore]), such proof-of-possession will 2762 be achieved through every multicast notification, that the server 2763 sends as protected with the group mode of Group OSCORE and including 2764 a signature computed with its private key. 2766 A client receiving an informative response uses the information above 2767 to set up the Group OSCORE Security Context, as described in 2768 Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client 2769 does not obtain a Sender ID of its own, hence it installs a Security 2770 Context that a "silent server" would, i.e., without Sender Context. 2771 From then on, the client uses the received keying material to process 2772 the incoming multicast notifications from the server. 2774 Since the server is also acting as Group Manager, the authentication 2775 credential of the server provided in the 'srv_cred' element of the 2776 informative response is also used in the 'gm_cred' element of the 2777 external_aad for encrypting and signing the phantom request and 2778 multicast notifications (see Section 4.3 of 2779 [I-D.ietf-core-oscore-groupcomm]) 2781 Furthermore, the server complies with the following points. 2783 * The server MUST NOT self-manage OSCORE groups and provide the 2784 related keying material in the informative response for any other 2785 purpose than the protection of group observations, as defined in 2786 this document. 2788 The server MAY use the same self-managed OSCORE group to protect 2789 the phantom request and the multicast notifications of multiple 2790 group observations it hosts. 2792 * The server MUST NOT provide in the informative response the keying 2793 material of other OSCORE groups it is or has been a member of. 2795 After the time indicated in the 'exp' field: 2797 * The server MUST stop using the keying material and MUST cancel the 2798 group observations for which that keying material is used (see 2799 Section 2.5 and Section 7.2.4). If the server creates a new group 2800 observation as a replacement or follow-up using the same OSCORE 2801 group: 2803 - The server MUST update the Master Secret. 2805 - The server MUST update the ID Context used as Group Identifier 2806 (Gid), consistently with Section 3.2 of 2807 [I-D.ietf-core-oscore-groupcomm]. 2809 - The server MAY update the Master Salt. 2811 * The client MUST stop using the keying material and MAY re-register 2812 the observation at the server. 2814 Before the keying material has expired, the server can send a 2815 multicast response with response code 5.03 (Service Unavailable) to 2816 the observing clients, protected with the current keying material. 2817 In particular, this is an informative response (see Section 2.2), 2818 which: i) additionally contains the abovementioned parameters for the 2819 next group keying material to be used; and ii) MAY omit the 'tp_info' 2820 and 'ph_req' parameters, since the associated information is 2821 immutable throughout the observation lifetime. The response has the 2822 same Token value T of the phantom registration request and it does 2823 not include an Observe option. The server MUST use its own Sender 2824 Sequence Number as Partial IV to protect the error response, and 2825 include it as Partial IV in the OSCORE option of the response. 2827 When some clients leave the OSCORE group and forget about the group 2828 observation, the server does not have to provide the remaining 2829 clients with any stale Sender IDs, as normally required for Group 2830 OSCORE (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). In 2831 fact, only two entities in the group have a Sender ID, i.e., the 2832 server and possibly the Deterministic Client, if the optimization 2833 defined in this appendix is combined with the use of phantom requests 2834 as deterministic requests (see Appendix D). In particular, both of 2835 them never change their Sender ID during the group lifetime, while 2836 they both remain part of the group until the group ceases to exist. 2838 As an alternative to renewing the keying material before it expires, 2839 the server can simply cancel the group observation (see Section 2.5 2840 and Section 7.2.4), which results in the eventual re-registration of 2841 the clients that are still interested in the group observation. 2843 Applications requiring backward security and forward security are 2844 REQUIRED to use an actual group joining process (usually through a 2845 dedicated Group Manager), e.g., the ACE joining procedure defined in 2846 [I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the 2847 clients by providing them information about the OSCORE group to join, 2848 as described in Section 7.1. 2850 Appendix D. Phantom Request as Deterministic Request 2852 In some settings, the server can assume that all the approaching 2853 clients already have the exact phantom observation request to use. 2855 For instance, the clients can be pre-configured with the phantom 2856 observation request, or they may be expected to retrieve it through 2857 dedicated means (see Appendix A), before sending an observe 2858 registration request to the server. 2860 If Group OSCORE is used to protect the group observation (see 2861 Section 7), and the OSCORE group supports the concept of 2862 Deterministic Client [I-D.amsuess-core-cachable-oscore], then the 2863 server and each client in the OSCORE group can independently protect 2864 the phantom observation request possibly available as plain CoAP 2865 message. To this end, they use the approach defined in Section 3 of 2866 [I-D.amsuess-core-cachable-oscore] to compute a protected 2867 deterministic request, against which the protected multicast 2868 notifications will match for the group observation in question. 2870 Note that the same deterministic request sent by each client as 2871 registration request is, in terms of transport-independent 2872 information, identical to the phantom registration request. Thus, 2873 the informative response sent by the server may omit the 'ph_req' 2874 parameter (see Section 2.2). If a client receives an informative 2875 response that includes the 'ph_req' parameter, and this specifies 2876 transport-independent information different from the one of the sent 2877 deterministic request, then the client considers the informative 2878 response malformed. 2880 If the optimization defined in Appendix C is also used, the 2881 'gp_material' element in the error informative response from the 2882 server MUST also include the following elements from the 2883 Group_OSCORE_Input_Material object. 2885 * 'alg', 'ecdh_alg' and 'ecdh_params', as per Section 6.4 of 2886 [I-D.ietf-ace-key-groupcomm-oscore]. 2888 * 'det_senderId' and 'det_hash_alg', defined in Section 4 of 2889 [I-D.amsuess-core-cachable-oscore]. These specify the Sender ID 2890 of the Deterministic Client in the OSCORE group, and the hash 2891 algorithm used to compute the deterministic request (see 2892 Section 3.4.1 of [I-D.amsuess-core-cachable-oscore]). 2894 Appendix E. Example with a Proxy 2896 This section provides an example when a proxy P is used between the 2897 clients and the server. The same assumptions and notation used in 2898 Section 5 are used for this example. In addition, the proxy has 2899 address PRX_ADDR and listens to the port number PRX_PORT. 2901 Unless explicitly indicated, all messages transmitted on the wire are 2902 sent over unicast. 2904 C1 C2 P S 2905 | | | | 2906 | | | | (The value of the resource /r is "1234") 2907 | | | | 2908 +------------>| | Token: 0x4a 2909 | GET | | | Observe: 0 (Register) 2910 | | | | Proxy-Uri: coap://sensor.example/r 2911 | | | | 2912 | | +------->| Token: 0x5e 2913 | | | GET | Observe: 0 (Register) 2914 | | | | Uri-Host: sensor.example 2915 | | | | Uri-Path: r 2916 | | | | 2917 | | | | (S allocates the available Token value 0x7b) 2918 | | | | 2919 | | | | (S sends to itself a phantom observation 2920 | | | | request PH_REQ as coming from the 2921 | | | | IP multicast address GRP_ADDR) 2922 | | | | 2923 | | | ------+ 2924 | | | / | 2925 | | | \----->| Token: 0x7b 2926 | | | GET | Observe: 0 (Register) 2927 | | | | Uri-Host: sensor.example 2928 | | | | Uri-Path: r 2929 | | | | 2930 | | | | (S creates a group observation of /r) 2931 | | | | 2932 | | | | (S increments the observer counter 2933 | | | | for the group observation of /r) 2934 | | | | 2935 | | | | 2936 | | | | 2937 | | |<-------+ Token: 0x5e 2938 | | | 5.03 | Content-Format: application/ 2939 | | | | informative-response+cbor 2940 | | | | Max-Age: 0 2941 | | | | 2942 | | | | Payload: { 2943 | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, 2944 | | | | 0x7b, bstr(GRP_ADDR), 2945 | | | | GRP_PORT], 2946 | | | | last_notif : bstr(0x45 | OPT | 2947 | | | | 0xff | PAYLOAD) 2948 | | | | } 2949 | | | | 2950 | | | | (PAYLOAD in 'last_notif' : "1234") 2951 | | | | 2952 | | | | 2953 | | | | (The proxy starts listening to the 2954 | | | | GRP_ADDR address and the GRP_PORT port.) 2955 | | | | 2956 | | | | (The proxy adds C1 to its list of observers.) 2957 | | | | 2958 |<------------+ | Token: 0x4a 2959 | 2.05 | | | Observe: 54120 2960 | | | | Content-Format: application/cbor 2961 | | | | 2962 | | | | Payload: "1234" 2963 | | | | 2964 : : : : 2965 : : : : 2966 : : : : 2967 | | | | 2968 | +----->| | Token: 0x01 2969 | | GET | | Observe: 0 (Register) 2970 | | | | Proxy-Uri: coap://sensor.example/r 2971 | | | | 2972 | | | | (The proxy has a fresh cache representation) 2973 | | | | 2974 | |<-----+ | Token: 0x01 2975 | | 2.05 | | Observe: 54120 2976 | | | | Content-Format: application/cbor 2977 | | | | 2978 | | | | Payload: "1234" 2979 | | | | 2980 : : : : 2981 : : : : (The value of the resource 2982 : : : : /r changes to "5678".) 2983 : : : : 2985 | | | | 2986 | | | (*) | 2987 | | |<-------+ Token: 0x7b 2988 | | | 2.05 | Observe: 11 2989 | | | | Content-Format: application/cbor 2990 | | | | 2991 | | | | Payload: "5678" 2992 | | | | 2993 |<------------+ | Token: 0x4a 2994 | 2.05 | | | Observe: 54123 2995 | | | | Content-Format: application/cbor 2996 | | | | 2997 | | | | Payload: "5678" 2998 | | | | 2999 | |<-----+ | Token: 0x01 3000 | | 2.05 | | Observe: 54123 3001 | | | | Content-Format: application/cbor 3002 | | | | 3003 | | | | Payload: "5678" 3004 | | | | 3006 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT 3008 Figure 12: Example of group observation with a proxy 3010 Note that the proxy has all the information to understand the 3011 observation request from C2, and can immediately start to serve the 3012 still fresh values. 3014 This behavior is mandated by Section 5 of [RFC7641], i.e., the proxy 3015 registers itself only once with the next hop and fans out the 3016 notifications it receives to all registered clients. 3018 Appendix F. Example with a Proxy and Group OSCORE 3020 This section provides an example when a proxy P is used between the 3021 clients and the server, and Group OSCORE is used to protect multicast 3022 notifications end-to-end between the server and the clients. 3024 The same assumptions and notation used in Section 8 are used for this 3025 example. In addition, the proxy has address PRX_ADDR and listens to 3026 the port number PRX_PORT. 3028 Unless explicitly indicated, all messages transmitted on the wire are 3029 sent over unicast and protected with OSCORE end-to-end between a 3030 client and the server. 3032 C1 C2 P S 3033 | | | | 3034 | | | | (The value of the resource /r is "1234") 3035 | | | | 3036 +-------------->| | Token: 0x4a 3037 | FETCH | | | Observe: 0 (Register) 3038 | | | | OSCORE: {kid: 0x01; piv: 101; ...} 3039 | | | | Uri-Host: sensor.example 3040 | | | | Proxy-Scheme: coap 3041 | | | | 3042 | | | | 0xff 3043 | | | | Encrypted_payload { 3044 | | | | 0x01 (GET), 3045 | | | | Observe: 0 (Register), 3046 | | | | Uri-Path: r, 3047 | | | | 3048 | | | | } 3049 | | | | 3050 | | +-------->| Token: 0x5e 3051 | | | FETCH | Observe: 0 (Register) 3052 | | | | OSCORE: {kid: 0x01; piv: 101; ...} 3053 | | | | Uri-Host: sensor.example 3054 | | | | 3055 | | | | 0xff 3056 | | | | Encrypted_payload { 3057 | | | | 0x01 (GET), 3058 | | | | Observe: 0 (Register), 3059 | | | | Uri-Path: r, 3060 | | | | 3061 | | | | } 3062 | | | | 3063 | | | | 3064 | | | | (S allocates the available 3065 | | | | Token value 0x7b .) 3066 | | | | 3067 | | | | (S sends to itself a phantom observation 3068 | | | | request PH_REQ as coming from the 3069 | | | | IP multicast address GRP_ADDR) 3070 | | | | 3071 | | | -------+ 3072 | | | / | 3073 | | | \------>| Token: 0x7b 3074 | | | FETCH | Observe: 0 (Register) 3075 | | | | OSCORE: {kid: 0x05; piv: 501; 3076 | | | | kid context: 0x57ab2e; ...} 3077 | | | | Uri-Host: sensor.example 3078 | | | | 3079 | | | | 0xff 3080 | | | | Encrypted_payload { 3081 | | | | 0x01 (GET), 3082 | | | | Observe: 0 (Register), 3083 | | | | Uri-Path: r, 3084 | | | | 3085 | | | | } 3086 | | | | 3087 | | | | 3088 | | | | (S steps SN_5 in the Group OSCORE 3089 | | | | Security Context : SN_5 <== 502) 3090 | | | | 3091 | | | | (S creates a group observation of /r) 3092 | | | | 3093 | | | | 3094 | | | | (S increments the observer counter 3095 | | | | for the group observation of /r) 3096 | | | | 3097 | | |<--------+ Token: 0x5e 3098 | | | 2.05 | OSCORE: {piv: 301; ...} 3099 | | | | Max-Age: 0 3100 | | | | 3101 | | | | 0xff 3102 | | | | Encrypted_payload { 3103 | | | | 5.03 (Service Unavailable), 3104 | | | | Content-Format: application/ 3105 | | | | informative-response+cbor, 3106 | | | | , 3107 | | | | 0xff, 3108 | | | | CBOR_payload { 3109 | | | | tp_info : [1, bstr(SRV_ADDR), 3110 | | | | SRV_PORT, 0x7b, 3111 | | | | bstr(GRP_ADDR), GRP_PORT], 3112 | | | | ph_req : bstr(0x05 | OPT | 0xff | 3113 | | | | PAYLOAD | SIGN), 3114 | | | | last_notif : bstr(0x45 | OPT | 0xff | 3115 | | | | PAYLOAD | SIGN), 3116 | | | | join_uri : "coap://myGM/ 3117 | | | | ace-group/myGroup", 3118 | | | | sec_gp : "myGroup" 3119 | | | | } 3120 | | | | } 3121 | | | | 3122 |<--------------+ | Token: 0x4a 3123 | 2.05 | | | OSCORE: {piv: 301; ...} 3124 | | | | 3125 | | | | 0xff 3126 | | | | (Same Encrypted_payload) 3127 | | | | 3128 | | | | 3129 +-------------->| | Token: 0x4b 3130 | FETCH | | | Observe: 0 (Register) 3131 | | | | OSCORE: {kid: 0x05 ; piv: 501; 3132 | | | | kid context: 0x57ab2e; ...} 3133 | | | | Uri-Host: sensor.example 3134 | | | | Proxy-Scheme: coap 3135 | | | | Listen-To- 3136 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 3137 | | | | SRV_PORT, 0x7b, 3138 | | | | bstr(GRP_ADDR), 3139 | | | | GRP_PORT] 3140 | | | | } 3141 | | | | 3142 | | | | 0xff 3143 | | | | Encrypted_payload { 3144 | | | | 0x01 (GET), 3145 | | | | Observe: 0 (Register), 3146 | | | | Uri-Path: r 3147 | | | | 3148 | | | | } 3149 | | | | 3150 | | | | 3151 | | | | (The proxy starts listening to the 3152 | | | | GRP_ADDR address and the GRP_PORT port.) 3153 | | | | 3154 | | | | (The proxy adds C1 to 3155 | | | | its list of observers.) 3156 | | | | 3157 |<--------------| | 3158 | | ACK | | 3159 : : : : 3160 : : : : 3161 : : : : 3162 | | | | 3163 | +------>| | Token: 0x01 3164 | | FETCH | | Observe: 0 (Register) 3165 | | | | OSCORE: {kid: 0x02; piv: 201; ...} 3166 | | | | Uri-Host: sensor.example 3167 | | | | Proxy-Scheme: coap 3168 | | | | 3169 | | | | 0xff 3170 | | | | Encrypted_payload { 3171 | | | | 0x01 (GET), 3172 | | | | Observe: 0 (Register), 3173 | | | | Uri-Path: r, 3174 | | | | 3175 | | | | } 3176 | | | | 3177 | | +-------->| Token: 0x5f 3178 | | | FETCH | Observe: 0 (Register) 3179 | | | | OSCORE: {kid: 0x02; piv: 201; ...} 3180 | | | | Uri-Host: sensor.example 3181 | | | | 3182 | | | | 0xff 3183 | | | | Encrypted_payload { 3184 | | | | 0x01 (GET), 3185 | | | | Observe: 0 (Register), 3186 | | | | Uri-Path: r, 3187 | | | | 3188 | | | | } 3189 | | | | 3190 | | |<--------+ Token: 0x5f 3191 | | | 2.05 | OSCORE: {piv: 401; ...} 3192 | | | | Max-Age: 0 3193 | | | | 3194 | | | | 0xff 3195 | | | | Encrypted_payload { 3196 | | | | 5.03 (Service Unavailable), 3197 | | | | Content-Format: application/ 3198 | | | | informative-response+cbor, 3199 | | | | , 3200 | | | | 0xff, 3201 | | | | CBOR_payload { 3202 | | | | tp_info : [1, bstr(SRV_ADDR), 3203 | | | | SRV_PORT, 0x7b, 3204 | | | | bstr(GRP_ADDR), GRP_PORT], 3205 | | | | ph_req : bstr(0x05 | OPT | 0xff | 3206 | | | | PAYLOAD | SIGN), 3207 | | | | last_notif : bstr(0x45 | OPT | 0xff | 3208 | | | | PAYLOAD | SIGN), 3209 | | | | join_uri : "coap://myGM/ 3210 | | | | ace-group/myGroup", 3211 | | | | sec_gp : "myGroup" 3212 | | | | } 3213 | | | | } 3214 | | | | 3215 | |<------+ | Token: 0x01 3216 | | 2.05 | | OSCORE: {piv: 401; ...} 3217 | | | | 3218 | | | | 0xff 3219 | | | | (Same Encrypted_payload) 3220 | | | | 3221 | +------>| | Token: 0x02 3222 | | FETCH | | Observe: 0 (Register) 3223 | | | | OSCORE: {kid: 0x05; piv: 501; 3224 | | | | kid context: 57ab2e; ...} 3225 | | | | Uri-Host: sensor.example 3226 | | | | Proxy-Scheme: coap 3227 | | | | Listen-To- 3228 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 3229 | | | | SRV_PORT, 0x7b, 3230 | | | | bstr(GRP_ADDR), 3231 | | | | GRP_PORT] 3232 | | | | } 3233 | | | | 3234 | | | | 0xff 3235 | | | | Encrypted_payload { 3236 | | | | 0x01 (GET), 3237 | | | | Observe: 0 (Register), 3238 | | | | Uri-Path: r 3239 | | | | 3240 | | | | } 3241 | | | | 3242 | | | | 3243 | | | | (The proxy adds C2 to 3244 | | | | its list of observers.) 3245 | |<------| | 3246 | | ACK | | 3247 | | | | 3248 : : : : 3249 : : : : (The value of the resource 3250 : : : : /r changes to "5678".) 3251 : : : : 3252 | | | (*) | 3253 | | |<--------+ Token: 0x7b 3254 | | | 2.05 | Observe: 11 3255 | | | | OSCORE: {kid: 0x05; piv: 502; ...} 3256 | | | | 3257 | | | | 0xff 3258 | | | | Encrypted_payload { 3259 | | | | 2.05 (Content), 3260 | | | | Observe: [empty], 3261 | | | | Content-Format: application/cbor, 3262 | | | | , 3263 | | | | 0xff, 3264 | | | | CBOR_Payload: "5678" 3265 | | | | } 3266 | | | | 3267 | | | | 3268 |<--------------+ | Token: 0x4b 3269 | 2.05 | | | Observe: 54123 3270 | | | | OSCORE: {kid: 0x05; piv: 502; ...} 3271 | | | | 3272 | | | | 0xff 3273 | | | | (Same Encrypted_payload and Signature) 3274 | | | | 3275 | |<------+ | Token: 0x02 3276 | | 2.05 | | Observe: 54123 3277 | | | | OSCORE: {kid: 0x05; piv: 502; ...} 3278 | | | | 3279 | | | | 0xff 3280 | | | | (Same Encrypted_payload and signature) 3281 | | | | 3283 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 3284 with Group OSCORE end-to-end between the server and the clients. 3286 Figure 13: Example of group observation with a proxy and Group OSCORE 3288 Unlike in the unprotected example in Appendix E, the proxy does _not_ 3289 have all the information to perform request deduplication, and can 3290 only recognize the identical request once the client sends the ticket 3291 request. 3293 Appendix G. Example with a Proxy and Deterministic Requests 3295 This section provides an example when a proxy P is used between the 3296 clients and the server, and Group OSCORE is used to protect multicast 3297 notifications end-to-end between the server and the clients. 3299 In addition, the phantom request is especially a deterministic 3300 request (see Appendix D), which is protected with the pairwise mode 3301 of Group OSCORE as defined in [I-D.amsuess-core-cachable-oscore]. 3303 G.1. Assumptions and Walkthrough 3305 The example provided in this appendix as reflected by the message 3306 exchange shown in Appendix G.2 assumes the following. 3308 1. The OSCORE group supports deterministic requests. Thus, the 3309 server creates the phantom request as a deterministic request 3310 [I-D.amsuess-core-cachable-oscore], and stores it locally as one 3311 of its issued phantom requests, without starting the group 3312 observation yet. 3314 2. The server makes the phantom request available through other 3315 means, e.g., a pub-sub broker, together with the transport- 3316 specific information for listening to multicast notifications 3317 bound to the phantom request (see Appendix A). 3319 3. Since the phantom request is a deterministic request, the server 3320 can more efficiently make it available in its smaller, plain 3321 version. The clients can obtain it from the particular 3322 alternative source, and compute the protected version to use 3323 from the retrieved plain version. 3325 4. If the client does not rely on a proxy between itself and the 3326 server, it simply sets the group observation and starts 3327 listening to multicast notifications. Building on point (2) 3328 above, the same would happen if the phantom request would not be 3329 specifically a deterministic request. 3331 5. If the client relies on a proxy between itself and the server, 3332 it uses the phantom request as a ticket request. However, 3333 unlike the case considered in Section 10 when the ticket request 3334 is not deterministic, the client does not include a Listen-to- 3335 Multicast-Responses option in the phantom request sent to the 3336 proxy. 3338 6. Unlike for the case considered in Section 10, here the proxy 3339 does not know that the request is exactly a ticket request for 3340 subscribing to multicast notifications. Thus, the proxy simply 3341 forwards the ticket request to the server as it normally does 3342 for any request. 3344 7. The server receives the ticket request, which is a deviation 3345 from the case where the ticket request is not deterministic and 3346 stops at the proxy (see Section 10). Then, the server can 3347 clearly understand what is happening. In fact, as the result of 3348 an early check, the server recognizes the phantom request among 3349 the stored ones. This happens through a byte-by-byte comparison 3350 of the incoming message minus the transport-related fields, 3351 i.e., by considering only: i) the outer REST code; ii) the outer 3352 options; and iii) the ciphertext and signature from the message 3353 payload. 3355 8. Having recognized the incoming request as one of the self- 3356 generated deterministic phantom requests made available at 3357 external sources, the server does not perform any OSCORE 3358 processing on it. This opens for replying to the proxy with an 3359 unprotected response, although not signaling any OSCORE-related 3360 error. 3362 9. The server starts the group observation and replies with an 3363 error response, i.e., the usual 5.03 informative response, 3364 including: the transport information, the phantom request, and 3365 (optionally) the latest notification. 3367 10. From the received 5.03 response, the proxy retrieves everything 3368 needed to set itself as an observer in the group observation, 3369 and it starts listening to multicast notifications. If the 5.03 3370 response included a latest notification, the proxy caches it and 3371 forwards it back to the client, otherwise it replies with an 3372 empty ACK (if it has not done it already and the request from 3373 the client was Confirmable). 3375 11. Like in the case with a non-deterministic phantom request 3376 considered in Section 10, the proxy fans out the multicast 3377 notifications to the origin clients as they come. Also, as new 3378 clients following the first one contact the proxy, this does not 3379 have to contact the server again as in Section 10, since the 3380 deterministic phantom request would produce a cache hit as per 3381 [I-D.amsuess-core-cachable-oscore]. Thus, the proxy can serve 3382 such clients with the latest fresh multicast notification from 3383 its cache. 3385 G.2. Message Exchange 3387 The same assumptions and notation used in Section 8 are used for this 3388 example. As a recap of some specific value: 3390 * Two clients C_1 and C_2 register to observe a resource /r at a 3391 Server S, which has address SRV_ADDR and listens to the port 3392 number SRV_PORT. Before the following exchanges occur, no clients 3393 are observing the resource /r , which has value "1234". 3395 * The server S sends multicast notifications to the IP multicast 3396 address GRP_ADDR and port number GRP_PORT, and starts the group 3397 observation upon receiving a registration request from a first 3398 client that wishes to start a traditional observation on the 3399 resource /r. 3401 * S is a member of the OSCORE group with 'kid context' = 0x57ab2e as 3402 Group ID. In the OSCORE group, S has 'kid' = 0x05 as Sender ID, 3403 and SN_5 = 501 as Sender Sequence Number. 3405 In addition: 3407 * The proxy has address PRX_ADDR and listens to the port number 3408 PRX_PORT. 3410 * The deterministic client in the OSCORE group has 'kid' = 0x09. 3412 Unless explicitly indicated, all messages transmitted on the wire are 3413 sent over unicast and protected with Group OSCORE end-to-end between 3414 a client and the server. 3416 C1 C2 P S 3417 | | | | 3418 | | | | (The value of the resource /r is "1234") 3419 | | | | 3420 | | | | (The server prepares a deterministic 3421 | | | | phantom request PH_REQ. The server 3422 | | | | stores PH_REQ locally and makes it 3423 | | | | available at an external source) 3424 | | | | 3425 | | | | (C1 obtains PH_REQ and sends it to P) 3426 | | | | 3427 | | | | 3428 +-------------->| | Token: 0x4a 3429 | FETCH | | | Uri-Host: sensor.example 3430 | | | | Observe: 0 (Register) 3431 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3432 | | | | kid context: 0x57ab2e ; ... } 3433 | | | | Proxy-Scheme: coap 3434 | | | | 3435 | | | | 0xff 3436 | | | | Encrypted_payload { 3437 | | | | 0x01 (GET), 3438 | | | | Observe: 0 (Register), 3439 | | | | Uri-Path: r, 3440 | | | | 3441 | | | | } 3442 | | | | 3443 | | +-------->| Token: 0x5e 3444 | | | FETCH | Uri-Host: sensor.example 3445 | | | | Observe: 0 (Register) 3446 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3447 | | | | kid context: 0x57ab2e ; ... } 3448 | | | | 3449 | | | | 0xff 3450 | | | | Encrypted_payload { 3451 | | | | 0x01 (GET), 3452 | | | | Observe: 0 (Register), 3453 | | | | Uri-Path: r, 3454 | | | | 3455 | | | | } 3456 | | | | 3457 | | | | (S recognizes PH_REQ through byte-by-byte 3458 | | | | comparison against the stored one, and 3459 | | | | skips any OSCORE processing) 3460 | | | | 3461 | | | | (S allocates the available 3462 | | | | Token value 0x7b .) 3463 | | | | 3464 | | | | (S sends to itself PH_REQ, with Token 0x7b 3465 | | | | and as coming from the IP multicast 3466 | | | | address GRP_ADDR; now the OSCORE 3467 | | | | processing does happen, as specified 3468 | | | | for a deterministic request) 3469 | | | | 3470 | | | -------| 3471 | | | / | 3472 | | | \------>| Token: 0x7b 3473 | | | FETCH | Uri-Host: sensor.example 3474 | | | | Observe: 0 (Register) 3475 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3476 | | | | kid context: 0x57ab2e ; ... } 3477 | | | | 3478 | | | | 0xff 3479 | | | | Encrypted_payload { 3480 | | | | 0x01 (GET), 3481 | | | | Observe: 0 (Register), 3482 | | | | Uri-Path: r, 3483 | | | | 3484 | | | | } 3485 | | | | 3486 | | | | (S prepares the "last notification" 3487 | | | | response defined below) 3488 | | | | 3489 | | | | 0x45 (2.05 Content) 3490 | | | | Observe: 10 3491 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} 3492 | | | | Max-Age: 3000 3493 | | | | 3494 | | | | 0xff 3495 | | | | Encrypted_payload { 3496 | | | | 0x45 (2.05 Content), 3497 | | | | Observe: [empty], 3498 | | | | CBOR_Payload: "1234" 3499 | | | | } 3500 | | | | 3501 | | | | 3502 | | | | (S responds to the proxy with an 3503 | | | | unprotected informative response) 3504 | | | | 3505 | | |<--------| Token: 0x5e 3506 | | | 5.03 | Content-Format: application/ 3507 | | | | informative-response+cbor 3508 | | | | Max-Age: 0 3509 | | | | 0xff, 3510 | | | | CBOR_payload { 3511 | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, 3512 | | | | 0x7b, bstr(GRP_ADDR), 3513 | | | | GRP_PORT], 3514 | | | | last_notif : 3516 | | | | } 3517 | | | | } 3518 | | | | 3519 | | | | (P extracts PH_REQ and starts listening 3520 | | | | to multicast notifications with Token 3521 | | | | 0x7b at GRP_ADDR:GRP_PORT) 3522 | | | | 3523 | | | | (P extracts the "last notification" 3524 | | | | response, caches it and forwards 3525 | | | | it back to C1) 3526 | | | | 3527 |<--------------+ | Token: 0x4a 3528 | 2.05 | | | Observe: 54120 3529 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} 3530 | | | | Max-Age: 2995 3531 | | | | 3532 | | | | 0xff 3533 | | | | Encrypted_payload { 3534 | | | | 0x45 (2.05 Content), 3535 | | | | Observe: [empty], 3536 | | | | CBOR_Payload: "1234" 3537 | | | | } 3538 | | | | 3539 | | | | 3540 : : : | 3541 : : : | 3542 : : : | 3543 | | | | 3544 | | | | (C2 obtains PH_REQ and sends it to P) 3545 | | | | 3546 | +------>| | Token: 0x01 3547 | | FETCH | | Uri-Host: sensor.example 3548 | | | | Observe: 0 (Register) 3549 | | | | OSCORE: {kid: 0x09 ; piv: 0 ; 3550 | | | | kid context: 0x57ab2e; ...} 3551 | | | | Proxy-Scheme: coap 3552 | | | | 3553 | | | | 0xff 3554 | | | | Encrypted_payload { 3555 | | | | 0x01 (GET), 3556 | | | | Observe: 0 (Register), 3557 | | | | Uri-Path: r, 3558 | | | | 3559 | | | | } 3560 | | | | 3561 | | | | (P serves C2 from it cache) 3562 | | | | 3563 | |<------+ | Token: 0x01 3564 | | 2.05 | | Observe: 54120 3565 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} 3566 | | | | Max-Age: 1800 3567 | | | | 3568 | | | | 0xff 3569 | | | | Encrypted_payload { 3570 | | | | 0x45 (2.05 Content), 3571 | | | | Observe: [empty], 3572 | | | | CBOR_Payload: "1234" 3573 | | | | } 3574 | | | | 3575 | | | | 3576 : : : | 3577 : : : | 3578 : : : | 3579 | | | | 3580 | | | | (The value of the resource 3581 | | | | /r changes to "5678".) 3582 | | | | 3583 | | | (*) | 3584 | | |<--------| Token: 0x7b 3585 | | | 2.05 | Observe: 11 3586 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} 3587 | | | | 3588 | | | | 0xff 3589 | | | | Encrypted_payload { 3590 | | | | 0x45 (2.05 Content), 3591 | | | | Observe: [empty], 3592 | | | | Content-Format: application/cbor, 3593 | | | | , 3594 | | | | 0xff, 3595 | | | | CBOR_Payload: "5678" 3596 | | | | } 3597 | | | | 3598 | | | | 3599 | | | | (P updates its cache entry 3600 | | | | with this notification) 3601 | | | | 3602 |<--------------+ | Token: 0x4a 3603 | 2.05 | | | Observe: 54123 3604 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} 3605 | | | | 3606 | | | | 0xff 3607 | | | | (Same Encrypted_payload and signature) 3608 | | | | 3609 | |<------+ | Token: 0x01 3610 | | 2.05 | | Observe: 54123 3611 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} 3612 | | | | 3613 | | | | 0xff 3614 | | | | (Same Encrypted_payload and signature) 3615 | | | | 3617 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 3618 with Group OSCORE end-to-end between the server and the clients. 3620 Appendix H. Document Updates 3622 RFC EDITOR: PLEASE REMOVE THIS SECTION. 3624 H.1. Version -02 to -03 3626 * Distinction between authentication credential and public key. 3628 * Fixed processing of informative response at the client, when Group 3629 OSCORE is used. 3631 * Discussed scenarios with pre-configured address/port and Token 3632 value. 3634 H.2. Version -01 to -02 3636 * Clarifications on client rough counting and IP multicast scope. 3638 * The 'ph_req' parameter is optional in the informative response. 3640 * New parameter 'next_not_before' for the informative response. 3642 * Optimization when rekeying the self-managed OSCORE group. 3644 * Security considerations on unsecured multicast notifications. 3646 * Protection of the ticket request sent to a proxy. 3648 * RFC8126 terminology in IANA considerations. 3650 * Editorial improvements. 3652 H.3. Version -00 to -01 3653 * Simplified cancellation of the group observation, without using a 3654 phantom cancellation request. 3656 * Aligned parameter semantics with core-oscore-groupcomm and ace- 3657 key-groupcomm-oscore. 3659 * Clarifications about self-managed OSCORE group and use of 3660 deterministic requests for cacheable OSCORE. 3662 * New example with a proxy, Group OSCORE and a deterministic phantom 3663 request. 3665 * Fixes in the examples and editorial improvements. 3667 Acknowledgments 3669 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 3670 Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander 3671 for their comments and feedback. 3673 The work on this document has been partly supported by VINNOVA and 3674 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 3675 (Grant agreement 952652). 3677 Authors' Addresses 3679 Marco Tiloca 3680 RISE AB 3681 Isafjordsgatan 22 3682 SE-16440 Stockholm Kista 3683 Sweden 3684 Email: marco.tiloca@ri.se 3686 Rikard Höglund 3687 RISE AB 3688 Isafjordsgatan 22 3689 SE-16440 Stockholm Kista 3690 Sweden 3691 Email: rikard.hoglund@ri.se 3693 Christian Amsüss 3694 Hollandstr. 12/4 3695 1020 Vienna 3696 Austria 3697 Email: christian@amsuess.com 3698 Francesca Palombini 3699 Ericsson AB 3700 Torshamnsgatan 23 3701 SE-16440 Stockholm Kista 3702 Sweden 3703 Email: francesca.palombini@ericsson.com