Using URIs With Multiple Transport Stacks
draft-thaler-appsawg-multi-transport-uris-00

Network Working Group                                          D. Thaler
Internet-Draft                                                 Microsoft
Intended status: Informational                             June 28, 2017
Expires: December 30, 2017

               Using URIs With Multiple Transport Stacks
              draft-thaler-appsawg-multi-transport-uris-00

Abstract

   Many Uniform Resource Identifiers (URIs) today have some mechanism to
   resolve them to one or more specific endpoints where that resource is
   available.  This document discusses issues that arise when the same
   resource can be reached over multiple protocol stacks, and discusses
   various approaches that have been used or discussed, and the
   tradeoffs between them.  Such issues are important to consider when
   defining new URI schemes and resolution mechanisms.

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 http://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 December 30, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://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

Thaler                  Expires December 30, 2017               [Page 1]
Internet-Draft            Multi-Transport URIs                 June 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Transport endpoint discovery  . . . . . . . . . . . . . . . .   4
     3.1.  Specified by the URI scheme specification . . . . . . . .   4
     3.2.  Passed in one URI . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Use separate URI for each transport endpoint  . . . . . .   6
     3.4.  Use another protocol for discovery  . . . . . . . . . . .   6
   4.  Transport endpoint selection  . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   For Uniform Resource Identifier (URI) schemes that function as
   locators, [RFC3986] explains that URI "resolution" is the process of
   determining an access mechanism and the appropriate parameters
   necessary to deference a URI; this resolution may require several
   iterations.  To use that access mechanism to perform an action on the
   URI's resource is to "dereference" the URI.

   The specific details vary by URI scheme and hence are up to each URI
   scheme definition to specify.  Requirements for URI scheme
   definitions are covered in [RFC3986], [RFC7320], and [RFC7595].  RFC
   7595 section 3.3 states:

      For schemes that function as locators, it is important that the
      mechanism of resource location be clearly defined.

   Closely related to the concept of resolving a URI to a resource that
   may have multiple ways to reach it, is the concept of "equivalence".
   [RFC3986] section 6.1 states:

      Even though it is possible to determine that two URIs are
      equivalent, URI comparison is not sufficient to determine whether
      two URIs identify different resources.  For example, an owner of
      two different domain names could decide to serve the same resource
      from both, resulting in two different URIs.  Therefore, comparison
      methods are designed to minimize false negatives while strictly
      avoiding false positives.

Thaler                  Expires December 30, 2017               [Page 2]
Internet-Draft            Multi-Transport URIs                 June 2017

   Thus, it is possible that two distinct URIs refer to the same
   resource.  The goal, as RFC 3986 stated above, is simply to
   "minimize" such cases, but such minimization often comes at a cost.
   For example, for many URIs schemes, a DNS name can be used in the
   authority component rather than using several URIs that differ only
   in IP address literal, with the cost being a dependency on DNS name
   resolution and the potential latency and traffic involved.

   As another example, [RFC5630] section 4.1 states:

      SIP and SIPS URIs that are identical except for the scheme itself
      (e.g., sip:alice@example.com and sips:alice@example.com) refer to
      the same resource.  This requirement is implicit in [RFC3261],
      Section 19.1, which states that "any resource described by a SIP
      URI can be 'upgraded' to a SIPS URI by just changing the scheme,
      if it is desired to communicate with that resource securely".
      This does not mean that the SIPS URI will necessarily be
      reachable, in particular, if the proxy cannot establish a secure
      connection to a client or another proxy.  This does not suggest
      either that proxies would arbitrarily "upgrade" SIP URIs to SIPS
      URIs when forwarding a request (see Section 5.3).  Rather, it
      means that when a resource is addressable with SIP, it will also
      be addressable with SIPS.

   Thus, the same resource might be identified by multiple URIs that
   differ only in URI scheme, or authority component, or path (e.g.,
   using ".." resolution).

2.  Problem Statement

   Besides specifying one or more URI scheme names to be used and the
   syntax for each (e.g., what the authority component contains), there
   are two issues a URI scheme definer must deal with when multiple
   transports are available for accessing a given resource:

   1.  Specifying how the set of transport endpoint identifiers (e.g.,
       TCP and UDP port numbers) for a given URI can be discovered by an
       entity wishing to resolve it, and

   2.  Specifying how an appropriate transport endpoint can be selected
       for use, from among the discovered set.

   At a high level, these issues are equivalent to those arising when
   multiple IP addresses are available for the same resource.  However,
   in general, there may be multiple layers in a transport stack, each
   with their own identifiers, so the problems are compounded when
   multiple choices exist at each of multiple layers below the
   application-layer protocol itself.

Thaler                  Expires December 30, 2017               [Page 3]
Internet-Draft            Multi-Transport URIs                 June 2017

3.  Transport endpoint discovery

   A client wishing to access a resource needs to know, for each layer
   in the transport stack, what protocol(s) to use, and what
   identifier(s) are needed by each such protocol.  There are several
   possible approaches to transport endpoint identifier discovery, which
   we cover in the following sections.  For simplicity, we will discuss
   them as if the same approach is used for both types of information,
   but it is important to remember that a URI scheme could specify
   discovery of the set of transport protocols via one approach, and
   discovery of the identifier(s) for each transport protocol via
   another approach.

3.1.  Specified by the URI scheme specification

   In this approach, every resource is assumed to use the exact same set
   of transport protocols (i.e., stacks of protocols above the network
   layer) and identifiers.  The identifiers can be IANA assigned and
   specified as part of the URI scheme specification.  If support for a
   new transport protocol is added later, different entities may thus
   have different hard-coded assumptions about the set of possible
   transport protocols, which just pushes the rest of the burden to the
   problem of selection among the known set (see Section 4).

   A disadvantage of this approach for many use cases is that it does
   not allow for non-default configurations such as custom ports.

3.2.  Passed in one URI

   For single-transport protocols, a common mechanism is to specify a
   default port for the URI scheme, and to allow putting a non-default
   port number in the URI authority component.

   For multi-transport protocols, historically it was sometimes assumed
   that multiple transport protocols (e.g., UDP and TCP) would use the
   same port number, so specifying a single number would also be
   sufficient for multiple transports.  When port numbers appear in
   URIs, they are not the default ports that might be IANA-assigned
   (since default ports should be omitted from the URI per [RFC3986]
   section 3.2.3), but instead are either statically chosen by the
   server application, or are ephemeral ports dynamically allocated on
   the server hosting the resource.  In most TCP/IP stacks, ephemeral
   ports used by UDP endpoints have no relationship to ephemeral ports
   used by TCP endpoints in the same application and so it cannot be
   guaranteed that the port numbers are the same.  For example, port
   51000 might be allocated to one application for UDP, and a different
   application for TCP.

Thaler                  Expires December 30, 2017               [Page 4]
Internet-Draft            Multi-Transport URIs                 June 2017

   Since 2011, this same issue can also occur with IANA-assigned ports,
   especially if support for a given transport protocol is added at a
   later time.  [RFC6335] section 7.2 explains:

      Effective with the publication of this document, IANA will begin
      assigning port numbers for only those transport protocols
      explicitly included in an assignment request.  This ends the long-
      standing practice of automatically assigning a port number to an
      application for both TCP and UDP, even if the request is for only
      one of these transport protocols.

   Thus, for most URI schemes, a port number appearing in a URI
   authority component must be specified as being in a specific
   transport-layer protocol's numbering space since its value for a
   given resource might differ by transport protocol.  If a URI scheme
   wishes for the port number in URI authority component to be able to
   apply to multiple transport protocols, the URI scheme would typically
   have to assume static configuration on servers; this may be
   acceptable in some circumstances and unacceptable in others.

   A common solution in non-URI contexts is to use a service name rather
   than a literal port number, and allow the service name to be resolved
   to the relevant transport-layer identifier.  Indeed, [RFC6335]
   section 3 says:

      Because the port number space is finite (and therefore
      conservation is an important goal), the alternative of using
      service names instead of port numbers is RECOMMENDED whenever
      possible.

   Unfortunately, it is not possible to follow this recommendation with
   the URI authority component, since the URI syntax does not support
   the use of service names in the authority.  Another limitation of
   service names is that they are currently limited only to TCP, UDP,
   SCTP, and DCCP, and so cannot be used with other layers (e.g.,
   websockets) or protocols.  Thus, a URI scheme for a protocol that
   supports both, say, websockets and raw TCP as possible transports for
   resource access, cannot use a service name as a common identifier for
   transport-layer endpoint resolution.

   It is usually also undesirable to put transport-layer endpoint
   information (the list of supported transport protocols or the
   identifier(s) used with the transport protocols) in the path or query
   components for two reasons.  First, those components are typically
   passed over the wire to the server when accessing a resource, which
   only consumes extra bandwidth with no benefit.  Second, if the
   transport-layer identifiers might change over the lifetime of the
   resource, then the URI would need to change even if the change did

Thaler                  Expires December 30, 2017               [Page 5]
Internet-Draft            Multi-Transport URIs                 June 2017

   not affect the actual endpoint chosen by the client.  Such a change
   would negatively affect equivalence with the previous URI, e.g.,
   resulting in cache misses.

   Thus, an advantage of this approach is that it can work without any
   dependency on other protocols or deployment of servers needed for
   resolution, and a disadvantage is that putting information about
   multiple transport-layer endpoints anywhere in the same URI could
   make for a very long URI that might have issues with certain
   software, or have bandwidth or storage issues.

3.3.  Use separate URI for each transport endpoint

   In this approach, one must simply accept the fact that multiple URIs
   might refer to the same resource as RFC 3986 already allows.  This is
   similar to using a set of URIs that differ only in IP address
   literal, for a case when the resource server is not resolvable via a
   protocol such as DNS or SIP.

   The obvious disadvantage is that there are multiple URIs for the same
   resource.  Another potential disadvantage for some more complex use
   cases where there are multiple layers of the transport stack, is that
   it may be difficult or impossible to express all the identifiers in
   an entire stack of protocols in one URI.

   For cases where there are multiple transport protocols but only one
   such layer, this approach results in needing to identify a single
   transport protocol per URI.  As discussed in Section 3.2, this often
   cannot be put in the authority component and is undesirable to put in
   the path or query component.  As a result, such cases involve
   specifying a separate URI scheme per transport.  For example, "sip"
   and "sips" do this.  The CoRE WG also proposed this approach for CoAP
   with "coap", "coaps", "coap+tcp", "coaps+tcp", etc.

3.4.  Use another protocol for discovery

   In this approach, a URI scheme definer would specify a mechanism
   whereby transport stack identifiers can be resolved for a given URI.
   If multiple layers exist, then such resolution might involve a
   resolution step for each layer.

   DNS records (e.g., SRV records) provide one potential mechanism that
   can be used to discover a set of supported transports and their
   associated identifiers.  Other types of directories might be usable
   in other cases.

   One challenge is defining a common mechanism that could discover
   identifiers for different transport protocols.  For example,

Thaler                  Expires December 30, 2017               [Page 6]
Internet-Draft            Multi-Transport URIs                 June 2017

   websockets use URIs and TCP uses port numbers (and there is currently
   no URI scheme for TCP itself), and so the syntax of such identifiers
   may differ if an application layer protocol could use both TCP and
   websockets.

   The advantage of requiring a resolution protocol is that the resource
   URI itself can be kept short and simple.  The downside is extra
   complexity in both clients and servers, and potentially extra
   specification work for the URI scheme definer, and the possible
   additional deployment burden of provisioning and operating extra
   protocols or servers to facilitate such resolution.

4.  Transport endpoint selection

   The URI scheme must specify the mechanism for choosing among
   transport protocol stacks, such as specifying at least one that is
   mandatory to implement and an algorithm for trying possible transport
   stacks in some order until one works.

   This problem is similar to that of choosing among multiple discovered
   IP addresses for the same transport stack, and two common solutions
   are used today in that context.  One category of algorithm is to sort
   the choices according to some criteria, and then to try them in order
   of preference.  For example, SRV records provide a priority and
   weight for each transport endpoint that can be used to sort them, and
   [RFC6724] provides an algorithm for sorting destination IP addresses.

   Another category of such algorithms is called "Happy Eyeballs"
   [RFC6555] where multiple possibilities are attempted in parallel
   (possibly with some delay added before starting non-preferred
   choices) and keeping the first one that successfully connects.  The
   advantage is faster connection when a non-preferred choice is needed,
   and the disadvantages are extra complexity in the client, extra
   traffic on the network, and extra connections at the server if
   multiple parallel attempts succeed.

   As noted earlier, when multiple layers exist in the transport stack,
   the number of possible permutations might be large in some cases, and
   so a mechanism must be cognizant of that.

5.  IANA Considerations

   This document has no actions for IANA.

Thaler                  Expires December 30, 2017               [Page 7]
Internet-Draft            Multi-Transport URIs                 June 2017

6.  Security Considerations

   The security considerations in section 3.7 of [RFC7595] and section 7
   of [RFC3986] apply.  [RFC6943] also discusses security considerations
   with determining equivalence, and section 3.1.4 of that document is
   relevant to resolution.  This document does not raise additional
   security issues.

7.  Informative References

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <http://www.rfc-editor.org/info/rfc2782>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Session
              Initiation Protocol (SIP)", RFC 5630,
              DOI 10.17487/RFC5630, October 2009,
              <http://www.rfc-editor.org/info/rfc5630>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <http://www.rfc-editor.org/info/rfc6335>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <http://www.rfc-editor.org/info/rfc6555>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <http://www.rfc-editor.org/info/rfc6724>.

   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <http://www.rfc-editor.org/info/rfc6943>.

Thaler                  Expires December 30, 2017               [Page 8]
Internet-Draft            Multi-Transport URIs                 June 2017

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7320]  Nottingham, M., "URI Design and Ownership", BCP 190,
              RFC 7320, DOI 10.17487/RFC7320, July 2014,
              <http://www.rfc-editor.org/info/rfc7320>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <http://www.rfc-editor.org/info/rfc7595>.

   [I-D.ietf-core-coap-tcp-tls]
              Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              draft-ietf-core-coap-tcp-tls-09 (work in progress), May
              2017.

   [ListDiscussion]
              Bormann, C., "Question about Location and redirection",
              Symposium on Security and Privacy 2003, October 2013,
              <https://www.ietf.org/mail-archive/web/core/current/
              msg04867.html>.

Author's Address

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: dthaler@microsoft.com

Thaler                  Expires December 30, 2017               [Page 9]