Network Working Group D. Thaler Internet-Draft Microsoft Intended status: Informational July 3, 2017 Expires: January 4, 2018 Using URIs With Multiple Transport Stacks draft-thaler-appsawg-multi-transport-uris-01 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 January 4, 2018. 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 January 4, 2018 [Page 1] Internet-Draft Multi-Transport URIs July 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 mechanism for discovery . . . . . . . . . . . 7 4. Transport endpoint selection . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. 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 January 4, 2018 [Page 2] Internet-Draft Multi-Transport URIs July 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). For URIs used in the World Wide Web, Section 2.3.1 of "Architecture of the World Wide Web" [AWWW] further discusses such aliasing, explaining that links to a resource increase the value of that resource, and multiple URIs for it interfere with such valuation, and also makes it difficult to correlate two sources as pointing to the same resource via differing aliases. Thus to maximize the benefit to the Web, URI aliases should be minimized. 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 Thaler Expires January 4, 2018 [Page 3] Internet-Draft Multi-Transport URIs July 2017 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. 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 or protocol specification. For example, TFTP only supports UDP port 69, and so no port number is permitted in a tftp URI. If support for a new transport protocol is later added under a protocol with a given URI scheme, 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. Thaler Expires January 4, 2018 [Page 4] Internet-Draft Multi-Transport URIs July 2017 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. 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 port field in URI authority component, since the URI syntax only allows integers in the port field. Thaler Expires January 4, 2018 [Page 5] Internet-Draft Multi-Transport URIs July 2017 For new URI schemes, it may be possible in some cases to place a service name in the host field, such as "_myservice._tcp.example.org" as would be used with a DNS SRV record [RFC2782]. That example still specifies only a single transport protocol stack ("_tcp") however, rather than a list of supported stacks. 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 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 Thaler Expires January 4, 2018 [Page 6] Internet-Draft Multi-Transport URIs July 2017 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 mechanism 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. For example, HTTP now provides an "Alt-Svc" [RFC7838] mechanism that can discover alternate transport endpoints for the same HTTP URI. One challenge in many cases is defining a common mechanism that could discover identifiers for different transport protocols. For example, 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 separate resolution mechanism 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. In some contexts, it might also be feasible to discover the additional identifiers using the same mechanism used to discover the URI itself, perhaps even in the same message. 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 Thaler Expires January 4, 2018 [Page 7] Internet-Draft Multi-Transport URIs July 2017 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. 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. Acknowledgements Thanks to Graham Klyne, Alexey Melnikov, and Gabriel Montenegro for helpful suggestions on this document. 8. 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, . [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, . Thaler Expires January 4, 2018 [Page 8] Internet-Draft Multi-Transport URIs July 2017 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, DOI 10.17487/RFC5630, October 2009, . [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, . [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, . [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, . [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, . [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, . [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, . [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, . [AWWW] Jacobs, I. and N. Walsh, "Architecture of the World Wide Web, Volume One", December 2004, . Author's Address Thaler Expires January 4, 2018 [Page 9] Internet-Draft Multi-Transport URIs July 2017 Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052 USA Email: dthaler@microsoft.com Thaler Expires January 4, 2018 [Page 10]