idnits 2.17.1 draft-ietf-httpbis-alt-svc-10.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 (December 15, 2015) is 3054 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: June 17, 2016 Mozilla 6 J. Reschke 7 greenbytes 8 December 15, 2015 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-10 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 and ; 28 source code and issues list for this draft can be found at 29 . 31 The changes in this draft are summarized in Appendix A. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 17, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 69 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5 70 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 7 71 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7 72 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7 73 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8 74 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9 75 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11 76 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12 77 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 14 78 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14 81 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15 82 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15 83 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15 84 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15 85 8. Internationalization Considerations . . . . . . . . . . . . . 16 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16 88 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16 89 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17 90 9.4. Tracking Clients Using Alternative Services . . . . . . . 18 91 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 95 Appendix A. Change Log (to be removed by RFC Editor before 96 publication) . . . . . . . . . . . . . . . . . . . . 20 97 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20 98 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20 99 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20 100 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21 101 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21 102 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21 103 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21 104 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22 105 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22 106 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23 107 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 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] along with 156 the "#rule" extension defined in Section 7 of [RFC7230]. The rules 157 below are defined in [RFC5234], [RFC7230], and [RFC7234]: 159 DIGIT = 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 (see [RFC6454]) has resources that are 171 accessible through a different protocol / host / port combination, it 172 is said to 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; i.e., 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 NOT use alternative services with a host that is 258 different than the origin's without strong server authentication; 259 this mitigates the attack described in Section 9.2. One way to 260 achieve this is for the alternative to use TLS with a certificate 261 that is valid for that origin. 263 For example, if the origin's host is "www.example.com" and an 264 alternative is offered on "other.example.com" with the "h2" protocol, 265 and the certificate offered is valid for "www.example.com", the 266 client can use the alternative. However, if "other.example.com" is 267 offered with the "h2c" protocol, the client cannot use it, because 268 there is no mechanism in that protocol to establish strong server 269 authentication. 271 2.2. Alternative Service Caching 273 Mechanisms for discovering alternative services also associate a 274 freshness lifetime with them; for example, the Alt-Svc header field 275 uses the "ma" parameter. 277 Clients can choose to use an alternative service instead of the 278 origin at any time when it is considered fresh; see Section 2.4 for 279 specific recommendations. 281 Clients with existing connections to an alternative service do not 282 need to stop using it when its freshness lifetime ends; i.e., the 283 caching mechanism is intended for limiting how long an alternative 284 service can be used for establishing new connections, not limiting 285 the use of existing ones. 287 Alternative services are fully authoritative for the origin in 288 question, including the ability to clear or update cached alternative 289 service entries, extend freshness lifetimes, and any other authority 290 the origin server would have. 292 When alternative services are used to send a client to the most 293 optimal server, a change in network configuration can result in 294 cached values becoming suboptimal. Therefore, clients SHOULD remove 295 from cache all alternative services that lack the "persist" flag with 296 the value "1" when they detect such a change (when information about 297 network state is available). 299 2.3. Requiring Server Name Indication 301 A client MUST only use a TLS-based alternative service if the client 302 also supports TLS Server Name Indication (SNI). This supports the 303 conservation of IP addresses on the alternative service host. 305 Note that the SNI information provided in TLS by the client will be 306 that of the origin, not the alternative (as will the Host HTTP header 307 field value). 309 2.4. Using Alternative Services 311 By their nature, alternative services are OPTIONAL: clients do not 312 need to use them. However, it is advantageous for clients to behave 313 in a predictable way when they are used by servers (e.g., for load 314 balancing). 316 Therefore, if a client becomes aware of an alternative service, the 317 client SHOULD use that alternative service for all requests to the 318 associated origin as soon as it is available, provided the 319 alternative service information is fresh (Section 2.2) and the 320 security properties of the alternative service protocol are 321 desirable, as compared to the existing connection. A viable 322 alternative service is then treated in every way as the origin; this 323 includes the ability to advertise alternative services. 325 If a client becomes aware of multiple alternative services, it MAY 326 choose the most suitable according to its own criteria (again, 327 keeping security properties in mind). For example, an origin might 328 advertise multiple alternative services to notify clients of support 329 for multiple versions of HTTP. 331 A client configured to use a proxy for a given request SHOULD NOT 332 directly connect to an alternative service for this request, but 333 instead route it through that proxy. 335 When a client uses an alternative service for a request, it can 336 indicate this to the server using the Alt-Used header field 337 (Section 5). 339 The client does not need to block requests on any existing 340 connection; it can be used until the alternative connection is 341 established. However, if the security properties of the existing 342 connection are weak (e.g. cleartext HTTP/1.1) then it might make 343 sense to block until the new connection is fully available in order 344 to avoid information leakage. 346 Furthermore, if the connection to the alternative service fails or is 347 unresponsive, the client MAY fall back to using the origin or another 348 alternative service. Note, however, that this could be the basis of 349 a downgrade attack, thus losing any enhanced security properties of 350 the alternative service. If the connection to the alternative 351 service does not negotiate the expected protocol (for example, ALPN 352 fails to negotiate h2, or an Upgrade request to h2c is not accepted), 353 the connection to the alternative service MUST be considered to have 354 failed. 356 3. The Alt-Svc HTTP Header Field 358 An HTTP(S) origin server can advertise the availability of 359 alternative services to clients by adding an Alt-Svc header field to 360 responses. 362 Alt-Svc = clear / 1#alt-value 363 clear = %x63.6C.65.61.72; "clear", case-sensitive 364 alt-value = alternative *( OWS ";" OWS parameter ) 365 alternative = protocol-id "=" alt-authority 366 protocol-id = token ; percent-encoded ALPN protocol name 367 alt-authority = quoted-string ; containing [ uri-host ] ":" port 368 parameter = token "=" ( token / quoted-string ) 370 The field value consists either of a list of values, each of which 371 indicating one alternative service, or the keyword "clear". 373 A field value containing the special value "clear" indicates that the 374 origin requests all alternatives for that origin to be invalidated 375 (including those specified in the same response, in case of an 376 invalid reply containing both "clear" and alternative services). 378 ALPN protocol names are octet sequences with no additional 379 constraints on format. Octets not allowed in tokens ([RFC7230], 380 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 381 [RFC3986]. Consequently, the octet representing the percent 382 character "%" (hex 25) MUST be percent-encoded as well. 384 In order to have precisely one way to represent any ALPN protocol 385 name, the following additional constraints apply: 387 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if 388 they are valid token characters except "%", and 390 2. When using percent-encoding, uppercase hex digits MUST be used. 392 With these constraints, recipients can apply simple string comparison 393 to match protocol identifiers. 395 The "alt-authority" component consists of an OPTIONAL uri-host 396 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 397 number. 399 For example: 401 Alt-Svc: h2=":8000" 403 This indicates the "h2" protocol ([RFC7540]) on the same host using 404 the indicated port 8000. 406 An example involving a change of host: 408 Alt-Svc: h2="new.example.org:80" 410 This indicates the "h2" protocol on the host "new.example.org", 411 running on port 80. Note that the "quoted-string" syntax needs to be 412 used because ":" is not an allowed character in "token". 414 Examples for protocol name escaping: 416 +--------------------+-------------+---------------------+ 417 | ALPN protocol name | protocol-id | Note | 418 +--------------------+-------------+---------------------+ 419 | h2 | h2 | No escaping needed | 420 +--------------------+-------------+---------------------+ 421 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 422 +--------------------+-------------+---------------------+ 423 | x%y | x%25y | "%" needs escaping | 424 +--------------------+-------------+---------------------+ 426 Alt-Svc MAY occur in any HTTP response message, regardless of the 427 status code. Note that recipients of Alt-Svc are free to ignore the 428 header field (and indeed need to in some situations; see Sections 2.1 429 and 6). 431 The Alt-Svc field value can have multiple values: 433 Alt-Svc: h2c=":8000", h2=":443" 435 When multiple values are present, the order of the values reflects 436 the server's preference (with the first value being the most 437 preferred alternative). 439 The value(s) advertised by Alt-Svc can be used by clients to open a 440 new connection to an alternative service. Subsequent requests can 441 start using this new connection immediately, or can continue using 442 the existing connection while the new connection is created. 444 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC 445 frame (Section 4). A single ALTSVC frame can be sent for a 446 connection; a new frame is not needed for every request. Note that, 447 despite this recommendation, Alt-Svc header fields remain valid in 448 responses delivered over HTTP/2. 450 Each "alt-value" is followed by an OPTIONAL semicolon-separated list 451 of additional parameters, each such "parameter" comprising a name and 452 a value. 454 This specification defines two parameters: "ma" and "persist", 455 defined in Section 3.1. Unknown parameters MUST be ignored, that is 456 the values (alt-value) they appear in MUST be processed as if the 457 unknown parameter was not present. 459 New parameters can be defined in extension specifications (see 460 Section 7.3 for registration details). 462 Note that all field elements that allow "quoted-string" syntax MUST 463 be processed as per Section 3.2.6 of [RFC7230]. 465 3.1. Caching Alt-Svc Header Field Values 467 When an alternative service is advertised using Alt-Svc, it is 468 considered fresh for 24 hours from generation of the message. This 469 can be modified with the 'ma' (max-age) parameter. 471 Syntax: 473 ma = delta-seconds; see [RFC7234], Section 1.2.1 475 The delta-seconds value indicates the number of seconds since the 476 response was generated the alternative service is considered fresh 477 for. 479 Alt-Svc: h2=":443"; ma=3600 481 See Section 4.2.3 of [RFC7234] for details of determining response 482 age. 484 For example, a response: 486 HTTP/1.1 200 OK 487 Content-Type: text/html 488 Cache-Control: max-age=600 489 Age: 30 490 Alt-Svc: h2c=":8000"; ma=60 492 indicates that an alternative service is available and usable for the 493 next 60 seconds. However, the response has already been cached for 494 30 seconds (as per the Age header field value), so therefore the 495 alternative service is only fresh for the 30 seconds from when this 496 response was received, minus estimated transit time. 498 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 499 does not affect caching of Alt-Svc values. 501 When an Alt-Svc response header field is received from an origin, its 502 value invalidates and replaces all cached alternative services for 503 that origin. 505 By default, cached alternative services will be cleared when the 506 client detects a network change. Alternative services that are 507 intended to be longer-lived (e.g., those that are not specific to the 508 client access network) can carry the "persist" parameter with a value 509 "1" as a hint that the service is potentially useful beyond a network 510 configuration change. 512 Syntax: 514 persist = 1DIGIT 516 For example: 518 Alt-Svc: h2=":443"; ma=2592000; persist=1 520 This specification only a defines a single value for "persist"; 521 others can be defined in future specifications. Clients MUST ignore 522 "persist" parameters with unknown values. 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 concerned by the additional fingerprinting can choose to 792 ignore alternative service advertisements. 794 In a user agent, any alternative service information MUST be removed 795 when origin-specific data is cleared (for instance, when cookies are 796 cleared). 798 9.5. Confusion Regarding Request Scheme 800 Some server-side HTTP applications make assumptions about security 801 based upon connection context; for example, equating being served 802 upon port 443 with the use of an "https://" URI (and the various 803 security properties that implies). 805 This affects not only the security properties of the connection 806 itself, but also the state of the client at the other end of it; for 807 example, a Web browser treats "https://" URIs differently than 808 "http://" URIs in many ways, not just for purposes of protocol 809 handling. 811 Since one of the uses of Alternative Services is to allow a 812 connection to be migrated to a different protocol and port, these 813 applications can become confused about the security properties of a 814 given connection, sending information (e.g., cookies, content) that 815 is intended for a secure context (e.g., an "https://" URI) to a 816 client that is not treating it as one. 818 This risk can be mitigated in servers by using the URI scheme 819 explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the 820 "absolute form" of the request target in HTTP/1.1) as an indication 821 of security context, instead of other connection properties 822 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 824 When the protocol does not explicitly carry the scheme (e.g., as is 825 usually the case for HTTP/1.1 over TLS, servers can, mitigate this 826 risk by either assuming that all requests have an insecure context, 827 or by refraining from advertising alternative services for insecure 828 schemes (such as HTTP). 830 10. References 831 10.1. Normative References 833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 834 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 835 RFC2119, March 1997, 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. 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 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 882 Transfer Protocol version 2", RFC 7540, DOI 10.17487/ 883 RFC7540, May 2015, 884 . 886 10.2. Informative References 888 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 889 Procedures for Message Header Fields", BCP 90, RFC 3864, 890 September 2004, . 892 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 893 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 894 RFC5246, August 2008, 895 . 897 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 898 Cheshire, "Internet Assigned Numbers Authority (IANA) 899 Procedures for the Management of the Service Name and 900 Transport Protocol Port Number Registry", RFC 6335, 901 DOI 10.17487/RFC6335, August 2011, 902 . 904 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 905 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 906 April 2015, . 908 Appendix A. Change Log (to be removed by RFC Editor before publication) 910 A.1. Since draft-nottingham-httpbis-alt-svc-05 912 This is the first version after adoption of 913 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 914 only contains editorial changes. 916 A.2. Since draft-ietf-httpbis-alt-svc-00 918 Selected 421 as proposed status code for "Not Authoritative". 920 Changed header field syntax to use percent-encoding of ALPN protocol 921 names (). 923 A.3. Since draft-ietf-httpbis-alt-svc-01 925 Updated HTTP/1.1 references. 927 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 928 to address fingerprinting concerns 929 (). 931 Note that ALTSVC frame is preferred to Alt-Svc header field 932 (). 934 Incorporate ALTSRV frame 935 (). 937 Moved definition of status code 421 to HTTP/2. 939 Partly resolved . 941 A.4. Since draft-ietf-httpbis-alt-svc-02 943 Updated ALPN reference. 945 Resolved . 947 A.5. Since draft-ietf-httpbis-alt-svc-03 949 Renamed "Alt-Svc-Used" to "Alt-Used" 950 (). 952 Clarify ALTSVC Origin information requirements 953 (). 955 Remove/tune language with respect to tracking risks (see 956 ). 958 A.6. Since draft-ietf-httpbis-alt-svc-04 960 Mention tracking by alt-svc host name in Security Considerations 961 (). 963 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 965 Allow the frame to carry multiple indicator and use the same payload 966 formats for both 967 (). 969 A.7. Since draft-ietf-httpbis-alt-svc-05 971 Go back to specifying the origin in Alt-Used, but make it a "SHOULD" 972 (). 974 Restore Origin field in ALT-SVC frame 975 (). 977 A.8. Since draft-ietf-httpbis-alt-svc-06 979 Disallow use of alternative services when the protocol might not 980 carry the scheme 981 (). 983 Align opp-sec and alt-svc 984 (). 986 alt svc frame on pushed (even and non-0) frame 987 (). 989 "browser" -> "user agent" 990 (). 992 ABNF for "parameter" 993 (). 995 Updated HTTP/2 reference. 997 A.9. Since draft-ietf-httpbis-alt-svc-07 999 Alt-Svc alternative cache invalidation 1000 (). 1002 Unexpected Alt-Svc frames 1003 (). 1005 Associating Alt-Svc header with an origin 1006 (). 1008 ALPN identifiers in Alt-Svc 1009 (). 1011 Number of alternate services used 1012 (). 1014 Proxy and .pac interaction 1015 (). 1017 Need to define extensibility for alt-svc parameters 1018 (). 1020 Persistence of alternates across network changes 1021 (). 1023 Alt-Svc header with 421 status 1024 (). 1026 Incorporate several editorial improvements suggested by Mike Bishop 1027 (, 1028 ). 1030 Alt-Svc response header field in HTTP/2 frame 1031 (). 1033 A.10. Since draft-ietf-httpbis-alt-svc-08 1035 Remove left over text about ext-params, applying to an earlier 1036 version of Alt-Used (see 1037 ). 1039 Conflicts between Alt-Svc and ALPN 1040 (). 1042 Elevation of privilege 1043 (). 1045 Alternates of alternates 1046 (). 1048 Alt-Svc and Cert Pinning 1049 (). 1051 Using alt-svc on localhost (no change to spec, see 1052 ). 1054 IANA procedure for alt-svc parameters 1055 (). 1057 Alt-svc from https (1.1) to https (1.1) 1058 (). 1060 Alt-svc vs the ability to convey the scheme inside the protocol 1061 (). 1063 Reconciling MAY/can vs. SHOULD 1064 (). 1066 Typo in alt-svc caching example 1067 (). 1069 A.11. Since draft-ietf-httpbis-alt-svc-09 1071 Editorial improvements 1072 (, 1073 , 1074 , 1075 , 1076 , 1077 , 1078 , 1079 ). 1081 Appendix B. Acknowledgements 1083 Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy 1084 Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew 1085 Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, 1086 Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and 1087 suggestions. 1089 The Alt-Svc header field was influenced by the design of the 1090 Alternate-Protocol header field in SPDY. 1092 Authors' Addresses 1094 Mark Nottingham 1095 Akamai 1097 EMail: mnot@mnot.net 1098 URI: https://www.mnot.net/ 1100 Patrick McManus 1101 Mozilla 1103 EMail: mcmanus@ducksong.com 1104 URI: https://mozillians.org/u/pmcmanus/ 1106 Julian F. Reschke 1107 greenbytes GmbH 1109 EMail: julian.reschke@greenbytes.de 1110 URI: https://greenbytes.de/tech/webdav/