idnits 2.17.1 draft-ietf-httpbis-alt-svc-11.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 3, 2016) is 2977 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 6, 2016 Mozilla 6 J. Reschke 7 greenbytes 8 February 3, 2016 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-11 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 6, 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 . . . . . . . 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 . . . . . . . . . . . 20 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 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 110 1. Introduction 112 HTTP [RFC7230] conflates the identification of resources with their 113 location. In other words, "http://" (and "https://") URIs are used 114 to both name and find things to interact with. 116 In some cases, it is desirable to separate identification and 117 location in HTTP; keeping the same identifier for a resource, but 118 interacting with it at a different location on the network. 120 For example: 122 o An origin server might wish to redirect a client to a different 123 server when it is under load, or it has found a server in a 124 location that is more local to the client. 126 o An origin server might wish to offer access to its resources using 127 a new protocol (such as HTTP/2, see [RFC7540]) or one using 128 improved security (such as Transport Layer Security (TLS), see 129 [RFC5246]). 131 o An origin server might wish to segment its clients into groups of 132 capabilities, such as those supporting Server Name Indication 133 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for 134 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 159 [RFC7234]: 161 OWS = 162 delta-seconds = 163 port = 164 quoted-string = 165 token = 166 uri-host = 168 2. Alternative Services Concepts 170 This specification defines a new concept in HTTP, the "Alternative 171 Service". When an origin (see [RFC6454]) has resources that are 172 accessible through a different protocol / host / port combination, it 173 is said to have an alternative service available. 175 An alternative service can be used to interact with the resources on 176 an origin server at a separate location on the network, possibly 177 using a different protocol configuration. Alternative services are 178 considered authoritative for an origin's resources, in the sense of 179 [RFC7230], Section 9.1. 181 For example, an origin: 183 ("http", "www.example.com", "80") 185 might declare that its resources are also accessible at the 186 alternative service: 188 ("h2", "new.example.com", "81") 190 By their nature, alternative services are explicitly at the 191 granularity of an origin; i.e., they cannot be selectively applied to 192 resources within an origin. 194 Alternative services do not replace or change the origin for any 195 given resource; in general, they are not visible to the software 196 "above" the access mechanism. The alternative service is essentially 197 alternative routing information that can also be used to reach the 198 origin in the same way that DNS CNAME or SRV records define routing 199 information at the name resolution level. Each origin maps to a set 200 of these routes -- the default route is derived from the origin 201 itself and the other routes are introduced based on alternative- 202 service information. 204 Furthermore, it is important to note that the first member of an 205 alternative service tuple is different from the "scheme" component of 206 an origin; it is more specific, identifying not only the major 207 version of the protocol being used, but potentially communication 208 options for that protocol. 210 This means that clients using an alternative service can change the 211 host, port and protocol that they are using to fetch resources, but 212 these changes MUST NOT be propagated to the application that is using 213 HTTP; from that standpoint, the URI being accessed and all 214 information derived from it (scheme, host, port) are the same as 215 before. 217 Importantly, this includes its security context; in particular, when 218 TLS [RFC5246] is used to authenticate, the alternative service will 219 need to present a certificate for the origin's host name, not that of 220 the alternative. Likewise, the Host header field ([RFC7230], Section 221 5.4) is still derived from the origin, not the alternative service 222 (just as it would if a CNAME were being used). 224 The changes MAY, however, be made visible in debugging tools, 225 consoles, etc. 227 Formally, an alternative service is identified by the combination of: 229 o An Application Layer Protocol Negotiation (ALPN) protocol name, as 230 per [RFC7301] 232 o A host, as per [RFC3986], Section 3.2.2 234 o A port, as per [RFC3986], Section 3.2.3 236 The ALPN protocol name is used to identify the application protocol 237 or suite of protocols used by the alternative service. Note that for 238 the purpose of this specification, an ALPN protocol name implicitly 239 includes TLS in the suite of protocols it identifies, unless 240 specified otherwise in its definition. In particular, the ALPN name 241 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 242 over TLS. 244 Additionally, each alternative service MUST have: 246 o A freshness lifetime, expressed in seconds; see Section 2.2 248 There are many ways that a client could discover the alternative 249 service(s) associated with an origin. This document describes two 250 such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the 251 "ALTSVC" HTTP/2 frame type (Section 4). 253 The remainder of this section describes requirements that are common 254 to alternative services, regardless of how they are discovered. 256 2.1. Host Authentication 258 Clients MUST NOT use alternative services with a host that is 259 different from the origin's without strong server authentication; 260 this mitigates the attack described in Section 9.2. One way to 261 achieve this is for the alternative to use TLS with a certificate 262 that is valid for that origin. 264 For example, if the origin's host is "www.example.com" and an 265 alternative is offered on "other.example.com" with the "h2" protocol, 266 and the certificate offered is valid for "www.example.com", the 267 client can use the alternative. However, if "other.example.com" is 268 offered with the "h2c" protocol, the client cannot use it, because 269 there is no mechanism in that protocol to establish strong server 270 authentication. 272 2.2. Alternative Service Caching 274 Mechanisms for discovering alternative services also associate a 275 freshness lifetime with them; for example, the Alt-Svc header field 276 uses the "ma" parameter. 278 Clients can choose to use an alternative service instead of the 279 origin at any time when it is considered fresh; see Section 2.4 for 280 specific recommendations. 282 Clients with existing connections to an alternative service do not 283 need to stop using it when its freshness lifetime ends; i.e., the 284 caching mechanism is intended for limiting how long an alternative 285 service can be used for establishing new connections, not limiting 286 the use of existing ones. 288 Alternative services are fully authoritative for the origin in 289 question, including the ability to clear or update cached alternative 290 service entries, extend freshness lifetimes, and any other authority 291 the origin server would have. 293 When alternative services are used to send a client to the most 294 optimal server, a change in network configuration can result in 295 cached values becoming suboptimal. Therefore, clients SHOULD remove 296 from cache all alternative services that lack the "persist" flag with 297 the value "1" when they detect such a change (when information about 298 network state is available). 300 2.3. Requiring Server Name Indication 302 A client MUST only use a TLS-based alternative service if the client 303 also supports TLS Server Name Indication (SNI). This supports the 304 conservation of IP addresses on the alternative service host. 306 Note that the SNI information provided in TLS by the client will be 307 that of the origin, not the alternative (as will the Host HTTP header 308 field value). 310 2.4. Using Alternative Services 312 By their nature, alternative services are OPTIONAL: clients do not 313 need to use them. However, it is advantageous for clients to behave 314 in a predictable way when alternative services are used by servers 315 (e.g., for load balancing). 317 Therefore, if a client becomes aware of an alternative service, the 318 client SHOULD use that alternative service for all requests to the 319 associated origin as soon as it is available, provided the 320 alternative service information is fresh (Section 2.2) and the 321 security properties of the alternative service protocol are 322 desirable, as compared to the existing connection. A viable 323 alternative service is then treated in every way as the origin; this 324 includes the ability to advertise alternative services. 326 If a client becomes aware of multiple alternative services, it 327 chooses the most suitable according to its own criteria (again, 328 keeping security properties in mind). For example, an origin might 329 advertise multiple alternative services to notify clients of support 330 for multiple versions of HTTP. 332 A client configured to use a proxy for a given request SHOULD NOT 333 directly connect to an alternative service for this request, but 334 instead route it through that proxy. 336 When a client uses an alternative service for a request, it can 337 indicate this to the server using the Alt-Used header field 338 (Section 5). 340 The client does not need to block requests on any existing 341 connection; it can be used until the alternative connection is 342 established. However, if the security properties of the existing 343 connection are weak (e.g. cleartext HTTP/1.1) then it might make 344 sense to block until the new connection is fully available in order 345 to avoid information leakage. 347 Furthermore, if the connection to the alternative service fails or is 348 unresponsive, the client MAY fall back to using the origin or another 349 alternative service. Note, however, that this could be the basis of 350 a downgrade attack, thus losing any enhanced security properties of 351 the alternative service. If the connection to the alternative 352 service does not negotiate the expected protocol (for example, ALPN 353 fails to negotiate h2, or an Upgrade request to h2c is not accepted), 354 the connection to the alternative service MUST be considered to have 355 failed. 357 3. The Alt-Svc HTTP Header Field 359 An HTTP(S) origin server can advertise the availability of 360 alternative services to clients by adding an Alt-Svc header field to 361 responses. 363 Alt-Svc = clear / 1#alt-value 364 clear = %s"clear"; "clear", case-sensitive 365 alt-value = alternative *( OWS ";" OWS parameter ) 366 alternative = protocol-id "=" alt-authority 367 protocol-id = token ; percent-encoded ALPN protocol name 368 alt-authority = quoted-string ; containing [ uri-host ] ":" port 369 parameter = token "=" ( token / quoted-string ) 371 The field value consists either of a list of values, each of which 372 indicates one alternative service, or the keyword "clear". 374 A field value containing the special value "clear" indicates that the 375 origin requests all alternatives for that origin to be invalidated 376 (including those specified in the same response, in case of an 377 invalid reply containing both "clear" and alternative services). 379 ALPN protocol names are octet sequences with no additional 380 constraints on format. Octets not allowed in tokens ([RFC7230], 381 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 382 [RFC3986]. Consequently, the octet representing the percent 383 character "%" (hex 25) MUST be percent-encoded as well. 385 In order to have precisely one way to represent any ALPN protocol 386 name, the following additional constraints apply: 388 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if 389 they are valid token characters except "%", and 391 2. When using percent-encoding, uppercase hex digits MUST be used. 393 With these constraints, recipients can apply simple string comparison 394 to match protocol identifiers. 396 The "alt-authority" component consists of an OPTIONAL uri-host 397 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 398 number. 400 For example: 402 Alt-Svc: h2=":8000" 404 This indicates the "h2" protocol ([RFC7540]) on the same host using 405 the indicated port 8000. 407 An example involving a change of host: 409 Alt-Svc: h2="new.example.org:80" 411 This indicates the "h2" protocol on the host "new.example.org", 412 running on port 80. Note that the "quoted-string" syntax needs to be 413 used because ":" is not an allowed character in "token". 415 Examples for protocol name escaping: 417 +--------------------+-------------+---------------------+ 418 | ALPN protocol name | protocol-id | Note | 419 +--------------------+-------------+---------------------+ 420 | h2 | h2 | No escaping needed | 421 +--------------------+-------------+---------------------+ 422 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 423 +--------------------+-------------+---------------------+ 424 | x%y | x%25y | "%" needs escaping | 425 +--------------------+-------------+---------------------+ 427 Alt-Svc MAY occur in any HTTP response message, regardless of the 428 status code. Note that recipients of Alt-Svc are free to ignore the 429 header field (and indeed need to in some situations; see Sections 2.1 430 and 6). 432 The Alt-Svc field value can have multiple values: 434 Alt-Svc: h2c=":8000", h2=":443" 436 When multiple values are present, the order of the values reflects 437 the server's preference (with the first value being the most 438 preferred alternative). 440 The value(s) advertised by Alt-Svc can be used by clients to open a 441 new connection to an alternative service. Subsequent requests can 442 start using this new connection immediately, or can continue using 443 the existing connection while the new connection is created. 445 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC 446 frame (Section 4). A single ALTSVC frame can be sent for a 447 connection; a new frame is not needed for every request. Note that, 448 despite this recommendation, Alt-Svc header fields remain valid in 449 responses delivered over HTTP/2. 451 Each "alt-value" is followed by an OPTIONAL semicolon-separated list 452 of additional parameters, each such "parameter" comprising a name and 453 a value. 455 This specification defines two parameters: "ma" and "persist", 456 defined in Section 3.1. Unknown parameters MUST be ignored, that is 457 the values (alt-value) they appear in MUST be processed as if the 458 unknown parameter was not present. 460 New parameters can be defined in extension specifications (see 461 Section 7.3 for registration details). 463 Note that all field elements that allow "quoted-string" syntax MUST 464 be processed as per Section 3.2.6 of [RFC7230]. 466 3.1. Caching Alt-Svc Header Field Values 468 When an alternative service is advertised using Alt-Svc, it is 469 considered fresh for 24 hours from generation of the message. This 470 can be modified with the 'ma' (max-age) parameter. 472 Syntax: 474 ma = delta-seconds; see [RFC7234], Section 1.2.1 476 The delta-seconds value indicates the number of seconds since the 477 response was generated the alternative service is considered fresh 478 for. 480 Alt-Svc: h2=":443"; ma=3600 482 See Section 4.2.3 of [RFC7234] for details of determining response 483 age. 485 For example, a response: 487 HTTP/1.1 200 OK 488 Content-Type: text/html 489 Cache-Control: max-age=600 490 Age: 30 491 Alt-Svc: h2c=":8000"; ma=60 493 indicates that an alternative service is available and usable for the 494 next 60 seconds. However, the response has already been cached for 495 30 seconds (as per the Age header field value), so therefore the 496 alternative service is only fresh for the 30 seconds from when this 497 response was received, minus estimated transit time. 499 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 500 does not affect caching of Alt-Svc values. 502 When an Alt-Svc response header field is received from an origin, its 503 value invalidates and replaces all cached alternative services for 504 that origin. 506 By default, cached alternative services will be cleared when the 507 client detects a network change. Alternative services that are 508 intended to be longer-lived (e.g., those that are not specific to the 509 client access network) can carry the "persist" parameter with a value 510 "1" as a hint that the service is potentially useful beyond a network 511 configuration change. 513 Syntax: 515 persist = "1" 517 For example: 519 Alt-Svc: h2=":443"; ma=2592000; persist=1 521 This specification only a defines a single value for "persist". 522 Clients MUST ignore "persist" parameters with values other than "1". 524 See Section 2.2 for general requirements on caching alternative 525 services. 527 4. The ALTSVC HTTP/2 Frame 529 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the 530 availability of an alternative service to an HTTP/2 client. 532 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 533 that do not support this frame can safely ignore it. 535 An ALTSVC frame from a server to a client on a stream other than 536 stream 0 indicates that the conveyed alternative service is 537 associated with the origin of that stream. 539 An ALTSVC frame from a server to a client on stream 0 indicates that 540 the conveyed alternative service is associated with the origin 541 contained in the Origin field of the frame. An association with an 542 origin that the client does not consider authoritative for the 543 current connection MUST be ignored. 545 The ALTSVC frame type is 0xa (decimal 10). 547 +-------------------------------+-------------------------------+ 548 | Origin-Len (16) | Origin? (*) ... 549 +-------------------------------+-------------------------------+ 550 | Alt-Svc-Field-Value (*) ... 551 +---------------------------------------------------------------+ 553 ALTSVC Frame Payload 555 The ALTSVC frame contains the following fields: 557 Origin-Len: An unsigned, 16-bit integer indicating the length, in 558 octets, of the Origin field. 560 Origin: An OPTIONAL sequence of characters containing the ASCII 561 serialization of an origin ([RFC6454], Section 6.2) that the 562 alternative service is applicable to. 564 Alt-Svc-Field-Value: A sequence of octets (length determined by 565 subtracting the length of all preceding fields from the frame 566 length) containing a value identical to the Alt-Svc field value 567 defined in Section 3 (ABNF production "Alt-Svc"). 569 The ALTSVC frame does not define any flags. 571 The ALTSVC frame is intended for receipt by clients; a server that 572 receives an ALTSVC frame can safely ignore it. 574 An ALTSVC frame on stream 0 with empty (length 0) "Origin" 575 information is invalid and MUST be ignored. An ALTSVC frame on a 576 stream other than stream 0 containing non-empty "Origin" information 577 is invalid and MUST be ignored. 579 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 580 forward ALTSVC frames, though it can use the information contained in 581 ALTSVC frames in forming new ALTSVC frames to send to its own 582 clients. 584 Receiving an ALTSVC frame is semantically equivalent to receiving an 585 Alt-Svc header field. As a result, the ALTSVC frame causes 586 alternative services for the corresponding origin to be replaced. 587 Note that it would be unwise to mix the use of Alt-Svc header fields 588 with the use of ALTSVC frames, as the sequence of receipt might be 589 hard to predict. 591 5. The Alt-Used HTTP Header Field 593 The Alt-Used header field is used in requests to indicate the 594 identity of the alternative service in use, just as the Host header 595 field (Section 5.4 of [RFC7230]) identifies the host and port of the 596 origin. 598 Alt-Used = uri-host [ ":" port ] 600 Alt-Used is intended to allow alternative services to detect loops, 601 differentiate traffic for purposes of load balancing, and generally 602 to ensure that it is possible to identify the intended destination of 603 traffic, since introducing this information after a protocol is in 604 use has proven to be problematic. 606 When using an alternative service, clients SHOULD include an Alt-Used 607 header field in all requests. 609 For example: 611 GET /thing HTTP/1.1 612 Host: origin.example.com 613 Alt-Used: alternate.example.net 615 6. The 421 Misdirected Request HTTP Status Code 617 The 421 (Misdirected Request) status code is defined in Section 9.1.2 618 of [RFC7540] to indicate that the current server instance is not 619 authoritative for the requested resource. This can be used to 620 indicate that an alternative service is not authoritative; see 621 Section 2). 623 Clients receiving 421 (Misdirected Request) from an alternative 624 service MUST remove the corresponding entry from its alternative 625 service cache (see Section 2.2) for that origin. Regardless of the 626 idempotency of the request method, they MAY retry the request, either 627 at another alternative server, or at the origin. 629 An Alt-Svc header field in a 421 (Misdirected Request) response MUST 630 be ignored. 632 7. IANA Considerations 634 7.1. Header Field Registrations 636 HTTP header fields are registered within the "Message Headers" 637 registry maintained at 638 . 640 This document defines the following HTTP header fields, so their 641 associated registry entries shall be added according to the permanent 642 registrations below (see [BCP90]): 644 +-------------------+----------+----------+-----------+ 645 | Header Field Name | Protocol | Status | Reference | 646 +-------------------+----------+----------+-----------+ 647 | Alt-Svc | http | standard | Section 3 | 648 | Alt-Used | http | standard | Section 5 | 649 +-------------------+----------+----------+-----------+ 651 The change controller is: "IETF (iesg@ietf.org) - Internet 652 Engineering Task Force". 654 7.2. The ALTSVC HTTP/2 Frame Type 656 This document registers the ALTSVC frame type in the HTTP/2 Frame 657 Types registry ([RFC7540], Section 11.2). 659 Frame Type: ALTSVC 661 Code: 0xa 663 Specification: Section 4 of this document 665 7.3. Alt-Svc Parameter Registry 667 The HTTP Alt-Svc Parameter Registry defines the name space for 668 parameters. It will be created and maintained at (the suggested URI) 669 . 671 7.3.1. Procedure 673 A registration MUST include the following fields: 675 o Parameter Name 677 o Pointer to specification text 679 Values to be added to this name space require Expert Review (see 680 [RFC5226], Section 4.1). 682 7.3.2. Registrations 684 The HTTP Alt-Svc Parameter Registry is to be populated with the 685 registrations below: 687 +-------------------+-------------+ 688 | Alt-Svc Parameter | Reference | 689 +-------------------+-------------+ 690 | ma | Section 3.1 | 691 | persist | Section 3.1 | 692 +-------------------+-------------+ 694 8. Internationalization Considerations 696 An internationalized domain name that appears in either the header 697 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 698 using A-labels ([RFC5890], Section 2.3.2.1). 700 9. Security Considerations 702 9.1. Changing Ports 704 Using an alternative service implies accessing an origin's resources 705 on an alternative port, at a minimum. An attacker that can inject 706 alternative services and listen at the advertised port is therefore 707 able to hijack an origin. On certain servers, it is normal for users 708 to be able to control some personal pages available on a shared port, 709 and also to accept to requests on less-privileged ports. 711 For example, an attacker that can add HTTP response header fields to 712 some pages can redirect traffic for an entire origin to a different 713 port on the same host using the Alt-Svc header field; if that port is 714 under the attacker's control, they can thus masquerade as the HTTP 715 server. 717 On servers, this risk can be reduced by restricting the ability to 718 advertise alternative services, and restricting who can open a port 719 for listening on that host. Clients can reduce this risk by imposing 720 stronger requirements (e.g. strong authentication) when moving from 721 System Ports to User or Dynamic Ports, or from User Ports to Dynamic 722 Ports, as defined in Section 6 of [RFC6335]. 724 It is always valid for a client to ignore an alternative service 725 advertisement which does not meet its implementation-specific 726 security requirements. Servers can increase the likelihood of 727 clients using the alternative service by providing strong 728 authentication even when not required. 730 9.2. Changing Hosts 732 When the host is changed due to the use of an alternative service, it 733 presents an opportunity for attackers to hijack communication to an 734 origin. 736 For example, if an attacker can convince a user agent to send all 737 traffic for "innocent.example.org" to "evil.example.com" by 738 successfully associating it as an alternative service, they can 739 masquerade as that origin. This can be done locally (see mitigations 740 in Section 9.1) or remotely (e.g., by an intermediary as a man-in- 741 the-middle attack). 743 This is the reason for the requirement in Section 2.1 that any 744 alternative service with a host different from the origin's be 745 strongly authenticated with the origin's identity; i.e., presenting a 746 certificate for the origin proves that the alternative service is 747 authorized to serve traffic for the origin. 749 However, this authorization is only as strong as the method used to 750 authenticate the alternative service. In particular, there are well- 751 known exploits to make an attacker's certificate appear as 752 legitimate. 754 Alternative services could be used to persist such an attack; for 755 example, an intermediary could man-in-the-middle TLS-protected 756 communication to a target, and then direct all traffic to an 757 alternative service with a large freshness lifetime, so that the user 758 agent still directs traffic to the attacker even when not using the 759 intermediary. 761 Implementations MUST perform any certificate-pinning validation (e.g. 762 [RFC7469]) on alternative services just as they would on direct 763 connections to the origin. Implementations might also choose to add 764 other requirements around which certificates are acceptable for 765 alternative services. 767 9.3. Changing Protocols 769 When the ALPN protocol is changed due to the use of an alternative 770 service, the security properties of the new connection to the origin 771 can be different from that of the "normal" connection to the origin, 772 because the protocol identifier itself implies this. 774 For example, if an "https://" URI has a protocol advertised that does 775 not use some form of end-to-end encryption (most likely, TLS), it 776 violates the expectations for security that the URI scheme implies. 778 Therefore, clients cannot blindly use alternative services, but 779 instead evaluate the option(s) presented to assure that security 780 requirements and expectations (of specifications, implementations and 781 end users) are met. 783 9.4. Tracking Clients Using Alternative Services 785 Choosing an alternative service implies connecting to a new, server- 786 supplied host name. By using many different (potentially unique) 787 host names, servers could conceivably track client requests. Such 788 tracking could follow users across multiple networks, when the 789 "persist" flag is used. 791 Clients that wish to prevent requests from being correlated (such as 792 those that offer modes aimed at providing improved privacy) can 793 decide not to use alternative services for multiple requests that 794 would not otherwise be allowed to be correlated. 796 In a user agent, any alternative service information MUST be removed 797 when origin-specific data is cleared (for instance, when cookies are 798 cleared). 800 9.5. Confusion Regarding Request Scheme 802 Some server-side HTTP applications make assumptions about security 803 based upon connection context; for example, equating being served 804 upon port 443 with the use of an "https://" URI (and the various 805 security properties that implies). 807 This affects not only the security properties of the connection 808 itself, but also the state of the client at the other end of it; for 809 example, a Web browser treats "https://" URIs differently than 810 "http://" URIs in many ways, not just for purposes of protocol 811 handling. 813 Since one of the uses of Alternative Services is to allow a 814 connection to be migrated to a different protocol and port, these 815 applications can become confused about the security properties of a 816 given connection, sending information (e.g., cookies, content) that 817 is intended for a secure context (e.g., an "https://" URI) to a 818 client that is not treating it as one. 820 This risk can be mitigated in servers by using the URI scheme 821 explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the 822 "absolute form" of the request target in HTTP/1.1) as an indication 823 of security context, instead of other connection properties 824 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 826 When the protocol does not explicitly carry the scheme (e.g., as is 827 usually the case for HTTP/1.1 over TLS, servers can mitigate this 828 risk by either assuming that all requests have an insecure context, 829 or by refraining from advertising alternative services for insecure 830 schemes (such as HTTP). 832 10. References 834 10.1. Normative References 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 838 RFC2119, March 1997, 839 . 841 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 842 Resource Identifier (URI): Generic Syntax", STD 66, 843 RFC 3986, DOI 10.17487/RFC3986, January 2005, 844 . 846 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 847 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 848 DOI 10.17487/RFC5226, May 2008, 849 . 851 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 852 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 853 RFC5234, January 2008, 854 . 856 [RFC5890] Klensin, J., "Internationalized Domain Names for 857 Applications (IDNA): Definitions and Document Framework", 858 RFC 5890, DOI 10.17487/RFC5890, August 2010, 859 . 861 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 862 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, 863 January 2011, . 865 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 866 DOI 10.17487/RFC6454, December 2011, 867 . 869 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 870 Protocol (HTTP/1.1): Message Syntax and Routing", 871 RFC 7230, DOI 10.17487/RFC7230, June 2014, 872 . 874 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 875 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 876 RFC 7234, DOI 10.17487/RFC7234, June 2014, 877 . 879 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, 880 "Transport Layer Security (TLS) Application-Layer Protocol 881 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 882 July 2014, . 884 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 885 RFC 7405, DOI 10.17487/RFC7405, December 2014, 886 . 888 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 889 Transfer Protocol version 2", RFC 7540, DOI 10.17487/ 890 RFC7540, May 2015, 891 . 893 10.2. Informative References 895 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 896 Procedures for Message Header Fields", BCP 90, RFC 3864, 897 September 2004, . 899 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 900 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 901 RFC5246, August 2008, 902 . 904 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 905 Cheshire, "Internet Assigned Numbers Authority (IANA) 906 Procedures for the Management of the Service Name and 907 Transport Protocol Port Number Registry", RFC 6335, 908 DOI 10.17487/RFC6335, August 2011, 909 . 911 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 912 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 913 April 2015, . 915 Appendix A. Change Log (to be removed by RFC Editor before publication) 917 A.1. Since draft-nottingham-httpbis-alt-svc-05 919 This is the first version after adoption of 920 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 921 only contains editorial changes. 923 A.2. Since draft-ietf-httpbis-alt-svc-00 925 Selected 421 as proposed status code for "Not Authoritative". 927 Changed header field syntax to use percent-encoding of ALPN protocol 928 names (). 930 A.3. Since draft-ietf-httpbis-alt-svc-01 932 Updated HTTP/1.1 references. 934 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 935 to address fingerprinting concerns 936 (). 938 Note that ALTSVC frame is preferred to Alt-Svc header field 939 (). 941 Incorporate ALTSRV frame 942 (). 944 Moved definition of status code 421 to HTTP/2. 946 Partly resolved . 948 A.4. Since draft-ietf-httpbis-alt-svc-02 950 Updated ALPN reference. 952 Resolved . 954 A.5. Since draft-ietf-httpbis-alt-svc-03 956 Renamed "Alt-Svc-Used" to "Alt-Used" 957 (). 959 Clarify ALTSVC Origin information requirements 960 (). 962 Remove/tune language with respect to tracking risks (see 963 ). 965 A.6. Since draft-ietf-httpbis-alt-svc-04 967 Mention tracking by alt-svc host name in Security Considerations 968 (). 970 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 972 Allow the frame to carry multiple indicator and use the same payload 973 formats for both 974 (). 976 A.7. Since draft-ietf-httpbis-alt-svc-05 978 Go back to specifying the origin in Alt-Used, but make it a "SHOULD" 979 (). 981 Restore Origin field in ALT-SVC frame 982 (). 984 A.8. Since draft-ietf-httpbis-alt-svc-06 986 Disallow use of alternative services when the protocol might not 987 carry the scheme 988 (). 990 Align opp-sec and alt-svc 991 (). 993 alt svc frame on pushed (even and non-0) frame 994 (). 996 "browser" -> "user agent" 997 (). 999 ABNF for "parameter" 1000 (). 1002 Updated HTTP/2 reference. 1004 A.9. Since draft-ietf-httpbis-alt-svc-07 1006 Alt-Svc alternative cache invalidation 1007 (). 1009 Unexpected Alt-Svc frames 1010 (). 1012 Associating Alt-Svc header with an origin 1013 (). 1015 ALPN identifiers in Alt-Svc 1016 (). 1018 Number of alternate services used 1019 (). 1021 Proxy and .pac interaction 1022 (). 1024 Need to define extensibility for alt-svc parameters 1025 (). 1027 Persistence of alternates across network changes 1028 (). 1030 Alt-Svc header with 421 status 1031 (). 1033 Incorporate several editorial improvements suggested by Mike Bishop 1034 (, 1035 ). 1037 Alt-Svc response header field in HTTP/2 frame 1038 (). 1040 A.10. Since draft-ietf-httpbis-alt-svc-08 1042 Remove left over text about ext-params, applying to an earlier 1043 version of Alt-Used (see 1044 ). 1046 Conflicts between Alt-Svc and ALPN 1047 (). 1049 Elevation of privilege 1050 (). 1052 Alternates of alternates 1053 (). 1055 Alt-Svc and Cert Pinning 1056 (). 1058 Using alt-svc on localhost (no change to spec, see 1059 ). 1061 IANA procedure for alt-svc parameters 1062 (). 1064 Alt-svc from https (1.1) to https (1.1) 1065 (). 1067 Alt-svc vs the ability to convey the scheme inside the protocol 1068 (). 1070 Reconciling MAY/can vs. SHOULD 1071 (). 1073 Typo in alt-svc caching example 1074 (). 1076 A.11. Since draft-ietf-httpbis-alt-svc-09 1078 Editorial improvements 1079 (, 1080 , 1081 , 1082 , 1083 , 1084 , 1085 , 1086 ). 1088 A.12. Since draft-ietf-httpbis-alt-svc-10 1090 Editorial improvements 1091 (). 1093 Use RFC 7405 ABNF extension 1094 (). 1096 Appendix B. Acknowledgements 1098 Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy 1099 Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew 1100 Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, 1101 Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and 1102 suggestions. 1104 The Alt-Svc header field was influenced by the design of the 1105 Alternate-Protocol header field in SPDY. 1107 Authors' Addresses 1109 Mark Nottingham 1110 Akamai 1112 EMail: mnot@mnot.net 1113 URI: https://www.mnot.net/ 1114 Patrick McManus 1115 Mozilla 1117 EMail: mcmanus@ducksong.com 1118 URI: https://mozillians.org/u/pmcmanus/ 1120 Julian F. Reschke 1121 greenbytes GmbH 1123 EMail: julian.reschke@greenbytes.de 1124 URI: https://greenbytes.de/tech/webdav/