Observe Notifications as CoAP Multicast Responses

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Readers are expected to be familiar with terms and concepts described in CoAP [RFC7252], group communication for CoAP [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949], OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm].¶

This document additionally defines the following terminology.¶

• Traditional observation. A resource observation associated with a single observer client, as defined in [RFC7641].¶
• Group observation. A resource observation associated with a group of clients. The server sends notifications for the group-observed resource over IP multicast to all the observer clients.¶
• Phantom request. The CoAP request message that the server would have received to start a group observation on one of its resources. A phantom request is generated inside the server and does not hit the wire.¶
• Informative response. A CoAP response message that the server sends to a given client via unicast, providing the client with information on a group observation.¶

4.1. Request

Assuming it is reachable at the address SRV_ADDR and port number SRV_PORT, the server starts a group observation on one of its resources as defined below. The server intends to send multicast notifications for the target resource to the multicast IP address GRP_ADDR and port number GRP_PORT.¶

1. The server builds a phantom observation request, i.e., a GET request with an Observe Option set to 0 (register).¶

2. The server selects an available value T, from the Token space of a CoAP endpoint used for messages having:¶

   • As source address and port number, the IP multicast address GRP_ADDR and port number GRP_PORT.¶
   • As destination address and port number, the server address SRV_ADDR and port number SRV_PORT, intended for accessing the target resource.¶

   This Token space is under exclusive control of the server.¶

3. The server processes the phantom observation request above, without transmitting it on the wire. The request is addressed to the resource for which the server wants to start the group observation, as if sent by the group of observers, i.e., with GRP_ADDR as source address and GRP_PORT as source port.¶
4. Upon processing the self-generated phantom registration request, the server interprets it as an observe registration received from the group of potential observer clients. In particular, from then on, the server MUST use T as its own local Token value associated with that observation, with respect to the (previous hop towards the) clients.¶
5. The server does not immediately respond to the phantom observation request with a multicast notification sent on the wire. The server stores the phantom observation request as is, throughout the lifetime of the group observation.¶
6. The server builds a CoAP response message INIT_NOTIF as initial multicast notification for the target resource, in response to the phantom observation request. This message is formatted as other multicast notifications (see Section 4.3) and MUST include the current representation of the target resource as payload. The server stores the message INIT_NOTIF and does not transmit it. The server considers this message as the latest multicast notification for the target resource, until it transmits a new multicast notification for that resource as a CoAP message on the wire. After that, the server deletes the message INIT_NOTIF.¶

4.2. Informative Response

After having started a group observation on a target resource, the server proceeds as follows.¶

For each traditional observation ongoing on the target resource, the server MAY cancel that observation. Then, the server considers the corresponding clients as now taking part in the group observation, for which it increases the corresponding observer counter accordingly.¶

The server sends to each of such clients an informative response message, encoded as a unicast response with response code 5.03 (Service Unavailable). As per [RFC7641], such a response does not include an Observe Option. The response MUST be Confirmable and MUST NOT encode link-local addresses.¶

The Content-Format of the informative response is set to application/informative-response+cbor, defined in Section 16.2. The payload of the informative response is a CBOR map including the following parameters, whose CBOR labels are defined in Section 13.¶

• 'tp_info', with value a CBOR array. This includes the transport-specific information required to correctly receive multicast notifications bound to the phantom observation request. Typically, this comprises the Token value associated with the group observation, as well as the source and destination addressing information of the related multicast notifications. The CBOR array is formatted as defined in Section 4.2.1. This parameter MUST be included.¶

• 'ph_req', with value the byte serialization of the transport-independent information of the phantom observation request (see Section 4.1), encoded as a CBOR byte string. The value of the CBOR byte string is formatted as defined in Section 4.2.2.¶

  This parameter MAY be omitted, in case the phantom request is, in terms of transport-independent information, identical to the registration request from the client. Otherwise, this parameter MUST be included.¶

  Note that the registration request from the client may indeed differ from the phantom observation request in terms of transport-independent information, but still be acceptable for the server to register the client as taking part in the group observation.¶

• 'last_notif', with value the byte serialization of the transport-independent information of the latest multicast notification for the target resource, encoded as a CBOR byte string. The value of the CBOR byte string is formatted as defined in Section 4.2.2. This parameter MAY be included.¶

• 'next_not_before', with value the amount of seconds that will minimally elapse before the server sends the next multicast notification for the group observation of the target resource, encoded as a CBOR unsigned integer. This parameter MAY be included.¶

  This information can help a new client to align itself with the server's timeline, especially in scenarios where multicast notifications are regularly sent. Also, it can help synchronizing different clients when orchestrating a content distribution through multicast notifications.¶

The CDDL notation [RFC8610] provided below describes the payload of the informative response.¶

informative_response_payload = {
   0 => array, ; 'tp_info', i.e., transport-specific information
 ? 1 => bstr,  ; 'ph_req' (transport-independent information)
 ? 2 => bstr   ; 'last_notif' (transport-independent information)
 ? 3 => uint   ; 'next_not_before'
}

Upon receiving a registration request to observe the target resource, the server does not create a corresponding individual observation for the requesting client. Instead, the server considers that client as now taking part in the group observation of the target resource, of which it increments the observer counter by 1. Then, the server replies to the client with the same informative response message defined above, which MUST be Confirmable.¶

Note that this also applies when, with no ongoing traditional observations on the target resource, the server receives a registration request from a first client and decides to start a group observation on the target resource.¶

tp_info = [
    srv_addr  ; Addressing information of the server
  ? req_info  ; Request data extension
]

srv_addr = (
    tp_id : int,  ; Identifier of the used transport protocol
  + elements      ; Number, format, and encoding
                  ; based on the value of 'tp_id'
)

req_info = (
  + elements  ; Number, format, and encoding based on
              ; the value of 'tp_id' in 'srv_addr'
)

tp_info = [
    tp_id    : 1,             ; UDP as transport protocol
    srv_host : #6.260(bstr),  ; Src. address of multicast notifications
    srv_port : uint,          ; Src. port of multicast notifications
    token    : bstr,          ; Token of the phantom request and
                              ; associated multicast notifications
    cli_host : #6.260(bstr),  ; Dst. address of multicast notifications
  ? cli_port : uint           ; Dst. port of multicast notifications
]

4.3. Notifications

Upon a change in the status of the target resource under group observation, the server sends a multicast notification, intended to all the clients taking part in the group observation of that resource. In particular, each of such multicast notifications is formatted as follows.¶

• It MUST be Non-confirmable.¶
• It MUST include an Observe Option, as per [RFC7641].¶

• It MUST have the same Token value T of the phantom registration request that started the group observation. This Token value is specified in the 'token' element of 'req_info' under the 'tp_info' parameter, in the informative response sent to all the observer clients.¶

  That is, every multicast notification for a target resource is not bound to the observation requests from the different clients, but rather to the phantom registration request associated with the whole set of clients taking part in the group observation of that resource.¶

• It MUST be sent from the same IP address SRV_ADDR and port number SRV_PORT where: i) the original Observe registration requests are sent to by the clients; and ii) the corresponding informative responses are sent from by the server (see Section 4.2). These are indicated to the observer clients as value of the 'srv_host' and 'srv_port' elements of 'srv_addr' under the 'tp_info' parameter, in the informative response (see Section 4.2.1.1). That is, redirection MUST NOT be used.¶
• It MUST be sent to the IP multicast address GRP_ADDR and port number GRP_PORT. These are indicated to the observer clients as value of the 'cli_host' and 'cli_port' elements of 'req_info' under the 'tp_info' parameter, in the informative response (see Section 4.2.1.1).¶

For each target resource with an active group observation, the server MUST store the latest multicast notification.¶

4.4. Congestion Control

In order to not cause congestion, the server should conservatively control the sending of multicast notifications. In particular:¶

• The multicast notifications MUST be Non-confirmable.¶
• In constrained environments such as low-power, lossy networks (LLNs), the server should only support multicast notifications for resources that are small. Following related guidelines from Section 3.6 of [I-D.ietf-core-groupcomm-bis], this can consist, for example, in having the payload of multicast notifications as limited to approximately 5% of the IP Maximum Transmit Unit (MTU) size, so that it fits into a single link-layer frame in case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (see Section 4 of [RFC4944]) is used.¶
• The server SHOULD provide multicast notifications with the smallest possible IP multicast scope that fulfills the application needs. For example, following related guidelines from Section 3.6 of [I-D.ietf-core-groupcomm-bis], site-local scope is always preferred over global scope IP multicast, if this fulfills the application needs. Similarly, realm-local scope is always preferred over site-local scope, if this fulfills the application needs. Ultimately, it is up to the server administrator to explicitly configure the most appropriate IP multicast scope.¶
• Following related guidelines from Section 4.5.1 of [RFC7641], the server SHOULD NOT send more than one multicast notification every 3 seconds, and SHOULD use an even less aggressive rate when possible (see also Section 3.1.2 of [RFC8085]). The transmission rate of multicast notifications should also take into account the avoidance of a possible "broadcast storm" problem [MOBICOM99]. This prevents a following, considerable increase of the channel load, whose origin would be likely attributed to a router rather than the server.¶

4.5. Cancellation

At any point in time, the server may want to cancel a group observation of a target resource. For instance, the server may realize that no clients or not enough clients are interested in taking part in the group observation anymore. A possible approach that the server can use to assess this is defined in Section 8.¶

In order to cancel the group observation, the server sends a multicast response with response code 5.03 (Service Unavailable), signaling that the group observation has been terminated. The response has the same Token value T of the phantom registration request, it has no payload, and it does not include an Observe Option.¶

The server sends the response to the same multicast IP address GRP_ADDR and port number GRP_PORT used to send the multicast notifications related to the target resource. Finally, the server releases the resources allocated for the group observation, and especially frees up the Token value T used at its CoAP endpoint.¶

5.1. Request

A client sends an observation request to the server as described in [RFC7641], i.e., a GET request with an Observe Option set to 0 (register). The request MUST NOT encode link-local addresses. If the server is not configured to accept registrations on that target resource specifically for a group observation, this would still result in a positive notification response to the client as described in [RFC7641], in case the server is able and willing to add the client to the list of observers.¶

In a particular setup, the information typically specified in the 'tp_info' parameter of the informative response (see Section 4.2) can be pre-configured on the server and the clients. For example, the destination multicast address and port number where to send multicast notifications for a group observation, as well as the associated Token value to use, can be set aside for particular tasks (e.g., enforcing observations of a specific resource). Alternative mechanisms can rely on using some bytes from the hash of the observation request as the last bytes of the multicast address or as part of the Token value.¶

In such a particular setup, the client may also have an early knowledge of the phantom request, i.e., it will be possible for the server to safely omit the parameter 'ph_req' from the informative response to the observation request (see Section 4.2). In this case, the client can include a No-Response Option [RFC7967] with value 16 in its Observe registration request, which results in the server suppressing the informative response. As a consequence, the observation request only informs the server that there is one additional client interested to take part in the group observation.¶

While the considered client is able to simply set up its multicast address and start receiving multicast notifications for the group observation, sending an observation request as above allows the server to increment the observer counter. This helps the server to assess the current number of clients interested in the group observation over time (e.g., by using the method in Section 8), which in turn can play a role in deciding to cancel the group observation.¶

5.2. Informative Response

Upon receiving the informative response defined in Section 4.2, the client proceeds as follows.¶

1. The client configures an observation of the target resource. To this end, it relies on a CoAP endpoint used for messages having:¶

   • As source address and port number, the server address SRV_ADDR and port number SRV_PORT intended for accessing the target resource. These are specified as value of the 'srv_host' and 'srv_port' elements of 'srv_addr' under the 'tp_info' parameter, in the informative response (see Section 4.2.1.1).¶
   • As destination address and port number, the IP multicast address GRP_ADDR and port number GRP_PORT. These are specified as value of the 'cli_host' and 'cli_port' elements of 'req_info' under the 'tp_info' parameter, in the informative response (see Section 4.2.1.1). If the 'cli_port' element is omitted in 'req_info', the client MUST assume the default port number 5683 as GRP_PORT.¶

2. The client rebuilds the phantom registration request as follows.¶

   • The client uses the Token value T, specified in the 'token' element of 'req_info' under the 'tp_info' parameter of the informative response.¶
   • If the 'ph_req' parameter is not present in the informative response, the client uses the transport-independent information from its original Observe registration request.¶
   • If the 'ph_req' parameter is present in the informative response, the client uses the transport-independent information specified in the parameter.¶
3. If the informative response includes the parameter 'ph_req', and the transport-independent information specified therein differs from the one in the original Observe registration request, then the client checks whether a response to the rebuilt phantom request can, if available in a cache entry, be used to satisfy the original observation request. If this is not the case, the client SHOULD explicitly withdraw from the group observation.¶
4. The client stores the phantom registration request, as associated with the observation of the target resource. In particular, the client MUST use the Token value T of this phantom registration request as its own local Token value associated with that group observation, with respect to the server. The particular way to achieve this is implementation specific.¶

5. If the informative response includes the parameter 'last_notif', the client rebuilds the latest multicast notification, by using:¶

   • The transport-independent information, specified in the 'last_notif' parameter of the informative response.¶
   • The Token value T, specified in the 'token' element of 'req_info' under the 'tp_info' parameter of the informative response.¶
6. If the informative response includes the parameter 'last_notif', the client processes the multicast notification rebuilt at step 5 as defined in Section 3.2 of [RFC7641]. In particular, the value of the Observe Option is used as initial baseline for notification reordering in this group observation.¶
7. If a traditional observation to the target resource is ongoing, the client MAY silently cancel it without notifying the server.¶

If any of the expected fields in the informative response are not present or malformed, the client MAY try sending a new registration request to the server (see Section 5.1). Otherwise, the client SHOULD explicitly withdraw from the group observation.¶

Appendix A describes possible alternative ways for clients to retrieve the phantom registration request and other information related to a group observation.¶

5.3. Notifications

After having successfully processed the informative response as defined in Section 5.2, the client will receive, accept, and process multicast notifications about the state of the target resource from the server, as responses to the phantom registration request and with Token value T.¶

The client relies on the value of the Observe Option for notification reordering, as defined in Section 3.4 of [RFC7641].¶

5.4. Cancellation

At a certain point in time, a client may become not interested in receiving further multicast notifications about a target resource. When this happens, the client can simply "forget" about being part of the group observation for that target resource, as per Section 3.6 of [RFC7641].¶

When, later on, the server sends the next multicast notification, the client will not recognize the Token value T in the message. Since the multicast notification is Non-confirmable, it is OPTIONAL for the client to reject the multicast notification with a Reset message, as defined in Section 3.5 of [RFC7641].¶

In case the server has canceled a group observation as defined in Section 4.5, the client simply forgets about the group observation and frees up the used Token value T for that endpoint, upon receiving the multicast error response defined in Section 4.5.¶

8.1. Multicast-Response-Feedback-Divider Option

In order to enable the rough counting of still active and interested clients, a new CoAP option is introduced, which SHOULD be supported by clients that listen to multicast responses.¶

The option is called Multicast-Response-Feedback-Divider. As summarized in Figure 6, the option is not Critical, not Safe-to-Forward, and integer valued. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable".¶

+-----+---+---+---+---+---------------------+--------+------+---------+
| No. | C | U | N | R | Name                | Format | Len. | Default |
+-----+---+---+---+---+---------------------+--------+------+---------+
| TBD |   | x | - |   | Multicast-Response- | uint   | 0-1  | (none)  |
|     |   |   |   |   | Feedback-Divider    |        |      |         |
+-----+---+---+---+---+---------------------+--------+------+---------+

      C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable

The Multicast-Response-Feedback-Divider Option is of class E for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].¶

8.2. Processing on the Client Side

Upon receiving a response with a Multicast-Response-Feedback-Divider Option, a client SHOULD acknowledge its interest in continuing receiving multicast notifications for the target resource, as described below.¶

The client picks an integer random number I, from 0 inclusive to the number Z = (2^Q) exclusive, where Q is the value specified in the option and "^" is the exponentiation operator. If I is different than 0, the client takes no further action. Otherwise, the client should wait a random fraction of the Leisure time (see Section 8.2 of [RFC7252]), and then registers a regular unicast observation on the same target resource.¶

To this end, the client essentially follows the steps that got it originally subscribed to group notifications for the target resource. In particular, the client sends an observation request to the server, i.e., a GET request with an Observe Option set to 0 (register). The request MUST be addressed to the same target resource, and MUST have the same destination IP address and port number used for the original registration request, regardless the source IP address and port number of the received multicast notification.¶

Since the Observe registration is only done for its side effect of showing as an attempted observation at the server, the client MUST send the unicast request in a non confirmable way, and with the maximum No-Response setting [RFC7967]. In the request, the client MUST include a Multicast-Response-Feedback-Divider Option, whose value MUST be empty (Option Length = 0). The client does not need to wait for responses, and can keep processing further notifications on the same Token.¶

The client MUST ignore the Multicast-Response-Feedback-Divider Option, if the multicast notification is retrieved from the 'last_notif' parameter of an informative response (see Section 4.2). A client includes the Multicast-Response-Feedback-Divider Option only in a re-registration request triggered by the server as described above, and MUST NOT include it in any other request.¶

Appendix B.1 and Appendix B.2 provide a description in pseudo-code of the operations above performed by the client.¶

Section 11 specifies how the approach presented in Section 4 and Section 5 works when a proxy is used between the origin clients and the origin server. That is, the clients register as observers at the proxy, which in turn registers as participant to the group observation at the server, receives the multicast notifications from the server, and forwards those to the clients. In such a case, the following applies.¶

• Since the Multicast-Response-Feedback-Divider Option is unsafe to forward, the proxy needs to recognize and understand the option in order to participate to the rough counting process.¶

  If the proxy receives a request that includes the Multicast-Response-Feedback-Divider Option but the proxy does not recognize and understand the option, then the proxy has to stop processing the request and send a 4.02 (Bad Option) response to the observer client (see Section 5.7.1 of [RFC7252]). This results in the client terminating its observation at the proxy, after which the client stops receiving notifications for the group observation.¶

  If the proxy receives a multicast notification that includes the Multicast-Response-Feedback-Divider Option but the proxy does not recognize and understand the option, then the proxy has to stop processing the received multicast notification and send a 5.02 (Bad Gateway) response to each of the observer clients (see Section 5.7.1 of [RFC7252]). This results in all the observer clients terminating their observation at the proxy, after which they stop receiving notifications for the group observation. Consequently, the proxy may decide to forget about its participation to the group observation at the server.¶

  This is not an issue if communications between the origin endpoints are protected end-to-end, i.e., both for the requests from the origin clients by using OSCORE or Group OSCORE, as well as for the multicast notifications from the origin server by using Group OSCORE (see Section 9 and Section 12). In fact, in such a case, the Multicast-Response-Feedback-Divider Option is protected end-to-end as well, and is thus hidden from the proxy.¶

  Therefore, if the server uses the rough counting process defined in this section but communications are not protected end-to-end between the origin enpoints, then it is practically required that the proxy recognizes and understands the Multicast-Response-Feedback-Divider Option. If that is not the case, then every execution of the rough counting process will effectively prevent the clients from receiving further notifications for the group observation, until they register again as observers at the proxy.¶

• The following applies when the proxy receives a multicast notification including the Multicast-Response-Feedback-Divider Option.¶

  • If the multicast notification is not protected end-to-end by using Group OSCORE (see Section 11), the Multicast-Response-Feedback-Divider Option is visible to the proxy. Then, the proxy proceeds like defined above for an origin client, i.e., by answering to the server on its own in case it picks a random number I equal to 0. When doing so, the proxy will be counted by the server as a single client.¶

    Instead, if the multicast notification is protected end-to-end by using Group OSCORE (see Section 9 and Section 12), then the Multicast-Response-Feedback-Divider Option is protected end-to-end as well, and is thus hidden from the proxy. As a consequence, the proxy forwards the notification to (the previous hop towards) any of the origin clients, each of which answers to the server if it picks a random number I equal to 0.¶

  • If the multicast notification is not protected end-to-end by using Group OSCORE, then the Multicast-Response-Feedback-Divider Option is visible to the proxy, which MUST remove the option before forwarding the notification to (the previous hop towards) any of the origin clients.¶

    The proxy would have to rely on separate means for asserting whether the origin clients are still interested in the observation, e.g., by regularly forwarding notifications to the clients as unicast, Confirmable response messages.¶

    When no interested origin clients remain, the proxy can simply forget about being part of the group observation for the target resource at the server, like an origin client would do (see Section 5.4).¶

8.3. Processing on the Server Side

In order to avoid needless use of network resources, a server SHOULD keep a rough, updated count of the number of clients taking part in the group observation of a target resource. To this end, the server updates the value COUNT of the associated observer counter (see Section 4), for instance by using the method described below.¶

9.1. Signaling the OSCORE Group in the Informative Response

This section describes a mechanism for the server to communicate to the client what OSCORE group to join in order to decrypt and verify the multicast notifications protected with Group OSCORE. The client MAY use the information provided by the server to start the ACE joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. This mechanism is OPTIONAL to support for the client and server.¶

Additionally to what is defined in Section 4, the CBOR map in the informative response payload contains the following fields, whose CBOR labels are defined in Section 13.¶

• 'join_uri', with value the URI for joining the OSCORE group at the respective Group Manager, encoded as a CBOR text string. If the procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used for joining, this field specifically indicates the URI of the group-membership resource at the Group Manager.¶
• 'sec_gp', with value the name of the OSCORE group, encoded as a CBOR text string.¶
• Optionally, 'as_uri', with value the URI of the Authorization Server associated with the Group Manager for the OSCORE group, encoded as a CBOR text string.¶
• Optionally, 'hkdf', with value the HKDF Algorithm used in the OSCORE group, encoded as a CBOR text string or integer. The value is taken from the 'Value' column of the "COSE Algorithms" registry [COSE.Algorithms].¶

• Optionally, 'cred_fmt', with value the format of the authentication credentials used in the OSCORE group, encoded as a CBOR integer. The value is taken from the 'Label' column of the "COSE Header Parameters" Registry [COSE.Header.Parameters]. Consistently with Section 2.4 of [I-D.ietf-core-oscore-groupcomm], acceptable values denote a format that MUST explicitly provide the comprehensive set of information related to the public key algorithm, including, e.g., the used elliptic curve (when applicable).¶

  At the time of writing this specification, acceptable formats of authentication credentials are CBOR Web Tokens (CWTs) and CWT Claim Sets (CCSs) [RFC8392], X.509 certificates [RFC5280] and C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. Further formats may be available in the future, and would be acceptable to use as long as they comply with the criteria defined above.¶

  [ As to CWTs and unprotected CWT claim sets, there is a pending registration requested by draft-ietf-lake-edhoc. ]¶

  [ As to C509 certificates, there is a pending registration requested by draft-ietf-cose-cbor-encoded-cert. ]¶

• Optionally, 'gp_enc_alg', with value the Group Encryption Algorithm used in the OSCORE group to encrypt messages protected with the group mode, encoded as a CBOR text string or integer. The value is taken from the 'Value' column of the "COSE Algorithms" registry [COSE.Algorithms].¶
• Optionally, 'sign_alg', with value the Signature Algorithm used to sign messages in the OSCORE group, encoded as a CBOR text string or integer. The value is taken from the 'Value' column of the "COSE Algorithms" registry [COSE.Algorithms].¶

• Optionally, 'sign_params', encoded as a CBOR array and including the following two elements:¶

  • 'sign_alg_capab': a CBOR array, with the same format and value of the COSE capabilities array for the algorithm indicated in 'sign_alg', as specified for that algorithm in the 'Capabilities' column of the "COSE Algorithms" Registry [COSE.Algorithms].¶
  • 'sign_key_type_capab': a CBOR array, with the same format and value of the COSE capabilities array for the COSE key type of the keys used with the algorithm indicated in 'sign_alg', as specified for that key type in the 'Capabilities' column of the "COSE Key Types" Registry [COSE.Key.Types].¶

The values of 'sign_alg', 'sign_params', and 'cred_fmt' provide an early knowledge of the format of authentication credentials as well as of the type of public keys used in the OSCORE group. Thus, the client does not need to ask the Group Manager for this information as a preliminary step before the (ACE) join process, or to perform a trial-and-error exchange with the Group Manager upon joining the group. Hence, the client is able to provide the Group Manager with its own authentication credential in the correct expected format and including a public key of the correct expected type, at the very first step of the (ACE) join process.¶

The values of 'hkdf', 'gp_enc_alg', and 'sign_alg' provide an early knowledge of the algorithms used in the OSCORE group. Thus, the client is able to decide whether to actually proceed with the (ACE) join process, depending on its support for the indicated algorithms.¶

As mentioned above, since this mechanism is OPTIONAL, all the fields are OPTIONAL in the informative response. However, the 'join_uri' and 'sec_gp' fields MUST be present if the mechanism is implemented and used. If any of the fields are present without the 'join_uri' and 'sec_gp' fields present, the client MUST ignore these fields, since they would not be sufficient to start the (ACE) join procedure. When this happens, the client MAY try sending a new registration request to the server (see Section 5.1). Otherwise, the client SHOULD explicitly withdraw from the group observation.¶

Appendix C describes a possible alternative approach, where the server self-manages the OSCORE group, and provides the observer clients with the necessary keying material in the informative response. The approach in Appendix C MUST NOT be used together with the mechanism defined in this section for indicating what OSCORE group to join.¶

9.2. Server-Side Requirements

When using Group OSCORE to protect multicast notifications, the server performs the operations described in Section 4, with the following differences.¶

9.3. Client-Side Requirements

When using Group OSCORE to protect multicast notifications, the client performs as described in Section 5, with the following differences.¶

12.1. Listen-To-Multicast-Responses Option

In order to allow the proxy to listen to the multicast notifications sent by the server, a new CoAP option is introduced. This option MUST be supported by clients interested to take part in group observations through intermediaries, and by proxies that collect multicast notifications and forward them back to the observer clients.¶

The option is called Listen-To-Multicast-Responses and is intended only for requests. As summarized in Figure 8, the option is critical and not Safe-to-Forward. Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable".¶

+-----+---+---+---+---+-------------------+--------+--------+---------+
| No. | C | U | N | R | Name              | Format | Len.   | Default |
+-----+---+---+---+---+-------------------+--------+--------+---------+
| TBD | x | x | - |   | Listen-To-        |  (*)   | 3-1024 | (none)  |
|     |   |   |   |   | Multicast-        |        |        |         |
|     |   |   |   |   | Responses         |        |        |         |
+-----+---+---+---+---+-------------------+--------+--------+---------+

      C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
      (*) See below.

The Listen-To-Multicast-Responses Option includes the serialization of a CBOR array. This specifies transport-specific message information required for listening to the multicast notifications of a group observation, and intended to the proxy adjacent to the origin server sending those notifications. In particular, the serialized CBOR array has the same format specified in Section 4.2.1 for the 'tp_info' parameter of the informative response (see Section 4.2).¶

The Listen-To-Multicast-Responses Option is of class U for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].¶

12.2. Message Processing

Compared to Section 11, the following additions apply when informative responses are protected end-to-end between the origin server and the clients.¶

After the origin server sends an informative response, each proxy simply forwards it back to the (previous hop towards the) origin client that has sent the observation request.¶

Once received the informative response, the origin client proceeds in a different way than in Section 9.3.1:¶

• The client performs all the additional decryption and verification steps of Section 9.3.1 on the phantom request specified in the 'ph_req' parameter and on the last notification specified in the 'last_notif' parameter (if present).¶

• The client builds a ticket request (see Appendix B of [I-D.amsuess-core-cachable-oscore]), as intended to reach the proxy adjacent to the origin server. The ticket request is formatted as follows.¶

  • The Token is chosen as the client sees fit. In fact, there is no reason for this Token to be the same as the phantom request's.¶
  • The outer Code field, the outer CoAP options, and the encrypted payload with AEAD tag (protecting the inner Code, the inner CoAP options, and the possible plain CoAP payload) concatenated with the signature are the same of the phantom request used for the group observation. That is, they are as specified in the 'ph_req' parameter of the received informative response.¶
  • An outer Observe Option is included and set to 0 (register). This will usually be set in the phantom request already.¶
  • The outer option Proxy-Uri or the outer options (Proxy-Scheme, Uri-Host, Uri-Port) are included, and set to the same values they had in the original registration request sent by the client.¶

  • The new option Listen-To-Multicast-Responses is included as an outer option. The value is set to the serialization of the CBOR array specified by the 'tp_info' parameter of the informative response.¶

    Note that, except for transport-specific information such as the Token and Message ID values, every different client participating to the same group observation (hence rebuilding the same phantom request) will build the same ticket request.¶

    Note also that, identically to the phantom request, the ticket request is still protected with Group OSCORE, i.e., it has the same OSCORE Option, encrypted payload, and signature.¶

Then, the client sends the ticket request to the next hop towards the origin server. Every proxy in the chain forwards the ticket request to the next hop towards the origin server, until the last proxy in the chain is reached. This last proxy, adjacent to the origin server, proceeds as follows.¶

• The proxy MUST NOT further forward the ticket request to the origin server.¶
• The proxy removes from the ticket request the Proxy-Uri Option or the (Proxy-Scheme, Uri-Host, Uri-Port) Options.¶
• The proxy removes the Listen-To-Multicast-Responses Option from the ticket request, and extracts the conveyed transport-specific information.¶
• The proxy rebuilds the phantom request associated with the group observation, by using the ticket request as directly providing the required transport-independent information. This includes the outer Code field, the outer CoAP options, and the encrypted payload with AEAD tag concatenated with the signature.¶
• The proxy configures an observation of the target resource at the origin server, acting as a client directly taking part in the group observation. To this end, the proxy uses the rebuilt phantom request and the transport-specific information retrieved from the Listen-To-Multicast-Responses Option. The particular way to achieve this is implementation specific.¶

After that, the proxy will listen to the IP multicast address and port number indicated in the Listen-To-Multicast-Responses Option, as 'cli_host' and 'cli_port' element of the serialized CBOR array, respectively. In particular, multicast notifications will match the phantom request stored at the proxy, based on the Token value specified in the 'token' element of the serialized CBOR array in the Listen-To-Multicast-Responses Option.¶

An example is provided in Appendix F.¶

15.1. Unprotected Communications

In case communications are not protected, the server might not be able to effectively authenticate a new client when it registers as an observer. Section 7 of [RFC7641] specifies how, in such a case, the server must strictly limit the number of notifications sent between receiving acknowledgements from the client, as confirming to be still interested in the observation; i.e., any notifications sent in Non-confirmable messages must be interspersed with confirmable messages.¶

This is not possible to achieve by the same means when using the communication model defined in this document, since multicast notifications are sent as Non-confirmable messages. Nonetheless, the server might obtain such acknowledgements by other means.¶

For instance, the method defined in Section 8 to perform the rough counting of still interested clients triggers (some of) them to explicitly send a new observation request to acknowledge their interest. Then, the server can decide to terminate the group observation altogether, in case not enough clients are estimated to be still active.¶

If the method defined in Section 8 is used, the server SHOULD NOT send more than a strict number of multicast notifications for a given group observation, without having first performed a new rough counting of active clients. Note that, when using the method defined in Section 8 with unprotected communications, an adversary can craft and inject multiple new observation requests including the Multicast-Response-Feedback-Divider Option, hence inducing the server to overestimate the number of still interested clients, and thus to inappropriately continue the group observation.¶

15.2. Protected Communications

If multicast notifications are protected using Group OSCORE as per Section 9, the following applies.¶

• The original registration requests and related unicast (notification) responses MUST also be secured, including and especially the informative responses from the server. This prevents on-path active adversaries from altering the conveyed IP multicast address and serialized phantom registration request. Thus, it ensures secure binding between every multicast notification for a same observed resource and the phantom registration request that started the group observation of that resource.¶
• A re-registration request, possibly including the Multicast-Response-Feedback-Divider Option to support the rough counting of clients (see Section 8), MUST also be secured.¶

To this end, clients and servers SHOULD use OSCORE or Group OSCORE, so ensuring that the secure binding above is enforced end-to-end between the server and each observing client.¶

15.3. Listen-To-Multicast-Responses Option

The CoAP option Listen-To-Multicast-Responses defined in Section 12.1 is of class U for OSCORE and Group OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].¶

This allows the proxy adjacent to the origin server to access the option value conveyed in a ticket request (see Section 12.2), and to retrieve from it the transport-specific information about a phantom request. By doing so, the proxy becomes able to configure an observation of the target resource and to receive multicast notifications matching to the phantom request.¶

Any proxy in the chain, as well as further possible intermediaries or on-path active adversaries, are thus able to remove the option or alter its content, before the ticket request reaches the proxy adjacent to the origin server.¶

Removing the option would result in the proxy adjacent to the origin server to not configure the group observation, if that has not happened yet. In such a case, the proxy would not receive the corresponding multicast notifications to be forwarded back to the clients.¶

Altering the option content would result in the proxy adjacent to the origin server to incorrectly configure a group observation (e.g., by indicating a wrong multicast IP address) hence preventing the correct reception of multicast notifications and their forwarding to the clients; or to configure bogus group observations that are currently not active on the origin server.¶

In order to prevent what is described above, the ticket requests conveying the Listen-To-Multicast-Responses Option can be additionally protected hop-by-hop. This can be achieved by the client protecting the ticket request sent to the proxy using OSCORE (see [I-D.ietf-core-oscore-capable-proxies]) and/or DTLS [RFC9147].¶

16.1. Media Type Registrations

This document registers the media type "application/informative-response+cbor" for error messages as informative response defined in Section 4.2, when carrying parameters encoded in CBOR. This registration follows the procedures specified in [RFC6838].¶

• Type name: application¶
• Subtype name: informative-response+cbor¶
• Required parameters: N/A¶
• Optional parameters: N/A¶
• Encoding considerations: Must be encoded as a CBOR map containing the parameters defined in Section 4.2 of [RFC-XXXX].¶
• Security considerations: See Section 15 of [RFC-XXXX].¶
• Interoperability considerations: N/A¶
• Published specification: [RFC-XXXX]¶
• Applications that use this media type: The type is used by CoAP servers and clients that support error messages as informative response defined in Section 4.2 of [RFC-XXXX].¶
• Fragment identifier considerations: N/A¶
• Additional information: N/A¶
• Person & email address to contact for further information: CoRE WG mailing list (core@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)¶
• Intended usage: COMMON¶
• Restrictions on usage: None¶
• Author/Change controller: IETF¶
• Provisional registration: No¶

16.2. CoAP Content-Formats Registry

IANA is asked to add the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

Content Type: application/informative-response+cbor¶

Content Coding: -¶

ID: TBD¶

Reference: [RFC-XXXX]¶

16.3. CoAP Option Numbers Registry

IANA is asked to enter the following option numbers to the "CoAP Option Numbers" registry within the "CoRE Parameters" registry group.¶

+--------+--------------------------------------+------------+
| Number |                 Name                 | Reference  |
+--------+--------------------------------------+------------+
|  TBD   |  Multicast-Response-Feedback-Divider | [RFC-XXXX] |
+--------+--------------------------------------+------------+
|  TBD   |  Listen-To-Multicast-Responses       | [RFC-XXXX] |
+--------+--------------------------------------+------------+

16.4. Informative Response Parameters Registry

This document establishes the "Informative Response Parameters" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 16.7.¶

The columns of this registry are:¶

• Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.¶
• CBOR Key: This is the value used as CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a string.¶
• CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.¶
• Reference: This contains a pointer to the public specification for the item.¶

This registry has been initially populated by the values in Section 13. The "Reference" column for all of these entries refers to sections of this document.¶

16.5. CoAP Transport Information Registry

This document establishes the "CoAP Transport Information" registry within the "CoRE Parameters" registry group. The registry has been created to use the "Expert Review" registration procedure [RFC8126]. Expert review guidelines are provided in Section 16.7. It should be noted that, in addition to the expert review, some portions of the Registry require a specification, potentially a Standards Track RFC, to be supplied as well.¶

The columns of this registry are:¶

• Transport Protocol: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.¶
• Description: Text giving an overview of the transport protocol referred by this item.¶
• Value: CBOR abbreviation for the transport protocol referred by this item. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535 are designated as "Specification Required". Integer values greater than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".¶
• Server Addr: List of elements providing addressing information of the server.¶
• Req Info: List of elements providing transport-specific information related to a pertinent CoAP request. Optional elements are prepended by '?'.¶
• Reference: This contains a pointer to the public specification for the item.¶

This registry has been initially populated by the values in Section 14. The "Reference" column for all of these entries refers to sections of this document.¶

16.6. Target Attributes Registry

IANA is asked to register the following entry in the "Target Attributes" registry within the "CoRE Parameters" registry group.¶

Attribute Name: gp-obs
Brief Description: Observable resource supporting group observation
Change Controller: IETF
Reference: Section 6 of [RFC-XXXX]

16.7. Expert Review Instructions

The IANA registries established in this document are defined as "Expert Review". This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.¶

Expert reviewers should take into consideration the following points:¶

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.¶
• Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.¶
• Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.¶

A.1. Topic Discovery in Publish-Subscribe Settings

In a Publish-Subscribe scenario [I-D.ietf-core-coap-pubsub], a group observation can be discovered along with topic metadata.¶

To this end, together with topic metadata, the server has to publish the same information associated with the group observation that would be conveyed in the informative response returned to observer clients (see Section 4.2).¶

This information especially includes the phantom observation request associated with the group observation, as well as the addressing information of the server and the addressing information where multicast notifications are sent to.¶

Figure 10 provides an example where a group observation is discovered. The example assumes a CoRAL namespace [I-D.ietf-core-coral], that contains properties analogous to those in the content-format application/informative-response+cbor.¶

Note that the information about the transport protocol used for the group observation is not expressed through a dedicated element equivalent to 'tp_id' of the informative response (see Section 4.2.1). Rather, it is expressed through the scheme component of the two URIs specified as 'tp_info_srv' and 'tp_info_cli', where the former specifies the addressing information of the server (like 'srv_host' and 'srv_port' in Section 4.2.1.1), while the latter specifies the addressing information where multicast notifications are sent to (like 'cli_host' and 'cli_port' in Section 4.2.1.1).¶

Request:

    GET </ps/topics?rt=oic.r.temperature>
    Accept: application/coral+cbor

Response:

    2.05 Content
    Content-Format: application/coral+cbor

    rdf:type [ = <http://example.org/pubsub/topic-list>,
           topic [ = </ps/topics/1234>,
               tp_info_srv <coap://[2001:db8::1]>,
               tp_info_token "7b"^^xsd::hexBinary,
               tp_info_cli <coap://[ff35:30:2001:db8::123]>,
               ph_req "0160.."^^xsd::hexBinary,
               last_notif "256105.."^^xsd::hexBinary,
           ]
    ]

With this information from the topic discovery step, the client can already set up its multicast address and start receiving multicast notifications for the group observation in question. Clients that are not directly able to listen to multicast notifications can instead rely on a proxy to do so on their behalf (see Section 11 and Section 12).¶

In heavily asymmetric networks like municipal notification services, discovery and notifications do not necessarily need to use the same network link. For example, a departure monitor could use its (costly and usually-off) cellular uplink to discover the topics it needs to update its display to, and then listen on a LoRA-WAN interface for receiving the actual multicast notifications.¶

A.2. Introspection at the Multicast Notification Sender

For network debugging purposes, it can be useful to query a server that sends multicast responses as matching a phantom registration request.¶

Such an interface is left for other documents to specify on demand. As an example, a possible interface can be as follows, and rely on the already known Token value of intercepted multicast notifications, associated with a phantom registration request.¶

Request:

GET </.well-known/core/mc-sender?token=6464>

Response:

2.05 Content
Content-Format: application/informative-response+cbor

{
  / tp_info /    0 : [1, h'7b', h'20010db80100/.../0001', 5683,
                      h'ff35003020010db8/.../1234', 5683],
  / ph_req /     1 : h'0160/.../',
  / last_notif / 2 : h'256105/.../'
}

For example, a network sniffer could offer sending such a request when unknown multicast notifications are seen in a network. Consequently, it can associate those notifications with a URI, or decrypt them, if member of the correct OSCORE group.¶

B.1. Client Side

input:  int Q, // Value of the MRFD option
        int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252,
                          // unless overridden

output: None


int RAND_MIN = 0;
int RAND_MAX = (2^Q) - 1;
int I = randomInteger(RAND_MIN, RAND_MAX);

if (I == 0) {
    float fraction = randomFloat(0, 1);

    Timer t = new Timer();
    t.setAndStart(fraction * LEISURE_TIME);
    while(!t.isExpired());

    Request req = new Request();
    // Initialize as NON and with maximum
    // No-Response settings, set options ...

    Option opt = new Option(OBSERVE);
    opt.set(0);
    req.setOption(opt);

    opt = new Option(MRFD);
    req.setOption(opt);

    req.send(SRV_ADDR, SRV_PORT);
}

B.2. Client Side - Optimized Version

input:  int Q, // Value of the MRFD option
        int LEISURE_TIME, // DEFAULT_LEISURE from RFC 7252,
                          // unless overridden

output: None


const unsigned int UINT_BIT = CHAR_BIT * sizeof(unsigned int);

if (respond_to(Q) == true) {
    float fraction = randomFloat(0, 1);

    Timer t = new Timer();
    t.setAndStart(fraction * LEISURE_TIME);
    while(!t.isExpired());

    Request req = new Request();
    // Initialize as NON and with maximum
    // No-Response settings, set options ...

    Option opt = new Option(OBSERVE);
    opt.set(0);
    req.setOption(opt);

    opt = new Option(MRFD);
    req.setOption(opt);

    req.send(SRV_ADDR, SRV_PORT);
}

bool respond_to(int Q) {
    while (Q >= UINT_BIT) {
        if (rand() != 0) return false;
        Q -= UINT_BIT;
    }
    unsigned int mask = ~((~0u) << Q);
    unsigned int masked = mask & rand();
    return masked == 0;
}

B.3. Server Side

input:  int COUNT, // Current observer counter
        int M, // Desired number of confirmations
        int MAX_CONFIRMATION_WAIT,
        Response notification, // Multicast notification to send

output: int NEW_COUNT // Updated observer counter


int D = 4; // Dampener value
int RETRY_NEXT_THRESHOLD = 4;
float CANCEL_THRESHOLD = 0.2;

int N = max(COUNT, 1);
int Q = max(ceil(log2(N / M)), 0);
Option opt = new Option(MRFD);
opt.set(Q);

notification.setOption(opt);
<Finalize the notification message>
notification.send(GRP_ADDR, GRP_PORT);

Timer t = new Timer();
t.setAndStart(MAX_CONFIRMATION_WAIT); // Time t1
while(!t.isExpired());

// Time t2

int R = <number of requests to the target resource
         between t1 and t2, with the MRFD option>;

int E = R * (2^Q);

// Determine after how many multicast notifications
// the next count update will be performed
if ((R == 0) || (max(E/N, N/E) > RETRY_NEXT_THRESHOLD)) {
    <Next count update with the next multicast notification>
}
else {
    <Next count update after 10 multicast notifications>
}

// Compute the new count estimate
int COUNT_PRIME = <current value of the observer counter>;
int NEW_COUNT = COUNT_PRIME + ((E - N) / D);

// Determine whether to cancel the group observation
if (NEW_COUNT < CANCEL_THRESHOLD) {
    <Cancel the group observation>;
    return 0;
}

return NEW_COUNT;

G.1. Assumptions and Walkthrough

The example provided in this appendix as reflected by the message exchange shown in Appendix G.2 assumes the following.¶

1. The OSCORE group supports deterministic requests. Thus, the server creates the phantom request as a deterministic request [I-D.amsuess-core-cachable-oscore], stores it locally as one of its issued phantom requests, and starts the group observation.¶
2. The server makes the phantom request available through other means, e.g., a pub-sub broker, together with the transport-specific information for listening to multicast notifications bound to the phantom request (see Appendix A).¶
3. Since the phantom request is a deterministic request, the server can more efficiently make it available in its smaller, plain version. The clients can obtain it from the particular alternative source and protect it as per Section 3 of [I-D.amsuess-core-cachable-oscore], thus all computing the same deterministic request to be used as phantom observation request.¶
4. If the client does not rely on a proxy between itself and the server, it simply sets the group observation and starts listening to multicast notifications. Building on point (2) above, the same would happen if the phantom request would not be specifically a deterministic request.¶
5. If the client relies on a proxy between itself and the server, it uses the phantom request as a ticket request (see Section 12). However, unlike the case considered in Section 12 when the ticket request is not deterministic, the client does not include a Listen-to-Multicast-Responses Option in the phantom request sent to the proxy.¶
6. Unlike for the case considered in Section 12, here the proxy does not know that the request is exactly a ticket request for subscribing to multicast notifications. Thus, the proxy simply forwards the ticket request to the server as it normally does for any request.¶
7. The server receives the ticket request, which is a deviation from the case where the ticket request is not deterministic and stops at the proxy (see Section 12). Then, the server can clearly understand what is happening. In fact, as the result of an early check, the server recognizes the phantom request among the stored ones. This happens through a byte-by-byte comparison of the incoming message minus the transport-related fields, i.e., by considering only: i) the outer REST code; ii) the outer options; and iii) the ciphertext from the message payload.¶
8. Having recognized the incoming request as one of the self-generated deterministic phantom requests made available at external sources, the server does not perform any OSCORE processing on it. This opens for replying to the proxy with an unprotected response, although not signaling any OSCORE-related error.¶
9. The server starts the group observation and replies with an error response, i.e., the usual 5.03 informative response, including: the transport information, the phantom request, and (optionally) the latest notification.¶
10. From the received 5.03 response, the proxy retrieves everything needed to set itself as an observer in the group observation, and it starts listening to multicast notifications. If the 5.03 response included a latest notification, the proxy caches it and forwards it back to the client, otherwise it replies with an empty ACK (if it has not done it already and the request from the client was Confirmable).¶
11. Like in the case with a non-deterministic phantom request considered in Section 12, the proxy fans out the multicast notifications to the origin clients as they come. Also, as new clients following the first one contact the proxy, this does not have to contact the server again as in Section 12, since the deterministic phantom request would produce a cache hit as per [I-D.amsuess-core-cachable-oscore]. Thus, the proxy can serve such clients with the latest fresh multicast notification from its cache.¶

G.2. Message Exchange

The same assumptions and notation used in Section 10 are used for this example. As a recap of some specific value:¶

• Two clients C_1 and C_2 register to observe a resource /r at a Server S, which has address SRV_ADDR and listens to the port number SRV_PORT. Before the following exchanges occur, no clients are observing the resource /r , which has value "1234".¶
• The server S sends multicast notifications to the IP multicast address GRP_ADDR and port number GRP_PORT, and starts the group observation already after creating the deterministic phantom request to early disseminate.¶
• S is a member of the OSCORE group with 'kid context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' = 0x05 as Sender ID, and SN_5 = 501 as Sender Sequence Number.¶

In addition:¶

• The proxy has address PRX_ADDR and listens to the port number PRX_PORT.¶
• The deterministic client in the OSCORE group has 'kid' = 0x09.¶

Unless explicitly indicated, all messages transmitted on the wire are sent over unicast and protected with Group OSCORE end-to-end between a client and the server.¶

C1      C2      P         S
|       |       |         |
|       |       |         |  (The value of the resource /r is "1234")
|       |       |         |
|       |       |         |  (S allocates the available
|       |       |         |   Token value 0x7b .)
|       |       |         |
|       |       |         |  (S sends to itself a phantom observation
|       |       |         |   request PH_REQ as coming from the
|       |       |         |   IP multicast address GRP_ADDR.
|       |       |         |   The OSCORE processing occurs as
|       |       |         |   specified for a deterministic request)
|       |       |         |
|       |       |  -------|
|       |       | /       |
|       |       | \------>|  Token: 0x7b
|       |       |   FETCH |  Uri-Host: sensor.example
|       |       |         |  Observe: 0 (register)
|       |       |         |  OSCORE: {kid: 0x09 ; piv: 0 ;
|       |       |         |           kid context: 0x57ab2e ; ... }
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x01 (GET),
|       |       |         |    Observe: 0 (register),
|       |       |         |    Uri-Path: r,
|       |       |         |    <Other class E options>
|       |       |         |  }
|       |       |         |
|       |       |         |  (S creates a group observation of /r)
|       |       |         |
|       |       |         |  (The server does not respond to PH_REQ.
|       |       |         |   The server stores PH_REQ locally and
|       |       |         |   makes it available at an external source)
|       |       |         |
|       |       |         |
|       |       |         |  (C1 obtains PH_REQ and sends it to P)
|       |       |         |
|       |       |         |
+-------------->|         |  Token: 0x4a
| FETCH |       |         |  Uri-Host: sensor.example
|       |       |         |  Observe: 0 (register)
|       |       |         |  OSCORE: {kid: 0x09 ; piv: 0 ;
|       |       |         |           kid context: 0x57ab2e ; ... }
|       |       |         |  Proxy-Scheme: coap
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x01 (GET),
|       |       |         |    Observe: 0 (register),
|       |       |         |    Uri-Path: r,
|       |       |         |    <Other class E options>
|       |       |         |  }
|       |       |         |
|       |       +-------->|  Token: 0x5e
|       |       | FETCH   |  Uri-Host: sensor.example
|       |       |         |  Observe: 0 (register)
|       |       |         |  OSCORE: {kid: 0x09 ; piv: 0 ;
|       |       |         |           kid context: 0x57ab2e ; ... }
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x01 (GET),
|       |       |         |    Observe: 0 (register),
|       |       |         |    Uri-Path: r,
|       |       |         |    <Other class E options>
|       |       |         |  }
|       |       |         |
|       |       |         |  (S recognizes PH_REQ through byte-by-byte
|       |       |         |   comparison against the stored one, and
|       |       |         |   skips any OSCORE processing)
|       |       |         |
|       |       |         |  (S prepares the "last notification"
|       |       |         |   response defined below)
|       |       |         |
|       |       |         |  0x45 (2.05 Content)
|       |       |         |  Observe: 10
|       |       |         |  OSCORE: {kid: 0x05 ; piv: 501 ; ...}
|       |       |         |  Max-Age: 3000
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x45 (2.05 Content),
|       |       |         |    Observe: [empty],
|       |       |         |    CBOR_Payload: "1234"
|       |       |         |  }
|       |       |         |  <Signature>
|       |       |         |
|       |       |         |  (S increments the observer counter
|       |       |         |  for the group observation of /r)
|       |       |         |
|       |       |         |  (S responds to the proxy with an
|       |       |         |   unprotected informative response)
|       |       |         |
|       |       |<--------|  Token: 0x5e
|       |       | 5.03    |  Content-Format: application/
|       |       |         |    informative-response+cbor
|       |       |         |  Max-Age: 0
|       |       |         |  0xff,
|       |       |         |  CBOR_payload {
|       |       |         |     tp_info : [1, bstr(SRV_ADDR), SRV_PORT,
|       |       |         |                0x7b, bstr(GRP_ADDR),
|       |       |         |                GRP_PORT],
|       |       |         |     last_notif : <the "last notification"
|       |       |         |                   response prepared above>
|       |       |         |    }
|       |       |         |  }
|       |       |         |
|       |       |         |  (P extracts PH_REQ and starts listening
|       |       |         |   to multicast notifications with Token
|       |       |         |   0x7b at GRP_ADDR:GRP_PORT)
|       |       |         |
|       |       |         |  (P extracts the "last notification"
|       |       |         |   response, caches it and forwards
|       |       |         |   it back to C1)
|       |       |         |
|<--------------+         |  Token: 0x4a
| 2.05  |       |         |  Observe: 54120
|       |       |         |  OSCORE: {kid: 0x05 ; piv: 501 ; ...}
|       |       |         |  Max-Age: 2995
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x45 (2.05 Content),
|       |       |         |    Observe: [empty],
|       |       |         |    CBOR_Payload: "1234"
|       |       |         |  }
|       |       |         |  <Signature>
|       |       |         |
:       :       :         |
:       :       :         |
:       :       :         |
|       |       |         |
|       |       |         |  (C2 obtains PH_REQ and sends it to P)
|       |       |         |
|       +------>|         |  Token: 0x01
|       | FETCH |         |  Uri-Host: sensor.example
|       |       |         |  Observe: 0 (register)
|       |       |         |  OSCORE: {kid: 0x09 ; piv: 0 ;
|       |       |         |           kid context: 0x57ab2e; ...}
|       |       |         |  Proxy-Scheme: coap
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x01 (GET),
|       |       |         |    Observe: 0 (register),
|       |       |         |    Uri-Path: r,
|       |       |         |    <Other class E options>
|       |       |         |  }
|       |       |         |
|       |       |         |  (P serves C2 from it cache)
|       |       |         |
|       |<------+         |  Token: 0x01
|       | 2.05  |         |  Observe: 54120
|       |       |         |  OSCORE: {kid: 0x05 ; piv: 501 ; ...}
|       |       |         |  Max-Age: 1800
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x45 (2.05 Content),
|       |       |         |    Observe: [empty],
|       |       |         |    CBOR_Payload: "1234"
|       |       |         |  }
|       |       |         |  <Signature>
|       |       |         |
:       :       :         |
:       :       :         |
:       :       :         |
|       |       |         |
|       |       |         |  (The value of the resource
|       |       |         |   /r changes to "5678".)
|       |       |         |
|       |       |   (*)   |
|       |       |<--------|  Token: 0x7b
|       |       | 2.05    |  Observe: 11
|       |       |         |  OSCORE: {kid: 0x05; piv: 502 ; ...}
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  Encrypted_payload {
|       |       |         |    0x45 (2.05 Content),
|       |       |         |    Observe: [empty],
|       |       |         |    Content-Format: application/cbor,
|       |       |         |    <Other class E options>,
|       |       |         |    0xff,
|       |       |         |    CBOR_Payload: "5678"
|       |       |         |  }
|       |       |         |  <Signature>
|       |       |         |
|       |       |         |  (P updates its cache entry
|       |       |         |   with this notification)
|       |       |         |
|<--------------+         |  Token: 0x4a
| 2.05  |       |         |  Observe: 54123
|       |       |         |  OSCORE: {kid: 0x05; piv: 502 ; ...}
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  (Same Encrypted_payload and signature)
|       |       |         |
|       |<------+         |  Token: 0x01
|       | 2.05  |         |  Observe: 54123
|       |       |         |  OSCORE: {kid: 0x05; piv: 502 ; ...}
|       |       |         |  <Other class U/I options>
|       |       |         |  0xff
|       |       |         |  (Same Encrypted_payload and signature)
|       |       |         |


(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected
    with Group OSCORE end-to-end between the server and the clients.

H.1. Version -06 to -07

• Added more details on proxies that do not support the Multicast-Response-Feedback-Divider Option.¶
• Added more details on the reliability of the client rough counting.¶
• Added more details on the unreliability of counting new clients, when the phantom request is obtained from other sources or is an OSCORE deterministic request.¶
• Revised parameter naming.¶
• Fixes in IANA considerations.¶
• Editorial improvements.¶

H.2. Version -05 to -06

• Clarified rough counting of clients when a proxy is used¶
• IANA considerations: registration of target attribute "gp-obs"¶
• Editorial improvements.¶

H.3. Version -04 to -05

• If the phantom request is an OSCORE deterministic request, there is no parallel group observation for clients that lack support.¶
• Clarification on pre-configured clients.¶
• Clarified early publication of phantom request.¶
• Fixes in IANA considerations.¶
• Fixed example with proxy and Group OSCORE.¶
• Editorial improvements.¶

H.4. Version -03 to -04

• Added a new section on prerequisites.¶
• Added a new section overviewing alternative variants.¶
• Consistent renaming of 'cli_addr' to 'cli_host' in 'tp_info'.¶
• Added pre-requirements for early retrieval of phantom request.¶
• Revised example with early retrieval of phantom request.¶
• Clarified use, rationale and example of phantom request as deterministic request.¶
• Editorial improvements.¶

H.5. Version -02 to -03

• Distinction between authentication credential and public key.¶
• Fixed processing of informative response at the client, when Group OSCORE is used.¶
• Discussed scenarios with pre-configured address/port and Token value.¶

H.6. Version -01 to -02

• Clarifications on client rough counting and IP multicast scope.¶
• The 'ph_req' parameter is optional in the informative response.¶
• New parameter 'next_not_before' for the informative response.¶
• Optimization when rekeying the self-managed OSCORE group.¶
• Security considerations on unsecured multicast notifications.¶
• Protection of the ticket request sent to a proxy.¶
• RFC8126 terminology in IANA considerations.¶
• Editorial improvements.¶

H.7. Version -00 to -01

• Simplified cancellation of the group observation, without using a phantom cancellation request.¶
• Aligned parameter semantics with core-oscore-groupcomm and ace-key-groupcomm-oscore.¶
• Clarifications about self-managed OSCORE group and use of deterministic requests for cacheable OSCORE.¶
• New example with a proxy, Group OSCORE and a deterministic phantom request.¶
• Fixes in the examples and editorial improvements.¶