メインコンテンツまでスキップ

RFC 8999 - QUICのバージョン非依存の特性

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

概要 (Abstract)​

本文書は、QUICトランスポートプロトコル (QUIC Transport Protocol) のすべてのバージョンに共通する特性を定義します。

本メモのステータス (Status of This Memo)​

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

本文書はインターネット技術タスクフォース (IETF) の成果物です。IETFコミュニティの合意を表しています。本文書は公開レビューを受けており、インターネット技術運営委員会 (IESG) によって発行が承認されています。インターネット標準に関する詳細情報はRFC 7841のセクション2で入手できます。

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

目次 (Table of Contents)​

付録 (Appendix)​

関連リソース​

1. QUICの極めて抽象的な説明 (An Extremely Abstract Description of QUIC)​

QUICは2つのエンドポイント (Endpoints) 間のコネクション指向プロトコル (Connection-Oriented Protocol) です。これらのエンドポイントはUDPデータグラム (UDP Datagrams) を交換します。これらのUDPデータグラムにはQUICパケット (QUIC Packets) が含まれています。QUICエンドポイントはQUICパケットを使用してQUIC接続 (QUIC Connection) を確立します。接続とは、これらのエンドポイント間で共有されるプロトコル状態 (Shared Protocol State) です。

2. すべてのQUICバージョンの固定特性 (Fixed Properties of All QUIC Versions)​

安全でマルチプレックスされたトランスポート (Secure, Multiplexed Transport) を提供することに加えて、QUIC [QUIC-TRANSPORT] はバージョンをネゴシエートするオプションを許可します。これにより、プロトコルは新しい要件に応じて時間とともに変化することができます。プロトコルの多くの特性はバージョン間で変化する可能性があります。

本文書は、新しいバージョンが開発され展開される際に安定したままであることが意図されているQUICのサブセットを記述します。これらすべての不変項 (Invariants) はIPバージョンから独立しています。

本文書の主な目標は、QUICの新しいバージョンを展開できることを保証することです。変更できない特性を文書化することにより、本文書はQUICエンドポイントがプロトコルの他のあらゆる側面の変更をネゴシエートする能力を保持することを目指しています。その結果、これはエンドポイント以外のエンティティに提供される最小限の情報量も保証します。本文書で明示的に禁止されていない限り、プロトコルのあらゆる側面は異なるバージョン間で変化する可能性があります。

付録Aには、QUICバージョン1の知識に基づいて行われる可能性のあるいくつかの誤った仮定の非網羅的なリストが含まれています。これらはQUICのすべてのバージョンに適用されるわけではありません。

3. 規約と定義 (Conventions and Definitions)​

本文書のキーワード "MUST" (しなければならない)、"MUST NOT" (してはならない)、"REQUIRED" (必須である)、"SHALL" (しなければならない)、"SHALL NOT" (してはならない)、"SHOULD" (すべきである)、"SHOULD NOT" (すべきでない)、"RECOMMENDED" (推奨される)、"NOT RECOMMENDED" (推奨されない)、"MAY" (してもよい)、"OPTIONAL" (任意である) は、BCP 14 [RFC2119] [RFC8174] に記載されているとおりに解釈されるものとします。これらのキーワードがすべて大文字で表示される場合に限ります。

本文書は、規範的な言語が使用されていない場合でも、将来のQUICバージョンに対する要件を定義します。

本文書は [QUIC-TRANSPORT] の用語と表記規則を使用します。

4. 表記規則 (Notational Conventions)​

パケットのフォーマットは、このセクションで定義される表記法を使用して記述されます。この表記法は [QUIC-TRANSPORT] で使用されるものと同じです。

複雑なフィールドには名前が付けられ、その後に一対の一致する中括弧で囲まれたフィールドのリストが続きます。このリスト内の各フィールドはカンマで区切られます。

個々のフィールドには長さ情報、および固定値、オプション性、または繰り返しに関する指示が含まれます。個々のフィールドは以下の表記規則を使用し、すべての長さはビット単位です：

x (A): x が A ビット長であることを示します

x (A..B): x が A から B までの任意の長さであることを示します。A は省略可能で、最小がゼロビットであることを示し、B は省略可能で、設定された上限がないことを示します。この形式の値は常にバイト境界で終了します

x (L) = C: x が固定値 C を持つことを示します。x の長さは L によって記述され、L は上記の長さ形式のいずれかを使用できます

x (L) ...: x がゼロ回以上繰り返され、各インスタンスの長さが L であることを示します

本文書はネットワークバイトオーダー (Network Byte Order, すなわちビッグエンディアン Big Endian) 値を使用します。フィールドは各バイトの高位ビットから配置されます。

図1に例示構造を示します：

Example Structure {
  One-bit Field (1),
  7-bit Field with Fixed Value (7) = 61,
  Arbitrary-Length Field (..),
  Variable-Length Field (8..24),
  Repeated Field (8) ...,
}

図1: 例示フォーマット

5. QUICパケット (QUIC Packets)​

QUICエンドポイントは、1つ以上のQUICパケットを含むUDPデータグラムを交換します。本セクションでは、QUICパケットの不変特性を記述します。QUICのバージョンによっては、単一のUDPデータグラムに複数のQUICパケットを許可する場合がありますが、不変特性はデータグラム内の最初のパケットのみを記述します。

QUICは2種類のパケットヘッダー (Packet Headers) を定義します: ロングヘッダー (Long Header) とショートヘッダー (Short Header)。ロングヘッダーを持つパケットは、最初のバイトの最上位ビット (Most Significant Bit) が1に設定されることで識別されます。ショートヘッダーを持つパケットは、そのビットがクリアされます。

QUICパケットは、ヘッダーを含めて完全性保護 (Integrity Protected) される場合があります。ただし、QUICバージョンネゴシエーションパケット (Version Negotiation Packets) は完全性保護されません。セクション6を参照してください。

ここで説明する値以外に、QUICパケットのペイロード (Payload) はバージョン固有 (Version-Specific) であり、任意の長さ (Arbitrary Length) です。

5.1 ロングヘッダー (Long Header)​

ロングヘッダーは図2に記述された形式をとります。

Long Header Packet {
  Header Form (1) = 1,
  Version-Specific Bits (7),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Version-Specific Data (..),
}

図2: QUICロングヘッダー

ロングヘッダーを持つQUICパケットは、最初のバイトの高位ビットが1に設定されています。そのバイトの他のすべてのビットはバージョン固有です。

次の4バイトには32ビットのバージョンフィールド (Version Field) が含まれます。バージョンはセクション5.4で説明されます。

次のバイトには、その後に続く宛先接続IDフィールド (Destination Connection ID Field) のバイト長が含まれます。この長さは8ビット符号なし整数としてエンコードされます。宛先接続IDフィールドは宛先接続ID長フィールドに続き、長さは0から255バイトの間です。接続IDはセクション5.3で説明されます。

次のバイトには、その後に続く送信元接続IDフィールド (Source Connection ID Field) のバイト長が含まれます。この長さは8ビット符号なし整数としてエンコードされます。送信元接続IDフィールドは送信元接続ID長フィールドに続き、長さは0から255バイトの間です。

パケットの残りの部分にはバージョン固有のコンテンツが含まれます。

5.2 ショートヘッダー (Short Header)​

ショートヘッダーは図3に記述された形式をとります。

Short Header Packet {
  Header Form (1) = 0,
  Version-Specific Bits (7),
  Destination Connection ID (..),
  Version-Specific Data (..),
}

図3: QUICショートヘッダー

ショートヘッダーを持つQUICパケットは、最初のバイトの高位ビットが0に設定されています。

ショートヘッダーを持つQUICパケットは、最初のバイトの直後に宛先接続IDを含みます。ショートヘッダーには、宛先接続ID長 (Destination Connection ID Length)、送信元接続ID長 (Source Connection ID Length)、送信元接続ID、またはバージョン (Version) フィールドは含まれません。ショートヘッダーを持つパケット内の宛先接続IDの長さは、パケット内にエンコードされておらず、本仕様によって制約されていません。

パケットの残りの部分はバージョン固有のセマンティクスを持ちます。

5.3 接続ID (Connection ID)​

接続ID (Connection ID) は任意の長さの不透明なフィールド (Opaque Field) です。

接続IDの主な機能は、下位プロトコル層 (UDP、IP、およびそれ以下) でのアドレス変更が、QUIC接続のパケットを誤ったQUICエンドポイントに配信させないことを保証することです。接続IDは、エンドポイントとそれらをサポートする中間デバイス (Intermediaries) によって使用され、各QUICパケットがエンドポイントの正しいインスタンスに配信されることを保証します。エンドポイントでは、接続IDはパケットが意図するQUIC接続を識別するために使用されます。

接続IDは、各エンドポイントによってバージョン固有の方法で選択されます。同じQUIC接続のパケットは、異なる接続ID値を使用する場合があります。

5.4 バージョン (Version)​

バージョンフィールド (Version Field) には4バイトの識別子が含まれます。この値は、エンドポイントがQUICバージョンを識別するために使用できます。0x00000000の値を持つバージョンフィールドは、バージョンネゴシエーション用に予約されています。セクション6を参照してください。他のすべての値は有効である可能性があります。

本文書で説明されている特性は、QUICのすべてのバージョンに適用されます。本文書で説明されている特性に準拠していないプロトコルはQUICではありません。将来の文書では、特定のQUICバージョンまたは一連のQUICバージョンに適用される追加の特性が説明される場合があります。

6. バージョンネゴシエーション (Version Negotiation)​

ロングヘッダーを持つパケットを受信し、そのバージョンが理解できない、またはサポートしていないQUICエンドポイントは、レスポンスとしてバージョンネゴシエーションパケット (Version Negotiation Packet) を送信する場合があります。ショートヘッダーを持つパケットはバージョンネゴシエーションをトリガーしません。

バージョンネゴシエーションパケットは最初のバイトの高位ビットを設定するため、セクション5.1で定義されたロングヘッダーを持つパケットのフォーマットに準拠します。バージョンネゴシエーションパケットは、0x00000000に設定されたバージョンフィールドによって識別できます。

Version Negotiation Packet {
  Header Form (1) = 1,
  Unused (7),
  Version (32) = 0,
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Supported Version (32) ...,
}

図4: バージョンネゴシエーションパケット

バージョンネゴシエーションパケットの最初のバイトでは、最上位ビットのみが定義された値を持ちます。"Unused" (未使用) とラベル付けされた残りの7ビットは、送信時に任意の値に設定でき、受信時には無視しなければなりません (MUST)。

送信元接続IDフィールドの後、バージョンネゴシエーションパケットにはサポートされるバージョンフィールド (Supported Version Fields) のリストが含まれ、各フィールドはパケットを送信するエンドポイントがサポートするバージョンを識別します。バージョンネゴシエーションパケットには他のフィールドは含まれません。エンドポイントは、サポートされるバージョンフィールドを含まない、または切り捨てられたサポートされるバージョン値を含むパケットを無視しなければなりません (MUST)。

バージョンネゴシエーションパケットは完全性保護や機密性保護を使用しません。特定のQUICバージョンには、エンドポイントがサポートされるバージョンセットの変更や破損を検出できるプロトコル要素が含まれる場合があります。

エンドポイントは、受信したパケットの送信元接続IDフィールドの値を宛先接続IDフィールドに含めなければなりません (MUST)。送信元接続IDフィールドの値は、受信したパケットの宛先接続IDフィールドからコピーしなければなりません (MUST)。これは最初にクライアントによってランダムに選択されます。両方の接続IDをエコーバックすることで、クライアントにサーバーがパケットを受信したこと、およびバージョンネゴシエーションパケットがパケットを観測できない攻撃者によって生成されたものではないことについて、ある程度の保証を提供します。

バージョンネゴシエーションパケットを受信したエンドポイントは、後続のパケットに使用することを決定したバージョンを変更する場合があります。エンドポイントがQUICバージョンを変更する条件は、選択するQUICバージョンに依存します。

QUICバージョン1をサポートするエンドポイントがバージョンネゴシエーションパケットをどのように生成および使用するかについての詳細な説明は、[QUIC-TRANSPORT] を参照してください。

7. セキュリティとプライバシーの考慮事項 (Security and Privacy Considerations)​

ミドルボックス (Middleboxes) は、特定のバージョンのQUICの特性を観察し、他のバージョンのQUICが類似の特性を示す場合に、同じ基本的なセマンティクスが表現されていると仮定する可能性があります。そのような特性は多数存在する可能性があります。付録Aを参照してください。QUICバージョン1では、いくつかの観察可能な特性を排除または曖昧にするための努力がなされていますが、多くは残っています。他のQUICバージョンは異なる設計上の決定を行う可能性があるため、異なる特性を示します。

QUICバージョン番号はすべてのQUICパケットに表示されるわけではありません。つまり、バージョン固有の特性に基づいてフローから情報を確実に抽出するには、ミドルボックスが見るすべての接続IDの状態を保持する必要があります。

本文書で説明されているバージョンネゴシエーションパケットは完全性保護されていません。攻撃者による挿入に対してはわずかな保護しかありません。エンドポイントは、その結果として異なるQUICバージョンを試みる場合、バージョンネゴシエーションパケットのセマンティックコンテンツを認証しなければなりません (MUST)。

8. 参考文献 (References)​

8.1 規範的参考文献 (Normative References)​

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

8.2 参考情報 (Informative References)​

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

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

Appendix A. 誤った仮定 (Incorrect Assumptions)​

QUICバージョン1 [QUIC-TRANSPORT] には、観察から保護されていないものの、新しいバージョンが展開される際に変更可能と考えられているいくつかの特性があります。

このセクションでは、QUICバージョン1の知識に基づいてQUICについて行われる可能性のある誤った仮定のいくつかの例を示します。これらの記述の一部は、QUICバージョン1に対してさえ真実ではありません。これは網羅的なリストではありません。説明目的でのみ意図されています。

以下のいずれかまたはすべての記述は、特定のQUICバージョンに対して誤りである可能性があります：

  • QUICはTLS [QUIC-TLS] を使用し、一部のTLSメッセージはワイヤ上で可視です。

  • QUICロングヘッダーは接続確立中にのみ交換されます。

  • 特定の5タプル上のすべてのフローには接続確立フェーズが含まれます。

  • フロー上で交換される最初のパケットはロングヘッダーを使用します。

  • 長時間の静止の前の最後のパケットは確認 (Acknowledgment) のみを含むと仮定される場合があります。

  • QUICは、接続確立中に交換されるパケットを保護するために認証付き暗号化 (AEAD) 関数 (AEAD_AES_128_GCM; [RFC5116] を参照) を使用します。

  • QUICパケット番号 (Packet Numbers) は暗号化されており、最初の暗号化バイトとして表示されます。

  • QUICパケット番号は送信されるパケットごとに1ずつ増加します。

  • QUICは、クライアントが送信する最初のハンドシェイクパケットの最小サイズ要件を持っています。

  • QUICはクライアントが最初に発言することを規定しています。

  • QUICパケットは常に最初のバイトの第2ビット (0x40) を設定します。

  • QUICバージョンネゴシエーションパケットはサーバーによってのみ送信されます。

  • QUIC接続IDは頻繁には変更されません。

  • QUICエンドポイントは、バージョンネゴシエーションパケットを送信された場合、使用するバージョンを変更します。

  • QUICロングヘッダーのバージョンフィールドは両方向で同じです。

  • バージョンフィールドに特定の値を持つQUICパケットは、対応するバージョンのQUICが使用されていることを意味します。

  • QUICエンドポイントのペア間で一度に確立される接続は1つだけです。