idnits 2.17.1
draft-ietf-httpbis-alt-svc-12.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 9, 2016) is 2999 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 12, 2016 Mozilla
6 J. Reschke
7 greenbytes
8 February 9, 2016
10 HTTP Alternative Services
11 draft-ietf-httpbis-alt-svc-12
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 12, 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 . . . . . . . 17
90 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . 20
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 . . . . . . . . . . . 21
103 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 21
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 . . . . . . . . . . . 23
107 A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24
108 A.13. Since draft-ietf-httpbis-alt-svc-11 . . . . . . . . . . . 24
109 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
111 1. Introduction
113 HTTP [RFC7230] conflates the identification of resources with their
114 location. In other words, "http://" (and "https://") URIs are used
115 to both name and find things to interact with.
117 In some cases, it is desirable to separate identification and
118 location in HTTP; keeping the same identifier for a resource, but
119 interacting with it at a different location on the network.
121 For example:
123 o An origin server might wish to redirect a client to a different
124 server when it is under load, or it has found a server in a
125 location that is more local to the client.
127 o An origin server might wish to offer access to its resources using
128 a new protocol (such as HTTP/2, see [RFC7540]) or one using
129 improved security (such as Transport Layer Security (TLS), see
130 [RFC5246]).
132 o An origin server might wish to segment its clients into groups of
133 capabilities, such as those supporting Server Name Indication
134 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for
135 operational purposes.
137 This specification defines a new concept in HTTP, "Alternative
138 Services", that allows an origin server to nominate additional means
139 of interacting with it on the network. It defines a general
140 framework for this in Section 2, along with specific mechanisms for
141 advertising their existence using HTTP header fields (Section 3) or
142 HTTP/2 frames (Section 4), plus a way to indicate that an alternative
143 service was used (Section 5).
145 It also endorses the status code 421 (Misdirected Request)
146 (Section 6) that origin servers (or their nominated alternatives) can
147 use to indicate that they are not authoritative for a given origin,
148 in cases where the wrong location is used.
150 1.1. Notational Conventions
152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
154 document are to be interpreted as described in [RFC2119].
156 This document uses the Augmented BNF defined in [RFC5234] and updated
157 by [RFC7405] along with the "#rule" extension defined in Section 7 of
158 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and
160 [RFC7234]:
162 OWS =
163 delta-seconds =
164 port =
165 quoted-string =
166 token =
167 uri-host =
169 2. Alternative Services Concepts
171 This specification defines a new concept in HTTP, the "Alternative
172 Service". When an origin (see [RFC6454]) has resources that are
173 accessible through a different protocol / host / port combination, it
174 is said to have an alternative service available.
176 An alternative service can be used to interact with the resources on
177 an origin server at a separate location on the network, possibly
178 using a different protocol configuration. Alternative services are
179 considered authoritative for an origin's resources, in the sense of
180 [RFC7230], Section 9.1.
182 For example, an origin:
184 ("http", "www.example.com", "80")
186 might declare that its resources are also accessible at the
187 alternative service:
189 ("h2", "new.example.com", "81")
191 By their nature, alternative services are explicitly at the
192 granularity of an origin; i.e., they cannot be selectively applied to
193 resources within an origin.
195 Alternative services do not replace or change the origin for any
196 given resource; in general, they are not visible to the software
197 "above" the access mechanism. The alternative service is essentially
198 alternative routing information that can also be used to reach the
199 origin in the same way that DNS CNAME or SRV records define routing
200 information at the name resolution level. Each origin maps to a set
201 of these routes -- the default route is derived from the origin
202 itself and the other routes are introduced based on alternative-
203 service information.
205 Furthermore, it is important to note that the first member of an
206 alternative service tuple is different from the "scheme" component of
207 an origin; it is more specific, identifying not only the major
208 version of the protocol being used, but potentially communication
209 options for that protocol.
211 This means that clients using an alternative service can change the
212 host, port and protocol that they are using to fetch resources, but
213 these changes MUST NOT be propagated to the application that is using
214 HTTP; from that standpoint, the URI being accessed and all
215 information derived from it (scheme, host, port) are the same as
216 before.
218 Importantly, this includes its security context; in particular, when
219 TLS [RFC5246] is used to authenticate, the alternative service will
220 need to present a certificate for the origin's host name, not that of
221 the alternative. Likewise, the Host header field ([RFC7230], Section
222 5.4) is still derived from the origin, not the alternative service
223 (just as it would if a CNAME were being used).
225 The changes MAY, however, be made visible in debugging tools,
226 consoles, etc.
228 Formally, an alternative service is identified by the combination of:
230 o An Application Layer Protocol Negotiation (ALPN) protocol name, as
231 per [RFC7301]
233 o A host, as per [RFC3986], Section 3.2.2
235 o A port, as per [RFC3986], Section 3.2.3
237 The ALPN protocol name is used to identify the application protocol
238 or suite of protocols used by the alternative service. Note that for
239 the purpose of this specification, an ALPN protocol name implicitly
240 includes TLS in the suite of protocols it identifies, unless
241 specified otherwise in its definition. In particular, the ALPN name
242 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1
243 over TLS.
245 Additionally, each alternative service MUST have:
247 o A freshness lifetime, expressed in seconds; see Section 2.2
249 There are many ways that a client could discover the alternative
250 service(s) associated with an origin. This document describes two
251 such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the
252 "ALTSVC" HTTP/2 frame type (Section 4).
254 The remainder of this section describes requirements that are common
255 to alternative services, regardless of how they are discovered.
257 2.1. Host Authentication
259 Clients MUST have reasonable assurances that the alternative service
260 is under control of and valid for the whole origin. This mitigates
261 the attack described in Section 9.2. One way to achieve this is for
262 the alternative to use TLS with a certificate that is valid for the
263 origin.
265 For example, if the origin's host is "www.example.com" and an
266 alternative is offered on "other.example.com" with the "h2" protocol,
267 and the certificate offered is valid for "www.example.com", the
268 client can use the alternative. However, if "other.example.com" is
269 offered with the "h2c" protocol, the client cannot use it, because
270 there is no mechanism in that protocol to establish the relationship
271 between the origin and the alternative.
273 2.2. Alternative Service Caching
275 Mechanisms for discovering alternative services also associate a
276 freshness lifetime with them; for example, the Alt-Svc header field
277 uses the "ma" parameter.
279 Clients can choose to use an alternative service instead of the
280 origin at any time when it is considered fresh; see Section 2.4 for
281 specific recommendations.
283 Clients with existing connections to an alternative service do not
284 need to stop using it when its freshness lifetime ends; i.e., the
285 caching mechanism is intended for limiting how long an alternative
286 service can be used for establishing new connections, not limiting
287 the use of existing ones.
289 Alternative services are fully authoritative for the origin in
290 question, including the ability to clear or update cached alternative
291 service entries, extend freshness lifetimes, and any other authority
292 the origin server would have.
294 When alternative services are used to send a client to the most
295 optimal server, a change in network configuration can result in
296 cached values becoming suboptimal. Therefore, clients SHOULD remove
297 from cache all alternative services that lack the "persist" flag with
298 the value "1" when they detect such a change (when information about
299 network state is available).
301 2.3. Requiring Server Name Indication
303 A client MUST only use a TLS-based alternative service if the client
304 also supports TLS Server Name Indication (SNI). This supports the
305 conservation of IP addresses on the alternative service host.
307 Note that the SNI information provided in TLS by the client will be
308 that of the origin, not the alternative (as will the Host HTTP header
309 field value).
311 2.4. Using Alternative Services
313 By their nature, alternative services are OPTIONAL: clients do not
314 need to use them. However, it is advantageous for clients to behave
315 in a predictable way when alternative services are used by servers
316 (e.g., for load balancing).
318 Therefore, if a client becomes aware of an alternative service, the
319 client SHOULD use that alternative service for all requests to the
320 associated origin as soon as it is available, provided the
321 alternative service information is fresh (Section 2.2) and the
322 security properties of the alternative service protocol are
323 desirable, as compared to the existing connection. A viable
324 alternative service is then treated in every way as the origin; this
325 includes the ability to advertise alternative services.
327 If a client becomes aware of multiple alternative services, it
328 chooses the most suitable according to its own criteria (again,
329 keeping security properties in mind). For example, an origin might
330 advertise multiple alternative services to notify clients of support
331 for multiple versions of HTTP.
333 A client configured to use a proxy for a given request SHOULD NOT
334 directly connect to an alternative service for this request, but
335 instead route it through that proxy.
337 When a client uses an alternative service for a request, it can
338 indicate this to the server using the Alt-Used header field
339 (Section 5).
341 The client does not need to block requests on any existing
342 connection; it can be used until the alternative connection is
343 established. However, if the security properties of the existing
344 connection are weak (e.g. cleartext HTTP/1.1) then it might make
345 sense to block until the new connection is fully available in order
346 to avoid information leakage.
348 Furthermore, if the connection to the alternative service fails or is
349 unresponsive, the client MAY fall back to using the origin or another
350 alternative service. Note, however, that this could be the basis of
351 a downgrade attack, thus losing any enhanced security properties of
352 the alternative service. If the connection to the alternative
353 service does not negotiate the expected protocol (for example, ALPN
354 fails to negotiate h2, or an Upgrade request to h2c is not accepted),
355 the connection to the alternative service MUST be considered to have
356 failed.
358 3. The Alt-Svc HTTP Header Field
360 An HTTP(S) origin server can advertise the availability of
361 alternative services to clients by adding an Alt-Svc header field to
362 responses.
364 Alt-Svc = clear / 1#alt-value
365 clear = %s"clear"; "clear", case-sensitive
366 alt-value = alternative *( OWS ";" OWS parameter )
367 alternative = protocol-id "=" alt-authority
368 protocol-id = token ; percent-encoded ALPN protocol name
369 alt-authority = quoted-string ; containing [ uri-host ] ":" port
370 parameter = token "=" ( token / quoted-string )
372 The field value consists either of a list of values, each of which
373 indicates one alternative service, or the keyword "clear".
375 A field value containing the special value "clear" indicates that the
376 origin requests all alternatives for that origin to be invalidated
377 (including those specified in the same response, in case of an
378 invalid reply containing both "clear" and alternative services).
380 ALPN protocol names are octet sequences with no additional
381 constraints on format. Octets not allowed in tokens ([RFC7230],
382 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
383 [RFC3986]. Consequently, the octet representing the percent
384 character "%" (hex 25) MUST be percent-encoded as well.
386 In order to have precisely one way to represent any ALPN protocol
387 name, the following additional constraints apply:
389 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if
390 they are valid token characters except "%", and
392 2. When using percent-encoding, uppercase hex digits MUST be used.
394 With these constraints, recipients can apply simple string comparison
395 to match protocol identifiers.
397 The "alt-authority" component consists of an OPTIONAL uri-host
398 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port
399 number.
401 For example:
403 Alt-Svc: h2=":8000"
405 This indicates the "h2" protocol ([RFC7540]) on the same host using
406 the indicated port 8000.
408 An example involving a change of host:
410 Alt-Svc: h2="new.example.org:80"
412 This indicates the "h2" protocol on the host "new.example.org",
413 running on port 80. Note that the "quoted-string" syntax needs to be
414 used because ":" is not an allowed character in "token".
416 Examples for protocol name escaping:
418 +--------------------+-------------+---------------------+
419 | ALPN protocol name | protocol-id | Note |
420 +--------------------+-------------+---------------------+
421 | h2 | h2 | No escaping needed |
422 +--------------------+-------------+---------------------+
423 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
424 +--------------------+-------------+---------------------+
425 | x%y | x%25y | "%" needs escaping |
426 +--------------------+-------------+---------------------+
428 Alt-Svc MAY occur in any HTTP response message, regardless of the
429 status code. Note that recipients of Alt-Svc are free to ignore the
430 header field (and indeed need to in some situations; see Sections 2.1
431 and 6).
433 The Alt-Svc field value can have multiple values:
435 Alt-Svc: h2c=":8000", h2=":443"
437 When multiple values are present, the order of the values reflects
438 the server's preference (with the first value being the most
439 preferred alternative).
441 The value(s) advertised by Alt-Svc can be used by clients to open a
442 new connection to an alternative service. Subsequent requests can
443 start using this new connection immediately, or can continue using
444 the existing connection while the new connection is created.
446 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC
447 frame (Section 4). A single ALTSVC frame can be sent for a
448 connection; a new frame is not needed for every request. Note that,
449 despite this recommendation, Alt-Svc header fields remain valid in
450 responses delivered over HTTP/2.
452 Each "alt-value" is followed by an OPTIONAL semicolon-separated list
453 of additional parameters, each such "parameter" comprising a name and
454 a value.
456 This specification defines two parameters: "ma" and "persist",
457 defined in Section 3.1. Unknown parameters MUST be ignored, that is
458 the values (alt-value) they appear in MUST be processed as if the
459 unknown parameter was not present.
461 New parameters can be defined in extension specifications (see
462 Section 7.3 for registration details).
464 Note that all field elements that allow "quoted-string" syntax MUST
465 be processed as per Section 3.2.6 of [RFC7230].
467 3.1. Caching Alt-Svc Header Field Values
469 When an alternative service is advertised using Alt-Svc, it is
470 considered fresh for 24 hours from generation of the message. This
471 can be modified with the 'ma' (max-age) parameter.
473 Syntax:
475 ma = delta-seconds; see [RFC7234], Section 1.2.1
477 The delta-seconds value indicates the number of seconds since the
478 response was generated the alternative service is considered fresh
479 for.
481 Alt-Svc: h2=":443"; ma=3600
483 See Section 4.2.3 of [RFC7234] for details of determining response
484 age.
486 For example, a response:
488 HTTP/1.1 200 OK
489 Content-Type: text/html
490 Cache-Control: max-age=600
491 Age: 30
492 Alt-Svc: h2c=":8000"; ma=60
494 indicates that an alternative service is available and usable for the
495 next 60 seconds. However, the response has already been cached for
496 30 seconds (as per the Age header field value), so therefore the
497 alternative service is only fresh for the 30 seconds from when this
498 response was received, minus estimated transit time.
500 Note that the freshness lifetime for HTTP caching (here, 600 seconds)
501 does not affect caching of Alt-Svc values.
503 When an Alt-Svc response header field is received from an origin, its
504 value invalidates and replaces all cached alternative services for
505 that origin.
507 By default, cached alternative services will be cleared when the
508 client detects a network change. Alternative services that are
509 intended to be longer-lived (e.g., those that are not specific to the
510 client access network) can carry the "persist" parameter with a value
511 "1" as a hint that the service is potentially useful beyond a network
512 configuration change.
514 Syntax:
516 persist = "1"
518 For example:
520 Alt-Svc: h2=":443"; ma=2592000; persist=1
522 This specification only defines a single value for "persist".
523 Clients MUST ignore "persist" parameters with values other than "1".
525 See Section 2.2 for general requirements on caching alternative
526 services.
528 4. The ALTSVC HTTP/2 Frame
530 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
531 availability of an alternative service to an HTTP/2 client.
533 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints
534 that do not support this frame can safely ignore it.
536 An ALTSVC frame from a server to a client on a stream other than
537 stream 0 indicates that the conveyed alternative service is
538 associated with the origin of that stream.
540 An ALTSVC frame from a server to a client on stream 0 indicates that
541 the conveyed alternative service is associated with the origin
542 contained in the Origin field of the frame. An association with an
543 origin that the client does not consider authoritative for the
544 current connection MUST be ignored.
546 The ALTSVC frame type is 0xa (decimal 10).
548 +-------------------------------+-------------------------------+
549 | Origin-Len (16) | Origin? (*) ...
550 +-------------------------------+-------------------------------+
551 | Alt-Svc-Field-Value (*) ...
552 +---------------------------------------------------------------+
554 ALTSVC Frame Payload
556 The ALTSVC frame contains the following fields:
558 Origin-Len: An unsigned, 16-bit integer indicating the length, in
559 octets, of the Origin field.
561 Origin: An OPTIONAL sequence of characters containing the ASCII
562 serialization of an origin ([RFC6454], Section 6.2) that the
563 alternative service is applicable to.
565 Alt-Svc-Field-Value: A sequence of octets (length determined by
566 subtracting the length of all preceding fields from the frame
567 length) containing a value identical to the Alt-Svc field value
568 defined in Section 3 (ABNF production "Alt-Svc").
570 The ALTSVC frame does not define any flags.
572 The ALTSVC frame is intended for receipt by clients; a server that
573 receives an ALTSVC frame can safely ignore it.
575 An ALTSVC frame on stream 0 with empty (length 0) "Origin"
576 information is invalid and MUST be ignored. An ALTSVC frame on a
577 stream other than stream 0 containing non-empty "Origin" information
578 is invalid and MUST be ignored.
580 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
581 forward ALTSVC frames, though it can use the information contained in
582 ALTSVC frames in forming new ALTSVC frames to send to its own
583 clients.
585 Receiving an ALTSVC frame is semantically equivalent to receiving an
586 Alt-Svc header field. As a result, the ALTSVC frame causes
587 alternative services for the corresponding origin to be replaced.
588 Note that it would be unwise to mix the use of Alt-Svc header fields
589 with the use of ALTSVC frames, as the sequence of receipt might be
590 hard to predict.
592 5. The Alt-Used HTTP Header Field
594 The Alt-Used header field is used in requests to indicate the
595 identity of the alternative service in use, just as the Host header
596 field (Section 5.4 of [RFC7230]) identifies the host and port of the
597 origin.
599 Alt-Used = uri-host [ ":" port ]
601 Alt-Used is intended to allow alternative services to detect loops,
602 differentiate traffic for purposes of load balancing, and generally
603 to ensure that it is possible to identify the intended destination of
604 traffic, since introducing this information after a protocol is in
605 use has proven to be problematic.
607 When using an alternative service, clients SHOULD include an Alt-Used
608 header field in all requests.
610 For example:
612 GET /thing HTTP/1.1
613 Host: origin.example.com
614 Alt-Used: alternate.example.net
616 6. The 421 Misdirected Request HTTP Status Code
618 The 421 (Misdirected Request) status code is defined in Section 9.1.2
619 of [RFC7540] to indicate that the current server instance is not
620 authoritative for the requested resource. This can be used to
621 indicate that an alternative service is not authoritative; see
622 Section 2).
624 Clients receiving 421 (Misdirected Request) from an alternative
625 service MUST remove the corresponding entry from its alternative
626 service cache (see Section 2.2) for that origin. Regardless of the
627 idempotency of the request method, they MAY retry the request, either
628 at another alternative server, or at the origin.
630 An Alt-Svc header field in a 421 (Misdirected Request) response MUST
631 be ignored.
633 7. IANA Considerations
635 7.1. Header Field Registrations
637 HTTP header fields are registered within the "Message Headers"
638 registry maintained at
639 .
641 This document defines the following HTTP header fields, so their
642 associated registry entries shall be added according to the permanent
643 registrations below (see [BCP90]):
645 +-------------------+----------+----------+-----------+
646 | Header Field Name | Protocol | Status | Reference |
647 +-------------------+----------+----------+-----------+
648 | Alt-Svc | http | standard | Section 3 |
649 | Alt-Used | http | standard | Section 5 |
650 +-------------------+----------+----------+-----------+
652 The change controller is: "IETF (iesg@ietf.org) - Internet
653 Engineering Task Force".
655 7.2. The ALTSVC HTTP/2 Frame Type
657 This document registers the ALTSVC frame type in the HTTP/2 Frame
658 Types registry ([RFC7540], Section 11.2).
660 Frame Type: ALTSVC
662 Code: 0xa
664 Specification: Section 4 of this document
666 7.3. Alt-Svc Parameter Registry
668 The HTTP Alt-Svc Parameter Registry defines the name space for
669 parameters. It will be created and maintained at (the suggested URI)
670 .
672 7.3.1. Procedure
674 A registration MUST include the following fields:
676 o Parameter Name
678 o Pointer to specification text
680 Values to be added to this name space require Expert Review (see
681 [RFC5226], Section 4.1).
683 7.3.2. Registrations
685 The HTTP Alt-Svc Parameter Registry is to be populated with the
686 registrations below:
688 +-------------------+-------------+
689 | Alt-Svc Parameter | Reference |
690 +-------------------+-------------+
691 | ma | Section 3.1 |
692 | persist | Section 3.1 |
693 +-------------------+-------------+
695 8. Internationalization Considerations
697 An internationalized domain name that appears in either the header
698 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed
699 using A-labels ([RFC5890], Section 2.3.2.1).
701 9. Security Considerations
703 9.1. Changing Ports
705 Using an alternative service implies accessing an origin's resources
706 on an alternative port, at a minimum. An attacker that can inject
707 alternative services and listen at the advertised port is therefore
708 able to hijack an origin. On certain servers, it is normal for users
709 to be able to control some personal pages available on a shared port,
710 and also to accept to requests on less-privileged ports.
712 For example, an attacker that can add HTTP response header fields to
713 some pages can redirect traffic for an entire origin to a different
714 port on the same host using the Alt-Svc header field; if that port is
715 under the attacker's control, they can thus masquerade as the HTTP
716 server.
718 This risk is mitigated by the requirements in Section 2.1.
720 On servers, this risk can also be reduced by restricting the ability
721 to advertise alternative services, and restricting who can open a
722 port for listening on that host.
724 9.2. Changing Hosts
726 When the host is changed due to the use of an alternative service, it
727 presents an opportunity for attackers to hijack communication to an
728 origin.
730 For example, if an attacker can convince a user agent to send all
731 traffic for "innocent.example.org" to "evil.example.com" by
732 successfully associating it as an alternative service, they can
733 masquerade as that origin. This can be done locally (see mitigations
734 in Section 9.1) or remotely (e.g., by an intermediary as a man-in-
735 the-middle attack).
737 This is the reason for the requirement in Section 2.1 that clients
738 have reasonable assurances that the alternative service is under
739 control of and valid for the whole origin; i.e., presenting a
740 certificate for the origin proves that the alternative service is
741 authorized to serve traffic for the origin.
743 Note that this assurance is only as strong as the method used to
744 authenticate the alternative service. In particular, when TLS
745 authentication is used to do so, there are well-known exploits to
746 make an attacker's certificate appear as legitimate.
748 Alternative services could be used to persist such an attack; for
749 example, an intermediary could man-in-the-middle TLS-protected
750 communication to a target, and then direct all traffic to an
751 alternative service with a large freshness lifetime, so that the user
752 agent still directs traffic to the attacker even when not using the
753 intermediary.
755 Implementations MUST perform any certificate-pinning validation (e.g.
756 [RFC7469]) on alternative services just as they would on direct
757 connections to the origin. Implementations might also choose to add
758 other requirements around which certificates are acceptable for
759 alternative services.
761 9.3. Changing Protocols
763 When the ALPN protocol is changed due to the use of an alternative
764 service, the security properties of the new connection to the origin
765 can be different from that of the "normal" connection to the origin,
766 because the protocol identifier itself implies this.
768 For example, if an "https://" URI has a protocol advertised that does
769 not use some form of end-to-end encryption (most likely, TLS), it
770 violates the expectations for security that the URI scheme implies.
772 Therefore, clients cannot blindly use alternative services, but
773 instead evaluate the option(s) presented to assure that security
774 requirements and expectations (of specifications, implementations and
775 end users) are met.
777 9.4. Tracking Clients Using Alternative Services
779 Choosing an alternative service implies connecting to a new, server-
780 supplied host name. By using many different (potentially unique)
781 host names, servers could conceivably track client requests. Such
782 tracking could follow users across multiple networks, when the
783 "persist" flag is used.
785 Clients that wish to prevent requests from being correlated (such as
786 those that offer modes aimed at providing improved privacy) can
787 decide not to use alternative services for multiple requests that
788 would not otherwise be allowed to be correlated.
790 In a user agent, any alternative service information MUST be removed
791 when origin-specific data is cleared (for instance, when cookies are
792 cleared).
794 9.5. Confusion Regarding Request Scheme
796 Some server-side HTTP applications make assumptions about security
797 based upon connection context; for example, equating being served
798 upon port 443 with the use of an "https://" URI (and the various
799 security properties that implies).
801 This affects not only the security properties of the connection
802 itself, but also the state of the client at the other end of it; for
803 example, a Web browser treats "https://" URIs differently than
804 "http://" URIs in many ways, not just for purposes of protocol
805 handling.
807 Since one of the uses of Alternative Services is to allow a
808 connection to be migrated to a different protocol and port, these
809 applications can become confused about the security properties of a
810 given connection, sending information (e.g., cookies, content) that
811 is intended for a secure context (e.g., an "https://" URI) to a
812 client that is not treating it as one.
814 This risk can be mitigated in servers by using the URI scheme
815 explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the
816 "absolute form" of the request target in HTTP/1.1) as an indication
817 of security context, instead of other connection properties
818 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
820 When the protocol does not explicitly carry the scheme (e.g., as is
821 usually the case for HTTP/1.1 over TLS, servers can mitigate this
822 risk by either assuming that all requests have an insecure context,
823 or by refraining from advertising alternative services for insecure
824 schemes (such as HTTP).
826 10. References
828 10.1. Normative References
830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
831 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
832 RFC2119, March 1997,
833 .
835 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
836 Resource Identifier (URI): Generic Syntax", STD 66,
837 RFC 3986, DOI 10.17487/RFC3986, January 2005,
838 .
840 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
841 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
842 DOI 10.17487/RFC5226, May 2008,
843 .
845 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
846 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
847 RFC5234, January 2008,
848 .
850 [RFC5890] Klensin, J., "Internationalized Domain Names for
851 Applications (IDNA): Definitions and Document Framework",
852 RFC 5890, DOI 10.17487/RFC5890, August 2010,
853 .
855 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
856 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066,
857 January 2011, .
859 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
860 DOI 10.17487/RFC6454, December 2011,
861 .
863 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
864 Protocol (HTTP/1.1): Message Syntax and Routing",
865 RFC 7230, DOI 10.17487/RFC7230, June 2014,
866 .
868 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
869 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
870 RFC 7234, DOI 10.17487/RFC7234, June 2014,
871 .
873 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile,
874 "Transport Layer Security (TLS) Application-Layer Protocol
875 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
876 July 2014, .
878 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
879 RFC 7405, DOI 10.17487/RFC7405, December 2014,
880 .
882 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
883 Transfer Protocol version 2", RFC 7540, DOI 10.17487/
884 RFC7540, May 2015,
885 .
887 10.2. Informative References
889 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
890 Procedures for Message Header Fields", BCP 90, RFC 3864,
891 September 2004, .
893 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
894 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
895 RFC5246, August 2008,
896 .
898 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
899 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
900 April 2015, .
902 Appendix A. Change Log (to be removed by RFC Editor before publication)
904 A.1. Since draft-nottingham-httpbis-alt-svc-05
906 This is the first version after adoption of
907 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
908 only contains editorial changes.
910 A.2. Since draft-ietf-httpbis-alt-svc-00
912 Selected 421 as proposed status code for "Not Authoritative".
914 Changed header field syntax to use percent-encoding of ALPN protocol
915 names ().
917 A.3. Since draft-ietf-httpbis-alt-svc-01
919 Updated HTTP/1.1 references.
921 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag
922 to address fingerprinting concerns
923 ().
925 Note that ALTSVC frame is preferred to Alt-Svc header field
926 ().
928 Incorporate ALTSRV frame
929 ().
931 Moved definition of status code 421 to HTTP/2.
933 Partly resolved .
935 A.4. Since draft-ietf-httpbis-alt-svc-02
937 Updated ALPN reference.
939 Resolved .
941 A.5. Since draft-ietf-httpbis-alt-svc-03
943 Renamed "Alt-Svc-Used" to "Alt-Used"
944 ().
946 Clarify ALTSVC Origin information requirements
947 ().
949 Remove/tune language with respect to tracking risks (see
950 ).
952 A.6. Since draft-ietf-httpbis-alt-svc-04
954 Mention tracking by alt-svc host name in Security Considerations
955 ().
957 "421 (Not Authoritative)" -> "421 (Misdirected Request)".
959 Allow the frame to carry multiple indicator and use the same payload
960 formats for both
961 ().
963 A.7. Since draft-ietf-httpbis-alt-svc-05
965 Go back to specifying the origin in Alt-Used, but make it a "SHOULD"
966 ().
968 Restore Origin field in ALT-SVC frame
969 ().
971 A.8. Since draft-ietf-httpbis-alt-svc-06
973 Disallow use of alternative services when the protocol might not
974 carry the scheme
975 ().
977 Align opp-sec and alt-svc
978 ().
980 alt svc frame on pushed (even and non-0) frame
981 ().
983 "browser" -> "user agent"
984 ().
986 ABNF for "parameter"
987 ().
989 Updated HTTP/2 reference.
991 A.9. Since draft-ietf-httpbis-alt-svc-07
993 Alt-Svc alternative cache invalidation
994 ().
996 Unexpected Alt-Svc frames
997 ().
999 Associating Alt-Svc header with an origin
1000 ().
1002 ALPN identifiers in Alt-Svc
1003 ().
1005 Number of alternate services used
1006 ().
1008 Proxy and .pac interaction
1009 ().
1011 Need to define extensibility for alt-svc parameters
1012 ().
1014 Persistence of alternates across network changes
1015 ().
1017 Alt-Svc header with 421 status
1018 ().
1020 Incorporate several editorial improvements suggested by Mike Bishop
1021 (,
1022 ).
1024 Alt-Svc response header field in HTTP/2 frame
1025 ().
1027 A.10. Since draft-ietf-httpbis-alt-svc-08
1029 Remove left over text about ext-params, applying to an earlier
1030 version of Alt-Used (see
1031 ).
1033 Conflicts between Alt-Svc and ALPN
1034 ().
1036 Elevation of privilege
1037 ().
1039 Alternates of alternates
1040 ().
1042 Alt-Svc and Cert Pinning
1043 ().
1045 Using alt-svc on localhost (no change to spec, see
1046 ).
1048 IANA procedure for alt-svc parameters
1049 ().
1051 Alt-svc from https (1.1) to https (1.1)
1052 ().
1054 Alt-svc vs the ability to convey the scheme inside the protocol
1055 ().
1057 Reconciling MAY/can vs. SHOULD
1058 ().
1060 Typo in alt-svc caching example
1061 ().
1063 A.11. Since draft-ietf-httpbis-alt-svc-09
1065 Editorial improvements
1066 (,
1067 ,
1068 ,
1069 ,
1070 ,
1071 ,
1072 ,
1073 ).
1075 A.12. Since draft-ietf-httpbis-alt-svc-10
1077 Editorial improvements
1078 ().
1080 Use RFC 7405 ABNF extension
1081 ().
1083 A.13. Since draft-ietf-httpbis-alt-svc-11
1085 Security considerations wrt system ports
1086 ().
1088 Appendix B. Acknowledgements
1090 Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy
1091 Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew
1092 Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury,
1093 Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and
1094 suggestions.
1096 The Alt-Svc header field was influenced by the design of the
1097 Alternate-Protocol header field in SPDY.
1099 Authors' Addresses
1101 Mark Nottingham
1102 Akamai
1104 EMail: mnot@mnot.net
1105 URI: https://www.mnot.net/
1107 Patrick McManus
1108 Mozilla
1110 EMail: mcmanus@ducksong.com
1111 URI: https://mozillians.org/u/pmcmanus/
1113 Julian F. Reschke
1114 greenbytes GmbH
1116 EMail: julian.reschke@greenbytes.de
1117 URI: https://greenbytes.de/tech/webdav/