idnits 2.17.1 draft-tiloca-core-observe-multicast-notifications-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2020) is 1508 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 1439 -- Looks like a reference, but probably isn't: '2' on line 1441 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-07 ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-05 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-37 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 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: September 10, 2020 7 F. Palombini 8 Ericsson AB 9 March 09, 2020 11 Observe Notifications as CoAP Multicast Responses 12 draft-tiloca-core-observe-multicast-notifications-02 14 Abstract 16 The Constrained Application Protocol (CoAP) allows clients to 17 "observe" resources at a server, and receive notifications as unicast 18 responses upon changes of the resource state. In some use cases, 19 such as based on publish-subscribe, it would be convenient for the 20 server to send a single notification to all the clients observing a 21 same target resource. This document defines how a CoAP server sends 22 observe notifications as response messages over multicast, by 23 synchronizing all the observers of a same resource on a same shared 24 Token value. Besides, this document defines how Group OSCORE can be 25 used to protect multicast notifications end-to-end from the CoAP 26 server to the multiple observer clients. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 10, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 65 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Informative Response . . . . . . . . . . . . . . . . . . 6 67 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 8 68 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 8 69 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 9 70 2.5.1. Rough Counting of Clients in the Group Observation . 9 71 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 12 72 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.2. Informative Response . . . . . . . . . . . . . . . . . . 12 74 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 13 75 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13 76 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5. Protection of Multicast Notifications with Group OSCORE . . . 15 78 5.1. Signaling the OSCORE Group in the Informative Response . 16 79 5.2. Server-Side Requirements . . . . . . . . . . . . . . . . 17 80 5.2.1. Registration . . . . . . . . . . . . . . . . . . . . 18 81 5.2.2. Informative Response . . . . . . . . . . . . . . . . 18 82 5.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 18 83 5.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 19 84 5.3. Client-Side Requirements . . . . . . . . . . . . . . . . 19 85 5.3.1. Informative Response . . . . . . . . . . . . . . . . 19 86 5.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 20 87 6. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 20 88 7. Informative Response Parameters . . . . . . . . . . . . . . . 23 89 8. Phantom Request Parameters . . . . . . . . . . . . . . . . . 24 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 10.1. Media Type Registrations . . . . . . . . . . . . . . . . 25 93 10.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 26 94 10.3. Informative Response Parameters Registry . . . . . . . . 27 95 10.4. Phantom Request Parameters Registry . . . . . . . . . . 27 96 10.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 28 97 10.6. Expert Review Instructions . . . . . . . . . . . . . . . 28 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 100 11.2. Informative References . . . . . . . . . . . . . . . . . 30 101 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 102 Appendix A. Different Sources for Phantom Requests . . . . . . . 32 103 A.1. PubSub . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 A.2. Sender Introspection . . . . . . . . . . . . . . . . . . 33 105 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 108 1. Introduction 110 The Constrained Application Protocol (CoAP) [RFC7252] has been 111 extended with a number of mechanisms, including resource Observation 112 [RFC7641]. This enables CoAP clients to register at a CoAP server as 113 "observers" of a resource, and hence being automatically notified 114 with an unsolicited response upon changes of the resource state. 116 CoAP supports group communication over IP multicast 117 [I-D.dijk-core-groupcomm-bis]. This includes support for Observe 118 registration requests over multicast, in order for clients to 119 efficiently register as observers of a resource hosted at multiple 120 servers. 122 However, in a number of use cases, using multicast messages for 123 responses would also be desirable. That is, it would be useful that 124 a server sends observe notifications for a same target resource to 125 multiple observers as responses over IP multicast. 127 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 128 multiple clients can subscribe to a topic, by observing the related 129 resource hosted at the responsible broker. When a new value is 130 published on that topic, it would be convenient for the broker to 131 send a single multicast notification at once, to all the subscriber 132 clients observing that topic. 134 A different use case concerns clients observing a same registration 135 resource at the CoRE Resource Directory 136 [I-D.ietf-core-resource-directory]. For example, multiple clients 137 can benefit of observation for discovering (to-be-created) OSCORE 138 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 139 Resource Directory updated links and descriptions to join them 140 through the respective Group Manager 141 [I-D.tiloca-core-oscore-discovery]. 143 More in general, multicast notifications would be beneficial whenever 144 several CoAP clients observe a same target resource at a CoAP server, 145 and can be all notified at once by means of a single response 146 message. However, CoAP does not currently define response messages 147 over IP multicast. This specification fills this gap and provides 148 the following twofold contribution. 150 First, it defines a method to deliver Observe notifications as CoAP 151 responses over IP multicast. In the proposed method, the group of 152 potential observers entrusts the server to manage the Token space for 153 multicast notifications. By doing so, the server provides all the 154 observers of a target resource with the same Token value to bind to 155 their own observation. That Token value is then used in every 156 multicast notification for the target resource. This is achieved by 157 means of an informative unicast response sent by the server to each 158 observer client. 160 Second, this specification defines how to use Group OSCORE 161 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 162 end-to-end between the server and the observer clients. This is also 163 achieved by means of the informative unicast response mentioned 164 above, which additionally includes parameter values used by the 165 server to protect every multicast notification for the target 166 resource by using Group OSCORE. This provides a secure binding 167 between each of such notifications and the observation of each of the 168 clients. 170 1.1. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 Readers are expected to be familiar with terms and concepts described 179 in CoAP [RFC7252], group communication for CoAP 180 [I-D.dijk-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC7049], 181 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 183 This specification additionally defines the following terminology. 185 o Traditional observation. A resource observation associated to a 186 single observer client, as defined in [RFC7641]. 188 o Group observation. A resource observation associated to a group 189 of clients. The server sends notifications for the group-observed 190 resource over IP multicast to all the observer clients. 192 o Phantom request. The CoAP request message that the server would 193 have received to generate a group observation on one of its 194 resources. The phantom request is generated inside the server and 195 does not hit the wire. 197 o Informative response. A CoAP response message that the server 198 sends to a given client via unicast, providing the client with 199 information on a group observation. 201 2. Server-Side Requirements 203 The server can, at any time, start a group observation on one of its 204 resources. Practically, the server may want to do that under the 205 following circumstances. 207 o In the absence of observations for the target resource, the server 208 receives a registration request from a first client wishing to 209 start a traditional observation on that resource. 211 o When a certain amount of traditional observations has been 212 established on the target resource, the server decides to make 213 those clients part of a group observation on that resource. 215 The server maintains an observer counter for each group observation 216 to a target resource, as a rough estimation of the observers actively 217 taking part in the group observation. The server increments the 218 counter when a new client starts taking part in that group 219 observation. Also, the server should update the counter over time, 220 for instance by using the method described in Section 2.5.1. 222 2.1. Request 224 When it wants to start a group observation on one of its resources, 225 and assuming it knows the multicast IP address to use to send 226 multicast notifications to, the server proceeds as follows. 228 1. The server builds a phantom observation request, i.e. a GET 229 request with an Observe option set to 0 (register). 231 2. The server selects a currently available value T, from the Token 232 space used for messages from the chosen multicast IP address to 233 the server address intended for accessing the target resource. 234 That Token space is under exclusive control of the server. 236 3. The server processes the phantom observation request above, 237 without transmitting it on the wire. The request is addressed to 238 the resource for which the server wants to start the group 239 observation, as if sent from the group of observers, i.e. with 240 the multicast IP address as source address. 242 4. Upon processing the self-generated phantom request, the server 243 interprets it as an observe registration received from the group 244 of potential observer clients. In particular, from then on, the 245 server MUST use T as its own local Token value associated to that 246 observation, with respect to the (next hop towards the) clients. 248 5. The server does not immediately respond to the phantom 249 observation request with a multicast notification. The server 250 stores the phantom observation request as is, throughout the 251 lifetime of the group observation. 253 2.2. Informative Response 255 After having started a group observation on a target resource, the 256 server proceeds as follows. 258 For each traditional observation ongoing on the target resource, the 259 server MAY cancel that observation. Then, the server considers the N 260 corresponding clients as now taking part in the group observation, of 261 which it increases the corresponding observer counter by N. 263 The server sends to each of such clients an informative response 264 message, encoded as a unicast response with response code 5.03 265 (Service Unavailable). As per [RFC7641], such a response does not 266 include an Observe option. The response MUST be Confirmable and MUST 267 NOT encode link-local addresses. 269 The Content-Format of the informative response is set to application/ 270 informative-response+cbor, as defined in Section 10.2. The payload 271 of the informative response is a CBOR map including the following 272 parameters, whose CBOR labels are defined in Section 7. 274 o 'ph_req', with value the phantom observation request received by 275 the server, encoded as a CBOR map including the following fields, 276 whose CBOR labels are defined in Section 8. 278 * 'src_addr', with value the source IP address of the phantom 279 observation request, encoded as a CBOR byte string. This 280 parameter is tagged and identified by the CBOR tag 260 "Network 281 Address (IPv4 or IPv6 or MAC Address)". The specified address 282 is the IP multicast address where the server will send 283 multicast notifications for the target resource. 285 * 'src_port', with value the source port number of the phantom 286 observation request, encoded as a CBOR unsigned integer. 288 * 'dst_addr', with value the destination IP address of the 289 phantom observation request, encoded as a CBOR byte string. 290 This parameter is tagged and identified by the CBOR tag 260 291 "Network Address (IPv4 or IPv6 or MAC Address)". The specified 292 address is the IP address of the server hosting the target 293 resource. 295 * 'dst_port', with value the destination port number of the 296 phantom observation request, encoded as a CBOR unsigned 297 integer. This is the port number the server hosting the target 298 resource has been listening to. 300 * 'coap_msg', with value the byte serialization of the CoAP 301 message sent as phantom observation request, encoded as a CBOR 302 byte string. Specifically, the value of the byte string is the 303 byte serialization of what becomes payload for the transport 304 layer underlying CoAP, such as UDP. 306 o 'notif_num', specifying a baseline Observe value for the group 307 observation of the target resource, encoded as a CBOR unsigned 308 integer. This parameter specifies either: i) the value of the 309 Observe option in the latest sent multicast notification; or ii) 310 X, where X + 1 will be used as value of the Observe option in the 311 first, yet-to-come multicast notification. 313 o Optionally, 'res', with value the byte serialization of the 314 current representation of the target resource, encoded as a CBOR 315 byte string. 317 o Optionally, 'res_ct', with value the format of the current 318 representation of the target resource specified in the 'res' 319 parameter, encoded as a CBOR unsigned integer. This parameter has 320 as value the numeric Content-Format identifier for the 321 representation format of the target resource, taken from the "CoAP 322 Content-Formats" Registry defined in Section 12.3 of [RFC7252]. 323 This parameter MUST be present if the 'res' parameter is present. 325 Upon receiving a registration request to observe the target resource, 326 the server does not create a corresponding individual observation for 327 the requesting client. Instead, the server considers that client as 328 now taking part in the group observation of the target resource, of 329 which it increments the observer counter by 1. Then, the server 330 replies to the client with the same informative response message 331 defined above, which MUST be Confirmable and MUST include also the 332 'res' and 'res_ct' parameters. 334 Note that this also applies when, with no ongoing traditional 335 observations on the target resource, the server receives a 336 registration request from a first client and decides to start a group 337 observation on the target resource. 339 2.3. Notifications 341 Upon a change of the status of the target resource under group 342 observation, the server sends a multicast notification, intended to 343 all the clients taking part in the group observation of that 344 resource. In particular, each of such multicast notifications: 346 o MUST be sent to the IP multicast address indicated to the observer 347 clients, as value of the 'src_addr' field within the 'ph_req' 348 parameter of the informative response message (see Section 2.2). 350 o MUST be Non-confirmable. 352 o MUST include an Observe option, as per [RFC7641]. 354 o MUST have the same Token value T of the phantom registration 355 request that started the group observation, also included in the 356 informative response message to the observer clients, as 357 'coap_msg' field of the 'ph_req' parameter. That is, every 358 multicast notification for a target resource is not bound to the 359 observation requests from the different clients, but rather to the 360 phantom registration request associated to the whole set of 361 clients taking part in the group observation of that resource. 363 2.4. Congestion Control 365 In order to not cause congestion, the server should conservatively 366 control the sending of multicast notifications. In particular: 368 o The multicast notifications MUST be Non-confirmable. 370 o In constrained environments such as low-power, lossy networks 371 (LLNs), the server should only support multicast notifications for 372 resources that are small. Following related guidelines from 373 Section 2.2.4 of [I-D.dijk-core-groupcomm-bis], this can consist, 374 for example, in having the payload of multicast notifications as 375 limited to approximately 5% of the IP Maximum Transmit Unit (MTU) 376 size, so that it fits into a single link-layer frame in case IPv6 377 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see 378 Section 4 of [RFC4944]) is used. 380 o The server SHOULD provide multicast notifications with the 381 smallest possible IP multicast scope that fulfills the application 382 needs. For example, following related guidelines from 383 Section 2.2.4 of [I-D.dijk-core-groupcomm-bis], site-local scope 384 is always preferred over global scope IP multicast, if this 385 fulfills the application needs. Similarly, realm-local scope is 386 always preferred over site-local scope, if this fulfills the 387 application needs. 389 o Following related guidelines from Section 4.5.1 of [RFC7641],the 390 server SHOULD NOT send more than one multicast notification every 391 3 seconds, and SHOULD use an even less aggressive rate when 392 possible (see also Section 3.1.2 of [RFC5405]). 394 2.5. Cancellation 396 At any point in time, the server may want to cancel a group 397 observation of a target resource. For instance, the server may 398 realize that no clients or not enough clients are interested in 399 taking part in the group observation anymore. A possible approach 400 that the server can use to assess this is defined in Section 2.5.1. 402 In order to cancel the group observation, the server sends to itself 403 a phantom cancellation request, i.e. a GET request with an Observe 404 option set to 1 (deregister), without transmitting it on the wire. 405 As per Section 3.6 of [RFC7641], all other options MUST be identical 406 to those in the phantom registration request, except for the set of 407 ETag Options. This request has the same Token value T of the phantom 408 registration request, and is addressed to the resource for which the 409 server wants to end the group observation, as if sent from the group 410 of observers, i.e. with the multicast IP address as source address. 412 After that, the server sends a multicast response with response code 413 5.03 (Service Unavailable), signaling that the group observation has 414 been terminated. The response has no payload, and is sent to the 415 same multicast IP address used to send the multicast notifications 416 related to the target resource. As per [RFC7641], this response does 417 not include an Observe option. Finally, the server releases the 418 resources allocated for the group observation, and especially frees 419 up the Token value T used at its endpoint. 421 2.5.1. Rough Counting of Clients in the Group Observation 423 To allow the server to keep an estimate of interested clients without 424 creating undue traffic on the network, a new CoAP option is 425 introduced, which SHOULD be supported by clients that listen to 426 multicast responses. 428 The option is called Multicast-Response-Feedback-Divider, and is only 429 used in responses. As summarized in Figure 1, the option is not 430 critical but proxy-unsafe, and integer valued. 432 +-----+---+---+---+---+---------------------+--------+-------+---------+ 433 | No. | C | U | N | R | Name | Format | Len. | Default | 434 +-----+---+---+---+---+---------------------+--------+-------+---------+ 435 | TBD | | x | | | Multicast-Response- | uint | 0-8 B | (none) | 436 | | | | | | Feedback-Divider | | | | 437 +-----+---+---+---+---+---------------------+--------+-------+---------+ 439 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable, 441 Figure 1: Multicast-Response-Feedback-Divider 443 The Multicast-Response-Feedback-Divider option is of class E for 444 OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. 446 2.5.1.1. Client Processing 448 Upon receiving a response with a Multicast-Response-Feedback-Divider 449 option, a client SHOULD acknowledge its interest in continuing 450 receiving multicast notifications for the target resource. 452 To do that, the client picks an integer random number 'c', from 0 453 inclusive to the number 'q' given in the option exclusive. If 'c' is 454 different than 0, the client takes no further action. Otherwise, the 455 client should wait a random fraction of the Leisure time (see 456 Section 8.2 of [RFC7252]), and then registers a regular unicast 457 observation on the same target resource. To this end, the client 458 essentially follows the steps that got it originally subscribed to 459 group notifications for the target resource. 461 As the observation registration is only done for its side effect of 462 showing as an attempted observation at the server, the client SHOULD 463 send the unicast request in a non confirmable way, and with the 464 maximum No-Response setting [RFC7967]. The client does not need to 465 wait for responses, and can keep processing further notifications on 466 the same token. 468 As the Multicast-Response-Feedback-Divider option is unsafe to 469 forward, a proxy needs to answer it on its own, and is later counted 470 as a single client. 472 2.5.1.2. Client Counting 474 In order to avoid needless use of network resources, a server SHOULD 475 keep a rough count of the number of clients taking part in the group 476 observation of a target resource. To this end, the server updates 477 the associated observer counter (see Section 2), for instance by 478 using the method described below. 480 When it wants to obtain a new estimated count, the server picks a 481 number 'm' of confirmations it would like to receive from the 482 clients. It is up to applications to define policies about how the 483 server determines and adjusts the value of 'm'. The following 484 example will be done with m = 5. 486 Then, the server considers its current estimate of listeners 'n', and 487 divides it by 'm'. The resulting quotient q = ceil(n / m) is set as 488 value in the Multicast-Response-Feedback-Divider option, which is 489 sent within a successful multicast notification. If several 490 multicast notifications are sent in a burst fashion, it is 491 RECOMMENDED for the server to include the Multicast-Response- 492 Feedback-Divider option only in the first one of those notifications. 494 Later on, the server counts the 'r' attempted unicast observations 495 arriving after the notification, and multiplies that with the last 496 Multicast-Response-Feedback-Divider value 'q', to get an updated 497 client estimate 'n'. 499 This estimate is skewed by new registrations and by packet loss, but 500 it gives the server a sufficiently good estimation for further counts 501 and for deciding when to cancel the group observation. It is up to 502 applications to define policies about how the server takes the 503 updated value of 'n' into account and determines whether to cancel 504 the group observation. 506 For example, if the server currently estimates that n = 20 observers 507 are active, it sends a notification out with Multicast-Response- 508 Feedback-Divider: 4. Then, out of 18 actually active clients, 5 send 509 a re-registration request based on their random draw, of which one 510 request gets lost, thus leaving four re-registration requests 511 received by the server. As a consequence, the server updates the 512 observer counter to n = 4 * 4 = 16, and continues sending 513 notifications to the group of observers. 515 Note that a server can send Multicast-Response-Feedback-Divider: 1 in 516 the last notifications, before cancelling a group observation. This 517 will trigger all the active clients to state their interest in 518 continuing receiving notifications for the target resource. 520 3. Client-Side Requirements 522 3.1. Request 524 A client sends an observation request to the server as described in 525 [RFC7641], i.e. a GET request with an Observe option set to 0 526 (register). The request MUST NOT encode link-local addresses. If 527 the server is not configured to accept registrations on that target 528 resource with a group observation, this would still result in a 529 positive notification response to the client as described in 530 [RFC7641]. 532 3.2. Informative Response 534 Upon receiving the informative response defined in Section 2.2, the 535 client proceeds as follows. 537 1. The client configures an observation of the target resource from 538 a CoAP endpoint associated to the IP multicast address, specified 539 by the 'src_addr' field within the 'ph_req' parameter of the 540 informative response. 542 2. The client retrieves and stores the phantom registration request 543 specified in the 'coap_msg' field within the 'ph_req' parameter 544 of the informative response. The group observation is bound to 545 this phantom registration request. In particular, the client 546 MUST use its Token value T as its own local Token value 547 associated to that group observation, with respect to the (next 548 hop towards the) server. The particular way to achieve this is 549 implementation specific. 551 3. The client retrieves and stores the value of the 'notif_num' 552 parameter of the informative response. 554 4. If a traditional observation to the target resource is ongoing, 555 the client MAY silently cancel it without notifying the server. 557 5. If the informative response from the server includes the 558 parameter 'res' with value the current representation of the 559 target resource, the client considers it as received from an 560 observe notification and processes it as usual. 562 If any of the expected fields are not present, the client MAY try 563 sending a new registration request to the server (see Section 3.1). 564 Otherwise, the client SHOULD explicitly withdraw from the group 565 observation. 567 3.3. Notifications 569 After having successfully processed the informative response as 570 defined in Section 3.2, the client will receive, accept and process 571 multicast notifications about the state of the target resource from 572 the server, as responses to the phantom registration request and with 573 Token value T. 575 The client relies on the value of the Observe option for notification 576 reordering, as defined in Section 3.4 of [RFC7641]. In particular, 577 upon receiving its first multicast notification for the target 578 resource, the client MUST treat it as fresh only if the value of the 579 Observe option is strictly greater than the stored value of the 580 'notif_num' parameter from the informative response (see 581 Section 2.2). 583 3.4. Cancellation 585 At a certain point in time, a client may become not interested in 586 receiving further multicast notifications about a target resource. 587 When this happens, the client can simply "forget" about being part of 588 the group observation for that target resource, as per Section 3.6 of 589 [RFC7641]. 591 When, later on, the server sends the next multicast notification, the 592 client will not recognize the Token value T in the message. Since 593 the multicast notification is Non-confirmable, it is OPTIONAL for the 594 client to reject the multicast notification with a Reset message, as 595 defined in Section 3.5 of [RFC7641]. 597 In case the server has cancelled a group observation as defined in 598 Section 2.5, the client simply forgets about the group observation 599 and frees up the used Token value T for that endpoint, upon receiving 600 the multicast error response defined in Section 2.5. 602 4. Example 604 The following example refers to two clients C_1 and C_2 that register 605 to observe a resource /r at a Server S with address SERVER_ADDR. 606 Before the following exchanges occur, no clients are observing the 607 resource /r , which has value "1234". 609 In the informative responses, 'bstr(X)' denotes a byte string with 610 value the byte serialization of X. Also, the notation Y.CoAP denotes 611 the CoAP-layer part of a message Y, i.e. the part of Y that becomes 612 payload for the transport layer underlying CoAP, such as UDP. 614 The server S sends multicast notifications to the IP multicast 615 address M_ADDR , and starts the group observation upon receiving a 616 registration request from a first client that wishes to start a 617 traditional observation on the resource /r. 619 C_1 ------------------ [ Unicast ] --------------------> S /r 620 | GET | 621 | Token: 0x4a | 622 | Observe: 0 (Register) | 623 | | 624 | (S allocates the available Token value 0xff .) | 625 | | 626 | (S sends to itself a phantom observation request PH_REQ | 627 | as coming from the IP multicast address M_ADDR .) | 628 | ------------------------------------------------- | 629 | / | 630 | \----------------------------------------------------> | /r 631 | GET | 632 | Token: 0xff | 633 | Observe: 0 (Register) | 634 | | 635 | (S creates a group observation of /r .) | 636 | | 637 | (S increments the observer counter | 638 | for the group observation of /r .) | 639 | | 640 C_1 <--------------------- [ Unicast ] ----------------- S 641 | 5.03 | 642 | Token: 0x4a | 643 | Payload: { ph_req : { | 644 | src_addr : bstr(M_ADDR), | 645 | src_port : 65500, | 646 | dst_addr : bstr(SERVER_ADDR), | 647 | dst_port : 7252, | 648 | coap_msg : bstr(PH_REQ.CoAP) | 649 | }, | 650 | notif_num : 10, | 651 | res : bstr("1234"), | 652 | res_ct : 0 | 653 | } | 654 | | 655 C_2 ------------------ [ Unicast ] --------------------> S /r 656 | GET | 657 | Token: 0x01 | 658 | Observe: 0 (Register) | 659 | | 660 | (S increments the observer counter | 661 | for the group observation of /r .) | 662 | | 663 C_2 <--------------------- [ Unicast ] ----------------- S 664 | 5.03 | 665 | Token: 0x01 | 666 | Payload: { ph_req : { | 667 | src_addr : bstr(M_ADDR), | 668 | src_port : 65500, | 669 | dst_addr : bstr(SERVER_ADDR), | 670 | dst_port : 7252, | 671 | coap_msg : bstr(PH_REQ.CoAP) | 672 | }, | 673 | notif_num : 10, | 674 | res : bstr("1234"), | 675 | res_ct : 0 | 676 | } | 677 | | 678 | (The value of the resource /r changes to "5678".) | 679 | | 680 C_1 | 681 + <-------------------- [ Multicast ] ---------------- S 682 C_2 (Destination address: M_ADDR) | 683 | 2.05 | 684 | Token: 0xff | 685 | Observe: 11 | 686 | Payload: "5678" | 687 | | 689 5. Protection of Multicast Notifications with Group OSCORE 691 A server can protect multicast notifications by using Group OSCORE 692 [I-D.ietf-core-oscore-groupcomm]. In such a case, both the server 693 and the clients interested in receiving multicast notifications from 694 that server have to be members of the same OSCORE group. 696 Clients MAY discover the OSCORE group to refer to by using the method 697 in [I-D.tiloca-core-oscore-discovery], based on the CoRE Resource 698 Directory (RD) [I-D.ietf-core-resource-directory]. Alternatively, 699 the server MAY communicate to the client what OSCORE group to join, 700 as described in Section 5.1. Furthermore, both the clients and the 701 server MAY join the OSCORE group by using the approach described in 702 [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework 703 for Authentication and Authorization in constrained environments 704 [I-D.ietf-ace-oauth-authz]. Further details on how to discover the 705 OSCORE group and join it are out of the scope of this specification. 707 Alternative security protocols than Group OSCORE, such as OSCORE 708 [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can be used to 709 protect other exchanges via unicast between the server and each 710 client, including the original client registration (see Section 3). 712 5.1. Signaling the OSCORE Group in the Informative Response 714 This section describes a mechanism for the server to communicate to 715 the client what OSCORE group to join in order to decrypt and verify 716 the multicast notifications protected with group OSCORE. The client 717 MAY use the information provided by the server to start the ACE 718 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 719 This mechanism is OPTIONAL to support for the client and server. 721 Additionally to what defined in Section 2, the CBOR map in the 722 informative response payload contains the following fields, whose 723 CBOR labels are defined in Section 7. 725 o 'join_uri', with value the URI for joining the OSCORE group at the 726 respective Group Manager, encoded as a CBOR text string. If the 727 procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used 728 for joining, this field specifically indicates the URI of the 729 group-membership resource at the Group Manager. 731 o 'sec_gp', with value the name of the OSCORE group, encoded as a 732 CBOR text string. 734 o Optionally, 'as_uri', with value the URI of the Authorization 735 Server associated to the Group Manager for the OSCORE group, 736 encoded as a CBOR text string. 738 o Optionally, 'cs_alg', with value the algorithm used to countersign 739 messages, encoded as a CBOR text string or integer. The value is 740 taken from the 'Value' column of the "COSE Algorithms" registry 741 defined in [RFC8152]. 743 o Optionally, 'cs_crv', with value the elliptic curve for the 744 algorithm used to countersign messages, encoded as a CBOR text 745 string or integer. The value is taken from the 'Value' column of 746 the "COSE Elliptic Curve" registry defined in [RFC8152]. 748 o Optionally, 'cs_kty', with value the key type of countersignature 749 keys used to countersign messages, encoded as a CBOR text string 750 or a integer. The value is taken from the 'Value' column of the 751 "COSE Key Types" registry defined in [RFC8152]. 753 o Optionally, 'cs_kenc', with value the encoding of the public keys, 754 encoded as a CBOR integer. The value is taken from the 755 'Confirmation Key' column of the "CWT Confirmation Method" 756 registry defined in [I-D.ietf-ace-cwt-proof-of-possession]. 757 Future specifications may define additional values for this 758 parameter. 760 o Optionally, 'alg', with value the AEAD algorithm, encoded as a 761 CBOR text string or integer. The value is taken from the 'Value' 762 column of the "COSE Algorithms" registry defined in [RFC8152]. 764 o Optionally, 'hkdf', with value the HKDF algorithm, encoded as a 765 CBOR text string or integer. The value is taken from the 'Value' 766 column of the "COSE Algorithms" registry defined in [RFC8152]. 768 The values of 'cs_alg', 'cs_crv', 'cs_kty' and 'cs_kenc' provide an 769 early knowledge of the format and encoding of public keys used in the 770 OSCORE group. Thus, the client does not need to ask the Group 771 Manager for this information as a preliminary step before the (ACE) 772 join process, or to perform a trial-and-error exchange with the Group 773 Manager upon joining the group. Hence, the client is able to provide 774 the Group Manager with its own public key in the correct expected 775 format and encoding, at the very first step of the (ACE) join 776 process. 778 The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge 779 of the algorithms used in the OSCORE group. Thus, the client is able 780 to decide whether to actually proceed with the (ACE) join process, 781 depending on its support for the indicated algorithms. 783 As mentioned above, since this mechanism is OPTIONAL, all the fields 784 are OPTIONAL in the informative response. However, the 'join_uri' 785 and 'sec_gp' fields MUST be present if the mechanism is implemented 786 and used. If any of the fields are present without the 'join_uri' 787 and 'sec_gp' fields present, the client MUST ignore these fields, 788 since they would not be sufficient to start the (ACE) join procedure. 789 When this happens, the client MAY try sending a new registration 790 request to the server (see Section 3.1). Otherwise, the client 791 SHOULD explicitly withdraw from the group observation. 793 5.2. Server-Side Requirements 795 When using Group OSCORE to protect multicast notifications, the 796 server performs the operations described in Section 2, with the 797 following differences. 799 5.2.1. Registration 801 The phantom registration request MUST be secured, by using Group 802 OSCORE. To this end, the server protects the phantom registration 803 request as if it was the actual sender, i.e. by using its own Sender 804 Context. As a consequence, the server consumes the current value of 805 its own Sender Sequence Number SN in the OSCORE group, and hence 806 updates it to SN* = (SN + 1). Consistently, the OSCORE option in the 807 phantom registration request includes: 809 o As 'kid', the Sender ID of the server in the OSCORE group. 811 o As 'piv', the previously consumed sender sequence number value SN 812 of the server in the OSCORE group, i.e. (SN* - 1). 814 5.2.2. Informative Response 816 The 'notif_num' parameter of the informative response defined in 817 Section 2 is set as follows. 819 o If only one multicast notification has been sent for the target 820 resource and it included a Partial IV in its OSCORE option, the 821 'notif_num' parameter takes the value of that Partial IV. 823 o If more than one multicast notification have been sent for the 824 target resource, the 'notif_num' parameter takes the value of the 825 Partial IV in the OSCORE option of the latest sent multicast 826 notification. 828 o In any other case, the 'notif_num' parameter takes the current 829 Sender Sequence Number of the server in the OSCORE group, from its 830 own Sender Context. 832 5.2.3. Notifications 834 Upon sending every multicast notification for the target resource, 835 the server protects it with Group OSCORE. In particular, the process 836 described in Section 7.3 of [I-D.ietf-core-oscore-groupcomm] applies, 837 with the following additions when building the two OSCORE 838 'external_aad' to encrypt and countersign the multicast notification 839 (see Sections 4.3.1 and 4.3.2 of [I-D.ietf-core-oscore-groupcomm]). 841 o The 'request_kid' is the 'kid' value in the OSCORE option of the 842 phantom registration request, i.e. the Sender ID of the server. 844 o The 'request_piv' is the 'piv' value in the OSCORE option of the 845 phantom registration request, i.e. the consumed sender sequence 846 number SN of the server. 848 Note that these same values are used to protect each and every 849 multicast notification sent for the target resource. 851 5.2.4. Cancellation 853 When cancelling a group observation (see Section 2.5), the phantom 854 cancellation request MUST be secured, by using Group OSCORE. 856 Like defined in Section 5.2.1 for the phantom registration request, 857 the server protects the phantom cancellation request by using its own 858 Sender Context and consuming its own current Sender Sequence number 859 in the OSCORE group, from its own Sender Context. The following, 860 corresponding multicast error response defined in Section 2.5 is also 861 protected with Group OSCORE, as per Section 7.3 of 862 [I-D.ietf-core-oscore-groupcomm]. 864 Note that, differently from the multicast notifications, this 865 multicast error response will be the only one securely paired with 866 the phantom cancellation request. 868 5.3. Client-Side Requirements 870 When using Group OSCORE to protect multicast notifications, the 871 client performs as described in Section 3, with the following 872 differences. 874 5.3.1. Informative Response 876 Upon receiving the informative response from the server, the client 877 retrieves the phantom registration request specified in the 878 'coap_msg' field of the 'ph_req' parameter. 880 Then, the client decrypts and verifies the phantom registration 881 request as defined in Section 7.2 of 882 [I-D.ietf-core-oscore-groupcomm], with the following differences. 884 o The client MUST NOT perform any replay check. That is, the client 885 skips step 3 in Section 8.2 of [RFC8613]. 887 o If decryption and verification of the phantom registration request 888 succeed: 890 * The client MUST NOT update the Replay Window in the Recipient 891 Context associated to the server. That is, the client skips 892 the second bullet of step 6 in Section 8.2 of [RFC8613]. 894 * The client MUST NOT take any further process as normally 895 expected according to [RFC7252]. That is, the client skips 896 step 8 in Section 8.2 of [RFC8613]. In particular, the client 897 MUST NOT deliver the phantom registration request to the 898 application, and MUST NOT take any action in the Token space of 899 its own unicast endpoint, where the informative response has 900 been received. 902 * The client stores the values of the 'kid' and 'piv' fields from 903 the OSCORE option of the phantom registration request. 905 5.3.2. Notifications 907 After having successfully processed the informative response as 908 defined in Section 5.3.1, the client will decrypt and verify every 909 multicast notification for the target resource as defined in 910 Section 7.4 of [I-D.ietf-core-oscore-groupcomm], with the following 911 difference. 913 The client MUST set the two 'external_aad' defined in Sections 4.3.1 914 and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The 915 particular way to achieve this is implementation specific. 917 o 'request_kid' takes the value of the 'kid' field from the OSCORE 918 option of the phantom registration request (see Section 5.3.1). 920 o 'request_piv' takes the value of the 'piv' field from the OSCORE 921 option of the phantom registration request (see Section 5.3.1). 923 Note that these same values are used to decrypt and verify each and 924 every multicast notification received for the target resource. 926 The replay protection and checking of multicast notifications is 927 performed as specified in Section 4.1.3.5.2 of [RFC8613], with the 928 following addition. When the client receives its first multicast 929 notification for the target resource and a Partial IV is included in 930 the OSCORE option, the client MUST treat the notification as fresh 931 only if the value of that Partial IV is strictly greater than the 932 stored value of the 'notif_num' parameter from the informative 933 response (see Section 2.2). 935 6. Example with Group OSCORE 937 The following example refers to two clients C_1 and C_2 that register 938 to observe a resource /r at a Server S with address SERVER_ADDR. 939 Before the following exchanges occur, no clients are observing the 940 resource /r , which has value "1234". 942 In the informative responses, 'bstr(X)' denotes a byte string with 943 value the byte serialization of X. Also, the notation Y.CoAP denotes 944 the CoAP-layer part of a message Y, i.e. the part of Y that becomes 945 payload for the transport layer underlying CoAP, such as UDP. 947 The server S sends multicast notifications to the IP multicast 948 address M_ADDR , and starts the group observation upon receiving a 949 registration request from a first client that wishes to start a 950 traditional observation on the resource /r. 952 Pairwise communication over unicast are protected with OSCORE, while 953 S protects multicast notifications with Group OSCORE. Specifically: 955 o C_1 and S have a pairwise OSCORE Security Context. In particular, 956 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sequence Number. 957 Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Sequence 958 Number. 960 o C_2 and S have a pairwise OSCORE Security Context. In particular, 961 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sequence Number. 962 Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Sequence 963 Number. 965 o S is a member of the OSCORE group with name "myGroup", and 966 'kid_context' = "feedca57ab2e" as Group ID. In the OSCORE group, 967 S has 'kid' = 5 as Sender ID, and SN_5 = 501 as Sequence Number. 969 C_1 ------------- [ Unicast w/ OSCORE ] ----------------> S /r 970 | GET | 971 | Token: 0x4a | 972 | Observe: 0 (Register) | 973 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 974 | | 975 | (S allocates the available Token value 0xff .) | 976 | | 977 | (S sends to itself a phantom observation request PH_REQ | 978 | as coming from the IP multicast address M_ADDR .) | 979 | --------------------------------------------------- | 980 | / | 981 | \------------------------------------------------------> | /r 982 | GET | 983 | Token: 0xff | 984 | Observe: 0 (Register) | 985 | OSCORE: {kid: 5 ; piv: 501 ; ...} | 986 | | 987 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 988 | | 989 | (S creates a group observation of /r .) | 990 | | 991 | (S increments the observer counter | 992 | for the group observation of /r .) | 993 | | 994 | | 995 C_1 <---------------- [ Unicast w/ OSCORE ] -------------- S 996 | 5.03 | 997 | Token: 0x4a | 998 | OSCORE: {piv: 301; ...} | 999 | Payload: { ph_req : { | 1000 | src_addr : bstr(M_ADDR), | 1001 | src_port : 65500, | 1002 | dst_addr : bstr(SERVER_ADDR), | 1003 | dst_port : 7252, | 1004 | coap_msg : bstr(PH_REQ.CoAP) | 1005 | }, | 1006 | notif_num : 10, | 1007 | res : bstr("1234"), | 1008 | res_ct : 0, | 1009 | join_uri : "coap://myGM/group-oscore/myGroup", | 1010 | sec_gp : "myGroup" | 1011 | } | 1012 | | 1013 | | 1014 C_2 ------------- [ Unicast w/ OSCORE ] ----------------> S /r 1015 | GET | 1016 | Token: 0x01 | 1017 | Observe: 0 (Register) | 1018 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 1019 | | 1020 | (S increments the observer counter | 1021 | for the group observation of /r .) | 1022 | | 1023 C_2 <---------------- [ Unicast w/ OSCORE ] -------------- S 1024 | 5.03 | 1025 | Token: 0x01 | 1026 | OSCORE: {piv: 401; ...} | 1027 | Payload: { ph_req : { | 1028 | src_addr : bstr(M_ADDR), | 1029 | src_port : 65500, | 1030 | dst_addr : bstr(SERVER_ADDR), | 1031 | dst_port : 7252, | 1032 | coap_msg : bstr(PH_REQ.CoAP) | 1033 | }, | 1034 | notif_num : 10, | 1035 | res : bstr("1234"), | 1036 | res_ct : 0, | 1037 | join_uri : "coap://myGM/group-oscore/myGroup", | 1038 | sec_gp : "myGroup" | 1039 | } | 1040 | | 1041 | | 1042 | (The value of the resource /r changes to "5678".) | 1043 | | 1044 C_1 | 1045 + <------------ [ Multicast w/ Group OSCORE ] ---------- S 1046 C_2 (Destination address: M_ADDR) | 1047 | 2.05 | 1048 | Token: 0xff | 1049 | Observe: 11 | 1050 | OSCORE: {kid: 5; piv: 502 ; ...} | 1051 | Payload: "5678" | 1052 | | 1054 The two external_aad used to encrypt and countersign the multicast 1055 notification above have 'req_kid' = 5 and 'req_iv' = 501. These are 1056 indicated in the 'kid' and 'iv' field of the OSCORE option of the 1057 phantom observation request, which is included in the 'ph_req' 1058 parameter of the unicast informative response to the two clients. 1059 Thus, the two clients can build the two same external_aad for 1060 decrypting and verifying this multicast notification and the 1061 following ones. 1063 7. Informative Response Parameters 1065 This specification defines a number of fields used in error messages 1066 as informative response defined in Section 2.2 of this specification. 1068 The table below summarizes them, and specifies the CBOR key to use 1069 instead of the full descriptive name. Note that the media type 1070 application/informative-response+cbor MUST be used when these fields 1071 are transported. 1073 +-----------+----------+-------------------+-------------+ 1074 | Name | CBOR Key | CBOR Type | Reference | 1075 +-----------+----------+-------------------+-------------+ 1076 | ph_req | TBD | map | Section 2.2 | 1077 | | | | | 1078 | notif_num | TBD | unsigned integer | Section 2.2 | 1079 | | | | | 1080 | res | TBD | byte string | Section 2.2 | 1081 | | | | | 1082 | res_ct | TBD | unsigned integer | Section 2.2 | 1083 | | | | | 1084 | join_uri | TBD | text string | Section 5.1 | 1085 | | | | | 1086 | sec_gp | TBD | text string | Section 5.1 | 1087 | | | | | 1088 | as_uri | TBD | text string | Section 5.1 | 1089 | | | | | 1090 | cs_alg | TBD | int / text string | Section 5.1 | 1091 | | | | | 1092 | cs_crv | TBD | int / text string | Section 5.1 | 1093 | | | | | 1094 | cs_kty | TBD | int / text string | Section 5.1 | 1095 | | | | | 1096 | cs_kenc | TBD | int | Section 5.1 | 1097 | | | | | 1098 | alg | TBD | int / text string | Section 5.1 | 1099 | | | | | 1100 | hkdf | TBD | int / text string | Section 5.1 | 1101 +-----------+----------+-------------------+-------------+ 1103 8. Phantom Request Parameters 1105 This specification defines a number of fields for the CBOR map 1106 'ph_req', specifying a phantom request within error messages as 1107 informative response defined in Section 2.2 of this specification. 1109 The table below summarizes them, and specifies the CBOR key to use 1110 instead of the full descriptive name. Note that the media type 1111 application/informative-response+cbor MUST be used when these fields 1112 are transported. 1114 +----------+----------+------------------+-------------+ 1115 | Name | CBOR Key | CBOR Type | Reference | 1116 +----------+----------+------------------+-------------+ 1117 | src_addr | TBD | byte string | Section 2.2 | 1118 | | | | | 1119 | src_port | TBD | unsigned integer | Section 2.2 | 1120 | | | | | 1121 | dst_addr | TBD | byte string | Section 2.2 | 1122 | | | | | 1123 | dst_port | TBD | unsigned integer | Section 2.2 | 1124 | | | | | 1125 | coap_msg | TBD | byte string | Section 2.2 | 1126 +----------+----------+------------------+-------------+ 1128 9. Security Considerations 1130 The same security considerations from [RFC7252][RFC7641][I-D.dijk-cor 1131 e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for 1132 this document. 1134 If multicast notifications are protected using Group OSCORE, the 1135 original registration requests and related unicast (notification) 1136 responses MUST also be secured, including and especially the 1137 informative responses from the server. This prevents on-path active 1138 adversaries from altering the conveyed IP multicast address and 1139 serialized phantom request. Thus, it ensures secure binding between 1140 every multicast notification for a same observed resource and the 1141 phantom request that started the group observation of that resource. 1143 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 1144 so ensuring that the secure binding above is enforced end-to-end 1145 between the server and each observing client. 1147 10. IANA Considerations 1149 This document has the following actions for IANA. 1151 10.1. Media Type Registrations 1153 This specification registers the media type 'application/informative- 1154 response+cbor' for error messages as informative response defined in 1155 Section 2.2 of this specification, when carrying parameters encoded 1156 in CBOR. This registration follows the procedures specified in 1157 [RFC6838]. 1159 o Type name: application 1161 o Subtype name: informative-response+cbor 1162 o Required parameters: none 1164 o Optional parameters: none 1166 o Encoding considerations: Must be encoded as a CBOR map containing 1167 the parameters defined in Section 2.2 of [this document]. 1169 o Security considerations: See Section 9 of [this document]. 1171 o Interoperability considerations: n/a 1173 o Published specification: [this document] 1175 o Applications that use this media type: The type is used by CoAP 1176 servers and clients that support error messages as informative 1177 response defined in Section 2.2 of [this document]. 1179 o Additional information: 1181 * Magic number(s): n/a 1183 * File extension(s): .informative-response 1185 * Macintosh file type code(s): n/a 1187 o Person & email address to contact for further information: 1188 iesg@ietf.org [1] 1190 o Intended usage: COMMON 1192 o Restrictions on usage: None 1194 o Author: Marco Tiloca marco.tiloca@ri.se [2] 1196 o Change controller: IESG 1198 o Provisional registration? (standards tree only): No 1200 10.2. CoAP Content-Formats Registry 1202 IANA is asked to add the following entry to the "CoAP Content- 1203 Formats" subregistry defined in Section 12.3 of [RFC7252], within the 1204 "Constrained RESTful Environments (CoRE) Parameters" registry. 1206 Media Type: application/informative-response+cbor 1208 Encoding: - 1209 ID: TBD 1211 Reference: [this document] 1213 10.3. Informative Response Parameters Registry 1215 This specification establishes the "Informative Response Parameters" 1216 IANA Registry. The Registry has been created to use the "Expert 1217 Review Required" registration procedure [RFC8126]. Expert review 1218 guidelines are provided in Section 10.6. 1220 The columns of this Registry are: 1222 o Name: This is a descriptive name that enables easier reference to 1223 the item. The name MUST be unique. It is not used in the 1224 encoding. 1226 o CBOR Key: This is the value used as CBOR key of the item. These 1227 values MUST be unique. The value can be a positive integer, a 1228 negative integer, or a string. 1230 o CBOR Type: This contains the CBOR type of the item, or a pointer 1231 to the registry that defines its type, when that depends on 1232 another item. 1234 o Reference: This contains a pointer to the public specification for 1235 the item. 1237 This Registry has been initially populated by the values in 1238 Section 7. The "Reference" column for all of these entries refers to 1239 sections of this document. 1241 10.4. Phantom Request Parameters Registry 1243 This specification establishes the "Phantom Request Parameters" IANA 1244 Registry. The Registry has been created to use the "Expert Review 1245 Required" registration procedure [RFC8126]. Expert review guidelines 1246 are provided in Section 10.6. 1248 The columns of this Registry are: 1250 o Name: This is a descriptive name that enables easier reference to 1251 the item. The name MUST be unique. It is not used in the 1252 encoding. 1254 o CBOR Key: This is the value used as CBOR key of the item. These 1255 values MUST be unique. The value can be a positive integer, a 1256 negative integer, or a string. 1258 o CBOR Type: This contains the CBOR type of the item, or a pointer 1259 to the registry that defines its type, when that depends on 1260 another item. 1262 o Reference: This contains a pointer to the public specification for 1263 the item. 1265 This Registry has been initially populated by the values in 1266 Section 8. The "Reference" column for all of these entries refers to 1267 sections of this document. 1269 10.5. CoAP Option Numbers Registry 1271 IANA is asked to enter the following option numbers to the "CoAP 1272 Option Numbers" registry defined in [RFC7252] within the "CoRE 1273 Parameters" registry. 1275 +--------+--------------------------------------+-------------------+ 1276 | Number | Name | Reference | 1277 +--------+--------------------------------------+-------------------+ 1278 | TBD | Multicast-Response-Feedback-Divider | [[this document]] | 1279 +--------+--------------------------------------+-------------------+ 1281 10.6. Expert Review Instructions 1283 The IANA Registries established in this document are defined as 1284 expert review. This section gives some general guidelines for what 1285 the experts should be looking for, but they are being designated as 1286 experts for a reason so they should be given substantial latitude. 1288 Expert reviewers should take into consideration the following points: 1290 o Point squatting should be discouraged. Reviewers are encouraged 1291 to get sufficient information for registration requests to ensure 1292 that the usage is not going to duplicate one that is already 1293 registered and that the point is likely to be used in deployments. 1294 The zones tagged as private use are intended for testing purposes 1295 and closed environments, code points in other ranges should not be 1296 assigned for testing. 1298 o Specifications are required for the standards track range of point 1299 assignment. Specifications should exist for specification 1300 required ranges, but early assignment before a specification is 1301 available is considered to be permissible. Specifications are 1302 needed for the first-come, first-serve range if they are expected 1303 to be used outside of closed environments in an interoperable way. 1304 When specifications are not provided, the description provided 1305 needs to have sufficient information to identify what the point is 1306 being used for. 1308 o Experts should take into account the expected usage of fields when 1309 approving point assignment. The fact that there is a range for 1310 standards track documents does not mean that a standards track 1311 document cannot have points assigned outside of that range. The 1312 length of the encoded value should be weighed against how many 1313 code points of that length are left, the size of device it will be 1314 used on, and the number of code points left that encode to that 1315 size. 1317 11. References 1319 11.1. Normative References 1321 [I-D.dijk-core-groupcomm-bis] 1322 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1323 for the Constrained Application Protocol (CoAP)", draft- 1324 dijk-core-groupcomm-bis-03 (work in progress), March 1325 2020. 1327 [I-D.ietf-core-oscore-groupcomm] 1328 Tiloca, M., Selander, G., Palombini, F., and J. Park, 1329 "Group OSCORE - Secure Group Communication for CoAP", 1330 draft-ietf-core-oscore-groupcomm-07 (work in progress), 1331 November 2020. 1333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1334 Requirement Levels", BCP 14, RFC 2119, 1335 DOI 10.17487/RFC2119, March 1997, 1336 . 1338 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1339 "Transmission of IPv6 Packets over IEEE 802.15.4 1340 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1341 . 1343 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1344 for Application Designers", RFC 5405, 1345 DOI 10.17487/RFC5405, November 2008, 1346 . 1348 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1349 Specifications and Registration Procedures", BCP 13, 1350 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1351 . 1353 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1354 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1355 October 2013, . 1357 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1358 Application Protocol (CoAP)", RFC 7252, 1359 DOI 10.17487/RFC7252, June 2014, 1360 . 1362 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1363 Application Protocol (CoAP)", RFC 7641, 1364 DOI 10.17487/RFC7641, September 2015, 1365 . 1367 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1368 Bose, "Constrained Application Protocol (CoAP) Option for 1369 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1370 August 2016, . 1372 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1373 Writing an IANA Considerations Section in RFCs", BCP 26, 1374 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1375 . 1377 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1378 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1379 May 2017, . 1381 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1382 "Object Security for Constrained RESTful Environments 1383 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1384 . 1386 11.2. Informative References 1388 [I-D.ietf-ace-cwt-proof-of-possession] 1389 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1390 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1391 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1392 possession-11 (work in progress), October 2019. 1394 [I-D.ietf-ace-key-groupcomm-oscore] 1395 Tiloca, M., Park, J., and F. Palombini, "Key Management 1396 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1397 oscore-05 (work in progress), March 2020. 1399 [I-D.ietf-ace-oauth-authz] 1400 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1401 H. Tschofenig, "Authentication and Authorization for 1402 Constrained Environments (ACE) using the OAuth 2.0 1403 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-33 1404 (work in progress), February 2020. 1406 [I-D.ietf-core-coap-pubsub] 1407 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1408 Subscribe Broker for the Constrained Application Protocol 1409 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 1410 progress), September 2019. 1412 [I-D.ietf-core-resource-directory] 1413 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1414 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1415 resource-directory-23 (work in progress), July 2019. 1417 [I-D.ietf-tls-dtls13] 1418 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1419 Datagram Transport Layer Security (DTLS) Protocol Version 1420 1.3", draft-ietf-tls-dtls13-37 (work in progress), 1421 March 2020. 1423 [I-D.tiloca-core-oscore-discovery] 1424 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1425 Groups with the CoRE Resource Directory", draft-tiloca- 1426 core-oscore-discovery-05 (work in progress), March 1427 2020. 1429 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1430 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1431 January 2012, . 1433 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1434 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1435 . 1437 11.3. URIs 1439 [1] mailto:iesg@ietf.org 1441 [2] mailto:marco.tiloca@ri.se 1443 Appendix A. Different Sources for Phantom Requests 1445 While the clients usually receive the phantom request and related 1446 information through an Informative Response, the same data can be 1447 made available through different services, such as the following 1448 ones. 1450 A.1. PubSub 1452 In a pubsub case ([I-D.ietf-core-coap-pubsub]), a phantom request can 1453 be discovered, along with topic metadata. For instance, a discovery 1454 step can make available the following metadata. 1456 This examples assumes a CoRAL namespace that contains properties 1457 analogous to those in the content-format application/informative- 1458 response+cbor. 1460 Request: 1462 GET 1463 Accept: CoRAL 1465 Response: 1467 2.05 Content 1468 Content-Format: CoRAL 1470 rdf:type 1471 topic { 1472 dst_addr h"ff35003020010db8..1234" 1473 src_port 5683 1474 dst_addr h"20010db80100..0001" 1475 dst_port 5683 1476 coap_msg h"120100006464b431323334" 1477 } 1479 With this information from the topic discovery step, the client can 1480 already set up its multicast address and start receiving multicast 1481 notifications. 1483 In heavily asymmetric networks like municipal notification services, 1484 discovery and notifications do not necessarily need to use the same 1485 network link. For example, a departure monitor could use its (costly 1486 and usually-off) cellular uplink to discover the topics it needs to 1487 update its display to, and then listen on a LoRA-WAN interface for 1488 receiving the actual multicast notifications. 1490 A.2. Sender Introspection 1492 For network debugging purposes, it can be useful to query a server 1493 that sends multicast messages for phantom requests. 1495 Such an interface is left for other documents to specify on demand, 1496 but could look like this: 1498 Request: 1500 GET 1502 Response: 1504 2.05 Content 1505 Content-Format: application/informative-response+cbor 1507 {'ph_req': { 1508 'dst_addr': h"ff35003020010db8..1234" 1509 'src_port': 5683 1510 'dst_addr': h"20010db80100..0001" 1511 'dst_port': 5683 1512 'coap_msg': h"120100006464b431323334" 1513 }} 1515 For example, a network sniffer could offer sending such a request 1516 when unknown multicast notifications are seen on a network. 1517 Consequently, it can associate those notifications with a URI, or 1518 decrypt them, if member of the correct OSCORE group. 1520 Acknowledgments 1522 The authors sincerely thank Carsten Bormann, Klaus Hartke, John 1523 Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander for their 1524 comments and feedback. 1526 The work on this document has been partly supported by VINNOVA and 1527 the Celtic-Next project CRITISEC. 1529 Authors' Addresses 1531 Marco Tiloca 1532 RISE AB 1533 Isafjordsgatan 22 1534 Kista SE-16440 Stockholm 1535 Sweden 1537 Email: marco.tiloca@ri.se 1538 Rikard Hoeglund 1539 RISE AB 1540 Isafjordsgatan 22 1541 Kista SE-16440 Stockholm 1542 Sweden 1544 Email: rikard.hoglund@ri.se 1546 Christian Amsuess 1547 Hollandstr. 12/4 1548 Vienna 1020 1549 Austria 1551 Email: christian@amsuess.com 1553 Francesca Palombini 1554 Ericsson AB 1555 Torshamnsgatan 23 1556 Kista SE-16440 Stockholm 1557 Sweden 1559 Email: francesca.palombini@ericsson.com