idnits 2.17.1 draft-amsuess-core-transport-indication-00.txt: -(2): 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 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7252], [RFC8288], [RFC8323]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 231: '... A client MAY use a unique-proxy lik...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 March 2021) is 1141 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsüss 3 Internet-Draft 12 March 2021 4 Intended status: Standards Track 5 Expires: 13 September 2021 7 CoAP Protocol Indication 8 draft-amsuess-core-transport-indication-00 10 Abstract 12 The Constrained Application Protocol (CoAP) is available over 13 different transports (UDP / DTLS since [RFC7252], TCP / TLS / 14 WebSockets since [RFC8323]), but lacks a way to unify these 15 addresses. This document provides terminology based on Web Linking 16 [RFC8288] to express alternative transports available to a device, 17 and to optimize exchanges using these. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Discussion of this document takes place on the Constrained RESTful 24 Environments Working Group mailing list (core@ietf.org), which is 25 archived at https://mailarchive.ietf.org/arch/browse/core/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/git@gitlab.com:chrysn/transport-indication. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 13 September 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Indicating alternative transports . . . . . . . . . . . . . . 4 67 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Elision of Proxy-Scheme and Uri-Host . . . . . . . . . . . . 5 69 4. Third party proxy services . . . . . . . . . . . . . . . . . 6 70 5. Client picked proxies . . . . . . . . . . . . . . . . . . . . 6 71 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 72 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 73 8. Informative References . . . . . . . . . . . . . . . . . . . 7 74 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 [ See Abstract for the moment ] 81 [ This document is being developed at https://gitlab.com/chrysn/ 82 transport-indication (https://gitlab.com/chrysn/transport- 83 indication). ] 85 1.1. Terminology 87 Same-host proxy A CoAP server that accepts forward proxy requests 88 (i.e., requests carrying the Proxy-Scheme option) exclusively for 89 URIs that it is the authoritative server for is defined as a 90 "same-host proxy". 92 hosts The verb "to host" is used here in the sense of the link 93 relation of the same name defined in [RFC6690]. 95 For resources discovered via CoAP's discovery interface, a hosting 96 statement is typically provided by the defaults implied by 97 [RFC6690] where a link like "" is implied to have 98 the relation "hosts" and the anchor "/", such that a statement 99 "coap://hostname hosts coap://hostname/sensor/temp" can be 100 inferred. 102 For many application it can make sense to assume that any resource 103 has a "host" relation leading from the root path of the server 104 without having performed that discovery explicitly. 106 [ TBD: The last paragraph could be a contentuous point; things 107 should still work without it, and maybe that's even better because 108 it precludes a dynamic resource created with one transport from 109 use with another transport unless explicitly cleared. ] 111 When talking of proxy requests, this document only talks of the 112 Proxy-Scheme option. Given that all URIs this is usable with can be 113 expressed in decomposed CoAP URIs, the need for using the Proxy-URI 114 option should never arise. 116 1.2. Goals 118 This document introduces provisions for the seamless use of different 119 transport mechanisms for CoAP. Combined, these provide: 121 * Enablement: Inform clients of the availability of other transports 122 of servers. 124 * No Aliasing: Any URI aliasing must be opt-in by the server. Any 125 defined mechanisms must allow applications to keep working on the 126 canonical URIs given by the server. 128 * Optimization: Do not incur per-request overhead from switching 129 protocls. This may depend on the server's willingness to create 130 aliased URIs. 132 * Proxy usability: All information provided must be usable by aware 133 proxies to reduce the need for duplicate cache entries. 135 * Proxy announcement: Allow third parties to announce that they 136 provide alternative transports to a host. 138 For all these functions, security policies must be described that 139 allow the client to use them as securely as the original transport. 141 This document will not concern itself with changes in transport 142 availability over time, neither in causing them ("Please take up your 143 TCP interface, I'm going to send a firmware update") nor in 144 advertising them (other than by the server putting suitable Max-Age 145 values on any of its statements). 147 2. Indicating alternative transports 149 While CoAP can indicate the authority component of the requested URI 150 in all requests (by means of Uri-Host), indicating the scheme of a 151 requested URI (by means of Proxy-Scheme) makes the request implicitly 152 a proxy request. However, this needs to be of only little practical 153 concern: Any device can serve as a proxy for itself (a "same-host 154 proxy") by accepting requests that carry the Proxy-Scheme option. If 155 it is to be a well-behaved as a proxy, the device should then check 156 whether it recognizes the name indicated in Uri-Host as one of its 157 own [ TBD: Check whether 7252 makes this a stricter requirement ], 158 reject the request with 5.05 when it is not recognized, and otherwise 159 process it as it would process a request coming in on that protocol 160 (which, for many hosts, is the same as if the option were absent 161 completely). 163 A server can indicate support for same-host proxying (or any kind of 164 proxying, really) by serving a Web Link with the "has-proxy" 165 relation. 167 The semantics of a link from C to T with relations has-proxy ("C has- 168 proxy T", ";rel=has-proxy;anchor="C"") are that for any resource R 169 hosted on C ("C hosts R"), T is can be used as a proxy to obtain R. 171 Note that HTTP and CoAP proxies are not located at a particular 172 resource, but at a host in general. Thus, a proxy URI "T" in these 173 protocols can not carry a path or query component. This is true even 174 for CoAP over WebSockets (which uses the concrete resource "/.well- 175 known/coap", but that can not expressed in "coap+ws" URI). Future 176 protocols for which CoAP proxying is defined may have expressible 177 path components. 179 2.1. Example 181 A constrained device at the address 2001:db1::1 that supports CoAP 182 over TCP in addition to CoAP can self-describe like this: 184 ;if="sensor", 185 ;rel=has-proxy;anchor="/" 186 Note that generating this discovery file needs to be dynamic based on 187 its available addresses; only if queried using a link-local source 188 address, it may also respond with a link-local address in the 189 authority component of the proxy URI. 191 Unless the device makes resources discoverable at 192 "coap+tcp://[2001:db1::1]/.well-known/core" or another discovery 193 mechanism, clients may not assume that 194 "coap+tcp://[2001:db1::1]/sensors/temp" is a valid resource (let 195 alone has any relation to the other resource on the same path). The 196 server advertising itself like this may reject any request on CoAP- 197 over-TCP unless they contain a Proxy-Scheme option. 199 Clients that want to access the device using CoAP-over-TCP would send 200 a request by connecting to 2001:db1::1 TCP port 5683 and sending a 201 GET with the options Proxy-Scheme: coap, no Uri-Host or -Port options 202 (utilizing their default values), and the Uri-Paths "sensors" and 203 "temp". 205 3. Elision of Proxy-Scheme and Uri-Host 207 A CoAP server may publish and accept multiple URIs for the same 208 resource, for example when it accepts requests on different IP 209 addresses that do not carry a Uri-Host option, or when it accepts 210 requests both with and without the Uri-Host option carrying a 211 registered name. Likewise, the server may serve the same resources 212 on different transports. This makes for efficient requests (with no 213 Proxy-Scheme or Uri-Host option), but In general is discouraged 214 [aliases]. 216 To make efficient requests possible without creating URI aliases that 217 propagate, the "has-unique-proxy" specialization of the has-proxy 218 relation is defined. 220 If a proxy is unique, it means that it unconditionally forwards to 221 the server indicated in the link context, even if the Proxy-Scheme 222 and Uri-Host options are elided. 224 While this creates URI aliasing in the requests as they are sent over 225 the network, applications that discover a proxy this way should not 226 "think" in terms of these URIs, but retain the originally discovered 227 URIs (which, because Cool URIs Don't Change[cooluris], should be 228 long-term usable). They use the proxy for as long as they have fresh 229 knowledge of the has-(unique-)proxy statement. 231 A client MAY use a unique-proxy like a proxy and still send the 232 Proxy-Scheme and Uri-Host option; such a client needs to recognize 233 both relation types, as relations of the has-unique-proxy type are a 234 specialization of has-proxy and typically don't carry the latter 235 (redundant) annotation. 237 4. Third party proxy services 239 A server that is aware of a suitable cross proxy may use the has- 240 proxy relation to advertise that proxy. This is particularly 241 interesting when the advertisements are made available across 242 transports, for example in a Resource Directory. 244 How the server can discover such a proxy (or, for the rare cases 245 where this is possible, discover that it is suitable as a unique 246 proxy) is out of scope for this document. 248 A third party proxy may advertise its availability to act as a proxy 249 for arbitrary CoAP requests. [ TBD: Specify a mechanism for this; 250 ";rel=has-proxy;anchor="coap://*"" for all 251 supported protocols appears to be an obvious but wrong solution. ] 253 5. Client picked proxies 255 When a resource is accessed through an "actual" proxy (i.e., a host 256 between the client and the server that may also have a same-host 257 proxy), the proxy's choice of the upstream server is originally 258 (i.e., without the mechanisms of this document) either configured (as 259 in a "chain" of proxies) or determined by the request URI (where a 260 proxy picks CoAP over TCP for a request aimed at a coap+tcp URI). 262 A proxy that has learned, by active solicitation of the information 263 or by consulting links in its cache, that the requested URI is 264 available through a same-host proxy, or that has learned of 265 advertised URI aliasings, may can that information. 267 For example, if a host at coap://h1.example.com has advertised 268 ",;rel=has-proxy;anchor="/"", then a 269 proxy that has an active CoAP-over-TCP connection to h1.example.com 270 can forward an incoming request for coap://h1.example.com/res through 271 that CoAP-over-TCP connection with a suitable Proxy-Scheme on that 272 connection. 274 If the host had marked the proxy point as 275 ";rel=has-unique-proxy", then the proxy 276 could elide the Proxy-Scheme and Uri-Host options, and would (from 277 the original CoAP caching rules) also be allowed to use any fresh 278 cache representation of coap+tcp://h1.example.com/res to satisfy 279 requests for coap://h1.example.com/res. 281 6. Security considerations 283 [ TBD; in key words: ] 285 * Always (ie. both with (D)TLS and OSCORE): Risk of attackers 286 redirecting traffic for metadata analysis. 288 Thus, only use transports you've obtained from either the server 289 itself or someone you trust to make routing decisions for you. 291 (If you have no other route, you may not be too picky about where 292 you get your routes from). 294 * Without E2E (ie. (D)TLS): Advertised proxy must either present 295 credentials that are good enough for you to use as a general 296 forward proxy, or present credentials good enough to be the actual 297 origin server (like Alt-Svc does). 299 * TBD: Protecting the indicated proxy (rather than the client) 301 7. IANA considerations 303 [ TBD: Request registration of the defined rel types ] 305 8. Informative References 307 [aliases] W3C, "Architecture of the World Wide Web, Section 2.3.1 308 URI aliases", n.d., 309 . 311 [cooluris] BL, T., "Cool URIs don't change", n.d., 312 . 314 [I-D.silverajan-core-coap-protocol-negotiation] 315 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", 316 Work in Progress, Internet-Draft, draft-silverajan-core- 317 coap-protocol-negotiation-09, 2 July 2018, 318 . 321 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 322 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 323 . 325 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 326 Application Protocol (CoAP)", RFC 7252, 327 DOI 10.17487/RFC7252, June 2014, 328 . 330 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 331 DOI 10.17487/RFC8288, October 2017, 332 . 334 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 335 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 336 Application Protocol) over TCP, TLS, and WebSockets", 337 RFC 8323, DOI 10.17487/RFC8323, February 2018, 338 . 340 Appendix A. Acknowledgements 342 This document heavily builds on concepts explored by Bill Silverajan 343 and Mert Ocak in [I-D.silverajan-core-coap-protocol-negotiation], and 344 together with Ines Robles and Klaus Hartke inside T2TRG. 346 Author's Address 348 Christian Amsüss 349 Hollandstr. 12/4 350 1020 351 Austria 353 Phone: +43-664-9790639 354 Email: christian@amsuess.com