要約

  • PADDINGは識別用の1バイトだけからなるフレームで、内容も意味も持たない。サイズは増やすが、アプリケーション、STREAM、CRYPTOのデータは運ばない。
  • PADDINGだけのパケットは輻輳制御上送信中として扱われ、輻輳ウィンドウを消費するが、ウィンドウを開くACKは発生しない。RFC 9000は、送信者が他のack-elicitingフレームを定期的に加えるべきだと SHOULD で示す。
  • クライアントはInitialを運ぶすべてのUDPデータグラムを少なくとも1200バイトにしなければならず MUST、サーバーの同じ要件はack-eliciting Initialパケットを運ぶデータグラムに限られる。どちらも進展の証明ではない。

運用担当者が1200バイトのUDPデータグラムを見て「有効なInitial」と記録し、送信中バイトの増加も進展として扱う場面を考える。この判断では別の証拠が混ざっている。UDPデータグラム長、QUICパケットの境界とタイプ、PADDINGバイト数、ack-elicitingフレームの有無、送信中バイト、輻輳ウィンドウの変化、ACK、握手状態、アプリケーション結果は別々に記録しなければならない。

QUICのPADDINGフレームは0x00というタイプで、識別用の1バイト以外の内容を持たない。意味も持たない。パケットを大きくし、Initialを必要なサイズにすることや、トラフィック分析に利用できる情報を減らすことには使える。しかしアプリケーション、STREAM、CRYPTOのデータ、受領通知、結果、完了信号は運ばない。したがってPADDINGのバイト量だけで、相手が有用な内容を処理したこと、握手が進んだこと、アプリケーションに届いたことは証明できない。

一つのデータグラムにはPADDINGを含むInitialと別のフレームを入れられる。また、複数のQUICパケットをパケットの併合によって一つのUDPデータグラムにまとめることもできる。長さだけでは、どのバイトが握手を進めたか分からない。許可されたエンドポイントでパケット境界と保護されたフレーム構造を解析する必要がある。PADDINGを含むパケットがack-elicitingフレームも含めば、ACKされることはある。そのACKはパケット処理についての限定的な証拠にすぎず、PADDINGを握手やアプリケーションの内容には変えない。

ACK、PADDING、CONNECTION_CLOSE以外のフレームを含むパケットがack-elicitingパケットである。PADDINGだけでは受信側にACKを送らせない。一方、PADDINGを含むパケットは輻輳制御上送信中として扱われる。PADDINGだけのパケットは輻輳ウィンドウを消費するが、ウィンドウを開くACKは生まない。そのためRFC 9000は、送信者が別のack-elicitingフレームを定期的に加えるべきだと SHOULD で示している。送信中バイトの増加は、意味のある進展とは別の事実である。

1200バイトの規則にも限定された意味がある。クライアントはInitialを運ぶすべてのUDPデータグラムを少なくとも1200バイトに拡張しなければならず MUST、PADDINGを加えるか、パケットの併合を行える。サーバーはack-eliciting Initialパケットを運ぶデータグラムについて同様に拡張しなければならない MUST。この要件は、合理的な経路MTUを扱えるかを試すものだ。クライアント側の拡張は、未検証アドレスに応答するサーバーの増幅余地も減らす。1200バイトが握手内容の最小量という意味ではなく、すべてのInitialがPADDINGを使うわけでもない。

アドレス検証前のサーバーは、接続に一意に帰属するUDPペイロードを三倍の反増幅台帳に入れる。PADDINGに由来するバイトも含まれる。意味がないからといって計算上無料にはならない。PADDINGは観測されるサイズを変え、トラフィック分析に利用できる情報の一部を減らせるが、プライバシーを保証せず、時間、方向、パケット数、すべての長さを隠すものでもない。安全な証拠保存とこの台帳は運用上の推奨であり、QUICの要求ではない。