idnits 2.17.1 draft-ietf-httpbis-alt-svc-13.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 (March 1, 2016) is 2940 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 2818 (Obsoleted by RFC 9110) ** 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: 5 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: September 2, 2016 Mozilla 6 J. Reschke 7 greenbytes 8 March 1, 2016 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-13 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 September 2, 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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 15 79 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . 16 84 8. Internationalization Considerations . . . . . . . . . . . . . 16 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16 87 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 17 88 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17 89 9.4. Tracking Clients Using Alternative Services . . . . . . . 18 90 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . 21 98 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 21 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 . . . . . . . . . . . 22 103 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22 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 . . . . . . . . . . . 24 107 A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24 108 A.13. Since draft-ietf-httpbis-alt-svc-11 . . . . . . . . . . . 24 109 A.14. Since draft-ietf-httpbis-alt-svc-12 . . . . . . . . . . . 24 110 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 112 1. Introduction 114 HTTP [RFC7230] conflates the identification of resources with their 115 location. In other words, "http://" and "https://" URIs are used to 116 both name and find things to interact with. 118 In some cases, it is desirable to separate identification and 119 location in HTTP; keeping the same identifier for a resource, but 120 interacting with it at a different location on the network. 122 For example: 124 o An origin server might wish to redirect a client to a different 125 server when it is under load, or it has found a server in a 126 location that is more local to the client. 128 o An origin server might wish to offer access to its resources using 129 a new protocol, such as HTTP/2 [RFC7540], or one using improved 130 security, such as Transport Layer Security (TLS) [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) (Section 3 of [RFC6066]), for operational purposes. 136 This specification defines a new concept in HTTP, "Alternative 137 Services", that allows an origin server to nominate additional means 138 of interacting with it on the network. It defines a general 139 framework for this in Section 2, along with specific mechanisms for 140 advertising their existence using HTTP header fields (Section 3) or 141 HTTP/2 frames (Section 4), plus a way to indicate that an alternative 142 service was used (Section 5). 144 It also endorses the status code 421 (Misdirected Request) 145 (Section 6) that origin servers or their nominated alternatives can 146 use to indicate that they are not authoritative for a given origin, 147 in cases where the wrong location is used. 149 1.1. Notational Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 This document uses the Augmented BNF defined in [RFC5234] and updated 156 by [RFC7405] along with the "#rule" extension defined in Section 7 of 157 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and 158 [RFC7234]: 160 OWS = 161 delta-seconds = 162 port = 163 quoted-string = 164 token = 165 uri-host = 167 2. Alternative Services Concepts 169 This specification defines a new concept in HTTP, the "Alternative 170 Service". When an origin [RFC6454] has resources that are accessible 171 through a different protocol / host / port combination, it is said to 172 have an alternative service available. 174 An alternative service can be used to interact with the resources on 175 an origin server at a separate location on the network, possibly 176 using a different protocol configuration. Alternative services are 177 considered authoritative for an origin's resources, in the sense of 178 [RFC7230], Section 9.1. 180 For example, an origin: 182 ("http", "www.example.com", "80") 184 might declare that its resources are also accessible at the 185 alternative service: 187 ("h2", "new.example.com", "81") 189 By their nature, alternative services are explicitly at the 190 granularity of an origin; they cannot be selectively applied to 191 resources within an origin. 193 Alternative services do not replace or change the origin for any 194 given resource; in general, they are not visible to the software 195 "above" the access mechanism. The alternative service is essentially 196 alternative routing information that can also be used to reach the 197 origin in the same way that DNS CNAME or SRV records define routing 198 information at the name resolution level. Each origin maps to a set 199 of these routes -- the default route is derived from the origin 200 itself and the other routes are introduced based on alternative- 201 service information. 203 Furthermore, it is important to note that the first member of an 204 alternative service tuple is different from the "scheme" component of 205 an origin; it is more specific, identifying not only the major 206 version of the protocol being used, but potentially communication 207 options for that protocol. 209 This means that clients using an alternative service can change the 210 host, port and protocol that they are using to fetch resources, but 211 these changes MUST NOT be propagated to the application that is using 212 HTTP; from that standpoint, the URI being accessed and all 213 information derived from it (scheme, host, port) are the same as 214 before. 216 Importantly, this includes its security context; in particular, when 217 TLS [RFC5246] is used to authenticate, the alternative service will 218 need to present a certificate for the origin's host name, not that of 219 the alternative. Likewise, the Host header field ([RFC7230], Section 220 5.4) is still derived from the origin, not the alternative service 221 (just as it would if a CNAME were being used). 223 The changes MAY, however, be made visible in debugging tools, 224 consoles, etc. 226 Formally, an alternative service is identified by the combination of: 228 o An Application Layer Protocol Negotiation (ALPN) protocol name, as 229 per [RFC7301] 231 o A host, as per [RFC3986], Section 3.2.2 233 o A port, as per [RFC3986], Section 3.2.3 235 The ALPN protocol name is used to identify the application protocol 236 or suite of protocols used by the alternative service. Note that for 237 the purpose of this specification, an ALPN protocol name implicitly 238 includes TLS in the suite of protocols it identifies, unless 239 specified otherwise in its definition. In particular, the ALPN name 240 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 241 over TLS. 243 Additionally, each alternative service MUST have: 245 o A freshness lifetime, expressed in seconds; see Section 2.2 247 There are many ways that a client could discover the alternative 248 service(s) associated with an origin. This document describes two 249 such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the 250 "ALTSVC" HTTP/2 frame type (Section 4). 252 The remainder of this section describes requirements that are common 253 to alternative services, regardless of how they are discovered. 255 2.1. Host Authentication 257 Clients MUST have reasonable assurances that the alternative service 258 is under control of and valid for the whole origin. This mitigates 259 the attack described in Section 9.2. 261 For the purposes of this document, "reasonable assurances" can be 262 established through use of a TLS-based protocol with the certificate 263 checks defined in [RFC2818]. Other means of establishing them MUST 264 be documented in an RFC that updates this specification. Clients MAY 265 impose additional criteria for establishing reasonable assurances. 267 For example, if the origin's host is "www.example.com" and an 268 alternative is offered on "other.example.com" with the "h2" protocol, 269 and the certificate offered is valid for "www.example.com", the 270 client can use the alternative. However, if either is offered with 271 the "h2c" protocol, the client cannot use it, because there is no 272 mechanism (at the time of the publication of this specification) in 273 that protocol to establish the relationship between the origin and 274 the alternative. 276 2.2. Alternative Service Caching 278 Mechanisms for discovering alternative services also associate a 279 freshness lifetime with them; for example, the Alt-Svc header field 280 uses the "ma" parameter. 282 Clients can choose to use an alternative service instead of the 283 origin at any time when it is considered fresh; see Section 2.4 for 284 specific recommendations. 286 Clients with existing connections to an alternative service do not 287 need to stop using it when its freshness lifetime ends; the caching 288 mechanism is intended for limiting how long an alternative service 289 can be used for establishing new connections, not limiting the use of 290 existing ones. 292 Alternative services are fully authoritative for the origin in 293 question, including the ability to clear or update cached alternative 294 service entries, extend freshness lifetimes, and any other authority 295 the origin server would have. 297 When alternative services are used to send a client to the most 298 optimal server, a change in network configuration can result in 299 cached values becoming suboptimal. Therefore, clients SHOULD remove 300 from cache all alternative services that lack the "persist" flag with 301 the value "1" when they detect such a change, when information about 302 network state is available. 304 2.3. Requiring Server Name Indication 306 A client MUST only use a TLS-based alternative service if the client 307 also supports TLS Server Name Indication (SNI). This supports the 308 conservation of IP addresses on the alternative service host. 310 Note that the SNI information provided in TLS by the client will be 311 that of the origin, not the alternative (as will the Host HTTP header 312 field value). 314 2.4. Using Alternative Services 316 By their nature, alternative services are OPTIONAL: clients do not 317 need to use them. However, it is advantageous for clients to behave 318 in a predictable way when alternative services are used by servers, 319 to aid purposes like load balancing. 321 Therefore, if a client becomes aware of an alternative service, the 322 client SHOULD use that alternative service for all requests to the 323 associated origin as soon as it is available, provided the 324 alternative service information is fresh (Section 2.2) and the 325 security properties of the alternative service protocol are 326 desirable, as compared to the existing connection. A viable 327 alternative service is then treated in every way as the origin; this 328 includes the ability to advertise alternative services. 330 If a client becomes aware of multiple alternative services, it 331 chooses the most suitable according to its own criteria, keeping 332 security properties in mind. For example, an origin might advertise 333 multiple alternative services to notify clients of support for 334 multiple versions of HTTP. 336 A client configured to use a proxy for a given request SHOULD NOT 337 directly connect to an alternative service for this request, but 338 instead route it through that proxy. 340 When a client uses an alternative service for a request, it can 341 indicate this to the server using the Alt-Used header field 342 (Section 5). 344 The client does not need to block requests on any existing 345 connection; it can be used until the alternative connection is 346 established. However, if the security properties of the existing 347 connection are weak (for example, cleartext HTTP/1.1) then it might 348 make sense to block until the new connection is fully available in 349 order to avoid information leakage. 351 Furthermore, if the connection to the alternative service fails or is 352 unresponsive, the client MAY fall back to using the origin or another 353 alternative service. Note, however, that this could be the basis of 354 a downgrade attack, thus losing any enhanced security properties of 355 the alternative service. If the connection to the alternative 356 service does not negotiate the expected protocol (for example, ALPN 357 fails to negotiate h2, or an Upgrade request to h2c is not accepted), 358 the connection to the alternative service MUST be considered to have 359 failed. 361 3. The Alt-Svc HTTP Header Field 363 An HTTP(S) origin server can advertise the availability of 364 alternative services to clients by adding an Alt-Svc header field to 365 responses. 367 Alt-Svc = clear / 1#alt-value 368 clear = %s"clear"; "clear", case-sensitive 369 alt-value = alternative *( OWS ";" OWS parameter ) 370 alternative = protocol-id "=" alt-authority 371 protocol-id = token ; percent-encoded ALPN protocol name 372 alt-authority = quoted-string ; containing [ uri-host ] ":" port 373 parameter = token "=" ( token / quoted-string ) 375 The field value consists either of a list of values, each of which 376 indicates one alternative service, or the keyword "clear". 378 A field value containing the special value "clear" indicates that the 379 origin requests all alternatives for that origin to be invalidated 380 (including those specified in the same response, in case of an 381 invalid reply containing both "clear" and alternative services). 383 ALPN protocol names are octet sequences with no additional 384 constraints on format. Octets not allowed in tokens ([RFC7230], 385 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 386 [RFC3986]. Consequently, the octet representing the percent 387 character "%" (hex 25) MUST be percent-encoded as well. 389 In order to have precisely one way to represent any ALPN protocol 390 name, the following additional constraints apply: 392 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if 393 they are valid token characters except "%", and 395 2. When using percent-encoding, uppercase hex digits MUST be used. 397 With these constraints, recipients can apply simple string comparison 398 to match protocol identifiers. 400 The "alt-authority" component consists of an OPTIONAL uri-host 401 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 402 number. 404 For example: 406 Alt-Svc: h2=":8000" 408 This indicates the "h2" protocol ([RFC7540]) on the same host using 409 the indicated port 8000. 411 An example involving a change of host: 413 Alt-Svc: h2="new.example.org:80" 415 This indicates the "h2" protocol on the host "new.example.org", 416 running on port 80. Note that the "quoted-string" syntax needs to be 417 used because ":" is not an allowed character in "token". 419 Examples for protocol name escaping: 421 +--------------------+-------------+---------------------+ 422 | ALPN protocol name | protocol-id | Note | 423 +--------------------+-------------+---------------------+ 424 | h2 | h2 | No escaping needed | 425 +--------------------+-------------+---------------------+ 426 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 427 +--------------------+-------------+---------------------+ 428 | x%y | x%25y | "%" needs escaping | 429 +--------------------+-------------+---------------------+ 431 Alt-Svc MAY occur in any HTTP response message, regardless of the 432 status code. Note that recipients of Alt-Svc can ignore the header 433 field (and are required to in some situations; see Sections 2.1 and 434 6). 436 The Alt-Svc field value can have multiple values: 438 Alt-Svc: h2="alt.example.com:8000", h2=":443" 440 When multiple values are present, the order of the values reflects 441 the server's preference (with the first value being the most 442 preferred alternative). 444 The value(s) advertised by Alt-Svc can be used by clients to open a 445 new connection to an alternative service. Subsequent requests can 446 start using this new connection immediately, or can continue using 447 the existing connection while the new connection is created. 449 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC 450 frame (Section 4). A single ALTSVC frame can be sent for a 451 connection; a new frame is not needed for every request. Note that, 452 despite this recommendation, Alt-Svc header fields remain valid in 453 responses delivered over HTTP/2. 455 Each "alt-value" is followed by an OPTIONAL semicolon-separated list 456 of additional parameters, each such "parameter" comprising a name and 457 a value. 459 This specification defines two parameters: "ma" and "persist", 460 defined in Section 3.1. Unknown parameters MUST be ignored. That 461 is, the values (alt-value) they appear in MUST be processed as if the 462 unknown parameter was not present. 464 New parameters can be defined in extension specifications (see 465 Section 7.3 for registration details). 467 Note that all field elements that allow "quoted-string" syntax MUST 468 be processed as per Section 3.2.6 of [RFC7230]. 470 3.1. Caching Alt-Svc Header Field Values 472 When an alternative service is advertised using Alt-Svc, it is 473 considered fresh for 24 hours from generation of the message. This 474 can be modified with the 'ma' (max-age) parameter. 476 Syntax: 478 ma = delta-seconds; see [RFC7234], Section 1.2.1 480 The delta-seconds value indicates the number of seconds since the 481 response was generated the alternative service is considered fresh 482 for. 484 Alt-Svc: h2=":443"; ma=3600 486 See Section 4.2.3 of [RFC7234] for details of determining response 487 age. 489 For example, a response: 491 HTTP/1.1 200 OK 492 Content-Type: text/html 493 Cache-Control: max-age=600 494 Age: 30 495 Alt-Svc: h2=":8000"; ma=60 497 indicates that an alternative service is available and usable for the 498 next 60 seconds. However, the response has already been cached for 499 30 seconds (as per the Age header field value), so therefore the 500 alternative service is only fresh for the 30 seconds from when this 501 response was received, minus estimated transit time. 503 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 504 does not affect caching of Alt-Svc values. 506 When an Alt-Svc response header field is received from an origin, its 507 value invalidates and replaces all cached alternative services for 508 that origin. 510 By default, cached alternative services will be cleared when the 511 client detects a network change. Alternative services that are 512 intended to be longer-lived (such as those that are not specific to 513 the client access network) can carry the "persist" parameter with a 514 value "1" as a hint that the service is potentially useful beyond a 515 network configuration change. 517 Syntax: 519 persist = "1" 521 For example: 523 Alt-Svc: h2=":443"; ma=2592000; persist=1 525 This specification only defines a single value for "persist". 526 Clients MUST ignore "persist" parameters with values other than "1". 528 See Section 2.2 for general requirements on caching alternative 529 services. 531 4. The ALTSVC HTTP/2 Frame 533 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the 534 availability of an alternative service to an HTTP/2 client. 536 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 537 that do not support this frame will ignore it (as per the 538 extensibility rules defined in Section 4.1 of [RFC7540]). 540 An ALTSVC frame from a server to a client on a stream other than 541 stream 0 indicates that the conveyed alternative service is 542 associated with the origin of that stream. 544 An ALTSVC frame from a server to a client on stream 0 indicates that 545 the conveyed alternative service is associated with the origin 546 contained in the Origin field of the frame. An association with an 547 origin that the client does not consider authoritative for the 548 current connection MUST be ignored. 550 The ALTSVC frame type is 0xa (decimal 10). 552 +-------------------------------+-------------------------------+ 553 | Origin-Len (16) | Origin? (*) ... 554 +-------------------------------+-------------------------------+ 555 | Alt-Svc-Field-Value (*) ... 556 +---------------------------------------------------------------+ 558 ALTSVC Frame Payload 560 The ALTSVC frame contains the following fields: 562 Origin-Len: An unsigned, 16-bit integer indicating the length, in 563 octets, of the Origin field. 565 Origin: An OPTIONAL sequence of characters containing the ASCII 566 serialization of an origin ([RFC6454], Section 6.2) that the 567 alternative service is applicable to. 569 Alt-Svc-Field-Value: A sequence of octets (length determined by 570 subtracting the length of all preceding fields from the frame 571 length) containing a value identical to the Alt-Svc field value 572 defined in Section 3 (ABNF production "Alt-Svc"). 574 The ALTSVC frame does not define any flags. 576 The ALTSVC frame is intended for receipt by clients. A device acting 577 as a server MUST ignore it. 579 An ALTSVC frame on stream 0 with empty (length 0) "Origin" 580 information is invalid and MUST be ignored. An ALTSVC frame on a 581 stream other than stream 0 containing non-empty "Origin" information 582 is invalid and MUST be ignored. 584 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 585 forward ALTSVC frames, though it can use the information contained in 586 ALTSVC frames in forming new ALTSVC frames to send to its own 587 clients. 589 Receiving an ALTSVC frame is semantically equivalent to receiving an 590 Alt-Svc header field. As a result, the ALTSVC frame causes 591 alternative services for the corresponding origin to be replaced. 592 Note that it would be unwise to mix the use of Alt-Svc header fields 593 with the use of ALTSVC frames, as the sequence of receipt might be 594 hard to predict. 596 5. The Alt-Used HTTP Header Field 598 The Alt-Used header field is used in requests to indicate the 599 identity of the alternative service in use, just as the Host header 600 field (Section 5.4 of [RFC7230]) identifies the host and port of the 601 origin. 603 Alt-Used = uri-host [ ":" port ] 605 Alt-Used is intended to allow alternative services to detect loops, 606 differentiate traffic for purposes of load balancing, and generally 607 to ensure that it is possible to identify the intended destination of 608 traffic, since introducing this information after a protocol is in 609 use has proven to be problematic. 611 When using an alternative service, clients SHOULD include an Alt-Used 612 header field in all requests. 614 For example: 616 GET /thing HTTP/1.1 617 Host: origin.example.com 618 Alt-Used: alternate.example.net 620 6. The 421 Misdirected Request HTTP Status Code 622 The 421 (Misdirected Request) status code is defined in Section 9.1.2 623 of [RFC7540] to indicate that the current server instance is not 624 authoritative for the requested resource. This can be used to 625 indicate that an alternative service is not authoritative; see 626 Section 2). 628 Clients receiving 421 (Misdirected Request) from an alternative 629 service MUST remove the corresponding entry from its alternative 630 service cache (see Section 2.2) for that origin. Regardless of the 631 idempotency of the request method, they MAY retry the request, either 632 at another alternative server, or at the origin. 634 An Alt-Svc header field in a 421 (Misdirected Request) response MUST 635 be ignored. 637 7. IANA Considerations 639 7.1. Header Field Registrations 641 HTTP header fields are registered within the "Message Headers" 642 registry maintained at 643 . 645 This document defines the following HTTP header fields, so their 646 associated registry entries shall be added according to the permanent 647 registrations below (see [BCP90]): 649 +-------------------+----------+----------+-----------+ 650 | Header Field Name | Protocol | Status | Reference | 651 +-------------------+----------+----------+-----------+ 652 | Alt-Svc | http | standard | Section 3 | 653 | Alt-Used | http | standard | Section 5 | 654 +-------------------+----------+----------+-----------+ 656 The change controller is: "IETF (iesg@ietf.org) - Internet 657 Engineering Task Force". 659 7.2. The ALTSVC HTTP/2 Frame Type 661 This document registers the ALTSVC frame type in the HTTP/2 Frame 662 Types registry ([RFC7540], Section 11.2). 664 Frame Type: ALTSVC 666 Code: 0xa 668 Specification: Section 4 of this document 670 7.3. Alt-Svc Parameter Registry 672 The HTTP Alt-Svc Parameter Registry defines the name space for 673 parameters. It will be created and maintained at (the suggested URI) 674 . 676 7.3.1. Procedure 678 A registration MUST include the following fields: 680 o Parameter Name 681 o Pointer to specification text 683 Values to be added to this name space require Expert Review (see 684 [RFC5226], Section 4.1). 686 7.3.2. Registrations 688 The HTTP Alt-Svc Parameter Registry is to be populated with the 689 registrations below: 691 +-------------------+-------------+ 692 | Alt-Svc Parameter | Reference | 693 +-------------------+-------------+ 694 | ma | Section 3.1 | 695 | persist | Section 3.1 | 696 +-------------------+-------------+ 698 8. Internationalization Considerations 700 An internationalized domain name that appears in either the header 701 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 702 using A-labels ([RFC5890], Section 2.3.2.1). 704 9. Security Considerations 706 9.1. Changing Ports 708 Using an alternative service implies accessing an origin's resources 709 on an alternative port, at a minimum. An attacker that can inject 710 alternative services and listen at the advertised port is therefore 711 able to hijack an origin. On certain servers, it is normal for users 712 to be able to control some personal pages available on a shared port, 713 and also to accept to requests on less-privileged ports. 715 For example, an attacker that can add HTTP response header fields to 716 some pages can redirect traffic for an entire origin to a different 717 port on the same host using the Alt-Svc header field; if that port is 718 under the attacker's control, they can thus masquerade as the HTTP 719 server. 721 This risk is mitigated by the requirements in Section 2.1. 723 On servers, this risk can also be reduced by restricting the ability 724 to advertise alternative services, and restricting who can open a 725 port for listening on that host. 727 9.2. Changing Hosts 729 When the host is changed due to the use of an alternative service, it 730 presents an opportunity for attackers to hijack communication to an 731 origin. 733 For example, if an attacker can convince a user agent to send all 734 traffic for "innocent.example.org" to "evil.example.com" by 735 successfully associating it as an alternative service, they can 736 masquerade as that origin. This can be done locally (see mitigations 737 in Section 9.1) or remotely (e.g., by an intermediary as a man-in- 738 the-middle attack). 740 This is the reason for the requirement in Section 2.1 that clients 741 have reasonable assurances that the alternative service is under 742 control of and valid for the whole origin; presenting a certificate 743 for the origin proves that the alternative service is authorized to 744 serve traffic for the origin. 746 Note that this assurance is only as strong as the method used to 747 authenticate the alternative service. In particular, when TLS 748 authentication is used to do so, there are well-known exploits to 749 make an attacker's certificate appear as legitimate. 751 Alternative services could be used to persist such an attack. For 752 example, an intermediary could man-in-the-middle TLS-protected 753 communication to a target, and then direct all traffic to an 754 alternative service with a large freshness lifetime, so that the user 755 agent still directs traffic to the attacker even when not using the 756 intermediary. 758 Implementations MUST perform any certificate-pinning validation (such 759 as [RFC7469]) on alternative services just as they would on direct 760 connections to the origin. Implementations might also choose to add 761 other requirements around which certificates are acceptable for 762 alternative services. 764 9.3. Changing Protocols 766 When the ALPN protocol is changed due to the use of an alternative 767 service, the security properties of the new connection to the origin 768 can be different from that of the "normal" connection to the origin, 769 because the protocol identifier itself implies this. 771 For example, if an "https://" URI has a protocol advertised that does 772 not use some form of end-to-end encryption (most likely, TLS), it 773 violates the expectations for security that the URI scheme implies. 774 Therefore, clients cannot blindly use alternative services, but 775 instead evaluate the option(s) presented to assure that security 776 requirements and expectations of specifications, implementations and 777 end users are met. 779 9.4. Tracking Clients Using Alternative Services 781 Choosing an alternative service implies connecting to a new, server- 782 supplied host name. By using unique names, servers could conceivably 783 track client requests. Such tracking could follow users across 784 multiple networks, when the "persist" flag is used. 786 Clients that wish to prevent requests from being correlated 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 (typically, when cookies 792 [RFC6265] are 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 (for example, cookies and 811 content) that is intended for a secure context (such as an "https://" 812 URI) to a 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 (such as ":scheme" in HTTP/2 or 816 the "absolute form" of the request target in HTTP/1.1) as an 817 indication of security context, instead of other connection 818 properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 820 When the protocol does not explicitly carry the scheme (as is usually 821 the case for HTTP/1.1 over TLS), servers can mitigate this risk by 822 either assuming that all requests have an insecure context, or by 823 refraining from advertising alternative services for insecure 824 schemes, for example 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 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 836 RFC2818, May 2000, 837 . 839 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 840 Resource Identifier (URI): Generic Syntax", STD 66, 841 RFC 3986, DOI 10.17487/RFC3986, January 2005, 842 . 844 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 845 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 846 DOI 10.17487/RFC5226, May 2008, 847 . 849 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 850 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 851 RFC5234, January 2008, 852 . 854 [RFC5890] Klensin, J., "Internationalized Domain Names for 855 Applications (IDNA): Definitions and Document Framework", 856 RFC 5890, DOI 10.17487/RFC5890, August 2010, 857 . 859 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 860 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, 861 January 2011, . 863 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 864 DOI 10.17487/RFC6454, December 2011, 865 . 867 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 868 Protocol (HTTP/1.1): Message Syntax and Routing", 869 RFC 7230, DOI 10.17487/RFC7230, June 2014, 870 . 872 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 873 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 874 RFC 7234, DOI 10.17487/RFC7234, June 2014, 875 . 877 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, 878 "Transport Layer Security (TLS) Application-Layer Protocol 879 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 880 July 2014, . 882 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 883 RFC 7405, DOI 10.17487/RFC7405, December 2014, 884 . 886 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 887 Transfer Protocol version 2", RFC 7540, DOI 10.17487/ 888 RFC7540, May 2015, 889 . 891 10.2. Informative References 893 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 894 Procedures for Message Header Fields", BCP 90, RFC 3864, 895 September 2004, . 897 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 898 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 899 RFC5246, August 2008, 900 . 902 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 903 DOI 10.17487/RFC6265, April 2011, 904 . 906 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 907 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 908 April 2015, . 910 Appendix A. Change Log (to be removed by RFC Editor before publication) 912 A.1. Since draft-nottingham-httpbis-alt-svc-05 914 This is the first version after adoption of 915 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 916 only contains editorial changes. 918 A.2. Since draft-ietf-httpbis-alt-svc-00 920 Selected 421 as proposed status code for "Not Authoritative". 922 Changed header field syntax to use percent-encoding of ALPN protocol 923 names (). 925 A.3. Since draft-ietf-httpbis-alt-svc-01 927 Updated HTTP/1.1 references. 929 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 930 to address fingerprinting concerns 931 (). 933 Note that ALTSVC frame is preferred to Alt-Svc header field 934 (). 936 Incorporate ALTSRV frame 937 (). 939 Moved definition of status code 421 to HTTP/2. 941 Partly resolved . 943 A.4. Since draft-ietf-httpbis-alt-svc-02 945 Updated ALPN reference. 947 Resolved . 949 A.5. Since draft-ietf-httpbis-alt-svc-03 951 Renamed "Alt-Svc-Used" to "Alt-Used" 952 (). 954 Clarify ALTSVC Origin information requirements 955 (). 957 Remove/tune language with respect to tracking risks (see 958 ). 960 A.6. Since draft-ietf-httpbis-alt-svc-04 962 Mention tracking by alt-svc host name in Security Considerations 963 (). 965 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 967 Allow the frame to carry multiple indicator and use the same payload 968 formats for both 969 (). 971 A.7. Since draft-ietf-httpbis-alt-svc-05 973 Go back to specifying the origin in Alt-Used, but make it a "SHOULD" 974 (). 976 Restore Origin field in ALT-SVC frame 977 (). 979 A.8. Since draft-ietf-httpbis-alt-svc-06 981 Disallow use of alternative services when the protocol might not 982 carry the scheme 983 (). 985 Align opp-sec and alt-svc 986 (). 988 alt svc frame on pushed (even and non-0) frame 989 (). 991 "browser" -> "user agent" 992 (). 994 ABNF for "parameter" 995 (). 997 Updated HTTP/2 reference. 999 A.9. Since draft-ietf-httpbis-alt-svc-07 1001 Alt-Svc alternative cache invalidation 1002 (). 1004 Unexpected Alt-Svc frames 1005 (). 1007 Associating Alt-Svc header with an origin 1008 (). 1010 ALPN identifiers in Alt-Svc 1011 (). 1013 Number of alternate services used 1014 (). 1016 Proxy and .pac interaction 1017 (). 1019 Need to define extensibility for alt-svc parameters 1020 (). 1022 Persistence of alternates across network changes 1023 (). 1025 Alt-Svc header with 421 status 1026 (). 1028 Incorporate several editorial improvements suggested by Mike Bishop 1029 (, 1030 ). 1032 Alt-Svc response header field in HTTP/2 frame 1033 (). 1035 A.10. Since draft-ietf-httpbis-alt-svc-08 1037 Remove left over text about ext-params, applying to an earlier 1038 version of Alt-Used (see 1039 ). 1041 Conflicts between Alt-Svc and ALPN 1042 (). 1044 Elevation of privilege 1045 (). 1047 Alternates of alternates 1048 (). 1050 Alt-Svc and Cert Pinning 1051 (). 1053 Using alt-svc on localhost (no change to spec, see 1054 ). 1056 IANA procedure for alt-svc parameters 1057 (). 1059 Alt-svc from https (1.1) to https (1.1) 1060 (). 1062 Alt-svc vs the ability to convey the scheme inside the protocol 1063 (). 1065 Reconciling MAY/can vs. SHOULD 1066 (). 1068 Typo in alt-svc caching example 1069 (). 1071 A.11. Since draft-ietf-httpbis-alt-svc-09 1073 Editorial improvements 1074 (, 1075 , 1076 , 1077 , 1078 , 1079 , 1080 , 1081 ). 1083 A.12. Since draft-ietf-httpbis-alt-svc-10 1085 Editorial improvements 1086 (). 1088 Use RFC 7405 ABNF extension 1089 (). 1091 A.13. Since draft-ietf-httpbis-alt-svc-11 1093 Security considerations wrt system ports 1094 (). 1096 A.14. Since draft-ietf-httpbis-alt-svc-12 1098 Editorial changes triggered by . 1101 Reasonable Assurances and H2C 1102 (). 1104 Appendix B. Acknowledgements 1106 Thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik 1107 Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, 1108 Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard 1109 Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their 1110 feedback and suggestions. 1112 The Alt-Svc header field was influenced by the design of the 1113 Alternate-Protocol header field in SPDY. 1115 Authors' Addresses 1117 Mark Nottingham 1118 Akamai 1120 EMail: mnot@mnot.net 1121 URI: https://www.mnot.net/ 1123 Patrick McManus 1124 Mozilla 1126 EMail: mcmanus@ducksong.com 1127 URI: https://mozillians.org/u/pmcmanus/ 1129 Julian F. Reschke 1130 greenbytes GmbH 1132 EMail: julian.reschke@greenbytes.de 1133 URI: https://greenbytes.de/tech/webdav/