Network Working Group I. Safruti Internet-Draft Akamai Intended status: Standards Track June 16, 2012 Expires: December 18, 2012 Connection Reuse for Multiple Hostnames and for Fast Redirect draft-safruti-httpbis-connection-reuse-01 Abstract This document describes a suggested enhancement to HTTP, in which a user-agent and a server can use a single connection to exchange requests/responses for multiple requested hostnames for which the server is authorized to serve. This enhancement suggests that user- agents will prefer to re-use an existing connection if it can be used to other hosts, and presents methods for a server to announce hosts that are served by it, as well as a mechanism for the user-agent to validate that the server is indeed trusted to serve this hosts. This is highly relevant when the server is actually a surrogate (like in a case of a CDN server), or in multi-hosts hosting environments, where the same server serves multiple hostnames/domains and can improve performance by the reuse of established and already optimized connections. 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 18, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Safruti Expires December 18, 2012 [Page 1] Internet-Draft Connection Reuse June 2012 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Client Side Implementation . . . . . . . . . . . . . . . . . . 4 2.1. Address validation . . . . . . . . . . . . . . . . . . . . 4 2.2. Validate server certificate . . . . . . . . . . . . . . . 4 3. Announcing permission to serve on behalf of a hostname . . . . 5 3.1. Trigger the UA to validate the hostname . . . . . . . . . 5 3.2. Signing the domain . . . . . . . . . . . . . . . . . . . . 5 3.3. Announcement message format . . . . . . . . . . . . . . . 6 3.4. Notes and comments . . . . . . . . . . . . . . . . . . . . 6 4. Reusing a single connection for multiple hosts over TLS . . . 7 4.1. Using a surrogate certificate . . . . . . . . . . . . . . 7 5. Redirect using a single connection . . . . . . . . . . . . . . 8 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Validate server hostname binding . . . . . . . . . . . . . 8 5.3. Reuse-Connection header . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Safruti Expires December 18, 2012 [Page 2] Internet-Draft Connection Reuse June 2012 1. Overview This document assumes that HTTP/2.0 will utilize some method of requests multiplexing on a single connection. By enabling requests multiplexing we can utilize a single connection for the delivery of multiple requests at the same level of performance (or better), reducing the overall number of connections required. Another benefit of a single connection is utilizing an established and optimized connection, and eliminating the overhead of connection setup. Most HTTP/1.1 user-agents will establish a separate connection according to the hostname and not only by the IP address the hostname resolves to. In fact a user-agent will typically open up to 6 different connections per hostname, to improve requests parallelism due to the way HTTP/1.1 is implemented. It is common that a single server, or IP address will serve multiple hosts, for instance in the case of CDNs, server farms, and when multiple servers are fronted by a load balancer. It is also common for a standard page to include multiple resources that are loaded from different hosts forcing the user-agent to establish many connections to retrieve a page. Splitting resources between multiple hostnames (also referred to as domain sharding) are a common practice with HTTP/1.1 due to the limitation of HTTP/1.1 (number of connections per domain, and serialization/blocking of HTTP requests). Utilizing a single optimized connection for multiple sites can reduce overhead of TCP connection setup, reduce load on server and client, and will speed the delivery of 3rd party and embedded objects if they are served from the same IP. Given that today web-sites are designed in a way that synthetically spread the resources on multiple hostnames, supporting multiple hostnames per single connection will be very helpful for the migrating from HTTP/1.1 to HTTP/2.0, with no application level change. It is important to note that HTTP/1.1 doesn't force a user-agent to establish a new connection for a different host, and it is perfectly valid to reuse a connection for multiple hosts if all hosts are resolved to the same IP address. However, due to other limitations of HTTP/1.1 it is typically not implemented that way. Safruti Expires December 18, 2012 [Page 3] Internet-Draft Connection Reuse June 2012 2. Client Side Implementation Validate server address, and trust to serve hostname's content. 2.1. Address validation When trying to establish a connection to a host, the user-agent will resolve the hostname to get an address (typically an IP address) to connect to. At that point - if a connection to that address is already established, the user-agent should try and reuse that connection to send requests to the host. 2.2. Validate server certificate In section 3 we describe a method for a server to sign/validate that it is trusted to serve on behalf of a hostname. For the purpose of this section we assume that such a method exists, where the server declares it is trusted to serve a domain, and the user-agent can validate that. At the point where such a validation is done, the user-agent can now reuse the existing connection to that server to send over it requests intended to the hostname. The user agent should cache the hostname-server binding for the provided TTL. Safruti Expires December 18, 2012 [Page 4] Internet-Draft Connection Reuse June 2012 3. Announcing permission to serve on behalf of a hostname Trusting DNS, or name resolution methods will not necessarily lead to the best outcome in means of performance. For once, it requires the user-agent to perform a task of resolving the hostname address that typically will take an additional roundtrip. The other issue is that as DNS is typically stateless, in case there are multiple servers serving this hostname, the user-agent may be assigned to a different server. This creates the need for a server to announce over an existing connection that it is also trusted to serve on behalf of other hostnames. It is up to the server implementation to determine when it should announce that, and in case it serves multiple hostnames, which hostnames it should announce. The server should announce the supported hostname by sending a control message. This assumes that HTTP will supports control messages, however, if it will not, HTTP headers can be used instead. We suggest 2 methods to sign or validate permission to handle the hostname. 3.1. Trigger the UA to validate the hostname In this scenario the server announces support of the hostname or domain. by doing so, it calls the UA to validate that, using a standard TLS handshake with the server. The UA sends a challenge to the server, and using the standard methods provided by TLS the validity of the certificate can be verified. This calls for a simple implementation as it relies on standard TLS methods, however this method also adds roundtrips for the validation process. 3.2. Signing the domain To eliminate the need for additional roundtrips, we are suggesting an additional method in which the server will send the validation for the domain as part of announcing the hostname. As there is no challenge from the UA, the server should generating a message that will indicate that the specific server is trusted, for instance a message that includes the address of the server and the announced hostname, and signing it with the private key of the certificate, which could be easily validated with the public key of the certificate. Safruti Expires December 18, 2012 [Page 5] Internet-Draft Connection Reuse June 2012 3.3. Announcement message format The announcement of a hostname or domain should include the following 3 elements: o The announced hostname o TTL for the assignment of the hostname to the specific server o The verification, which can be provided as part of the message, or achieved by the client initiating the verification 3.4. Notes and comments This document suggests using TLS methods to help validate and authenticate server permissions to serve specific hostnames. This risks crossing between layers, and crossing the scope of HTTP, however this is required to enable more efficient connection reuse. One alternative could be to manage the act of the validation and certificate push as a TLS extension, and to provide the right hooks for HTTP to trigger such a task, either by the client (when receiving the announcement from the server), or by the server. It should also be noted that this section describes concept rather than specific implementation details, as these can be finalized if the concepts are agreed upon. Safruti Expires December 18, 2012 [Page 6] Internet-Draft Connection Reuse June 2012 4. Reusing a single connection for multiple hosts over TLS In section 2 we describe a mechanism for the client to reuse a connection for multiple hosts served by the server. This is good when not using TLS, on a non-encrypted connection. Once TLS is used, it is important to ensure the privacy and security of the different hosts, as typically each host is using a different certificate, we want to ensure that having control of one certificate will not enable you to decipher request and responses of another host on the same connection. 4.1. Using a surrogate certificate In a case where the server would like to serve multiple hosts over TLS, the server should use a "neutral" certificate, namely a certificate issued for the surrogate. When establishing the TLS connection the server will use the surrogate certificate and will immediately provide evidence that it is trusted to serve the requested hostname, signing a message in a manner similar to the signing above. In this specific case, the validating could be achieved by signing its own public key with the certificate of the requested host that should be validated. This method provides the privacy and security required by TLS, while enabling serving multiple hosts. No single certificate owner can decipher the connection as the connection is encrypted using the surrogate certificate that is known only to the surrogate. Safruti Expires December 18, 2012 [Page 7] Internet-Draft Connection Reuse June 2012 5. Redirect using a single connection 5.1. Background Redirects are extremely common on today's sites. In many cases the redirects are used for naming and brand reasons and SEO reasons, or to ease handling of requests (like the case for mobile sites), and not necessarily to hand over to a different server. Where the redirected URL is served from the same server, the process of resolving the DNS record, and forcing a new connection is highly inefficient. We suggest a mechanism that will enable a server to indicate with a redirect response that the new URL can be requested over the existing connection. By doing that, eliminating the need for additional round-trips and warming up new connections. 5.2. Validate server hostname binding By utilizing the method above to validate the server is trusted to serve the redirected hostname, the user-agent can reuse the connection as detailed above. 5.3. Reuse-Connection header The server can add a specific header "Reuse-Connection" on a redirect response to indicate that the redirect should reuse the same connection it is delivered on. In that case the user-agent must validate that the server is trusted for that hostname and if valid should reuse the connection to send the redirected request. A sample response would look like this: server (www.example.com) --> UA HTTP/2.0 301 Moved Permanently Location: mobile.example.com Reuse-Connection: 1 Safruti Expires December 18, 2012 [Page 8] Internet-Draft Connection Reuse June 2012 6. Security Considerations Announcing additional domains has a potential to break things, and add the risk of enabling hijack domains and sites, as well as getting access to domain specific data, such as user-agent's cookies. To prevent that, a strong validation is required, and we believe that TLS methods as described provides that requirement. Safruti Expires December 18, 2012 [Page 9] Internet-Draft Connection Reuse June 2012 7. IANA Considerations ... Safruti Expires December 18, 2012 [Page 10] Internet-Draft Connection Reuse June 2012 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 8.2. Informative References [Fab1999] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", 1999. Safruti Expires December 18, 2012 [Page 11] Internet-Draft Connection Reuse June 2012 Author's Address Ido Safruti Akamai Technologies Safruti Expires December 18, 2012 [Page 12]