Summary

  • draft-acee-lsr-ospfv3-deprecate-ah-00 は、新しい OSPFv3 実装で IPsec AH を実装しないよう求め、ESP の NULL 暗号化または OSPFv3 Authentication Trailer への移行を促す。00 版は個人 Internet-Draft であり、承認済み標準ではない。
  • 非推奨という状態はリンクを再設定しない。全ルーターが新方式を受信できるようにしてから送信を切り替え、隣接、LSDB、転送を確認した後に旧方式を閉じる必要がある。

保守開始直後、ルーター A が新方式で Hello を送る。B には鍵があるが、正しい受信 SA がない。C のソフトウェアは対応しているものの、そのインターフェースでは無効だ。D は AH しか受け付けない。四つの管理画面がすべて緑でも、最初の Hello は互換集合が成立していないことを示す。

2026 年 9 月 30 日付の Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication 00 版は、Standards Track を意図した個人草案で、承認されれば RFC 4552 を更新する。RFC ではなく、ワーキンググループ、ベンダー、運用者の採用実績でもない。

RFC 4552 は ESP の対応を必須とし、AH を許可している。草案は、新規実装では OSPFv3 認証用 AH を実装しないこと、既存実装は互換性のため警告付きで残せること、運用者は ESP-NULL または RFC 7166 の Authentication Trailer に移ることを提案する。

ESP-NULL がここで提供するのは完全性と認証であり、機密性ではない。Trailer は IPv6 送信元アドレスもダイジェストに含める。どちらも、有効な共有鍵を持つ侵害済みルーターを排除する仕組みではない。

文書の状態とリンクの状態は別物だ

草案は、OSPFv3 での AH 採用が限定的で、RFC 8221 では実装が任意となり、AH と ESP の別々のコード、設定、手順を保つ負担が大きいと説明する。通常の OSPFv3 はリンクローカルアドレスと Hop Limit 1 を使うため、AH が不変 IPv6 ヘッダーを覆う追加価値も限られるという。

これは設計上の判断であって、製品調査ではない。ましてオンライン交渉ではない。草案の公開だけで鍵、SA、受信条件、送信開始時刻が揃うことはない。

00 版は、OSPFv3 インターフェースまたは仮想リンクが一つの認証方式を使い、リンク上の全ルーターが一致しなければならないと明記する。安全な変更単位は一台のルーターではなくリンク全体である。

新方式を受け入れてから、新方式で送る

RFC 4552 の鍵更新手順は順序を示す。まず全ルーターに新しい受信 SA を追加する。全台が受信可能になってから送信 SA を変える。全台が新 SA で送るようになった後で旧受信 SA を削除する。

AH から ESP への移行は単なる鍵更新ではないが、「新を受信、新で送信、旧を退役」という原則は共通する。各境界でリンク全体の証跡が要る。

草案は、保守時間に全台へ代替方式と鍵を準備する方法と、移行中に複数方式を受信できる実装だけを使う段階方式を示す。その能力は稼働中のビルドと対象インターフェースで確認すべきで、製品名から推定できない。

重複期間は継続性と引き換えに受理範囲を広げる。短すぎれば隣接が分断され、長すぎれば旧経路が残る。責任者、対象一覧、開始・終了時刻、証跡不足時の停止条件が必要だ。

Full だけでは、どの経路で受理したか分からない

ESP-NULL は IPsec の SA と手動鍵モデルに残る。Authentication Trailer は OSPFv3 とともに運ばれ、SA ID と単調増加する 64 ビット暗号シーケンス番号を使う。

RFC 7166 の任意移行モードは Trailer を送信しながら、Trailer のないパケットも受理できる。旧隣接を保てる一方、移行期間に未認証データへ露出し得ると RFC 自身が警告する。

従って、隣接 Full は十分な証拠ではない。新方式、旧方式、互換モードのどれで受理されたかを記録する必要がある。有効なダイジェストは共有鍵へのアクセスを示すが、個人の身元、機器の健全性、各 LSA の権限までは証明しない。

旧経路を閉じて初めて移行が終わる

証跡は、正確な草案版、各実機の対応、受信 SA または Trailer と鍵世代、送信切替、認証済み Hello と Database Description、全隣接の安定 Full、LSDB 収束、FIB と通信試験、旧 AH または緩い受理の削除、という順に分ける。

一段は次段の代わりにならない。旧経路で Full が維持されることも、LSDB が揃って FIB が違うこともある。重複期間中の通信成功では、新方式が支えたとは断定できない。

Heng Lu の最小共通仕様、将来判断の局所化、自発的採用、稼働コード優先という枠組みは、役割を明確にする。標準は相互運用の最小条件を示し、運用者は方式と時間を決める。採用を閉じるのは、実際のパケット、隣接、データベース、転送の証拠である。

経営上の問いは「AH が非推奨になったか」ではない。「全ルーターが同じ新しい証明と鍵世代を受理し、旧経路が本当に閉じたか」である。

Sources