idnits 2.17.00 (12 Aug 2021)
/tmp/idnits30540/draft-amsuess-core-transport-indication-03.txt:
-(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(853): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(881): 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 9 instances of lines with non-ascii characters in the document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 3 instances of too long lines in the document, the longest one
being 33 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 336: '... is used, the client MUST only use the...'
RFC 2119 keyword, line 368: '... Clients MAY switch between advertis...'
RFC 2119 keyword, line 460: '... A client MAY use a unique-proxy lik...'
RFC 2119 keyword, line 1090: '...ddress of the used one, the client MAY...'
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (3 March 2022) is 72 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-10) exists of
draft-ietf-core-href-09
== Outdated reference: draft-ietf-core-resource-directory has been
published as RFC 9176
== Outdated reference: draft-ietf-lpwan-coap-static-context-hc has been
published as RFC 8824
== Outdated reference: A later version (-02) exists of
draft-tiloca-core-oscore-capable-proxies-01
Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 CoRE C. Amsüss
3 Internet-Draft 3 March 2022
4 Intended status: Standards Track
5 Expires: 4 September 2022
7 CoAP Protocol Indication
8 draft-amsuess-core-transport-indication-03
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 and provisions based on Web Linking [RFC8288] to express
16 alternative transports available to a device, and to optimize
17 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://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 4 September 2022.
47 Copyright Notice
49 Copyright (c) 2022 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 Revised BSD License text as
58 described in Section 4.e of the Trust Legal Provisions and are
59 provided without warranty as described in the Revised BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
65 1.1.1. Using URIs to identify protocol endpoints . . . . . . 4
66 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
67 2. Indicating alternative transports . . . . . . . . . . . . . . 6
68 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
69 2.2. Security context propagation . . . . . . . . . . . . . . 8
70 2.3. Choice of transports . . . . . . . . . . . . . . . . . . 8
71 2.4. Selection of a canonical origin . . . . . . . . . . . . . 9
72 2.5. Advertisement through a Resource Directory . . . . . . . 9
73 3. Elision of Proxy-Scheme and Uri-Host . . . . . . . . . . . . 9
74 3.1. Impact on caches . . . . . . . . . . . . . . . . . . . . 11
75 3.2. Using unique proxies securely . . . . . . . . . . . . . . 12
76 4. Third party proxy services . . . . . . . . . . . . . . . . . 13
77 4.1. Generic proxy advertisements . . . . . . . . . . . . . . 14
78 5. Client picked proxies . . . . . . . . . . . . . . . . . . . . 15
79 6. Security considerations . . . . . . . . . . . . . . . . . . . 16
80 6.1. Security context propagation . . . . . . . . . . . . . . 16
81 6.2. Traffic misdirection . . . . . . . . . . . . . . . . . . 16
82 6.3. Protecting the proxy . . . . . . . . . . . . . . . . . . 17
83 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
84 7.1. Link Relation Types . . . . . . . . . . . . . . . . . . . 17
85 7.2. Resource Types . . . . . . . . . . . . . . . . . . . . . 17
86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
87 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
88 8.2. Informative References . . . . . . . . . . . . . . . . . 18
89 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20
90 Appendix B. Related work and applicability to related fields . . 21
91 B.1. On HTTP . . . . . . . . . . . . . . . . . . . . . . . . . 22
92 B.2. Using DNS . . . . . . . . . . . . . . . . . . . . . . . . 22
93 B.3. Using names outside regular DNS . . . . . . . . . . . . . 23
94 B.4. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 23
96 Appendix C. Open Questions / further ideas . . . . . . . . . . . 24
97 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 25
98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
100 1. Introduction
102 The Constrained Application Protocol (CoAP) provides transports
103 mechanisms (UDP and DTLS since [RFC7252], TCP, TLS and WebSockets
104 since [RFC8323]), with some additional being used in LwM2M [lwm2m]
105 and even more being explored ([I-D.bormann-t2trg-slipmux],
106 [I-D.amsuess-core-coap-over-gatt]). These are mutually incompatible
107 on the wire, but CoAP implementations commonly support several of
108 them, and proxies can translate between them.
110 CoAP currently lacks a way to indicate which transports are available
111 for a given resource, and to indicate that a device is prepared to
112 serve as a proxy; this document solves both by introducing the "has-
113 proxy" terminology to Web Linking [RFC8288] that expresses the former
114 through the latter. The additional "has-unique-proxy" term is
115 introduced to negate any per-request overhead that would otherwise be
116 introduced in the course of this.
118 CoAP also lacks a unified scheme to label a resource in a transport-
119 independent way. This document does _not_ attempt to introduce any
120 new scheme here, or raise a scheme to be the canonical one. Instead,
121 each host or application can pick a canonical address for its
122 resources, and advertise other transports in addition.
124 1.1. Terminology
126 Readers are expected to be familiar with the terms and concepts
127 described in CoAP [RFC7252] and link format ([RFC6690] (or,
128 equivalently, web links as described in [RFC8288]).
130 Same-host proxy: A CoAP server that accepts forward proxy requests
131 (i.e., requests carrying the Proxy-Scheme option) exclusively for
132 URIs that it is also the authoritative server for is defined as a
133 "same-host proxy".
135 The distinction between a same-host and any other proxy is only
136 relevant on a practical, server-implementation and illustrative
137 level; this specification does not use the distinction in
138 normative requirements, and clients need not make the distinction
139 at all.
141 hosts: The verb "to host" is used here in the sense of the link
142 relation of the same name defined in [RFC6690].
144 For resources discovered via CoAP's discovery interface, a hosting
145 statement is typically provided by the defaults implied by
146 [RFC6690] where a link like is implied to have the
147 relation "hosts" and the anchor /, such that a statement
148 "coap://hostname hosts coap://hostname/sensor/temp" is implied in
149 the link.
151 The link relation has been occasionally used with different
152 interpretations, which ascribe more meaning to the term than it
153 has in its definition. In particular,
155 * the "hosts" relation can not be inferred merely by two URIs
156 having the same scheme, host and port (and vice versa), and
158 * the "hosts" relation on its own does not make any statement
159 about the physical devices that hold the resource's
160 representation.
162 [ TBD: The former could probably still be used without too many
163 ill effects; but things might also get weird when a dynamic
164 resource created with one transport from use with another
165 transport unless explicitly cleared. ]
167 When talking of proxy requests, this document only talks of the
168 Proxy-Scheme option. Given that all URIs this is usable with can be
169 expressed in decomposed CoAP URIs, the need for using the Proxy-URI
170 option should never arise. The Proxy-URI option is still equivalent
171 to the decomposed options, and can be used if the server supports it.
173 1.1.1. Using URIs to identify protocol endpoints
175 The URI coap://device.example.com identifies a particular resource,
176 possibly a "welcome" text. It is, colloquially, also used to
177 identify the combination of a host (identified through a name), the
178 default port, and the CoAP method of sending requests to the host.
180 For precision, this document uses the term "the transport address
181 indicated by (a URI)" to refer to the host / port / protocol
182 combination, but otherwise no big deal is made of it.
184 For the CoAP schemes (coap, coaps, coap+tcp, coaps+tcp, coap+ws,
185 coaps+ws), URIs indicating a transport are always given with an empty
186 path (which under their URI normalization rules is equivalent to a
187 path containing a single slash). For the coap and coap+tcp schemes,
188 URIs with different host names can indicate the same transport as
189 long as the names resolve to the same addresses. For the other
190 protocols, the given host name informs the name set in TLS's Server
191 Name Indication (SNI) and/or the host sent in the "Host" header of
192 the underlying HTTP request.
194 If an update to this document extends the list, for new schemes it
195 might be allowed to have paths, queries or fragment identifiers
196 present in the URI indicating the transport address. No guidance can
197 be given here for these, as no realistic example is known. (Note
198 that while the coap+ws scheme does use the well-known path /.well-
199 known/coap internally, that is used purely on the HTTP side, and not
200 part of the CoAP URI, not even for indicating the transport address).
202 URIs indicating a transport are especially useful when talking about
203 proxies; this use is aligned with the way they are exprssed in the
204 conventional environment variables http_proxy etc. [ cite
205 https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/ ].
206 Furthermore, URIs processing is widespread in CoAP systems, and when
207 that changes (e.g. through the introduction of [I-D.ietf-core-href]),
208 URIs indicating a transport will still be efficient to encode. And
209 last but not least, it lines up well with the colloquial identity
210 mentioned above. (An alternative would be using a dedicated naming
211 scheme, say, transport:coap:device.example.com:port, but that would
212 needlessly introduce implementation complexity).
214 Note that this mechanism can only used with proxies that use CoAP's
215 native address indication mechanisms. Proxies that perform URI
216 mapping (as described in Section 5 of [RFC8075], especially using URI
217 templates) are not supported in this document.
219 [ TBD: Do we want to extend this to HTTP proxies? Probably just not,
220 and if so, only to those that can just take coap://... for a URI. ]
222 1.2. Goals
224 This document introduces provisions for the seamless use of different
225 transport mechanisms for CoAP. Combined, these provide:
227 * Enablement: Inform clients of the availability of other transports
228 of servers.
230 * No Aliasing: Any URI aliasing must be opt-in by the server. Any
231 defined mechanisms must allow applications to keep working on the
232 canonical URIs given by the server.
234 * Optimization: Do not incur per-request overhead from switching
235 protocols. This may depend on the server's willingness to create
236 aliased URIs.
238 * Proxy usability: All information provided must be usable by aware
239 proxies to reduce the need for duplicate cache entries.
241 * Proxy announcement: Allow third parties to announce that they
242 provide alternative transports to a host.
244 For all these functions, security policies must be described that
245 allow the client to use them as securely as the original transport.
247 This document will not concern itself with changes in transport
248 availability over time, neither in causing them ("Please take up your
249 TCP interface, I'm going to send a firmware update") nor in
250 advertising their availability in advance. Hosts whose transport's
251 availability changes over time can utilize any suitable mechanism to
252 keep client updated, such as placing a suitable Max-Age value on
253 their resources or having them observable.
255 2. Indicating alternative transports
257 While CoAP can set the authority component of the requested URI in
258 all requests (by means of Uri-Host and Uri-Port), setting the scheme
259 of a requested URI (by means of Proxy-Scheme) makes the request
260 implicitly a proxy request. However, this needs to be of only little
261 practical concern: Any device can serve as a proxy for itself (a
262 "same-host proxy") by accepting requests that carry the Proxy-Scheme
263 option. If it is to be a well-behaved proxy, the device should then
264 check whether it recognizes the name set in Uri-Host as one of its
265 own (as it should if no Proxy-Scheme option accompanied it). If the
266 name is not recognized, it should reject the request with 5.05
267 (Proxying Not Supported) -- unless, of course, it implements forward
268 proxy functionality exceeding the same-host proxy. If the name is
269 recognized, it should process the request as it would process a
270 request coming in on the given protocol (which, for many hosts, is
271 the same as if the option were absent completely).
273 A server can advertise a recommended proxy by serving a Web Link with
274 the "has-proxy" relation to a URI indicating its transport address.
275 In particular (and that is a typical case), it can indicate its own
276 transport address on an alternative transport when implementing same-
277 host proxy functionality.
279 The semantics of a link from S to P with relations has-proxy ("S has-
280 proxy P",
;rel=has-proxy;anchor="S") are that for any resource R
281 hosted on S ("S hosts R"), the proxy with the transport address
282 indicated by P can be used to obtain R.
284 2.1. Example
286 A constrained device at the address 2001:db8::1 that supports CoAP
287 over TCP in addition to CoAP can self-describe like this:
289 Req: to [ff02::fd]:5683 on UDP
290 Code: GET
291 Uri-Path: /.well-known/core
292 Uri-Query: if=tag:example.com,sensor
294 Res: from [2001:db8::1]:5683
295 Content-Format: application/link-format
296 Payload:
297 ;if="tag:example.com,sensor",
298 ;rel=has-proxy;anchor="/"
300 Req: to [2001:db8::1]:5683 on TCP
301 Code: GET
302 Proxy-Scheme: coap
303 Uri-Path: /sensors/temp
304 Observe: 0
306 Res: 2.05 Content
307 Observe: 0
308 Payload:
309 39.1°C
311 Figure 1: Discovery and follow-up request through a has-proxy
312 relation
314 Note that generating this discovery file needs to be dynamic based on
315 its available addresses; only if queried using a link-local source
316 address, the server may also respond with a link-local address in the
317 authority component of the proxy URI.
319 Unless the device makes resources discoverable at
320 coap+tcp://[2001:db8::1]/.well-known/core or another discovery
321 mechanism, clients may not assume that
322 coap+tcp://[2001:db8::1]/sensors/temp is a valid resource (let alone
323 is equivalent to the other resource on the same path). The server
324 advertising itself like this may reject any request on CoAP-over-TCP
325 unless it contains a Proxy-Scheme option.
327 Clients that want to access the device using CoAP-over-TCP would send
328 a request by connecting to 2001:db8::1 TCP port 5683 and sending a
329 GET with the options Proxy-Scheme: coap, no Uri-Host or -Port options
330 (utilizing their default values), and the Uri-Paths "sensors" and
331 "temp".
333 2.2. Security context propagation
335 If the originally requested URI R or the application requirements
336 demand a security mechanism is used, the client MUST only use the
337 proxy P if the proxy can provide suitable credentials. (The hosting
338 URI S is immaterial to these considerations).
340 For example, if the application uses the host name and a public key
341 infrastructure and R is coap://example.com/ the proxy accessed as
342 coap+tcp://[2001:db8::1] still needs to provide a certificate chain
343 for the name example.com to one of the system's trust anchors. If,
344 on the other hand, the application is doing a firmware update and
345 requires any certificate from its configured firmware update issuer,
346 the proxy needs to provide such a firmware update certificate.
348 Some applications have requirements exceeding the requirements of a
349 secure connection, e.g., (explicitly or implicitly) requiring that
350 name resolution happen through a secure process and packets are only
351 routed into networks where it trusts that they will not be
352 intercepted on the path to the server. Such applications need to
353 extend their requirements to the source of the has-proxy statement; a
354 sufficient (but maybe needlessly strict) requirement is to only
355 follow has-proxy statements that are part of the same resource that
356 advertises the link currently being followed. Section Section 6.2
357 adds further considerations.
359 2.3. Choice of transports
361 It is up to the client whether to use an advertised proxy transport,
362 or (if multiple are provided) which to pick.
364 Links to proxies may be annotated with additional metadata that may
365 help guide such a choice; defining such metadata is out of scope for
366 this document.
368 Clients MAY switch between advertised transports as long as the
369 document describing them is fresh; they may even do so per request.
370 (For example, they may perform individual requests using CoAP-over-
371 UDP, but choose CoAP-over-TCP for requests with large expected
372 responses). When the describing document approaches expiry, the
373 client can use the representation's ETag to efficiently renew its
374 justification for using the alternative transport.
376 2.4. Selection of a canonical origin
378 While a server is at liberty to provide the same resource
379 independently on different transports (i.e. to create aliases), it
380 may make sense for it to pick a single scheme and authority under
381 which it announces its resources. Using only one address helps
382 proxies keep their caches efficient, and makes it easier for clients
383 to avoid exploring the same server twice from different angles.
385 When there is a predominant scheme and authority through which an
386 existing service is discovered, it makes sense to use these for the
387 canonical addresses.
389 Otherwise, it is suggested to use the coap or coaps scheme (given
390 that these are the most basic and widespread ones), and the most
391 stable usable name the host has.
393 2.5. Advertisement through a Resource Directory
395 In the Resource Directory specification
396 [I-D.ietf-core-resource-directory], protocol negotiation was
397 anticipated to use multiple base values. This approach was abandoned
398 since then, as it would incur heavy URI aliasing.
400 Instead, devices can submit their has-proxy links to the Resource
401 Directory like all their other metadata.
403 A client performing resource lookup can ask the RD to provide
404 available (same-host-)proxies in a follow-up request by asking for
405 ?anchor=&rel=has-proxy. The RD may also
406 volunteer that information during resource lookups even though the
407 has-proxy link itself does not match the search criteria.
409 [ It may be useful to define RD parameters for use with lookup here,
410 which'd guide which available proxies to include. For example,
411 asking ?if=tag:example.com,sensor&proxy-links=tcp could give as a
412 result: ;rt=tag:example.com,sensor,;rel=has-proxy;anchor="coap://[2001:db8::1]/" ]
415 3. Elision of Proxy-Scheme and Uri-Host
417 A CoAP server may publish and accept multiple URIs for the same
418 resource, for example when it accepts requests on different IP
419 addresses that do not carry a Uri-Host option, or when it accepts
420 requests both with and without the Uri-Host option carrying a
421 registered name. Likewise, the server may serve the same resources
422 on different transports. This makes for efficient requests (with no
423 Proxy-Scheme or Uri-Host option), but in general is discouraged
425 [aliases].
427 To make efficient requests possible without creating URI aliases that
428 propagate, the "has-unique-proxy" specialization of the has-proxy
429 relation is defined.
431 If a proxy is unique, it means that requests arriving at the proxy
432 are treated the same no matter whether the scheme, authority and port
433 of the link context are set in the Proxy-Scheme, Uri-Host and Uri-
434 Port options, respectively, or whether all of them are absent.
436 [ The following two paragraphs are both true but follow different
437 approaches to explaining the observable and implementable behavior;
438 it may later be decided to focus on one or the other in this
439 document. ]
441 While this creates URI aliasing in the requests as they are sent over
442 the network, applications that discover a proxy this way should not
443 "think" in terms of these URIs, but retain the originally discovered
444 URIs (which, because Cool URIs Don't Change[cooluris], should be
445 long-term usable). They use the proxy for as long as they have fresh
446 knowledge of the has-(unique-)proxy statement.
448 In a way, advertising has-unique-proxy can be viewed as a description
449 of the link target in terms of SCHC
450 [I-D.ietf-lpwan-coap-static-context-hc]: In requests to that target,
451 the link source's scheme and host are implicitly present.
453 While applications retain knowledge of the originally requested URI
454 (even if it is not expressed in full on the wire), the original URI
455 is not accessible to caches both within the host and on the network
456 (for the latter, see Section 5). Thus, cached responses to the
457 canonical and any aliased URI are mutually interchangeable as long as
458 both the response and the proxy statement are fresh.
460 A client MAY use a unique-proxy like a proxy and still send the
461 Proxy-Scheme and Uri-Host option; such a client needs to recognize
462 both relation types, as relations of the has-unique-proxy type are a
463 specialization of has-proxy and typically don't carry the latter
464 (redundant) annotation. [ To be evaluated -- on one hand, supporting
465 it this way means that the server needs to identify all of its
466 addresses and reject others. Then again, is a server that (like many
467 now do) fully ignore any set Uri-Host correct at all? ]
469 Example:
471 Req: to [ff02::fd]:5683 on UDP
472 Code: GET
473 Uri-Path: /.well-known/core
474 Uri-Query: if=tag:example.com,sensor
476 Res: from [2001:db8::1]:5683
477 Content-Format: application/link-format
478 Payload:
479 ;if="tag:example.com,collection",
480 ;rel=has-unique-proxy;anchor="/"
482 Req: to [2001:db8::1] via WebSockets over HTTPS
483 Code: GET
484 Uri-Path: /sensors/
486 Res: 2.05 Content
487 Content-Format: application/link-format
488 Payload:
489 ;if="tag:example.com,sensor"
491 Figure 2: Follow-up request through a has-unique-proxy relation.
492 Compared to the last example, 5 bytes of scheme indication are
493 saved during the follow-up request.
495 It is noteworthy that when the URI reference /sensors/temperature is
496 resolved, the base URI is coap://device0815.example.com and not its
497 coaps+ws counterpart -- as the request is still for that URI, which
498 both the client and the server are aware of. However, this detail is
499 of little practical importance: A simplistic client that uses
500 coaps+ws://device0815.proxy.rd.example.com as a base URI will still
501 arrive at an identical follow-up request with no ill effect, as long
502 as it only uses the wrongly assembled URI for dereferencing
503 resources, the security context is the same, the state is kept no
504 longer than the has-unique-proxy statement is fresh, and it does not
505 (for example) pass the URI on to other devices.
507 3.1. Impact on caches
509 [ This section is written with the "there is implied URI aliasing"
510 mindset; it should be possible to write it with the "compression"
511 mindset as well (but there is no point in having both around in the
512 document at this time).
514 It is also slightly duplicating, but also more detailed than, the
515 brief note on the topic in Section 5 ]
516 When a node that performs caching learns of a has-unique-proxy
517 statement, it can utilize the information about the implied URI
518 aliasing: Requests to resources hosted by S can be answered with
519 cached entries from P (because by the rules of has-unique-proxy a
520 request can be crafted that is sent to P for which a fresh response
521 is available). The inverse direction (serving resources whose URI
522 "starts with" P from a cached request that was sent to S) is harder
523 to serve because it additionaly requires a fresh statement that "S
524 hosts R" for the matching resource R.
526 3.2. Using unique proxies securely
528 [ This section is work in progress, it is more a flow of
529 considerations turning back on each other. This is all made a bit
530 trickier by not applying to OSCORE which is usually the author's go-
531 to example, because OSCORE's requirements already preclude all these
532 troubles. ]
534 The use of unique proxies requires slightly more care in terms of
535 security.
537 No requirements are necessary on the client side; those of {#secctx-
538 propagation} suffice. (In particular, it is not necessary for the
539 statement to originate from the original server unless that were
540 already a requirement without the uniqueness property).
542 The extra care is necessary on the side of servers that are
543 commissioned with wide ranging authorization [ or is it? ]: These may
544 now be tricked into serving a resource of which the client assumes a
545 different name. For example, if the desired resource is
546 coaps://high-security.example.org/configuration, and there exists a
547 "home page" style service for employees with patterns of
548 coaps+tcp://user-${username}.example.org/ at which they can store
549 files, and the server operating that service is commissioned with a
550 wild-card certificate "*.example.org", then a device that receives
551 the (malicious) information ;rel=has-unique-proxy;anchor="coaps://high-
553 security.example.org" might use this statement to contact the
554 transport address indicated by coaps+tcp://user-mave.example.org and
555 ask for /config (which, to the server, is indistinguishable from
556 coaps+tcp://user-mave.example.org/config) and obtain a malicious
557 configuration.
559 In a non-unique proxy situation, the error would have been caught by
560 the server, which would have seen the request for coaps://high-
561 security.example.com and refused to serve a request containing
562 critical options it can not adaequately process.
564 In the unique proxy situation, ... [ TBD: now whose fault is it? Can
565 only be the client's ... because it looked at the wildcard
566 certificate rather than whether the host-name it was narrowing it
567 down to is authorized to speak for high-security.example.com? The
568 server (operator) can barely be blamed, for while the certificate is
569 needlessly wide, to the server it did look precisely like a good
570 request. ]
572 4. Third party proxy services
574 A server that is aware of a suitable cross proxy may use the has-
575 proxy relation to advertise that proxy. If the protocol used towards
576 the proxy provides name indication (as CoAP over TLS or WebSockets
577 does), or by using a large number of addresses or ports, it can even
578 advertise a (more efficient) has-unique-proxy relation. This is
579 particularly interesting when the advertisements are made available
580 across transports, for example in a Resource Directory.
582 How the server can discover and trust such a proxy is out of scope
583 for this document, but generally involves the same kind of links. In
584 particular, a server may obtain a link to a third party proxy from an
585 administrator as part of its configuration.
587 The proxy may advertise itself without the origin server's
588 involvement; in that case, the client needs to take additional care
589 (see Section 6.2).
591 Req: GET http://rd.example.com/rd-lookup?if=tag:example.com,sensor
593 Res:
594 Content-Format: application/link-format
595 Payload:
596 ;if="tag:example.com,collection",
597 ;rel=has-unique-proxy;anchor="coap://device0815.example.com/"
599 Req: to device0815.proxy.rd.example.com on WebSocket
600 Host (indicated during upgrade): device0815.proxy.rd.example.com
601 Code: GET
602 Uri-Path: /sensors/
604 Res: 2.05 Content
605 Content-Format: application/link-format
606 Payload:
607 ;if="tag:example.com,sensor"
609 Figure 3: HTTP based discovery and CoAP-over-WS request to a CoAP
610 resource through a has-unique-proxy relation
612 4.1. Generic proxy advertisements
614 A third party proxy may advertise its availability to act as a proxy
615 for arbitrary CoAP requests. This use is not directly related to the
616 protocol indication in other parts of this document, but sufficiently
617 similar to warrant being described in the same document.
619 The resource type "TBDcore.proxy" can be used to describe such a
620 proxy. The link target attribute "proxy-schemes" can be used to
621 indicate the scheme(s) supported by the proxy, separated by the space
622 character.
624 Req: GET coap://[fe80::1]/.well-known/core?rt=TBDcore.proxy
626 Res:
627 Content-Format: application/link-format
628 Payload:
629 <>;rt=TBDcore.proxy;proxy-schemes="coap coap+tcp coap+ws http"
631 Req: to [fe80::1] via CoAP
632 Code: GET
633 Proxy-Scheme: http
634 Uri-Host: example.com
635 Uri-Path: /motd
636 Accept: text/plain
638 Res: 2.05 Content
639 Content-Format: text/plain
640 Payload:
641 On Monday, October 25th 2021, there is no special message of the day.
643 Figure 4: A CoAP client discovers that its border router can also
644 serve as a proxy, and uses that to access a resource on an HTTP
645 server.
647 The considerations of Section 6.2 apply here.
649 A generic advertised proxy is always a forward proxy, and can not be
650 advertised as a "unique" proxy as it would lack information about
651 where to forward. (A proxy limited to a single outbound protocol
652 might in theory work as a unique proxy when using a transport in
653 which the full default Uri-Host value is configured at setup time,
654 but these are considered impractical and thus not assigned a resource
655 type here.)
656 The use of a generic proxy can be limited to a set of devices that
657 have permission to use it. Clients can be allowed by their network
658 address if they can be verified, or by using explicit client
659 authentication using the methods of
660 [I-D.tiloca-core-oscore-capable-proxies].
662 5. Client picked proxies
664 This section is purely informative, and serves to illustrate that the
665 mechanisms introduced in this document do not hinder the continued
666 use of existing proxies.
668 When a resource is accessed through an "actual" proxy (i.e., a host
669 between the client and the server, which itself may have a same-host
670 proxy in addition to that), the proxy's choice of the upstream server
671 is originally (i.e., without the mechanisms of this document) either
672 configured (as in a "chain" of proxies) or determined by the request
673 URI (where a proxy picks CoAP over TCP and resolves the given name
674 for a request aimed at a coap+tcp URI).
676 A proxy that has learned, by active solicitation of the information
677 or by consulting links in its cache, that the requested URI is
678 available through a (possibly same-host) proxy, may use that
679 information in choosing the upstream transport, to correct the URI
680 associated with a cached response, and to use responses obtained
681 through one transport to satisfy requests on another.
683 For example, if a host at coap://h1.example.com has advertised
684 ,;rel=has-proxy;anchor="/", then a
685 proxy that has an active CoAP-over-TCP connection to h1.example.com
686 can forward an incoming request for coap://h1.example.com/res through
687 that CoAP-over-TCP connection with a suitable Proxy-Scheme on that
688 connection.
690 If the host had marked the proxy point as
691 ;rel=has-unique-proxy instead, then the
692 proxy could elide the Proxy-Scheme and Uri-Host options, and would
693 (from the original CoAP caching rules) also be allowed to use any
694 fresh cache representation of coap+tcp://h1.example.com/res to
695 satisfy requests for coap://h1.example.com/res.
697 A client that uses a forward proxy and learns of a different proxy
698 advertised to access a particular resource will not change its
699 behavior if its original proxy is part of its configuration. If the
700 forward proxy was only used out of necessity (e.g., to access a
701 resource on the protocol not supported by the client) it can be
702 practical for the client to use the advertised proxy instead.
704 6. Security considerations
706 6.1. Security context propagation
708 Clients need to strictly enforce the rules of Section 2.2. Failure
709 to do so, in particular using a thusly announced proxy based on a
710 certificate that attests the proxy's name, would allow attackers to
711 circumvent the client's security expectation.
713 When security is terminated at proxies (as is in DTLS and TLS), a
714 third party proxy can usually not satisfy this requirement; these
715 transports are limited to same-host proxies.
717 6.2. Traffic misdirection
719 Accepting arbitrary proxies, even with security context propagation
720 performed properly, would allow attackers to redirect traffic through
721 systems under their control. Not only does that impact availability,
722 it also allows an attacker to observe traffic patterns.
724 This affects both OSCORE and (D)TLS, as neither protect the
725 participants' network addresses.
727 Other than the security context propagation rules, there are no hard
728 and general rules about when an advertised proxy is a suitable
729 candidate. Aspects for consideration are:
731 * When no direct connection is possible (e.g. because the resource
732 to be accessed is served as coap+tcp and TCP is not implemented in
733 the client, or because the resource's host is available on IPv6
734 while the client has no default IPv6 route), using a proxy is
735 necessary if complete service disruption is to be avoided.
737 While an adversary can cause such a situation (e.g. by
738 manipulating routing or DNS entries), such an adversary is usually
739 already in a position to observe traffic patterns.
741 * A proxy advertised by the device hosting the resource to be
742 accessed is less risky to use than one advertised by a third
743 party.
745 Note that in some applications, servers produce representations
746 based on unverified user input. In such cases, and more so when
747 multiple applications share a security context, the
748 advertisements' provenance may need to be considered.
750 6.3. Protecting the proxy
752 A widely published statement about a host's availability as a proxy
753 can cause many clients to attempt to use it.
755 This is mitigated in well-behaved clients by observing the rate
756 limits of [RFC7252], and by ceasing attempts to reach a proxy for the
757 Max-Age of received errors.
759 Operators can further limit ill-effects by ensuring that their client
760 systems do not needlessly use proxies advertised in an unsecured way,
761 and by providing own proxies when their clients need them.
763 7. IANA considerations
765 7.1. Link Relation Types
767 IANA is asked to add two entries into the Link Relation Type Registry
768 last updated in [RFC8288]:
770 +==================+==================================+===========+
771 | Relation Name | Description | Reference |
772 +==================+==================================+===========+
773 | has-proxy | The link target can be used as a | RFCthis |
774 | | proxy to reach the link context. | |
775 +------------------+----------------------------------+-----------+
776 | has-unique-proxy | Like has-proxy, and using this | RFCthis |
777 | | proxy implies scheme and host of | |
778 | | the target. | |
779 +------------------+----------------------------------+-----------+
781 Table 1: New Link Relation types
783 7.2. Resource Types
785 IANA is asked to add an entry into the "Resource Type (rt=) Link
786 Target Attribute Values" registry under the Constrained RESTful
787 Environments (CoRE) Parameters:
789 [ The RFC Editor is asked to replace any occurrence of TBDcore.proxy
790 with the actually registered attribute value. ]
792 Attribute Value: core.proxy
794 Description: Forward proxying services
796 Reference: [ this document ]
797 Notes: The schemes for which the proxy is usable may be indicated
798 using the proxy-schemes target attribute as per Section 4.1 of [ this
799 document ].
801 8. References
803 8.1. Normative References
805 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
806 Application Protocol (CoAP)", RFC 7252,
807 DOI 10.17487/RFC7252, June 2014,
808 .
810 [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
811 DOI 10.17487/RFC8288, October 2017,
812 .
814 8.2. Informative References
816 [aliases] W3C, "Architecture of the World Wide Web, Section 2.3.1
817 URI aliases", n.d.,
818 .
820 [cooluris] BL, T., "Cool URIs don't change", n.d.,
821 .
823 [I-D.amsuess-core-coap-over-gatt]
824 Amsüss, C., "CoAP over GATT (Bluetooth Low Energy Generic
825 Attributes)", Work in Progress, Internet-Draft, draft-
826 amsuess-core-coap-over-gatt-01, 2 November 2020,
827 .
830 [I-D.amsuess-t2trg-rdlink]
831 Amsüss, C., "rdlink: Robust distributed links to
832 constrained devices", Work in Progress, Internet-Draft,
833 draft-amsuess-t2trg-rdlink-01, 23 September 2019,
834 .
837 [I-D.bormann-t2trg-slipmux]
838 Bormann, C. and T. Kaupat, "Slipmux: Using an UART
839 interface for diagnostics, configuration, and packet
840 transfer", Work in Progress, Internet-Draft, draft-
841 bormann-t2trg-slipmux-03, 4 November 2019,
842 .
845 [I-D.ietf-core-href]
846 Bormann, C. and H. Birkholz, "Constrained Resource
847 Identifiers", Work in Progress, Internet-Draft, draft-
848 ietf-core-href-09, 15 January 2022,
849 .
852 [I-D.ietf-core-resource-directory]
853 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V.
854 D. Stok, "CoRE Resource Directory", Work in Progress,
855 Internet-Draft, draft-ietf-core-resource-directory-28, 7
856 March 2021, .
859 [I-D.ietf-lpwan-coap-static-context-hc]
860 Minaburo, A., Toutain, L., and R. Andreasen, "Static
861 Context Header Compression (SCHC) for the Constrained
862 Application Protocol (CoAP)", Work in Progress, Internet-
863 Draft, draft-ietf-lpwan-coap-static-context-hc-19, 8 March
864 2021, .
867 [I-D.silverajan-core-coap-protocol-negotiation]
868 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",
869 Work in Progress, Internet-Draft, draft-silverajan-core-
870 coap-protocol-negotiation-09, 2 July 2018,
871 .
874 [I-D.tiloca-core-oscore-capable-proxies]
875 Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work
876 in Progress, Internet-Draft, draft-tiloca-core-oscore-
877 capable-proxies-01, 25 October 2021,
878 .
881 [lwm2m] OMA SpecWorks, "White Paper – Lightweight M2M 1.1", n.d.,
882 .
885 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
886 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
887 .
889 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
890 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
891 .
893 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
894 Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
895 April 2016, .
897 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
898 E. Dijk, "Guidelines for Mapping Implementations: HTTP to
899 the Constrained Application Protocol (CoAP)", RFC 8075,
900 DOI 10.17487/RFC8075, February 2017,
901 .
903 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
904 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
905 Application Protocol) over TCP, TLS, and WebSockets",
906 RFC 8323, DOI 10.17487/RFC8323, February 2018,
907 .
909 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
910 "Object Security for Constrained RESTful Environments
911 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
912 .
914 Appendix A. Change log
916 Since -02 (mainly processing reviews from Marco and Klaus):
918 * Acknowledge that 'coap://hostname/' is not the proxy but a URI
919 that (in a particular phrasing) is used to stand in for the
920 proxy's address (while it regularly identifies a resurce on the
921 server)
923 * Security: Referencing traffic misdirection already in the first
924 security block.
926 * Security: Add (incomplete) considerations for unique-proxy case.
928 * Narrow down "unique" proxy semantics to those properties used by
929 the client, allowing unique proxies to be co-hosted with forward
930 proxies.
932 * "Client picked proxies" clarified to merely illustrate how this is
933 compatible with them.
935 * Use of "hosts" relation sharpened.
937 * Precision on how this does and does not consider changing
938 transports.
940 * "Related work" section demoted to appendix.
942 * Add note on DTLS session resumption.
944 * Variable renaming.
946 * Various editorial fixes.
948 Since -01:
950 * Removed suggestion for generally trusted proxies; now stating that
951 with (D)TLS, "a third party proxy can usually not satisfy [the
952 security context propagation requirement]".
954 * State more clearly that valid cache entries for resources aliased
955 through has-unique-proxy can be used.
957 * Added considerations for Multipath TCP.
959 * Added concrete suggestion and example for advertisement of general
960 proxies.
962 * Added concrete suggestion for RD lookup extension that provides
963 proxies.
965 * Minor editorial and example changes.
967 Since -00:
969 * Added introduction
971 * Added examples
973 * Added SCHC analogy
975 * Expanded security considerations
977 * Added guidance on choice of transport, and canonical addresses
979 * Added subsection on interaction with a Resource Directory
981 * Added comparisons with related work, including rdlink and DNS-SD
982 sketches
984 * Added IANA considerations
986 * Added section on open questions
988 Appendix B. Related work and applicability to related fields
989 B.1. On HTTP
991 The mechanisms introduced here are similar to the Alt-Svc header of
992 [RFC7838] in that they do not create different application-visible
993 addresses, but provide dispatch through lower transport
994 implementations.
996 Unlike in HTTP, the variations of CoAP protocols each come with their
997 unique URI schemes and thus enable the "transport address indicated
998 by a URI" concept. Thus, there is no need for a distinction between
999 protocol-id and scheme.
1001 To accommodate the message size constraints typical of CoRE
1002 environments, and accounting for the differences between HTTP headers
1003 and CoAP options, information is delivered once at discovery time.
1005 Using the has-proxy and has-unique-proxy with HTTP URIs as the
1006 context is NOT RECOMMENDED; the HTTP provisions of the Alt-Svc header
1007 and ALPN are preferred.
1009 B.2. Using DNS
1011 As pointed out in [RFC7838], DNS can already serve some of the
1012 applications of Alt-Svc and has-unique-proxy by providing different
1013 CNAME records. These cover cases of multiple addresses, but not
1014 different ports or protocols.
1016 While not specified for CoAP yet (and neither being specified here),
1018 [ which is an open discussion point for CoRE -- should we? Here? In
1019 a separate DNS-SD document? ]
1021 DNS SRV records (possibly in combination with DNS Service Discovery
1022 [RFC6763]) can provide records that could be considered equivalent to
1023 has-unique-proxy relations. If _coap._tcp, _coaps._tcp, _coap._udp,
1024 _coap+ws._tcp etc. were defined with suitable semantics, these can be
1025 equivalent:
1027 _coap._udp.device.example.com SRV 0 0 device.example.com 61616
1028 device.example.com AAAA 2001:db8::1
1030 ;rel=has-unique-proxy;anchor="coap://device.example.com"
1032 It would be up to such a specification to give details on what the
1033 link's context is; unlike the link based discovery of this document,
1034 it would either need to pick one distinguished context scheme for
1035 which these records are looked up, or would introduce aliasing on its
1036 own.
1038 B.3. Using names outside regular DNS
1040 Names that are resolved through different mechanisms than DNS, or
1041 names which are defined within the scope of DNS but have no
1042 universally valid answers to A/AAAA requests, can be advertised using
1043 the relation types defined here and CoAP discovery.
1045 In Figure 5, a server using a cryptographic name as described in
1046 [I-D.amsuess-t2trg-rdlink] is discovered and used.
1048 Req: to [ff02::fd]:5683 on UDP
1049 Code: GET
1050 Uri-Path: /.well-known/core
1051 Uri-Query: rel=has-proxy
1052 Uri-Query: anchor=coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa
1054 Res: from [2001:db8::1]:5683
1055 Content-Format: application/link-format
1056 Payload:
1057 ;rel=has-unique-proxy;
1058 anchor="coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa"
1060 Req: to [2001:db8::1]:5683 on TCP
1061 Code: GET
1062 OSCORE: ...
1063 Uri-Path: /sensors/temp
1064 Observe: 0
1066 Res: 2.05 Content
1067 OSCORE: ...
1068 Observe: 0
1069 Payload:
1070 39.1°C
1072 Figure 5: Obtaining a sensor value from a local device with a
1073 global name
1075 B.4. Multipath TCP
1077 When CoAP-over-TCP is used over Multipath TCP and no Uri-Host option
1078 is sent, the implicit assumption is that there is aliasing between
1079 URIs containing any of the endpoints' addresses.
1081 As these are negotiated within MPTCP, this works independently of
1082 this document's mechanisms. As long as all the server's addresses
1083 are equally reachable, there is no need to advertise multiple
1084 addresses that can later be discovered through MPTCP anyway. When
1085 advertisements are long-lived and there is no single more stable
1086 address, several available addresses can be advertised (independently
1087 of whether MPTCP is involved or not). If a client uses an address
1088 that is merely a proxy address (and not a unique proxy address), but
1089 during MPTCP finds out that the network location being accessed is
1090 actually an MPTCP alternative address of the used one, the client MAY
1091 forego sending of the Proxy-Scheme and Uri-Path option.
1093 [ This follows from multiple addresses being valid for that TCP
1094 connection; at some point we may want to say something about what
1095 that means for the default value of the Uri-Host option -- maybe
1096 something like "has the default value of any of the associated
1097 addresses, but the server may only enable MPTCP if there is implicit
1098 aliasing between all of them" (similar to OSCORE's statement)? ]
1100 [ TBD: Do we need a section analog to this that deals with (D)TLS
1101 session resumption in absence of SNI? ]
1103 Appendix C. Open Questions / further ideas
1105 * OSCORE interaction: [RFC8613] Section 4.1.3.2 requirements place
1106 OSCORE use in a weird category between has-proxy and has-unique-
1107 proxy (because if routing still works, the result will be
1108 correct). Not sure how to write this down properly, or whether
1109 it's actionable at all.
1111 Possibly there is an inbetween category of "The host needs the
1112 Uri-Host etc. when accessed through CoAP, but because the host
1113 does not use the same OSCORE KID across different virtual hosts,
1114 it's has-unique-proxy as soon as you talk OSCORE".
1116 * Self-uniqueness:
1118 A host that wants to indicate that it doesn't care about Uri-Host
1119 can probably publish something like >;rel=has-unique-proxy to do
1120 so.
1122 This'd help applications justify when they can elide the Uri-Host,
1123 even when no different protocols are involved.
1125 * Advertising under a stable name:
1127 If a host wants to advertise its host name rather than its IP
1128 address during multicast, how does it best do that?
1130 Options, when answering from 2001:db8::1 to a request to ff02::fd
1131 are:
1133 ,...,
1134 ;rel=has-unique-proxy;anchor="coap://myhostname"
1136 which is verbose but formally clear, and
1138 ,...,
1139 ;rel=has-unique-proxy;anchor="coap://myhostname"
1141 which is compatible with unaware clients, but its correctness with
1142 respect to canonical URIs needs to be argued by the client, in
1143 this sequence
1145 - understanding the has-unique-proxy line,
1147 - understanding that the request that went to 2001:db8::1 was
1148 really a Proxy-Scheme/Uri-Host-elided version of a request to
1149 coap://myhostname, and then
1151 - processing any relative reference with this new base in mind.
1153 (Not that it'd need to happen in software in that sequence, but
1154 that's the sequence needed to understand how the /foo here is
1155 really coap://myhostname/foo).
1157 If CoRAL is used during discovery, a base directive or reverse
1158 relation to has-unique-proxy would make this easier.
1160 Appendix D. Acknowledgements
1162 This document heavily builds on concepts explored by Bill Silverajan
1163 and Mert Ocak in [I-D.silverajan-core-coap-protocol-negotiation], and
1164 together with Ines Robles and Klaus Hartke inside T2TRG.
1166 [ TBD: reviewers Marco Klaus ]
1168 Author's Address
1170 Christian Amsüss
1171 Austria
1172 Email: christian@amsuess.com