| Internet-Draft | Proxy Operations for Group Communication | February 2023 |
| Tiloca & Dijk | Expires 1 September 2023 | [Page] |
This document specifies the operations performed by a proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such a proxy processes a single request sent by a client over unicast, and distributes the request over IP multicast to a group of servers. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies.¶
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://gitlab.com/crimson84/draft-tiloca-core-groupcomm-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 1 September 2023.¶
Copyright (c) 2023 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] allows the presence of proxies, as intermediary entities supporting clients by performing requests on their behalf and relaying back responses.¶
CoAP supports also group communication over IP multicast [I-D.ietf-core-groupcomm-bis], where a group request can be addressed to multiple recipient servers, each of which may reply with an individual unicast response. As discussed in Section 3.5 of [I-D.ietf-core-groupcomm-bis], this group communication scenario poses a number of issues and limitations to proxy operations.¶
In particular, the client sends to the proxy a single unicast request, which the proxy forwards to a group of servers over IP multicast. Later on, the proxy replies to the client's original unicast request, by relaying back the responses from the servers.¶
As per [RFC7252], a CoAP-to-CoAP proxy relays those responses to the client as separate CoAP messages, all matching (by Token) with the client's original unicast request. A possible alternative approach for aggregating those responses into a single CoAP response sent to the client would require a specific aggregation content-format, which is not available yet. Both these approaches have open issues.¶
This document considers the former approach. That is, after forwarding a CoAP group request from the client to the group of CoAP servers, the proxy relays the individual responses back to the client as separate CoAP messages. The described method addresses all the related issues raised in Section 3.5 of [I-D.ietf-core-groupcomm-bis]. To this end, a dedicated signaling protocol is defined, using two new CoAP options.¶
Using this protocol, the client explicitly confirms its intent to perform a proxied group request and its support for receiving multiple responses as a result, i.e., one or more from each origin server. Also, the client signals for how long it is willing to wait for responses. When relaying to the client a response to the group request, the proxy indicates the addressing information of the origin server. This enables the client to distinguish, multiple diffent responses by origin and to possibly contact one or more of the respective servers by sending individual unicast request(s) to the indicated address(es). In doing these follow-up unicast requests, the client may optionally bypass the proxy.¶
This document also defines how the proposed protocol is used between an HTTP client and an HTTP-CoAP cross-proxy, in order to forward an HTTP group request from the client to a group of CoAP servers, and relay back the individual CoAP responses as HTTP responses.¶
Finally, this document defines a caching model for proxies and specifies how they can serve a group request by using cached responses. Therefore, this document updates [RFC7252].¶
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 defined in CoAP [RFC7252], Group Communication for CoAP [I-D.ietf-core-groupcomm-bis], CBOR [RFC8949], OSCORE [RFC8613] and Group OSCORE [I-D.ietf-core-oscore-groupcomm].¶
Unless specified otherwise, the term "proxy" refers to a CoAP-to-CoAP forward-proxy, as defined in Section 5.7.2 of [RFC7252].¶
The Multicast-Timeout Option defined in this section has the properties summarized in Figure 1, which extends Table 4 of [RFC7252].¶
Since the option is not Safe-to-Forward, the column "N" indicates a dash for "not applicable". The value of the Multicast-Timeout Option specifies a timeout value in seconds, encoded as an unsigned integer (see Section 3.2 of [RFC7252]).¶
+------+---+---+---+---+------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+------------+--------+--------+---------+
| | | | | | | | | |
| TBD1 | | x | - | | Multicast- | uint | 0-4 | (none) |
| | | | | | Timeout | | | |
| | | | | | | | | |
+------+---+---+---+---+------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
This document specifically defines how this option is used by a client in a CoAP request, to indicate to a proxy its support for and interest in receiving multiple responses to a proxied CoAP group request, i.e., one or more from each origin server, and for how long it is willing to wait for receiving responses via that proxy (see Section 5.1.1 and Section 5.2.1).¶
When sending a CoAP group request to a proxy via IP unicast, to be forwarded by the proxy to a targeted group of servers, the client includes the Multicast-Timeout Option into the request. The option value indicates after how much time in seconds the client will stop accepting responses matching its original unicast request, with the exception of notifications if the CoAP Observe Option [RFC7641] is used in the same request. This allows the proxy to stop relaying responses back to the client, if those are received from servers after the indicated amount of time has elapsed.¶
The Multicast-Timeout Option is of class U in terms of OSCORE processing (see Section 4.1 of [RFC8613]).¶
The Response-Forwarding Option defined in this section has the properties summarized in Figure 2, which extends Table 4 of [RFC7252]. The option is intended only for inclusion in CoAP responses, and builds on the Base-Uri option from Section 3 of [I-D.bormann-coap-misc].¶
Since the option is intended only for responses, the column "N" indicates a dash for "not applicable".¶
+------+---+---+---+---+------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+------------+--------+--------+---------+
| | | | | | | | | |
| TBD2 | | | - | | Response- | (*) | 10-25 | (none) |
| | | | | | Forwarding | | | |
| | | | | | | | | |
+------+---+---+---+---+------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
(*) See below.
This document specifically defines how this option is used by a proxy that can perform proxied CoAP group requests.¶
Upon receiving a response to such request from a server, the proxy includes the Response-Forwarding Option into the response sent to the origin client (see Section 5). The proxy uses the option to indicate the addressing information where the client can send an individual request intended to that origin server.¶
In particular, the client can use the addressing information specified in the option to identify the response originator and possibly send it individual requests later on, either directly, or indirectly via the proxy, as unicast requests.¶
The option value is set to the byte serialization of the CBOR array 'tp_info' defined in Section 4.2.1 of [I-D.ietf-core-observe-multicast-notifications], including only the set of elements 'srv_addr'. In turn, the set includes the integer 'tp_id' identifying the used transport protocol, and further elements whose number, format and encoding depend on the value of 'tp_id'.¶
The value of 'tp_id' MUST be taken from the "Value" column of the "CoAP Transport Information" registry defined in Section 16.5 of [I-D.ietf-core-observe-multicast-notifications]. The elements of 'srv_addr' following 'tp_id' are specified in the corresponding entry of the Registry, under the "Server Addr" column.¶
If the server is reachable through CoAP transported over UDP, the 'tp_info' array includes the following elements, encoded as defined in Section 4.2.1.1 of [I-D.ietf-core-observe-multicast-notifications].¶
'srv_port': a CBOR unsigned integer or the CBOR simple value "null" (0xf6). This element MAY be present.¶
If present as a CBOR unsigned integer, it has as value the destination UDP port number to use for individual requests to the server.¶
If present as the CBOR simple value "null" (0xf6), the client MUST assume that the same port number specified in the group URI of the original unicast CoAP group request sent to the proxy (see Section 5.1.1) can be used for individual requests to the server.¶
If not present, the client MUST assume that the default port number 5683 defined in [RFC7252] can be used as the destination UDP port number for individual requests to the server.¶
The CDDL notation [RFC8610] provided below describes the 'tp_info' CBOR array using the format defined above.¶
tp_info = [
tp_id : 1, ; UDP as transport protocol
srv_host : #6.260(bstr), ; IP address where to reach the server
? srv_port : uint / null ; Port number where to reach the server
]
¶
At present, 'tp_id' is expected to take only value 1 (UDP) when using forward proxies, UDP being the only currently available transport for CoAP to work over IP multicast. While additional multicast-friendly transports may be defined in the future, other current tranport protocols can still be useful in applications relying on a reverse-proxy (see Section 6).¶
The rest of this section considers the new values of 'tp_id' registered by this document (see Section 11.2), and specifies:¶
The Response-Forwarding Option is of class U in terms of OSCORE processing (see Section 4.1 of [RFC8613]).¶
This document defines some values used as transport protocol identifiers, whose respective new entries are included in the "CoAP Transport Information" registry defined in Section 16.5 of [I-D.ietf-core-observe-multicast-notifications].¶
For each of these values, the following table summarizes the elements specified under the "Srv Addr" and "Req Info" columns of the registry, together with their CBOR encoding and short description.¶
While not listed here for brevity, the element 'tp_id' is always present as a CBOR integer in the element set "Srv Addr".¶
+----------+-------------+----------+--------------+---------------+ | 'tp_id' | Element Set | Element | CBOR Type | Description | | Values | | | | | +----------+-------------+----------+--------------+---------------+ | 2, 3, 4, | Srv Addr | srv_host | #6.260(bstr) | Address of | | 5, 6 | | | (*) | the server | | | +----------+--------------+---------------+ | | | srv_port | uint / null | Port number | | | | | | of the server | | +-------------+----------+--------------+---------------+ | | Req Info | cli_host | #6.260(bstr) | Address of | | | | | (*) | the client | | | +----------+--------------+---------------+ | | | cli_port | uint | Port number | | | | | | of the client | +----------+-------------+----------+--------------+---------------+ * The CBOR byte string is tagged and identified by the CBOR tag 260 "Network Address (IPv4 or IPv6 or MAC Address)".¶
If the 'srv_port' element of the 'tp_info' array is not present, the client MUST assume the following value as port number where to send individual requests intended to the server, based on the value of 'tp_id'.¶
In this section, the word "proxy" is not limited to forward-proxies. Instead, it comprises also reverse-proxies and HTTP-to-CoAP proxies.¶
This document assumes that the following requirements are fulfilled.¶
REQ2. The proxy MUST identify a client sending a unicast group request to be proxied, in order to verify whether the client is allowed-listed to do so. For example, this can rely on one of the following security associations.¶
This document defines how to achieve the following objectives.¶
This section specifies the steps of the signaling protocol.¶
This section defines the operations performed by the client, for sending a request targeting a group of servers via the proxy.¶
The client proceeds according to the following steps.¶
The client MUST retain the Token value used for this original unicast request beyond the reception of a first CoAP response matching with it. To this end, the client follows the same rules for Token retention defined for multicast CoAP requests in Section 3.1.5 of [I-D.ietf-core-groupcomm-bis].¶
In particular, the client picks an amount of time T that it is fine to wait for before freeing up the Token value. Specifically, the value of T MUST be such that:¶
The client MUST include the Multicast-Timeout Option defined in Section 2 into the unicast request to send to the proxy. The option value specifies an amount of time T' < T. The difference (T - T') should be at least the expected worst-case round-trip time between the client and the proxy.¶
The client can specify T' = 0 as option value, thus indicating to be not interested in receiving responses from the origin servers through the proxy. In such a case, the client SHOULD also include a No-Response Option [RFC7967] with value 26 (suppress all response codes), if it supports the option.¶
Consistently, if the unicast request to send to the proxy already included a No-Response Option with value 26, the client SHOULD specify T' = 0 as value of the Multicast-Timeout Option.¶
The exact method that the client uses to estimate the worst-case processing times and round-trip delays mentioned above is out of the scope of this document. However, such a method is expected to be already used by the client when generally determining an appropriate Token lifetime and reuse interval.¶
When using CoAP Observe [RFC7641], the client follows what is specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis], with the difference that it sends a unicast request to the proxy, to be forwarded to the group of servers, as defined in Section 5.1.1 of this document.¶
Furthermore, the client especially follows what is specified in Section 5 of [RFC7641], i.e., it registers its interest to be an observer with the proxy, as if it was communicating with the servers.¶
This section defines the operations performed by the proxy, when receiving a request to forward to a group of servers.¶
Upon receiving the request from the client, the proxy proceeds according to the following steps.¶
The proxy verifies the presence of the Multicast-Timeout Option, as a confirmation that the client is fine to receive multiple CoAP responses matching with the same original request.¶
If the Multicast-Timeout Option is not present, the proxy MUST stop processing the request and MUST reply to the client with a 4.00 (Bad Request) response. The response MUST include a Multicast-Timeout Option with an empty (zero-length) value, indicating that the Multicast-Timeout Option was missing and has to be included in the request. As per Section 5.9.2 of [RFC7252] The response SHOULD include a diagnostic payload.¶
The proxy sets a timeout with the value T' retrieved from the Multicast-Timeout Option of the original unicast request.¶
In case T' > 0, the proxy will ignore responses to the forwarded group request coming from servers, if received after the timeout expiration, with the exception of Observe notifications (see Section 5.4).¶
In case T' = 0, the proxy will ignore all responses to the forwarded group request coming from servers.¶
If the proxy supports caching of responses, it can serve the original unicast request also by using cached responses, as per Section 7.¶
When using CoAP Observe [RFC7641], the proxy takes the role of the client and registers its own interest to observe the target resource with the servers as per Section 5 of [RFC7641].¶
When doing so, the proxy especially follows what is specified for the client in Section 3.7 of [I-D.ietf-core-groupcomm-bis], by forwarding the group request to the servers over IP multicast as defined in Section 5.2.1 of this document.¶
This section defines the operations performed by the server, when receiving a group request from the proxy.¶
Upon receiving the request from the proxy, the server proceeds according to the following steps.¶
When using CoAP Observe [RFC7641], the server especially follows what is specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641].¶
This section defines the operations performed by the proxy, when receiving a response matching with a forwarded group request.¶
Upon receiving a response matching with the group request before the amount of time T' has elapsed, the proxy proceeds according to the following steps.¶
The proxy MUST include the Response-Forwarding Option defined in Section 3 into the response. The proxy specifies as option value the addressing information of the server generating the response, encoded as defined in Section 3. In particular:¶
As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is possible that a same server replies with multiple responses to the same group request, i.e., with the same Token. As long as the proxy forwards responses to a group request back to the origin client, the proxy MUST follow the steps defined above and forward also such multiple responses "as they come".¶
Upon timeout expiration, i.e., T' seconds after having sent the group request over IP multicast, the proxy frees up its local Token value associated with that request. Thus, following late responses to the same group request will be discarded and not forwarded back to the client.¶
When using CoAP Observe [RFC7641], the proxy acts as a client registered with the servers, as described earlier in Section 5.2.2.¶
Furthermore, the proxy takes the role of a server when forwarding notifications from origin servers back to the client. To this end, the proxy follows what is specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the following additions.¶
Finally, the proxy SHOULD regularly verify that the client is still interested in receiving observe notifications for a group observation. To this end, the proxy can rely on the same approach discussed for servers in Section 3.7 of [I-D.ietf-core-groupcomm-bis], with more details available in Section 4.5 of [RFC7641].¶
This section defines the operations performed by the client, when receiving a response matching with a request that targeted a group of servers via the proxy.¶
Upon receiving from the proxy a response matching with the original unicast request before the amount of time T has elapsed, the client proceeds according to the following steps.¶
The client identifies the origin server, whose addressing information is specified as value of the Response-Forwarding Option. If the 'srv_port' element of the 'tp_info' array in the Response-Forwarding Option is not present or specifies the CBOR simple value "null" (0xf6), then the client determines the port number where to send unicast requests to the server -- in case this is needed -- as defined in Section 3. In the former case, the assumed default port number depends on the transport protocol specified by the 'tp_id' element of the 'tp_info' array (see Section 3.2).¶
In particular, the client is able to distinguish different responses as originated by different servers. Optionally, the client may contact one or more of those servers individually, i.e., directly (bypassing the proxy) or indirectly (via a proxied unicast request).¶
In order to individually reach an origin server again through the proxy, the client is not required to understand or support the transport protocol indicated in the Response-Forwarding Option, as used between the proxy and the origin server, in case it differs from "UDP" (1). That is, using the IPv4/IPv6 address value and optional port value from the Response-Forwarding Option, the client simply creates the correct URI for the individual request, by means of the Proxy-Uri or Uri-Scheme Option in the unicast request to the proxy. The client uses the transport protocol it knows, and has used before, to send the request to the proxy.¶
As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is possible that the client receives multiple responses to the same group request, i.e., with the same Token, from the same origin server. The client normally processes at the CoAP layer each of those responses from the same origin server, and decides how to exactly handle them depending on its available context information (see Section 3.1.6 of [I-D.ietf-core-groupcomm-bis]).¶
Upon the timeout expiration, i.e., T seconds after having sent the original unicast request to the proxy, the client frees up its local Token value associated with that request. Note that, upon this timeout expiration, the Token value is not eligible for possible reuse yet (see Section 5.1.1). Thus, until the actual amount of time before enabling Token reusage has elapsed, any following late responses to the same request forwarded by the proxy will be discarded, as these are not matching (by Token) with any active request from the client.¶
When using CoAP Observe [RFC7641], the client frees up its Token value only if, after the timeout T expiration, no 2.xx (Success) responses matching with the original unicast request and also including an Observe option have been received.¶
Instead, if at least one such response has been received, the client continues receiving those notifications as forwarded by the proxy, as long as the observation for the target resource of the original unicast request is active.¶
The example in this section refers to the following actors.¶
The origin servers are members of a CoAP group with IP multicast address G_ADDR and port number G_PORT. Also, the origin servers are members of a same application group, and share the same resource /r.¶
The communication between C and P is based on CoAP over UDP, as per [RFC7252]. The communication between P and the origin servers is based on CoAP over UDP and IP multicast, as per [I-D.ietf-core-groupcomm-bis].¶
Finally, 'bstr(X)' denotes a CBOR byte string where its value is the byte serialization of X.¶
C P S1 S2
| | | |
|------------------------->| | |
| Src: C_ADDR:C_PORT | | |
| Dst: P_ADDR:P_PORT | | |
| Proxi-URI { | | |
| coap://G_ADDR:G_PORT/r | | |
| } | | |
| Multicast-Timeout: 60 | | |
| | | |
| | | |
| | Src: P_ADDR:P_PORT | |
| | Dst: G_ADDR:G_PORT | |
| | Uri-Path: /r | |
| |---------------+----->| |
| | \ | |
| | +----------------->|
| | | |
| | /* t = 0 : P starts | |
| | accepting responses | |
| | for this request */ | |
| | | |
| | | |
| |<---------------------| |
| | Src: S1_ADDR:G_PORT | |
| | Dst: P_ADDR:P_PORT | |
| | | |
| | | |
|<-------------------------| | |
| Src: P_ADDR:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S1_ADDR)), | | |
| null /* G_PORT */ | | |
| ] | | |
| } | | |
| |<-----------------------------------|
| | Src: S2_ADDR:S2_PORT |
| | Dst: P_ADDR:P_PORT |
| | | |
| | | |
| | | |
|<-------------------------| | |
| Src: P_ADDR:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S2_ADDR)), | | |
| S2_PORT | | |
| ] | | |
| } | | |
| /* At t = 60, P stops accepting | |
| responses for this request */ | |
| | | |
The use of reverse-proxies in group communication scenarios is defined in Section 3.5.2 of [I-D.ietf-core-groupcomm-bis].¶
This section clarifies how the Multicast-Timeout Option is effective also in such a context, in order for:¶
This practically addresses the addional issues compared to the case with a forward-proxy, as compiled in Section 3.5.2 of [I-D.ietf-core-groupcomm-bis]. A reverse-proxy may also operate without support of the Multicast-Timeout Option, as defined in that section.¶
Appendix A provides examples with a reverse-proxy.¶
If a client sends a CoAP request intended to a group of servers and is aware of actually communicating with a reverse-proxy, then the client SHOULD perform the steps defined in Section 5.1.1. In particular, this results in a request sent to the proxy including a Multicast-Timeout Option.¶
An exception is the case where the reverse-proxy has a pre-configured timeout value T_PROXY, as the default timeout value to use for when to stop accepting responses from the servers, after the reception of the original unicast request from the client. In this case, a client aware of such a configuration MAY omit the Multicast-Timeout Option in the request sent to the proxy.¶
The client processes the CoAP responses forwarded back by the proxy as defined in Section 5.5.¶
If the proxy receives a CoAP request and determines that it should be forwarded to a group of servers over IP multicast, then the proxy performs the steps defined in Section 5.2.¶
In particular, when such a request does not include a Multicast-Timeout Option, the proxy SHOULD explicitly reveal itself as a reverse-proxy, by sending a 4.00 (Bad Request) response including a Multicast-Timeout Option with empty (zero-length) value.¶
An exception is the case where the reverse-proxy has a pre-configured timeout value T_PROXY, as default timeout value to use for when to stop accepting responses from the servers, after the reception of the original unicast request from the client. In this case, the proxy MAY replace the steps 3 and 4 in Section 5.2.1 with the following step.¶
A. The proxy verifies the presence of the Multicast-Timeout Option, as a confirmation that the client is willing to receive multiple CoAP responses matching with the same original request. Then, the proxy performs the following actions.¶
If the Multicast-Timeout option is not present, the proxy checks that, according to its local configuration, both the following conditions hold for the client (which, at this point, has been successfully authenticated).¶
These conditions are expected to hold for clients that are locally registered at the proxy, successfully authenticated and allowed-listed to have their requests proxied to CoAP group URIs.¶
If the proxy is able to successfully assert that both the two conditions hold, then the proxy considers the value T' as equal to T_PROXY and proceeds to step 5.¶
If the proxy is not able to successfully assert that both the two conditions hold, the proxy MUST stop processing the request and MUST reply to the client with a 4.00 (Bad Request) response. The response MUST include a Multicast-Timeout Option with an empty (zero-length) value, indicating that the Multicast-Timeout Option was missing and has to be included in the request. As per Section 5.9.2 of [RFC7252] The response SHOULD include a diagnostic payload.¶
The proxy processes the CoAP responses forwarded back to the client as defined in Section 5.4.¶
A proxy MAY cache responses to a group request, as defined in Section 5.7.1 of [RFC7252]. In particular, the same rules apply to determine the set of request options used as "Cache-Key", and to determine the max-age values offered for responses served from the cache.¶
A cache entry is associated with one server and stores one response from that server, regardless whether it is a response to a unicast request or to a group request. The following two types of requests can produce a hit to a cache entry.¶
A matching request intended to that server, i.e., to the corresponding unicast URI.¶
When the stored response is a response to a unicast request to the server, the unicast URI of the matching request is the same target URI used for the original unicast request.¶
When the stored response is a response to a group request to the CoAP group, the unicast URI of the matching request is the target URI obtained by replacing the authority part of the group URI in the original group request with the transport-layer source address and port number of the response.¶
A matching group request intended to the CoAP group, i.e., to the corresponding group URI.¶
That is, a matching group request produces a hit to multiple cache entries, each of which associated with one of the CoAP servers currently member of the CoAP group.¶
Note that, as per the freshness model defined in Section 7.1, the proxy might serve a group request exclusively from its cached responses only when it knows all the CoAP servers that are current members of the CoAP group and it has a valid cache entry for each of them.¶
When forwarding a GET or FETCH group request to the servers in the CoAP group, the proxy behaves like a CoAP client as defined in Section 3.2 of [I-D.ietf-core-groupcomm-bis], with the following additions.¶
The following subsections define the freshness model and validation model that the proxy uses for cached responses.¶
The proxy relies on the same freshness model defined in Section 3.2.1 of [I-D.ietf-core-groupcomm-bis], by taking the role of a CoAP client with respect to the servers in the CoAP group.¶
In particular, when receiving a unicast group request from the client, the proxy MAY serve it by using exclusively cached responses without forwarding the group request to the servers in the CoAP group, but only if both the following conditions hold.¶
The specific way that the proxy uses to determine the CoAP servers currently members of the target CoAP group is out of scope for this document. As possible examples, the proxy can synchronize with a group manager server; rely on well-known time patterns used in the application or in the network for the addition of new CoAP group members; observe group join requests or IGMP/MLD multicast group join messages, e.g., if embedded in a multicast router.¶
When forwarding the group request to the servers, the proxy may have fresh responses stored in its cache for (some of) those servers. In such a case, the proxy uses (also) those cached responses to serve the original unicast group request, as defined below.¶
The request processing in Section 5.2.1 is extended as follows.¶
After setting the timeout with value T' > 0 in step 6, the proxy checks whether its cache currently stores fresh responses to the group request. For each of such responses, the proxy compares the residual lifetime L of the corresponding cache entry against the value T'.¶
If a cached response X is such that L < T', then the proxy forwards X back to the client at its earliest convenience. Otherwise, the proxy does not forward X back to the client right away, and rather waits for approaching the timeout expiration, as discussed in the next point.¶
The response processing in Section 5.4.1 is extended as follows.¶
Before the timeout with original value T' > 0 expires and the proxy stops accepting responses to the group request, the proxy checks whether it stores in its cache any fresh response X to the group request such that both the following conditions hold.¶
Then, the proxy sends back to the client each response X stored in its cache and selected as above, before the timeout expires.¶
Note that, from the forwarding of the group request until the timeout expiration, the proxy still forwards responses to the group request back to the client "as they come" (see Section 5.4.1). Also, such responses possibly refresh older responses from the same servers that the proxy has stored in its cache, as defined earlier in Section 7.¶
This section defines the revalidation of responses, separately between the proxy and the origin servers, as well as between the origin client and the proxy.¶
The proxy MAY revalidate a cached response by making a GET or FETCH request on the related unicast request URI, i.e., by taking the role of a CoAP client with respect to a server in the CoAP group.¶
As discussed in Section 7.4, this is however not possible for the proxy if communications in the group are secured end-to-end between origin client and origin servers by using Group OSCORE [I-D.ietf-core-oscore-groupcomm].¶
[ TODO¶
It can be actually possible to enable revalidation of responses between proxy and server, also in this case where Group OSCORE is used end-to-end between client and origin servers.¶
Fundamentally, this requires to define the possible use of the ETag option also as an outer option for OSCORE. Thus, in addition to the normal inner ETag, a server can add also an outer ETag option intended to the proxy.¶
Since validation of responses assumes that cacheability of responses is possible in the first place, it would be convenient to define the use of ETag as outer option in [I-D.amsuess-core-cachable-oscore].¶
In case OSCORE is also used between the proxy and an individual origin server as per [I-D.tiloca-core-oscore-capable-proxies], then the outer ETag option would be seamlessly protected with the OSCORE Security Context shared between the proxy and the origin server.¶
The following text can be used to replace the last paragraph above.¶
As discussed in Section 7.4, the following applies when Group OSCORE [I-D.ietf-core-oscore-groupcomm] is used to secure communications end-to-end between the origin client and the origin servers in the group.¶
If a cached response included an outer ETag option intended to the proxy, then the proxy can perform revalidatation of the cached response, by making a request to the unicast URI targeting the server, and including outer ETag Option(s).¶
This is possible also in case the proxy and the origin server use OSCORE to further protect the exchanged request and response, as defined in [I-D.tiloca-core-oscore-capable-proxies]. In such a case, the originally outer ETag option is protected with the OSCORE Security Context shared between the proxy and the origin server, before transferring the message over the communication leg between the proxy and origin server.¶
]¶
When forwarding a group request to the servers in the CoAP group, the proxy MAY revalidate one or more stored responses that it has cached.¶
To this end, the proxy relies on the same validation model defined in Section 3.2.2 of [I-D.ietf-core-groupcomm-bis] and using the ETag Option, by taking the role of a CoAP client with respect to the servers in the CoAP group.¶
As discussed in Section 7.4, this is however not possible for the proxy if communications in the group are secured end-to-end between origin client and origin servers by using Group OSCORE [I-D.ietf-core-oscore-groupcomm].¶
[ TODO¶
See the notes in Section 7.2.1.¶
The following text can be used to replace the last paragraph above.¶
As discussed in Section 7.4, the following applies when Group OSCORE [I-D.ietf-core-oscore-groupcomm] is used to secure communications end-to-end between the origin client and the origin servers in the group.¶
If a cached response included an outer ETag option intended to the proxy, then the proxy can perform revalidatation of the cached response, by making a request to the group URI targeting the CoAP group, and including outer ETag Option(s).¶
This is possible also in case the proxy and the origin servers use Group OSCORE to further protect the exchanged request and response, as defined in [I-D.tiloca-core-oscore-capable-proxies]. In such a case, the originally outer ETag option is protected with the Group OSCORE Security Context shared between the proxy and the origin server, before transferring the message over the communication leg between the proxy and origin server.¶
]¶
A client MAY revalidate the full set of responses to a group request by leveraging the corresponding cache entries at the proxy. To this end, this document defines the new Group-ETag Option.¶
The Group-ETag Option has the properties summarized in Figure 4, which extends Table 4 of [RFC7252]. The Group-ETag Option is elective, safe to forward, part of the cache key, and repeatable.¶
The option is intended for group requests sent to a proxy to be forwarded to the servers in a CoAP group, as well as for the associated responses.¶
+------+---+---+---+---+------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+------------+--------+--------+---------+
| | | | | | | | | |
| TBD3 | | | | x | Group-ETag | opaque | 1-8 | (none) |
| | | | | | | | | |
+------+---+---+---+---+------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
The Group-ETag Option has the same properties of the ETag Option defined in Section 5.10.6 of [RFC7252].¶
The Group-ETag Option is of class U in terms of OSCORE processing (see Section 4.1 of [RFC8613]).¶
A proxy MUST NOT provide this form of validation if it is not in a position to serve a group request by using exclusively cached responses, i.e., without sending the group request to the servers in the CoAP group (see Section 7.1).¶
If the proxy supports this form of response revalidation, the following applies.¶
When sending to the proxy a GET or FETCH request to be forwarded to the servers in the CoAP group, the client MAY include one or more Group-ETag Options. Each option specifies one entity-tag value, applicable to the set J of cache entries that can be hit by the group request.¶
The proxy MAY perform the following actions, in case the group request produces a hit to the cache entry of each CoAP server currently member of the CoAP group, i.e., the set J associated with the group request is "complete".¶
That is, the 2.03 (Valid) response from the proxy indicates to the client that the stored responses idenfied by the entity-tag given in the response's Group-ETag Option can be reused, after updating each of them as described in Section 5.9.1.3 of [RFC7252]. In effect, the client can determine if any of the stored representations from the respective cache entries at the proxy is current, without needing to transfer any of them again.¶
When using Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect communications end-to-end between a client and multiple servers in the group, it is normally not possible for an intermediary proxy to cache protected responses.¶
In fact, when starting from the same plain CoAP message, different clients generate different protected requests to send on the wire. This prevents different clients to generate potential cache hits, and thus makes response caching at the proxy pointless.¶
For application scenarios that use secure group communication, it is still possible to achieve cacheability of responses at proxies, by using the approach defined in [I-D.amsuess-core-cachable-oscore] which is based on Deterministic Requests protected with the pairwise mode of Group OSCORE. This approach is limited to group requests that are safe (in the RESTful sense) to process and do not yield side effects at the server. As for any protected group request, it requires the clients and all the servers in the CoAP group to have already joined the correct OSCORE group.¶
Starting from the same plain CoAP request, this allows different clients in the OSCORE group to deterministically generate a same request protected with Group OSCORE, which is sent to the proxy for being forwarded to the CoAP group. The proxy can now effectively cache the resulting responses from the servers in the CoAP group, since the same plain CoAP request will result again in the same Deterministic Request and thus will produce a cache hit.¶
When caching of Group OSCORE secured responses is enabled at the proxy, the same as defined in Section 7 applies, with respect to cache entries and their lifetimes.¶
Note that different Deterministic Requests result in different cache entries at the proxy. This includes the case where different plain group requests differ only in their set of ETag Options, as defined in Section 3.2.2 of [I-D.ietf-core-groupcomm-bis].¶
That is, even though the servers would produce the same plain CoAP responses in reply to two different Deterministic Requests, those will result in different protected responses to each respective Deterministic Request, hence in different cache entries at the proxy.¶
Thus, given a plain group request, a client needs to reuse the same set of ETag Options, in order to send that group request as a Deterministic Request that can actually produce a cache hit at the proxy. However, while this would prevent the caching at the proxy to be inefficient and unnecessarily redundant, it would also limit the flexibility of end-to-end response revalidation for a client.¶
Response revalidation remains possible end-to-end between the client and the servers in the group, by means of including inner ETag Option(s) as defined in Sections 3.2 and 3.2.2 of [I-D.ietf-core-groupcomm-bis].¶
Furthermore, it remains possible for a client to attempt revalidating responses to a group request from a "complete" set of cache entries at the proxy, by using the Group-ETag Option as defined in Section 7.3.¶
When directly interacting with the servers in the CoAP group to refresh its cache entries, the proxy cannot rely on response revalidation anymore. This applies to both the case where the request is addressed to a single server and sent to the related unicast URI (see Section 7.2.1) or instead is a group request addressed to the CoAP group and sent to the related group URI (see Section 7.2.2).¶
[ TODO¶
See the notes in Section 7.2.1.¶
The following text can be used to replace the last paragraph above.¶
When directly interacting with the servers in the CoAP group to refresh its cache entries, the proxy also remains able to perform response revalidation. That is, if a cached response included an outer ETag option intended to the proxy, then the proxy can perform revalidatation of the cached response, by making a request to the unicast URI addressed to a single server and sent to the related unicast URI (see Section 7.2.1) or a group request addressed to the CoAP group and sent to the related group URI (see Section 7.2.2).¶
]¶
A client may be interested to access a resource at a group of origin servers which is reached through a chain of two or more proxies.¶
That is, these proxies are configured into a chain, where each non-last proxy is configured to forward (group) requests to the next hop towards the origin servers. Also, each non-first proxy is configured to forward back responses to (the previous hop proxy towards) the origin client.¶
This section specifies how the signaling protocol defined in Section 5 is used in that setting. Except for the last proxy before the origin servers, every other proxy in the chain takes the role of client with respect to the next hop towards the origin servers. Also, every proxy in the chain except the first takes the role of server towards the previous proxy closer to the origin client.¶
Accordingly, possible caching of responses at each proxy works as defined in Section 7 and Section 7.4. Also, possible revalidation of responses cached ad each proxy and based on the Group-ETag option works as defined in Section 7.3 and Section 7.4.2.¶
The requirements REQ1 and REQ2 defined in Section 4 MUST be fulfilled for each proxy in the chain. That is, every proxy in the chain has to be explicitly configured (allow-list) to allow proxied group requests from specific senders, and MUST identify those senders upon receiving their group request. For the first proxy in the chain, that sender is the origin client. For each other proxy in the chain, that sender is the previous hop proxy closer to the origin client. In either case, a proxy can identify the sender of a group request by the same means mentioned in Section 4.¶
Upon receiving a group request to be forwarded to a CoAP group URIs, a proxy proceed as follows.¶
If the proxy is the last one in the chain, i.e., it is the last hop before the origin servers, the proxy performs the steps defined in Section 5.2, with no modifications.¶
Otherwise, the proxy performs the steps defined in Section 5.2, with the following differences.¶
At step 4, the proxy rather performs the following actions.¶
In case T' > 0, the proxy picks an amount of time T it is fine to wait for before freeing up its local Token value to use with the next hop towards the origin servers. To this end, the proxy MUST follow what is defined at step 2 of Section 5.1.1 for the origin client, with the following differences.¶
In case T' > 0, the proxy replaces the value of the Multicast-Timeout Option with a new value T'', such that:¶
If the proxy is not able to determine a value T'' that fulfills both the requirements above, the proxy MUST stop processing the request and MUST respond with a 5.05 (Proxying Not Supported) error response to the previous hop proxy closer to the origin client. The proxy SHOULD include a Multicast-Timeout Option, set to the minimum value T' that would be acceptable in the Multicast-Timeout Option of a group request to forward.¶
Upon receiving such an error response, any proxy in the chain MAY send an updated group request to the next hop towards the origin servers, specifying in the Multicast-Timeout Option a value T' greater than in the previous request. If this does not happen, the proxy receiving the error response MUST also send a 5.05 (Proxying Not Supported) error response to the previous hop proxy closer to the origin client. Like the received one, also this error response SHOULD include a Multicast-Timeout Option, set to the minimum value T' acceptable by the proxy sending the error response.¶
At step 6, the proxy sets a timeout with the value T' retrieved from the Multicast-Timeout Option of the request received from the (previous hop proxy closer to the) origin client.¶
In case T' > 0, the proxy will ignore responses to the forwarded group request coming from the (next hop towards the) origin servers, if received after the timeout expiration, with the exception of Observe notifications (see Section 5.4).¶
In case T' = 0, the proxy will ignore all responses to the forwarded group request coming from the (next hop towards the) origin servers.¶
When using CoAP Observe [RFC7641], what is defined in Section 5.2.2 applies for the last proxy in the chain, i.e., the last hop before the origin servers.¶
Any other proxy in the chain acts as a client and registers its own interest to observe the target resource with the next hop towards the origin servers, as per Section 5 of [RFC7641].¶
Upon receiving a response matching with the group request before the amount of time T' has elapsed, the proxy proceeds as follows.¶
If the proxy is the last one in the chain, i.e., it is the last hop before the origin servers, the proxy performs the steps defined in Section 5.4, with no modifications.¶
Otherwise, the proxy performs the steps defined in Section 5.4, with the following differences.¶
As to the possible reception of multiple responses to the same group request from the same (next hop proxy towards the) origin server, the same as defined in Section 5.4.1 applies. That is, as long as the proxy forwards responses to a group request back to the (previous hop proxy closer to the) origin client, the proxy MUST follow the steps above and forward also such multiple responses "as they come".¶
Upon timeout expiration, i.e., T seconds after having forwarded the group request to the next hop towards the origin servers, the proxy frees up its local Token value associated with that request. Thus, following late responses to the same group request will be discarded and not forwarded back to the (previous hop proxy closer to the) origin client.¶
When using CoAP Observe [RFC7641], what is defined in Section 5.4.2 applies for the last proxy in the chain, i.e., the last hop before the origin servers.¶
As to any other proxy in the chain, the following applies.¶
This section defines the components needed to use the signaling protocol specified in this document, when an HTTP client wishes to send a group request to the servers of a CoAP group, via an HTTP-CoAP cross-proxy.¶
The following builds on the mapping of the CoAP request/response model to HTTP and vice versa as defined in Section 10 of [RFC7252], as well as on the additional details about the HTTP-CoAP mapping defined in [RFC8075].¶
Furthermore, the components defined in Section 11 of [RFC8613] are also used to map and transport OSCORE-protected messages over HTTP. This allows an HTTP client to use Group OSCORE end-to-end with the servers in the CoAP group.¶
The HTTP Multicast-Timeout header field (see Section 11.3) is used for carrying the content otherwise specified in the CoAP Multicast-Timeout Option defined in Section 2.¶
Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] and including the core ABNF syntax rule DIGIT (decimal digits) defined by that specification, the HTTP Multicast-Timeout header field value is as follows.¶
Multicast-Timeout = *DIGIT¶
When translating a CoAP message into an HTTP message, the HTTP Multicast-Timeout header field is set with the content of the CoAP Multicast-Timeout Option, or is left empty in case the option is empty.¶
The same applies in the opposite direction, when translating an HTTP message into a CoAP message.¶
The HTTP Response-Forwarding header field (see Section 11.3) is used for carrying the content otherwise specified in the CoAP Response-Forwarding Option defined in Section 3.¶
Using the Uniform Resource Identifier (URI) syntax components defined in [RFC3986], the HTTP Response-Forwarding header field value is as follows.¶
scheme = <scheme, see Section 3.1 of [RFC3986]>¶
authority = <authority, see Section 3.2 of [RFC3986]>¶
Response-Forwarding = scheme "://" authority¶
In particular:¶
When translating a CoAP message into an HTTP message, the HTTP Response-Forwarding header field is set to the URI specified in the CoAP Response-Forwarding Option, as per the rules defined above. In particular, consistently with what is defined in Section 3:¶
When translating an HTTP message into a CoAP message, the CoAP Response-Forwarding Option is set to the URI specified by the HTTP Response-Forwarding header field. In particular, the URI is encoded according to the format specified in Section 3.¶
The HTTP Group-ETag header field (see Section 11.3) is used for carrying the content otherwise specified in the CoAP Group-ETag Option defined in Section 7.3.¶
Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] and including the following core ABNF syntax rules defined by that specification: ALPHA (letters) and DIGIT (decimal digits), the HTTP Group-ETag header field value is as follows.¶
group-etag-char = ALPHA / DIGIT / "-" / "_"¶
Group-ETag = 2*group-etag-char¶
When translating a CoAP message into an HTTP message, the HTTP Group-ETag header field is set to the value of the CoAP Group-ETag Option in base64url (see Section 5 of [RFC4648]) encoding without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515].¶
When translating an HTTP message into a CoAP message, the CoAP Group-ETag Option is set to the value of the HTTP Group-ETag header field decoded from base64url (see Section 5 of [RFC4648]) without padding. Implementation notes for this encoding are given in Appendix C of [RFC7515].¶
The client proceeds according to the following steps.¶
The proxy translates the HTTP request to a CoAP request, as per [RFC8075]. The additional rules for HTTP messages with the HTTP Multicast-Timeout header field and HTTP Group-ETag header field are defined in Section 9.1 and Section 9.3, respectively.¶
Once translated the HTTP request into a CoAP request, the proxy MUST perform the steps defined in Section 5.2. If the proxy supports caching of responses, it can serve the unicast request also by using cached responses as per Section 7, considering the CoAP request above as the potentially matching request.¶
In addition, in case the HTTP Multicast-Timeout header field had value 0, the proxy replies to the client with an HTTP response with status code 204 (No Content), right after forwarding the group request to the group of servers.¶
Upon receiving a CoAP response matching with the group request before the amount of time T' > 0 has elapsed, the proxy includes the Response-Forwarding Option in the response, as per step 1 of Section 5.4.1. Then, the proxy translates the CoAP response to an HTTP response, as per Section 10.1 of [RFC7252] and [RFC8075], as well as Section 11.2 of [RFC8613] if Group OSCORE is used end-to-end between the client and servers. The additional rules for CoAP messages specifying the Response-Forwarding Option are defined in Section 9.2.¶
After that, the proxy stores the resulting HTTP response until the timeout with original value T' > 0 expires. If, before then, the proxy receives another response to the same group request from the same CoAP server, the proxy performs the steps above, and stores the resulting HTTP response by superseding the currently stored one from that server.¶
When the timout expires, if no responses have been received from the servers, the proxy replies to the client's original unicast group request with an HTTP response with status code 204 (No Content).¶
Otherwise, the proxy relays to the client all the collected and stored HTTP responses to the group request, according to the following steps.¶
For each stored individual HTTP response RESP, the proxy prepares a corresponding batch part to include in the HTTP batch response, such that:¶
When it receives an HTTP response as a reply to the original unicast group request, the client proceeds as follows.¶
For each individual HTTP response RESP, the client performs the following steps.¶
Similarly to step 3 in Section 5.5.1, the client identifies the origin server that originated the CoAP response correspoding to the HTTP response RESP, by means of its addressing information specified as value of the HTTP Response-Forwarding header field. This allows the client to distinguish different individual HTTP responses as corresponding to different CoAP responses from the servers in the CoAP group.¶
The examples in this section build on Section 5.6, with the difference that the origin client C is an HTTP client and the proxy P is an HTTP-CoAP cross-proxy. The examples are simply illustrative and are not to be intended as a test vector.¶
The following is an example of unicast group request sent by C to P. The URI mapping and notation are based on the "Simple Form" defined in Section 5.4.1 of [RFC8075].¶
POST https://proxy.url/hc/?target_uri=coap://G_ADDR:G_PORT/ HTTP/1.1 Content-Length: <REQUEST_TOTAL_CONTENT_LENGTH> Content-Type: text/plain Multicast-Timeout: 60 Body: Do that!¶
The following is an example of HTTP batch response sent by P to C, as a reply to the client's original unicast group request.¶
HTTP/1.1 200 OK Content-Length: <BATCH_RESPONSE_TOTAL_CONTENT_LENGTH> Content-Type: multipart/mixed; boundary=batch_foo_bar --batch_foo_bar Content-Type: application/http HTTP/1.1 200 OK Content-Type: text/plain Content-Length: <INDIVIDUAL_RESPONSE_1_CONTENT_LENGTH> Response-Forwarding: coap://S1_ADDR:G_PORT Body: Done! --batch_foo_bar Content-Type: application/http HTTP/1.1 200 OK Content-Type: text/plain Content-Length: <INDIVIDUAL_RESPONSE_2_CONTENT_LENGTH> Response-Forwarding: coap://S2_ADDR:S2_PORT Body: More than done! --batch_foo_bar--¶
[ TODO¶
The proxy might still be able to forward back individual responses to the client in a streamed fashion.¶
Individual responses can be forwarded back one by one as they come (like a CoAP-to-CoAP proxy does), or as soon as a certain amount of them have been received from the servers.¶
This can be achieved by combining the Content-Type multipart/mixed used in the previous sections with the Transfer-Coding "chunked" specified in RFC 9112.¶
The above applies to HTTP 1.1, while HTTP/2 has its own mechanisms for data streaming.¶
]¶
In case an HTTP-to-CoAP proxy acts specifically as a reverse-proxy, the same principles defined in Section 6 applies, as specified below.¶
If an HTTP client sends a request intended to a group of servers and is aware of actually communicating with a reverse-proxy, then the client SHOULD perform the steps defined in Section 9.4. In particular, this results in a request sent to the proxy including a Multicast-Timeout header field.¶
An exception is the case where the reverse-proxy has a pre-configured timeout value T_PROXY, as the default timeout value to use for when to stop accepting responses from the servers, after the reception of the original unicast request from the client. In this case, a client aware of such a configuration MAY omit the Multicast-Timeout header field in the request sent to the proxy.¶
The client processes the HTTP response forwarded back by the proxy as defined in Section 9.7.¶
If the proxy receives a request and determines that it should be forwarded to a group of servers over IP multicast, then the same as defined in Section 9.5 applies, with the following difference.¶
Once translated the HTTP request into a CoAP request, the proxy performs what is defined in Section 6.2. Note that, in this case, the condition COND_2 always holds, since the proxy is going to send to the client at most one response, i.e., the HTTP batch response (see Section 9.6).¶
The proxy processes the HTTP response sent to the client as defined in Section 9.6.¶
The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document.¶
When a chain of proxies is used (see Section 8), the secure communication between any two adjacent hops is independent.¶
When Group OSCORE is used for end-to-end secure group communication between the origin client and the origin servers, this security association is unaffected by the possible presence of a proxy or a chain of proxies.¶
Furthermore, the following additional considerations hold.¶
As per the requirement REQ2 (see Section 4), the client has to authenticate to the proxy when sending a group request to forward. This leverages an established security association between the client and the proxy, that the client uses to protect the group request, before sending it to the proxy.¶
If the group request is (also) protected end-to-end between the client and the servers using the group mode of Group OSCORE, the proxy can act as external signature checker (see Section 8.5 of [I-D.ietf-core-oscore-groupcomm]) and authenticate the client by successfully verifying the signature embedded in the group request. However, this requires that, for each client to authenticate, the proxy stores the authentication credential and public key included therin used by that client in the OSCORE group. This in turn would require a form of active synchronization between the proxy and the Group Manager for that group [I-D.ietf-core-oscore-groupcomm].¶
Nevertheless, the client and the proxy SHOULD still rely on a full-fledged pairwise secure association. In addition to ensuring the integrity of group requests sent to the proxy (see Section 10.2, Section 10.3 and Section 10.4), this prevents the proxy from forwarding replayed group requests with a valid signature, as possibly injected by an active, on-path adversary.¶
The same considerations apply when a chain of proxies is used (see Section 8), with each proxy but the last one in the chain acting as client with the next hop towards the origin servers.¶
The Multicast-Timeout Option is of class U for OSCORE [RFC8613]. Hence, also when Group OSCORE is used between the client and the servers [I-D.ietf-core-oscore-groupcomm], a proxy is able to access the option value and retrieve the timeout value T', as well as to remove the option altogether before forwarding the group request to the servers. When a chain of proxies is used (see Section 8), this also allows each proxy but the last one in the chain to update the option value, as an indication for the next hop towards the origin servers (see Section 8.1).¶
The security association between the client and the proxy MUST provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to remove the option or alter its content, before the group request reaches the proxy. Removing the option would otherwise result in not forwarding the group request to the servers. Instead, altering the option content would result in the proxy accepting and forwarding back responses for an amount of time different than the one actually indicated by the client.¶
The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to simply access the option content, and thus learn for how long the client is willing to receive responses from the servers in the group via the proxy. This may in turn be used to perform a more efficient, selective suppression of responses from the servers.¶
When the client protects the unicast request sent to the proxy using OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy.¶
The same considerations above about security associations apply when a chain of proxies is used (see Section 8), with each proxy but the last one in the chain acting as client with the next hop towards the origin servers.¶
The Response-Forwarding Option is of class U for OSCORE [RFC8613]. Hence, also when Group OSCORE is used between the client and the servers [I-D.ietf-core-oscore-groupcomm], the proxy that has forwarded the group request to the servers is able to include the option into a server response, before forwarding this response back to the (previous hop proxy closer to the) origin client.¶
Since the security association between the client and the proxy provides message integrity, any further intermediaries between the two as well as any on-path active adversaries are not able to undetectably remove the Response-Forwarding Option from a forwarded server response. This ensures that the client can correctly distinguish the different responses and identify their corresponding origin server.¶
When the proxy protects the response forwarded back to the client using OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or (D)TLS, message integrity is achieved in the leg between the client and the proxy.¶
The same considerations above about security associations apply when a chain of proxies is used (see Section 8), with each proxy but the last one in the chain acting as client with the next hop towards the origin servers.¶
The Group-ETag Option is of class U for OSCORE [RFC8613]. Hence, also when Group OSCORE is used between the client and the servers [I-D.ietf-core-oscore-groupcomm], a proxy is able to access the option value and use it to possibly perform response revalidation at its cache entries associated with the servers in the CoAP group, as well as to remove the option altogether before forwarding the group request to the servers. When a chain of proxies is used (see Section 8), this also allows each proxy but the last one in the chain to update the option value, to possibly ask the next hop towards the origin servers to perform response revalidation at its cache entries.¶
The security association between the client and the proxy MUST provide message integrity, so that further intermediaries between the two as well as on-path active adversaries are not able to remove the option or alter its content, before the group request reaches the proxy. Removing the option would otherwise result in the proxy not performing response revalidation at its cache entries associated with the servers in the CoAP group, even though that was what the client asked for.¶
Altering the option content in a group request would result in the proxy replying with 2.05 (Content) responses conveying the full resource representations from its cache entries, rather than with a single 2.03 (Valid) response. Instead, altering the option content in a 2.03 (Valid) or 2.05 (Content) response would result in the client wrongly believing that the already stored or the just received representation, respectively, is also the current one, as per the entity value of the tampered Group-ETag Option.¶
The security association between the client and the proxy SHOULD also provide message confidentiality. Otherwise, any further intermediaries between the two as well as any on-path passive adversaries would be able to simply access the option content, and thus learn the rate and pattern according to which the group resource in question changes over time, as inferable from the entity values read over time.¶
When the client protects the unicast request sent to the proxy using OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or (D)TLS, both message integrity and message confidentiality are achieved in the leg between the client and the proxy.¶
The same considerations above about security associations apply when a chain of proxies is used (see Section 8), with each proxy but the last one in the chain acting as client with the next hop towards the origin servers.¶
When caching of Group OSCORE secured responses is enabled at the proxy, the same as defined in Section 7 applies, with respect to cache entries and the way they are maintained.¶
Consistently with what is discussed in Section 10.1, an HTTP client has to authenticate to the HTTP-to-CoAP proxy, and they SHOULD rely on a full-fledged pairwise secure association. This can rely on a TLS [RFC8446] channel as also recommended in Section 12.1 of [RFC8613] for when OSCORE is used with HTTP, or on a pairwise OSCORE [RFC8613] Security Context between the client and the proxy as defined in [I-D.tiloca-core-oscore-capable-proxies].¶
[ TODO¶
Revisit security considerations from [RFC8075]¶
]¶
This document has the following actions for IANA.¶
IANA is asked to enter the following option numbers to the "CoAP Option Numbers" registry within the "CoRE Parameters" registry group.¶
+--------+---------------------+-------------------+ | Number | Name | Reference | +--------+---------------------+-------------------+ | TBD1 | Multicast-Timeout | [[this document]] | +--------+---------------------+-------------------+ | TBD2 | Response-Forwarding | [[this document]] | +--------+---------------------+-------------------+ | TBD3 | Group-ETag | [[this document]] | +--------+---------------------+-------------------+¶
IANA is asked to add the following entries to the "CoAP Transport Information" registry defined in Section 16.5 of [I-D.ietf-core-observe-multicast-notifications].¶
+------------+-------------+-------+----------+-----------+-----------+ | Transport | Description | Value | Srv Addr | Req Info | Reference | | Protocol | | | | | | +------------+-------------+-------+----------+-----------+-----------+ | UDP | UDP with | 2 | tp_id | token | [This | | secured | DTLS is | | srv_host | cli_host | document] | | with DTLS | used as per | | srv_port | ?cli_port | | | | RFC8323 | | | | | +------------+-------------+-------+----------+-----------+-----------+ | TCP | TCP is used | 3 | tp_id | token | [This | | | as per | | srv_host | cli_host | document] | | | RFC8323 | | srv_port | ?cli_port | | +------------+-------------+-------+----------+-----------+-----------+ | TCP | TCP with | 4 | tp_id | token | [This | | secured | TLS is | | srv_host | cli_host | document] | | with TLS | used as per | | srv_port | ?cli_port | | | | RFC8323 | | | | | +------------+-------------+-------+----------+-----------+-----------+ | WebSockets | WebSockets | 5 | tp_id | token | [This | | | are used as | | srv_host | cli_host | document] | | | per RFC8323 | | srv_port | ?cli_port | | +------------+-------------+-------+----------+-----------+-----------+ | WebSockets | WebSockets | 6 | tp_id | token | [This | | secured | with TLS | | srv_host | cli_host | document] | | with TLS | are used as | | srv_port | ?cli_port | | | | per RFC8323 | | | | | +------------+-------------+-------+----------+-----------+-----------+¶
IANA is asked to enter the following HTTP header fields to the "Message Headers" registry.¶
+---------------------+----------+----------+-----------+ | Header Field Name | Protocol | Status | Reference | +---------------------+----------+----------+-----------+ | Multicast-Timeout | http | standard | [This | | | | | document] | +---------------------+----------+----------+-----------+ | Response-Forwarding | http | standard | [This | | | | | document] | +---------------------+----------+----------+-----------+ | Group-ETag | http | standard | [This | | | | | document] | +---------------------+----------+----------+-----------+¶
The examples in this section refer to the following actors.¶
The origin servers are members of a CoAP group with IP multicast address G_ADDR and port number G_PORT. Also, the origin servers are members of a same application group, and share the same resource /r.¶
The communication between C and P is based on CoAP over TCP, as per [RFC8323]. The group communication between P and the origin servers is based on CoAP over UDP and IP multicast, as per [I-D.ietf-core-groupcomm-bis].¶
Finally, 'bstr(X)' denotes a CBOR byte string where its value is the byte serialization of X.¶
The example shown in Figure 5 considers a reverse-proxy P that provides access to both the whole group of servers {S1,S2} and also to each of those servers individually. The client C may not have a way to reach the servers directly (e.g., P is acting as a firewall). After the client C has received two responses to its group request sent via the proxy, it selects one server (S1) and requests another resource from it in unicast, again via the proxy.¶
In particular:¶
Note that this type of reverse-proxy only requires one unicast IP address (P_ADDR) for the proxy, so it is well scalable to a large number of servers Sx. The type of reverse-proxy in the example in Appendix A.2 requires an additional IP address for each server Sx and also for each CoAP group that it supports.¶
C P S1 S2
| | | |
|----------------------------->| /* C embeds the | |
| Src: C_ADDR:C_PORT | group URI into its | |
| Dst: p.example.com:P_PORT | request to the | |
| Uri-Path: | proxy */ | |
| /cp/coap://group1.com/r | | |
| Multicast-Timeout: 60 | | |
| | | |
| | Src: P_ADDR:P_PORT | |
| | Dst: G_ADDR:G_PORT | |
| | Uri-Path: /r | |
| |---------------+----->| |
| | \ | |
| | +----------------->|
| | | |
| | | |
| | /* t = 0 : P starts | |
| | accepting responses | |
| | for this request */ | |
| | | |
| | | |
| |<---------------------| |
| | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | |
| | | |
| | | |
|<-----------------------------| | |
| Src: p.example.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [3, /*CoAP over TCP*/ | | |
| #6.260(bstr(S1_ADDR)), | | |
| S1_PORT | | |
| ] | | |
| } | | |
| | | |
| | | |
| |<-----------------------------------|
| | Src: S2_ADDR:S2_PORT |
| | Dst: P_ADDR:P_PORT |
| | | |
|<-----------------------------| | |
| Src: p.example.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [3, /*CoAP over TCP*/ | | |
| #6.260(bstr(S2_ADDR)), | | |
| S2_PORT | | |
| ] | | |
| } | | |
| | | |
| /* At t = 60, P stops accepting | |
| responses for this request */ | |
| | | |
| | | |
|----------------------------->| /* Request intended | |
| Src: C_ADDR:C_PORT | only to S1, via | |
| Dst: p.example.com:P_PORT | proxy P */ | |
| Uri-Path: /cp/coap:// | | |
| [S1_ADDR]:S1_PORT/r2 | | |
| | | |
| | Src: P_ADDR:P_PORT | |
| | Dst: S1_ADDR:S1_PORT | |
| | Uri-Path: /r2 | |
| |--------------------->| |
| | | |
| | | |
| |<---------------------| |
| | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | |
| | | |
|<-----------------------------| | |
| Src: P_ADDR:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| | | |
The example shown in Figure 6 considers a reverse-proxy that stands in for both the whole group of servers {S1,S2} and for each of those servers Sx. The client C may not have a way to reach the servers directly (e.g., P is acting as a firewall). After the client C has received two responses to its group request sent via the proxy, it selects one server (S1) and requests at a later time the same resource from it in unicast, again via the proxy.¶
In particular:¶
Note that this type of reverse-proxy implementation requires the proxy to use (potentially) a large number of distinct IP addresses, hence it is not very scalable. Instead, the type of reverse-proxy shown in the example in Appendix A.1 uses only one IPv6 unicast address to provide access to all servers and all CoAP groups.¶
C P S1 S2
| | | |
|----------------------------->| /* C is not aware | |
| Src: C_ADDR:C_PORT | that P is in fact | |
| Dst: group1.com:P_PORT | a reverse-proxy */ | |
| Uri-Path: /r | | |
| | | |
|<-----------------------------| | |
| Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| 4.00 Bad Request | | |
| Multicast-Timeout: (empty) | | |
| Payload: "Please use | | |
| Multicast-Timeout" | | |
| | | |
|----------------------------->| | |
| Src: C_ADDR:C_PORT | | |
| Dst: group1.com:P_PORT | | |
| Multicast-Timeout: 60 | | |
| Uri-Path: /r | | |
| | | |
| | | |
| | Src: P_ADDR:P_PORT | |
| | Dst: G_ADDR:G_PORT | |
| | Uri-Path: /r | |
| |---------------+----->| |
| | \ | |
| | +----------------->|
| | | |
| | | |
| | /* t = 0 : P starts | |
| | accepting responses | |
| | for this request */ | |
| | | |
| | | |
| |<---------------------| |
| | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | |
| | | |
| | | |
|<-----------------------------| | |
| Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [3, /*CoAP over TCP*/ | | |
| #6.260(bstr(D1_ADDR)), | | |
| D1_PORT | | |
| ] | | |
| } | | |
| | | |
| |<-----------------------------------|
| | Src: S2_ADDR:S2_PORT |
| | Dst: P_ADDR:P_PORT |
| | | |
|<-----------------------------| | |
| Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [3, /*CoAP over TCP*/ | | |
| #6.260(bstr(D2_ADDR)), | | |
| D2_PORT | | |
| ] | | |
| } | | |
| | | |
| /* At t = 60, P stops accepting | |
| responses for this request */ | |
| | | |
... ... /* time passes */ ... ...
| | | |
|----------------------------->| /* Request intended | |
| Src: C_ADDR:C_PORT | only to S1 for same | |
| Dst: D1_ADDR:D1_PORT | resource /r */ | |
| Uri-Path: /r | | |
| | | |
| | Src: P_ADDR:P_PORT | |
| | Dst: S1_ADDR:S1_PORT | |
| | Uri-Path: /r | |
| |--------------------->| |
| | | |
| | | |
| |<---------------------| |
| | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | |
| | | |
|<-----------------------------| | |
| Src: D1_ADDR:D1_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| | | |
The example shown in Figure 7 builds on the example in Appendix A.2.¶
However, it considers a reverse-proxy that stands in for only the whole group of servers, but not for each individual server Sx.¶
The final exchange between C and S1 occurs with CoAP over UDP.¶
C P S1 S2
| | | |
|----------------------------->| /* C is not aware | |
| Src: C_ADDR:C_PORT | that P is in fact | |
| Dst: group1.com:P_PORT | a reverse-proxy */ | |
| Uri-Path: /r | | |
| | | |
|<-----------------------------| | |
| Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| 4.00 Bad Request | | |
| Multicast-Timeout: (empty) | | |
| Payload: "Please use | | |
| Multicast-Timeout" | | |
| | | |
| | | |
|----------------------------->| | |
| Src: C_ADDR:C_PORT | | |
| Dst: group1.com:P_PORT | | |
| Multicast-Timeout: 60 | | |
| Uri-Path: /r | | |
| | | |
| | Src: P_ADDR:P_PORT | |
| | Dst: G_ADDR:G_PORT | |
| | Uri-Path: /r | |
| |---------------+----->| |
| | \ | |
| | +----------------->|
| | | |
| | | |
| | /* t = 0 : P starts | |
| | accepting responses | |
| | for this request */ | |
| | | |
| | | |
| |<---------------------| |
| | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | |
| | | |
|<-----------------------------| | |
| Dst: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S1_ADDR)), | | |
| S1_PORT | | |
| ] | | |
| } | | |
| | | |
| |<-----------------------------------|
| | Src: S2_ADDR:S2_PORT |
| | Dst: P_ADDR:P_PORT |
| | | |
|<-----------------------------| | |
| Dst: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S2_ADDR)), | | |
| S2_PORT | | |
| ] | | |
| } | | |
| | | |
| | | |
| /* At t = 60, P stops accepting | |
| responses for this request */ | |
| | | |
... ... /* time passes */ ... ...
| | | |
|---------------------------------------------------->| |
| Src: C_ADDR:C_PORT | /* Request intended | |
| Dst: S1.ADDR:S1_PORT | only to S1 for same | |
| Uri-Path: /r | resource /r */ | |
| | | |
|<----------------------------------------------------| |
| Src: S1.ADDR:S1_PORT | | |
| Dst: C_ADDR:C_PORT | | |
| | | |
The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran Selander for their comments and feedback.¶
The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home (Grant agreement 952652).¶