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

RFC 9221 - QUIC への信頼性のないデータグラム拡張

  • ステータス: Proposed Standard
  • 発行日: March 2022
  • Stream: IETF
  • エラッタ: エラッタなし

概要 (Abstract)​

本文書は、QUIC 接続上で信頼性のないデータグラムの送受信をサポートするための、QUIC トランスポートプロトコルへの拡張を定義する。

本メモの状態​

これは Internet Standards Track 文書である。

本文書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティのコンセンサスを表す。公開レビューを受け、Internet Engineering Steering Group (IESG) による公開が承認されている。Internet Standards の詳細は RFC 7841 の Section 2 を参照。

本文書の現状については https://www.rfc-editor.org/info/rfc9221 を参照。

著作権表示​

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

本文書は BCP 78 および IETF Trust の IETF Documents に関する法的規定 (https://trustee.ietf.org/license-info) に従う。本文書から抽出したコードコンポーネントには、Trust Legal Provisions の Section 4.e に記載の Revised BSD License テキストを含める必要がある。

目次​

    1. はじめに
    1. 動機
    1. トランスポートパラメータ
    1. データグラムフレーム種別
    1. 動作と利用
    1. セキュリティ考慮事項
    1. IANA 考慮事項
    1. 参考文献
  • 謝辞
  • 著者の連絡先

1. はじめに​

QUIC トランスポートプロトコル [RFC9000] は、信頼性のあるアプリケーションデータストリームを伝送するための、安全で多重化された接続を提供する。QUIC はパケット内でデータを伝送するためにさまざまなフレーム種別を用い、各フレーム種別はそれが含むデータが再送されるかどうかを定義する。信頼性のあるアプリケーションデータのストリームは STREAM フレームを用いて送信される。

一部のアプリケーション、特にリアルタイムデータを伝送する必要があるものは、データを信頼性なく伝送することを好む。過去、これらのアプリケーションは UDP [RFC0768] をトランスポートとして直接構築し、しばしば DTLS [RFC6347] でセキュリティを追加してきた。信頼性のないアプリケーションデータの伝送をサポートするよう QUIC を拡張することは、信頼性のあるストリームに用いる暗号・認証コンテキストを共有できるという追加の利点とともに、安全なデータグラムの別の選択肢を提供する。

本文書は、再送を必要とせずにアプリケーションデータを運ぶ 2 つの新しい DATAGRAM QUIC フレーム種別を定義する。

1.1. 要件の仕様​

キーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" は、すべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] の記述に従って解釈される。

2. 動機​

QUIC 上で信頼性のないデータを伝送することは、既存の解決策に対して次の利点を提供する:

  • 信頼性のあるストリームと信頼性のないフローの両方を同一ピアに使いたいアプリケーションは、信頼性のある QUIC ストリームと信頼性のない QUIC データグラムのフローの間で単一のハンドシェイクと認証コンテキストを共有することで恩恵を受けられる。これは TLS 接続と DTLS 接続の両方を開く場合と比べ、ハンドシェイクに必要な遅延を削減できる。
  • QUIC は DTLS ハンドシェイクよりも精緻な損失回復機構を用いる。これにより QUIC データの損失回復をより迅速に行える場合がある。
  • QUIC データグラムは QUIC 輻輳制御の対象となる。信頼性と非信頼性の両方のデータに単一の輻輳制御を提供することは、より効果的かつ効率的であり得る。

これらの機能は、音声/映像ストリーミング、ゲーム、その他のリアルタイムネットワークアプリケーションの最適化に有用であり得る。

信頼性のない QUIC データグラムは、仮想プライベートネットワーク (VPN) などのために QUIC 上の IP パケットトンネルを実装するためにも使用できる。インターネット層トンネリングプロトコルは一般に、信頼性があり認証されたハンドシェイクの後に、信頼性のない安全な通信を必要とする。

3. トランスポートパラメータ​

本文書は新しいトランスポートパラメータ max_datagram_frame_size (値 0x20) を定義する。このパラメータは、エンドポイントが受信を望む DATAGRAM フレームの最大サイズ（フレーム種別、長さ、ペイロードを含む）をバイト単位で表す。

4. データグラムフレーム種別​

本文書は 2 つの新しいフレーム種別を定義する:

  • DATAGRAM (0x30): アプリケーションデータを含む DATAGRAM フレーム。長さフィールドを含まず、データはパケット末尾まで延びる。
  • DATAGRAM_WITH_LEN (0x31): アプリケーションデータを含む DATAGRAM フレーム。長さフィールドを含む。

5. 動作と利用​

5.1. データグラムの多重化​

DATAGRAM フレームは QUIC パケット内で他の QUIC フレームと多重化される。

5.2. 確認応答の扱い​

DATAGRAM フレームは損失時に再送されないが、確認応答される。これにより送信者は輻輳制御状態を維持し、配送に関する統計を収集できる場合がある。

5.3. フロー制御​

DATAGRAM フレームはフロー制御の対象ではない。max_datagram_frame_size トランスポートパラメータは個々のフレームのサイズを制限するが、総バイト数やフレーム数の上限はない。

5.4. 輻輳制御​

DATAGRAM フレームは輻輳制御される。送信者は DATAGRAM フレームを送る際、輻輳コントローラの制限を尊重しなければならない (MUST)。

6. セキュリティ考慮事項​

本文書のセキュリティ考慮事項は QUIC [RFC9000] のものと類似する。信頼性のないデータグラムの使用は、データグラムがトラフィックを反射するために使われる場合の増幅攻撃の可能性など、追加の考慮事項を導入する。

7. IANA 考慮事項​

7.1. QUIC トランスポートパラメータ​

本文書は "QUIC Transport Parameters" レジストリに新しい値を登録する:

  • Value: 0x20
  • Parameter Name: max_datagram_frame_size
  • Status: permanent
  • Specification: RFC 9221

7.2. QUIC フレーム種別​

本文書は "QUIC Frame Types" レジストリに 2 つの新しい値を登録する:

  • Value: 0x30-0x31
  • Frame Name: DATAGRAM
  • Status: permanent
  • Specification: RFC 9221

8. 参考文献​

8.1. 規範的参考文献​

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

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

[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. 参考情報​

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc0768.

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

謝辞​

著者は...に感謝する。

著者の連絡先​

Tommy Pauly Apple Inc. Email: [email protected]

Eric Kinnear Apple Inc. Email: [email protected]

David Schinazi Google LLC Email: [email protected]