このメモの位置付け

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

この文書は、Internet Engineering Task Force (IETF) の成果物である。これはIETFコミュニティの合意を 表している。公開レビューを受けており、 Internet Engineering Steering Group (IESG) によって 発行が承認されている。インターネット標準に関する 詳細情報は、RFC 7841のセクション2で入手できる。¶

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

Copyright Notice

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

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

目次

1. QUICの極めて抽象的な説明

QUICは、2つのエンドポイント間のコネクション指向プロトコルである。これらのエンドポイントは UDPデータグラムを交換する。これらのUDPデータグラムにはQUICパケットが含まれる。QUIC エンドポイントは、QUICパケットを使用してQUIC接続を確立する。これは、それらのエンドポイント間で共有される プロトコル状態である。¶

2. すべてのQUICバージョンの固定特性

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

この文書は、新しいバージョンが開発および展開される際にも安定したままであることを 意図したQUICのサブセットについて説明する。これらの不変特性はすべて IPバージョンに依存しない。¶

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

付録Aには、 QUICバージョン1に関する知識に基づいてなされる可能性のある 誤った仮定の一部について、網羅的ではない一覧が含まれている。これらは QUICのすべてのバージョンに適用されるわけではない。¶

3. 規約と定義

この文書におけるキーワード「MUST」、「MUST NOT」、 「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、 「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、 ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されるとおりに解釈される。¶

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

この文書は、[QUIC-TRANSPORT]の用語と記法上の規約を使用する。¶

4. 記法上の規約

パケットの形式は、このセクションで定義する記法を使用して記述される。 この記法は、[QUIC-TRANSPORT]で使用されているものと同じである。¶

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

個々のフィールドには、長さ情報に加え、固定値、任意性、または反復に関する 指示が含まれる。個々のフィールドは、すべての長さをビット単位として、 次の記法上の規約を使用する。¶

x (A):

xがAビット長であることを示す¶

x (A..B):

xがAからBまでの任意の長さを取り得ることを示す。Aは省略して 最小0ビットを示すことができ、Bは省略して上限が設定されないことを示すことができる。 この形式の値は常にバイト境界で終わる¶

x (L) = C:

xが固定値Cを持つことを示す。xの長さは Lによって記述され、Lは上記の長さ形式のいずれも使用できる¶

x (L) ...:

xが0回以上反復され、各インスタンスの長さが Lであることを示す¶

この文書はネットワークバイトオーダー（すなわちビッグエンディアン）の値を使用する。 フィールドは各バイトの上位ビットから配置される。¶

図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) ...,
}

5. QUICパケット

QUICエンドポイントは、1つ以上のQUICパケットを含むUDPデータグラムを交換する。 このセクションでは、QUICパケットの不変の特性について説明する。 QUICのあるバージョンでは、1つのUDPデータグラム内に複数のQUICパケットを含めることが 許可される可能性があるが、不変特性が説明するのはデータグラム内の最初のパケットのみである。¶

QUICは2種類のパケットヘッダー、すなわちロングヘッダーとショートヘッダーを定義する。 ロングヘッダーを持つパケットは、最初のバイトの最上位ビットが設定されていることで識別される。 ショートヘッダーを持つパケットでは、そのビットはクリアされている。¶

QUICパケットは、ヘッダーを含めて完全性保護される場合がある。ただし、QUIC バージョンネゴシエーションパケットは完全性保護されない。セクション6を参照。¶

ここで説明する値を除き、QUICパケットのペイロードは バージョン固有であり、任意の長さである。¶

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 (..),
}

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

6. バージョンネゴシエーション

QUICエンドポイントは、ロングヘッダーを持ち、自身が理解しない、または サポートしないバージョンのパケットを受信した場合、応答としてVersion Negotiation パケットを送信する場合がある。ショートヘッダーを持つパケットはバージョン ネゴシエーションを発生させない。¶

Version Negotiationパケットは最初のバイトの上位ビットを設定するため、 セクション5.1で定義されるロングヘッダーを持つ パケットの形式に適合する。Version Negotiationパケットは、 0x00000000に設定されたVersionフィールドによって、そのようなパケットとして識別できる。¶

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) ...,
}

Version Negotiationパケットの最初のバイトのうち、定義された値を持つのは 最上位ビットのみである。「Unused」とラベル付けされた残りの7ビットは、送信時に 任意の値に設定でき、受信時にはMUST無視される。¶

Source Connection IDフィールドの後に、Version Negotiationパケットは、 パケットを送信するエンドポイントがサポートするバージョンをそれぞれ識別する Supported Versionフィールドのリストを含む。Version Negotiationパケットには他の フィールドは含まれない。エンドポイントは、Supported Versionフィールドを含まないパケット、または 切り詰められたSupported Version値を含むパケットをMUST無視する。¶

Version Negotiationパケットは、完全性保護または機密性保護を使用しない。 特定のQUICバージョンには、エンドポイントがサポートされるバージョンの集合に対する 変更または破損を検出できるようにするプロトコル要素が含まれる場合がある。¶

エンドポイントは、受信したパケットのSource Connection IDフィールドからの値を Destination Connection IDフィールドにMUST含める。 Source Connection IDフィールドの値は、受信したパケットのDestination Connection ID フィールドからMUSTコピーされる。この値は最初にクライアントによってランダムに選択される。 両方の接続IDをエコーすることで、クライアントは、サーバーが パケットを受信したこと、およびVersion Negotiationパケットがパケットを観測できない攻撃者によって 生成されたものではないことについて、ある程度の確証を得られる。¶

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

QUICバージョン1をサポートするエンドポイントがVersion Negotiationパケットを生成および処理する方法についての より詳細な説明は、[QUIC-TRANSPORT]を参照。¶

7. セキュリティとプライバシーに関する考慮事項

ミドルボックスが特定のQUICバージョンの特徴を観測し、QUICの他のバージョンが 類似の特徴を示す場合に同じ基礎となる意味が表現されていると仮定する可能性がある。 そのような特徴は多数存在し得る。付録Aを参照。 QUICバージョン1では、観測可能な特徴の一部を排除または 不明瞭にするための努力がなされているが、その多くは残っている。 他のQUICバージョンでは異なる設計判断がなされ、そのため異なる特徴を示す場合がある。¶

QUICバージョン番号はすべてのQUICパケットに現れるわけではない。これは、 バージョン固有の特徴に基づいてフローから情報を確実に抽出するには、 ミドルボックスが目にするすべての接続IDについて状態を保持する必要があることを意味する。¶

この文書で説明されるVersion Negotiationパケットは 完全性保護されていない。これは攻撃者による挿入に対して限定的な保護しか持たない。 エンドポイントは、その結果として異なるQUICバージョンを試行する場合、Version Negotiationパケットの意味内容をMUST認証する。¶

付録A. 誤った仮定

QUICバージョン1 [QUIC-TRANSPORT]には、 観測から保護されていないものの、新しいバージョンが展開される際には 変更可能と見なされるいくつかの特徴がある。¶

このセクションでは、QUICバージョン1に関する知識に基づいてQUICについて なされる可能性のある誤った仮定の例を列挙する。これらの記述の一部は、 QUICバージョン1についてさえ真ではない。これは網羅的な一覧ではなく、 例示のみを意図している。¶

以下の記述はいずれも、特定のQUICバージョンでは偽である可能性がある。¶

• QUICはTLS [QUIC-TLS]を使用し、一部のTLSメッセージはネットワーク上で可視である。¶
• QUICロングヘッダーは、接続確立中にのみ交換される。¶
• 特定の5タプル上のすべてのフローには、接続確立フェーズが含まれる。¶
• フロー上で最初に交換されるパケットはロングヘッダーを使用する。¶
• 長い静止期間の前の最後のパケットには、 確認応答のみが含まれると仮定される場合がある。¶
• QUICは、接続確立中に交換するパケットを保護するために、 Associated Data付き認証暗号（AEAD）関数 （AEAD_AES_128_GCM。[RFC5116]を参照）を使用する。¶
• QUICパケット番号は暗号化され、最初の暗号化バイトとして現れる。¶
• QUICパケット番号は、送信されるパケットごとに1ずつ増加する。¶
• QUICには、クライアントが送信する最初のハンドシェイクパケットについて 最小サイズがある。¶
• QUICは、クライアントが先に発話することを規定している。¶
• QUICパケットでは、最初のバイトの第2ビット（0x40）が常に設定されている。¶
• QUIC Version Negotiationパケットは、サーバーによってのみ送信される。¶
• QUIC接続IDはめったに変更されない。¶
• QUICエンドポイントは、Version Negotiationパケットを送信されると、使用するバージョンを変更する。¶
• QUICロングヘッダー内のVersionフィールドは、 両方向で同じである。¶
• Version フィールドに特定の値を持つQUICパケットは、対応するQUICバージョンが使用中であることを意味する。¶
• 任意のQUICエンドポイントのペア間では、一度に1つの接続だけが 確立される。¶

著者の連絡先