draft-tiloca-core-groupcomm-proxy-03.txt   draft-tiloca-core-groupcomm-proxy-04.txt 
CoRE Working Group M. Tiloca CoRE Working Group M. Tiloca
Internet-Draft RISE AB Internet-Draft RISE AB
Intended status: Standards Track E. Dijk Updates: 7252 (if approved) E. Dijk
Expires: August 26, 2021 IoTconsultancy.nl Intended status: Standards Track IoTconsultancy.nl
February 22, 2021 Expires: 13 January 2022 12 July 2021
Proxy Operations for CoAP Group Communication Proxy Operations for CoAP Group Communication
draft-tiloca-core-groupcomm-proxy-03 draft-tiloca-core-groupcomm-proxy-04
Abstract Abstract
This document specifies the operations performed by a forward-proxy This document specifies the operations performed by a forward-proxy
or reverse-proxy, when using the Constrained Application Protocol or reverse-proxy, when using the Constrained Application Protocol
(CoAP) in group communication scenarios. Such CoAP proxy processes a (CoAP) in group communication scenarios. Such CoAP proxy processes a
single request, sent by a CoAP client over unicast, and distributes single request, sent by a CoAP client over unicast, and distributes
the request over IP multicast to a group of CoAP servers. It then the request over IP multicast to a group of CoAP servers. It then
collects the individual responses from these CoAP servers and sends collects the individual responses from these CoAP servers and sends
these responses to the CoAP client such that the client is able to these responses to the CoAP client, in a way that allows the client
distinguish the responses and their origin servers through addressing to distinguish the responses and their origin servers through
information. addressing information. This document updates RFC7252.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Constrained RESTful
Environments Working Group mailing list (core@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/core/.
Source for this draft and an issue tracker can be found at
https://gitlab.com/crimson84/draft-tiloca-core-groupcomm-proxy.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 January 2022.
This Internet-Draft will expire on August 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 4 2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 4
3. The Response-Forwarding Option . . . . . . . . . . . . . . . 5 3. The Response-Forwarding Option . . . . . . . . . . . . . . . 5
3.1. Encoding of Server Address . . . . . . . . . . . . . . . 7 3.1. Encoding of Server Address . . . . . . . . . . . . . . . 8
3.2. Default Values of the Server Port Number . . . . . . . . 8 3.2. Default Values of the Server Port Number . . . . . . . . 8
4. Requirements and Objectives . . . . . . . . . . . . . . . . . 8 4. Requirements and Objectives . . . . . . . . . . . . . . . . . 9
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 10
5.1. Request Sending at the Client . . . . . . . . . . . . . . 10 5.1. Request Sending at the Client . . . . . . . . . . . . . . 10
5.1.1. Request Sending . . . . . . . . . . . . . . . . . . . 10 5.1.1. Request Sending . . . . . . . . . . . . . . . . . . . 10
5.1.2. Supporting Observe . . . . . . . . . . . . . . . . . 11 5.1.2. Supporting Observe . . . . . . . . . . . . . . . . . 12
5.2. Request Processing at the Proxy . . . . . . . . . . . . . 11 5.2. Request Processing at the Proxy . . . . . . . . . . . . . 12
5.2.1. Request Processing . . . . . . . . . . . . . . . . . 12 5.2.1. Request Processing . . . . . . . . . . . . . . . . . 12
5.2.2. Supporting Observe . . . . . . . . . . . . . . . . . 13 5.2.2. Supporting Observe . . . . . . . . . . . . . . . . . 13
5.3. Request and Response Processing at the Server . . . . . . 13 5.3. Request and Response Processing at the Server . . . . . . 13
5.3.1. Request and Response Processing . . . . . . . . . . . 13 5.3.1. Request and Response Processing . . . . . . . . . . . 13
5.3.2. Supporting Observe . . . . . . . . . . . . . . . . . 13 5.3.2. Supporting Observe . . . . . . . . . . . . . . . . . 14
5.4. Response Processing at the Proxy . . . . . . . . . . . . 13 5.4. Response Processing at the Proxy . . . . . . . . . . . . 14
5.4.1. Response Processing . . . . . . . . . . . . . . . . . 13 5.4.1. Response Processing . . . . . . . . . . . . . . . . . 14
5.4.2. Supporting Observe . . . . . . . . . . . . . . . . . 14 5.4.2. Supporting Observe . . . . . . . . . . . . . . . . . 15
5.5. Response Processing at the Client . . . . . . . . . . . . 15 5.5. Response Processing at the Client . . . . . . . . . . . . 16
5.5.1. Response Processing . . . . . . . . . . . . . . . . . 15 5.5.1. Response Processing . . . . . . . . . . . . . . . . . 16
5.5.2. Supporting Observe . . . . . . . . . . . . . . . . . 16 5.5.2. Supporting Observe . . . . . . . . . . . . . . . . . 17
5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Reverse-Proxies . . . . . . . . . . . . . . . . . . . . . . . 18 6. Reverse-Proxies . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Processing on the Client Side . . . . . . . . . . . . . . 19 6.1. Processing on the Client Side . . . . . . . . . . . . . . 20
6.2. Processing on the Proxy Side . . . . . . . . . . . . . . 19 6.2. Processing on the Proxy Side . . . . . . . . . . . . . . 20
7. Chain of Proxies . . . . . . . . . . . . . . . . . . . . . . 19 7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Request Processing at the Proxy . . . . . . . . . . . . . 20 7.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 21
7.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 21 7.2. Validation Model . . . . . . . . . . . . . . . . . . . . 23
7.2. Response Processing at the Proxy . . . . . . . . . . . . 22 7.2.1. Proxy-Servers Revalidation with Unicast Requests . . 23
7.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 22 7.2.2. Proxy-Servers Revalidation with Group Requests . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.3. Client-Proxy Revalidation with Group Requests . . . . . . 23
8.1. Client Authentication . . . . . . . . . . . . . . . . . . 23 7.4. Caching of End-To-End Protected Responses at Proxies . . 25
8.2. Multicast-Signaling Option . . . . . . . . . . . . . . . 24 7.4.1. Deterministic Requests to Achieve Cacheability . . . 25
8.3. Response-Forwarding Option . . . . . . . . . . . . . . . 25 7.4.2. Validation of Responses . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Chain of Proxies . . . . . . . . . . . . . . . . . . . . . . 27
9.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 25 8.1. Request Processing at the Proxy . . . . . . . . . . . . . 27
9.2. CoAP Transport Information Registry . . . . . . . . . . . 25 8.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Response Processing at the Proxy . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 26 8.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
Appendix A. Using OSCORE Between Client and Proxy . . . . . . . 28 9.1. Client Authentication . . . . . . . . . . . . . . . . . . 31
A.1. Protecting the Request . . . . . . . . . . . . . . . . . 29 9.2. Multicast-Signaling Option . . . . . . . . . . . . . . . 32
A.2. Verifying the Request . . . . . . . . . . . . . . . . . . 30 9.3. Response-Forwarding Option . . . . . . . . . . . . . . . 33
A.3. Protecting the Response . . . . . . . . . . . . . . . . . 30 9.4. Group-ETag Option . . . . . . . . . . . . . . . . . . . . 33
A.4. Verifying the Response . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Examples with Reverse-Proxy . . . . . . . . . . . . 31 10.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 34
B.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. CoAP Transport Information Registry . . . . . . . . . . 35
B.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.1. Normative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Examples with Reverse-Proxy . . . . . . . . . . . . 38
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] allows the The Constrained Application Protocol (CoAP) [RFC7252] allows the
presence of forward-proxies and reverse-proxies, as intermediary presence of forward-proxies and reverse-proxies, as intermediary
entities supporting clients to perform requests on their behalf. entities supporting clients to perform requests on their behalf.
CoAP supports also group communication over IP multicast CoAP supports also group communication over IP multicast
[I-D.ietf-core-groupcomm-bis], where a group request can be addressed [I-D.ietf-core-groupcomm-bis], where a group request can be addressed
to multiple recipient servers, each of which may reply with an to multiple recipient servers, each of which may reply with an
individual unicast response. As discussed in Section 3.4 of individual unicast response. As discussed in Section 3.5 of
[I-D.ietf-core-groupcomm-bis], this group communication scenario [I-D.ietf-core-groupcomm-bis], this group communication scenario
poses a number of issues and limitations to proxy operations. poses a number of issues and limitations to proxy operations.
In particular, the client sends a single unicast request to the In particular, the client sends a single unicast request to the
proxy, which the proxy forwards to a group of servers over IP proxy, which the proxy forwards to a group of servers over IP
multicast. Later on, the proxy delivers back to the client multiple multicast. Later on, the proxy delivers back to the client multiple
responses to the original unicast request. As defined by [RFC7252], responses to the original unicast request. As defined by [RFC7252],
the multiple responses are delivered to the client inside separate the multiple responses are delivered to the client inside separate
CoAP messages, all matching (by Token) to the client's original CoAP messages, all matching (by Token) to the client's original
unicast request. A possible alternative approach of performing unicast request. A possible alternative approach of performing
aggregation of responses into a single CoAP response would require a aggregation of responses into a single CoAP response would require a
specific aggregation content-format, which is not available yet. specific aggregation content-format, which is not available yet.
Both these approaches have open issues. Both these approaches have open issues.
This specification considers the former approach, i.e. the proxy This specification considers the former approach, i.e., the proxy
forwards the individual responses to a CoAP group request back to the forwards the individual responses to a CoAP group request back to the
client. The described method addresses all the related issues raised 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 in Section 3.5 of [I-D.ietf-core-groupcomm-bis]. To this end, a
dedicated signaling protocol is defined, using two new CoAP options. dedicated signaling protocol is defined, using two new CoAP options.
Using this protocol, the client explicitly confirms its intent to Using this protocol, the client explicitly confirms its intent to
perform a proxied group request and its support for receiving perform a proxied group request and its support for receiving
multiple responses as a result, i.e. one per origin server. It also 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 signals for how long it is willing to wait for responses. Also, when
forwarding a response to the client, the proxy indicates the forwarding a response to the client, the proxy indicates the
addressing information of the origin server. This enables the client addressing information of the origin server. This enables the client
to distinguish multiple, diffent responses by origin and to possibly to distinguish multiple, diffent responses by origin and to possibly
contact one or more of the respective servers by sending individual contact one or more of the respective servers by sending individual
unicast request(s) to the indicated address(es). In doing these unicast request(s) to the indicated address(es). In doing these
follow-up unicast requests, the client may optionally bypass the follow-up unicast requests, the client may optionally bypass the
proxy. proxy.
Furthermore, this document defines a caching model for proxies and
specifies how they can serve a group request by using cached
responses. Therefore, this document updates [RFC7252].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with terms and concepts defined Readers are expected to be familiar with terms and concepts defined
in CoAP [RFC7252], Group Communication for CoAP in CoAP [RFC7252], Group Communication for CoAP
skipping to change at page 5, line 5 skipping to change at page 5, line 25
| | | | | | Signaling | | | | | | | | | | Signaling | | | |
| | | | | | | | | | | | | | | | | | | |
+------+---+---+---+---+------------+--------+--------+---------+ +------+---+---+---+---+------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
Figure 1: The Multicast-Signaling Option. Figure 1: The Multicast-Signaling Option.
This document specifically defines how this option is used by a This document specifically defines how this option is used by a
client in a CoAP request, to indicate to a forward-proxy its support client in a CoAP request, to indicate to a forward-proxy its support
for and interest in receiving multiple responses to a proxied CoAP 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 group request, i.e., one per origin server, and for how long it is
willing to wait for receiving responses via that proxy (see willing to wait for receiving responses via that proxy (see
Section 5.1.1 and Section 5.2.1). Section 5.1.1 and Section 5.2.1).
The client, when sending a CoAP group request to a proxy via IP 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, unicast, to be forwarded by the proxy to a targeted group of servers,
includes the Multicast-Signaling Option into the request. The option includes the Multicast-Signaling Option into the request. The option
value indicates after what time period in seconds the client will value indicates after what time period in seconds the client will
stop accepting responses matching its original unicast request, with stop accepting responses matching its original unicast request, with
the exception of notifications if the CoAP Observe Option [RFC7641] the exception of notifications if the CoAP Observe Option [RFC7641]
is used in the same request. Signaling the time period allows the is used in the same request. Signaling the time period allows the
skipping to change at page 5, line 37 skipping to change at page 6, line 9
responses, and builds on the Base-Uri option from Section 3 of responses, and builds on the Base-Uri option from Section 3 of
[I-D.bormann-coap-misc]. [I-D.bormann-coap-misc].
Since the option is intended only for responses, the column "N" Since the option is intended only for responses, the column "N"
indicates a dash for "not applicable". indicates a dash for "not applicable".
+------+---+---+---+---+------------+--------+--------+---------+ +------+---+---+---+---+------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default | | No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+------------+--------+--------+---------+ +------+---+---+---+---+------------+--------+--------+---------+
| | | | | | | | | | | | | | | | | | | |
| TBD2 | | | - | | Response- | (*) | 9-24 | (none) | | TBD2 | | | - | | Response- | (*) | 10-25 | (none) |
| | | | | | Forwarding | | | | | | | | | | Forwarding | | | |
| | | | | | | | | | | | | | | | | | | |
+------+---+---+---+---+------------+--------+--------+---------+ +------+---+---+---+---+------------+--------+--------+---------+
C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable
(*) See below. (*) See below.
Figure 2: The Response-Forwarding Option. Figure 2: The Response-Forwarding Option.
This document specifically defines how this option is used by a proxy This document specifically defines how this option is used by a proxy
skipping to change at page 6, line 15 skipping to change at page 6, line 35
the addressing information where the client can send an individual the addressing information where the client can send an individual
request intended to that origin server. request intended to that origin server.
In particular, the client can use the addressing information In particular, the client can use the addressing information
specified in the option to identify the response originator and specified in the option to identify the response originator and
possibly send it individual requests later on, either directly, or possibly send it individual requests later on, either directly, or
indirectly via the proxy, as CoAP unicast requests. indirectly via the proxy, as CoAP unicast requests.
The option value is set to the byte serialization of the CBOR array The option value is set to the byte serialization of the CBOR array
'tp_info' defined in Section 2.2.1 of 'tp_info' defined in Section 2.2.1 of
[I-D.tiloca-core-observe-multicast-notifications], including only the [I-D.ietf-core-observe-multicast-notifications], including only the
set of elements 'srv_addr'. In turn, the set includes the integer set of elements 'srv_addr'. In turn, the set includes the integer
'tp_id' identifying the used transport protocol, and further elements 'tp_id' identifying the used transport protocol, and further elements
whose number, format and encoding depend on the value of 'tp_id'. 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 The value of 'tp_id' MUST be taken from the "Value" column of the
"CoAP Transport Information" Registry defined in Section 14.4 of "CoAP Transport Information" Registry defined in Section 14.4 of
[I-D.tiloca-core-observe-multicast-notifications]. The elements of [I-D.ietf-core-observe-multicast-notifications]. The elements of
'srv_addr' following 'tp_id' are specified in the corresponding entry 'srv_addr' following 'tp_id' are specified in the corresponding entry
of the Registry, under the "Server Addr" column. of the Registry, under the "Server Addr" column.
If the server is reachable through CoAP transported over UDP, the If the server is reachable through CoAP transported over UDP, the
'tp_info' array includes the following elements, encoded as defined 'tp_info' array includes the following elements, encoded as defined
in Section 2.2.1.1 of in Section 2.2.1.1 of
[I-D.tiloca-core-observe-multicast-notifications]. [I-D.ietf-core-observe-multicast-notifications].
o 'tp_id': the CBOR integer with value 1. This element MUST be * 'tp_id': the CBOR integer with value 1. This element MUST be
present. present.
o 'srv_host': a CBOR byte string, encoding the unicast IP address of * 'srv_host': a CBOR byte string, encoding the unicast IP address of
the server. This element is tagged and identified by the CBOR tag the server. This element is tagged and identified by the CBOR tag
260 "Network Address (IPv4 or IPv6 or MAC Address)". This element 260 "Network Address (IPv4 or IPv6 or MAC Address)". This element
MUST be present. MUST be present.
o 'srv_port': a CBOR unsigned integer or the CBOR simple value Null. * 'srv_port': a CBOR unsigned integer or the CBOR simple value Null.
This element MAY be present. This element MAY be present.
If present as a CBOR unsigned integer, it has as value the If present as a CBOR unsigned integer, it has as value the
destination UDP port number to use for individual requests to the destination UDP port number to use for individual requests to the
server. server.
If present as the CBOR simple value Null, the client MUST assume If present as the CBOR simple value Null, the client MUST assume
that the default port number 5683 defined in [RFC7252] can be used that the default port number 5683 defined in [RFC7252] can be used
as the destination UDP port number for individual requests to the as the destination UDP port number for individual requests to the
server. server.
skipping to change at page 7, line 27 skipping to change at page 7, line 44
] ]
At present, 'tp_id' is expected to take only value 1 (UDP) when using At present, 'tp_id' is expected to take only value 1 (UDP) when using
forward proxies, UDP being the only currently available transport for forward proxies, UDP being the only currently available transport for
CoAP to work over IP multicast. While additional multicast-friendly CoAP to work over IP multicast. While additional multicast-friendly
transports may be defined in the future, other current tranport transports may be defined in the future, other current tranport
protocols can still be useful in applications relying on a reverse- protocols can still be useful in applications relying on a reverse-
proxy (see Section 6). proxy (see Section 6).
The rest of this section considers the new values of 'tp_id' The rest of this section considers the new values of 'tp_id'
registered by this document (see Section 9.2), and specifies: registered by this document (see Section 10.2), and specifies:
o The encoding for the elements of 'tp_info' following 'tp_id' (see * The encoding for the elements of 'tp_info' following 'tp_id' (see
Section 3.1). Section 3.1).
o The port number assumed by the client if 'srv_port' in 'tp_info' * The port number assumed by the client if 'srv_port' in 'tp_info'
specifies the CBOR simple value Null (see Section 3.2). specifies the CBOR simple value Null (see Section 3.2).
The Response-Forwarding Option is of class U in terms of OSCORE The Response-Forwarding Option is of class U in terms of OSCORE
processing (see Section 4.1 of [RFC8613]). processing (see Section 4.1 of [RFC8613]).
3.1. Encoding of Server Address 3.1. Encoding of Server Address
This specification defines some values used as transport protocol This specification defines some values used as transport protocol
identifiers, whose respective new entries are included in the "CoAP identifiers, whose respective new entries are included in the "CoAP
Transport Information" Registry defined in Section 14.4 of Transport Information" Registry defined in Section 14.4 of
[I-D.tiloca-core-observe-multicast-notifications]. [I-D.ietf-core-observe-multicast-notifications].
For each of these values, the following table summarizes the elements For each of these values, the following table summarizes the elements
specified under the "Srv Addr" and "Req Info" columns of the specified under the "Srv Addr" and "Req Info" columns of the
registry, together with their CBOR encoding and short description. registry, together with their CBOR encoding and short description.
While not listed here for brevity, the element 'tp_id' is always While not listed here for brevity, the element 'tp_id' is always
present as a CBOR integer in the element set "Srv Addr". present as a CBOR integer in the element set "Srv Addr".
+----------+-------------+----------+--------------+---------------+ +----------+-------------+----------+--------------+---------------+
| 'tp_id' | Element Set | Element | CBOR Type | Description | | 'tp_id' | Element Set | Element | CBOR Type | Description |
skipping to change at page 8, line 32 skipping to change at page 8, line 49
* The CBOR byte string is tagged and identified by the * The CBOR byte string is tagged and identified by the
CBOR tag 260 "Network Address (IPv4 or IPv6 or MAC Address)". CBOR tag 260 "Network Address (IPv4 or IPv6 or MAC Address)".
3.2. Default Values of the Server Port Number 3.2. Default Values of the Server Port Number
If the 'srv_port' element in the 'tp_info' array specifies the CBOR 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 simple value Null, the client MUST assume the following value as port
number where to send individual requests intended to the server, number where to send individual requests intended to the server,
based on the value of 'tp_id'. based on the value of 'tp_id'.
o If 'tp_id' is equal to 2, i.e. CoAP over UDP secured with DTLS, * If 'tp_id' is equal to 2, i.e., CoAP over UDP secured with DTLS,
the default port number 5684 as defined in [RFC7252]. 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 * If 'tp_id' is equal to 3, i.e., CoAP over TCP, the default port
number 5683 as defined in [RFC8323]. number 5683 as defined in [RFC8323].
o If 'tp_id' is equal to 4, i.e. CoAP over TCP secured with TLS, the * If 'tp_id' is equal to 4, i.e., CoAP over TCP secured with TLS,
default port number 5684 as defined in [RFC8323]. the default port number 5684 as defined in [RFC8323].
o If 'tp_id' is equal to 5, i.e. CoAP over WebSockets, the default * If 'tp_id' is equal to 5, i.e., CoAP over WebSockets, the default
port number 80 as defined in [RFC8323]. port number 80 as defined in [RFC8323].
o If 'tp_id' is equal to 6, i.e. CoAP over WebSockets secured with * If 'tp_id' is equal to 6, i.e., CoAP over WebSockets secured with
TLS, the default port number 443 as defined in [RFC8323]. TLS, the default port number 443 as defined in [RFC8323].
4. Requirements and Objectives 4. Requirements and Objectives
This specification assumes that the following requirements are This specification assumes that the following requirements are
fulfilled. fulfilled.
o REQ1. The CoAP proxy is explicitly configured (allow-list) to * REQ1. The CoAP proxy is explicitly configured (allow-list) to
allow proxied CoAP group requests from specific client(s). allow proxied CoAP group requests from specific client(s).
o REQ2. The CoAP proxy MUST identify a client sending a CoAP group * REQ2. The CoAP proxy MUST identify a client sending a CoAP group
request, in order to verify whether the client is allowed-listed request, in order to verify whether the client is allowed-listed
to do so. For example, this can rely on one of the following. to do so. For example, this can rely on one of the following
security associations.
* A TLS [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13] channel - A TLS [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13] channel
between the client and the proxy, where the client has been between the client and the proxy, where the client has been
authenticated during the secure channel establishment. authenticated during the secure channel establishment.
* A pairwise OSCORE Security Context between the client and the - A pairwise OSCORE [RFC8613] Security Context between the client
proxy, as described in Appendix A. and the proxy, as defined in
[I-D.tiloca-core-oscore-capable-proxies].
o REQ3. If secure, end-to-end communication is required between the * REQ3. If secure, end-to-end communication is required between the
client and the servers in the CoAP group, exchanged messages MUST client and the servers in the CoAP group, exchanged messages MUST
be protected by using Group OSCORE be protected by using Group OSCORE
[I-D.ietf-core-oscore-groupcomm], as discussed in Section 5.2 of [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5 of
[I-D.ietf-core-groupcomm-bis]. This requires the client and the [I-D.ietf-core-groupcomm-bis]. This requires the client and the
servers to have previously joined the correct OSCORE group, for servers to have previously joined the correct OSCORE group, for
instance by using the approach described in instance by using the approach described in
[I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to [I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to
join can be pre-configured or alternatively discovered, for join can be pre-configured or alternatively discovered, for
instance by using the approach described in instance by using the approach described in
[I-D.tiloca-core-oscore-discovery]. [I-D.tiloca-core-oscore-discovery].
This specification defines how to achieve the following objectives. This specification defines how to achieve the following objectives.
o OBJ1. The CoAP proxy gets an indication from the client that it * OBJ1. The CoAP proxy gets an indication from the client that it
is in fact interested in and capable to receive multiple responses is in fact interested in and capable to receive multiple responses
to its unicast request containing a CoAP group URI. to its unicast request containing a CoAP group URI.
o OBJ2. The CoAP proxy learns how long it should wait for responses * OBJ2. The CoAP proxy learns how long it should wait for responses
to a proxied request, before starting to ignore following to a proxied request, before starting to ignore following
responses (except for notifications, if a CoAP Observe Option is responses (except for notifications, if a CoAP Observe Option is
used [RFC7641]). used [RFC7641]).
o OBJ3. The CoAP proxy returns individual unicast responses to the * OBJ3. The CoAP proxy returns individual unicast responses to the
client, each of which matches the original unicast request made to client, each of which matches the original unicast request made to
the proxy. the proxy.
o OBJ4. The CoAP client is able to distinguish the different * OBJ4. The CoAP client is able to distinguish the different
responses to the original unicast request, as well as their responses to the original unicast request, as well as their
corresponding origin servers. corresponding origin servers.
o OBJ5. The CoAP client is enabled to optionally contact one or * OBJ5. The CoAP client is enabled to optionally contact one or
more of the responding origin servers in the future, either more of the responding origin servers in the future, either
directly or via the CoAP proxy. directly or via the CoAP proxy.
5. Protocol Description 5. Protocol Description
This section specifies the steps of the signaling protocol. This section specifies the steps of the signaling protocol.
5.1. Request Sending at the Client 5.1. Request Sending at the Client
This section defines the operations that the client performs for This section defines the operations that the client performs for
sending a request addressed to a group of servers via the CoAP proxy. sending a request addressed to a group of servers via the CoAP proxy.
5.1.1. Request Sending 5.1.1. Request Sending
The client proceeds according to the following steps. The client proceeds according to the following steps.
1. The client prepares a request addressed to the CoAP proxy. The 1. The client prepares a request addressed to the CoAP proxy. The
request specifies the group URI as a string in the Proxi-URI request specifies the group URI as a string in the Proxi-URI
option, or by using the Proxy-Scheme option with the group URI option, or by using the Proxy-Scheme option with the group URI
constructed from the URI-* options (see Section 2.3.3 of constructed from the URI-* options (see Section 3.5.1 of
[I-D.ietf-core-groupcomm-bis]). [I-D.ietf-core-groupcomm-bis]).
2. The client MUST retain the Token value used for this original 2. The client MUST retain the Token value used for this original
unicast request beyond the reception of a first response matching unicast request beyond the reception of a first response matching
it. To this end, the client follows the same rules for Token it. To this end, the client follows the same rules for Token
retention defined for multicast requests in Section 2.3.1 of retention defined for multicast requests in Section 3.1.5 of
[I-D.ietf-core-groupcomm-bis]. [I-D.ietf-core-groupcomm-bis].
In particular, the client picks an amount of time T it is fine to In particular, the client picks an amount of time T it is fine to
wait for before freeing up the Token value. Specifically, the wait for before freeing up the Token value. Specifically, the
value of T MUST be such that: value of T MUST be such that:
* T < T_r , where T_r is the amount of time that the client is * 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. fine to wait for before potentially reusing the Token value.
Note that T_r MUST NOT be less than MIN_TOKEN_REUSE_TIME 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]. defined in Section 3.1.5 of [I-D.ietf-core-groupcomm-bis].
* T should be at least the expected worst-case time taken by the * T should be at least the expected worst-case time taken by the
request and response processing on the forward-proxy and on request and response processing on the forward-proxy and on
the servers in the addressed CoAP group. the servers in the addressed CoAP group.
* T should be at least the expected worst-case round-trip delay * T should be at least the expected worst-case round-trip delay
between the client and the forward-proxy plus the worst-case between the client and the forward-proxy plus the worst-case
round-trip delay between the proxy and any one of the origin round-trip delay between the proxy and any one of the origin
servers. servers.
skipping to change at page 11, line 20 skipping to change at page 11, line 44
Consistently, if the unicast request to send to the proxy already Consistently, if the unicast request to send to the proxy already
included a No-Response Option with value 26, the client SHOULD included a No-Response Option with value 26, the client SHOULD
specify T' = 0 as value of the Multicast-Signaling Option. specify T' = 0 as value of the Multicast-Signaling Option.
4. The client processes the request as defined in 4. The client processes the request as defined in
[I-D.ietf-core-groupcomm-bis], and also as in [I-D.ietf-core-groupcomm-bis], and also as in
[I-D.ietf-core-oscore-groupcomm] when secure group communication [I-D.ietf-core-oscore-groupcomm] when secure group communication
is used between the client and the servers. is used between the client and the servers.
5. If OSCORE is used to protect the leg between the client and the 5. The client protects the unicast request resulting at the end of
proxy (see REQ2 in Section 4), the client (further) protects the step 4, according to the security association it has with the
unicast request resulting at the end of step 4. In particular, proxy.
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 6. The client sends the request to the proxy as a unicast CoAP
message. message.
The exact method that the client uses to estimate the worst-case The exact method that the client uses to estimate the worst-case
processing times and round-trip delays mentioned above is out of the processing times and round-trip delays mentioned above is out of the
scope of this specification. However, such a method is expected to scope of this specification. However, such a method is expected to
be already used by the client when generally determining a good Token be already used by the client when generally determining a good Token
lifetime and reuse interval. lifetime and reuse interval.
5.1.2. Supporting Observe 5.1.2. Supporting Observe
When using CoAP Observe [RFC7641], the client follows what is 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 specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis], with the
difference that it sends a unicast request to the proxy, to be 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 forwarded to the group of servers, as defined in Section 5.1.1 of
this specification. this specification.
Furthermore, the client especially follows what is specified in Furthermore, the client especially follows what is specified in
Section 5 of [RFC7641], i.e. it registers its interest to be an 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. observer with the proxy, as if it was communicating with the servers.
5.2. Request Processing at the Proxy 5.2. Request Processing at the Proxy
This section defines the operations that the proxy performs when This section defines the operations that the proxy performs when
receiving a request addressed to a group of servers. receiving a request addressed to a group of servers.
5.2.1. Request Processing 5.2.1. Request Processing
Upon receiving the request from the client, the proxy proceeds Upon receiving the request from the client, the proxy proceeds
according to the following steps. according to the following steps.
1. If OSCORE is used to protect the leg between the client and the 1. The proxy decrypts the request, according to the security
proxy (see REQ2 in Section 4), the proxy decrypts the request association it has with the client.
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 2. The proxy identifies the client, and verifies that the client is
in fact allowed-listed to have its requests proxyied to CoAP in fact allowed-listed to have its requests proxyied to CoAP
group URIs. group URIs.
3. The proxy verifies the presence of the Multicast-Signaling 3. The proxy verifies the presence of the Multicast-Signaling
Option, as a confirmation that the client is fine to receive Option, as a confirmation that the client is fine to receive
multiple responses matching the same original request. multiple responses matching the same original request.
If the Multicast-Signaling Option is not present, the proxy MUST If the Multicast-Signaling Option is not present, the proxy MUST
skipping to change at page 13, line 5 skipping to change at page 13, line 23
Multicast-Signaling Option of the original unicast request. Multicast-Signaling Option of the original unicast request.
In case T' > 0, the proxy will ignore responses to the forwarded In case T' > 0, the proxy will ignore responses to the forwarded
group request coming from servers, if received after the timeout group request coming from servers, if received after the timeout
expiration, with the exception of Observe notifications (see expiration, with the exception of Observe notifications (see
Section 5.4). Section 5.4).
In case T' = 0, the proxy will ignore all responses to the In case T' = 0, the proxy will ignore all responses to the
forwarded group request coming from servers. forwarded group request coming from servers.
If the proxy supports caching of responses, it can serve the original
unicast request also by using cached responses, as per Section 7.
5.2.2. Supporting Observe 5.2.2. Supporting Observe
When using CoAP Observe [RFC7641], the proxy takes the role of the When using CoAP Observe [RFC7641], the proxy takes the role of the
client and registers its own interest to observe the target resource client and registers its own interest to observe the target resource
with the servers as per Section 5 of [RFC7641]. with the servers as per Section 5 of [RFC7641].
When doing so, the proxy especially follows what is specified for the 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 client in Section 3.7 of [I-D.ietf-core-groupcomm-bis], by forwarding
forwarding the group request to the servers over IP multicast, as the group request to the servers over IP multicast, as defined in
defined in Section 5.2.1 of this specification. Section 5.2.1 of this specification.
5.3. Request and Response Processing at the Server 5.3. Request and Response Processing at the Server
This section defines the operations that the server performs when This section defines the operations that the server performs when
receiving a group request from the proxy. receiving a group request from the proxy.
5.3.1. Request and Response Processing 5.3.1. Request and Response Processing
Upon receiving the request from the proxy, the server proceeds Upon receiving the request from the proxy, the server proceeds
according to the following steps. according to the following steps.
skipping to change at page 13, line 39 skipping to change at page 14, line 13
is used between the client and the server. is used between the client and the server.
2. The server processes the response to be forwarded back to the 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 client as defined in [I-D.ietf-core-groupcomm-bis], and also as
in [I-D.ietf-core-oscore-groupcomm] when secure group in [I-D.ietf-core-oscore-groupcomm] when secure group
communication is used between the client and the server. communication is used between the client and the server.
5.3.2. Supporting Observe 5.3.2. Supporting Observe
When using CoAP Observe [RFC7641], the server especially follows what 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 is specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis] and
Section 5 of [RFC7641]. Section 5 of [RFC7641].
5.4. Response Processing at the Proxy 5.4. Response Processing at the Proxy
This section defines the operations that the proxy performs when This section defines the operations that the proxy performs when
receiving a response matching a forwarded group request. receiving a response matching a forwarded group request.
5.4.1. Response Processing 5.4.1. Response Processing
Upon receiving a response matching the group request before the Upon receiving a response matching the group request before the
skipping to change at page 14, line 24 skipping to change at page 14, line 46
address. address.
* If present, the 'srv_port' element of the 'srv_info' array * If present, the 'srv_port' element of the 'srv_info' array
MUST specify the port number of the server as the source port MUST specify the port number of the server as the source port
number of the response. This element MUST be present if the number of the response. This element MUST be present if the
source port number of the response differs from the port source port number of the response differs from the port
number specified in the group URI of the original unicast CoAP number specified in the group URI of the original unicast CoAP
group request (see Section 5.1.1). Otherwise, the 'srv_port' group request (see Section 5.1.1). Otherwise, the 'srv_port'
element MAY be omitted. element MAY be omitted.
2. If OSCORE is used to protect the leg between the client and the 2. The proxy protects the response according to the security
proxy (see REQ2 in Section 4), the proxy (further) protects the association it has with the client.
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. 3. The proxy forwards the response back to the client.
Upon timeout expiration, i.e. T' seconds after having sent the group As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is
possible that a same server replies with multiple responses to the
same group request, i.e., with the same Token. As long as the proxy
forwards responses to a group request back to the origin client, the
proxy MUST follow the steps defined above and forward also such
multiple responses "as they come".
Upon timeout expiration, i.e., T' seconds after having sent the group
request over IP multicast, the proxy frees up its local Token value request over IP multicast, the proxy frees up its local Token value
associated to that request. Thus, following late responses to the associated to that request. Thus, following late responses to the
same group request will be discarded and not forwarded back to the same group request will be discarded and not forwarded back to the
client. client.
5.4.2. Supporting Observe 5.4.2. Supporting Observe
When using CoAP Observe [RFC7641], the proxy acts as a client When using CoAP Observe [RFC7641], the proxy acts as a client
registered with the servers, as described earlier in Section 5.2.2. registered with the servers, as described earlier in Section 5.2.2.
Furthermore, the proxy takes the role of a server when forwarding Furthermore, the proxy takes the role of a server when forwarding
notifications from origin servers back to the client. To this end, notifications from origin servers back to the client. To this end,
the proxy follows what is specified in Section 2.3.5 of the proxy follows what is specified in Section 3.7 of
[I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the
following additions. following additions.
o At step 1 in Section 5.4, the proxy includes the Response- * At step 1 in Section 5.4, the proxy includes the Response-
Forwarding Option in every notification, including non-2.xx Forwarding Option in every notification, including non-2.xx
notifications resulting in removing the proxy from the list of notifications resulting in removing the proxy from the list of
observers of the origin server. observers of the origin server.
o The proxy frees up its Token value used for a group observation * The proxy frees up its Token value used for a group observation
only if, after the timeout expiration, no 2.xx (Success) responses only if, after the timeout expiration, no 2.xx (Success) responses
matching the group request and also including an Observe option matching the group request and also including an Observe option
have been received from any origin server. After that, as long as have been received from any origin server. After that, as long as
observations are active with servers in the group for the target observations are active with servers in the group for the target
resource of the group request, notifications from those servers resource of the group request, notifications from those servers
are forwarded back to the client, as defined in Section 5.4, and 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 the Token value used for the group observation is not freed during
this time. this time.
Finally, the proxy SHOULD regularly verify that the client is still Finally, the proxy SHOULD regularly verify that the client is still
interested in receiving observe notifications for a group interested in receiving observe notifications for a group
observation. To this end, the proxy can rely on the same approach observation. To this end, the proxy can rely on the same approach
discussed for servers in Section 2.3.5 of discussed for servers in Section 3.7 of
[I-D.ietf-core-groupcomm-bis], with more details available in [I-D.ietf-core-groupcomm-bis], with more details available in
Section 4.5 of [RFC7641]. Section 4.5 of [RFC7641].
5.5. Response Processing at the Client 5.5. Response Processing at the Client
This section defines the operations that the client performs when This section defines the operations that the client performs when
receiving a response matching a request addressed to a group of receiving a response matching a request addressed to a group of
servers via the CoAP proxy. servers via the CoAP proxy.
5.5.1. Response Processing 5.5.1. Response Processing
Upon receiving from the proxy a response matching the original Upon receiving from the proxy a response matching the original
unicast request before the amount of time T has elapsed, the client unicast request before the amount of time T has elapsed, the client
proceeds according to the following steps. proceeds according to the following steps.
1. The client processes the response as defined in 1. The client processes the response as defined in
[I-D.ietf-core-groupcomm-bis]. [I-D.ietf-core-groupcomm-bis].
2. If OSCORE is used to protect the leg between the client and the 2. The client decrypts the response, according to the security
proxy (see REQ2 in Section 4), the client decrypts the response association it has with the proxy.
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 3. If secure group communication is used end-to-end between the
client and the servers, the client processes the response, client and the servers, the client processes the response
possibly as outcome of step 2, as defined in resulting at the end of step 2, as defined in
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm].
4. The client identifies the origin server, whose addressing 4. The client identifies the origin server, whose addressing
information is specified as value of the Response-Forwarding information is specified as value of the Response-Forwarding
Option. If the port number is omitted in the value of the Option. If the port number is omitted in the value of the
Response-Forwarding Option, the client MUST assume that the port Response-Forwarding Option, the client MUST assume that the port
number where to send unicast requests to the server - in case number where to send unicast requests to the server -- in case
this is needed - is the same port number specified in the group this is needed -- is the same port number specified in the group
URI of the original unicast CoAP group request sent to the proxy URI of the original unicast CoAP group request sent to the proxy
(see Section 5.1.1). (see Section 5.1.1).
In particular, the client is able to distinguish different In particular, the client is able to distinguish different
responses as originated by different servers. Optionally, the responses as originated by different servers. Optionally, the
client may contact one or more of those servers individually, client may contact one or more of those servers individually,
i.e. directly (bypassing the proxy) or indirectly (via a proxied i.e., directly (bypassing the proxy) or indirectly (via a proxied
CoAP unicast request). CoAP unicast request).
In order to individually reach an origin server again through the In order to individually reach an origin server again through the
proxy, the client is not required to understand or support the proxy, the client is not required to understand or support the
transport protocol indicated in the Response-Forwarding Option, transport protocol indicated in the Response-Forwarding Option,
as used between the proxy and the origin server, in case it as used between the proxy and the origin server, in case it
differs from "UDP" (1). That is, using the IPv4/IPv6 address differs from "UDP" (1). That is, using the IPv4/IPv6 address
value and optional port value from the Response-Forwarding value and optional port value from the Response-Forwarding
Option, the client simply creates the correct URI for the Option, the client simply creates the correct URI for the
individual request, by means of the Proxy-Uri or Uri-Scheme individual request, by means of the Proxy-Uri or Uri-Scheme
Option in the unicast request to the proxy. The client uses the Option in the unicast request to the proxy. The client uses the
transport protocol it knows, and has used before, to send the transport protocol it knows, and has used before, to send the
request to the proxy. request to the proxy.
Upon the timeout expiration, i.e. T seconds after having sent the As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is
possible that the client receives multiple responses to the same
group request, i.e., with the same Token, from the same origin
server. The client normally processes at the CoAP layer each of
those responses from the same origin server, and decides how to
exactly handle them depending on its available context information
(see Section 3.1.6 of [I-D.ietf-core-groupcomm-bis]).
Upon the timeout expiration, i.e., T seconds after having sent the
original unicast request to the proxy, the client frees up its local original unicast request to the proxy, the client frees up its local
Token value associated to that request. Note that, upon this timeout Token value associated to that request. Note that, upon this timeout
expiration, the Token value is not eligible for possible reuse yet expiration, the Token value is not eligible for possible reuse yet
(see Section 5.1.1). Thus, until the actual amount of time before (see Section 5.1.1). Thus, until the actual amount of time before
enabling Token reusage has elapsed, any following late responses to enabling Token reusage has elapsed, any following late responses to
the same request forwarded by the proxy will be discarded, as these the same request forwarded by the proxy will be discarded, as these
are not matching (by Token) any active request from the client. are not matching (by Token) any active request from the client.
5.5.2. Supporting Observe 5.5.2. Supporting Observe
skipping to change at page 16, line 50 skipping to change at page 17, line 50
Instead, if at least one such response has been received, the client Instead, if at least one such response has been received, the client
continues receiving those notifications as forwarded by the proxy, as continues receiving those notifications as forwarded by the proxy, as
long as the observation for the target resource of the original long as the observation for the target resource of the original
unicast request is active. unicast request is active.
5.6. Example 5.6. Example
The example in this section refers to the following actors. The example in this section refers to the following actors.
o One origin client C, with address C_ADDR and port number C_PORT. * 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. * 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 * Two origin servers S1 and S2, where the server Sx has address
Sx_ADDR and port number Sx_PORT. Sx_ADDR and port number Sx_PORT.
The origin servers are members of a CoAP group with IP multicast 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 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. 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 The communication between C and P is based on CoAP over UDP, as per
[RFC7252]. The communication between P and the origin servers is [RFC7252]. The communication between P and the origin servers is
based on CoAP over UDP and IP multicast, as per based on CoAP over UDP and IP multicast, as per
[I-D.ietf-core-groupcomm-bis]. [I-D.ietf-core-groupcomm-bis].
skipping to change at page 18, line 16 skipping to change at page 19, line 9
| Src: P_ADDR:P_PORT | | | | Src: P_ADDR:P_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | | | Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | | | [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S1_ADDR)) | | | | #6.260(bstr(S1_ADDR)) | | |
| ] | | | | ] | | |
| } | | | | } | | |
| |<-----------------------------------| | |<-----------------------------------|
| | Src: S2_ADDR:S2_PORT | | | Src: S2_ADDR:S2_PORT |
| | Dst: P_ADDR:P_PORT | | | Dst: P_ADDR:P_PORT |
| | | |
| | | |
| | | |
|<-------------------------| | | |<-------------------------| | |
| Src: P_ADDR:P_PORT | | | | Src: P_ADDR:P_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | | | Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | | | [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S2_ADDR)), | | | | #6.260(bstr(S2_ADDR)), | | |
| S2_PORT | | | | S2_PORT | | |
| ] | | | | ] | | |
| } | | | | } | | |
| /* At t = 60, P stops accepting | | | /* At t = 60, P stops accepting | |
| responses for this request */ | | | responses for this request */ | |
| | | | | | | |
Figure 3: Workflow example with a forward-proxy Figure 3: Workflow example with a forward-proxy
6. Reverse-Proxies 6. Reverse-Proxies
The use of reverse-proxies in group communication scenarios is The use of reverse-proxies in group communication scenarios is
defined in Section 3.4.2 of [I-D.ietf-core-groupcomm-bis]. defined in Section 3.5.2 of [I-D.ietf-core-groupcomm-bis].
This section clarifies how the Multicast-Signaling Option is This section clarifies how the Multicast-Signaling Option is
effective also in such a context, in order for: effective also in such a context, in order for:
o The proxy to explictly reveal itself as a reverse-proxy to the * The proxy to explictly reveal itself as a reverse-proxy to the
client. client.
o The client to indicate to the proxy of being aware that it is * 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 communicating with a reverse-proxy, and for how long it is willing
to receive responses to a proxied request. to receive responses to a proxied request.
This practically addresses the addional issues compared to the case This practically addresses the addional issues compared to the case
with a forward-proxy, as compiled in Section 3.4.2 of with a forward-proxy, as compiled in Section 3.5.2 of
[I-D.ietf-core-groupcomm-bis]. A reverse-proxy may also operate [I-D.ietf-core-groupcomm-bis]. A reverse-proxy may also operate
without support of the Multicast-Signaling Option, as defined in that without support of the Multicast-Signaling Option, as defined in that
section. section.
Appendix B provides examples with a reverse-proxy. Appendix A provides examples with a reverse-proxy.
6.1. Processing on the Client Side 6.1. Processing on the Client Side
If a client sends a request intended to a group of servers and is 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 aware of actually communicating with a reverse-proxy, then the client
MUST perform the steps defined in Section 5.1.1. In particular, this MUST perform the steps defined in Section 5.1.1. In particular, this
results in a request sent to the proxy including a Multicast- results in a request sent to the proxy including a Multicast-
Signaling Option. Signaling Option.
The client processes the responses forwarded back by the proxy as The client processes the responses forwarded back by the proxy as
defined in Section 5.5. defined in Section 5.5.
6.2. Processing on the Proxy Side 6.2. Processing on the Proxy Side
If the proxy receives a request and determines that it should forward 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 it to a group of servers over IP multicast, then the proxy MUST
perform the steps defined in Section 5.2. perform the steps defined in Section 5.2.
In particular, when such request does not include a Multicast- In particular, when such request does not include a Multicast-
Signaling Option, the proxy explicitly reveals itself as a reverse- Signaling Option, the proxy explicitly reveals itself as a reverse-
proxy, by sending a 4.00 (Bad Request) response including an proxy, by sending a 4.00 (Bad Request) response including a
Multicast-Signaling Option with empty (zero-length) value. Multicast-Signaling Option with empty (zero-length) value.
7. Chain of Proxies 7. Caching
A proxy MAY cache responses to a group request, as defined in
Section 5.7.1 of [RFC7252]. In particular, these same rules apply to
determine the set of request options used as "Cache-Key", and to
determine the max-age values offered for responses served from the
cache.
A cache entry is associated to one server and stores one response
from that server, regardless whether it is a response to a unicast
request or to a group request. The following two types of requests
can produce a hit to a cache entry.
* A matching request intended to that server, i.e., to the
corresponding unicast URI.
When the stored response is a response to a unicast request to the
server, the unicast URI of the matching request is the same target
URI used for the original unicast request.
When the stored response is a response to a group request to the
CoAP group, the unicast URI of the matching request is the target
URI obtained by replacing the authority part of the group URI in
the original group request with the transport-layer source address
and port number of the response.
* A matching group request intended to the CoAP group, i.e., to the
corresponding group URI.
That is, a matching group request produces a hit to multiple cache
entries, each of which associated to one of the CoAP servers
currently member of the CoAP group.
Note that, as per the freshness model defined in Section 7.1, the
proxy might serve a group request exclusively from its cached
responses only when it knows all the CoAP servers that are current
members of the CoAP group and it has a valid cache entry for each
of them.
When forwarding a GET or FETCH group request to the servers in the
CoAP group, a proxy behaves like a CoAP client as defined in
Section 3.2 of [I-D.ietf-core-groupcomm-bis], with the following
additions.
* As discussed in Section 5.4.1, the proxy can receive multiple
responses to the same group request from a same origin server, and
forwards them back to the origin client "as they come". When this
happens, each of such multiple responses is stored in the cache
entry associated to the server "as it comes", possibly replacing
an already stored response from that server.
* As discussed in Section 7.4, when communications in the group are
secured with Group OSCORE [I-D.ietf-core-oscore-groupcomm],
additional means are required to enable cacheability of responses
at the proxy.
The following subsections define the freshness model and validation
model that the proxy uses for cached responses.
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 group request, the proxy MAY serve
the request 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 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
forwarding the group request.
- The proxy has received no response to the forwarded group
request from the server associated to E.
Then, the proxy forwards 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.2.1. Proxy-Servers Revalidation with Unicast Requests
The proxy MAY revalidate a cached response by making a GET or FETCH
request on the related unicast request URI, i.e., by taking the role
of a CoAP client with respect to a server in the CoAP group.
As discussed in Section 7.4, this is however not possible for the
proxy if communications in the group are secured end-to-end between
origin client and origin servers by using Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
7.2.2. Proxy-Servers Revalidation with Group Requests
When forwarding a group request to the servers in the CoAP group, the
proxy MAY revalidate one of more stored responses it has cached.
To this end, the proxy relies on the same validation model defined in
Section 3.2.2 of [I-D.ietf-core-groupcomm-bis] and using the ETag
Option, by taking the role of a CoAP client with respect to the
servers in the CoAP group.
As discussed in Section 7.4, this is however not possible for the
proxy if communications in the group are secured end-to-end between
origin client and origin servers by using Group OSCORE
[I-D.ietf-core-oscore-groupcomm].
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 specification 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, 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
Figure 4: The Group-ETag Option.
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 forwarding 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 returning 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 a GET or FETCH group request to the proxy, to be
forwarded to a 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 group request.
* 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.
7.4.1. Deterministic Requests to Achieve Cacheability
For application scenarios that use secure group communication, it is
still possible to achieve cacheability of responses at proxies, by
using the approach defined in [I-D.amsuess-core-cachable-oscore]
which is based on Deterministic Requests protected with the pairwise
mode of Group OSCORE. This approach is limited to group requests
that are safe (in the RESTful sense) to process and do not yield side
effects at the server. As for any protected group request, it
requires the clients and all the servers in the CoAP group to have
already joined the correct OSCORE group.
Starting from the same plain CoAP request, this allows different
clients in the OSCORE group to deterministically generate a same
request protected with Group OSCORE, which is sent to the proxy for
being forwarded to the CoAP group. The proxy can now effectively
cache the resulting responses from the servers in the CoAP group,
since the same plain CoAP request will result again in the same
Deterministic Request and thus will produce a cache hit.
When caching of Group OSCORE secured responses is enabled at the
proxy, the same as defined in Section 7 applies, with respect to
cache entries and their lifetimes.
Note that different Deterministic Requests result in different cache
entries at the proxy. This includes the case where different plain
group requests differ only in their set of ETag Options, as defined
in Section 3.2.2 of [I-D.ietf-core-groupcomm-bis].
That is, even though the servers would produce the same plain CoAP
responses in reply to two different Deterministic Requests, those
will result in different protected responses to each respective
Deterministic Request, hence in different cache entries at the proxy.
Thus, given a plain group request, a client needs to reuse the same
set of ETag Options, in order to send that group request as a
Deterministic Request that can actually produce a cache hit at the
proxy. However, while this would prevent the caching at the proxy to
be inefficient and unnecessarily redundant, it would also limit the
flexibility of end-to-end response revalidation for a client.
7.4.2. Validation of Responses
Response revalidation remains possible end-to-end between the client
and the servers in the group, by means of including inner ETag
Option(s) as defined in Sections 3.2 and 3.2.2 of
[I-D.ietf-core-groupcomm-bis].
Furthermore, it remains possible for a client to attempt revalidating
responses to a group request from a "complete" set of cache entries
at the proxy, by using the Group-ETag Option as defined in
Section 7.3.
When directly interacting with the servers in the CoAP group to
refresh its cache entries, the proxy cannot rely on response
revalidation anymore. This applies to both the case where the
request is addressed to a single server and sent to the related
unicast URI (see Section 7.2.1) or instead is a group request
addressed to the CoAP group and sent to the related group URI (see
Section 7.2.2).
8. Chain of Proxies
A client may be interested to access a resource at a group of origin 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. servers which is reached through a chain of two or more proxies.
That is, these proxies are configured into a chain, where each non- That is, these proxies are configured into a chain, where each non-
last proxy is configured to forward CoAP (group) requests to the next last proxy is configured to forward CoAP (group) requests to the next
hop towards the origin servers. Also, each non-first proxy is hop towards the origin servers. Also, each non-first proxy is
configured to forward back CoAP responses to (the previous hop proxy configured to forward back CoAP responses to (the previous hop proxy
towards) the origin client. towards) the origin client.
This section specifies how the signaling protocol defined in This section specifies how the signaling protocol defined in
Section 5 is used in that setting. Except for the last proxy before 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 the origin servers, every other proxy in the chain takes the role of
client with respect to the next hop towards the origin servers. client with respect to the next hop towards the origin servers.
Also, every proxy in the chain except the first takes the role of Also, every proxy in the chain except the first takes the role of
server towards the previous proxy closer to the origin client. server towards the previous proxy closer to the origin client.
Accordingly, possible caching of responses at each proxy works as
defined in Section 7 and Section 7.4. Also, possible revalidation of
responses cached ad each proxy and based on the Group-ETag option
works as defined in Section 7.3 and Section 7.4.2.
The requirements REQ1 and REQ2 defined in Section 4 MUST be fulfilled 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 for each proxy in the chain. That is, every proxy in the chain has
to be explicitly configured (allow-list) to allow proxied group to be explicitly configured (allow-list) to allow proxied group
requests from specific senders, and MUST identify those senders upon requests from specific senders, and MUST identify those senders upon
receiving their group request. For the first proxy in the chain, receiving their group request. For the first proxy in the chain,
that sender is the origin client. For each other proxy in the chain, that sender is the origin client. For each other proxy in the chain,
that sender is the previous hop proxy closer to the origin client. 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 In either case, a proxy can identify the sender of a group request by
the same means mentioned in Section 4. the same means mentioned in Section 4.
7.1. Request Processing at the Proxy 8.1. Request Processing at the Proxy
Upon receiving a group request to be forwarded to a CoAP group URIs, Upon receiving a group request to be forwarded to a CoAP group URIs,
a proxy proceed as follows. a proxy proceed as follows.
If the proxy is the last one in the chain, i.e. it is the last hop 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 before the origin servers, the proxy performs the steps defined in
Section 5.2, with no modifications. Section 5.2, with no modifications.
Otherwise, the proxy performs the steps defined in Section 5.2, with Otherwise, the proxy performs the steps defined in Section 5.2, with
the following differences. the following differences.
o At steps 1-3, "client" refers to the origin client for the first * 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 proxy in the chain; or to the previous hop proxy closer to the
origin client, otherwise. origin client, otherwise.
o At step 4, the proxy rather performs the following actions. * At step 4, the proxy rather performs the following actions.
1. The proxy retrieves the value T' from the Multicast-Signaling 1. The proxy retrieves the value T' from the Multicast-Signaling
Option, and does not remove the option. Option, and does not remove the option.
2. In case T' > 0, the proxy picks an amount of time T it is fine 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 to wait for before freeing up its local Token value to use
with the next hop towards the origin servers. To this end, with the next hop towards the origin servers. To this end,
the proxy MUST follow what is defined at step 2 of the proxy MUST follow what is defined at step 2 of
Section 5.1.1 for the origin client, with the following Section 5.1.1 for the origin client, with the following
differences. differences.
+ T MUST be greater than the retrieved value T', i.e. T' < T. - T MUST be greater than the retrieved value T', i.e., T' <
T.
+ The worst-case message processing time takes into account - The worst-case message processing time takes into account
all the next hops towards the origin servers, as well as all the next hops towards the origin servers, as well as
the origin servers themselves. the origin servers themselves.
+ The worst-case round-trip delay takes into account all the - The worst-case round-trip delay takes into account all the
legs between the proxy and the origin servers. legs between the proxy and the origin servers.
3. In case T' > 0, the proxy replaces the value of the Multicast- 3. In case T' > 0, the proxy replaces the value of the Multicast-
Signaling Option with a new value T'', such that: Signaling Option with a new value T'', such that:
+ T'' < T. The difference (T - T'') should be at least the - T'' < T. The difference (T - T'') should be at least the
expected worst-case round-trip time between the proxy and expected worst-case round-trip time between the proxy and
the next hop towards the origin servers. the next hop towards the origin servers.
+ T'' < T'. The difference (T' - T'') should be at least the - T'' < T'. The difference (T' - T'') should be at least the
expected worst-case round-trip time between the proxy and expected worst-case round-trip time between the proxy and
the (previous hop proxy closer to the) origin client. the (previous hop proxy closer to the) origin client.
If the proxy is not able to determine a value T'' that If the proxy is not able to determine a value T'' that
fulfills both the requirements above, the proxy MUST stop fulfills both the requirements above, the proxy MUST stop
processing the request and MUST respond with a 5.05 (Proxying processing the request and MUST respond with a 5.05 (Proxying
Not Supported) error response to the previous hop proxy closer Not Supported) error response to the previous hop proxy closer
to the origin client. The proxy SHOULD include a Multicast- to the origin client. The proxy SHOULD include a Multicast-
Signaling Option, set to the minimum value T' that would be Signaling Option, set to the minimum value T' that would be
acceptable in the Multicast-Signaling Option of a request to acceptable in the Multicast-Signaling Option of a request to
skipping to change at page 21, line 29 skipping to change at page 29, line 9
MAY send an updated request to the next hop towards the origin MAY send an updated request to the next hop towards the origin
servers, specifying in the Multicast-Signaling Option a value servers, specifying in the Multicast-Signaling Option a value
T' greater than in the previous request. If this does not T' greater than in the previous request. If this does not
happen, the proxy receiving the error response MUST also send happen, the proxy receiving the error response MUST also send
a 5.05 (Proxying Not Supported) error response to the previous a 5.05 (Proxying Not Supported) error response to the previous
hop proxy closer to the origin client. Like the received one, hop proxy closer to the origin client. Like the received one,
also this error response SHOULD include a Multicast-Signaling also this error response SHOULD include a Multicast-Signaling
Option, set to the minimum value T' acceptable by the proxy Option, set to the minimum value T' acceptable by the proxy
sending the error response. sending the error response.
o At step 5, the proxy forwards the request to the next hop towards * At step 5, the proxy forwards the request to the next hop towards
the origin servers. the origin servers.
o At step 6, the proxy sets a timeout with the value T' retrieved * At step 6, the proxy sets a timeout with the value T' retrieved
from the Multicast-Signaling Option of the request received from from the Multicast-Signaling Option of the request received from
the (previous hop proxy closer to the) origin client. the (previous hop proxy closer to the) origin client.
In case T' > 0, the proxy will ignore responses to the forwarded In case T' > 0, the proxy will ignore responses to the forwarded
group request coming from the (next hop towards the) origin group request coming from the (next hop towards the) origin
servers, if received after the timeout expiration, with the servers, if received after the timeout expiration, with the
exception of Observe notifications (see Section 5.4). exception of Observe notifications (see Section 5.4).
In case T' = 0, the proxy will ignore all responses to the In case T' = 0, the proxy will ignore all responses to the
forwarded group request coming from the (next hop towards the) forwarded group request coming from the (next hop towards the)
origin servers. origin servers.
7.1.1. Supporting Observe 8.1.1. Supporting Observe
When using CoAP Observe [RFC7641], what is defined in Section 5.2.2 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 applies for the last proxy in the chain, i.e., the last hop before
origin servers. the origin servers.
Any other proxy in the chain acts as a client and registers its own 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 interest to observe the target resource with the next hop towards the
origin servers, as per Section 5 of [RFC7641]. origin servers, as per Section 5 of [RFC7641].
7.2. Response Processing at the Proxy 8.2. Response Processing at the Proxy
Upon receiving a response matching the group request before the Upon receiving a response matching the group request before the
amount of time T' has elapsed, the proxy proceeds as follows. 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 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 before the origin servers, the proxy performs the steps defined in
Section 5.4, with no modifications. Section 5.4, with no modifications.
Otherwise, the proxy performs the steps defined in Section 5.4, with Otherwise, the proxy performs the steps defined in Section 5.4, with
the following differences. the following differences.
o The proxy skips step 1. In particular, the proxy MUST NOT remove, * The proxy skips step 1. In particular, the proxy MUST NOT remove,
alter or replace the Response-Forwarding Option. alter or replace the Response-Forwarding Option.
o At steps 2-3, "client" refers to the origin client for the first * 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 proxy in the chain; or to the previous hop proxy closer to the
origin client, otherwise. origin client, otherwise.
Upon timeout expiration, i.e. T seconds after having sent the group 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 sent the group
request to the next hop towards the origin servers, the proxy frees request to the next hop towards the origin servers, the proxy frees
up its local Token value associated to that request. Thus, following up its local Token value associated to that request. Thus, following
late responses to the same group request will be discarded and not late responses to the same group request will be discarded and not
forwarded back to the (previous hop proxy closer to the) origin forwarded back to the (previous hop proxy closer to the) origin
client. client.
7.2.1. Supporting Observe 8.2.1. Supporting Observe
When using CoAP Observe [RFC7641], what is defined in Section 5.4.2 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 applies for the last proxy in the chain, i.e., the last hop before
origin servers. the origin servers.
As to any other proxy in the chain, the following applies. 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 proxy acts as a client registered with the next hop towards
the origin servers, as described earlier in Section 7.1.1. the origin servers, as described earlier in Section 8.1.1.
o The proxy takes the role of a server when forwarding notifications * The proxy takes the role of a server when forwarding notifications
from the next hop to the origin servers back to the (previous hop 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]. 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 * The proxy frees up its Token value used for a group observation
only if, after the timeout expiration, no 2.xx (Success) responses only if, after the timeout expiration, no 2.xx (Success) responses
matching the group request and also including an Observe option matching the group request and also including an Observe option
have been received from the next hop towards the origin servers. have been received from the next hop towards the origin servers.
After that, as long as the observation for the target resource of After that, as long as the observation for the target resource of
the group request is active with the next hop towards the origin the group request is active with the next hop towards the origin
servers in the group, notifications from that hop are forwarded servers in the group, notifications from that hop are forwarded
back to the (previous hop proxy closer to the) origin client, as back to the (previous hop proxy closer to the) origin client, as
defined in Section 7.2. defined in Section 8.2.
o The proxy SHOULD regularly verify that the (previous hop proxy * The proxy SHOULD regularly verify that the (previous hop proxy
closer to the) origin client is still interested in receiving closer to the) origin client is still interested in receiving
observe notifications for a group observation. To this end, the observe notifications for a group observation. To this end, the
proxy can rely on the same approach defined in Section 4.5 of proxy can rely on the same approach defined in Section 4.5 of
[RFC7641]. [RFC7641].
8. Security Considerations 9. Security Considerations
The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi
s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document.
When a chain of proxies is used (see Section 7), the secure When a chain of proxies is used (see Section 8), the secure
communication between any two adjacent hops is independent. communication between any two adjacent hops is independent.
When Group OSCORE is used for end-to-end secure group communication When Group OSCORE is used for end-to-end secure group communication
between the origin client and the origin servers, this security between the origin client and the origin servers, this security
association is unaffected by the possible presence of a proxy or a association is unaffected by the possible presence of a proxy or a
chain of proxies. chain of proxies.
Furthermore, the following additional considerations hold. Furthermore, the following additional considerations hold.
8.1. Client Authentication 9.1. Client Authentication
As per the requirement REQ2 (see Section 4), the client has to As per the requirement REQ2 (see Section 4), the client has to
authenticate to the proxy when sending a group request to forward. authenticate to the proxy when sending a group request to forward.
This leverages an established security association between the client This leverages an established security association between the client
and the proxy, that the client uses to protect the group request, and the proxy, that the client uses to protect the group request,
before sending it to the proxy. before sending it to the proxy.
Note that, if the group request is (also) protected with Group 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 OSCORE, i.e., end-to-end between the client and the servers, the
can authenticate the client by successfully verifying the counter proxy can authenticate the client by successfully verifying the
signature embedded in the group request. This requires that, for counter signature embedded in the group request. However, this
each client to authenticate, the proxy stores the public key used by requires that, for each client to authenticate, the proxy stores the
that client in the OSCORE group, which in turn would require a form public key used by that client in the OSCORE group, which in turn
of active synchronization between the proxy and the Group Manager for would require a form of active synchronization between the proxy and
that group [I-D.ietf-core-oscore-groupcomm]. the Group Manager for that group [I-D.ietf-core-oscore-groupcomm].
Nevertheless, the client and the proxy SHOULD still rely on a full- Nevertheless, the client and the proxy SHOULD still rely on a full-
fledged, pairwise secure association. In addition to ensuring the fledged, pairwise secure association. In addition to ensuring the
integrity of group requests sent to the proxy (see Section 8.2 and integrity of group requests sent to the proxy (see Section 9.2,
Section 8.3), this prevents the proxy from forwarding replayed group Section 9.3 and Section 9.4), this prevents the proxy from forwarding
requests with a valid counter signature, as possibly injected by an replayed group requests with a valid counter signature, as possibly
active, on-path adversary. injected by an active, on-path adversary.
The same considerations apply when a chain of proxies is used (see 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 Section 8), with each proxy but the last one in the chain acting as
client with the next hop towards the origin servers. client with the next hop towards the origin servers.
8.2. Multicast-Signaling Option 9.2. Multicast-Signaling Option
The Multicast-Signaling Option is of class U for OSCORE [RFC8613]. The Multicast-Signaling Option is of class U for OSCORE [RFC8613].
Hence, also when Group OSCORE is used between the client and the 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 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 the option value and retrieve the timeout value T', as well as to
remove the option altogether before forwarding the group request to remove the option altogether before forwarding the group request to
the servers. When a chain of proxies is used (see Section 7), this 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 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 option value, as an indication for the next hop towards the origin
servers (see Section 7.1). servers (see Section 8.1).
The security association between the client and the proxy MUST The security association between the client and the proxy MUST
provide message integrity, so that further intermediaries between the provide message integrity, so that further intermediaries between the
two as well as on-path active adversaries are not able to remove 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 option or alter its content, before the group request reaches the
proxy. Removing the option would otherwise result in not forwarding proxy. Removing the option would otherwise result in not forwarding
the group request to the servers. Instead, altering the option the group request to the servers. Instead, altering the option
content would result in the proxy accepting and forwarding back content would result in the proxy accepting and forwarding back
responses for an amount of time different than the one actually responses for an amount of time different than the one actually
indicated by the client. indicated by the client.
The security association between the client and the proxy SHOULD also The security association between the client and the proxy SHOULD also
provide message confidentiality. Otherwise, further intermediaries provide message confidentiality. Otherwise, any further
between the two as well as on-path passive adversaries would be able intermediaries between the two as well as any on-path passive
to simply access the option content, and thus learn for how long the adversaries would be able to simply access the option content, and
client is willing to receive responses from the servers in the group thus learn for how long the client is willing to receive responses
via the proxy. This may in turn be used to perform a more efficient, from the servers in the group via the proxy. This may in turn be
selective suppression of responses from the servers. used to perform a more efficient, selective suppression of responses
from the servers.
When the client (further) protects the unicast request sent to the When the client protects the unicast request sent to the proxy using
proxy using OSCORE (see Appendix A) and/or with (D)TLS, both message OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or with
integrity and message confidentiality are achieved in the leg between (D)TLS, both message integrity and message confidentiality are
the client and the proxy. achieved in the leg between the client and the proxy.
The same considerations above about security associations apply when The same considerations above about security associations apply when
a chain of proxies is used (see Section 7), with each proxy but the 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 last one in the chain acting as client with the next hop towards the
origin servers. origin servers.
8.3. Response-Forwarding Option 9.3. Response-Forwarding Option
The Response-Forwarding Option is of class U for OSCORE [RFC8613]. The Response-Forwarding Option is of class U for OSCORE [RFC8613].
Hence, also when Group OSCORE is used between the client and the Hence, also when Group OSCORE is used between the client and the
servers [I-D.ietf-core-oscore-groupcomm], the proxy that has servers [I-D.ietf-core-oscore-groupcomm], the proxy that has
forwarded the group request to the servers is able to include the forwarded the group request to the servers is able to include the
option into a server response, before forwarding this response back option into a server response, before forwarding this response back
to the (previous hop proxy closer to the) origin client. to the (previous hop proxy closer to the) origin client.
Since the security association between the client and the proxy Since the security association between the client and the proxy
provides message integrity, any further intermediaries between the provides message integrity, any further intermediaries between the
two or on-path active adversaries are not able to undetectably remove two as well as any on-path active adversaries are not able to
the Response-Forwarding Option from a forwarded server response. undetectably remove the Response-Forwarding Option from a forwarded
This ensures that the client can correctly distinguish the different server response. This ensures that the client can correctly
responses and identify their corresponding origin server. distinguish the different responses and identify their corresponding
origin server.
When the proxy (further) protects the response forwarded back to the When the proxy protects the response forwarded back to the client
client using OSCORE (see Appendix A) and/or with (D)TLS, message using OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or
integrity is achieved in the leg between the client and the proxy. (D)TLS, message integrity is achieved in the leg between the client
and the proxy.
The same considerations above about security associations apply when The same considerations above about security associations apply when
a chain of proxies is used (see Section 7), with each proxy but the 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 last one in the chain acting as client with the next hop towards the
origin servers. origin servers.
9. IANA Considerations 9.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. IANA Considerations
This document has the following actions for IANA. This document has the following actions for IANA.
9.1. CoAP Option Numbers Registry 10.1. CoAP Option Numbers Registry
IANA is asked to enter the following option numbers to the "CoAP IANA is asked to enter the following option numbers to the "CoAP
Option Numbers" registry defined in [RFC7252] within the "CoRE Option Numbers" registry defined in [RFC7252] within the "CoRE
Parameters" registry. Parameters" registry.
+--------+---------------------+-------------------+ +--------+---------------------+-------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+---------------------+-------------------+ +--------+---------------------+-------------------+
| TBD1 | Multicast-Signaling | [[this document]] | | TBD1 | Multicast-Signaling | [[this document]] |
+--------+---------------------+-------------------+ +--------+---------------------+-------------------+
| TBD2 | Response-Forwarding | [[this document]] | | TBD2 | Response-Forwarding | [[this document]] |
+--------+---------------------+-------------------+ +--------+---------------------+-------------------+
| TBD3 | Group-ETag | [[this document]] |
+--------+---------------------+-------------------+
9.2. CoAP Transport Information Registry 10.2. CoAP Transport Information Registry
IANA is asked to enter the following entries to the "CoAP Transport IANA is asked to enter the following entries to the "CoAP Transport
Information" Registry defined in Section 14.4 of Information" Registry defined in Section 14.4 of
[I-D.tiloca-core-observe-multicast-notifications]. [I-D.ietf-core-observe-multicast-notifications].
+------------+-------------+-------+----------+-----------+-----------+ +------------+-------------+-------+----------+-----------+-----------+
| Transport | Description | Value | Srv Addr | Req Info | Reference | | Transport | Description | Value | Srv Addr | Req Info | Reference |
| Protocol | | | | | | | Protocol | | | | | |
+------------+-------------+-------+----------+-----------+-----------+ +------------+-------------+-------+----------+-----------+-----------+
| UDP | UDP with | 2 | tp_id | token | [This | | UDP | UDP with | 2 | tp_id | token | [This |
| secured | DTLS is | | srv_host | cli_host | document] | | secured | DTLS is | | srv_host | cli_host | document] |
| with DTLS | used as per | | srv_port | ?cli_port | | | with DTLS | used as per | | srv_port | ?cli_port | |
| | RFC8323 | | | | | | | RFC8323 | | | | |
+------------+-------------+-------+----------+-----------+-----------+ +------------+-------------+-------+----------+-----------+-----------+
skipping to change at page 26, line 33 skipping to change at page 35, line 49
| WebSockets | WebSockets | 5 | tp_id | token | [This | | WebSockets | WebSockets | 5 | tp_id | token | [This |
| | are used as | | srv_host | cli_host | document] | | | are used as | | srv_host | cli_host | document] |
| | per RFC8323 | | srv_port | ?cli_port | | | | per RFC8323 | | srv_port | ?cli_port | |
+------------+-------------+-------+----------+-----------+-----------+ +------------+-------------+-------+----------+-----------+-----------+
| WebSockets | WebSockets | 6 | tp_id | token | [This | | WebSockets | WebSockets | 6 | tp_id | token | [This |
| secured | with TLS | | srv_host | cli_host | document] | | secured | with TLS | | srv_host | cli_host | document] |
| with TLS | are used as | | srv_port | ?cli_port | | | with TLS | are used as | | srv_port | ?cli_port | |
| | per RFC8323 | | | | | | | per RFC8323 | | | | |
+------------+-------------+-------+----------+-----------+-----------+ +------------+-------------+-------+----------+-----------+-----------+
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft- for the Constrained Application Protocol (CoAP)", Work in
ietf-core-groupcomm-bis-03 (work in progress), February Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
2021. 04, 12 July 2021, <https://www.ietf.org/archive/id/
draft-ietf-core-groupcomm-bis-04.txt>.
[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.
[I-D.tiloca-core-observe-multicast-notifications] [I-D.ietf-core-observe-multicast-notifications]
Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini,
"Observe Notifications as CoAP Multicast Responses", "Observe Notifications as CoAP Multicast Responses", Work
draft-tiloca-core-observe-multicast-notifications-05 (work in Progress, Internet-Draft, draft-ietf-core-observe-
in progress), February 2021. multicast-notifications-01, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-observe-
multicast-notifications-01.txt>.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group OSCORE - Secure Group Communication
for CoAP", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-groupcomm-12, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-core-oscore-
groupcomm-12.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
skipping to change at page 28, line 5 skipping to change at page 37, line 21
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References 11.2. Informative References
[I-D.amsuess-core-cachable-oscore]
Amsuess, C. and M. Tiloca, "Cacheable OSCORE", Work in
Progress, Internet-Draft, draft-amsuess-core-cachable-
oscore-01, 22 February 2021,
<https://www.ietf.org/archive/id/draft-amsuess-core-
cachable-oscore-01.txt>.
[I-D.bormann-coap-misc] [I-D.bormann-coap-misc]
Bormann, C. and K. Hartke, "Miscellaneous additions to Bormann, C. and K. Hartke, "Miscellaneous additions to
CoAP", draft-bormann-coap-misc-27 (work in progress), CoAP", Work in Progress, Internet-Draft, draft-bormann-
November 2014. coap-misc-27, 14 November 2014,
<https://www.ietf.org/archive/id/draft-bormann-coap-misc-
27.txt>.
[I-D.ietf-ace-key-groupcomm-oscore] [I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- for OSCORE Groups in ACE", Work in Progress, Internet-
oscore-10 (work in progress), February 2021. Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July
2021, <https://www.ietf.org/archive/id/draft-ietf-ace-key-
groupcomm-oscore-11.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-41 (work in progress), 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
February 2021. dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>.
[I-D.tiloca-core-oscore-capable-proxies]
Tiloca, M. and R. Hoeglund, "OSCORE-capable Proxies", Work
in Progress, Internet-Draft, draft-tiloca-core-oscore-
capable-proxies-00, 12 July 2021,
<https://www.ietf.org/archive/id/draft-tiloca-core-oscore-
capable-proxies-00.txt>.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of
Groups with the CoRE Resource Directory", draft-tiloca- OSCORE Groups with the CoRE Resource Directory", Work in
core-oscore-discovery-08 (work in progress), February Progress, Internet-Draft, draft-tiloca-core-oscore-
2020. discovery-09, 12 July 2021,
<https://www.ietf.org/archive/id/draft-tiloca-core-oscore-
discovery-09.txt>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Using OSCORE Between Client and Proxy Appendix A. Examples with Reverse-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.
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.
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.
Appendix B. Examples with Reverse-Proxy
The examples in this section refer to the following actors. The examples in this section refer to the following actors.
o One origin client C, with address C_ADDR and port number C_PORT. * 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. * 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 * Two origin servers S1 and S2, where the server Sx has address
Sx_ADDR and port number Sx_PORT. Sx_ADDR and port number Sx_PORT.
The origin servers are members of a CoAP group with IP multicast 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 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. 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 The communication between C and P is based on CoAP over TCP, as per
[RFC8323]. The communication between P and the origin servers is [RFC8323]. The communication between P and the origin servers is
based on CoAP over UDP and IP multicast, as per based on CoAP over UDP and IP multicast, as per
[I-D.ietf-core-groupcomm-bis]. [I-D.ietf-core-groupcomm-bis].
Finally, 'bstr(X)' denotes a CBOR byte string with value the byte Finally, 'bstr(X)' denotes a CBOR byte string with value the byte
serialization of X. serialization of X.
B.1. Example 1 A.1. Example 1
The example shown in Figure 4 considers a reverse-proxy that stands 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 in for both the whole group of servers and for each of those servers
(e.g. acting as a firewall). (e.g., acting as a firewall).
In particular: In particular:
o The address 'group1.com' resolves to P_ADDR. The proxy forwards * The address 'group1.com' resolves to P_ADDR. The proxy forwards
an incoming request to that address, for any resource i.e. URI 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 path, towards the CoAP group at G_ADDR:G_PORT leaving the URI path
unchanged. unchanged.
o The address Dx_ADDR and port number Dx_PORT are used by the proxy, * The address Dx_ADDR and port number Dx_PORT are used by the proxy,
which forwards an incoming request to that address towards the which forwards an incoming request to that address towards the
server at Sx_ADDR:Sx_PORT. server at Sx_ADDR:Sx_PORT.
Note that this type of reverse-proxy implementation requires the Note that this type of reverse-proxy implementation requires the
proxy to use (potentially) a large number of distinct IP addresses, proxy to use (potentially) a large number of distinct IP addresses,
so it is not very scalable. so it is not very scalable.
C P S1 S2 C P S1 S2
| | | | | | | |
|----------------------------->| /* C is not aware | | |----------------------------->| /* C is not aware | |
| Src: C_ADDR:C_PORT | that P is in fact | | | Src: C_ADDR:C_PORT | that P is in fact | |
| Dst: group1.com:P_PORT | a reverse-proxy */ | | | Dst: group1.com:P_PORT | a reverse-proxy */ | |
| Uri-Path: /r | | | | Uri-Path: /r | | |
| | | | | | | |
| | | |
|<-----------------------------| | | |<-----------------------------| | |
| Src: group1.com:P_PORT | | | | Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| 4.00 Bad Request | | | | 4.00 Bad Request | | |
| Multicast-Signaling: (empty) | | | | Multicast-Signaling: (empty) | | |
| Payload: "Please use | | | | Payload: "Please use | | |
| Multicast-Signaling" | | | | Multicast-Signaling" | | |
| | | | | | | |
|----------------------------->| | | |----------------------------->| | |
| Src: C_ADDR:C_PORT | | | | Src: C_ADDR:C_PORT | | |
| Dst: group1.com:P_PORT | | | | Dst: group1.com:P_PORT | | |
| Multicast-Signaling: 60 | | | | Multicast-Signaling: 60 | | |
| Uri-Path: /r | | | | Uri-Path: /r | | |
| | | | | | | |
| | | |
| | | |
| | | |
| | | |
| | Src: P_ADDR:P_PORT | | | | Src: P_ADDR:P_PORT | |
| | Dst: G_ADDR:G_PORT | | | | Dst: G_ADDR:G_PORT | |
| | Uri-Path: /r | | | | Uri-Path: /r | |
| |---------------+----->| | | |---------------+----->| |
| | \ | | | | \ | |
| | +----------------->| | | +----------------->|
| | | | | | | |
| | /* t = 0 : P starts | | | | /* t = 0 : P starts | |
| | accepting responses | | | | accepting responses | |
| | for this request */ | | | | for this request */ | |
| | | | | | | |
| | | | | | | |
| | | |
| |<---------------------| | | |<---------------------| |
| | Src: S1_ADDR:S1_PORT | | | | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | | | | Dst: P_ADDR:P_PORT | |
| | | | | | | |
|<-----------------------------| | | |<-----------------------------| | |
| Src: group1.com:P_PORT | | | | Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | | | Response-Forwarding { | | |
| [3, /*CoAP over TCP*/ | | | | [3, /*CoAP over TCP*/ | | |
| #6.260(bstr(D1_ADDR)), | | | | #6.260(bstr(D1_ADDR)), | | |
skipping to change at page 33, line 22 skipping to change at page 40, line 50
| [3, /*CoAP over TCP*/ | | | | [3, /*CoAP over TCP*/ | | |
| #6.260(bstr(D2_ADDR)), | | | | #6.260(bstr(D2_ADDR)), | | |
| D2_PORT | | | | D2_PORT | | |
| ] | | | | ] | | |
| } | | | | } | | |
| | | | | | | |
| /* At t = 60, P stops accepting | | | /* At t = 60, P stops accepting | |
| responses for this request */ | | | responses for this request */ | |
| | | | | | | |
| | | | | | | |
| | | |
| | | |
|----------------------------->| /* Request intended | | |----------------------------->| /* Request intended | |
| Src: C_ADDR:C_PORT | only to S1 */ | | | Src: C_ADDR:C_PORT | only to S1 */ | |
| Dst: D1_ADDR:D1_PORT | | | | Dst: D1_ADDR:D1_PORT | | |
| Uri-Path: /r | | | | Uri-Path: /r | | |
| | | | | | | |
| | Src: P_ADDR:P_PORT | | | | Src: P_ADDR:P_PORT | |
| | Dst: S1_ADDR:S1_PORT | | | | Dst: S1_ADDR:S1_PORT | |
| | Uri-Path: /r | | | | Uri-Path: /r | |
| |--------------------->| | | |--------------------->| |
| | | | | | | |
| | | | | | | |
| |<---------------------| | | |<---------------------| |
| | Src: S1_ADDR:S1_PORT | | | | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | | | | Dst: P_ADDR:P_PORT | |
| | | | | | | |
|<-----------------------------| | | |<-----------------------------| | |
| Src: D1_ADDR:D1_PORT | | | | Src: D1_ADDR:D1_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| | | | | | | |
Figure 4: Workflow example with reverse-proxy standing in for both Figure 5: Workflow example with reverse-proxy standing in for
the whole group of servers and each individual server both the whole group of servers and each individual server
B.2. Example 2 A.2. Example 2
The example shown in Figure 5 builds on the example in Appendix B.1. 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 However, it considers a reverse-proxy that stands in for only the
whole group of servers, but not for each individual server. whole group of servers, but not for each individual server.
The final exchange between C and S1 occurs with CoAP over UDP. The final exchange between C and S1 occurs with CoAP over UDP.
C P S1 S2 C P S1 S2
| | | | | | | |
|----------------------------->| /* C is not aware | | |----------------------------->| /* C is not aware | |
| Src: C_ADDR:C_PORT | that P is in fact | | | Src: C_ADDR:C_PORT | that P is in fact | |
skipping to change at page 34, line 22 skipping to change at page 42, line 4
| Uri-Path: /r | | | | Uri-Path: /r | | |
| | | | | | | |
|<-----------------------------| | | |<-----------------------------| | |
| Src: group1.com:P_PORT | | | | Src: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| 4.00 Bad Request | | | | 4.00 Bad Request | | |
| Multicast-Signaling: (empty) | | | | Multicast-Signaling: (empty) | | |
| Payload: "Please use | | | | Payload: "Please use | | |
| Multicast-Signaling" | | | | Multicast-Signaling" | | |
| | | | | | | |
| | | |
|----------------------------->| | | |----------------------------->| | |
| Src: C_ADDR:C_PORT | | | | Src: C_ADDR:C_PORT | | |
| Dst: group1.com:P_PORT | | | | Dst: group1.com:P_PORT | | |
| Multicast-Signaling: 60 | | | | Multicast-Signaling: 60 | | |
| Uri-Path: /r | | | | Uri-Path: /r | | |
| | | | | | | |
| | Src: P_ADDR:P_PORT | | | | Src: P_ADDR:P_PORT | |
| | Dst: G_ADDR:G_PORT | | | | Dst: G_ADDR:G_PORT | |
| | Uri-Path: /r | | | | Uri-Path: /r | |
| |---------------+----->| | | |---------------+----->| |
| | \ | | | | \ | |
| | +----------------->| | | +----------------->|
| | | | | | | |
| | | |
| | /* t = 0 : P starts | | | | /* t = 0 : P starts | |
| | accepting responses | | | | accepting responses | |
| | for this request */ | | | | for this request */ | |
| | | | | | | |
| | | | | | | |
| |<---------------------| | | |<---------------------| |
| | Src: S1_ADDR:S1_PORT | | | | Src: S1_ADDR:S1_PORT | |
| | Dst: P_ADDR:P_PORT | | | | Dst: P_ADDR:P_PORT | |
| | | | | | | |
|<-----------------------------| | | |<-----------------------------| | |
skipping to change at page 35, line 19 skipping to change at page 43, line 4
|<-----------------------------| | | |<-----------------------------| | |
| Dst: group1.com:P_PORT | | | | Dst: group1.com:P_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| Response-Forwarding { | | | | Response-Forwarding { | | |
| [1, /*CoAP over UDP*/ | | | | [1, /*CoAP over UDP*/ | | |
| #6.260(bstr(S2_ADDR)), | | | | #6.260(bstr(S2_ADDR)), | | |
| S2_PORT | | | | S2_PORT | | |
| ] | | | | ] | | |
| } | | | | } | | |
| | | | | | | |
| | | |
| /* At t = 60, P stops accepting | | | /* At t = 60, P stops accepting | |
| responses for this request */ | | | responses for this request */ | |
| | | | | | | |
| | | | | | | |
| | | |
|---------------------------------------------------->| | |---------------------------------------------------->| |
| Src: C_ADDR:C_PORT | /* Request intended | | | Src: C_ADDR:C_PORT | /* Request intended | |
| Dst: S1.ADDR:S1_PORT | only to S1 */ | | | Dst: S1.ADDR:S1_PORT | only to S1 */ | |
| Uri-Path: /r | | | | Uri-Path: /r | | |
| | | | | | | |
| | | | | | | |
|<----------------------------------------------------| | |<----------------------------------------------------| |
| Src: S1.ADDR:S1_PORT | | | | Src: S1.ADDR:S1_PORT | | |
| Dst: C_ADDR:C_PORT | | | | Dst: C_ADDR:C_PORT | | |
| | | | | | | |
Figure 5: Workflow example with reverse-proxy standing in for only Figure 6: Workflow example with reverse-proxy standing in for
the whole group of servers, but not for each individual server only the whole group of servers, but not for each individual
server
Acknowledgments Acknowledgments
The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran
Selander for their comments and feedback. Selander for their comments and feedback.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
(Grant agreement 952652). (Grant agreement 952652).
skipping to change at page 36, line 4 skipping to change at page 43, line 35
Acknowledgments Acknowledgments
The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran
Selander for their comments and feedback. Selander for their comments and feedback.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
(Grant agreement 952652). (Grant agreement 952652).
Authors' Addresses Authors' Addresses
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista SE-16440 Stockholm SE-16440 Stockholm Kista
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
Esko Dijk Esko Dijk
IoTconsultancy.nl IoTconsultancy.nl
\________________\ \________________\
Utrecht Utrecht
The Netherlands
Email: esko.dijk@iotconsultancy.nl Email: esko.dijk@iotconsultancy.nl
 End of changes. 156 change blocks. 
359 lines changed or deleted 706 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/