Internet Engineering Task Force (IETF) A. Bittau
Request for Comments: 8547 Google
Category: Experimental D. Giffin
ISSN: 2070-1721 Stanford University
M. Handley
University College London
D. Mazieres
Stanford University
E. Smith
Kestrel Institute
May 2019
Internet Engineering Task Force (IETF) A. Bittau
Request for Comments: 8547 Google
Category: Experimental D. Giffin
ISSN: 2070-1721 Stanford University
M. Handley
University College London
D. Mazieres
Stanford University
E. Smith
Kestrel Institute
May 2019
TCP-ENO: Encryption Negotiation Option
TCP-ENO：加密协商选项
Abstract
摘要
Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.
尽管TLS被越来越多地采用，但互联网上的TCP流量中有很大一部分仍然没有加密。未加密流量的持续存在至少可归因于两个因素。首先，一些遗留协议缺少用于传递对加密支持的信令机制（如STARTTLS命令），因此无法进行增量部署。其次，传统应用程序本身不能总是升级，因此需要一种完全在传输层内透明地实现加密的方法。TCP加密协商选项（TCP-ENO）通过提供带外、完全向后兼容的加密协商的新TCP选项解决了这两个问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8547.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8547.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TCP-ENO Specification . . . . . . . . . . . . . . . . . . . . 6
4.1. ENO Option . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. The Global Suboption . . . . . . . . . . . . . . . . . . 9
4.3. TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Specifying Suboption Data Length . . . . . . . . . . . . 11
4.5. The Negotiated TEP . . . . . . . . . . . . . . . . . . . 12
4.6. TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . . 13
4.7. Data in SYN Segments . . . . . . . . . . . . . . . . . . 14
4.8. Negotiation Transcript . . . . . . . . . . . . . . . . . 16
5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 16
5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 18
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Future Developments . . . . . . . . . . . . . . . . . . . . . 21
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 22
8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 22
8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 22
8.4. Application-Aware Bit . . . . . . . . . . . . . . . . . . 23
8.5. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 24
8.6. Unpredictability of Session IDs . . . . . . . . . . . . . 24
9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TCP-ENO Specification . . . . . . . . . . . . . . . . . . . . 6
4.1. ENO Option . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. The Global Suboption . . . . . . . . . . . . . . . . . . 9
4.3. TCP-ENO Roles . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Specifying Suboption Data Length . . . . . . . . . . . . 11
4.5. The Negotiated TEP . . . . . . . . . . . . . . . . . . . 12
4.6. TCP-ENO Handshake . . . . . . . . . . . . . . . . . . . . 13
4.7. Data in SYN Segments . . . . . . . . . . . . . . . . . . 14
4.8. Negotiation Transcript . . . . . . . . . . . . . . . . . 16
5. Requirements for TEPs . . . . . . . . . . . . . . . . . . . . 16
5.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 18
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Future Developments . . . . . . . . . . . . . . . . . . . . . 21
8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Handshake Robustness . . . . . . . . . . . . . . . . . . 22
8.2. Suboption Data . . . . . . . . . . . . . . . . . . . . . 22
8.3. Passive Role Bit . . . . . . . . . . . . . . . . . . . . 22
8.4. Application-Aware Bit . . . . . . . . . . . . . . . . . . 23
8.5. Use of ENO Option Kind by TEPs . . . . . . . . . . . . . 24
8.6. Unpredictability of Session IDs . . . . . . . . . . . . . 24
9. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Many applications and protocols running on top of TCP today do not encrypt traffic. This failure to encrypt lowers the bar for certain attacks, harming both user privacy and system security. Counteracting the problem demands a minimally intrusive, backward-compatible mechanism for incrementally deploying encryption. The TCP Encryption Negotiation Option (TCP-ENO) specified in this document provides such a mechanism.
如今，许多运行在TCP之上的应用程序和协议都不加密流量。加密失败降低了某些攻击的门槛，从而损害了用户隐私和系统安全。要解决这个问题，需要一种侵入性最小、向后兼容的机制来增量部署加密。本文档中指定的TCP加密协商选项（TCP-ENO）提供了这种机制。
Introducing TCP options, extending operating system interfaces to support TCP-level encryption, and extending applications to take advantage of TCP-level encryption all require effort. To the greatest extent possible, the effort invested in realizing TCP-level encryption today needs to remain applicable in the future should the need arise to change encryption strategies. To this end, it is useful to consider two questions separately:
引入TCP选项、扩展操作系统接口以支持TCP级加密以及扩展应用程序以利用TCP级加密都需要付出努力。在最大可能的范围内，如果需要更改加密策略，那么当前为实现TCP级加密而投入的努力需要在将来继续适用。为此，分别考虑两个问题是有用的：
1. How to negotiate the use of encryption at the TCP layer
1. 如何在TCP层协商加密的使用
2. How to perform encryption at the TCP layer
2. 如何在TCP层执行加密
This document addresses question 1 with a new TCP option, ENO. TCP-ENO provides a framework in which two endpoints can agree on a TCP encryption protocol (TEP) out of multiple possible TEPs. For future compatibility, TEPs can vary widely in terms of wire format, use of TCP option space, and integration with the TCP header and segmentation. However, ENO abstracts these differences to ensure the introduction of new TEPs can be transparent to applications taking advantage of TCP-level encryption.
本文档使用新的TCP选项ENO解决了问题1。TCP-ENO提供了一个框架，其中两个端点可以在多个可能的TEP中就TCP加密协议（TEP）达成一致。为了将来的兼容性，TEP可以在有线格式、TCP选项空间的使用以及与TCP头和分段的集成方面有很大的不同。然而，ENO对这些差异进行了抽象，以确保新TEP的引入对利用TCP级别加密的应用程序是透明的。
Question 2 is addressed by one or more companion TEP specification documents. While current TEPs enable TCP-level traffic encryption today, TCP-ENO ensures that the effort invested to deploy today's TEPs will additionally benefit future ones.
问题2由一个或多个配套TEP规范文件解决。虽然当前的TEP现在支持TCP级别的流量加密，但TCP-ENO确保为部署当前的TEP而投入的精力将为未来的TEP带来额外的好处。
TCP-ENO was designed to achieve the following goals:
TCP-ENO旨在实现以下目标：
1. Enable endpoints to negotiate the use of a separately specified TCP encryption protocol (TEP) suitable for either opportunistic security [RFC7435] of arbitrary TCP communications or stronger security of applications willing to perform endpoint authentication.
1. 允许端点协商使用单独指定的TCP加密协议（TEP），该协议适用于任意TCP通信的机会主义安全[RFC7435]或愿意执行端点身份验证的应用程序的更高安全性。
2. Transparently fall back to unencrypted TCP when not supported by both endpoints.
2. 当两个端点都不支持时，透明地退回到未加密的TCP。
3. Provide out-of-band signaling through which applications can better take advantage of TCP-level encryption (for instance, by improving authentication mechanisms in the presence of TCP-level encryption).
3. 提供带外信令，通过该信令，应用程序可以更好地利用TCP级加密（例如，通过在存在TCP级加密的情况下改进身份验证机制）。
4. Define a standard negotiation transcript that TEPs can use to defend against tampering with TCP-ENO.
4. 定义TEPs可用于防止TCP-ENO被篡改的标准谈判记录。
5. Make parsimonious use of TCP option space.
5. 节约使用TCP选项空间。
6. Define roles for the two ends of a TCP connection, so as to name each end of a connection for encryption or authentication purposes even following a symmetric simultaneous open.
6. 为TCP连接的两端定义角色，以便为连接的每一端命名，以便进行加密或身份验证，即使在对称同时打开后也是如此。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Throughout this document, we use the following terms, several of which have more detailed normative descriptions in [RFC793]:
在本文件中，我们使用以下术语，其中一些术语在[RFC793]中有更详细的规范性描述：
SYN segment A TCP segment in which the SYN flag is set
SYN段设置SYN标志的TCP段
ACK segment A TCP segment in which the ACK flag is set (which includes most segments other than an initial SYN segment)
ACK段设置ACK标志的TCP段（包括除初始SYN段以外的大多数段）
Non-SYN segment A TCP segment in which the SYN flag is clear
非SYN段清除SYN标志的TCP段
SYN-only segment A TCP segment in which the SYN flag is set but the ACK flag is clear
仅SYN段设置SYN标志但ACK标志清除的TCP段
SYN-ACK segment A TCP segment in which the SYN and ACK flags are both set
SYN-ACK段设置SYN和ACK标志的TCP段
Active opener A host that initiates a connection by sending a SYN-only segment. With the BSD socket API, an active opener calls "connect". In client-server configurations, active openers are typically clients.
主动开启器通过发送仅SYN段来启动连接的主机。使用BSD套接字API，活动的开启器调用“connect”。在客户机-服务器配置中，活动开启器通常是客户机。
Passive opener A host that does not send a SYN-only segment but responds to one with a SYN-ACK segment. With the BSD socket API, passive openers call "listen" and "accept", rather than "connect". In client-server configurations, passive openers are typically servers.
被动开启器不发送仅SYN段，但使用SYN-ACK段响应SYN段的主机。使用BSD套接字API，被动开启器调用“侦听”和“接受”，而不是“连接”。在客户机-服务器配置中，被动开启器通常是服务器。
Simultaneous open The act of symmetrically establishing a TCP connection between two active openers (both of which call "connect" with BSD sockets). Each host of a simultaneous open sends both a SYN-only and a SYN-ACK segment. Simultaneous open is less common than asymmetric open with one active and one passive opener, but it can be used for NAT traversal by peer-to-peer applications [RFC5382].
同时打开在两个活动的打开程序之间对称地建立TCP连接的行为（这两个打开程序都使用BSD套接字调用“连接”）。同时打开的每个主机同时发送一个SYN only和一个SYN-ACK段。同时开放不如一个主动和一个被动开放器的非对称开放常见，但它可用于对等应用程序的NAT遍历[RFC5382]。
TEP A TCP encryption protocol intended for use with TCP-ENO and specified in a separate document
TEP一种TCP加密协议，用于TCP-ENO，并在单独的文档中指定
TEP identifier A unique 7-bit value in the range 0x20-0x7f that IANA has assigned to a TEP
TEP标识符IANA分配给TEP的0x20-0x7f范围内的唯一7位值
Negotiated TEP The single TEP governing a TCP connection, determined by use of the TCP ENO option specified in this document
协商TEP控制TCP连接的单个TEP，由使用本文档中指定的TCP ENO选项确定
TCP-ENO extends TCP connection establishment to enable encryption opportunistically. It uses a new TCP option kind [RFC793] to negotiate one among multiple possible TCP encryption protocols (TEPs). The negotiation involves hosts exchanging sets of supported TEPs, where each TEP is represented by a suboption within a larger TCP ENO option in the offering host's SYN segment.
TCP-ENO扩展了TCP连接建立，以便有机会实现加密。它使用新的TCP选项种类[RFC793]在多个可能的TCP加密协议（TEP）之间协商一个。协商涉及主机交换受支持的TEP集，其中每个TEP由提供主机的SYN段中较大的TCP ENO选项中的一个子选项表示。
If TCP-ENO succeeds, it yields the following information:
如果TCP-ENO成功，将产生以下信息：
o a negotiated TEP represented by a unique 7-bit TEP identifier,
o 由唯一的7位TEP标识符表示的协商TEP，
o a few extra bytes of suboption data from each host, if needed by the TEP,
o 如果TEP需要，则从每个主机上额外发送几个字节的子选项数据，
o a negotiation transcript with which to mitigate attacks on the negotiation itself,
o 用于缓解对谈判本身的攻击的谈判记录，
o role assignments designating one endpoint "host A" and the other endpoint "host B", and
o 指定一个端点“主机A”和另一个端点“主机B”的角色分配，以及
o a bit available to higher-layer protocols at each endpoint for out-of-band negotiation of updated behavior in the presence of TCP encryption.
o 在TCP加密存在的情况下，每个端点的高层协议可用于更新行为的带外协商的位。
If TCP-ENO fails, encryption is disabled and the connection falls back to traditional unencrypted TCP.
如果TCP-ENO失败，加密将被禁用，连接将退回到传统的未加密TCP。
The remainder of this section provides the normative description of the TCP ENO option and handshake protocol.
本节剩余部分提供了TCP ENO选项和握手协议的规范性描述。
TCP-ENO employs an option in the TCP header [RFC793]. Figure 1 illustrates the high-level format of this option.
TCP-ENO在TCP头[RFC793]中使用一个选项。图1说明了此选项的高级格式。
byte 0 1 2 N+1 (N+2 bytes total)
+-----+-----+-----+--....--+-----+
|Kind=|Len= | |
| 69 | N+2 | contents (N bytes) |
+-----+-----+-----+--....--+-----+
byte 0 1 2 N+1 (N+2 bytes total)
+-----+-----+-----+--....--+-----+
|Kind=|Len= | |
| 69 | N+2 | contents (N bytes) |
+-----+-----+-----+--....--+-----+
Figure 1: The TCP-ENO Option
图1:TCP-ENO选项
The contents of an ENO option can take one of two forms. A SYN-form ENO option, illustrated in Figure 2, appears only in SYN segments. A non-SYN-form ENO option, illustrated in Figure 3, appears only in non-SYN segments. The SYN-form ENO option acts as a container for zero or more suboptions, labeled "Opt_0", "Opt_1", ... in Figure 2. The non-SYN-form ENO option, by its presence, acts as a one-bit acknowledgment, with the actual contents ignored by ENO. Particular TEPs MAY assign additional meaning to the contents of non-SYN-form ENO options. When a negotiated TEP does not assign such meaning, the contents of a non-SYN-form ENO option MUST be zero bytes (i.e., N = 0) in sent segments and MUST be ignored in received segments.
ENO选项的内容可以采用两种形式之一。如图2所示，SYN form ENO选项仅出现在SYN段中。非SYN形式的ENO选项（如图3所示）仅出现在非SYN段中。SYN form ENO选项充当零个或多个子选项的容器，标记为“Opt_0”、“Opt_1”。。。如图2所示。非SYN form ENO选项通过其存在充当一位确认，实际内容被ENO忽略。特定TEP可能会赋予非SYN形式ENO选项的内容额外的含义。当协商的TEP未分配此类含义时，非SYN形式ENO选项的内容在发送段中必须为零字节（即N=0），在接收段中必须忽略。
byte 0 1 2 3 ... N+1
+-----+-----+-----+-----+--...--+-----+----...----+
|Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i |
| 69 | N+2 | | | | | data |
+-----+-----+-----+-----+--...--+-----+----...----+
byte 0 1 2 3 ... N+1
+-----+-----+-----+-----+--...--+-----+----...----+
|Kind=|Len= |Opt_0|Opt_1| |Opt_i| Opt_i |
| 69 | N+2 | | | | | data |
+-----+-----+-----+-----+--...--+-----+----...----+
Figure 2: SYN-Form ENO Option
图2:SYN Form ENO选项
byte 0 1 2 N+1
+-----+-----+-----...----+
|Kind=|Len= | ignored |
| 69 | N+2 | by TCP-ENO |
+-----+-----+-----...----+
byte 0 1 2 N+1
+-----+-----+-----...----+
|Kind=|Len= | ignored |
| 69 | N+2 | by TCP-ENO |
+-----+-----+-----...----+
Figure 3: Non-SYN-Form ENO option, Where N MAY Be 0
图3：非SYN形式的ENO选项，其中N可以是0
Every suboption starts with a byte of the form illustrated in Figure 4. The high bit "v", when set, introduces suboptions with variable-length data. When v = 0, the byte itself constitutes the entirety of the suboption. The remaining 7-bit value, called "glt", takes on various meanings as defined below:
每个子选项都以图4所示形式的字节开始。设置高位“v”时，会引入具有可变长度数据的子选项。当v=0时，字节本身构成子选项的整体。剩余的7位值称为“glt”，具有如下定义的各种含义：
o Global configuration data (discussed in Section 4.2)
o 全局配置数据（在第4.2节中讨论）
o Suboption data length for the next suboption (discussed in Section 4.4)
o 下一个子选项的子选项数据长度（在第4.4节中讨论）
o An offer to use a particular TEP defined in a separate TEP specification document
o 使用单独TEP规范文档中定义的特定TEP的报价
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| v | glt |
+---+---+---+---+---+---+---+---+
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| v | glt |
+---+---+---+---+---+---+---+---+
v - non-zero for use with variable-length suboption data glt - Global suboption, Length, or TEP identifier
v-用于可变长度子选项数据glt的非零-全局子选项、长度或TEP标识符
Figure 4: Format of Initial Suboption Byte
图4：初始子选项字节的格式
Table 1 summarizes the meaning of initial suboption bytes. Values of glt below 0x20 are used for global suboptions and length information (the "gl" in "glt"), while those greater than or equal to 0x20 are TEP identifiers (the "t"). When v = 0, since the initial suboption byte constitutes the entirety of the suboption, all information is expressed by the 7-bit glt value, which can be either a global suboption or a TEP identifier. When v = 1, it indicates a suboption with variable-length suboption data. Only TEP identifiers have suboption data, not global suboptions. Therefore, bytes with v = 1 and glt < 0x20 are not global suboptions but rather length bytes governing the length of the next suboption (which MUST be a TEP identifier). In the absence of a length byte, a TEP identifier suboption with v = 1 has suboption data extending to the end of the TCP option.
表1总结了初始子选项字节的含义。低于0x20的glt值用于全局子选项和长度信息（“glt”中的“gl”），而大于或等于0x20的值是TEP标识符（“t”）。当v=0时，由于初始子选项字节构成子选项的整体，因此所有信息都由7位glt值表示，该值可以是全局子选项或TEP标识符。当v=1时，表示具有可变长度子选项数据的子选项。只有TEP标识符具有子选项数据，而不具有全局子选项。因此，v=1且glt<0x20的字节不是全局子选项，而是控制下一个子选项（必须是TEP标识符）长度的长度字节。在缺少长度字节的情况下，v=1的TEP标识符子选项具有扩展到TCP选项末尾的子选项数据。
+-----------+---+-------------------------------------------+
| glt | v | Meaning |
+-----------+---+-------------------------------------------+
| 0x00-0x1f | 0 | Global suboption (Section 4.2) |
| 0x00-0x1f | 1 | Length byte (Section 4.4) |
| 0x20-0x7f | 0 | TEP identifier without suboption data |
| 0x20-0x7f | 1 | TEP identifier followed by suboption data |
+-----------+---+-------------------------------------------+
+-----------+---+-------------------------------------------+
| glt | v | Meaning |
+-----------+---+-------------------------------------------+
| 0x00-0x1f | 0 | Global suboption (Section 4.2) |
| 0x00-0x1f | 1 | Length byte (Section 4.4) |
| 0x20-0x7f | 0 | TEP identifier without suboption data |
| 0x20-0x7f | 1 | TEP identifier followed by suboption data |
+-----------+---+-------------------------------------------+
Table 1: Initial Suboption Byte Values
表1：初始子选项字节值
A SYN segment MUST contain at most one TCP ENO option. If a SYN segment contains more than one ENO option, the receiver MUST behave as though the segment contained no ENO options and disable encryption. A TEP MAY specify the use of multiple ENO options in a non-SYN segment. For non-SYN segments, ENO itself only distinguishes between the presence or absence of ENO options; multiple ENO options are interpreted the same as one.
SYN段最多必须包含一个TCP ENO选项。如果SYN段包含多个ENO选项，则接收方必须表现为该段不包含ENO选项，并禁用加密。TEP可以指定在非SYN段中使用多个ENO选项。对于非SYN段，ENO本身仅区分是否存在ENO选项；多个ENO选项的解释与一个相同。
Suboptions 0x00-0x1f are used for global configuration that applies regardless of the negotiated TEP. A TCP SYN segment MUST include at most one ENO suboption in this range. A receiver MUST ignore all but the first suboption in this range in any given TCP segment so as to anticipate updates to ENO that assign new meaning to bits in subsequent global suboptions. The value of a global suboption byte is interpreted as a bit mask, illustrated in Figure 5.
子选项0x00-0x1f用于全局配置，无论协商的TEP如何。TCP SYN段在此范围内最多必须包含一个ENO子选项。接收方必须忽略任何给定TCP段中该范围内除第一个子选项外的所有子选项，以便预测ENO的更新，从而为后续全局子选项中的位分配新的含义。全局子选项字节的值被解释为位掩码，如图5所示。
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |z1 |z2 |z3 | a | b |
+---+---+---+---+---+---+---+---+
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 |z1 |z2 |z3 | a | b |
+---+---+---+---+---+---+---+---+
b - Passive role bit a - Application-aware bit z* - Zero bits (reserved for future use)
b-被动角色位a-应用程序感知位z*-零位（保留供将来使用）
Figure 5: Format of the Global Suboption Byte
图5：全局子选项字节的格式
The fields of the bit mask are interpreted as follows:
位掩码的字段解释如下：
b The passive role bit MUST be 1 for all passive openers. For active openers, it MUST default to 0, but implementations MUST provide an API through which an application can explicitly set b = 1 before initiating an active open. (Manual configuration of "b" is only necessary to enable encryption with a simultaneous open
b对于所有被动开启器，被动角色位必须为1。对于活动Opener，它必须默认为0，但实现必须提供一个API，通过该API，应用程序可以在启动活动Opener之前显式设置b=1。（手动配置“b”仅用于在同时打开的情况下启用加密
and requires prior coordination to ensure exactly one endpoint sets b = 1 before connecting.) See Section 8.3 for further discussion.
并且需要事先协调，以确保在连接之前恰好有一个端点设置为b=1。）有关进一步的讨论，请参见第8.3节。
a Legacy applications can benefit from ENO-specific updates that improve endpoint authentication or avoid double encryption. The application-aware bit "a" is an out-of-band signal through which higher-layer protocols can enable ENO-specific updates that would otherwise not be backwards compatible. Implementations MUST set this bit to zero by default, and MUST provide an API through which applications can change the value of the bit as well as examine the value of the bit sent by the remote host. Implementations MUST furthermore support a mandatory application-aware mode in which TCP-ENO is automatically disabled if the remote host does not set a = 1. See Section 8.4 for further discussion.
传统应用程序可以从特定于ENO的更新中获益，这些更新可以改进端点身份验证或避免双重加密。应用程序感知位“a”是一个带外信号，通过它，高层协议可以启用ENO特定更新，否则将无法向后兼容。默认情况下，实现必须将该位设置为零，并且必须提供一个API，通过该API，应用程序可以更改位的值，并检查远程主机发送的位的值。实现还必须支持强制的应用程序感知模式，在该模式下，如果远程主机未设置a=1，TCP-ENO将自动禁用。进一步讨论见第8.4节。
z1, z2, z3 The "z" bits are reserved for future updates to TCP-ENO. They MUST be set to zero in sent segments and MUST be ignored in received segments.
z1、z2、z3“z”位保留用于将来对TCP-ENO的更新。在发送段中，它们必须设置为零，在接收段中必须忽略。
A SYN segment without an explicit global suboption has an implicit global suboption of 0x00. Because passive openers MUST always set b = 1, they cannot rely on this implicit 0x00 byte and MUST include an explicit global suboption in their SYN-ACK segments.
没有显式全局子选项的SYN段具有0x00的隐式全局子选项。由于被动开启器必须始终设置b=1，因此它们不能依赖此隐式0x00字节，并且必须在其SYN-ACK段中包含显式全局子选项。
TCP-ENO uses abstract roles called "A" and "B" to distinguish the two ends of a TCP connection. These roles are determined by the "b" bit in the global suboption. The host that sent an implicit or explicit suboption with b = 0 plays the A role. The host that sent b = 1 plays the B role. Because a passive opener MUST set b = 1 and an active opener by default has b = 0, the normal case is for the active opener to play role A and the passive opener role B.
TCP-ENO使用称为“A”和“B”的抽象角色来区分TCP连接的两端。这些角色由全局子选项中的“b”位确定。发送b=0的隐式或显式子选项的主机扮演A角色。发送b=1的主机扮演b角色。因为被动开场白必须设置b=1，而主动开场白默认为b=0，所以通常情况下，主动开场白扮演角色a，被动开场白扮演角色b。
Applications performing a simultaneous open, if they desire TCP-level encryption, need to arrange for exactly one endpoint to set b = 1 (despite being an active opener) while the other endpoint keeps the default b = 0. Otherwise, if both sides use the default b = 0 or if both sides set b = 1, then TCP-ENO will fail and fall back to unencrypted TCP. Likewise, if an active opener explicitly configures b = 1 and connects to a passive opener (which MUST always have b = 1), then TCP-ENO will fail and fall back to unencrypted TCP.
如果执行同时打开的应用程序需要TCP级别的加密，则需要安排恰好一个端点设置b=1（尽管是活动的打开程序），而另一个端点保持默认的b=0。否则，如果双方都使用默认的b=0，或者如果双方都设置了b=1，那么TCP-ENO将失败并返回到未加密的TCP。同样，如果主动开启器显式配置b=1并连接到被动开启器（必须始终具有b=1），则TCP-ENO将失败并返回到未加密的TCP。
TEP specifications SHOULD refer to TCP-ENO's A and B roles to specify asymmetric behavior by the two hosts. For the remainder of this document, we will use the terms "host A" and "host B" to designate the hosts with roles A and B, respectively, in a connection.
TEP规范应参考TCP-ENO的A和B角色，以指定两台主机的不对称行为。对于本文档的其余部分，我们将使用术语“主机A”和“主机B”来指定连接中分别具有角色A和角色B的主机。
A TEP MAY optionally make use of one or more bytes of suboption data. The presence of such data is indicated by setting v = 1 in the initial suboption byte (see Figure 4). A suboption introduced by a TEP identifier with v = 1 (i.e., a suboption whose first octet has value 0xa0 or higher) extends to the end of the TCP option. Hence, if only one suboption requires data, the most compact way to encode it is to place it last in the ENO option, after all other suboptions. In Figure 2, for example, the last suboption, Opt_i, has suboption data and thus requires v = 1. However, the suboption data length is inferred from the total length of the TCP option.
TEP可以选择使用一个或多个字节的子选项数据。通过在初始子选项字节中设置v=1来指示此类数据的存在（见图4）。由v=1的TEP标识符引入的子选项（即，第一个八位字节的值为0xa0或更高的子选项）扩展到TCP选项的末尾。因此，如果只有一个子选项需要数据，那么编码它的最简洁的方法就是将它放在ENO选项的最后，在所有其他子选项之后。例如，在图2中，最后一个子选项Opt_i具有子选项数据，因此需要v=1。但是，子选项数据长度是从TCP选项的总长度推断出来的。
When a suboption with data is not last in an ENO option, the sender MUST explicitly specify the suboption data length for the receiver to know where the next suboption starts. The sender does so by introducing the suboption with a length byte, depicted in Figure 6. The length byte encodes a 5-bit value nnnnn. Adding one to nnnnn yields the length of the suboption data (not including the length byte or the TEP identifier). Hence, a length byte can designate anywhere from 1 to 32 bytes of suboption data (inclusive).
当包含数据的子选项不是ENO选项中的最后一个时，发送方必须明确指定子选项数据长度，以便接收方知道下一个子选项从何处开始。发送方通过引入带有长度字节的子选项来实现，如图6所示。长度字节编码一个5位值nnn。将一个添加到nnnnn将生成子选项数据的长度（不包括长度字节或TEP标识符）。因此，长度字节可以指定1到32字节的子选项数据（包括）。
bit 7 6 5 4 3 2 1 0
+---+---+---+-------------------+
| 1 0 0 nnnnn |
+---+---+---+-------------------+
bit 7 6 5 4 3 2 1 0
+---+---+---+-------------------+
| 1 0 0 nnnnn |
+---+---+---+-------------------+
nnnnn - 5-bit value encoding (length - 1)
NNN-5位值编码（长度-1）
Figure 6: Format of a Length Byte
图6：长度字节的格式
A suboption preceded by a length byte MUST be a TEP identifier (glt >= 0x20) and MUST have v = 1. Figure 7 shows an example of such a suboption.
前面带有长度字节的子选项必须是TEP标识符（glt>=0x20），并且必须具有v=1。图7显示了这样一个子选项的示例。
byte 0 1 2 nnnnn+2 (nnnnn+3 bytes total)
+------+------+-------...-------+
|length| TEP | suboption data |
| byte |ident.| (nnnnn+1 bytes) |
+------+------+-------...-------+
byte 0 1 2 nnnnn+2 (nnnnn+3 bytes total)
+------+------+-------...-------+
|length| TEP | suboption data |
| byte |ident.| (nnnnn+1 bytes) |
+------+------+-------...-------+
length byte - specifies nnnnn
TEP identifier - MUST have v = 1 and glt >= 0x20
suboption data - length specified by nnnnn+1
length byte - specifies nnnnn
TEP identifier - MUST have v = 1 and glt >= 0x20
suboption data - length specified by nnnnn+1
Figure 7: Suboption with Length Byte
图7：长度为字节的子选项
A host MUST ignore an ENO option in a SYN segment and MUST disable encryption if either of the following apply:
主机必须忽略SYN段中的ENO选项，并且必须在以下任一情况下禁用加密：
1. A length byte indicates that suboption data would extend beyond the end of the TCP ENO option.
1. 长度字节表示子选项数据将超出TCP ENO选项的末尾。
2. A length byte is followed by an octet in the range 0x00-0x9f (meaning the following byte has v = 0 or glt < 0x20).
2. 长度字节后跟0x00-0x9f范围内的八位字节（表示以下字节的v=0或glt<0x20）。
Because the last suboption in an ENO option is special-cased to have its length inferred from the 8-bit TCP option length, it MAY contain more than 32 bytes of suboption data. Other suboptions are limited to 32 bytes by the length byte format. However, the TCP header itself can only accommodate a maximum of 40 bytes of options. Therefore, regardless of the length byte format, a segment would not be able to contain more than one suboption over 32 bytes in size. That said, TEPs MAY define the use of multiple suboptions with the same TEP identifier in the same SYN segment, providing another way to convey over 32 bytes of suboption data even with length bytes.
由于ENO选项中的最后一个子选项的长度是根据8位TCP选项长度推断出来的特殊情况，因此它可能包含超过32字节的子选项数据。其他子选项的长度字节格式限制为32字节。但是，TCP报头本身最多只能容纳40字节的选项。因此，无论长度字节格式如何，一个段不能包含超过32字节的多个子选项。也就是说，TEP可以定义在同一SYN段中使用具有相同TEP标识符的多个子选项，从而提供另一种方式来传输超过32字节的子选项数据，即使长度为字节。
A TEP identifier glt (with glt >= 0x20) is valid for a connection when all of the following hold:
当以下所有条件均成立时，TEP标识符glt（glt>=0x20）对连接有效：
1. Each side has sent a suboption for glt in its SYN-form ENO option.
1. 每一方都在其SYN form ENO选项中为glt发送了一个子选项。
2. Any suboption data in these glt suboptions is valid according to the TEP specification and satisfies any runtime constraints.
2. 根据TEP规范，这些glt子选项中的任何子选项数据都是有效的，并且满足任何运行时约束。
3. If an ENO option contains multiple suboptions with glt, then such repetition is well-defined by the TEP specification.
3. 如果ENO选项包含多个glt子选项，那么TEP规范会很好地定义这种重复。
A passive opener (which is always host B) sees the remote host's SYN segment before constructing its own SYN-ACK segment. Therefore, a passive opener SHOULD include only one TEP identifier in SYN-ACK segments and SHOULD ensure this TEP identifier is valid. However, simultaneous open or implementation considerations can prevent host B from offering only one TEP.
被动开启器（始终为主机B）在构建自己的SYN-ACK段之前会看到远程主机的SYN段。因此，被动开启器应在SYN-ACK段中仅包含一个TEP标识符，并应确保该TEP标识符有效。但是，同时考虑的开放或实现因素可能会阻止主机B只提供一个TEP。
To accommodate scenarios in which host B sends multiple TEP identifiers in the SYN-ACK segment, the negotiated TEP is defined as the last valid TEP identifier in host B's SYN-form ENO option. This definition means host B specifies TEP suboptions in order of increasing priority, while host A does not influence TEP priority.
为了适应主机B在SYN-ACK段中发送多个TEP标识符的情况，协商的TEP被定义为主机B的SYN form ENO选项中的最后一个有效TEP标识符。此定义意味着主机B按优先级增加的顺序指定TEP子选项，而主机A不影响TEP优先级。
A host employing TCP-ENO for a connection MUST include an ENO option in every TCP segment sent until either encryption is disabled or the host receives a non-SYN segment. In particular, this means an active opener MUST include a non-SYN-form ENO option in the third segment of a three-way handshake.
使用TCP-ENO进行连接的主机必须在发送的每个TCP段中包含ENO选项，直到禁用加密或主机接收到非SYN段为止。特别是，这意味着主动开启器必须在三方握手的第三段中包含非SYN形式的ENO选项。
A host MUST disable encryption, refrain from sending any further ENO options, and fall back to unencrypted TCP if any of the following occurs:
主机必须禁用加密，避免发送任何进一步的ENO选项，并在出现以下任何情况时退回到未加密的TCP：
1. Any segment it receives up to and including the first received ACK segment does not contain an ENO option (or contains an ill-formed SYN-form ENO option).
1. 它接收到的任何段（包括第一个接收到的ACK段）都不包含ENO选项（或包含格式错误的SYN form ENO选项）。
2. The SYN segment it receives does not contain a valid TEP identifier.
2. 它接收的SYN段不包含有效的TEP标识符。
3. It receives a SYN segment with an incompatible global suboption. (Specifically, "incompatible" means the two hosts set the same "b" value, or the connection is in mandatory application-aware mode and the remote host set a = 0.)
3. 它接收具有不兼容全局子选项的SYN段。（具体而言，“不兼容”是指两台主机设置了相同的“b”值，或者连接处于强制应用程序感知模式，而远程主机设置为a=0。）
Hosts MUST NOT alter SYN-form ENO options in retransmitted segments, or between the SYN and SYN-ACK segments of a simultaneous open, with two exceptions for an active opener. First, an active opener MAY unilaterally disable ENO (and thus remove the ENO option) between retransmissions of a SYN-only segment. (Such removal could enable recovery from middleboxes dropping segments with ENO options.) Second, an active opener performing simultaneous open MAY include no TCP-ENO option in its SYN-ACK if the received SYN caused it to disable encryption according to the above rules (for instance, because role negotiation failed).
主机不得更改重传段中的SYN form ENO选项，或同时打开的SYN和SYN-ACK段之间的选项，活动打开程序有两个例外。首先，主动开启器可在仅SYN段的重传之间单方面禁用ENO（从而移除ENO选项）。（这样的删除可以使用ENO选项从删除段的中间盒中恢复。）其次，如果接收到的SYN导致其根据上述规则禁用加密（例如，因为角色协商失败），则执行同时打开的活动打开程序的SYN-ACK中可能不包含TCP-ENO选项。
Once a host has both sent and received an ACK segment containing an ENO option, encryption MUST be enabled. Once encryption is enabled, hosts MUST follow the specification of the negotiated TEP and MUST NOT present raw TCP payload data to the application. In particular, data segments MUST NOT contain plaintext application data, but rather ciphertext, key negotiation parameters, or other messages as determined by the negotiated TEP.
主机发送和接收包含ENO选项的ACK段后，必须启用加密。启用加密后，主机必须遵循协商的TEP规范，并且不得向应用程序提供原始TCP有效负载数据。特别是，数据段不能包含明文应用程序数据，而是包含密文、密钥协商参数或协商TEP确定的其他消息。
A host MAY send a SYN-form ENO option containing zero TEP identifier suboptions, which we term a "vacuous" ENO option. If either host's SYN segment contains a vacuous ENO option, it follows that there are no valid TEP identifiers for the connection, and therefore the connection MUST fall back to unencrypted TCP. Hosts MAY send vacuous ENO options to indicate that ENO is supported but unavailable by configuration, or to probe network paths for robustness to ENO options. However, a passive opener MUST NOT send a vacuous ENO option in a SYN-ACK segment unless there was an ENO option in the SYN segment it received. Moreover, a passive opener's SYN-form ENO option MUST still include a global suboption with b = 1 as discussed in Section 4.3.
主机可以发送包含零TEP标识符子选项的SYN-form ENO选项，我们称之为“真空”ENO选项。如果任一主机的SYN段包含一个空ENO选项，则表明该连接没有有效的TEP标识符，因此该连接必须退回到未加密的TCP。主机可能会发送空洞的ENO选项，以指示ENO受支持但配置不可用，或者探测网络路径以确保对ENO选项的健壮性。但是，被动开启器不得在SYN-ACK段中发送空ENO选项，除非其接收的SYN段中存在ENO选项。此外，如第4.3节所述，被动开场白的SYN form ENO选项仍必须包括b=1的全局子选项。
TEPs MAY specify the use of data in SYN segments so as to reduce the number of round trips required for connection setup. The meaning of data in a SYN segment with an ENO option (a SYN+ENO segment) is determined by the last TEP identifier in the ENO option, which we term the segment's "SYN TEP". A SYN+ENO segment MAY of course include multiple TEP suboptions, but only the SYN TEP (i.e., the last one) specifies how to interpret the SYN segment's data payload.
TEP可以指定SYN段中数据的使用，以减少连接设置所需的往返次数。带有ENO选项（SYN+ENO段）的SYN段中数据的含义由ENO选项中的最后一个TEP标识符确定，我们称之为段的“SYN TEP”。SYN+ENO段当然可能包括多个TEP子选项，但只有SYN TEP（即最后一个）指定如何解释SYN段的数据有效负载。
A host sending a SYN+ENO segment MUST NOT include data in the segment unless the SYN TEP's specification defines the use of such data. Furthermore, to avoid conflicting interpretations of SYN data, a SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) option [RFC7413].
发送SYN+ENO段的主机不得在该段中包含数据，除非SYN TEP的规范定义了此类数据的使用。此外，为避免对SYN数据的解释冲突，SYN+ENO段不得包含非空TCP快速打开（TFO）选项[RFC7413]。
Because a host can send SYN data before knowing which if any TEP the connection will negotiate, hosts implementing ENO are REQUIRED to discard data from SYN+ENO segments when the SYN TEP does not become the negotiated TEP. Hosts are furthermore REQUIRED to discard SYN data in cases where another Internet standard specifies a conflicting interpretation of SYN data (as would occur when receiving a non-empty TFO option). This requirement applies to hosts that implement ENO even when ENO has been disabled by configuration. However, note that discarding SYN data is already common practice [RFC4987] and the new requirement applies only to segments containing ENO options.
因为主机可以在知道连接将协商哪个TEP之前发送SYN数据，所以当SYN TEP没有成为协商的TEP时，实现ENO的主机需要丢弃来自SYN+ENO段的数据。此外，如果另一个Internet标准指定了对SYN数据的冲突解释（接收非空TFO选项时会发生这种情况），则主机需要丢弃SYN数据。此要求适用于实现ENO的主机，即使配置已禁用ENO。但是，请注意，丢弃SYN数据已经是常见做法[RFC4987]，新要求仅适用于包含ENO选项的段。
More specifically, a host that implements ENO MUST discard the data in a received SYN+ENO segment if any of the following applies:
更具体地说，实现ENO的主机必须丢弃接收到的SYN+ENO段中的数据（如果以下任一情况适用）：
o ENO fails and TEP-indicated encryption is disabled for the connection.
o ENO失败，TEP指示的连接加密已禁用。
o The received segment's SYN TEP is not the negotiated TEP.
o 接收段的SYN TEP不是协商的TEP。
o The negotiated TEP does not define the use of SYN data.
o 协商的TEP没有定义SYN数据的使用。
o The SYN segment contains a non-empty TFO option or any other TCP option implying a conflicting definition of SYN data.
o SYN段包含非空的TFO选项或任何其他TCP选项，这意味着SYN数据的定义存在冲突。
A host discarding SYN data in compliance with the above requirement MUST NOT acknowledge the sequence number of the discarded data, but rather MUST acknowledge the other host's initial sequence number as if the received SYN segment contained no data. Furthermore, after discarding SYN data, such a host MUST NOT assume the SYN data will be identically retransmitted, and MUST process data only from non-SYN segments.
按照上述要求丢弃SYN数据的主机不得确认丢弃数据的序列号，而是必须确认另一主机的初始序列号，就像接收到的SYN段不包含任何数据一样。此外，在丢弃SYN数据之后，这样的主机不得假定SYN数据将被相同地重新传输，并且必须仅处理来自非SYN段的数据。
If a host sends a SYN+ENO segment with data and receives acknowledgment for the data, but the SYN TEP in its transmitted SYN segment is not the negotiated TEP (either because a different TEP was negotiated or because ENO failed to negotiate encryption), then the host MUST abort the TCP connection. Proceeding in any other fashion risks misinterpreted SYN data.
如果主机发送包含数据的SYN+ENO段并接收数据确认，但其传输的SYN段中的SYN TEP不是协商的TEP（可能是因为协商了不同的TEP，或者是因为ENO无法协商加密），则主机必须中止TCP连接。以任何其他方式进行都有可能误解SYN数据。
If a host sends a SYN-only SYN+ENO segment bearing data and subsequently receives a SYN-ACK segment without an ENO option, that host MUST abort the connection even if the SYN-ACK segment does not acknowledge the SYN data. The issue is that unacknowledged data could nonetheless have been cached by the receiver; later retransmissions intended to supersede this unacknowledged data could fail to do so if the receiver gives precedence to the cached original data. Implementations MAY provide an API call for a non-default mode in which unacknowledged SYN data does not cause a connection abort, but applications MUST use this mode only when a higher-layer integrity check would anyway terminate a garbled connection.
如果主机发送带有数据的仅SYN SYN+ENO段，然后接收不带ENO选项的SYN-ACK段，则即使SYN-ACK段未确认SYN数据，该主机也必须中止连接。问题是，未确认的数据仍可能被接收方缓存；如果接收者优先于缓存的原始数据，则以后用于取代此未确认数据的重新传输可能会失败。实现可能会为非默认模式提供API调用，在该模式下，未确认的SYN数据不会导致连接中止，但应用程序必须仅在高层完整性检查将终止乱码连接时才使用此模式。
To avoid unexpected connection aborts, ENO implementations MUST disable the use of data in SYN-only segments by default. Such data MAY be enabled by an API command. In particular, implementations MAY provide a per-connection mandatory encryption mode that automatically aborts a connection if ENO fails, and they MAY enable SYN data in this mode.
为了避免意外的连接中止，ENO实现必须在默认情况下禁用仅SYN段中的数据使用。此类数据可通过API命令启用。具体而言，实现可能提供每连接强制加密模式，该模式在ENO失败时自动中止连接，并且可能在此模式下启用SYN数据。
To satisfy the requirement of the previous paragraph, all TEPs SHOULD support a normal mode of operation that avoids data in SYN-only segments. An exception is TEPs intended to be disabled by default.
为满足上一段的要求，所有TEP应支持正常操作模式，避免仅SYN段中的数据。例外情况是默认情况下要禁用的TEP。
To defend against attacks on encryption negotiation itself, a TEP MUST, with high probability, fail to establish a working connection between two ENO-compliant hosts when SYN-form ENO options have been altered in transit. (Of course, in the absence of endpoint authentication, two compliant hosts can each still be connected to a man-in-the-middle attacker.) To detect SYN-form ENO option tampering, TEPs MUST reference a transcript of TCP-ENO's negotiation.
为了防御对加密协商本身的攻击，当SYN form ENO选项在传输过程中被更改时，TEP必须极有可能无法在两个符合ENO的主机之间建立工作连接。（当然，在没有端点身份验证的情况下，两个兼容主机仍然可以分别连接到中间人攻击者。）要检测SYN form ENO选项篡改，TEPs必须引用TCP-ENO协商的副本。
TCP-ENO defines its negotiation transcript as a packed data structure consisting of two TCP-ENO options exactly as they appeared in the TCP header (including the TCP option kind and TCP option length byte as illustrated in Figure 1). The transcript is constructed from the following, in order:
TCP-ENO将其协商转录本定义为一个压缩数据结构，由两个TCP-ENO选项组成，与TCP报头中显示的完全相同（包括TCP选项种类和TCP选项长度字节，如图1所示）。成绩单按以下顺序构建：
1. The TCP-ENO option in host A's SYN segment, including the kind and length bytes
1. 主机A的SYN段中的TCP-ENO选项，包括种类和长度字节
2. The TCP-ENO option in host B's SYN segment, including the kind and length bytes
2. 主机B的SYN段中的TCP-ENO选项，包括种类和长度字节
Note that because the ENO options in the transcript contain length bytes as specified by TCP, the transcript unambiguously delimits A's and B's ENO options.
请注意，由于转录本中的ENO选项包含TCP指定的长度字节，因此转录本明确界定了A和B的ENO选项。
TCP-ENO affords TEP specifications a large amount of design flexibility. However, to abstract TEP differences away from applications requires fitting them all into a coherent framework. As such, any TEP claiming an ENO TEP identifier MUST satisfy the following normative list of properties:
TCP-ENO为TEP规范提供了大量的设计灵活性。然而，要将TEP差异从应用程序中抽象出来，需要将它们全部整合到一个连贯的框架中。因此，任何声称拥有ENO TEP标识符的TEP必须满足以下规范性属性列表：
o TEPs MUST protect TCP data streams with authenticated encryption. (Note that "authenticated encryption" refers only to the form of encryption, such as an Authenticated Encryption with Associated Data (AEAD) algorithm meeting the requirements of [RFC5116]; it does not imply endpoint authentication.)
o TEP必须使用经过身份验证的加密保护TCP数据流。（注意，“认证加密”仅指加密形式，如符合[RFC5116]要求的相关数据认证加密（AEAD）算法；它并不意味着端点认证。）
o TEPs MUST define a session ID whose value identifies the TCP connection and, with overwhelming probability, is unique over all time if either host correctly obeys the TEP. Section 5.1 describes the requirements of the session ID in more detail.
o TEP必须定义一个会话ID，该ID的值标识TCP连接，并且如果任一主机正确遵守TEP，则该ID的值在所有时间内都是唯一的，这是绝对可能的。第5.1节更详细地描述了会话ID的要求。
o TEPs MUST NOT make data confidentiality dependent on encryption algorithms with a security strength [NIST-SP-800-57] of less than 120 bits. The number 120 was chosen to accommodate ciphers with 128-bit keys that lose a few bits of security either to particularities of the key schedule or to highly theoretical and unrealistic attacks.
o TEP不得使数据机密性依赖于安全强度[NIST-SP-800-57]小于120位的加密算法。选择数字120是为了容纳128位密钥的密码，这些密钥由于密钥调度的特殊性或高度理论化和不切实际的攻击而失去一些安全性。
o TEPs MUST NOT allow the negotiation of null cipher suites, even for debugging purposes. (Implementations MAY support debugging modes that allow applications to extract their own session keys.)
o TEP不得允许协商空密码套件，即使是出于调试目的。（实现可能支持允许应用程序提取自己的会话密钥的调试模式。）
o TEPs MUST guarantee the confidentiality of TCP streams without assuming the security of any long-lived secrets. Implementations SHOULD provide forward secrecy soon after the close of a TCP connection and SHOULD therefore bound the delay between closing a connection and erasing any relevant cryptographic secrets. (Exceptions to forward secrecy are permissible only at the implementation level and only in response to hardware or architectural constraints -- e.g., storage that cannot be securely erased.)
o TEP必须保证TCP流的机密性，而不承担任何长期机密的安全性。实现应该在TCP连接关闭后立即提供前向保密，因此应该限制关闭连接和删除任何相关密码之间的延迟。（只有在实现级别，并且仅在响应硬件或体系结构约束时，才允许对前向保密性进行例外—例如，无法安全擦除的存储。）
o TEPs MUST protect and authenticate the end-of-file marker conveyed by TCP's FIN flag. In particular, a receiver MUST, with overwhelming probability, detect a FIN flag that was set or cleared in transit and does not match the sender's intent. A TEP MAY discard a segment with such a corrupted FIN bit or MAY abort the connection in response to such a segment. However, any such abort MUST raise an error condition distinct from an authentic end-of-file condition.
o TEP必须保护和验证TCP的FIN标志传递的文件结束标记。特别是，接收方必须以压倒性的概率检测到在传输过程中设置或清除的FIN标志，该标志与发送方的意图不匹配。TEP可能会丢弃具有此类损坏FIN位的段，或者可能会中断连接以响应此类段。但是，任何此类中止都必须引发与真实文件结束条件不同的错误条件。
o TEPs MUST prevent corrupted packets from causing urgent data to be delivered when none has been sent. There are several ways to do so. For instance, a TEP MAY cryptographically protect the URG flag and urgent pointer alongside ordinary payload data. Alternatively, a TEP MAY disable urgent data functionality by clearing the URG flag on all received segments and returning errors in response to sender-side urgent-data API calls. Implementations SHOULD avoid negotiating TEPs that disable urgent data by default. The exception is when applications and protocols are known never to send urgent data.
o TEP必须防止损坏的数据包导致在未发送任何数据时发送紧急数据。有几种方法可以做到这一点。例如，TEP可以对URG标志和紧急指针以及普通有效负载数据进行加密保护。或者，TEP可以通过清除所有接收段上的URG标志并返回错误以响应发送方紧急数据API调用来禁用紧急数据功能。实现应该避免协商默认情况下禁用紧急数据的TEP。例外情况是，已知应用程序和协议从不发送紧急数据。
Each TEP MUST define a session ID that is computable by both endpoints and uniquely identifies each encrypted TCP connection. Implementations MUST expose the session ID to applications via an API extension. The API extension MUST return an error when no session ID is available because ENO has failed to negotiate encryption or because no connection is yet established. Applications that are aware of TCP-ENO SHOULD, when practical, authenticate the TCP endpoints by incorporating the values of the session ID and TCP-ENO role (A or B) into higher-layer authentication mechanisms.
每个TEP必须定义一个会话ID，该ID可由两个端点计算并唯一标识每个加密的TCP连接。实现必须通过API扩展向应用程序公开会话ID。当由于ENO无法协商加密或尚未建立连接而没有可用的会话ID时，API扩展必须返回错误。了解TCP-ENO的应用程序应在实际情况下，通过将会话ID和TCP-ENO角色（A或B）的值合并到更高层的身份验证机制中，对TCP端点进行身份验证。
In order to avoid replay attacks and prevent authenticated session IDs from being used out of context, session IDs MUST be unique over all time with high probability. This uniqueness property MUST hold even if one end of a connection maliciously manipulates the protocol in an effort to create duplicate session IDs. In other words, it MUST be infeasible for a host, even by violating the TEP specification, to establish two TCP connections with the same session ID to remote hosts properly implementing the TEP.
为了避免重播攻击并防止在上下文之外使用经过身份验证的会话ID，会话ID必须始终具有高概率的唯一性。即使连接的一端恶意操纵协议以创建重复的会话ID，此唯一性属性也必须保持不变。换句话说，即使违反TEP规范，主机也不可能建立两个具有相同会话ID的TCP连接到正确实现TEP的远程主机。
To prevent session IDs from being confused across TEPs, all session IDs begin with the negotiated TEP identifier -- that is, the last valid TEP identifier in host B's SYN segment. Furthermore, this initial byte has bit "v" set to the same value that accompanied the negotiated TEP identifier in B's SYN segment. However, only this single byte is included, not any suboption data. Figure 8 shows the resulting format. This format is designed for TEPs to compute unique identifiers; it is not intended for application authors to pick apart session IDs. Applications SHOULD treat session IDs as monolithic opaque values and SHOULD NOT discard the first byte to shorten identifiers. (An exception is for non-security-relevant purposes, such as gathering statistics about negotiated TEPs.)
为了防止会话ID在TEP之间混淆，所有会话ID都以协商的TEP标识符开始，即主机B的SYN段中最后一个有效的TEP标识符。此外，该初始字节将位“v”设置为与B的SYN段中协商TEP标识符的值相同的值。但是，仅包含此单字节，不包含任何子选项数据。图8显示了结果格式。该格式设计用于TEP计算唯一标识符；应用程序作者不打算分离会话ID。应用程序应将会话ID视为整体不透明值，不应丢弃第一个字节以缩短标识符。（例外情况是出于与安全无关的目的，例如收集有关协商TEP的统计数据。）
byte 0 1 2 N-1 N
+-----+------------...------------+
| sub-| collision-resistant hash |
| opt | of connection information |
+-----+------------...------------+
byte 0 1 2 N-1 N
+-----+------------...------------+
| sub-| collision-resistant hash |
| opt | of connection information |
+-----+------------...------------+
Figure 8: Format of a Session ID
图8：会话ID的格式
Though TEP specifications retain considerable flexibility in their definitions of the session ID, all session IDs MUST meet the following normative list of requirements:
尽管TEP规范在会话ID的定义中保持了相当大的灵活性，但所有会话ID必须满足以下规范性要求列表：
o The session ID MUST be at least 33 bytes (including the one-byte suboption), though TEPs MAY choose longer session IDs.
o 会话ID必须至少为33字节（包括“一字节”子选项），但TEP可以选择更长的会话ID。
o The session ID MUST depend, in a collision-resistant way, on all of the following (meaning it is computationally infeasible to produce collisions of the session ID derivation function unless all of the following quantities are identical):
o 会话ID必须以防冲突的方式依赖于以下所有内容（这意味着除非以下所有数量相同，否则在计算上不可能产生会话ID派生函数的冲突）：
* Fresh data contributed by both sides of the connection
* 连接双方提供的最新数据
* Any public keys, public Diffie-Hellman parameters, or other public asymmetric cryptographic parameters that are employed by the TEP and have corresponding private data that is known by only one side of the connection
* TEP使用的任何公钥、公共Diffie-Hellman参数或其他公共非对称加密参数，并且具有仅由连接的一方知道的相应私有数据
* The negotiation transcript specified in Section 4.8
* 第4.8节规定的谈判记录
o Unless and until applications disclose information about the session ID, all but the first byte MUST be computationally indistinguishable from random bytes to a network eavesdropper.
o 除非应用程序公开有关会话ID的信息，否则对于网络窃听者来说，除了第一个字节外，所有字节都必须在计算上与随机字节无法区分。
o Applications MAY choose to make session IDs public. Therefore, TEPs MUST NOT place any confidential data in the session ID (such as data permitting the derivation of session keys).
o 应用程序可以选择公开会话ID。因此，TEP不得在会话ID中放置任何机密数据（例如允许导出会话密钥的数据）。
This subsection illustrates the TCP-ENO handshake with a few non-normative examples.
本小节用几个非规范性示例说明TCP-ENO握手。
(1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK ENO<b=1,Y>
(3) A -> B: ACK ENO<>
[rest of connection encrypted according to TEP Y]
(1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK ENO<b=1,Y>
(3) A -> B: ACK ENO<>
[rest of connection encrypted according to TEP Y]
Figure 9: Three-Way Handshake with Successful TCP-ENO Negotiation
图9:TCP-ENO协商成功的三方握手
Figure 9 shows a three-way handshake with a successful TCP-ENO negotiation. Host A includes two ENO suboptions with TEP identifiers X and Y. Host A does not include an explicit global suboption, which means it has an implicit global suboption 0x00 conveying passive role bit b = 0. The two sides agree to follow the TEP identified by suboption Y.
图9显示了成功进行TCP-ENO协商的三方握手。主机A包括两个带有TEP标识符X和Y的ENO子选项。主机A不包括显式全局子选项，这意味着它有一个隐式全局子选项0x00，表示被动角色位b=0。双方同意遵循子方案Y确定的TEP。
(1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK
(3) A -> B: ACK
[rest of connection unencrypted legacy TCP]
(1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK
(3) A -> B: ACK
[rest of connection unencrypted legacy TCP]
Figure 10: Three-Way Handshake with Failed TCP-ENO Negotiation
图10:TCP-ENO协商失败的三方握手
Figure 10 shows a failed TCP-ENO negotiation. The active opener (A) indicates support for TEPs corresponding to suboptions X and Y. Unfortunately, at this point, one of several things occurs:
图10显示了失败的TCP-ENO协商。活动开场白（A）表示支持对应于子选项X和Y的TEP。不幸的是，此时出现了以下几种情况之一：
1. The passive opener (B) does not support TCP-ENO.
1. 被动开启器（B）不支持TCP-ENO。
2. B supports TCP-ENO but supports neither of the TEPs X and Y, and so it does not reply with an ENO option.
2. B支持TCP-ENO，但不支持TEPs X和Y，因此它不使用ENO选项进行回复。
3. B supports TCP-ENO but has the connection configured in mandatory application-aware mode and thus disables ENO because A's SYN segment contains an implicit global suboption with a = 0.
3. B支持TCP-ENO，但在强制应用程序感知模式下配置了连接，因此禁用了ENO，因为A的SYN段包含A=0的隐式全局子选项。
4. The network stripped the ENO option out of A's SYN segment, so B did not receive it.
4. 网络将ENO选项从A的SYN段中剥离，因此B没有收到它。
Whichever of the above applies, the connection transparently falls back to unencrypted TCP.
无论上述哪一项适用，连接都会透明地退回到未加密的TCP。
(1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK ENO<b=1,X> [ENO stripped by middlebox]
(3) A -> B: ACK
[rest of connection unencrypted legacy TCP]
(1) A -> B: SYN ENO<X,Y>
(2) B -> A: SYN-ACK ENO<b=1,X> [ENO stripped by middlebox]
(3) A -> B: ACK
[rest of connection unencrypted legacy TCP]
Figure 11: Failed TCP-ENO Negotiation Because of Option Stripping
图11：由于选项剥离，TCP-ENO协商失败
Figure 11 Shows another handshake with a failed encryption negotiation. In this case, the passive opener (B) receives an ENO option from A and replies. However, the reverse network path from B to A strips ENO options. Therefore, A does not receive an ENO option from B, it disables ENO, and it does not include a non-SYN-form ENO option in segment 3 when ACKing B's SYN. Had A not disabled encryption, Section 4.6 would have required it to include a non-SYN-form ENO option in segment 3. The omission of this option informs B that encryption negotiation has failed, after which the two hosts proceed with unencrypted TCP.
图11显示了另一个加密协商失败的握手。在这种情况下，被动开启器（B）从A接收ENO选项并回复。但是，从B到A的反向网络路径剥夺了ENO选项。因此，A没有从B接收ENO选项，它禁用ENO，并且在确认B的SYN时，在段3中不包括非SYN形式的ENO选项。如果未禁用加密，第4.6节将要求其在第3段中包含非SYN形式的ENO选项。省略此选项将通知B加密协商失败，然后两台主机继续使用未加密的TCP。
(1) A -> B: SYN ENO<Y,X>
(2) B -> A: SYN ENO<b=1,X,Y,Z>
(3) A -> B: SYN-ACK ENO<Y,X>
(4) B -> A: SYN-ACK ENO<b=1,X,Y,Z>
[rest of connection encrypted according to TEP Y]
(1) A -> B: SYN ENO<Y,X>
(2) B -> A: SYN ENO<b=1,X,Y,Z>
(3) A -> B: SYN-ACK ENO<Y,X>
(4) B -> A: SYN-ACK ENO<b=1,X,Y,Z>
[rest of connection encrypted according to TEP Y]
Figure 12: Simultaneous Open with Successful TCP-ENO Negotiation
图12：在TCP-ENO协商成功的情况下同时打开
Figure 12 shows a successful TCP-ENO negotiation with simultaneous open. Here, the first four segments contain a SYN-form ENO option, as each side sends both a SYN-only and a SYN-ACK segment. The ENO
图12显示了一个成功的TCP-ENO协商，同时打开。在这里，前四个段包含一个SYN form ENO选项，因为每一方同时发送一个SYN only和一个SYN-ACK段。埃诺
option in each host's SYN-ACK is identical to the ENO option in its SYN-only segment, as otherwise, connection establishment could not recover from the loss of a SYN segment. The last valid TEP in host B's ENO option is Y, so Y is the negotiated TEP.
每个主机的SYN-ACK中的选项与其仅SYN段中的ENO选项相同，否则，连接建立无法从丢失SYN段中恢复。主机B的ENO选项中的最后一个有效TEP是Y，因此Y是协商的TEP。
TCP-ENO is designed to capitalize on future developments that could alter trade-offs and change the best approach to TCP-level encryption (beyond introducing new cipher suites). By way of example, we discuss a few such possible developments.
TCP-ENO旨在利用未来的发展，这些发展可能会改变权衡，改变TCP级加密的最佳方法（除了引入新的密码套件）。作为例子，我们讨论了一些可能的发展。
Various proposals exist to increase the maximum space for options in the TCP header. These proposals are highly experimental -- particularly those that apply to SYN segments. Therefore, future TEPs are unlikely to benefit from extended SYN option space. In the unlikely event that SYN option space is one day extended, however, future TEPs could benefit by embedding key agreement messages directly in SYN segments. Under such usage, the 32-byte limit on length bytes could prove insufficient. This document intentionally aborts TCP-ENO if a length byte is followed by an octet in the range 0x00-0x9f. If necessary, a future update to this document can define a format for larger suboptions by assigning meaning to such currently undefined byte sequences.
存在各种建议来增加TCP标头中选项的最大空间。这些建议是高度实验性的——特别是那些适用于SYN段的建议。因此，未来的TEP不太可能从扩展的SYN选项空间中获益。然而，在SYN选项空间不太可能延长一天的情况下，未来的TEP可以通过将密钥协议消息直接嵌入SYN段而受益。在这种情况下，长度字节的32字节限制可能是不够的。如果长度字节后跟0x00-0x9f范围内的八位字节，则本文档有意中止TCP-ENO。如有必要，本文档的未来更新可以通过为这些当前未定义的字节序列赋予意义来定义较大子选项的格式。
New revisions to socket interfaces [RFC3493] could involve library calls that simultaneously have access to hostname information and an underlying TCP connection. Such an API enables the possibility of authenticating servers transparently to the application, particularly in conjunction with technologies such as DNS-Based Authentication of Named Entities (DANE) [RFC6394]. An update to TCP-ENO can adopt one of the "z" bits in the global suboption to negotiate the use of an endpoint authentication protocol before any application use of the TCP connection. Over time, the consequences of failed or missing endpoint authentication can gradually be increased from issuing log messages to aborting the connection if some as yet unspecified DNS record indicates authentication is mandatory. Through shared library updates, such endpoint authentication can potentially be added transparently to legacy applications without recompilation.
套接字接口[RFC3493]的新修订版可能涉及同时访问主机名信息和底层TCP连接的库调用。这样的API使得能够对应用程序透明地对服务器进行身份验证，特别是与基于DNS的命名实体身份验证（DANE）等技术结合使用[RFC6394]。对TCP-ENO的更新可以采用全局子选项中的“z”位之一，以便在任何应用程序使用TCP连接之前协商端点身份验证协议的使用。随着时间的推移，如果某些尚未指定的DNS记录指示必须进行身份验证，则端点身份验证失败或丢失的后果可能会逐渐增加，从发出日志消息到中止连接。通过共享库更新，这样的端点身份验证可以透明地添加到遗留应用程序中，而无需重新编译。
TLS can currently only be added to legacy applications whose protocols accommodate a STARTTLS command or equivalent. TCP-ENO, because it provides out-of-band signaling, opens the possibility of future TLS revisions being generically applicable to any TCP application.
TLS目前只能添加到协议包含STARTTLS命令或等效命令的遗留应用程序中。由于TCP-ENO提供带外信令，因此它为将来的TLS修订版一般适用于任何TCP应用提供了可能性。
This section describes some of the design rationale behind TCP-ENO.
本节介绍TCP-ENO背后的一些设计原理。
Incremental deployment of TCP-ENO depends critically on failure cases devolving to unencrypted TCP rather than causing the entire TCP connection to fail.
TCP-ENO的增量部署在很大程度上取决于转移到未加密TCP的故障案例，而不是导致整个TCP连接失败。
Because a network path might drop ENO options in one direction only, a host needs to know not just that the peer supports encryption, but that the peer has received an ENO option. To this end, ENO disables encryption unless it receives an ACK segment bearing an ENO option. To stay robust in the face of dropped segments, hosts continue to include non-SYN-form ENO options in segments until the point that they have received a non-SYN segment from the other side.
因为网络路径可能只在一个方向上丢弃ENO选项，所以主机不仅需要知道对等方支持加密，还需要知道对等方已收到ENO选项。为此，ENO禁用加密，除非它接收到带有ENO选项的ACK段。为了在遇到丢弃的段时保持健壮，主机继续在段中包含非SYN形式的ENO选项，直到从另一端接收到非SYN段为止。
One particularly pernicious middlebox behavior found in the wild is load balancers that echo unknown TCP options found in SYN segments back to an active opener. The passive role bit "b" in global suboptions ensures encryption will always be disabled under such circumstances, as sending back a verbatim copy of an active opener's SYN-form ENO option always causes role negotiation to fail.
在野外发现的一种特别有害的中间盒行为是负载平衡器，它将在SYN段中发现的未知TCP选项回传给活动的开启器。全局子选项中的被动角色位“b”确保在这种情况下始终禁用加密，因为发回主动开场白的SYN form ENO选项的逐字副本总是导致角色协商失败。
TEPs can employ suboption data for session caching, cipher suite negotiation, or other purposes. However, TCP currently limits total option space consumed by all options to only 40 bytes, making it impractical to have many suboptions with data. For this reason, ENO optimizes the case of a single suboption with data by inferring the length of the last suboption from the TCP option length. Doing so saves one byte.
TEP可以将子选项数据用于会话缓存、密码套件协商或其他目的。但是，TCP目前将所有选项占用的总选项空间限制为仅40字节，这使得在数据中有许多子选项是不切实际的。出于这个原因，ENO通过从TCP选项长度推断最后一个子选项的长度来优化具有数据的单个子选项的情况。这样做可以节省一个字节。
TCP-ENO, TEPs, and applications all have asymmetries that require an unambiguous way to identify one of the two connection endpoints. As an example, Section 4.8 specifies that host A's ENO option comes before host B's in the negotiation transcript. As another example, an application might need to authenticate one end of a TCP connection with a digital signature. To ensure the signed message cannot be interpreted out of context to authenticate the other end, the signed message would need to include both the session ID and the local role, A or B.
TCP-ENO、TEPs和应用程序都具有不对称性，需要以明确的方式标识两个连接端点之一。例如，第4.8节规定，在谈判记录中，主机A的ENO选项在主机B之前。作为另一个示例，应用程序可能需要使用数字签名对TCP连接的一端进行身份验证。为了确保签名消息不能脱离上下文进行解释以对另一端进行身份验证，签名消息需要同时包含会话ID和本地角色A或B。
A normal TCP three-way handshake involves one active and one passive opener. This asymmetry is captured by the default configuration of the "b" bit in the global suboption. With simultaneous open, both hosts are active openers, so TCP-ENO requires that one host explicitly configure b = 1. An alternate design might automatically break the symmetry to avoid this need for explicit configuration. However, all such designs we considered either lacked robustness or consumed precious bytes of SYN option space even in the absence of simultaneous open. (One complicating factor is that TCP does not know it is participating in a simultaneous open until after it has sent a SYN segment. Moreover, with packet loss, one host might never learn it has participated in a simultaneous open.)
正常的TCP三方握手包括一个主动和一个被动开启器。这种不对称性由全局子选项中“b”位的默认配置捕获。同时打开时，两台主机都是活动的打开程序，因此TCP-ENO要求一台主机显式配置b=1。另一种设计可能会自动打破对称性，以避免这种显式配置的需要。然而，我们考虑的所有此类设计要么缺乏健壮性，要么即使在没有同时打开的情况下也会消耗宝贵的SYN选项空间字节。（一个复杂的因素是，TCP在发送SYN段之前不知道它正在参与同步开放。此外，由于数据包丢失，一台主机可能永远也不会知道它参与了同步开放。）
Applications developed before TCP-ENO can potentially evolve to take advantage of TCP-level encryption. For instance, an application designed to run only on trusted networks might leverage TCP-ENO to run on untrusted networks, but, importantly, needs to authenticate endpoints and session IDs to do so. In addition to user-visible changes such as requesting credentials, this kind of authentication functionality requires application-layer protocol changes. Some protocols can accommodate the requisite changes -- for instance, by introducing a new verb analogous to STARTTLS, while others cannot do so in a backwards-compatible manner.
在TCP-ENO之前开发的应用程序可能会发展为利用TCP级别的加密。例如，设计为仅在受信任网络上运行的应用程序可能会利用TCP-ENO在不受信任的网络上运行，但重要的是，需要验证端点和会话ID才能这样做。除了用户可见的更改（如请求凭据）之外，这种身份验证功能还需要更改应用层协议。一些协议可以适应必要的更改——例如，通过引入一个类似于STARTTLS的新动词，而其他协议则不能以向后兼容的方式进行。
The application-aware bit "a" in the global suboption provides a means of incrementally deploying enhancements specific to TCP-ENO to application-layer protocols that would otherwise lack the necessary extensibility. Software implementing the enhancement always sets a = 1 in its own global suboption, but only activates the new behavior when the other end of the connection also sets a = 1.
全局子选项中的应用程序感知位“a”提供了一种将特定于TCP-ENO的增强功能增量部署到应用程序层协议的方法，否则将缺乏必要的可扩展性。实现增强功能的软件始终在其自身的全局子选项中设置a=1，但仅当连接的另一端也设置a=1时才激活新行为。
A related issue is that an application might leverage TCP-ENO as a replacement for legacy application-layer encryption. In this scenario, if both endpoints support TCP-ENO, then application-layer encryption can be disabled in favor of simply authenticating the TCP-ENO session ID. On the other hand, if one endpoint is not aware of the new mode of operation specific to TCP-ENO, there is little benefit to performing redundant encryption at the TCP layer; data is already encrypted once at the application layer, and authentication only has meaning with respect to this application-layer encryption. The mandatory application-aware mode lets applications avoid double encryption in this case: the mode sets a = 1 in the local host's global suboption but also disables TCP-ENO entirely in the event that the other side has not also set a = 1.
一个相关的问题是，应用程序可能会利用TCP-ENO替代传统的应用程序层加密。在这种情况下，如果两个端点都支持TCP-ENO，则可以禁用应用层加密，只需验证TCP-ENO会话ID即可。另一方面，如果一个端点不知道特定于TCP-ENO的新操作模式，则在TCP层执行冗余加密没有什么好处；数据已经在应用层加密一次，身份验证仅对该应用层加密有意义。强制应用程序感知模式允许应用程序在这种情况下避免双重加密：该模式在本地主机的全局子选项中设置a=1，但在另一方未设置a=1的情况下，也会完全禁用TCP-ENO。
Note that the application-aware bit is not needed by applications that already support adequate higher-layer encryption such as those provided by TLS [RFC8446] or SSH [RFC4253]. To avoid double encryption in such cases, it suffices to disable TCP-ENO by configuration on any ports with known secure protocols.
注意，已经支持适当的高层加密的应用程序（如TLS[RFC8446]或SSH[RFC4253]提供的应用程序）不需要应用程序感知位。为了避免这种情况下的双重加密，在任何具有已知安全协议的端口上通过配置禁用TCP-ENO就足够了。
This document does not specify the use of ENO options beyond the first few segments of a connection. Moreover, it does not specify the content of ENO options in non-SYN segments, only their presence. As a result, any use of option kind 69 after the SYN exchange does not conflict with this document. In addition, because ENO guarantees at most one negotiated TEP per connection, TEPs will not conflict with one another or ENO if they use option kind 69 for out-of-band signaling in non-SYN segments.
本文档未指定在连接的前几段之外使用ENO选项。此外，它没有指定非SYN段中ENO选项的内容，只指定它们的存在。因此，在SYN交换后使用选项种类69与本文件不冲突。此外，由于ENO保证每个连接最多有一个协商TEP，因此如果TEP在非SYN段中使用选项种类69进行带外信令，则TEP不会相互冲突或与ENO冲突。
Section 5.1 specifies that all but the first (TEP identifier) byte of a session ID MUST be computationally indistinguishable from random bytes to a network eavesdropper. This property is easy to ensure under standard assumptions about cryptographic hash functions. Such unpredictability helps security in a broad range of cases. For example, it makes it possible for applications to use a session ID from one connection to authenticate a session ID from another, thereby tying the two connections together. It furthermore helps ensure that TEPs do not trivially subvert the 33-byte minimum-length requirement for session IDs by padding shorter session IDs with zeros.
第5.1节规定，除了会话ID的第一个（TEP标识符）字节外，网络窃听者必须在计算上无法从随机字节中区分所有字节。在关于加密哈希函数的标准假设下，很容易确保此属性。这种不可预测性在许多情况下有助于安全。例如，它使应用程序可以使用来自一个连接的会话ID来验证来自另一个连接的会话ID，从而将两个连接绑定在一起。此外，它还有助于确保TEP不会因为用零填充较短的会话ID而破坏会话ID的33字节最小长度要求。
This document has experimental status because TCP-ENO's viability depends on middlebox behavior that can only be determined a posteriori. Specifically, we need to determine to what extent middleboxes will permit the use of TCP-ENO. Once TCP-ENO is deployed, we will be in a better position to gather data on two types of failure:
本文档处于实验状态，因为TCP-ENO的可行性取决于只能事后确定的中间盒行为。具体来说，我们需要确定中间盒在多大程度上允许使用TCP-ENO。一旦部署TCP-ENO，我们将能够更好地收集两种类型故障的数据：
1. Middleboxes downgrading TCP-ENO connections to unencrypted TCP. This can happen if middleboxes strip unknown TCP options or if they terminate TCP connections and relay data back and forth.
1. 中间盒将TCP-ENO连接降级为未加密的TCP。如果中间盒删除未知的TCP选项，或者终止TCP连接并来回中继数据，则可能发生这种情况。
2. Middleboxes causing TCP-ENO connections to fail completely. This can happen if middleboxes perform deep packet inspection and start dropping segments that unexpectedly contain ciphertext, or
2. 导致TCP-ENO连接完全失败的中间盒。如果中间盒执行深度数据包检查并开始丢弃意外包含密文的段，或者
if middleboxes strip ENO options from non-SYN segments after allowing them in SYN segments.
如果中间盒在SYN段中允许ENO选项后，将其从非SYN段中剥离。
Type-1 failures are tolerable since TCP-ENO is designed for incremental deployment anyway. Type-2 failures are more problematic, and, if prevalent, will require the development of techniques to avoid and recover from such failures. The experiment will succeed so long as we can avoid type-2 failures and find sufficient use cases that avoid type-1 failures (possibly along with a gradual path for further reducing type-1 failures).
类型1故障是可以容忍的，因为TCP-ENO设计用于增量部署。2型故障问题更大，如果普遍存在，则需要开发技术来避免此类故障并从中恢复。只要我们能够避免类型2故障，并找到足够的避免类型1故障的用例（可能还有进一步减少类型1故障的渐进路径），实验就会成功。
In addition to the question of basic viability, deploying TCP-ENO will allow us to identify and address other potential corner cases or relaxations. For example, does the slight decrease in effective TCP segment payload pose a problem to any applications, which would require restrictions on how TEPs interpret socket buffer sizes? Conversely, can we relax the prohibition on default TEPs that disable urgent data?
除了基本的生存能力问题外，部署TCP-ENO将使我们能够识别和解决其他潜在的角落案例或放松。例如，有效TCP段负载的轻微减少是否会对任何应用程序造成问题，这需要限制TEP如何解释套接字缓冲区大小？相反，我们能否放松对禁用紧急数据的默认TEP的禁令？
A final important metric, related to the pace of deployment and incidence of type-1 failures, will be the extent to which applications adopt enhancements specific to TCP-ENO for endpoint authentication.
与部署速度和1型故障发生率相关的最后一个重要指标是应用程序采用特定于TCP-ENO的增强功能进行端点身份验证的程度。
An obvious use case for TCP-ENO is opportunistic encryption, e.g., encrypting some connections, but only where supported and without any kind of endpoint authentication. Opportunistic encryption provides a property known as "opportunistic security" [RFC7435], which protects against undetectable large-scale eavesdropping. However, it does not protect against detectable large-scale eavesdropping (for instance, if ISPs terminate TCP connections and proxy them or simply downgrade connections to unencrypted). Moreover, opportunistic encryption emphatically does not protect against targeted attacks that employ trivial spoofing to redirect a specific high-value connection to a man-in-the-middle attacker. Hence, the mere presence of TEP-indicated encryption does not suffice for an application to represent a connection as secure to the user.
TCP-ENO的一个明显的用例是机会主义加密，例如，加密一些连接，但仅在受支持且没有任何端点身份验证的情况下进行。机会主义加密提供了一种称为“机会主义安全性”（RFC7435）的属性，可防止无法检测到的大规模窃听。但是，它不能防止可检测的大规模窃听（例如，如果ISP终止TCP连接并代理它们，或者只是将连接降级为未加密的连接）。此外，机会主义加密显然无法抵御利用普通欺骗将特定高价值连接重定向到中间人攻击者的目标攻击。因此，仅仅存在TEP指示的加密并不足以让应用程序将连接表示为对用户安全的连接。
Achieving stronger security with TCP-ENO requires verifying session IDs. Any application relying on ENO for communication security MUST incorporate session IDs into its endpoint authentication. By way of example, an authentication mechanism based on keyed digests (such as Digest Access Authentication [RFC7616]) can be extended to include the role and session ID in the input of the keyed digest. Authentication mechanisms with a notion of channel binding (such as Salted Challenge Response Authentication Mechanism (SCRAM) [RFC5802])
使用TCP-ENO实现更高的安全性需要验证会话ID。任何依赖ENO实现通信安全的应用程序都必须将会话ID合并到其端点身份验证中。举例来说，基于键控摘要的认证机制（例如摘要访问认证[RFC7616]）可被扩展以在键控摘要的输入中包括角色和会话ID。具有通道绑定概念的身份验证机制（如Salted质询-响应身份验证机制（SCRAM）[RFC5802]）
can be updated to derive a channel binding from the session ID. Higher-layer protocols MAY use the application-aware "a" bit to negotiate the inclusion of session IDs in authentication even when there is no in-band way to carry out such a negotiation. Because there is only one "a" bit, however, a protocol extension that specifies use of the "a" bit will likely require a built-in versioning or negotiation mechanism to accommodate crypto agility and future updates.
可以更新以从会话ID派生通道绑定。更高层协议可以使用应用程序感知的“a”位来协商将会话ID包括在身份验证中，即使没有带内方式来执行这种协商。但是，由于只有一个“a”位，指定使用“a”位的协议扩展可能需要内置版本控制或协商机制，以适应加密灵活性和未来更新。
Because TCP-ENO enables multiple different TEPs to coexist, security could potentially be only as strong as the weakest available TEP. In particular, if TEPs use a weak hash function to incorporate the TCP-ENO transcript into session IDs, then an attacker can undetectably tamper with ENO options to force negotiation of a deprecated and vulnerable TEP. To avoid such problems, security reviewers of new TEPs SHOULD pay particular attention to the collision resistance of hash functions used for session IDs (including the state of cryptanalysis and research into possible attacks). Even if other parts of a TEP rely on more esoteric cryptography that turns out to be vulnerable, it ought nonetheless to be intractable for an attacker to induce identical session IDs at both ends after tampering with ENO contents in SYN segments.
由于TCP-ENO允许多个不同的TEP共存，因此安全性可能仅与最脆弱的可用TEP一样强。特别是，如果TEP使用弱散列函数将TCP-ENO转录本合并到会话ID中，则攻击者可以不可检测地篡改ENO选项，以强制协商不推荐且易受攻击的TEP。为避免此类问题，新TEP的安全审查人员应特别注意用于会话ID的哈希函数的抗冲突性（包括密码分析状态和对可能攻击的研究）。即使TEP的其他部分依赖于更为深奥的加密技术，而这些加密技术被证明是易受攻击的，但攻击者在篡改SYN段中的ENO内容后，在两端诱导相同的会话ID应该是难以对付的。
Implementations MUST NOT send ENO options unless they have access to an adequate source of randomness [RFC4086]. Without secret unpredictable data at both ends of a connection, it is impossible for TEPs to achieve confidentiality and forward secrecy. Because systems typically have very little entropy on bootup, implementations might need to disable TCP-ENO until after system initialization.
除非能够访问足够的随机性源，否则实现不得发送ENO选项[RFC4086]。如果连接两端没有秘密的不可预测数据，TEPs就不可能实现机密性和前向保密性。因为系统在启动时通常只有很少的熵，所以实现可能需要在系统初始化之前禁用TCP-ENO。
With a regular three-way handshake (meaning no simultaneous open), the non-SYN-form ENO option in an active opener's first ACK segment MAY contain N > 0 bytes of TEP-specific data, as shown in Figure 3. Such data is not part of the TCP-ENO negotiation transcript and therefore MUST be separately authenticated by the TEP.
对于常规的三向握手（意味着没有同时打开），活动开启器的第一个ACK段中的非SYN形式ENO选项可能包含N>0字节的TEP特定数据，如图3所示。此类数据不属于TCP-ENO谈判记录的一部分，因此必须由TEP单独验证。
This document defines a new TCP option kind for TCP-ENO, assigned a value of 69 from the TCP option space. This value is defined as:
本文档为TCP-ENO定义了一种新的TCP选项类型，从TCP选项空间中分配了69的值。该值定义为：
+------+--------+----------------------------------+-----------+
| Kind | Length | Meaning | Reference |
+------+--------+----------------------------------+-----------+
| 69 | N | Encryption Negotiation (TCP-ENO) | RFC 8547 |
+------+--------+----------------------------------+-----------+
+------+--------+----------------------------------+-----------+
| Kind | Length | Meaning | Reference |
+------+--------+----------------------------------+-----------+
| 69 | N | Encryption Negotiation (TCP-ENO) | RFC 8547 |
+------+--------+----------------------------------+-----------+
Table 2: TCP Option Kind Numbers
表2:TCP选项种类编号
Early implementations of TCP-ENO and a predecessor TCP encryption protocol made unauthorized use of TCP option kind 69. These earlier uses of option 69 are not compatible with TCP-ENO and could disable encryption or suffer complete connection failure when interoperating with TCP-ENO-compliant hosts. Hence, legacy use of option 69 MUST be disabled on hosts that cannot be upgraded to TCP-ENO. More recent implementations used experimental option 253 per [RFC6994] with 16-bit ExID 0x454E. Current and new implementations of TCP-ENO MUST use option 69, while any legacy implementations MUST migrate to option 69. Note in particular that Section 4.1 requires at most one SYN-form ENO option per segment, which means hosts MUST NOT include both option 69 and option 253 with ExID 0x454E in the same TCP segment.
TCP-ENO和前身TCP加密协议的早期实现未经授权使用TCP选项种类69。选项69的这些早期使用与TCP-ENO不兼容，在与符合TCP-ENO的主机互操作时，可能会禁用加密或遭受完全连接失败。因此，必须在无法升级到TCP-ENO的主机上禁用选项69的传统使用。最近的实现使用了实验选项253 per[RFC6994]和16位ExID 0x454E。当前和新的TCP-ENO实现必须使用选项69，而任何遗留实现都必须迁移到选项69。请特别注意，第4.1节要求每个网段最多有一个SYN form ENO选项，这意味着主机不得在同一TCP网段中同时包含ExID为0x454E的选项69和选项253。
This document defines a 7-bit glt field in the range of 0x20-0x7f. IANA has created and will maintain a new registry titled "TCP Encryption Protocol Identifiers" under the "Transmission Control Protocol (TCP) Parameters" registry. Table 3 shows the initial contents of this registry. This document allocates one TEP identifier (0x20) for experimental use. In case the TEP identifier space proves too small, identifiers in the range 0x70-0x7f are reserved to enable a future update to this document to define extended identifier values. Future assignments are to be made upon satisfying either of two policies defined in [RFC8126]: "IETF Review" or (for non-IETF stream specifications) "Expert Review with RFC Required". IANA will furthermore provide early allocation [RFC7120] to facilitate testing before RFCs are finalized.
本文档定义了0x20-0x7f范围内的7位glt字段。IANA已在“传输控制协议（TCP）参数”注册表下创建并将维护一个名为“TCP加密协议标识符”的新注册表。表3显示了该注册表的初始内容。本文档分配一个TEP标识符（0x20）供实验使用。如果TEP标识符空间太小，则保留0x70-0x7f范围内的标识符，以便将来对此文档进行更新，以定义扩展标识符值。未来的任务将在满足[RFC8126]中定义的两项政策中的一项后进行：“IETF审查”或（对于非IETF流规范）“需要RFC的专家审查”。IANA还将提供早期分配[RFC7120]，以便于在RFC最终确定之前进行测试。
+-----------+------------------------------+-----------+
| Value | Meaning | Reference |
+-----------+------------------------------+-----------+
| 0x20 | Experimental Use | RFC 8547 |
| 0x70-0x7f | Reserved for extended values | RFC 8547 |
+-----------+------------------------------+-----------+
+-----------+------------------------------+-----------+
| Value | Meaning | Reference |
+-----------+------------------------------+-----------+
| 0x20 | Experimental Use | RFC 8547 |
| 0x70-0x7f | Reserved for extended values | RFC 8547 |
+-----------+------------------------------+-----------+
Table 3: TCP Encryption Protocol Identifiers
表3:TCP加密协议标识符
[NIST-SP-800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General", NIST Special Publication, 800-57, Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>.
[NIST-SP-800-57]国家标准与技术研究所，“关键管理建议-第1部分：概述”，NIST特别出版物，800-57，第4版，DOI 10.6028/NIST.SP.800-57pt1r4，2016年1月<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7120]Cotton，M.，“标准轨道代码点的早期IANA分配”，BCP 100，RFC 7120，DOI 10.17487/RFC7120，2014年1月<https://www.rfc-editor.org/info/rfc7120>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, <https://www.rfc-editor.org/info/rfc3493>.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，DOI 10.17487/RFC3493，2003年2月<https://www.rfc-editor.org/info/rfc3493>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<https://www.rfc-editor.org/info/rfc4253>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.
[RFC4987]Eddy，W.“TCP SYN洪泛攻击和常见缓解措施”，RFC 4987，DOI 10.17487/RFC4987，2007年8月<https://www.rfc-editor.org/info/rfc4987>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<https://www.rfc-editor.org/info/rfc5116>.
[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <https://www.rfc-editor.org/info/rfc5382>.
[RFC5382]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，DOI 10.17487/RFC5382，2008年10月<https://www.rfc-editor.org/info/rfc5382>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, DOI 10.17487/RFC5802, July 2010, <https://www.rfc-editor.org/info/rfc5802>.
[RFC5802]Newman，C.，Menon Sen，A.，Melnikov，A.，和N.Williams，“盐渍挑战响应认证机制（SCRAM）SASL和GSS-API机制”，RFC 5802，DOI 10.17487/RFC5802，2010年7月<https://www.rfc-editor.org/info/rfc5802>.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)", RFC 6394, DOI 10.17487/RFC6394, October 2011, <https://www.rfc-editor.org/info/rfc6394>.
[RFC6394]巴恩斯，R.“基于DNS的命名实体身份验证（DANE）的用例和要求”，RFC 6394，DOI 10.17487/RFC6394，2011年10月<https://www.rfc-editor.org/info/rfc6394>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <https://www.rfc-editor.org/info/rfc6994>.
[RFC6994]Touch，J.，“实验TCP选项的共享使用”，RFC 6994，DOI 10.17487/RFC6994，2013年8月<https://www.rfc-editor.org/info/rfc6994>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<https://www.rfc-editor.org/info/rfc7413>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<https://www.rfc-editor.org/info/rfc7435>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<https://www.rfc-editor.org/info/rfc7616>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
Acknowledgments
致谢
We are grateful for contributions, help, discussions, and feedback from the IETF and its TCPINC Working Group, including Marcelo Bagnulo, David Black, Bob Briscoe, Benoit Claise, Spencer Dawkins, Jake Holland, Jana Iyengar, Tero Kivinen, Mirja Kuhlewind, Watson Ladd, Kathleen Moriarty, Yoav Nir, Christoph Paasch, Eric Rescorla, Adam Roach, Kyle Rose, Michael Scharf, Joe Touch, and Eric Vyncke. This work was partially funded by DARPA CRASH and the Stanford Secure Internet of Things Project.
我们感谢IETF及其TCPINC工作组的贡献、帮助、讨论和反馈，包括Marcelo Bagnulo、David Black、Bob Briscoe、Benoit Claise、Spencer Dawkins、Jake Holland、Jana Iyengar、Tero Kivinen、Mirja Kuhlewind、Watson Ladd、Kathleen Moriarty、Yoav Nir、Christoph Paasch、Eric Rescorla、Adam Roach、，凯尔·罗斯、迈克尔·沙尔夫、乔·图奇和埃里克·温克。这项工作的部分资金来自DARPA CRASH和斯坦福安全物联网项目。
Contributors
贡献者
Dan Boneh was a coauthor of the draft that became this document.
Dan Boneh是成为本文件的草案的合著者。
Authors' Addresses
作者地址
Andrea Bittau Google 345 Spear Street San Francisco, CA 94105 United States of America
Andrea Bittau Google 345枪街旧金山，CA 94105美利坚合众国
Email: bittau@google.com
Email: bittau@google.com
Daniel B. Giffin Stanford University 353 Serra Mall, Room 288 Stanford, CA 94305 United States of America
Daniel B.Giffin斯坦福大学353 Serra Mall，美国加利福尼亚州斯坦福市288室，邮编94305
Email: daniel@beech-grove.net
Email: daniel@beech-grove.net
Mark Handley University College London Gower St. London WC1E 6BT United Kingdom
英国马克·汉德利大学学院伦敦高尔街WC1E 6BT
Email: M.Handley@cs.ucl.ac.uk
Email: M.Handley@cs.ucl.ac.uk
David Mazieres Stanford University 353 Serra Mall, Room 290 Stanford, CA 94305 United States of America
David Mazieres斯坦福大学353 Serra Mall，290室，美国加利福尼亚州斯坦福94305
Email: dm@uun.org
Email: dm@uun.org
Eric W. Smith Kestrel Institute 3260 Hillview Avenue Palo Alto, CA 94304 United States of America
Eric W.Smith Kestrel研究所美国加利福尼亚州帕洛阿尔托Hillview大道3260号，邮编94304
Email: eric.smith@kestrel.edu
Email: eric.smith@kestrel.edu