idnits 2.17.1 draft-amsuess-core-transport-indication-01.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(740): 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 7 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 35 characters in excess of 72. ** The abstract seems to contain references ([RFC7252], [RFC8288]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 270: '... is used, the client MUST only use the...' RFC 2119 keyword, line 312: '... Clients MAY switch between advertis...' RFC 2119 keyword, line 390: '... 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 (10 July 2021) is 1019 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-amsuess-core-coap-over-gatt-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsüss 3 Internet-Draft 10 July 2021 4 Intended status: Standards Track 5 Expires: 11 January 2022 7 CoAP Protocol Indication 8 draft-amsuess-core-transport-indication-01 10 Abstract 12 The Constrained Application Protocol (CoAP, [RFC7252]) is available 13 over different transports (UDP, DTLS, TCP, TLS, WebSockets), but 14 lacks a way to unify these addresses. This document provides 15 terminology based on Web Linking [RFC8288] to express alternative 16 transports available to a device, and to optimize exchanges using 17 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://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 11 January 2022. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Indicating alternative transports . . . . . . . . . . . . . . 5 67 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2. Security context propagation . . . . . . . . . . . . . . 7 69 2.3. Choice of transports . . . . . . . . . . . . . . . . . . 7 70 2.4. Selection of a canonical origin . . . . . . . . . . . . . 8 71 2.5. Advertisement through a Resource Directory . . . . . . . 8 72 3. Elision of Proxy-Scheme and Uri-Host . . . . . . . . . . . . 9 73 4. Third party proxy services . . . . . . . . . . . . . . . . . 10 74 4.1. Generic proxy advertisements . . . . . . . . . . . . . . 11 75 5. Client picked proxies . . . . . . . . . . . . . . . . . . . . 11 76 6. Related work and applicability to related fields . . . . . . 12 77 6.1. On HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.2. Using DNS . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.3. Using names outside regular DNS . . . . . . . . . . . . . 13 80 7. Security considerations . . . . . . . . . . . . . . . . . . . 14 81 7.1. Security context propagation . . . . . . . . . . . . . . 14 82 7.2. Traffic misdirection . . . . . . . . . . . . . . . . . . 14 83 7.3. Protecting the proxy . . . . . . . . . . . . . . . . . . 15 84 7.4. Implementing proxies . . . . . . . . . . . . . . . . . . 15 85 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 86 8.1. Link Relation Types . . . . . . . . . . . . . . . . . . . 16 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 9.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18 91 Appendix B. Open Questions / further ideas . . . . . . . . . . . 19 92 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 20 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 The Constrained Application Protocol (CoAP) provides transports 98 mechanisms (UDP and DTLS since [RFC7252], TCP, TLS and WebSockets 99 since [RFC8323]), with some additional being used in LwM2M [lwm2m] 100 and even more being explored ([I-D.bormann-t2trg-slipmux], 101 [I-D.amsuess-core-coap-over-gatt]). These are mutually incompatible 102 on the wire, but CoAP implementations commonly support several of 103 them, and proxies can translate between them. 105 CoAP currently lacks a way to indicate which transports are available 106 for a given resource, and to indicate that a device is prepared to 107 serve as a proxy; this document solves both by introducing the "has- 108 proxy" terminology to Web Linking [RFC8288] that expresses the former 109 through the latter. The additional "has-unique-proxy" term is 110 introduced to negate any per-request overhead that would otherwise be 111 introduced in the course of this. 113 CoAP also lacks a unified scheme to label a resource in a transport- 114 indepenent way. This document does _not_ attempt to introduce any 115 new scheme here, or raise a scheme to be the canonical one. Instead, 116 each host can pick a canonical address for its resources, and 117 advertise other transports in addition. 119 1.1. Terminology 121 Same-host proxy A CoAP server that accepts forward proxy requests 122 (i.e., requests carrying the Proxy-Scheme option) exclusively for 123 URIs that it is the authoritative server for is defined as a 124 "same-host proxy". 126 The distinction between a same-host and any other proxy is only 127 relevant on a practical, server-implementation and illustrative 128 level; this specification does not use the distinction in 129 normative requirements, and clients need not make the distinction 130 at all. 132 hosts The verb "to host" is used here in the sense of the link 133 relation of the same name defined in [RFC6690]. 135 For resources discovered via CoAP's discovery interface, a hosting 136 statement is typically provided by the defaults implied by 137 [RFC6690] where a link like "" is implied to have 138 the relation "hosts" and the anchor "/", such that a statement 139 "coap://hostname hosts coap://hostname/sensor/temp" can be 140 inferred. 142 For many application it can make sense to assume that any resource 143 has a "host" relation leading from the root path of the server 144 without having performed that discovery explicitly. 146 [ TBD: The last paragraph could be a contentuous point; things 147 should still work without it, and maybe that's even better because 148 it precludes a dynamic resource created with one transport from 149 use with another transport unless explicitly cleared. ] 151 When talking of proxy requests, this document only talks of the 152 Proxy-Scheme option. Given that all URIs this is usable with can be 153 expressed in decomposed CoAP URIs, the need for using the Proxy-URI 154 option should never arise. 156 1.2. Goals 158 This document introduces provisions for the seamless use of different 159 transport mechanisms for CoAP. Combined, these provide: 161 * Enablement: Inform clients of the availability of other transports 162 of servers. 164 * No Aliasing: Any URI aliasing must be opt-in by the server. Any 165 defined mechanisms must allow applications to keep working on the 166 canonical URIs given by the server. 168 * Optimization: Do not incur per-request overhead from switching 169 protocls. This may depend on the server's willingness to create 170 aliased URIs. 172 * Proxy usability: All information provided must be usable by aware 173 proxies to reduce the need for duplicate cache entries. 175 * Proxy announcement: Allow third parties to announce that they 176 provide alternative transports to a host. 178 For all these functions, security policies must be described that 179 allow the client to use them as securely as the original transport. 181 This document will not concern itself with changes in transport 182 availability over time, neither in causing them ("Please take up your 183 TCP interface, I'm going to send a firmware update") nor in 184 advertising them (other than by the server putting suitable Max-Age 185 values on any of its statements). 187 2. Indicating alternative transports 189 While CoAP can indicate the authority component of the requested URI 190 in all requests (by means of Uri-Host), indicating the scheme of a 191 requested URI (by means of Proxy-Scheme) makes the request implicitly 192 a proxy request. However, this needs to be of only little practical 193 concern: Any device can serve as a proxy for itself (a "same-host 194 proxy") by accepting requests that carry the Proxy-Scheme option. If 195 it is to be a well-behaved as a proxy, the device should then check 196 whether it recognizes the name indicated in Uri-Host as one of its 197 own [ TBD: Check whether 7252 makes this a stricter requirement ], 198 reject the request with 5.05 when it is not recognized, and otherwise 199 process it as it would process a request coming in on that protocol 200 (which, for many hosts, is the same as if the option were absent 201 completely). 203 A server can indicate support for same-host proxying (or any kind of 204 proxying, really) by serving a Web Link with the "has-proxy" 205 relation. 207 The semantics of a link from C to T with relations has-proxy ("C has- 208 proxy T", ";rel=has-proxy;anchor="C"") are that for any resource R 209 hosted on C ("C hosts R"), T is can be used as a proxy to obtain R. 211 Note that HTTP and CoAP proxies are not located at a particular 212 resource, but at a host in general. Thus, a proxy URI "T" in these 213 protocols can not carry a path or query component. This is true even 214 for CoAP over WebSockets (which uses the concrete resource "/.well- 215 known/coap", but that can not expressed in "coap+ws" URI). Future 216 protocols for which CoAP proxying is defined may have expressible 217 path components. 219 2.1. Example 221 A constrained device at the address 2001:db8::1 that supports CoAP 222 over TCP in addition to CoAP can self-describe like this: 224 Req: to [ff02::fd]:5683 on UDP 225 Code: GET 226 Uri-Path: /.well-known/core 227 Uri-Query: if=tag:example.com,sensor 229 Res: from [2001:db8::1]:5683 230 Content-Format: application/link-format 231 Payload: 232 ;if="tag:example.com,sensor", 233 ;rel=has-proxy;anchor="/" 235 Req: to [2001:db8::1]:5683 on TCP 236 Code: GET 237 Proxy-Scheme: coap 238 Uri-Path: /sensors/temp 239 Observe: 0 241 Res: 2.05 Content 242 Observe: 0 243 Payload: 244 39.1°C 246 Figure 1: Follow-up request through a has-proxy relation 248 Note that generating this discovery file needs to be dynamic based on 249 its available addresses; only if queried using a link-local source 250 address, it may also respond with a link-local address in the 251 authority component of the proxy URI. 253 Unless the device makes resources discoverable at 254 "coap+tcp://[2001:db8::1]/.well-known/core" or another discovery 255 mechanism, clients may not assume that 256 "coap+tcp://[2001:db8::1]/sensors/temp" is a valid resource (let 257 alone has any relation to the other resource on the same path). The 258 server advertising itself like this may reject any request on CoAP- 259 over-TCP unless they contain a Proxy-Scheme option. 261 Clients that want to access the device using CoAP-over-TCP would send 262 a request by connecting to 2001:db8::1 TCP port 5683 and sending a 263 GET with the options Proxy-Scheme: coap, no Uri-Host or -Port options 264 (utilizing their default values), and the Uri-Paths "sensors" and 265 "temp". 267 2.2. Security context propagation 269 If the originally requested URI R or the application requirements 270 demand a security mechanism is used, the client MUST only use the 271 proxy T if the proxy can provide suitable credentials. (The hosting 272 URI C is immaterial to these considerations). 274 Credentials are usable if either: 276 * The credentials are good for the intended use of R. 278 For example, if the application uses the host name and a public 279 key infrastructure and R is "coap://example.com/" the proxy 280 accessed as "coap+tcp://[2001:db8::1]" still needs to provide a 281 certificate chain for the name example.com to one of the system's 282 trust anchors. If, on the other hand, the application is doing a 283 firmware update and requires any certificate from its configured 284 firmware update issuer, the proxy needs to provide such a firmware 285 update certificate. 287 * The credentials are suitable as a general trusted proxy for the 288 system. 290 This applies only to security mechsnisms that are terminated in 291 proxies (i.e. (D)TLS and not OSCORE). 293 For a client to trust a proxy to this extent, it must have 294 configured knowledge which proxies it may trust. Such 295 configuration is generally only possible if the application's 296 security selection is based on the host name (as the client's 297 intention to, as in the above example, obtain a firmware update, 298 can not be transported to the proxy). 300 This option is unlikely to be useful in same-host proxies, but 301 convenient in scenarios like in Section 4. 303 2.3. Choice of transports 305 It is up to the client whether to use an advertised proxy transport, 306 or (if multiple are provided) which to pick. 308 Links to proxies may be annotated with additional metadata that may 309 help guide such a choice; defining such metadata is out of scope for 310 this document. 312 Clients MAY switch between advertised transports as long as the 313 document describing them is fresh; they may even do so per request. 314 (For example, they may perform individual requests using CoAP-over- 315 UDP, but choose CoAP-over-TCP for requests with large expected 316 responses). 318 2.4. Selection of a canonical origin 320 While a server is at liberty to provide the same resource 321 independently on different transports (i.e. to create aliases), it 322 may make sense for it to pick a single scheme and authority under 323 which it announces its resources. Using only one address helps 324 proxies keep their caches efficient, and makes it easier for clients 325 to avoid exploring the same server twice from different angles. 327 When there is a predominant scheme and authority through which an 328 existing service is discovered, it makes sense to use these for the 329 canonical addresses. 331 Otherwise, it is suggested to use the "coap" or "coaps" scheme (given 332 that these are the most basic and widespread ones), and the most 333 stable usable name the host has. 335 2.5. Advertisement through a Resource Directory 337 In the Resource Directory specification 338 [I-D.ietf-core-resource-directory], protocol negotiation was 339 anticipated to use multiple base values. This approach was abandoned 340 since then, as it would incur heavy URI aliasing. 342 Instead, devices can submit their has-proxy links to the Resource 343 Directory like all their other metadata. 345 A client performing resource lookup can ask the RD to provide 346 available (same-host-)proxies in a follow-up request by asking for 347 "?anchor=the-discovered-host&rel=has-proxy". The RD may also 348 volunteer that information during resource lookups even though the 349 has-proxy link itself does not match the search criteria. 351 [ It may be useful to define RD parameters for use with lookup here, 352 which'd guide which available proxies to include. ] 354 3. Elision of Proxy-Scheme and Uri-Host 356 A CoAP server may publish and accept multiple URIs for the same 357 resource, for example when it accepts requests on different IP 358 addresses that do not carry a Uri-Host option, or when it accepts 359 requests both with and without the Uri-Host option carrying a 360 registered name. Likewise, the server may serve the same resources 361 on different transports. This makes for efficient requests (with no 362 Proxy-Scheme or Uri-Host option), but In general is discouraged 363 [aliases]. 365 To make efficient requests possible without creating URI aliases that 366 propagate, the "has-unique-proxy" specialization of the has-proxy 367 relation is defined. 369 If a proxy is unique, it means that it unconditionally forwards to 370 the server indicated in the link context, even if the Proxy-Scheme 371 and Uri-Host options are elided. 373 [ The following two paragraphs are both true but follow different 374 approaches to explaining the observable and implementable behavior; 375 it may later be decided to focus on one or the other in this 376 document. ] 378 While this creates URI aliasing in the requests as they are sent over 379 the network, applications that discover a proxy this way should not 380 "think" in terms of these URIs, but retain the originally discovered 381 URIs (which, because Cool URIs Don't Change[cooluris], should be 382 long-term usable). They use the proxy for as long as they have fresh 383 knowledge of the has-(unique-)proxy statement. 385 In a way, advertising "has-unique-proxy" can be viewed as a 386 description of the link target in terms of SCHC 387 [I-D.ietf-lpwan-coap-static-context-hc]: In requests to that target, 388 the link source's scheme and host are implicitly present. 390 A client MAY use a unique-proxy like a proxy and still send the 391 Proxy-Scheme and Uri-Host option; such a client needs to recognize 392 both relation types, as relations of the has-unique-proxy type are a 393 specialization of has-proxy and typically don't carry the latter 394 (redundant) annotation. [ To be evaluated -- one one hand, supporting 395 it this way means that the server needs to identify all of its 396 addresses and reject others. Then again, is a server that (like many 397 now do) fully ignore any set Uri-Host correct at all? ] 399 Example: 401 Req: to [ff02::fd]:5683 on UDP 402 Code: GET 403 Uri-Path: /.well-known/core 404 Uri-Query: if=tag:example.com,sensor 406 Res: from [2001:db8::1]:5683 407 Content-Format: application/link-format 408 Payload: 409 ;if="tag:example.com,collection", 410 ;rel=has-proxy;anchor="/" 412 Req: to [2001:db8::1]:5683 on TCP 413 Code: GET 414 Uri-Path: /sensors/ 416 Res: 2.05 Content 417 Content-Format: application/link-format 418 Payload: 419 ;if="tag:example.com,sensor" 421 Figure 2: Follow-up request through a has-unique-proxy relation. 422 Compared to the last example, 5 bytes of scheme indication are 423 saved during the follow-up request. 425 It is noteworthy that when the URI reference "/sensors/temperature" 426 is resolved, the base URI is "coap://device0815.example.com" and not 427 its coap+ws counterpart -- as the request is implicitly forwarded 428 there, which both the client and the server are aware of. However, 429 this detail is of little practical importance: A simplistic client 430 that uses "coap+ws://device0815.proxy.rd.example.com" as a base URI 431 will still arrive at an identical follow-up request with no ill 432 effect, as long as it only uses the wrongly assembled URI for 433 dereferencing resources, the security context is the same, and it 434 does not (for example) pass it on to other devices. 436 4. Third party proxy services 438 A server that is aware of a suitable cross proxy may use the has- 439 proxy relation to advertise that proxy. If the protocol used towards 440 the proxy provides name indication (as CoAP over TLS or WebSockets 441 does), or by using a large number of addresses or ports, it can even 442 advertise a (more efficient) has-unique-proxy relation. This is 443 particularly interesting when the advertisements are made available 444 across transports, for example in a Resource Directory. 446 How the server can discover and trust such a proxy is out of scope 447 for this document, but generally involves the same kind of links. 449 The proxy may advertise itself without the origin server's 450 involvement; in that case, the client needs to take additional care 451 (see Section 7.2). 453 Req: GET http://rd.example.com/rd-lookup?if=tag:example.com,sensor 455 Res: 456 Content-Format: application/link-format 457 Payload: 458 ;if="tag:example.com,collection", 459 ;rel=has-unique-proxy;anchor="coap://device0815.example.com/" 461 Req: to device0815.proxy.rd.example.com on WebSocket 462 Host (indicated during upgrade): device0815.proxy.rd.example.com 463 Code: GET 464 Uri-Path: /sensors/ 466 Res: 2.05 Content 467 Content-Format: application/link-format 468 Payload: 469 ;if="tag:example.com,sensor" 471 Figure 3: HTTP based discovery and CoAP-over-WS request to a CoAP 472 resource through a has-unique-proxy relation 474 4.1. Generic proxy advertisements 476 A third party proxy may advertise its availability to act as a proxy 477 for arbitrary CoAP requests. 479 [ TBD: Specify a mechanism for this; ";rel=has- 480 proxy;anchor="coap://*"" for all supported protocols appears to be an 481 obvious but wrong solution. ] 483 The considerations of Section 7.2 apply here. 485 5. Client picked proxies 487 When a resource is accessed through an "actual" proxy (i.e., a host 488 between the client and the server, which itself may have a same-host 489 proxy in addition to that), the proxy's choice of the upstream server 490 is originally (i.e., without the mechanisms of this document) either 491 configured (as in a "chain" of proxies) or determined by the request 492 URI (where a proxy picks CoAP over TCP for a request aimed at a 493 coap+tcp URI). 495 A proxy that has learned, by active solicitation of the information 496 or by consulting links in its cache, that the requested URI is 497 available through a same-host proxy, or that has learned of 498 advertised URI aliasings, may use that information in choosing the 499 upstream transport, and to use responses obtained through one 500 transport to satisfy requests on another. 502 For example, if a host at coap://h1.example.com has advertised 503 ",;rel=has-proxy;anchor="/"", then a 504 proxy that has an active CoAP-over-TCP connection to h1.example.com 505 can forward an incoming request for coap://h1.example.com/res through 506 that CoAP-over-TCP connection with a suitable Proxy-Scheme on that 507 connection. 509 If the host had marked the proxy point as 510 ";rel=has-unique-proxy", then the proxy 511 could elide the Proxy-Scheme and Uri-Host options, and would (from 512 the original CoAP caching rules) also be allowed to use any fresh 513 cache representation of coap+tcp://h1.example.com/res to satisfy 514 requests for coap://h1.example.com/res. 516 6. Related work and applicability to related fields 518 6.1. On HTTP 520 The mechanisms introduced here are similar to the Alt-Svc header of 521 [RFC7838] in that they do not create different application-visible 522 addresses, but provide dispatch through lower transport 523 implementations. 525 Unlike in HTTP, the variations of CoAP protocols each come with their 526 unique URI schemes. Thus, origin URIs can be used without 527 introducing a distrinction between protocol-id and scheme. 529 To accomodate the message size constraints typical of CoRE 530 environments, and accounting for the differences between HTTP headers 531 and CoAP options, information is delivered once at discovery time. 533 Using the has-proxy and has-unique-proxy with HTTP URIs as the 534 context is NOT RECOMMENDED; the HTTP provisions the Alt-Svc header 535 and ALPN are preferred. 537 6.2. Using DNS 539 As pointed out in [RFC7838], DNS can already serve some of the 540 applications of Alt-Svc and has-unique-proxy by providing different 541 CNAME records. These cover cases of multiple addresses, but not 542 different ports or protocols. 544 While not specified for CoAP yet (and neither being specified here), 546 [ which is an open discussion point for CoRE -- should we? Here? In 547 a separte DNS-SD document? ] 549 DNS SRV records (possibly in combination with DNS Service Discovery 550 [RFC6763]) can provide records that could be considered equivalent to 551 has-unique-proxy relations. If "_coap._tcp", "_coaps._tcp", 552 "_coap._udp", "_coap+ws._tcp" etc. were defined with suitable 553 semantics, these can be equivalent: 555 ``` _coap._udp.device.example.com SRV 0 0 device.example.com 61616 556 device.example.com AAAA 2001:db8::1 558 ;rel=has-unique- 559 proxy;anchor="coap://device.example.com" ``` 561 It would be up to such a specification to give details on what the 562 link's context is; unlike the link based discovery of this document, 563 it would either need to pick one distinguished context scheme for 564 which these records are looked up, or would introduce aliasing on its 565 own. 567 6.3. Using names outside regular DNS 569 Names that are resolved through different mechanisms than DNS, or 570 names which are defined within the scope of DNS but have no 571 universally valid answers to A/AAAA requests, can be advertised using 572 the relation types defined here and CoAP discovery. 574 In figure Figure 4, a server using a cryptographic name as described 575 in [I-D.amsuess-t2trg-rdlink] is discovered and used. 577 Req: to [ff02::fd]:5683 on UDP 578 Code: GET 579 Uri-Path: /.well-known/core 580 Uri-Query: rel=has-proxy&anchor=coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa 582 Res: from [2001:db8::1]:5683 583 Content-Format: application/link-format 584 Payload: 585 ;rel=has-unique-proxy;anchor="coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa" 587 Req: to [2001:db8::1]:5683 on TCP 588 Code: GET 589 OSCORE: ... 590 Uri-Path: /sensors/temp 591 Observe: 0 593 Res: 2.05 Content 594 OSCORE: ... 595 Observe: 0 596 Payload: 597 39.1°C 599 Figure 4: Obtaining a sensor value from a local device with a 600 global name 602 7. Security considerations 604 7.1. Security context propagation 606 Clients need to strictly enforce the rules of Section 2.2. Failure 607 to do so, in particular using a thusly announced proxy based on a 608 certificate that attests the proxy's name, would allow attackers to 609 circumvent the client's security expectation. 611 The option to accept credentials suitable for a general trusted proxy 612 is in place for (D)TLS protected scenarios, in which cross-protocol 613 end-to-end protection is not available. Whether a client will 614 recognize certificates for general trusted proxies at all depends on 615 the original proxy setup's security considerations (of [RFC7252] 616 Section 11.2 and [RFC2616] Section 15.7). 618 7.2. Traffic misdirection 620 Accepting arbitrary proxies, even with security context propagation 621 performed properly, would attackers to redirect traffic through 622 systems under their control. Not only does that impact availability, 623 it also allows an attacker to observe traffic patterns. 625 This affects both OSCORE and (D)TLS, as neither protect the 626 participants' network addresses. 628 Other than the security context propagation rules, there are no hard 629 and general rules about when an advertised proxy is a suitable 630 candidate. Aspects for consideration are: 632 * When no direct connection is possible (e.g. because the resource 633 to be accessed is served as coap+tcp and TCP is not implemented in 634 the client, or because the resource's host is available on IPv6 635 while the client has no default IPv6 route), using a proxy is 636 necessary if complete service disruption is to be avoided. 638 While an adversary can cause such a situation (e.g. by 639 manipulating routing or DNS entries), such an adversary is usually 640 already in a position to observe traffic patterns. 642 * A proxy advertised by the device hosting the resource to be 643 accessed is less risky to use than one advertised by a third 644 party. 646 Note that in some applications, servers produce representations 647 based on unverified user input. In such cases, and more so when 648 multiple applications share a security context, the 649 advertisements' provenance may need to be considered. 651 7.3. Protecting the proxy 653 A widely published statement about a host's availability as a proxy 654 can cause many clients to attempt to use it. 656 This is mitigated in well-behaved clients by observing the rate 657 limits of [RFC7252], and by ceasing attempts to reach a proxy for the 658 Max-Age of received errors. 660 Operators can further limit ill-effects by ensuring that their client 661 systems do not needlessly use proxies advertised in an unsecured way, 662 and by providing own proxies when their clients need them. 664 7.4. Implementing proxies 666 Proxies that are trusted (i.e., that terminate (D)TLS connections and 667 have an own server certificate) need to consider the same aspects as 668 clients for their client-side interface as all other clients. 670 Proxies can often process data from different security contexts. 671 When they do, care needs to be taken to not apply has-proxy 672 statements across security contexts. (This consideration is not 673 specific to proxies, but comes up more frequently there). 675 8. IANA considerations 677 8.1. Link Relation Types 679 IANA is asked to add two entries into the Link Relation Type Registry 680 last updated in [RFC8288]: 682 +==================+==================================+===========+ 683 | Relation Name | Description | Reference | 684 +==================+==================================+===========+ 685 | has-proxy | The link target can be used as a | RFCthis | 686 | | proxy to reach the link context. | | 687 +------------------+----------------------------------+-----------+ 688 | has-unique-proxy | Like has-proxy, and using this | RFCthis | 689 | | proxy implies scheme and host of | | 690 | | the target. | | 691 +------------------+----------------------------------+-----------+ 693 Table 1: New Link Relation types 695 9. References 697 9.1. Normative References 699 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 700 Application Protocol (CoAP)", RFC 7252, 701 DOI 10.17487/RFC7252, June 2014, 702 . 704 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 705 DOI 10.17487/RFC8288, October 2017, 706 . 708 9.2. Informative References 710 [aliases] W3C, "Architecture of the World Wide Web, Section 2.3.1 711 URI aliases", n.d., 712 . 714 [cooluris] BL, T., "Cool URIs don't change", n.d., 715 . 717 [I-D.amsuess-core-coap-over-gatt] 718 Amsüss, C., "CoAP over GATT (Bluetooth Low Energy Generic 719 Attributes)", Work in Progress, Internet-Draft, draft- 720 amsuess-core-coap-over-gatt-01, 2 November 2020, 721 . 724 [I-D.amsuess-t2trg-rdlink] 725 Amsüss, C., "rdlink: Robust distributed links to 726 constrained devices", Work in Progress, Internet-Draft, 727 draft-amsuess-t2trg-rdlink-01, 23 September 2019, 728 . 731 [I-D.bormann-t2trg-slipmux] 732 Bormann, C. and T. Kaupat, "Slipmux: Using an UART 733 interface for diagnostics, configuration, and packet 734 transfer", Work in Progress, Internet-Draft, draft- 735 bormann-t2trg-slipmux-03, 4 November 2019, 736 . 739 [I-D.ietf-core-resource-directory] 740 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 741 D. Stok, "CoRE Resource Directory", Work in Progress, 742 Internet-Draft, draft-ietf-core-resource-directory-28, 7 743 March 2021, . 746 [I-D.ietf-lpwan-coap-static-context-hc] 747 Minaburo, A., Toutain, L., and R. Andreasen, "Static 748 Context Header Compression (SCHC) for the Constrained 749 Application Protocol (CoAP)", Work in Progress, Internet- 750 Draft, draft-ietf-lpwan-coap-static-context-hc-19, 8 March 751 2021, . 754 [I-D.silverajan-core-coap-protocol-negotiation] 755 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", 756 Work in Progress, Internet-Draft, draft-silverajan-core- 757 coap-protocol-negotiation-09, 2 July 2018, 758 . 761 [lwm2m] OMA SpecWorks, "White Paper - Lightweight M2M 1.1", n.d., 762 . 765 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 766 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 767 Transfer Protocol -- HTTP/1.1", RFC 2616, 768 DOI 10.17487/RFC2616, June 1999, 769 . 771 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 772 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 773 . 775 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 776 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 777 . 779 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 780 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 781 April 2016, . 783 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 784 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 785 Application Protocol) over TCP, TLS, and WebSockets", 786 RFC 8323, DOI 10.17487/RFC8323, February 2018, 787 . 789 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 790 "Object Security for Constrained RESTful Environments 791 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 792 . 794 Appendix A. Change log 796 Since -00: 798 * Added introduction 800 * Added examples 802 * Added SCHC analogy 804 * Expanded security considerations 806 * Added guidance on choice of transport, and canonical addresses 808 * Added subsection on interaction with a Resource Directory 810 * Added comparisons with related work, including rdlink and DNS-SD 811 sketches 813 * Added IANA considerations 815 * Added section on open questions 817 Appendix B. Open Questions / further ideas 819 * OSCORE interaction: [RFC8613] Section 4.1.3.2 requirements place 820 OSCORE use in a weird category between has-proxy and has-unique- 821 proxy (because if routing still works, the result will be 822 correct). Not sure how to write this down properly, or whether 823 it's actionable at all. 825 Possibly there is an inbetween category of "The host needs the 826 Uri-Host etc. when accessed through CoAP, but because the host 827 does not use the same OSCORE KID across different virtual hosts, 828 it's has-unique-proxy as soon as you talk OSCORE". 830 * Self-uniqueness: 832 A host that wants to indicate that it doesn't care about Uri-Host 833 can probably publish something like ";rel=has-unique-proxy" to 834 do so. 836 This'd help applications justify when they can elide the Uri-Host, 837 even when no different protocols are involved. 839 * Advertising under a stable name: 841 If a host wants to advertise its host name rather than its IP 842 address during multicast, how does it best do that? 844 Options, when answering from 2001:db8::1 to a request to ff02::fd 845 are: 847 ,..., 848 ;rel=has-unique-proxy;anchor="coap://myhostname" 850 which is verbose but formally clear, and 852 ,..., 853 ;rel=has-unique-proxy;anchor="coap://myhostname" 855 which is compatible with unaware clients, but its correctnes with 856 respect to canonical URIs needs to be argued by the client, in 857 this sequence 859 - understanding the has-unique-proxy line, 860 - understanding that the request that went to 2001:db8::1 was 861 really a Proxy-Scheme/Uri-Host-elided version of a request to 862 coap://myhostname, and then 864 - processing any relative reference with this new base in mind. 866 (Not that it'd need to happen in software in that sequence, but 867 that's the sequence needed to understand how the "/foo" here is 868 really "coap://myhostname/foo"). 870 Appendix C. Acknowledgements 872 This document heavily builds on concepts explored by Bill Silverajan 873 and Mert Ocak in [I-D.silverajan-core-coap-protocol-negotiation], and 874 together with Ines Robles and Klaus Hartke inside T2TRG. 876 Author's Address 878 Christian Amsüss 879 Hollandstr. 12/4 880 1020 881 Austria 883 Phone: +43-664-9790639 884 Email: christian@amsuess.com