RFC 9369 - QUIC Version 2

• ステータス: Proposed Standard
• 発行日: May 2023
• ストリーム: IETF
• エラッタ: エラッタなし

---

Abstract

This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.

このドキュメントでは QUIC バージョン 2 を規定します。これは、いくつかの些細な詳細を除いて QUIC バージョン 1 と同じです。その目的は、さまざまな固定化ベクトルに対抗し、バージョンネゴシエーションフレームワークを行使することです。また、QUIC の将来のバージョンにおける最小限の変更のテンプレートとしても機能します。

Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks.

「バージョン2」はこの提案の非公式な名前であり、Standards Track ドキュメントとして公開される QUIC の2番目のバージョンであることを示しています。ここで指定されるプロトコルは、固定化のリスクを最小限に抑えるために、ワイヤーイメージで2以外のバージョン番号を使用します。

Status of This Memo

This is an Internet Standards Track document.

これはインターネット標準化過程の文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティの総意を表しています。公開レビューを受け、Internet Engineering Steering Group (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/rfc9369.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9369 で入手できます。

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78 および IETF ドキュメントに関連する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション 4.e で説明されている改訂 BSD ライセンスのテキストが含まれている必要があり、改訂 BSD ライセンスで説明されているように保証なしで提供されます。

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. Differences with QUIC Version 1
• 4. Version Negotiation Considerations
• 5. TLS Resumption and NEW_TOKEN Tokens
• 6. Ossification Considerations
• 7. Applicability
• 8. Security Considerations
• 9. IANA Considerations
• 10. References
• Appendix A. Sample Packet Protection
• Acknowledgments
• Author's Address

1. Introduction

QUIC version 1 [QUIC] has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see [QUIC-INVARIANTS]). If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes that are usually 0x00000001.

QUIC バージョン 1 [QUIC] には、すべてのロングヘッダーの2番目から5番目のバイトを占めるバージョン番号など、多数の拡張ポイントがあります（[QUIC-INVARIANTS] を参照）。実験的なバージョンがまれであり、QUIC バージョン 1 が QUIC トラフィックの大部分を構成する場合、ミドルボックスが通常 0x00000001 であるバージョンバイトで固定化する可能性があります。

In QUIC version 1, Initial packets are encrypted with the version-specific salt, as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the version 1 key derivation and packet formats.

QUIC バージョン 1 では、[QUIC-TLS] のセクション 5.2 で説明されているように、初期パケットはバージョン固有のソルトで暗号化されます。このように初期パケットを保護することで、オブザーバーはその内容（TLS Client Hello または Server Hello メッセージを含む）を検査できます。ここでも、ミドルボックスがバージョン 1 の鍵導出およびパケット形式で固定化する可能性があります。

Finally, [QUIC-VN] describes two mechanisms endpoints can use to negotiate which QUIC version to select. The "incompatible" version negotiation method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round trip at the start of the connection. "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically.

最後に、[QUIC-VN] は、エンドポイントがどの QUIC バージョンを選択するかを交渉するために使用できる2つのメカニズムについて説明しています。「互換性のない」バージョンネゴシエーション方法は、接続の開始時に追加のラウンドトリップが発生する代わりに、任意の QUIC バージョンから他の任意のバージョンへの切り替えを完全に一般的にサポートできます。「互換性のある」バージョンネゴシエーションは、ラウンドトリップのペナルティを排除しますが、2つのバージョンが意味的にどれだけ異なるかについていくつかの制限を課します。

QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms. The changes provide an example of the minimum set of changes necessary to specify a new QUIC version. However, note that the choice of the version number on the wire is randomly chosen instead of "2", and the two bits that identify each Long Header packet type are different from version 1; both of these properties are meant to combat ossification and are not strictly required of a new QUIC version.

QUIC バージョン 2 は、固定化の懸念を軽減し、バージョンネゴシエーションメカニズムを行使することを目的としています。変更点は、新しい QUIC バージョンを指定するために必要な最小限の変更セットの例を提供します。ただし、ワイヤー上のバージョン番号の選択は「2」ではなくランダムに選択されており、各ロングヘッダーパケットタイプを識別する2つのビットはバージョン 1 とは異なることに注意してください。これらのプロパティはどちらも固定化に対抗するためのものであり、新しい QUIC バージョンに厳密に要求されるものではありません。

Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks.

2つのバージョンをサポートするエンドポイントは、ダウングレード攻撃を防ぐためにバージョンネゴシエーションを実装する必要があります。

2. Conventions

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] で説明されているように解釈されます。

3. Differences with QUIC Version 1

Except for a few differences, QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY]. The remainder of this section lists the differences.

いくつかの違いを除いて、QUIC バージョン 2 エンドポイントは、[QUIC]、[QUIC-TLS]、および [QUIC-RECOVERY] で説明されている QUIC バージョン 1 仕様を実装する必要があります。このセクションの残りの部分では、違いをリストします。

3.1. Version Field

The Version field of long headers is 0x6b3343cf. This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number".

ロングヘッダーの Version フィールドは 0x6b3343cf です。これは、"QUICv2 version number" の sha256sum の最初の4バイトを取得して生成されました。

3.2. Long Header Packet Types

All version 2 Long Header packet types are different. The Type field values are:

すべてのバージョン 2 ロングヘッダーパケットタイプは異なります。Type フィールドの値は次のとおりです。

• Initial: 0b01
• 0-RTT: 0b10
• Handshake: 0b11
• Retry: 0b00

3.3. Cryptography Changes

3.3.1. Initial Salt

The salt used to derive Initial keys in Section 5.2 of [QUIC-TLS] changes to:

[QUIC-TLS] のセクション 5.2 で初期鍵を導出するために使用されるソルトは、次のように変更されます。

initial_salt = 0x0dede3def700a6db819381be6e269dcbf9bd2ed9

This is the first 20 bytes of the sha256sum of "QUICv2 salt".

これは "QUICv2 salt" の sha256sum の最初の20バイトです。

3.3.2. HMAC-based Key Derivation Function (HKDF) Labels

The labels used in [QUIC-TLS] to derive packet protection keys (Section 5.1), header protection keys (Section 5.4), Retry Integrity Tag keys (Section 5.8), and key updates (Section 6.1) change from "quic key" to "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku" to meet the guidance for new versions in Section 9.6 of that document.

[QUIC-TLS] でパケット保護鍵（セクション 5.1）、ヘッダー保護鍵（セクション 5.4）、再試行整合性タグ鍵（セクション 5.8）、および鍵更新（セクション 6.1）を導出するために使用されるラベルは、そのドキュメントのセクション 9.6 の新しいバージョンに関するガイダンスを満たすために、"quic key" から "quicv2 key"、"quic iv" から "quicv2 iv"、"quic hp" から "quicv2 hp"、"quic ku" から "quicv2 ku" に変更されます。

3.3.3. Retry Integrity Tag

The key and nonce used for the Retry Integrity Tag (Section 5.8 of [QUIC-TLS]) change to:

再試行整合性タグ（[QUIC-TLS] のセクション 5.8）に使用される鍵とナンスは、次のように変更されます。

secret = 0xc4dd2484d681aefa4ff4d69c2c20299984a765a5d3c31982f38fc74162155e9f key = 0x8fb4b01b56ac48e260fbcbcead7ccc92 nonce = 0xd86969bc2d7c6d9990efb04a

The secret is the sha256sum of "QUICv2 retry secret". The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively.

シークレットは "QUICv2 retry secret" の sha256sum です。鍵とナンスは、それぞれラベル "quicv2 key" と "quicv2 iv" を使用してこのシークレットから導出されます。

4. Version Negotiation Considerations

QUIC version 2 is not intended to deprecate version 1. Endpoints that support version 2 might continue support for version 1 to maximize compatibility with other endpoints. In particular, HTTP clients often use Alt-Svc [RFC7838] to discover QUIC support. As this mechanism does not currently distinguish between QUIC versions, HTTP servers SHOULD support multiple versions to reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback. For example, an origin advertising support for "h3" in Alt-Svc should support QUIC version 1, as it was the original QUIC version used by HTTP/3; therefore, some clients will only support that version.

QUIC バージョン 2 は、バージョン 1 を廃止することを意図したものではありません。バージョン 2 をサポートするエンドポイントは、他のエンドポイントとの互換性を最大化するためにバージョン 1 のサポートを継続する場合があります。特に、HTTP クライアントは、QUIC サポートを検出するために Alt-Svc [RFC7838] をよく使用します。このメカニズムは現在 QUIC バージョンを区別しないため、HTTP サーバーは、非互換性の可能性と QUIC バージョンネゴシエーションまたは TCP フォールバックに関連するコストを削減するために、複数のバージョンをサポートする必要があります (SHOULD)。たとえば、Alt-Svc で "h3" のサポートをアドバタイズするオリジンは、HTTP/3 で使用される元の QUIC バージョンであるため、QUIC バージョン 1 をサポートする必要があります。したがって、一部のクライアントはそのバージョンのみをサポートします。

Any QUIC endpoint that supports QUIC version 2 MUST send, process, and validate the version_information transport parameter specified in [QUIC-VN] to prevent version downgrade attacks.

QUIC バージョン 2 をサポートするすべての QUIC エンドポイントは、バージョンダウングレード攻撃を防ぐために、[QUIC-VN] で指定された version_information トランスポートパラメータを送信、処理、および検証する必要があります (MUST)。

Note that version 2 meets the definition in [QUIC-VN] of a compatible version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip.

バージョン 2 は [QUIC-VN] におけるバージョン 1 との互換性のあるバージョンの定義を満たしており、バージョン 1 はバージョン 2 と互換性があることに注意してください。したがって、サーバーは互換性のあるネゴシエーションを使用して、2つのバージョン間で接続を切り替えることができます。両方のバージョンをサポートするエンドポイントは、ラウンドトリップを回避するために互換性のあるバージョンネゴシエーションをサポートする必要があります (SHOULD)。

4.1. Compatible Negotiation Requirements

Compatible version negotiation between versions 1 and 2 follows the same requirements in either direction. This section uses the terms "original version" and "negotiated version" from [QUIC-VN].

バージョン 1 と 2 の間の互換性のあるバージョンネゴシエーションは、どちらの方向でも同じ要件に従います。このセクションでは、[QUIC-VN] の用語「元のバージョン」と「ネゴシエートされたバージョン」を使用します。

If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions. The client MUST NOT use a different version in the subsequent Initial packet that contains the Retry token. The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched, to enforce client compliance.

サーバーが Retry パケットを送信する場合、元のバージョンを使用する必要があります (MUST)。クライアントは、他のバージョンを使用する Retry パケットを無視します。クライアントは、Retry トークンを含む後続の Initial パケットで異なるバージョンを使用してはなりません (MUST NOT)。サーバーは、クライアントがバージョンを切り替えなかったことを検証するために Retry トークンに QUIC バージョンをエンコードし、切り替えた場合はパケットをドロップして、クライアントのコンプライアンスを強制することができます (MAY)。

QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1. After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in Section 7.3 of [QUIC].

QUIC バージョン 2 は、Retry を認証するために QUIC バージョン 1 と同じトランスポートパラメータを使用します。Retry 後にネゴシエートされたバージョンに切り替えた後、サーバーは、[QUIC] のセクション 7.3 で説明されているように、サーバーが Retry を送信したこと、および交換で使用された接続 ID を検証するために、関連するトランスポートパラメータを含める必要があります (MUST)。

The server cannot send CRYPTO frames until it has processed the client's transport parameters. The server MUST send all CRYPTO frames using the negotiated version.

サーバーは、クライアントのトランスポートパラメータを処理するまで CRYPTO フレームを送信できません。サーバーは、ネゴシエートされたバージョンを使用してすべての CRYPTO フレームを送信する必要があります (MUST)。

The client learns the negotiated version by observing the first long header Version field that differs from the original version. If the client receives a CRYPTO frame from the server in the original version, it indicates that the negotiated version is equal to the original version.

クライアントは、元のバージョンとは異なる最初のロングヘッダー Version フィールドを観察することで、ネゴシエートされたバージョンを知ります。クライアントが元のバージョンでサーバーから CRYPTO フレームを受信した場合、ネゴシエートされたバージョンが元のバージョンと等しいことを示します。

Before the server is able to process transport parameters from the client, it might need to respond to Initial packets from the client. For these packets, the server uses the original version.

サーバーがクライアントからのトランスポートパラメータを処理できるようになる前に、クライアントからの Initial パケットに応答する必要がある場合があります。これらのパケットに対して、サーバーは元のバージョンを使用します。

Once the client has learned the negotiated version, it SHOULD send subsequent Initial packets using that version. The server MUST NOT discard its original version Initial receive keys until it successfully processes a Handshake packet with the negotiated version.

クライアントがネゴシエートされたバージョンを知ったら、そのバージョンを使用して後続の Initial パケットを送信する必要があります (SHOULD)。サーバーは、ネゴシエートされたバージョンで Handshake パケットを正常に処理するまで、元のバージョンの Initial 受信鍵を破棄してはなりません (MUST NOT)。

Both endpoints MUST send Handshake and 1-RTT packets using the negotiated version. An endpoint MUST drop packets using any other version. Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate such packets.

両方のエンドポイントは、ネゴシエートされたバージョンを使用して Handshake および 1-RTT パケットを送信する必要があります (MUST)。エンドポイントは、他のバージョンを使用するパケットをドロップする必要があります (MUST)。エンドポイントには、そのようなパケットを復号化または認証できるようにする鍵材料を生成する必要はありません。

The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can accept 0-RTT and then process 0-RTT packets from the original version.

クライアントは、サーバーからそのバージョンのパケットを処理した後でも、ネゴシエートされたバージョンを使用して 0-RTT パケットを送信してはなりません (MUST NOT)。サーバーは 0-RTT を受け入れてから、元のバージョンの 0-RTT パケットを処理できます。

5. TLS Resumption and NEW_TOKEN Tokens

TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them. Clients MUST NOT use a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, and vice versa. When a connection includes compatible version negotiation, any issued server tokens are considered to originate from the negotiated version, not the original one.

TLS セッションチケットと NEW_TOKEN トークンは、それらを提供した接続の QUIC バージョンに固有です。クライアントは、QUIC バージョン 1 接続からのセッションチケットまたはトークンを使用して QUIC バージョン 2 接続を開始してはならず (MUST NOT)、その逆も同様です。接続に互換性のあるバージョンネゴシエーションが含まれる場合、発行されたサーバートークンは、元のバージョンではなく、ネゴシエートされたバージョンに由来すると見なされます。

Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version. A rejected ticket results in falling back to a full TLS handshake, without 0-RTT. A rejected token results in the client address remaining unverified, which limits the amount of data the server can send.

サーバーは、セッションチケットまたはトークンの元のバージョンを検証する必要があり (MUST)、異なるバージョンから発行されたものを受け入れてはなりません。拒否されたチケットは、0-RTT なしで完全な TLS ハンドシェイクにフォールバックします。拒否されたトークンは、クライアントアドレスが未確認のままになり、サーバーが送信できるデータ量が制限されます。

After compatible version negotiation, any resulting session ticket maps to the negotiated version rather than the original one.

互換性のあるバージョンネゴシエーションの後、結果として得られるセッションチケットは、元のバージョンではなくネゴシエートされたバージョンにマップされます。

6. Ossification Considerations

QUIC version 2 provides protection against some forms of ossification. Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets.

QUIC バージョン 2 は、いくつかの形式の固定化に対する保護を提供します。すべてのロングヘッダーがバージョン 1 をエンコードすると想定するデバイス、またはバージョン 1 Initial 鍵導出式がバージョン不変のままであると想定するデバイスは、バージョン 2 パケットを正しく処理しません。

However, many middleboxes, such as firewalls, focus on the first packet in a connection, which will often remain in the version 1 format due to the considerations above.

ただし、ファイアウォールなどの多くのミドルボックスは接続の最初のパケットに重点を置いており、上記の考慮事項により、バージョン 1 形式のままになることがよくあります。

Clients interested in combating middlebox ossification can initiate a connection using version 2 if they are reasonably certain the server supports it and if they are willing to suffer a round-trip penalty if they are incorrect. In particular, a server that issues a session ticket for version 2 indicates an intent to maintain version 2 support while the ticket remains valid, even if support cannot be guaranteed.

ミドルボックスの固定化に対抗することに関心のあるクライアントは、サーバーがバージョン 2 をサポートしていることが合理的に確実であり、間違っていた場合にラウンドトリップのペナルティを受ける意思がある場合、バージョン 2 を使用して接続を開始できます。特に、バージョン 2 のセッションチケットを発行するサーバーは、サポートが保証されていなくても、チケットが有効である間はバージョン 2 のサポートを維持する意図を示しています。

7. Applicability

QUIC version 2 provides no change from QUIC version 1 for the capabilities available to applications. Therefore, all Application-Layer Protocol Negotiation (ALPN) [RFC7301] codepoints specified to operate over QUIC version 1 can also operate over this version of QUIC. In particular, both the "h3" [HTTP/3] and "doq" [RFC9250] ALPNs can operate over QUIC version 2.

QUIC バージョン 2 は、アプリケーションが利用できる機能について QUIC バージョン 1 から変更はありません。したがって、QUIC バージョン 1 上で動作するように指定されたすべての Application-Layer Protocol Negotiation (ALPN) [RFC7301] コードポイントは、このバージョンの QUIC 上でも動作できます。特に、"h3" [HTTP/3] および "doq" [RFC9250] ALPN はどちらも QUIC バージョン 2 上で動作できます。

Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2.

特に明記されていない限り、バージョン 1 で動作するように定義されたすべての QUIC 拡張機能は、バージョン 2 でも動作します。

8. Security Considerations

QUIC version 2 introduces no changes to the security or privacy properties of QUIC version 1.

QUIC バージョン 2 は、QUIC バージョン 1 のセキュリティまたはプライバシープロパティに変更を加えません。

The mandatory version negotiation mechanism guards against downgrade attacks, but downgrades have no security implications, as the version properties are identical.

必須のバージョンネゴシエーションメカニズムはダウングレード攻撃を防ぎますが、バージョンプロパティは同じであるため、ダウングレードにはセキュリティ上の影響はありません。

Support for QUIC version 2 can help an observer to fingerprint both client and server devices.

QUIC バージョン 2 のサポートは、オブザーバーがクライアントとサーバーの両方のデバイスをフィンガープリントするのに役立ちます。

9. IANA Considerations

IANA has added the following entries to the "QUIC Versions" registry maintained at https://www.iana.org/assignments/quic.

IANA は、https://www.iana.org/assignments/quic で維持されている「QUIC バージョン」レジストリに次のエントリを追加しました。

Value: 0x6b3343cf Status: permanent Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG

Value: 0x709a50c4 Status: provisional Specification: RFC 9369 Change Controller: IETF Contact: QUIC WG Notes: QUIC v2 draft codepoint

10. References

10.1. Normative References

[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, https://www.rfc-editor.org/info/rfc9000.

[QUIC-RECOVERY] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, https://www.rfc-editor.org/info/rfc9002.

[QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, https://www.rfc-editor.org/info/rfc9001.

[QUIC-VN] Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, May 2023, https://www.rfc-editor.org/info/rfc9368.

[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.

[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.

10.2. Informative References

[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, https://www.rfc-editor.org/info/rfc9114.

[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, https://www.rfc-editor.org/info/rfc8999.

[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.

[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, https://www.rfc-editor.org/info/rfc7838.

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, https://www.rfc-editor.org/info/rfc9250.

Appendix A. Sample Packet Protection

This section shows examples of packet protection so that implementations can be verified incrementally. Samples of Initial packets from both the client and server plus a Retry packet are defined. These packets use an 8-byte client-chosen Destination Connection ID of 0x8394c8f03e515708. Some intermediate values are included. All values are shown in hexadecimal.

このセクションでは、実装を段階的に検証できるように、パケット保護の例を示します。クライアントとサーバーの両方からの Initial パケットと Retry パケットのサンプルが定義されています。これらのパケットは、8バイトのクライアント選択宛先接続 ID 0x8394c8f03e515708 を使用します。いくつかの中間値が含まれています。すべての値は16進数で表示されます。

(See RFC text for details on A.1 - A.5, code blocks are untranslated)

Acknowledgments

The author would like to thank Christian Huitema, Lucas Pardue, Kyle Rose, Anthony Rossi, Zahed Sarker, David Schinazi, Tatsuhiro Tsujikawa, and Martin Thomson for their helpful suggestions.

著者は、Christian Huitema、Lucas Pardue、Kyle Rose、Anthony Rossi、Zahed Sarker、David Schinazi、Tatsuhiro Tsujikawa、および Martin Thomson の有益な提案に感謝します。

Author's Address

Martin Duke Google LLC Email: [email protected]