idnits 2.17.1 draft-tiloca-core-observe-multicast-notifications-05.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 (February 22, 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 2303 -- Looks like a reference, but probably isn't: '2' on line 2305 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-10 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-16 == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') -- 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-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-37 == 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-41 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-08 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 5 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: August 26, 2021 7 F. Palombini 8 Ericsson AB 9 February 22, 2021 11 Observe Notifications as CoAP Multicast Responses 12 draft-tiloca-core-observe-multicast-notifications-05 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 August 26, 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 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 65 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 67 2.2.1. Encoding of Transport-Specific Message Information . 8 68 2.2.2. Encoding of Transport-Independent Message 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 . . . . . . . . . . . . . . . 22 84 6.2.3. Processing of Feedback . . . . . . . . . . . . . . . 22 85 7. Protection of Multicast Notifications with Group OSCORE . . . 24 86 7.1. Signaling the OSCORE Group in the Informative Response . 24 87 7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 26 88 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . 29 94 7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 30 95 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 30 96 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 34 97 10. Intermediaries Together with End-to-End Security . . . . . . 36 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 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 50 115 Appendix A. Different Sources for Group Observation Data . . . . 50 116 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 50 117 A.2. Introspection at the Multicast Notification Sender . . . 51 118 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 52 119 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 52 120 B.2. Client Side - Optimized Version . . . . . . . . . . . . . 53 121 B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 53 122 Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 55 123 Appendix D. Phantom Request as Deterministic Request . . . . . . 57 124 Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 58 125 Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 60 126 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 66 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 129 1. Introduction 131 The Constrained Application Protocol (CoAP) [RFC7252] has been 132 extended with a number of mechanisms, including resource Observation 133 [RFC7641]. This enables CoAP clients to register at a CoAP server as 134 "observers" of a resource, and hence being automatically notified 135 with an unsolicited response upon changes of the resource state. 137 CoAP supports group communication over IP multicast 138 [I-D.ietf-core-groupcomm-bis]. This includes support for Observe 139 registration requests over multicast, in order for clients to 140 efficiently register as observers of a resource hosted at multiple 141 servers. 143 However, in a number of use cases, using multicast messages for 144 responses would also be desirable. That is, it would be useful that 145 a server sends observe notifications for a same target resource to 146 multiple observers as responses over IP multicast. 148 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 149 multiple clients can subscribe to a topic, by observing the related 150 resource hosted at the responsible broker. When a new value is 151 published on that topic, it would be convenient for the broker to 152 send a single multicast notification at once, to all the subscriber 153 clients observing that topic. 155 A different use case concerns clients observing a same registration 156 resource at the CoRE Resource Directory 157 [I-D.ietf-core-resource-directory]. For example, multiple clients 158 can benefit of observation for discovering (to-be-created) OSCORE 159 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 160 Resource Directory updated links and descriptions to join them 161 through the respective Group Manager 162 [I-D.tiloca-core-oscore-discovery]. 164 More in general, multicast notifications would be beneficial whenever 165 several CoAP clients observe a same target resource at a CoAP server, 166 and can be all notified at once by means of a single response 167 message. However, CoAP does not currently define response messages 168 over IP multicast. This specification fills this gap and provides 169 the following twofold contribution. 171 First, it updates [RFC7252] and [RFC7641], by defining a method to 172 deliver Observe notifications as CoAP responses addressed to multiple 173 clients, e.g. over IP multicast. In the proposed method, the group 174 of potential observers entrusts the server to manage the Token space 175 for multicast notifications. By doing so, the server provides all 176 the observers of a target resource with the same Token value to bind 177 to their own observation. That Token value is then used in every 178 multicast notification for the target resource. This is achieved by 179 means of an informative unicast response sent by the server to each 180 observer client. 182 Second, this specification defines how to use Group OSCORE 183 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 184 end-to-end between the server and the observer clients. This is also 185 achieved by means of the informative unicast response mentioned 186 above, which additionally includes parameter values used by the 187 server to protect every multicast notification for the target 188 resource by using Group OSCORE. This provides a secure binding 189 between each of such notifications and the observation of each of the 190 clients. 192 1.1. Terminology 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 196 "OPTIONAL" in this document are to be interpreted as described in BCP 197 14 [RFC2119] [RFC8174] when, and only when, they appear in all 198 capitals, as shown here. 200 Readers are expected to be familiar with terms and concepts described 201 in CoAP [RFC7252], group communication for CoAP 202 [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949], 203 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 205 This specification additionally defines the following terminology. 207 o Traditional observation. A resource observation associated to a 208 single observer client, as defined in [RFC7641]. 210 o Group observation. A resource observation associated to a group 211 of clients. The server sends notifications for the group-observed 212 resource over IP multicast to all the observer clients. 214 o Phantom request. The CoAP request message that the server would 215 have received to start or cancel a group observation on one of its 216 resources. A phantom request is generated inside the server and 217 does not hit the wire. 219 o Informative response. A CoAP response message that the server 220 sends to a given client via unicast, providing the client with 221 information on a group observation. 223 2. Server-Side Requirements 225 The server can, at any time, start a group observation on one of its 226 resources. Practically, the server may want to do that under the 227 following circumstances. 229 o In the absence of observations for the target resource, the server 230 receives a registration request from a first client wishing to 231 start a traditional observation on that resource. 233 o When a certain amount of traditional observations has been 234 established on the target resource, the server decides to make 235 those clients part of a group observation on that resource. 237 The server maintains an observer counter for each group observation 238 to a target resource, as a rough estimation of the observers actively 239 taking part in the group observation. 241 The server initializes the counter to 0 when starting the group 242 observation, and increments it after a new client starts taking part 243 in that group observation. Also, the server should keep the counter 244 up-to-date over time, for instance by using the method described in 245 Section 6. 247 This document does not describe a way for the client to influence the 248 server's decision to start group observations. That is done on 249 purpose: the specified mechanism is expected to be used in situations 250 where sending individual notifications is not feasible, or not 251 preferred beyond a certain number of clients observing a target 252 resource. If applications arise where negotiation does make sense, 253 they are welcome to specify additional means to opt in to multicast 254 notifications. 256 2.1. Request 258 Assuming it is reachable at the address SRV_ADDR and port number 259 SRV_PORT, the server starts a group observation on one of its 260 resources as defined below. The server intends to send multicast 261 notifications for the target resource to the multicast IP address 262 GRP_ADDR and port number GRP_PORT. 264 1. The server builds a phantom observation request, i.e. a GET 265 request with an Observe option set to 0 (register). 267 2. The server selects an available value T, from the Token space of 268 a CoAP endpoint used for messages having: 270 * As source address and port number, the IP multicast address 271 GRP_ADDR and port number GRP_PORT. 273 * As destination address and port number, the server address 274 SRV_ADDR and port number SRV_PORT, intended for accessing the 275 target resource. 277 This Token space is under exclusive control of the server. 279 3. The server processes the phantom observation request above, 280 without transmitting it on the wire. The request is addressed to 281 the resource for which the server wants to start the group 282 observation, as if sent by the group of observers, i.e. with 283 GRP_ADDR as source address and GRP_PORT as source port. 285 4. Upon processing the self-generated phantom registration request, 286 the server interprets it as an observe registration received from 287 the group of potential observer clients. In particular, from 288 then on, the server MUST use T as its own local Token value 289 associated to that observation, with respect to the (previous hop 290 towards the) clients. 292 5. The server does not immediately respond to the phantom 293 observation request with a multicast notification sent on the 294 wire. The server stores the phantom observation request as is, 295 throughout the lifetime of the group observation. 297 6. The server builds a CoAP response message INIT_NOTIF as initial 298 multicast notification for the target resource, in response to 299 the phantom observation request. This message is formatted as 300 other multicast notifications (see Section 2.3) and MUST include 301 the current representation of the target resource as payload. 302 The server stores the message INIT_NOTIF and does not transmit 303 it. The server considers this message as the latest multicast 304 notification for the target resource, until it transmits a new 305 multicast notification for that resource as a CoAP message on the 306 wire. After that, the server deletes the message INIT_NOTIF. 308 2.2. Informative Response 310 After having started a group observation on a target resource, the 311 server proceeds as follows. 313 For each traditional observation ongoing on the target resource, the 314 server MAY cancel that observation. Then, the server considers the 315 corresponding clients as now taking part in the group observation, 316 for which it increases the corresponding observer counter 317 accordingly. 319 The server sends to each of such clients an informative response 320 message, encoded as a unicast response with response code 5.03 321 (Service Unavailable). As per [RFC7641], such a response does not 322 include an Observe option. The response MUST be Confirmable and MUST 323 NOT encode link-local addresses. 325 The Content-Format of the informative response is set to application/ 326 informative-response+cbor, defined in Section 14.2. The payload of 327 the informative response is a CBOR map including the following 328 parameters, whose CBOR labels are defined in Section 11. 330 o 'tp_info', with value a CBOR array. This includes the transport- 331 specific information required to correctly receive multicast 332 notifications bound to the phantom observation request. The CBOR 333 array is formatted as defined in Section 2.2.1. This parameter 334 MUST be included. 336 o 'ph_req', with value the byte serialization of the transport- 337 independent information of the phantom observation request (see 338 Section 2.1), encoded as a CBOR byte string. The value of the 339 CBOR byte string is formatted as defined in Section 2.2.2. This 340 parameter MUST be included. 342 o 'last_notif', with value the byte serialization of the transport- 343 independent information of the latest multicast notification for 344 the target resource, encoded as a CBOR byte string. The value of 345 the CBOR byte string is formatted as defined in Section 2.2.2. 346 This parameter MAY be included. 348 The CDDL notation [RFC8610] provided below describes the payload of 349 the informative response. 351 informative_response_payload = { 352 1 => array, ; 'tp_info', i.e. transport-specific information 353 2 => bstr, ; 'ph_req' (transport-independent information) 354 ? 3 => bstr ; 'last_notif' (transport-independent information) 355 } 357 Figure 1: Format of the informative response payload 359 Upon receiving a registration request to observe the target resource, 360 the server does not create a corresponding individual observation for 361 the requesting client. Instead, the server considers that client as 362 now taking part in the group observation of the target resource, of 363 which it increments the observer counter by 1. Then, the server 364 replies to the client with the same informative response message 365 defined above, which MUST be Confirmable. 367 Note that this also applies when, with no ongoing traditional 368 observations on the target resource, the server receives a 369 registration request from a first client and decides to start a group 370 observation on the target resource. 372 2.2.1. Encoding of Transport-Specific Message Information 374 The CBOR array specified in the 'tp_info' parameter is formatted 375 according to the following CDDL notation. 377 tp_info = [ 378 srv_addr ; Addressing information of the server 379 ? req_info ; Request data extension 380 ] 382 srv_addr = ( 383 tp_id : int, ; Identifier of the used transport protocol 384 + elements ; Number, format and encoding 385 ; based on the value of 'tp_id' 386 ) 388 req_info = ( 389 + elements ; Number, format and encoding based on 390 ; the value of 'tp_id' in 'srv_addr' 391 ) 393 Figure 2: General format of 'tp_info' 395 The 'srv_addr' element of 'tp_info' specifies the addressing 396 information of the server, and includes at least one element 'tp_id' 397 which is formatted as follows. 399 o 'tp_id' : this element is a CBOR integer, which specifies the 400 transport protocol used to transport the CoAP response from the 401 server, i.e. a multicast notification in this specification. 403 This element takes value from the "Value" column of the "CoAP 404 Transport Information" registry defined in Section 14.4 of this 405 specification. This element MUST be present. The value of this 406 element determines: 408 * How many elements are required to follow in 'srv_addr', as well 409 as what information they convey, their encoding and their 410 semantics. 412 * How many elements are required in the 'req_info' element of the 413 'tp_info' array, as well as what information they convey, their 414 encoding and their semantics. 416 This specification registers the integer value 1 ("UDP") to be 417 used as value for the 'tp_id' element, when CoAP responses are 418 transported over UDP. In such a case, the full encoding of the 419 'tp_info' CBOR array is as defined in Section 2.2.1.1. 421 Future specifications that consider CoAP multicast notifications 422 transported over different transport protocols MUST: 424 * Register an entry with an integer value to be used for 'tp_id', 425 in the "CoAP Transport Information" registry defined in 426 Section 14.4 of this specification. 428 * Accordingly, define the elements of the 'tp_info' CBOR array, 429 i.e. the elements following 'tp_id' in 'srv_addr' as well as 430 the elements in 'req_info', as to what information they convey, 431 their encoding and their semantics. 433 The 'req_info' element of 'tp_info' specifies transport-specific 434 information related to a pertinent request message, i.e. the phantom 435 observation request in this specification. The exact format of 436 'req_info' depends on the value of 'tp_id'. 438 Given a specific value of 'tp_id', the complete set of elements 439 composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is 440 indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP 441 Transport Information" registry defined in Section 14.4, 442 respectively. 444 2.2.1.1. UDP Transport-Specific Information 446 When CoAP multicast notifications are transported over UDP as per 447 [RFC7252] and [I-D.ietf-core-groupcomm-bis], the server specifies the 448 integer value 1 ("UDP") as value of 'tp_id' in the 'srv_addr' element 449 of the 'tp_info' CBOR array in the error informative response. Then, 450 the rest of the 'tp_info' CBOR array is defined as follows. 452 o 'srv_addr' includes two more elements following 'tp_id': 454 * 'srv_host': this element is a CBOR byte string, with value the 455 destination IP address of the phantom observation request. 456 This parameter is tagged and identified by the CBOR tag 260 457 "Network Address (IPv4 or IPv6 or MAC Address)". That is, the 458 value of the CBOR byte string is the IP address SRV_ADDR of the 459 server hosting the target resource, from where the server will 460 send multicast notifications for the target resource. This 461 element MUST be present. 463 * 'srv_port': this element is a CBOR unsigned integer, with value 464 the destination port number of the phantom observation request. 465 That is, the specified value is the port number SRV_PORT, from 466 where the server will send multicast notifications for the 467 target resource. This element MUST be present. 469 o 'req_info' includes the following elements: 471 * 'token': this element is a CBOR byte string, with value the 472 Token value of the phantom observation request generated by the 473 server (see Section 2.1). Note that the same Token value is 474 used for the multicast notifications bound to that phantom 475 observation request (see Section 2.3). This element MUST be 476 present. 478 * 'cli_addr': this element is a CBOR byte string, with value the 479 source IP address of the phantom observation request. This 480 parameter is tagged and identified by the CBOR tag 260 "Network 481 Address (IPv4 or IPv6 or MAC Address)". That is, the value of 482 the CBOR byte string is the IP multicast address GRP_ADDR, 483 where the server will send multicast notifications for the 484 target resource. This element MUST be present. 486 * 'cli_port': this element is a CBOR unsigned integer, with value 487 the source port number of the phantom observation request. 488 That is, the specified value is the port number GRP_PORT, where 489 the server will send multicast notifications for the target 490 resource. This element is OPTIONAL. If not included, the 491 default port number 5683 is assumed. 493 The CDDL notation provided below describes the full 'tp_info' CBOR 494 array using the format above. 496 tp_info = [ 497 tp_id : 1, ; UDP as transport protocol 498 srv_host : #6.260(bstr), ; Src. address of multicast notifications 499 srv_port : uint, ; Src. port of multicast notifications 500 token : bstr, ; Token of the phantom request and 501 ; associated multicast notifications 502 cli_addr : #6.260(bstr), ; Dst. address of multicast notifications 503 ? cli_port : uint ; Dst. port of multicast notifications 504 ] 506 Figure 3: Format of 'tp_info' with UDP as transport protocol 508 2.2.2. Encoding of Transport-Independent Message Information 510 For both the parameters 'ph_req' and 'last_notif' in the informative 511 response, the value of the byte string is the concatenation of the 512 following components, in the order specified below. 514 When defining the value of each component, "CoAP message" refers to 515 the phantom observation request for the 'ph_req' parameter, and to 516 the corresponding latest multicast notification for the 'last_notif' 517 parameter. 519 o A single byte, with value the content of the Code field in the 520 CoAP message. 522 o The byte serialization of the complete sequence of CoAP options in 523 the CoAP message. 525 o If the CoAP message includes a non-zero length payload, the one- 526 byte Payload Marker (0xff) followed by the payload. 528 2.3. Notifications 530 Upon a change in the status of the target resource under group 531 observation, the server sends a multicast notification, intended to 532 all the clients taking part in the group observation of that 533 resource. In particular, each of such multicast notifications is 534 formatted as follows. 536 o It MUST be Non-confirmable. 538 o It MUST include an Observe option, as per [RFC7641]. 540 o It MUST have the same Token value T of the phantom registration 541 request that started the group observation. This Token value is 542 specified in the 'token' element of 'req_info' under the 'tp_info' 543 parameter, in the informative response message sent to all the 544 observer clients. 546 That is, every multicast notification for a target resource is not 547 bound to the observation requests from the different clients, but 548 rather to the phantom registration request associated to the whole 549 set of clients taking part in the group observation of that 550 resource. 552 o It MUST be sent from the same IP address SRV_ADDR and port number 553 SRV_PORT where: i) the original Observe registration requests are 554 sent to by the clients; and ii) the corresponding informative 555 responses are sent from by the server (see Section 2.2). These 556 are indicated to the observer clients as value of the 'srv_host' 557 and 'srv_port' elements of 'srv_addr' under the 'tp_info' 558 parameter, in the informative response message (see 559 Section 2.2.1.1). That is, redirection MUST NOT be used. 561 o It MUST be sent to the IP multicast address GRP_ADDR and port 562 number GRP_PORT. These are indicated to the observer clients as 563 value of the 'cli_addr' and 'cli_port' elements of 'req_info' 564 under the 'tp_info' parameter, in the informative response message 565 (see Section 2.2.1.1). 567 For each target resource with an active group observation, the server 568 MUST store the latest multicast notification. 570 2.4. Congestion Control 572 In order to not cause congestion, the server should conservatively 573 control the sending of multicast notifications. In particular: 575 o The multicast notifications MUST be Non-confirmable. 577 o In constrained environments such as low-power, lossy networks 578 (LLNs), the server should only support multicast notifications for 579 resources that are small. Following related guidelines from 580 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], this can consist, 581 for example, in having the payload of multicast notifications as 582 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 583 size, so that it fits into a single link-layer frame in case IPv6 584 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 585 Section 4 of [RFC4944]) is used. 587 o The server SHOULD provide multicast notifications with the 588 smallest possible IP multicast scope that fulfills the application 589 needs. For example, following related guidelines from 590 Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], site-local scope 591 is always preferred over global scope IP multicast, if this 592 fulfills the application needs. Similarly, realm-local scope is 593 always preferred over site-local scope, if this fulfills the 594 application needs. 596 o Following related guidelines from Section 4.5.1 of [RFC7641], the 597 server SHOULD NOT send more than one multicast notification every 598 3 seconds, and SHOULD use an even less aggressive rate when 599 possible (see also Section 3.1.2 of [RFC8085]). The transmission 600 rate of multicast notifications should also take into account the 601 avoidance of a possible "broadcast storm" problem [MOBICOM99]. 602 This prevents a following, considerable increase of the channel 603 load, whose origin would be likely attributed to a router rather 604 than the server. 606 2.5. Cancellation 608 At any point in time, the server may want to cancel a group 609 observation of a target resource. For instance, the server may 610 realize that no clients or not enough clients are interested in 611 taking part in the group observation anymore. A possible approach 612 that the server can use to assess this is defined in Section 6. 614 In order to cancel the group observation, the server sends to itself 615 a phantom cancellation request, i.e. a GET request with an Observe 616 option set to 1 (deregister), without transmitting it on the wire. 617 As per Section 3.6 of [RFC7641], all other options MUST be identical 618 to those in the phantom registration request, except for the set of 619 ETag Options. This request has the same Token value T of the phantom 620 registration request, and is addressed to the resource for which the 621 server wants to end the group observation, as if sent by the group of 622 observers, i.e. with the multicast IP address GRP_ADDR as source 623 address and the port number GRP_PORT as source port. 625 After that, the server sends a multicast response with response code 626 5.03 (Service Unavailable), signaling that the group observation has 627 been terminated. The response has no payload, and is sent to the 628 same multicast IP address GRP_ADDR and port number GRP_PORT used to 629 send the multicast notifications related to the target resource. As 630 per [RFC7641], this response does not include an Observe option. 631 Finally, the server releases the resources allocated for the group 632 observation, and especially frees up the Token value T used at its 633 CoAP endpoint. 635 3. Client-Side Requirements 637 3.1. Request 639 A client sends an observation request to the server as described in 640 [RFC7641], i.e. a GET request with an Observe option set to 0 641 (register). The request MUST NOT encode link-local addresses. If 642 the server is not configured to accept registrations on that target 643 resource with a group observation, this would still result in a 644 positive notification response to the client as described in 645 [RFC7641]. 647 3.2. Informative Response 649 Upon receiving the informative response defined in Section 2.2, the 650 client proceeds as follows. 652 1. The client configures an observation of the target resource. To 653 this end, it relies on a CoAP endpoint used for messages having: 655 * As source address and port number, the server address SRV_ADDR 656 and port number SRV_PORT intended for accessing the target 657 resource. These are specified as value of the 'srv_host' and 658 'srv_port' elements of 'srv_addr' under the 'tp_info' 659 parameter, in the informative response (see Section 2.2.1.1). 661 * As destination address and port number, the IP multicast 662 address GRP_ADDR and port number GRP_PORT. These are 663 specified as value of the 'cli_addr' and 'cli_port' elements 664 of 'req_info' under the 'tp_info' parameter, in the 665 informative response (see Section 2.2.1.1). If the 'cli_port' 666 element is omitted in 'req_info', the client MUST assume the 667 default port number 5683 as GRP_PORT. 669 2. The client rebuilds the phantom registration request, by using: 671 * The transport-independent information, specified in the 672 'ph_req' parameter of the informative response. 674 * The Token value T, specified in the 'token' element of 675 'req_info' under the 'tp_info' parameter of the informative 676 response. 678 3. The client stores the phantom registration request, as associated 679 to the observation of the target resource. In particular, the 680 client MUST use the Token value T of this phantom registration 681 request as its own local Token value associated to that group 682 observation, with respect to the server. The particular way to 683 achieve this is implementation specific. 685 4. If the informative response includes the parameter 'last_notif', 686 the client rebuilds the latest multicast notification, by using: 688 * The transport-independent information, specified in the 689 'last_notif' parameter of the informative response. 691 * The Token value T, specified in the 'token' element of 692 'req_info' under the 'tp_info' parameter of the informative 693 response. 695 5. If the informative response includes the parameter 'last_notif', 696 the client processes the multicast notification rebuilt in step 4 697 as defined in Section 3.2 of [RFC7641]. In particular, the value 698 of the Observe option is used as initial baseline for 699 notification reordering in this group observation. 701 6. If a traditional observation to the target resource is ongoing, 702 the client MAY silently cancel it without notifying the server. 704 If any of the expected fields in the informative response are not 705 present or malformed, the client MAY try sending a new registration 706 request to the server (see Section 3.1). Otherwise, the client 707 SHOULD explicitly withdraw from the group observation. 709 Appendix A describes possible alternative ways for clients to 710 retrieve the phantom registration request and other information 711 related to a group observation. 713 3.3. Notifications 715 After having successfully processed the informative response as 716 defined in Section 3.2, the client will receive, accept and process 717 multicast notifications about the state of the target resource from 718 the server, as responses to the phantom registration request and with 719 Token value T. 721 The client relies on the value of the Observe option for notification 722 reordering, as defined in Section 3.4 of [RFC7641]. 724 3.4. Cancellation 726 At a certain point in time, a client may become not interested in 727 receiving further multicast notifications about a target resource. 728 When this happens, the client can simply "forget" about being part of 729 the group observation for that target resource, as per Section 3.6 of 730 [RFC7641]. 732 When, later on, the server sends the next multicast notification, the 733 client will not recognize the Token value T in the message. Since 734 the multicast notification is Non-confirmable, it is OPTIONAL for the 735 client to reject the multicast notification with a Reset message, as 736 defined in Section 3.5 of [RFC7641]. 738 In case the server has canceled a group observation as defined in 739 Section 2.5, the client simply forgets about the group observation 740 and frees up the used Token value T for that endpoint, upon receiving 741 the multicast error response defined in Section 2.5. 743 4. Web Linking 745 The possible use of multicast notifications in a group observation 746 may be indicated by a target "grp_obs" attribute in a web link 747 [RFC8288] to a resource, e.g. using a link-format document [RFC6690] 748 if the resource is accessible over CoAP. 750 The "grp_obs" attribute is a hint, indicating that the server might 751 send multicast notifications for observations of the resource 752 targeted by the link. Note that this is simply a hint, i.e. it does 753 not include any information required to participate in a group 754 observation, and to receive and process multicast notifications. 756 A value MUST NOT be given for the "grp_obs" attribute; any present 757 value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT 758 appear more than once in a given link-value; occurrences after the 759 first MUST be ignored by parsers. 761 The example in Figure 4 shows a use of the "grp_obs" attribute: the 762 client does resource discovery on a server and gets back a list of 763 resources, one of which includes the "grp_obs" attribute indicating 764 that the server might send multicast notifications for observations 765 of that resource. The link-format notation (see Section 5 of 766 [RFC6690]) is used. 768 REQ: GET /.well-known/core 770 RES: 2.05 Content 771 ;grp_obs, 772 ;if="sensor" 774 Figure 4: The Web Link 776 5. Example 778 The following example refers to two clients C_1 and C_2 that register 779 to observe a resource /r at a Server S, which has address SRV_ADDR 780 and listens to the port number SRV_PORT. Before the following 781 exchanges occur, no clients are observing the resource /r , which has 782 value "1234". 784 The server S sends multicast notifications to the IP multicast 785 address GRP_ADDR and port number GRP_PORT, and starts the group 786 observation upon receiving a registration request from a first client 787 that wishes to start a traditional observation on the resource /r. 789 The following notation is used for the payload of the informative 790 responses: 792 o 'bstr(X)' denotes a CBOR byte string with value the byte 793 serialization of X, with '|' denoting byte concatenation. 795 o 'OPT' denotes a sequence of CoAP options. This refers to the 796 phantom registration request encoded by the 'ph_req' parameter, or 797 to the corresponding latest multicast notification encoded by the 798 'last_notif' parameter. 800 o 'PAYLOAD' denotes a CoAP payload. This refers to the latest 801 multicast notification encoded by the 'last_notif' parameter. 803 C_1 ----------------- [ Unicast ] ------------------------> S /r 804 | GET | 805 | Token: 0x4a | 806 | Observe: 0 (Register) | 807 | | 808 | | 809 | (S allocates the available Token value 0x7b .) | 810 | | 811 | | 812 | | 813 | (S sends to itself a phantom observation request PH_REQ | 814 | as coming from the IP multicast address GRP_ADDR .) | 815 | ------------------------------------------------ | 816 | / | 817 | \----------------------------------------------------> | /r 818 | GET | 819 | Token: 0x7b | 820 | Observe: 0 (Register) | 821 | | 822 | | 823 | (S creates a group observation of /r .) | 824 | | 825 | (S increments the observer counter | 826 | for the group observation of /r .) | 827 | | 828 C_1 <-------------------- [ Unicast ] --------------------- S 829 | 5.03 | 830 | Token: 0x4a | 831 | Content-Format: application/informative-response+cbor | 832 | | 833 | Payload: { | 834 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 835 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 836 | ph_req : bstr(0x01 | OPT), | 837 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 838 | } | 839 | | 840 C_2 ----------------- [ Unicast ] ------------------------> S /r 841 | GET | 842 | Token: 0x01 | 843 | Observe: 0 (Register) | 844 | | 845 | | 846 | (S increments the observer counter | 847 | for the group observation of /r .) | 848 | | 849 | | 850 C_2 <-------------------- [ Unicast ] --------------------- S 851 | 5.03 | 852 | Token: 0x01 | 853 | Content-Format: application/informative-response+cbor | 854 | | 855 | Payload: { | 856 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 857 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 858 | ph_req : bstr(0x01 | OPT), | 859 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | 860 | } | 861 | | 862 | (The value of the resource /r changes to "5678".) | 863 | | 864 C_1 | 865 + <------------------- [ Multicast ] -------------------- S 866 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 867 | 2.05 | 868 | Token: 0x7b | 869 | Observe: 11 | 870 | Content-Format: application/cbor | 871 | | 872 | Payload: : "5678" | 873 | | 875 Figure 5: Example of group observation 877 6. Rough Counting of Clients in the Group Observation 879 To allow the server to keep an estimate of interested clients without 880 creating undue traffic on the network, a new CoAP option is 881 introduced, which SHOULD be supported by clients that listen to 882 multicast responses. 884 The option is called Multicast-Response-Feedback-Divider. As 885 summarized in Figure 6, the option is not critical but proxy-unsafe, 886 and integer valued. 888 +-----+---+---+---+---+---------------------+--------+------+---------+ 889 | No. | C | U | N | R | Name | Format | Len. | Default | 890 +-----+---+---+---+---+---------------------+--------+------+---------+ 891 | TBD | | x | | | Multicast-Response- | uint | 0-1 | (none) | 892 | | | | | | Feedback-Divider | | | | 893 +-----+---+---+---+---+---------------------+--------+------+---------+ 895 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 897 Figure 6: Multicast-Response-Feedback-Divider 899 The Multicast-Response-Feedback-Divider option is of class E for 900 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 902 6.1. Processing on the Client Side 904 Upon receiving a response with a Multicast-Response-Feedback-Divider 905 option, a client SHOULD acknowledge its interest in continuing 906 receiving multicast notifications for the target resource, as 907 described below. 909 The client picks an integer random number I, from 0 inclusive to the 910 number Z = (2 ** Q) exclusive, where Q is the value specified in the 911 option and "**" is the exponentiation operator. If I is different 912 than 0, the client takes no further action. Otherwise, the client 913 should wait a random fraction of the Leisure time (see Section 8.2 of 914 [RFC7252]), and then registers a regular unicast observation on the 915 same target resource. 917 To this end, the client essentially follows the steps that got it 918 originally subscribed to group notifications for the target resource. 919 In particular, the client sends an observation request to the server, 920 i.e. a GET request with an Observe option set to 0 (register). The 921 request MUST be addressed to the same target resource, and MUST have 922 the same destination IP address and port number used for the original 923 registration request, regardless the source IP address and port 924 number of the received multicast notification. 926 Since the observation registration is only done for its side effect 927 of showing as an attempted observation at the server, the client MUST 928 send the unicast request in a non confirmable way, and with the 929 maximum No-Response setting [RFC7967]. In the request, the client 930 MUST include a Multicast-Response-Feedback-Divider option, whose 931 value MUST be empty (Option Length = 0). The client does not need to 932 wait for responses, and can keep processing further notifications on 933 the same token. 935 The client MUST ignore the Multicast-Response-Feedback-Divider 936 option, if the multicast notification is retrieved from the 937 'last_notif' parameter of an informative response (see Section 2.2). 938 A client includes the Multicast-Response-Feedback-Divider option only 939 in a re-registration request triggered by the server as described 940 above, and MUST NOT include it in any other request. 942 As the Multicast-Response-Feedback-Divider option is unsafe to 943 forward, a proxy needs to answer it on its own, and is later counted 944 as a single client. 946 Appendix B.1 provides a description in pseudo-code of the operations 947 above performed by the client. 949 6.2. Processing on the Server Side 951 In order to avoid needless use of network resources, a server SHOULD 952 keep a rough, updated count of the number of clients taking part in 953 the group observation of a target resource. To this end, the server 954 updates the value COUNT of the associated observer counter (see 955 Section 2), for instance by using the method described below. 957 6.2.1. Request for Feedback 959 When it wants to obtain a new estimated count, the server considers a 960 number M of confirmations it would like to receive from the clients. 961 It is up to applications to define policies about how the server 962 determines and possibly adjusts the value of M. 964 Then, the server computes the value Q = max(L, 0), where: 966 o L is computed as L = ceil(log2(N / M)). 968 o N is the current value of the observer counter, possibly rounded 969 up to 1, i.e. N = max(COUNT, 1). 971 Finally, the server sets Q as the value of the Multicast-Response- 972 Feedback-Divider option, which is sent within a successful multicast 973 notification. 975 If several multicast notifications are sent in a burst fashion, it is 976 RECOMMENDED for the server to include the Multicast-Response- 977 Feedback-Divider option only in the first one of those notifications. 979 6.2.2. Collection of Feedback 981 The server collects unicast observation requests from the clients, 982 for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this 983 time, the server regularly increments the observer counter when 984 adding a new client to the group observation (see Section 2.2). 986 It is up to applications to define the value of 987 MAX_CONFIRMATION_WAIT, which has to take into account the 988 transmission time of the multicast notification and of unicast 989 observation requests, as well as the leisure time of the clients, 990 which may be hard to know or estimate for the server. 992 If this information is not known to the server, it is recommended to 993 define MAX_CONFIRMATION_WAIT as follows. 995 MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY 997 where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has 998 default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is 999 equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 2.3.1 of 1000 [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In 1001 the absence of more specific information, the server can thus 1002 consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. 1004 If more information is available in deployments, a much shorter 1005 MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic 1006 round trip time (replacing MAX_RTT) and on the largest leisure time 1007 configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g. 1008 DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to 1009 a few seconds. 1011 6.2.3. Processing of Feedback 1013 Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the 1014 R confirmations arrived as unicast observation requests to the target 1015 resource, since the multicast notification with the Multicast- 1016 Response-Feedback-Divider option has been sent. In particular, the 1017 server considers a unicast observation request as a confirmation from 1018 a client only if it includes a Multicast-Response-Feedback-Divider 1019 option with an empty value (Option Length = 0). 1021 Then, the server computes a feedback indicator as E = R * (2 ** Q), 1022 where "**" is the exponentiation operator. According to what defined 1023 by application policies, the server determines the next time when to 1024 ask clients for their confirmation, e.g. after a certain number of 1025 multicast notifications has been sent. For example, the decision can 1026 be influenced by the reception of no confirmations from the clients, 1027 i.e. R = 0, or by the value of the ratios (E/N) and (N/E). 1029 Finally, the server computes a new estimated count of the observers. 1030 To this end the server first consider COUNT' as the current value of 1031 the observer counter at this point in time. Note that COUNT' may be 1032 greater than the value COUNT used at the beginning of this process, 1033 if the server has incremented the observer counter upon adding new 1034 clients to the group observation (see Section 2.2). 1036 In particular, the server computes the new estimated count value as 1037 COUNT' + ((E - N) / D), where D > 0 is an integer value used as 1038 dampener. This step has to be performed atomically. That is, until 1039 this step is completed, the server MUST hold the processing of an 1040 observation request for the same target resource from a new client. 1041 Finally, the server considers the result as the current observer 1042 counter, and assesses it for possibly canceling the group observation 1043 (see Section 2.5). 1045 This estimate is skewed by packet loss, but it gives the server a 1046 sufficiently good estimation for further counts and for deciding when 1047 to cancel the group observation. It is up to applications to define 1048 policies about how the server takes the newly updated estimate into 1049 account and determines whether to cancel the group observation. 1051 As an example, if the server currently estimates that N = COUNT = 32 1052 observers are active and considers a constant M = 8, it sends out a 1053 notification with Multicast-Response-Feedback-Divider: 2. Then, out 1054 of 18 actually active clients, 5 send a re-registration request based 1055 on their random draw, of which one request gets lost, thus leaving 4 1056 re-registration requests received by the server. Also, no new 1057 clients have been added to the group observation during this time, 1058 i.e. COUNT' is equal to COUNT. As a consequence, assuming that a 1059 dampener value D = 1 is used, the server computes the new estimated 1060 count value as 32 + (16 - 32) = 16, and keeps the group observation 1061 active. 1063 To produce a most accurate updated counter, a server can include a 1064 Multicast-Response-Feedback-Divider option with value Q = 0 in its 1065 multicast notifications, as if M is equal to N. This will trigger 1066 all the active clients to state their interest in continuing 1067 receiving notifications for the target resource. Thus, the amount R 1068 of arrived confirmations is affected only by possible packet loss. 1070 Appendix B.3 provides a description in pseudo-code of the operations 1071 above performed by the server, including example behaviors for 1072 scheduling the next count update and deciding whether to cancel the 1073 group observation. 1075 7. Protection of Multicast Notifications with Group OSCORE 1077 A server can protect multicast notifications by using Group OSCORE 1078 [I-D.ietf-core-oscore-groupcomm], thus ensuring they are protected 1079 end-to-end with the observer clients. This requires that both the 1080 server and the clients interested in receiving multicast 1081 notifications from that server are members of the same OSCORE group. 1083 In some settings, the OSCORE group to refer to can be pre-configured 1084 on the clients and the server. In such a case, a server which is 1085 aware of such pre-configuration can simply assume a client to be 1086 already member of the correct OSCORE group. 1088 In any other case, the server MAY communicate to clients what OSCORE 1089 group they are required to join, by providing additional guidance in 1090 the informative response as described in Section 7.1. Note that 1091 clients can already be members of the right OSCORE group, in case 1092 they have previously joined it to securely communicate with the same 1093 and/or other servers to access their resources. 1095 Both the clients and the server MAY join the OSCORE group by using 1096 the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and 1097 based on the ACE framework for Authentication and Authorization in 1098 constrained environments [I-D.ietf-ace-oauth-authz]. Further details 1099 on how to discover the OSCORE group and join it are out of the scope 1100 of this specification. 1102 If multicast notifications are protected using Group OSCORE, the 1103 original registration requests and related unicast (notification) 1104 responses MUST also be secured, including and especially the 1105 informative responses from the server. 1107 To this end, alternative security protocols than Group OSCORE, such 1108 as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can 1109 be used to protect other exchanges via unicast between the server and 1110 each client, including the original client registration (see 1111 Section 3). 1113 7.1. Signaling the OSCORE Group in the Informative Response 1115 This section describes a mechanism for the server to communicate to 1116 the client what OSCORE group to join in order to decrypt and verify 1117 the multicast notifications protected with group OSCORE. The client 1118 MAY use the information provided by the server to start the ACE 1119 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 1120 This mechanism is OPTIONAL to support for the client and server. 1122 Additionally to what defined in Section 2, the CBOR map in the 1123 informative response payload contains the following fields, whose 1124 CBOR labels are defined in Section 11. 1126 o 'join_uri', with value the URI for joining the OSCORE group at the 1127 respective Group Manager, encoded as a CBOR text string. If the 1128 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 1129 for joining, this field specifically indicates the URI of the 1130 group-membership resource at the Group Manager. 1132 o 'sec_gp', with value the name of the OSCORE group, encoded as a 1133 CBOR text string. 1135 o Optionally, 'as_uri', with value the URI of the Authorization 1136 Server associated to the Group Manager for the OSCORE group, 1137 encoded as a CBOR text string. 1139 o Optionally, 'cs_alg', with value the COSE algorithm 1140 [I-D.ietf-cose-rfc8152bis-algs] used to countersign messages in 1141 the OSCORE group, encoded as a CBOR text string or integer. The 1142 value is taken from the 'Value' column of the "COSE Algorithms" 1143 registry [COSE.Algorithms]. 1145 o Optionally, 'cs_alg_crv', with value the elliptic curve (if 1146 applicable) for the COSE algorithm [I-D.ietf-cose-rfc8152bis-algs] 1147 used to countersign messages in the OSCORE group, encoded as a 1148 CBOR text string or integer. The value is taken from the 'Value' 1149 column of the "COSE Elliptic Curve" registry 1150 [COSE.Elliptic.Curves]. 1152 o Optionally, 'cs_key_kty', with value the COSE key type 1153 [I-D.ietf-cose-rfc8152bis-struct] of countersignature keys used to 1154 countersign messages in the OSCORE group, encoded as a CBOR text 1155 string or an integer. The value is taken from the 'Value' column 1156 of the "COSE Key Types" registry [COSE.Key.Types]. 1158 o Optionally, 'cs_key_crv', with value the elliptic curve (if 1159 applicable) of countersignature keys used to countersign messages 1160 in the OSCORE group, encoded as a CBOR text string or integer. 1161 The value is taken from the 'Value' column of the "COSE Elliptic 1162 Curve" registry [COSE.Elliptic.Curves]. 1164 o Optionally, 'cs_kenc', with value the encoding of the public keys 1165 used in the OSCORE group, encoded as a CBOR integer. The value is 1166 taken from the 'Confirmation Key' column of the "CWT Confirmation 1167 Method" registry defined in [RFC8747]. Future specifications may 1168 define additional values for this parameter. 1170 o Optionally, 'alg', with value the COSE AEAD algorithm 1171 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 1172 integer. The value is taken from the 'Value' column of the "COSE 1173 Algorithms" registry [COSE.Algorithms]. 1175 o Optionally, 'hkdf', with value the COSE HKDF algorithm 1176 [I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or 1177 integer. The value is taken from the 'Value' column of the "COSE 1178 Algorithms" registry [COSE.Algorithms]. 1180 The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' and 1181 'cs_key_kenc' provide an early knowledge of the format and encoding 1182 of public keys used in the OSCORE group. Thus, the client does not 1183 need to ask the Group Manager for this information as a preliminary 1184 step before the (ACE) join process, or to perform a trial-and-error 1185 exchange with the Group Manager upon joining the group. Hence, the 1186 client is able to provide the Group Manager with its own public key 1187 in the correct expected format and encoding, at the very first step 1188 of the (ACE) join process. 1190 The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge 1191 of the algorithms used in the OSCORE group. Thus, the client is able 1192 to decide whether to actually proceed with the (ACE) join process, 1193 depending on its support for the indicated algorithms. 1195 As mentioned above, since this mechanism is OPTIONAL, all the fields 1196 are OPTIONAL in the informative response. However, the 'join_uri' 1197 and 'sec_gp' fields MUST be present if the mechanism is implemented 1198 and used. If any of the fields are present without the 'join_uri' 1199 and 'sec_gp' fields present, the client MUST ignore these fields, 1200 since they would not be sufficient to start the (ACE) join procedure. 1201 When this happens, the client MAY try sending a new registration 1202 request to the server (see Section 3.1). Otherwise, the client 1203 SHOULD explicitly withdraw from the group observation. 1205 Appendix C describes a possible alternative approach, where the 1206 server self-manages the OSCORE group, and provides the observer 1207 clients with the necessary keying material in the informative 1208 response. The approach in Appendix C MUST NOT be used together with 1209 the mechanism defined in this section for indicating what OSCORE 1210 group to join. 1212 7.2. Server-Side Requirements 1214 When using Group OSCORE to protect multicast notifications, the 1215 server performs the operations described in Section 2, with the 1216 following differences. 1218 7.2.1. Registration 1220 The phantom registration request MUST be secured, by using Group 1221 OSCORE. In particular, the group mode of Group OSCORE defined in 1222 Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. 1224 The server protects the phantom registration request as defined in 1225 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the 1226 actual sender, i.e. by using its Sender Context. As a consequence, 1227 the server consumes the current value of its Sender Sequence Number 1228 SN in the OSCORE group, and hence updates it to SN* = (SN + 1). 1229 Consistently, the OSCORE option in the phantom registration request 1230 includes: 1232 o As 'kid', the Sender ID of the server in the OSCORE group. 1234 o As 'piv', the previously consumed Sender Sequence Number value SN 1235 of the server in the OSCORE group, i.e. (SN* - 1). 1237 7.2.2. Informative Response 1239 The value of the CBOR byte string in the 'ph_req' parameter encodes 1240 the phantom observation request as a message protected with Group 1241 OSCORE (see Section 7.2.1). As a consequence: the specified Code is 1242 always 0.05 (FETCH); the sequence of CoAP options will be limited to 1243 the outer, non encrypted options; a payload is always present, as the 1244 authenticated ciphertext followed by the counter signature. 1246 Similarly, the value of the CBOR byte string in the 'last_notif' 1247 parameter encodes the latest multicast notification as a message 1248 protected with Group OSCORE (see Section 7.2.3). This applies also 1249 to the initial multicast notification INIT_NOTIF built in step 6 of 1250 Section 2.1. 1252 Optionally, the informative response includes information on the 1253 OSCORE group to join, as additional parameters (see Section 7.1). 1255 7.2.3. Notifications 1257 The server MUST protect every multicast notification for the target 1258 resource with Group OSCORE. In particular, the group mode of Group 1259 OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST 1260 be used. 1262 The process described in Section 8.3 of 1263 [I-D.ietf-core-oscore-groupcomm] applies, with the following 1264 additions when building the two OSCORE 'external_aad' to encrypt and 1265 countersign the multicast notification (see Sections 4.3.1 and 4.3.2 1266 of [I-D.ietf-core-oscore-groupcomm]). 1268 o The 'request_kid' is the 'kid' value in the OSCORE option of the 1269 phantom registration request, i.e. the Sender ID of the server. 1271 o The 'request_piv' is the 'piv' value in the OSCORE option of the 1272 phantom registration request, i.e. the consumed Sender Sequence 1273 Number SN of the server. 1275 o The 'request_kid_context' is the 'kid context' value in the OSCORE 1276 option of the phantom registration request, i.e. the Group 1277 Identifier value (Gid) of the OSCORE group used as ID Context. 1279 Note that these same values are used to protect each and every 1280 multicast notification sent for the target resource under this group 1281 observation. 1283 7.2.4. Cancellation 1285 When canceling a group observation (see Section 2.5), the phantom 1286 cancellation request MUST be secured, by using Group OSCORE. In 1287 particular, the group mode of Group OSCORE defined in Section 8 of 1288 [I-D.ietf-core-oscore-groupcomm] MUST be used. 1290 Like defined in Section 7.2.1 for the phantom registration request, 1291 the server protects the phantom cancellation request as per 1292 Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender 1293 Context and consuming its current Sender Sequence number in the 1294 OSCORE group, from its Sender Context. The following, corresponding 1295 multicast error response defined in Section 2.5 is also protected 1296 with Group OSCORE, as per Section 8.3 of 1297 [I-D.ietf-core-oscore-groupcomm]. 1299 Note that, differently from the multicast notifications, this 1300 multicast error response will be the only one securely paired with 1301 the phantom cancellation request. 1303 7.3. Client-Side Requirements 1305 When using Group OSCORE to protect multicast notifications, the 1306 client performs as described in Section 3, with the following 1307 differences. 1309 7.3.1. Informative Response 1311 Upon receiving the informative response from the server, the client 1312 performs as described in Section 3.2, with the following additions. 1314 Once completed step 2, the client decrypts and verifies the rebuilt 1315 phantom registration request as defined in Section 8.2 of 1316 [I-D.ietf-core-oscore-groupcomm], with the following differences. 1318 o The client MUST NOT perform any replay check. That is, the client 1319 skips step 3 in Section 8.2 of [RFC8613]. 1321 o If decryption and verification of the phantom registration request 1322 succeed: 1324 * The client MUST NOT update the Replay Window in the Recipient 1325 Context associated to the server. That is, the client skips 1326 the second bullet of step 6 in Section 8.2 of [RFC8613]. 1328 * The client MUST NOT take any further process as normally 1329 expected according to [RFC7252]. That is, the client skips 1330 step 8 in Section 8.2 of [RFC8613]. In particular, the client 1331 MUST NOT deliver the phantom registration request to the 1332 application, and MUST NOT take any action in the Token space of 1333 its unicast endpoint, where the informative response has been 1334 received. 1336 * The client stores the values of the 'kid', 'piv' and 'kid 1337 context' fields from the OSCORE option of the phantom 1338 registration request. 1340 o If decryption and verification of the phantom registration request 1341 fail, the client MAY try sending a new registration request to the 1342 server (see Section 3.1). Otherwise, the client SHOULD explicitly 1343 withdraw from the group observation. 1345 o If the informative response includes the parameter 'last_notif', 1346 the client also decrypts and verifies the latest multicast 1347 notification rebuilt in step 4, just like it would for the 1348 multicast notifications transmitted as CoAP messages on the wire 1349 (see Section 7.3.2). The client proceeds with step 5 if 1350 decryption and verification of the latest multicast notification 1351 succeed, or to step 6 otherwise. 1353 7.3.2. Notifications 1355 After having successfully processed the informative response as 1356 defined in Section 7.3.1, the client will decrypt and verify every 1357 multicast notification for the target resource as defined in 1358 Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following 1359 difference. 1361 The client MUST set the two 'external_aad' defined in Sections 4.3.1 1362 and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The 1363 particular way to achieve this is implementation specific. 1365 o 'request_kid' takes the value of the 'kid' field from the OSCORE 1366 option of the phantom registration request (see Section 7.3.1). 1368 o 'request_piv' takes the value of the 'piv' field from the OSCORE 1369 option of the phantom registration request (see Section 7.3.1). 1371 o 'request_kid_context' takes the value of the 'kid context' field 1372 from the OSCORE option of the phantom registration request (see 1373 Section 7.3.1). 1375 Note that these same values are used to decrypt and verify each and 1376 every multicast notification received for the target resource. 1378 The replay protection and checking of multicast notifications is 1379 performed as specified in Section 4.1.3.5.2 of [RFC8613]. 1381 8. Example with Group OSCORE 1383 The following example refers to two clients C_1 and C_2 that register 1384 to observe a resource /r at a Server S, which has address SRV_ADDR 1385 and listens to the port number SRV_PORT. Before the following 1386 exchanges occur, no clients are observing the resource /r , which has 1387 value "1234". 1389 The server S sends multicast notifications to the IP multicast 1390 address GRP_ADDR and port number GRP_PORT, and starts the group 1391 observation upon receiving a registration request from a first client 1392 that wishes to start a traditional observation on the resource /r. 1394 Pairwise communication over unicast is protected with OSCORE, while S 1395 protects multicast notifications with Group OSCORE. Specifically: 1397 o C_1 and S have a pairwise OSCORE Security Context. In particular, 1398 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sender Sequence 1399 Number. Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as 1400 Sender Sequence Number. 1402 o C_2 and S have a pairwise OSCORE Security Context. In particular, 1403 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sender Sequence 1404 Number. Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as 1405 Sender Sequence Number. 1407 o S is a member of the OSCORE group with name "myGroup", and 'kid 1408 context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' 1409 = 5 as Sender ID, and SN_5 = 501 as Sender Sequence Number. 1411 The following notation is used for the payload of the informative 1412 responses: 1414 o 'bstr(X)' denotes a CBOR byte string with value the byte 1415 serialization of X, with '|' denoting byte concatenation. 1417 o 'OPT' denotes a sequence of CoAP options. This refers to the 1418 phantom registration request encoded by the 'ph_req' parameter, or 1419 to the corresponding latest multicast notification encoded by the 1420 'last_notif' parameter. 1422 o 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the 1423 phantom registration request encoded by the 'ph_req' parameter, or 1424 to the corresponding latest multicast notification encoded by the 1425 'last_notif' parameter. 1427 o 'SIGN' denotes the counter signature appended to an encrypted CoAP 1428 payload. This refers to the phantom registration request encoded 1429 by the 'ph_req' parameter, or to the corresponding latest 1430 multicast notification encoded by the 'last_notif' parameter. 1432 C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1433 | 0.05 (FETCH) | 1434 | Token: 0x4a | 1435 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 1436 | | 1437 | 0xff | 1438 | Encrypted_payload { | 1439 | 0x01 (GET), | 1440 | Observe: 0 (Register), | 1441 | | 1442 | } | 1443 | | 1444 | (S allocates the available Token value 0x7b .) | 1445 | | 1446 | | 1447 | (S sends to itself a phantom observation request PH_REQ | 1448 | as coming from the IP multicast address GRP_ADDR .) | 1449 | ------------------------------------------------------ | 1450 | / | 1451 | \-------------------------------------------------------> | /r 1452 | 0.05 (FETCH) | 1453 | Token: 0x7b | 1454 | OSCORE: {kid: 5 ; piv: 501 ; | 1455 | kid context: 57ab2e; ...} | 1456 | | 1457 | 0xff | 1458 | Encrypted_payload { | 1459 | 0x01 (GET), | 1460 | Observe: 0 (Register), | 1461 | | 1462 | } | 1463 | | 1464 | | 1465 | | 1466 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 1467 | | 1468 | (S creates a group observation of /r .) | 1469 | | 1470 | (S increments the observer counter | 1471 | for the group observation of /r .) | 1472 | | 1473 | | 1474 C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1475 | 2.05 (Content) | 1476 | Token: 0x4a | 1477 | OSCORE: {piv: 301; ...} | 1478 | | 1479 | 0xff | 1480 | Encrypted_payload { | 1481 | 5.03 (Service Unavailable), | 1482 | Content-Format: application/informative-response+cbor, | 1483 | , | 1484 | 0xff, | 1485 | CBOR_payload { | 1486 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1487 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1488 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1489 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1490 | join_uri : "coap://myGM/ace-group/myGroup", | 1491 | sec_gp : "myGroup" | 1492 | } | 1493 | } | 1494 | | 1495 | | 1496 C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r 1497 | 0.05 (FETCH) | 1498 | Token: 0x01 | 1499 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 1500 | | 1501 | 0xff | 1502 | Encrypted_payload { | 1503 | 0x01 (GET), | 1504 | Observe: 0 (Register), | 1505 | | 1506 | } | 1507 | | 1508 | (S increments the observer counter | 1509 | for the group observation of /r .) | 1510 | | 1511 C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S 1512 | 2.05 (Content) | 1513 | Token: 0x01 | 1514 | OSCORE: {piv: 401; ...} | 1515 | | 1516 | 0xff, | 1517 | Encrypted_payload { | 1518 | 5.03 (Service Unavailable), | 1519 | Content-Format: application/informative-response+cbor, | 1520 | , | 1521 | 0xff, | 1522 | CBOR_payload { | 1523 | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | 1524 | 0x7b, bstr(GRP_ADDR), GRP_PORT], | 1525 | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | 1526 | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | 1527 | join_uri : "coap://myGM/ace-group/myGroup", | 1528 | sec_gp : "myGroup" | 1529 | } | 1530 | } | 1531 | | 1532 | | 1533 | (The value of the resource /r changes to "5678".) | 1534 | | 1535 C_1 | 1536 + <----------- [ Multicast w/ Group OSCORE ] ------------ S 1537 C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | 1538 | 2.05 (Content) | 1539 | Token: 0x7b | 1540 | OSCORE: {kid: 5; piv: 502 ; | 1541 | kid context: 57ab2e; ...} | 1542 | | 1543 | 0xff | 1544 | Encrypted_payload { | 1545 | 2.05 (Content), | 1546 | Observe: 11, | 1547 | Content-Format: application/cbor, | 1548 | , | 1549 | 0xff, | 1550 | CBOR_Payload : "5678" | 1551 | } | 1552 | | 1553 | | 1555 Figure 7: Example of group observation with Group OSCORE 1557 The two external_aad used to encrypt and countersign the multicast 1558 notification above have 'request_kid' = 5, 'request_piv' = 501 and 1559 'request_kid_context' = 0x57ab2e. These values are specified in the 1560 'kid', 'piv' and 'kid context' field of the OSCORE option of the 1561 phantom observation request, which is encoded in the 'ph_req' 1562 parameter of the unicast informative response to the two clients. 1563 Thus, the two clients can build the two same external_aad for 1564 decrypting and verifying this multicast notification and the 1565 following ones. 1567 9. Intermediaries 1569 This section specifies how the approach presented in Section 2 and 1570 Section 3 works when a proxy is used between the clients and the 1571 server. In addition to what specified in Section 5.7 of [RFC7252] 1572 and Section 5 of [RFC7641], the following applies. 1574 A client sends its original observation request to the proxy. If the 1575 proxy is not already registered at the server for that target 1576 resource, the proxy forwards the observation request to the server, 1577 hence registering itself as an observer. If the server has an 1578 ongoing group observation for the target resource or decides to start 1579 one, the server considers the proxy as taking part in the group 1580 observation, and replies to the proxy with an informative response. 1582 Upon receiving an informative response, the proxy performs as 1583 specified for the client in Section 3, with the peculiarity that 1584 "consuming" the last notification (if present) means populating its 1585 cache. 1587 In particular, by using the information retrieved from the 1588 informative response, the proxy configures an observation of the 1589 target resource at the origin server, acting as a client directly 1590 taking part in the group observation. 1592 As a consequence, the proxy will listen to the IP multicast address 1593 and port number indicated by the server in the informative response, 1594 as 'cli_addr' and 'cli_port' element of 'req_info' under the 1595 'tp_info' parameter, respectively (see Section 2.2.1.1). 1596 Furthermore, multicast notifications will match the phantom request 1597 stored at the proxy, based on the Token value specified in the 1598 'token' element of 'req_info' under the 'tp_info' parameter in the 1599 informative response. 1601 Then, the proxy performs the following actions. 1603 o If the 'last_notif' field is not present, the proxy responds to 1604 the client with an Empty Acknowledgement (if indicated by the 1605 message type, and if it has not already done so). 1607 o If the 'last_notif' field is present, the proxy rebuilds the 1608 latest multicast notification, as defined in Section 3. Then, the 1609 proxy responds to the client, by forwarding back the latest 1610 multicast notification. 1612 When responding to an observation request from a client, the proxy 1613 also adds that client (and its Token) to the list of its registered 1614 observers for the target resource, next to the older observations. 1616 Upon receiving a multicast notification from the server, the proxy 1617 forwards it back separately to each observer client over unicast. 1618 Note that the notification forwarded back to a certain client has the 1619 same Token value of the original observation request sent by that 1620 client to the proxy. 1622 Note that the proxy configures the observation of the target resource 1623 at the server only once, when receiving the informative response 1624 associated to a (newly started) group observation for that target 1625 resource. 1627 After that, when receiving an observation request from a following 1628 new client to be added to the same group observation, the proxy does 1629 not take any further action with the server. Instead, the proxy 1630 responds to the client either with the latest multicast notification 1631 if available from its cache, or with an Empty Acknowledgement 1632 otherwise, as defined above. 1634 An example is provided in Appendix E. 1636 In the general case with a chain of two or more proxies, every proxy 1637 in the chain takes the role of client with the (next hop towards the) 1638 origin server. Note that the proxy adjacent to the origin server is 1639 the only one in the chain that receives informative responses and 1640 listens to an IP multicast address to receive notifications for the 1641 group observation. Furthermore, every proxy in the chain takes the 1642 role of server with the (previous hop towards the) origin client. 1644 10. Intermediaries Together with End-to-End Security 1646 As defined in Section 7, Group OSCORE can be used to protect 1647 multicast notifications end-to-end between the origin server and the 1648 clients. In such a case, additional actions are required when also 1649 the informative responses from the origin server are protected 1650 specifically end-to-end, by using OSCORE or Group OSCORE. 1652 In fact, the proxy adjacent to the origin server is not able to 1653 access the encrypted payload of such informative responses. Hence, 1654 the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters 1655 necessary to correctly receive multicast notifications and forward 1656 them back to the clients. 1658 Then, differently from what defined in Section 9, each proxy 1659 receiving an informative response simply forwards it back to the 1660 client that has sent the corresponding observation request. Note 1661 that the proxy does not even realize the message to be an actual 1662 informative response, since the outer Code field is set to 2.05 1663 (Content). 1665 Upon receiving the informative response, the client does not 1666 configure an observation of the target resource. Instead, the client 1667 performs a new observe registration request, by transmitting the re- 1668 built phantom request as intended to reach the proxy adjacent to the 1669 origin server. In particular, the client includes the new Listen-To- 1670 Multicast-Responses CoAP option defined in Section 10.1, to provide 1671 that proxy with the transport-specific information required for 1672 receiving multicast notifications for the group observation. 1674 Details on the additional message exchange and processing are defined 1675 in Section 10.2. 1677 10.1. The Listen-To-Multicast-Responses Option 1679 To allow the proxy to listen to the multicast notifications sent by 1680 the server, a new CoAP option is introduced. This option MUST be 1681 supported by clients interested to take part in group observations 1682 through intermediaries, and by proxies that collect multicast 1683 notifications and forward them back to the observer clients. 1685 The option is called Listen-To-Multicast-Responses and is intended 1686 only for requests. As summarized in Figure 8, the option is critical 1687 and proxy-unsafe. 1689 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1690 | No. | C | U | N | R | Name | Format | Len. | Default | 1691 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1692 | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) | 1693 | | | | | | Multicast- | | | | 1694 | | | | | | Responses | | | | 1695 +-----+---+---+---+---+-------------------+--------+--------+---------+ 1697 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 1698 (*) See below. 1700 Figure 8: Listen-To-Multicast-Responses 1702 The Listen-To-Multicast-Responses option includes the serialization 1703 of a CBOR array. This specifies transport-specific message 1704 information required for listening to the multicast notifications of 1705 a group observation, and intended to the proxy adjacent to the origin 1706 server sending those notifications. In particular, the serialized 1707 CBOR array has the same format specified in Section 2.2.1 for the 1708 'tp_info' parameter of the informative response (see Section 2.2). 1710 The Listen-To-Multicast-Responses option is of class U for OSCORE 1711 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1713 10.2. Message Processing 1715 Compared to Section 9, the following additions apply when informative 1716 responses are protected end-to-end between the origin server and the 1717 clients. 1719 After the origin server sends an informative response, each proxy 1720 simply forwards it back to the (previous hop towards the) origin 1721 client that has sent the observation request. 1723 Once received the informative response, the origin client proceeds in 1724 a different way than in Section 7.3.1: 1726 o The client performs all the additional decryption and verification 1727 steps of Section 7.3.1 on the phantom request specified in the 1728 'ph_req' parameter and on the last notification specified in the 1729 'last_notif' parameter (if present). 1731 o The client builds a ticket request (see Appendix B of 1732 [I-D.amsuess-core-cachable-oscore]), as intended to reach the 1733 proxy adjacent to the origin server. The ticket request is 1734 formatted as follows. 1736 * The Token is chosen as the client sees fit. In fact, there is 1737 no reason for this Token to be the same as the phantom 1738 request's. 1740 * The Code field, the outer CoAP options and the encrypted 1741 payload (containing inner options, AEAD tag etc.) are the same 1742 of the phantom request used for the group observation. That 1743 is, they are as specified in the 'ph_req' parameter of the 1744 received informative response. 1746 * An outer Observe option is included and set to 0 (Register). 1747 This will usually be set in the phantom request already. 1749 * The outer options Proxy-Scheme, Uri-Host and Uri-Port are 1750 included, and set to the same values they had in the original 1751 registration request sent by the client. 1753 * The new option Listen-To-Multicast-Responses is included as an 1754 outer option. The value is set to the serialization of the 1755 CBOR array specified by the 'tp_info' parameter of the 1756 informative response. 1758 Note that, except for transport-specific information such as 1759 the Token and Message ID values, every different client 1760 participating to the same group observation (hence rebuilding 1761 the same phantom request) will build the same ticket request. 1763 Note also that, identically to the phantom request, the ticket 1764 request is still protected with Group OSCORE, i.e. it has the 1765 same OSCORE option, encrypted payload and counter signature. 1767 Then, the client sends the ticket request to the next hop towards the 1768 origin server. Every proxy in the chain forwards the ticket request 1769 to the next hop towards the origin server, until the last proxy in 1770 the chain is reached. This last proxy, adjacent to the origin 1771 server, proceeds as follows. 1773 o The proxy MUST NOT further forward the ticket request to the 1774 origin server. 1776 o The proxy removes the Proxy-Scheme, Uri-Host and Uri-Port options 1777 from the ticket request. 1779 o The proxy removes the Listen-To-Multicast-Responses option from 1780 the ticket request, and extracts the conveyed transport-specific 1781 information. 1783 o The proxy rebuilds the phantom request associated to the group 1784 observation, by using the ticket request as directly providing the 1785 required transport-independent information. This includes the 1786 outer Code field, the outer CoAP options and the encrypted payload 1787 concatenated with the counter signature. 1789 o The proxy configures an observation of the target resource at the 1790 origin server, acting as a client directly taking part in the 1791 group observation. To this end, the proxy uses the rebuilt 1792 phantom request and the transport-specific information retrieved 1793 from the Listen-To-Multicast-Responses Option. The particular way 1794 to achieve this is implementation specific. 1796 After that, the proxy will listen to the IP multicast address and 1797 port number indicated in the Listen-To-Multicast-Responses option, as 1798 'cli_addr' and 'cli_port' element of the serialized CBOR array, 1799 respectively. Furthermore, multicast notifications will match the 1800 phantom request stored at the proxy, based on the Token value 1801 specified in the 'token' element of the serialized CBOR array in the 1802 Listen-To-Multicast-Responses option. 1804 An example is provided in Appendix F. 1806 11. Informative Response Parameters 1808 This specification defines a number of fields used in the informative 1809 response message defined in Section 2.2. 1811 The table below summarizes them and specifies the CBOR key to use 1812 instead of the full descriptive name. Note that the media type 1813 application/informative-response+cbor MUST be used when these fields 1814 are transported. 1816 +----------------+----------+-------------------+-------------+ 1817 | Name | CBOR Key | CBOR Type | Reference | 1818 +----------------+----------+-------------------+-------------+ 1819 | tp_info | 1 | array | Section 2.2 | 1820 | | | | | 1821 | ph_req | 2 | byte string | Section 2.2 | 1822 | | | | | 1823 | last_notif | 3 | byte string | Section 2.2 | 1824 | | | | | 1825 | join_uri | 4 | text string | Section 7.1 | 1826 | | | | | 1827 | sec_gp | 5 | text string | Section 7.1 | 1828 | | | | | 1829 | as_uri | 6 | text string | Section 7.1 | 1830 | | | | | 1831 | cs_alg | 7 | int / text string | Section 7.1 | 1832 | | | | | 1833 | cs_crv | 8 | int / text string | Section 7.1 | 1834 | | | | | 1835 | cs_kty | 9 | int / text string | Section 7.1 | 1836 | | | | | 1837 | cs_kenc | 10 | int | Section 7.1 | 1838 | | | | | 1839 | alg | 11 | int / text string | Section 7.1 | 1840 | | | | | 1841 | hkdf | 12 | int / text string | Section 7.1 | 1842 | | | | | 1843 | gp_material | 13 | map | Appendix C | 1844 | | | | | 1845 | srv_pub_key | 14 | byte string | Appendix C | 1846 | | | | | 1847 | srv_identifier | 15 | byte string | Appendix C | 1848 | | | | | 1849 | exp | 16 | uint | Appendix C | 1850 +----------------+----------+-------------------+-------------+ 1852 Figure 9: CBOR abbreviations for informative response parameters 1854 12. Transport Protocol Information 1856 This specification defines some values of transport protocol 1857 identifiers to use within the 'tp_info' parameter of the informative 1858 response message defined in Section 2.2 of this specification. 1860 According to the encoding specified in Section 2.2.1, these values 1861 are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' 1862 parameter. 1864 The table below summarizes them, specifies the integer value to use 1865 instead of the full descriptive name, and provides the corresponding 1866 full set of information elements to include in the 'tp_info' 1867 parameter. 1869 +-----------+-------------+-------+----------+-----------+-----------+ 1870 | Transport | Description | Value | Srv Addr | Req Info | Reference | 1871 | Protocol | | | | | | 1872 +-----------+-------------+-------+----------+-----------+-----------+ 1873 | Reserved | This value | 0 | | | [This | 1874 | | is reserved | | | | document] | 1875 | | | | | | | 1876 | UDP | UDP is used | 1 | tp_id | token | [This | 1877 | | as per | | srv_host | cli_host | document] | 1878 | | RFC7252 | | srv_port | ?cli_port | | 1879 +-----------+-------------+-------+----------+-----------+-----------+ 1881 Figure 10: Transport protocol information 1883 13. Security Considerations 1885 The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor 1886 e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for 1887 this document. 1889 If multicast notifications are protected using Group OSCORE, the 1890 original registration requests and related unicast (notification) 1891 responses MUST also be secured, including and especially the 1892 informative responses from the server. This prevents on-path active 1893 adversaries from altering the conveyed IP multicast address and 1894 serialized phantom registration request. Thus, it ensures secure 1895 binding between every multicast notification for a same observed 1896 resource and the phantom registration request that started the group 1897 observation of that resource. 1899 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 1900 so ensuring that the secure binding above is enforced end-to-end 1901 between the server and each observing client. 1903 13.1. Listen-To-Multicast-Responses Option 1905 The CoAP option Listen-To-Multicast-Responses defined in Section 10.1 1906 is of class U for OSCORE and Group OSCORE 1907 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 1909 This allows the proxy adjacent to the origin server to access the 1910 option value conveyed in a ticket request (see Section 10.2), and to 1911 retrieve from it the transport-specific information about a phantom 1912 request. By doing so, the proxy becomes able to configure an 1913 observation of the target resource and to receive multicast 1914 notifications matching to the phantom request. 1916 Any proxy in the chain, as well as further possible intermediaries or 1917 on-path active adversaries, are thus able to remove the option or 1918 alter its content, before the ticket request reaches the proxy 1919 adjacent to the origin server. 1921 Removing the option would result in the proxy adjacent to the origin 1922 server to not configure the group observation, if that has not 1923 happened yet. In such a case, the proxy would not receive the 1924 corresponding multicast notifications to be forwarded back to the 1925 clients. 1927 Altering the option content would result in the proxy adjacent to the 1928 origin server to incorrectly configure a group observation (e.g., by 1929 indicating a wrong multicast IP address) hence preventing the correct 1930 reception of multicast notifications and their forwarding to the 1931 clients; or to configure bogus group observations that are currently 1932 not active on the origin server. 1934 In order to prevent what described above, the ticket requests 1935 conveying the Listen-To-Multicast-Responses option can be 1936 additionally protected hop-by-hop. 1938 14. IANA Considerations 1940 This document has the following actions for IANA. 1942 14.1. Media Type Registrations 1944 This specification registers the media type 'application/informative- 1945 response+cbor' for error messages as informative response defined in 1946 Section 2.2 of this specification, when carrying parameters encoded 1947 in CBOR. This registration follows the procedures specified in 1948 [RFC6838]. 1950 o Type name: application 1952 o Subtype name: informative-response+cbor 1954 o Required parameters: N/A 1956 o Optional parameters: N/A 1958 o Encoding considerations: Must be encoded as a CBOR map containing 1959 the parameters defined in Section 2.2 of [this document]. 1961 o Security considerations: See Section 13 of [this document]. 1963 o Interoperability considerations: N/A 1965 o Published specification: [this document] 1967 o Applications that use this media type: The type is used by CoAP 1968 servers and clients that support error messages as informative 1969 response defined in Section 2.2 of [this document]. 1971 o Fragment identifier considerations: N/A 1973 o Additional information: N/A 1975 o Person & email address to contact for further information: 1976 iesg@ietf.org [1] 1978 o Intended usage: COMMON 1980 o Restrictions on usage: None 1982 o Author: Marco Tiloca marco.tiloca@ri.se [2] 1984 o 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 o 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 o 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 o 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 o 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 o 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 o Description: Text giving an overview of the transport protocol 2043 referred by this item. 2045 o 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 o Server Addr: List of elements providing addressing information of 2055 the server. 2057 o Req Info: List of elements providing transport-specific 2058 information related to a pertinent CoAP request. Optional 2059 elements are prepended by '?'. 2061 o 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 o 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 o 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 o 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", draft-ietf-ace-key-groupcomm- 2141 oscore-10 (work in progress), February 2021. 2143 [I-D.ietf-ace-oscore-profile] 2144 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 2145 "OSCORE Profile of the Authentication and Authorization 2146 for Constrained Environments Framework", draft-ietf-ace- 2147 oscore-profile-16 (work in progress), January 2021. 2149 [I-D.ietf-core-groupcomm-bis] 2150 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 2151 for the Constrained Application Protocol (CoAP)", draft- 2152 ietf-core-groupcomm-bis-03 (work in progress), February 2153 2021. 2155 [I-D.ietf-core-oscore-groupcomm] 2156 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 2157 J. Park, "Group OSCORE - Secure Group Communication for 2158 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 2159 progress), February 2021. 2161 [I-D.ietf-cose-rfc8152bis-algs] 2162 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2163 Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12 2164 (work in progress), September 2020. 2166 [I-D.ietf-cose-rfc8152bis-struct] 2167 Schaad, J., "CBOR Object Signing and Encryption (COSE): 2168 Structures and Process", draft-ietf-cose-rfc8152bis- 2169 struct-15 (work in progress), February 2021. 2171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2172 Requirement Levels", BCP 14, RFC 2119, 2173 DOI 10.17487/RFC2119, March 1997, 2174 . 2176 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2177 "Transmission of IPv6 Packets over IEEE 802.15.4 2178 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2179 . 2181 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 2182 Specifications and Registration Procedures", BCP 13, 2183 RFC 6838, DOI 10.17487/RFC6838, January 2013, 2184 . 2186 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2187 Application Protocol (CoAP)", RFC 7252, 2188 DOI 10.17487/RFC7252, June 2014, 2189 . 2191 [RFC7641] Hartke, K., "Observing Resources in the Constrained 2192 Application Protocol (CoAP)", RFC 7641, 2193 DOI 10.17487/RFC7641, September 2015, 2194 . 2196 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 2197 Bose, "Constrained Application Protocol (CoAP) Option for 2198 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 2199 August 2016, . 2201 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 2202 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 2203 March 2017, . 2205 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2206 Writing an IANA Considerations Section in RFCs", BCP 26, 2207 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2208 . 2210 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2211 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2212 May 2017, . 2214 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 2215 DOI 10.17487/RFC8288, October 2017, 2216 . 2218 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2219 "Object Security for Constrained RESTful Environments 2220 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 2221 . 2223 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 2224 Representation (CBOR)", STD 94, RFC 8949, 2225 DOI 10.17487/RFC8949, December 2020, 2226 . 2228 15.2. Informative References 2230 [I-D.amsuess-core-cachable-oscore] 2231 Amsuess, C. and M. Tiloca, "Cachable OSCORE", draft- 2232 amsuess-core-cachable-oscore-01 (work in progress), 2233 February 2021. 2235 [I-D.ietf-ace-oauth-authz] 2236 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 2237 H. Tschofenig, "Authentication and Authorization for 2238 Constrained Environments (ACE) using the OAuth 2.0 2239 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37 2240 (work in progress), February 2021. 2242 [I-D.ietf-core-coap-pubsub] 2243 Koster, M., Keranen, A., and J. Jimenez, "Publish- 2244 Subscribe Broker for the Constrained Application Protocol 2245 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 2246 progress), September 2019. 2248 [I-D.ietf-core-coral] 2249 Hartke, K., "The Constrained RESTful Application Language 2250 (CoRAL)", draft-ietf-core-coral-03 (work in progress), 2251 March 2020. 2253 [I-D.ietf-core-resource-directory] 2254 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 2255 Stok, "CoRE Resource Directory", draft-ietf-core-resource- 2256 directory-26 (work in progress), November 2020. 2258 [I-D.ietf-tls-dtls13] 2259 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 2260 Datagram Transport Layer Security (DTLS) Protocol Version 2261 1.3", draft-ietf-tls-dtls13-41 (work in progress), 2262 February 2021. 2264 [I-D.tiloca-core-oscore-discovery] 2265 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 2266 Groups with the CoRE Resource Directory", draft-tiloca- 2267 core-oscore-discovery-08 (work in progress), February 2268 2021. 2270 [MOBICOM99] 2271 Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast 2272 Storm Problem in a Mobile Ad Hoc Network", Proceedings of 2273 the 5th annual ACM/IEEE international conference on Mobile 2274 computing and networking , August 1999, 2275 . 2278 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2279 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2280 January 2012, . 2282 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 2283 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 2284 . 2286 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2287 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2288 . 2290 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 2291 Definition Language (CDDL): A Notational Convention to 2292 Express Concise Binary Object Representation (CBOR) and 2293 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 2294 June 2019, . 2296 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 2297 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 2298 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2299 2020, . 2301 15.3. URIs 2303 [1] mailto:iesg@ietf.org 2305 [2] mailto:marco.tiloca@ri.se 2307 Appendix A. Different Sources for Group Observation Data 2309 While the clients usually receive the phantom registration request 2310 and other information related to the group observation through an 2311 Informative Response, the same data can be made available through 2312 different services, such as the following ones. 2314 A.1. Topic Discovery in Publish-Subscribe Settings 2316 In a Publish-Subscribe scenario ([I-D.ietf-core-coap-pubsub]), a 2317 group observation can be discovered along with topic metadata. For 2318 instance, a discovery step can make the following metadata available. 2320 This example assumes a CoRAL namespace [I-D.ietf-core-coral], that 2321 contains properties analogous to those in the content-format 2322 application/informative-response+cbor. 2324 Request: 2326 GET 2327 Accept: CoRAL 2329 Response: 2331 2.05 Content 2332 Content-Format: CoRAL 2334 rdf:type 2335 topic { 2336 tp_info [1, h"7b", h"20010db80100..0001", 5683, 2337 h"ff35003020010db8..1234", 5683], 2338 ph_req h"0160..", 2339 last_notif h"256105.." 2340 } 2342 Figure 11: Group observation discovery in a Pub-Sub scenario 2344 With this information from the topic discovery step, the client can 2345 already set up its multicast address and start receiving multicast 2346 notifications. 2348 In heavily asymmetric networks like municipal notification services, 2349 discovery and notifications do not necessarily need to use the same 2350 network link. For example, a departure monitor could use its (costly 2351 and usually-off) cellular uplink to discover the topics it needs to 2352 update its display to, and then listen on a LoRA-WAN interface for 2353 receiving the actual multicast notifications. 2355 A.2. Introspection at the Multicast Notification Sender 2357 For network debugging purposes, it can be useful to query a server 2358 that sends multicast responses as matching a phantom registration 2359 request. 2361 Such an interface is left for other documents to specify on demand. 2362 As an example, a possible interface can be as follows, and rely on 2363 the already known Token value of intercepted multicast notifications, 2364 associated to a phantom registration request. 2366 Request: 2368 GET 2370 Response: 2372 2.05 Content 2373 Content-Format: application/informative-response+cbor 2375 { 2376 'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 2377 h"ff35003020010db8..1234", 5683], 2378 'ph_req': h"0160..", 2379 'last_notif' : h"256105.." 2380 } 2382 Figure 12: Group observation discovery with server introspection 2384 For example, a network sniffer could offer sending such a request 2385 when unknown multicast notifications are seen on a network. 2386 Consequently, it can associate those notifications with a URI, or 2387 decrypt them, if member of the correct OSCORE group. 2389 Appendix B. Pseudo-Code for Rough Counting of Clients 2391 This appendix provides a description in pseudo-code of the two 2392 algorithms used for the rough counting of active observers, as 2393 defined in Section 6. 2395 In particular, Appendix B.1 describes the algorithm for the client 2396 side, while Appendix B.2 describes an optimized version for 2397 constrained clients. Finally, Appendix B.3 describes the algorithm 2398 for the server side. 2400 B.1. Client Side 2402 input: int Q, // Value of the MRFD option 2403 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2404 // unless overridden 2406 output: None 2408 int RAND_MIN = 0; 2409 int RAND_MAX = (2**Q) - 1; 2410 int I = randomInteger(RAND_MIN, RAND_MAX); 2412 if (I == 0) { 2413 float fraction = randomFloat(0, 1); 2415 Timer t = new Timer(); 2416 t.setAndStart(fraction * LEISURE_TIME); 2417 while(!t.isExpired()); 2419 Request req = new Request(); 2420 // Initialize as NON and with maximum 2421 // No-Response settings, set options ... 2423 Option opt = new Option(OBSERVE); 2424 opt.set(0); 2425 req.setOption(opt); 2427 opt = new Option(MRFD); 2428 req.setOption(opt); 2430 req.send(SRV_ADDR, SRV_PORT); 2431 } 2433 B.2. Client Side - Optimized Version 2435 input: int Q, // Value of the MRFD option 2436 int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252, 2437 // unless overridden 2439 output: None 2441 const unsigned int UINT_BIT = CHAR_BIT * sizeof(unsigned int); 2443 if (respond_to(Q) == true) { 2444 float fraction = randomFloat(0, 1); 2446 Timer t = new Timer(); 2447 t.setAndStart(fraction * LEISURE_TIME); 2448 while(!t.isExpired()); 2450 Request req = new Request(); 2451 // Initialize as NON and with maximum 2452 // No-Response settings, set options ... 2454 Option opt = new Option(OBSERVE); 2455 opt.set(0); 2456 req.setOption(opt); 2458 opt = new Option(MRFD); 2459 req.setOption(opt); 2461 req.send(SRV_ADDR, SRV_PORT); 2462 } 2464 bool respond_to(int Q) { 2465 while (Q >= UINT_BIT) { 2466 if (rand() != 0) return false; 2467 Q -= UINT_BIT; 2468 } 2469 unsigned int mask = ~((~0u) << Q); 2470 unsigned int masked = mask & rand(); 2471 return masked == 0; 2472 } 2474 B.3. Server Side 2476 input: int COUNT, // Current observer counter 2477 int M, // Desired number of confirmations 2478 int MAX_CONFIRMATION_WAIT, 2479 Response notification, // Multicast notification to send 2481 output: int NEW_COUNT // Updated observer counter 2483 int D = 4; // Dampener value 2484 int RETRY_NEXT_THRESHOLD = 4; 2485 float CANCEL_THRESHOLD = 0.2; 2487 int N = max(COUNT, 1); 2488 int Q = max(ceil(log2(N / M)), 0); 2489 Option opt = new Option(MRFD); 2490 opt.set(Q); 2492 notification.setOption(opt); 2493 2494 notification.send(GRP_ADDR, GRP_PORT); 2496 Timer t = new Timer(); 2497 t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1 2498 while(!t.isExpired()); 2500 // Time t2 2502 int R = ; 2505 int E = R * (2**Q); 2507 // Determine after how many multicast notifications 2508 // the next count update will be performed 2509 if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) { 2510 2511 } 2512 else { 2513 2514 } 2516 // Compute the new count estimate 2517 int COUNT_PRIME = ; 2518 int NEW_COUNT = COUNT_PRIME + ((E - N) / D); 2520 // Determine whether to cancel the group observation 2521 if (NEW_COUNT < CANCEL_THRESHOLD) { 2522 ; 2523 return 0; 2524 } 2526 return NEW_COUNT; 2528 Appendix C. OSCORE Group Self-Managed by the Server 2530 For simple settings, where no pre-arranged group with suitable 2531 memberships is available, the server can be responsible to setup and 2532 manage the OSCORE group used to protect the group observation. 2534 In such a case, a client would implicitly request to join the OSCORE 2535 group when sending the observe registration request to the server. 2536 When replying, the server includes the group keying material and 2537 related information in the informative response (see Section 2.2). 2539 Additionally to what defined in Section 2, the CBOR map in the 2540 informative response payload contains the following fields, whose 2541 CBOR labels are defined in Section 11. 2543 o 'gp_material': this element is a CBOR map, which includes what the 2544 client needs in order to set up the Group OSCORE Security Context. 2546 This parameter has as value a subset of the 2547 Group_OSCORE_Input_Material object, which is defined in 2548 Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the 2549 OSCORE_Input_Material object encoded in CBOR as defined in 2550 Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. 2552 In particular, the following elements of the 2553 Group_OSCORE_Input_Material object are included, using the same 2554 CBOR labels from the OSCORE Security Context Parameters Registry, 2555 as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. 2557 * 'ms', 'contexId', 'cs_alg', 'cs_params', 'cs_key_params', 2558 'cs_key_enc'. These elements MUST be included. 2560 * 'hkdf', 'alg', 'salt'. These elements MAY be included. 2562 The following elements of the Group_OSCORE_Input_Material object 2563 MUST NOT be included. 2565 * 'group_senderId', 'ecdh_alg', 'ecdh_params', 'ecdh_key_params'. 2567 o 'srv_pub_key': this element is a CBOR byte string, which wraps the 2568 serialization of the public key that the server uses in the OSCORE 2569 group. If the public key of the server is encoded as a COSE_Key 2570 (see the 'cs_key_enc' element of the 'gp_material' parameter), it 2571 includes 'kid' specifying the Sender ID that the server has in the 2572 OSCORE group. 2574 o 'srv_identifier': this element MUST be present only if 2575 'srv_pub_key' is also present and, at the same time, the used 2576 encoding for the public key of the server does not allow to 2577 specify a Sender ID within the associated public key. Otherwise, 2578 it MUST NOT be present. If present, this element is a CBOR byte 2579 string, with value the Sender ID that the server has in the OSCORE 2580 group. 2582 o 'exp': with value the expiration time of the keying material of 2583 the OSCORE group specified in the 'gp_material' parameter, encoded 2584 as a CBOR unsigned integer. This field contains a numeric value 2585 representing the number of seconds from 1970-01-01T00:00:00Z UTC 2586 until the specified UTC date/time, ignoring leap seconds, 2587 analogous to what specified for NumericDate in Section 2 of 2588 [RFC7519]. 2590 A client receiving an informative response uses the information above 2591 to set up the Group OSCORE Security Context, as described in 2592 Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client 2593 does not obtain a Sender ID of its own, hence it installs a Security 2594 Context that a "silent server" would, i.e. without Sender Context. 2595 From then on, the client uses the received keying material to process 2596 the incoming multicast notifications from the server. 2598 The server complies with the following points. 2600 o The server MUST NOT self-manage OSCORE groups and provide the 2601 related keying material in the informative response for any other 2602 purpose than the protection of group observations, as defined in 2603 this document. 2605 The server MAY use the same self-managed OSCORE group to protect 2606 the phantom request and the multicast notifications of multiple 2607 group observations it hosts. 2609 o The server MUST NOT provide in the informative response the keying 2610 material of other OSCORE groups it is or has been a member of. 2612 After the time indicated in the 'exp' field: 2614 o The server MUST stop using the keying material and MUST cancel the 2615 group observations for which that keying material is used (see 2616 Section 2.5). If the server creates a new group observation as a 2617 replacement or follow-up using the same OSCORE group: 2619 * The server MUST update the Master Secret. 2621 * The server MUST update the ID Context (Gid). Consistently with 2622 Section 2.3 of [I-D.ietf-core-oscore-groupcomm], the server 2623 MUST assign an ID Context that it has never assigned before in 2624 the OSCORE group. 2626 * The server MAY update the Master Salt. 2628 o The client MUST stop using the keying material and MAY re-register 2629 the observation at the server. 2631 Before the key material has expired, the server can send a multicast 2632 response with response code 5.03 (Service Unavailable) to the 2633 observing clients, protected with the current key material. In 2634 particular, this is an informative response (see Section 2.2) and 2635 contains the abovementioned parameters for the next group keying 2636 material to be used. Alternatively, the server can simply cancel the 2637 group observation (see Section 2.5), which results in the eventual 2638 re-registration of the clients that are still interested in the group 2639 observation. 2641 Applications requiring backward security and forward security are 2642 REQUIRED to use an actual group joining process (usually through a 2643 dedicated Group Manager), e.g. the ACE joining procedure defined in 2644 [I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the 2645 clients by providing them information about the OSCORE group to join, 2646 as described in Section 7.1. 2648 Appendix D. Phantom Request as Deterministic Request 2650 In some settings, the server can assume that all the approaching 2651 clients already have the exact phantom observation request to use. 2653 For instance, the clients can be pre-configured with the phantom 2654 observation request, or they may be expected to retrieve it through 2655 dedicated means (see Appendix A), before sending an observe 2656 registration request to the server. 2658 If Group OSCORE is used to protect the group observation (see 2659 Section 7), and the OSCORE group supports the concept of 2660 Deterministic Client [I-D.amsuess-core-cachable-oscore], then the 2661 server and each client in the OSCORE group can independently protect 2662 the phantom observation request possibly available as plain CoAP 2663 message. To this end, they use the approach defined in Section 2 of 2664 [I-D.amsuess-core-cachable-oscore] to compute a protected 2665 deterministic request, against which the protected multicast 2666 notifications will match for the group observation in question. 2668 Note that, if the optimization defined in Appendix C is also used, 2669 the error informative response from the server has to include 2670 additional information, i.e. the Sender ID of the Deterministic 2671 Client in the OSCORE group, and the hash algorithm used to compute 2672 the deterministic request (see Section 2.3.1 of 2673 [I-D.amsuess-core-cachable-oscore]). 2675 This optimization allows the server to not provide the same full 2676 phantom observation request to each client in the error informative 2677 response (see Section 2.2). That is, the informative response does 2678 not need to include the 'ph_req' parameter, but only the 'tp_info' 2679 parameter specifying the transport-specific information and 2680 (optionally) the 'last_notif' parameter specifying the latest sent 2681 multicast notification. 2683 Appendix E. Example with a Proxy 2685 This section provides an example when a proxy P is used between the 2686 clients and the server. The same assumptions and notation used in 2687 Section 5 are used for this example. In addition, the proxy has 2688 address PRX_ADDR and listens to the port number PRX_PORT. 2690 Unless explicitly indicated, all messages transmitted on the wire are 2691 sent over unicast. 2693 C1 C2 P S 2694 | | | | 2695 | | | | (The value of the resource /r is "1234") 2696 | | | | 2697 +------------>| | Token: 0x4a 2698 | GET | | | Observe: 0 (Register) 2699 | | | | Proxy-Uri: coap://sensor.example/r 2700 | | | | 2701 | | +------->| Token: 0x5e 2702 | | | GET | Observe: 0 (Register) 2703 | | | | Uri-Host: sensor.example 2704 | | | | Uri-Path: r 2705 | | | | 2706 | | | | (S allocates the available Token value 0x7b) 2707 | | | | 2708 | | | | (S sends to itself a phantom observation 2709 | | | | request PH_REQ as coming from the 2710 | | | | IP multicast address GRP_ADDR) 2711 | | | | 2712 | | | ------+ 2713 | | | / | 2714 | | | \----->| Token: 0x7b 2715 | | | GET | Observe: 0 (Register) 2716 | | | | Uri-Host: sensor.example 2717 | | | | Uri-Path: r 2718 | | | | 2719 | | | | 2720 | | | | (S creates a group observation of /r) 2721 | | | | 2722 | | | | (S increments the observer counter 2723 | | | | for the group observation of /r) 2724 | | | | 2725 | | | | 2726 | | |<-------+ Token: 0x5e 2727 | | | 5.03 | Content-Format: application/ 2728 | | | | informative-response+cbor 2729 | | | | 2730 | | | | Payload: { 2731 | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, 2732 | | | | 0x7b, bstr(GRP_ADDR), 2733 | | | | GRP_PORT], 2734 | | | | ph_req : bstr(0x01 | OPT), 2735 | | | | last_notif : bstr(0x45 | OPT | 2736 | | | | 0xff | PAYLOAD) 2737 | | | | } 2738 | | | | 2739 | | | | (PAYLOAD in 'last_notif' : "1234") 2740 | | | | 2741 | | | | 2742 | | | | (The proxy starts listening to the 2743 | | | | GRP_ADDR address and the GRP_PORT port.) 2744 | | | | 2745 | | | | (The proxy adds C1 to its list of observers.) 2746 | | | | 2747 | | | | 2748 |<------------+ | Token: 0x4a 2749 | 2.05 | | | Content-Format: application/cbor 2750 | | | | 2751 | | | | Payload: "1234" 2752 : : : : 2753 : : : : 2754 : : : : 2755 | +----->| | Token: 0x01 2756 | | GET | | Observe: 0 (Register) 2757 | | | | Proxy-Uri: coap://sensor.example/r 2758 | | | | 2759 | | | | (The proxy has a fresh cache representation) 2760 | | | | 2761 | |<-----+ | Token: 0x01 2762 | | 2.05 | | Content-Format: application/cbor 2763 | | | | 2764 | | | | Payload: "1234" 2765 | | | | 2766 | | | | 2767 : : : : 2768 : : : : (The value of the resource 2769 : : : : /r changes to "5678".) 2770 : : : (*) : 2771 | | |<-------+ Token: 0x7b 2772 | | | 2.05 | Observe: 11 2773 | | | | Content-Format: application/cbor 2774 | | | | 2775 | | | | Payload: "5678" 2776 | | | | 2777 |<------------+ | Token: 0x4a 2778 | 2.05 | | | Observe: 54123 2779 | | | | Content-Format: application/cbor 2780 | | | | 2781 | | | | Payload: "5678" 2782 | | | | 2783 | |<-----+ | Token: 0x01 2784 | | 2.05 | | Observe: 54123 2785 | | | | Content-Format: application/cbor 2786 | | | | 2787 | | | | Payload: "5678" 2789 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT 2791 Figure 13: Example of group observation with a proxy 2793 Note that the proxy has all the information to understand the 2794 observation request from C2, and can immediately start to serve the 2795 still fresh values. 2797 This behavior is mandated by Section 5 of [RFC7641], i.e. the proxy 2798 registers itself only once with the next hop and fans out the 2799 notifications it receives to all registered clients. 2801 Appendix F. Example with a Proxy and Group OSCORE 2803 This section provides an example when a proxy P is used between the 2804 clients and the server, and Group OSCORE is used to protect multicast 2805 notifications end-to-end between the server and the clients. 2807 The same assumptions and notation used in Section 8 are used for this 2808 example. In addition, the proxy has address PRX_ADDR and listens to 2809 the port number PRX_PORT. 2811 Unless explicitly indicated, all messages transmitted on the wire are 2812 sent over unicast and protected with OSCORE end-to-end between a 2813 client and the server. 2815 C1 C2 P S 2816 | | | | (The value of the resource /r is "1234") 2817 | | | | 2818 +-------------->| | Token: 0x4a 2819 | FETCH | | | Observe: 0 (Register) 2820 | | | | OSCORE: {kid: 1 ; piv: 101 ; ...} 2821 | | | | Uri-Host: sensor.example 2822 | | | | Proxy-Scheme: coap 2823 | | | | 2824 | | | | 0xff 2825 | | | | Encrypted_payload { 2826 | | | | 0x01 (GET), 2827 | | | | Observe: 0 (Register), 2828 | | | | Uri-Path: r, 2829 | | | | 2830 | | | | } 2831 | | | | 2832 | | +-------->| Token: 0x5e 2833 | | | FETCH | Observe: 0 (Register) 2834 | | | | OSCORE: {kid: 1 ; piv: 101 ; ...} 2835 | | | | Uri-Host: sensor.example 2836 | | | | 2837 | | | | 0xff 2838 | | | | Encrypted_payload { 2839 | | | | 0x01 (GET), 2840 | | | | Observe: 0 (Register), 2841 | | | | Uri-Path: r, 2842 | | | | 2843 | | | | } 2844 | | | | 2845 | | | | 2846 | | | | (S allocates the available 2847 | | | | Token value 0x7b .) 2848 | | | | 2849 | | | | (S sends to itself a phantom observation 2850 | | | | request PH_REQ as coming from the 2851 | | | | IP multicast address GRP_ADDR) 2852 | | | | 2853 | | | -------+ 2854 | | | / | 2855 | | | \------>| Token: 0x7b 2856 | | | FETCH | Observe: 0 (Register) 2857 | | | | OSCORE: {kid: 5 ; piv: 501 ; 2858 | | | | kid context: 57ab2e; ...} 2859 | | | | Uri-Host: sensor.example 2860 | | | | 2861 | | | | 0xff 2862 | | | | Encrypted_payload { 2863 | | | | 0x01 (GET), 2864 | | | | Observe: 0 (Register), 2865 | | | | Uri-Path: r 2866 | | | | 2867 | | | | } 2868 | | | | 2869 | | | | 2870 | | | | 2871 | | | | (S steps SN_5 in the Group OSCORE 2872 | | | | Security Context : SN_5 <== 502) 2873 | | | | 2874 | | | | (S creates a group observation of /r) 2875 | | | | 2876 | | | | (S increments the observer counter 2877 | | | | for the group observation of /r) 2878 | | | | 2879 | | | | 2880 | | |<--------+ Token: 0x5e 2881 | | | 2.05 | OSCORE: {piv: 301 ; ...} 2882 | | | | 2883 | | | | 0xff 2884 | | | | Encrypted_payload { 2885 | | | | 5.03 (Service Unavailable), 2886 | | | | Content-Format: application/ 2887 | | | | informative-response+cbor, 2888 | | | | , 2889 | | | | 0xff, 2890 | | | | CBOR_payload { 2891 | | | | tp_info : [1, bstr(SRV_ADDR), 2892 | | | | SRV_PORT, 0x7b, 2893 | | | | bstr(GRP_ADDR), GRP_PORT], 2894 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2895 | | | | PAYLOAD | SIGN), 2896 | | | | last_notif : bstr(0x45 | OPT | 0xff | 2897 | | | | PAYLOAD | SIGN), 2898 | | | | join_uri : "coap://myGM/ 2899 | | | | ace-group/myGroup", 2900 | | | | sec_gp : "myGroup" 2901 | | | | } 2902 | | | | } 2903 | | | | 2904 | | | | 2905 |<--------------+ | Token: 0x4a 2906 | 2.05 | | | OSCORE: {piv: 301 ; ...} 2907 | | | | 2908 | | | | 0xff 2909 | | | | (Same Encrypted_payload) 2910 | | | | 2911 | | | | 2912 +-------------->| | Token: 0x4b 2913 | FETCH | | | Observe: 0 (Register) 2914 | | | | OSCORE: {kid: 5 ; piv: 501 ; ...} 2915 | | | | Uri-Host: sensor.example 2916 | | | | Proxy-Scheme: coap 2917 | | | | Listen-To- 2918 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 2919 | | | | SRV_PORT, 0x7b, 2920 | | | | bstr(GRP_ADDR), 2921 | | | | GRP_PORT] 2922 | | | | } 2923 | | | | 2924 | | | | 0xff 2925 | | | | Encrypted_payload { 2926 | | | | 0x01 (GET), 2927 | | | | Observe: 0 (Register), 2928 | | | | Uri-Path: r 2929 | | | | 2930 | | | | } 2931 | | | | 2932 | | | | 2933 | | | | 2934 | | | | (The proxy starts listening to the 2935 | | | | GRP_ADDR address and the GRP_PORT port.) 2936 | | | | 2937 | | | | (The proxy adds C1 to 2938 | | | | its list of observers.) 2939 : : : : 2940 : : : : 2941 : : : : 2942 | +------>| | Token: 0x01 2943 | | FETCH | | Observe: 0 (Register) 2944 | | | | OSCORE: {kid: 2 ; piv: 201 ; ...} 2945 | | | | Uri-Host: sensor.example 2946 | | | | Proxy-Scheme: coap 2947 | | | | 2948 | | | | 0xff 2949 | | | | Encrypted_payload { 2950 | | | | 0x01 (GET), 2951 | | | | Observe: 0 (Register), 2952 | | | | Uri-Path: r, 2953 | | | | 2954 | | | | } 2955 | | | | 2956 | | +-------->| Token: 0x5e 2957 | | | FETCH | Observe: 0 (Register) 2958 | | | | OSCORE: {kid: 2 ; piv: 201 ; ...} 2959 | | | | Uri-Host: sensor.example 2960 | | | | 2961 | | | | 0xff 2962 | | | | Encrypted_payload { 2963 | | | | 0x01 (GET), 2964 | | | | Observe: 0 (Register), 2965 | | | | Uri-Path: r, 2966 | | | | 2967 | | | | } 2968 | | | | 2969 | | |<--------+ Token: 0x5e 2970 | | | 2.05 | OSCORE: {piv: 401 ; ...} 2971 | | | | 2972 | | | | 0xff 2973 | | | | Encrypted_payload { 2974 | | | | 5.03 (Service Unavailable), 2975 | | | | Content-Format: application/ 2976 | | | | informative-response+cbor, 2977 | | | | , 2978 | | | | 0xff, 2979 | | | | CBOR_payload { 2980 | | | | tp_info : [1, bstr(SRV_ADDR), 2981 | | | | SRV_PORT, 0x7b, 2982 | | | | bstr(GRP_ADDR), GRP_PORT], 2983 | | | | ph_req : bstr(0x05 | OPT | 0xff | 2984 | | | | PAYLOAD | SIGN), 2985 | | | | last_notif : bstr(0x45 | OPT | 0xff | 2986 | | | | PAYLOAD | SIGN), 2987 | | | | join_uri : "coap://myGM/ 2988 | | | | ace-group/myGroup", 2989 | | | | sec_gp : "myGroup" 2990 | | | | } 2991 | | | | } 2992 | | | | 2993 | |<------+ | Token: 0x01 2994 | | 2.05 | | OSCORE: {piv: 401 ; ...} 2995 | | | | 2996 | | | | 0xff 2997 | | | | (Same Encrypted_payload) 2998 | | | | 2999 | | | | 3000 | +------>| | Token: 0x02 3001 | | FETCH | | Observe: 0 (Register) 3002 | | | | OSCORE: {kid: 5 ; piv: 501 ; ...} 3003 | | | | Uri-Host: sensor.example 3004 | | | | Proxy-Scheme: coap 3005 | | | | Listen-To- 3006 | | | | Multicast-Responses: {[1, bstr(SRV_ADDR), 3007 | | | | SRV_PORT, 0x7b, 3008 | | | | bstr(GRP_ADDR), 3009 | | | | GRP_PORT] 3010 | | | | } 3011 | | | | 3012 | | | | 0xff 3013 | | | | Encrypted_payload { 3014 | | | | 0x01 (GET), 3015 | | | | Observe: 0 (Register), 3016 | | | | Uri-Path: r 3017 | | | | 3018 | | | | } 3019 | | | | 3020 | | | | 3021 | | | | (The proxy adds C2 to its list of 3022 | | | | observers, and serves the cached 3023 | | | | response) 3024 | | | | 3025 | |<------+ | Token: 0x02 3026 | | 2.05 | | OSCORE: {piv: 301 ; ...} 3027 | | | | 3028 | | | | 0xff 3029 | | | | (Same as earlier to C1) 3030 : : : : 3031 : : : : 3032 : : : : 3033 | | | | (The value of the resource 3034 | | | | /r changes to "5678".) 3035 | | | | 3036 | | | | 3037 | | | (*) | 3038 | | |<--------+ Token: 0x7b 3039 | | | 2.05 | Observe: 11 3040 | | | | OSCORE: {kid: 5; piv: 502 ; 3041 | | | | kid context: 57ab2e; ...} 3042 | | | | 3043 | | | | 0xff 3044 | | | | Encrypted_payload { 3045 | | | | 2.05 (Content), 3046 | | | | Observe: 11, 3047 | | | | Content-Format: application/cbor, 3048 | | | | , 3049 | | | | 0xff, 3050 | | | | CBOR_Payload : "5678" 3051 | | | | } 3052 | | | | 3053 | | | | 3054 | | | | 3055 |<--------------+ | Token: 0x4b 3056 | 2.05 | | | Observe: 54123 3057 | | | | OSCORE: {kid: 5; piv: 502 ; 3058 | | | | kid context: 57ab2e; ...} 3059 | | | | 3060 | | | | 0xff 3061 | | | | (Same Encrypted_payload) 3062 | | | | 3063 | |<------+ | Token: 0x02 3064 | | 2.05 | | Observe: 54123 3065 | | | | OSCORE: {kid: 5; piv: 502 ; 3066 | | | | kid context: 57ab2e; ...} 3067 | | | | 3068 | | | | 0xff 3069 | | | | (Same Encrypted_payload) 3071 (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected 3072 with Group OSCORE end-to-end between the server and the clients. 3074 Figure 14: Example of group observation with a proxy and Group OSCORE 3076 Unlike in the unprotected example in Appendix E, the proxy does _not_ 3077 have all the information to perform request deduplication, and can 3078 only recognize the identical request once the client sends the ticket 3079 request. 3081 Acknowledgments 3083 The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime 3084 Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander 3085 for their comments and feedback. 3087 The work on this document has been partly supported by VINNOVA and 3088 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 3089 (Grant agreement 952652). 3091 Authors' Addresses 3093 Marco Tiloca 3094 RISE AB 3095 Isafjordsgatan 22 3096 Kista SE-16440 Stockholm 3097 Sweden 3099 Email: marco.tiloca@ri.se 3101 Rikard Hoeglund 3102 RISE AB 3103 Isafjordsgatan 22 3104 Kista SE-16440 Stockholm 3105 Sweden 3107 Email: rikard.hoglund@ri.se 3109 Christian Amsuess 3110 Hollandstr. 12/4 3111 Vienna 1020 3112 Austria 3114 Email: christian@amsuess.com 3116 Francesca Palombini 3117 Ericsson AB 3118 Torshamnsgatan 23 3119 Kista SE-16440 Stockholm 3120 Sweden 3122 Email: francesca.palombini@ericsson.com