| Internet-Draft | Proxies for Observe Multicast Notificati | October 2025 |
| Tiloca, et al. | Expires 23 April 2026 | [Page] |
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic.¶
The present version -00 refers to version -12 of draft-ietf-core-observe-multicast-notifications, which includes content about proxies that is also included in the present document. Such content will be removed from draft-ietf-core-observe-multicast-notifications in its next revision.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/.¶
Source for this draft and an issue tracker can be found at https://github.com/core-wg/multicast-notifications-proxy.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Constrained Application Protocol (CoAP) [RFC7252] has been extended with a number of mechanisms, including resource Observation [RFC7641]. This enables CoAP clients to register at a CoAP server as "observers" of a resource, and hence being automatically notified with an unsolicited response upon changes of the resource state.¶
CoAP supports group communication [I-D.ietf-core-groupcomm-bis], e.g., over IP multicast. This includes support for Observe registration requests over multicast, in order for clients to efficiently register as observers of a resource hosted at multiple servers.¶
In a number of use cases, it is conversely desirable that a server sends observe notifications for the same target resource to multiple observers at once. In general, this is beneficial when several CoAP clients observe the same target resource at a CoAP server, and thus they could all be notified at once by means of a single response message.¶
To this end, [I-D.ietf-core-observe-multicast-notifications] defines a method that a server can use to deliver observe notifications as CoAP responses addressed to multiple clients, e.g., over IP multicast. Also, it defines how to use the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications end-to-end between the server and the observer clients.¶
This document describes how the method specified in [I-D.ietf-core-observe-multicast-notifications] can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic.¶
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], Concise Data Definition Language (CDDL) [RFC8610], Concise Binary Object Representation (CBOR) [RFC8949], Object Security for Constrained RESTful Environments (OSCORE) [RFC8613], Group OSCORE [I-D.ietf-core-oscore-groupcomm], and Constrained Resource Identifiers (CRIs) [I-D.ietf-core-href].¶
Readers are also expected to be familiar with terms and concepts described in [I-D.ietf-core-observe-multicast-notifications], particularly with the terms "traditional observation", "group observation", "phantom request", and "informative response".¶
Building on what is specified in [I-D.ietf-core-observe-multicast-notifications], this document considers network setups where proxies are deployed, which is expected in case (some of) the clients participating in the group observation are not capable to listen to multicast traffic. In such setups, a proxy directly receives multicast notifications from the server and relays them back to the clients.¶
Therefore, with respect to [I-D.ietf-core-observe-multicast-notifications], this document introduces additional variants to enforce a group observation. As a complement to Section 3 of [I-D.ietf-core-observe-multicast-notifications], the rest of this section provides an overview of such additional variants, which differ as to whether exchanged messages are protected end-to-end between the observer clients and the server.¶
Variant with proxy and without end-to-end security - Messages pertaining to the group observation are not protected end-to-end between the clients and the server. This basic case is defined in Section 3. An example is provided in Section 6.¶
Variant with proxy and with end-to-end security - Messages pertaining to the group observation are protected end-to-end between the clients and the server, by using the security protocol Group OSCORE [I-D.ietf-core-oscore-groupcomm]. In particular, the clients are required to separately provide the proxy with the obtained phantom request, thus enabling the proxy to receive the multicast notifications from the server. This case is defined in Section 4. An example is provided in Section 7.¶
If the participating endpoints using Group OSCORE also support the concept of Deterministic Client [I-D.ietf-core-cacheable-oscore], the same advantages mentioned in Section 3 of [I-D.ietf-core-observe-multicast-notifications] for the case without a proxy apply (see Appendix D of [I-D.ietf-core-observe-multicast-notifications]). In addition, this allows for a more efficient setup and enforcement of the group observation, by reducing the amount of message exchanges and allowing the proxy to effectively serve protected multicast notifications from its cache. An example is provided in Section 8.2.¶
This section specifies how the approach presented in Sections 4 and 5 of [I-D.ietf-core-observe-multicast-notifications] works when a proxy is used between the clients and the server. In addition to what is specified in Section 5.7 of [RFC7252] and Section 5 of [RFC7641], the following applies.¶
A client sends its original observation request to the proxy. If the proxy is not already registered at the server for that target resource, the proxy forwards the observation request to the server, hence registering itself as an observer. If the server has an ongoing group observation for the target resource or decides to start one, the server considers the proxy as taking part in the group observation and replies to the proxy with an informative response.¶
Upon receiving an informative response, the proxy performs as specified for the client in Section 5 of [I-D.ietf-core-observe-multicast-notifications], with the peculiarity that "consuming" the last notification (if present) means populating its cache.¶
In particular, by using the information retrieved from the informative response, the proxy configures an observation of the target resource at the origin server, acting as a client directly taking part in the group observation.¶
As a consequence, the proxy listens to the IP multicast address and port number indicated by the server, i.e., per the CRI [I-D.ietf-core-href] specified by a dedicated element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the CRI is conveyed by the element 'tpi_client' (see Section 4.2.1.1 of [I-D.ietf-core-observe-multicast-notifications]).¶
Furthermore, multicast notifications will match the phantom request stored at the proxy, based on the Token value specified by a dedicated element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the Token value is specified by the element 'tpi_token' (see Section 4.2.1.1 of [I-D.ietf-core-observe-multicast-notifications]).¶
Then, the proxy performs the following actions.¶
If the 'last_notif' field is not present, the proxy responds to the client with an Empty Acknowledgement (if indicated by the message type, and if the proxy has not already done so).¶
If the 'last_notif' field is present, the proxy rebuilds the latest multicast notification, as defined in Section 5 of [I-D.ietf-core-observe-multicast-notifications]. Then, the proxy responds to the client, by forwarding back the latest multicast notification.¶
When responding to an observation request from a client, the proxy also adds that client (and its Token) to the list of its registered observers for the target resource, next to the older observations.¶
Upon receiving a multicast notification from the server, the proxy forwards it back separately to each observer client over unicast. Note that the notification forwarded back to a certain client has the same Token value of the original observation request sent by that client to the proxy.¶
Note that the proxy configures the observation of the target resource at the server only once, when receiving the informative response associated with a (newly started) group observation for that target resource.¶
After that, when receiving an observation request from a following new client to be added to the same group observation, the proxy does not take any further action with the server. Instead, the proxy responds to the client either with the latest multicast notification if available from its cache, or with an Empty Acknowledgement otherwise, as defined above.¶
As a result, the observer counter at the server (see Section 4 of [I-D.ietf-core-observe-multicast-notifications]) is not incremented when a new origin client behind the proxy registers as an observer at the proxy. Instead, the observer counter takes into account only the proxy, which has registered as observer at the server and has received the informative response from the server.¶
An example is provided in Section 6.¶
In the general case with a chain of two or more proxies, every proxy in the chain takes the role of client with the (next hop towards the) origin server. Note that the proxy adjacent to the origin server is the only one in the chain that receives informative responses and that listens to an IP multicast address and port number to receive notifications for the group observation. Furthermore, every proxy in the chain takes the role of server with the (previous hop towards the) origin client.¶
As defined in Section 9 of [I-D.ietf-core-observe-multicast-notifications], the security protocol Group OSCORE [I-D.ietf-core-oscore-groupcomm] can be used to protect multicast notifications end-to-end between the origin server and the origin clients.¶
Since the informative responses from the origin server are protected specifically end-to-end by using OSCORE or Group OSCORE, additional actions are required in the presence of a proxy.¶
In fact, the proxy adjacent to the origin server is not able to access the encrypted payload of such informative responses. Hence, the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters necessary to correctly receive multicast notifications and forward them back to the clients.¶
Then, differently from what is defined in Section 11 of [I-D.ietf-core-observe-multicast-notifications], each proxy receiving an informative response simply forwards it back to the client that has sent the corresponding observation request. Note that the proxy does not even realize that the message is an informative response, since the outer Code field is set to 2.05 (Content).¶
Upon receiving the informative response, the client does not configure an observation of the target resource. Instead, the client performs a new observe registration request, by transmitting the re-built phantom request as intended to reach the proxy adjacent to the origin server. In particular, the client includes the new Listen-To-Multicast-Responses CoAP option defined in Section 4.1, to provide that proxy with the transport-specific information required for receiving multicast notifications for the group observation.¶
As a result, the observer counter at the server (see Section 4 of [I-D.ietf-core-observe-multicast-notifications]) is incremented when, after having received the original observation request from a new origin client, the origin server replies with the informative response. In particular, the observer counter at the server reliably takes into account the new, different origin clients behind the proxy, which the server distinguishes through their security identity specified by the pair (OSCORE Sender ID, OSCORE ID Context) in the OSCORE Option of their original observation request. Note that this does not hold anymore if the origin endpoints use phantom observation requests as deterministic requests (see Appendix D of [I-D.ietf-core-observe-multicast-notifications]).¶
Details on the additional message exchange and processing are defined in Section 4.2.¶
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-Response, is intended only for requests, and has the properties summarized in Table 1, which extends Table 4 of [RFC7252]. The option is critical and not Safe-to-Forward. Since the option is not Safe-to-Forward, the 'N' column indicates a dash for "not applicable".¶
| No. | C | U | N | R | Name | Format | Length | Default |
|---|---|---|---|---|---|---|---|---|
| TBD47 | x | x | - | Listen-To- Multicast-Responses |
(*) | 3-1024 | (none) |
Note to RFC Editor: In the table above, please replace TBD47 with the registered option number. Then, please delete this paragraph.¶
The Listen-To-Multicast-Responses Option includes the byte serialization of a CBOR array. This specifies transport-specific message information that is required for listening to the multicast notifications of a group observation and is 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 of [I-D.ietf-core-observe-multicast-notifications] for the 'tp_info' parameter of the informative response defined in Section 4.2 of [I-D.ietf-core-observe-multicast-notifications].¶
The Listen-To-Multicast-Responses Option is of class U for OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].¶
Compared to Section 3, the following additions apply when informative responses are protected end-to-end between the origin server and the origin 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 of [I-D.ietf-core-observe-multicast-notifications]:¶
The client performs all the additional decryption and verification steps of Section 9.3.1 of [I-D.ietf-core-observe-multicast-notifications] 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 C of [I-D.ietf-core-cacheable-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 client includes: the outer option Proxy-Uri or Proxy-Cri [I-D.ietf-core-href]; or the outer options (Uri-Host, Uri-Port), together with the outer option Proxy-Scheme or Proxy-Scheme-Number [I-D.ietf-core-href]. These options are set in order to specify the same request URI of 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 byte 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 in 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 the option Proxy-Uri, or Proxy-Scheme, or Proxy-Cri, or Proxy-Scheme-Number from the ticket request.¶
The proxy removes the Listen-To-Multicast-Responses Option from the ticket request and extracts the transport-specific information conveyed therein.¶
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 listens to the IP multicast address and port number indicated in the Listen-To-Multicast-Responses Option, i.e., per the CRI specified by a dedicated element of 'tpi_details' within the serialized CBOR array conveyed in the option. In particular, when transporting CoAP over UDP, the CRI is conveyed by the element 'tpi_client' (see Section 4.2.1.1 of [I-D.ietf-core-observe-multicast-notifications]).¶
Furthermore, multicast notifications will match the phantom request stored at the proxy, based on the Token value specified by a dedicated element of 'tpi_details' within the serialized CBOR array conveyed in the Listen-To-Multicast-Responses Option. In particular, when transporting CoAP over UDP, the Token value is specified by the element 'tpi_token' (see Section 4.2.1.1 of [I-D.ietf-core-observe-multicast-notifications]).¶
Section 3 specifies how the approach presented in Sections 4 and 5 of [I-D.ietf-core-observe-multicast-notifications] 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 a participant to the group observation at the server, receives the multicast notifications from the server, and forwards those to the clients.¶
With reference to the method defined in Section 8 of [I-D.ietf-core-observe-multicast-notifications], this has an impact on the rough counting that the server performs to keep an estimate of still active and interested clients. In particular, the following applies.¶
Since the Multicast-Response-Feedback-Divider Option defined in Section 8.1 of [I-D.ietf-core-observe-multicast-notifications] is not Safe-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 sends 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 sends 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 of [I-D.ietf-core-observe-multicast-notifications] and Section 4 of this document). 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 Section 8 of [I-D.ietf-core-observe-multicast-notifications] but communications are not protected end-to-end between the origin endpoints, 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 holds 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 3), then the Multicast-Response-Feedback-Divider Option is visible to the proxy.¶
In this case, the proxy proceeds like defined in Section 8.2 of [I-D.ietf-core-observe-multicast-notifications] 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.¶
Furthermore, the proxy 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 verifying 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 of [I-D.ietf-core-observe-multicast-notifications]).¶
If the multicast notification is protected end-to-end by using Group OSCORE (see Section 9 of [I-D.ietf-core-observe-multicast-notifications] and Section 4 of this document), 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.¶
This section provides an example when a proxy P is used between the clients and the server. The same assumptions and notation used in Section 7 of [I-D.ietf-core-observe-multicast-notifications] are used for this example. In addition, the proxy has address PRX_ADDR and listens to the port number PRX_PORT.¶
Unless explicitly indicated, all messages transmitted on the wire are sent over unicast.¶
Note that the proxy has all the information to understand the observation request from C2 and can immediately start to serve the still fresh values.¶
This behavior is mandated by Section 5 of [RFC7641], i.e., the proxy registers itself only once with the next hop and fans out the notifications it receives to all the registered clients.¶
This section provides an example when a proxy P is used between the clients and the server, and Group OSCORE is used to protect multicast notifications end-to-end between the server and the clients.¶
The same assumptions and notation used in Section 10 of [I-D.ietf-core-observe-multicast-notifications] are used for this example. In addition, the proxy has address PRX_ADDR and listens to the port number PRX_PORT.¶
Unless explicitly indicated, all messages transmitted on the wire are sent over unicast and protected with OSCORE end-to-end between a client and the server.¶
Unlike in the unprotected example in Section 6, the proxy does not have all the information to perform request deduplication and can only recognize the identical request once the client sends the ticket request.¶
This section provides an example when a proxy P is used between the clients and the server, and Group OSCORE is used to protect multicast notifications end-to-end between the server and the clients.¶
In addition, the phantom request is especially a deterministic request (see Appendix D of [I-D.ietf-core-observe-multicast-notifications]), which is protected with the pairwise mode of Group OSCORE as defined in [I-D.ietf-core-cacheable-oscore].¶
Since the server replies to such a deterministic request with an informative response that is not protected (see Appendix D of [I-D.ietf-core-observe-multicast-notifications]), the proxy is able to retrieve from the informative response everything needed to set itself as an observer in the group observation and to start listening to multicast notifications.¶
In particular, each client sends the deterministic request to the proxy as a ticket request (see Section 4). However, differently from what is defined in Section 4 where the ticket request is not a deterministic request, the clients do not include a Listen-to-Multicast-Responses Option. This results in the proxy forwarding the ticket request (i.e., the phantom observation request) to the server and obtaining the information required to listen to multicast notifications, unless the proxy has already set itself to do so. Also, the proxy will be able to serve multicast notifications from its cache as per [I-D.ietf-core-cacheable-oscore].¶
Appendix D of [I-D.ietf-core-observe-multicast-notifications] discusses how, when using a deterministic request as a phantom observation request, the observer counter at the server (see Section 4 of [I-D.ietf-core-observe-multicast-notifications]) is not reliably incremented when new clients start participating in the group observation. The same applies also if a proxy is deployed.¶
That is, the origin server increments its observer counter after having sent the informative response to the proxy, as a reply to the deterministic request forwarded to the origin server on behalf of the first origin client that contacted the proxy. After that, the same deterministic request sent by any origin client will not be forwarded to the origin server, but will instead produce a cache hit at the proxy that will serve the client accordingly. Hence, the observer counter at the server is not further incremented as additional, new origin clients start participating in the group observation through the proxy.¶
Also in this case, the security identity associated with the sender of any deterministic request in the OSCORE group is exactly the same one, i.e., the pair (SID, OSCORE ID Context), where SID is the OSCORE Sender ID of the Deterministic Client in the OSCORE group, which all the clients in the group rely on to produce deterministic requests.¶
The example provided in this appendix as reflected by the message exchange shown in Section 8.2 assumes the following.¶
The OSCORE group supports deterministic requests. Thus, the server creates the phantom request as a deterministic request [I-D.ietf-core-cacheable-oscore], stores it locally as one of its issued phantom requests, and starts the group observation.¶
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 of [I-D.ietf-core-observe-multicast-notifications]).¶
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.ietf-core-cacheable-oscore], thus all computing the same deterministic request to be used as phantom observation request.¶
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 Step 2 above, the same would happen if the phantom request was not specifically a deterministic request.¶
If the client relies on a proxy between itself and the server, it uses the phantom request as a ticket request (see Section 4). However, unlike the case considered in Section 4 where the ticket request is not a deterministic request, the client does not include a Listen-to-Multicast-Responses Option in the phantom request sent to the proxy.¶
Unlike for the case considered in Section 4, 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 like it normally would.¶
The server receives the ticket request, which is a deviation from the case where the ticket request is not a deterministic request and stops at the proxy (see Section 4). Then, the server recognizes the phantom request among the stored ones, through a byte-by-byte comparison of the incoming message minus the transport-related fields (see Appendix D of [I-D.ietf-core-observe-multicast-notifications]). Consequently, the server does not perform any Group OSCORE processing on it.¶
The server replies with an unprotected informative response (see Section 4.2 of [I-D.ietf-core-observe-multicast-notifications]), including: the transport-specific information, (optionally) the phantom request, and (optionally) the latest notification.¶
Note that the phantom request can be omitted, since it is the deterministic phantom request from the client, and thus "in terms of transport-independent information, identical to the registration request from the client" (see Section 4.2 of [I-D.ietf-core-observe-multicast-notifications]).¶
From the received informative 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 informative response includes a latest notification, the proxy caches it and forwards it back to the client. Otherwise, the proxy replies with an empty ACK (if it has not done it already and the request from the client was Confirmable).¶
Like in the case with a non-deterministic phantom request considered in Section 4, 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, the latter does not have to contact the server again as in Section 4, since the deterministic phantom request would produce a cache hit as per [I-D.ietf-core-cacheable-oscore]. Thus, the proxy can serve such clients with the latest fresh multicast notification from its cache.¶
The same assumptions and notation used in Section 10 of [I-D.ietf-core-observe-multicast-notifications] are used for this example. As a recap of some specific values:¶
Two clients C1 and C2 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.¶
This section describes an example where specifically a reverse-proxy PRX is used between the clients and the server (see Section 5.7.3 of [RFC7252]).¶
Like for the example in Section 8, the phantom request is especially a deterministic request (see Appendix D of [I-D.ietf-core-observe-multicast-notifications]), which is protected with the pairwise mode of Group OSCORE as defined in [I-D.ietf-core-cacheable-oscore].¶
The same assumptions compiled in Section 8.1 apply in this scenario too, with the following differences:¶
Assumption (2): when the server makes the phantom request available through other means (see Appendix A of [I-D.ietf-core-observe-multicast-notifications]), the accompanying group observation data does not specify client-side, transport-specific information for listening to multicast notifications bound to the phantom request.¶
Assumption (4): this assumption does not apply, since all the clients rely on PRX, although they are not aware to communicate with a proxy.¶
Furthermore, the following assumptions apply to this scenario:¶
The server knows the address PRX_ADDR and port number PRX_PORT that PRX exposes to the clients when acting as stand-in for the server.¶
That is, a request sent with destination address PRX_ADDR and port number PRX_PORT will reach PRX, which forwards the request to the server.¶
When the server makes the phantom request available through other means (see Appendix A of [I-D.ietf-core-observe-multicast-notifications]), the accompanying group observation data is such that:¶
It provides server-side, transport-specific information, which consists of the address PRX_ADDR and port number PRX_PORT associated with PRX.¶
It does not provide any further client-side, transport-specific information.¶
Assuming that the group information data has a format consistent with the 'tp_info' array of the informative response (see Section 4.2.1 of [I-D.ietf-core-observe-multicast-notifications]), this means that the 'tp_info' array includes only the 'tpi_server' element specifying a CRI with addressing information PRX_ADDR and PRX_PORT (i.e., targeting PRX). That is, 'tp_info' does not include the 'tpi_details' element, regardless of what is expected per the transport used.¶
The rest of this section describes how a client can take part in a group observation.¶
If any of the following conditions does not hold, then the client first performs the initialization procedure described in Section 9.1.1.¶
The client has already obtained the group observation data specifying the deterministic phantom request, which the server has made available through other means (see Appendix A of [I-D.ietf-core-observe-multicast-notifications]).¶
The client is already a member of the correct OSCORE group.¶
The main process consists of the following steps.¶
From the group observation data, the client knows the deterministic phantom request PH_REQ, the address PRX_ADDR, and the port number PRX_PORT, but no other client-side, transport-specific information.¶
In such a particular situation, the client sends PH_REQ with destination address PRX_ADDR and port number PRX_PORT, i.e., to PRX.¶
Upon receiving PH_REQ, PRX performs the same actions performed by the proxy in the scenario of Section 8.¶
That is, if PH_REQ results in a cache hit at PRX, then PRX replies to the client with the latest multicast notification for the target resource from its cache and takes no further actions.¶
Otherwise, PRX forwards PH_REQ to the server. After recognizing PH_REQ byte-by-byte, the server replies to PRX with an unprotected informative response, where 'tp_info' specifies the information to receive multicast notifications for the target resource. Based on such information, PRX starts listening to multicast notifications. If the informative response includes a latest notification, then PRX caches that notification and forwards it to the client.¶
Editor's note: add a figure showing an example of message exchange.¶
The following early initialization procedure is performed by a client that does not have the group observation data and/or is not a member of the correct OSCORE group, before starting the main process described in Section 9.1.¶
The client is minimally provided with the pair (PRX_ADDR, PRX_PORT) associated with PRX, which the client believes to be targeting the origin server.¶
a. The client sends a traditional Observe registration request with destination address PRX_ADDR and port number PRX_PORT, i.e., to PRX. The request is protected with (Group) OSCORE, i.e., end-to-end between the client and the server.¶
b. PRX receives the request and forwards it to the server, as usual.¶
c. The server replies with a 5.03 (Service Unavailable) informative response. The response is protected with (Group) OSCORE, i.e., end-to-end between the client and the server. The payload of the response specifies the following parameters:¶
The 'tp_info' parameter, within which the 'tpi_server' element is a CRI with addressing information PRX_ADDR and PRX_PORT (i.e., targeting PRX). The 'tp_info' parameter does not include the 'tpi_details' element, regardless of what is expected per the transport used.¶
The 'ph_req' parameter, conveying the deterministic phantom request PH_REQ.¶
Optionally, parameters conveying information that the client can use for joining the OSCORE group if that has not happened yet, or the keying material used in the OSCORE group if the server is managing it (see Section 9.1).¶
d. PRX receives the protected informative response and forwards it to the client, as usual.¶
e. Upon receiving the protected informative response, the client takes its payload as the group observation data for the group observation of interest.¶
Per the instructions specified in the response, the client takes the necessary steps to join the correct OSCORE group, in case it is not already a member.¶
In addition to the security considerations from [I-D.ietf-core-observe-multicast-notifications], the following considerations hold for this document.¶
The CoAP option Listen-To-Multicast-Responses defined in Section 4.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 4.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 that match 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., as based on 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, e.g., by using OSCORE (see [I-D.ietf-core-oscore-capable-proxies]) and/or DTLS [RFC9147].¶
This document has the following actions for IANA.¶
Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.¶
IANA is asked to enter the following option number to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶
| Number | Name | Reference |
|---|---|---|
| TBD47 | Listen-To-Multicast-Responses | [RFC-XXXX] |
For the Listen-To-Multicast-Responses Option, the preferred value range is 0-255. In particular, 47 is the preferred option number.¶
Note to RFC Editor: In the table above, please replace TBD47 with the registered option number. Then, please delete this paragraph and the previous paragraph.¶
This section is to be removed before publishing as an RFC.¶
Imported content about proxies from draft-ietf-core-observe-multicast-notifications-12.¶
The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime Jiménez, Matthias Kovatsch, John Preuß Mattsson, Jim Schaad, Ludwig Seitz, and Göran Selander for their comments and feedback.¶
The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).¶