[要約] RFC 8922は、セキュリティプロトコルとトランスポートサービス間の相互作用に関する調査を提供します。この文書の目的は、これらのプロトコルとサービスがどのように組み合わさっているか、そしてそれがセキュリティ特性にどのように影響するかを理解することです。主に、ネットワーク設計者や開発者がセキュアな通信システムを設計する際の参考資料として利用されます。
Internet Engineering Task Force (IETF) T. Enghardt
Request for Comments: 8922 TU Berlin
Category: Informational T. Pauly
ISSN: 2070-1721 Apple Inc.
C. Perkins
University of Glasgow
K. Rose
Akamai Technologies, Inc.
C. Wood
Cloudflare
October 2020
A Survey of the Interaction between Security Protocols and Transport Services
セキュリティプロトコルとトランスポートサービスの間の相互作用の調査
Abstract
概要
This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support.
この資料は、一般的に使用されているネットワークセキュリティプロトコルの調査を提供し、それらがどのように対話してアプリケーションとトランスポートプロトコルと統合されているかに焦点を当てています。その目標は、セキュリティプロトコルを追加するために必要なインタフェースを説明することによって、トランスポートサービスを定義およびカタログ化するための努力を補完することです。この調査は、IETFの範囲または文脈内で開発されたプロトコルに限定されず、含まれているものは、トランスポートサービスシステムがサポートする必要があるかもしれない機能のスーパーセットを表す。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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/rfc8922.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc8922で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Goals
1.2. Non-goals
2. Terminology
3. Transport Security Protocol Descriptions
3.1. Application Payload Security Protocols
3.1.1. TLS
3.1.2. DTLS
3.2. Application-Specific Security Protocols
3.2.1. Secure RTP
3.3. Transport-Layer Security Protocols
3.3.1. IETF QUIC
3.3.2. Google QUIC
3.3.3. tcpcrypt
3.3.4. MinimaLT
3.3.5. CurveCP
3.4. Packet Security Protocols
3.4.1. IPsec
3.4.2. WireGuard
3.4.3. OpenVPN
4. Transport Dependencies
4.1. Reliable Byte-Stream Transports
4.2. Unreliable Datagram Transports
4.2.1. Datagram Protocols with Defined Byte-Stream Mappings
4.3. Transport-Specific Dependencies
5. Application Interface
5.1. Pre-connection Interfaces
5.2. Connection Interfaces
5.3. Post-connection Interfaces
5.4. Summary of Interfaces Exposed by Protocols
6. IANA Considerations
7. Security Considerations
8. Privacy Considerations
9. Informative References
Acknowledgments
Authors' Addresses
Services and features provided by transport protocols have been cataloged in [RFC8095]. This document supplements that work by surveying commonly used and notable network security protocols, and identifying the interfaces between these protocols and both transport protocols and applications. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP, and MinimaLT. For each protocol, this document provides a brief description. Then, it describes the interfaces between these protocols and transports in Section 4 and the interfaces between these protocols and applications in Section 5.
トランスポートプロトコルによって提供されるサービスと機能は[RFC8095]でカタログ化されています。この文書は、一般的に使用されているネットワークセキュリティプロトコルを調査し、これらのプロトコルとトランスポートプロトコルとアプリケーションの両方のインターフェイスを識別します。トランスポート層セキュリティ（TLS）、データグラムトランスポート層セキュリティ（DTLS）、IETF QUIC、Google QUIC（Goos）、TCPCRYPT、インターネットプロトコルセキュリティ（IPSec）、DTLS、Wireguard、Curvecpによるセキュアリアルタイムトランスポートプロトコル（SRTP）、そして最小限の。プロトコルごとに、このドキュメントで簡単な説明が記載されています。そして、これらのプロトコルとセクション4でのトランスポートと、セクション5のこれらのプロトコルとアプリケーションとの間のインタフェースを説明します。
A Transport Services system exposes an interface for applications to
access various (secure) transport protocol features. The security
protocols included in this survey represent a superset of
functionality and features a Transport Services system may need to
support both internally and externally (via an API) for applications
[TAPS-ARCH]. Ubiquitous IETF protocols such as (D)TLS, as well as
non-standard protocols such as gQUIC, are included despite
overlapping features. As such, this survey is not limited to
protocols developed within the scope or context of the IETF. Outside
of this candidate set, protocols that do not offer new features are
omitted. For example, newer protocols such as WireGuard make unique
design choices that have implications for and limitations on
application usage. In contrast, protocols such as secure shell (SSH)
[RFC4253], GRE [RFC2890], the Layer 2 Tunneling Protocol (L2TP)
[RFC5641], and Application Layer Transport Security (ALTS) [ALTS] are
omitted since they do not provide interfaces deemed unique.
Authentication-only protocols such as the TCP Authentication Option (TCP-AO) [RFC5925] and the IPsec Authentication Header (AH) [RFC4302] are excluded from this survey. TCP-AO adds authentication to long-lived TCP connections, e.g., replay protection with per-packet Message Authentication Codes. (TCP-AO obsoletes TCP MD5 "signature" options specified in [RFC2385].) One primary use case of TCP-AO is for protecting BGP connections. Similarly, AH adds per-datagram authentication and integrity, along with replay protection. Despite these improvements, neither protocol sees general use and both lack critical properties important for emergent transport security protocols, such as confidentiality and privacy protections. Such protocols are thus omitted from this survey.
TCP認証オプション（TCP-AO）[RFC5925]やIPsec認証ヘッダー（AH）[RFC4302]などの認証専用プロトコルは、この調査から除外されています。TCP-AOは、長期的なTCP接続、例えばパケットごとのメッセージ認証コードを再生するための認証を追加します。（TCP-aoは、RFC2385]で指定された[TCP MD5 "Signature"オプション。）TCP-AOの1つの主なユースケースはBGP接続を保護するためのものです。同様に、AHはデータグラム認証と整合性を再生保護と共に追加します。これらの改良にもかかわらず、両方のプロトコルは一般的な使用も見ていない、そして両方とも、機密性やプライバシー保護などの緊急のトランスポートセキュリティプロトコルにとって重要な特性が重要です。このようなプロトコルはこの調査から省略されている。
This document only surveys point-to-point protocols; multicast protocols are out of scope.
この文書はポイントツーポイントプロトコルのみを調査します。マルチキャストプロトコルは範囲外です。
This survey is intended to help identify the most common interface surfaces between security protocols and transport protocols, and between security protocols and applications.
この調査は、セキュリティプロトコルとトランスポートプロトコルとセキュリティプロトコルとアプリケーションとの間で最も一般的なインターフェースサーフェスを特定するのに役立つことを目的としています。
One of the goals of the Transport Services effort is to define a common interface for using transport protocols that allows software using transport protocols to easily adopt new protocols that provide similar feature sets. The survey of the dependencies security protocols have upon transport protocols can guide implementations in determining which transport protocols are appropriate to be able to use beneath a given security protocol. For example, a security protocol that expects to run over a reliable stream of bytes, like TLS, restricts the set of transport protocols that can be used to those that offer a reliable stream of bytes.
トランスポートサービスの取り組みの目標の1つは、トランスポートプロトコルを使用してソフトウェアを使用することを可能にするトランスポートプロトコルを使用するための一般的なインタフェースを定義することです。これは、同様の機能セットを提供する新しいプロトコルを簡単に採用します。依存関係セキュリティプロトコルの調査は、トランスポートプロトコルがあると、どのトランスポートプロトコルが特定のセキュリティプロトコルの下に使用できるかを判断する際に実装を導くことができます。たとえば、TLSのような信頼できるバイトのストリームを実行することを期待するセキュリティプロトコルは、信頼できるバイトのストリームを提供するものに使用できるトランスポートプロトコルのセットを制限します。
Defining the common interfaces that security protocols provide to applications also allows interfaces to be designed in a way that common functionality can use the same APIs. For example, many security protocols that provide authentication let the application be involved in peer identity validation. Any interface to use a secure transport protocol stack thus needs to allow applications to perform this action during connection establishment.
セキュリティプロトコルがアプリケーションに提供する共通のインタフェースの定義は、共通の機能が同じAPIを使用できるようにインタフェースを設計することもできます。たとえば、認証を提供する多くのセキュリティプロトコルをアプリケーションをピアID検証に関与させることができます。したがって、安全なトランスポートプロトコルスタックを使用するための任意のインターフェースは、接続確立中にこの動作を実行できるようにする必要があります。
While this survey provides similar analysis to that which was performed for transport protocols in [RFC8095], it is important to distinguish that the use of security protocols requires more consideration.
この調査では、[RFC8095]のトランスポートプロトコルに対して実行されたものと同様の分析を提供しますが、セキュリティプロトコルの使用に多くの検討を必要とすると区別することが重要です。
It is not a goal to allow software implementations to automatically switch between different security protocols, even where their interfaces to transport and applications are equivalent. Even between versions, security protocols have subtly different guarantees and vulnerabilities. Thus, any implementation needs to only use the set of protocols and algorithms that are requested by applications or by a system policy.
トランスポートおよびアプリケーションへのインタフェースが同等の場合でも、ソフトウェア実装が異なるセキュリティプロトコルを自動的に切り替えることを目的ではありません。バージョン間でさえ、セキュリティプロトコルは微妙に異なる保証と脆弱性を持ちます。したがって、任意の実装は、アプリケーションによってまたはシステムポリシーによって要求されるプロトコルとアルゴリズムのセットのみを使用する必要があります。
Different security protocols also can use incompatible notions of peer identity and authentication, and cryptographic options. It is not a goal to identify a common set of representations for these concepts.
異なるセキュリティプロトコルは、ピアIDと認証の互換性のない概念、および暗号化オプションを使用することもできます。これらの概念の一般的な表現セットを特定することは目標ではありません。
The protocols surveyed in this document represent a superset of functionality and features a Transport Services system may need to support. It does not list all transport protocols that a Transport Services system may need to implement, nor does it mandate that a Transport Service system implement any particular protocol.
この文書で調査されたプロトコルは、機能性のスーパーセットを表し、トランスポートサービスシステムがサポートする必要があるかもしれません。トランスポートサービスシステムが実装する必要がある、またはトランスポートサービスシステムが特定のプロトコルを実装する必要はない可能性があるというすべてのトランスポートプロトコルをリストしません。
A Transport Services system may implement any secure transport protocol that provides the described features. In doing so, it may need to expose an interface to the application to configure these features.
トランスポートサービスシステムは、説明された機能を提供する安全なトランスポートプロトコルを実装することができる。そうすることで、これらの機能を設定するためにインターフェイスをアプリケーションに公開する必要があります。
The following terms are used throughout this document to describe the roles and interactions of transport security protocols (some of which are also defined in [RFC8095]):
次の条項は、トランスポートセキュリティプロトコルの役割と相互作用を説明するためにこの文書全体を通して使用されます（その一部は[RFC8095]でも定義されています）。
Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, and message-versus-stream orientation.
トランスポート機能：トランスポート層がアプリケーションに提供する特定のエンドツーエンド機能。例としては、機密性、信頼性の高い配信、順序付け配信、およびメッセージ対ストリームの向きがあります。
Transport Service: a set of Transport Features, without an association to any given framing protocol, that provides functionality to an application.
トランスポートサービス：アプリケーションに機能性を提供する、任意のフレーミングプロトコルとの関連付けがない一連のトランスポート機能。
Transport Services system: a software component that exposes an interface to different Transport Services to an application.
トランスポートサービスシステム：さまざまなトランスポートサービスへのインタフェースをアプリケーションに公開するソフトウェアコンポーネント。
Transport Protocol: an implementation that provides one or more different Transport Services using a specific framing and header format on the wire. A Transport Protocol services an application, whether directly or in conjunction with a security protocol.
トランスポートプロトコル：ワイヤ上の特定のフレーミングおよびヘッダフォーマットを使用して1つ以上の異なるトランスポートサービスを提供する実装。トランスポートプロトコルサービスは、直接またはセキュリティプロトコルと組み合わせて、アプリケーションをアプリケーションに保護します。
Application: an entity that uses a transport protocol for end-to-end delivery of data across the network. This may also be an upper layer protocol or tunnel encapsulation.
アプリケーション：ネットワーク全体のデータのエンドツーエンド配信のためのトランスポートプロトコルを使用するエンティティ。これはまた、上位層プロトコルまたはトンネルカプセル化であり得る。
Security Protocol: a defined network protocol that implements one or more security features, such as authentication, encryption, key generation, session resumption, and privacy. Security protocols may be used alongside transport protocols, and in combination with other security protocols when appropriate.
セキュリティプロトコル：認証、暗号化、鍵生成、セッションの再開、およびプライバシーなど、1つ以上のセキュリティ機能を実装する定義済みのネットワークプロトコル。セキュリティプロトコルは、トランスポートプロトコルと一緒に、および適切な場合は他のセキュリティプロトコルと組み合わせて使用できます。
Handshake Protocol: a protocol that enables peers to validate each other and to securely establish shared cryptographic context.
ハンドシェイクプロトコル：ピアが互いを検証することを可能にし、共有暗号化コンテキストを確実に確実に確実にすることを可能にするプロトコル。
Record: framed protocol messages.
記録：フレームのプロトコルメッセージ。
Record Protocol: a security protocol that allows data to be divided into manageable blocks and protected using shared cryptographic context.
レコードプロトコル：データを管理可能なブロックに分割し、共有暗号化コンテキストを使用して保護されることを可能にするセキュリティプロトコル。
Session: an ephemeral security association between applications.
セッション：アプリケーション間のエフェメラルセキュリティアソシエーション。
Connection: the shared state of two or more endpoints that persists across messages that are transmitted between these endpoints. A connection is a transient participant of a session, and a session generally lasts between connection instances.
接続：これらのエンドポイント間で送信されるメッセージ間で解決される2つ以上のエンドポイントの共有状態。接続はセッションの一時的な参加者であり、セッションは一般に接続インスタンス間で続きます。
Peer: an endpoint application party to a session.
ピア：セッションへのエンドポイントアプリケーションパーティー。
Client: the peer responsible for initiating a session.
クライアント：セッションを開始する責任があるピア。
Server: the peer responsible for responding to a session initiation.
サーバー：セッション開始への応答を担当するピア。
This section contains brief transport and security descriptions of various security protocols currently used to protect data being sent over a network. These protocols are grouped based on where in the protocol stack they are implemented, which influences which parts of a packet they protect: Generic application payload, application payload for specific application-layer protocols, both application payload and transport headers, or entire IP packets.
このセクションでは、ネットワーク経由で送信されているデータを保護するために現在使用されているさまざまなセキュリティプロトコルの簡単なトランスポートとセキュリティの説明が含まれています。これらのプロトコルは、それらが実装されている場所にある場所に基づいてグループ化されています。
Note that not all security protocols can be easily categorized, e.g., as some protocols can be used in different ways or in combination with other protocols. One major reason for this is that channel security protocols often consist of two components:
すべてのセキュリティプロトコルを簡単に分類できるわけではありません。たとえば、いくつかのプロトコルをさまざまな方法で、または他のプロトコルと組み合わせて使用できることに注意してください。これの1つの主な理由は、チャネルセキュリティプロトコルがしばしば2つのコンポーネントで構成されていることです。
* A handshake protocol, which is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys.
* ハンドシェイクプロトコル。パラメータの交渉、エンドポイントの認証、および共有キーの確立の責任があります。
* A record protocol, which is used to encrypt traffic using keys and parameters provided by the handshake protocol.
* handshakeプロトコルによって提供されるキーとパラメータを使用してトラフィックを暗号化するために使用されるレコードプロトコル。
For some protocols, such as tcpcrypt, these two components are tightly integrated. In contrast, for IPsec, these components are implemented in separate protocols: AH and the Encapsulating Security Payload (ESP) are record protocols, which can use keys supplied by the handshake protocol Internet Key Exchange Protocol Version 2 (IKEv2), by other handshake protocols, or by manual configuration. Moreover, some protocols can be used in different ways: While the base TLS protocol as defined in [RFC8446] has an integrated handshake and record protocol, TLS or DTLS can also be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake protocol can be used with a separate record layer, as in QUIC [QUIC-TRANSPORT].
TCPCRYPTなどのプロトコルによっては、これら2つのコンポーネントがしっかりと統合されています。対照的に、IPsecの場合、これらのコンポーネントは別々のプロトコルで実装されています.Ahとカプセル化セキュリティペイロード（ESP）は、ハンドシェイクプロトコルインターネットExchange Protocol Version 2（IKEv2）によって提供される鍵（IKEv2）、他のハンドシェイクプロトコルによって提供されるレコードプロトコルです。、または手動構成で。さらに、いくつかのプロトコルをさまざまな方法で使用できます。[RFC8446]で定義されている基本TLSプロトコルには、統合ハンドシェイクとレコードプロトコルがありますが、DTLS-SRTPのように、他のプロトコルのキーをネゴシエートするためにTLSまたはDTLSも使用できます。またはQuic-transportの場合のように、ハンドシェイクプロトコルを別のレコードレイヤーで使用できます。
The following protocols provide security that protects application payloads sent over a transport. They do not specifically protect any headers used for transport-layer functionality.
次のプロトコルは、トランスポートを介して送信されたアプリケーションペイロードを保護するセキュリティを提供します。それらは、トランスポート層の機能に使用されるヘッダーを特に保護しません。
TLS (Transport Layer Security) [RFC8446] is a common protocol used to establish a secure session between two endpoints. Communication over this session prevents "eavesdropping, tampering, and message forgery." TLS consists of a tightly coupled handshake and record protocol. The handshake protocol is used to authenticate peers, negotiate protocol options such as cryptographic algorithms, and derive session-specific keying material. The record protocol is used to marshal and, once the handshake has sufficiently progressed, encrypt data from one peer to the other. This data may contain handshake messages or raw application data.
TLS（トランスポート層セキュリティ）[RFC8446]は、2つのエンドポイント間で安全なセッションを確立するために使用される一般的なプロトコルです。このセッションのコミュニケーションは、「盗聴、改ざん、そしてメッセージの偽造」を防ぎます。TLSは、厳密に結合されたハンドシェイクと記録プロトコルで構成されています。ハンドシェイクプロトコルは、ピアを認証するために使用され、暗号化アルゴリズムなどのプロトコルオプションをネゴシエートし、セッション固有のキーイングマテリアを導出します。レコードプロトコルは整列化するために使用され、ハンドシェイクが十分に進行したら、1つのピアから他方のピアへデータを暗号化します。このデータは、ハンドシェイクメッセージまたは生のアプリケーションデータを含み得る。
DTLS (Datagram Transport Layer Security) [RFC6347] [DTLS-1.3] is based on TLS, but differs in that it is designed to run over unreliable datagram protocols like UDP instead of TCP. DTLS modifies the protocol to make sure it can still provide equivalent security guarantees to TLS with the exception of order protection/non-replayability. DTLS was designed to be as similar to TLS as possible, so this document assumes that all properties from TLS are carried over except where specified.
DTLS（データグラムトランスポート層セキュリティ）[RFC6347] [DTLS-1.3]はTLSに基づいていますが、TCPの代わりにUDPのような信頼性の低いデータグラムプロトコルを実行するように設計されているという点で異なります。DTLSは、注文保護/非再生可能性を除いて、TLSに同等のセキュリティ保証を提供できることを確認するためにプロトコルを変更します。DTLSはできるだけTLSに似ているように設計されているため、このドキュメントでは、指定された場所を除いて、TLSのすべてのプロパティが経過していると想定しています。
The following protocols provide application-specific security by protecting application payloads used for specific use cases. Unlike the protocols above, these are not intended for generic application use.
次のプロトコルは、特定のユースケースに使用されるアプリケーションペイロードを保護することによって、アプリケーション固有のセキュリティを提供します。上記のプロトコルとは異なり、これらは一般的なアプリケーションの使用を目的としていません。
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a record layer only, and requires a separate handshake protocol to provide key agreement and identity management.
Secure RTP（SRTP）は、RTPデータパケットとRTP制御プロトコル（RTCP）パケットの機密保持、メッセージ認証、および再生保護を提供するRTPのプロファイルです[RFC3711]。SRTPはレコードレイヤーのみを提供し、キー契約およびID管理を提供するために別々のハンドシェイクプロトコルを必要とします。
The commonly used handshake protocol for SRTP is DTLS, in the form of DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates the use of SRTP as the record layer and describes how to export keys for use with SRTP.
SRTPの一般的に使用されているハンドシェイクプロトコルはDTLSで、DTLS-SRTP [RFC5764]の形式です。これは、SRTPの使用をレコードレイヤとしてネゴシエートするDTLの拡張機能であり、SRTPで使用するためのキーをエクスポートする方法を説明します。
ZRTP [RFC6189] is an alternative key agreement and identity management protocol for SRTP. ZRTP Key agreement is performed using a Diffie-Hellman key exchange that runs on the media path. This generates a shared secret that is then used to generate the master key and salt for SRTP.
Zrtp [RFC6189]は、SRTPの代替鍵合意およびID管理プロトコルです。ZRTPキー契約は、メディアパス上で実行されるDiffie-Hellman鍵交換を使用して実行されます。これにより、SRTP用のマスターキーとSALTを生成するために使用される共有秘密が生成されます。
The following security protocols provide protection for both application payloads and headers that are used for Transport Services.
次のセキュリティプロトコルは、トランスポートサービスに使用されるアプリケーションペイロードとヘッダーの両方を保護します。
QUIC is a new standards-track transport protocol that runs over UDP, loosely based on Google's original proprietary gQUIC protocol [QUIC-TRANSPORT] (See Section 3.3.2 for more details). The QUIC transport layer itself provides support for data confidentiality and integrity. This requires keys to be derived with a separate handshake protocol. A mapping for QUIC of TLS 1.3 [QUIC-TLS] has been specified to provide this handshake.
QUICは、Googleの独自の独自のGQUICプロトコル[QUIC-Transport]に基づいて、UDPを介して実行される新しい標準トラックトランスポートプロトコルです（詳細については、セクション3.3.2を参照）。QUICトランスポート層自体は、データの機密性と完全性をサポートします。これには、鍵が別のハンドシェイクプロトコルで派生する必要があります。このハンドシェイクを提供するために、TLS 1.3 [QUIC-TLS]のQUICのマッピングが指定されています。
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol designed and deployed by Google following experience from deploying SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally known as "QUIC"; this document uses gQUIC to unambiguously distinguish it from the standards-track IETF QUIC. The proprietary technical forebear of IETF QUIC, gQUIC was originally designed with tightly integrated security and application data transport protocols.
Google QUIC（Goquic）は、SPDYの展開から、独自の先行者へのhttp / 2の展開から、Googleの後にデザインされ展開されたUDPベースの多重化ストリーミングプロトコルです。GQUICはもともと「QUIC」として知られていました。この資料はGROCICを使用して標準トラックのIETF QUICと明白に区別します。IETF QUICの独自の技術的な先見は、もともと厳密に統合されたセキュリティとアプリケーションのデータ転送プロトコルで設計されていました。
Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for opportunistic encryption. Applications may use tcpcrypt's unique session ID for further application-level authentication. Absent this authentication, tcpcrypt is vulnerable to active attacks.
TCPCRYPT [RFC8548]は、日和見論的暗号化のためのTCPプロトコルへの軽量拡張です。アプリケーションは、さらにアプリケーションレベルの認証のためにTCPCryptの一意のセッションIDを使用することがあります。この認証を欠席して、TCPCryptはアクティブな攻撃に対して脆弱です。
MinimaLT [MinimaLT] is a UDP-based transport security protocol designed to offer confidentiality, mutual authentication, DoS prevention, and connection mobility. One major goal of the protocol is to leverage existing protocols to obtain server-side configuration information used to more quickly bootstrap a connection. MinimaLT uses a variant of TCP's congestion control algorithm.
Minimalt [MinimalT]は、機密性、相互認証、DOS防止、および接続移動度を提供するように設計されたUDPベースのトランスポートセキュリティプロトコルです。プロトコルの1つの主な目的は、既存のプロトコルを活用して、接続をより迅速にブートストラップするために使用されるサーバーサイド構成情報を取得することです。MinimaltはTCPの輻輳制御アルゴリズムの変形を使用します。
CurveCP [CurveCP] is a UDP-based transport security that, unlike many other security protocols, is based entirely upon public key algorithms. CurveCP provides its own reliability for application data as part of its protocol.
CURVECP [curvecp]は、他の多くのセキュリティプロトコルとは異なり、完全に公開鍵アルゴリズムに基づいているUDPベースのトランスポートセキュリティです。Curvecpは、そのプロトコルの一部としてアプリケーションデータの独自の信頼性を提供します。
The following protocols provide protection for IP packets. These are generally used as tunnels, such as for Virtual Private Networks (VPNs). Often, applications will not interact directly with these protocols. However, applications that implement tunnels will interact directly with these protocols.
次のプロトコルはIPパケットの保護を提供します。これらは一般に、仮想プライベートネットワーク（VPN）などのトンネルとして使用されます。多くの場合、アプリケーションはこれらのプロトコルと直接対話しません。ただし、トンネルを実装するアプリケーションはこれらのプロトコルと直接対話します。
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either for creating tunnels (tunnel-mode) or for direct transport connections (transport-mode). This suite of protocols separates out the key generation protocol (IKEv2) from the transport encryption protocol (ESP). Each protocol can be used independently, but this document considers them together, since that is the most common pattern.
IKEV2 [RFC7296]およびESP [RFC4303]は、トンネル（トンネルモード）または直接トランスポート接続（トランスポートモード）の場合、IPパケットを暗号化および認証する最新のIPSecプロトコルスイートを形成します。このプロトコルのスイートは、トランスポート暗号化プロトコル（ESP）からキー生成プロトコル（IKEv2）を分離します。各プロトコルは独立して使用できますが、このドキュメントはそれらをまとめて考慮していますが、それが最も一般的なパターンです。
WireGuard [WireGuard] is an IP-layer protocol designed as an alternative to IPsec for certain use cases. It uses UDP to encapsulate IP datagrams between peers. Unlike most transport security protocols, which rely on Public Key Infrastructure (PKI) for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out of band, each of which is bound to one or more IP addresses. Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility.
Wireguard [WireGuard]は、特定のユースケースのためのIPSecの代わりとして設計されたIP層プロトコルです。それはudpを使ってピア間のIPデータグラムをカプセル化します。ピア認証のための公開鍵インフラストラクチャ（PKI）に依存するほとんどのトランスポートセキュリティプロトコルとは異なり、Wireguardは帯域外に配信された事前共有公開鍵を使用してピアを認証し、それぞれが1つ以上のIPアドレスにバインドされます。さらに、VPNSに適したプロトコルとして、Wireguardは拡張性、交渉、または暗号化の敏捷性を提供しません。
OpenVPN [OpenVPN] is a commonly used protocol designed as an alternative to IPsec. A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports. OpenVPN encapsulates either IP packets or Ethernet frames within a secure tunnel and can run over either UDP or TCP. For key establishment, OpenVPN can either use TLS as a handshake protocol or use pre-shared keys.
OpenVPN [OpenVPN]は、IPsecの代わりとして設計された一般的に使用されるプロトコルです。このプロトコルの主な目的は、さまざまなトランスポートを設定して動作するのが簡単なVPNを提供することです。OpenVPNは、セキュアトンネル内のIPパケットまたはイーサネットフレームをカプセル化し、UDPまたはTCPのどちらでも実行できます。重要な確立のために、OpenVPNはハンドシェイクプロトコルとしてTLSを使用するか、または事前共有キーを使用することができます。
Across the different security protocols listed above, the primary dependency on transport protocols is the presentation of data: either an unbounded stream of bytes, or framed messages. Within protocols that rely on the transport for message framing, most are built to run over transports that inherently provide framing, like UDP, but some also define how their messages can be framed over byte-stream transports.
上記のさまざまなセキュリティプロトコルを越えて、トランスポートプロトコルへの主な依存関係はデータの表示です。無制限のバイトストリーム、またはフレームメッセージ。メッセージフレーミングのトランスポートに依存するプロトコル内では、ほとんどの場合、UDPのようなフレーミングを本質的に提供するトランスポートを実行するために構築されていますが、一部のメッセージもバイトストリームトランスポートを介してそれらのメッセージをフレーム化できる方法を定義します。
The following protocols all depend upon running on a transport protocol that provides a reliable, in-order stream of bytes. This is typically TCP.
次のプロトコルはすべて、信頼性の高い、順序のバイトのストリームを提供するトランスポートプロトコル上で実行されます。これは通常TCPです。
Application Payload Security Protocols:
アプリケーションペイロードセキュリティプロトコル：
* TLS
* TLS
Transport-Layer Security Protocols:
トランスポート層セキュリティプロトコル：
* tcpcrypt
* tcpcrypt.
The following protocols all depend on the transport protocol to provide message framing to encapsulate their data. These protocols are built to run using UDP, and thus do not have any requirement for reliability. Running these protocols over a protocol that does provide reliability will not break functionality but may lead to multiple layers of reliability if the security protocol is encapsulating other transport protocol traffic.
以下のプロトコルはすべて、データをカプセル化するためのメッセージフレーミングを提供するためのトランスポートプロトコルに依存します。これらのプロトコルはUDPを使用して実行されるように構築されているため、信頼性の要件はありません。信頼性を提供するプロトコルを介してこれらのプロトコルを実行すると機能性がありませんが、セキュリティプロトコルが他のトランスポートプロトコルトラフィックをカプセル化している場合は、複数層の信頼性につながる可能性があります。
Application Payload Security Protocols:
アプリケーションペイロードセキュリティプロトコル：
* DTLS
* DTLS
* ZRTP
* Zrtp.
* SRTP
* SRTP.
Transport-Layer Security Protocols:
トランスポート層セキュリティプロトコル：
* QUIC
* 寡黙の
* MinimaLT
* ミニマルタ
* CurveCP
* cur cur
Packet Security Protocols:
パケットセキュリティプロトコル：
* IPsec
* IPsec.
* WireGuard
* wireguard
* OpenVPN
* openvpn
Of the protocols listed above that depend on the transport for message framing, some do have well-defined mappings for sending their messages over byte-stream transports like TCP.
メッセージフレーミングのためのトランスポートに依存する上記のプロトコルのうち、いくつかはTCPのようなバイトストリームトランスポートを介してメッセージを送信するための明確に定義されたマッピングを持ちます。
Application Payload Security Protocols:
アプリケーションペイロードセキュリティプロトコル：
* DTLS when used as a handshake protocol for SRTP [RFC7850]
* SRTPのハンドシェイクプロトコルとして使用した場合のDTLS [RFC7850]
* ZRTP [RFC6189]
* Zrtp [RFC6189]
* SRTP [RFC4571][RFC3711]
* SRTP [RFC4571] [RFC3711]
Packet Security Protocols:
パケットセキュリティプロトコル：
* IPsec [RFC8229]
* IPsec [RFC8229]
One protocol surveyed, tcpcrypt, has a direct dependency on a feature in the transport that is needed for its functionality. Specifically, tcpcrypt is designed to run on top of TCP and uses the TCP Encryption Negotiation Option (TCP-ENO) [RFC8547] to negotiate its protocol support.
調査された1つのプロトコル、TCPCRYPTは、その機能に必要なトランスポート内の機能に直接依存しています。具体的には、TCPCRYPTはTCPの上で実行され、TCP暗号化ネゴシエーションオプション（TCP-ENO）[RFC8547]を使用してプロトコルサポートをネゴシエートします。
QUIC, CurveCP, and MinimaLT provide both transport functionality and security functionality. They depend on running over a framed protocol like UDP, but they add their own layers of reliability and other Transport Services. Thus, an application that uses one of these protocols cannot decouple the security from transport functionality.
QUIC、CURVECP、およびMinimalTは、トランスポート機能とセキュリティ機能の両方を提供します。それらはUDPのようなフレーム化されたプロトコルの上で実行されることに依存しますが、それらは自分の信頼性やその他のトランスポートサービスを追加します。したがって、これらのプロトコルのいずれかを使用するアプリケーションは、セキュリティをトランスポート機能から切り離すことはできません。
This section describes the interface exposed by the security protocols described above. We partition these interfaces into pre-connection (configuration), connection, and post-connection interfaces, following conventions in [TAPS-INTERFACE] and [TAPS-ARCH].
このセクションでは、上記のセキュリティプロトコルによって公開されているインターフェースについて説明します。これらのインタフェースを接続前（設定）、接続、および接続後のインターフェイスに分割し、[TAPS-Interface]と[Taps-Arch]の規則に従ってください。
Note that not all protocols support each interface. The table in Section 5.4 summarizes which protocol exposes which of the interfaces. In the following sections, we provide abbreviations of the interface names to use in the summary table.
すべてのプロトコルが各インタフェースをサポートしているわけではないことに注意してください。セクション5.4のテーブルは、どのプロトコルがどのインターフェースを公開するかを要約しています。次のセクションでは、サマリテーブルで使用するインターフェイス名の略語を提供します。
Configuration interfaces are used to configure the security protocols before a handshake begins or keys are negotiated.
ハンドシェイクが始まる前にセキュリティプロトコルを設定するために、コンフィギュレーションインタフェースを使用します。
Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or mechanisms to access these, to the security protocol to use during handshakes.
アイデンティティと秘密鍵（IPK）：アプリケーションは、そのID、認証情報（例えば、証明書）、および秘密鍵、またはこれらにアクセスするメカニズムを、ハンドシェイク中に使用するためのセキュリティプロトコルに提供できます。
* TLS
* TLS
* DTLS
* DTLS
* ZRTP
* Zrtp.
* QUIC
* 寡黙の
* MinimaLT
* ミニマルタ
* CurveCP
* cur cur
* IPsec
* IPsec.
* WireGuard
* wireguard
* OpenVPN
* openvpn
Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) (ALG): The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites.
サポートされているアルゴリズム（鍵交換、署名、および直交スイート）（ALG）：アプリケーションは、鍵交換、シグネチャ、および直交スイートでサポートされているアルゴリズムを選択できます。
* TLS
* TLS
* DTLS
* DTLS
* ZRTP
* Zrtp.
* QUIC
* 寡黙の
* tcpcrypt
* tcpcrypt.
* MinimaLT
* ミニマルタ
* IPsec
* IPsec.
* OpenVPN
* openvpn
Extensions (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as Application-Layer Protocol Negotiation (ALPN) [RFC7301].
Extensions（ext）：アプリケーションは、アプリケーション層プロトコルネゴシエーション（ALPN）[RFC7301]など、セキュリティプロトコルによってネゴシエートされるべき拡張機能を有効または構成します。
* TLS
* TLS
* DTLS
* DTLS
* QUIC
* 寡黙の
Session Cache Management (CM): The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session.
セッションキャッシュ管理（cm）：アプリケーションは、セキュリティセッションを再開するために使用される可能性があるセッション状態（チケット、キーイングの資料、サーバーパラメータなど）を保存および取得する機能を提供します。
* TLS
* TLS
* DTLS
* DTLS
* ZRTP
* Zrtp.
* QUIC
* 寡黙の
* tcpcrypt
* tcpcrypt.
* MinimaLT
* ミニマルタ
Authentication Delegation (AD): The application provides access to a separate module that will provide authentication, using the Extensible Authentication Protocol (EAP) [RFC3748] for example.
認証委任（AD）：アプリケーションは、拡張認証プロトコル（EAP）[RFC3748]を使用して、認証を提供する別のモジュールへのアクセスを提供します。
* IPsec
* IPsec.
* tcpcrypt
* tcpcrypt.
Pre-Shared Key Import (PSKI): Either the handshake protocol or the application directly can supply pre-shared keys for use in encrypting (and authenticating) communication with a peer.
事前共有キーのインポート（PSKI）：ハンドシェイクプロトコルまたはアプリケーションは、ピアとの暗号化（および認証）通信で使用するための事前共有キーを直接供給できます。
* TLS
* TLS
* DTLS
* DTLS
* ZRTP
* Zrtp.
* QUIC
* 寡黙の
* tcpcrypt
* tcpcrypt.
* MinimaLT
* ミニマルタ
* IPsec
* IPsec.
* WireGuard
* wireguard
* OpenVPN
* openvpn
Identity Validation (IV): During a handshake, the security protocol will conduct identity validation of the peer. This can offload validation or occur transparently to the application.
ID検証（IV）：ハンドシェイク中に、セキュリティプロトコルはピアのID検証を行います。これは検証をオフロードするか、アプリケーションに透過的に発生する可能性があります。
* TLS
* TLS
* DTLS
* DTLS
* ZRTP
* Zrtp.
* QUIC
* 寡黙の
* MinimaLT
* ミニマルタ
* CurveCP
* cur cur
* IPsec
* IPsec.
* WireGuard
* wireguard
* OpenVPN
* openvpn
Source Address Validation (SAV): The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data. This involves sending a cookie exchange to avoid DoS attacks. (This list omits protocols that depend on TCP and therefore implicitly perform SAV.)
送信元アドレス検証（SAV）：ハンドシェイクプロトコルは、トランスポートプロトコルまたはアプリケーションと対話して、データを送信したリモートピアのアドレスを検証することができます。これには、DOS攻撃を避けるためにクッキー交換を送信することが含まれます。（このリストはTCPに依存し、暗黙的にSAVを実行するプロトコルを省略します。）
* DTLS
* DTLS
* QUIC
* 寡黙の
* IPsec
* IPsec.
* WireGuard
* wireguard
Connection Termination (CT): The security protocol may be instructed to tear down its connection and session information. This is needed by some protocols, e.g., to prevent application data truncation attacks in which an attacker terminates an underlying insecure connection-oriented protocol to terminate the session.
接続終了（CT）：セキュリティプロトコルは、その接続およびセッション情報を引き下げるように指示されてもよい。これは、例えば、攻撃者が基礎となる不安定な接続指向プロトコルを終了してセッションを終了するアプリケーションデータの切り捨て攻撃を防ぐために、いくつかのプロトコルによって必要とされる。
* TLS
* TLS
* DTLS
* DTLS
* ZRTP
* Zrtp.
* QUIC
* 寡黙の
* tcpcrypt
* tcpcrypt.
* MinimaLT
* ミニマルタ
* IPsec
* IPsec.
* OpenVPN
* openvpn
Key Update (KU): The handshake protocol may be instructed to update its keying material, either by the application directly or by the record protocol sending a key expiration event.
キーアップデート（ku）：handshakeプロトコルは、アプリケーションによって直接または鍵の有効期限イベントを送信するレコードプロトコルによって、キーイングプロトコルを更新するように指示されます。
* TLS
* TLS
* DTLS
* DTLS
* QUIC
* 寡黙の
* tcpcrypt
* tcpcrypt.
* MinimaLT
* ミニマルタ
* IPsec
* IPsec.
Shared Secret Key Export (SSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific uses.
共有シークレットキーエクスポート（SSKE）：ハンドシェイクプロトコルは、アプリケーション固有の用途に共有秘密を生成するためのインタフェースを提供することがあります。
* TLS
* TLS
* DTLS
* DTLS
* tcpcrypt
* tcpcrypt.
* IPsec
* IPsec.
* OpenVPN
* openvpn
* MinimaLT
* ミニマルタ
Key Expiration (KE): The record protocol can signal that its keys are expiring due to reaching a time-based deadline or a use-based deadline (number of bytes that have been encrypted with the key). This interaction is often limited to signaling between the record layer and the handshake layer.
キーの有効期限（KE）：レコードプロトコルは、時間ベースの期限または使用ベースの期限（キーで暗号化されたバイト数）に達するため、そのキーが期限切れになっていることを通知できます。この相互作用は、記録層とハンドシェイク層との間のシグナリングに限定されることが多い。
* IPsec
* IPsec.
Mobility Events (ME): The record protocol can be signaled that it is being migrated to another transport or interface due to connection mobility, which may reset address and state validation and induce state changes such as use of a new Connection Identifier (CID).
モビリティイベント（ME）：レコードプロトコルは、接続モビリティのために別のトランスポートまたはインタフェースに移行されていることを通知することができ、これはアドレスと状態検証をリセットし、新しい接続識別子（CID）の使用などの状態変化を誘発する可能性があります。
* DTLS (version 1.3 only [DTLS-1.3])
* DTLS（バージョン1.3のみ[DTLS-1.3]]）
* QUIC
* 寡黙の
* MinimaLT
* ミニマルタ
* CurveCP
* cur cur
* IPsec [RFC4555]
* IPsec [RFC4555]
* WireGuard
* wireguard
The following table summarizes which protocol exposes which interface.
次の表は、どのプロトコルがどのインターフェイスを公開するかを要約しています。
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
| Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| SSKE |KE|ME|
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
| TLS | x | x | x |x | | x |x | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| DTLS | x | x | x |x | | x |x | x |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| ZRTP | x | x | |x | | x |x | |x | | | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| QUIC | x | x | x |x | | x |x | x |x |x | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| tcpcrypt | | x | |x |x | x | | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| MinimaLT | x | x | |x | | x |x | |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| CurveCP | x | | | | | |x | | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| IPsec | x | x | | |x | x |x | x |x |x | x |x |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| WireGuard | x | | | | | x |x | x | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| OpenVPN | x | x | | | | x |x | |x | | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
Table 1
表1
x = Interface is exposed (blank) = Interface is not exposed
X =インターフェイスが公開されています（空白）=インターフェースが公開されていません
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document summarizes existing transport security protocols and their interfaces. It does not propose changes to or recommend usage of reference protocols. Moreover, no claims of security and privacy properties beyond those guaranteed by the protocols discussed are made. For example, metadata leakage via timing side channels and traffic analysis may compromise any protocol discussed in this survey. Applications using Security Interfaces should take such limitations into consideration when using a particular protocol implementation.
この文書は既存のトランスポートセキュリティプロトコルとそのインタフェースをまとめたものです。参照プロトコルへの変更を提案したり推奨したりすることはありません。さらに、議論されたプロトコルによって保証されているものを超えたセキュリティおよびプライバシーの特性の主張は行われません。たとえば、タイミングサイドチャネルとトラフィック分析によるメタデータ漏洩と、この調査で説明したプロトコルも妥協する可能性があります。セキュリティインターフェイスを使用しているアプリケーションは、特定のプロトコル実装を使用する場合にそのような制限を考慮に入れる必要があります。
Analysis of how features improve or degrade privacy is intentionally omitted from this survey. All security protocols surveyed generally improve privacy by using encryption to reduce information leakage. However, varying amounts of metadata remain in the clear across each protocol. For example, client and server certificates are sent in cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 [RFC8446]. A survey of privacy features, or lack thereof, for various security protocols could be addressed in a separate document.
この調査からの特徴をどのように改善または劣化させるかの分析は、この調査から意図的に省略されています。調査対象のすべてのセキュリティプロトコルは、一般に、情報漏洩を減らすために暗号化を使用することによってプライバシーを向上させます。ただし、さまざまな金額のメタデータは、各プロトコル全体では明確になります。たとえば、クライアント証明書とサーバーの証明書はTLS 1.2 [RFC5246]のClearTextで送信されますが、TLS 1.3 [RFC8446]で暗号化されています。さまざまなセキュリティプロトコルのためのプライバシー機能、またはその欠如の調査は、別の文書で対処することができます。
[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, B., and J. Boeuf, "Application Layer Transport Security", <https://cloud.google.com/security/encryption-in-transit/ application-layer-transport-security/>.
[ALTS] Ghali、C、StubbleField、A.、Knapp、E.、Li、J.、Schmidt、B.、J.Boeuf、「アプリケーション層輸送セキュリティ」、<https：//cloud.google.com/セキュリティ/暗号化/輸送/ application-layer-transport-security />。
[CurveCP] Bernstein, D., "CurveCP: Usable security for the Internet", <https://curvecp.org/>.
[curvecp] Bernstein、D.、 "Curvecp：インターネットのための使用可能なセキュリティ"、<https://curvecp.org/>。
[DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-38, 29 May 2020, <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.
[DTLS-1.3] Rescorla、E.、Tschofenig、H.、およびN. ModAdugu、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-DTLS13-2020年5月38日、<https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>。
[MinimaLT] Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and T. Lange, "MinimaLT: minimal-latency networking through better security", DOI 10.1145/2508859.2516737, <https://dl.acm.org/citation.cfm?id=2516737>.
[MinimalT] Petullo、W.、Zhang、X.、Solworth、J.、Bernstein、D.、T. Lange、「Minimalt：より良いセキュリティによる最小待ち時間ネットワーキング」、DOI 10.1145 / 2508859.2516737、<https：//dl.acm.org/catute.cfm?id=2516737>。
[OpenVPN] OpenVPN, "OpenVPN cryptographic layer", <https://openvpn.net/community-resources/openvpn-cryptographic-layer/>.
[OpenVPN] OpenVPN、 "OpenVPN暗号レイヤ"、<https://openvpn.net/community-Resources/OpenVPN-Cryptographic-Layer/>。
[QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-tls-31, 24 September 2020, <https://tools.ietf.org/html/draft-ietf-quic-tls-31>.
[QUIC-TLS] Thomson、M.およびS. Turner、「QUICをセキュリティを確保するためのTLSの使用」、インターネットドラフト、ドラフト-IETF-QUIC-TLS-31,24 9月24日、<https：//ツール.ietf.org / html / draft-ietf-quic-tls-31>。
[QUIC-TRANSPORT] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-31, 24 September 2020, <https://tools.ietf.org/html/draft-ietf-quic-transport-31>.
[QUIC-Transport] Iyngar、J.およびM. Thomson、「QUIC：UDPベースの多重化および安全な輸送」、進行中の作業、インターネットドラフト、ドラフト-IETF-Quic-Transport-31,24 9月24日、<https://tools.ietf.org/html/draft-ietf-quic-transport-31>。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2385] HEFFERNAN、A。、「TCP MD5シグネチャオプションによるBGPセッションの保護」、RFC 2385、DOI 10.17487 / RFC2385、1998年8月、<https://www.rfc-editor.org/info/rfc2385>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
[RFC2890] DOMMYTY、G、「GREおよびシーケンス番号拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<https://www.rfc-editor.org/info/rfc2890>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、H. Levkowetz、Ed。、「拡張認証プロトコル（EAP）」、RFC 3748、DOI 10.17487 / RFC3748、2004年6月<https://www.rfc-editor.org/info/rfc3748>。
[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、Ed。、「セキュアシェル（SSH）トランスポート層プロトコル」、RFC 4253、DOI 10.17487 / RFC4253、2006年1月、<https：//www.rfc-editor.org/ INFO / RFC4253>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302] Kent、S.、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https：//www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, <https://www.rfc-editor.org/info/rfc4555>.
[RFC4555] ERONEN、P、「IKEV2モビリティとマルチホームプロトコル（Mobike）」、RFC 4555、DOI 10.17487 / RFC4555、2006年6月、<https：//www.rfc-editor.org/info/rfc4555>。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <https://www.rfc-editor.org/info/rfc4571>.
[RFC4571] Lazzaro、J.、「リアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）およびRFC 4571、RFC 4571、DOI 10.17487 / RFC4571、2006年7月、<https：// www.rfc-editor.org / info / rfc4571>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https：//www.rfc-editor.org/info/ RFC5246>。
[RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", RFC 5641, DOI 10.17487/RFC5641, August 2009, <https://www.rfc-editor.org/info/rfc5641>.
[RFC5641] McGill、N.およびC. Pignataro、 "Layer 2 Tunneling Protocol Version 3（L2TPv3）拡張回路状態値"、RFC 5641、DOI 10.17487 / RFC5641、2009年8月、<https：//www.rfc-編集者。ORG / INFO / RFC5641>。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764] MCGREW、D.およびE. RESCORLA、セキュアリアルタイムトランスポートプロトコル（SRTP） "、RFC 5764、DOI 10.17487 / RFC5764、2010年5月、<HTTPS）：//www.rfc-editor.org/info/rfc5764>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info/ RFC5925>。
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, <https://www.rfc-editor.org/info/rfc6189>.
[RFC6189] Zimmermann、P.、Johnston、A.、ED。、およびJ.Callas、 "Zrtp：ユニキャストセキュアRTPのメディアパスキー契約RFC 6189、DOI 10.17487 / RFC6189、2011年4月、<https：//www.rfc-editor.org/info/rfc6189>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] RESCORLA、E.およびN. MODADUGU、「データグラムトランスポートレイヤセキュリティバージョン1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https：//www.rfc-editor.org/info/rfc6347>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、NIR、Y.、Eronen、P.、およびT.Kivinen、「インターネットキー交換プロトコル版2（IKEV2）」、STD 79、RFC 7296、DOI 10.17487 / RFC72962014年10月、<https：//www.rfc-editor.org/info/rfc7296>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A.、およびE.Stethan、「トランスポート層セキュリティ（TLS）アプリケーション層プロトコルネゴシエーション拡張」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, <https://www.rfc-editor.org/info/rfc7850>.
[RFC7850] Nandakumar、S。、「SDP 'Protoの値の登録は、様々なRTPプロファイルの下でTCPを介したRTPメディアを輸送するための値の登録」、RFC 7850、DOI 10.17487 / RFC7850、2016年4月、<https：//www.rfc-editor.org/info/rfc7850>。
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.
[RFC8095] Fairhurst、G.、Ed。、Trammell、B.、Ed。、およびM.Kuehlewind、ED。、「IETFトランスポートプロトコルと輻輳制御メカニズムによるサービス」、RFC 8095、DOI 10.17487 / RFC8095、2017年3月<https：//www.rfc-editor.org/info/rfc8095>。
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8229] Pouly、T.、Touati、S.、R. Mantha、「IPSとIPsecパケットのTCPカプセル化」、RFC 8229、DOI 10.17487 / RFC8229、2017年8月、<https：//www.rfc-編集者。ORG / INFO / RFC8229>。
[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>。
[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, DOI 10.17487/RFC8547, May 2019, <https://www.rfc-editor.org/info/rfc8547>.
[RFC8547] Bittau、A.、Giffin、D.、Handley、M.、Mazieres、D.、およびE.Smith、 "TCP-ENO：暗号化ネゴシエーションオプション"、RFC 8547、DOI 10.17487 / RFC8547、2019年5月、<https://www.rfc-editor.org/info/rfc8547>。
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, <https://www.rfc-editor.org/info/rfc8548>.
[RFC8548] Bittau、A.、Giffin、D.、Handley、M.、Mazieres、D.、Slack、Q.、およびE.Smith、「TCPストリームの暗号保護（TCPCRYPT）」、RFC 8548、DOI 10.17487 /RFC8548、2019年5月、<https：//www.rfc-editor.org/info/rfc8548>。
[TAPS-ARCH] Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P. S., and C. A. Wood, "An Architecture for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-08, 13 July 2020, <https://tools.ietf.org/html/draft-ietf-taps-arch-08>.
[タップアーチ] Pauly、T.、Trammell、B.、Brunstrom、A.、Fairhurst、G.、Perkins、C.、Tiesel、PS、およびCA Wood、「トランスポートサービスのためのアーキテクチャ」、進行中の作業2020年7月13日、<https://tools.ietf.org/html/draft-ietf-taps-ath-08>を通じて、インターネットドラフト、Draft-Ietf-Taps-Arch-08,13。
[TAPS-INTERFACE] Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., and T. Pauly, "An Abstract Application Layer Interface to Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-interface-09, 27 July 2020, <https://tools.ietf.org/html/draft-ietf-taps-interface-09>.
[TAPS-Interface] Trammell、B.、Welzl、M.、Enghardt、T.、FairHurst、G.、Kuehlewind、M.、Perkins、C、Tiesel、PS、Wood、CA、およびT. Pauly、 "抽象化サービスへの抽象的なアプリケーション層インタフェース2020年7月27日、<https://tools.ietf.org/html/draft-ietf.org/html/draft-ietf-taps-taps-Interface-09>。
[WireGuard] Donenfeld, J., "WireGuard: Next Generation Kernel Network Tunnel", <https://www.wireguard.com/papers/wireguard.pdf>.
[Wireguard] Donenfeld、J.、 "Wireguard：Next Generation Kernel Network Tunnel"、<https://www.wireguard.com/papers/wireguard.pdf>。
Acknowledgments
謝辞
The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja Kühlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for their input and feedback on this document.
著者らは、Bob Bradley、Frederic Jacobs、MirjaKühlewind、Yannick Sierra、Brian Trammell、およびMagnus westerlundに感謝します。
Authors' Addresses
著者の住所
Theresa Enghardt TU Berlin Marchstr. 23 10587 Berlin Germany
Theresa enghardt Tu Berlin Marchstr。23 10587ベルリンドイツ
Email: ietf@tenghardt.net
Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America
Tommy Pouly Apple Inc. 1アップアップルパークウェイCupertino、カリフォルニア州95014アメリカ合衆国
Email: tpauly@apple.com
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
Colin Perkins Glasgow大学コンピューティングサイエンスグラスゴーG12 8QQイギリス
Email: csp@csperkins.org
Kyle Rose Akamai Technologies, Inc. 150 Broadway Cambridge, MA 02144 United States of America
Kyle Rose Akamai Technologies、Inc。150 Broadway Cambridge、MA 02144アメリカ合衆国
Email: krose@krose.org
Christopher A. Wood Cloudflare 101 Townsend St San Francisco, United States of America
Christopher A. Wood CloudFlare 101 TownSend Stサンフランシスコ、アメリカ合衆国
Email: caw@heapingbits.net