idnits 2.17.00 (12 Aug 2021) /tmp/idnits16298/draft-ietf-httpbis-alt-svc-09.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 (November 17, 2015) is 2376 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 informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 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: May 20, 2016 Mozilla 6 J. Reschke 7 greenbytes 8 November 17, 2015 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-09 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 May 20, 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 . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . 15 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 . . . . . . . 17 91 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . 21 105 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22 106 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 22 107 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 109 1. Introduction 111 HTTP [RFC7230] conflates the identification of resources with their 112 location. In other words, "http://" (and "https://") URLs are used 113 to both name and find things to interact with. 115 In some cases, it is desirable to separate identification and 116 location in HTTP; keeping the same identifier for a resource, but 117 interacting with it at a different location on the network. 119 For example: 121 o An origin server might wish to redirect a client to a different 122 server when it is under load, or it has found a server in a 123 location that is more local to the client. 125 o An origin server might wish to offer access to its resources using 126 a new protocol (such as HTTP/2, see [RFC7540]) or one using 127 improved security (such as Transport Layer Security (TLS), see 128 [RFC5246]). 130 o An origin server might wish to segment its clients into groups of 131 capabilities, such as those supporting Server Name Indication 132 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for 133 operational purposes. 135 This specification defines a new concept in HTTP, "Alternative 136 Services", that allows an origin server to nominate additional means 137 of interacting with it on the network. It defines a general 138 framework for this in Section 2, along with specific mechanisms for 139 advertising their existence using HTTP header fields (Section 3) or 140 HTTP/2 frames (Section 4), plus a way to indicate that an alternative 141 service was used (Section 5). 143 It also endorses the status code 421 (Misdirected Request) 144 (Section 6) that origin servers (or their nominated alternatives) can 145 use to indicate that they are not authoritative for a given origin, 146 in cases where the wrong location is used. 148 1.1. Notational Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 This document uses the Augmented BNF defined in [RFC5234] along with 155 the "#rule" extension defined in Section 7 of [RFC7230]. The rules 156 below are defined in [RFC5234], [RFC7230], and [RFC7234]: 158 DIGIT = 159 OWS = 160 delta-seconds = 161 port = 162 quoted-string = 163 token = 164 uri-host = 166 2. Alternative Services Concepts 168 This specification defines a new concept in HTTP, the "alternative 169 service". When an origin (see [RFC6454]) has resources that are 170 accessible through a different protocol / host / port combination, it 171 is said to have an alternative service available. 173 An alternative service can be used to interact with the resources on 174 an origin server at a separate location on the network, possibly 175 using a different protocol configuration. Alternative services are 176 considered authoritative for an origin's resources, in the sense of 177 [RFC7230], Section 9.1. 179 For example, an origin: 181 ("http", "www.example.com", "80") 183 might declare that its resources are also accessible at the 184 alternative service: 186 ("h2", "new.example.com", "81") 188 By their nature, alternative services are explicitly at the 189 granularity of an origin; i.e., they cannot be selectively applied to 190 resources within an origin. 192 Alternative services do not replace or change the origin for any 193 given resource; in general, they are not visible to the software 194 "above" the access mechanism. The alternative service is essentially 195 alternative routing information that can also be used to reach the 196 origin in the same way that DNS CNAME or SRV records define routing 197 information at the name resolution level. Each origin maps to a set 198 of these routes -- the default route is derived from the origin 199 itself and the other routes are introduced based on alternative- 200 protocol information. 202 Furthermore, it is important to note that the first member of an 203 alternative service tuple is different from the "scheme" component of 204 an origin; it is more specific, identifying not only the major 205 version of the protocol being used, but potentially communication 206 options for that protocol. 208 This means that clients using an alternative service can change the 209 host, port and protocol that they are using to fetch resources, but 210 these changes MUST NOT be propagated to the application that is using 211 HTTP; from that standpoint, the URI being accessed and all 212 information derived from it (scheme, host, port) are the same as 213 before. 215 Importantly, this includes its security context; in particular, when 216 TLS [RFC5246] is used to authenticate, the alternative service will 217 need to present a certificate for the origin's host name, not that of 218 the alternative. Likewise, the Host header field ([RFC7230], Section 219 5.4) is still derived from the origin, not the alternative service 220 (just as it would if a CNAME were being used). 222 The changes MAY, however, be made visible in debugging tools, 223 consoles, etc. 225 Formally, an alternative service is identified by the combination of: 227 o An Application Layer Protocol Negotiation (ALPN) protocol name, as 228 per [RFC7301] 230 o A host, as per [RFC3986], Section 3.2.2 232 o A port, as per [RFC3986], Section 3.2.3 234 The ALPN protocol name is used to identify the application protocol 235 or suite of protocols used by the alternative service. Note that for 236 the purpose of this specification, an ALPN protocol name implicitly 237 includes TLS in the suite of protocols it identifies, unless 238 specified otherwise in its definition. In particular, the ALPN name 239 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1 240 over TLS. 242 Additionally, each alternative service MUST have: 244 o A freshness lifetime, expressed in seconds; see Section 2.2 246 There are many ways that a client could discover the alternative 247 service(s) associated with an origin. This document describes two 248 such mechanisms: an HTTP header field (Section 3) and an HTTP/2 frame 249 type (Section 4). 251 The remainder of this section describes requirements that are common 252 to alternative services, regardless of how they are discovered. 254 2.1. Host Authentication 256 Clients MUST NOT use alternative services with a host that is 257 different than the origin's without strong server authentication; 258 this mitigates the attack described in Section 9.2. One way to 259 achieve this is for the alternative to use TLS with a certificate 260 that is valid for that origin. 262 For example, if the origin's host is "www.example.com" and an 263 alternative is offered on "other.example.com" with the "h2" protocol, 264 and the certificate offered is valid for "www.example.com", the 265 client can use the alternative. However, if "other.example.com" is 266 offered with the "h2c" protocol, the client cannot use it, because 267 there is no mechanism in that protocol to establish strong server 268 authentication. 270 2.2. Alternative Service Caching 272 Mechanisms for discovering alternative services also associate a 273 freshness lifetime with them; for example, the Alt-Svc header field 274 uses the "ma" parameter. 276 Clients can choose to use an alternative service instead of the 277 origin at any time when it is considered fresh; see Section 2.4 for 278 specific recommendations. 280 Clients with existing connections to an alternative service do not 281 need to stop using it when its freshness lifetime ends; i.e., the 282 caching mechanism is intended for limiting how long an alternative 283 service can be used for establishing new connections, not limiting 284 the use of existing ones. 286 Alternative services are fully authoritative for the origin in 287 question, including the ability to clear or update cached alternative 288 service entries, extend freshness lifetimes, and any other authority 289 the origin server would have. 291 When alternative services are used to send a client to the most 292 optimal server, a change in network configuration can result in 293 cached values becoming suboptimal. Therefore, clients SHOULD remove 294 from cache all alternative services that lack the "persist" flag with 295 the value "1" when they detect such a change (when information about 296 network state is available). 298 2.3. Requiring Server Name Indication 300 A client MUST only use a TLS-based alternative service if the client 301 also supports TLS Server Name Indication (SNI). This supports the 302 conservation of IP addresses on the alternative service host. 304 Note that the SNI information provided in TLS by the client will be 305 that of the origin, not the alternative (as will the Host HTTP header 306 field-value). 308 2.4. Using Alternative Services 310 By their nature, alternative services are OPTIONAL: clients do not 311 need to use them. However, it is advantageous for clients to behave 312 in a predictable way when they are used by servers (e.g., for load 313 balancing). 315 Therefore, if a client becomes aware of an alternative service, the 316 client SHOULD use that alternative service for all requests to the 317 associated origin as soon as it is available, provided the 318 alternative service information is fresh (Section 2.2) and the 319 security properties of the alternative service protocol are 320 desirable, as compared to the existing connection. 322 If a client becomes aware of multiple alternative services, it MAY 323 choose the most suitable according to its own criteria (again, 324 keeping security properties in mind). For example, an origin might 325 advertise multiple alternative services to notify clients of support 326 for multiple versions of HTTP; or, an alternative service might 327 itself advertise an alternative. 329 A client configured to use a proxy for a given request SHOULD NOT 330 directly connect to an alternative service for it, but instead route 331 it through that proxy. 333 When a client uses an alternative service for a request, it can 334 indicate this to the server using the Alt-Used header field 335 (Section 5). 337 The client does not need to block requests on any existing 338 connection; it can be used until the alternative connection is 339 established. However, if the security properties of the existing 340 connection are weak (e.g. cleartext HTTP/1.1) then it might make 341 sense to block until the new connection is fully available in order 342 to avoid information leakage. 344 Furthermore, if the connection to the alternative service fails or is 345 unresponsive, the client MAY fall back to using the origin or another 346 alternative service. Note, however, that this could be the basis of 347 a downgrade attack, thus losing any enhanced security properties of 348 the alternative service. If the connection to the alternative 349 service does not negotiate the expected protocol (for example, ALPN 350 fails to negotiate h2, or an Upgrade request to h2c is not accepted), 351 the connection to the alternative service MUST be considered to have 352 failed. 354 3. The Alt-Svc HTTP Header Field 356 An HTTP(S) origin server can advertise the availability of 357 alternative services to clients by adding an Alt-Svc header field to 358 responses. 360 Alt-Svc = clear / 1#alt-value 361 clear = %x63.6C.65.61.72; "clear", case-sensitive 362 alt-value = alternative *( OWS ";" OWS parameter ) 363 alternative = protocol-id "=" alt-authority 364 protocol-id = token ; percent-encoded ALPN protocol name 365 alt-authority = quoted-string ; containing [ uri-host ] ":" port 366 parameter = token "=" ( token / quoted-string ) 368 The field value consists either of a list of values, each of which 369 indicating one alternative service, or the keyword "clear". 371 A field value containing the special value "clear" indicates that the 372 origin requests all alternatives for that origin to be invalidated 373 (including those specified in the same response, in case of an 374 invalid reply containing both "clear" and alternative services). 376 ALPN protocol names are octet sequences with no additional 377 constraints on format. Octets not allowed in tokens ([RFC7230], 378 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 379 [RFC3986]. Consequently, the octet representing the percent 380 character "%" (hex 25) MUST be percent-encoded as well. 382 In order to have precisely one way to represent any ALPN protocol 383 name, the following additional constraints apply: 385 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if 386 they are valid token characters except "%", and 388 2. When using percent-encoding, uppercase hex digits MUST be used. 390 With these constraints, recipients can apply simple string comparison 391 to match protocol identifiers. 393 The "alt-authority" component consists of an OPTIONAL uri-host 394 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 395 number. 397 For example: 399 Alt-Svc: h2=":8000" 401 This indicates the "h2" protocol ([RFC7540]) on the same host using 402 the indicated port 8000. 404 An example involving a change of host: 406 Alt-Svc: h2="new.example.org:80" 408 This indicates the "h2" protocol on the host "new.example.org", 409 running on port 80. Note that the "quoted-string" syntax needs to be 410 used because ":" is not an allowed character in "token". 412 Examples for protocol name escaping: 414 +--------------------+-------------+---------------------+ 415 | ALPN protocol name | protocol-id | Note | 416 +--------------------+-------------+---------------------+ 417 | h2 | h2 | No escaping needed | 418 +--------------------+-------------+---------------------+ 419 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 420 +--------------------+-------------+---------------------+ 421 | x%y | x%25y | "%" needs escaping | 422 +--------------------+-------------+---------------------+ 424 Alt-Svc MAY occur in any HTTP response message, regardless of the 425 status code. Note that recipients of Alt-Svc are free to ignore the 426 header field (and indeed need to in some situations; see Sections 2.1 427 and 6). 429 The Alt-Svc field value can have multiple values: 431 Alt-Svc: h2c=":8000", h2=":443" 433 When multiple values are present, the order of the values reflects 434 the server's preference (with the first value being the most 435 preferred alternative). 437 The value(s) advertised by Alt-Svc can be used by clients to open a 438 new connection to an alternative service. Subsequent requests can 439 start using this new connection immediately, or can continue using 440 the existing connection while the new connection is created. 442 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC 443 frame (Section 4). A single ALTSVC frame can be sent for a 444 connection; a new frame is not needed for every request. Note that, 445 despite this recommendation, Alt-Svc header fields remain valid in 446 responses delivered over HTTP/2. 448 This specification defines two parameters: "ma" and "persist", 449 defined in Section 3.1. Unknown parameters MUST be ignored, that is 450 the values (alt-value) they appear in MUST be processed as if the 451 unknown parameter was not present. 453 New parameters can be defined in extension specifications (see 454 Section 7.3 for registration details). 456 Note that all field elements that allow "quoted-string" syntax MUST 457 be processed as per Section 3.2.6 of [RFC7230]. 459 3.1. Caching Alt-Svc Header Field Values 461 When an alternative service is advertised using Alt-Svc, it is 462 considered fresh for 24 hours from generation of the message. This 463 can be modified with the 'ma' (max-age) parameter: 465 Alt-Svc: h2=":443"; ma=3600 467 which indicates the number of seconds since the response was 468 generated the alternative service is considered fresh for. 470 ma = delta-seconds 472 See Section 4.2.3 of [RFC7234] for details of determining response 473 age. 475 For example, a response: 477 HTTP/1.1 200 OK 478 Content-Type: text/html 479 Cache-Control: max-age=600 480 Age: 30 481 Alt-Svc: h2c=":8000"; ma=60 483 indicates that an alternative service is available and usable for the 484 next 60 seconds. However, the response has already been cached for 485 30 seconds (as per the Age header field value), so therefore the 486 alternative service is only fresh for the 30 seconds from when this 487 response was received, minus estimated transit time. 489 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 490 does not affect caching of Alt-Svc values. 492 When an Alt-Svc response header field is received from an origin, its 493 value invalidates and replaces all cached alternative services for 494 that origin. 496 By default, cached alternative services will be cleared when the 497 client detects a network change. Alternative services that are 498 intended to be longer-lived (e.g., those that are not specific to the 499 client access network) can carry the "persist" parameter with a value 500 "1" as a hint that the service is potentially useful beyond a network 501 configuration change. 503 persist = 1DIGIT 505 For example: 507 Alt-Svc: h2=":443"; ma=2592000; persist=1 509 This specification only a defines a single value for "persist"; 510 others can be defined in future specifications. Clients MUST ignore 511 "persist" parameters with unknown values. 513 See Section 2.2 for general requirements on caching alternative 514 services. 516 4. The ALTSVC HTTP/2 Frame 518 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the 519 availability of an alternative service to an HTTP/2 client. 521 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 522 that do not support this frame can safely ignore it. 524 An ALTSVC frame from a server to a client on a stream other than 525 stream 0 indicates that the conveyed alternative service is 526 associated with the origin of that stream. 528 An ALTSVC frame from a server to a client on stream 0 indicates that 529 the conveyed alternative service is associated with the origin 530 contained in the Origin field of the frame. An association with an 531 origin that the client does not consider authoritative for the 532 current connection MUST be ignored. 534 The ALTSVC frame type is 0xa (decimal 10). 536 +-------------------------------+-------------------------------+ 537 | Origin-Len (16) | Origin? (*) ... 538 +-------------------------------+-------------------------------+ 539 | Alt-Svc-Field-Value (*) ... 540 +---------------------------------------------------------------+ 541 ALTSVC Frame Payload 543 The ALTSVC frame contains the following fields: 545 Origin-Len: An unsigned, 16-bit integer indicating the length, in 546 octets, of the Origin field. 548 Origin: An OPTIONAL sequence of characters containing the ASCII 549 serialization of an origin ([RFC6454], Section 6.2) that the 550 alternative service is applicable to. 552 Alt-Svc-Field-Value: A sequence of octets (length determined by 553 subtracting the length of all preceding fields from the frame 554 length) containing a value identical to the Alt-Svc field value 555 defined in Section 3 (ABNF production "Alt-Svc"). 557 The ALTSVC frame does not define any flags. 559 The ALTSVC frame is intended for receipt by clients; a server that 560 receives an ALTSVC frame can safely ignore it. 562 An ALTSVC frame on stream 0 with empty (length 0) "Origin" 563 information is invalid and MUST be ignored. An ALTSVC frame on a 564 stream other than stream 0 containing non-empty "Origin" information 565 is invalid and MUST be ignored. 567 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 568 forward ALTSVC frames, though it can use the information contained in 569 ALTSVC frames in forming new ALTSVC frames to send to its own 570 clients. 572 5. The Alt-Used HTTP Header Field 574 The Alt-Used header field is used in requests to indicate the 575 identity of the alternative service in use, just as the Host header 576 field (Section 5.4 of [RFC7230]) identifies the host and port of the 577 origin. 579 Alt-Used = uri-host [ ":" port ] 581 Alt-Used is intended to allow alternative services to detect loops, 582 differentiate traffic for purposes of load balancing, and generally 583 to ensure that it is possible to identify the intended destination of 584 traffic, since introducing this information after a protocol is in 585 use has proven to be problematic. 587 When using an alternative service, clients SHOULD include a Alt-Used 588 header field in all requests. 590 As the Alt-Used header field might be used by the server for tracking 591 the client, a client MAY choose not to include it in its requests for 592 protecting its privacy (see Section 9.4). 594 For example: 596 GET /thing HTTP/1.1 597 Host: origin.example.com 598 Alt-Used: alternate.example.net 600 6. The 421 Misdirected Request HTTP Status Code 602 The 421 (Misdirected Request) status code is defined in Section 9.1.2 603 of [RFC7540] to indicate that the current server instance is not 604 authoritative for the requested resource. This can be used to 605 indicate that an alternative service is not authoritative; see 606 Section 2). 608 Clients receiving 421 (Misdirected Request) from an alternative 609 service MUST remove the corresponding entry from its alternative 610 service cache (see Section 2.2) for that origin. Regardless of the 611 idempotency of the request method, they MAY retry the request, either 612 at another alternative server, or at the origin. 614 An Alt-Svc header field in a 421 (Misdirected Request) response MUST 615 be ignored. 617 7. IANA Considerations 619 7.1. Header Field Registrations 621 HTTP header fields are registered within the "Message Headers" 622 registry maintained at 623 . 625 This document defines the following HTTP header fields, so their 626 associated registry entries shall be added according to the permanent 627 registrations below (see [BCP90]): 629 +-------------------+----------+----------+-----------+ 630 | Header Field Name | Protocol | Status | Reference | 631 +-------------------+----------+----------+-----------+ 632 | Alt-Svc | http | standard | Section 3 | 633 | Alt-Used | http | standard | Section 5 | 634 +-------------------+----------+----------+-----------+ 636 The change controller is: "IETF (iesg@ietf.org) - Internet 637 Engineering Task Force". 639 7.2. The ALTSVC HTTP/2 Frame Type 641 This document registers the ALTSVC frame type in the HTTP/2 Frame 642 Types registry ([RFC7540], Section 11.2). 644 Frame Type: ALTSVC 646 Code: 0xa 648 Specification: Section 4 of this document 650 7.3. Alt-Svc Parameter Registry 652 The HTTP Alt-Svc Parameter Registry defines the name space for the 653 cache directives. It will be created and maintained at (the 654 suggested URI) 655 . 657 7.3.1. Procedure 659 A registration MUST include the following fields: 661 o Parameter Name 663 o Pointer to specification text 665 Values to be added to this name space require Expert Review (see 666 [RFC5226], Section 4.1). 668 7.3.2. Registrations 670 The HTTP Alt-Svc Parameter Registry is to be populated with the 671 registrations below: 673 +-------------------+-------------+ 674 | Alt-Svc Parameter | Reference | 675 +-------------------+-------------+ 676 | ma | Section 3.1 | 677 | persist | Section 3.1 | 678 +-------------------+-------------+ 680 8. Internationalization Considerations 682 An internationalized domain name that appears in either the header 683 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 684 using A-labels ([RFC5890], Section 2.3.2.1). 686 9. Security Considerations 688 9.1. Changing Ports 690 Using an alternative service implies accessing an origin's resources 691 on an alternative port, at a minimum. An attacker that can inject 692 alternative services and listen at the advertised port is therefore 693 able to hijack an origin. On certain servers, it is normal for users 694 to be able to control some personal pages available on a shared port, 695 and also to accept to requests on less-privileged ports. 697 For example, an attacker that can add HTTP response header fields to 698 some pages can redirect traffic for an entire origin to a different 699 port on the same host using the Alt-Svc header field; if that port is 700 under the attacker's control, they can thus masquerade as the HTTP 701 server. 703 On servers, this risk can be reduced by restricting the ability to 704 advertise alternative services, and restricting who can open a port 705 for listening on that host. Clients can reduce this risk by imposing 706 stronger requirements (e.g. strong authentication) when moving from 707 System Ports to User or Dynamic Ports, or from User Ports to Dynamic 708 Ports, as defined in Section 6 of [RFC6335]. 710 It is always valid for a client to ignore an alternative service 711 advertisement which does not meet its implementation-specific 712 security requirements. Servers can increase the likelihood of 713 clients using the alternative service by providing strong 714 authentication even when not required. 716 9.2. Changing Hosts 718 When the host is changed due to the use of an alternative service, it 719 presents an opportunity for attackers to hijack communication to an 720 origin. 722 For example, if an attacker can convince a user agent to send all 723 traffic for "innocent.example.org" to "evil.example.com" by 724 successfully associating it as an alternative service, they can 725 masquerade as that origin. This can be done locally (see mitigations 726 in Section 9.1) or remotely (e.g., by an intermediary as a man-in- 727 the-middle attack). 729 This is the reason for the requirement in Section 2.1 that any 730 alternative service with a host different to the origin's be strongly 731 authenticated with the origin's identity; i.e., presenting a 732 certificate for the origin proves that the alternative service is 733 authorized to serve traffic for the origin. 735 However, this authorization is only as strong as the method used to 736 authenticate the alternative service. In particular, there are well- 737 known exploits to make an attacker's certificate appear as 738 legitimate. 740 Alternative services could be used to persist such an attack; for 741 example, an intermediary could man-in-the-middle TLS-protected 742 communication to a target, and then direct all traffic to an 743 alternative service with a large freshness lifetime, so that the user 744 agent still directs traffic to the attacker even when not using the 745 intermediary. 747 Implementations MUST perform any certificate-pinning validation (e.g. 748 [RFC7469]) on alternative services just as they would on direct 749 connections to the origin. Implementations might also choose to add 750 other requirements around which certificates are acceptable for 751 alternative services. 753 9.3. Changing Protocols 755 When the ALPN protocol is changed due to the use of an alternative 756 service, the security properties of the new connection to the origin 757 can be different from that of the "normal" connection to the origin, 758 because the protocol identifier itself implies this. 760 For example, if a "https://" URI has a protocol advertised that does 761 not use some form of end-to-end encryption (most likely, TLS), it 762 violates the expectations for security that the URI scheme implies. 764 Therefore, clients cannot blindly use alternative services, but 765 instead evaluate the option(s) presented to assure that security 766 requirements and expectations (of specifications, implementations and 767 end users) are met. 769 9.4. Tracking Clients Using Alternative Services 771 Choosing an alternative service implies connecting to a new, server- 772 supplied host name. By using many different (potentially unique) 773 host names, servers could conceivably track client requests. Such 774 tracking could follow users across multiple networks, when the 775 "persist" flag is used. 777 Clients concerned by the additional fingerprinting can choose to 778 ignore alternative service advertisements. 780 In a user agent, any alternative service information MUST be removed 781 when origin-specific data is cleared (for instance, when cookies are 782 cleared). 784 9.5. Confusion Regarding Request Scheme 786 Some server-side HTTP applications make assumptions about security 787 based upon connection context; for example, equating being served 788 upon port 443 with the use of a HTTPS URL (and the various security 789 properties that implies). 791 This affects not only the security properties of the connection 792 itself, but also the state of the client at the other end of it; for 793 example, a Web browser treats HTTPS URLs differently than HTTP URLs 794 in many ways, not just for purposes of protocol handling. 796 Since one of the uses of Alternative Services is to allow a 797 connection to be migrated to a different protocol and port, these 798 applications can become confused about the security properties of a 799 given connection, sending information (e.g., cookies, content) that 800 is intended for a secure context (e.g., a HTTPS URL) to a client that 801 is not treating it as one. 803 This risk can be mitigated in servers by using the URL scheme 804 explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the 805 "absolute form" of the request target in HTTP/1.1) as an indication 806 of security context, instead of other connection properties 807 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). 809 When the protocol does not explicitly carry the scheme (e.g., as is 810 usually the case for HTTP/1.1 over TLS, servers can, mitigate this 811 risk by either assuming that all requests have an insecure context, 812 or by refraining from advertising alternative services for insecure 813 schemes (such as HTTP). 815 10. References 817 10.1. Normative References 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 821 RFC2119, March 1997, 822 . 824 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 825 Resource Identifier (URI): Generic Syntax", STD 66, 826 RFC 3986, DOI 10.17487/RFC3986, January 2005, 827 . 829 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 830 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 831 DOI 10.17487/RFC5226, May 2008, 832 . 834 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 835 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 836 RFC5234, January 2008, 837 . 839 [RFC5890] Klensin, J., "Internationalized Domain Names for 840 Applications (IDNA): Definitions and Document Framework", 841 RFC 5890, DOI 10.17487/RFC5890, August 2010, 842 . 844 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 845 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, 846 January 2011, . 848 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 849 DOI 10.17487/RFC6454, December 2011, 850 . 852 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 853 Protocol (HTTP/1.1): Message Syntax and Routing", 854 RFC 7230, DOI 10.17487/RFC7230, June 2014, 855 . 857 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 858 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 859 RFC 7234, DOI 10.17487/RFC7234, June 2014, 860 . 862 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, 863 "Transport Layer Security (TLS) Application-Layer Protocol 864 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 865 July 2014, . 867 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 868 Transfer Protocol version 2", RFC 7540, DOI 10.17487/ 869 RFC7540, May 2015, 870 . 872 10.2. Informative References 874 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 875 Procedures for Message Header Fields", BCP 90, RFC 3864, 876 September 2004, . 878 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 879 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 880 RFC5246, August 2008, 881 . 883 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 884 Cheshire, "Internet Assigned Numbers Authority (IANA) 885 Procedures for the Management of the Service Name and 886 Transport Protocol Port Number Registry", RFC 6335, 887 DOI 10.17487/RFC6335, August 2011, 888 . 890 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 891 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, 892 April 2015, . 894 Appendix A. Change Log (to be removed by RFC Editor before publication) 896 A.1. Since draft-nottingham-httpbis-alt-svc-05 898 This is the first version after adoption of 899 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 900 only contains editorial changes. 902 A.2. Since draft-ietf-httpbis-alt-svc-00 904 Selected 421 as proposed status code for "Not Authoritative". 906 Changed header field syntax to use percent-encoding of ALPN protocol 907 names (). 909 A.3. Since draft-ietf-httpbis-alt-svc-01 911 Updated HTTP/1.1 references. 913 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 914 to address fingerprinting concerns 915 (). 917 Note that ALTSVC frame is preferred to Alt-Svc header field 918 (). 920 Incorporate ALTSRV frame 921 (). 923 Moved definition of status code 421 to HTTP/2. 925 Partly resolved . 927 A.4. Since draft-ietf-httpbis-alt-svc-02 929 Updated ALPN reference. 931 Resolved . 933 A.5. Since draft-ietf-httpbis-alt-svc-03 935 Renamed "Alt-Svc-Used" to "Alt-Used" 936 (). 938 Clarify ALTSVC Origin information requirements 939 (). 941 Remove/tune language with respect to tracking risks (see 942 ). 944 A.6. Since draft-ietf-httpbis-alt-svc-04 946 Mention tracking by alt-svc host name in Security Considerations 947 (). 949 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 951 Allow the frame to carry multiple indicator and use the same payload 952 formats for both 953 (). 955 A.7. Since draft-ietf-httpbis-alt-svc-05 957 Go back to specifying the origin in Alt-Used, but make it a "SHOULD" 958 (). 960 Restore Origin field in ALT-SVC frame 961 (). 963 A.8. Since draft-ietf-httpbis-alt-svc-06 965 Disallow use of alternative services when the protocol might not 966 carry the scheme 967 (). 969 Align opp-sec and alt-svc 970 (). 972 alt svc frame on pushed (even and non-0) frame 973 (). 975 "browser" -> "user agent" 976 (). 978 ABNF for "parameter" 979 (). 981 Updated HTTP/2 reference. 983 A.9. Since draft-ietf-httpbis-alt-svc-07 985 Alt-Svc alternative cache invalidation 986 (). 988 Unexpected Alt-Svc frames 989 (). 991 Associating Alt-Svc header with an origin 992 (). 994 ALPN identifiers in Alt-Svc 995 (). 997 Number of alternate services used 998 (). 1000 Proxy and .pac interaction 1001 (). 1003 Need to define extensibility for alt-svc parameters 1004 (). 1006 Persistence of alternates across network changes 1007 (). 1009 Alt-Svc header with 421 status 1010 (). 1012 Incorporate several editorial improvements suggested by Mike Bishop 1013 (, 1014 ). 1016 Alt-Svc response header field in HTTP/2 frame 1017 (). 1019 A.10. Since draft-ietf-httpbis-alt-svc-08 1021 Remove left over text about ext-params, applying to an earlier 1022 version of Alt-Used (see 1023 ). 1025 Conflicts between Alt-Svc and ALPN 1026 (). 1028 Elevation of privilege 1029 (). 1031 Alternates of alternates 1032 (). 1034 Alt-Svc and Cert Pinning 1035 (). 1037 Using alt-svc on localhost (no change to spec, see 1038 ). 1040 IANA procedure for alt-svc parameters 1041 (). 1043 Alt-svc from https (1.1) to https (1.1) 1044 (). 1046 Alt-svc vs the ability to convey the scheme inside the protocol 1047 (). 1049 Reconciling MAY/can vs. SHOULD 1050 (). 1052 Typo in alt-svc caching example 1053 (). 1055 Appendix B. Acknowledgements 1057 Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy 1058 Podjarny, Herve Ruellan, Martin Thomson, Matthew Kerwin, Mike Bishop, 1059 Paul Hoffman, Richard Barnes, Richard Bradbury, Stephen Farrell, 1060 Stephen Ludin, and Will Chan for their feedback and suggestions. 1062 The Alt-Svc header field was influenced by the design of the 1063 Alternate-Protocol header field in SPDY. 1065 Authors' Addresses 1067 Mark Nottingham 1068 Akamai 1070 EMail: mnot@mnot.net 1071 URI: https://www.mnot.net/ 1073 Patrick McManus 1074 Mozilla 1076 EMail: mcmanus@ducksong.com 1077 URI: https://mozillians.org/u/pmcmanus/ 1079 Julian F. Reschke 1080 greenbytes GmbH 1082 EMail: julian.reschke@greenbytes.de 1083 URI: https://greenbytes.de/tech/webdav/