Summary

  • CID は既存の DTLS コンテキストを探す手掛かりであり、新しい UDP 送信元アドレスを検証するものではない。
  • basic RRC は新アドレスを調べ、enhanced RRC は先に旧経路が優先経路かを確かめる。
  • Cookie の一致が支えるのは一回の判断であり、原因、対称性、持続性、アプリ完了は別々に観測すべきである。

同じ接続と分かっても、同じ送信先とは限らない

未知のアドレスから保護されたレコードが届く。CID で正しいセキュリティコンテキストが見つかり、認証にも成功する。RFC 9853 は、ここで直ちにアドレスを書き換えないための RRC を定義した。RFC 9146 の DTLS 1.2 CID と RFC 9147 の DTLS 1.3 CID を、アドレス検証という別の処理につなぐ。

仕様が知るのは送信元が変わったという観測だけだ。NAT の再バインド、能動的な移動、正規レコードを高速な別経路で競争させる転送のいずれかは、この時点では確定しない。

RRC は拡張 61、ContentType 27 を使い、現在のコンテキストで暗号化・認証されたメッセージに 8 バイトの Cookie を載せる。IANA TLS レジストリの path_challenge、path_response、path_drop は、異なる状態遷移を表す。

basic と enhanced は同じ合格試験ではない

basic では、新アドレスへ challenge を送り、期限 T 内に同じ Cookie を含む保護された response が戻ればバインディングを更新する。期限切れなら更新しない。これは、その検証区間で challenge と response が往復した証拠である。同じリンクを通ったこと、今後も安定すること、逆方向 PMTU、後続のアプリデータまでは証明しない。

enhanced は、正規パケットを観測してより速い経路へコピーできるオフパス攻撃者を想定する。最初に旧アドレスを probe する。旧経路がまだ優先なら path_response は「旧バインディングを維持」を意味する。旧経路は生きているが優先でなければ path_drop を返し、その後に新アドレスの basic 検査へ進む。旧経路の timeout も basic を起動するが、それ自体は更新を許可しない。

NAT 再バインドでは、開始側は新経路を見ても、応答側は旧経路を現在の経路として見ることがある。両端の経路認識は一致しない。さらに、転送経路が常に速ければ、攻撃と本当の経路改善を完全には区別できない。

検証前は、保留中のアプリデータを止めるか、未検証アドレスから受理した量の 3 倍という anti-amplification 制限に従う。検証後に送信処理を再開できても、それは遠端での受信結果ではない。

T は既知の旧経路 RTT があれば 3 倍、なければ 1 秒が推奨される。検証中に再びアドレスが変わる nested rebinding は処理対象外で、response は破棄され、更新せず timeout し、新しいデータで次の世代を始める。

継続性を語るには五つの記録が必要だ

記録は、CID とコンテキスト世代、RRC モード・Cookie・アドレス・timer、実際のバインディング更新、各方向で最初に受理された保護パケット、期限内に受理・処理・応答されたアプリ要求に分ける。Cookie が戻るのは二番目であり、三番目を許可する場合があるだけだ。

RFC は失敗、単一 challenge への複数 response、頻繁な probe を SIEM と診断に記録するよう勧める。しかし、それらは調査すべき兆候であり、実際の攻撃や障害の証明ではない。RFC Editor、Datatracker、errataも導入実績を示す資料ではない。

Running-Code Primacy、Minimum Initial Specification、Reality Layersが示す原則も同じだ。仕様上の「validated」を、実行された結果より大きな権威にしてはならない。

Sources