idnits 2.17.1 draft-ietf-httpbis-alt-svc-14.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 8, 2016) is 2969 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 9, 2016 Mozilla 6 J. Reschke 7 greenbytes 8 March 8, 2016 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-14 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 9, 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]. Clients MAY impose additional criteria 264 for establishing reasonable assurances. 266 For example, if the origin's host is "www.example.com" and an 267 alternative is offered on "other.example.com" with the "h2" protocol, 268 and the certificate offered is valid for "www.example.com", the 269 client can use the alternative. However, if either is offered with 270 the "h2c" protocol, the client cannot use it, because there is no 271 mechanism (at the time of the publication of this specification) in 272 that protocol to establish the relationship between the origin and 273 the alternative. 275 2.2. Alternative Service Caching 277 Mechanisms for discovering alternative services also associate a 278 freshness lifetime with them; for example, the Alt-Svc header field 279 uses the "ma" parameter. 281 Clients can choose to use an alternative service instead of the 282 origin at any time when it is considered fresh; see Section 2.4 for 283 specific recommendations. 285 Clients with existing connections to an alternative service do not 286 need to stop using it when its freshness lifetime ends; the caching 287 mechanism is intended for limiting how long an alternative service 288 can be used for establishing new connections, not limiting the use of 289 existing ones. 291 Alternative services are fully authoritative for the origin in 292 question, including the ability to clear or update cached alternative 293 service entries, extend freshness lifetimes, and any other authority 294 the origin server would have. 296 When alternative services are used to send a client to the most 297 optimal server, a change in network configuration can result in 298 cached values becoming suboptimal. Therefore, clients SHOULD remove 299 from cache all alternative services that lack the "persist" flag with 300 the value "1" when they detect such a change, when information about 301 network state is available. 303 2.3. Requiring Server Name Indication 305 A client MUST NOT use a TLS-based alternative service unless the 306 client supports TLS Server Name Indication (SNI). This supports the 307 conservation of IP addresses on the alternative service host. 309 Note that the SNI information provided in TLS by the client will be 310 that of the origin, not the alternative (as will the Host HTTP header 311 field value). 313 2.4. Using Alternative Services 315 By their nature, alternative services are OPTIONAL: clients do not 316 need to use them. However, it is advantageous for clients to behave 317 in a predictable way when alternative services are used by servers, 318 to aid purposes like load balancing. 320 Therefore, if a client supporting this specification becomes aware of 321 an alternative service, the client SHOULD use that alternative 322 service for all requests to the associated origin as soon as it is 323 available, provided the alternative service information is fresh 324 (Section 2.2) and the security properties of the alternative service 325 protocol are desirable, as compared to the existing connection. A 326 viable alternative service is then treated in every way as the 327 origin; this includes the ability to advertise alternative services. 329 If a client becomes aware of multiple alternative services, it 330 chooses the most suitable according to its own criteria, keeping 331 security properties in mind. For example, an origin might advertise 332 multiple alternative services to notify clients of support for 333 multiple versions of HTTP. 335 A client configured to use a proxy for a given request SHOULD NOT 336 directly connect to an alternative service for this request, but 337 instead route it through that proxy. 339 When a client uses an alternative service for a request, it can 340 indicate this to the server using the Alt-Used header field 341 (Section 5). 343 The client does not need to block requests on any existing 344 connection; it can be used until the alternative connection is 345 established. However, if the security properties of the existing 346 connection are weak (for example, cleartext HTTP/1.1) then it might 347 make sense to block until the new connection is fully available in 348 order to avoid information leakage. 350 Furthermore, if the connection to the alternative service fails or is 351 unresponsive, the client MAY fall back to using the origin or another 352 alternative service. Note, however, that this could be the basis of 353 a downgrade attack, thus losing any enhanced security properties of 354 the alternative service. If the connection to the alternative 355 service does not negotiate the expected protocol (for example, ALPN 356 fails to negotiate h2, or an Upgrade request to h2c is not accepted), 357 the connection to the alternative service MUST be considered to have 358 failed. 360 3. The Alt-Svc HTTP Header Field 362 An HTTP(S) origin server can advertise the availability of 363 alternative services to clients by adding an Alt-Svc header field to 364 responses. 366 Alt-Svc = clear / 1#alt-value 367 clear = %s"clear"; "clear", case-sensitive 368 alt-value = alternative *( OWS ";" OWS parameter ) 369 alternative = protocol-id "=" alt-authority 370 protocol-id = token ; percent-encoded ALPN protocol name 371 alt-authority = quoted-string ; containing [ uri-host ] ":" port 372 parameter = token "=" ( token / quoted-string ) 374 The field value consists either of a list of values, each of which 375 indicates one alternative service, or the keyword "clear". 377 A field value containing the special value "clear" indicates that the 378 origin requests all alternatives for that origin to be invalidated 379 (including those specified in the same response, in case of an 380 invalid reply containing both "clear" and alternative services). 382 ALPN protocol names are octet sequences with no additional 383 constraints on format. Octets not allowed in tokens ([RFC7230], 384 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 385 [RFC3986]. Consequently, the octet representing the percent 386 character "%" (hex 25) MUST be percent-encoded as well. 388 In order to have precisely one way to represent any ALPN protocol 389 name, the following additional constraints apply: 391 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if 392 they are valid token characters except "%", and 394 2. When using percent-encoding, uppercase hex digits MUST be used. 396 With these constraints, recipients can apply simple string comparison 397 to match protocol identifiers. 399 The "alt-authority" component consists of an OPTIONAL uri-host 400 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 401 number. 403 For example: 405 Alt-Svc: h2=":8000" 407 This indicates the "h2" protocol ([RFC7540]) on the same host using 408 the indicated port 8000. 410 An example involving a change of host: 412 Alt-Svc: h2="new.example.org:80" 414 This indicates the "h2" protocol on the host "new.example.org", 415 running on port 80. Note that the "quoted-string" syntax needs to be 416 used because ":" is not an allowed character in "token". 418 Examples for protocol name escaping: 420 +--------------------+-------------+---------------------+ 421 | ALPN protocol name | protocol-id | Note | 422 +--------------------+-------------+---------------------+ 423 | h2 | h2 | No escaping needed | 424 +--------------------+-------------+---------------------+ 425 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 426 +--------------------+-------------+---------------------+ 427 | x%y | x%25y | "%" needs escaping | 428 +--------------------+-------------+---------------------+ 430 Alt-Svc MAY occur in any HTTP response message, regardless of the 431 status code. Note that recipients of Alt-Svc can ignore the header 432 field (and are required to in some situations; see Sections 2.1 and 433 6). 435 The Alt-Svc field value can have multiple values: 437 Alt-Svc: h2="alt.example.com:8000", h2=":443" 439 When multiple values are present, the order of the values reflects 440 the server's preference (with the first value being the most 441 preferred alternative). 443 The value(s) advertised by Alt-Svc can be used by clients to open a 444 new connection to an alternative service. Subsequent requests can 445 start using this new connection immediately, or can continue using 446 the existing connection while the new connection is created. 448 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC 449 frame (Section 4). A single ALTSVC frame can be sent for a 450 connection; a new frame is not needed for every request. Note that, 451 despite this recommendation, Alt-Svc header fields remain valid in 452 responses delivered over HTTP/2. 454 Each "alt-value" is followed by an OPTIONAL semicolon-separated list 455 of additional parameters, each such "parameter" comprising a name and 456 a value. 458 This specification defines two parameters: "ma" and "persist", 459 defined in Section 3.1. Unknown parameters MUST be ignored. That 460 is, the values (alt-value) they appear in MUST be processed as if the 461 unknown parameter was not present. 463 New parameters can be defined in extension specifications (see 464 Section 7.3 for registration details). 466 Note that all field elements that allow "quoted-string" syntax MUST 467 be processed as per Section 3.2.6 of [RFC7230]. 469 3.1. Caching Alt-Svc Header Field Values 471 When an alternative service is advertised using Alt-Svc, it is 472 considered fresh for 24 hours from generation of the message. This 473 can be modified with the 'ma' (max-age) parameter. 475 Syntax: 477 ma = delta-seconds; see [RFC7234], Section 1.2.1 479 The delta-seconds value indicates the number of seconds since the 480 response was generated the alternative service is considered fresh 481 for. 483 Alt-Svc: h2=":443"; ma=3600 485 See Section 4.2.3 of [RFC7234] for details of determining response 486 age. 488 For example, a response: 490 HTTP/1.1 200 OK 491 Content-Type: text/html 492 Cache-Control: max-age=600 493 Age: 30 494 Alt-Svc: h2=":8000"; ma=60 496 indicates that an alternative service is available and usable for the 497 next 60 seconds. However, the response has already been cached for 498 30 seconds (as per the Age header field value), so therefore the 499 alternative service is only fresh for the 30 seconds from when this 500 response was received, minus estimated transit time. 502 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 503 does not affect caching of Alt-Svc values. 505 When an Alt-Svc response header field is received from an origin, its 506 value invalidates and replaces all cached alternative services for 507 that origin. 509 By default, cached alternative services will be cleared when the 510 client detects a network change. Alternative services that are 511 intended to be longer-lived (such as those that are not specific to 512 the client access network) can carry the "persist" parameter with a 513 value "1" as a hint that the service is potentially useful beyond a 514 network configuration change. 516 Syntax: 518 persist = "1" 520 For example: 522 Alt-Svc: h2=":443"; ma=2592000; persist=1 524 This specification only defines a single value for "persist". 525 Clients MUST ignore "persist" parameters with values other than "1". 527 See Section 2.2 for general requirements on caching alternative 528 services. 530 4. The ALTSVC HTTP/2 Frame 532 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the 533 availability of an alternative service to an HTTP/2 client. 535 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 536 that do not support this frame will ignore it (as per the 537 extensibility rules defined in Section 4.1 of [RFC7540]). 539 An ALTSVC frame from a server to a client on a stream other than 540 stream 0 indicates that the conveyed alternative service is 541 associated with the origin of that stream. 543 An ALTSVC frame from a server to a client on stream 0 indicates that 544 the conveyed alternative service is associated with the origin 545 contained in the Origin field of the frame. An association with an 546 origin that the client does not consider authoritative for the 547 current connection MUST be ignored. 549 The ALTSVC frame type is 0xa (decimal 10). 551 +-------------------------------+-------------------------------+ 552 | Origin-Len (16) | Origin? (*) ... 553 +-------------------------------+-------------------------------+ 554 | Alt-Svc-Field-Value (*) ... 555 +---------------------------------------------------------------+ 557 ALTSVC Frame Payload 559 The ALTSVC frame contains the following fields: 561 Origin-Len: An unsigned, 16-bit integer indicating the length, in 562 octets, of the Origin field. 564 Origin: An OPTIONAL sequence of characters containing the ASCII 565 serialization of an origin ([RFC6454], Section 6.2) that the 566 alternative service is applicable to. 568 Alt-Svc-Field-Value: A sequence of octets (length determined by 569 subtracting the length of all preceding fields from the frame 570 length) containing a value identical to the Alt-Svc field value 571 defined in Section 3 (ABNF production "Alt-Svc"). 573 The ALTSVC frame does not define any flags. 575 The ALTSVC frame is intended for receipt by clients. A device acting 576 as a server MUST ignore it. 578 An ALTSVC frame on stream 0 with empty (length 0) "Origin" 579 information is invalid and MUST be ignored. An ALTSVC frame on a 580 stream other than stream 0 containing non-empty "Origin" information 581 is invalid and MUST be ignored. 583 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 584 forward ALTSVC frames, though it can use the information contained in 585 ALTSVC frames in forming new ALTSVC frames to send to its own 586 clients. 588 Receiving an ALTSVC frame is semantically equivalent to receiving an 589 Alt-Svc header field. As a result, the ALTSVC frame causes 590 alternative services for the corresponding origin to be replaced. 591 Note that it would be unwise to mix the use of Alt-Svc header fields 592 with the use of ALTSVC frames, as the sequence of receipt might be 593 hard to predict. 595 5. The Alt-Used HTTP Header Field 597 The Alt-Used header field is used in requests to indicate the 598 identity of the alternative service in use, just as the Host header 599 field (Section 5.4 of [RFC7230]) identifies the host and port of the 600 origin. 602 Alt-Used = uri-host [ ":" port ] 604 Alt-Used is intended to allow alternative services to detect loops, 605 differentiate traffic for purposes of load balancing, and generally 606 to ensure that it is possible to identify the intended destination of 607 traffic, since introducing this information after a protocol is in 608 use has proven to be problematic. 610 When using an alternative service, clients SHOULD include an Alt-Used 611 header field in all requests. 613 For example: 615 GET /thing HTTP/1.1 616 Host: origin.example.com 617 Alt-Used: alternate.example.net 619 6. The 421 Misdirected Request HTTP Status Code 621 The 421 (Misdirected Request) status code is defined in Section 9.1.2 622 of [RFC7540] to indicate that the current server instance is not 623 authoritative for the requested resource. This can be used to 624 indicate that an alternative service is not authoritative; see 625 Section 2). 627 Clients receiving 421 (Misdirected Request) from an alternative 628 service MUST remove the corresponding entry from its alternative 629 service cache (see Section 2.2) for that origin. Regardless of the 630 idempotency of the request method, they MAY retry the request, either 631 at another alternative server, or at the origin. 633 An Alt-Svc header field in a 421 (Misdirected Request) response MUST 634 be ignored. 636 7. IANA Considerations 638 7.1. Header Field Registrations 640 HTTP header fields are registered within the "Message Headers" 641 registry maintained at 642 . 644 This document defines the following HTTP header fields, so their 645 associated registry entries shall be added according to the permanent 646 registrations below (see [BCP90]): 648 +-------------------+----------+----------+-----------+ 649 | Header Field Name | Protocol | Status | Reference | 650 +-------------------+----------+----------+-----------+ 651 | Alt-Svc | http | standard | Section 3 | 652 | Alt-Used | http | standard | Section 5 | 653 +-------------------+----------+----------+-----------+ 655 The change controller is: "IETF (iesg@ietf.org) - Internet 656 Engineering Task Force". 658 7.2. The ALTSVC HTTP/2 Frame Type 660 This document registers the ALTSVC frame type in the HTTP/2 Frame 661 Types registry ([RFC7540], Section 11.2). 663 Frame Type: ALTSVC 665 Code: 0xa 667 Specification: Section 4 of this document 669 7.3. Alt-Svc Parameter Registry 671 The HTTP Alt-Svc Parameter Registry defines the name space for 672 parameters. It will be created and maintained at (the suggested URI) 673 . 675 7.3.1. Procedure 677 A registration MUST include the following fields: 679 o Parameter Name 680 o Pointer to specification text 682 Values to be added to this name space require Expert Review (see 683 [RFC5226], Section 4.1). 685 7.3.2. Registrations 687 The HTTP Alt-Svc Parameter Registry is to be populated with the 688 registrations below: 690 +-------------------+-------------+ 691 | Alt-Svc Parameter | Reference | 692 +-------------------+-------------+ 693 | ma | Section 3.1 | 694 | persist | Section 3.1 | 695 +-------------------+-------------+ 697 8. Internationalization Considerations 699 An internationalized domain name that appears in either the header 700 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 701 using A-labels ([RFC5890], Section 2.3.2.1). 703 9. Security Considerations 705 9.1. Changing Ports 707 Using an alternative service implies accessing an origin's resources 708 on an alternative port, at a minimum. An attacker that can inject 709 alternative services and listen at the advertised port is therefore 710 able to hijack an origin. On certain servers, it is normal for users 711 to be able to control some personal pages available on a shared port, 712 and also to accept to requests on less-privileged ports. 714 For example, an attacker that can add HTTP response header fields to 715 some pages can redirect traffic for an entire origin to a different 716 port on the same host using the Alt-Svc header field; if that port is 717 under the attacker's control, they can thus masquerade as the HTTP 718 server. 720 This risk is mitigated by the requirements in Section 2.1. 722 On servers, this risk can also be reduced by restricting the ability 723 to advertise alternative services, and restricting who can open a 724 port for listening on that host. 726 9.2. Changing Hosts 728 When the host is changed due to the use of an alternative service, it 729 presents an opportunity for attackers to hijack communication to an 730 origin. 732 For example, if an attacker can convince a user agent to send all 733 traffic for "innocent.example.org" to "evil.example.com" by 734 successfully associating it as an alternative service, they can 735 masquerade as that origin. This can be done locally (see mitigations 736 in Section 9.1) or remotely (e.g., by an intermediary as a man-in- 737 the-middle attack). 739 This is the reason for the requirement in Section 2.1 that clients 740 have reasonable assurances that the alternative service is under 741 control of and valid for the whole origin; for example, presenting a 742 certificate for the origin proves that the alternative service is 743 authorized to serve traffic for the origin. 745 Note that this assurance is only as strong as the method used to 746 authenticate the alternative service. In particular, when TLS 747 authentication is used to do so, there are well-known exploits to 748 make an attacker's certificate appear as legitimate. 750 Alternative services could be used to persist such an attack. For 751 example, an intermediary could man-in-the-middle TLS-protected 752 communication to a target, and then direct all traffic to an 753 alternative service with a large freshness lifetime, so that the user 754 agent still directs traffic to the attacker even when not using the 755 intermediary. 757 Implementations MUST perform any certificate-pinning validation (such 758 as [RFC7469]) on alternative services just as they would on direct 759 connections to the origin. Implementations might also choose to add 760 other requirements around which certificates are acceptable for 761 alternative services. 763 9.3. Changing Protocols 765 When the ALPN protocol is changed due to the use of an alternative 766 service, the security properties of the new connection to the origin 767 can be different from that of the "normal" connection to the origin, 768 because the protocol identifier itself implies this. 770 For example, if an "https://" URI has a protocol advertised that does 771 not use some form of end-to-end encryption (most likely, TLS), it 772 violates the expectations for security that the URI scheme implies. 773 Therefore, clients cannot blindly use alternative services, but 774 instead evaluate the option(s) presented to assure that security 775 requirements and expectations of specifications, implementations and 776 end users are met. 778 9.4. Tracking Clients Using Alternative Services 780 Choosing an alternative service implies connecting to a new, server- 781 supplied host name. By using unique names, servers could conceivably 782 track client requests. Such tracking could follow users across 783 multiple networks, when the "persist" flag is used. 785 Clients that wish to prevent requests from being correlated can 786 decide not to use alternative services for multiple requests that 787 would not otherwise be allowed to be correlated. 789 In a user agent, any alternative service information MUST be removed 790 when origin-specific data is cleared (typically, when cookies 791 [RFC6265] are cleared). 793 9.5. Confusion Regarding Request Scheme 795 Some server-side HTTP applications make assumptions about security 796 based upon connection context; for example, equating being served 797 upon port 443 with the use of an "https://" URI and the various 798 security properties that implies. 800 This affects not only the security properties of the connection 801 itself, but also the state of the client at the other end of it; for 802 example, a Web browser treats "https://" URIs differently than 803 "http://" URIs in many ways, not just for purposes of protocol 804 handling. 806 Since one of the uses of Alternative Services is to allow a 807 connection to be migrated to a different protocol and port, these 808 applications can become confused about the security properties of a 809 given connection, sending information (for example, cookies and 810 content) that is intended for a secure context (such as an "https://" 811 URI) to a client that is not treating it as one. 813 This risk can be mitigated in servers by using the URI scheme 814 explicitly carried by the protocol (such as ":scheme" in HTTP/2 or 815 the "absolute form" of the request target in HTTP/1.1) as an 816 indication of security context, instead of other connection 817 properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 819 When the protocol does not explicitly carry the scheme (as is usually 820 the case for HTTP/1.1 over TLS), servers can mitigate this risk by 821 either assuming that all requests have an insecure context, or by 822 refraining from advertising alternative services for insecure schemes 823 (for example, HTTP). 825 10. References 827 10.1. Normative References 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 831 RFC2119, March 1997, 832 . 834 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 835 RFC2818, May 2000, 836 . 838 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 839 Resource Identifier (URI): Generic Syntax", STD 66, 840 RFC 3986, DOI 10.17487/RFC3986, January 2005, 841 . 843 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 844 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 845 DOI 10.17487/RFC5226, May 2008, 846 . 848 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 849 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 850 RFC5234, January 2008, 851 . 853 [RFC5890] Klensin, J., "Internationalized Domain Names for 854 Applications (IDNA): Definitions and Document Framework", 855 RFC 5890, DOI 10.17487/RFC5890, August 2010, 856 . 858 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 859 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, 860 January 2011, . 862 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 863 DOI 10.17487/RFC6454, December 2011, 864 . 866 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 867 Protocol (HTTP/1.1): Message Syntax and Routing", 868 RFC 7230, DOI 10.17487/RFC7230, June 2014, 869 . 871 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 872 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 873 RFC 7234, DOI 10.17487/RFC7234, June 2014, 874 . 876 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, 877 "Transport Layer Security (TLS) Application-Layer Protocol 878 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 879 July 2014, . 881 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 882 RFC 7405, DOI 10.17487/RFC7405, December 2014, 883 . 885 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 886 Transfer Protocol version 2", RFC 7540, DOI 10.17487/ 887 RFC7540, May 2015, 888 . 890 10.2. Informative References 892 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 893 Procedures for Message Header Fields", BCP 90, RFC 3864, 894 September 2004, . 896 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 897 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 898 RFC5246, August 2008, 899 . 901 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 902 DOI 10.17487/RFC6265, April 2011, 903 . 905 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 906 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 907 April 2015, . 909 Appendix A. Change Log (to be removed by RFC Editor before publication) 911 A.1. Since draft-nottingham-httpbis-alt-svc-05 913 This is the first version after adoption of 914 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 915 only contains editorial changes. 917 A.2. Since draft-ietf-httpbis-alt-svc-00 919 Selected 421 as proposed status code for "Not Authoritative". 921 Changed header field syntax to use percent-encoding of ALPN protocol 922 names (). 924 A.3. Since draft-ietf-httpbis-alt-svc-01 926 Updated HTTP/1.1 references. 928 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 929 to address fingerprinting concerns 930 (). 932 Note that ALTSVC frame is preferred to Alt-Svc header field 933 (). 935 Incorporate ALTSRV frame 936 (). 938 Moved definition of status code 421 to HTTP/2. 940 Partly resolved . 942 A.4. Since draft-ietf-httpbis-alt-svc-02 944 Updated ALPN reference. 946 Resolved . 948 A.5. Since draft-ietf-httpbis-alt-svc-03 950 Renamed "Alt-Svc-Used" to "Alt-Used" 951 (). 953 Clarify ALTSVC Origin information requirements 954 (). 956 Remove/tune language with respect to tracking risks (see 957 ). 959 A.6. Since draft-ietf-httpbis-alt-svc-04 961 Mention tracking by alt-svc host name in Security Considerations 962 (). 964 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 966 Allow the frame to carry multiple indicator and use the same payload 967 formats for both 968 (). 970 A.7. Since draft-ietf-httpbis-alt-svc-05 972 Go back to specifying the origin in Alt-Used, but make it a "SHOULD" 973 (). 975 Restore Origin field in ALT-SVC frame 976 (). 978 A.8. Since draft-ietf-httpbis-alt-svc-06 980 Disallow use of alternative services when the protocol might not 981 carry the scheme 982 (). 984 Align opp-sec and alt-svc 985 (). 987 alt svc frame on pushed (even and non-0) frame 988 (). 990 "browser" -> "user agent" 991 (). 993 ABNF for "parameter" 994 (). 996 Updated HTTP/2 reference. 998 A.9. Since draft-ietf-httpbis-alt-svc-07 1000 Alt-Svc alternative cache invalidation 1001 (). 1003 Unexpected Alt-Svc frames 1004 (). 1006 Associating Alt-Svc header with an origin 1007 (). 1009 ALPN identifiers in Alt-Svc 1010 (). 1012 Number of alternate services used 1013 (). 1015 Proxy and .pac interaction 1016 (). 1018 Need to define extensibility for alt-svc parameters 1019 (). 1021 Persistence of alternates across network changes 1022 (). 1024 Alt-Svc header with 421 status 1025 (). 1027 Incorporate several editorial improvements suggested by Mike Bishop 1028 (, 1029 ). 1031 Alt-Svc response header field in HTTP/2 frame 1032 (). 1034 A.10. Since draft-ietf-httpbis-alt-svc-08 1036 Remove left over text about ext-params, applying to an earlier 1037 version of Alt-Used (see 1038 ). 1040 Conflicts between Alt-Svc and ALPN 1041 (). 1043 Elevation of privilege 1044 (). 1046 Alternates of alternates 1047 (). 1049 Alt-Svc and Cert Pinning 1050 (). 1052 Using alt-svc on localhost (no change to spec, see 1053 ). 1055 IANA procedure for alt-svc parameters 1056 (). 1058 Alt-svc from https (1.1) to https (1.1) 1059 (). 1061 Alt-svc vs the ability to convey the scheme inside the protocol 1062 (). 1064 Reconciling MAY/can vs. SHOULD 1065 (). 1067 Typo in alt-svc caching example 1068 (). 1070 A.11. Since draft-ietf-httpbis-alt-svc-09 1072 Editorial improvements 1073 (, 1074 , 1075 , 1076 , 1077 , 1078 , 1079 , 1080 ). 1082 A.12. Since draft-ietf-httpbis-alt-svc-10 1084 Editorial improvements 1085 (). 1087 Use RFC 7405 ABNF extension 1088 (). 1090 A.13. Since draft-ietf-httpbis-alt-svc-11 1092 Security considerations wrt system ports 1093 (). 1095 A.14. Since draft-ietf-httpbis-alt-svc-12 1097 Editorial changes triggered by . 1100 Reasonable Assurances and H2C 1101 (). 1103 Appendix B. Acknowledgements 1105 Thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik 1106 Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, 1107 Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard 1108 Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their 1109 feedback and suggestions. 1111 The Alt-Svc header field was influenced by the design of the 1112 Alternate-Protocol header field in SPDY. 1114 Authors' Addresses 1116 Mark Nottingham 1117 Akamai 1119 EMail: mnot@mnot.net 1120 URI: https://www.mnot.net/ 1122 Patrick McManus 1123 Mozilla 1125 EMail: mcmanus@ducksong.com 1126 URI: https://mozillians.org/u/pmcmanus/ 1128 Julian F. Reschke 1129 greenbytes GmbH 1131 EMail: julian.reschke@greenbytes.de 1132 URI: https://greenbytes.de/tech/webdav/