[要約] RFC 8547は、TCP-ENO (TCP Encryption Negotiation Option) に関する文書で、TCP接続における暗号化のネゴシエーションを可能にするためのメカニズムを定義しています。この目的は、TCP接続の初期段階でセキュリティオプションを柔軟に交渉し、データのプライバシーと整合性を向上させることにあります。利用場面としては、セキュアな通信を必要とするあらゆるTCPベースのアプリケーションやサービスが挙げられます。関連するRFCには、TCPに関する基本的なRFCであるRFC 793や、TCP-ENOを補完するセキュリティプロトコルを定義するRFCが含まれますが、RFC 8547自体が新しい概念を導入しているため、直接的な関連RFCは文書内で特定の番号としては言及されていない場合があります。
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トラフィックのかなりの部分が暗号化されていません。暗号化されていないトラフィックの持続性は、少なくとも2つの要因に起因する可能性があります。まず、一部のレガシープロトコルには、暗号化のサポートを伝達するためのシグナリングメカニズム（STARTTLSコマンドなど）がないため、段階的な展開が不可能です。第2に、レガシーアプリケーション自体を常にアップグレードできるとは限らないため、トランスポート層内で完全に透過的に暗号化を実装する方法が必要です。 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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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レベルの暗号化を実現するために費やした労力は、将来も引き続き適用可能である必要があります。このためには、2つの質問を個別に検討すると便利です。
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は、2つのエンドポイントが複数の可能なTEPからTCP暗号化プロトコル（TEP）に同意できるフレームワークを提供します。将来の互換性のために、TEPは、ワイヤー形式、TCPオプションスペースの使用、TCPヘッダーとセグメンテーションとの統合の点で大きく異なる可能性があります。ただし、ENOはこれらの違いを抽象化して、TCPレベルの暗号化を利用するアプリケーションに対して新しいTEPの導入を透過的に行えるようにします。
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は、1つ以上の関連する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. TEPが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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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では、アクティブなオープナーが「接続」を呼び出します。クライアント/サーバー構成では、アクティブなオープナーは通常クライアントです。
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セグメントで応答するホスト。 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].
同時オープン2つのアクティブなオープナー間で対称的にTCP接続を確立する動作（どちらもBSDソケットで「接続」を呼び出します）。同時オープンの各ホストは、SYNのみのセグメントとSYN-ACKセグメントの両方を送信します。同時オープンは、アクティブオープナーとパッシブオープナーが1つずつある非対称オープンよりも一般的ではありませんが、ピアツーピアアプリケーションによるNATトラバーサルに使用できます[RFC5382]。
TEP A TCP encryption protocol intended for use with TCP-ENO and specified in a separate document
TEP TCP-ENOでの使用を目的とし、別のドキュメントで指定されているTCP暗号化プロトコル
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）のうちの1つをネゴシエートします。ネゴシエーションには、サポートされる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) |
+-----+-----+-----+--....--+-----+
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つの形式のいずれかになります。図2に示すSYN形式のENOオプションは、SYNセグメントにのみ表示されます。図3に示す非SYN形式のENOオプションは、非SYNセグメントでのみ表示されます。 SYN形式のENOオプションは、図2で「Opt_0」、「Opt_1」、...とラベル付けされた0個以上のサブオプションのコンテナーとして機能します。非SYN形式のENOオプションは、その存在により、1つとして機能します実際の内容がENOによって無視されたビット確認応答。特定のTEPは、非SYN形式のENOオプションの内容に追加の意味を割り当ててもよい（MAY）。ネゴシエートされたTEPがそのような意味を割り当てない場合、非SYN形式のENOオプションの内容は、送信されたセグメントではゼロバイト（つまり、N = 0）でなければならず、受信されたセグメントでは無視されなければなりません（MUST）。
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フォーム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：Nが0の場合がある非SYNフォームENOオプション
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の場合、バイト自体がサブオプション全体を構成します。 「glt」と呼ばれる残りの7ビット値は、以下に定義するように、さまざまな意味を持ちます。
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 |
+---+---+---+---+---+---+---+---+
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 |
+-----------+---+-------------------------------------------+
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セグメントには、最大で1つのTCP ENOオプションを含める必要があります。 SYNセグメントに複数のENOオプションが含まれている場合、受信者はそのセグメントにENOオプションが含まれていないかのように動作し、暗号化を無効にする必要があります。 TEPは、非SYNセグメントで複数のENOオプションの使用を指定してもよい（MAY）。非SYNセグメントの場合、ENO自体はENOオプションの有無を区別するだけです。複数のENOオプションは1つと同じように解釈されます。
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セグメントには、この範囲で最大1つのENOサブオプションを含める必要があります。受信者は、後続のグローバルサブオプションのビットに新しい意味を割り当てるENOへの更新を予測するために、特定のTCPセグメントでこの範囲の最初のサブオプション以外をすべて無視する必要があります。図5に示すように、グローバルサブオプションバイトの値はビットマスクとして解釈されます。
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 and requires prior coordination to ensure exactly one endpoint sets b = 1 before connecting.) See Section 8.3 for further discussion.
bパッシブロールビットは、すべてのパッシブオープナーに対して1でなければなりません。アクティブなオープナーの場合、デフォルトで0にする必要がありますが、実装では、アプリケーションがアクティブなオープンを開始する前にb = 1を明示的に設定できるAPIを提供する必要があります。 （「b」の手動設定は、同時オープンで暗号化を有効にする場合にのみ必要であり、接続する前に正確に1つのエンドポイントが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を提供する必要があります。実装は、リモートホストが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を設定する必要があるため（MUST）、この暗黙の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仕様は、2つのホストによる非対称の動作を指定するために、TCP-ENOのAおよびBの役割を参照する必要があります（SHOULD）。このドキュメントの残りの部分では、「ホスト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は、オプションで1バイト以上のサブオプションデータを使用できます。このようなデータの存在は、初期サブオプションバイトにv = 1を設定することで示されます（図4を参照）。 v = 1のTEP識別子によって導入されたサブオプション（つまり、最初のオクテットの値が0xa0以上のサブオプション）は、TCPオプションの終わりまで拡張されます。したがって、1つのサブオプションのみがデータを必要とする場合、それをエンコードする最もコンパクトな方法は、他のすべてのサブオプションの後に、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ビット値nnnnnをエンコードします。 nnnnnに1を追加すると、サブオプションデータの長さが得られます（長さバイトまたはTEP識別子は含まれません）。したがって、長さバイトは、1〜32バイトのサブオプションデータ（両端を含む）のいずれかを指定できます。
bit 7 6 5 4 3 2 1 0
+---+---+---+-------------------+
| 1 0 0 nnnnn |
+---+---+---+-------------------+
nnnnn - 5-bit value encoding (length - 1)
nnnnn-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) |
+------+------+-------...-------+
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バイトを超えるサブオプションデータを含めることができます（MAY）。その他のサブオプションは、長さバイト形式により32バイトに制限されています。ただし、TCPヘッダー自体は最大40バイトのオプションしか収容できません。したがって、長さバイト形式に関係なく、セグメントには、サイズが32バイトを超える複数のサブオプションを含めることができません。つまり、TEPは、同じSYNセグメントで同じTEP識別子を持つ複数のサブオプションの使用を定義することができ（MAY）、長さバイトでも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形式のENOオプションでgltのサブオプションを送信しました。
2. Any suboption data in these glt suboptions is valid according to the TEP specification and satisfies any runtime constraints.
2. これらのgltサブオプションのすべてのサブオプションデータは、TEP仕様に従って有効であり、実行時の制約を満たします。
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識別子を1つだけ含める必要があり（SHOULD）、このTEP識別子が有効であることを確認する必要があります。ただし、同時にオープンまたは実装を検討すると、ホストBがTEPを1つしか提供できない場合があります。
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形式のENOオプションで最後の有効なTEP識別子として定義されます。この定義は、ホストAはTEP優先度に影響を与えないが、ホストBは優先度の高い順に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を使用するホストは、暗号化が無効になるか、ホストが非SYNセグメントを受信するまで、送信されるすべてのTCPセグメントにENOオプションを含める必要があります。特に、これはアクティブなオープナーが3ウェイハンドシェイクの3番目のセグメントに非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形式の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セグメントを受け取ります。 （具体的には、「非互換」とは、2つのホストが同じ「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セグメントとSYN-ACKセグメントの間で、アクティブなオープナーの2つの例外を除いて、SYN形式のENOオプションを変更してはなりません（MUST NOT）。最初に、アクティブなオープナーは、SYNのみのセグメントの再送信の間に一方的にENOを無効にする（したがって、ENOオプションを削除する）ことができる（MAY）。 （そのような削除により、ミドルボックスが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ペイロードデータを提示してはなりません（MUST NOT）。特に、データセグメントには、プレーンテキストのアプリケーションデータを含めることはできません（MUST NOT）。ただし、ネゴシエートされた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形式のENOオプションを送信できます（MAY）。これを「空の」ENOオプションと呼びます。いずれかのホストのSYNセグメントに空のENOオプションが含まれている場合、接続に有効なTEP識別子がないため、接続は暗号化されていないTCPにフォールバックする必要があります。ホストは、空のENOオプションを送信して、ENOがサポートされているが構成では利用できないことを示すか、またはENOオプションの堅牢性についてネットワークパスをプローブする場合があります。ただし、パッシブオープナーは、受信したSYNセグメントにENOオプションが存在しない限り、SYN-ACKセグメントに空のENOオプションを送信してはなりません（MUST NOT）。さらに、パッシブオープナーのSYN形式のENOオプションには、セクション4.3で説明するように、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セグメント（SYN + ENOセグメント）のデータの意味は、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 TEPの仕様でそのようなデータの使用が定義されていない限り、SYN + ENOセグメントを送信するホストはセグメントにデータを含めてはなりません（MUST NOT）。さらに、SYNデータの解釈の競合を回避するために、SYN + ENOセグメントに空でないTCP Fast Open（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データを送信できるため、ENOを実装するホストは、SYN TEPがネゴシエートされたTEPにならない場合、SYN + ENOセグメントからデータを破棄する必要があります。さらに、別のインターネット標準が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オプション、またはSYNデータの定義の競合を意味するその他のTCPオプションが含まれています。
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データがまったく同じように再送信されることを想定してはならず（MUST NOT）、非SYNセグメントからのデータのみを処理しなければなりません（MUST）。
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のみのセグメントのデータを回避する通常の動作モードをサポートする必要があります（SHOULD）。例外は、デフォルトで無効にすることを目的とした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.
暗号化ネゴシエーション自体への攻撃を防ぐために、TEPは、SYN形式のENOオプションが転送中に変更された場合、高い確率で、2つのENO準拠ホスト間で有効な接続を確立できません。 （もちろん、エンドポイント認証がない場合でも、2つの準拠ホストをそれぞれman-in-the-middle攻撃者に接続できます。）SYN形式のENOオプションの改ざんを検出するには、TEPは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ヘッダーに表示されたとおりの2つのTCP-ENOオプションで構成されるパックデータ構造として定義します（図1に示すように、TCPオプションの種類とTCPオプションの長さバイトを含みます）。筆記録は、以下から順番に作成されます。
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は、以下の規範的なプロパティのリストを満たさなければなりません（MUST）。
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は、TCP接続を識別する値を持つセッションIDを定義する必要があり、圧倒的な確率で、いずれかのホストがTEPに正しく従った場合、常に一意です。セクション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は、データの機密性を、120ビット未満のセキュリティ強度[NIST-SP-800-57]の暗号化アルゴリズムに依存させてはなりません（MUST NOT）。数値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は、デバッグ目的であっても、null暗号スイートのネゴシエーションを許可してはなりません（MUST NOT）。 （実装は、アプリケーションが独自のセッションキーを抽出できるようにするデバッグモードをサポートする場合があります。）
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接続を閉じた直後に転送秘密を提供する必要があるため（SHOULD）、接続を閉じてから関連する暗号秘密を消去するまでの遅延を制限する必要があります（SHOULD）。 （転送秘密の例外は、実装レベルでのみ、ハードウェアまたはアーキテクチャーの制約（安全に消去できないストレージなど）に応じた場合にのみ許可されます。）
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フラグと緊急ポインタを暗号で保護できます（MAY）。または、TEPは、受信したすべてのセグメントのURGフラグをクリアし、送信側の緊急データAPI呼び出しに応答してエラーを返すことにより、緊急データ機能を無効にすることができます（MAY）。実装では、デフォルトで緊急データを無効にする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は、両方のエンドポイントで計算可能で、暗号化された各TCP接続を一意に識別するセッションIDを定義する必要があります。実装では、API拡張を介してアプリケーションにセッションIDを公開する必要があります。 ENOが暗号化のネゴシエーションに失敗したため、または接続がまだ確立されていないために、セッションIDが利用できない場合、API拡張はエラーを返さなければなりません（MUST）。 TCP-ENOを認識するアプリケーションは、実用的な場合、セッションIDの値とTCP-ENOロール（AまたはB）を上位層の認証メカニズムに組み込むことにより、TCPエンドポイントを認証する必要があります（SHOULD）。
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仕様に違反していても、TEPを適切に実装しているリモートホストに対して同じセッションIDで2つのTCP接続を確立することは、ホストにとって実行不可能でなければなりません。
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.)
TEP間でセッションIDが混同されるのを防ぐために、すべてのセッションIDは、ネゴシエートされたTEP識別子、つまりホストBのSYNセグメント内の最後の有効なTEP識別子で始まります。さらに、この最初のバイトのビット "v"は、BのSYNセグメントでネゴシエートされたTEP識別子に伴う値と同じ値に設定されています。ただし、この単一バイトのみが含まれ、サブオプションデータは含まれません。図8は、結果のフォーマットを示しています。この形式は、TEPが一意の識別子を計算するために設計されています。アプリケーション作成者がセッションIDを分解することは意図されていません。アプリケーションはセッションIDをモノリシックの不透明な値として扱い、識別子を短くするために最初のバイトを破棄してはなりません（SHOULD NOT）。 （例外は、ネゴシエートされたTEPに関する統計の収集など、セキュリティに関連しない目的のためです。）
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 TEPはより長いセッションIDを選択できますが、セッションIDは少なくとも33バイト（1バイトのサブオプションを含む）でなければなりません。
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に機密データ（セッションキーの導出を許可するデータなど）を配置してはなりません（MUST NOT）。
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]
Figure 9: Three-Way Handshake with Successful TCP-ENO Negotiation
図9：TCP-ENOネゴシエーションが成功した3ウェイハンドシェイク
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ネゴシエーションが成功した3ウェイハンドシェイクを示しています。ホストAには、TEP識別子XおよびYを持つ2つのENOサブオプションが含まれています。ホストAには、明示的なグローバルサブオプションが含まれていません。つまり、パッシブな役割ビットb = 0を伝える暗黙的なグローバルサブオプション0x00があります。サブオプションY。
(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ネゴシエーションが失敗した3ウェイハンドシェイク
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をサポートしていますが、TEP 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をサポートしますが、接続を必須のアプリケーション認識モードで構成し、AのSYNセグメントにa = 0の暗黙的なグローバルサブオプションが含まれているため、ENOが無効になります。
4. The network stripped the ENO option out of A's SYN segment, so B did not receive it.
4. ネットワークはAのSYNセグメントからENOオプションを取り除いたため、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]
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にACKを送信するときにセグメント3に非SYN形式のENOオプションを含めません。暗号化が無効になっていない場合、セクション4.6では、セグメント3に非SYN形式のENOオプションを含める必要がありました。このオプションを省略すると、暗号化ネゴシエーションが失敗したことをBに通知し、その後、2つのホストが暗号化されていない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]
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 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.
図12は、同時オープンで成功したTCP-ENOネゴシエーションを示しています。ここでは、最初の4つのセグメントにSYN形式のENOオプションが含まれています。これは、両側がSYNのみのセグメントとSYN-ACKセグメントの両方を送信するためです。各ホストのSYN-ACKのENOオプションは、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オプションのスペースが1日延長されるという事態が発生した場合、将来の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」ビットの1つを採用して、アプリケーションが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セグメントを受信するまで、非SYN形式のENOオプションをセグメントに含め続けます。
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.
実際に見られるミドルボックスの特に悪質な動作の1つは、SYNセグメントにある不明なTCPオプションをアクティブなオープナーにエコーバックするロードバランサーです。グローバルサブオプションのパッシブロールビット "b"は、アクティブなオープナーのSYN形式の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オプションの長さから最後のサブオプションの長さを推測することにより、データを持つ単一のサブオプションのケースを最適化します。これにより、1バイトが節約されます。
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、TEP、およびアプリケーションにはすべて非対称性があり、2つの接続エンドポイントの1つを識別する明確な方法が必要です。例として、セクション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 3ウェイハンドシェイクには、アクティブオープナーとパッシブオープナーが1つずつ含まれます。この非対称性は、グローバルサブオプションの「b」ビットのデフォルト設定によってキャプチャされます。同時オープンでは、両方のホストがアクティブなオープナーであるため、TCP-ENOでは1つのホストが明示的にb = 1を構成する必要があります。代替設計では、明示的な構成の必要性を回避するために対称性を自動的に壊す場合があります。しかし、私たちが検討したそのようなすべての設計は、堅牢性に欠けるか、同時オープンがなくても貴重なバイトのSYNオプションスペースを消費しました。 （1つの複雑な要因は、SYNセグメントを送信するまで、TCPが同時オープンに参加していることをTCPが認識しないことです。さらに、パケット損失があると、1つのホストが同時オープンに参加していることを1つのホストが知ることはありません。）
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を単に認証することを優先して、アプリケーション層の暗号化を無効にすることができます。一方、1つのエンドポイントが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は接続ごとに最大1つのネゴシエートされた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識別子）バイト以外のすべてが、ランダムバイトからネットワーク盗聴者への計算上区別できないものでなければならないことを指定しています。このプロパティは、暗号化ハッシュ関数に関する標準的な仮定の下で簡単に確認できます。このような予測不可能性は、幅広いケースでセキュリティを支援します。たとえば、アプリケーションが1つの接続のセッションIDを使用して別の接続のセッションIDを認証できるようにすることで、2つの接続を結び付けます。さらに、短いセッションIDにゼロを埋め込むことにより、TEPがセッション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が導入されると、次の2種類の障害に関するデータを収集できるようになります。
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 if middleboxes strip ENO options from non-SYN segments after allowing them in SYN segments.
2.ミドルボックスが原因でTCP-ENO接続が完全に失敗します。これは、ミドルボックスが詳細なパケットインスペクションを実行し、暗号テキストを予期せずに含むセグメントのドロップを開始した場合、またはミドルボックスがSYNセグメントで許可した後に非SYNセグメントからENOオプションを削除した場合に発生する可能性があります。
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).
いずれにしても、TCP-ENOは増分展開用に設計されているため、タイプ1の障害は許容できます。タイプ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]) 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.
TCP-ENOでより強力なセキュリティを実現するには、セッションIDを確認する必要があります。通信セキュリティをENOに依存するすべてのアプリケーションは、セッションIDをそのエンドポイント認証に組み込む必要があります。例として、キー付きダイジェストに基づく認証メカニズム（ダイジェストアクセス認証[RFC7616]など）を拡張して、キー付きダイジェストの入力にロールとセッションIDを含めることができます。チャネルバインディングの概念を持つ認証メカニズム（ソルトチャレンジレスポンス認証メカニズム（SCRAM）[RFC5802]など）を更新して、セッションIDからチャネルバインディングを派生させることができます。上位層プロトコルは、アプリケーション対応の「a」ビットを使用して、そのようなネゴシエーションを実行するインバンドの方法がない場合でも、認証にセッションIDを含めることをネゴシエートできます。ただし、「a」ビットは1つしかないため、「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.
実装は、ランダム性の適切なソース[RFC4086]にアクセスできない限り、ENOオプションを送信してはなりません（MUST NOT）。接続の両端に予期しない秘密のデータがないと、TEPが機密性と転送秘密を達成することは不可能です。システムは通常、起動時にエントロピーがほとんどないため、システムの初期化が完了するまで、実装で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.
通常の3ウェイハンドシェイク（同時オープンを意味しない）では、アクティブオープナーの最初のACKセグメントの非SYN形式のENOオプションには、図3に示すように、N> 0バイトのTEP固有のデータが含まれる場合があります（MAY）。 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 |
+------+--------+----------------------------------+-----------+
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の従来の使用を無効にする必要があります。最近の実装では、[RFC6994]の実験オプション253と16ビットExID 0x454Eを使用していました。 TCP-ENOの現在の実装と新しい実装ではオプション69を使用する必要がありますが、従来の実装ではオプション69に移行する必要があります。特に、セクション4.1ではセグメントごとに最大で1つのSYN形式のENOオプションが必要であることに注意してください。同じTCPセグメント内のExID 0x454Eを持つオプション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は、「Transmission Control Protocol（TCP）Parameters」レジストリの下に「TCP Encryption Protocol Identifiers」という名前の新しいレジストリを作成して維持します。表3は、このレジストリの初期コンテンツを示しています。このドキュメントでは、実験用に1つのTEP識別子（0x20）を割り当てています。 TEP識別子スペースが小さすぎることが判明した場合、0x70-0x7fの範囲の識別子は、拡張された識別子の値を定義するためにこのドキュメントの将来の更新を可能にするために予約されています。将来の割り当ては、[RFC8126]で定義されている2つのポリシー「IETFレビュー」または（非IETFストリーム仕様の場合）「RFCが必要なエキスパートレビュー」のいずれかを満たすことで行われます。 IANAはさらに、RFCが確定する前のテストを容易にするために、早期割り当て[RFC7120]を提供します。
+-----------+------------------------------+-----------+
| 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] 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、 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。、「Transmission Control Protocol」、STD 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.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<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。、「Early IANA Allocation of Standards Track Code Points」、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]コットン、M。、レイバ、B。、およびT.ナルテン、「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.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、DOI 10.17487 / RFC3493、February 2003、<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、編、「The Secure Shell（SSH）Transport Layer Protocol」、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 Flooding Attacks and Common Mitigations」、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。、編、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]ニューマン、C。、メノンセン、A。、メルニコフ、A。、およびN.ウィリアムズ、「ソルトチャレンジレスポンス認証メカニズム（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] Barnes、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 Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年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 Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年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。、「The Transport Layer Security（TLS）Protocol Version 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ワーキンググループからの貢献、ヘルプ、ディスカッション、フィードバックに感謝しています。ラッド、キャスリーンモリアーティ、ヨーブニール、クリストフパーシュ、エリックレスコーラ、アダムローチ、カイルローズ、マイケルシャーフ、ジョータッチ、エリックヴィンケ。この作品の一部は、DARPA CRASHおよびStanford Secure Internet of Things Projectによって資金提供されました。
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
アンドレアビッタウグーグル345 Spear Streetサンフランシスコ、CA 94105アメリカ合衆国
Email: bittau@google.com
Daniel B. Giffin Stanford University 353 Serra Mall, Room 288 Stanford, CA 94305 United States of America
ダニエルB.ギフィンスタンフォード大学353セラモール、ルーム288スタンフォード、カリフォルニア94305アメリカ合衆国
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
David Mazieres Stanford University 353 Serra Mall, Room 290 Stanford, CA 94305 United States of America
David Mazieresスタンフォード大学353 Serra Mall、Room 290 Stanford、CA 94305アメリカ合衆国
Email: dm@uun.org
Eric W. Smith Kestrel Institute 3260 Hillview Avenue Palo Alto, CA 94304 United States of America
エリックW.スミスケストレルインスティテュート3260 Hillview Avenueパロアルト、CA 94304アメリカ合衆国
Email: eric.smith@kestrel.edu