idnits 2.17.1 draft-ietf-core-observe-multicast-notifications-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (1 April 2021) is 1114 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-09 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-15 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-10 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-15) exists of draft-ietf-cose-rfc8152bis-struct-14 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-00 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-36 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-26 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-40 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-07 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft R. Hoeglund 4 Updates: 7252, 7641 (if approved) RISE AB 5 Intended status: Standards Track C. Amsuess 6 Expires: 3 October 2021 7 F. Palombini 8 Ericsson AB 9 1 April 2021 11 Observe Notifications as CoAP Multicast Responses 12 draft-ietf-core-observe-multicast-notifications-00 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 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 3 October 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 64 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 66 2.2.1. Encoding of Transport-Specific Message Information . 8 67 2.2.2. Encoding of Transport-Independent Message 68 Information . . . . . . . . . . . . . . . . . . . . . 11 69 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 70 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 13 71 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13 72 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 14 73 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 3.2. Informative Response . . . . . . . . . . . . . . . . . . 14 75 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16 76 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 16 77 4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 6. Rough Counting of Clients in the Group Observation . . . . . 19 80 6.1. Processing on the Client Side . . . . . . . . . . . . . . 20 81 6.2. Processing on the Server Side . . . . . . . . . . . . . . 21 82 6.2.1. Request for Feedback . . . . . . . . . . . . . . . . 21 83 6.2.2. Collection of Feedback . . . . . . . . . . . . . . . 21 84 6.2.3. Processing of Feedback . . . . . . . . . . . . . . . 22 85 7. Protection of Multicast Notifications with Group OSCORE . . . 23 86 7.1. Signaling the OSCORE Group in the Informative Response . 24 87 7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 26 88 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 26 89 7.2.2. Informative Response . . . . . . . . . . . . . . . . 27 90 7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 27 91 7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 28 92 7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 28 93 7.3.1. Informative Response . . . . . . . . . . . . . . . . 28 94 7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 29 95 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 30 96 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 34 97 10. Intermediaries Together with End-to-End Security . . . . . . 35 98 10.1. The Listen-To-Multicast-Responses Option . . . . . . . . 36 99 10.2. Message Processing . . . . . . . . . . . . . . . . . . . 37 100 11. Informative Response Parameters . . . . . . . . . . . . . . . 39 101 12. Transport Protocol Information . . . . . . . . . . . . . . . 40 102 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 103 13.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 41 104 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 105 14.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 106 14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 43 107 14.3. Informative Response Parameters Registry . . . . . . . . 43 108 14.4. CoAP Transport Information Registry . . . . . . . . . . 44 109 14.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45 110 14.6. Expert Review Instructions . . . . . . . . . . . . . . . 45 111 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 112 15.1. Normative References . . . . . . . . . . . . . . . . . . 46 113 15.2. Informative References . . . . . . . . . . . . . . . . . 48 114 Appendix A. Different Sources for Group Observation Data . . . . 50 115 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 50 116 A.2. Introspection at the Multicast Notification Sender . . . 51 117 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 52 118 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 52 119 B.2. Client Side - Optimized Version . . . . . . . . . . . . . 53 120 B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 54 121 Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 56 122 Appendix D. Phantom Request as Deterministic Request . . . . . . 58 123 Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 59 124 Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 61 125 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 67 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 128 1. Introduction 130 The Constrained Application Protocol (CoAP) [RFC7252] has been 131 extended with a number of mechanisms, including resource Observation 132 [RFC7641]. This enables CoAP clients to register at a CoAP server as 133 "observers" of a resource, and hence being automatically notified 134 with an unsolicited response upon changes of the resource state. 136 CoAP supports group communication over IP multicast 137 [I-D.ietf-core-groupcomm-bis]. This includes support for Observe 138 registration requests over multicast, in order for clients to 139 efficiently register as observers of a resource hosted at multiple 140 servers. 142 However, in a number of use cases, using multicast messages for 143 responses would also be desirable. That is, it would be useful that 144 a server sends observe notifications for a same target resource to 145 multiple observers as responses over IP multicast. 147 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 148 multiple clients can subscribe to a topic, by observing the related 149 resource hosted at the responsible broker. When a new value is 150 published on that topic, it would be convenient for the broker to 151 send a single multicast notification at once, to all the subscriber 152 clients observing that topic. 154 A different use case concerns clients observing a same registration 155 resource at the CoRE Resource Directory 156 [I-D.ietf-core-resource-directory]. For example, multiple clients 157 can benefit of observation for discovering (to-be-created) OSCORE 158 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 159 Resource Directory updated links and descriptions to join them 160 through the respective Group Manager 161 [I-D.tiloca-core-oscore-discovery]. 163 More in general, multicast notifications would be beneficial whenever 164 several CoAP clients observe a same target resource at a CoAP server, 165 and can be all notified at once by means of a single response 166 message. However, CoAP does not currently define response messages 167 over IP multicast. This specification fills this gap and provides 168 the following twofold contribution. 170 First, it updates [RFC7252] and [RFC7641], by defining a method to 171 deliver Observe notifications as CoAP responses addressed to multiple 172 clients, e.g. over IP multicast. In the proposed method, the group 173 of potential observers entrusts the server to manage the Token space 174 for multicast notifications. By doing so, the server provides all 175 the observers of a target resource with the same Token value to bind 176 to their own observation. That Token value is then used in every 177 multicast notification for the target resource. This is achieved by 178 means of an informative unicast response sent by the server to each 179 observer client. 181 Second, this specification defines how to use Group OSCORE 182 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 183 end-to-end between the server and the observer clients. This is also 184 achieved by means of the informative unicast response mentioned 185 above, which additionally includes parameter values used by the 186 server to protect every multicast notification for the target 187 resource by using Group OSCORE. This provides a secure binding 188 between each of such notifications and the observation of each of the 189 clients. 191 1.1. Terminology 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 Readers are expected to be familiar with terms and concepts described 200 in CoAP [RFC7252], group communication for CoAP 201 [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949], 202 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 204 This specification additionally defines the following terminology. 206 * Traditional observation. A resource observation associated to a 207 single observer client, as defined in [RFC7641]. 209 * Group observation. A resource observation associated to a group 210 of clients. The server sends notifications for the group-observed 211 resource over IP multicast to all the observer clients. 213 * Phantom request. The CoAP request message that the server would 214 have received to start or cancel a group observation on one of its 215 resources. A phantom request is generated inside the server and 216 does not hit the wire. 218 * Informative response. A CoAP response message that the server 219 sends to a given client via unicast, providing the client with 220 information on a group observation. 222 2. Server-Side Requirements 224 The server can, at any time, start a group observation on one of its 225 resources. Practically, the server may want to do that under the 226 following circumstances. 228 * In the absence of observations for the target resource, the server 229 receives a registration request from a first client wishing to 230 start a traditional observation on that resource. 232 * When a certain amount of traditional observations has been 233 established on the target resource, the server decides to make 234 those clients part of a group observation on that resource. 236 The server maintains an observer counter for each group observation 237 to a target resource, as a rough estimation of the observers actively 238 taking part in the group observation. 240 The server initializes the counter to 0 when starting the group 241 observation, and increments it after a new client starts taking part 242 in that group observation. Also, the server should keep the counter 243 up-to-date over time, for instance by using the method described in 244 Section 6. 246 This document does not describe a way for the client to influence the 247 server's decision to start group observations. That is done on 248 purpose: the specified mechanism is expected to be used in situations 249 where sending individual notifications is not feasible, or not 250 preferred beyond a certain number of clients observing a target 251 resource. If applications arise where negotiation does make sense, 252 they are welcome to specify additional means to opt in to multicast 253 notifications. 255 2.1. Request 257 Assuming it is reachable at the address SRV_ADDR and port number 258 SRV_PORT, the server starts a group observation on one of its 259 resources as defined below. The server intends to send multicast 260 notifications for the target resource to the multicast IP address 261 GRP_ADDR and port number GRP_PORT. 263 1. The server builds a phantom observation request, i.e. a GET 264 request with an Observe option set to 0 (register). 266 2. The server selects an available value T, from the Token space of 267 a CoAP endpoint used for messages having: 269 * As source address and port number, the IP multicast address 270 GRP_ADDR and port number GRP_PORT. 272 * As destination address and port number, the server address 273 SRV_ADDR and port number SRV_PORT, intended for accessing the 274 target resource. 276 This Token space is under exclusive control of the server. 278 3. The server processes the phantom observation request above, 279 without transmitting it on the wire. The request is addressed to 280 the resource for which the server wants to start the group 281 observation, as if sent by the group of observers, i.e. with 282 GRP_ADDR as source address and GRP_PORT as source port. 284 4. Upon processing the self-generated phantom registration request, 285 the server interprets it as an observe registration received from 286 the group of potential observer clients. In particular, from 287 then on, the server MUST use T as its own local Token value 288 associated to that observation, with respect to the (previous hop 289 towards the) clients. 291 5. The server does not immediately respond to the phantom 292 observation request with a multicast notification sent on the 293 wire. The server stores the phantom observation request as is, 294 throughout the lifetime of the group observation. 296 6. The server builds a CoAP response message INIT_NOTIF as initial 297 multicast notification for the target resource, in response to 298 the phantom observation request. This message is formatted as 299 other multicast notifications (see Section 2.3) and MUST include 300 the current representation of the target resource as payload. 301 The server stores the message INIT_NOTIF and does not transmit 302 it. The server considers this message as the latest multicast 303 notification for the target resource, until it transmits a new 304 multicast notification for that resource as a CoAP message on the 305 wire. After that, the server deletes the message INIT_NOTIF. 307 2.2. Informative Response 309 After having started a group observation on a target resource, the 310 server proceeds as follows. 312 For each traditional observation ongoing on the target resource, the 313 server MAY cancel that observation. Then, the server considers the 314 corresponding clients as now taking part in the group observation, 315 for which it increases the corresponding observer counter 316 accordingly. 318 The server sends to each of such clients an informative response 319 message, encoded as a unicast response with response code 5.03 320 (Service Unavailable). As per [RFC7641], such a response does not 321 include an Observe option. The response MUST be Confirmable and MUST 322 NOT encode link-local addresses. 324 The Content-Format of the informative response is set to application/ 325 informative-response+cbor, defined in Section 14.2. The payload of 326 the informative response is a CBOR map including the following 327 parameters, whose CBOR labels are defined in Section 11. 329 * 'tp_info', with value a CBOR array. This includes the transport- 330 specific information required to correctly receive multicast 331 notifications bound to the phantom observation request. The CBOR 332 array is formatted as defined in Section 2.2.1. This parameter 333 MUST be included. 335 * 'ph_req', with value the byte serialization of the transport- 336 independent information of the phantom observation request (see 337 Section 2.1), encoded as a CBOR byte string. The value of the 338 CBOR byte string is formatted as defined in Section 2.2.2. This 339 parameter MUST be included. 341 * 'last_notif', with value the byte serialization of the transport- 342 independent information of the latest multicast notification for 343 the target resource, encoded as a CBOR byte string. The value of 344 the CBOR byte string is formatted as defined in Section 2.2.2. 345 This parameter MAY be included. 347 The CDDL notation [RFC8610] provided below describes the payload of 348 the informative response. 350 informative_response_payload = { 351 1 => array, ; 'tp_info', i.e. transport-specific information 352 2 => bstr, ; 'ph_req' (transport-independent information) 353 ? 3 => bstr ; 'last_notif' (transport-independent information) 354 } 356 Figure 1: Format of the informative response payload 358 Upon receiving a registration request to observe the target resource, 359 the server does not create a corresponding individual observation for 360 the requesting client. Instead, the server considers that client as 361 now taking part in the group observation of the target resource, of 362 which it increments the observer counter by 1. Then, the server 363 replies to the client with the same informative response message 364 defined above, which MUST be Confirmable. 366 Note that this also applies when, with no ongoing traditional 367 observations on the target resource, the server receives a 368 registration request from a first client and decides to start a group 369 observation on the target resource. 371 2.2.1. Encoding of Transport-Specific Message Information 373 The CBOR array specified in the 'tp_info' parameter is formatted 374 according to the following CDDL notation. 376 tp_info = [ 377 srv_addr ; Addressing information of the server 378 ? req_info ; Request data extension 379 ] 381 srv_addr = ( 382 tp_id : int, ; Identifier of the used transport protocol 383 + elements ; Number, format and encoding 384 ; based on the value of 'tp_id' 385 ) 387 req_info = ( 388 + elements ; Number, format and encoding based on 389 ; the value of 'tp_id' in 'srv_addr' 390 ) 392 Figure 2: General format of 'tp_info' 394 The 'srv_addr' element of 'tp_info' specifies the addressing 395 information of the server, and includes at least one element 'tp_id' 396 which is formatted as follows. 398 * 'tp_id' : this element is a CBOR integer, which specifies the 399 transport protocol used to transport the CoAP response from the 400 server, i.e. a multicast notification in this specification. 402 This element takes value from the "Value" column of the "CoAP 403 Transport Information" registry defined in Section 14.4 of this 404 specification. This element MUST be present. The value of this 405 element determines: 407 - How many elements are required to follow in 'srv_addr', as well 408 as what information they convey, their encoding and their 409 semantics. 411 - How many elements are required in the 'req_info' element of the 412 'tp_info' array, as well as what information they convey, their 413 encoding and their semantics. 415 This specification registers the integer value 1 ("UDP") to be 416 used as value for the 'tp_id' element, when CoAP responses are 417 transported over UDP. In such a case, the full encoding of the 418 'tp_info' CBOR array is as defined in Section 2.2.1.1. 420 Future specifications that consider CoAP multicast notifications 421 transported over different transport protocols MUST: 423 - Register an entry with an integer value to be used for 'tp_id', 424 in the "CoAP Transport Information" registry defined in 425 Section 14.4 of this specification. 427 - Accordingly, define the elements of the 'tp_info' CBOR array, 428 i.e. the elements following 'tp_id' in 'srv_addr' as well as 429 the elements in 'req_info', as to what information they convey, 430 their encoding and their semantics. 432 The 'req_info' element of 'tp_info' specifies transport-specific 433 information related to a pertinent request message, i.e. the phantom 434 observation request in this specification. The exact format of 435 'req_info' depends on the value of 'tp_id'. 437 Given a specific value of 'tp_id', the complete set of elements 438 composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is 439 indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP 440 Transport Information" registry defined in Section 14.4, 441 respectively. 443 2.2.1.1. UDP Transport-Specific Information 445 When CoAP multicast notifications are transported over UDP as per 446 [RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the 447 integer value 1 ("UDP") as value of 'tp_id' in the 'srv_addr' element 448 of the 'tp_info' CBOR array in the error informative response. Then, 449 the rest of the 'tp_info' CBOR array is defined as follows. 451 * 'srv_addr' includes two more elements following 'tp_id': 453 - 'srv_host': this element is a CBOR byte string, with value the 454 destination IP address of the phantom observation request. 455 This parameter is tagged and identified by the CBOR tag 260 456 "Network Address (IPv4 or IPv6 or MAC Address)". That is, the 457 value of the CBOR byte string is the IP address SRV_ADDR of the 458 server hosting the target resource, from where the server will 459 send multicast notifications for the target resource. This 460 element MUST be present. 462 - 'srv_port': this element is a CBOR unsigned integer, with value 463 the destination port number of the phantom observation request. 464 That is, the specified value is the port number SRV_PORT, from 465 where the server will send multicast notifications for the 466 target resource. This element MUST be present. 468 * 'req_info' includes the following elements: 470 - 'token': this element is a CBOR byte string, with value the 471 Token value of the phantom observation request generated by the 472 server (see Section 2.1). Note that the same Token value is 473 used for the multicast notifications bound to that phantom 474 observation request (see Section 2.3). This element MUST be 475 present. 477 - 'cli_addr': this element is a CBOR byte string, with value the 478 source IP address of the phantom observation request. This 479 parameter is tagged and identified by the CBOR tag 260 "Network 480 Address (IPv4 or IPv6 or MAC Address)". That is, the value of 481 the CBOR byte string is the IP multicast address GRP_ADDR, 482 where the server will send multicast notifications for the 483 target resource. This element MUST be present. 485 - 'cli_port': this element is a CBOR unsigned integer, with value 486 the source port number of the phantom observation request. 487 That is, the specified value is the port number GRP_PORT, where 488 the server will send multicast notifications for the target 489 resource. This element is OPTIONAL. If not included, the 490 default port number 5683 is assumed. 492 The CDDL notation provided below describes the full 'tp_info' CBOR 493 array using the format above. 495 tp_info = [ 496 tp_id : 1, ; UDP as transport protocol 497 srv_host : #6.260(bstr), ; Src. address of multicast notifications 498 srv_port : uint, ; Src. port of multicast notifications 499 token : bstr, ; Token of the phantom request and 500 ; associated multicast notifications 501 cli_addr : #6.260(bstr), ; Dst. address of multicast notifications 502 ? cli_port : uint ; Dst. port of multicast notifications 503 ] 505 Figure 3: Format of 'tp_info' with UDP as transport protocol 507 2.2.2. Encoding of Transport-Independent Message Information 509 For both the parameters 'ph_req' and 'last_notif' in the informative 510 response, the value of the byte string is the concatenation of the 511 following components, in the order specified below. 513 When defining the value of each component, "CoAP message" refers to 514 the phantom observation request for the 'ph_req' parameter, and to 515 the corresponding latest multicast notification for the 'last_notif' 516 parameter. 518 * A single byte, with value the content of the Code field in the 519 CoAP message. 521 * The byte serialization of the complete sequence of CoAP options in 522 the CoAP message. 524 * If the CoAP message includes a non-zero length payload, the one- 525 byte Payload Marker (0xff) followed by the payload. 527 2.3. Notifications 529 Upon a change in the status of the target resource under group 530 observation, the server sends a multicast notification, intended to 531 all the clients taking part in the group observation of that 532 resource. In particular, each of such multicast notifications is 533 formatted as follows. 535 * It MUST be Non-confirmable. 537 * It MUST include an Observe option, as per [RFC7641]. 539 * It MUST have the same Token value T of the phantom registration 540 request that started the group observation. This Token value is 541 specified in the 'token' element of 'req_info' under the 'tp_info' 542 parameter, in the informative response message sent to all the 543 observer clients. 545 That is, every multicast notification for a target resource is not 546 bound to the observation requests from the different clients, but 547 rather to the phantom registration request associated to the whole 548 set of clients taking part in the group observation of that 549 resource. 551 * It MUST be sent from the same IP address SRV_ADDR and port number 552 SRV_PORT where: i) the original Observe registration requests are 553 sent to by the clients; and ii) the corresponding informative 554 responses are sent from by the server (see Section 2.2). These 555 are indicated to the observer clients as value of the 'srv_host' 556 and 'srv_port' elements of 'srv_addr' under the 'tp_info' 557 parameter, in the informative response message (see 558 Section 2.2.1.1). That is, redirection MUST NOT be used. 560 * It MUST be sent to the IP multicast address GRP_ADDR and port 561 number GRP_PORT. These are indicated to the observer clients as 562 value of the 'cli_addr' and 'cli_port' elements of 'req_info' 563 under the 'tp_info' parameter, in the informative response message 564 (see Section 2.2.1.1). 566 For each target resource with an active group observation, the server 567 MUST store the latest multicast notification. 569 2.4. Congestion Control 571 In order to not cause congestion, the server should conservatively 572 control the sending of multicast notifications. In particular: 574 * The multicast notifications MUST be Non-confirmable. 576 * In constrained environments such as low-power, lossy networks 577 (LLNs), the server should only support multicast notifications for 578 resources that are small. Following related guidelines from 579 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], this can consist, 580 for example, in having the payload of multicast notifications as 581 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 582 size, so that it fits into a single link-layer frame in case IPv6 583 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 584 Section 4 of [RFC4944]) is used. 586 * The server SHOULD provide multicast notifications with the 587 smallest possible IP multicast scope that fulfills the application 588 needs. For example, following related guidelines from 589 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], site-local scope 590 is always preferred over global scope IP multicast, if this 591 fulfills the application needs. Similarly, realm-local scope is 592 always preferred over site-local scope, if this fulfills the 593 application needs. 595 * Following related guidelines from Section 4.5.1 of [RFC7641], the 596 server SHOULD NOT send more than one multicast notification every 597 3 seconds, and SHOULD use an even less aggressive rate when 598 possible (see also Section 3.1.2 of [RFC8085]). The transmission 599 rate of multicast notifications should also take into account the 600 avoidance of a possible "broadcast storm" problem [MOBICOM99]. 601 This prevents a following, considerable increase of the channel 602 load, whose origin would be likely attributed to a router rather 603 than the server. 605 2.5. Cancellation 607 At any point in time, the server may want to cancel a group 608 observation of a target resource. For instance, the server may 609 realize that no clients or not enough clients are interested in 610 taking part in the group observation anymore. A possible approach 611 that the server can use to assess this is defined in Section 6. 613 In order to cancel the group observation, the server sends to itself 614 a phantom cancellation request, i.e. a GET request with an Observe 615 option set to 1 (deregister), without transmitting it on the wire. 616 As per Section 3.6 of [RFC7641], all other options MUST be identical 617 to those in the phantom registration request, except for the set of 618 ETag Options. This request has the same Token value T of the phantom 619 registration request, and is addressed to the resource for which the 620 server wants to end the group observation, as if sent by the group of 621 observers, i.e. with the multicast IP address GRP_ADDR as source 622 address and the port number GRP_PORT as source port. 624 After that, the server sends a multicast response with response code 625 5.03 (Service Unavailable), signaling that the group observation has 626 been terminated. The response has no payload, and is sent to the 627 same multicast IP address GRP_ADDR and port number GRP_PORT used to 628 send the multicast notifications related to the target resource. As 629 per [RFC7641], this response does not include an Observe option. 630 Finally, the server releases the resources allocated for the group 631 observation, and especially frees up the Token value T used at its 632 CoAP endpoint. 634 3. Client-Side Requirements 636 3.1. Request 638 A client sends an observation request to the server as described in 639 [RFC7641], i.e. a GET request with an Observe option set to 0 640 (register). The request MUST NOT encode link-local addresses. If 641 the server is not configured to accept registrations on that target 642 resource with a group observation, this would still result in a 643 positive notification response to the client as described in 644 [RFC7641]. 646 3.2. Informative Response 648 Upon receiving the informative response defined in Section 2.2, the 649 client proceeds as follows. 651 1. The client configures an observation of the target resource. To 652 this end, it relies on a CoAP endpoint used for messages having: 654 * As source address and port number, the server address SRV_ADDR 655 and port number SRV_PORT intended for accessing the target 656 resource. These are specified as value of the 'srv_host' and 657 'srv_port' elements of 'srv_addr' under the 'tp_info' 658 parameter, in the informative response (see Section 2.2.1.1). 660 * As destination address and port number, the IP multicast 661 address GRP_ADDR and port number GRP_PORT. These are 662 specified as value of the 'cli_addr' and 'cli_port' elements 663 of 'req_info' under the 'tp_info' parameter, in the 664 informative response (see Section 2.2.1.1). If the 'cli_port' 665 element is omitted in 'req_info', the client MUST assume the 666 default port number 5683 as GRP_PORT. 668 2. The client rebuilds the phantom registration request, by using: 670 * The transport-independent information, specified in the 671 'ph_req' parameter of the informative response. 673 * The Token value T, specified in the 'token' element of 674 'req_info' under the 'tp_info' parameter of the informative 675 response. 677 3. The client stores the phantom registration request, as associated 678 to the observation of the target resource. In particular, the 679 client MUST use the Token value T of this phantom registration 680 request as its own local Token value associated to that group 681 observation, with respect to the server. The particular way to 682 achieve this is implementation specific. 684 4. If the informative response includes the parameter 'last_notif', 685 the client rebuilds the latest multicast notification, by using: 687 * The transport-independent information, specified in the 688 'last_notif' parameter of the informative response. 690 * The Token value T, specified in the 'token' element of 691 'req_info' under the 'tp_info' parameter of the informative 692 response. 694 5. If the informative response includes the parameter 'last_notif', 695 the client processes the multicast notification rebuilt in step 4 696 as defined in Section 3.2 of [RFC7641]. In particular, the value 697 of the Observe option is used as initial baseline for 698 notification reordering in this group observation. 700 6. If a traditional observation to the target resource is ongoing, 701 the client MAY silently cancel it without notifying the server. 703 If any of the expected fields in the informative response are not 704 present or malformed, the client MAY try sending a new registration 705 request to the server (see Section 3.1). Otherwise, the client 706 SHOULD explicitly withdraw from the group observation. 708 Appendix A describes possible alternative ways for clients to 709 retrieve the phantom registration request and other information 710 related to a group observation. 712 3.3. Notifications 714 After having successfully processed the informative response as 715 defined in Section 3.2, the client will receive, accept and process 716 multicast notifications about the state of the target resource from 717 the server, as responses to the phantom registration request and with 718 Token value T. 720 The client relies on the value of the Observe option for notification 721 reordering, as defined in Section 3.4 of [RFC7641]. 723 3.4. Cancellation 725 At a certain point in time, a client may become not interested in 726 receiving further multicast notifications about a target resource. 727 When this happens, the client can simply "forget" about being part of 728 the group observation for that target resource, as per Section 3.6 of 729 [RFC7641]. 731 When, later on, the server sends the next multicast notification, the 732 client will not recognize the Token value T in the message. Since 733 the multicast notification is Non-confirmable, it is OPTIONAL for the 734 client to reject the multicast notification with a Reset message, as 735 defined in Section 3.5 of [RFC7641]. 737 In case the server has canceled a group observation as defined in 738 Section 2.5, the client simply forgets about the group observation 739 and frees up the used Token value T for that endpoint, upon receiving 740 the multicast error response defined in Section 2.5. 742 4. Web Linking 744 The possible use of multicast notifications in a group observation 745 may be indicated by a target "grp_obs" attribute in a web link 746 [RFC8288] to a resource, e.g. using a link-format document [RFC6690] 747 if the resource is accessible over CoAP. 749 The "grp_obs" attribute is a hint, indicating that the server might 750 send multicast notifications for observations of the resource 751 targeted by the link. Note that this is simply a hint, i.e. it does 752 not include any information required to participate in a group 753 observation, and to receive and process multicast notifications. 755 A value MUST NOT be given for the "grp_obs" attribute; any present 756 value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT 757 appear more than once in a given link-value; occurrences after the 758 first MUST be ignored by parsers. 760 The example in Figure 4 shows a use of the "grp_obs" attribute: the 761 client does resource discovery on a server and gets back a list of 762 resources, one of which includes the "grp_obs" attribute indicating 763 that the server might send multicast notifications for observations 764 of that resource. The link-format notation (see Section 5 of 765 [RFC6690]) is used. 767 REQ: GET /.well-known/core 769 RES: 2.05 Content 770 ;grp_obs, 771 ;if="sensor" 773 Figure 4: The Web Link 775 5. Example 777 The following example refers to two clients C_1 and C_2 that register 778 to observe a resource /r at a Server S, which has address SRV_ADDR 779 and listens to the port number SRV_PORT. Before the following 780 exchanges occur, no clients are observing the resource /r , which has 781 value "1234". 783 The server S sends multicast notifications to the IP multicast 784 address GRP_ADDR and port number GRP_PORT, and starts the group 785 observation upon receiving a registration request from a first client 786 that wishes to start a traditional observation on the resource /r. 788 The following notation is used for the payload of the informative 789 responses: 791 * 'bstr(X)' denotes a CBOR byte string with value the byte 792 serialization of X, with '|' denoting byte concatenation. 794 * 'OPT' denotes a sequence of CoAP options. This refers to the 795 phantom registration request encoded by the 'ph_req' parameter, or 796 to the corresponding latest multicast notification encoded by the 797 'last_notif' parameter. 799 * 'PAYLOAD' denotes a CoAP payload. This refers to the latest 800 multicast notification encoded by the 'last_notif' parameter. 802 C_1 ----------------- [ Unicast ] ------------------------> S /r 803 | GET | 804 | Token: 0x4a | 805 | Observe: 0 (Register) | 806 | | 807 | | 808 | (S allocates the available Token value 0x7b .) | 809 | | 810 | | 811 | | 812 | (S sends to itself a phantom observation request PH_REQ | 813 | as coming from the IP multicast address GRP_ADDR .) | 814 | ------------------------------------------------ | 815 | / | 816 | \----------------------------------------------------> | /r 817 | GET | 818 | Token: 0x7b | 819 | Observe: 0 (Register) | 820 | | 821 | | 822 | (S creates a group observation of /r .) | 823 | | 824 | (S increments the observer counter | 825 | for the group observation of /r .) | 826 | | 827 C_1 <-------------------- [ Unicast ] --------------------- S 828 | 5.03 | 829 | Token: 0x4a | 830 | Content-Format: application/informative-response+cbor | 831 | | 832 | Payload: { | 833 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 834 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 835 | ph_req : bstr(0x01 | OPT), | 836 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 837 | } | 838 | | 839 C_2 ----------------- [ Unicast ] ------------------------> S /r 840 | GET | 841 | Token: 0x01 | 842 | Observe: 0 (Register) | 843 | | 844 | | 845 | (S increments the observer counter | 846 | for the group observation of /r .) | 847 | | 848 | | 849 C_2 <-------------------- [ Unicast ] --------------------- S 850 | 5.03 | 851 | Token: 0x01 | 852 | Content-Format: application/informative-response+cbor | 853 | | 854 | Payload: { | 855 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 856 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 857 | ph_req : bstr(0x01 | OPT), | 858 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 859 | } | 860 | | 861 | (The value of the resource /r changes to "5678".) | 862 | | 863 C_1 | 864 + <------------------- [ Multicast ] -------------------- S 865 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 866 | 2.05 | 867 | Token: 0x7b | 868 | Observe: 11 | 869 | Content-Format: application/cbor | 870 | | 871 | Payload: : "5678" | 872 | | 874 Figure 5: Example of group observation 876 6. Rough Counting of Clients in the Group Observation 878 To allow the server to keep an estimate of interested clients without 879 creating undue traffic on the network, a new CoAP option is 880 introduced, which SHOULD be supported by clients that listen to 881 multicast responses. 883 The option is called Multicast-Response-Feedback-Divider. As 884 summarized in Figure 6, the option is not critical but proxy-unsafe, 885 and integer valued. 887 +-----+---+---+---+---+---------------------+--------+------+---------+ 888 | No. | C | U | N | R | Name | Format | Len. | Default | 889 +-----+---+---+---+---+---------------------+--------+------+---------+ 890 | TBD | | x | | | Multicast-Response- | uint | 0-1 | (none) | 891 | | | | | | Feedback-Divider | | | | 892 +-----+---+---+---+---+---------------------+--------+------+---------+ 894 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 895 Figure 6: Multicast-Response-Feedback-Divider 897 The Multicast-Response-Feedback-Divider option is of class E for 898 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 900 6.1. Processing on the Client Side 902 Upon receiving a response with a Multicast-Response-Feedback-Divider 903 option, a client SHOULD acknowledge its interest in continuing 904 receiving multicast notifications for the target resource, as 905 described below. 907 The client picks an integer random number I, from 0 inclusive to the 908 number Z = (2 ** Q) exclusive, where Q is the value specified in the 909 option and "**" is the exponentiation operator. If I is different 910 than 0, the client takes no further action. Otherwise, the client 911 should wait a random fraction of the Leisure time (see Section 8.2 of 912 [RFC7252]), and then registers a regular unicast observation on the 913 same target resource. 915 To this end, the client essentially follows the steps that got it 916 originally subscribed to group notifications for the target resource. 917 In particular, the client sends an observation request to the server, 918 i.e. a GET request with an Observe option set to 0 (register). The 919 request MUST be addressed to the same target resource, and MUST have 920 the same destination IP address and port number used for the original 921 registration request, regardless the source IP address and port 922 number of the received multicast notification. 924 Since the observation registration is only done for its side effect 925 of showing as an attempted observation at the server, the client MUST 926 send the unicast request in a non confirmable way, and with the 927 maximum No-Response setting [RFC7967]. In the request, the client 928 MUST include a Multicast-Response-Feedback-Divider option, whose 929 value MUST be empty (Option Length = 0). The client does not need to 930 wait for responses, and can keep processing further notifications on 931 the same token. 933 The client MUST ignore the Multicast-Response-Feedback-Divider 934 option, if the multicast notification is retrieved from the 935 'last_notif' parameter of an informative response (see Section 2.2). 936 A client includes the Multicast-Response-Feedback-Divider option only 937 in a re-registration request triggered by the server as described 938 above, and MUST NOT include it in any other request. 940 As the Multicast-Response-Feedback-Divider option is unsafe to 941 forward, a proxy needs to answer it on its own, and is later counted 942 as a single client. 944 Appendix B.1 provides a description in pseudo-code of the operations 945 above performed by the client. 947 6.2. Processing on the Server Side 949 In order to avoid needless use of network resources, a server SHOULD 950 keep a rough, updated count of the number of clients taking part in 951 the group observation of a target resource. To this end, the server 952 updates the value COUNT of the associated observer counter (see 953 Section 2), for instance by using the method described below. 955 6.2.1. Request for Feedback 957 When it wants to obtain a new estimated count, the server considers a 958 number M of confirmations it would like to receive from the clients. 959 It is up to applications to define policies about how the server 960 determines and possibly adjusts the value of M. 962 Then, the server computes the value Q = max(L, 0), where: 964 * L is computed as L = ceil(log2(N / M)). 966 * N is the current value of the observer counter, possibly rounded 967 up to 1, i.e. N = max(COUNT, 1). 969 Finally, the server sets Q as the value of the Multicast-Response- 970 Feedback-Divider option, which is sent within a successful multicast 971 notification. 973 If several multicast notifications are sent in a burst fashion, it is 974 RECOMMENDED for the server to include the Multicast-Response- 975 Feedback-Divider option only in the first one of those notifications. 977 6.2.2. Collection of Feedback 979 The server collects unicast observation requests from the clients, 980 for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this 981 time, the server regularly increments the observer counter when 982 adding a new client to the group observation (see Section 2.2). 984 It is up to applications to define the value of 985 MAX_CONFIRMATION_WAIT, which has to take into account the 986 transmission time of the multicast notification and of unicast 987 observation requests, as well as the leisure time of the clients, 988 which may be hard to know or estimate for the server. 990 If this information is not known to the server, it is recommended to 991 define MAX_CONFIRMATION_WAIT as follows. 993 MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY 995 where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has 996 default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is 997 equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 2.3.1 of 998 [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In 999 the absence of more specific information, the server can thus 1000 consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. 1002 If more information is available in deployments, a much shorter 1003 MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic 1004 round trip time (replacing MAX_RTT) and on the largest leisure time 1005 configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g. 1006 DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to 1007 a few seconds. 1009 6.2.3. Processing of Feedback 1011 Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the 1012 R confirmations arrived as unicast observation requests to the target 1013 resource, since the multicast notification with the Multicast- 1014 Response-Feedback-Divider option has been sent. In particular, the 1015 server considers a unicast observation request as a confirmation from 1016 a client only if it includes a Multicast-Response-Feedback-Divider 1017 option with an empty value (Option Length = 0). 1019 Then, the server computes a feedback indicator as E = R * (2 ** Q), 1020 where "**" is the exponentiation operator. According to what defined 1021 by application policies, the server determines the next time when to 1022 ask clients for their confirmation, e.g. after a certain number of 1023 multicast notifications has been sent. For example, the decision can 1024 be influenced by the reception of no confirmations from the clients, 1025 i.e. R = 0, or by the value of the ratios (E/N) and (N/E). 1027 Finally, the server computes a new estimated count of the observers. 1028 To this end the server first consider COUNT' as the current value of 1029 the observer counter at this point in time. Note that COUNT' may be 1030 greater than the value COUNT used at the beginning of this process, 1031 if the server has incremented the observer counter upon adding new 1032 clients to the group observation (see Section 2.2). 1034 In particular, the server computes the new estimated count value as 1035 COUNT' + ((E - N) / D), where D > 0 is an integer value used as 1036 dampener. This step has to be performed atomically. That is, until 1037 this step is completed, the server MUST hold the processing of an 1038 observation request for the same target resource from a new client. 1039 Finally, the server considers the result as the current observer 1040 counter, and assesses it for possibly canceling the group observation 1041 (see Section 2.5). 1043 This estimate is skewed by packet loss, but it gives the server a 1044 sufficiently good estimation for further counts and for deciding when 1045 to cancel the group observation. It is up to applications to define 1046 policies about how the server takes the newly updated estimate into 1047 account and determines whether to cancel the group observation. 1049 As an example, if the server currently estimates that N = COUNT = 32 1050 observers are active and considers a constant M = 8, it sends out a 1051 notification with Multicast-Response-Feedback-Divider: 2. Then, out 1052 of 18 actually active clients, 5 send a re-registration request based 1053 on their random draw, of which one request gets lost, thus leaving 4 1054 re-registration requests received by the server. Also, no new 1055 clients have been added to the group observation during this time, 1056 i.e. COUNT' is equal to COUNT. As a consequence, assuming that a 1057 dampener value D = 1 is used, the server computes the new estimated 1058 count value as 32 + (16 - 32) = 16, and keeps the group observation 1059 active. 1061 To produce a most accurate updated counter, a server can include a 1062 Multicast-Response-Feedback-Divider option with value Q = 0 in its 1063 multicast notifications, as if M is equal to N. This will trigger 1064 all the active clients to state their interest in continuing 1065 receiving notifications for the target resource. Thus, the amount R 1066 of arrived confirmations is affected only by possible packet loss. 1068 Appendix B.3 provides a description in pseudo-code of the operations 1069 above performed by the server, including example behaviors for 1070 scheduling the next count update and deciding whether to cancel the 1071 group observation. 1073 7. Protection of Multicast Notifications with Group OSCORE 1075 A server can protect multicast notifications by using Group OSCORE 1076 [I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected 1077 end-to-end with the observer clients. This requires that both the 1078 server and the clients interested in receiving multicast 1079 notifications from that server are members of the same OSCORE group. 1081 In some settings, the OSCORE group to refer to can be pre-configured 1082 on the clients and the server. In such a case, a server which is 1083 aware of such pre-configuration can simply assume a client to be 1084 already member of the correct OSCORE group. 1086 In any other case, the server MAY communicate to clients what OSCORE 1087 group they are required to join, by providing additional guidance in 1088 the informative response as described in Section 7.1. Note that 1089 clients can already be members of the right OSCORE group, in case 1090 they have previously joined it to securely communicate with the same 1091 and/or other servers to access their resources. 1093 Both the clients and the server MAY join the OSCORE group by using 1094 the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and 1095 based on the ACE framework for Authentication and Authorization in 1096 constrained environments [I-D.ietf-ace-oauth-authz]. Further details 1097 on how to discover the OSCORE group and join it are out of the scope 1098 of this specification. 1100 If multicast notifications are protected using Group OSCORE, the 1101 original registration requests and related unicast (notification) 1102 responses MUST also be secured, including and especially the 1103 informative responses from the server. 1105 To this end, alternative security protocols than Group OSCORE, such 1106 as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can 1107 be used to protect other exchanges via unicast between the server and 1108 each client, including the original client registration (see 1109 Section 3). 1111 7.1. Signaling the OSCORE Group in the Informative Response 1113 This section describes a mechanism for the server to communicate to 1114 the client what OSCORE group to join in order to decrypt and verify 1115 the multicast notifications protected with group OSCORE. The client 1116 MAY use the information provided by the server to start the ACE 1117 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 1118 This mechanism is OPTIONAL to support for the client and server. 1120 Additionally to what defined in Section 2, the CBOR map in the 1121 informative response payload contains the following fields, whose 1122 CBOR labels are defined in Section 11. 1124 * 'join_uri', with value the URI for joining the OSCORE group at the 1125 respective Group Manager, encoded as a CBOR text string. If the 1126 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 1127 for joining, this field specifically indicates the URI of the 1128 group-membership resource at the Group Manager. 1130 * 'sec_gp', with value the name of the OSCORE group, encoded as a 1131 CBOR text string. 1133 * Optionally, 'as_uri', with value the URI of the Authorization 1134 Server associated to the Group Manager for the OSCORE group, 1135 encoded as a CBOR text string. 1137 * Optionally, 'cs_alg', with value the COSE algorithm 1138 [I-D.ietf-cose-rfc8152bis-algs] used to countersign messages in 1139 the OSCORE group, encoded as a CBOR text string or integer. The 1140 value is taken from the 'Value' column of the "COSE Algorithms" 1141 registry [COSE.Algorithms]. 1143 * Optionally, 'cs_alg_crv', with value the elliptic curve (if 1144 applicable) for the COSE algorithm [I-D.ietf-cose-rfc8152bis-algs] 1145 used to countersign messages in the OSCORE group, encoded as a 1146 CBOR text string or integer. The value is taken from the 'Value' 1147 column of the "COSE Elliptic Curve" registry 1148 [COSE.Elliptic.Curves]. 1150 * Optionally, 'cs_key_kty', with value the COSE key type 1151 [I-D.ietf-cose-rfc8152bis-struct] of countersignature keys used to 1152 countersign messages in the OSCORE group, encoded as a CBOR text 1153 string or an integer. The value is taken from the 'Value' column 1154 of the "COSE Key Types" registry [COSE.Key.Types]. 1156 * Optionally, 'cs_key_crv', with value the elliptic curve (if 1157 applicable) of countersignature keys used to countersign messages 1158 in the OSCORE group, encoded as a CBOR text string or integer. 1159 The value is taken from the 'Value' column of the "COSE Elliptic 1160 Curve" registry [COSE.Elliptic.Curves]. 1162 * Optionally, 'cs_kenc', with value the encoding of the public keys 1163 used in the OSCORE group, encoded as a CBOR integer. The value is 1164 taken from the 'Confirmation Key' column of the "CWT Confirmation 1165 Method" registry defined in [RFC8747]. Future specifications may 1166 define additional values for this parameter. 1168 * Optionally, 'alg', with value the COSE AEAD algorithm 1169 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 1170 integer. The value is taken from the 'Value' column of the "COSE 1171 Algorithms" registry [COSE.Algorithms]. 1173 * Optionally, 'hkdf', with value the COSE HKDF algorithm 1174 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 1175 integer. The value is taken from the 'Value' column of the "COSE 1176 Algorithms" registry [COSE.Algorithms]. 1178 The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' and 1179 'cs_key_kenc' provide an early knowledge of the format and encoding 1180 of public keys used in the OSCORE group. Thus, the client does not 1181 need to ask the Group Manager for this information as a preliminary 1182 step before the (ACE) join process, or to perform a trial-and-error 1183 exchange with the Group Manager upon joining the group. Hence, the 1184 client is able to provide the Group Manager with its own public key 1185 in the correct expected format and encoding, at the very first step 1186 of the (ACE) join process. 1188 The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge 1189 of the algorithms used in the OSCORE group. Thus, the client is able 1190 to decide whether to actually proceed with the (ACE) join process, 1191 depending on its support for the indicated algorithms. 1193 As mentioned above, since this mechanism is OPTIONAL, all the fields 1194 are OPTIONAL in the informative response. However, the 'join_uri' 1195 and 'sec_gp' fields MUST be present if the mechanism is implemented 1196 and used. If any of the fields are present without the 'join_uri' 1197 and 'sec_gp' fields present, the client MUST ignore these fields, 1198 since they would not be sufficient to start the (ACE) join procedure. 1199 When this happens, the client MAY try sending a new registration 1200 request to the server (see Section 3.1). Otherwise, the client 1201 SHOULD explicitly withdraw from the group observation. 1203 Appendix C describes a possible alternative approach, where the 1204 server self-manages the OSCORE group, and provides the observer 1205 clients with the necessary keying material in the informative 1206 response. The approach in Appendix C MUST NOT be used together with 1207 the mechanism defined in this section for indicating what OSCORE 1208 group to join. 1210 7.2. Server-Side Requirements 1212 When using Group OSCORE to protect multicast notifications, the 1213 server performs the operations described in Section 2, with the 1214 following differences. 1216 7.2.1. Registration 1218 The phantom registration request MUST be secured, by using Group 1219 OSCORE. In particular, the group mode of Group OSCORE defined in 1220 Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. 1222 The server protects the phantom registration request as defined in 1223 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the 1224 actual sender, i.e. by using its Sender Context. As a consequence, 1225 the server consumes the current value of its Sender Sequence Number 1226 SN in the OSCORE group, and hence updates it to SN* = (SN + 1). 1227 Consistently, the OSCORE option in the phantom registration request 1228 includes: 1230 * As 'kid', the Sender ID of the server in the OSCORE group. 1232 * As 'piv', the previously consumed Sender Sequence Number value SN 1233 of the server in the OSCORE group, i.e. (SN* - 1). 1235 7.2.2. Informative Response 1237 The value of the CBOR byte string in the 'ph_req' parameter encodes 1238 the phantom observation request as a message protected with Group 1239 OSCORE (see Section 7.2.1). As a consequence: the specified Code is 1240 always 0.05 (FETCH); the sequence of CoAP options will be limited to 1241 the outer, non encrypted options; a payload is always present, as the 1242 authenticated ciphertext followed by the counter signature. 1244 Similarly, the value of the CBOR byte string in the 'last_notif' 1245 parameter encodes the latest multicast notification as a message 1246 protected with Group OSCORE (see Section 7.2.3). This applies also 1247 to the initial multicast notification INIT_NOTIF built in step 6 of 1248 Section 2.1. 1250 Optionally, the informative response includes information on the 1251 OSCORE group to join, as additional parameters (see Section 7.1). 1253 7.2.3. Notifications 1255 The server MUST protect every multicast notification for the target 1256 resource with Group OSCORE. In particular, the group mode of Group 1257 OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST 1258 be used. 1260 The process described in Section 8.3 of 1261 [I-D.ietf-core-oscore-groupcomm] applies, with the following 1262 additions when building the two OSCORE 'external_aad' to encrypt and 1263 countersign the multicast notification (see Sections 4.3.1 and 4.3.2 1264 of [I-D.ietf-core-oscore-groupcomm]). 1266 * The 'request_kid' is the 'kid' value in the OSCORE option of the 1267 phantom registration request, i.e. the Sender ID of the server. 1269 * The 'request_piv' is the 'piv' value in the OSCORE option of the 1270 phantom registration request, i.e. the consumed Sender Sequence 1271 Number SN of the server. 1273 * The 'request_kid_context' is the 'kid context' value in the OSCORE 1274 option of the phantom registration request, i.e. the Group 1275 Identifier value (Gid) of the OSCORE group used as ID Context. 1277 Note that these same values are used to protect each and every 1278 multicast notification sent for the target resource under this group 1279 observation. 1281 7.2.4. Cancellation 1283 When canceling a group observation (see Section 2.5), the phantom 1284 cancellation request MUST be secured, by using Group OSCORE. In 1285 particular, the group mode of Group OSCORE defined in Section 8 of 1286 [I-D.ietf-core-oscore-groupcomm] MUST be used. 1288 Like defined in Section 7.2.1 for the phantom registration request, 1289 the server protects the phantom cancellation request as per 1290 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender 1291 Context and consuming its current Sender Sequence number in the 1292 OSCORE group, from its Sender Context. The following, corresponding 1293 multicast error response defined in Section 2.5 is also protected 1294 with Group OSCORE, as per Section 8.3 of 1295 [I-D.ietf-core-oscore-groupcomm]. 1297 Note that, differently from the multicast notifications, this 1298 multicast error response will be the only one securely paired with 1299 the phantom cancellation request. 1301 7.3. Client-Side Requirements 1303 When using Group OSCORE to protect multicast notifications, the 1304 client performs as described in Section 3, with the following 1305 differences. 1307 7.3.1. Informative Response 1309 Upon receiving the informative response from the server, the client 1310 performs as described in Section 3.2, with the following additions. 1312 Once completed step 2, the client decrypts and verifies the rebuilt 1313 phantom registration request as defined in Section 8.2 of 1314 [I-D.ietf-core-oscore-groupcomm], with the following differences. 1316 * The client MUST NOT perform any replay check. That is, the client 1317 skips step 3 in Section 8.2 of [RFC8613]. 1319 * If decryption and verification of the phantom registration request 1320 succeed: 1322 - The client MUST NOT update the Replay Window in the Recipient 1323 Context associated to the server. That is, the client skips 1324 the second bullet of step 6 in Section 8.2 of [RFC8613]. 1326 - The client MUST NOT take any further process as normally 1327 expected according to [RFC7252]. That is, the client skips 1328 step 8 in Section 8.2 of [RFC8613]. In particular, the client 1329 MUST NOT deliver the phantom registration request to the 1330 application, and MUST NOT take any action in the Token space of 1331 its unicast endpoint, where the informative response has been 1332 received. 1334 - The client stores the values of the 'kid', 'piv' and 'kid 1335 context' fields from the OSCORE option of the phantom 1336 registration request. 1338 * If decryption and verification of the phantom registration request 1339 fail, the client MAY try sending a new registration request to the 1340 server (see Section 3.1). Otherwise, the client SHOULD explicitly 1341 withdraw from the group observation. 1343 * If the informative response includes the parameter 'last_notif', 1344 the client also decrypts and verifies the latest multicast 1345 notification rebuilt in step 4, just like it would for the 1346 multicast notifications transmitted as CoAP messages on the wire 1347 (see Section 7.3.2). The client proceeds with step 5 if 1348 decryption and verification of the latest multicast notification 1349 succeed, or to step 6 otherwise. 1351 7.3.2. Notifications 1353 After having successfully processed the informative response as 1354 defined in Section 7.3.1, the client will decrypt and verify every 1355 multicast notification for the target resource as defined in 1356 Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following 1357 difference. 1359 The client MUST set the two 'external_aad' defined in Sections 4.3.1 1360 and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The 1361 particular way to achieve this is implementation specific. 1363 * 'request_kid' takes the value of the 'kid' field from the OSCORE 1364 option of the phantom registration request (see Section 7.3.1). 1366 * 'request_piv' takes the value of the 'piv' field from the OSCORE 1367 option of the phantom registration request (see Section 7.3.1). 1369 * 'request_kid_context' takes the value of the 'kid context' field 1370 from the OSCORE option of the phantom registration request (see 1371 Section 7.3.1). 1373 Note that these same values are used to decrypt and verify each and 1374 every multicast notification received for the target resource. 1376 The replay protection and checking of multicast notifications is 1377 performed as specified in Section 4.1.3.5.2 of [RFC8613]. 1379 8. Example with Group OSCORE 1381 The following example refers to two clients C_1 and C_2 that register 1382 to observe a resource /r at a Server S, which has address SRV_ADDR 1383 and listens to the port number SRV_PORT. Before the following 1384 exchanges occur, no clients are observing the resource /r , which has 1385 value "1234". 1387 The server S sends multicast notifications to the IP multicast 1388 address GRP_ADDR and port number GRP_PORT, and starts the group 1389 observation upon receiving a registration request from a first client 1390 that wishes to start a traditional observation on the resource /r. 1392 Pairwise communication over unicast is protected with OSCORE, while S 1393 protects multicast notifications with Group OSCORE. Specifically: 1395 * C_1 and S have a pairwise OSCORE Security Context. In particular, 1396 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sender Sequence 1397 Number. Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as 1398 Sender Sequence Number. 1400 * C_2 and S have a pairwise OSCORE Security Context. In particular, 1401 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sender Sequence 1402 Number. Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as 1403 Sender Sequence Number. 1405 * S is a member of the OSCORE group with name "myGroup", and 'kid 1406 context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' 1407 = 5 as Sender ID, and SN_5 = 501 as Sender Sequence Number. 1409 The following notation is used for the payload of the informative 1410 responses: 1412 * 'bstr(X)' denotes a CBOR byte string with value the byte 1413 serialization of X, with '|' denoting byte concatenation. 1415 * 'OPT' denotes a sequence of CoAP options. This refers to the 1416 phantom registration request encoded by the 'ph_req' parameter, or 1417 to the corresponding latest multicast notification encoded by the 1418 'last_notif' parameter. 1420 * 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the 1421 phantom registration request encoded by the 'ph_req' parameter, or 1422 to the corresponding latest multicast notification encoded by the 1423 'last_notif' parameter. 1425 * 'SIGN' denotes the counter signature appended to an encrypted CoAP 1426 payload. This refers to the phantom registration request encoded 1427 by the 'ph_req' parameter, or to the corresponding latest 1428 multicast notification encoded by the 'last_notif' parameter. 1430 C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1431 | 0.05 (FETCH) | 1432 | Token: 0x4a | 1433 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 1434 | | 1435 | 0xff | 1436 | Encrypted_payload { | 1437 | 0x01 (GET), | 1438 | Observe: 0 (Register), | 1439 | | 1440 | } | 1441 | | 1442 | (S allocates the available Token value 0x7b .) | 1443 | | 1445 | | 1446 | (S sends to itself a phantom observation request PH_REQ | 1447 | as coming from the IP multicast address GRP_ADDR .) | 1448 | ------------------------------------------------------ | 1449 | / | 1450 | \-------------------------------------------------------> | /r 1451 | 0.05 (FETCH) | 1452 | Token: 0x7b | 1453 | OSCORE: {kid: 5 ; piv: 501 ; | 1454 | kid context: 57ab2e; ...} | 1455 | | 1456 | 0xff | 1457 | Encrypted_payload { | 1458 | 0x01 (GET), | 1459 | Observe: 0 (Register), | 1460 | | 1461 | } | 1462 | | 1463 | | 1464 | | 1465 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 1466 | | 1467 | (S creates a group observation of /r .) | 1468 | | 1469 | (S increments the observer counter | 1470 | for the group observation of /r .) | 1471 | | 1472 | | 1473 C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1474 | 2.05 (Content) | 1475 | Token: 0x4a | 1476 | OSCORE: {piv: 301; ...} | 1477 | | 1478 | 0xff | 1479 | Encrypted_payload { | 1480 | 5.03 (Service Unavailable), | 1481 | Content-Format: application/informative-response+cbor, | 1482 | , | 1483 | 0xff, | 1484 | CBOR_payload { | 1485 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1486 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1487 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1488 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1489 | join_uri : "coap://myGM/ace-group/myGroup", | 1490 | sec_gp : "myGroup" | 1491 | } | 1492 | } | 1493 | | 1494 | | 1495 C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1496 | 0.05 (FETCH) | 1497 | Token: 0x01 | 1498 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 1499 | | 1500 | 0xff | 1501 | Encrypted_payload { | 1502 | 0x01 (GET), | 1503 | Observe: 0 (Register), | 1504 | | 1505 | } | 1506 | | 1507 | (S increments the observer counter | 1508 | for the group observation of /r .) | 1509 | | 1510 C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1511 | 2.05 (Content) | 1512 | Token: 0x01 | 1513 | OSCORE: {piv: 401; ...} | 1514 | | 1515 | 0xff, | 1516 | Encrypted_payload { | 1517 | 5.03 (Service Unavailable), | 1518 | Content-Format: application/informative-response+cbor, | 1519 | , | 1520 | 0xff, | 1521 | CBOR_payload { | 1522 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1523 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1524 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1525 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1526 | join_uri : "coap://myGM/ace-group/myGroup", | 1527 | sec_gp : "myGroup" | 1528 | } | 1529 | } | 1530 | | 1531 | | 1532 | (The value of the resource /r changes to "5678".) | 1533 | | 1534 C_1 | 1535 + <----------- [ Multicast w/ Group OSCORE ] ------------ S 1536 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 1537 | 2.05 (Content) | 1538 | Token: 0x7b | 1539 | OSCORE: {kid: 5; piv: 502 ; | 1540 | kid context: 57ab2e; ...} | 1541 | | 1542 | 0xff | 1543 | Encrypted_payload { | 1544 | 2.05 (Content), | 1545 | Observe: 11, | 1546 | Content-Format: application/cbor, | 1547 | , | 1548 | 0xff, | 1549 | CBOR_Payload : "5678" | 1550 | } | 1551 | | 1552 | | 1554 Figure 7: Example of group observation with Group OSCORE 1556 The two external_aad used to encrypt and countersign the multicast 1557 notification above have 'request_kid' = 5, 'request_piv' = 501 and 1558 'request_kid_context' = 0x57ab2e. These values are specified in the 1559 'kid', 'piv' and 'kid context' field of the OSCORE option of the 1560 phantom observation request, which is encoded in the 'ph_req' 1561 parameter of the unicast informative response to the two clients. 1562 Thus, the two clients can build the two same external_aad for 1563 decrypting and verifying this multicast notification and the 1564 following ones. 1566 9. Intermediaries 1568 This section specifies how the approach presented in Section 2 and 1569 Section 3 works when a proxy is used between the clients and the 1570 server. In addition to what specified in Section 5.7 of [RFC7252] 1571 and Section 5 of [RFC7641], the following applies. 1573 A client sends its original observation request to the proxy. If the 1574 proxy is not already registered at the server for that target 1575 resource, the proxy forwards the observation request to the server, 1576 hence registering itself as an observer. If the server has an 1577 ongoing group observation for the target resource or decides to start 1578 one, the server considers the proxy as taking part in the group 1579 observation, and replies to the proxy with an informative response. 1581 Upon receiving an informative response, the proxy performs as 1582 specified for the client in Section 3, with the peculiarity that 1583 "consuming" the last notification (if present) means populating its 1584 cache. 1586 In particular, by using the information retrieved from the 1587 informative response, the proxy configures an observation of the 1588 target resource at the origin server, acting as a client directly 1589 taking part in the group observation. 1591 As a consequence, the proxy will listen to the IP multicast address 1592 and port number indicated by the server in the informative response, 1593 as 'cli_addr' and 'cli_port' element of 'req_info' under the 1594 'tp_info' parameter, respectively (see Section 2.2.1.1). 1595 Furthermore, multicast notifications will match the phantom request 1596 stored at the proxy, based on the Token value specified in the 1597 'token' element of 'req_info' under the 'tp_info' parameter in the 1598 informative response. 1600 Then, the proxy performs the following actions. 1602 * If the 'last_notif' field is not present, the proxy responds to 1603 the client with an Empty Acknowledgement (if indicated by the 1604 message type, and if it has not already done so). 1606 * If the 'last_notif' field is present, the proxy rebuilds the 1607 latest multicast notification, as defined in Section 3. Then, the 1608 proxy responds to the client, by forwarding back the latest 1609 multicast notification. 1611 When responding to an observation request from a client, the proxy 1612 also adds that client (and its Token) to the list of its registered 1613 observers for the target resource, next to the older observations. 1615 Upon receiving a multicast notification from the server, the proxy 1616 forwards it back separately to each observer client over unicast. 1617 Note that the notification forwarded back to a certain client has the 1618 same Token value of the original observation request sent by that 1619 client to the proxy. 1621 Note that the proxy configures the observation of the target resource 1622 at the server only once, when receiving the informative response 1623 associated to a (newly started) group observation for that target 1624 resource. 1626 After that, when receiving an observation request from a following 1627 new client to be added to the same group observation, the proxy does 1628 not take any further action with the server. Instead, the proxy 1629 responds to the client either with the latest multicast notification 1630 if available from its cache, or with an Empty Acknowledgement 1631 otherwise, as defined above. 1633 An example is provided in Appendix E. 1635 In the general case with a chain of two or more proxies, every proxy 1636 in the chain takes the role of client with the (next hop towards the) 1637 origin server. Note that the proxy adjacent to the origin server is 1638 the only one in the chain that receives informative responses and 1639 listens to an IP multicast address to receive notifications for the 1640 group observation. Furthermore, every proxy in the chain takes the 1641 role of server with the (previous hop towards the) origin client. 1643 10. Intermediaries Together with End-to-End Security 1645 As defined in Section 7, Group OSCORE can be used to protect 1646 multicast notifications end-to-end between the origin server and the 1647 clients. In such a case, additional actions are required when also 1648 the informative responses from the origin server are protected 1649 specifically end-to-end, by using OSCORE or Group OSCORE. 1651 In fact, the proxy adjacent to the origin server is not able to 1652 access the encrypted payload of such informative responses. Hence, 1653 the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters 1654 necessary to correctly receive multicast notifications and forward 1655 them back to the clients. 1657 Then, differently from what defined in Section 9, each proxy 1658 receiving an informative response simply forwards it back to the 1659 client that has sent the corresponding observation request. Note 1660 that the proxy does not even realize the message to be an actual 1661 informative response, since the outer Code field is set to 2.05 1662 (Content). 1664 Upon receiving the informative response, the client does not 1665 configure an observation of the target resource. Instead, the client 1666 performs a new observe registration request, by transmitting the re- 1667 built phantom request as intended to reach the proxy adjacent to the 1668 origin server. In particular, the client includes the new Listen-To- 1669 Multicast-Responses CoAP option defined in Section 10.1, to provide 1670 that proxy with the transport-specific information required for 1671 receiving multicast notifications for the group observation. 1673 Details on the additional message exchange and processing are defined 1674 in Section 10.2. 1676 10.1. The Listen-To-Multicast-Responses Option 1678 To allow the proxy to listen to the multicast notifications sent by 1679 the server, a new CoAP option is introduced. This option MUST be 1680 supported by clients interested to take part in group observations 1681 through intermediaries, and by proxies that collect multicast 1682 notifications and forward them back to the observer clients. 1684 The option is called Listen-To-Multicast-Responses and is intended 1685 only for requests. As summarized in Figure 8, the option is critical 1686 and proxy-unsafe. 1688 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1689 | No. | C | U | N | R | Name | Format | Len. | Default | 1690 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1691 | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) | 1692 | | | | | | Multicast- | | | | 1693 | | | | | | Responses | | | | 1694 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1696 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 1697 (*) See below. 1699 Figure 8: Listen-To-Multicast-Responses 1701 The Listen-To-Multicast-Responses option includes the serialization 1702 of a CBOR array. This specifies transport-specific message 1703 information required for listening to the multicast notifications of 1704 a group observation, and intended to the proxy adjacent to the origin 1705 server sending those notifications. In particular, the serialized 1706 CBOR array has the same format specified in Section 2.2.1 for the 1707 'tp_info' parameter of the informative response (see Section 2.2). 1709 The Listen-To-Multicast-Responses option is of class U for OSCORE 1710 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1712 10.2. Message Processing 1714 Compared to Section 9, the following additions apply when informative 1715 responses are protected end-to-end between the origin server and the 1716 clients. 1718 After the origin server sends an informative response, each proxy 1719 simply forwards it back to the (previous hop towards the) origin 1720 client that has sent the observation request. 1722 Once received the informative response, the origin client proceeds in 1723 a different way than in Section 7.3.1: 1725 * The client performs all the additional decryption and verification 1726 steps of Section 7.3.1 on the phantom request specified in the 1727 'ph_req' parameter and on the last notification specified in the 1728 'last_notif' parameter (if present). 1730 * The client builds a ticket request (see Appendix B of 1731 [I-D.amsuess-core-cachable-oscore]), as intended to reach the 1732 proxy adjacent to the origin server. The ticket request is 1733 formatted as follows. 1735 - The Token is chosen as the client sees fit. In fact, there is 1736 no reason for this Token to be the same as the phantom 1737 request's. 1739 - The Code field, the outer CoAP options and the encrypted 1740 payload (containing inner options, AEAD tag etc.) are the same 1741 of the phantom request used for the group observation. That 1742 is, they are as specified in the 'ph_req' parameter of the 1743 received informative response. 1745 - An outer Observe option is included and set to 0 (Register). 1746 This will usually be set in the phantom request already. 1748 - The outer options Proxy-Scheme, Uri-Host and Uri-Port are 1749 included, and set to the same values they had in the original 1750 registration request sent by the client. 1752 - The new option Listen-To-Multicast-Responses is included as an 1753 outer option. The value is set to the serialization of the 1754 CBOR array specified by the 'tp_info' parameter of the 1755 informative response. 1757 Note that, except for transport-specific information such as 1758 the Token and Message ID values, every different client 1759 participating to the same group observation (hence rebuilding 1760 the same phantom request) will build the same ticket request. 1762 Note also that, identically to the phantom request, the ticket 1763 request is still protected with Group OSCORE, i.e. it has the 1764 same OSCORE option, encrypted payload and counter signature. 1766 Then, the client sends the ticket request to the next hop towards the 1767 origin server. Every proxy in the chain forwards the ticket request 1768 to the next hop towards the origin server, until the last proxy in 1769 the chain is reached. This last proxy, adjacent to the origin 1770 server, proceeds as follows. 1772 * The proxy MUST NOT further forward the ticket request to the 1773 origin server. 1775 * The proxy removes the Proxy-Scheme, Uri-Host and Uri-Port options 1776 from the ticket request. 1778 * The proxy removes the Listen-To-Multicast-Responses option from 1779 the ticket request, and extracts the conveyed transport-specific 1780 information. 1782 * The proxy rebuilds the phantom request associated to the group 1783 observation, by using the ticket request as directly providing the 1784 required transport-independent information. This includes the 1785 outer Code field, the outer CoAP options and the encrypted payload 1786 concatenated with the counter signature. 1788 * The proxy configures an observation of the target resource at the 1789 origin server, acting as a client directly taking part in the 1790 group observation. To this end, the proxy uses the rebuilt 1791 phantom request and the transport-specific information retrieved 1792 from the Listen-To-Multicast-Responses Option. The particular way 1793 to achieve this is implementation specific. 1795 After that, the proxy will listen to the IP multicast address and 1796 port number indicated in the Listen-To-Multicast-Responses option, as 1797 'cli_addr' and 'cli_port' element of the serialized CBOR array, 1798 respectively. Furthermore, multicast notifications will match the 1799 phantom request stored at the proxy, based on the Token value 1800 specified in the 'token' element of the serialized CBOR array in the 1801 Listen-To-Multicast-Responses option. 1803 An example is provided in Appendix F. 1805 11. Informative Response Parameters 1807 This specification defines a number of fields used in the informative 1808 response message defined in Section 2.2. 1810 The table below summarizes them and specifies the CBOR key to use 1811 instead of the full descriptive name. Note that the media type 1812 application/informative-response+cbor MUST be used when these fields 1813 are transported. 1815 +================+==========+===================+=============+ 1816 | Name | CBOR Key | CBOR Type | Reference | 1817 +================+==========+===================+=============+ 1818 | tp_info | 1 | array | Section 2.2 | 1819 +----------------+----------+-------------------+-------------+ 1820 | ph_req | 2 | byte string | Section 2.2 | 1821 +----------------+----------+-------------------+-------------+ 1822 | last_notif | 3 | byte string | Section 2.2 | 1823 +----------------+----------+-------------------+-------------+ 1824 | join_uri | 4 | text string | Section 7.1 | 1825 +----------------+----------+-------------------+-------------+ 1826 | sec_gp | 5 | text string | Section 7.1 | 1827 +----------------+----------+-------------------+-------------+ 1828 | as_uri | 6 | text string | Section 7.1 | 1829 +----------------+----------+-------------------+-------------+ 1830 | cs_alg | 7 | int / text string | Section 7.1 | 1831 +----------------+----------+-------------------+-------------+ 1832 | cs_crv | 8 | int / text string | Section 7.1 | 1833 +----------------+----------+-------------------+-------------+ 1834 | cs_kty | 9 | int / text string | Section 7.1 | 1835 +----------------+----------+-------------------+-------------+ 1836 | cs_kenc | 10 | int | Section 7.1 | 1837 +----------------+----------+-------------------+-------------+ 1838 | alg | 11 | int / text string | Section 7.1 | 1839 +----------------+----------+-------------------+-------------+ 1840 | hkdf | 12 | int / text string | Section 7.1 | 1841 +----------------+----------+-------------------+-------------+ 1842 | gp_material | 13 | map | Appendix C | 1843 +----------------+----------+-------------------+-------------+ 1844 | srv_pub_key | 14 | byte string | Appendix C | 1845 +----------------+----------+-------------------+-------------+ 1846 | srv_identifier | 15 | byte string | Appendix C | 1847 +----------------+----------+-------------------+-------------+ 1848 | exp | 16 | uint | Appendix C | 1849 +----------------+----------+-------------------+-------------+ 1851 Table 1 1853 12. Transport Protocol Information 1855 This specification defines some values of transport protocol 1856 identifiers to use within the 'tp_info' parameter of the informative 1857 response message defined in Section 2.2 of this specification. 1859 According to the encoding specified in Section 2.2.1, these values 1860 are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' 1861 parameter. 1863 The table below summarizes them, specifies the integer value to use 1864 instead of the full descriptive name, and provides the corresponding 1865 full set of information elements to include in the 'tp_info' 1866 parameter. 1868 +-----------+-------------+-------+----------+-----------+-----------+ 1869 | Transport | Description | Value | Srv Addr | Req Info | Reference | 1870 | Protocol | | | | | | 1871 +-----------+-------------+-------+----------+-----------+-----------+ 1872 | Reserved | This value | 0 | | | [This | 1873 | | is reserved | | | | document] | 1874 | | | | | | | 1875 | UDP | UDP is used | 1 | tp_id | token | [This | 1876 | | as per | | srv_host | cli_host | document] | 1877 | | RFC7252 | | srv_port | ?cli_port | | 1878 +-----------+-------------+-------+----------+-----------+-----------+ 1880 Figure 9: Transport protocol information 1882 13. Security Considerations 1884 The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor 1885 e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for 1886 this document. 1888 If multicast notifications are protected using Group OSCORE, the 1889 original registration requests and related unicast (notification) 1890 responses MUST also be secured, including and especially the 1891 informative responses from the server. This prevents on-path active 1892 adversaries from altering the conveyed IP multicast address and 1893 serialized phantom registration request. Thus, it ensures secure 1894 binding between every multicast notification for a same observed 1895 resource and the phantom registration request that started the group 1896 observation of that resource. 1898 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 1899 so ensuring that the secure binding above is enforced end-to-end 1900 between the server and each observing client. 1902 13.1. Listen-To-Multicast-Responses Option 1904 The CoAP option Listen-To-Multicast-Responses defined in Section 10.1 1905 is of class U for OSCORE and Group OSCORE 1906 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1908 This allows the proxy adjacent to the origin server to access the 1909 option value conveyed in a ticket request (see Section 10.2), and to 1910 retrieve from it the transport-specific information about a phantom 1911 request. By doing so, the proxy becomes able to configure an 1912 observation of the target resource and to receive multicast 1913 notifications matching to the phantom request. 1915 Any proxy in the chain, as well as further possible intermediaries or 1916 on-path active adversaries, are thus able to remove the option or 1917 alter its content, before the ticket request reaches the proxy 1918 adjacent to the origin server. 1920 Removing the option would result in the proxy adjacent to the origin 1921 server to not configure the group observation, if that has not 1922 happened yet. In such a case, the proxy would not receive the 1923 corresponding multicast notifications to be forwarded back to the 1924 clients. 1926 Altering the option content would result in the proxy adjacent to the 1927 origin server to incorrectly configure a group observation (e.g., by 1928 indicating a wrong multicast IP address) hence preventing the correct 1929 reception of multicast notifications and their forwarding to the 1930 clients; or to configure bogus group observations that are currently 1931 not active on the origin server. 1933 In order to prevent what described above, the ticket requests 1934 conveying the Listen-To-Multicast-Responses option can be 1935 additionally protected hop-by-hop. 1937 14. IANA Considerations 1939 This document has the following actions for IANA. 1941 14.1. Media Type Registrations 1943 This specification registers the media type 'application/informative- 1944 response+cbor' for error messages as informative response defined in 1945 Section 2.2 of this specification, when carrying parameters encoded 1946 in CBOR. This registration follows the procedures specified in 1947 [RFC6838]. 1949 * Type name: application 1951 * Subtype name: informative-response+cbor 1953 * Required parameters: N/A 1955 * Optional parameters: N/A 1957 * Encoding considerations: Must be encoded as a CBOR map containing 1958 the parameters defined in Section 2.2 of [this document]. 1960 * Security considerations: See Section 13 of [this document]. 1962 * Interoperability considerations: N/A 1964 * Published specification: [this document] 1966 * Applications that use this media type: The type is used by CoAP 1967 servers and clients that support error messages as informative 1968 response defined in Section 2.2 of [this document]. 1970 * Fragment identifier considerations: N/A 1972 * Additional information: N/A 1974 * Person & email address to contact for further information: 1975 iesg@ietf.org (mailto:iesg@ietf.org) 1977 * Intended usage: COMMON 1979 * Restrictions on usage: None 1981 * Author: Marco Tiloca marco.tiloca@ri.se 1982 (mailto:marco.tiloca@ri.se) 1984 * Change controller: IESG 1986 14.2. CoAP Content-Formats Registry 1988 IANA is asked to add the following entry to the "CoAP Content- 1989 Formats" sub-registry defined in Section 12.3 of [RFC7252], within 1990 the "Constrained RESTful Environments (CoRE) Parameters" registry. 1992 Media Type: application/informative-response+cbor 1994 Encoding: - 1996 ID: TBD 1998 Reference: [this document] 2000 14.3. Informative Response Parameters Registry 2002 This specification establishes the "Informative Response Parameters" 2003 IANA registry. The registry has been created to use the "Expert 2004 Review Required" registration procedure [RFC8126]. Expert review 2005 guidelines are provided in Section 14.6. 2007 The columns of this registry are: 2009 * Name: This is a descriptive name that enables easier reference to 2010 the item. The name MUST be unique. It is not used in the 2011 encoding. 2013 * CBOR Key: This is the value used as CBOR key of the item. These 2014 values MUST be unique. The value can be a positive integer, a 2015 negative integer, or a string. 2017 * CBOR Type: This contains the CBOR type of the item, or a pointer 2018 to the registry that defines its type, when that depends on 2019 another item. 2021 * Reference: This contains a pointer to the public specification for 2022 the item. 2024 This registry has been initially populated by the values in 2025 Section 11. The "Reference" column for all of these entries refers 2026 to sections of this document. 2028 14.4. CoAP Transport Information Registry 2030 This specification defines the subregistry "CoAP Transport 2031 Information" within the "CoRE Parameters" registry. The registry has 2032 been created to use the "Expert Review Required" registration 2033 procedure [RFC8126]. Expert review guidelines are provided in 2034 Section 14.6. 2036 The columns of this registry are: 2038 * Transport Protocol: This is a descriptive name that enables easier 2039 reference to the item. The name MUST be unique. It is not used 2040 in the encoding. 2042 * Description: Text giving an overview of the transport protocol 2043 referred by this item. 2045 * Value: CBOR abbreviation for the transport protocol referred by 2046 this item. Different ranges of values use different registration 2047 policies [RFC8126]. Integer values from -256 to 255 are 2048 designated as Standards Action. Integer values from -65536 to 2049 -257 and from 256 to 65535 are designated as Specification 2050 Required. Integer values greater than 65535 are designated as 2051 Expert Review. Integer values less than -65536 are marked as 2052 Private Use. 2054 * Server Addr: List of elements providing addressing information of 2055 the server. 2057 * Req Info: List of elements providing transport-specific 2058 information related to a pertinent CoAP request. Optional 2059 elements are prepended by '?'. 2061 * Reference: This contains a pointer to the public specification for 2062 the item. 2064 This registry has been initially populated by the values in 2065 Section 12. The "Reference" column for all of these entries refers 2066 to sections of this document. 2068 14.5. CoAP Option Numbers Registry 2070 IANA is asked to enter the following option numbers to the "CoAP 2071 Option Numbers" registry defined in [RFC7252] within the "CoRE 2072 Parameters" registry. 2074 +--------+--------------------------------------+-----------------+ 2075 | Number | Name | Reference | 2076 +--------+--------------------------------------+-----------------+ 2077 | TBD | Multicast-Response-Feedback-Divider | [This document] | 2078 +--------+--------------------------------------+-----------------+ 2079 | TBD | Listen-To-Multicast-Responses | [This document] | 2080 +--------+--------------------------------------+-----------------+ 2082 14.6. Expert Review Instructions 2084 The IANA registries established in this document are defined as 2085 expert review. This section gives some general guidelines for what 2086 the experts should be looking for, but they are being designated as 2087 experts for a reason so they should be given substantial latitude. 2089 Expert reviewers should take into consideration the following points: 2091 * Point squatting should be discouraged. Reviewers are encouraged 2092 to get sufficient information for registration requests to ensure 2093 that the usage is not going to duplicate one that is already 2094 registered and that the point is likely to be used in deployments. 2095 The zones tagged as private use are intended for testing purposes 2096 and closed environments, code points in other ranges should not be 2097 assigned for testing. 2099 * Specifications are required for the standards track range of point 2100 assignment. Specifications should exist for specification 2101 required ranges, but early assignment before a specification is 2102 available is considered to be permissible. Specifications are 2103 needed for the first-come, first-serve range if they are expected 2104 to be used outside of closed environments in an interoperable way. 2106 When specifications are not provided, the description provided 2107 needs to have sufficient information to identify what the point is 2108 being used for. 2110 * Experts should take into account the expected usage of fields when 2111 approving point assignment. The fact that there is a range for 2112 standards track documents does not mean that a standards track 2113 document cannot have points assigned outside of that range. The 2114 length of the encoded value should be weighed against how many 2115 code points of that length are left, the size of device it will be 2116 used on, and the number of code points left that encode to that 2117 size. 2119 15. References 2121 15.1. Normative References 2123 [COSE.Algorithms] 2124 IANA, "COSE Algorithms", 2125 . 2128 [COSE.Elliptic.Curves] 2129 IANA, "COSE Elliptic Curves", 2130 . 2133 [COSE.Key.Types] 2134 IANA, "COSE Key Types", 2135 . 2138 [I-D.ietf-ace-key-groupcomm-oscore] 2139 Tiloca, M., Park, J., and F. Palombini, "Key Management 2140 for OSCORE Groups in ACE", Work in Progress, Internet- 2141 Draft, draft-ietf-ace-key-groupcomm-oscore-09, 2 November 2142 2020, . 2145 [I-D.ietf-ace-oscore-profile] 2146 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2147 "OSCORE Profile of the Authentication and Authorization 2148 for Constrained Environments Framework", Work in Progress, 2149 Internet-Draft, draft-ietf-ace-oscore-profile-15, 26 2150 January 2021, . 2153 [I-D.ietf-core-groupcomm-bis] 2154 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2155 for the Constrained Application Protocol (CoAP)", Work in 2156 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 2157 02, 2 November 2020, . 2160 [I-D.ietf-core-oscore-groupcomm] 2161 Tiloca, M., Selander, G., Palombini, F., and J. Park, 2162 "Group OSCORE - Secure Group Communication for CoAP", Work 2163 in Progress, Internet-Draft, draft-ietf-core-oscore- 2164 groupcomm-10, 2 November 2020, . 2167 [I-D.ietf-cose-rfc8152bis-algs] 2168 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2169 Initial Algorithms", Work in Progress, Internet-Draft, 2170 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 2171 . 2174 [I-D.ietf-cose-rfc8152bis-struct] 2175 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2176 Structures and Process", Work in Progress, Internet-Draft, 2177 draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020, 2178 . 2181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2182 Requirement Levels", BCP 14, RFC 2119, 2183 DOI 10.17487/RFC2119, March 1997, 2184 . 2186 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2187 "Transmission of IPv6 Packets over IEEE 802.15.4 2188 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2189 . 2191 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2192 Specifications and Registration Procedures", BCP 13, 2193 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2194 . 2196 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2197 Application Protocol (CoAP)", RFC 7252, 2198 DOI 10.17487/RFC7252, June 2014, 2199 . 2201 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2202 Application Protocol (CoAP)", RFC 7641, 2203 DOI 10.17487/RFC7641, September 2015, 2204 . 2206 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2207 Bose, "Constrained Application Protocol (CoAP) Option for 2208 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2209 August 2016, . 2211 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2212 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2213 March 2017, . 2215 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2216 Writing an IANA Considerations Section in RFCs", BCP 26, 2217 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2218 . 2220 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2221 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2222 May 2017, . 2224 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 2225 DOI 10.17487/RFC8288, October 2017, 2226 . 2228 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2229 "Object Security for Constrained RESTful Environments 2230 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2231 . 2233 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2234 Representation (CBOR)", STD 94, RFC 8949, 2235 DOI 10.17487/RFC8949, December 2020, 2236 . 2238 15.2. Informative References 2240 [I-D.amsuess-core-cachable-oscore] 2241 Amsuess, C. and M. Tiloca, "Cachable OSCORE", Work in 2242 Progress, Internet-Draft, draft-amsuess-core-cachable- 2243 oscore-00, 13 July 2020, . 2246 [I-D.ietf-ace-oauth-authz] 2247 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2248 H. Tschofenig, "Authentication and Authorization for 2249 Constrained Environments (ACE) using the OAuth 2.0 2250 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 2251 draft-ietf-ace-oauth-authz-36, 16 November 2020, 2252 . 2255 [I-D.ietf-core-coap-pubsub] 2256 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2257 Subscribe Broker for the Constrained Application Protocol 2258 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 2259 core-coap-pubsub-09, 30 September 2019, 2260 . 2263 [I-D.ietf-core-coral] 2264 Hartke, K., "The Constrained RESTful Application Language 2265 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 2266 core-coral-03, 9 March 2020, . 2269 [I-D.ietf-core-resource-directory] 2270 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 2271 Stok, "CoRE Resource Directory", Work in Progress, 2272 Internet-Draft, draft-ietf-core-resource-directory-26, 2 2273 November 2020, . 2276 [I-D.ietf-tls-dtls13] 2277 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2278 Datagram Transport Layer Security (DTLS) Protocol Version 2279 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 2280 dtls13-40, 20 January 2021, . 2283 [I-D.tiloca-core-oscore-discovery] 2284 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 2285 Groups with the CoRE Resource Directory", Work in 2286 Progress, Internet-Draft, draft-tiloca-core-oscore- 2287 discovery-07, 2 November 2020, . 2291 [MOBICOM99] 2292 Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The 2293 Broadcast Storm Problem in a Mobile Ad Hoc Network", 2294 Proceedings of the 5th annual ACM/IEEE international 2295 conference on Mobile computing and networking , August 2296 1999, . 2299 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2300 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2301 January 2012, . 2303 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2304 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2305 . 2307 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2308 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2309 . 2311 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2312 Definition Language (CDDL): A Notational Convention to 2313 Express Concise Binary Object Representation (CBOR) and 2314 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2315 June 2019, . 2317 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2318 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2319 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2320 2020, . 2322 Appendix A. Different Sources for Group Observation Data 2324 While the clients usually receive the phantom registration request 2325 and other information related to the group observation through an 2326 Informative Response, the same data can be made available through 2327 different services, such as the following ones. 2329 A.1. Topic Discovery in Publish-Subscribe Settings 2331 In a Publish-Subscribe scenario ([I-D.ietf-core-coap-pubsub]), a 2332 group observation can be discovered along with topic metadata. For 2333 instance, a discovery step can make the following metadata available. 2335 This example assumes a CoRAL namespace [I-D.ietf-core-coral], that 2336 contains properties analogous to those in the content-format 2337 application/informative-response+cbor. 2339 Request: 2341 GET 2342 Accept: CoRAL 2344 Response: 2346 2.05 Content 2347 Content-Format: CoRAL 2349 rdf:type 2350 topic { 2351 tp_info [1, h"7b", h"20010db80100..0001", 5683, 2352 h"ff35003020010db8..1234", 5683], 2353 ph_req h"0160..", 2354 last_notif h"256105.." 2355 } 2357 Figure 10: Group observation discovery in a Pub-Sub scenario 2359 With this information from the topic discovery step, the client can 2360 already set up its multicast address and start receiving multicast 2361 notifications. 2363 In heavily asymmetric networks like municipal notification services, 2364 discovery and notifications do not necessarily need to use the same 2365 network link. For example, a departure monitor could use its (costly 2366 and usually-off) cellular uplink to discover the topics it needs to 2367 update its display to, and then listen on a LoRA-WAN interface for 2368 receiving the actual multicast notifications. 2370 A.2. Introspection at the Multicast Notification Sender 2372 For network debugging purposes, it can be useful to query a server 2373 that sends multicast responses as matching a phantom registration 2374 request. 2376 Such an interface is left for other documents to specify on demand. 2377 As an example, a possible interface can be as follows, and rely on 2378 the already known Token value of intercepted multicast notifications, 2379 associated to a phantom registration request. 2381 Request: 2383 GET 2385 Response: 2387 2.05 Content 2388 Content-Format: application/informative-response+cbor 2390 { 2391 'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 2392 h"ff35003020010db8..1234", 5683], 2393 'ph_req': h"0160..", 2394 'last_notif' : h"256105.." 2395 } 2397 Figure 11: Group observation discovery with server introspection 2399 For example, a network sniffer could offer sending such a request 2400 when unknown multicast notifications are seen on a network. 2401 Consequently, it can associate those notifications with a URI, or 2402 decrypt them, if member of the correct OSCORE group. 2404 Appendix B. Pseudo-Code for Rough Counting of Clients 2406 This appendix provides a description in pseudo-code of the two 2407 algorithms used for the rough counting of active observers, as 2408 defined in Section 6. 2410 In particular, Appendix B.1 describes the algorithm for the client 2411 side, while Appendix B.2 describes an optimized version for 2412 constrained clients. Finally, Appendix B.3 describes the algorithm 2413 for the server side. 2415 B.1. Client Side 2416 input: int Q, // Value of the MRFD option 2417 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2418 // unless overridden 2420 output: None 2422 int RAND_MIN = 0; 2423 int RAND_MAX = (2**Q) - 1; 2424 int I = randomInteger(RAND_MIN, RAND_MAX); 2426 if (I == 0) { 2427 float fraction = randomFloat(0, 1); 2429 Timer t = new Timer(); 2430 t.setAndStart(fraction * LEISURE_TIME); 2431 while(!t.isExpired()); 2433 Request req = new Request(); 2434 // Initialize as NON and with maximum 2435 // No-Response settings, set options ... 2437 Option opt = new Option(OBSERVE); 2438 opt.set(0); 2439 req.setOption(opt); 2441 opt = new Option(MRFD); 2442 req.setOption(opt); 2444 req.send(SRV_ADDR, SRV_PORT); 2445 } 2447 B.2. Client Side - Optimized Version 2448 input: int Q, // Value of the MRFD option 2449 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2450 // unless overridden 2452 output: None 2454 const unsigned int UINT_BIT = CHAR_BIT * sizeof(unsigned int); 2456 if (respond_to(Q) == true) { 2457 float fraction = randomFloat(0, 1); 2459 Timer t = new Timer(); 2460 t.setAndStart(fraction * LEISURE_TIME); 2461 while(!t.isExpired()); 2463 Request req = new Request(); 2464 // Initialize as NON and with maximum 2465 // No-Response settings, set options ... 2467 Option opt = new Option(OBSERVE); 2468 opt.set(0); 2469 req.setOption(opt); 2471 opt = new Option(MRFD); 2472 req.setOption(opt); 2474 req.send(SRV_ADDR, SRV_PORT); 2475 } 2477 bool respond_to(int Q) { 2478 while (Q >= UINT_BIT) { 2479 if (rand() != 0) return false; 2480 Q -= UINT_BIT; 2481 } 2482 unsigned int mask = ~((~0u) << Q); 2483 unsigned int masked = mask & rand(); 2484 return masked == 0; 2485 } 2487 B.3. Server Side 2489 input: int COUNT, // Current observer counter 2490 int M, // Desired number of confirmations 2491 int MAX_CONFIRMATION_WAIT, 2492 Response notification, // Multicast notification to send 2494 output: int NEW_COUNT // Updated observer counter 2495 int D = 4; // Dampener value 2496 int RETRY_NEXT_THRESHOLD = 4; 2497 float CANCEL_THRESHOLD = 0.2; 2499 int N = max(COUNT, 1); 2500 int Q = max(ceil(log2(N / M)), 0); 2501 Option opt = new Option(MRFD); 2502 opt.set(Q); 2504 notification.setOption(opt); 2505 2506 notification.send(GRP_ADDR, GRP_PORT); 2508 Timer t = new Timer(); 2509 t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 2510 while(!t.isExpired()); 2512 // Time t2 2514 int R = ; 2517 int E = R * (2**Q); 2519 // Determine after how many multicast notifications 2520 // the next count update will be performed 2521 if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) { 2522 2523 } 2524 else { 2525 2526 } 2528 // Compute the new count estimate 2529 int COUNT_PRIME = ; 2530 int NEW_COUNT = COUNT_PRIME + ((E - N) / D); 2532 // Determine whether to cancel the group observation 2533 if (NEW_COUNT < CANCEL_THRESHOLD) { 2534 ; 2535 return 0; 2536 } 2538 return NEW_COUNT; 2540 Appendix C. OSCORE Group Self-Managed by the Server 2542 For simple settings, where no pre-arranged group with suitable 2543 memberships is available, the server can be responsible to setup and 2544 manage the OSCORE group used to protect the group observation. 2546 In such a case, a client would implicitly request to join the OSCORE 2547 group when sending the observe registration request to the server. 2548 When replying, the server includes the group keying material and 2549 related information in the informative response (see Section 2.2). 2551 Additionally to what defined in Section 2, the CBOR map in the 2552 informative response payload contains the following fields, whose 2553 CBOR labels are defined in Section 11. 2555 * 'gp_material': this element is a CBOR map, which includes what the 2556 client needs in order to set up the Group OSCORE Security Context. 2558 This parameter has as value a subset of the 2559 Group_OSCORE_Input_Material object, which is defined in 2560 Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the 2561 OSCORE_Input_Material object encoded in CBOR as defined in 2562 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 2564 In particular, the following elements of the 2565 Group_OSCORE_Input_Material object are included, using the same 2566 CBOR labels from the OSCORE Security Context Parameters Registry, 2567 as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 2569 - 'ms', 'contexId', 'cs_alg', 'cs_params', 'cs_key_params', 2570 'cs_key_enc'. These elements MUST be included. 2572 - 'hkdf', 'alg', 'salt'. These elements MAY be included. 2574 The following elements of the Group_OSCORE_Input_Material object 2575 MUST NOT be included. 2577 - 'group_senderId', 'ecdh_alg', 'ecdh_params', 'ecdh_key_params'. 2579 * 'srv_pub_key': this element is a CBOR byte string, which wraps the 2580 serialization of the public key that the server uses in the OSCORE 2581 group. If the public key of the server is encoded as a COSE_Key 2582 (see the 'cs_key_enc' element of the 'gp_material' parameter), it 2583 includes 'kid' specifying the Sender ID that the server has in the 2584 OSCORE group. 2586 * 'srv_identifier': this element MUST be present only if 2587 'srv_pub_key' is also present and, at the same time, the used 2588 encoding for the public key of the server does not allow to 2589 specify a Sender ID within the associated public key. Otherwise, 2590 it MUST NOT be present. If present, this element is a CBOR byte 2591 string, with value the Sender ID that the server has in the OSCORE 2592 group. 2594 * 'exp': with value the expiration time of the keying material of 2595 the OSCORE group specified in the 'gp_material' parameter, encoded 2596 as a CBOR unsigned integer. This field contains a numeric value 2597 representing the number of seconds from 1970-01-01T00:00:00Z UTC 2598 until the specified UTC date/time, ignoring leap seconds, 2599 analogous to what specified for NumericDate in Section 2 of 2600 [RFC7519]. 2602 A client receiving an informative response uses the information above 2603 to set up the Group OSCORE Security Context, as described in 2604 Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client 2605 does not obtain a Sender ID of its own, hence it installs a Security 2606 Context that a "silent server" would, i.e. without Sender Context. 2607 From then on, the client uses the received keying material to process 2608 the incoming multicast notifications from the server. 2610 The server complies with the following points. 2612 * The server MUST NOT self-manage OSCORE groups and provide the 2613 related keying material in the informative response for any other 2614 purpose than the protection of group observations, as defined in 2615 this document. 2617 The server MAY use the same self-managed OSCORE group to protect 2618 the phantom request and the multicast notifications of multiple 2619 group observations it hosts. 2621 * The server MUST NOT provide in the informative response the keying 2622 material of other OSCORE groups it is or has been a member of. 2624 After the time indicated in the 'exp' field: 2626 * The server MUST stop using the keying material and MUST cancel the 2627 group observations for which that keying material is used (see 2628 Section 2.5). If the server creates a new group observation as a 2629 replacement or follow-up using the same OSCORE group: 2631 - The server MUST update the Master Secret. 2633 - The server MUST update the ID Context (Gid). Consistently with 2634 Section 2.3 of [I-D.ietf-core-oscore-groupcomm], the server 2635 MUST assign an ID Context that it has never assigned before in 2636 the OSCORE group. 2638 - The server MAY update the Master Salt. 2640 * The client MUST stop using the keying material and MAY re-register 2641 the observation at the server. 2643 Before the key material has expired, the server can send a multicast 2644 response with response code 5.03 (Service Unavailable) to the 2645 observing clients, protected with the current key material. In 2646 particular, this is an informative response (see Section 2.2) and 2647 contains the abovementioned parameters for the next group keying 2648 material to be used. Alternatively, the server can simply cancel the 2649 group observation (see Section 2.5), which results in the eventual 2650 re-registration of the clients that are still interested in the group 2651 observation. 2653 Applications requiring backward security and forward security are 2654 REQUIRED to use an actual group joining process (usually through a 2655 dedicated Group Manager), e.g. the ACE joining procedure defined in 2656 [I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the 2657 clients by providing them information about the OSCORE group to join, 2658 as described in Section 7.1. 2660 Appendix D. Phantom Request as Deterministic Request 2662 In some settings, the server can assume that all the approaching 2663 clients already have the exact phantom observation request to use. 2665 For instance, the clients can be pre-configured with the phantom 2666 observation request, or they may be expected to retrieve it through 2667 dedicated means (see Appendix A), before sending an observe 2668 registration request to the server. 2670 If Group OSCORE is used to protect the group observation (see 2671 Section 7), and the OSCORE group supports the concept of 2672 Deterministic Client [I-D.amsuess-core-cachable-oscore], then the 2673 server and each client in the OSCORE group can independently protect 2674 the phantom observation request possibly available as plain CoAP 2675 message. To this end, they use the approach defined in Section 2 of 2676 [I-D.amsuess-core-cachable-oscore] to compute a protected 2677 deterministic request, against which the protected multicast 2678 notifications will match for the group observation in question. 2680 Note that, if the optimization defined in Appendix C is also used, 2681 the error informative response from the server has to include 2682 additional information, i.e. the Sender ID of the Deterministic 2683 Client in the OSCORE group, and the hash algorithm used to compute 2684 the deterministic request (see Section 2.3.1 of 2685 [I-D.amsuess-core-cachable-oscore]). 2687 This optimization allows the server to not provide the same full 2688 phantom observation request to each client in the error informative 2689 response (see Section 2.2). That is, the informative response does 2690 not need to include the 'ph_req' parameter, but only the 'tp_info' 2691 parameter specifying the transport-specific information and 2692 (optionally) the 'last_notif' parameter specifying the latest sent 2693 multicast notification. 2695 Appendix E. Example with a Proxy 2697 This section provides an example when a proxy P is used between the 2698 clients and the server. The same assumptions and notation used in 2699 Section 5 are used for this example. In addition, the proxy has 2700 address PRX_ADDR and listens to the port number PRX_PORT. 2702 Unless explicitly indicated, all messages transmitted on the wire are 2703 sent over unicast. 2705 C1 C2 P S 2706 | | | | 2707 | | | | (The value of the resource /r is "1234") 2708 | | | | 2709 +------------>| | Token: 0x4a 2710 | GET | | | Observe: 0 (Register) 2711 | | | | Proxy-Uri: coap://sensor.example/r 2712 | | | | 2713 | | +------->| Token: 0x5e 2714 | | | GET | Observe: 0 (Register) 2715 | | | | Uri-Host: sensor.example 2716 | | | | Uri-Path: r 2717 | | | | 2718 | | | | (S allocates the available Token value 0x7b) 2719 | | | | 2720 | | | | (S sends to itself a phantom observation 2721 | | | | request PH_REQ as coming from the 2722 | | | | IP multicast address GRP_ADDR) 2723 | | | | 2724 | | | ------+ 2725 | | | / | 2726 | | | \----->| Token: 0x7b 2727 | | | GET | Observe: 0 (Register) 2728 | | | | Uri-Host: sensor.example 2729 | | | | Uri-Path: r 2730 | | | | 2731 | | | | 2732 | | | | (S creates a group observation of /r) 2733 | | | | 2734 | | | | (S increments the observer counter 2735 | | | | for the group observation of /r) 2736 | | | | 2737 | | | | 2738 | | |<-------+ Token: 0x5e 2739 | | | 5.03 | Content-Format: application/ 2740 | | | | informative-response+cbor 2741 | | | | 2742 | | | | Payload: { 2743 | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, 2744 | | | | 0x7b, bstr(GRP_ADDR), 2745 | | | | GRP_PORT], 2746 | | | | ph_req : bstr(0x01 | OPT), 2747 | | | | last_notif : bstr(0x45 | OPT | 2748 | | | | 0xff | PAYLOAD) 2749 | | | | } 2750 | | | | 2751 | | | | (PAYLOAD in 'last_notif' : "1234") 2752 | | | | 2753 | | | | 2754 | | | | (The proxy starts listening to the 2755 | | | | GRP_ADDR address and the GRP_PORT port.) 2756 | | | | 2757 | | | | (The proxy adds C1 to its list of observers.) 2758 | | | | 2759 | | | | 2760 |<------------+ | Token: 0x4a 2761 | 2.05 | | | Content-Format: application/cbor 2762 | | | | 2763 | | | | Payload: "1234" 2764 : : : : 2765 : : : : 2766 : : : : 2767 | +----->| | Token: 0x01 2768 | | GET | | Observe: 0 (Register) 2769 | | | | Proxy-Uri: coap://sensor.example/r 2770 | | | | 2771 | | | | (The proxy has a fresh cache representation) 2772 | | | | 2773 | |<-----+ | Token: 0x01 2774 | | 2.05 | | Content-Format: application/cbor 2775 | | | | 2776 | | | | Payload: "1234" 2777 | | | | 2779 | | | | 2780 : : : : 2781 : : : : (The value of the resource 2782 : : : : /r changes to "5678".) 2783 : : : (*) : 2784 | | |<-------+ Token: 0x7b 2785 | | | 2.05 | Observe: 11 2786 | | | | Content-Format: application/cbor 2787 | | | | 2788 | | | | Payload: "5678" 2789 | | | | 2790 |<------------+ | Token: 0x4a 2791 | 2.05 | | | Observe: 54123 2792 | | | | Content-Format: application/cbor 2793 | | | | 2794 | | | | Payload: "5678" 2795 | | | | 2796 | |<-----+ | Token: 0x01 2797 | | 2.05 | | Observe: 54123 2798 | | | | Content-Format: application/cbor 2799 | | | | 2800 | | | | Payload: "5678" 2802 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT 2804 Figure 12: Example of group observation with a proxy 2806 Note that the proxy has all the information to understand the 2807 observation request from C2, and can immediately start to serve the 2808 still fresh values. 2810 This behavior is mandated by Section 5 of [RFC7641], i.e. the proxy 2811 registers itself only once with the next hop and fans out the 2812 notifications it receives to all registered clients. 2814 Appendix F. Example with a Proxy and Group OSCORE 2816 This section provides an example when a proxy P is used between the 2817 clients and the server, and Group OSCORE is used to protect multicast 2818 notifications end-to-end between the server and the clients. 2820 The same assumptions and notation used in Section 8 are used for this 2821 example. In addition, the proxy has address PRX_ADDR and listens to 2822 the port number PRX_PORT. 2824 Unless explicitly indicated, all messages transmitted on the wire are 2825 sent over unicast and protected with OSCORE end-to-end between a 2826 client and the server. 2828 C1 C2 P S 2829 | | | | (The value of the resource /r is "1234") 2830 | | | | 2831 +-------------->| | Token: 0x4a 2832 | FETCH | | | Observe: 0 (Register) 2833 | | | | OSCORE: {kid: 1 ; piv: 101 ; ...} 2834 | | | | Uri-Host: sensor.example 2835 | | | | Proxy-Scheme: coap 2836 | | | | 2837 | | | | 0xff 2838 | | | | Encrypted_payload { 2839 | | | | 0x01 (GET), 2840 | | | | Observe: 0 (Register), 2841 | | | | Uri-Path: r, 2842 | | | | 2843 | | | | } 2844 | | | | 2845 | | +-------->| Token: 0x5e 2846 | | | FETCH | Observe: 0 (Register) 2847 | | | | OSCORE: {kid: 1 ; piv: 101 ; ...} 2848 | | | | Uri-Host: sensor.example 2849 | | | | 2850 | | | | 0xff 2851 | | | | Encrypted_payload { 2852 | | | | 0x01 (GET), 2853 | | | | Observe: 0 (Register), 2854 | | | | Uri-Path: r, 2855 | | | | 2856 | | | | } 2857 | | | | 2858 | | | | 2859 | | | | (S allocates the available 2860 | | | | Token value 0x7b .) 2861 | | | | 2862 | | | | (S sends to itself a phantom observation 2863 | | | | request PH_REQ as coming from the 2864 | | | | IP multicast address GRP_ADDR) 2865 | | | | 2866 | | | -------+ 2867 | | | / | 2868 | | | \------>| Token: 0x7b 2869 | | | FETCH | Observe: 0 (Register) 2870 | | | | OSCORE: {kid: 5 ; piv: 501 ; 2871 | | | | kid context: 57ab2e; ...} 2872 | | | | Uri-Host: sensor.example 2873 | | | | 2874 | | | | 0xff 2875 | | | | Encrypted_payload { 2876 | | | | 0x01 (GET), 2877 | | | | Observe: 0 (Register), 2878 | | | | Uri-Path: r 2879 | | | | 2880 | | | | } 2881 | | | | 2882 | | | | 2883 | | | | 2884 | | | | (S steps SN_5 in the Group OSCORE 2885 | | | | Security Context : SN_5 <== 502) 2886 | | | | 2887 | | | | (S creates a group observation of /r) 2888 | | | | 2889 | | | | (S increments the observer counter 2890 | | | | for the group observation of /r) 2891 | | | | 2892 | | | | 2893 | | |<--------+ Token: 0x5e 2894 | | | 2.05 | OSCORE: {piv: 301 ; ...} 2895 | | | | 2896 | | | | 0xff 2897 | | | | Encrypted_payload { 2898 | | | | 5.03 (Service Unavailable), 2899 | | | | Content-Format: application/ 2900 | | | | informative-response+cbor, 2901 | | | | , 2902 | | | | 0xff, 2903 | | | | CBOR_payload { 2904 | | | | tp_info : [1, bstr(SRV_ADDR), 2905 | | | | SRV_PORT, 0x7b, 2906 | | | | bstr(GRP_ADDR), GRP_PORT], 2907 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2908 | | | | PAYLOAD | SIGN), 2909 | | | | last_notif : bstr(0x45 | OPT | 0xff | 2910 | | | | PAYLOAD | SIGN), 2911 | | | | join_uri : "coap://myGM/ 2912 | | | | ace-group/myGroup", 2913 | | | | sec_gp : "myGroup" 2914 | | | | } 2915 | | | | } 2916 | | | | 2917 | | | | 2918 |<--------------+ | Token: 0x4a 2919 | 2.05 | | | OSCORE: {piv: 301 ; ...} 2920 | | | | 2921 | | | | 0xff 2922 | | | | (Same Encrypted_payload) 2923 | | | | 2924 | | | | 2925 +-------------->| | Token: 0x4b 2926 | FETCH | | | Observe: 0 (Register) 2927 | | | | OSCORE: {kid: 5 ; piv: 501 ; ...} 2928 | | | | Uri-Host: sensor.example 2929 | | | | Proxy-Scheme: coap 2930 | | | | Listen-To- 2931 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 2932 | | | | SRV_PORT, 0x7b, 2933 | | | | bstr(GRP_ADDR), 2934 | | | | GRP_PORT] 2935 | | | | } 2936 | | | | 2937 | | | | 0xff 2938 | | | | Encrypted_payload { 2939 | | | | 0x01 (GET), 2940 | | | | Observe: 0 (Register), 2941 | | | | Uri-Path: r 2942 | | | | 2943 | | | | } 2944 | | | | 2945 | | | | 2946 | | | | 2947 | | | | (The proxy starts listening to the 2948 | | | | GRP_ADDR address and the GRP_PORT port.) 2949 | | | | 2950 | | | | (The proxy adds C1 to 2951 | | | | its list of observers.) 2952 : : : : 2953 : : : : 2954 : : : : 2955 | +------>| | Token: 0x01 2956 | | FETCH | | Observe: 0 (Register) 2957 | | | | OSCORE: {kid: 2 ; piv: 201 ; ...} 2958 | | | | Uri-Host: sensor.example 2959 | | | | Proxy-Scheme: coap 2960 | | | | 2961 | | | | 0xff 2962 | | | | Encrypted_payload { 2963 | | | | 0x01 (GET), 2964 | | | | Observe: 0 (Register), 2965 | | | | Uri-Path: r, 2966 | | | | 2967 | | | | } 2968 | | | | 2969 | | +-------->| Token: 0x5e 2970 | | | FETCH | Observe: 0 (Register) 2971 | | | | OSCORE: {kid: 2 ; piv: 201 ; ...} 2972 | | | | Uri-Host: sensor.example 2973 | | | | 2974 | | | | 0xff 2975 | | | | Encrypted_payload { 2976 | | | | 0x01 (GET), 2977 | | | | Observe: 0 (Register), 2978 | | | | Uri-Path: r, 2979 | | | | 2980 | | | | } 2981 | | | | 2982 | | |<--------+ Token: 0x5e 2983 | | | 2.05 | OSCORE: {piv: 401 ; ...} 2984 | | | | 2985 | | | | 0xff 2986 | | | | Encrypted_payload { 2987 | | | | 5.03 (Service Unavailable), 2988 | | | | Content-Format: application/ 2989 | | | | informative-response+cbor, 2990 | | | | , 2991 | | | | 0xff, 2992 | | | | CBOR_payload { 2993 | | | | tp_info : [1, bstr(SRV_ADDR), 2994 | | | | SRV_PORT, 0x7b, 2995 | | | | bstr(GRP_ADDR), GRP_PORT], 2996 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2997 | | | | PAYLOAD | SIGN), 2998 | | | | last_notif : bstr(0x45 | OPT | 0xff | 2999 | | | | PAYLOAD | SIGN), 3000 | | | | join_uri : "coap://myGM/ 3001 | | | | ace-group/myGroup", 3002 | | | | sec_gp : "myGroup" 3003 | | | | } 3004 | | | | } 3005 | | | | 3006 | |<------+ | Token: 0x01 3007 | | 2.05 | | OSCORE: {piv: 401 ; ...} 3008 | | | | 3009 | | | | 0xff 3010 | | | | (Same Encrypted_payload) 3011 | | | | 3012 | | | | 3013 | +------>| | Token: 0x02 3014 | | FETCH | | Observe: 0 (Register) 3015 | | | | OSCORE: {kid: 5 ; piv: 501 ; ...} 3016 | | | | Uri-Host: sensor.example 3017 | | | | Proxy-Scheme: coap 3018 | | | | Listen-To- 3019 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 3020 | | | | SRV_PORT, 0x7b, 3021 | | | | bstr(GRP_ADDR), 3022 | | | | GRP_PORT] 3023 | | | | } 3024 | | | | 3025 | | | | 0xff 3026 | | | | Encrypted_payload { 3027 | | | | 0x01 (GET), 3028 | | | | Observe: 0 (Register), 3029 | | | | Uri-Path: r 3030 | | | | 3031 | | | | } 3032 | | | | 3033 | | | | 3034 | | | | (The proxy adds C2 to its list of 3035 | | | | observers, and serves the cached 3036 | | | | response) 3037 | | | | 3038 | |<------+ | Token: 0x02 3039 | | 2.05 | | OSCORE: {piv: 301 ; ...} 3040 | | | | 3041 | | | | 0xff 3042 | | | | (Same as earlier to C1) 3043 : : : : 3044 : : : : 3045 : : : : 3046 | | | | (The value of the resource 3047 | | | | /r changes to "5678".) 3048 | | | | 3049 | | | | 3050 | | | (*) | 3051 | | |<--------+ Token: 0x7b 3052 | | | 2.05 | Observe: 11 3053 | | | | OSCORE: {kid: 5; piv: 502 ; 3054 | | | | kid context: 57ab2e; ...} 3055 | | | | 3056 | | | | 0xff 3057 | | | | Encrypted_payload { 3058 | | | | 2.05 (Content), 3059 | | | | Observe: 11, 3060 | | | | Content-Format: application/cbor, 3061 | | | | , 3062 | | | | 0xff, 3063 | | | | CBOR_Payload : "5678" 3064 | | | | } 3065 | | | | 3066 | | | | 3067 | | | | 3068 |<--------------+ | Token: 0x4b 3069 | 2.05 | | | Observe: 54123 3070 | | | | OSCORE: {kid: 5; piv: 502 ; 3071 | | | | kid context: 57ab2e; ...} 3072 | | | | 3073 | | | | 0xff 3074 | | | | (Same Encrypted_payload) 3075 | | | | 3076 | |<------+ | Token: 0x02 3077 | | 2.05 | | Observe: 54123 3078 | | | | OSCORE: {kid: 5; piv: 502 ; 3079 | | | | kid context: 57ab2e; ...} 3080 | | | | 3081 | | | | 0xff 3082 | | | | (Same Encrypted_payload) 3084 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 3085 with Group OSCORE end-to-end between the server and the clients. 3087 Figure 13: Example of group observation with a proxy and Group OSCORE 3089 Unlike in the unprotected example in Appendix E, the proxy does _not_ 3090 have all the information to perform request deduplication, and can 3091 only recognize the identical request once the client sends the ticket 3092 request. 3094 Acknowledgments 3096 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 3097 Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander 3098 for their comments and feedback. 3100 The work on this document has been partly supported by VINNOVA and 3101 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 3102 (Grant agreement 952652). 3104 Authors' Addresses 3105 Marco Tiloca 3106 RISE AB 3107 Isafjordsgatan 22 3108 SE-16440 Stockholm Kista 3109 Sweden 3111 Email: marco.tiloca@ri.se 3113 Rikard Hoeglund 3114 RISE AB 3115 Isafjordsgatan 22 3116 SE-16440 Stockholm Kista 3117 Sweden 3119 Email: rikard.hoglund@ri.se 3121 Christian Amsuess 3122 Hollandstr. 12/4 3123 1020 Vienna 3124 Austria 3126 Email: christian@amsuess.com 3128 Francesca Palombini 3129 Ericsson AB 3130 Torshamnsgatan 23 3131 SE-16440 Stockholm Kista 3132 Sweden 3134 Email: francesca.palombini@ericsson.com