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/