要約

  • リポジトリ収集と検証は全地点で同時に完了しないため、到達可能な二台のRPKIバリデーターが異なる検証済みペイロード集合を示すことがある。
  • ルーターが参照するキャッシュを選択・変更すると、起点検証の根拠も変わり得る。可用性とポリシー権限は別の統制である。
  • 不一致対応には、検証集合の指紋、収集結果、ルーター割り当て、決定責任者、切替条件、ロールバック証拠が必要だ。

保守時間帯に、バリデーターAとBはいずれも正常で、RTRセッションも接続中、赤いアラームもない。しかしAは直近のROA撤回を反映した収集を完了し、Bは一つの公開ポイントについて以前の検証済みオブジェクトを保持している。Aにつながるルーター群とBにつながる群は、同じプレフィックスと起点ASを別の状態に分類し得る。

プロトコル故障がなくても、この状態は生じる。RFC 7115は世界のRPKIを疎に整合するものとして扱う。公開、取得、検証、配布は別々の時刻で進む。複数のrelying partyは入口を増やすが、世界同時の単一回答を作るわけではない。

検証キャッシュは受動的なコピーでもない。リポジトリのオブジェクトを集め、有効性を判断し、その結果をルーターへ提示する。AからBへの切替は接続を回復させる一方、ローカルな経路ポリシーが参照する起点認可を変える可能性がある。自動切替も運用上の選択を実行している。

RFC 9286では、nextUpdateを過ぎたmanifestはstaleとなり取得失敗として扱われるが、影響は一つの公開ポイントに限られる場合がある。RFC 8182はRRDPのセッション、シリアル、ハッシュを個別に検証させる。snapshotへの移行は定義済みの回復経路であり、それだけで誤りとは言えない。検証が完了したか、どの状態を受理したかが重要だ。

RFC 8210はルーター側の境界を置く。ルーターはEnd of Dataまで完全な応答を受けてからキャッシュ状態を採用し、refresh、retry、expireが再照会と保持を左右する。接続が緑でも、二台の出力が同じこと、全ルーターが同じ更新を終えたこと、切替がポリシー中立であることは証明されない。

監視画面は稼働数ではなく、出力と依存関係を比較すべきだ。各バリデーターについて、検証集合の安定した指紋、最後に完全成功した収集、失敗した公開ポイント、トラストアンカーと例外設定、利用中のルーターを保持する。差は調査の起点であって、どちらが正しいかの自動判定ではない。

APNICが掲載する運用事例も、複数バリデーターとクライアント接続の監視を勧める。二つのプロセスを動かすだけではなく、各々が何を提供し誰が使っているかを観測することが要点だ。

情報源