idnits 2.17.1 draft-bormann-core-responses-00.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 13, 2017) is 2349 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-06 Summary: 0 errors (**), 0 flaws (~~), 2 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 Universitaet Bremen TZI 4 Intended status: Informational November 13, 2017 5 Expires: May 17, 2018 7 CoAP: Non-traditional response forms 8 draft-bormann-core-responses-00 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 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 17, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Response with embedded request . . . . . . . . . . . . . . . 3 56 3. Response for configured request . . . . . . . . . . . . . . . 3 57 3.1. Examples for configured requests . . . . . . . . . . . . 3 58 3.2. Example: Periodic request . . . . . . . . . . . . . . . . 4 59 3.3. Example: Event driven request . . . . . . . . . . . . . . 4 60 3.4. Example: Configured observe . . . . . . . . . . . . . . . 4 61 3.5. Multicast responses . . . . . . . . . . . . . . . . . . . 4 62 3.6. Respond-To option . . . . . . . . . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 In CoAP as defined by RFC 7252, responses are always unicast back to 74 a client that posed a request. A server may want to send a response 75 to a request that it did not receive, may want to multicast a 76 response, or both. 78 The descriptions in this specification are not intended as advocacy 79 for adopting these approaches immediately, they are provided to point 80 out potential avenues for development that would have to be carefully 81 evaluated. 83 1.1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in BCP 88 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 The term "byte" is used in its now customary sense as a synonym for 92 "octet". 94 Terms used in this draft: 96 Configured request: A request that reaches the server in another way 97 than by transmitting a usual CoAP request on the same 98 communication channel a response is expected on. 100 Embedded request: A request that is provided by the server to the 101 recipient of its response by embedding it into the response. 103 2. Response with embedded request 105 A server can send a response to a request that it did not actually 106 receive by embedding the request which the response answers in the 107 response. 109 The option "Response-For" contains a request packaged as in 110 Section 5.2 of [I-D.ietf-core-object-security]. The response is then 111 intended to serve as a response to this request. 113 +-----+---+---+---+---+--------------+--------+--------+---------+ 114 | No. | C | U | N | R | Name | Format | Length | Default | 115 +-----+---+---+---+---+--------------+--------+--------+---------+ 116 | TBD | C | - | - | - | Response-For | opaque | 0-1023 | (none) | 117 +-----+---+---+---+---+--------------+--------+--------+---------+ 119 Table 1: The Response-For Option 121 The CoAP Token becomes meaningless for this form of response; 122 responses with embedded requests are therefore sent with an zero- 123 length Token. (In essence, the "Response-For" option takes the place 124 of the request the Token usually stands for.) 126 The congestion control considerations for confirmable and non- 127 confirmable messages apply unchanged. 129 3. Response for configured request 131 A request may reach the server using a different means than that used 132 for the response. For instance, the request may be configured in the 133 server. Without limiting generality, we speak about _configured 134 requests_. 136 The client MUST be cognizant of that configuration as the request 137 uses a token from the token name space it controls. 139 3.1. Examples for configured requests 140 3.2. Example: Periodic request 142 A server may be configured to act on a configured request every day 143 at 12:00. 145 3.3. Example: Event driven request 147 A server may be configured to act on a configured request each time 148 it reboots. 150 3.4. Example: Configured observe 152 A server may be configured with a GET request from a client that 153 includes an Observe option with value 0. This means that the server 154 will send updates to the state of the resource addressed by the GET 155 request to the configured address of the client. 157 The considerations of Section 4.5 of [RFC7641] apply. How losing 158 interest reflects back into to configuration and whether there is 159 some form of error notification to the source of the configuration is 160 out of scope of the present specification. 162 3.5. Multicast responses 164 A server MAY send a response to a multicast address. (This needs to 165 be a response to a configured request as a normal request cannot be 166 sent _from_ a multicast address.) 168 Note that, as the originator of a multicast response is a unicast 169 address, the relaxation of matching rules described in Section 8.2 of 170 [RFC7252] does not apply. 172 The token space in CoAP is owned by the client, which is identified 173 by a transport endpoint (address/port). Here, the address is a 174 multicast address, so the token name space is shared by all nodes 175 joined to that multicast address. The assumption for multicast 176 responses is that, for each multicast group, there is some form of 177 management for the token space (and the port number) that everyone 178 can participate that needs to join that multicast group; the specific 179 form of management is out of the scope of this specification. Note 180 that this means that multicast responses MUST NOT be sent to 181 unmanaged multicast addresses such as All Coap Nodes (Section 12.8 of 182 [RFC7252]). 184 Multicast responses are always non-confirmable. The congestion 185 control considerations for non-confirmable multicast messages apply 186 unchanged. 188 3.6. Respond-To option 190 What has been called "configured request" here may also be triggered 191 by a usual CoAP request that carries the Respond-To option. (The 192 term "configured request" is still appropriate as the server ought to 193 be configured to accept this option; see Section 5.) 195 If a single client wants to request a server to send the response to 196 a specific multicast address, it can include the "Respond-To" option. 197 This contains an opaque string with the port number as a 16-bit 198 number (in network byte order), followed by the IP address (4-byte 199 IPv4 or 16-byte IPv6). 201 +-----+---+---+---+---+------------+--------+--------+---------+ 202 | No. | C | U | N | R | Name | Format | Length | Default | 203 +-----+---+---+---+---+------------+--------+--------+---------+ 204 | TBD | C | U | - | - | Respond-To | opaque | 6-18 | (none) | 205 +-----+---+---+---+---+------------+--------+--------+---------+ 207 4. IANA Considerations 209 This draft adds the following option numbers to the CoAP Option 210 Numbers registry of [RFC7252]: 212 +--------+--------------+-----------+ 213 | Number | Name | Reference | 214 +--------+--------------+-----------+ 215 | TBD | Response-For | RFCthis | 216 | TBD | Respond-To | RFCthis | 217 +--------+--------------+-----------+ 219 Table 2: CoAP Option Numbers 221 5. Security Considerations 223 TBD 225 (Clearly, multicast responses pose a potential for amplification, in 226 particular if unverified sources can cause them via Respond-To. 227 Discuss how to mitigate.) 229 A Respond-To option can be used to incite a server to send data to a 230 third party. This ought not be done blindly, i.e., only with 231 considered application assent. 233 The CoAP request/response mechanism allows the client to ascertain a 234 level of authentication (not resistant though to on-path attackers 235 unless the communication is protected) and freshness of the response: 237 The Token echoed in the response shows that the responder had 238 knowledge of the (fresh) request (Section 5.3.1 of [RFC7252]). 239 Responses with embedded requests can not be authenticated or checked 240 for freshness this way. Their content therefore is less trustworthy 241 than normal responses unless authenticated in another way (e.g., via 242 [I-D.ietf-core-object-security]). 244 6. References 246 6.1. Normative References 248 [I-D.ietf-core-object-security] 249 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 250 "Object Security for Constrained RESTful Environments 251 (OSCORE)", draft-ietf-core-object-security-06 (work in 252 progress), October 2017. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 260 Application Protocol (CoAP)", RFC 7252, 261 DOI 10.17487/RFC7252, June 2014, 262 . 264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 266 May 2017, . 268 6.2. Informative References 270 [RFC7641] Hartke, K., "Observing Resources in the Constrained 271 Application Protocol (CoAP)", RFC 7641, 272 DOI 10.17487/RFC7641, September 2015, 273 . 275 Acknowledgements 277 TBD 279 Author's Address 280 Carsten Bormann 281 Universitaet Bremen TZI 282 Postfach 330440 283 Bremen D-28359 284 Germany 286 Phone: +49-421-218-63921 287 Email: cabo@tzi.org