要約

  • 9月30日付の draft-acee-lsr-ospfv3-deprecate-ah-00 は、OSPFv3認証におけるIPsec AHの非推奨化を提案した。新しい実装にはAHを加えないことを勧め、既存実装には互換性のための継続を認めつつ、ESPのNULL暗号化またはRFC 7166の認証トレーラーへの移行を促す。Datatracker上は個人のInternet-Draftであり、RFC 4552の改訂はまだ成立していない。
  • 草案は同一リンク上のルーターが認証方式を揃える必要を明記する。RFC 7166はパラメーターの不一致による隣接形成の失敗を説明し、寛容な移行モードには未認証パケットを受け入れる時間帯が生じ得ると警告する。

認証機能の廃止をソフトウェアの整理としてだけ見ると、影響範囲を見誤る。OSPFv3のHelloを受け取る隣のルーターは、こちらの変更表を読んでくれない。片側のAHを止めても、相手側に対応する方式、鍵、セキュリティーアソシエーションがなければ隣接は戻らない。逆に、隣接を維持するため受理条件を広げれば、暗号上の保証が一時的に下がる可能性がある。この二つの結果を分けて読むことが今回の要点だ。

文書の権威を先取りしてはいけない。草案の表紙にはLink State Routing Working Groupの名があるが、Datatrackerの文書種別は個人提出の有効なInternet-Draft、IESG状態はI-D Existsである。「Updates: 4552 (if approved)」も承認を条件にした記述だ。作成者の改訂案を、採択済みの作業部会案や現行RFCへの強制変更として扱う根拠はない。

代替方式は昔から存在する。RFC 4552は、規格に従う実装にESP対応を必須とし、AH対応を任意としていた。RFC 7166はIPsecに依存しないOSPFv3認証トレーラーを定めた。したがって2026年の提案の新しさは、別の認証手段を発明したことではなく、OSPFv3向けAHを今後の選択肢から外す方向を明示したことにある。既存機器での互換動作は残せるが、非推奨であることを運用者に示すべきだという構成で、ESPに関するRFC 4552の要求は変えていない。

ESPの「NULL暗号化」は無認証と同義ではない。秘匿のための暗号化を行わず、認証と完全性を確保する構成である。一方、認証トレーラーにも固有の鍵と検証手順がある。草案はAH専用のコード、鍵設定、手順を維持する複雑さを理由に挙げ、採用が少ないとも述べる。しかし確認した一次資料にはOSPFv3実運用のAH利用率を測った表はない。著者の評価を普及率の確定値に言い換えるべきではない。

移行について草案の第4節は、インターフェースまたは仮想リンクに設定する認証方式を、参加する全ルーターで合わせるよう求める。保守時間帯に新方式と鍵を揃えてから切り替える案を示し、段階的移行は移行中に複数方式を受け入れられる実装に限る。装置が「OSPFv3対応」であることと、その受理動作を実際に備えることは別の事実だ。全ての製品で無停止切替が可能だとは書かれていない。

RFC 7166の移行節も丁寧に読む必要がある。SA ID、認証種別、ダイジェストが合わなければ隣接は形成されない。同RFCの任意の移行モードは、認証トレーラーを導入する途中で未認証の相手を受け入れる場面を想定し、未認証データへの露出を明示する。これをAHからトレーラーへの安全な自動変換機能だと扱うのは誤りだ。装置固有の併用可否、受理方向、期間を検証しなければ、隣接の回復と完全性の回復を同時に証明できない。

なお、方式変更は有効な鍵を持つ侵害済みルーターへの対策にはならないと草案自身が断っている。本稿が説明するのは提案された仕様上の境界と、そこから生じる運用上の確認点であり、実際の事故、導入状況、ベンダーの機能保証ではない。

出典