要約

  • 適用可能なRSVPセキュリティアソシエーションがすべて期限切れになると、草案は管理者へ通知し、最後の一つを延長・削除・交換するまで無期限として扱うよう勧告する。
  • これは古い鍵を安全と認定する判断ではない。未認証通信への後退と、稼働中の予約を突然壊して障害を拡大することの双方を避けるfail-operational設計である。
  • ローテーション完了の証拠は新鍵の登録ではなく、後継アソシエーションの適用、十分な重複期間、時刻の健全性、全受信者のハンドシェイク完了である。

鍵の有効期限が切れた。だが、次のRSVPメッセージは拒否されなかった。障害通知は上がっても、予約は維持され、パケット処理は続く。

この挙動は、2026年9月27日に公開された RSVP Cryptographic Authentication Version 2の改訂02 が意図的に選んだものである。同文書は現在、IETF TEASワーキンググループのLast Callにある。Proposed Standardを目指すInternet-Draftであり、まだRFCではない。特定の製品や網での導入を示す資料でもない。成立すれば、RFC 2747 と RFC 3097 を置き換える。

草案は、利用できるセキュリティアソシエーションがすべて期限切れになった状態を「Pathological Case」と呼ぶ。RSVPを未認証へ戻すことは容認できない。一方、既存予約の破壊は、より広いネットワーク障害を起こしかねない。そこでシステムは、最後のアソシエーションが切れたと管理者へ通知しつつ、それを無期限として扱うべきだとする。終わらせる方法は三つだけだ。有効期間を延ばす、管理操作で削除する、新しいアソシエーションを設定する。

この規則は改訂01にも存在する。改訂02で追加されたのではない。今回の意味は、その運用上の取引を含む文書が現段階のレビューに達した点にある。有効期限を強制停止線ではなく、例外の発生を告げる境界として扱う設計が、合意形成の対象になっている。

RFC 2205 のRSVPは資源予約をシグナルし、RFC 3209 はトラフィックエンジニアリングへ拡張した。新草案はINTEGRITYオブジェクトでRSVPメッセージをホップごとに認証する。ここでいう送信者と受信者は、そのホップで隣接するRSVPシステムであり、アプリケーションの端点とは限らない。

オブジェクトには48ビットのKey Identifier、64ビットのシーケンス番号、認証データが入る。受信者はKey Identifierと送信元アドレスの組でアソシエーションを選ぶ。アソシエーションには暗号変換、認証鍵、対象インターフェースまたはピア、開始・終了時刻も含まれる。方向ごとに別物である。

これが証明する範囲は限られる。設定鍵を持つ隣接ピアが、受信者の認める新しいシーケンス位置でメッセージを作った、という証拠である。暗号化ではない。予約要求の業務上の権限、 admission control の判断、データプレーンの転送、サービス提供の完了までは証明しない。メッセージの真正性を網全体の現実へ膨らませてはならない。

再送防止には再起動時の問題がある。シーケンス番号は鍵の寿命中、重複せず単調増加しなければならない。受信者が再起動して現在位置を失えば、古いメッセージが新しく見える余地が生じる。草案はIntegrity Handshakeの実装を必須とし、既定で有効にするよう勧める。受信者が予測困難なcookieを送り、送信者は現在のシーケンス番号とともに認証済み応答で返す。

各RSVPセッションは、このハンドシェイクを使うか、安定記憶にシーケンス状態を保存しなければならない。RFC 4086 と RFC 8937 は乱数の質を支えるが、どの受信者が交換を終えたかという運用証跡にはならない。

鍵交換は一時点の作業でもない。実装は少なくとも二つのアソシエーションを同時に扱う。新しいものを古いものの終了前に開始し、時刻の不確実性の二倍以上を重ねる。草案は五分で足りる場合が多いと記す。さらに、すべての受信者が新しいアソシエーションでハンドシェイクを行う必要がある。

したがって「新鍵を設定済み」は完了条件ではない。同じピアまたはインターフェース範囲に適用され、信頼できる時計の上で有効になり、送信者が使用し、受信者が選択でき、安全なシーケンス開始点を得て初めて後継となる。台帳上に二つの鍵があっても、この連鎖が欠ければローテーションは終わっていない。

時刻配信も信頼境界の内側に入る。草案は十分な同期を求め、時刻配信を認証するよう勧める。RFC 5905 はNTPv4を定義するが、設定欄にNTPと書かれているだけでは、現在のずれや時刻源の健全性を証明できない。

有効な後継がある通常時、古い鍵への扱いは厳しい。期限切れアソシエーションを指すパケットは、暗号計算の前に破棄しなければならない。セキュリティエラーはレート制限付きで記録することが推奨される。後継が使えるのに送信者が古い鍵を選び続けることを許さない。

ところが後継が一つもない場合、結果は逆になる。期限切れアソシエーションを、期限内であるかのように検証へ使う。これは古い暗号への免罪符ではない。最後に確認された認証関係を維持し、未認証への後退と予約断絶を同時に避ける選択だ。

最大の弱点は、成功して見えることにある。通信が続けば、修復の優先順位は下がる。アラートは担当不明のキューに残り得る。「無期限」という文言には第二の自動停止がなく、管理操作だけが例外を終わらせる。

鍵管理は草案の外に置かれている。手動配布への対応は必須で、手動鍵を永久にする設定も可能だが推奨されない。暗号変換はIANAレジストリで拡張する。従来のHMAC-MD5形式との互換性も残る一方、RFC 6151 はその安全性を慎重に扱う理由を示す。アルゴリズムの選択肢が増えても、新しい秘密が正しい隣接点へ届くわけではない。

必要な運用記録は、期限という一フィールドではなく移行全体を追うべきだ。Key Identifierと送信元、ピア・インターフェース範囲、暗号変換、開始・終了、後継識別子、重複時間、時計のずれ、想定受信者、個々のハンドシェイク、期限後に初めて受理したメッセージ、通知の送達と確認、例外を終えた管理操作を結ぶ。秘密鍵そのものは記録せず、状態の来歴を残す。

Heng Luの動いているコードを優先する原則に従えば、有効期限は記号であり、実際のパケット処理が現実である。最小初期仕様は共通規格を狭く保ち、例外判断をローカルへ残す。現実の層は、「期限切れ」という名称と、信頼が実際に止まったという事実を区別する。

最後の鍵が切れた瞬間、プロトコルは答えを出さない。認証された経路を保ち、警報を上げ、誰かが責任を持って移行を完了するのを待つ。

情報源