idnits 2.17.1 draft-bormann-core-responses-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(130): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. 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 (3 February 2022) is 806 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-09) exists of draft-tiloca-core-groupcomm-proxy-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational C. Amsüss 5 Expires: 7 August 2022 3 February 2022 7 CoAP: Non-traditional response forms 8 draft-bormann-core-responses-01 10 Abstract 12 In CoAP as defined by RFC 7252, responses are always unicast back to 13 a client that posed a request. The present memo describes two forms 14 of responses that go beyond that model. These descriptions are not 15 intended as advocacy for adopting these approaches immediately, they 16 are provided to point out potential avenues for development that 17 would have to be carefully evaluated. 19 About This Document 21 This note is to be removed before publishing as an RFC. 23 Status information for this document may be found at 24 https://datatracker.ietf.org/doc/draft-bormann-core-responses/. 26 Discussion of this document takes place on the Constrained RESTful 27 Environments (CoRE) Working Group mailing list 28 (mailto:core@ietf.org), which is archived at 29 https://mailarchive.ietf.org/arch/browse/core/. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/core-wg/core-responses. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 7 August 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Sending non-traditional responses . . . . . . . . . . . . . . 4 69 2.1. Preconditions to sending non-traditional responses . . . 4 70 2.2. Responses without request . . . . . . . . . . . . . . . . 5 71 3. Response with embedded request . . . . . . . . . . . . . . . 5 72 4. Response for configured request . . . . . . . . . . . . . . . 5 73 4.1. Examples for configured requests . . . . . . . . . . . . 6 74 4.1.1. Example: Periodic request . . . . . . . . . . . . . . 6 75 4.1.2. Example: Event driven request . . . . . . . . . . . . 6 76 4.1.3. Example: Configured observe . . . . . . . . . . . . . 6 77 4.2. Multicast responses . . . . . . . . . . . . . . . . . . . 6 78 4.3. Respond-To option . . . . . . . . . . . . . . . . . . . . 7 79 4.4. Leisure-For-Responses Option . . . . . . . . . . . . . . 7 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 7.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Appendix A. CoAP extensions explained by non-traditional 86 responses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 A.1. Observation . . . . . . . . . . . . . . . . . . . . . . . 10 88 A.2. Responses to multicast requests . . . . . . . . . . . . . 10 89 A.3. Triangular responses (Response-To) . . . . . . . . . . . 11 90 A.4. Other current documents . . . . . . . . . . . . . . . . . 11 91 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 94 1. Introduction 96 In CoAP as defined by RFC 7252, responses are always unicast back to 97 a client that posed a request. A server may want to send a response 98 to a request that it did not receive, may want to multicast a 99 response, or both. 101 The descriptions in this specification are not intended as advocacy 102 for adopting these approaches immediately, they are provided to point 103 out potential avenues for development that would have to be carefully 104 evaluated. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 The term "byte" is used in its now customary sense as a synonym for 115 "octet". 117 Terms used in this draft: 119 Non-traditional response: A response that is not the single response 120 generated for a request received on the same transport. 122 Non-matching response: A response that has properties (typically 123 options) that make it incompatible with the original request, and 124 thus in particular unsuitable as a cached response to that request 125 (but possibly suitable to populate the cache for a similar 126 request). Options that make a response non-matching need to be 127 proxy unsafe. 129 For example, a Block2 response with a different value of block 130 number × block size than indicated in the request is non-matching. 132 Configured request: A request that reaches the server in another way 133 than by transmitting a usual CoAP request on the same 134 communication channel a response is expected on. 136 Embedded request: A request that is provided by the server to the 137 recipient of its response by embedding it into the response. 139 2. Sending non-traditional responses 141 Non-traditional responses are sets of responses produced for a single 142 request, or responses sent without a transmitted request. 144 Where tokens are involved, all non-traditional responses use the 145 request's token; in any case, they are bound to the original request 146 (e.g. by using the same request_kid/request_piv pair in OSCORE 147 [RFC8613]). Where message IDs are involved, one of the non- 148 traditional response (the first sent, not necessarily the first 149 received as generally the network might reorder messages) can be sent 150 as a piggybacked response in an ACK (thus sharing the request's 151 message ID), the others are CON or NON responses. 153 Some established responses (observations defined in [RFC7641], and 154 multicast responses in [I-D.ietf-core-groupcomm-bis]) match this 155 definition and already follow the guidance set out here for non- 156 traditional responses; Appendix A gives details for them. 158 A second response differing from the first that can be sent by a non- 159 deduplicating server responding to a retransmission of a request is 160 not non-traditional because there is a second request -- that is 161 probably the last corner case at the line separating traditional from 162 non-traditional responses. 164 2.1. Preconditions to sending non-traditional responses 166 A server may send multiple responses to a request if there is any 167 property in the request that indicates the client's intention to 168 receive them. This is typically indicated by a request option, and 169 rarely in external properties of the message (in the multicast case, 170 the destination address). 172 A mechanism for eliciting multiple responses must specify the 173 conditions under which a token gets freed, as the traditional arrival 174 of the response is insufficient. It may also specify for which 175 requests the token can be reused immediately in follow-up requests. 176 On unordered transports, or when it's a client's follow-up request 177 and not a response that terminates the token, the client needs to 178 wait until no reordered non-traditional responses can be expected 179 anymore. 181 If a non-traditional response answers the original request, no 182 further action is required (this is the case of observation: ordering 183 is added on top of that to ensure that only the latest response is 184 used). If the response does not answer the original request, it must 185 be non-matching, either by an option introduced with the eliciting 186 option or by a generic option like Response-For. 188 2.2. Responses without request 190 Endpoints may agree out of band on a token (or other request-matching 191 details). One way to do that is to exchange a "phantom request", 192 which is a request that client and server will agree to have sent and 193 received, respectively, without it actually being sent between those 194 endpoints. 196 As tokens are managed by the client, that request needs to be 197 generated by the client, or in close collaboration with the client 198 (for example by the client allowing a third party to use a subset of 199 its token values in order to set up non-traditional responses). 201 3. Response with embedded request 203 A server can send a response to a request that it did not actually 204 receive by embedding the request which the response answers in the 205 response. 207 The option "Response-For" contains a request packaged as in 208 Section 5.3 of [RFC8613]. The response is then intended to serve as 209 a response to this request. 211 +=====+===+===+===+===+==============+========+========+=========+ 212 | No. | C | U | N | R | Name | Format | Length | Default | 213 +=====+===+===+===+===+==============+========+========+=========+ 214 | TBD | C | - | - | - | Response-For | opaque | 0-1023 | (none) | 215 +-----+---+---+---+---+--------------+--------+--------+---------+ 217 Table 1: The Response-For Option 219 The CoAP Token becomes meaningless for this form of response; 220 responses with embedded requests are therefore sent with a zero- 221 length Token. (In essence, the "Response-For" option takes the place 222 of the request the Token usually stands for.) 224 The congestion control considerations for confirmable and non- 225 confirmable messages apply unchanged. 227 4. Response for configured request 229 A request may reach the server using a different means than that used 230 for the response. For instance, the request may be configured in the 231 server. Without limiting generality, we speak about _configured 232 requests_. 234 The client MUST be cognizant of that configuration as the request 235 uses a token from the token name space it controls. 237 4.1. Examples for configured requests 239 4.1.1. Example: Periodic request 241 A server may be configured to act on a configured request every day 242 at 12:00. 244 4.1.2. Example: Event driven request 246 A server may be configured to act on a configured request each time 247 it reboots. 249 4.1.3. Example: Configured observe 251 A server may be configured with a GET request from a client that 252 includes an Observe option with value 0. This means that the server 253 will send updates to the state of the resource addressed by the GET 254 request to the configured address of the client. 256 The considerations of Section 4.5 of [RFC7641] apply. How losing 257 interest reflects back into to configuration and whether there is 258 some form of error notification to the source of the configuration is 259 out of scope of the present specification. 261 4.2. Multicast responses 263 A server MAY send a response to a multicast address. (This needs to 264 be a response to a configured request as a normal request cannot be 265 sent _from_ a multicast address.) 267 Note that, as the originator of a multicast response is a unicast 268 address, the relaxation of matching rules described in Section 8.2 of 269 [RFC7252] does not apply. 271 The token space in CoAP is owned by the client, which is identified 272 by a transport endpoint (address/port). Here, the address is a 273 multicast address, so the token name space is shared by all nodes 274 joined to that multicast address. The assumption for multicast 275 responses is that, for each multicast group, there is some form of 276 management for the token space (and the port number) that everyone 277 can participate that needs to join that multicast group; the specific 278 form of management is out of the scope of this specification. Note 279 that this means that multicast responses MUST NOT be sent to 280 unmanaged multicast addresses such as All CoAP Nodes (Section 12.8 of 281 [RFC7252]). 283 Multicast responses are always non-confirmable. The congestion 284 control considerations for non-confirmable multicast messages apply 285 unchanged. 287 4.3. Respond-To option 289 What has been called "configured request" here may also be triggered 290 by a usual CoAP request that carries the Respond-To option. (The 291 term "configured request" is still appropriate as the server ought to 292 be configured to accept this option; see Section 6.) 294 If a single client wants to request a server to send the response to 295 a specific multicast address, it can include the "Respond-To" option. 296 This contains an opaque string with the port number as a 16-bit 297 number (in network byte order), followed by the IP address (4-byte 298 IPv4 or 16-byte IPv6). 300 +=====+===+===+===+===+============+========+========+=========+ 301 | No. | C | U | N | R | Name | Format | Length | Default | 302 +=====+===+===+===+===+============+========+========+=========+ 303 | TBD | C | U | - | - | Respond-To | opaque | 6-18 | (none) | 304 +-----+---+---+---+---+------------+--------+--------+---------+ 306 Table 2: The Respond-To Option 308 4.4. Leisure-For-Responses Option 310 This new option indicates a number expressed as a uint. It allows 311 the server to send that number of non-traditional response messages 312 in addition to the requested response. They are to be sent without 313 undue delay after the original response. 315 +=====+=+=+=+===+=======================+========+========+=========+ 316 | No. |C|U|N| R | Name | Format | Length | Default | 317 +=====+=+=+=+===+=======================+========+========+=========+ 318 | TBD | |U|-| | Leisure-For-Responses | uint | 1-4 | 0 | 319 +-----+-+-+-+---+-----------------------+--------+--------+---------+ 321 Table 3: The Leisure-For-Responses Option 323 The option is elective, but unsafe for proxies (as the option would 324 otherwise cause multiple responses to a proxy that expects only one 325 and that needs to be a matching response). A proxy that chooses not 326 to implement it may forward the request with the Leisure-For- 327 Responses option removed. 329 On its own, the option does not indicate which kind of additional 330 responses the client would expect (though further elective proxy-safe 331 no-cache-key options can be added on top of that to give better 332 guidance), and the server may choose not to send any at all. 334 Intermediaries may add or remove the option, and use incoming 335 responses to populate their cache. They may serve additional 336 responses from their cache, but in most cases the sensible course of 337 action is to forward the additional responses the origin server 338 sends. 340 Use cases for Leisure-For-Responses include sending further blocks in 341 a Block2 transfer (which are obviously non-matching and thus don't 342 need a Response-For), or serving follow-up documents (a response 343 containing a single link can be followed by a representation of the 344 linked resource, which needs a Request-For header that indicates the 345 URI). 347 5. IANA Considerations 349 This draft adds the following option numbers to the CoAP Option 350 Numbers registry of [RFC7252]: 352 +========+=======================+===========+ 353 | Number | Name | Reference | 354 +========+=======================+===========+ 355 | TBD | Response-For | RFCthis | 356 +--------+-----------------------+-----------+ 357 | TBD | Respond-To | RFCthis | 358 +--------+-----------------------+-----------+ 359 | TBD | Leisure-For-Responses | RFCthis | 360 +--------+-----------------------+-----------+ 362 Table 4: CoAP Option Numbers 364 6. Security Considerations 366 TBD 368 (Clearly, multicast responses pose a potential for amplification, in 369 particular if unverified sources can cause them via Respond-To. 370 Discuss how to mitigate.) 372 A Respond-To option can be used to incite a server to send data to a 373 third party. This ought not be done blindly, i.e., only with 374 considered application assent. 376 The CoAP request/response mechanism allows the client to ascertain a 377 level of authentication (not resistant though to on-path attackers 378 unless the communication is protected) and freshness of the response: 379 The Token echoed in the response shows that the responder had 380 knowledge of the (fresh) request (Section 5.3.1 of [RFC7252]). 381 Responses with embedded requests can not be authenticated or checked 382 for freshness this way. Their content therefore is less trustworthy 383 than normal responses unless authenticated in another way (e.g., via 384 [RFC8613]). 386 7. References 388 7.1. Normative References 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, 392 DOI 10.17487/RFC2119, March 1997, 393 . 395 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 396 Application Protocol (CoAP)", RFC 7252, 397 DOI 10.17487/RFC7252, June 2014, 398 . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 405 "Object Security for Constrained RESTful Environments 406 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 407 . 409 7.2. Informative References 411 [I-D.ietf-core-groupcomm-bis] 412 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 413 for the Constrained Application Protocol (CoAP)", Work in 414 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 415 05, 25 October 2021, . 418 [I-D.tiloca-core-groupcomm-proxy] 419 Tiloca, M. and E. Dijk, "Proxy Operations for CoAP Group 420 Communication", Work in Progress, Internet-Draft, draft- 421 tiloca-core-groupcomm-proxy-05, 25 October 2021, 422 . 425 [I-D.tiloca-core-observe-multicast-notifications] 426 Tiloca, M., Hoeglund, R., Amsuess, C., and F. Palombini, 427 "Observe Notifications as CoAP Multicast Responses", Work 428 in Progress, Internet-Draft, draft-tiloca-core-observe- 429 multicast-notifications-05, 22 February 2021, 430 . 433 [RFC7641] Hartke, K., "Observing Resources in the Constrained 434 Application Protocol (CoAP)", RFC 7641, 435 DOI 10.17487/RFC7641, September 2015, 436 . 438 Appendix A. CoAP extensions explained by non-traditional responses 440 A.1. Observation 442 This section describes the Observe option [RFC7641] in the terms of 443 this document, [ so nothing in here should contradict that document 444 ]. 446 When Observe:0 is present in a request, this sets up non-traditional 447 responses until either of the following conditions is met: 449 * A follow-up request on the same token carries an Observe:1 option. 451 (This is primarily in here because; Observe:1 and No-Response:any 452 could be combined; otherwise, the other conditions suffice). 454 * Any response does not carry an Observe option. 456 * Any response has a non-successful status. 458 Follow-up requests are limited to extending the request ETag set. 459 Responses are obviously non-matching by their Observe option; each 460 hop discards the Observe option for the purpose of caching and 461 refreshes its cache with the most recent one as per the Observe 462 value. 464 A.2. Responses to multicast requests 466 As with observe, this just phrases the existing mechanism in the 467 context of this generalization. 469 When the destination address of a CoAP request is a multicast 470 address, that token is valid for any member of that group (which, for 471 the purpose of the client, is any server at all) on any port. 473 (Except for that the implications of having received a multicast 474 request still need to be followed, it might be seen as a template for 475 creating a phantom request to any endpoint, if that suits the 476 reader's mental model.) 478 Responses can only be sent for up to the deployment's Leisure time 479 (see Section 8.2 of [RFC7252]) plus the application's timeout (in 480 proxy situations, this needs to be communicated explicitly in the 481 Multicast-Signaling option of [I-D.tiloca-core-groupcomm-proxy]). 483 A.3. Triangular responses (Response-To) 485 The Response-To option can be viewed as a shorthand notation for 486 "Consider this a No-Response:any request, but take a copy of it, make 487 it into a CoAP-over-UDP request with that particular address as a 488 source and any address of yours as a response, and treat that as a 489 phantom request". 491 [ It may make sense to add an explicit return token, and include a 492 No-Response option; that might allow it to be used even across 493 proxies. ] 495 A.4. Other current documents 497 [I-D.tiloca-core-observe-multicast-notifications] is a 498 straightforward application of the phantom requests (the concept was 499 developed there); Leisure-For-Responses could help it around the 500 topic of joining a multicast group securely through a proxy. 502 [I-D.tiloca-core-groupcomm-proxy] seems to fit well with the concepts 503 here as well, and might be simplified by it both in terminology and 504 by replacing Response-Forwarding with Response-For(Proxy-Scheme, Uri- 505 Host). 507 Acknowledgements 509 TBD 511 Authors' Addresses 513 Carsten Bormann 514 Universität Bremen TZI 515 Postfach 330440 516 D-28359 Bremen 517 Germany 519 Phone: +49-421-218-63921 520 Email: cabo@tzi.org 521 Christian Amsüss 523 Email: christian@amsuess.com