idnits 2.17.1 draft-ietf-httpbis-alt-svc-12.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 (February 9, 2016) is 2999 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group M. Nottingham 3 Internet-Draft Akamai 4 Intended status: Standards Track P. McManus 5 Expires: August 12, 2016 Mozilla 6 J. Reschke 7 greenbytes 8 February 9, 2016 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-12 13 Abstract 15 This document specifies "Alternative Services" for HTTP, which allow 16 an origin's resources to be authoritatively available at a separate 17 network location, possibly accessed with a different protocol 18 configuration. 20 Editorial Note (To be removed by RFC Editor) 22 Discussion of this draft takes place on the HTTPBIS working group 23 mailing list (ietf-http-wg@w3.org), which is archived at 24 . 26 Working Group information can be found at ; 27 source code and issues list for this draft can be found at 28 . 30 The changes in this draft are summarized in Appendix A. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 12, 2016. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 68 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5 69 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 7 70 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7 71 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7 72 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8 73 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9 74 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11 75 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12 76 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 14 77 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14 80 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15 81 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15 82 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 83 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15 84 8. Internationalization Considerations . . . . . . . . . . . . . 16 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16 87 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16 88 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17 89 9.4. Tracking Clients Using Alternative Services . . . . . . . 17 90 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Appendix A. Change Log (to be removed by RFC Editor before 95 publication) . . . . . . . . . . . . . . . . . . . . 20 96 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20 97 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20 98 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20 99 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21 100 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21 101 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21 102 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21 103 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 21 104 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22 105 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23 106 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 23 107 A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24 108 A.13. Since draft-ietf-httpbis-alt-svc-11 . . . . . . . . . . . 24 109 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 HTTP [RFC7230] conflates the identification of resources with their 114 location. In other words, "http://" (and "https://") URIs are used 115 to both name and find things to interact with. 117 In some cases, it is desirable to separate identification and 118 location in HTTP; keeping the same identifier for a resource, but 119 interacting with it at a different location on the network. 121 For example: 123 o An origin server might wish to redirect a client to a different 124 server when it is under load, or it has found a server in a 125 location that is more local to the client. 127 o An origin server might wish to offer access to its resources using 128 a new protocol (such as HTTP/2, see [RFC7540]) or one using 129 improved security (such as Transport Layer Security (TLS), see 130 [RFC5246]). 132 o An origin server might wish to segment its clients into groups of 133 capabilities, such as those supporting Server Name Indication 134 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for 135 operational purposes. 137 This specification defines a new concept in HTTP, "Alternative 138 Services", that allows an origin server to nominate additional means 139 of interacting with it on the network. It defines a general 140 framework for this in Section 2, along with specific mechanisms for 141 advertising their existence using HTTP header fields (Section 3) or 142 HTTP/2 frames (Section 4), plus a way to indicate that an alternative 143 service was used (Section 5). 145 It also endorses the status code 421 (Misdirected Request) 146 (Section 6) that origin servers (or their nominated alternatives) can 147 use to indicate that they are not authoritative for a given origin, 148 in cases where the wrong location is used. 150 1.1. Notational Conventions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 This document uses the Augmented BNF defined in [RFC5234] and updated 157 by [RFC7405] along with the "#rule" extension defined in Section 7 of 158 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 160 [RFC7234]: 162 OWS = 163 delta-seconds = 164 port = 165 quoted-string = 166 token = 167 uri-host = 169 2. Alternative Services Concepts 171 This specification defines a new concept in HTTP, the "Alternative 172 Service". When an origin (see [RFC6454]) has resources that are 173 accessible through a different protocol / host / port combination, it 174 is said to have an alternative service available. 176 An alternative service can be used to interact with the resources on 177 an origin server at a separate location on the network, possibly 178 using a different protocol configuration. Alternative services are 179 considered authoritative for an origin's resources, in the sense of 180 [RFC7230], Section 9.1. 182 For example, an origin: 184 ("http", "www.example.com", "80") 186 might declare that its resources are also accessible at the 187 alternative service: 189 ("h2", "new.example.com", "81") 191 By their nature, alternative services are explicitly at the 192 granularity of an origin; i.e., they cannot be selectively applied to 193 resources within an origin. 195 Alternative services do not replace or change the origin for any 196 given resource; in general, they are not visible to the software 197 "above" the access mechanism. The alternative service is essentially 198 alternative routing information that can also be used to reach the 199 origin in the same way that DNS CNAME or SRV records define routing 200 information at the name resolution level. Each origin maps to a set 201 of these routes -- the default route is derived from the origin 202 itself and the other routes are introduced based on alternative- 203 service information. 205 Furthermore, it is important to note that the first member of an 206 alternative service tuple is different from the "scheme" component of 207 an origin; it is more specific, identifying not only the major 208 version of the protocol being used, but potentially communication 209 options for that protocol. 211 This means that clients using an alternative service can change the 212 host, port and protocol that they are using to fetch resources, but 213 these changes MUST NOT be propagated to the application that is using 214 HTTP; from that standpoint, the URI being accessed and all 215 information derived from it (scheme, host, port) are the same as 216 before. 218 Importantly, this includes its security context; in particular, when 219 TLS [RFC5246] is used to authenticate, the alternative service will 220 need to present a certificate for the origin's host name, not that of 221 the alternative. Likewise, the Host header field ([RFC7230], Section 222 5.4) is still derived from the origin, not the alternative service 223 (just as it would if a CNAME were being used). 225 The changes MAY, however, be made visible in debugging tools, 226 consoles, etc. 228 Formally, an alternative service is identified by the combination of: 230 o An Application Layer Protocol Negotiation (ALPN) protocol name, as 231 per [RFC7301] 233 o A host, as per [RFC3986], Section 3.2.2 235 o A port, as per [RFC3986], Section 3.2.3 237 The ALPN protocol name is used to identify the application protocol 238 or suite of protocols used by the alternative service. Note that for 239 the purpose of this specification, an ALPN protocol name implicitly 240 includes TLS in the suite of protocols it identifies, unless 241 specified otherwise in its definition. In particular, the ALPN name 242 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 243 over TLS. 245 Additionally, each alternative service MUST have: 247 o A freshness lifetime, expressed in seconds; see Section 2.2 249 There are many ways that a client could discover the alternative 250 service(s) associated with an origin. This document describes two 251 such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the 252 "ALTSVC" HTTP/2 frame type (Section 4). 254 The remainder of this section describes requirements that are common 255 to alternative services, regardless of how they are discovered. 257 2.1. Host Authentication 259 Clients MUST have reasonable assurances that the alternative service 260 is under control of and valid for the whole origin. This mitigates 261 the attack described in Section 9.2. One way to achieve this is for 262 the alternative to use TLS with a certificate that is valid for the 263 origin. 265 For example, if the origin's host is "www.example.com" and an 266 alternative is offered on "other.example.com" with the "h2" protocol, 267 and the certificate offered is valid for "www.example.com", the 268 client can use the alternative. However, if "other.example.com" is 269 offered with the "h2c" protocol, the client cannot use it, because 270 there is no mechanism in that protocol to establish the relationship 271 between the origin and the alternative. 273 2.2. Alternative Service Caching 275 Mechanisms for discovering alternative services also associate a 276 freshness lifetime with them; for example, the Alt-Svc header field 277 uses the "ma" parameter. 279 Clients can choose to use an alternative service instead of the 280 origin at any time when it is considered fresh; see Section 2.4 for 281 specific recommendations. 283 Clients with existing connections to an alternative service do not 284 need to stop using it when its freshness lifetime ends; i.e., the 285 caching mechanism is intended for limiting how long an alternative 286 service can be used for establishing new connections, not limiting 287 the use of existing ones. 289 Alternative services are fully authoritative for the origin in 290 question, including the ability to clear or update cached alternative 291 service entries, extend freshness lifetimes, and any other authority 292 the origin server would have. 294 When alternative services are used to send a client to the most 295 optimal server, a change in network configuration can result in 296 cached values becoming suboptimal. Therefore, clients SHOULD remove 297 from cache all alternative services that lack the "persist" flag with 298 the value "1" when they detect such a change (when information about 299 network state is available). 301 2.3. Requiring Server Name Indication 303 A client MUST only use a TLS-based alternative service if the client 304 also supports TLS Server Name Indication (SNI). This supports the 305 conservation of IP addresses on the alternative service host. 307 Note that the SNI information provided in TLS by the client will be 308 that of the origin, not the alternative (as will the Host HTTP header 309 field value). 311 2.4. Using Alternative Services 313 By their nature, alternative services are OPTIONAL: clients do not 314 need to use them. However, it is advantageous for clients to behave 315 in a predictable way when alternative services are used by servers 316 (e.g., for load balancing). 318 Therefore, if a client becomes aware of an alternative service, the 319 client SHOULD use that alternative service for all requests to the 320 associated origin as soon as it is available, provided the 321 alternative service information is fresh (Section 2.2) and the 322 security properties of the alternative service protocol are 323 desirable, as compared to the existing connection. A viable 324 alternative service is then treated in every way as the origin; this 325 includes the ability to advertise alternative services. 327 If a client becomes aware of multiple alternative services, it 328 chooses the most suitable according to its own criteria (again, 329 keeping security properties in mind). For example, an origin might 330 advertise multiple alternative services to notify clients of support 331 for multiple versions of HTTP. 333 A client configured to use a proxy for a given request SHOULD NOT 334 directly connect to an alternative service for this request, but 335 instead route it through that proxy. 337 When a client uses an alternative service for a request, it can 338 indicate this to the server using the Alt-Used header field 339 (Section 5). 341 The client does not need to block requests on any existing 342 connection; it can be used until the alternative connection is 343 established. However, if the security properties of the existing 344 connection are weak (e.g. cleartext HTTP/1.1) then it might make 345 sense to block until the new connection is fully available in order 346 to avoid information leakage. 348 Furthermore, if the connection to the alternative service fails or is 349 unresponsive, the client MAY fall back to using the origin or another 350 alternative service. Note, however, that this could be the basis of 351 a downgrade attack, thus losing any enhanced security properties of 352 the alternative service. If the connection to the alternative 353 service does not negotiate the expected protocol (for example, ALPN 354 fails to negotiate h2, or an Upgrade request to h2c is not accepted), 355 the connection to the alternative service MUST be considered to have 356 failed. 358 3. The Alt-Svc HTTP Header Field 360 An HTTP(S) origin server can advertise the availability of 361 alternative services to clients by adding an Alt-Svc header field to 362 responses. 364 Alt-Svc = clear / 1#alt-value 365 clear = %s"clear"; "clear", case-sensitive 366 alt-value = alternative *( OWS ";" OWS parameter ) 367 alternative = protocol-id "=" alt-authority 368 protocol-id = token ; percent-encoded ALPN protocol name 369 alt-authority = quoted-string ; containing [ uri-host ] ":" port 370 parameter = token "=" ( token / quoted-string ) 372 The field value consists either of a list of values, each of which 373 indicates one alternative service, or the keyword "clear". 375 A field value containing the special value "clear" indicates that the 376 origin requests all alternatives for that origin to be invalidated 377 (including those specified in the same response, in case of an 378 invalid reply containing both "clear" and alternative services). 380 ALPN protocol names are octet sequences with no additional 381 constraints on format. Octets not allowed in tokens ([RFC7230], 382 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 383 [RFC3986]. Consequently, the octet representing the percent 384 character "%" (hex 25) MUST be percent-encoded as well. 386 In order to have precisely one way to represent any ALPN protocol 387 name, the following additional constraints apply: 389 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if 390 they are valid token characters except "%", and 392 2. When using percent-encoding, uppercase hex digits MUST be used. 394 With these constraints, recipients can apply simple string comparison 395 to match protocol identifiers. 397 The "alt-authority" component consists of an OPTIONAL uri-host 398 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 399 number. 401 For example: 403 Alt-Svc: h2=":8000" 405 This indicates the "h2" protocol ([RFC7540]) on the same host using 406 the indicated port 8000. 408 An example involving a change of host: 410 Alt-Svc: h2="new.example.org:80" 412 This indicates the "h2" protocol on the host "new.example.org", 413 running on port 80. Note that the "quoted-string" syntax needs to be 414 used because ":" is not an allowed character in "token". 416 Examples for protocol name escaping: 418 +--------------------+-------------+---------------------+ 419 | ALPN protocol name | protocol-id | Note | 420 +--------------------+-------------+---------------------+ 421 | h2 | h2 | No escaping needed | 422 +--------------------+-------------+---------------------+ 423 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 424 +--------------------+-------------+---------------------+ 425 | x%y | x%25y | "%" needs escaping | 426 +--------------------+-------------+---------------------+ 428 Alt-Svc MAY occur in any HTTP response message, regardless of the 429 status code. Note that recipients of Alt-Svc are free to ignore the 430 header field (and indeed need to in some situations; see Sections 2.1 431 and 6). 433 The Alt-Svc field value can have multiple values: 435 Alt-Svc: h2c=":8000", h2=":443" 437 When multiple values are present, the order of the values reflects 438 the server's preference (with the first value being the most 439 preferred alternative). 441 The value(s) advertised by Alt-Svc can be used by clients to open a 442 new connection to an alternative service. Subsequent requests can 443 start using this new connection immediately, or can continue using 444 the existing connection while the new connection is created. 446 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC 447 frame (Section 4). A single ALTSVC frame can be sent for a 448 connection; a new frame is not needed for every request. Note that, 449 despite this recommendation, Alt-Svc header fields remain valid in 450 responses delivered over HTTP/2. 452 Each "alt-value" is followed by an OPTIONAL semicolon-separated list 453 of additional parameters, each such "parameter" comprising a name and 454 a value. 456 This specification defines two parameters: "ma" and "persist", 457 defined in Section 3.1. Unknown parameters MUST be ignored, that is 458 the values (alt-value) they appear in MUST be processed as if the 459 unknown parameter was not present. 461 New parameters can be defined in extension specifications (see 462 Section 7.3 for registration details). 464 Note that all field elements that allow "quoted-string" syntax MUST 465 be processed as per Section 3.2.6 of [RFC7230]. 467 3.1. Caching Alt-Svc Header Field Values 469 When an alternative service is advertised using Alt-Svc, it is 470 considered fresh for 24 hours from generation of the message. This 471 can be modified with the 'ma' (max-age) parameter. 473 Syntax: 475 ma = delta-seconds; see [RFC7234], Section 1.2.1 477 The delta-seconds value indicates the number of seconds since the 478 response was generated the alternative service is considered fresh 479 for. 481 Alt-Svc: h2=":443"; ma=3600 483 See Section 4.2.3 of [RFC7234] for details of determining response 484 age. 486 For example, a response: 488 HTTP/1.1 200 OK 489 Content-Type: text/html 490 Cache-Control: max-age=600 491 Age: 30 492 Alt-Svc: h2c=":8000"; ma=60 494 indicates that an alternative service is available and usable for the 495 next 60 seconds. However, the response has already been cached for 496 30 seconds (as per the Age header field value), so therefore the 497 alternative service is only fresh for the 30 seconds from when this 498 response was received, minus estimated transit time. 500 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 501 does not affect caching of Alt-Svc values. 503 When an Alt-Svc response header field is received from an origin, its 504 value invalidates and replaces all cached alternative services for 505 that origin. 507 By default, cached alternative services will be cleared when the 508 client detects a network change. Alternative services that are 509 intended to be longer-lived (e.g., those that are not specific to the 510 client access network) can carry the "persist" parameter with a value 511 "1" as a hint that the service is potentially useful beyond a network 512 configuration change. 514 Syntax: 516 persist = "1" 518 For example: 520 Alt-Svc: h2=":443"; ma=2592000; persist=1 522 This specification only defines a single value for "persist". 523 Clients MUST ignore "persist" parameters with values other than "1". 525 See Section 2.2 for general requirements on caching alternative 526 services. 528 4. The ALTSVC HTTP/2 Frame 530 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the 531 availability of an alternative service to an HTTP/2 client. 533 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 534 that do not support this frame can safely ignore it. 536 An ALTSVC frame from a server to a client on a stream other than 537 stream 0 indicates that the conveyed alternative service is 538 associated with the origin of that stream. 540 An ALTSVC frame from a server to a client on stream 0 indicates that 541 the conveyed alternative service is associated with the origin 542 contained in the Origin field of the frame. An association with an 543 origin that the client does not consider authoritative for the 544 current connection MUST be ignored. 546 The ALTSVC frame type is 0xa (decimal 10). 548 +-------------------------------+-------------------------------+ 549 | Origin-Len (16) | Origin? (*) ... 550 +-------------------------------+-------------------------------+ 551 | Alt-Svc-Field-Value (*) ... 552 +---------------------------------------------------------------+ 554 ALTSVC Frame Payload 556 The ALTSVC frame contains the following fields: 558 Origin-Len: An unsigned, 16-bit integer indicating the length, in 559 octets, of the Origin field. 561 Origin: An OPTIONAL sequence of characters containing the ASCII 562 serialization of an origin ([RFC6454], Section 6.2) that the 563 alternative service is applicable to. 565 Alt-Svc-Field-Value: A sequence of octets (length determined by 566 subtracting the length of all preceding fields from the frame 567 length) containing a value identical to the Alt-Svc field value 568 defined in Section 3 (ABNF production "Alt-Svc"). 570 The ALTSVC frame does not define any flags. 572 The ALTSVC frame is intended for receipt by clients; a server that 573 receives an ALTSVC frame can safely ignore it. 575 An ALTSVC frame on stream 0 with empty (length 0) "Origin" 576 information is invalid and MUST be ignored. An ALTSVC frame on a 577 stream other than stream 0 containing non-empty "Origin" information 578 is invalid and MUST be ignored. 580 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 581 forward ALTSVC frames, though it can use the information contained in 582 ALTSVC frames in forming new ALTSVC frames to send to its own 583 clients. 585 Receiving an ALTSVC frame is semantically equivalent to receiving an 586 Alt-Svc header field. As a result, the ALTSVC frame causes 587 alternative services for the corresponding origin to be replaced. 588 Note that it would be unwise to mix the use of Alt-Svc header fields 589 with the use of ALTSVC frames, as the sequence of receipt might be 590 hard to predict. 592 5. The Alt-Used HTTP Header Field 594 The Alt-Used header field is used in requests to indicate the 595 identity of the alternative service in use, just as the Host header 596 field (Section 5.4 of [RFC7230]) identifies the host and port of the 597 origin. 599 Alt-Used = uri-host [ ":" port ] 601 Alt-Used is intended to allow alternative services to detect loops, 602 differentiate traffic for purposes of load balancing, and generally 603 to ensure that it is possible to identify the intended destination of 604 traffic, since introducing this information after a protocol is in 605 use has proven to be problematic. 607 When using an alternative service, clients SHOULD include an Alt-Used 608 header field in all requests. 610 For example: 612 GET /thing HTTP/1.1 613 Host: origin.example.com 614 Alt-Used: alternate.example.net 616 6. The 421 Misdirected Request HTTP Status Code 618 The 421 (Misdirected Request) status code is defined in Section 9.1.2 619 of [RFC7540] to indicate that the current server instance is not 620 authoritative for the requested resource. This can be used to 621 indicate that an alternative service is not authoritative; see 622 Section 2). 624 Clients receiving 421 (Misdirected Request) from an alternative 625 service MUST remove the corresponding entry from its alternative 626 service cache (see Section 2.2) for that origin. Regardless of the 627 idempotency of the request method, they MAY retry the request, either 628 at another alternative server, or at the origin. 630 An Alt-Svc header field in a 421 (Misdirected Request) response MUST 631 be ignored. 633 7. IANA Considerations 635 7.1. Header Field Registrations 637 HTTP header fields are registered within the "Message Headers" 638 registry maintained at 639 . 641 This document defines the following HTTP header fields, so their 642 associated registry entries shall be added according to the permanent 643 registrations below (see [BCP90]): 645 +-------------------+----------+----------+-----------+ 646 | Header Field Name | Protocol | Status | Reference | 647 +-------------------+----------+----------+-----------+ 648 | Alt-Svc | http | standard | Section 3 | 649 | Alt-Used | http | standard | Section 5 | 650 +-------------------+----------+----------+-----------+ 652 The change controller is: "IETF (iesg@ietf.org) - Internet 653 Engineering Task Force". 655 7.2. The ALTSVC HTTP/2 Frame Type 657 This document registers the ALTSVC frame type in the HTTP/2 Frame 658 Types registry ([RFC7540], Section 11.2). 660 Frame Type: ALTSVC 662 Code: 0xa 664 Specification: Section 4 of this document 666 7.3. Alt-Svc Parameter Registry 668 The HTTP Alt-Svc Parameter Registry defines the name space for 669 parameters. It will be created and maintained at (the suggested URI) 670 . 672 7.3.1. Procedure 674 A registration MUST include the following fields: 676 o Parameter Name 678 o Pointer to specification text 680 Values to be added to this name space require Expert Review (see 681 [RFC5226], Section 4.1). 683 7.3.2. Registrations 685 The HTTP Alt-Svc Parameter Registry is to be populated with the 686 registrations below: 688 +-------------------+-------------+ 689 | Alt-Svc Parameter | Reference | 690 +-------------------+-------------+ 691 | ma | Section 3.1 | 692 | persist | Section 3.1 | 693 +-------------------+-------------+ 695 8. Internationalization Considerations 697 An internationalized domain name that appears in either the header 698 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 699 using A-labels ([RFC5890], Section 2.3.2.1). 701 9. Security Considerations 703 9.1. Changing Ports 705 Using an alternative service implies accessing an origin's resources 706 on an alternative port, at a minimum. An attacker that can inject 707 alternative services and listen at the advertised port is therefore 708 able to hijack an origin. On certain servers, it is normal for users 709 to be able to control some personal pages available on a shared port, 710 and also to accept to requests on less-privileged ports. 712 For example, an attacker that can add HTTP response header fields to 713 some pages can redirect traffic for an entire origin to a different 714 port on the same host using the Alt-Svc header field; if that port is 715 under the attacker's control, they can thus masquerade as the HTTP 716 server. 718 This risk is mitigated by the requirements in Section 2.1. 720 On servers, this risk can also be reduced by restricting the ability 721 to advertise alternative services, and restricting who can open a 722 port for listening on that host. 724 9.2. Changing Hosts 726 When the host is changed due to the use of an alternative service, it 727 presents an opportunity for attackers to hijack communication to an 728 origin. 730 For example, if an attacker can convince a user agent to send all 731 traffic for "innocent.example.org" to "evil.example.com" by 732 successfully associating it as an alternative service, they can 733 masquerade as that origin. This can be done locally (see mitigations 734 in Section 9.1) or remotely (e.g., by an intermediary as a man-in- 735 the-middle attack). 737 This is the reason for the requirement in Section 2.1 that clients 738 have reasonable assurances that the alternative service is under 739 control of and valid for the whole origin; i.e., presenting a 740 certificate for the origin proves that the alternative service is 741 authorized to serve traffic for the origin. 743 Note that this assurance is only as strong as the method used to 744 authenticate the alternative service. In particular, when TLS 745 authentication is used to do so, there are well-known exploits to 746 make an attacker's certificate appear as legitimate. 748 Alternative services could be used to persist such an attack; for 749 example, an intermediary could man-in-the-middle TLS-protected 750 communication to a target, and then direct all traffic to an 751 alternative service with a large freshness lifetime, so that the user 752 agent still directs traffic to the attacker even when not using the 753 intermediary. 755 Implementations MUST perform any certificate-pinning validation (e.g. 756 [RFC7469]) on alternative services just as they would on direct 757 connections to the origin. Implementations might also choose to add 758 other requirements around which certificates are acceptable for 759 alternative services. 761 9.3. Changing Protocols 763 When the ALPN protocol is changed due to the use of an alternative 764 service, the security properties of the new connection to the origin 765 can be different from that of the "normal" connection to the origin, 766 because the protocol identifier itself implies this. 768 For example, if an "https://" URI has a protocol advertised that does 769 not use some form of end-to-end encryption (most likely, TLS), it 770 violates the expectations for security that the URI scheme implies. 772 Therefore, clients cannot blindly use alternative services, but 773 instead evaluate the option(s) presented to assure that security 774 requirements and expectations (of specifications, implementations and 775 end users) are met. 777 9.4. Tracking Clients Using Alternative Services 779 Choosing an alternative service implies connecting to a new, server- 780 supplied host name. By using many different (potentially unique) 781 host names, servers could conceivably track client requests. Such 782 tracking could follow users across multiple networks, when the 783 "persist" flag is used. 785 Clients that wish to prevent requests from being correlated (such as 786 those that offer modes aimed at providing improved privacy) can 787 decide not to use alternative services for multiple requests that 788 would not otherwise be allowed to be correlated. 790 In a user agent, any alternative service information MUST be removed 791 when origin-specific data is cleared (for instance, when cookies are 792 cleared). 794 9.5. Confusion Regarding Request Scheme 796 Some server-side HTTP applications make assumptions about security 797 based upon connection context; for example, equating being served 798 upon port 443 with the use of an "https://" URI (and the various 799 security properties that implies). 801 This affects not only the security properties of the connection 802 itself, but also the state of the client at the other end of it; for 803 example, a Web browser treats "https://" URIs differently than 804 "http://" URIs in many ways, not just for purposes of protocol 805 handling. 807 Since one of the uses of Alternative Services is to allow a 808 connection to be migrated to a different protocol and port, these 809 applications can become confused about the security properties of a 810 given connection, sending information (e.g., cookies, content) that 811 is intended for a secure context (e.g., an "https://" URI) to a 812 client that is not treating it as one. 814 This risk can be mitigated in servers by using the URI scheme 815 explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the 816 "absolute form" of the request target in HTTP/1.1) as an indication 817 of security context, instead of other connection properties 818 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 820 When the protocol does not explicitly carry the scheme (e.g., as is 821 usually the case for HTTP/1.1 over TLS, servers can mitigate this 822 risk by either assuming that all requests have an insecure context, 823 or by refraining from advertising alternative services for insecure 824 schemes (such as HTTP). 826 10. References 828 10.1. Normative References 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 832 RFC2119, March 1997, 833 . 835 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 836 Resource Identifier (URI): Generic Syntax", STD 66, 837 RFC 3986, DOI 10.17487/RFC3986, January 2005, 838 . 840 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 841 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 842 DOI 10.17487/RFC5226, May 2008, 843 . 845 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 846 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 847 RFC5234, January 2008, 848 . 850 [RFC5890] Klensin, J., "Internationalized Domain Names for 851 Applications (IDNA): Definitions and Document Framework", 852 RFC 5890, DOI 10.17487/RFC5890, August 2010, 853 . 855 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 856 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, 857 January 2011, . 859 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 860 DOI 10.17487/RFC6454, December 2011, 861 . 863 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 864 Protocol (HTTP/1.1): Message Syntax and Routing", 865 RFC 7230, DOI 10.17487/RFC7230, June 2014, 866 . 868 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 869 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 870 RFC 7234, DOI 10.17487/RFC7234, June 2014, 871 . 873 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, 874 "Transport Layer Security (TLS) Application-Layer Protocol 875 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 876 July 2014, . 878 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 879 RFC 7405, DOI 10.17487/RFC7405, December 2014, 880 . 882 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 883 Transfer Protocol version 2", RFC 7540, DOI 10.17487/ 884 RFC7540, May 2015, 885 . 887 10.2. Informative References 889 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 890 Procedures for Message Header Fields", BCP 90, RFC 3864, 891 September 2004, . 893 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 894 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 895 RFC5246, August 2008, 896 . 898 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 899 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 900 April 2015, . 902 Appendix A. Change Log (to be removed by RFC Editor before publication) 904 A.1. Since draft-nottingham-httpbis-alt-svc-05 906 This is the first version after adoption of 907 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 908 only contains editorial changes. 910 A.2. Since draft-ietf-httpbis-alt-svc-00 912 Selected 421 as proposed status code for "Not Authoritative". 914 Changed header field syntax to use percent-encoding of ALPN protocol 915 names (). 917 A.3. Since draft-ietf-httpbis-alt-svc-01 919 Updated HTTP/1.1 references. 921 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 922 to address fingerprinting concerns 923 (). 925 Note that ALTSVC frame is preferred to Alt-Svc header field 926 (). 928 Incorporate ALTSRV frame 929 (). 931 Moved definition of status code 421 to HTTP/2. 933 Partly resolved . 935 A.4. Since draft-ietf-httpbis-alt-svc-02 937 Updated ALPN reference. 939 Resolved . 941 A.5. Since draft-ietf-httpbis-alt-svc-03 943 Renamed "Alt-Svc-Used" to "Alt-Used" 944 (). 946 Clarify ALTSVC Origin information requirements 947 (). 949 Remove/tune language with respect to tracking risks (see 950 ). 952 A.6. Since draft-ietf-httpbis-alt-svc-04 954 Mention tracking by alt-svc host name in Security Considerations 955 (). 957 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 959 Allow the frame to carry multiple indicator and use the same payload 960 formats for both 961 (). 963 A.7. Since draft-ietf-httpbis-alt-svc-05 965 Go back to specifying the origin in Alt-Used, but make it a "SHOULD" 966 (). 968 Restore Origin field in ALT-SVC frame 969 (). 971 A.8. Since draft-ietf-httpbis-alt-svc-06 973 Disallow use of alternative services when the protocol might not 974 carry the scheme 975 (). 977 Align opp-sec and alt-svc 978 (). 980 alt svc frame on pushed (even and non-0) frame 981 (). 983 "browser" -> "user agent" 984 (). 986 ABNF for "parameter" 987 (). 989 Updated HTTP/2 reference. 991 A.9. Since draft-ietf-httpbis-alt-svc-07 993 Alt-Svc alternative cache invalidation 994 (). 996 Unexpected Alt-Svc frames 997 (). 999 Associating Alt-Svc header with an origin 1000 (). 1002 ALPN identifiers in Alt-Svc 1003 (). 1005 Number of alternate services used 1006 (). 1008 Proxy and .pac interaction 1009 (). 1011 Need to define extensibility for alt-svc parameters 1012 (). 1014 Persistence of alternates across network changes 1015 (). 1017 Alt-Svc header with 421 status 1018 (). 1020 Incorporate several editorial improvements suggested by Mike Bishop 1021 (, 1022 ). 1024 Alt-Svc response header field in HTTP/2 frame 1025 (). 1027 A.10. Since draft-ietf-httpbis-alt-svc-08 1029 Remove left over text about ext-params, applying to an earlier 1030 version of Alt-Used (see 1031 ). 1033 Conflicts between Alt-Svc and ALPN 1034 (). 1036 Elevation of privilege 1037 (). 1039 Alternates of alternates 1040 (). 1042 Alt-Svc and Cert Pinning 1043 (). 1045 Using alt-svc on localhost (no change to spec, see 1046 ). 1048 IANA procedure for alt-svc parameters 1049 (). 1051 Alt-svc from https (1.1) to https (1.1) 1052 (). 1054 Alt-svc vs the ability to convey the scheme inside the protocol 1055 (). 1057 Reconciling MAY/can vs. SHOULD 1058 (). 1060 Typo in alt-svc caching example 1061 (). 1063 A.11. Since draft-ietf-httpbis-alt-svc-09 1065 Editorial improvements 1066 (, 1067 , 1068 , 1069 , 1070 , 1071 , 1072 , 1073 ). 1075 A.12. Since draft-ietf-httpbis-alt-svc-10 1077 Editorial improvements 1078 (). 1080 Use RFC 7405 ABNF extension 1081 (). 1083 A.13. Since draft-ietf-httpbis-alt-svc-11 1085 Security considerations wrt system ports 1086 (). 1088 Appendix B. Acknowledgements 1090 Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy 1091 Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew 1092 Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, 1093 Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and 1094 suggestions. 1096 The Alt-Svc header field was influenced by the design of the 1097 Alternate-Protocol header field in SPDY. 1099 Authors' Addresses 1101 Mark Nottingham 1102 Akamai 1104 EMail: mnot@mnot.net 1105 URI: https://www.mnot.net/ 1107 Patrick McManus 1108 Mozilla 1110 EMail: mcmanus@ducksong.com 1111 URI: https://mozillians.org/u/pmcmanus/ 1113 Julian F. Reschke 1114 greenbytes GmbH 1116 EMail: julian.reschke@greenbytes.de 1117 URI: https://greenbytes.de/tech/webdav/