CoAP Protocol Indication
draft-amsuess-core-transport-indication-00

CoRE                                                           C. Amsüss
Internet-Draft                                             12 March 2021
Intended status: Standards Track                                        
Expires: 13 September 2021

                        CoAP Protocol Indication
               draft-amsuess-core-transport-indication-00

Abstract

   The Constrained Application Protocol (CoAP) is available over
   different transports (UDP / DTLS since [RFC7252], TCP / TLS /
   WebSockets since [RFC8323]), but lacks a way to unify these
   addresses.  This document provides terminology based on Web Linking
   [RFC8288] to express alternative transports available to a device,
   and to optimize exchanges using these.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Constrained RESTful
   Environments Working Group mailing list (core@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/core/.

   Source for this draft and an issue tracker can be found at
   https://github.com/git@gitlab.com:chrysn/transport-indication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 13 September 2021.

Amsüss                  Expires 13 September 2021               [Page 1]
Internet-Draft          CoAP Protocol Indication              March 2021

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Indicating alternative transports . . . . . . . . . . . . . .   4
     2.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Elision of Proxy-Scheme and Uri-Host  . . . . . . . . . . . .   5
   4.  Third party proxy services  . . . . . . . . . . . . . . . . .   6
   5.  Client picked proxies . . . . . . . . . . . . . . . . . . . .   6
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [ See Abstract for the moment ]

   [ This document is being developed at https://gitlab.com/chrysn/
   transport-indication (https://gitlab.com/chrysn/transport-
   indication). ]

1.1.  Terminology

   Same-host proxy  A CoAP server that accepts forward proxy requests
      (i.e., requests carrying the Proxy-Scheme option) exclusively for
      URIs that it is the authoritative server for is defined as a
      "same-host proxy".

   hosts  The verb "to host" is used here in the sense of the link
      relation of the same name defined in [RFC6690].

Amsüss                  Expires 13 September 2021               [Page 2]
Internet-Draft          CoAP Protocol Indication              March 2021

      For resources discovered via CoAP's discovery interface, a hosting
      statement is typically provided by the defaults implied by
      [RFC6690] where a link like "</sensor/temp>" is implied to have
      the relation "hosts" and the anchor "/", such that a statement
      "coap://hostname hosts coap://hostname/sensor/temp" can be
      inferred.

      For many application it can make sense to assume that any resource
      has a "host" relation leading from the root path of the server
      without having performed that discovery explicitly.

      [ TBD: The last paragraph could be a contentuous point; things
      should still work without it, and maybe that's even better because
      it precludes a dynamic resource created with one transport from
      use with another transport unless explicitly cleared. ]

   When talking of proxy requests, this document only talks of the
   Proxy-Scheme option.  Given that all URIs this is usable with can be
   expressed in decomposed CoAP URIs, the need for using the Proxy-URI
   option should never arise.

1.2.  Goals

   This document introduces provisions for the seamless use of different
   transport mechanisms for CoAP.  Combined, these provide:

   *  Enablement: Inform clients of the availability of other transports
      of servers.

   *  No Aliasing: Any URI aliasing must be opt-in by the server.  Any
      defined mechanisms must allow applications to keep working on the
      canonical URIs given by the server.

   *  Optimization: Do not incur per-request overhead from switching
      protocls.  This may depend on the server's willingness to create
      aliased URIs.

   *  Proxy usability: All information provided must be usable by aware
      proxies to reduce the need for duplicate cache entries.

   *  Proxy announcement: Allow third parties to announce that they
      provide alternative transports to a host.

   For all these functions, security policies must be described that
   allow the client to use them as securely as the original transport.

Amsüss                  Expires 13 September 2021               [Page 3]
Internet-Draft          CoAP Protocol Indication              March 2021

   This document will not concern itself with changes in transport
   availability over time, neither in causing them ("Please take up your
   TCP interface, I'm going to send a firmware update") nor in
   advertising them (other than by the server putting suitable Max-Age
   values on any of its statements).

2.  Indicating alternative transports

   While CoAP can indicate the authority component of the requested URI
   in all requests (by means of Uri-Host), indicating the scheme of a
   requested URI (by means of Proxy-Scheme) makes the request implicitly
   a proxy request.  However, this needs to be of only little practical
   concern: Any device can serve as a proxy for itself (a "same-host
   proxy") by accepting requests that carry the Proxy-Scheme option.  If
   it is to be a well-behaved as a proxy, the device should then check
   whether it recognizes the name indicated in Uri-Host as one of its
   own [ TBD: Check whether 7252 makes this a stricter requirement ],
   reject the request with 5.05 when it is not recognized, and otherwise
   process it as it would process a request coming in on that protocol
   (which, for many hosts, is the same as if the option were absent
   completely).

   A server can indicate support for same-host proxying (or any kind of
   proxying, really) by serving a Web Link with the "has-proxy"
   relation.

   The semantics of a link from C to T with relations has-proxy ("C has-
   proxy T", "<T>;rel=has-proxy;anchor="C"") are that for any resource R
   hosted on C ("C hosts R"), T is can be used as a proxy to obtain R.

   Note that HTTP and CoAP proxies are not located at a particular
   resource, but at a host in general.  Thus, a proxy URI "T" in these
   protocols can not carry a path or query component.  This is true even
   for CoAP over WebSockets (which uses the concrete resource "/.well-
   known/coap", but that can not expressed in "coap+ws" URI).  Future
   protocols for which CoAP proxying is defined may have expressible
   path components.

2.1.  Example

   A constrained device at the address 2001:db1::1 that supports CoAP
   over TCP in addition to CoAP can self-describe like this:

   </sensors/temp>;if="sensor",
   <coap+tcp://[2001:db1::1]>;rel=has-proxy;anchor="/"

Amsüss                  Expires 13 September 2021               [Page 4]
Internet-Draft          CoAP Protocol Indication              March 2021

   Note that generating this discovery file needs to be dynamic based on
   its available addresses; only if queried using a link-local source
   address, it may also respond with a link-local address in the
   authority component of the proxy URI.

   Unless the device makes resources discoverable at
   "coap+tcp://[2001:db1::1]/.well-known/core" or another discovery
   mechanism, clients may not assume that
   "coap+tcp://[2001:db1::1]/sensors/temp" is a valid resource (let
   alone has any relation to the other resource on the same path).  The
   server advertising itself like this may reject any request on CoAP-
   over-TCP unless they contain a Proxy-Scheme option.

   Clients that want to access the device using CoAP-over-TCP would send
   a request by connecting to 2001:db1::1 TCP port 5683 and sending a
   GET with the options Proxy-Scheme: coap, no Uri-Host or -Port options
   (utilizing their default values), and the Uri-Paths "sensors" and
   "temp".

3.  Elision of Proxy-Scheme and Uri-Host

   A CoAP server may publish and accept multiple URIs for the same
   resource, for example when it accepts requests on different IP
   addresses that do not carry a Uri-Host option, or when it accepts
   requests both with and without the Uri-Host option carrying a
   registered name.  Likewise, the server may serve the same resources
   on different transports.  This makes for efficient requests (with no
   Proxy-Scheme or Uri-Host option), but In general is discouraged
   [aliases].

   To make efficient requests possible without creating URI aliases that
   propagate, the "has-unique-proxy" specialization of the has-proxy
   relation is defined.

   If a proxy is unique, it means that it unconditionally forwards to
   the server indicated in the link context, even if the Proxy-Scheme
   and Uri-Host options are elided.

   While this creates URI aliasing in the requests as they are sent over
   the network, applications that discover a proxy this way should not
   "think" in terms of these URIs, but retain the originally discovered
   URIs (which, because Cool URIs Don't Change[cooluris], should be
   long-term usable).  They use the proxy for as long as they have fresh
   knowledge of the has-(unique-)proxy statement.

Amsüss                  Expires 13 September 2021               [Page 5]
Internet-Draft          CoAP Protocol Indication              March 2021

   A client MAY use a unique-proxy like a proxy and still send the
   Proxy-Scheme and Uri-Host option; such a client needs to recognize
   both relation types, as relations of the has-unique-proxy type are a
   specialization of has-proxy and typically don't carry the latter
   (redundant) annotation.

4.  Third party proxy services

   A server that is aware of a suitable cross proxy may use the has-
   proxy relation to advertise that proxy.  This is particularly
   interesting when the advertisements are made available across
   transports, for example in a Resource Directory.

   How the server can discover such a proxy (or, for the rare cases
   where this is possible, discover that it is suitable as a unique
   proxy) is out of scope for this document.

   A third party proxy may advertise its availability to act as a proxy
   for arbitrary CoAP requests. [ TBD: Specify a mechanism for this;
   "<coap+ws://myself>;rel=has-proxy;anchor="coap://*"" for all
   supported protocols appears to be an obvious but wrong solution. ]

5.  Client picked proxies

   When a resource is accessed through an "actual" proxy (i.e., a host
   between the client and the server that may also have a same-host
   proxy), the proxy's choice of the upstream server is originally
   (i.e., without the mechanisms of this document) either configured (as
   in a "chain" of proxies) or determined by the request URI (where a
   proxy picks CoAP over TCP for a request aimed at a coap+tcp URI).

   A proxy that has learned, by active solicitation of the information
   or by consulting links in its cache, that the requested URI is
   available through a same-host proxy, or that has learned of
   advertised URI aliasings, may can that information.

   For example, if a host at coap://h1.example.com has advertised
   "</res>,<coap+tcp://h1.example.com>;rel=has-proxy;anchor="/"", then a
   proxy that has an active CoAP-over-TCP connection to h1.example.com
   can forward an incoming request for coap://h1.example.com/res through
   that CoAP-over-TCP connection with a suitable Proxy-Scheme on that
   connection.

Amsüss                  Expires 13 September 2021               [Page 6]
Internet-Draft          CoAP Protocol Indication              March 2021

   If the host had marked the proxy point as
   "<coap+tcp://h1.example.com>;rel=has-unique-proxy", then the proxy
   could elide the Proxy-Scheme and Uri-Host options, and would (from
   the original CoAP caching rules) also be allowed to use any fresh
   cache representation of coap+tcp://h1.example.com/res to satisfy
   requests for coap://h1.example.com/res.

6.  Security considerations

   [ TBD; in key words: ]

   *  Always (ie. both with (D)TLS and OSCORE): Risk of attackers
      redirecting traffic for metadata analysis.

      Thus, only use transports you've obtained from either the server
      itself or someone you trust to make routing decisions for you.

      (If you have no other route, you may not be too picky about where
      you get your routes from).

   *  Without E2E (ie.  (D)TLS): Advertised proxy must either present
      credentials that are good enough for you to use as a general
      forward proxy, or present credentials good enough to be the actual
      origin server (like Alt-Svc does).

   *  TBD: Protecting the indicated proxy (rather than the client)

7.  IANA considerations

   [ TBD: Request registration of the defined rel types ]

8.  Informative References

   [aliases]  W3C, "Architecture of the World Wide Web, Section 2.3.1
              URI aliases", n.d.,
              <https://www.w3.org/TR/webarch/#uri-aliases>.

   [cooluris] BL, T., "Cool URIs don't change", n.d.,
              <https://www.w3.org/Provider/Style/URI>.

   [I-D.silverajan-core-coap-protocol-negotiation]
              Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",
              Work in Progress, Internet-Draft, draft-silverajan-core-
              coap-protocol-negotiation-09, 2 July 2018,
              <https://tools.ietf.org/html/draft-silverajan-core-coap-
              protocol-negotiation-09>.

Amsüss                  Expires 13 September 2021               [Page 7]
Internet-Draft          CoAP Protocol Indication              March 2021

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://doi.org/10.17487/RFC6690>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://doi.org/10.17487/RFC7252>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://doi.org/10.17487/RFC8288>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://doi.org/10.17487/RFC8323>.

Appendix A.  Acknowledgements

   This document heavily builds on concepts explored by Bill Silverajan
   and Mert Ocak in [I-D.silverajan-core-coap-protocol-negotiation], and
   together with Ines Robles and Klaus Hartke inside T2TRG.

Author's Address

   Christian Amsüss
   Hollandstr. 12/4
   1020
   Austria

   Phone: +43-664-9790639
   Email: christian@amsuess.com

Amsüss                  Expires 13 September 2021               [Page 8]