idnits 2.17.1 draft-safruti-httpbis-connection-reuse-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2012) is 4332 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) == Unused Reference: 'RFC2119' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'Fab1999' is defined on line 319, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Safruti 3 Internet-Draft Akamai 4 Intended status: Standards Track June 16, 2012 5 Expires: December 18, 2012 7 Connection Reuse for Multiple Hostnames and for Fast Redirect 8 draft-safruti-httpbis-connection-reuse-01 10 Abstract 12 This document describes a suggested enhancement to HTTP, in which a 13 user-agent and a server can use a single connection to exchange 14 requests/responses for multiple requested hostnames for which the 15 server is authorized to serve. This enhancement suggests that user- 16 agents will prefer to re-use an existing connection if it can be used 17 to other hosts, and presents methods for a server to announce hosts 18 that are served by it, as well as a mechanism for the user-agent to 19 validate that the server is indeed trusted to serve this hosts. 21 This is highly relevant when the server is actually a surrogate (like 22 in a case of a CDN server), or in multi-hosts hosting environments, 23 where the same server serves multiple hostnames/domains and can 24 improve performance by the reuse of established and already optimized 25 connections. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 18, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Client Side Implementation . . . . . . . . . . . . . . . . . . 4 63 2.1. Address validation . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Validate server certificate . . . . . . . . . . . . . . . 4 65 3. Announcing permission to serve on behalf of a hostname . . . . 5 66 3.1. Trigger the UA to validate the hostname . . . . . . . . . 5 67 3.2. Signing the domain . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Announcement message format . . . . . . . . . . . . . . . 6 69 3.4. Notes and comments . . . . . . . . . . . . . . . . . . . . 6 70 4. Reusing a single connection for multiple hosts over TLS . . . 7 71 4.1. Using a surrogate certificate . . . . . . . . . . . . . . 7 72 5. Redirect using a single connection . . . . . . . . . . . . . . 8 73 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Validate server hostname binding . . . . . . . . . . . . . 8 75 5.3. Reuse-Connection header . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Overview 85 This document assumes that HTTP/2.0 will utilize some method of 86 requests multiplexing on a single connection. By enabling requests 87 multiplexing we can utilize a single connection for the delivery of 88 multiple requests at the same level of performance (or better), 89 reducing the overall number of connections required. Another benefit 90 of a single connection is utilizing an established and optimized 91 connection, and eliminating the overhead of connection setup. 93 Most HTTP/1.1 user-agents will establish a separate connection 94 according to the hostname and not only by the IP address the hostname 95 resolves to. In fact a user-agent will typically open up to 6 96 different connections per hostname, to improve requests parallelism 97 due to the way HTTP/1.1 is implemented. 99 It is common that a single server, or IP address will serve multiple 100 hosts, for instance in the case of CDNs, server farms, and when 101 multiple servers are fronted by a load balancer. It is also common 102 for a standard page to include multiple resources that are loaded 103 from different hosts forcing the user-agent to establish many 104 connections to retrieve a page. Splitting resources between multiple 105 hostnames (also referred to as domain sharding) are a common practice 106 with HTTP/1.1 due to the limitation of HTTP/1.1 (number of 107 connections per domain, and serialization/blocking of HTTP requests). 109 Utilizing a single optimized connection for multiple sites can reduce 110 overhead of TCP connection setup, reduce load on server and client, 111 and will speed the delivery of 3rd party and embedded objects if they 112 are served from the same IP. 114 Given that today web-sites are designed in a way that synthetically 115 spread the resources on multiple hostnames, supporting multiple 116 hostnames per single connection will be very helpful for the 117 migrating from HTTP/1.1 to HTTP/2.0, with no application level 118 change. 120 It is important to note that HTTP/1.1 doesn't force a user-agent to 121 establish a new connection for a different host, and it is perfectly 122 valid to reuse a connection for multiple hosts if all hosts are 123 resolved to the same IP address. However, due to other limitations 124 of HTTP/1.1 it is typically not implemented that way. 126 2. Client Side Implementation 128 Validate server address, and trust to serve hostname's content. 130 2.1. Address validation 132 When trying to establish a connection to a host, the user-agent will 133 resolve the hostname to get an address (typically an IP address) to 134 connect to. At that point - if a connection to that address is 135 already established, the user-agent should try and reuse that 136 connection to send requests to the host. 138 2.2. Validate server certificate 140 In section 3 we describe a method for a server to sign/validate that 141 it is trusted to serve on behalf of a hostname. For the purpose of 142 this section we assume that such a method exists, where the server 143 declares it is trusted to serve a domain, and the user-agent can 144 validate that. 146 At the point where such a validation is done, the user-agent can now 147 reuse the existing connection to that server to send over it requests 148 intended to the hostname. 150 The user agent should cache the hostname-server binding for the 151 provided TTL. 153 3. Announcing permission to serve on behalf of a hostname 155 Trusting DNS, or name resolution methods will not necessarily lead to 156 the best outcome in means of performance. For once, it requires the 157 user-agent to perform a task of resolving the hostname address that 158 typically will take an additional roundtrip. The other issue is that 159 as DNS is typically stateless, in case there are multiple servers 160 serving this hostname, the user-agent may be assigned to a different 161 server. 163 This creates the need for a server to announce over an existing 164 connection that it is also trusted to serve on behalf of other 165 hostnames. It is up to the server implementation to determine when 166 it should announce that, and in case it serves multiple hostnames, 167 which hostnames it should announce. 169 The server should announce the supported hostname by sending a 170 control message. This assumes that HTTP will supports control 171 messages, however, if it will not, HTTP headers can be used instead. 173 We suggest 2 methods to sign or validate permission to handle the 174 hostname. 176 3.1. Trigger the UA to validate the hostname 178 In this scenario the server announces support of the hostname or 179 domain. by doing so, it calls the UA to validate that, using a 180 standard TLS handshake with the server. The UA sends a challenge to 181 the server, and using the standard methods provided by TLS the 182 validity of the certificate can be verified. This calls for a simple 183 implementation as it relies on standard TLS methods, however this 184 method also adds roundtrips for the validation process. 186 3.2. Signing the domain 188 To eliminate the need for additional roundtrips, we are suggesting an 189 additional method in which the server will send the validation for 190 the domain as part of announcing the hostname. As there is no 191 challenge from the UA, the server should generating a message that 192 will indicate that the specific server is trusted, for instance a 193 message that includes the address of the server and the announced 194 hostname, and signing it with the private key of the certificate, 195 which could be easily validated with the public key of the 196 certificate. 198 3.3. Announcement message format 200 The announcement of a hostname or domain should include the following 201 3 elements: 203 o The announced hostname 205 o TTL for the assignment of the hostname to the specific server 207 o The verification, which can be provided as part of the message, or 208 achieved by the client initiating the verification 210 3.4. Notes and comments 212 This document suggests using TLS methods to help validate and 213 authenticate server permissions to serve specific hostnames. This 214 risks crossing between layers, and crossing the scope of HTTP, 215 however this is required to enable more efficient connection reuse. 216 One alternative could be to manage the act of the validation and 217 certificate push as a TLS extension, and to provide the right hooks 218 for HTTP to trigger such a task, either by the client (when receiving 219 the announcement from the server), or by the server. 221 It should also be noted that this section describes concept rather 222 than specific implementation details, as these can be finalized if 223 the concepts are agreed upon. 225 4. Reusing a single connection for multiple hosts over TLS 227 In section 2 we describe a mechanism for the client to reuse a 228 connection for multiple hosts served by the server. This is good 229 when not using TLS, on a non-encrypted connection. 231 Once TLS is used, it is important to ensure the privacy and security 232 of the different hosts, as typically each host is using a different 233 certificate, we want to ensure that having control of one certificate 234 will not enable you to decipher request and responses of another host 235 on the same connection. 237 4.1. Using a surrogate certificate 239 In a case where the server would like to serve multiple hosts over 240 TLS, the server should use a "neutral" certificate, namely a 241 certificate issued for the surrogate. When establishing the TLS 242 connection the server will use the surrogate certificate and will 243 immediately provide evidence that it is trusted to serve the 244 requested hostname, signing a message in a manner similar to the 245 signing above. 247 In this specific case, the validating could be achieved by signing 248 its own public key with the certificate of the requested host that 249 should be validated. 251 This method provides the privacy and security required by TLS, while 252 enabling serving multiple hosts. No single certificate owner can 253 decipher the connection as the connection is encrypted using the 254 surrogate certificate that is known only to the surrogate. 256 5. Redirect using a single connection 258 5.1. Background 260 Redirects are extremely common on today's sites. In many cases the 261 redirects are used for naming and brand reasons and SEO reasons, or 262 to ease handling of requests (like the case for mobile sites), and 263 not necessarily to hand over to a different server. Where the 264 redirected URL is served from the same server, the process of 265 resolving the DNS record, and forcing a new connection is highly 266 inefficient. 268 We suggest a mechanism that will enable a server to indicate with a 269 redirect response that the new URL can be requested over the existing 270 connection. By doing that, eliminating the need for additional 271 round-trips and warming up new connections. 273 5.2. Validate server hostname binding 275 By utilizing the method above to validate the server is trusted to 276 serve the redirected hostname, the user-agent can reuse the 277 connection as detailed above. 279 5.3. Reuse-Connection header 281 The server can add a specific header "Reuse-Connection" on a redirect 282 response to indicate that the redirect should reuse the same 283 connection it is delivered on. In that case the user-agent must 284 validate that the server is trusted for that hostname and if valid 285 should reuse the connection to send the redirected request. 287 A sample response would look like this: server (www.example.com) --> 288 UA 290 HTTP/2.0 301 Moved Permanently 291 Location: mobile.example.com 292 Reuse-Connection: 1 294 6. Security Considerations 296 Announcing additional domains has a potential to break things, and 297 add the risk of enabling hijack domains and sites, as well as getting 298 access to domain specific data, such as user-agent's cookies. 300 To prevent that, a strong validation is required, and we believe that 301 TLS methods as described provides that requirement. 303 7. IANA Considerations 305 ... 307 8. References 309 8.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 315 Specifications: ABNF", RFC 2234, November 1997. 317 8.2. Informative References 319 [Fab1999] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in 320 TCP and Its Effect on Busy Servers", 1999. 322 Author's Address 324 Ido Safruti 325 Akamai Technologies