要約

  • RFC 9853はDTLS 1.2と1.3に、現在のセキュリティコンテキストで認証・暗号化される到達往復確認を追加した。チャレンジに結び付いた応答が届けばCIDとアドレスの対応を更新でき、時間切れなら旧対応を維持する。
  • その結果は本人性、認可、完了した移行より狭い。説明可能な記録には、発端、脅威モデル、探査予算、応答の対応関係、コンテキスト移動、アプリケーション受理、観察期間、ロールバック先を分けて残す必要がある。

アドレスBから来た最初のレコードは有効である。CIDは、相手がアドレスAにいたときのDTLS状態を選び、epochとシーケンス番号も受理でき、認証付き復号にも成功した。それでも「次のアプリケーション応答をBへ送るべきか」という問いは未決定のままだ。

CIDは、UDPのアドレスとポートを接続の恒久的な名前にしない。NATの再割り当てやインターフェース変更の後も、端末は既存のDTLS関連を使える。この継続性には反面がある。本物のレコードのコピーが別経路を先回りすれば、自然な移動に見える。送信元を偽った小さな入力が大きな応答を第三者へ向けさせる可能性もある。

RFC 9146は、相手アドレスを更新する前に三条件を要求した。レコードがDTLSで検証されること、epochと番号の上で新しいこと、そして候補アドレスがDTLSレコードを受信・処理できると確かめる方法があることだ。最後の方法は規定していなかった。

2026年3月のIETF Standards TrackであるRFC 9853は、この空白をDTLS 1.2と1.3について埋め、RFC 9146とRFC 9147を更新した。Return Routability Check（RRC）は、CIDとアドレスの対応を書き換える前に候補経路を検査する。

順序には意味がある。CIDは状態を見つけ、レコード層はその状態に属するデータかを判定し、RRCは経路を試し、その後にローカルな対応変更が行われる。前の判定が後の権限を自動的に得ることはない。

先に合意される機能

RRCは空のrrc拡張、コード61で交渉する。これを提示するクライアントはconnection_idも提示しなければならず、サーバーはServerHelloで受け入れる。双方が正しく交換しない限り、RRCを使ってはならない。

交渉済みでも、すべてのアプリケーションがRRCだけを使うわけではない。CIDレコードが別アドレスから来ればRRCを行うべきだが、アプリケーション固有の確認を起動できる場合は例外となる。RFC 9175のCoAP Echoは、資源、メソッド、方針に応じて要求の新鮮さや相手アドレスへの到達性を問える。輸送経路が通ることと、操作を受け入れることは同じではない。

RRCはcontent type 27のreturn_routability_checkを使い、path_challenge、path_response、path_dropの三種類を持つ。各メッセージには64ビットのエントロピーを持つ8オクテットのcookieが入り、現在のDTLSセキュリティコンテキストで認証・暗号化される。

Cookieは相手の身元でも、アドレスの所有証明でも、アプリケーション命令でもない。応答を特定のチャレンジへ結ぶ値である。「RRC成功」だけを保存すると、接続、試行、対象経路、開始時刻、期限という証明の範囲が消える。

証明の前に送信量を縛る

アドレス変更を検出した受信側は、保留中のアプリケーションデータ送信を止めるか、未検証アドレスへの出力をanti-amplification上限に収める。RFC 9853では、破棄したレコードを除き、そのアドレスから受けた量の三倍である。

これは性能値ではなく、未検証の宛先へ向けられる危険の上限だ。偽装された小さな要求に大きな応答を許さず、まず小さな保護済みチャレンジを送る。DTLS状態を持たない被害者は復号も正しい応答もできず、対応は変わらない。

基本手順では、開始側が予測不能なcookieをpath_challengeに入れ、新しいアドレスへ送ってタイマーTを始める。相手は検証後、path_responseで同じ値を返す。開始側は一致を確認して初めてアドレスを更新する。Tが切れれば更新しない。

損失対策の追加チャレンジには限度がある。異なる輸送パケットに入れ、間隔を空け、各メッセージに乱数を使う。固有要件がなければ、1 RTTに1回、増幅上限までが目安である。応答側は有効なチャレンジごとに遅延なく一つだけ応答し、チャレンジを受けたアドレスへ返す。逆方向PMTUは別の検証を必要とする。

Tの選択も判定の一部である。活動経路のRTT情報が外部にあれば3倍RTT、なければ1秒が推奨され、展開プロファイルは別値を選べる。時間切れは選択した窓内に必要な証拠がなかったという意味で、相手の永久消滅ではない。

旧経路を先に尋ねる理由

基本手順は増幅を抑えるが、本物のレコードを観察し、より速い経路でコピーを競争させるオフパス攻撃には十分でない。先着したコピーが移動に見え、新経路だけの確認で攻撃者をオンパスにしてしまう場合がある。

強化手順は旧アドレスを先に探査する。まだ優先される旧経路からpath_responseが返れば、既存対応を守る。path_dropなら旧経路は生きているが優先ではないため、新アドレスに基本確認を行う。旧経路が無応答でも自動移行せず、新経路を改めて試す。

沈黙、旧経路の明示的な放棄、旧経路の継続利用が別の状態になる。ただし完全な識別ではない。攻撃経路が一貫して速ければ、実際の経路改善と見分けられないことをRFCは認める。旧経路の直近通信や重複パケットはローカルな判断材料になっても、cookieの証明内容を広げない。

検証中の再度のアドレス変更も境界である。入れ子のrebindは規定手順の対象外で、対応しない応答は捨てられ、試行は時間切れになり、旧対応を維持する。その後のデータが新しい確認を始める。試行番号を失えば、どの候補が検証されたか説明できない。

往復可能でも本人とは限らない

成功したRRCが示すのは、現在のDTLS状態を使う相手が、試験経路で保護済みチャレンジを受け、期限内に対応する値を返したことだ。アドレスの法的所有者、利用者や端末の本人性、移動の承認者、場所、将来の持続性、盗聴の不在は示さない。

アプリケーションの継続も別だ。CoAPの操作は独自の新鮮さを要求できる。保留された命令が失効し、非冪等な要求を繰り返せず、認可が変わっているかもしれない。バイトの送信再開は輸送結果であり、処理の意味を保つことはアプリケーション結果である。

Lu Hengの最小初期仕様、将来判断の局所化、自発的採用という考え方は、この分担を明確にする。共通層は安全と相互運用に必要な決定的証拠に絞り、脅威モデル、アプリケーション代替、採用時期、効果の受理はコードを動かす参加者に残す。Policy Mirrorが照らす決定面は、IANA番号ではなく、アドレスを書き換えてアプリ出力を解放するローカル状態遷移である。

一つの緑表示では足りない

RFC 9853は、失敗、同じチャレンジへの複数応答、頻繁な探査を記録するよう勧める。失敗は偽装や戻り経路障害、複数応答は競争攻撃、反復は基盤経路の不安定さを示す可能性がある。

DTLS 1.3はオンパス観察者からレコード種別を隠す。DTLS 1.2でRRCがtls12_cidに包まれない方向では種別が見え、中間装置が選択的に落とせる。両方向CIDが対策となる。DTLS 1.3は経路ごとに新CIDを求められるが、1.2はセッション中に補充できない。相関が問題となるマルチホーム環境では1.3が適する。

すでにオンパスの攻撃者は接続を妨害し、検証を本物の相手へ転送できる。RRCはその力を消さない。IANA TLS Parametersはtype 27、extension 61、三つの初期メッセージを共通化するが、実装、本人性、認可、業務完了を認証しない。

情報源と限界

主な資料はRFC 9853と状態・Errata情報、RFC 9146、RFC 9147、RFC 9175、RFC 9000、IANA登録表、RFC 8126である。これらは仕様上の契約を示すが、実装率、製品既定値、実測性能、事故数、特定運用者の方針を示さない。

RFC Editorの独立したRFC 9853 Errata記録には、調査時点で確認した訂正履歴が残る。