idnits 2.17.1 draft-nygren-httpbis-connection-redirect-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 2012) is 4305 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) == Missing Reference: 'RFC2616' is mentioned on line 235, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC2396' is mentioned on line 197, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) == Missing Reference: 'RFC3986' is mentioned on line 234, but not defined == Unused Reference: 'RFC2119' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'Cors' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'HappyEyes' is defined on line 400, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nygren 3 Internet-Draft S. Ludin 4 Intended status: Standards Track M. Levine 5 Expires: December 01, 2012 A. Champagne 6 Akamai 7 June 2012 9 Method for suggestion Alternative Servers to Enhance Connection Level 10 Performance 11 draft-nygren-httpbis-connection-redirect-00 13 Abstract 15 This memo presents a method for allowing an HTTP server to provide 16 hints in its HTTP responses to a user-agent that indicate the user 17 could be better off connecting to a different IP than what they are 18 currently connected to. This is highly relevant in a multi-homed 19 server world where DNS may not have all of the relevant state 20 necessary to make a proper routing decision. Additionally it is done 21 in a manner that does not require application level changes as could 22 be the case for an application level redirect such as a 3xx response 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 01, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Illustrative Use Case . . . . . . . . . . . . . . . . . . . . 3 59 3. Goals and use-cases . . . . . . . . . . . . . . . . . . . . . 4 60 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Proposed HTTP protocol extension . . . . . . . . . . . . . . . 5 62 6. When requests may be sent to an Alt-Server . . . . . . . . . . 5 63 7. Mechanisms for clients to balance performance . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 10.2. Informational References . . . . . . . . . . . . . . . . 8 69 Appendix A. Other Considerations . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Overview 74 Large deployments of HTTP servers commonly use DNS for Mapping 75 clients to servers, both for performance and load-balancing. The 76 current HTTP protocol provides no mechanism for a server to move 77 clients to a better alternative server without URI changes that can 78 interfere with application semantics. The primary goal of this 79 initiative is to develop a proposed standard set of extensions to the 80 HTTP/1.1 protocol that will enable HTTP servers to influence the 81 behavior of HTTP clients at the connection-level, rather than at the 82 application-level. This must be done in a way that enables an 83 incremental roll-out (both to servers and clients), which doesn't add 84 undue complexity, and which does not introduce or exacerbate security 85 vulnerabilities. 87 At the core of the initial proposal is a set of additional HTTP 88 response headers which servers can return to clients to influence 89 connection-level client behavior for subsequent HTTP requests. These 90 response headers are intended to provide changes to client behavior 91 by allowing servers to take the actual network location of clients 92 into account and give a per-client answer. 94 A goal here is to minimize the complexity of client implementations 95 and to provide service providers the leeway to evolve actual 96 heuristics used to assign clients to servers. 98 The closest existing alternative is for a server to issue a 302 (or 99 other 3xx) redirect to clients. The major down-side of this 100 302-redirect mechanism is that to provide an alternative server, it 101 requires altering the host component of URIs and, thus, the http 102 redirect approach is not transparent to applications. Due to user 103 agent same-origin and cross-domain security policies surrounding 104 cookies, and some scripting languages (ECMAScript, Silverlight, Java, 105 Flash, and potentially others), this can require significant 106 application changes as part of implementation. Experience has shown 107 that there is a high barrier to adoption for technologies that 108 require significant application-level changes, as many companies have 109 organizational separation between web application development and the 110 teams responsible for application performance and deployment. As 111 such, there is a strong desire for an alternative to 3xx redirects 112 that minimizes (or eliminates) the need for changes to applications 113 or URIs, but which also does not introduce any additional security 114 vulnerabilities. 116 2. Illustrative Use Case 118 In the following use-case, a user agent (UA) requests a URI under 119 https://www.example.com/ and is returned a hint that subsequent 120 requests for www.example.com should be sent to an alternative server 121 (sfo-server.example.com), which (based on considerations outside of 122 this proposal) has better performance: 124 request: UA --> server (www.example.com) 126 GET /application.asp HTTP/1.1 127 Host: www.example.com 129 response: server (www.example.com) --> UA 131 HTTP/1.1 200 OK 132 Alt-Server: sfo-server.example.com ; Max-Age=900 133 Alt-Server-Policy: Path=/ 134 (...body...) 136 request: UA --> alternative server (sfo-server.example.com) 138 GET /ajax-handler.asp HTTP/1.1 139 Host: www.example.com 140 Alt-Server-Name: sfo-server.example.com 142 response: alternative server (sfo-server.example.com) --> UA 144 HTTP/1.1 200 OK 145 Alt-Server: sfo-server.example.com ; Max-Age=900 146 Alt-Server-Policy: Path=/ 147 Alt-Server-Allow-Host: www.example.com 148 (...body...) 150 Note that in this example, URI of the request is not changed by the 151 response and clients/servers not supporting this new header would 152 continue to behave without changes. In this example, subsequent 153 requests under https://www.example.com/ will also continue to be sent 154 to the alternative server unless another is provided, the Max-Age is 155 reached without the Alt-Server being refreshed, or the client 156 experiences a failure in retrieving content from the Alt-Server. 158 3. Goals and use-cases 160 The desire is to handle as many of the following use-cases as 161 possible with this proposal. Earlier use-cases are considered to be 162 more important to satisfy if trade-offs need to be made. In all of 163 these cases, the common theme is to provide an application- 164 transparent manner to enable clients to be directed to alternative 165 servers without modifying the absoluteURI (http_URL) or the 166 corresponding user agent behavior. 168 1. A goal is to enable HTTP servers to propose to clients 169 semantically- equivalent alternative servers to provide improved 170 performance in certain scenarios. This is desirable both for 171 applications requiring high throughput (such as Video content 172 that can face challenges with the bandwidth*delay product), as 173 well as for latency-sensitive interactive applications. 175 2. Provide a mechanism to provide better performance and locality of 176 reference for large libraries of content. A problem is that 177 popular content may need to be replicated to spread out load, but 178 replicating all the unpopular content is not feasible. Enable 179 clients to be directed to alternative servers that may provide 180 better performance for particular content. 182 3. Provide an additional mechanism within HTTP to address potential 183 performance and scalability issues during the roll-outs of IPv6, 184 TLS SNI, and other Internet protocols with compatibility 185 challenges. In particular, provide a mechanism where clients can 186 be initially directed by DNS to a smaller set of servers 187 guaranteed to be reachable and fully compatible, but then provide 188 those a mechanism to direct newer clients to alternative servers 189 that may provide better performance at the expense of full 190 compatibility with older clients. 192 4. Terminology 194 The terms user agent, client, server, proxy, tunnel, origin server, 195 connection, request, and http_URL have the same meaning as in the 196 HTTP/1.1 specification [RFC2616]. The term absoluteURI has the same 197 meaning as in the URI Syntax specification [RFC2396]. 199 The term alt-server or "alternative server" refers to a domain name 200 (and optional port) or numeric IP address (and optional port) to 201 which a client should initiate connections for subsequent HTTP 202 requests. 204 The terms request-hostport and request-path refer to the hostport and 205 path portions of the absoluteURI (http_URL) of the HTTP request. 207 5. Proposed HTTP protocol extension 209 It is proposed to provide appropriate user agent mechanisms that can 210 interpret and respond appropriately to optional Alt-Server and Alt- 211 Sever-Policy HTTP response headers, as well as an Alt-Server-Host 212 HTTP request header. 214 The actual details of these headers (and the Alt-Server-Policy header 215 in-particular) are included as an initial starting point for 216 discussions, rather than as a final proposal. One potential grammar 217 for such headers might look like: 219 Alt-Server = "Alt-Server:" alt-servers 220 alt-servers = 1#alt-server-host 221 alt-server-host = hostport *(";" alt-server-av) 222 alt-server-av = "Max-Age" "=" delta-seconds 224 Alt-Server-Policy = "Alt-Server-Policy:" alt-server-policies 225 alt-server-policies = 1#alt-server-policy-av 226 alt-server-policy-av = "Path" "=" path-absolute ; [RFC3986] 227 | "When" "=" policy-when-value 228 policy-when-value = "immediate" 229 | "next" 230 | "sticky" 232 Alt-Server-Name = "Alt-Server-Name:" hostport *(";" alt-server-host-av) 233 Alt-Server-Allow-Host = "Alt-Server-Allow-Host:" hostport | "*" 234 hostport = host [ ":" port ] ; [RFC3986] 235 delta-seconds = 1*DIGIT ; [RFC2616] 237 Both of the Alt-Server and Alt-Server-Policy headers are optional. 238 If the Alt-Server-Policy response header is provided, an Alt-Server 239 header MUST also be provided. 241 On subsequent requests to an alt-server-host, the hostport of the 242 alternative server MUST be specified in the Alt-Server-Name request 243 header. 245 On subsequent responses, the Alt-Server-Allow-Host needs to match the 246 Host header or the client MUST drop the response. 248 6. When requests may be sent to an Alt-Server 249 Subject to the policy rules described subsequently, clients SHOULD 250 attempt to issue subsequent matching requests to an alt-server-host 251 while preserving the absoluteURI of the request. Clients MUST NOT 252 send non-matching requests to an alt-server-host. 254 A subsequent request is matching to a pair 255 if and only if all of these conditions are met: 257 1. The request-hostport of the subsequent request is equal to the 258 request-hostport of the request corresponding to the response for 259 which the alt-server-host was set. 261 2. The Path specified in the Alt-Server-Policy is a prefix of the 262 request-path for the subsequent request (including the case where 263 they string-compare equal). 265 3. Max-Age seconds have not passed since a corresponding alt-server- 266 host and Path were last returned in a response. 268 If multiple pairs match, the one with the 269 longest Path should be applied. 271 Depending on the policy-when-value the behavior should change: 273 "immediate" - the client SHOULD abort this HTTP request and re- 274 issue the request to an alt-server. This MUST NOT be returned in 275 response to non-idempotent requests (such as POST/PUT). 277 "next" = the client SHOULD continue with any in-flight HTTP 278 requests but should in-parallel establish a connection to the alt- 279 server for use in subsequent requests. 281 Clients should flush the Alt-Server data when it IP address changes, 282 for example when establishing a VPN connection or switching between 283 wi-fi and cellular connection on a mobile device 285 7. Mechanisms for clients to balance performance 287 Independent of the protocol elements for enabling redirects to 288 alternative servers while preserving semantic transparency and 289 maintaining security, the majority of the remaining protocol details 290 surround the area of how clients should behave to give servers 291 flexibility in moving client traffic around to meet various 292 performance objectives. The exact details here are an area for 293 further discussion. 295 Some considerations include: 297 It would be good for clients to minimize the number of times they 298 switch between servers (to minimize the performance impact of 299 setting up new connections). 301 The desired "stickiness" of clients to servers may vary between 302 systems and applications, and as such the protocol should give 303 servers some degree of control over how and when clients move 304 between servers or go back to the original server specified in the 305 request-hostport. 307 For sites that consist of many performance-sensitive small 308 requests (such as AJAX-based websites, map tiles, or chunked HTTP 309 streaming), a good behavior is often to err on the side of clients 310 being able to receive the first few objects from a sub-optimal 311 server while in-parallel setting up connections to an alternative 312 server for subsequent requests. 314 For large objects (such as downloads or progressive media), it may 315 be advantageous for the client to immediately disconnect after 316 receiving response headers and to issue a new request to an 317 alternative server. 319 Clients should be able to obtain a reaffirmation from an 320 alternative server that it is a good choice without needing to 321 return back to the initial host. 323 In error cases (such as when an alternative server has failed), 324 client behavior should involve retrying other alternative servers 325 and then eventually falling back to the initial host. 327 Some approaches to achieve this include allowing alt-servers to be 328 returned with a Max-Age (which is how long a client should remember 329 the answer if it hasn't been refreshed) as well as by having a set of 330 different alt-server-policies which may be specified (for example, 331 for suggesting that the client immediately disconnect, wait until 332 subsequent requests to connect, etc.) As the policy behaviors here 333 are performance hints to clients, it may also be possible to design 334 this in such a way that future policies can be added without 335 requiring full adoption by all clients. 337 A guiding design tension here will be finding a small set of features 338 to implement within clients that enables as many use-cases as 339 possible, enables future performance improvements from server-side- 340 only changes, but also minimizes client and protocol complexity. 342 8. Security Considerations 344 To retain semantic transparency, user agents must continue to follow 345 existing origin and domain-oriented security policies (for cookies, 346 scripting domains, etc.) as per the request-hostport of the request, 347 regardless of the current alt-server. The Origin (as applies to 348 same-origin policies) should continue to be derived from the request- 349 hostport of the request. This has potential security ramifications 350 that will need to be evaluated at in significant detail. 352 However, we believe that this protocol extension will not introduce 353 significant new vulnerabilities when used within the HTTPS/TLS 354 context. In this case, user agents must be validating that the 355 Common Name (CN) or subjectAltName of the certificate continues to 356 match the request-host (and not the alt-server). In this manner, the 357 server is cryptographically authenticating that it continues to be an 358 authoritative server for the request-host. (Due to constraints with 359 IPv4 availability and the context in which this protocol extension 360 will be used, it may be prudent to also encourage user agents 361 implementing it to also implement the TLS SNI extension.) 363 It is likely that the Alt-Server-Allow-Host constraints will protect 364 agaist many types of attacks, but further restrictions may need to be 365 imposed when using this protocol extension outside of the HTTPS/TLS 366 context and will need to be explored in more detail. In particular, 367 there may be ways in which this extension could worsen existing XSS, 368 CSRF, and similar vulnerabilities. 370 Additional security could be provided by signing the response in some 371 way. This should be explored as a method to allow more safe 372 flexibility in the Alt-Server names. 374 9. IANA Considerations 376 The new headers: 378 Alt-Server 380 Alt-Server-Policy 382 Alt-Server-Allow-Host 384 Alt-Server-Name 386 Require IANA assignment. 388 10. References 390 10.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 10.2. Informational References 397 [Cors] "Cross-Origin Resource Sharing", , . 400 [HappyEyes] 401 "Happy Eyeballs", , . 404 Appendix A. Other Considerations 405 Should we clients be encouraged to do races if multiple Alt-Servers 406 are returned? The Happy Eyeballs draft may be relevant (http:// 407 tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07). Some of the 408 changes to Chrome/FireFox to support Happy Eyeballs may also be of 409 help in implementing this extension if we want to prototype it. 411 Authors' Addresses 413 Erik Nygren 414 Akamai Technologies 416 Stephen Ludin 417 Akamai Technologies 419 Matt Levine 420 Akamai Technologies 422 Andy Champagne 423 Akamai Technologies