idnits 2.17.1 draft-tiloca-core-groupcomm-proxy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1018 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-04 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-01 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-12 == Outdated reference: A later version (-08) exists of draft-amsuess-core-cachable-oscore-01 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-11 == Outdated reference: A later version (-07) exists of draft-tiloca-core-oscore-capable-proxies-00 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-09 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Updates: 7252 (if approved) E. Dijk 5 Intended status: Standards Track IoTconsultancy.nl 6 Expires: 13 January 2022 12 July 2021 8 Proxy Operations for CoAP Group Communication 9 draft-tiloca-core-groupcomm-proxy-04 11 Abstract 13 This document specifies the operations performed by a forward-proxy 14 or reverse-proxy, when using the Constrained Application Protocol 15 (CoAP) in group communication scenarios. Such CoAP proxy processes a 16 single request, sent by a CoAP client over unicast, and distributes 17 the request over IP multicast to a group of CoAP servers. It then 18 collects the individual responses from these CoAP servers and sends 19 these responses to the CoAP client, in a way that allows the client 20 to distinguish the responses and their origin servers through 21 addressing information. This document updates RFC7252. 23 Discussion Venues 25 This note is to be removed before publishing as an RFC. 27 Discussion of this document takes place on the Constrained RESTful 28 Environments Working Group mailing list (core@ietf.org), which is 29 archived at https://mailarchive.ietf.org/arch/browse/core/. 31 Source for this draft and an issue tracker can be found at 32 https://gitlab.com/crimson84/draft-tiloca-core-groupcomm-proxy. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 13 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 4 69 3. The Response-Forwarding Option . . . . . . . . . . . . . . . 5 70 3.1. Encoding of Server Address . . . . . . . . . . . . . . . 8 71 3.2. Default Values of the Server Port Number . . . . . . . . 8 72 4. Requirements and Objectives . . . . . . . . . . . . . . . . . 9 73 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 74 5.1. Request Sending at the Client . . . . . . . . . . . . . . 10 75 5.1.1. Request Sending . . . . . . . . . . . . . . . . . . . 10 76 5.1.2. Supporting Observe . . . . . . . . . . . . . . . . . 12 77 5.2. Request Processing at the Proxy . . . . . . . . . . . . . 12 78 5.2.1. Request Processing . . . . . . . . . . . . . . . . . 12 79 5.2.2. Supporting Observe . . . . . . . . . . . . . . . . . 13 80 5.3. Request and Response Processing at the Server . . . . . . 13 81 5.3.1. Request and Response Processing . . . . . . . . . . . 13 82 5.3.2. Supporting Observe . . . . . . . . . . . . . . . . . 14 83 5.4. Response Processing at the Proxy . . . . . . . . . . . . 14 84 5.4.1. Response Processing . . . . . . . . . . . . . . . . . 14 85 5.4.2. Supporting Observe . . . . . . . . . . . . . . . . . 15 86 5.5. Response Processing at the Client . . . . . . . . . . . . 16 87 5.5.1. Response Processing . . . . . . . . . . . . . . . . . 16 88 5.5.2. Supporting Observe . . . . . . . . . . . . . . . . . 17 89 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 6. Reverse-Proxies . . . . . . . . . . . . . . . . . . . . . . . 19 91 6.1. Processing on the Client Side . . . . . . . . . . . . . . 20 92 6.2. Processing on the Proxy Side . . . . . . . . . . . . . . 20 93 7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 7.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 21 95 7.2. Validation Model . . . . . . . . . . . . . . . . . . . . 23 96 7.2.1. Proxy-Servers Revalidation with Unicast Requests . . 23 97 7.2.2. Proxy-Servers Revalidation with Group Requests . . . 23 98 7.3. Client-Proxy Revalidation with Group Requests . . . . . . 23 99 7.4. Caching of End-To-End Protected Responses at Proxies . . 25 100 7.4.1. Deterministic Requests to Achieve Cacheability . . . 25 101 7.4.2. Validation of Responses . . . . . . . . . . . . . . . 26 102 8. Chain of Proxies . . . . . . . . . . . . . . . . . . . . . . 27 103 8.1. Request Processing at the Proxy . . . . . . . . . . . . . 27 104 8.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 29 105 8.2. Response Processing at the Proxy . . . . . . . . . . . . 29 106 8.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 30 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 108 9.1. Client Authentication . . . . . . . . . . . . . . . . . . 31 109 9.2. Multicast-Signaling Option . . . . . . . . . . . . . . . 32 110 9.3. Response-Forwarding Option . . . . . . . . . . . . . . . 33 111 9.4. Group-ETag Option . . . . . . . . . . . . . . . . . . . . 33 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 113 10.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 34 114 10.2. CoAP Transport Information Registry . . . . . . . . . . 35 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 35 117 11.2. Informative References . . . . . . . . . . . . . . . . . 37 118 Appendix A. Examples with Reverse-Proxy . . . . . . . . . . . . 38 119 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 39 120 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 41 121 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 124 1. Introduction 126 The Constrained Application Protocol (CoAP) [RFC7252] allows the 127 presence of forward-proxies and reverse-proxies, as intermediary 128 entities supporting clients to perform requests on their behalf. 130 CoAP supports also group communication over IP multicast 131 [I-D.ietf-core-groupcomm-bis], where a group request can be addressed 132 to multiple recipient servers, each of which may reply with an 133 individual unicast response. As discussed in Section 3.5 of 134 [I-D.ietf-core-groupcomm-bis], this group communication scenario 135 poses a number of issues and limitations to proxy operations. 137 In particular, the client sends a single unicast request to the 138 proxy, which the proxy forwards to a group of servers over IP 139 multicast. Later on, the proxy delivers back to the client multiple 140 responses to the original unicast request. As defined by [RFC7252], 141 the multiple responses are delivered to the client inside separate 142 CoAP messages, all matching (by Token) to the client's original 143 unicast request. A possible alternative approach of performing 144 aggregation of responses into a single CoAP response would require a 145 specific aggregation content-format, which is not available yet. 146 Both these approaches have open issues. 148 This specification considers the former approach, i.e., the proxy 149 forwards the individual responses to a CoAP group request back to the 150 client. The described method addresses all the related issues raised 151 in Section 3.5 of [I-D.ietf-core-groupcomm-bis]. To this end, a 152 dedicated signaling protocol is defined, using two new CoAP options. 154 Using this protocol, the client explicitly confirms its intent to 155 perform a proxied group request and its support for receiving 156 multiple responses as a result, i.e., one per origin server. It also 157 signals for how long it is willing to wait for responses. Also, when 158 forwarding a response to the client, the proxy indicates the 159 addressing information of the origin server. This enables the client 160 to distinguish multiple, diffent responses by origin and to possibly 161 contact one or more of the respective servers by sending individual 162 unicast request(s) to the indicated address(es). In doing these 163 follow-up unicast requests, the client may optionally bypass the 164 proxy. 166 Furthermore, this document defines a caching model for proxies and 167 specifies how they can serve a group request by using cached 168 responses. Therefore, this document updates [RFC7252]. 170 1.1. Terminology 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 Readers are expected to be familiar with terms and concepts defined 179 in CoAP [RFC7252], Group Communication for CoAP 180 [I-D.ietf-core-groupcomm-bis], CBOR [RFC8949], OSCORE [RFC8613] and 181 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 183 Unless specified otherwise, the term "proxy" refers to a CoAP-to-CoAP 184 forward-proxy, as defined in Section 5.7.2 of [RFC7252]. 186 2. The Multicast-Signaling Option 188 The Multicast-Signaling Option defined in this section has the 189 properties summarized in Figure 1, which extends Table 4 of 190 [RFC7252]. 192 Since the option is not Safe-to-Forward, the column "N" indicates a 193 dash for "not applicable". The value of the Multicast-Signaling 194 Option specifies a timeout value in seconds, encoded as an unsigned 195 integer (see Section 3.2 of [RFC7252]). 197 +------+---+---+---+---+------------+--------+--------+---------+ 198 | No. | C | U | N | R | Name | Format | Length | Default | 199 +------+---+---+---+---+------------+--------+--------+---------+ 200 | | | | | | | | | | 201 | TBD1 | | x | - | | Multicast- | uint | 0-5 | (none) | 202 | | | | | | Signaling | | | | 203 | | | | | | | | | | 204 +------+---+---+---+---+------------+--------+--------+---------+ 205 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 207 Figure 1: The Multicast-Signaling Option. 209 This document specifically defines how this option is used by a 210 client in a CoAP request, to indicate to a forward-proxy its support 211 for and interest in receiving multiple responses to a proxied CoAP 212 group request, i.e., one per origin server, and for how long it is 213 willing to wait for receiving responses via that proxy (see 214 Section 5.1.1 and Section 5.2.1). 216 The client, when sending a CoAP group request to a proxy via IP 217 unicast, to be forwarded by the proxy to a targeted group of servers, 218 includes the Multicast-Signaling Option into the request. The option 219 value indicates after what time period in seconds the client will 220 stop accepting responses matching its original unicast request, with 221 the exception of notifications if the CoAP Observe Option [RFC7641] 222 is used in the same request. Signaling the time period allows the 223 proxy to stop forwarding responses back to the client, that are 224 received from servers after the end of the time period. 226 The Multicast-Signaling Option is of class U in terms of OSCORE 227 processing (see Section 4.1 of [RFC8613]). 229 3. The Response-Forwarding Option 231 The Response-Forwarding Option defined in this section has the 232 properties summarized in Figure 2, which extends Table 4 of 233 [RFC7252]. The option is intended only for inclusion in CoAP 234 responses, and builds on the Base-Uri option from Section 3 of 235 [I-D.bormann-coap-misc]. 237 Since the option is intended only for responses, the column "N" 238 indicates a dash for "not applicable". 240 +------+---+---+---+---+------------+--------+--------+---------+ 241 | No. | C | U | N | R | Name | Format | Length | Default | 242 +------+---+---+---+---+------------+--------+--------+---------+ 243 | | | | | | | | | | 244 | TBD2 | | | - | | Response- | (*) | 10-25 | (none) | 245 | | | | | | Forwarding | | | | 246 | | | | | | | | | | 247 +------+---+---+---+---+------------+--------+--------+---------+ 248 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 250 (*) See below. 252 Figure 2: The Response-Forwarding Option. 254 This document specifically defines how this option is used by a proxy 255 that can perform proxied CoAP group communication requests. 257 Upon receiving a response to such request from a server, the proxy 258 includes the Response-Forwarding Option into the response sent to the 259 origin client (see Section 5). The proxy uses the option to indicate 260 the addressing information where the client can send an individual 261 request intended to that origin server. 263 In particular, the client can use the addressing information 264 specified in the option to identify the response originator and 265 possibly send it individual requests later on, either directly, or 266 indirectly via the proxy, as CoAP unicast requests. 268 The option value is set to the byte serialization of the CBOR array 269 'tp_info' defined in Section 2.2.1 of 270 [I-D.ietf-core-observe-multicast-notifications], including only the 271 set of elements 'srv_addr'. In turn, the set includes the integer 272 'tp_id' identifying the used transport protocol, and further elements 273 whose number, format and encoding depend on the value of 'tp_id'. 275 The value of 'tp_id' MUST be taken from the "Value" column of the 276 "CoAP Transport Information" Registry defined in Section 14.4 of 277 [I-D.ietf-core-observe-multicast-notifications]. The elements of 278 'srv_addr' following 'tp_id' are specified in the corresponding entry 279 of the Registry, under the "Server Addr" column. 281 If the server is reachable through CoAP transported over UDP, the 282 'tp_info' array includes the following elements, encoded as defined 283 in Section 2.2.1.1 of 284 [I-D.ietf-core-observe-multicast-notifications]. 286 * 'tp_id': the CBOR integer with value 1. This element MUST be 287 present. 289 * 'srv_host': a CBOR byte string, encoding the unicast IP address of 290 the server. This element is tagged and identified by the CBOR tag 291 260 "Network Address (IPv4 or IPv6 or MAC Address)". This element 292 MUST be present. 294 * 'srv_port': a CBOR unsigned integer or the CBOR simple value Null. 295 This element MAY be present. 297 If present as a CBOR unsigned integer, it has as value the 298 destination UDP port number to use for individual requests to the 299 server. 301 If present as the CBOR simple value Null, the client MUST assume 302 that the default port number 5683 defined in [RFC7252] can be used 303 as the destination UDP port number for individual requests to the 304 server. 306 If not present, the client MUST assume that the same port number 307 specified in the group URI of the original unicast CoAP group 308 request sent to the proxy (see Section 5.1.1) can be used for 309 individual requests to the server. 311 The CDDL notation [RFC8610] provided below describes the 'tp_info' 312 CBOR array using the format defined above. 314 tp_info = [ 315 tp_id : 1, ; UDP as transport protocol 316 srv_host : #6.260(bstr), ; IP address where to reach the server 317 ? srv_port : uint / null ; Port number where to reach the server 318 ] 320 At present, 'tp_id' is expected to take only value 1 (UDP) when using 321 forward proxies, UDP being the only currently available transport for 322 CoAP to work over IP multicast. While additional multicast-friendly 323 transports may be defined in the future, other current tranport 324 protocols can still be useful in applications relying on a reverse- 325 proxy (see Section 6). 327 The rest of this section considers the new values of 'tp_id' 328 registered by this document (see Section 10.2), and specifies: 330 * The encoding for the elements of 'tp_info' following 'tp_id' (see 331 Section 3.1). 333 * The port number assumed by the client if 'srv_port' in 'tp_info' 334 specifies the CBOR simple value Null (see Section 3.2). 336 The Response-Forwarding Option is of class U in terms of OSCORE 337 processing (see Section 4.1 of [RFC8613]). 339 3.1. Encoding of Server Address 341 This specification defines some values used as transport protocol 342 identifiers, whose respective new entries are included in the "CoAP 343 Transport Information" Registry defined in Section 14.4 of 344 [I-D.ietf-core-observe-multicast-notifications]. 346 For each of these values, the following table summarizes the elements 347 specified under the "Srv Addr" and "Req Info" columns of the 348 registry, together with their CBOR encoding and short description. 350 While not listed here for brevity, the element 'tp_id' is always 351 present as a CBOR integer in the element set "Srv Addr". 353 +----------+-------------+----------+--------------+---------------+ 354 | 'tp_id' | Element Set | Element | CBOR Type | Description | 355 | Values | | | | | 356 +----------+-------------+----------+--------------+---------------+ 357 | 2, 3, 4, | Srv Addr | srv_host | #6.260(bstr) | Address of | 358 | 5, 6 | | | (*) | the server | 359 | | +----------+--------------+---------------+ 360 | | | srv_port | uint / null | Port number | 361 | | | | | of the server | 362 | +-------------+----------+--------------+---------------+ 363 | | Req Info | cli_host | #6.260(bstr) | Address of | 364 | | | | (*) | the client | 365 | | +----------+--------------+---------------+ 366 | | | cli_port | uint | Port number | 367 | | | | | of the client | 368 +----------+-------------+----------+--------------+---------------+ 370 * The CBOR byte string is tagged and identified by the 371 CBOR tag 260 "Network Address (IPv4 or IPv6 or MAC Address)". 373 3.2. Default Values of the Server Port Number 375 If the 'srv_port' element in the 'tp_info' array specifies the CBOR 376 simple value Null, the client MUST assume the following value as port 377 number where to send individual requests intended to the server, 378 based on the value of 'tp_id'. 380 * If 'tp_id' is equal to 2, i.e., CoAP over UDP secured with DTLS, 381 the default port number 5684 as defined in [RFC7252]. 383 * If 'tp_id' is equal to 3, i.e., CoAP over TCP, the default port 384 number 5683 as defined in [RFC8323]. 386 * If 'tp_id' is equal to 4, i.e., CoAP over TCP secured with TLS, 387 the default port number 5684 as defined in [RFC8323]. 389 * If 'tp_id' is equal to 5, i.e., CoAP over WebSockets, the default 390 port number 80 as defined in [RFC8323]. 392 * If 'tp_id' is equal to 6, i.e., CoAP over WebSockets secured with 393 TLS, the default port number 443 as defined in [RFC8323]. 395 4. Requirements and Objectives 397 This specification assumes that the following requirements are 398 fulfilled. 400 * REQ1. The CoAP proxy is explicitly configured (allow-list) to 401 allow proxied CoAP group requests from specific client(s). 403 * REQ2. The CoAP proxy MUST identify a client sending a CoAP group 404 request, in order to verify whether the client is allowed-listed 405 to do so. For example, this can rely on one of the following 406 security associations. 408 - A TLS [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13] channel 409 between the client and the proxy, where the client has been 410 authenticated during the secure channel establishment. 412 - A pairwise OSCORE [RFC8613] Security Context between the client 413 and the proxy, as defined in 414 [I-D.tiloca-core-oscore-capable-proxies]. 416 * REQ3. If secure, end-to-end communication is required between the 417 client and the servers in the CoAP group, exchanged messages MUST 418 be protected by using Group OSCORE 419 [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5 of 420 [I-D.ietf-core-groupcomm-bis]. This requires the client and the 421 servers to have previously joined the correct OSCORE group, for 422 instance by using the approach described in 423 [I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to 424 join can be pre-configured or alternatively discovered, for 425 instance by using the approach described in 426 [I-D.tiloca-core-oscore-discovery]. 428 This specification defines how to achieve the following objectives. 430 * OBJ1. The CoAP proxy gets an indication from the client that it 431 is in fact interested in and capable to receive multiple responses 432 to its unicast request containing a CoAP group URI. 434 * OBJ2. The CoAP proxy learns how long it should wait for responses 435 to a proxied request, before starting to ignore following 436 responses (except for notifications, if a CoAP Observe Option is 437 used [RFC7641]). 439 * OBJ3. The CoAP proxy returns individual unicast responses to the 440 client, each of which matches the original unicast request made to 441 the proxy. 443 * OBJ4. The CoAP client is able to distinguish the different 444 responses to the original unicast request, as well as their 445 corresponding origin servers. 447 * OBJ5. The CoAP client is enabled to optionally contact one or 448 more of the responding origin servers in the future, either 449 directly or via the CoAP proxy. 451 5. Protocol Description 453 This section specifies the steps of the signaling protocol. 455 5.1. Request Sending at the Client 457 This section defines the operations that the client performs for 458 sending a request addressed to a group of servers via the CoAP proxy. 460 5.1.1. Request Sending 462 The client proceeds according to the following steps. 464 1. The client prepares a request addressed to the CoAP proxy. The 465 request specifies the group URI as a string in the Proxi-URI 466 option, or by using the Proxy-Scheme option with the group URI 467 constructed from the URI-* options (see Section 3.5.1 of 468 [I-D.ietf-core-groupcomm-bis]). 470 2. The client MUST retain the Token value used for this original 471 unicast request beyond the reception of a first response matching 472 it. To this end, the client follows the same rules for Token 473 retention defined for multicast requests in Section 3.1.5 of 474 [I-D.ietf-core-groupcomm-bis]. 476 In particular, the client picks an amount of time T it is fine to 477 wait for before freeing up the Token value. Specifically, the 478 value of T MUST be such that: 480 * T < T_r , where T_r is the amount of time that the client is 481 fine to wait for before potentially reusing the Token value. 482 Note that T_r MUST NOT be less than MIN_TOKEN_REUSE_TIME 483 defined in Section 3.1.5 of [I-D.ietf-core-groupcomm-bis]. 485 * T should be at least the expected worst-case time taken by the 486 request and response processing on the forward-proxy and on 487 the servers in the addressed CoAP group. 489 * T should be at least the expected worst-case round-trip delay 490 between the client and the forward-proxy plus the worst-case 491 round-trip delay between the proxy and any one of the origin 492 servers. 494 3. The client MUST include the Multicast-Signaling Option defined in 495 Section 2 into the unicast request to send to the proxy. The 496 option value specifies an amount of time T' < T. The difference 497 (T - T') should be at least the expected worst-case round-trip 498 time between the client and the forward-proxy. 500 The client can specify T' = 0 as option value, thus indicating to 501 be not interested in receiving responses from the origin servers 502 through the proxy. In such a case, the client SHOULD also 503 include a No-Response Option [RFC7967] with value 26 (suppress 504 all response codes), if it supports the option. 506 Consistently, if the unicast request to send to the proxy already 507 included a No-Response Option with value 26, the client SHOULD 508 specify T' = 0 as value of the Multicast-Signaling Option. 510 4. The client processes the request as defined in 511 [I-D.ietf-core-groupcomm-bis], and also as in 512 [I-D.ietf-core-oscore-groupcomm] when secure group communication 513 is used between the client and the servers. 515 5. The client protects the unicast request resulting at the end of 516 step 4, according to the security association it has with the 517 proxy. 519 6. The client sends the request to the proxy as a unicast CoAP 520 message. 522 The exact method that the client uses to estimate the worst-case 523 processing times and round-trip delays mentioned above is out of the 524 scope of this specification. However, such a method is expected to 525 be already used by the client when generally determining a good Token 526 lifetime and reuse interval. 528 5.1.2. Supporting Observe 530 When using CoAP Observe [RFC7641], the client follows what is 531 specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis], with the 532 difference that it sends a unicast request to the proxy, to be 533 forwarded to the group of servers, as defined in Section 5.1.1 of 534 this specification. 536 Furthermore, the client especially follows what is specified in 537 Section 5 of [RFC7641], i.e., it registers its interest to be an 538 observer with the proxy, as if it was communicating with the servers. 540 5.2. Request Processing at the Proxy 542 This section defines the operations that the proxy performs when 543 receiving a request addressed to a group of servers. 545 5.2.1. Request Processing 547 Upon receiving the request from the client, the proxy proceeds 548 according to the following steps. 550 1. The proxy decrypts the request, according to the security 551 association it has with the client. 553 2. The proxy identifies the client, and verifies that the client is 554 in fact allowed-listed to have its requests proxyied to CoAP 555 group URIs. 557 3. The proxy verifies the presence of the Multicast-Signaling 558 Option, as a confirmation that the client is fine to receive 559 multiple responses matching the same original request. 561 If the Multicast-Signaling Option is not present, the proxy MUST 562 stop processing the request and MUST reply to the client with a 563 4.00 (Bad Request) response. The response MUST include a 564 Multicast-Signaling Option with an empty (zero-length) value, 565 specifying that the Multicast-Signaling Option was missing and 566 has to be included in the request. As per Section 5.9.2 of 567 [RFC7252] The response SHOULD include a diagnostic payload. 569 4. The proxy retrieves the value T' from the Multicast-Signaling 570 Option, and then removes the option from the client's request. 572 5. The proxy forwards the client's request to the group of servers. 573 In particular, the proxy sends it as a CoAP group request over IP 574 multicast, addressed to the group URI specified by the client. 576 6. The proxy sets a timeout with the value T' retrieved from the 577 Multicast-Signaling Option of the original unicast request. 579 In case T' > 0, the proxy will ignore responses to the forwarded 580 group request coming from servers, if received after the timeout 581 expiration, with the exception of Observe notifications (see 582 Section 5.4). 584 In case T' = 0, the proxy will ignore all responses to the 585 forwarded group request coming from servers. 587 If the proxy supports caching of responses, it can serve the original 588 unicast request also by using cached responses, as per Section 7. 590 5.2.2. Supporting Observe 592 When using CoAP Observe [RFC7641], the proxy takes the role of the 593 client and registers its own interest to observe the target resource 594 with the servers as per Section 5 of [RFC7641]. 596 When doing so, the proxy especially follows what is specified for the 597 client in Section 3.7 of [I-D.ietf-core-groupcomm-bis], by forwarding 598 the group request to the servers over IP multicast, as defined in 599 Section 5.2.1 of this specification. 601 5.3. Request and Response Processing at the Server 603 This section defines the operations that the server performs when 604 receiving a group request from the proxy. 606 5.3.1. Request and Response Processing 608 Upon receiving the request from the proxy, the server proceeds 609 according to the following steps. 611 1. The server processes the group request as defined in 612 [I-D.ietf-core-groupcomm-bis], and also as in 613 [I-D.ietf-core-oscore-groupcomm] when secure group communication 614 is used between the client and the server. 616 2. The server processes the response to be forwarded back to the 617 client as defined in [I-D.ietf-core-groupcomm-bis], and also as 618 in [I-D.ietf-core-oscore-groupcomm] when secure group 619 communication is used between the client and the server. 621 5.3.2. Supporting Observe 623 When using CoAP Observe [RFC7641], the server especially follows what 624 is specified in Section 3.7 of [I-D.ietf-core-groupcomm-bis] and 625 Section 5 of [RFC7641]. 627 5.4. Response Processing at the Proxy 629 This section defines the operations that the proxy performs when 630 receiving a response matching a forwarded group request. 632 5.4.1. Response Processing 634 Upon receiving a response matching the group request before the 635 amount of time T' has elapsed, the proxy proceeds according to the 636 following steps. 638 1. The proxy MUST include the Response-Forwarding Option defined in 639 Section 3 into the response. The proxy specifies as option value 640 the addressing information of the server generating the response, 641 encoded as defined in Section 3. In particular: 643 * The 'srv_addr' element of the 'srv_info' array MUST specify 644 the server IPv6 address if the multicast request was destined 645 for an IPv6 multicast address, and MUST specify the server 646 IPv4 address if the multicast request was destined for an IPv4 647 address. 649 * If present, the 'srv_port' element of the 'srv_info' array 650 MUST specify the port number of the server as the source port 651 number of the response. This element MUST be present if the 652 source port number of the response differs from the port 653 number specified in the group URI of the original unicast CoAP 654 group request (see Section 5.1.1). Otherwise, the 'srv_port' 655 element MAY be omitted. 657 2. The proxy protects the response according to the security 658 association it has with the client. 660 3. The proxy forwards the response back to the client. 662 As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is 663 possible that a same server replies with multiple responses to the 664 same group request, i.e., with the same Token. As long as the proxy 665 forwards responses to a group request back to the origin client, the 666 proxy MUST follow the steps defined above and forward also such 667 multiple responses "as they come". 669 Upon timeout expiration, i.e., T' seconds after having sent the group 670 request over IP multicast, the proxy frees up its local Token value 671 associated to that request. Thus, following late responses to the 672 same group request will be discarded and not forwarded back to the 673 client. 675 5.4.2. Supporting Observe 677 When using CoAP Observe [RFC7641], the proxy acts as a client 678 registered with the servers, as described earlier in Section 5.2.2. 680 Furthermore, the proxy takes the role of a server when forwarding 681 notifications from origin servers back to the client. To this end, 682 the proxy follows what is specified in Section 3.7 of 683 [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the 684 following additions. 686 * At step 1 in Section 5.4, the proxy includes the Response- 687 Forwarding Option in every notification, including non-2.xx 688 notifications resulting in removing the proxy from the list of 689 observers of the origin server. 691 * The proxy frees up its Token value used for a group observation 692 only if, after the timeout expiration, no 2.xx (Success) responses 693 matching the group request and also including an Observe option 694 have been received from any origin server. After that, as long as 695 observations are active with servers in the group for the target 696 resource of the group request, notifications from those servers 697 are forwarded back to the client, as defined in Section 5.4, and 698 the Token value used for the group observation is not freed during 699 this time. 701 Finally, the proxy SHOULD regularly verify that the client is still 702 interested in receiving observe notifications for a group 703 observation. To this end, the proxy can rely on the same approach 704 discussed for servers in Section 3.7 of 705 [I-D.ietf-core-groupcomm-bis], with more details available in 706 Section 4.5 of [RFC7641]. 708 5.5. Response Processing at the Client 710 This section defines the operations that the client performs when 711 receiving a response matching a request addressed to a group of 712 servers via the CoAP proxy. 714 5.5.1. Response Processing 716 Upon receiving from the proxy a response matching the original 717 unicast request before the amount of time T has elapsed, the client 718 proceeds according to the following steps. 720 1. The client processes the response as defined in 721 [I-D.ietf-core-groupcomm-bis]. 723 2. The client decrypts the response, according to the security 724 association it has with the proxy. 726 3. If secure group communication is used end-to-end between the 727 client and the servers, the client processes the response 728 resulting at the end of step 2, as defined in 729 [I-D.ietf-core-oscore-groupcomm]. 731 4. The client identifies the origin server, whose addressing 732 information is specified as value of the Response-Forwarding 733 Option. If the port number is omitted in the value of the 734 Response-Forwarding Option, the client MUST assume that the port 735 number where to send unicast requests to the server -- in case 736 this is needed -- is the same port number specified in the group 737 URI of the original unicast CoAP group request sent to the proxy 738 (see Section 5.1.1). 740 In particular, the client is able to distinguish different 741 responses as originated by different servers. Optionally, the 742 client may contact one or more of those servers individually, 743 i.e., directly (bypassing the proxy) or indirectly (via a proxied 744 CoAP unicast request). 746 In order to individually reach an origin server again through the 747 proxy, the client is not required to understand or support the 748 transport protocol indicated in the Response-Forwarding Option, 749 as used between the proxy and the origin server, in case it 750 differs from "UDP" (1). That is, using the IPv4/IPv6 address 751 value and optional port value from the Response-Forwarding 752 Option, the client simply creates the correct URI for the 753 individual request, by means of the Proxy-Uri or Uri-Scheme 754 Option in the unicast request to the proxy. The client uses the 755 transport protocol it knows, and has used before, to send the 756 request to the proxy. 758 As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is 759 possible that the client receives multiple responses to the same 760 group request, i.e., with the same Token, from the same origin 761 server. The client normally processes at the CoAP layer each of 762 those responses from the same origin server, and decides how to 763 exactly handle them depending on its available context information 764 (see Section 3.1.6 of [I-D.ietf-core-groupcomm-bis]). 766 Upon the timeout expiration, i.e., T seconds after having sent the 767 original unicast request to the proxy, the client frees up its local 768 Token value associated to that request. Note that, upon this timeout 769 expiration, the Token value is not eligible for possible reuse yet 770 (see Section 5.1.1). Thus, until the actual amount of time before 771 enabling Token reusage has elapsed, any following late responses to 772 the same request forwarded by the proxy will be discarded, as these 773 are not matching (by Token) any active request from the client. 775 5.5.2. Supporting Observe 777 When using CoAP Observe [RFC7641], the client frees up its Token 778 value only if, after the timeout T expiration, no 2.xx (Success) 779 responses matching the original unicast request and also including an 780 Observe option have been received. 782 Instead, if at least one such response has been received, the client 783 continues receiving those notifications as forwarded by the proxy, as 784 long as the observation for the target resource of the original 785 unicast request is active. 787 5.6. Example 789 The example in this section refers to the following actors. 791 * One origin client C, with address C_ADDR and port number C_PORT. 793 * One proxy P, with address P_ADDR and port number P_PORT. 795 * Two origin servers S1 and S2, where the server Sx has address 796 Sx_ADDR and port number Sx_PORT. 798 The origin servers are members of a CoAP group with IP multicast 799 address G_ADDR and port number G_PORT. Also, the origin servers are 800 members of a same application group, and share the same resource /r. 802 The communication between C and P is based on CoAP over UDP, as per 803 [RFC7252]. The communication between P and the origin servers is 804 based on CoAP over UDP and IP multicast, as per 805 [I-D.ietf-core-groupcomm-bis]. 807 Finally, 'bstr(X)' denotes a CBOR byte string with value the byte 808 serialization of X. 810 C P S1 S2 811 | | | | 812 |------------------------->| | | 813 | Src: C_ADDR:C_PORT | | | 814 | Dst: P_ADDR:P_PORT | | | 815 | Proxi-URI { | | | 816 | coap://G_ADDR:G_PORT/r | | | 817 | } | | | 818 | Multicast-Signaling: 60 | | | 819 | | | | 820 | | Src: P_ADDR:P_PORT | | 821 | | Dst: G_ADDR:G_PORT | | 822 | | Uri-Path: /r | | 823 | |---------------+----->| | 824 | | \ | | 825 | | +----------------->| 826 | | | | 827 | | /* t = 0 : P starts | | 828 | | accepting responses | | 829 | | for this request */ | | 830 | | | | 831 | | | | 832 | |<---------------------| | 833 | | Src: S1_ADDR:G_PORT | | 834 | | Dst: P_ADDR:P_PORT | | 835 | | | | 836 | | | | 837 |<-------------------------| | | 838 | Src: P_ADDR:P_PORT | | | 839 | Dst: C_ADDR:C_PORT | | | 840 | Response-Forwarding { | | | 841 | [1, /*CoAP over UDP*/ | | | 842 | #6.260(bstr(S1_ADDR)) | | | 843 | ] | | | 844 | } | | | 845 | |<-----------------------------------| 846 | | Src: S2_ADDR:S2_PORT | 847 | | Dst: P_ADDR:P_PORT | 848 | | | | 849 | | | | 850 | | | | 851 |<-------------------------| | | 852 | Src: P_ADDR:P_PORT | | | 853 | Dst: C_ADDR:C_PORT | | | 854 | Response-Forwarding { | | | 855 | [1, /*CoAP over UDP*/ | | | 856 | #6.260(bstr(S2_ADDR)), | | | 857 | S2_PORT | | | 858 | ] | | | 859 | } | | | 860 | /* At t = 60, P stops accepting | | 861 | responses for this request */ | | 862 | | | | 864 Figure 3: Workflow example with a forward-proxy 866 6. Reverse-Proxies 868 The use of reverse-proxies in group communication scenarios is 869 defined in Section 3.5.2 of [I-D.ietf-core-groupcomm-bis]. 871 This section clarifies how the Multicast-Signaling Option is 872 effective also in such a context, in order for: 874 * The proxy to explictly reveal itself as a reverse-proxy to the 875 client. 877 * The client to indicate to the proxy of being aware that it is 878 communicating with a reverse-proxy, and for how long it is willing 879 to receive responses to a proxied request. 881 This practically addresses the addional issues compared to the case 882 with a forward-proxy, as compiled in Section 3.5.2 of 883 [I-D.ietf-core-groupcomm-bis]. A reverse-proxy may also operate 884 without support of the Multicast-Signaling Option, as defined in that 885 section. 887 Appendix A provides examples with a reverse-proxy. 889 6.1. Processing on the Client Side 891 If a client sends a request intended to a group of servers and is 892 aware of actually communicating with a reverse-proxy, then the client 893 MUST perform the steps defined in Section 5.1.1. In particular, this 894 results in a request sent to the proxy including a Multicast- 895 Signaling Option. 897 The client processes the responses forwarded back by the proxy as 898 defined in Section 5.5. 900 6.2. Processing on the Proxy Side 902 If the proxy receives a request and determines that it should forward 903 it to a group of servers over IP multicast, then the proxy MUST 904 perform the steps defined in Section 5.2. 906 In particular, when such request does not include a Multicast- 907 Signaling Option, the proxy explicitly reveals itself as a reverse- 908 proxy, by sending a 4.00 (Bad Request) response including a 909 Multicast-Signaling Option with empty (zero-length) value. 911 7. Caching 913 A proxy MAY cache responses to a group request, as defined in 914 Section 5.7.1 of [RFC7252]. In particular, these same rules apply to 915 determine the set of request options used as "Cache-Key", and to 916 determine the max-age values offered for responses served from the 917 cache. 919 A cache entry is associated to one server and stores one response 920 from that server, regardless whether it is a response to a unicast 921 request or to a group request. The following two types of requests 922 can produce a hit to a cache entry. 924 * A matching request intended to that server, i.e., to the 925 corresponding unicast URI. 927 When the stored response is a response to a unicast request to the 928 server, the unicast URI of the matching request is the same target 929 URI used for the original unicast request. 931 When the stored response is a response to a group request to the 932 CoAP group, the unicast URI of the matching request is the target 933 URI obtained by replacing the authority part of the group URI in 934 the original group request with the transport-layer source address 935 and port number of the response. 937 * A matching group request intended to the CoAP group, i.e., to the 938 corresponding group URI. 940 That is, a matching group request produces a hit to multiple cache 941 entries, each of which associated to one of the CoAP servers 942 currently member of the CoAP group. 944 Note that, as per the freshness model defined in Section 7.1, the 945 proxy might serve a group request exclusively from its cached 946 responses only when it knows all the CoAP servers that are current 947 members of the CoAP group and it has a valid cache entry for each 948 of them. 950 When forwarding a GET or FETCH group request to the servers in the 951 CoAP group, a proxy behaves like a CoAP client as defined in 952 Section 3.2 of [I-D.ietf-core-groupcomm-bis], with the following 953 additions. 955 * As discussed in Section 5.4.1, the proxy can receive multiple 956 responses to the same group request from a same origin server, and 957 forwards them back to the origin client "as they come". When this 958 happens, each of such multiple responses is stored in the cache 959 entry associated to the server "as it comes", possibly replacing 960 an already stored response from that server. 962 * As discussed in Section 7.4, when communications in the group are 963 secured with Group OSCORE [I-D.ietf-core-oscore-groupcomm], 964 additional means are required to enable cacheability of responses 965 at the proxy. 967 The following subsections define the freshness model and validation 968 model that the proxy uses for cached responses. 970 7.1. Freshness Model 972 The proxy relies on the same freshness model defined in Section 3.2.1 973 of [I-D.ietf-core-groupcomm-bis], by taking the role of a CoAP client 974 with respect to the servers in the CoAP group. 976 In particular, when receiving a group request, the proxy MAY serve 977 the request by using exclusively cached responses without forwarding 978 the group request to the servers in the CoAP group, but only if both 979 the following conditions hold. 981 * The proxy knows all the CoAP servers that are currently members of 982 the CoAP group for which the group request is intended to. 984 * The proxy's cache currently stores a fresh response for each of 985 those CoAP servers. 987 The specific way that the proxy uses to determine the CoAP servers 988 currently members of the target CoAP group is out of scope for this 989 document. As possible examples, the proxy can synchronize with a 990 group manager server; rely on well-known time patterns used in the 991 application or in the network for the addition of new CoAP group 992 members; observe group join requests or IGMP/MLD multicast group join 993 messages, e.g., if embedded in a multicast router. 995 When forwarding the group request to the servers, the proxy may have 996 fresh responses stored in its cache for (some of) those servers. In 997 such a case, the proxy uses (also) those cached responses to serve 998 the original unicast request, as defined below. 1000 * The request processing in Section 5.2.1 is extended as follows. 1002 After setting the timeout with value T' > 0 in step 6, the proxy 1003 checks whether its cache currently stores fresh responses to the 1004 group request. For each of such responses, the proxy compares the 1005 residual lifetime L of the corresponding cache entry against the 1006 value T'. 1008 If a cached response X is such that L < T', then the proxy 1009 forwards X back to the client at its earliest convenience. 1010 Otherwise, the proxy does not forward X back to the client right 1011 away, and rather waits for approaching the timeout expiration, as 1012 discussed in the next point. 1014 * The response processing in Section 5.4.1 is extended as follows. 1016 Before the timeout with original value T' > 0 expires and the 1017 proxy stops accepting responses to the group request, the proxy 1018 checks whether it stores in its cache any fresh response X to the 1019 group request such that both the following conditions hold. 1021 - The cache entry E storing X was already existing when 1022 forwarding the group request. 1024 - The proxy has received no response to the forwarded group 1025 request from the server associated to E. 1027 Then, the proxy forwards back to the client each response X stored 1028 in its cache and selected as above, before the timeout expires. 1030 Note that, from the forwarding of the group request until the 1031 timeout expiration, the proxy still forwards responses to the 1032 group request back to the client as they come (see Section 5.4.1). 1033 Also, such responses possibly refresh older responses from the 1034 same servers that the proxy has stored in its cache, as defined 1035 earlier in Section 7. 1037 7.2. Validation Model 1039 This section defines the revalidation of responses, separately 1040 between the proxy and the origin servers, as well as between the 1041 origin client and the proxy. 1043 7.2.1. Proxy-Servers Revalidation with Unicast Requests 1045 The proxy MAY revalidate a cached response by making a GET or FETCH 1046 request on the related unicast request URI, i.e., by taking the role 1047 of a CoAP client with respect to a server in the CoAP group. 1049 As discussed in Section 7.4, this is however not possible for the 1050 proxy if communications in the group are secured end-to-end between 1051 origin client and origin servers by using Group OSCORE 1052 [I-D.ietf-core-oscore-groupcomm]. 1054 7.2.2. Proxy-Servers Revalidation with Group Requests 1056 When forwarding a group request to the servers in the CoAP group, the 1057 proxy MAY revalidate one of more stored responses it has cached. 1059 To this end, the proxy relies on the same validation model defined in 1060 Section 3.2.2 of [I-D.ietf-core-groupcomm-bis] and using the ETag 1061 Option, by taking the role of a CoAP client with respect to the 1062 servers in the CoAP group. 1064 As discussed in Section 7.4, this is however not possible for the 1065 proxy if communications in the group are secured end-to-end between 1066 origin client and origin servers by using Group OSCORE 1067 [I-D.ietf-core-oscore-groupcomm]. 1069 7.3. Client-Proxy Revalidation with Group Requests 1071 A client MAY revalidate the full set of responses to a group request 1072 by leveraging the corresponding cache entries at the proxy. To this 1073 end, this specification defines the new Group-ETag Option. 1075 The Group-ETag Option has the properties summarized in Figure 4, 1076 which extends Table 4 of [RFC7252]. The Group-ETag Option is 1077 elective, safe to forward, part of the cache key, and repeatable. 1079 The option is intended for group requests sent to a proxy, as well as 1080 for the associated responses. 1082 +------+---+---+---+---+------------+--------+--------+---------+ 1083 | No. | C | U | N | R | Name | Format | Length | Default | 1084 +------+---+---+---+---+------------+--------+--------+---------+ 1085 | | | | | | | | | | 1086 | TBD3 | | | | x | Group-ETag | opaque | 1-8 | (none) | 1087 | | | | | | | | | | 1088 +------+---+---+---+---+------------+--------+--------+---------+ 1089 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 1091 Figure 4: The Group-ETag Option. 1093 The Group-ETag Option has the same properties of the ETag Option 1094 defined in Section 5.10.6 of [RFC7252]. 1096 The Group-ETag Option is of class U in terms of OSCORE processing 1097 (see Section 4.1 of [RFC8613]). 1099 A proxy MUST NOT provide this form of validation if it is not in a 1100 position to serve a group request by using exclusively cached 1101 responses, i.e., without forwarding the group request to the servers 1102 in the CoAP group (see Section 7.1). 1104 If the proxy supports this form of response revalidation, the 1105 following applies. 1107 * The proxy defines J as a joint set including all the cache entries 1108 currently storing fresh responses that satisfy a group request. A 1109 set J is "complete" if it includes a valid cache entry for each of 1110 the CoAP servers currently members of the CoAP group. 1112 * When the set J becomes "complete", the proxy assigns it an entity- 1113 tag value. The proxy MUST update the current entity-tag value, 1114 when J is "complete" and one of its cache entry is updated. 1116 * When returning a 2.05 (Content) response to a GET or FETCH group 1117 request, the proxy MAY include one Group-ETag Option, in case the 1118 set J is "complete". Such a response MUST NOT include more than 1119 one Group-ETag Option. The option value specifies the entity-tag 1120 value currently associated to the set J. 1122 When sending a GET or FETCH group request to the proxy, to be 1123 forwarded to a CoAP group, the client MAY include one or more Group- 1124 ETag Options. Each option specifies one entity-tag value, applicable 1125 to the set J of cache entries that can be hit by the group request. 1127 The proxy MAY perform the following actions, in case the group 1128 request produces a hit to the cache entry of each CoAP server 1129 currently member of the CoAP group, i.e., the set J associated to the 1130 group request is "complete". 1132 * The proxy checks whether the current entity-tag value of the set J 1133 matches with one of the entity-tag values specified in the Group- 1134 ETag Options of the group request. 1136 * In case of positive match, the proxy replies with a single 2.03 1137 (Valid) response. This response has no payload and MUST include 1138 one Group-ETag Option, specifying the current entity-tag value of 1139 the set J. 1141 That is, the 2.03 (Valid) response from the proxy indicates to the 1142 client that the stored responses idenfied by the entity-tag given in 1143 the response's Group-ETag Option can be reused, after updating each 1144 of them as described in Section 5.9.1.3 of [RFC7252]. In effect, the 1145 client can determine if any of the stored representations from the 1146 respective cache entries at the proxy is current, without needing to 1147 transfer any of them again. 1149 7.4. Caching of End-To-End Protected Responses at Proxies 1151 When using Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect 1152 communications end-to-end between a client and multiple servers in 1153 the group, it is normally not possible for an intermediary proxy to 1154 cache protected responses. 1156 In fact, when starting from the same plain CoAP message, different 1157 clients generate different protected requests to send on the wire. 1158 This prevents different clients to generate potential cache hits, and 1159 thus makes response caching at the proxy pointless. 1161 7.4.1. Deterministic Requests to Achieve Cacheability 1163 For application scenarios that use secure group communication, it is 1164 still possible to achieve cacheability of responses at proxies, by 1165 using the approach defined in [I-D.amsuess-core-cachable-oscore] 1166 which is based on Deterministic Requests protected with the pairwise 1167 mode of Group OSCORE. This approach is limited to group requests 1168 that are safe (in the RESTful sense) to process and do not yield side 1169 effects at the server. As for any protected group request, it 1170 requires the clients and all the servers in the CoAP group to have 1171 already joined the correct OSCORE group. 1173 Starting from the same plain CoAP request, this allows different 1174 clients in the OSCORE group to deterministically generate a same 1175 request protected with Group OSCORE, which is sent to the proxy for 1176 being forwarded to the CoAP group. The proxy can now effectively 1177 cache the resulting responses from the servers in the CoAP group, 1178 since the same plain CoAP request will result again in the same 1179 Deterministic Request and thus will produce a cache hit. 1181 When caching of Group OSCORE secured responses is enabled at the 1182 proxy, the same as defined in Section 7 applies, with respect to 1183 cache entries and their lifetimes. 1185 Note that different Deterministic Requests result in different cache 1186 entries at the proxy. This includes the case where different plain 1187 group requests differ only in their set of ETag Options, as defined 1188 in Section 3.2.2 of [I-D.ietf-core-groupcomm-bis]. 1190 That is, even though the servers would produce the same plain CoAP 1191 responses in reply to two different Deterministic Requests, those 1192 will result in different protected responses to each respective 1193 Deterministic Request, hence in different cache entries at the proxy. 1195 Thus, given a plain group request, a client needs to reuse the same 1196 set of ETag Options, in order to send that group request as a 1197 Deterministic Request that can actually produce a cache hit at the 1198 proxy. However, while this would prevent the caching at the proxy to 1199 be inefficient and unnecessarily redundant, it would also limit the 1200 flexibility of end-to-end response revalidation for a client. 1202 7.4.2. Validation of Responses 1204 Response revalidation remains possible end-to-end between the client 1205 and the servers in the group, by means of including inner ETag 1206 Option(s) as defined in Sections 3.2 and 3.2.2 of 1207 [I-D.ietf-core-groupcomm-bis]. 1209 Furthermore, it remains possible for a client to attempt revalidating 1210 responses to a group request from a "complete" set of cache entries 1211 at the proxy, by using the Group-ETag Option as defined in 1212 Section 7.3. 1214 When directly interacting with the servers in the CoAP group to 1215 refresh its cache entries, the proxy cannot rely on response 1216 revalidation anymore. This applies to both the case where the 1217 request is addressed to a single server and sent to the related 1218 unicast URI (see Section 7.2.1) or instead is a group request 1219 addressed to the CoAP group and sent to the related group URI (see 1220 Section 7.2.2). 1222 8. Chain of Proxies 1224 A client may be interested to access a resource at a group of origin 1225 servers which is reached through a chain of two or more proxies. 1227 That is, these proxies are configured into a chain, where each non- 1228 last proxy is configured to forward CoAP (group) requests to the next 1229 hop towards the origin servers. Also, each non-first proxy is 1230 configured to forward back CoAP responses to (the previous hop proxy 1231 towards) the origin client. 1233 This section specifies how the signaling protocol defined in 1234 Section 5 is used in that setting. Except for the last proxy before 1235 the origin servers, every other proxy in the chain takes the role of 1236 client with respect to the next hop towards the origin servers. 1237 Also, every proxy in the chain except the first takes the role of 1238 server towards the previous proxy closer to the origin client. 1240 Accordingly, possible caching of responses at each proxy works as 1241 defined in Section 7 and Section 7.4. Also, possible revalidation of 1242 responses cached ad each proxy and based on the Group-ETag option 1243 works as defined in Section 7.3 and Section 7.4.2. 1245 The requirements REQ1 and REQ2 defined in Section 4 MUST be fulfilled 1246 for each proxy in the chain. That is, every proxy in the chain has 1247 to be explicitly configured (allow-list) to allow proxied group 1248 requests from specific senders, and MUST identify those senders upon 1249 receiving their group request. For the first proxy in the chain, 1250 that sender is the origin client. For each other proxy in the chain, 1251 that sender is the previous hop proxy closer to the origin client. 1252 In either case, a proxy can identify the sender of a group request by 1253 the same means mentioned in Section 4. 1255 8.1. Request Processing at the Proxy 1257 Upon receiving a group request to be forwarded to a CoAP group URIs, 1258 a proxy proceed as follows. 1260 If the proxy is the last one in the chain, i.e., it is the last hop 1261 before the origin servers, the proxy performs the steps defined in 1262 Section 5.2, with no modifications. 1264 Otherwise, the proxy performs the steps defined in Section 5.2, with 1265 the following differences. 1267 * At steps 1-3, "client" refers to the origin client for the first 1268 proxy in the chain; or to the previous hop proxy closer to the 1269 origin client, otherwise. 1271 * At step 4, the proxy rather performs the following actions. 1273 1. The proxy retrieves the value T' from the Multicast-Signaling 1274 Option, and does not remove the option. 1276 2. In case T' > 0, the proxy picks an amount of time T it is fine 1277 to wait for before freeing up its local Token value to use 1278 with the next hop towards the origin servers. To this end, 1279 the proxy MUST follow what is defined at step 2 of 1280 Section 5.1.1 for the origin client, with the following 1281 differences. 1283 - T MUST be greater than the retrieved value T', i.e., T' < 1284 T. 1286 - The worst-case message processing time takes into account 1287 all the next hops towards the origin servers, as well as 1288 the origin servers themselves. 1290 - The worst-case round-trip delay takes into account all the 1291 legs between the proxy and the origin servers. 1293 3. In case T' > 0, the proxy replaces the value of the Multicast- 1294 Signaling Option with a new value T'', such that: 1296 - T'' < T. The difference (T - T'') should be at least the 1297 expected worst-case round-trip time between the proxy and 1298 the next hop towards the origin servers. 1300 - T'' < T'. The difference (T' - T'') should be at least the 1301 expected worst-case round-trip time between the proxy and 1302 the (previous hop proxy closer to the) origin client. 1304 If the proxy is not able to determine a value T'' that 1305 fulfills both the requirements above, the proxy MUST stop 1306 processing the request and MUST respond with a 5.05 (Proxying 1307 Not Supported) error response to the previous hop proxy closer 1308 to the origin client. The proxy SHOULD include a Multicast- 1309 Signaling Option, set to the minimum value T' that would be 1310 acceptable in the Multicast-Signaling Option of a request to 1311 forward. 1313 Upon receiving such an error response, any proxy in the chain 1314 MAY send an updated request to the next hop towards the origin 1315 servers, specifying in the Multicast-Signaling Option a value 1316 T' greater than in the previous request. If this does not 1317 happen, the proxy receiving the error response MUST also send 1318 a 5.05 (Proxying Not Supported) error response to the previous 1319 hop proxy closer to the origin client. Like the received one, 1320 also this error response SHOULD include a Multicast-Signaling 1321 Option, set to the minimum value T' acceptable by the proxy 1322 sending the error response. 1324 * At step 5, the proxy forwards the request to the next hop towards 1325 the origin servers. 1327 * At step 6, the proxy sets a timeout with the value T' retrieved 1328 from the Multicast-Signaling Option of the request received from 1329 the (previous hop proxy closer to the) origin client. 1331 In case T' > 0, the proxy will ignore responses to the forwarded 1332 group request coming from the (next hop towards the) origin 1333 servers, if received after the timeout expiration, with the 1334 exception of Observe notifications (see Section 5.4). 1336 In case T' = 0, the proxy will ignore all responses to the 1337 forwarded group request coming from the (next hop towards the) 1338 origin servers. 1340 8.1.1. Supporting Observe 1342 When using CoAP Observe [RFC7641], what is defined in Section 5.2.2 1343 applies for the last proxy in the chain, i.e., the last hop before 1344 the origin servers. 1346 Any other proxy in the chain acts as a client and registers its own 1347 interest to observe the target resource with the next hop towards the 1348 origin servers, as per Section 5 of [RFC7641]. 1350 8.2. Response Processing at the Proxy 1352 Upon receiving a response matching the group request before the 1353 amount of time T' has elapsed, the proxy proceeds as follows. 1355 If the proxy is the last one in the chain, i.e., it is the last hop 1356 before the origin servers, the proxy performs the steps defined in 1357 Section 5.4, with no modifications. 1359 Otherwise, the proxy performs the steps defined in Section 5.4, with 1360 the following differences. 1362 * The proxy skips step 1. In particular, the proxy MUST NOT remove, 1363 alter or replace the Response-Forwarding Option. 1365 * At steps 2-3, "client" refers to the origin client for the first 1366 proxy in the chain; or to the previous hop proxy closer to the 1367 origin client, otherwise. 1369 As to the possible reception of multiple responses to the same group 1370 request from the same (next hop proxy towards the) origin server, the 1371 same as defined in Section 5.4.1 applies. That is, as long as the 1372 proxy forwards responses to a group request back to the (previous hop 1373 proxy closer to the) origin client, the proxy MUST follow the steps 1374 above and forward also such multiple responses "as they come". 1376 Upon timeout expiration, i.e., T seconds after having sent the group 1377 request to the next hop towards the origin servers, the proxy frees 1378 up its local Token value associated to that request. Thus, following 1379 late responses to the same group request will be discarded and not 1380 forwarded back to the (previous hop proxy closer to the) origin 1381 client. 1383 8.2.1. Supporting Observe 1385 When using CoAP Observe [RFC7641], what is defined in Section 5.4.2 1386 applies for the last proxy in the chain, i.e., the last hop before 1387 the origin servers. 1389 As to any other proxy in the chain, the following applies. 1391 * The proxy acts as a client registered with the next hop towards 1392 the origin servers, as described earlier in Section 8.1.1. 1394 * The proxy takes the role of a server when forwarding notifications 1395 from the next hop to the origin servers back to the (previous hop 1396 proxy closer to the) origin client, as per Section 5 of [RFC7641]. 1398 * The proxy frees up its Token value used for a group observation 1399 only if, after the timeout expiration, no 2.xx (Success) responses 1400 matching the group request and also including an Observe option 1401 have been received from the next hop towards the origin servers. 1402 After that, as long as the observation for the target resource of 1403 the group request is active with the next hop towards the origin 1404 servers in the group, notifications from that hop are forwarded 1405 back to the (previous hop proxy closer to the) origin client, as 1406 defined in Section 8.2. 1408 * The proxy SHOULD regularly verify that the (previous hop proxy 1409 closer to the) origin client is still interested in receiving 1410 observe notifications for a group observation. To this end, the 1411 proxy can rely on the same approach defined in Section 4.5 of 1412 [RFC7641]. 1414 9. Security Considerations 1416 The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi 1417 s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. 1419 When a chain of proxies is used (see Section 8), the secure 1420 communication between any two adjacent hops is independent. 1422 When Group OSCORE is used for end-to-end secure group communication 1423 between the origin client and the origin servers, this security 1424 association is unaffected by the possible presence of a proxy or a 1425 chain of proxies. 1427 Furthermore, the following additional considerations hold. 1429 9.1. Client Authentication 1431 As per the requirement REQ2 (see Section 4), the client has to 1432 authenticate to the proxy when sending a group request to forward. 1433 This leverages an established security association between the client 1434 and the proxy, that the client uses to protect the group request, 1435 before sending it to the proxy. 1437 Note that, if the group request is (also) protected with Group 1438 OSCORE, i.e., end-to-end between the client and the servers, the 1439 proxy can authenticate the client by successfully verifying the 1440 counter signature embedded in the group request. However, this 1441 requires that, for each client to authenticate, the proxy stores the 1442 public key used by that client in the OSCORE group, which in turn 1443 would require a form of active synchronization between the proxy and 1444 the Group Manager for that group [I-D.ietf-core-oscore-groupcomm]. 1446 Nevertheless, the client and the proxy SHOULD still rely on a full- 1447 fledged, pairwise secure association. In addition to ensuring the 1448 integrity of group requests sent to the proxy (see Section 9.2, 1449 Section 9.3 and Section 9.4), this prevents the proxy from forwarding 1450 replayed group requests with a valid counter signature, as possibly 1451 injected by an active, on-path adversary. 1453 The same considerations apply when a chain of proxies is used (see 1454 Section 8), with each proxy but the last one in the chain acting as 1455 client with the next hop towards the origin servers. 1457 9.2. Multicast-Signaling Option 1459 The Multicast-Signaling Option is of class U for OSCORE [RFC8613]. 1460 Hence, also when Group OSCORE is used between the client and the 1461 servers [I-D.ietf-core-oscore-groupcomm], a proxy is able to access 1462 the option value and retrieve the timeout value T', as well as to 1463 remove the option altogether before forwarding the group request to 1464 the servers. When a chain of proxies is used (see Section 8), this 1465 also allows each proxy but the last one in the chain to update the 1466 option value, as an indication for the next hop towards the origin 1467 servers (see Section 8.1). 1469 The security association between the client and the proxy MUST 1470 provide message integrity, so that further intermediaries between the 1471 two as well as on-path active adversaries are not able to remove the 1472 option or alter its content, before the group request reaches the 1473 proxy. Removing the option would otherwise result in not forwarding 1474 the group request to the servers. Instead, altering the option 1475 content would result in the proxy accepting and forwarding back 1476 responses for an amount of time different than the one actually 1477 indicated by the client. 1479 The security association between the client and the proxy SHOULD also 1480 provide message confidentiality. Otherwise, any further 1481 intermediaries between the two as well as any on-path passive 1482 adversaries would be able to simply access the option content, and 1483 thus learn for how long the client is willing to receive responses 1484 from the servers in the group via the proxy. This may in turn be 1485 used to perform a more efficient, selective suppression of responses 1486 from the servers. 1488 When the client protects the unicast request sent to the proxy using 1489 OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or with 1490 (D)TLS, both message integrity and message confidentiality are 1491 achieved in the leg between the client and the proxy. 1493 The same considerations above about security associations apply when 1494 a chain of proxies is used (see Section 8), with each proxy but the 1495 last one in the chain acting as client with the next hop towards the 1496 origin servers. 1498 9.3. Response-Forwarding Option 1500 The Response-Forwarding Option is of class U for OSCORE [RFC8613]. 1501 Hence, also when Group OSCORE is used between the client and the 1502 servers [I-D.ietf-core-oscore-groupcomm], the proxy that has 1503 forwarded the group request to the servers is able to include the 1504 option into a server response, before forwarding this response back 1505 to the (previous hop proxy closer to the) origin client. 1507 Since the security association between the client and the proxy 1508 provides message integrity, any further intermediaries between the 1509 two as well as any on-path active adversaries are not able to 1510 undetectably remove the Response-Forwarding Option from a forwarded 1511 server response. This ensures that the client can correctly 1512 distinguish the different responses and identify their corresponding 1513 origin server. 1515 When the proxy protects the response forwarded back to the client 1516 using OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or 1517 (D)TLS, message integrity is achieved in the leg between the client 1518 and the proxy. 1520 The same considerations above about security associations apply when 1521 a chain of proxies is used (see Section 8), with each proxy but the 1522 last one in the chain acting as client with the next hop towards the 1523 origin servers. 1525 9.4. Group-ETag Option 1527 The Group-ETag Option is of class U for OSCORE [RFC8613]. Hence, 1528 also when Group OSCORE is used between the client and the servers 1529 [I-D.ietf-core-oscore-groupcomm], a proxy is able to access the 1530 option value and use it to possibly perform response revalidation at 1531 its cache entries associated to the servers in the CoAP group, as 1532 well as to remove the option altogether before forwarding the group 1533 request to the servers. When a chain of proxies is used (see 1534 Section 8), this also allows each proxy but the last one in the chain 1535 to update the option value, to possibly ask the next hop towards the 1536 origin servers to perform response revalidation at its cache entries. 1538 The security association between the client and the proxy MUST 1539 provide message integrity, so that further intermediaries between the 1540 two as well as on-path active adversaries are not able to remove the 1541 option or alter its content, before the group request reaches the 1542 proxy. Removing the option would otherwise result in the proxy not 1543 performing response revalidation at its cache entries associated to 1544 the servers in the CoAP group, even though that was what the client 1545 asked for. 1547 Altering the option content in a group request would result in the 1548 proxy replying with 2.05 (Content) responses conveying the full 1549 resource representations from its cache entries, rather than with a 1550 single 2.03 (Valid) response. Instead, altering the option content 1551 in a 2.03 (Valid) or 2.05 (Content) response would result in the 1552 client wrongly believing that the already stored or the just received 1553 representation, respectively, is also the current one, as per the 1554 entity value of the tampered Group-ETag option. 1556 The security association between the client and the proxy SHOULD also 1557 provide message confidentiality. Otherwise, any further 1558 intermediaries between the two as well as any on-path passive 1559 adversaries would be able to simply access the option content, and 1560 thus learn the rate and pattern according to which the group resource 1561 in question changes over time, as inferable from the entity values 1562 read over time. 1564 When the client protects the unicast request sent to the proxy using 1565 OSCORE (see [I-D.tiloca-core-oscore-capable-proxies]) and/or (D)TLS, 1566 both message integrity and message confidentiality are achieved in 1567 the leg between the client and the proxy. 1569 The same considerations above about security associations apply when 1570 a chain of proxies is used (see Section 8), with each proxy but the 1571 last one in the chain acting as client with the next hop towards the 1572 origin servers. 1574 When caching of Group OSCORE secured responses is enabled at the 1575 proxy, the same as defined in Section 7 applies, with respect to 1576 cache entries and the way they are maintained. 1578 10. IANA Considerations 1580 This document has the following actions for IANA. 1582 10.1. CoAP Option Numbers Registry 1584 IANA is asked to enter the following option numbers to the "CoAP 1585 Option Numbers" registry defined in [RFC7252] within the "CoRE 1586 Parameters" registry. 1588 +--------+---------------------+-------------------+ 1589 | Number | Name | Reference | 1590 +--------+---------------------+-------------------+ 1591 | TBD1 | Multicast-Signaling | [[this document]] | 1592 +--------+---------------------+-------------------+ 1593 | TBD2 | Response-Forwarding | [[this document]] | 1594 +--------+---------------------+-------------------+ 1595 | TBD3 | Group-ETag | [[this document]] | 1596 +--------+---------------------+-------------------+ 1598 10.2. CoAP Transport Information Registry 1600 IANA is asked to enter the following entries to the "CoAP Transport 1601 Information" Registry defined in Section 14.4 of 1602 [I-D.ietf-core-observe-multicast-notifications]. 1604 +------------+-------------+-------+----------+-----------+-----------+ 1605 | Transport | Description | Value | Srv Addr | Req Info | Reference | 1606 | Protocol | | | | | | 1607 +------------+-------------+-------+----------+-----------+-----------+ 1608 | UDP | UDP with | 2 | tp_id | token | [This | 1609 | secured | DTLS is | | srv_host | cli_host | document] | 1610 | with DTLS | used as per | | srv_port | ?cli_port | | 1611 | | RFC8323 | | | | | 1612 +------------+-------------+-------+----------+-----------+-----------+ 1613 | TCP | TCP is used | 3 | tp_id | token | [This | 1614 | | as per | | srv_host | cli_host | document] | 1615 | | RFC8323 | | srv_port | ?cli_port | | 1616 +------------+-------------+-------+----------+-----------+-----------+ 1617 | TCP | TCP with | 4 | tp_id | token | [This | 1618 | secured | TLS is | | srv_host | cli_host | document] | 1619 | with TLS | used as per | | srv_port | ?cli_port | | 1620 | | RFC8323 | | | | | 1621 +------------+-------------+-------+----------+-----------+-----------+ 1622 | WebSockets | WebSockets | 5 | tp_id | token | [This | 1623 | | are used as | | srv_host | cli_host | document] | 1624 | | per RFC8323 | | srv_port | ?cli_port | | 1625 +------------+-------------+-------+----------+-----------+-----------+ 1626 | WebSockets | WebSockets | 6 | tp_id | token | [This | 1627 | secured | with TLS | | srv_host | cli_host | document] | 1628 | with TLS | are used as | | srv_port | ?cli_port | | 1629 | | per RFC8323 | | | | | 1630 +------------+-------------+-------+----------+-----------+-----------+ 1632 11. References 1634 11.1. Normative References 1636 [I-D.ietf-core-groupcomm-bis] 1637 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1638 for the Constrained Application Protocol (CoAP)", Work in 1639 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 1640 04, 12 July 2021, . 1643 [I-D.ietf-core-observe-multicast-notifications] 1644 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 1645 "Observe Notifications as CoAP Multicast Responses", Work 1646 in Progress, Internet-Draft, draft-ietf-core-observe- 1647 multicast-notifications-01, 12 July 2021, 1648 . 1651 [I-D.ietf-core-oscore-groupcomm] 1652 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 1653 and J. Park, "Group OSCORE - Secure Group Communication 1654 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 1655 core-oscore-groupcomm-12, 12 July 2021, 1656 . 1659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1660 Requirement Levels", BCP 14, RFC 2119, 1661 DOI 10.17487/RFC2119, March 1997, 1662 . 1664 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1665 Application Protocol (CoAP)", RFC 7252, 1666 DOI 10.17487/RFC7252, June 2014, 1667 . 1669 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1670 Application Protocol (CoAP)", RFC 7641, 1671 DOI 10.17487/RFC7641, September 2015, 1672 . 1674 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1675 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1676 May 2017, . 1678 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1679 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1680 Application Protocol) over TCP, TLS, and WebSockets", 1681 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1682 . 1684 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1685 Definition Language (CDDL): A Notational Convention to 1686 Express Concise Binary Object Representation (CBOR) and 1687 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1688 June 2019, . 1690 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1691 "Object Security for Constrained RESTful Environments 1692 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1693 . 1695 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1696 Representation (CBOR)", STD 94, RFC 8949, 1697 DOI 10.17487/RFC8949, December 2020, 1698 . 1700 11.2. Informative References 1702 [I-D.amsuess-core-cachable-oscore] 1703 Amsuess, C. and M. Tiloca, "Cacheable OSCORE", Work in 1704 Progress, Internet-Draft, draft-amsuess-core-cachable- 1705 oscore-01, 22 February 2021, 1706 . 1709 [I-D.bormann-coap-misc] 1710 Bormann, C. and K. Hartke, "Miscellaneous additions to 1711 CoAP", Work in Progress, Internet-Draft, draft-bormann- 1712 coap-misc-27, 14 November 2014, 1713 . 1716 [I-D.ietf-ace-key-groupcomm-oscore] 1717 Tiloca, M., Park, J., and F. Palombini, "Key Management 1718 for OSCORE Groups in ACE", Work in Progress, Internet- 1719 Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July 1720 2021, . 1723 [I-D.ietf-tls-dtls13] 1724 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1725 Datagram Transport Layer Security (DTLS) Protocol Version 1726 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1727 dtls13-43, 30 April 2021, . 1730 [I-D.tiloca-core-oscore-capable-proxies] 1731 Tiloca, M. and R. Hoeglund, "OSCORE-capable Proxies", Work 1732 in Progress, Internet-Draft, draft-tiloca-core-oscore- 1733 capable-proxies-00, 12 July 2021, 1734 . 1737 [I-D.tiloca-core-oscore-discovery] 1738 Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of 1739 OSCORE Groups with the CoRE Resource Directory", Work in 1740 Progress, Internet-Draft, draft-tiloca-core-oscore- 1741 discovery-09, 12 July 2021, 1742 . 1745 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1746 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1747 January 2012, . 1749 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1750 Bose, "Constrained Application Protocol (CoAP) Option for 1751 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1752 August 2016, . 1754 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1755 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1756 . 1758 Appendix A. Examples with Reverse-Proxy 1760 The examples in this section refer to the following actors. 1762 * One origin client C, with address C_ADDR and port number C_PORT. 1764 * One proxy P, with address P_ADDR and port number P_PORT. 1766 * Two origin servers S1 and S2, where the server Sx has address 1767 Sx_ADDR and port number Sx_PORT. 1769 The origin servers are members of a CoAP group with IP multicast 1770 address G_ADDR and port number G_PORT. Also, the origin servers are 1771 members of a same application group, and share the same resource /r. 1773 The communication between C and P is based on CoAP over TCP, as per 1774 [RFC8323]. The communication between P and the origin servers is 1775 based on CoAP over UDP and IP multicast, as per 1776 [I-D.ietf-core-groupcomm-bis]. 1778 Finally, 'bstr(X)' denotes a CBOR byte string with value the byte 1779 serialization of X. 1781 A.1. Example 1 1783 The example shown in Figure 5 considers a reverse-proxy that stands 1784 in for both the whole group of servers and for each of those servers 1785 (e.g., acting as a firewall). 1787 In particular: 1789 * The address 'group1.com' resolves to P_ADDR. The proxy forwards 1790 an incoming request to that address, for any resource i.e., URI 1791 path, towards the CoAP group at G_ADDR:G_PORT leaving the URI path 1792 unchanged. 1794 * The address Dx_ADDR and port number Dx_PORT are used by the proxy, 1795 which forwards an incoming request to that address towards the 1796 server at Sx_ADDR:Sx_PORT. 1798 Note that this type of reverse-proxy implementation requires the 1799 proxy to use (potentially) a large number of distinct IP addresses, 1800 so it is not very scalable. 1802 C P S1 S2 1803 | | | | 1804 |----------------------------->| /* C is not aware | | 1805 | Src: C_ADDR:C_PORT | that P is in fact | | 1806 | Dst: group1.com:P_PORT | a reverse-proxy */ | | 1807 | Uri-Path: /r | | | 1808 | | | | 1809 |<-----------------------------| | | 1810 | Src: group1.com:P_PORT | | | 1811 | Dst: C_ADDR:C_PORT | | | 1812 | 4.00 Bad Request | | | 1813 | Multicast-Signaling: (empty) | | | 1814 | Payload: "Please use | | | 1815 | Multicast-Signaling" | | | 1816 | | | | 1817 |----------------------------->| | | 1818 | Src: C_ADDR:C_PORT | | | 1819 | Dst: group1.com:P_PORT | | | 1820 | Multicast-Signaling: 60 | | | 1821 | Uri-Path: /r | | | 1822 | | | | 1823 | | | | 1824 | | | | 1825 | | | | 1826 | | | | 1827 | | Src: P_ADDR:P_PORT | | 1828 | | Dst: G_ADDR:G_PORT | | 1829 | | Uri-Path: /r | | 1830 | |---------------+----->| | 1831 | | \ | | 1832 | | +----------------->| 1833 | | | | 1834 | | /* t = 0 : P starts | | 1835 | | accepting responses | | 1836 | | for this request */ | | 1837 | | | | 1838 | | | | 1839 | | | | 1840 | |<---------------------| | 1841 | | Src: S1_ADDR:S1_PORT | | 1842 | | Dst: P_ADDR:P_PORT | | 1843 | | | | 1844 |<-----------------------------| | | 1845 | Src: group1.com:P_PORT | | | 1846 | Dst: C_ADDR:C_PORT | | | 1847 | Response-Forwarding { | | | 1848 | [3, /*CoAP over TCP*/ | | | 1849 | #6.260(bstr(D1_ADDR)), | | | 1850 | D1_PORT | | | 1851 | ] | | | 1852 | } | | | 1853 | | | | 1854 | |<-----------------------------------| 1855 | | Src: S2_ADDR:S2_PORT | 1856 | | Dst: P_ADDR:P_PORT | 1857 | | | | 1858 |<-----------------------------| | | 1859 | Src: group1.com:P_PORT | | | 1860 | Dst: C_ADDR:C_PORT | | | 1861 | Response-Forwarding { | | | 1862 | [3, /*CoAP over TCP*/ | | | 1863 | #6.260(bstr(D2_ADDR)), | | | 1864 | D2_PORT | | | 1865 | ] | | | 1866 | } | | | 1867 | | | | 1868 | /* At t = 60, P stops accepting | | 1869 | responses for this request */ | | 1870 | | | | 1871 | | | | 1872 | | | | 1873 | | | | 1874 |----------------------------->| /* Request intended | | 1875 | Src: C_ADDR:C_PORT | only to S1 */ | | 1876 | Dst: D1_ADDR:D1_PORT | | | 1877 | Uri-Path: /r | | | 1878 | | | | 1879 | | Src: P_ADDR:P_PORT | | 1880 | | Dst: S1_ADDR:S1_PORT | | 1881 | | Uri-Path: /r | | 1882 | |--------------------->| | 1883 | | | | 1884 | | | | 1885 | |<---------------------| | 1886 | | Src: S1_ADDR:S1_PORT | | 1887 | | Dst: P_ADDR:P_PORT | | 1888 | | | | 1889 |<-----------------------------| | | 1890 | Src: D1_ADDR:D1_PORT | | | 1891 | Dst: C_ADDR:C_PORT | | | 1892 | | | | 1894 Figure 5: Workflow example with reverse-proxy standing in for 1895 both the whole group of servers and each individual server 1897 A.2. Example 2 1899 The example shown in Figure 6 builds on the example in Appendix A.1. 1901 However, it considers a reverse-proxy that stands in for only the 1902 whole group of servers, but not for each individual server. 1904 The final exchange between C and S1 occurs with CoAP over UDP. 1906 C P S1 S2 1907 | | | | 1908 |----------------------------->| /* C is not aware | | 1909 | Src: C_ADDR:C_PORT | that P is in fact | | 1910 | Dst: group1.com:P_PORT | a reverse-proxy */ | | 1911 | Uri-Path: /r | | | 1912 | | | | 1913 |<-----------------------------| | | 1914 | Src: group1.com:P_PORT | | | 1915 | Dst: C_ADDR:C_PORT | | | 1916 | 4.00 Bad Request | | | 1917 | Multicast-Signaling: (empty) | | | 1918 | Payload: "Please use | | | 1919 | Multicast-Signaling" | | | 1920 | | | | 1921 | | | | 1922 |----------------------------->| | | 1923 | Src: C_ADDR:C_PORT | | | 1924 | Dst: group1.com:P_PORT | | | 1925 | Multicast-Signaling: 60 | | | 1926 | Uri-Path: /r | | | 1927 | | | | 1928 | | Src: P_ADDR:P_PORT | | 1929 | | Dst: G_ADDR:G_PORT | | 1930 | | Uri-Path: /r | | 1931 | |---------------+----->| | 1932 | | \ | | 1933 | | +----------------->| 1934 | | | | 1935 | | | | 1936 | | /* t = 0 : P starts | | 1937 | | accepting responses | | 1938 | | for this request */ | | 1939 | | | | 1940 | | | | 1941 | |<---------------------| | 1942 | | Src: S1_ADDR:S1_PORT | | 1943 | | Dst: P_ADDR:P_PORT | | 1944 | | | | 1945 |<-----------------------------| | | 1946 | Dst: group1.com:P_PORT | | | 1947 | Dst: C_ADDR:C_PORT | | | 1948 | Response-Forwarding { | | | 1949 | [1, /*CoAP over UDP*/ | | | 1950 | #6.260(bstr(S1_ADDR)), | | | 1951 | S1_PORT | | | 1952 | ] | | | 1953 | } | | | 1954 | | | | 1955 | |<-----------------------------------| 1956 | | Src: S2_ADDR:S2_PORT | 1957 | | Dst: P_ADDR:P_PORT | 1958 | | | | 1959 |<-----------------------------| | | 1960 | Dst: group1.com:P_PORT | | | 1961 | Dst: C_ADDR:C_PORT | | | 1962 | Response-Forwarding { | | | 1963 | [1, /*CoAP over UDP*/ | | | 1964 | #6.260(bstr(S2_ADDR)), | | | 1965 | S2_PORT | | | 1966 | ] | | | 1967 | } | | | 1968 | | | | 1969 | | | | 1970 | /* At t = 60, P stops accepting | | 1971 | responses for this request */ | | 1972 | | | | 1973 | | | | 1974 | | | | 1975 |---------------------------------------------------->| | 1976 | Src: C_ADDR:C_PORT | /* Request intended | | 1977 | Dst: S1.ADDR:S1_PORT | only to S1 */ | | 1978 | Uri-Path: /r | | | 1979 | | | | 1980 | | | | 1981 |<----------------------------------------------------| | 1982 | Src: S1.ADDR:S1_PORT | | | 1983 | Dst: C_ADDR:C_PORT | | | 1984 | | | | 1986 Figure 6: Workflow example with reverse-proxy standing in for 1987 only the whole group of servers, but not for each individual 1988 server 1990 Acknowledgments 1992 The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran 1993 Selander for their comments and feedback. 1995 The work on this document has been partly supported by VINNOVA and 1996 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1997 (Grant agreement 952652). 1999 Authors' Addresses 2001 Marco Tiloca 2002 RISE AB 2003 Isafjordsgatan 22 2004 SE-16440 Stockholm Kista 2005 Sweden 2007 Email: marco.tiloca@ri.se 2009 Esko Dijk 2010 IoTconsultancy.nl 2011 \________________\ 2012 Utrecht 2014 Email: esko.dijk@iotconsultancy.nl