< draft-nottingham-httpbis-alt-svc-04.txt   draft-nottingham-httpbis-alt-svc-05.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track P. McManus Intended status: Standards Track P. McManus
Expires: September 22, 2014 Mozilla Expires: September 22, 2014 Mozilla
March 21, 2014 March 21, 2014
HTTP Alternative Services HTTP Alternative Services
draft-nottingham-httpbis-alt-svc-04 draft-nottingham-httpbis-alt-svc-05
Abstract Abstract
This document specifies "alternative services" for HTTP, which allow This document specifies "alternative services" for HTTP, which allow
an origin's resources to be authoritatively available at a separate an origin's resources to be authoritatively available at a separate
network location, possibly accessed with a different protocol network location, possibly accessed with a different protocol
configuration. configuration.
Status of this Memo Status of this Memo
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2. Alternative Services Concepts . . . . . . . . . . . . . . . . 4 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 4
2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 5 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 5
2.2. Alternative Service Caching . . . . . . . . . . . . . . . 5 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 5
2.3. Requiring Server Name Indication . . . . . . . . . . . . . 6 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 6
2.4. Using Alternative Services . . . . . . . . . . . . . . . . 6 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 6
3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 7 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 7
3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 7 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 8
4. The 4NN Not Authoritative HTTP Status Code . . . . . . . . . . 8 4. The Service HTTP Header Field . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. The 4NN Not Authoritative HTTP Status Code . . . . . . . . . . 9
5.1. The Alt-Svc Message Header Field . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.2. The 4NN Not Authoritative HTTP Status Code . . . . . . . . 9 6.1. The Alt-Svc Message Header Field . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.2. The Service Message Header Field . . . . . . . . . . . . . 10
6.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 9 6.3. The 4NN Not Authoritative HTTP Status Code . . . . . . . . 10
6.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 10 7.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
HTTP [I-D.ietf-httpbis-p1-messaging] conflates the identification of HTTP [I-D.ietf-httpbis-p1-messaging] conflates the identification of
resources with their location. In other words, http:// (and resources with their location. In other words, http:// (and
https://) URLs are used to both name and find things to interact https://) URLs are used to both name and find things to interact
with. with.
In some cases, it is desirable to separate these aspects; to be able In some cases, it is desirable to separate these aspects; to be able
to keep the same identifier for a resource, but interact with it to keep the same identifier for a resource, but interact with it
skipping to change at page 3, line 34 skipping to change at page 3, line 34
o An origin server might wish to segment its clients into groups of o An origin server might wish to segment its clients into groups of
capabilities, such as those supporting SNI (see [RFC6066]) and capabilities, such as those supporting SNI (see [RFC6066]) and
those not supporting it, for operational purposes. those not supporting it, for operational purposes.
This specification defines a new concept in HTTP, "Alternative This specification defines a new concept in HTTP, "Alternative
Services", that allows a resource to nominate additional means of Services", that allows a resource to nominate additional means of
interacting with it on the network. It defines a general framework interacting with it on the network. It defines a general framework
for this in Section 2, along with a specific mechanism for for this in Section 2, along with a specific mechanism for
discovering them using HTTP headers in Section 3. discovering them using HTTP headers in Section 3.
It also introduces a new status code in Section 4, so that origin It also introduces a new status code in Section 5, so that origin
servers (or their nominated alternatives) can indicate that they are servers (or their nominated alternatives) can indicate that they are
not authoritative for a given origin, in cases where the wrong not authoritative for a given origin, in cases where the wrong
location is used. location is used.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the Augmented BNF defined in [RFC5234] along with This document uses the Augmented BNF defined in [RFC5234] along with
the "OWS", "DIGIT", "parameter", "port" and "delta-second" rules from the "OWS", "DIGIT", "parameter", "uri-host", "port" and "delta-
[I-D.ietf-httpbis-p1-messaging], and uses the "#rule" extension second" rules from [I-D.ietf-httpbis-p1-messaging], and uses the
defined in Section 7 of that document. "#rule" extension defined in Section 7 of that document.
2. Alternative Services Concepts 2. Alternative Services Concepts
This specification defines a new concept in HTTP, the "alternative This specification defines a new concept in HTTP, the "alternative
service." When an origin (see [RFC6454]) has resources are service." When an origin (see [RFC6454]) has resources are
accessible through a different protocol / host / port combination, it accessible through a different protocol / host / port combination, it
is said to have an alternative service. is said to have an alternative service.
An alternative service can be used to interact with the resources on An alternative service can be used to interact with the resources on
an origin server at a separate location on the network, possibly an origin server at a separate location on the network, possibly
skipping to change at page 5, line 32 skipping to change at page 5, line 32
o A freshness lifetime, expressed in seconds; see Section 2.2 o A freshness lifetime, expressed in seconds; see Section 2.2
There are many ways that a client could discover the alternative There are many ways that a client could discover the alternative
service(s) associated with an origin. service(s) associated with an origin.
2.1. Host Authentication 2.1. Host Authentication
Clients MUST NOT use alternative services with a host other than the Clients MUST NOT use alternative services with a host other than the
origin's without strong server authentication; this mitigates the origin's without strong server authentication; this mitigates the
attack described in Section 6.2. One way to achieve this is for the attack described in Section 7.2. One way to achieve this is for the
alternative to use TLS with a certificate that is valid for that alternative to use TLS with a certificate that is valid for that
origin. origin.
For example, if the origin's host is "www.example.com" and an For example, if the origin's host is "www.example.com" and an
alternative is offered on "other.example.com" with the "h2" protocol, alternative is offered on "other.example.com" with the "h2" protocol,
and the certificate offered is valid for "www.example.com", the and the certificate offered is valid for "www.example.com", the
client can use the alternative. However, if "other.example.com" is client can use the alternative. However, if "other.example.com" is
offered with the "h2c" protocol, the client cannot use it, because offered with the "h2c" protocol, the client cannot use it, because
there is no mechanism in that protocol to establish strong server there is no mechanism in that protocol to establish strong server
authentication. authentication.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
origin at any time when it is considered fresh; see Section 2.4 for origin at any time when it is considered fresh; see Section 2.4 for
specific recommendations. specific recommendations.
Clients with existing connections to alternative services are not Clients with existing connections to alternative services are not
required to fall back to the origin when its freshness lifetime ends; required to fall back to the origin when its freshness lifetime ends;
i.e., the caching mechanism is intended for limiting how long an i.e., the caching mechanism is intended for limiting how long an
alternative service can be used for establishing new requests, not alternative service can be used for establishing new requests, not
limiting the use of existing ones. limiting the use of existing ones.
To mitigate risks associated with caching compromised values (see To mitigate risks associated with caching compromised values (see
Section 6.2 for details), user agents SHOULD examine cached Section 7.2 for details), user agents SHOULD examine cached
alternative services when they detect a change in network alternative services when they detect a change in network
configuration, and remove any that could be compromised (for example, configuration, and remove any that could be compromised (for example,
those whose association with the trust root is questionable). UAs those whose association with the trust root is questionable). UAs
that do not have a means of detecting network changes SHOULD place an that do not have a means of detecting network changes SHOULD place an
upper bound on their lifetime. upper bound on their lifetime.
2.3. Requiring Server Name Indication 2.3. Requiring Server Name Indication
A client must only use a TLS-based alternative service if the client A client must only use a TLS-based alternative service if the client
also supports TLS Server Name Indication (SNI) [RFC6066]. This also supports TLS Server Name Indication (SNI) [RFC6066]. This
skipping to change at page 6, line 43 skipping to change at page 6, line 43
required to use them. However, it is advantageous for clients to required to use them. However, it is advantageous for clients to
behave in a predictable way when they are used by servers (e.g., for behave in a predictable way when they are used by servers (e.g., for
load balancing). load balancing).
Therefore, if a client becomes aware of an alternative service, the Therefore, if a client becomes aware of an alternative service, the
client SHOULD use that alternative service for all requests to the client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available, provided that the associated origin as soon as it is available, provided that the
security properties of the alternative service protocol are security properties of the alternative service protocol are
desirable, as compared to the existing connection. desirable, as compared to the existing connection.
When a client uses an alternate service, it MUST emit the Service
header field Section 4 on every request using that alternate service.
The client is not required to block requests; the origin's connection The client is not required to block requests; the origin's connection
can be used until the alternative connection is established. can be used until the alternative connection is established.
However, if the security properties of the existing connection are However, if the security properties of the existing connection are
weak (e.g. cleartext HTTP/1.1) then it might make sense to block weak (e.g. cleartext HTTP/1.1) then it might make sense to block
until the new connection is fully available in order to avoid until the new connection is fully available in order to avoid
information leakage. information leakage.
Furthermore, if the connection to the alternative service fails or is Furthermore, if the connection to the alternative service fails or is
unresponsive, the client MAY fall back to using the origin. Note, unresponsive, the client MAY fall back to using the origin. Note,
however, that this could be the basis of a downgrade attack, thus however, that this could be the basis of a downgrade attack, thus
skipping to change at page 8, line 36 skipping to change at page 8, line 43
When an Alt-Svc response header is received from an origin, its value When an Alt-Svc response header is received from an origin, its value
invalidates and replaces all cached alternative services for that invalidates and replaces all cached alternative services for that
origin. origin.
See Section 2.2 for general requirements on caching alternative See Section 2.2 for general requirements on caching alternative
services. services.
Note that the freshness lifetime for HTTP caching (here, 600 seconds) Note that the freshness lifetime for HTTP caching (here, 600 seconds)
does not affect caching of Alt-Svc values. does not affect caching of Alt-Svc values.
4. The 4NN Not Authoritative HTTP Status Code 4. The Service HTTP Header Field
The Service HTTP header field is used in requests to indicate the
identity of the alternate service in use, just as the Host header
identifies the host and port of the origin.
Service = uri-host [ ":" port ]
Service is intended to allow alternate services to detect loops,
differentiate traffic for purposes of load balancing, and generally
to ensure that it is possible to identify the intended destination of
traffic, since introducing this information after a protocol is in
use has proven to be problematic.
When using an Alternate Service, clients MUST include a Service
header in all requests. For example:
GET /thing
Host: origin.example.com
Service: alternate.example.net
User-Agent: Example/1.0
5. The 4NN Not Authoritative HTTP Status Code
The 4NN (Not Authoritative) status code indicates that the current The 4NN (Not Authoritative) status code indicates that the current
origin server (usually, but not always an alternative service; see origin server (usually, but not always an alternative service; see
Section 2) is not authoritative for the requested resource, in the Section 2) is not authoritative for the requested resource, in the
sense of [I-D.ietf-httpbis-p1-messaging], Section 9.1. sense of [I-D.ietf-httpbis-p1-messaging], Section 9.1.
Clients receiving 4NN (Not Authoritative) from an alternative service Clients receiving 4NN (Not Authoritative) from an alternative service
MUST remove the corresponding entry from its alternative service MUST remove the corresponding entry from its alternative service
cache (see Section 2.2) for that origin. Regardless of the cache (see Section 2.2) for that origin. Regardless of the
idempotency of the request method, they MAY retry the request, either idempotency of the request method, they MAY retry the request, either
at another alternative server, or at the origin. at another alternative server, or at the origin.
4NN (Not Authoritative) MAY carry an Alt-Svc header field. 4NN (Not Authoritative) MAY carry an Alt-Svc header field.
This status code MUST NOT be generated by proxies. This status code MUST NOT be generated by proxies.
A 4NN response is cacheable by default; i.e., unless otherwise A 4NN response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [I-D.ietf-httpbis-p6-cache]). Section 4.2.2 of [I-D.ietf-httpbis-p6-cache]).
5. IANA Considerations 6. IANA Considerations
5.1. The Alt-Svc Message Header Field 6.1. The Alt-Svc Message Header Field
This document registers Alt-Svc in the Permanent Message Header This document registers Alt-Svc in the Permanent Message Header
Registry [RFC3864]. Registry [RFC3864].
o Header Field Name: Alt-Svc o Header Field Name: Alt-Svc
o Application Protocol: http o Application Protocol: http
o Status: standard o Status: standard
o Author/Change Controller: IETF o Author/Change Controller: IETF
o Specification Document: [this document] o Specification Document: [this document]
o Related Information: o Related Information:
5.2. The 4NN Not Authoritative HTTP Status Code 6.2. The Service Message Header Field
This document registers Alt-Svc in the Permanent Message Header
Registry [RFC3864].
o Header Field Name: Service
o Application Protocol: http
o Status: standard
o Author/Change Controller: IETF
o Specification Document: [this document]
o Related Information:
6.3. The 4NN Not Authoritative HTTP Status Code
This document registers the 4NN (Not Authoritative) HTTP Status code This document registers the 4NN (Not Authoritative) HTTP Status code
[I-D.ietf-httpbis-p2-semantics]. [I-D.ietf-httpbis-p2-semantics].
o Status Code: 4NN o Status Code: 4NN
o Short Description: Not Authoritative o Short Description: Not Authoritative
o Specification: [this document], Section 4 o Specification: [this document], Section 5
6. Security Considerations 7. Security Considerations
Identified security considerations should be enumerated in the Identified security considerations should be enumerated in the
appropriate documents depending on which proposals are accepted. appropriate documents depending on which proposals are accepted.
Those listed below are generic to all uses of alternative services; Those listed below are generic to all uses of alternative services;
more specific ones might be necessary. more specific ones might be necessary.
6.1. Changing Ports 7.1. Changing Ports
Using an alternative service implies accessing an origin's resources Using an alternative service implies accessing an origin's resources
on an alternative port, at a minimum. An attacker that can inject on an alternative port, at a minimum. An attacker that can inject
alternative services and listen at the advertised port is therefore alternative services and listen at the advertised port is therefore
able to hijack an origin. able to hijack an origin.
For example, an attacker that can add HTTP response header fields can For example, an attacker that can add HTTP response header fields can
redirect traffic to a different port on the same host using the Alt- redirect traffic to a different port on the same host using the Alt-
Svc header field; if that port is under the attacker's control, they Svc header field; if that port is under the attacker's control, they
can thus masquerade as the HTTP server. can thus masquerade as the HTTP server.
This risk can be mitigated by restricting the ability to advertise This risk can be mitigated by restricting the ability to advertise
alternative services, and restricting who can open a port for alternative services, and restricting who can open a port for
listening on that host. listening on that host.
6.2. Changing Hosts 7.2. Changing Hosts
When the host is changed due to the use of an alternative service, it When the host is changed due to the use of an alternative service, it
presents an opportunity for attackers to hijack communication to an presents an opportunity for attackers to hijack communication to an
origin. origin.
For example, if an attacker can convince a user agent to send all For example, if an attacker can convince a user agent to send all
traffic for "innocent.example.org" to "evil.example.com" by traffic for "innocent.example.org" to "evil.example.com" by
successfully associating it as an alternative service, they can successfully associating it as an alternative service, they can
masquerade as that origin. This can be done locally (see mitigations masquerade as that origin. This can be done locally (see mitigations
above) or remotely (e.g., by an intermediary as a man-in-the-middle above) or remotely (e.g., by an intermediary as a man-in-the-middle
skipping to change at page 10, line 44 skipping to change at page 11, line 39
Alternative services could be used to persist such an attack; for Alternative services could be used to persist such an attack; for
example, an intermediary could man-in-the-middle TLS-protected example, an intermediary could man-in-the-middle TLS-protected
communication to a target, and then direct all traffic to an communication to a target, and then direct all traffic to an
alternative service with a large freshness lifetime, so that the user alternative service with a large freshness lifetime, so that the user
agent still directs traffic to the attacker even when not using the agent still directs traffic to the attacker even when not using the
intermediary. intermediary.
As a result, there is a requirement in Section 2.2 to examine cached As a result, there is a requirement in Section 2.2 to examine cached
alternative services when a network change is detected. alternative services when a network change is detected.
6.3. Changing Protocols 7.3. Changing Protocols
When the ALPN protocol is changed due to the use of an alternative When the ALPN protocol is changed due to the use of an alternative
service, the security properties of the new connection to the origin service, the security properties of the new connection to the origin
can be different from that of the "normal" connection to the origin, can be different from that of the "normal" connection to the origin,
because the protocol identifier itself implies this. because the protocol identifier itself implies this.
For example, if a "https://" URI had a protocol advertised that does For example, if a "https://" URI had a protocol advertised that does
not use some form of end-to-end encryption (most likely, TLS), it not use some form of end-to-end encryption (most likely, TLS), it
violates the expectations for security that the URI scheme implies. violates the expectations for security that the URI scheme implies.
Therefore, clients cannot blindly use alternative services, but Therefore, clients cannot blindly use alternative services, but
instead evaluate the option(s) presented to assure that security instead evaluate the option(s) presented to assure that security
requirements and expectations (of specifications, implementations and requirements and expectations (of specifications, implementations and
end users) are met. end users) are met.
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.ietf-httpbis-p1-messaging] [I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-26 (work in progress), draft-ietf-httpbis-p1-messaging-26 (work in progress),
February 2014. February 2014.
[I-D.ietf-httpbis-p6-cache] [I-D.ietf-httpbis-p6-cache]
Fielding, R., Nottingham, M., and J. Reschke, "Hypertext Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", Transfer Protocol (HTTP/1.1): Caching",
skipping to change at page 12, line 5 skipping to change at page 12, line 44
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
December 2011. December 2011.
7.2. Informative References 8.2. Informative References
[I-D.ietf-httpbis-http2] [I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-10 (work in Protocol version 2", draft-ietf-httpbis-http2-10 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-httpbis-p2-semantics] [I-D.ietf-httpbis-p2-semantics]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-26 (work in progress), draft-ietf-httpbis-p2-semantics-26 (work in progress),
 End of changes. 19 change blocks. 
33 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/