要約

  • RFC 9868 はUDP Lengthの後、IPデータグラムの終端前にある surplus area をUDPトランスポート・オプションに使う。そこはUDPユーザーデータとは別の領域である。
  • DTLSが守るのはユーザーデータであり、UDPオプションではない。保護されたペイロード、OCS、送信済みのオプションから、オプションの保護・処理・効果を推定してはならない。

小さな拡張が大きな保証に見えるのは、隣接する層の性質を持ち込んだときだ。RFC 9868 は、IPが示すトランスポート領域とUDP Lengthの間に生じ得る差を利用する。境界より前はユーザーデータ、残りはオプション対応実装が解釈する領域になる。この構造は共通の形式を与えるが、相手の実装、経路の保持、アプリケーションの採用を約束しない。

UDPの性質も変わらない。RFC 9868 でもUDPはステートレスで単方向のままで、オプションは完成した対話プロトコルではなく枠組みである。定義された必須対応の範囲を除けば、送信者は受信者に処理を強制できない。受信者は任意オプションをローカル設定に従って無視できる。したがって「送った」という記録は送信側の事実であって、相手の能力、途中での保持、確認応答の証明ではない。

保護の範囲はRFC自身が限定している。RFC 9868 はTLSとDTLSがトランスポート層を保護せず、DTLSはUDPユーザーデータだけを対象にすると述べる。また、OCS、AUTH、UENC、IPsecなどで別途カバーしない限り、UDPヘッダ、ペイロード、surplus areaの改変に対する特別な保護は機構自体からは得られない。適切な暗号化がなければ、オプションは経路上で見える。DTLSを使ったという一文を、隣のオプションの機密性や完全性に読み替えることはできない。

OCSの役割も狭く保つべきだ。これはsurplus areaの誤りを検出するもので、権限者を識別せず、経路を保証せず、行為を承認しない。従来UDPとの互換性を保つ既定動作では、適用されるOCSに失敗しても、受信者はユーザーデータを上位へ渡し、ほかのオプションを無視し得る。監査に必要なのは、どのローカル方針で何を処理したかであり、「安全なオプションだった」という広い表現ではない。

RFC 9869 のDPLPMTUDは、形式と観測の間の空白を示す。UDP Optionsによる方式には送信側と受信側の有効化、そして探測への明示的な応答が必要だ。オプションの構文だけで経路測定は成立しない。RFC 9868 は、途中の装置がsurplus areaを取り除く場合や、オプション付きデータグラムを落とす場合も示す。送信記録、保護範囲、受信側の報告、時刻付き経路証拠、アプリケーションの結果は分けて残す必要がある。

Heng Lu の考え方では、RFCが提供するのは検証可能な共通工件である。オンにするか、どの保護を要求するか、失敗時に何を上位へ渡すか、後続の判断に何を使うかはローカルの責任に残る。この境界を残すことで、便利なオプションを、存在しなかった決定や結果の代理にしない。

Sources