Proxy Operations for CoAP Group Communication

1.1. Terminology

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

Readers are expected to be familiar with terms and concepts 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].¶

3.1. Encoding of Server Address

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 14.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)".

3.2. Default Values of the Server Port Number

If the 'srv_port' element in the 'tp_info' array specifies the CBOR simple value Null, 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'.¶

• If 'tp_id' is equal to 2, i.e., CoAP over UDP secured with DTLS, the default port number 5684 as defined in [RFC7252].¶
• If 'tp_id' is equal to 3, i.e., CoAP over TCP, the default port number 5683 as defined in [RFC8323].¶
• If 'tp_id' is equal to 4, i.e., CoAP over TCP secured with TLS, the default port number 5684 as defined in [RFC8323].¶
• If 'tp_id' is equal to 5, i.e., CoAP over WebSockets, the default port number 80 as defined in [RFC8323].¶
• If 'tp_id' is equal to 6, i.e., CoAP over WebSockets secured with TLS, the default port number 443 as defined in [RFC8323].¶

5.1. Request Sending at the Client

This section defines the operations performed by the client, for sending a request targeting a group of servers via the proxy.¶

5.2. Request Processing at the Proxy

This section defines the operations performed by the proxy, when receiving a request to forward to a group of servers.¶

5.3. Request and Response Processing at the Server

This section defines the operations performed by the server, when receiving a group request from the proxy.¶

5.4. Response Processing at the Proxy

This section defines the operations performed by the proxy, when receiving a response matching with a forwarded group request.¶

5.5. Response Processing at the Client

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.¶

5.6. Example

The example in this section refers to the following actors.¶

• One origin client C, with address C_ADDR and port number C_PORT.¶
• One proxy P, with address P_ADDR and port number P_PORT.¶
• Two origin servers S1 and S2, where the server Sx has address Sx_ADDR and port number Sx_PORT.¶

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 with value 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-Signaling: 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))  |                      |             |
|  ]                       |                      |             |
| }                        |                      |             |
|                          |<-----------------------------------|
|                          |               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 */        |             |
|                          |                      |             |

6.1. Processing on the Client Side

If a client sends a request intended to a group of servers and is aware of actually communicating with a reverse-proxy, then the client MUST perform the steps defined in Section 5.1.1. In particular, this results in a request sent to the proxy including a Multicast-Signaling Option.¶

The client processes the responses forwarded back by the proxy as defined in Section 5.5.¶

6.2. Processing on the Proxy Side

If the proxy receives a request and determines that it should forward it to a group of servers over IP multicast, then the proxy MUST perform the steps defined in Section 5.2.¶

In particular, when such request does not include a Multicast-Signaling Option, the proxy explicitly reveals itself as a reverse-proxy, by sending a 4.00 (Bad Request) response including a Multicast-Signaling Option with empty (zero-length) value.¶

7.1. Freshness Model

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 proxy knows all the CoAP servers that are currently members of the CoAP group for which the group request is intended to.¶
• The proxy's cache currently stores a fresh response for each of those CoAP servers.¶

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.¶

  • The cache entry E storing X was already existing when the proxy forwarded the group request.¶
  • The proxy has received no response to the forwarded group request from the server associated to E.¶

  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.¶

7.2. Validation Model

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.¶

7.3. Client-Proxy Revalidation with Group Requests

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.¶

• The proxy defines J as a joint set including all the cache entries currently storing fresh responses that satisfy a group request. A set J is "complete" if it includes a valid cache entry for each of the CoAP servers currently members of the CoAP group.¶
• When the set J becomes "complete", the proxy assigns it an entity-tag value. The proxy MUST update the current entity-tag value, when J is "complete" and one of its cache entry is updated.¶
• When forwarding to the client a 2.05 (Content) response to a GET or FETCH group request, the proxy MAY include one Group-ETag Option, in case the set J is "complete". Such a response MUST NOT include more than one Group-ETag Option. The option value specifies the entity-tag value currently associated to the set J.¶

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 to the group request is "complete".¶

• The proxy checks whether the current entity-tag value of the set J matches with one of the entity-tag values specified in the Group-ETag Options of the unicast group request from the client.¶
• In case of positive match, the proxy replies with a single 2.03 (Valid) response. This response has no payload and MUST include one Group-ETag Option, specifying the current entity-tag value of the set J.¶

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.¶

7.4. Caching of End-To-End Protected Responses at Proxies

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.¶

8.1. Request Processing at the Proxy

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 steps 1-3, "client" refers to the origin client for the first proxy in the chain; or to the previous hop proxy closer to the origin client, otherwise.¶

• At step 4, the proxy rather performs the following actions.¶

  1. The proxy retrieves the value T' from the Multicast-Signaling Option, and does not remove the option.¶

  2. 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.¶

     • T MUST be greater than the retrieved value T', i.e., T' < T.¶
     • The worst-case message processing time takes into account all the next hops towards the origin servers, as well as the origin servers themselves.¶
     • The worst-case round-trip delay takes into account all the legs between the proxy and the origin servers.¶

  3. In case T' > 0, the proxy replaces the value of the Multicast-Signaling Option with a new value T'', such that:¶

     • T'' < T. The difference (T - T'') should be at least the expected worst-case round-trip time between the proxy and the next hop towards the origin servers.¶
     • T'' < T'. The difference (T' - T'') should be at least the expected worst-case round-trip time between the proxy and the (previous hop proxy closer to the) origin client.¶

     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-Signaling Option, set to the minimum value T' that would be acceptable in the Multicast-Signaling 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-Signaling 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-Signaling Option, set to the minimum value T' acceptable by the proxy sending the error response.¶

• At step 5, the proxy forwards the request to the next hop towards the origin servers.¶

• At step 6, the proxy sets a timeout with the value T' retrieved from the Multicast-Signaling 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.¶

8.2. Response Processing at the Proxy

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.¶

• The proxy skips step 1. In particular, the proxy MUST NOT remove, alter or replace the Response-Forwarding Option.¶
• At step 2, "client" refers to the origin client for the first proxy in the chain; or to the previous hop proxy closer to the origin client, otherwise.¶

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 to 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.¶

9.1. The HTTP Multicast-Signaling Header Field

The HTTP Multicast-Signaling header field (see Section 11.3) is used for carrying the content otherwise specified in the CoAP Multicast-Signaling 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-Signaling header field value is as follows.¶

Multicast-Signaling = *DIGIT¶

When translating a CoAP message into an HTTP message, the HTTP Multicast-Signaling header field is set with the content of the CoAP Multicast-Signaling 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.¶

9.2. The HTTP Response-Forwarding Header Field

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:¶

• The scheme component indicates the URI scheme otherwise specified in the CoAP Response-Forwarding Option, as per the 'tp_id' element of the 'tp_info' array (see Section 3). That is, the 'tp_id' element with integer value 1 results in the scheme "coap".¶
• The authority component indicates the URI authority otherwise specified in the CoAP Response-Forwarding Option, as per the 'srv_host' and 'srv_port' elements of the 'tp_info' array (see Section 3).¶

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. If the 'srv_port' element of the 'tp_info' array is the CBOR simple value Null, the URI authority of the header field includes a default port number depending on the value of the 'tp_id' element of the 'tp_info' array, as per Section 3.2.¶

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.¶

9.3. The HTTP Group-ETag Header Field

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].¶

9.4. Request Sending at the Client

The client proceeds according to the following steps.¶

1. The client prepares an HTTP request to send to the proxy via IP unicast, and to be forwarded by the proxy to the targeted group of CoAP servers over IP multicast. With reference to Section 5 of [RFC8075], the request is addressed to a Hosting HTTP URI, such that the proxy can extract the Target CoAP URI as the group URI where to forward the request.¶
2. The client determines the amount of time T that it is fine to wait for a response to the request from the proxy. Then, the client determines the amount of time T' < T, where the difference (T - T') should be at least the expected worst-case round-trip time between the client and the proxy.¶
3. If Group OSCORE is used end-to-end between the client and the servers, the client translates the HTTP request into a CoAP request, as per [RFC8075]. Then, the client protects the resulting CoAP request by using Group OSCORE, as defined in [I-D.ietf-core-oscore-groupcomm]. Finally, the protected CoAP request is mapped to HTTP as defined in Section 11.2 of [RFC8613]. Later on, the resulting HTTP request MUST be sent in compliance with the rules in Section 11.1 of [RFC8613].¶
4. The client includes the HTTP Multicast-Signaling header field in the request, specifying T' as its value. The client can specify T' = 0, thus indicating to be not interested in receiving responses from the origin servers through the proxy.¶
5. If the client wishes to revalidate responses to a previous group request from the corresponding cache entries at the proxy (see Section 7.3), the client includes one or multiple HTTP Group-ETag header fields in the request (see Section 9.3), each specifying an entity-tag value like they would in a corresponding CoAP Group E-Tag option.¶
6. The client sends the request to the proxy, as a unicast HTTP message. In particular, the client protects the request according to the security association it has with the proxy.¶

9.5. Request Processing at the Proxy

The proxy translates the HTTP request to a CoAP request, as per [RFC8075]. The additional rules for HTTP messages with the HTTP Multicast-Signaling 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-Signaling 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.¶

9.6. Response Processing at the Proxy

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, the proxy relays to the client all the collected and stored HTTP responses to the group request, according to the following steps.¶

1. The proxy prepares a single HTTP batch response, which MUST have its HTTP Content-Type header field with value multipart/mixed [RFC2046].¶

2. For each stored individual HTTP response RESP, the proxy prepares a corresponding batch part to include in the HTTP batch response, such that:¶

   • The batch part has its own HTTP Content-Type header field with value application/http [RFC7230].¶
   • The body of the batch part is the individual HTTP response RESP, including its status code, headers and body.¶
3. The proxy includes each batch part prepared at step 2 in the HTTP batch response.¶
4. The proxy replies to the client's original unicast group request, by sending the HTTP batch response. When doing so, the proxy protects the response according to the security association it has with the client.¶

9.7. Response Processing at the Client

When it receives an HTTP response as a reply to the original unicast group request, the client proceeds as follows.¶

1. The client decrypts the response, according to the security association it has with the proxy.¶
2. From the resulting HTTP batch response, the client extracts the different batch parts.¶
3. From each of the extracted batch parts, the client extracts the body as one of the individual HTTP response RESP.¶

4. For each individual HTTP response RESP, the client performs the following steps.¶

   • If Group OSCORE is used end-to-end between the client and servers, the client translates the HTTP response RESP into a CoAP response, as per Section 11.3 of [RFC8613]. Then, the client decrypts the resulting CoAP response by using Group OSCORE, as defined in [I-D.ietf-core-oscore-groupcomm]. Finally, the decrypted CoAP response is mapped to HTTP as per Section 10.2 of [RFC7252] as well as [RFC8075]. The additional rules for HTTP messages with the HTTP Response-Forwarding header field are defined in Section 9.2.¶
   • The client delivers to the application the individual HTTP response.¶

   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.¶

9.8. Example

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-Signaling: 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

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

10.1. Client Authentication

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.¶

Note that, if the group request is (also) protected with Group OSCORE, i.e., end-to-end between the client and the servers, the proxy can 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 public key used by that client in the OSCORE group, which 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.¶

10.2. Multicast-Signaling Option

The Multicast-Signaling 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.¶

10.3. Response-Forwarding Option

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.¶

10.4. Group-ETag Option

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 to 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 to 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.¶

10.5. HTTP-CoAP Proxies

[ TODO¶

Revisit security considerations from [RFC8075]¶

]¶

11.1. CoAP Option Numbers Registry

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

+--------+---------------------+-------------------+
| Number |        Name         |     Reference     |
+--------+---------------------+-------------------+
|  TBD1  | Multicast-Signaling | [[this document]] |
+--------+---------------------+-------------------+
|  TBD2  | Response-Forwarding | [[this document]] |
+--------+---------------------+-------------------+
|  TBD3  |     Group-ETag      | [[this document]] |
+--------+---------------------+-------------------+

11.2. CoAP Transport Information Registry

IANA is asked to add the following entries to the "CoAP Transport Information" registry defined in Section 14.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 |       |          |           |           |
+------------+-------------+-------+----------+-----------+-----------+

11.3. Header Field Registrations

IANA is asked to enter the following HTTP header fields to the "Message Headers" registry.¶

+---------------------+----------+----------+-----------+
| Header Field Name   | Protocol | Status   | Reference |
+---------------------+----------+----------+-----------+
| Multicast-Signaling | http     | standard | [This     |
|                     |          |          | document] |
+---------------------+----------+----------+-----------+
| Response-Forwarding | http     | standard | [This     |
|                     |          |          | document] |
+---------------------+----------+----------+-----------+
| Group-ETag          | http     | standard | [This     |
|                     |          |          | document] |
+---------------------+----------+----------+-----------+

A.1. Example 1

The example shown in Figure 5 considers a reverse-proxy that stands in for both the whole group of servers and for each of those servers (e.g., acting as a firewall).¶

In particular:¶

• The address 'group1.com' resolves to P_ADDR. The proxy forwards an incoming request to that address, for any resource i.e., URI path, towards the CoAP group at G_ADDR:G_PORT leaving the URI path unchanged.¶
• The address Dx_ADDR and port number Dx_PORT are used by the proxy, which forwards an incoming request to that address towards the server at Sx_ADDR:Sx_PORT.¶

Note that this type of reverse-proxy implementation requires the proxy to use (potentially) a large number of distinct IP addresses, so it is not very scalable.¶

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-Signaling: (empty) |                      |             |
| Payload: "Please use         |                      |             |
|     Multicast-Signaling"     |                      |             |
|                              |                      |             |
|----------------------------->|                      |             |
| Src: C_ADDR:C_PORT           |                      |             |
| Dst: group1.com:P_PORT       |                      |             |
| Multicast-Signaling: 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 */        |             |
|                              |                      |             |
|                              |                      |             |
|----------------------------->| /* Request intended  |             |
| Src: C_ADDR:C_PORT           | only to S1 */        |             |
| Dst: D1_ADDR:D1_PORT         |                      |             |
| 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           |                      |             |
|                              |                      |             |

A.2. Example 2

The example shown in Figure 6 builds on the example in Appendix A.1.¶

However, it considers a reverse-proxy that stands in for only the whole group of servers, but not for each individual server.¶

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-Signaling: (empty) |                      |             |
| Payload: "Please use         |                      |             |
|     Multicast-Signaling"     |                      |             |
|                              |                      |             |
|                              |                      |             |
|----------------------------->|                      |             |
| Src: C_ADDR:C_PORT           |                      |             |
| Dst: group1.com:P_PORT       |                      |             |
| Multicast-Signaling: 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 */        |             |
|                              |                      |             |
|                              |                      |             |
|                              |                      |             |
|---------------------------------------------------->|             |
| Src: C_ADDR:C_PORT           | /* Request intended  |             |
| Dst: S1.ADDR:S1_PORT         | only to S1 */        |             |
| Uri-Path: /r                 |                      |             |
|                              |                      |             |
|                              |                      |             |
|<----------------------------------------------------|             |
| Src: S1.ADDR:S1_PORT         |                      |             |
| Dst: C_ADDR:C_PORT           |                      |             |
|                              |                      |             |