Internet Engineering Task Force (IETF) A. Hutton
Request for Comments: 7639 Unify
Category: Standards Track J. Uberti
ISSN: 2070-1721 Google
M. Thomson
Mozilla
August 2015
Internet Engineering Task Force (IETF) A. Hutton
Request for Comments: 7639 Unify
Category: Standards Track J. Uberti
ISSN: 2070-1721 Google
M. Thomson
Mozilla
August 2015
The ALPN HTTP Header Field
ALPN HTTP头字段
Abstract
摘要
This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.
此规范允许HTTP CONNECT请求使用ALPN标头字段指示一旦建立，隧道内将使用的协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7639.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7639.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The ALPN HTTP Header Field . . . . . . . . . . . . . . . . . 3
2.1. Header Field Values . . . . . . . . . . . . . . . . . . . 3
2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The ALPN HTTP Header Field . . . . . . . . . . . . . . . . . 3
2.1. Header Field Values . . . . . . . . . . . . . . . . . . . 3
2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
The HTTP CONNECT method (Section 4.3.6 of [RFC7231]) requests that the recipient establish a tunnel to the identified origin server and thereafter forward packets, in both directions, until the tunnel is closed. Such tunnels are commonly used to create end-to-end virtual connections through one or more proxies.
HTTP连接方法（RFC7231第4.3.6节）要求接收方建立一个到已识别的源服务器的隧道，然后在两个方向上转发数据包，直到隧道关闭。此类隧道通常用于通过一个或多个代理创建端到端虚拟连接。
The ALPN HTTP header field identifies the protocol or protocols that the client intends to use within a tunnel that is established using CONNECT. This uses the Application-Layer Protocol Negotiation (ALPN) identifier [RFC7301].
ALPN HTTP头字段标识客户端打算在使用CONNECT建立的隧道中使用的一个或多个协议。这使用应用层协议协商（ALPN）标识符[RFC7301]。
For a tunnel that is then secured using Transport Layer Security (TLS) [RFC5246], the header field carries the same application protocol label as will be carried within the TLS handshake [RFC7301]. If there are multiple possible application protocols, all of those application protocols are indicated.
对于随后使用传输层安全性（TLS）[RFC5246]进行保护的隧道，报头字段携带与TLS握手[RFC7301]中携带的应用协议标签相同的应用协议标签。如果存在多个可能的应用程序协议，则指示所有这些应用程序协议。
The ALPN header field carries an indication of client intent only. An ALPN identifier is used here only to identify the application protocol or suite of protocols that the client intends to use in the tunnel. No negotiation takes place using this header field. In TLS, the final choice of application protocol is made by the server from the set of choices presented by the client. Other substrates could negotiate the application protocol differently.
ALPN标头字段仅包含客户意图的指示。ALPN标识符在这里仅用于标识客户端打算在隧道中使用的应用程序协议或协议套件。使用此标题字段不会进行协商。在TLS中，应用程序协议的最终选择由服务器从客户端提供的一组选择中做出。其他基板可以以不同方式协商应用协议。
Proxies do not implement the tunneled protocol, though they might choose to make policy decisions based on the value of the header field. For example, a proxy could use the application protocol to select appropriate traffic prioritization.
代理不实现隧道协议，尽管它们可能会选择根据头字段的值做出策略决策。例如，代理可以使用应用程序协议来选择适当的流量优先级。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Clients include the ALPN header field in an HTTP CONNECT request to indicate the application-layer protocol that a client intends to use within the tunnel, or a set of protocols that might be used within the tunnel.
客户端在HTTP连接请求中包括ALPN头字段，以指示客户端打算在隧道内使用的应用层协议，或可能在隧道内使用的一组协议。
Valid values for the protocol field are taken from the "Application-Layer Protocol Negotiation (ALPN) Protocol ID" registry [ALPN-IDS] established by [RFC7301].
协议字段的有效值取自[RFC7301]建立的“应用层协议协商（ALPN）协议ID”注册表[ALPN-IDS]。
The ABNF (Augmented Backus-Naur Form) syntax for the ALPN header field value is given below. It uses the syntax defined in Section 1.2 of [RFC7230].
ALPN头字段值的ABNF（增强的Backus Naur形式）语法如下所示。它使用[RFC7230]第1.2节中定义的语法。
ALPN = 1#protocol-id
protocol-id = token ; percent-encoded ALPN protocol identifier
ALPN = 1#protocol-id
protocol-id = token ; percent-encoded ALPN protocol identifier
ALPN protocol names are octet sequences with no additional constraints on format. Octets not allowed in tokens ([RFC7230], Section 3.2.6) MUST be percent-encoded as per Section 2.1 of [RFC3986]. Consequently, the octet representing the percent character "%" (hex 25) MUST be percent-encoded as well.
ALPN协议名称是八位字节序列，没有额外的格式限制。令牌中不允许的八位字节（[RFC7230]，第3.2.6节）必须按照[RFC3986]第2.1节进行百分比编码。因此，表示百分比字符“%”（十六进制25）的八位字节也必须进行百分比编码。
In order to have precisely one way to represent any ALPN protocol name, the following additional constraints apply:
为了精确地用一种方法表示任何ALPN协议名称，以下附加约束适用：
o Octets in the ALPN protocol MUST NOT be percent-encoded if they are valid token characters except "%".
o 如果ALPN协议中的八位字节是除“%”以外的有效令牌字符，则不能对其进行百分比编码。
o When using percent-encoding, uppercase hex digits MUST be used.
o 使用百分比编码时，必须使用大写十六进制数字。
With these constraints, recipients can apply simple string comparison to match protocol identifiers.
有了这些约束，收件人可以应用简单的字符串比较来匹配协议标识符。
For example:
例如：
CONNECT www.example.com HTTP/1.1 Host: www.example.com ALPN: h2, http%2F1.1
连接www.example.com HTTP/1.1主机：www.example.com ALPN:h2，HTTP%2F1.1
When used in the ALPN header field, an ALPN identifier is used to identify an entire application protocol stack, not a single protocol layer or component.
在ALPN标头字段中使用时，ALPN标识符用于标识整个应用程序协议堆栈，而不是单个协议层或组件。
For a CONNECT tunnel that conveys a protocol secured with TLS, the value of the ALPN header field contains the same list of ALPN identifiers that will be sent in the TLS ClientHello message [RFC7301].
对于传输由TLS保护的协议的连接隧道，ALPN标头字段的值包含将在TLS ClientHello消息[RFC7301]中发送的相同ALPN标识符列表。
Where no protocol negotiation is expected to occur, such as in protocols that do not use TLS, the ALPN header field contains a single ALPN protocol identifier corresponding to the application protocol that is intended to be used. If an alternative form of protocol negotiation is possible, the ALPN header field contains the set of protocols that might be negotiated.
在预期不会发生协议协商的情况下，例如在不使用TLS的协议中，ALPN报头字段包含与预期使用的应用协议相对应的单个ALPN协议标识符。如果协议协商的另一种形式是可能的，ALPN头字段包含可能协商的协议集。
A proxy can use the value of the ALPN header field to more cleanly and efficiently reject requests for a CONNECT tunnel. Exposing protocol information at the HTTP layer allows a proxy to deny requests earlier, with better error reporting (such as a 403 status code). The ALPN header field can be falsified and therefore is not a sufficient basis for authorizing a request.
代理可以使用ALPN header字段的值来更干净有效地拒绝连接隧道的请求。在HTTP层公开协议信息允许代理更早地拒绝请求，并提供更好的错误报告（例如403状态代码）。ALPN标头字段可能被伪造，因此不是授权请求的充分依据。
A proxy could attempt to inspect packets to determine the protocol in use. This requires that the proxy understand each ALPN identifier. Protocols like TLS could hide negotiated protocols, or protocol negotiation details could change over time. Proxies SHOULD NOT break a CONNECT tunnel solely on the basis of a failure to recognize the protocol.
代理可以尝试检查数据包以确定正在使用的协议。这要求代理理解每个ALPN标识符。像TLS这样的协议可能隐藏协商的协议，或者协议协商的细节可能会随着时间的推移而改变。代理不应仅基于无法识别协议而中断连接隧道。
A proxy can use the ALPN header field value to change how it manages or prioritizes connections.
代理可以使用ALPN header字段值来更改其管理连接或确定连接优先级的方式。
HTTP header fields are registered within the "Permanent Message Header Field Names" registry maintained by IANA [MSG-HDRS]. This document defines and registers the ALPN header field, according to [RFC3864] as follows:
HTTP头字段在IANA[MSG-HDRS]维护的“永久消息头字段名称”注册表中注册。本文件根据[RFC3864]定义并注册ALPN标题字段，如下所示：
Header Field Name: ALPN
标题字段名称：ALPN
Protocol: http
协议：http
Status: Standard
状态：标准
Reference: Section 2 of this document (RFC 7639)
参考：本文件第2节（RFC 7639）
Change Controller: IETF (iesg@ietf.org) - Internet Engineering Task Force
更改控制器：IETF(iesg@ietf.org)-互联网工程专责小组
In case of using HTTP CONNECT to a TURN (Traversal Using Relays around NAT, [RFC5766]) server, the security considerations of Section 4.3.6 of [RFC7231] apply. It states that there "are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. ... Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."
如果使用HTTP连接到TURN（使用NAT[RFC5766]服务器周围的中继进行遍历），则[RFC7231]第4.3.6节中的安全注意事项适用。它指出，“建立到任意服务器的隧道存在重大风险，特别是当目标是一个众所周知的或保留的TCP端口，不用于Web流量时……支持CONNECT的代理应将其使用限制在有限的一组已知端口或可配置的安全请求目标白名单上。”
The ALPN header field described in this document is OPTIONAL. Clients and HTTP proxies could choose not to support it and therefore either fail to provide it or ignore it when present. If the header field is not available or is ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel. This is indistinguishable from the case where either client or proxy does not support the ALPN header field.
本文档中描述的ALPN标题字段是可选的。客户端和HTTP代理可以选择不支持它，因此要么无法提供它，要么在存在时忽略它。如果标头字段不可用或被忽略，则代理无法识别隧道的用途并将其用作有关隧道的任何授权决策的输入。这与客户端或代理不支持ALPN头字段的情况没有区别。
There is no confidentiality protection for the ALPN header field. ALPN identifiers that might expose confidential or sensitive information SHOULD NOT be sent, as described in Section 5 of [RFC7301].
ALPN标头字段没有保密保护。如[RFC7301]第5节所述，不应发送可能暴露机密或敏感信息的ALPN标识符。
The value of the ALPN header field could be falsified by a client. If the data being sent through the tunnel is encrypted (for example, with TLS [RFC5246]), then the proxy might not be able to directly inspect the data to verify that the claimed protocol is the one which is actually being used, though a proxy might be able to perform traffic analysis [TRAFFIC]. Therefore, a proxy cannot rely on the value of the ALPN header field as a policy input in all cases.
客户端可能会伪造ALPN标头字段的值。如果通过隧道发送的数据是加密的（例如，使用TLS[RFC5246]），则代理可能无法直接检查数据以验证声明的协议是否是实际使用的协议，尽管代理可能能够执行流量分析[traffic]。因此，代理不能在所有情况下都将ALPN头字段的值作为策略输入。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<http://www.rfc-editor.org/info/rfc3864>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7301]Friedl，S.，Popov，A.，Langley，A.，和E.Stephan，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<http://www.rfc-editor.org/info/rfc7301>.
[ALPN-IDS] IANA, "Application-Layer Protocol Negotiation (ALPN) Protocol ID", <http://www.iana.org/assignments/ tls-extensiontype-values>.
[ALPN-IDS]IANA，“应用层协议协商（ALPN）协议ID”<http://www.iana.org/assignments/ tls扩展类型值>。
[MSG-HDRS] IANA, "Permanent Message Header Field Names>", <https://www.iana.org/assignments/message-headers>.
[MSG-HDRS]IANA，“永久消息头字段名称>”<https://www.iana.org/assignments/message-headers>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[TRAFFIC] Pironti, A., Strub, P-Y., and K. Bhargavan, "Identifying Website Users by TLS Traffic Analysis: New Attacks and Effective Countermeasures, Revision 1", 2012, <https://alfredo.pironti.eu/research/publications/full/ identifying-website-users-tls-traffic-analysis-new-attacks-and-effective-counterme>.
[流量]Pironti，A.，Strub，P-Y.，和K.Bhargavan，“通过TLS流量分析识别网站用户：新攻击和有效对策，第1版”，2012年<https://alfredo.pironti.eu/research/publications/full/ 识别网站用户tls流量分析新攻击和有效对策>。
Authors' Addresses
作者地址
Andrew Hutton Unify Technology Drive Nottingham NG9 1LA United Kingdom
Andrew Hutton Unified Technology Drive英国诺丁汉NG9 1LA
Email: andrew.hutton@unify.com
Email: andrew.hutton@unify.com
Justin Uberti Google 747 6th Street South Kirkland, WA 98033 United States
Justin Uberti谷歌747美国华盛顿州柯克兰南第6街，邮编：98033
Email: justin@uberti.name
Email: justin@uberti.name
Martin Thomson Mozilla 331 East Evelyn Avenue Mountain View, CA 94041 United States
美国加利福尼亚州东伊夫林大道山景城331号马丁·汤姆森·莫兹拉94041
Email: martin.thomson@gmail.com
Email: martin.thomson@gmail.com