idnits 2.17.1 draft-tiloca-core-groupcomm-proxy-02.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 (November 02, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cbor-7049bis' == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-10 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-09 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-07 -- 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: May 6, 2021 IoTconsultancy.nl 6 November 02, 2020 8 Proxy Operations for CoAP Group Communication 9 draft-tiloca-core-groupcomm-proxy-02 11 Abstract 13 This document specifies the operations performed by a forward-proxy, 14 when using the Constrained Application Protocol (CoAP) in group 15 communication scenarios. Proxy operations involve the processing of 16 individual responses from servers, as reply to a single request sent 17 by the client over unicast to the proxy, and then distributed by the 18 proxy over IP multicast to the servers. When receiving the different 19 responses via the proxy, the client is able to distinguish them and 20 their origin servers, by acquiring their addressing information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 6, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 4 59 3. The Response-Forwarding Option . . . . . . . . . . . . . . . 5 60 4. Requirements and Objectives . . . . . . . . . . . . . . . . . 6 61 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Request Sending . . . . . . . . . . . . . . . . . . . . . 7 63 5.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 9 64 5.2. Request Processing at the Proxy . . . . . . . . . . . . . 9 65 5.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 10 66 5.3. Request and Response Processing at the Server . . . . . . 10 67 5.3.1. Supporting Observe . . . . . . . . . . . . . . . . . 10 68 5.4. Response Processing at the Proxy . . . . . . . . . . . . 10 69 5.4.1. Supporting Observe . . . . . . . . . . . . . . . . . 11 70 5.5. Response Processing at the Client . . . . . . . . . . . . 12 71 5.5.1. Supporting Observe . . . . . . . . . . . . . . . . . 13 72 6. Chain of Proxies . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Request Processing at the Proxy . . . . . . . . . . . . . 14 74 6.1.1. Supporting Observe . . . . . . . . . . . . . . . . . 15 75 6.2. Response Processing at the Proxy . . . . . . . . . . . . 16 76 6.2.1. Supporting Observe . . . . . . . . . . . . . . . . . 16 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 7.1. Client Authentication . . . . . . . . . . . . . . . . . . 17 79 7.2. Multicast-Signaling Option . . . . . . . . . . . . . . . 18 80 7.3. Response-Forwarding Option . . . . . . . . . . . . . . . 19 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 82 8.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 19 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 85 9.2. Informative References . . . . . . . . . . . . . . . . . 21 86 Appendix A. Using OSCORE Between Client and Proxy . . . . . . . 21 87 A.1. Protecting the Request . . . . . . . . . . . . . . . . . 22 88 A.2. Verifying the Request . . . . . . . . . . . . . . . . . . 22 89 A.3. Protecting the Response . . . . . . . . . . . . . . . . . 23 90 A.4. Verifying the Response . . . . . . . . . . . . . . . . . 23 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 The Constrained Application Protocol (CoAP) [RFC7252] allows the 97 presence of forward-proxies, as intermediary entities supporting 98 clients to perform requests on their behalf. 100 CoAP supports also group communication over IP multicast 101 [I-D.ietf-core-groupcomm-bis], where a group request can be addressed 102 to multiple recipient servers, each of which may reply with an 103 individual unicast response. As discussed in Section 2.3.3 of 104 [I-D.ietf-core-groupcomm-bis], this group communication scenario 105 poses a number of issues and limitations to proxy operations. 107 In particular, the client sends a single unicast request to the 108 proxy, which the proxy forwards to a group of servers over IP 109 multicast. Later on, the proxy delivers back to the client multiple 110 responses to the original unicast request. As defined by [RFC7252], 111 the multiple responses are delivered to the client inside separate 112 CoAP messages, all matching (by Token) to the client's original 113 unicast request. A possible alternative approach of performing 114 aggregation of responses into a single CoAP response would require a 115 specific aggregation content-format, which is not available yet. 116 Both these approaches have open issues. 118 This specification considers the former approach, i.e. the proxy 119 forwards the individual responses to a CoAP group request back to the 120 client. The described method addresses all the related issues raised 121 in Section 2.3.3 of [I-D.ietf-core-groupcomm-bis]. To this end, a 122 dedicated signaling protocol is defined, using two new CoAP options. 124 In particular, the client explicitly confirms its support for 125 receiving multiple responses to a proxied unicast request, i.e. one 126 per origin server, and for how long it is willing to wait for 127 responses. Also, when forwarding a response to the client, the proxy 128 indicates the addressing information of the origin server. This 129 enables the client to distinguish the multiple, diffent responses by 130 origin and to possibly contact one or more of the servers by sending 131 individual unicast requests, optionally bypassing the forward-proxy. 133 1.1. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 Readers are expected to be familiar with terms and concepts defined 142 in CoAP [RFC7252], Group Communication for CoAP 143 [I-D.ietf-core-groupcomm-bis], CBOR [I-D.ietf-cbor-7049bis], OSCORE 144 [RFC8613] and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 146 2. The Multicast-Signaling Option 148 The Multicast-Signaling Option defined in this section has the 149 properties summarized in Figure 1, which extends Table 4 of 150 [RFC7252]. 152 Since the option is not Safe-to-Forward, the column "N" indicates a 153 dash for "not applicable". The value of the Multicast-Signaling 154 Option specifies a timeout value in seconds, encoded as an unsigned 155 integer (see Section 3.2 of [RFC7252]). 157 +------+---+---+---+---+------------+--------+--------+---------+ 158 | No. | C | U | N | R | Name | Format | Length | Default | 159 +------+---+---+---+---+------------+--------+--------+---------+ 160 | | | | | | | | | | 161 | TBD1 | | x | - | | Multicast- | uint | 0-5 | (none) | 162 | | | | | | Signaling | | | | 163 | | | | | | | | | | 164 +------+---+---+---+---+------------+--------+--------+---------+ 165 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 167 Figure 1: The Multicast-Signaling Option. 169 This document specifically defines how this option is used by a 170 client, to indicate to a forward-proxy its support for and interest 171 in receiving multiple responses to a proxied CoAP group request, i.e. 172 one per origin server, and for how long it is willing to wait for 173 receiving responses via that proxy (see Section 5.1 and Section 5.2). 175 The client, when sending a CoAP group request to a proxy via IP 176 unicast, to be forwarded by the proxy to a targeted group of servers, 177 includes the Multicast-Signaling Option into the request. The option 178 value indicates after what time period in seconds the client will 179 stop accepting responses matching its original unicast request, with 180 the exception of notifications if CoAP Observe is used [RFC7641]. 181 This allows the intermediary proxy to stop forwarding responses back 182 to the client, if received from the servers later than a timeout 183 expiration. 185 The Multicast-Signaling Option is of class U in terms of OSCORE 186 processing (see Section 4.1 of [RFC8613]). 188 3. The Response-Forwarding Option 190 The Response-Forwarding Option defined in this section has the 191 properties summarized in Figure 2, which extends Table 4 of 192 [RFC7252]. The option is intended only for CoAP responses, and 193 builds on the Base-Uri option from Section 3 of 194 [I-D.bormann-coap-misc]. 196 Since the option is intended only for responses, the column "N" 197 indicates a dash for "not applicable". 199 +------+---+---+---+---+------------+--------+--------+---------+ 200 | No. | C | U | N | R | Name | Format | Length | Default | 201 +------+---+---+---+---+------------+--------+--------+---------+ 202 | | | | | | | | | | 203 | TBD2 | | | - | | Response- | (*) | 9-24 | (none) | 204 | | | | | | Forwarding | | | | 205 | | | | | | | | | | 206 +------+---+---+---+---+------------+--------+--------+---------+ 207 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 209 (*) See below. 211 Figure 2: The Response-Forwarding Option. 213 This document specifically defines how this option is used by a proxy 214 that forwards a request originated by a client over IP multicast. 216 Upon receiving a response to that request from a server, the proxy 217 includes the Response-Forwarding Option into the response sent to the 218 origin client (see Section 5). The proxy uses the option to indicate 219 to the client the addressing information of the server generating the 220 response. 222 The client can use the addressing information of the server specified 223 in the option to identify the response originator and possibly send 224 it individual requests later on, either directly or via the proxy as 225 CoAP unicast requests. 227 The option value is the byte serialization of a CBOR array 228 'srv_info', which includes the following elements. 230 o 'srv_addr': this element is a CBOR byte string, with value the 231 unicast IP address of the server. This element is tagged and 232 identified by the CBOR tag 260 "Network Address (IPv4 or IPv6 or 233 MAC Address)". This element MUST be present. 235 o 'srv_port': this element is a CBOR unsigned integer, with value 236 the destination port number where to send unicast requests to the 237 server. This element MAY be present. 239 The CDDL notation [RFC8610] provided below describes the 'srv_info' 240 CBOR array using the format above. 242 srv_info = [ 243 srv_addr : #6.260(bstr), ; IP address of the server 244 ? srv_port : uint, ; Port number of the server 245 ] 247 If the 'srv_info' array does not include the element 'srv_port', it 248 is assumed that the port number where to send unicast requests to the 249 server is the same port number specified in the group URI of the 250 original unicast CoAP group request sent to the proxy (see 251 Section 5.1). 253 The Response-Forwarding Option is of class U in terms of OSCORE 254 processing (see Section 4.1 of [RFC8613]). 256 4. Requirements and Objectives 258 This specification assumes that the following requirements are 259 fulfilled. 261 o REQ1. The CoAP proxy is explicitly configured (allow-list) to 262 allow proxied CoAP group requests from specific client(s). 264 o REQ2. The CoAP proxy MUST identify a client sending a CoAP group 265 request, in order to verify whether the client is allowed-listed 266 to do so. For example, this can rely on one of the following. 268 * A DTLS channel [RFC6347][I-D.ietf-tls-dtls13] between the 269 client and the proxy, where the client has also been 270 authenticated during the secure channel establishment. 272 * A pairwise OSCORE Security Context between the client and the 273 proxy, as described in Appendix A. 275 o REQ3. If secure, end-to-end communication is required between the 276 client and the servers in the CoAP group, exchanged messages MUST 277 be protected by using Group OSCORE 278 [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5.2 of 279 [I-D.ietf-core-groupcomm-bis]. This requires the client and the 280 servers to have previously joined the correct OSCORE group, for 281 instance by using the approach described in 282 [I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to 283 join can be pre-configured or alternatively discovered, for 284 instance by using the approach described in 285 [I-D.tiloca-core-oscore-discovery]. 287 This specification defines how to achieve the following objectives. 289 o OBJ1. The CoAP proxy gets an indication from the client that it 290 is in fact interested to and capable to receive multiple responses 291 to its unicast request containing a CoAP group URI. 293 o OBJ2. The CoAP proxy learns how long it should wait for responses 294 to a proxied request, before starting to ignore following 295 responses (except for notifications, if CoAP Observe is used 296 [RFC7641]). 298 o OBJ3. The CoAP proxy returns individual unicast responses to the 299 client, each of which matches the original unicast request to the 300 proxy. 302 o OBJ4. The CoAP client is able to distinguish the different 303 responses to the original unicast request, as well as their 304 corresponding origin servers. 306 o OBJ5. The CoAP client is enabled to optionally contact one or 307 more of the responding origin servers in the future, either 308 directly or via the CoAP proxy. 310 5. Protocol Description 312 This section specifies the steps of the signaling protocol. 314 5.1. Request Sending 316 In order to send a request addressed to a group of servers via the 317 CoAP proxy, the client proceeds as follows. 319 1. The client prepares a request addressed to the CoAP proxy. The 320 request specifies the group URI as a string in the Proxi-URI 321 option, or by using the Proxy-Scheme option with the group URI 322 constructed from the URI-* options (see Section 2.3.3 of 323 [I-D.ietf-core-groupcomm-bis]). 325 2. The client MUST retain the Token value used for this original 326 unicast request beyond the reception of a first response matching 327 it. To this end, the client follows the same rules for Token 328 retention defined for multicast requests in Section 2.3.1 of 329 [I-D.ietf-core-groupcomm-bis]. 331 In particular, the client picks an amount of time T it is fine to 332 wait for before freeing up the Token value. Specifically, the 333 value of T MUST be such that: 335 * T < T_r , where T_r is the amount of time that the client is 336 fine to wait for before potentially reusing the Token value. 337 Note that T_r MUST NOT be less than MIN_TOKEN_REUSE_TIME 338 defined in Section 2.3.1 of [I-D.ietf-core-groupcomm-bis]. 340 * T should be at least the expected worst-case time taken by the 341 request and response processing on the forward-proxy and on 342 the servers in the addressed CoAP group. 344 * T should be at least the expected worst-case round-trip delay 345 between the client and the forward-proxy, as well as between 346 the proxy and the origin servers. 348 3. The client MUST include the Multicast-Signaling Option defined in 349 Section 2 into the unicast request to send to the proxy. The 350 option value specifies an amount of time T' < T. The difference 351 (T - T') should be at least the expected worst-case round-trip 352 time between the client and the forward-proxy. 354 The client can specify T' = 0 as option value, thus indicating to 355 be not interested in receiving responses from the origin servers 356 through the proxy. In such a case, the client SHOULD also 357 include a No-Response Option [RFC7967] with value 26 (suppress 358 all response codes), if it supports the option. 360 Consistently, if the unicast request to send to the proxy already 361 included a No-Response Option with value 26, the client SHOULD 362 specify T' = 0 as value of the Multicast-Signaling Option. 364 4. The client processes the request as defined in 365 [I-D.ietf-core-groupcomm-bis], and also as in 366 [I-D.ietf-core-oscore-groupcomm] when secure group communication 367 is used between the client and the servers. 369 5. If OSCORE is used to protect the leg between the client and the 370 proxy (see REQ2 in Section 4), the client (further) protects the 371 unicast request as resulting at the end of step 4. In 372 particular, the client uses the pairwise OSCORE Security Context 373 it has with the proxy, as described in Appendix A.1. 375 6. The client sends the request to the proxy as a unicast CoAP 376 message. 378 The exact method that the client uses to estimate the worst-case 379 processing times and round-trip delays mentioned above is out of the 380 scope of this specification. However, such a method is expected to 381 be already used by the client when generally determining a good Token 382 lifetime and reuse interval. 384 5.1.1. Supporting Observe 386 When using CoAP Observe [RFC7641], the client follows what is 387 specified in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis], with the 388 difference that it sends a unicast request to the proxy, to be 389 forwarded to the group of servers, as defined in Section 5.1 of this 390 specification. 392 Furthermore, the client especially follows what is specified in 393 Section 5 of [RFC7641], i.e. it registers its interest to be an 394 observer with the proxy, as if it was communicating with the servers. 396 5.2. Request Processing at the Proxy 398 Upon receiving the request from the client, the proxy proceeds as 399 follows. 401 1. If OSCORE is used to protect the leg between the client and the 402 proxy (see REQ2 in Section 4), the proxy decrypts the request 403 using the pairwise OSCORE Security Context it has with the 404 client, as described in Appendix A.2. 406 2. The proxy identifies the client, and verifies that the client is 407 in fact allowed-listed to have its requests proxyied to CoAP 408 group URIs. 410 3. The proxy verifies the presence of the Multicast-Signaling 411 Option, as a confirmation that the client is fine to receive 412 multiple responses matching the same original request. 414 If the Multicast-Signaling Option is not present, the proxy MUST 415 stop processing the request and MUST reply to the client with a 416 4.00 (Bad Request) response. The response MUST include a 417 diagnostic payload, specifying that the Multicast-Signaling 418 Option was missing and has to be included. 420 4. The proxy retrieves the value T' from the Multicast-Signaling 421 Option, and then removes the option from the client's request. 423 5. The proxy forwards the client's request to the group of servers. 424 In particular, the proxy sends it as a CoAP group request over IP 425 multicast, addressed to the group URI specified by the client. 427 6. The proxy sets a timeout with the value T' retrieved from the 428 Multicast-Signaling Option of the original unicast request. 430 In case T' > 0, the proxy will ignore responses to the forwarded 431 group request coming from servers, if received after the timeout 432 expiration, with the exception of Observe notifications (see 433 Section 5.4). 435 In case T' = 0, the proxy will ignore all responses to the 436 forwarded group request coming from servers. 438 5.2.1. Supporting Observe 440 When using CoAP Observe [RFC7641], the proxy takes the role of the 441 client and registers its own interest to observe the target resource 442 with the servers as per Section 5 of [RFC7641]. 444 When doing so, the proxy especially follows what is specified for the 445 client in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis], by 446 forwarding the group request to the servers over IP multicast, as 447 defined in Section 5.2 of this specification. 449 5.3. Request and Response Processing at the Server 451 Upon receiving the group request from the proxy, a server proceeds as 452 follows. 454 1. The server processes the group request as defined in 455 [I-D.ietf-core-groupcomm-bis], and also as in 456 [I-D.ietf-core-oscore-groupcomm] when secure group communication 457 is used between the client and the server. 459 2. The server processes the response to be forwarded back to the 460 client as defined in [I-D.ietf-core-groupcomm-bis], and also as 461 in [I-D.ietf-core-oscore-groupcomm] when secure group 462 communication is used between the client and the server. 464 5.3.1. Supporting Observe 466 When using CoAP Observe [RFC7641], the server especially follows what 467 is specified in Section 2.3.5 of [I-D.ietf-core-groupcomm-bis] and 468 Section 5 of [RFC7641]. 470 5.4. Response Processing at the Proxy 472 Upon receiving a response matching the group request before the 473 amount of time T' has elapsed, the proxy proceeds as follows. 475 1. The proxy MUST include the Response-Forwarding Option defined in 476 Section 3 into the response. The proxy specifies as option value 477 the addressing information of the server generating the response, 478 encoded as defined in Section 3. In particular: 480 * The 'srv_addr' element of the 'srv_info' array MUST specify 481 the server IPv6 address if the multicast request was destined 482 for an IPv6 multicast address, and MUST specify the server 483 IPv4 address if the multicast request was destined for an IPv4 484 address. 486 * If present, the 'srv_port' element of the 'srv_info' array 487 MUST specify the port number of the server as the source port 488 number of the response. This element MUST be present if the 489 source port number of the response differs from the port 490 number specified in the group URI of the original unicast CoAP 491 group request (see Section 5.1). Otherwise, the 'srv_port' 492 element MAY be omitted. 494 2. If OSCORE is used to protect the leg between the client and the 495 proxy (see REQ2 in Section 4), the proxy (further) protects the 496 response using the pairwise OSCORE Security Context it has with 497 the client, as described in Appendix A.3. 499 3. The proxy forwards the response back to the client. 501 Upon timeout expiration, i.e. T' seconds after having sent the group 502 request over IP multicast, the proxy frees up its local Token value 503 associated to that request. Thus, following late responses to the 504 same group request will be discarded and not forwarded back to the 505 client. 507 5.4.1. Supporting Observe 509 When using CoAP Observe [RFC7641], the proxy acts as a client 510 registered with the servers, as described earlier in Section 5.2.1. 512 Furthermore, the proxy takes the role of a server when forwarding 513 notifications from origin servers back to the client. To this end, 514 the proxy follows what is specified in Section 2.3.5 of 515 [I-D.ietf-core-groupcomm-bis] and Section 5 of [RFC7641], with the 516 following additions. 518 o At step 1 in Section 5.4, the proxy includes the Response- 519 Forwarding Option in every notification, including non-2.xx 520 notifications resulting in removing the proxy from the list of 521 observers of the origin server. 523 o The proxy frees up its Token value used for a group observation 524 only if, after the timeout expiration, no 2.xx (Success) responses 525 matching the group request and also including an Observe option 526 have been received from any origin server. After that, as long as 527 observations are active with servers in the group for the target 528 resource of the group request, notifications from those servers 529 are forwarded back to the client, as defined in Section 5.4. 531 Finally, the proxy SHOULD regularly verify that the client is still 532 interested in receiving observe notifications for a group 533 observation. To this end, the proxy can rely on the same approach 534 discussed for servers in Section 2.3.5 of 535 [I-D.ietf-core-groupcomm-bis], with more details available in 536 Section 4.5 of [RFC7641]. 538 5.5. Response Processing at the Client 540 Upon receiving from the proxy a response matching the original 541 unicast request before the amount of time T has elapsed, the client 542 proceeds as follows. 544 1. The client processes the response as defined in 545 [I-D.ietf-core-groupcomm-bis]. 547 2. If OSCORE is used to protect the leg between the client and the 548 proxy (see REQ2 in Section 4), the client decrypts the response 549 using the pairwise OSCORE Security Context it has with the proxy, 550 as described in Appendix A.4. 552 3. If secure group communication is used between the client and the 553 servers, the client processes the response, possibly as outcome 554 of step 2, as defined in [I-D.ietf-core-oscore-groupcomm]. 556 4. The client identifies the origin server, whose addressing 557 information is specified as value of the Response-Forwarding 558 Option. If the port number is omitted in the value of the 559 Response-Forwarding Option, the client MUST assume that the port 560 number where to send unicast requests to the server is the same 561 port number specified in the group URI of the original unicast 562 CoAP group request sent to the proxy (see Section 5.1). 564 In particular, the client is able to distinguish different responses 565 as originated by different servers. Optionally, the client may 566 contact one or more of those servers individually, i.e. directly 567 (bypassing the proxy) or indirectly (via a proxied CoAP unicast 568 request). 570 Upon the timeout expiration, i.e. T seconds after having sent the 571 original unicast request to the proxy, the client frees up its local 572 Token value associated to that request. Note that, upon this timeout 573 expiration, the Token value is not eligible for possible reuse yet 574 (see Section 5.1). Thus, until the actual amount of time before 575 enabling Token reusage has elapsed, following late responses to the 576 same request forwarded by the proxy will be discarded, as not 577 matching (by Token) any active request from the client. 579 5.5.1. Supporting Observe 581 When using CoAP Observe [RFC7641], the client frees up its Token 582 value only if, after the timeout expiration, no 2.xx (Success) 583 responses matching the original unicast request and also including an 584 Observe option have been received. 586 Instead, if at least one such response has been received, the client 587 continues receiving those notifications as forwarded by the proxy, as 588 long as the observation for the target resource of the original 589 unicast request is active. 591 6. Chain of Proxies 593 A client may be interested to access a resource at a group of origin 594 servers which is reached through a chain of two or more proxies. 596 That is, these proxies are configured into a chain, where each non- 597 last proxy is configured to forward CoAP (multicast) requests to the 598 next hop towards the origin servers. Also, each non-first proxy is 599 configured to forward back CoAP responses to (the previous hop proxy 600 towards) the origin client. 602 This section specifies how the signaling protocol defined in 603 Section 5 is used in that setting. Except for the last proxy before 604 the origin servers, every other proxy in the chain takes the role of 605 client with respect to the next hop towards the origin servers. 606 Also, every proxy in the chain takes the role of server towards the 607 previous proxy closer to the origin client. 609 The requirements REQ1 and REQ2 defined in Section 4 MUST be fulfilled 610 for each proxy in the chain. That is, every proxy in the chain has 611 to be explicitly configured (allow-list) to allow proxied group 612 requests from specific senders, and MUST identify those senders upon 613 receiving their group request. For the first proxy in the chain, 614 that sender is the origin client. For each other proxy in the chain, 615 that sender is the previous hop proxy closer the origin client. In 616 either case, a proxy can identify the sender of a group request by 617 the same means mentioned in Section 4. 619 6.1. Request Processing at the Proxy 621 Upon receiving a group request to be forwarded to a CoAP group URIs, 622 a proxy proceed as follows. 624 If the proxy is the last one in the chain, i.e. it is the last hop 625 before the origin servers, the proxy performs the steps defined in 626 Section 5.2, with no modifications. 628 Otherwise, the proxy performs the steps defined in Section 5.2, with 629 the following differences. 631 o At steps 1-3, "client" refers to the origin client for the first 632 proxy in the chain; or to the previous hop proxy closer to the 633 origin client, otherwise. 635 o At step 4, the proxy rather performs the following actions. 637 1. The proxy retrieves the value T' from the Multicast-Signaling 638 Option, and does not remove the option. 640 2. In case T' > 0, the proxy picks an amount of time T it is fine 641 to wait for before freeing up its local Token value to use 642 with the next hop towards the origin servers. To this end, 643 the proxy MUST follow what defined at step 2 of Section 5.1 644 for the origin client, with the following differences. 646 + T MUST be greater than the retrieved value T', i.e. T' < T. 648 + The worst-case message processing time takes into account 649 all the next hops towards the origin servers, as well as 650 the origin servers themselves. 652 + The worst-case round-trip delay takes into account all the 653 legs between the proxy and the origin servers. 655 3. In case T' > 0, the proxy replaces the value of the Multicast- 656 Signaling Option with a new value T'', such that: 658 + T'' < T. The difference (T - T'') should be at least the 659 expected worst-case round-trip time between the proxy and 660 the next hop towards the origin servers. 662 + T'' < T'. The difference (T' - T'') should be at least the 663 expected worst-case round-trip time between the proxy and 664 the (previous hop proxy closer to the) origin client. 666 If the proxy is not able to determine a value T'' that 667 fulfills both the requirements above, the proxy MUST stop 668 processing the request and MUST respond with a 5.05 (Proxying 669 Not Supported) error response to the previous hop proxy closer 670 to the origin client. The proxy SHOULD include a Multicast- 671 Signaling Option, set to the minimum value T' that would be 672 acceptable in the Multicast-Signaling Option of a request to 673 forward. 675 Upon receiving such an error response, any proxy in the chain 676 MAY send an updated request to the next hop towards the origin 677 servers, specifying in the Multicast-Signaling Option a value 678 T' greater than in the previous request. If this does not 679 happen, the proxy receiving the error response MUST also send 680 a 5.05 (Proxying Not Supported) error response to the previous 681 hop proxy closer to the origin client. Like the received one, 682 also this error response SHOULD include a Multicast-Signaling 683 Option, set to the minimum value T' acceptable by the proxy 684 sending the error response. 686 o At step 5, the proxy forwards the request to the next hop towards 687 the origin servers. 689 o At step 6, the proxy sets a timeout with the value T' retrieved 690 from the Multicast-Signaling Option of the request received from 691 the (previous hop proxy closer to the) origin client. 693 In case T' > 0, the proxy will ignore responses to the forwarded 694 group request coming from the (next hop towards the) origin 695 servers, if received after the timeout expiration, with the 696 exception of Observe notifications (see Section 5.4). 698 In case T' = 0, the proxy will ignore all responses to the 699 forwarded group request coming from the (next hop towards the) 700 origin servers. 702 6.1.1. Supporting Observe 704 When using CoAP Observe [RFC7641], what defined in Section 5.2.1 705 applies for the last proxy in the chain, i.e. the last hop before the 706 origin servers. 708 Any other proxy in the chain acts as a client and registers its own 709 interest to observe the target resource with the next hop towards the 710 origin servers, as per Section 5 of [RFC7641]. 712 6.2. Response Processing at the Proxy 714 Upon receiving a response matching the group request before the 715 amount of time T' has elapsed, the proxy proceeds as follows. 717 If the proxy is the last one in the chain, i.e. it is the last hop 718 before the origin servers, the proxy performs the steps defined in 719 Section 5.4, with no modifications. 721 Otherwise, the proxy performs the steps defined in Section 5.4, with 722 the following differences. 724 o The proxy skips step 1. In particular, the proxy MUST NOT remove, 725 alter or replace the Response-Forwarding Option. 727 o At steps 2-3, "client" refers to the origin client for the first 728 proxy in the chain; or to the previous hop proxy closer to the 729 origin client, otherwise. 731 Upon timeout expiration, i.e. T seconds after having sent the group 732 request to the next hop towards the origin servers, the proxy frees 733 up its local Token value associated to that request. Thus, following 734 late responses to the same group request will be discarded and not 735 forwarded back to the (previous hop proxy closer to the) origin 736 client. 738 6.2.1. Supporting Observe 740 When using CoAP Observe [RFC7641], what defined in Section 5.4.1 741 applies for the last proxy in the chain, i.e. the last hop before the 742 origin servers. 744 As to any other proxy in the chain, the following applies. 746 o The proxy acts as a client registered with the next hop towards 747 the origin servers, as described earlier in Section 6.1.1. 749 o The proxy takes the role of a server when forwarding notifications 750 from the next hop to the origin servers back to the (previous hop 751 proxy closer to the) origin client, as per Section 5 of [RFC7641]. 753 o The proxy frees up its Token value used for a group observation 754 only if, after the timeout expiration, no 2.xx (Success) responses 755 matching the group request and also including an Observe option 756 have been received from the next hop towards the origin servers. 757 After that, as long as the observation for the target resource of 758 the group request is active with the next hop towards the origin 759 servers in the group, notifications from that hop are forwarded 760 back to the (previous hop proxy closer to the) origin client, as 761 defined in Section 6.2. 763 o The proxy SHOULD regularly verify that the (previous hop proxy 764 closer to the) origin client is still interested in receiving 765 observe notifications for a group observation. To this end, the 766 proxy can rely on the same approach defined in Section 4.5 of 767 [RFC7641]. 769 7. Security Considerations 771 The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi 772 s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. 774 When a chain of proxies is used (see Section 6), the secure 775 communication between any two adjacent hops is independent. 777 When Group OSCORE is used for end-to-end secure group communication 778 between the origin client and the origin servers, this security 779 association is unaffected by the possible presence of a proxy or a 780 chain of proxies. 782 Furthermore, the following additional considerations hold. 784 7.1. Client Authentication 786 As per the requirement REQ2 (see Section 4), the client has to 787 authenticate to the proxy when sending a group request to forward. 788 This leverages an established security association between the client 789 and the proxy, that the client uses to protect the group request, 790 before sending it to the proxy. 792 Note that, if the group request is (also) protected with Group 793 OSCORE, i.e. end-to-end between the client and the servers, the proxy 794 can authenticate the client by successfully verifying the counter 795 signature embedded in the group request. This requires that, for 796 each client to authenticate, the proxy stores the public key used by 797 that client in the OSCORE group, which in turn would require a form 798 of active synchronization between the proxy and the Group Manager for 799 that group [I-D.ietf-core-oscore-groupcomm]. 801 Nevertheless, the client and the proxy SHOULD still rely on a full- 802 fledged, pairwise secure association. In addition to ensuring the 803 integrity of group requests sent to the proxy (see Section 7.2 and 804 Section 7.3), this prevents the proxy from forwarding replayed group 805 requests with a valid counter signature, as possibly injected by an 806 active, on-path adversary. 808 The same considerations apply when a chain of proxies is used (see 809 Section 6), with each proxy but the last one in the chain acting as 810 client with the next hop towards the origin servers. 812 7.2. Multicast-Signaling Option 814 The Multicast-Signaling Option is of class U for OSCORE [RFC8613]. 815 Hence, also when Group OSCORE is used between the client and the 816 servers [I-D.ietf-core-oscore-groupcomm], a proxy is able to access 817 the option value and retrieve the timeout value T', as well as to 818 remove the option altogether before forwarding the group request to 819 the servers. When a chain of proxies is used (see Section 6), this 820 also allows each proxy but the last one in the chain to update the 821 option value, as an indication for the next hop towards the origin 822 servers (see Section 6.1). 824 The security association between the client and the proxy MUST 825 provide message integrity, so that further intermediaries between the 826 two as well as on-path active adversaries are not able to remove the 827 option or alter its content, before the group request reaches the 828 proxy. Removing the option would otherwise result in not forwarding 829 the group request to the servers. Instead, altering the option 830 content would result in the proxy accepting and forwarding back 831 responses for an amount of time different than the one actually 832 indicated by the client. 834 The security association between the client and the proxy SHOULD also 835 provide message confidentiality. Otherwise, further intermediaries 836 between the two as well as on-path passive adversaries would be able 837 to simply access the option content, and thus learn for how long the 838 client is willing to receive responses from the servers in the group 839 via the proxy. This may in turn be used to perform a more efficient, 840 selective suppression of responses from the servers. 842 When the client (further) protects the unicast request sent to the 843 proxy using OSCORE (see Appendix A) and/or with DTLS, both message 844 integrity and message confidentiality are achieved in the leg between 845 the client and the proxy. 847 The same considerations above about security associations apply when 848 a chain of proxies is used (see Section 6), with each proxy but the 849 last one in the chain acting as client with the next hop towards the 850 origin servers. 852 7.3. Response-Forwarding Option 854 The Response-Forwarding Option is of class U for OSCORE [RFC8613]. 855 Hence, also when Group OSCORE is used between the client and the 856 servers [I-D.ietf-core-oscore-groupcomm], the proxy that has 857 forwarded the group request to the servers is able to include the 858 option into a server response, before forwarding this response back 859 to the (previous hop proxy closer to the) origin client. 861 Since the security association between the client and the proxy 862 provides message integrity, any further intermediaries between the 863 two or on-path active adversaries are not able to undetectably remove 864 the Response-Forwarding Option from a forwarded server response. 865 This ensures that the client can correctly distinguish the different 866 responses and identify their corresponding origin server. 868 When the proxy (further) protects the response forwarded back to the 869 client using OSCORE (see Appendix A) and/or with DTLS, message 870 integrity is achieved in the leg between the client and the proxy. 872 The same considerations above about security associations apply when 873 a chain of proxies is used (see Section 6), with each proxy but the 874 last one in the chain acting as client with the next hop towards the 875 origin servers. 877 8. IANA Considerations 879 This document has the following actions for IANA. 881 8.1. CoAP Option Numbers Registry 883 IANA is asked to enter the following option numbers to the "CoAP 884 Option Numbers" registry defined in [RFC7252] within the "CoRE 885 Parameters" registry. 887 +--------+---------------------+-------------------+ 888 | Number | Name | Reference | 889 +--------+---------------------+-------------------+ 890 | TBD1 | Multicast-Signaling | [[this document]] | 891 +--------+---------------------+-------------------+ 892 | TBD2 | Response-Forwarding | [[this document]] | 893 +--------+---------------------+-------------------+ 895 9. References 896 9.1. Normative References 898 [I-D.ietf-cbor-7049bis] 899 Bormann, C. and P. Hoffman, "Concise Binary Object 900 Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work 901 in progress), September 2020. 903 [I-D.ietf-core-groupcomm-bis] 904 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 905 for the Constrained Application Protocol (CoAP)", draft- 906 ietf-core-groupcomm-bis-02 (work in progress), November 907 2020. 909 [I-D.ietf-core-oscore-groupcomm] 910 Tiloca, M., Selander, G., Palombini, F., and J. Park, 911 "Group OSCORE - Secure Group Communication for CoAP", 912 draft-ietf-core-oscore-groupcomm-10 (work in progress), 913 November 2020. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 921 Application Protocol (CoAP)", RFC 7252, 922 DOI 10.17487/RFC7252, June 2014, 923 . 925 [RFC7641] Hartke, K., "Observing Resources in the Constrained 926 Application Protocol (CoAP)", RFC 7641, 927 DOI 10.17487/RFC7641, September 2015, 928 . 930 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 931 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 932 May 2017, . 934 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 935 Definition Language (CDDL): A Notational Convention to 936 Express Concise Binary Object Representation (CBOR) and 937 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 938 June 2019, . 940 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 941 "Object Security for Constrained RESTful Environments 942 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 943 . 945 9.2. Informative References 947 [I-D.bormann-coap-misc] 948 Bormann, C. and K. Hartke, "Miscellaneous additions to 949 CoAP", draft-bormann-coap-misc-27 (work in progress), 950 November 2014. 952 [I-D.ietf-ace-key-groupcomm-oscore] 953 Tiloca, M., Park, J., and F. Palombini, "Key Management 954 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 955 oscore-09 (work in progress), November 2020. 957 [I-D.ietf-tls-dtls13] 958 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 959 Datagram Transport Layer Security (DTLS) Protocol Version 960 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 961 2020. 963 [I-D.tiloca-core-oscore-discovery] 964 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 965 Groups with the CoRE Resource Directory", draft-tiloca- 966 core-oscore-discovery-07 (work in progress), November 967 2020. 969 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 970 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 971 January 2012, . 973 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 974 Bose, "Constrained Application Protocol (CoAP) Option for 975 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 976 August 2016, . 978 Appendix A. Using OSCORE Between Client and Proxy 980 This section describes how OSCORE is used to protect messages 981 exchanged by an origin client and a proxy, using their pairwise 982 OSCORE Security Context. 984 This is especially convenient for the communication scenario 985 addressed in this document, when the origin client already supports 986 and uses Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect 987 messages end-to-end with the origin servers. 989 The following focuses on the origin client originating the group 990 request and a single proxy as its immediate next hop. When a chain 991 of proxies is used (see Section 6), the same independently applies 992 between each pair of proxies in the chain, where the proxy forwarding 993 the group request acts as client and the next hop towards the origin 994 servers acts as server. 996 A.1. Protecting the Request 998 Before sending the CoAP request to the proxy, the origin client 999 protects it using the pairwise OSCORE Security Context it has with 1000 the proxy. 1002 To this end, the origin client processes the CoAP request as defined 1003 in Section 8.1 of [RFC8613], with the following differences. 1005 o The Proxy-Uri option, if present, is not decomposed and recomposed 1006 as defined in Section 4.1.3.3 of [RFC8613]. 1008 o The following options, if present, are processed as Class E. 1010 * Proxy-Uri, Proxy-Scheme, Uri-Host and Uri-Port, defined in 1011 [RFC7252]. 1013 * OSCORE, defined in [RFC8613], which is present if Group OSCORE 1014 is used between the origin client and the origin servers, to 1015 achieve end-to-end secure group communication. 1017 * Multicast-Signaling Option, defined in Section 2 of this 1018 specification. 1020 As per [RFC8613], the resulting message includes an outer OSCORE 1021 Option, which reflects the usage of the pairwise OSCORE Security 1022 Context between the origin client and the proxy. 1024 A.2. Verifying the Request 1026 The proxy verifies the CoAP request as defined in Section 8.2 of 1027 [RFC8613]. Note that the Multicast-Signaling Option is retrieved 1028 during the decryption process, and added to the decrypted request. 1030 If secure group communication is also used between the origin client 1031 and the origin servers, the request resulting from the previous step 1032 and to be forwarded to the origin servers is also already protected 1033 with Group OSCORE [I-D.ietf-core-oscore-groupcomm]. Consequently, it 1034 includes an outer OSCORE Option, which reflects the usage of the 1035 group OSCORE Security Context between the origin client and the 1036 origin servers. 1038 A.3. Protecting the Response 1040 The proxy protects the CoAP response received from a server, using 1041 the pairwise OSCORE Security Context it has with the origin client. 1043 To this end, the proxy processes the CoAP response as defined in 1044 Section 8.3 of [RFC8613], with the difference that the OSCORE Option, 1045 if present, is processed as Class E. This is the case if Group 1046 OSCORE is used between the origin client and the origin servers, to 1047 achieve end-to-end secure group communication. 1049 Furthermore, the Response-Forwarding Option defined in Section 3 of 1050 this specification is also processed as Class E. 1052 As per [RFC8613], the resulting message to be forwarded back to the 1053 origin client includes an outer OSCORE Option, which reflects the 1054 usage of the pairwise OSCORE Security Context between the origin 1055 client and the proxy. 1057 A.4. Verifying the Response 1059 The origin client verifies the CoAP response received from the proxy 1060 as defined in Section 8.4 of [RFC8613]. Note that, the Response- 1061 Forwarding Option is retrieved during the decryption process, and 1062 added to the decrypted response. 1064 If secure group communication is also used between the origin client 1065 and the origin servers, the response resulting from the previous step 1066 is protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 1067 Consequently, it includes an outer OSCORE Option, which reflects the 1068 usage of the group OSCORE Security Context between the origin client 1069 and the origin servers. 1071 Acknowledgments 1073 The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran 1074 Selander for their comments and feedback. 1076 The work on this document has been partly supported by VINNOVA and 1077 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1078 (Grant agreement 952652). 1080 Authors' Addresses 1081 Marco Tiloca 1082 RISE AB 1083 Isafjordsgatan 22 1084 Kista SE-16440 Stockholm 1085 Sweden 1087 Email: marco.tiloca@ri.se 1089 Esko Dijk 1090 IoTconsultancy.nl 1091 \________________\ 1092 Utrecht 1093 The Netherlands 1095 Email: esko.dijk@iotconsultancy.nl