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