Proxy Operations for CoAP Group Communication
draft-tiloca-core-groupcomm-proxy-03

Document Type Active Internet-Draft (individual)
Authors Marco Tiloca  , Esko Dijk 
Last updated 2021-02-22
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
CoRE Working Group                                             M. Tiloca
Internet-Draft                                                   RISE AB
Intended status: Standards Track                                 E. Dijk
Expires: August 26, 2021                               IoTconsultancy.nl
                                                       February 22, 2021

             Proxy Operations for CoAP Group Communication
                  draft-tiloca-core-groupcomm-proxy-03

Abstract

   This document specifies the operations performed by a forward-proxy
   or reverse-proxy, when using the Constrained Application Protocol
   (CoAP) in group communication scenarios.  Such CoAP proxy processes a
   single request, sent by a CoAP client over unicast, and distributes
   the request over IP multicast to a group of CoAP servers.  It then
   collects the individual responses from these CoAP servers and sends
   these responses to the CoAP client such that the client is able to
   distinguish the responses and their origin servers through addressing
   information.

Status of This Memo

   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 August 26, 2021.

Copyright Notice

   Copyright (c) 2021 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

Tiloca & Dijk            Expires August 26, 2021                [Page 1]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The Multicast-Signaling Option  . . . . . . . . . . . . . . .   4
   3.  The Response-Forwarding Option  . . . . . . . . . . . . . . .   5
     3.1.  Encoding of Server Address  . . . . . . . . . . . . . . .   7
     3.2.  Default Values of the Server Port Number  . . . . . . . .   8
   4.  Requirements and Objectives . . . . . . . . . . . . . . . . .   8
   5.  Protocol Description  . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Request Sending at the Client . . . . . . . . . . . . . .  10
       5.1.1.  Request Sending . . . . . . . . . . . . . . . . . . .  10
       5.1.2.  Supporting Observe  . . . . . . . . . . . . . . . . .  11
     5.2.  Request Processing at the Proxy . . . . . . . . . . . . .  11
       5.2.1.  Request Processing  . . . . . . . . . . . . . . . . .  12
       5.2.2.  Supporting Observe  . . . . . . . . . . . . . . . . .  13
     5.3.  Request and Response Processing at the Server . . . . . .  13
       5.3.1.  Request and Response Processing . . . . . . . . . . .  13
       5.3.2.  Supporting Observe  . . . . . . . . . . . . . . . . .  13
     5.4.  Response Processing at the Proxy  . . . . . . . . . . . .  13
       5.4.1.  Response Processing . . . . . . . . . . . . . . . . .  13
       5.4.2.  Supporting Observe  . . . . . . . . . . . . . . . . .  14
     5.5.  Response Processing at the Client . . . . . . . . . . . .  15
       5.5.1.  Response Processing . . . . . . . . . . . . . . . . .  15
       5.5.2.  Supporting Observe  . . . . . . . . . . . . . . . . .  16
     5.6.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  16
   6.  Reverse-Proxies . . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.  Processing on the Client Side . . . . . . . . . . . . . .  19
     6.2.  Processing on the Proxy Side  . . . . . . . . . . . . . .  19
   7.  Chain of Proxies  . . . . . . . . . . . . . . . . . . . . . .  19
     7.1.  Request Processing at the Proxy . . . . . . . . . . . . .  20
       7.1.1.  Supporting Observe  . . . . . . . . . . . . . . . . .  21
     7.2.  Response Processing at the Proxy  . . . . . . . . . . . .  22
       7.2.1.  Supporting Observe  . . . . . . . . . . . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  23
     8.1.  Client Authentication . . . . . . . . . . . . . . . . . .  23
     8.2.  Multicast-Signaling Option  . . . . . . . . . . . . . . .  24
     8.3.  Response-Forwarding Option  . . . . . . . . . . . . . . .  25
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  CoAP Option Numbers Registry  . . . . . . . . . . . . . .  25
     9.2.  CoAP Transport Information Registry . . . . . . . . . . .  25
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26

Tiloca & Dijk            Expires August 26, 2021                [Page 2]
Internet-Draft  Proxy Operations for Group Communication   February 2021

     10.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     10.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Appendix A.  Using OSCORE Between Client and Proxy  . . . . . . .  28
     A.1.  Protecting the Request  . . . . . . . . . . . . . . . . .  29
     A.2.  Verifying the Request . . . . . . . . . . . . . . . . . .  30
     A.3.  Protecting the Response . . . . . . . . . . . . . . . . .  30
     A.4.  Verifying the Response  . . . . . . . . . . . . . . . . .  30
   Appendix B.  Examples with Reverse-Proxy  . . . . . . . . . . . .  31
     B.1.  Example 1 . . . . . . . . . . . . . . . . . . . . . . . .  31
     B.2.  Example 2 . . . . . . . . . . . . . . . . . . . . . . . .  33
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1.  Introduction

   The Constrained Application Protocol (CoAP) [RFC7252] allows the
   presence of forward-proxies and reverse-proxies, as intermediary
   entities supporting clients to perform requests on their behalf.

   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.4 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 a single unicast request to the
   proxy, which the proxy forwards to a group of servers over IP
   multicast.  Later on, the proxy delivers back to the client multiple
   responses to the original unicast request.  As defined by [RFC7252],
   the multiple responses are delivered to the client inside separate
   CoAP messages, all matching (by Token) to the client's original
   unicast request.  A possible alternative approach of performing
   aggregation of responses into a single CoAP response would require a
   specific aggregation content-format, which is not available yet.
   Both these approaches have open issues.

   This specification considers the former approach, i.e. the proxy
   forwards the individual responses to a CoAP group request back to the
   client.  The described method addresses all the related issues raised
   in Section 3.4 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 per origin server.  It also
   signals for how long it is willing to wait for responses.  Also, when
   forwarding a response to the client, the proxy indicates the

Tiloca & Dijk            Expires August 26, 2021                [Page 3]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   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.

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

2.  The Multicast-Signaling Option

   The Multicast-Signaling 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-Signaling
   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-5   | (none)  |
     |      |   |   |   |   | Signaling  |        |        |         |
     |      |   |   |   |   |            |        |        |         |
     +------+---+---+---+---+------------+--------+--------+---------+
                C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

                 Figure 1: The Multicast-Signaling Option.

   This document specifically defines how this option is used by a
   client in a CoAP request, to indicate to a forward-proxy its support

Tiloca & Dijk            Expires August 26, 2021                [Page 4]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   for and interest in receiving multiple responses to a proxied CoAP
   group request, i.e. one per 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).

   The client, when sending a CoAP group request to a proxy via IP
   unicast, to be forwarded by the proxy to a targeted group of servers,
   includes the Multicast-Signaling Option into the request.  The option
   value indicates after what time period 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.  Signaling the time period allows the
   proxy to stop forwarding responses back to the client, that are
   received from servers after the end of the time period.

   The Multicast-Signaling Option is of class U in terms of OSCORE
   processing (see Section 4.1 of [RFC8613]).

3.  The Response-Forwarding Option

   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-  |  (*)   |  9-24  | (none)  |
     |      |   |   |   |   | Forwarding |        |        |         |
     |      |   |   |   |   |            |        |        |         |
     +------+---+---+---+---+------------+--------+--------+---------+
                C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

     (*) See below.

                 Figure 2: The Response-Forwarding Option.

   This document specifically defines how this option is used by a proxy
   that can perform proxied CoAP group communication requests.

   Upon receiving a response to such request from a server, the proxy
   includes the Response-Forwarding Option into the response sent to the

Tiloca & Dijk            Expires August 26, 2021                [Page 5]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   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 CoAP unicast requests.

   The option value is set to the byte serialization of the CBOR array
   'tp_info' defined in Section 2.2.1 of
   [I-D.tiloca-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 14.4 of
   [I-D.tiloca-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 2.2.1.1 of
   [I-D.tiloca-core-observe-multicast-notifications].

   o  'tp_id': the CBOR integer with value 1.  This element MUST be
      present.

   o  'srv_host': a CBOR byte string, encoding the unicast IP address of
      the server.  This element is tagged and identified by the CBOR tag
      260 "Network Address (IPv4 or IPv6 or MAC Address)".  This element
      MUST be present.

   o  'srv_port': a CBOR unsigned integer or the CBOR simple value Null.
      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, 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.

Tiloca & Dijk            Expires August 26, 2021                [Page 6]
Internet-Draft  Proxy Operations for Group Communication   February 2021

      If not present, 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.

   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 9.2), and specifies:

   o  The encoding for the elements of 'tp_info' following 'tp_id' (see
      Section 3.1).

   o  The port number assumed by the client if 'srv_port' in 'tp_info'
      specifies the CBOR simple value Null (see Section 3.2).

   The Response-Forwarding Option is of class U in terms of OSCORE
   processing (see Section 4.1 of [RFC8613]).

3.1.  Encoding of Server Address

   This specification defines some values used as transport protocol
   identifiers, whose respective new entries are included in the "CoAP
   Transport Information" Registry defined in Section 14.4 of
   [I-D.tiloca-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".

Tiloca & Dijk            Expires August 26, 2021                [Page 7]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   +----------+-------------+----------+--------------+---------------+
   | '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'.

   o  If 'tp_id' is equal to 2, i.e. CoAP over UDP secured with DTLS,
      the default port number 5684 as defined in [RFC7252].

   o  If 'tp_id' is equal to 3, i.e. CoAP over TCP, the default port
      number 5683 as defined in [RFC8323].

   o  If 'tp_id' is equal to 4, i.e. CoAP over TCP secured with TLS, the
      default port number 5684 as defined in [RFC8323].

   o  If 'tp_id' is equal to 5, i.e. CoAP over WebSockets, the default
      port number 80 as defined in [RFC8323].

   o  If 'tp_id' is equal to 6, i.e. CoAP over WebSockets secured with
      TLS, the default port number 443 as defined in [RFC8323].

4.  Requirements and Objectives

   This specification assumes that the following requirements are
   fulfilled.

Tiloca & Dijk            Expires August 26, 2021                [Page 8]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   o  REQ1.  The CoAP proxy is explicitly configured (allow-list) to
      allow proxied CoAP group requests from specific client(s).

   o  REQ2.  The CoAP proxy MUST identify a client sending a CoAP group
      request, in order to verify whether the client is allowed-listed
      to do so.  For example, this can rely on one of the following.

      *  A TLS [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13] channel
         between the client and the proxy, where the client has been
         authenticated during the secure channel establishment.

      *  A pairwise OSCORE Security Context between the client and the
         proxy, as described in Appendix A.

   o  REQ3.  If secure, end-to-end communication is required between the
      client and the servers in the CoAP group, exchanged messages MUST
      be protected by using Group OSCORE
      [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5.2 of
      [I-D.ietf-core-groupcomm-bis].  This requires the client and the
      servers to have previously joined the correct OSCORE group, for
      instance by using the approach described in
      [I-D.ietf-ace-key-groupcomm-oscore].  The correct OSCORE group to
      join can be pre-configured or alternatively discovered, for
      instance by using the approach described in
      [I-D.tiloca-core-oscore-discovery].

   This specification defines how to achieve the following objectives.

   o  OBJ1.  The CoAP proxy gets an indication from the client that it
      is in fact interested in and capable to receive multiple responses
      to its unicast request containing a CoAP group URI.

   o  OBJ2.  The CoAP proxy learns how long it should wait for responses
      to a proxied request, before starting to ignore following
      responses (except for notifications, if a CoAP Observe Option is
      used [RFC7641]).

   o  OBJ3.  The CoAP proxy returns individual unicast responses to the
      client, each of which matches the original unicast request made to
      the proxy.

   o  OBJ4.  The CoAP client is able to distinguish the different
      responses to the original unicast request, as well as their
      corresponding origin servers.

   o  OBJ5.  The CoAP client is enabled to optionally contact one or
      more of the responding origin servers in the future, either
      directly or via the CoAP proxy.

Tiloca & Dijk            Expires August 26, 2021                [Page 9]
Internet-Draft  Proxy Operations for Group Communication   February 2021

5.  Protocol Description

   This section specifies the steps of the signaling protocol.

5.1.  Request Sending at the Client

   This section defines the operations that the client performs for
   sending a request addressed to a group of servers via the CoAP proxy.

5.1.1.  Request Sending

   The client proceeds according to the following steps.

   1.  The client prepares a request addressed to the CoAP proxy.  The
       request specifies the group URI as a string in the Proxi-URI
       option, or by using the Proxy-Scheme option with the group URI
       constructed from the URI-* options (see Section 2.3.3 of
       [I-D.ietf-core-groupcomm-bis]).

   2.  The client MUST retain the Token value used for this original
       unicast request beyond the reception of a first response matching
       it.  To this end, the client follows the same rules for Token
       retention defined for multicast requests in Section 2.3.1 of
       [I-D.ietf-core-groupcomm-bis].

       In particular, the client picks an amount of time T it is fine to
       wait for before freeing up the Token value.  Specifically, the
       value of T MUST be such that:

       *  T < T_r , where T_r is the amount of time that the client is
          fine to wait for before potentially reusing the Token value.
          Note that T_r MUST NOT be less than MIN_TOKEN_REUSE_TIME
          defined in Section 2.3.1 of [I-D.ietf-core-groupcomm-bis].

       *  T should be at least the expected worst-case time taken by the
          request and response processing on the forward-proxy and on
          the servers in the addressed CoAP group.

       *  T should be at least the expected worst-case round-trip delay
          between the client and the forward-proxy plus the worst-case
          round-trip delay between the proxy and any one of the origin
          servers.

   3.  The client MUST include the Multicast-Signaling 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 forward-proxy.

Tiloca & Dijk            Expires August 26, 2021               [Page 10]
Internet-Draft  Proxy Operations for Group Communication   February 2021

       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-Signaling Option.

   4.  The client processes the request as defined in
       [I-D.ietf-core-groupcomm-bis], and also as in
       [I-D.ietf-core-oscore-groupcomm] when secure group communication
       is used between the client and the servers.

   5.  If OSCORE is used to protect the leg between the client and the
       proxy (see REQ2 in Section 4), the client (further) protects the
       unicast request resulting at the end of step 4.  In particular,
       the client uses the pairwise OSCORE Security Context it has with
       the proxy, as described in Appendix A.1.

   6.  The client sends the request to the proxy as a unicast CoAP
       message.

   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 specification.  However, such a method is expected to
   be already used by the client when generally determining a good Token
   lifetime and reuse interval.

5.1.2.  Supporting Observe

   When using CoAP Observe [RFC7641], the client follows what is
   specified in Section 2.3.5 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 specification.

   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.

5.2.  Request Processing at the Proxy

   This section defines the operations that the proxy performs when
   receiving a request addressed to a group of servers.

Tiloca & Dijk            Expires August 26, 2021               [Page 11]
Internet-Draft  Proxy Operations for Group Communication   February 2021

5.2.1.  Request Processing

   Upon receiving the request from the client, the proxy proceeds
   according to the following steps.

   1.  If OSCORE is used to protect the leg between the client and the
       proxy (see REQ2 in Section 4), the proxy decrypts the request
       using the pairwise OSCORE Security Context it has with the
       client, as described in Appendix A.2.

   2.  The proxy identifies the client, and verifies that the client is
       in fact allowed-listed to have its requests proxyied to CoAP
       group URIs.

   3.  The proxy verifies the presence of the Multicast-Signaling
       Option, as a confirmation that the client is fine to receive
       multiple responses matching the same original request.

       If the Multicast-Signaling 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-Signaling Option with an empty (zero-length) value,
       specifying that the Multicast-Signaling 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.

   4.  The proxy retrieves the value T' from the Multicast-Signaling
       Option, and then removes the option from the client's request.

   5.  The proxy forwards the client's request to the group of servers.
       In particular, the proxy sends it as a CoAP group request over IP
       multicast, addressed to the group URI specified by the client.

   6.  The proxy sets a timeout with the value T' retrieved from the
       Multicast-Signaling 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.

Tiloca & Dijk            Expires August 26, 2021               [Page 12]
Internet-Draft  Proxy Operations for Group Communication   February 2021

5.2.2.  Supporting Observe

   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 2.3.5 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 specification.

5.3.  Request and Response Processing at the Server

   This section defines the operations that the server performs when
   receiving a group request from the proxy.

5.3.1.  Request and Response Processing

   Upon receiving the request from the proxy, the server proceeds
   according to the following steps.

   1.  The server processes the group request as defined in
       [I-D.ietf-core-groupcomm-bis], and also as in
       [I-D.ietf-core-oscore-groupcomm] when secure group communication
       is used between the client and the server.

   2.  The server processes the response to be forwarded back to the
       client as defined in [I-D.ietf-core-groupcomm-bis], and also as
       in [I-D.ietf-core-oscore-groupcomm] when secure group
       communication is used between the client and the server.

5.3.2.  Supporting Observe

   When using CoAP Observe [RFC7641], the server especially follows what
   is specified in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis] and
   Section 5 of [RFC7641].

5.4.  Response Processing at the Proxy

   This section defines the operations that the proxy performs when
   receiving a response matching a forwarded group request.

5.4.1.  Response Processing

   Upon receiving a response matching the group request before the
   amount of time T' has elapsed, the proxy proceeds according to the
   following steps.

Tiloca & Dijk            Expires August 26, 2021               [Page 13]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   1.  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:

       *  The 'srv_addr' element of the 'srv_info' array MUST specify
          the server IPv6 address if the multicast request was destined
          for an IPv6 multicast address, and MUST specify the server
          IPv4 address if the multicast request was destined for an IPv4
          address.

       *  If present, the 'srv_port' element of the 'srv_info' array
          MUST specify the port number of the server as the source port
          number of the response.  This element MUST be present if the
          source port number of the response differs from the port
          number specified in the group URI of the original unicast CoAP
          group request (see Section 5.1.1).  Otherwise, the 'srv_port'
          element MAY be omitted.

   2.  If OSCORE is used to protect the leg between the client and the
       proxy (see REQ2 in Section 4), the proxy (further) protects the
       response using the pairwise OSCORE Security Context it has with
       the client, as described in Appendix A.3.

   3.  The proxy forwards the response back to the client.

   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 to that request.  Thus, following late responses to the
   same group request will be discarded and not forwarded back to the
   client.

5.4.2.  Supporting Observe

   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 2.3.5 of
   [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the
   following additions.

   o  At step 1 in Section 5.4, the proxy includes the Response-
      Forwarding Option in every notification, including non-2.xx
      notifications resulting in removing the proxy from the list of
      observers of the origin server.

Tiloca & Dijk            Expires August 26, 2021               [Page 14]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   o  The proxy frees up its Token value used for a group observation
      only if, after the timeout expiration, no 2.xx (Success) responses
      matching the group request and also including an Observe option
      have been received from any origin server.  After that, as long as
      observations are active with servers in the group for the target
      resource of the group request, notifications from those servers
      are forwarded back to the client, as defined in Section 5.4, and
      the Token value used for the group observation is not freed during
      this time.

   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 2.3.5 of
   [I-D.ietf-core-groupcomm-bis], with more details available in
   Section 4.5 of [RFC7641].

5.5.  Response Processing at the Client

   This section defines the operations that the client performs when
   receiving a response matching a request addressed to a group of
   servers via the CoAP proxy.

5.5.1.  Response Processing

   Upon receiving from the proxy a response matching the original
   unicast request before the amount of time T has elapsed, the client
   proceeds according to the following steps.

   1.  The client processes the response as defined in
       [I-D.ietf-core-groupcomm-bis].

   2.  If OSCORE is used to protect the leg between the client and the
       proxy (see REQ2 in Section 4), the client decrypts the response
       using the pairwise OSCORE Security Context it has with the proxy,
       as described in Appendix A.4.

   3.  If secure group communication is used end-to-end between the
       client and the servers, the client processes the response,
       possibly as outcome of step 2, as defined in
       [I-D.ietf-core-oscore-groupcomm].

   4.  The client identifies the origin server, whose addressing
       information is specified as value of the Response-Forwarding
       Option.  If the port number is omitted in the value of the
       Response-Forwarding Option, the client MUST assume that the port
       number where to send unicast requests to the server - in case
       this is needed - is the same port number specified in the group

Tiloca & Dijk            Expires August 26, 2021               [Page 15]
Internet-Draft  Proxy Operations for Group Communication   February 2021

       URI of the original unicast CoAP group request sent to the proxy
       (see Section 5.1.1).

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

   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 to 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) any active request from the client.

5.5.2.  Supporting Observe

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

5.6.  Example

   The example in this section refers to the following actors.

   o  One origin client C, with address C_ADDR and port number C_PORT.

Tiloca & Dijk            Expires August 26, 2021               [Page 16]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   o  One proxy P, with address P_ADDR and port number P_PORT.

   o  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   |             |
   |                          |                      |             |

Tiloca & Dijk            Expires August 26, 2021               [Page 17]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   |                          |                      |             |
   |<-------------------------|                      |             |
   | 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 */        |             |
   |                          |                      |             |

              Figure 3: Workflow example with a forward-proxy

6.  Reverse-Proxies

   The use of reverse-proxies in group communication scenarios is
   defined in Section 3.4.2 of [I-D.ietf-core-groupcomm-bis].

   This section clarifies how the Multicast-Signaling Option is
   effective also in such a context, in order for:

   o  The proxy to explictly reveal itself as a reverse-proxy to the
      client.

   o  The client to indicate to the proxy of being aware that it is
      communicating with a reverse-proxy, and for how long it is willing
      to receive responses to a proxied request.

   This practically addresses the addional issues compared to the case
   with a forward-proxy, as compiled in Section 3.4.2 of
   [I-D.ietf-core-groupcomm-bis].  A reverse-proxy may also operate
   without support of the Multicast-Signaling Option, as defined in that
   section.

Tiloca & Dijk            Expires August 26, 2021               [Page 18]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   Appendix B provides examples with a reverse-proxy.

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 an
   Multicast-Signaling Option with empty (zero-length) value.

7.  Chain of Proxies

   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 CoAP (group) requests to the next
   hop towards the origin servers.  Also, each non-first proxy is
   configured to forward back CoAP 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.

   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,

Tiloca & Dijk            Expires August 26, 2021               [Page 19]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   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.

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

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

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

Tiloca & Dijk            Expires August 26, 2021               [Page 20]
Internet-Draft  Proxy Operations for Group Communication   February 2021

          +  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 request to
          forward.

          Upon receiving such an error response, any proxy in the chain
          MAY send an updated 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.

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

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

7.1.1.  Supporting Observe

   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.

Tiloca & Dijk            Expires August 26, 2021               [Page 21]
Internet-Draft  Proxy Operations for Group Communication   February 2021

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

7.2.  Response Processing at the Proxy

   Upon receiving a response matching 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.

   o  The proxy skips step 1.  In particular, the proxy MUST NOT remove,
      alter or replace the Response-Forwarding Option.

   o  At steps 2-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.

   Upon timeout expiration, i.e. T seconds after having sent 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.

7.2.1.  Supporting Observe

   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.

   o  The proxy acts as a client registered with the next hop towards
      the origin servers, as described earlier in Section 7.1.1.

   o  The proxy takes the role of a server when forwarding notifications
      from the next hop to the origin servers back to the (previous hop
      proxy closer to the) origin client, as per Section 5 of [RFC7641].

   o  The proxy frees up its Token value used for a group observation
      only if, after the timeout expiration, no 2.xx (Success) responses
      matching the group request and also including an Observe option

Tiloca & Dijk            Expires August 26, 2021               [Page 22]
Internet-Draft  Proxy Operations for Group Communication   February 2021

      have been received from the next hop towards the origin servers.
      After that, as long as the observation for the target resource of
      the group request is active with the next hop towards the origin
      servers in the group, notifications from that hop are forwarded
      back to the (previous hop proxy closer to the) origin client, as
      defined in Section 7.2.

   o  The proxy SHOULD regularly verify that the (previous hop proxy
      closer to the) origin client is still interested in receiving
      observe notifications for a group observation.  To this end, the
      proxy can rely on the same approach defined in Section 4.5 of
      [RFC7641].

8.  Security Considerations

   The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi
   s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document.

   When a chain of proxies is used (see Section 7), 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.

8.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 counter
   signature embedded in the group request.  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 8.2 and

Tiloca & Dijk            Expires August 26, 2021               [Page 23]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   Section 8.3), this prevents the proxy from forwarding replayed group
   requests with a valid counter signature, as possibly injected by an
   active, on-path adversary.

   The same considerations apply when a chain of proxies is used (see
   Section 7), with each proxy but the last one in the chain acting as
   client with the next hop towards the origin servers.

8.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 7), 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 7.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, further intermediaries
   between the two as well as 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 (further) protects the unicast request sent to the
   proxy using OSCORE (see Appendix A) and/or with (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 7), with each proxy but the
   last one in the chain acting as client with the next hop towards the
   origin servers.

Tiloca & Dijk            Expires August 26, 2021               [Page 24]
Internet-Draft  Proxy Operations for Group Communication   February 2021

8.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 or 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 (further) protects the response forwarded back to the
   client using OSCORE (see Appendix A) and/or with (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 7), with each proxy but the
   last one in the chain acting as client with the next hop towards the
   origin servers.

9.  IANA Considerations

   This document has the following actions for IANA.

9.1.  CoAP Option Numbers Registry

   IANA is asked to enter the following option numbers to the "CoAP
   Option Numbers" registry defined in [RFC7252] within the "CoRE
   Parameters" registry.

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

9.2.  CoAP Transport Information Registry

   IANA is asked to enter the following entries to the "CoAP Transport
   Information" Registry defined in Section 14.4 of
   [I-D.tiloca-core-observe-multicast-notifications].

Tiloca & Dijk            Expires August 26, 2021               [Page 25]
Internet-Draft  Proxy Operations for Group Communication   February 2021

 +------------+-------------+-------+----------+-----------+-----------+
 | 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 |       |          |           |           |
 +------------+-------------+-------+----------+-----------+-----------+

10.  References

10.1.  Normative References

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E., Wang, C., and M. Tiloca, "Group Communication
              for the Constrained Application Protocol (CoAP)", draft-
              ietf-core-groupcomm-bis-03 (work in progress), February
              2021.

   [I-D.ietf-core-oscore-groupcomm]
              Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and
              J. Park, "Group OSCORE - Secure Group Communication for
              CoAP", draft-ietf-core-oscore-groupcomm-11 (work in
              progress), February 2021.

Tiloca & Dijk            Expires August 26, 2021               [Page 26]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   [I-D.tiloca-core-observe-multicast-notifications]
              Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini,
              "Observe Notifications as CoAP Multicast Responses",
              draft-tiloca-core-observe-multicast-notifications-05 (work
              in progress), February 2021.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/info/rfc8323>.

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/info/rfc8610>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/info/rfc8613>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

Tiloca & Dijk            Expires August 26, 2021               [Page 27]
Internet-Draft  Proxy Operations for Group Communication   February 2021

10.2.  Informative References

   [I-D.bormann-coap-misc]
              Bormann, C. and K. Hartke, "Miscellaneous additions to
              CoAP", draft-bormann-coap-misc-27 (work in progress),
              November 2014.

   [I-D.ietf-ace-key-groupcomm-oscore]
              Tiloca, M., Park, J., and F. Palombini, "Key Management
              for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
              oscore-10 (work in progress), February 2021.

   [I-D.ietf-tls-dtls13]
              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", draft-ietf-tls-dtls13-41 (work in progress),
              February 2021.

   [I-D.tiloca-core-oscore-discovery]
              Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE
              Groups with the CoRE Resource Directory", draft-tiloca-
              core-oscore-discovery-08 (work in progress), February
              2020.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC7967]  Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
              Bose, "Constrained Application Protocol (CoAP) Option for
              No Server Response", RFC 7967, DOI 10.17487/RFC7967,
              August 2016, <https://www.rfc-editor.org/info/rfc7967>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

Appendix A.  Using OSCORE Between Client and Proxy

   This section describes how OSCORE is used to protect messages
   exchanged by an origin client and a proxy, using their pairwise
   OSCORE Security Context.

   This is especially convenient for the communication scenario
   addressed in this document, when the origin client already supports
   and uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect
   messages end-to-end with the origin servers.

Tiloca & Dijk            Expires August 26, 2021               [Page 28]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   In particular, a CoAP message is protected with the OSCORE Security
   Context between the origin client and the proxy, as considering both
   of them to be terminal endpoints for the exchange in question.  This
   requires that some CoAP options in that message are processed as
   class E, although originally defined as class U or class I.

   This generally applies to all options that the proxy needs to
   understand and process in its exchange with the origin client.
   Further options can be added and treated as class U, e.g. related to
   routing information.  The rest of this section hightlights the most
   relevant CoAP options to consider in this respect.

   The following focuses on the origin client originating the group
   request and a single proxy as its immediate next hop.  When a chain
   of proxies is used (see Section 7), the same independently applies
   between each pair of proxies in the chain, where the proxy forwarding
   the group request acts as client and the next hop towards the origin
   servers acts as server.

A.1.  Protecting the Request

   Before sending the CoAP request to the proxy, the origin client
   protects it using the pairwise OSCORE Security Context it has with
   the proxy.

   To this end, the origin client processes the CoAP request as defined
   in Section 8.1 of [RFC8613], with the following differences.

   o  The Proxy-Uri option, if present, is not decomposed and recomposed
      as defined in Section 4.1.3.3 of [RFC8613].

   o  The following options, if present, are processed as Class E.

      *  Proxy-Uri, Proxy-Scheme, Uri-Host and Uri-Port, defined in
         [RFC7252].

      *  OSCORE, defined in [RFC8613], which is present if Group OSCORE
         is used between the origin client and the origin servers, to
         achieve end-to-end secure group communication.

      *  Multicast-Signaling Option, defined in Section 2 of this
         specification.

   As per [RFC8613], the resulting message includes an outer OSCORE
   Option, which reflects the usage of the pairwise OSCORE Security
   Context between the origin client and the proxy.

Tiloca & Dijk            Expires August 26, 2021               [Page 29]
Internet-Draft  Proxy Operations for Group Communication   February 2021

A.2.  Verifying the Request

   The proxy verifies the CoAP request as defined in Section 8.2 of
   [RFC8613].  Note that the Multicast-Signaling Option is retrieved
   during the decryption process, and added to the decrypted request.

   If secure group communication is also used between the origin client
   and the origin servers, the request resulting from the previous step
   and to be forwarded to the origin servers is also already protected
   with Group OSCORE [I-D.ietf-core-oscore-groupcomm].  Consequently, it
   includes an outer OSCORE Option, which reflects the usage of the
   group OSCORE Security Context between the origin client and the
   origin servers.

A.3.  Protecting the Response

   The proxy protects the CoAP response received from a server, using
   the pairwise OSCORE Security Context it has with the origin client.

   To this end, the proxy processes the CoAP response as defined in
   Section 8.3 of [RFC8613], with the difference that the OSCORE Option,
   if present, is processed as Class E.  This is the case if Group
   OSCORE is used between the origin client and the origin servers, to
   achieve end-to-end secure group communication.

   Furthermore, the Response-Forwarding Option defined in Section 3 of
   this specification is also processed as Class E.

   As per [RFC8613], the resulting message to be forwarded back to the
   origin client includes an outer OSCORE Option, which reflects the
   usage of the pairwise OSCORE Security Context between the origin
   client and the proxy.

A.4.  Verifying the Response

   The origin client verifies the CoAP response received from the proxy
   as defined in Section 8.4 of [RFC8613].  Note that, the Response-
   Forwarding Option is retrieved during the decryption process, and
   added to the decrypted response.

   If secure group communication is also used between the origin client
   and the origin servers, the response resulting from the previous step
   is protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm].
   Consequently, it includes an outer OSCORE Option, which reflects the
   usage of the group OSCORE Security Context between the origin client
   and the origin servers.

Tiloca & Dijk            Expires August 26, 2021               [Page 30]
Internet-Draft  Proxy Operations for Group Communication   February 2021

Appendix B.  Examples with Reverse-Proxy

   The examples in this section refer to the following actors.

   o  One origin client C, with address C_ADDR and port number C_PORT.

   o  One proxy P, with address P_ADDR and port number P_PORT.

   o  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 TCP, as per
   [RFC8323].  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.

B.1.  Example 1

   The example shown in Figure 4 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:

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

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

Tiloca & Dijk            Expires August 26, 2021               [Page 31]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   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                    |                      |             |
   |  ]                           |                      |             |
   | }                            |                      |             |
   |                              |                      |             |

Tiloca & Dijk            Expires August 26, 2021               [Page 32]
Internet-Draft  Proxy Operations for Group Communication   February 2021

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

    Figure 4: Workflow example with reverse-proxy standing in for both
           the whole group of servers and each individual server

B.2.  Example 2

   The example shown in Figure 5 builds on the example in Appendix B.1.

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

Tiloca & Dijk            Expires August 26, 2021               [Page 33]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   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                    |                      |             |
   |  ]                           |                      |             |
   | }                            |                      |             |

Tiloca & Dijk            Expires August 26, 2021               [Page 34]
Internet-Draft  Proxy Operations for Group Communication   February 2021

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

    Figure 5: Workflow example with reverse-proxy standing in for only
      the whole group of servers, but not for each individual server

Acknowledgments

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

Authors' Addresses

Tiloca & Dijk            Expires August 26, 2021               [Page 35]
Internet-Draft  Proxy Operations for Group Communication   February 2021

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   Kista  SE-16440 Stockholm
   Sweden

   Email: marco.tiloca@ri.se

   Esko Dijk
   IoTconsultancy.nl
   \________________\
   Utrecht
   The Netherlands

   Email: esko.dijk@iotconsultancy.nl

Tiloca & Dijk            Expires August 26, 2021               [Page 36]