idnits 2.17.1 draft-tiloca-core-groupcomm-proxy-03.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 (February 22, 2021) is 1156 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 (-10) exists of draft-ietf-core-groupcomm-bis-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-11 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-10 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-41 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-08 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 6 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 Intended status: Standards Track E. Dijk 5 Expires: August 26, 2021 IoTconsultancy.nl 6 February 22, 2021 8 Proxy Operations for CoAP Group Communication 9 draft-tiloca-core-groupcomm-proxy-03 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 such that the client is able to 20 distinguish the responses and their origin servers through addressing 21 information. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 26, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 4 60 3. The Response-Forwarding Option . . . . . . . . . . . . . . . 5 61 3.1. Encoding of Server Address . . . . . . . . . . . . . . . 7 62 3.2. Default Values of the Server Port Number . . . . . . . . 8 63 4. Requirements and Objectives . . . . . . . . . . . . . . . . . 8 64 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 10 65 5.1. Request Sending at the Client . . . . . . . . . . . . . . 10 66 5.1.1. Request Sending . . . . . . . . . . . . . . . . . . . 10 67 5.1.2. Supporting Observe . . . . . . . . . . . . . . . . . 11 68 5.2. Request Processing at the Proxy . . . . . . . . . . . . . 11 69 5.2.1. Request Processing . . . . . . . . . . . . . . . . . 12 70 5.2.2. Supporting Observe . . . . . . . . . . . . . . . . . 13 71 5.3. Request and Response Processing at the Server . . . . . . 13 72 5.3.1. Request and Response Processing . . . . . . . . . . . 13 73 5.3.2. Supporting Observe . . . . . . . . . . . . . . . . . 13 74 5.4. Response Processing at the Proxy . . . . . . . . . . . . 13 75 5.4.1. Response Processing . . . . . . . . . . . . . . . . . 13 76 5.4.2. Supporting Observe . . . . . . . . . . . . . . . . . 14 77 5.5. Response Processing at the Client . . . . . . . . . . . . 15 78 5.5.1. Response Processing . . . . . . . . . . . . . . . . . 15 79 5.5.2. Supporting Observe . . . . . . . . . . . . . . . . . 16 80 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 6. Reverse-Proxies . . . . . . . . . . . . . . . . . . . . . . . 18 82 6.1. Processing on the Client Side . . . . . . . . . . . . . . 19 83 6.2. Processing on the Proxy Side . . . . . . . . . . . . . . 19 84 7. Chain of Proxies . . . . . . . . . . . . . . . . . . . . . . 19 85 7.1. Request Processing at the Proxy . . . . . . . . . . . . . 20 86 7.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 21 87 7.2. Response Processing at the Proxy . . . . . . . . . . . . 22 88 7.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 22 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 8.1. Client Authentication . . . . . . . . . . . . . . . . . . 23 91 8.2. Multicast-Signaling Option . . . . . . . . . . . . . . . 24 92 8.3. Response-Forwarding Option . . . . . . . . . . . . . . . 25 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 9.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 25 95 9.2. CoAP Transport Information Registry . . . . . . . . . . . 25 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 98 10.2. Informative References . . . . . . . . . . . . . . . . . 28 99 Appendix A. Using OSCORE Between Client and Proxy . . . . . . . 28 100 A.1. Protecting the Request . . . . . . . . . . . . . . . . . 29 101 A.2. Verifying the Request . . . . . . . . . . . . . . . . . . 30 102 A.3. Protecting the Response . . . . . . . . . . . . . . . . . 30 103 A.4. Verifying the Response . . . . . . . . . . . . . . . . . 30 104 Appendix B. Examples with Reverse-Proxy . . . . . . . . . . . . 31 105 B.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 31 106 B.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 33 107 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 110 1. Introduction 112 The Constrained Application Protocol (CoAP) [RFC7252] allows the 113 presence of forward-proxies and reverse-proxies, as intermediary 114 entities supporting clients to perform requests on their behalf. 116 CoAP supports also group communication over IP multicast 117 [I-D.ietf-core-groupcomm-bis], where a group request can be addressed 118 to multiple recipient servers, each of which may reply with an 119 individual unicast response. As discussed in Section 3.4 of 120 [I-D.ietf-core-groupcomm-bis], this group communication scenario 121 poses a number of issues and limitations to proxy operations. 123 In particular, the client sends a single unicast request to the 124 proxy, which the proxy forwards to a group of servers over IP 125 multicast. Later on, the proxy delivers back to the client multiple 126 responses to the original unicast request. As defined by [RFC7252], 127 the multiple responses are delivered to the client inside separate 128 CoAP messages, all matching (by Token) to the client's original 129 unicast request. A possible alternative approach of performing 130 aggregation of responses into a single CoAP response would require a 131 specific aggregation content-format, which is not available yet. 132 Both these approaches have open issues. 134 This specification considers the former approach, i.e. the proxy 135 forwards the individual responses to a CoAP group request back to the 136 client. The described method addresses all the related issues raised 137 in Section 3.4 of [I-D.ietf-core-groupcomm-bis]. To this end, a 138 dedicated signaling protocol is defined, using two new CoAP options. 140 Using this protocol, the client explicitly confirms its intent to 141 perform a proxied group request and its support for receiving 142 multiple responses as a result, i.e. one per origin server. It also 143 signals for how long it is willing to wait for responses. Also, when 144 forwarding a response to the client, the proxy indicates the 145 addressing information of the origin server. This enables the client 146 to distinguish multiple, diffent responses by origin and to possibly 147 contact one or more of the respective servers by sending individual 148 unicast request(s) to the indicated address(es). In doing these 149 follow-up unicast requests, the client may optionally bypass the 150 proxy. 152 1.1. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 Readers are expected to be familiar with terms and concepts defined 161 in CoAP [RFC7252], Group Communication for CoAP 162 [I-D.ietf-core-groupcomm-bis], CBOR [RFC8949], OSCORE [RFC8613] and 163 Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 165 Unless specified otherwise, the term "proxy" refers to a CoAP-to-CoAP 166 forward-proxy, as defined in Section 5.7.2 of [RFC7252]. 168 2. The Multicast-Signaling Option 170 The Multicast-Signaling Option defined in this section has the 171 properties summarized in Figure 1, which extends Table 4 of 172 [RFC7252]. 174 Since the option is not Safe-to-Forward, the column "N" indicates a 175 dash for "not applicable". The value of the Multicast-Signaling 176 Option specifies a timeout value in seconds, encoded as an unsigned 177 integer (see Section 3.2 of [RFC7252]). 179 +------+---+---+---+---+------------+--------+--------+---------+ 180 | No. | C | U | N | R | Name | Format | Length | Default | 181 +------+---+---+---+---+------------+--------+--------+---------+ 182 | | | | | | | | | | 183 | TBD1 | | x | - | | Multicast- | uint | 0-5 | (none) | 184 | | | | | | Signaling | | | | 185 | | | | | | | | | | 186 +------+---+---+---+---+------------+--------+--------+---------+ 187 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 189 Figure 1: The Multicast-Signaling Option. 191 This document specifically defines how this option is used by a 192 client in a CoAP request, to indicate to a forward-proxy its support 193 for and interest in receiving multiple responses to a proxied CoAP 194 group request, i.e. one per origin server, and for how long it is 195 willing to wait for receiving responses via that proxy (see 196 Section 5.1.1 and Section 5.2.1). 198 The client, when sending a CoAP group request to a proxy via IP 199 unicast, to be forwarded by the proxy to a targeted group of servers, 200 includes the Multicast-Signaling Option into the request. The option 201 value indicates after what time period in seconds the client will 202 stop accepting responses matching its original unicast request, with 203 the exception of notifications if the CoAP Observe Option [RFC7641] 204 is used in the same request. Signaling the time period allows the 205 proxy to stop forwarding responses back to the client, that are 206 received from servers after the end of the time period. 208 The Multicast-Signaling Option is of class U in terms of OSCORE 209 processing (see Section 4.1 of [RFC8613]). 211 3. The Response-Forwarding Option 213 The Response-Forwarding Option defined in this section has the 214 properties summarized in Figure 2, which extends Table 4 of 215 [RFC7252]. The option is intended only for inclusion in CoAP 216 responses, and builds on the Base-Uri option from Section 3 of 217 [I-D.bormann-coap-misc]. 219 Since the option is intended only for responses, the column "N" 220 indicates a dash for "not applicable". 222 +------+---+---+---+---+------------+--------+--------+---------+ 223 | No. | C | U | N | R | Name | Format | Length | Default | 224 +------+---+---+---+---+------------+--------+--------+---------+ 225 | | | | | | | | | | 226 | TBD2 | | | - | | Response- | (*) | 9-24 | (none) | 227 | | | | | | Forwarding | | | | 228 | | | | | | | | | | 229 +------+---+---+---+---+------------+--------+--------+---------+ 230 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 232 (*) See below. 234 Figure 2: The Response-Forwarding Option. 236 This document specifically defines how this option is used by a proxy 237 that can perform proxied CoAP group communication requests. 239 Upon receiving a response to such request from a server, the proxy 240 includes the Response-Forwarding Option into the response sent to the 241 origin client (see Section 5). The proxy uses the option to indicate 242 the addressing information where the client can send an individual 243 request intended to that origin server. 245 In particular, the client can use the addressing information 246 specified in the option to identify the response originator and 247 possibly send it individual requests later on, either directly, or 248 indirectly via the proxy, as CoAP unicast requests. 250 The option value is set to the byte serialization of the CBOR array 251 'tp_info' defined in Section 2.2.1 of 252 [I-D.tiloca-core-observe-multicast-notifications], including only the 253 set of elements 'srv_addr'. In turn, the set includes the integer 254 'tp_id' identifying the used transport protocol, and further elements 255 whose number, format and encoding depend on the value of 'tp_id'. 257 The value of 'tp_id' MUST be taken from the "Value" column of the 258 "CoAP Transport Information" Registry defined in Section 14.4 of 259 [I-D.tiloca-core-observe-multicast-notifications]. The elements of 260 'srv_addr' following 'tp_id' are specified in the corresponding entry 261 of the Registry, under the "Server Addr" column. 263 If the server is reachable through CoAP transported over UDP, the 264 'tp_info' array includes the following elements, encoded as defined 265 in Section 2.2.1.1 of 266 [I-D.tiloca-core-observe-multicast-notifications]. 268 o 'tp_id': the CBOR integer with value 1. This element MUST be 269 present. 271 o 'srv_host': a CBOR byte string, encoding the unicast IP address of 272 the server. This element is tagged and identified by the CBOR tag 273 260 "Network Address (IPv4 or IPv6 or MAC Address)". This element 274 MUST be present. 276 o 'srv_port': a CBOR unsigned integer or the CBOR simple value Null. 277 This element MAY be present. 279 If present as a CBOR unsigned integer, it has as value the 280 destination UDP port number to use for individual requests to the 281 server. 283 If present as the CBOR simple value Null, the client MUST assume 284 that the default port number 5683 defined in [RFC7252] can be used 285 as the destination UDP port number for individual requests to the 286 server. 288 If not present, the client MUST assume that the same port number 289 specified in the group URI of the original unicast CoAP group 290 request sent to the proxy (see Section 5.1.1) can be used for 291 individual requests to the server. 293 The CDDL notation [RFC8610] provided below describes the 'tp_info' 294 CBOR array using the format defined above. 296 tp_info = [ 297 tp_id : 1, ; UDP as transport protocol 298 srv_host : #6.260(bstr), ; IP address where to reach the server 299 ? srv_port : uint / null ; Port number where to reach the server 300 ] 302 At present, 'tp_id' is expected to take only value 1 (UDP) when using 303 forward proxies, UDP being the only currently available transport for 304 CoAP to work over IP multicast. While additional multicast-friendly 305 transports may be defined in the future, other current tranport 306 protocols can still be useful in applications relying on a reverse- 307 proxy (see Section 6). 309 The rest of this section considers the new values of 'tp_id' 310 registered by this document (see Section 9.2), and specifies: 312 o The encoding for the elements of 'tp_info' following 'tp_id' (see 313 Section 3.1). 315 o The port number assumed by the client if 'srv_port' in 'tp_info' 316 specifies the CBOR simple value Null (see Section 3.2). 318 The Response-Forwarding Option is of class U in terms of OSCORE 319 processing (see Section 4.1 of [RFC8613]). 321 3.1. Encoding of Server Address 323 This specification defines some values used as transport protocol 324 identifiers, whose respective new entries are included in the "CoAP 325 Transport Information" Registry defined in Section 14.4 of 326 [I-D.tiloca-core-observe-multicast-notifications]. 328 For each of these values, the following table summarizes the elements 329 specified under the "Srv Addr" and "Req Info" columns of the 330 registry, together with their CBOR encoding and short description. 332 While not listed here for brevity, the element 'tp_id' is always 333 present as a CBOR integer in the element set "Srv Addr". 335 +----------+-------------+----------+--------------+---------------+ 336 | 'tp_id' | Element Set | Element | CBOR Type | Description | 337 | Values | | | | | 338 +----------+-------------+----------+--------------+---------------+ 339 | 2, 3, 4, | Srv Addr | srv_host | #6.260(bstr) | Address of | 340 | 5, 6 | | | (*) | the server | 341 | | +----------+--------------+---------------+ 342 | | | srv_port | uint / null | Port number | 343 | | | | | of the server | 344 | +-------------+----------+--------------+---------------+ 345 | | Req Info | cli_host | #6.260(bstr) | Address of | 346 | | | | (*) | the client | 347 | | +----------+--------------+---------------+ 348 | | | cli_port | uint | Port number | 349 | | | | | of the client | 350 +----------+-------------+----------+--------------+---------------+ 352 * The CBOR byte string is tagged and identified by the 353 CBOR tag 260 "Network Address (IPv4 or IPv6 or MAC Address)". 355 3.2. Default Values of the Server Port Number 357 If the 'srv_port' element in the 'tp_info' array specifies the CBOR 358 simple value Null, the client MUST assume the following value as port 359 number where to send individual requests intended to the server, 360 based on the value of 'tp_id'. 362 o If 'tp_id' is equal to 2, i.e. CoAP over UDP secured with DTLS, 363 the default port number 5684 as defined in [RFC7252]. 365 o If 'tp_id' is equal to 3, i.e. CoAP over TCP, the default port 366 number 5683 as defined in [RFC8323]. 368 o If 'tp_id' is equal to 4, i.e. CoAP over TCP secured with TLS, the 369 default port number 5684 as defined in [RFC8323]. 371 o If 'tp_id' is equal to 5, i.e. CoAP over WebSockets, the default 372 port number 80 as defined in [RFC8323]. 374 o If 'tp_id' is equal to 6, i.e. CoAP over WebSockets secured with 375 TLS, the default port number 443 as defined in [RFC8323]. 377 4. Requirements and Objectives 379 This specification assumes that the following requirements are 380 fulfilled. 382 o REQ1. The CoAP proxy is explicitly configured (allow-list) to 383 allow proxied CoAP group requests from specific client(s). 385 o REQ2. The CoAP proxy MUST identify a client sending a CoAP group 386 request, in order to verify whether the client is allowed-listed 387 to do so. For example, this can rely on one of the following. 389 * A TLS [RFC8446] or DTLS [RFC6347][I-D.ietf-tls-dtls13] channel 390 between the client and the proxy, where the client has been 391 authenticated during the secure channel establishment. 393 * A pairwise OSCORE Security Context between the client and the 394 proxy, as described in Appendix A. 396 o REQ3. If secure, end-to-end communication is required between the 397 client and the servers in the CoAP group, exchanged messages MUST 398 be protected by using Group OSCORE 399 [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5.2 of 400 [I-D.ietf-core-groupcomm-bis]. This requires the client and the 401 servers to have previously joined the correct OSCORE group, for 402 instance by using the approach described in 403 [I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to 404 join can be pre-configured or alternatively discovered, for 405 instance by using the approach described in 406 [I-D.tiloca-core-oscore-discovery]. 408 This specification defines how to achieve the following objectives. 410 o OBJ1. The CoAP proxy gets an indication from the client that it 411 is in fact interested in and capable to receive multiple responses 412 to its unicast request containing a CoAP group URI. 414 o OBJ2. The CoAP proxy learns how long it should wait for responses 415 to a proxied request, before starting to ignore following 416 responses (except for notifications, if a CoAP Observe Option is 417 used [RFC7641]). 419 o OBJ3. The CoAP proxy returns individual unicast responses to the 420 client, each of which matches the original unicast request made to 421 the proxy. 423 o OBJ4. The CoAP client is able to distinguish the different 424 responses to the original unicast request, as well as their 425 corresponding origin servers. 427 o OBJ5. The CoAP client is enabled to optionally contact one or 428 more of the responding origin servers in the future, either 429 directly or via the CoAP proxy. 431 5. Protocol Description 433 This section specifies the steps of the signaling protocol. 435 5.1. Request Sending at the Client 437 This section defines the operations that the client performs for 438 sending a request addressed to a group of servers via the CoAP proxy. 440 5.1.1. Request Sending 442 The client proceeds according to the following steps. 444 1. The client prepares a request addressed to the CoAP proxy. The 445 request specifies the group URI as a string in the Proxi-URI 446 option, or by using the Proxy-Scheme option with the group URI 447 constructed from the URI-* options (see Section 2.3.3 of 448 [I-D.ietf-core-groupcomm-bis]). 450 2. The client MUST retain the Token value used for this original 451 unicast request beyond the reception of a first response matching 452 it. To this end, the client follows the same rules for Token 453 retention defined for multicast requests in Section 2.3.1 of 454 [I-D.ietf-core-groupcomm-bis]. 456 In particular, the client picks an amount of time T it is fine to 457 wait for before freeing up the Token value. Specifically, the 458 value of T MUST be such that: 460 * T < T_r , where T_r is the amount of time that the client is 461 fine to wait for before potentially reusing the Token value. 462 Note that T_r MUST NOT be less than MIN_TOKEN_REUSE_TIME 463 defined in Section 2.3.1 of [I-D.ietf-core-groupcomm-bis]. 465 * T should be at least the expected worst-case time taken by the 466 request and response processing on the forward-proxy and on 467 the servers in the addressed CoAP group. 469 * T should be at least the expected worst-case round-trip delay 470 between the client and the forward-proxy plus the worst-case 471 round-trip delay between the proxy and any one of the origin 472 servers. 474 3. The client MUST include the Multicast-Signaling Option defined in 475 Section 2 into the unicast request to send to the proxy. The 476 option value specifies an amount of time T' < T. The difference 477 (T - T') should be at least the expected worst-case round-trip 478 time between the client and the forward-proxy. 480 The client can specify T' = 0 as option value, thus indicating to 481 be not interested in receiving responses from the origin servers 482 through the proxy. In such a case, the client SHOULD also 483 include a No-Response Option [RFC7967] with value 26 (suppress 484 all response codes), if it supports the option. 486 Consistently, if the unicast request to send to the proxy already 487 included a No-Response Option with value 26, the client SHOULD 488 specify T' = 0 as value of the Multicast-Signaling Option. 490 4. The client processes the request as defined in 491 [I-D.ietf-core-groupcomm-bis], and also as in 492 [I-D.ietf-core-oscore-groupcomm] when secure group communication 493 is used between the client and the servers. 495 5. If OSCORE is used to protect the leg between the client and the 496 proxy (see REQ2 in Section 4), the client (further) protects the 497 unicast request resulting at the end of step 4. In particular, 498 the client uses the pairwise OSCORE Security Context it has with 499 the proxy, as described in Appendix A.1. 501 6. The client sends the request to the proxy as a unicast CoAP 502 message. 504 The exact method that the client uses to estimate the worst-case 505 processing times and round-trip delays mentioned above is out of the 506 scope of this specification. However, such a method is expected to 507 be already used by the client when generally determining a good Token 508 lifetime and reuse interval. 510 5.1.2. Supporting Observe 512 When using CoAP Observe [RFC7641], the client follows what is 513 specified in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis], with the 514 difference that it sends a unicast request to the proxy, to be 515 forwarded to the group of servers, as defined in Section 5.1.1 of 516 this specification. 518 Furthermore, the client especially follows what is specified in 519 Section 5 of [RFC7641], i.e. it registers its interest to be an 520 observer with the proxy, as if it was communicating with the servers. 522 5.2. Request Processing at the Proxy 524 This section defines the operations that the proxy performs when 525 receiving a request addressed to a group of servers. 527 5.2.1. Request Processing 529 Upon receiving the request from the client, the proxy proceeds 530 according to the following steps. 532 1. If OSCORE is used to protect the leg between the client and the 533 proxy (see REQ2 in Section 4), the proxy decrypts the request 534 using the pairwise OSCORE Security Context it has with the 535 client, as described in Appendix A.2. 537 2. The proxy identifies the client, and verifies that the client is 538 in fact allowed-listed to have its requests proxyied to CoAP 539 group URIs. 541 3. The proxy verifies the presence of the Multicast-Signaling 542 Option, as a confirmation that the client is fine to receive 543 multiple responses matching the same original request. 545 If the Multicast-Signaling Option is not present, the proxy MUST 546 stop processing the request and MUST reply to the client with a 547 4.00 (Bad Request) response. The response MUST include a 548 Multicast-Signaling Option with an empty (zero-length) value, 549 specifying that the Multicast-Signaling Option was missing and 550 has to be included in the request. As per Section 5.9.2 of 551 [RFC7252] The response SHOULD include a diagnostic payload. 553 4. The proxy retrieves the value T' from the Multicast-Signaling 554 Option, and then removes the option from the client's request. 556 5. The proxy forwards the client's request to the group of servers. 557 In particular, the proxy sends it as a CoAP group request over IP 558 multicast, addressed to the group URI specified by the client. 560 6. The proxy sets a timeout with the value T' retrieved from the 561 Multicast-Signaling Option of the original unicast request. 563 In case T' > 0, the proxy will ignore responses to the forwarded 564 group request coming from servers, if received after the timeout 565 expiration, with the exception of Observe notifications (see 566 Section 5.4). 568 In case T' = 0, the proxy will ignore all responses to the 569 forwarded group request coming from servers. 571 5.2.2. Supporting Observe 573 When using CoAP Observe [RFC7641], the proxy takes the role of the 574 client and registers its own interest to observe the target resource 575 with the servers as per Section 5 of [RFC7641]. 577 When doing so, the proxy especially follows what is specified for the 578 client in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis], by 579 forwarding the group request to the servers over IP multicast, as 580 defined in Section 5.2.1 of this specification. 582 5.3. Request and Response Processing at the Server 584 This section defines the operations that the server performs when 585 receiving a group request from the proxy. 587 5.3.1. Request and Response Processing 589 Upon receiving the request from the proxy, the server proceeds 590 according to the following steps. 592 1. The server processes the group request as defined in 593 [I-D.ietf-core-groupcomm-bis], and also as in 594 [I-D.ietf-core-oscore-groupcomm] when secure group communication 595 is used between the client and the server. 597 2. The server processes the response to be forwarded back to the 598 client as defined in [I-D.ietf-core-groupcomm-bis], and also as 599 in [I-D.ietf-core-oscore-groupcomm] when secure group 600 communication is used between the client and the server. 602 5.3.2. Supporting Observe 604 When using CoAP Observe [RFC7641], the server especially follows what 605 is specified in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis] and 606 Section 5 of [RFC7641]. 608 5.4. Response Processing at the Proxy 610 This section defines the operations that the proxy performs when 611 receiving a response matching a forwarded group request. 613 5.4.1. Response Processing 615 Upon receiving a response matching the group request before the 616 amount of time T' has elapsed, the proxy proceeds according to the 617 following steps. 619 1. The proxy MUST include the Response-Forwarding Option defined in 620 Section 3 into the response. The proxy specifies as option value 621 the addressing information of the server generating the response, 622 encoded as defined in Section 3. In particular: 624 * The 'srv_addr' element of the 'srv_info' array MUST specify 625 the server IPv6 address if the multicast request was destined 626 for an IPv6 multicast address, and MUST specify the server 627 IPv4 address if the multicast request was destined for an IPv4 628 address. 630 * If present, the 'srv_port' element of the 'srv_info' array 631 MUST specify the port number of the server as the source port 632 number of the response. This element MUST be present if the 633 source port number of the response differs from the port 634 number specified in the group URI of the original unicast CoAP 635 group request (see Section 5.1.1). Otherwise, the 'srv_port' 636 element MAY be omitted. 638 2. If OSCORE is used to protect the leg between the client and the 639 proxy (see REQ2 in Section 4), the proxy (further) protects the 640 response using the pairwise OSCORE Security Context it has with 641 the client, as described in Appendix A.3. 643 3. The proxy forwards the response back to the client. 645 Upon timeout expiration, i.e. T' seconds after having sent the group 646 request over IP multicast, the proxy frees up its local Token value 647 associated to that request. Thus, following late responses to the 648 same group request will be discarded and not forwarded back to the 649 client. 651 5.4.2. Supporting Observe 653 When using CoAP Observe [RFC7641], the proxy acts as a client 654 registered with the servers, as described earlier in Section 5.2.2. 656 Furthermore, the proxy takes the role of a server when forwarding 657 notifications from origin servers back to the client. To this end, 658 the proxy follows what is specified in Section 2.3.5 of 659 [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the 660 following additions. 662 o At step 1 in Section 5.4, the proxy includes the Response- 663 Forwarding Option in every notification, including non-2.xx 664 notifications resulting in removing the proxy from the list of 665 observers of the origin server. 667 o The proxy frees up its Token value used for a group observation 668 only if, after the timeout expiration, no 2.xx (Success) responses 669 matching the group request and also including an Observe option 670 have been received from any origin server. After that, as long as 671 observations are active with servers in the group for the target 672 resource of the group request, notifications from those servers 673 are forwarded back to the client, as defined in Section 5.4, and 674 the Token value used for the group observation is not freed during 675 this time. 677 Finally, the proxy SHOULD regularly verify that the client is still 678 interested in receiving observe notifications for a group 679 observation. To this end, the proxy can rely on the same approach 680 discussed for servers in Section 2.3.5 of 681 [I-D.ietf-core-groupcomm-bis], with more details available in 682 Section 4.5 of [RFC7641]. 684 5.5. Response Processing at the Client 686 This section defines the operations that the client performs when 687 receiving a response matching a request addressed to a group of 688 servers via the CoAP proxy. 690 5.5.1. Response Processing 692 Upon receiving from the proxy a response matching the original 693 unicast request before the amount of time T has elapsed, the client 694 proceeds according to the following steps. 696 1. The client processes the response as defined in 697 [I-D.ietf-core-groupcomm-bis]. 699 2. If OSCORE is used to protect the leg between the client and the 700 proxy (see REQ2 in Section 4), the client decrypts the response 701 using the pairwise OSCORE Security Context it has with the proxy, 702 as described in Appendix A.4. 704 3. If secure group communication is used end-to-end between the 705 client and the servers, the client processes the response, 706 possibly as outcome of step 2, as defined in 707 [I-D.ietf-core-oscore-groupcomm]. 709 4. The client identifies the origin server, whose addressing 710 information is specified as value of the Response-Forwarding 711 Option. If the port number is omitted in the value of the 712 Response-Forwarding Option, the client MUST assume that the port 713 number where to send unicast requests to the server - in case 714 this is needed - is the same port number specified in the group 715 URI of the original unicast CoAP group request sent to the proxy 716 (see Section 5.1.1). 718 In particular, the client is able to distinguish different 719 responses as originated by different servers. Optionally, the 720 client may contact one or more of those servers individually, 721 i.e. directly (bypassing the proxy) or indirectly (via a proxied 722 CoAP unicast request). 724 In order to individually reach an origin server again through the 725 proxy, the client is not required to understand or support the 726 transport protocol indicated in the Response-Forwarding Option, 727 as used between the proxy and the origin server, in case it 728 differs from "UDP" (1). That is, using the IPv4/IPv6 address 729 value and optional port value from the Response-Forwarding 730 Option, the client simply creates the correct URI for the 731 individual request, by means of the Proxy-Uri or Uri-Scheme 732 Option in the unicast request to the proxy. The client uses the 733 transport protocol it knows, and has used before, to send the 734 request to the proxy. 736 Upon the timeout expiration, i.e. T seconds after having sent the 737 original unicast request to the proxy, the client frees up its local 738 Token value associated to that request. Note that, upon this timeout 739 expiration, the Token value is not eligible for possible reuse yet 740 (see Section 5.1.1). Thus, until the actual amount of time before 741 enabling Token reusage has elapsed, any following late responses to 742 the same request forwarded by the proxy will be discarded, as these 743 are not matching (by Token) any active request from the client. 745 5.5.2. Supporting Observe 747 When using CoAP Observe [RFC7641], the client frees up its Token 748 value only if, after the timeout T expiration, no 2.xx (Success) 749 responses matching the original unicast request and also including an 750 Observe option have been received. 752 Instead, if at least one such response has been received, the client 753 continues receiving those notifications as forwarded by the proxy, as 754 long as the observation for the target resource of the original 755 unicast request is active. 757 5.6. Example 759 The example in this section refers to the following actors. 761 o One origin client C, with address C_ADDR and port number C_PORT. 763 o One proxy P, with address P_ADDR and port number P_PORT. 765 o Two origin servers S1 and S2, where the server Sx has address 766 Sx_ADDR and port number Sx_PORT. 768 The origin servers are members of a CoAP group with IP multicast 769 address G_ADDR and port number G_PORT. Also, the origin servers are 770 members of a same application group, and share the same resource /r. 772 The communication between C and P is based on CoAP over UDP, as per 773 [RFC7252]. The communication between P and the origin servers is 774 based on CoAP over UDP and IP multicast, as per 775 [I-D.ietf-core-groupcomm-bis]. 777 Finally, 'bstr(X)' denotes a CBOR byte string with value the byte 778 serialization of X. 780 C P S1 S2 781 | | | | 782 |------------------------->| | | 783 | Src: C_ADDR:C_PORT | | | 784 | Dst: P_ADDR:P_PORT | | | 785 | Proxi-URI { | | | 786 | coap://G_ADDR:G_PORT/r | | | 787 | } | | | 788 | Multicast-Signaling: 60 | | | 789 | | | | 790 | | Src: P_ADDR:P_PORT | | 791 | | Dst: G_ADDR:G_PORT | | 792 | | Uri-Path: /r | | 793 | |---------------+----->| | 794 | | \ | | 795 | | +----------------->| 796 | | | | 797 | | /* t = 0 : P starts | | 798 | | accepting responses | | 799 | | for this request */ | | 800 | | | | 801 | | | | 802 | |<---------------------| | 803 | | Src: S1_ADDR:G_PORT | | 804 | | Dst: P_ADDR:P_PORT | | 805 | | | | 806 | | | | 807 |<-------------------------| | | 808 | Src: P_ADDR:P_PORT | | | 809 | Dst: C_ADDR:C_PORT | | | 810 | Response-Forwarding { | | | 811 | [1, /*CoAP over UDP*/ | | | 812 | #6.260(bstr(S1_ADDR)) | | | 813 | ] | | | 814 | } | | | 815 | |<-----------------------------------| 816 | | Src: S2_ADDR:S2_PORT | 817 | | Dst: P_ADDR:P_PORT | 818 |<-------------------------| | | 819 | Src: P_ADDR:P_PORT | | | 820 | Dst: C_ADDR:C_PORT | | | 821 | Response-Forwarding { | | | 822 | [1, /*CoAP over UDP*/ | | | 823 | #6.260(bstr(S2_ADDR)), | | | 824 | S2_PORT | | | 825 | ] | | | 826 | } | | | 827 | /* At t = 60, P stops accepting | | 828 | responses for this request */ | | 829 | | | | 831 Figure 3: Workflow example with a forward-proxy 833 6. Reverse-Proxies 835 The use of reverse-proxies in group communication scenarios is 836 defined in Section 3.4.2 of [I-D.ietf-core-groupcomm-bis]. 838 This section clarifies how the Multicast-Signaling Option is 839 effective also in such a context, in order for: 841 o The proxy to explictly reveal itself as a reverse-proxy to the 842 client. 844 o The client to indicate to the proxy of being aware that it is 845 communicating with a reverse-proxy, and for how long it is willing 846 to receive responses to a proxied request. 848 This practically addresses the addional issues compared to the case 849 with a forward-proxy, as compiled in Section 3.4.2 of 850 [I-D.ietf-core-groupcomm-bis]. A reverse-proxy may also operate 851 without support of the Multicast-Signaling Option, as defined in that 852 section. 854 Appendix B provides examples with a reverse-proxy. 856 6.1. Processing on the Client Side 858 If a client sends a request intended to a group of servers and is 859 aware of actually communicating with a reverse-proxy, then the client 860 MUST perform the steps defined in Section 5.1.1. In particular, this 861 results in a request sent to the proxy including a Multicast- 862 Signaling Option. 864 The client processes the responses forwarded back by the proxy as 865 defined in Section 5.5. 867 6.2. Processing on the Proxy Side 869 If the proxy receives a request and determines that it should forward 870 it to a group of servers over IP multicast, then the proxy MUST 871 perform the steps defined in Section 5.2. 873 In particular, when such request does not include a Multicast- 874 Signaling Option, the proxy explicitly reveals itself as a reverse- 875 proxy, by sending a 4.00 (Bad Request) response including an 876 Multicast-Signaling Option with empty (zero-length) value. 878 7. Chain of Proxies 880 A client may be interested to access a resource at a group of origin 881 servers which is reached through a chain of two or more proxies. 883 That is, these proxies are configured into a chain, where each non- 884 last proxy is configured to forward CoAP (group) requests to the next 885 hop towards the origin servers. Also, each non-first proxy is 886 configured to forward back CoAP responses to (the previous hop proxy 887 towards) the origin client. 889 This section specifies how the signaling protocol defined in 890 Section 5 is used in that setting. Except for the last proxy before 891 the origin servers, every other proxy in the chain takes the role of 892 client with respect to the next hop towards the origin servers. 893 Also, every proxy in the chain except the first takes the role of 894 server towards the previous proxy closer to the origin client. 896 The requirements REQ1 and REQ2 defined in Section 4 MUST be fulfilled 897 for each proxy in the chain. That is, every proxy in the chain has 898 to be explicitly configured (allow-list) to allow proxied group 899 requests from specific senders, and MUST identify those senders upon 900 receiving their group request. For the first proxy in the chain, 901 that sender is the origin client. For each other proxy in the chain, 902 that sender is the previous hop proxy closer to the origin client. 903 In either case, a proxy can identify the sender of a group request by 904 the same means mentioned in Section 4. 906 7.1. Request Processing at the Proxy 908 Upon receiving a group request to be forwarded to a CoAP group URIs, 909 a proxy proceed as follows. 911 If the proxy is the last one in the chain, i.e. it is the last hop 912 before the origin servers, the proxy performs the steps defined in 913 Section 5.2, with no modifications. 915 Otherwise, the proxy performs the steps defined in Section 5.2, with 916 the following differences. 918 o At steps 1-3, "client" refers to the origin client for the first 919 proxy in the chain; or to the previous hop proxy closer to the 920 origin client, otherwise. 922 o At step 4, the proxy rather performs the following actions. 924 1. The proxy retrieves the value T' from the Multicast-Signaling 925 Option, and does not remove the option. 927 2. In case T' > 0, the proxy picks an amount of time T it is fine 928 to wait for before freeing up its local Token value to use 929 with the next hop towards the origin servers. To this end, 930 the proxy MUST follow what is defined at step 2 of 931 Section 5.1.1 for the origin client, with the following 932 differences. 934 + T MUST be greater than the retrieved value T', i.e. T' < T. 936 + The worst-case message processing time takes into account 937 all the next hops towards the origin servers, as well as 938 the origin servers themselves. 940 + The worst-case round-trip delay takes into account all the 941 legs between the proxy and the origin servers. 943 3. In case T' > 0, the proxy replaces the value of the Multicast- 944 Signaling Option with a new value T'', such that: 946 + T'' < T. The difference (T - T'') should be at least the 947 expected worst-case round-trip time between the proxy and 948 the next hop towards the origin servers. 950 + T'' < T'. The difference (T' - T'') should be at least the 951 expected worst-case round-trip time between the proxy and 952 the (previous hop proxy closer to the) origin client. 954 If the proxy is not able to determine a value T'' that 955 fulfills both the requirements above, the proxy MUST stop 956 processing the request and MUST respond with a 5.05 (Proxying 957 Not Supported) error response to the previous hop proxy closer 958 to the origin client. The proxy SHOULD include a Multicast- 959 Signaling Option, set to the minimum value T' that would be 960 acceptable in the Multicast-Signaling Option of a request to 961 forward. 963 Upon receiving such an error response, any proxy in the chain 964 MAY send an updated request to the next hop towards the origin 965 servers, specifying in the Multicast-Signaling Option a value 966 T' greater than in the previous request. If this does not 967 happen, the proxy receiving the error response MUST also send 968 a 5.05 (Proxying Not Supported) error response to the previous 969 hop proxy closer to the origin client. Like the received one, 970 also this error response SHOULD include a Multicast-Signaling 971 Option, set to the minimum value T' acceptable by the proxy 972 sending the error response. 974 o At step 5, the proxy forwards the request to the next hop towards 975 the origin servers. 977 o At step 6, the proxy sets a timeout with the value T' retrieved 978 from the Multicast-Signaling Option of the request received from 979 the (previous hop proxy closer to the) origin client. 981 In case T' > 0, the proxy will ignore responses to the forwarded 982 group request coming from the (next hop towards the) origin 983 servers, if received after the timeout expiration, with the 984 exception of Observe notifications (see Section 5.4). 986 In case T' = 0, the proxy will ignore all responses to the 987 forwarded group request coming from the (next hop towards the) 988 origin servers. 990 7.1.1. Supporting Observe 992 When using CoAP Observe [RFC7641], what is defined in Section 5.2.2 993 applies for the last proxy in the chain, i.e. the last hop before the 994 origin servers. 996 Any other proxy in the chain acts as a client and registers its own 997 interest to observe the target resource with the next hop towards the 998 origin servers, as per Section 5 of [RFC7641]. 1000 7.2. Response Processing at the Proxy 1002 Upon receiving a response matching the group request before the 1003 amount of time T' has elapsed, the proxy proceeds as follows. 1005 If the proxy is the last one in the chain, i.e. it is the last hop 1006 before the origin servers, the proxy performs the steps defined in 1007 Section 5.4, with no modifications. 1009 Otherwise, the proxy performs the steps defined in Section 5.4, with 1010 the following differences. 1012 o The proxy skips step 1. In particular, the proxy MUST NOT remove, 1013 alter or replace the Response-Forwarding Option. 1015 o At steps 2-3, "client" refers to the origin client for the first 1016 proxy in the chain; or to the previous hop proxy closer to the 1017 origin client, otherwise. 1019 Upon timeout expiration, i.e. T seconds after having sent the group 1020 request to the next hop towards the origin servers, the proxy frees 1021 up its local Token value associated to that request. Thus, following 1022 late responses to the same group request will be discarded and not 1023 forwarded back to the (previous hop proxy closer to the) origin 1024 client. 1026 7.2.1. Supporting Observe 1028 When using CoAP Observe [RFC7641], what is defined in Section 5.4.2 1029 applies for the last proxy in the chain, i.e. the last hop before the 1030 origin servers. 1032 As to any other proxy in the chain, the following applies. 1034 o The proxy acts as a client registered with the next hop towards 1035 the origin servers, as described earlier in Section 7.1.1. 1037 o The proxy takes the role of a server when forwarding notifications 1038 from the next hop to the origin servers back to the (previous hop 1039 proxy closer to the) origin client, as per Section 5 of [RFC7641]. 1041 o The proxy frees up its Token value used for a group observation 1042 only if, after the timeout expiration, no 2.xx (Success) responses 1043 matching the group request and also including an Observe option 1044 have been received from the next hop towards the origin servers. 1045 After that, as long as the observation for the target resource of 1046 the group request is active with the next hop towards the origin 1047 servers in the group, notifications from that hop are forwarded 1048 back to the (previous hop proxy closer to the) origin client, as 1049 defined in Section 7.2. 1051 o The proxy SHOULD regularly verify that the (previous hop proxy 1052 closer to the) origin client is still interested in receiving 1053 observe notifications for a group observation. To this end, the 1054 proxy can rely on the same approach defined in Section 4.5 of 1055 [RFC7641]. 1057 8. Security Considerations 1059 The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi 1060 s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. 1062 When a chain of proxies is used (see Section 7), the secure 1063 communication between any two adjacent hops is independent. 1065 When Group OSCORE is used for end-to-end secure group communication 1066 between the origin client and the origin servers, this security 1067 association is unaffected by the possible presence of a proxy or a 1068 chain of proxies. 1070 Furthermore, the following additional considerations hold. 1072 8.1. Client Authentication 1074 As per the requirement REQ2 (see Section 4), the client has to 1075 authenticate to the proxy when sending a group request to forward. 1076 This leverages an established security association between the client 1077 and the proxy, that the client uses to protect the group request, 1078 before sending it to the proxy. 1080 Note that, if the group request is (also) protected with Group 1081 OSCORE, i.e. end-to-end between the client and the servers, the proxy 1082 can authenticate the client by successfully verifying the counter 1083 signature embedded in the group request. This requires that, for 1084 each client to authenticate, the proxy stores the public key used by 1085 that client in the OSCORE group, which in turn would require a form 1086 of active synchronization between the proxy and the Group Manager for 1087 that group [I-D.ietf-core-oscore-groupcomm]. 1089 Nevertheless, the client and the proxy SHOULD still rely on a full- 1090 fledged, pairwise secure association. In addition to ensuring the 1091 integrity of group requests sent to the proxy (see Section 8.2 and 1092 Section 8.3), this prevents the proxy from forwarding replayed group 1093 requests with a valid counter signature, as possibly injected by an 1094 active, on-path adversary. 1096 The same considerations apply when a chain of proxies is used (see 1097 Section 7), with each proxy but the last one in the chain acting as 1098 client with the next hop towards the origin servers. 1100 8.2. Multicast-Signaling Option 1102 The Multicast-Signaling Option is of class U for OSCORE [RFC8613]. 1103 Hence, also when Group OSCORE is used between the client and the 1104 servers [I-D.ietf-core-oscore-groupcomm], a proxy is able to access 1105 the option value and retrieve the timeout value T', as well as to 1106 remove the option altogether before forwarding the group request to 1107 the servers. When a chain of proxies is used (see Section 7), this 1108 also allows each proxy but the last one in the chain to update the 1109 option value, as an indication for the next hop towards the origin 1110 servers (see Section 7.1). 1112 The security association between the client and the proxy MUST 1113 provide message integrity, so that further intermediaries between the 1114 two as well as on-path active adversaries are not able to remove the 1115 option or alter its content, before the group request reaches the 1116 proxy. Removing the option would otherwise result in not forwarding 1117 the group request to the servers. Instead, altering the option 1118 content would result in the proxy accepting and forwarding back 1119 responses for an amount of time different than the one actually 1120 indicated by the client. 1122 The security association between the client and the proxy SHOULD also 1123 provide message confidentiality. Otherwise, further intermediaries 1124 between the two as well as on-path passive adversaries would be able 1125 to simply access the option content, and thus learn for how long the 1126 client is willing to receive responses from the servers in the group 1127 via the proxy. This may in turn be used to perform a more efficient, 1128 selective suppression of responses from the servers. 1130 When the client (further) protects the unicast request sent to the 1131 proxy using OSCORE (see Appendix A) and/or with (D)TLS, both message 1132 integrity and message confidentiality are achieved in the leg between 1133 the client and the proxy. 1135 The same considerations above about security associations apply when 1136 a chain of proxies is used (see Section 7), with each proxy but the 1137 last one in the chain acting as client with the next hop towards the 1138 origin servers. 1140 8.3. Response-Forwarding Option 1142 The Response-Forwarding Option is of class U for OSCORE [RFC8613]. 1143 Hence, also when Group OSCORE is used between the client and the 1144 servers [I-D.ietf-core-oscore-groupcomm], the proxy that has 1145 forwarded the group request to the servers is able to include the 1146 option into a server response, before forwarding this response back 1147 to the (previous hop proxy closer to the) origin client. 1149 Since the security association between the client and the proxy 1150 provides message integrity, any further intermediaries between the 1151 two or on-path active adversaries are not able to undetectably remove 1152 the Response-Forwarding Option from a forwarded server response. 1153 This ensures that the client can correctly distinguish the different 1154 responses and identify their corresponding origin server. 1156 When the proxy (further) protects the response forwarded back to the 1157 client using OSCORE (see Appendix A) and/or with (D)TLS, message 1158 integrity is achieved in the leg between the client and the proxy. 1160 The same considerations above about security associations apply when 1161 a chain of proxies is used (see Section 7), with each proxy but the 1162 last one in the chain acting as client with the next hop towards the 1163 origin servers. 1165 9. IANA Considerations 1167 This document has the following actions for IANA. 1169 9.1. CoAP Option Numbers Registry 1171 IANA is asked to enter the following option numbers to the "CoAP 1172 Option Numbers" registry defined in [RFC7252] within the "CoRE 1173 Parameters" registry. 1175 +--------+---------------------+-------------------+ 1176 | Number | Name | Reference | 1177 +--------+---------------------+-------------------+ 1178 | TBD1 | Multicast-Signaling | [[this document]] | 1179 +--------+---------------------+-------------------+ 1180 | TBD2 | Response-Forwarding | [[this document]] | 1181 +--------+---------------------+-------------------+ 1183 9.2. CoAP Transport Information Registry 1185 IANA is asked to enter the following entries to the "CoAP Transport 1186 Information" Registry defined in Section 14.4 of 1187 [I-D.tiloca-core-observe-multicast-notifications]. 1189 +------------+-------------+-------+----------+-----------+-----------+ 1190 | Transport | Description | Value | Srv Addr | Req Info | Reference | 1191 | Protocol | | | | | | 1192 +------------+-------------+-------+----------+-----------+-----------+ 1193 | UDP | UDP with | 2 | tp_id | token | [This | 1194 | secured | DTLS is | | srv_host | cli_host | document] | 1195 | with DTLS | used as per | | srv_port | ?cli_port | | 1196 | | RFC8323 | | | | | 1197 +------------+-------------+-------+----------+-----------+-----------+ 1198 | TCP | TCP is used | 3 | tp_id | token | [This | 1199 | | as per | | srv_host | cli_host | document] | 1200 | | RFC8323 | | srv_port | ?cli_port | | 1201 +------------+-------------+-------+----------+-----------+-----------+ 1202 | TCP | TCP with | 4 | tp_id | token | [This | 1203 | secured | TLS is | | srv_host | cli_host | document] | 1204 | with TLS | used as per | | srv_port | ?cli_port | | 1205 | | RFC8323 | | | | | 1206 +------------+-------------+-------+----------+-----------+-----------+ 1207 | WebSockets | WebSockets | 5 | tp_id | token | [This | 1208 | | are used as | | srv_host | cli_host | document] | 1209 | | per RFC8323 | | srv_port | ?cli_port | | 1210 +------------+-------------+-------+----------+-----------+-----------+ 1211 | WebSockets | WebSockets | 6 | tp_id | token | [This | 1212 | secured | with TLS | | srv_host | cli_host | document] | 1213 | with TLS | are used as | | srv_port | ?cli_port | | 1214 | | per RFC8323 | | | | | 1215 +------------+-------------+-------+----------+-----------+-----------+ 1217 10. References 1219 10.1. Normative References 1221 [I-D.ietf-core-groupcomm-bis] 1222 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 1223 for the Constrained Application Protocol (CoAP)", draft- 1224 ietf-core-groupcomm-bis-03 (work in progress), February 1225 2021. 1227 [I-D.ietf-core-oscore-groupcomm] 1228 Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and 1229 J. Park, "Group OSCORE - Secure Group Communication for 1230 CoAP", draft-ietf-core-oscore-groupcomm-11 (work in 1231 progress), February 2021. 1233 [I-D.tiloca-core-observe-multicast-notifications] 1234 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 1235 "Observe Notifications as CoAP Multicast Responses", 1236 draft-tiloca-core-observe-multicast-notifications-05 (work 1237 in progress), February 2021. 1239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1240 Requirement Levels", BCP 14, RFC 2119, 1241 DOI 10.17487/RFC2119, March 1997, 1242 . 1244 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1245 Application Protocol (CoAP)", RFC 7252, 1246 DOI 10.17487/RFC7252, June 2014, 1247 . 1249 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1250 Application Protocol (CoAP)", RFC 7641, 1251 DOI 10.17487/RFC7641, September 2015, 1252 . 1254 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1255 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1256 May 2017, . 1258 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1259 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1260 Application Protocol) over TCP, TLS, and WebSockets", 1261 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1262 . 1264 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 1265 Definition Language (CDDL): A Notational Convention to 1266 Express Concise Binary Object Representation (CBOR) and 1267 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 1268 June 2019, . 1270 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1271 "Object Security for Constrained RESTful Environments 1272 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1273 . 1275 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1276 Representation (CBOR)", STD 94, RFC 8949, 1277 DOI 10.17487/RFC8949, December 2020, 1278 . 1280 10.2. Informative References 1282 [I-D.bormann-coap-misc] 1283 Bormann, C. and K. Hartke, "Miscellaneous additions to 1284 CoAP", draft-bormann-coap-misc-27 (work in progress), 1285 November 2014. 1287 [I-D.ietf-ace-key-groupcomm-oscore] 1288 Tiloca, M., Park, J., and F. Palombini, "Key Management 1289 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 1290 oscore-10 (work in progress), February 2021. 1292 [I-D.ietf-tls-dtls13] 1293 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1294 Datagram Transport Layer Security (DTLS) Protocol Version 1295 1.3", draft-ietf-tls-dtls13-41 (work in progress), 1296 February 2021. 1298 [I-D.tiloca-core-oscore-discovery] 1299 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 1300 Groups with the CoRE Resource Directory", draft-tiloca- 1301 core-oscore-discovery-08 (work in progress), February 1302 2020. 1304 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1305 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1306 January 2012, . 1308 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1309 Bose, "Constrained Application Protocol (CoAP) Option for 1310 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1311 August 2016, . 1313 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1314 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1315 . 1317 Appendix A. Using OSCORE Between Client and Proxy 1319 This section describes how OSCORE is used to protect messages 1320 exchanged by an origin client and a proxy, using their pairwise 1321 OSCORE Security Context. 1323 This is especially convenient for the communication scenario 1324 addressed in this document, when the origin client already supports 1325 and uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect 1326 messages end-to-end with the origin servers. 1328 In particular, a CoAP message is protected with the OSCORE Security 1329 Context between the origin client and the proxy, as considering both 1330 of them to be terminal endpoints for the exchange in question. This 1331 requires that some CoAP options in that message are processed as 1332 class E, although originally defined as class U or class I. 1334 This generally applies to all options that the proxy needs to 1335 understand and process in its exchange with the origin client. 1336 Further options can be added and treated as class U, e.g. related to 1337 routing information. The rest of this section hightlights the most 1338 relevant CoAP options to consider in this respect. 1340 The following focuses on the origin client originating the group 1341 request and a single proxy as its immediate next hop. When a chain 1342 of proxies is used (see Section 7), the same independently applies 1343 between each pair of proxies in the chain, where the proxy forwarding 1344 the group request acts as client and the next hop towards the origin 1345 servers acts as server. 1347 A.1. Protecting the Request 1349 Before sending the CoAP request to the proxy, the origin client 1350 protects it using the pairwise OSCORE Security Context it has with 1351 the proxy. 1353 To this end, the origin client processes the CoAP request as defined 1354 in Section 8.1 of [RFC8613], with the following differences. 1356 o The Proxy-Uri option, if present, is not decomposed and recomposed 1357 as defined in Section 4.1.3.3 of [RFC8613]. 1359 o The following options, if present, are processed as Class E. 1361 * Proxy-Uri, Proxy-Scheme, Uri-Host and Uri-Port, defined in 1362 [RFC7252]. 1364 * OSCORE, defined in [RFC8613], which is present if Group OSCORE 1365 is used between the origin client and the origin servers, to 1366 achieve end-to-end secure group communication. 1368 * Multicast-Signaling Option, defined in Section 2 of this 1369 specification. 1371 As per [RFC8613], the resulting message includes an outer OSCORE 1372 Option, which reflects the usage of the pairwise OSCORE Security 1373 Context between the origin client and the proxy. 1375 A.2. Verifying the Request 1377 The proxy verifies the CoAP request as defined in Section 8.2 of 1378 [RFC8613]. Note that the Multicast-Signaling Option is retrieved 1379 during the decryption process, and added to the decrypted request. 1381 If secure group communication is also used between the origin client 1382 and the origin servers, the request resulting from the previous step 1383 and to be forwarded to the origin servers is also already protected 1384 with Group OSCORE [I-D.ietf-core-oscore-groupcomm]. Consequently, it 1385 includes an outer OSCORE Option, which reflects the usage of the 1386 group OSCORE Security Context between the origin client and the 1387 origin servers. 1389 A.3. Protecting the Response 1391 The proxy protects the CoAP response received from a server, using 1392 the pairwise OSCORE Security Context it has with the origin client. 1394 To this end, the proxy processes the CoAP response as defined in 1395 Section 8.3 of [RFC8613], with the difference that the OSCORE Option, 1396 if present, is processed as Class E. This is the case if Group 1397 OSCORE is used between the origin client and the origin servers, to 1398 achieve end-to-end secure group communication. 1400 Furthermore, the Response-Forwarding Option defined in Section 3 of 1401 this specification is also processed as Class E. 1403 As per [RFC8613], the resulting message to be forwarded back to the 1404 origin client includes an outer OSCORE Option, which reflects the 1405 usage of the pairwise OSCORE Security Context between the origin 1406 client and the proxy. 1408 A.4. Verifying the Response 1410 The origin client verifies the CoAP response received from the proxy 1411 as defined in Section 8.4 of [RFC8613]. Note that, the Response- 1412 Forwarding Option is retrieved during the decryption process, and 1413 added to the decrypted response. 1415 If secure group communication is also used between the origin client 1416 and the origin servers, the response resulting from the previous step 1417 is protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 1418 Consequently, it includes an outer OSCORE Option, which reflects the 1419 usage of the group OSCORE Security Context between the origin client 1420 and the origin servers. 1422 Appendix B. Examples with Reverse-Proxy 1424 The examples in this section refer to the following actors. 1426 o One origin client C, with address C_ADDR and port number C_PORT. 1428 o One proxy P, with address P_ADDR and port number P_PORT. 1430 o Two origin servers S1 and S2, where the server Sx has address 1431 Sx_ADDR and port number Sx_PORT. 1433 The origin servers are members of a CoAP group with IP multicast 1434 address G_ADDR and port number G_PORT. Also, the origin servers are 1435 members of a same application group, and share the same resource /r. 1437 The communication between C and P is based on CoAP over TCP, as per 1438 [RFC8323]. The communication between P and the origin servers is 1439 based on CoAP over UDP and IP multicast, as per 1440 [I-D.ietf-core-groupcomm-bis]. 1442 Finally, 'bstr(X)' denotes a CBOR byte string with value the byte 1443 serialization of X. 1445 B.1. Example 1 1447 The example shown in Figure 4 considers a reverse-proxy that stands 1448 in for both the whole group of servers and for each of those servers 1449 (e.g. acting as a firewall). 1451 In particular: 1453 o The address 'group1.com' resolves to P_ADDR. The proxy forwards 1454 an incoming request to that address, for any resource i.e. URI 1455 path, towards the CoAP group at G_ADDR:G_PORT leaving the URI path 1456 unchanged. 1458 o The address Dx_ADDR and port number Dx_PORT are used by the proxy, 1459 which forwards an incoming request to that address towards the 1460 server at Sx_ADDR:Sx_PORT. 1462 Note that this type of reverse-proxy implementation requires the 1463 proxy to use (potentially) a large number of distinct IP addresses, 1464 so it is not very scalable. 1466 C P S1 S2 1467 | | | | 1468 |----------------------------->| /* C is not aware | | 1469 | Src: C_ADDR:C_PORT | that P is in fact | | 1470 | Dst: group1.com:P_PORT | a reverse-proxy */ | | 1471 | Uri-Path: /r | | | 1472 | | | | 1473 | | | | 1474 |<-----------------------------| | | 1475 | Src: group1.com:P_PORT | | | 1476 | Dst: C_ADDR:C_PORT | | | 1477 | 4.00 Bad Request | | | 1478 | Multicast-Signaling: (empty) | | | 1479 | Payload: "Please use | | | 1480 | Multicast-Signaling" | | | 1481 | | | | 1482 |----------------------------->| | | 1483 | Src: C_ADDR:C_PORT | | | 1484 | Dst: group1.com:P_PORT | | | 1485 | Multicast-Signaling: 60 | | | 1486 | Uri-Path: /r | | | 1487 | | | | 1488 | | Src: P_ADDR:P_PORT | | 1489 | | Dst: G_ADDR:G_PORT | | 1490 | | Uri-Path: /r | | 1491 | |---------------+----->| | 1492 | | \ | | 1493 | | +----------------->| 1494 | | | | 1495 | | /* t = 0 : P starts | | 1496 | | accepting responses | | 1497 | | for this request */ | | 1498 | | | | 1499 | | | | 1500 | |<---------------------| | 1501 | | Src: S1_ADDR:S1_PORT | | 1502 | | Dst: P_ADDR:P_PORT | | 1503 | | | | 1504 |<-----------------------------| | | 1505 | Src: group1.com:P_PORT | | | 1506 | Dst: C_ADDR:C_PORT | | | 1507 | Response-Forwarding { | | | 1508 | [3, /*CoAP over TCP*/ | | | 1509 | #6.260(bstr(D1_ADDR)), | | | 1510 | D1_PORT | | | 1511 | ] | | | 1512 | } | | | 1513 | | | | 1514 | |<-----------------------------------| 1515 | | Src: S2_ADDR:S2_PORT | 1516 | | Dst: P_ADDR:P_PORT | 1517 | | | | 1518 |<-----------------------------| | | 1519 | Src: group1.com:P_PORT | | | 1520 | Dst: C_ADDR:C_PORT | | | 1521 | Response-Forwarding { | | | 1522 | [3, /*CoAP over TCP*/ | | | 1523 | #6.260(bstr(D2_ADDR)), | | | 1524 | D2_PORT | | | 1525 | ] | | | 1526 | } | | | 1527 | | | | 1528 | /* At t = 60, P stops accepting | | 1529 | responses for this request */ | | 1530 | | | | 1531 | | | | 1532 |----------------------------->| /* Request intended | | 1533 | Src: C_ADDR:C_PORT | only to S1 */ | | 1534 | Dst: D1_ADDR:D1_PORT | | | 1535 | Uri-Path: /r | | | 1536 | | | | 1537 | | Src: P_ADDR:P_PORT | | 1538 | | Dst: S1_ADDR:S1_PORT | | 1539 | | Uri-Path: /r | | 1540 | |--------------------->| | 1541 | | | | 1542 | | | | 1543 | |<---------------------| | 1544 | | Src: S1_ADDR:S1_PORT | | 1545 | | Dst: P_ADDR:P_PORT | | 1546 | | | | 1547 |<-----------------------------| | | 1548 | Src: D1_ADDR:D1_PORT | | | 1549 | Dst: C_ADDR:C_PORT | | | 1550 | | | | 1552 Figure 4: Workflow example with reverse-proxy standing in for both 1553 the whole group of servers and each individual server 1555 B.2. Example 2 1557 The example shown in Figure 5 builds on the example in Appendix B.1. 1559 However, it considers a reverse-proxy that stands in for only the 1560 whole group of servers, but not for each individual server. 1562 The final exchange between C and S1 occurs with CoAP over UDP. 1564 C P S1 S2 1565 | | | | 1566 |----------------------------->| /* C is not aware | | 1567 | Src: C_ADDR:C_PORT | that P is in fact | | 1568 | Dst: group1.com:P_PORT | a reverse-proxy */ | | 1569 | Uri-Path: /r | | | 1570 | | | | 1571 |<-----------------------------| | | 1572 | Src: group1.com:P_PORT | | | 1573 | Dst: C_ADDR:C_PORT | | | 1574 | 4.00 Bad Request | | | 1575 | Multicast-Signaling: (empty) | | | 1576 | Payload: "Please use | | | 1577 | Multicast-Signaling" | | | 1578 | | | | 1579 |----------------------------->| | | 1580 | Src: C_ADDR:C_PORT | | | 1581 | Dst: group1.com:P_PORT | | | 1582 | Multicast-Signaling: 60 | | | 1583 | Uri-Path: /r | | | 1584 | | | | 1585 | | Src: P_ADDR:P_PORT | | 1586 | | Dst: G_ADDR:G_PORT | | 1587 | | Uri-Path: /r | | 1588 | |---------------+----->| | 1589 | | \ | | 1590 | | +----------------->| 1591 | | | | 1592 | | /* t = 0 : P starts | | 1593 | | accepting responses | | 1594 | | for this request */ | | 1595 | | | | 1596 | | | | 1597 | |<---------------------| | 1598 | | Src: S1_ADDR:S1_PORT | | 1599 | | Dst: P_ADDR:P_PORT | | 1600 | | | | 1601 |<-----------------------------| | | 1602 | Dst: group1.com:P_PORT | | | 1603 | Dst: C_ADDR:C_PORT | | | 1604 | Response-Forwarding { | | | 1605 | [1, /*CoAP over UDP*/ | | | 1606 | #6.260(bstr(S1_ADDR)), | | | 1607 | S1_PORT | | | 1608 | ] | | | 1609 | } | | | 1610 | | | | 1611 | |<-----------------------------------| 1612 | | Src: S2_ADDR:S2_PORT | 1613 | | Dst: P_ADDR:P_PORT | 1614 | | | | 1615 |<-----------------------------| | | 1616 | Dst: group1.com:P_PORT | | | 1617 | Dst: C_ADDR:C_PORT | | | 1618 | Response-Forwarding { | | | 1619 | [1, /*CoAP over UDP*/ | | | 1620 | #6.260(bstr(S2_ADDR)), | | | 1621 | S2_PORT | | | 1622 | ] | | | 1623 | } | | | 1624 | | | | 1625 | /* At t = 60, P stops accepting | | 1626 | responses for this request */ | | 1627 | | | | 1628 | | | | 1629 |---------------------------------------------------->| | 1630 | Src: C_ADDR:C_PORT | /* Request intended | | 1631 | Dst: S1.ADDR:S1_PORT | only to S1 */ | | 1632 | Uri-Path: /r | | | 1633 | | | | 1634 | | | | 1635 |<----------------------------------------------------| | 1636 | Src: S1.ADDR:S1_PORT | | | 1637 | Dst: C_ADDR:C_PORT | | | 1638 | | | | 1640 Figure 5: Workflow example with reverse-proxy standing in for only 1641 the whole group of servers, but not for each individual server 1643 Acknowledgments 1645 The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran 1646 Selander for their comments and feedback. 1648 The work on this document has been partly supported by VINNOVA and 1649 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1650 (Grant agreement 952652). 1652 Authors' Addresses 1653 Marco Tiloca 1654 RISE AB 1655 Isafjordsgatan 22 1656 Kista SE-16440 Stockholm 1657 Sweden 1659 Email: marco.tiloca@ri.se 1661 Esko Dijk 1662 IoTconsultancy.nl 1663 \________________\ 1664 Utrecht 1665 The Netherlands 1667 Email: esko.dijk@iotconsultancy.nl