要約

  • BGPポリシーは変更前も変更後も正しく、それでも移行中だけ危険になり得る。コマンドを即時反映する装置では、拒否条件を追加する前に許可規則が有効になったり、並べ替えで削除した規則が障害後も欠けたまま残ったりする。
  • 改訂03は、この問題を原子的な切り替え、規則順序、制御プレーン負荷、冪等性、生成失敗時の方針まで一つの運用課題として扱う。成功応答だけでなく、実効ポリシーと経路差分の証拠が必要だ。

運用者が確認した差分は、二つの規則の順番を入れ替えるだけだった。ところが装置にとっては、古い規則を削除し、新しい位置へ追加し、別の規則を削除し、また追加する四つの出来事である。その最初の削除と次の追加の間には、拒否されるはずの経路が通れる時間が存在する。

変更後の設定を読んでも、その時間は見えない。

2026年10月2日に公開された Current Options for Securing Global Routing 改訂03の重要性はここにある。これはIETF GROW作業部会の進行中のInternet-Draftで、IETF stream、想定ステータスはInformational、有効期限は2027年4月5日である。RFCでも最終合意でもなく、BCPでも製品試験でも、特定ネットワークで漏えいが起きたという報告でもない。文書自身が、現時点の非網羅的かつ非権威的な選択肢集だと明記している。

それでも、静的な「正しい設定」から、時間を含む「安全な変更」へ議論を動かす材料になる。

未完成の規則も実効状態になる

ルーターの設定方式には大きな差がある。複数の変更を候補状態に置き、検証してから一括コミットできる方式もあれば、各コマンドを受けた瞬間に実行する方式もある。意図した最終設定が同じでも、途中で通過する状態は同じではない。

草案のroute-map例では、新しい規則を作り、action permit を設定し、その後にlarge community条件を追加する。即時実行型では、二番目の操作が終わった時点で許可規則が動く。上流から学んだ経路を拒否する規則より前に置かれていれば、条件のない未完成規則がすべてを許し、上流経路をピアへ輸出し得る。

これは単なる入力順の失敗ではない。インターフェースが構築途中の表現を本番の権限判断に昇格させる設計である。事前レビューは望ましい状態を検査し、事後取得は収束した状態を検査する。しかし経路を実際に許可したのは、その間の実効状態だ。

望ましいポリシーファイルはコントローラーの意図を表す。実効ポリシーは、ルーターがいま受け入れ、広告する権限を決める。両者が一致しているという前提を、変更中には置けない。

並べ替えは削除を伴う

草案は、上流由来のプレフィックス、bogon、RPKI Invalidを順に拒否し、残りを許可する輸出ポリシーを例にする。目的はbogonとRPKI Invalidの位置を交換するだけだ。

非原子的な装置では、古いbogon規則の削除、空いた位置へのRPKI規則の追加、古いRPKI規則の削除、新しい位置へのbogon規則の追加という操作になり得る。最初の二つの間ではbogonが通る。さらに処理が削除直後に止まれば、その状態は一瞬ではなく稼働設定になる。

「窓は短いはずだ」は検証結果ではない。制御プレーンが高負荷なら、各操作の反映は遅れる。管理クライアントのタイムアウトは、装置がロールバックしたことを意味しない。再試行は、すでに一部が変わった状態へ同じ操作を重ねるかもしれない。

草案が示す対策は、完全な新ルールセットを別名で構築し、隣接セッションの参照を新しいものへ切り替え、確認後に旧セットを削除することだ。危険な操作を多数の内部編集から一つの参照変更へ狭める。

ただし参照変更そのものが原子的かは、製品と実装に依存する。NETCONFのcandidate/running datastoreとcommitは、段階的構成のプロトコル例を与えるが、あらゆる経路評価が同時に切り替わると証明しない。NMDAがintendedとoperationalを分けるのも、最終的に問うべきものが実際の運用状態だからだ。

規則順序は負荷と危険時間を決める

条件の順番は意味だけでなく、同じ結論へ到達するまでの計算量を変える。改訂03は、100万件のIPv4 NLRIを送るピアのうち、許可されたconeに属するものが60件だけという仮想例を示す。

効率の悪い順序では、二つのcommunityを付与し、private AS、bogon、RPKI Invalidを確認した後で、ようやくcone外の経路を拒否する。草案の計算では5,986,500操作になる。選択性の高いcone拒否を先頭に移すと1,000,300操作まで減る。

これは特定製品のベンチマークではなく、草案内の説明用数値である。実際のコストは実装に依存する。草案がscalar、tree lookup、list lookup、正規表現という相対的な検討順を示すのも、絶対値を保証するためではない。

それでも運用上の連結は明確だ。不要な検査で制御プレーンを消費すれば、同じ制御プレーンが変更を完了する余力が減る。複数隣接からの大量入力が重なれば、非整合状態の寿命も延びる。規則順序は、判定意味、資源消費、移行危険時間の三つを同時に決める。

冪等性は原子性ではない

草案は、プレフィックスフィルターを専用システムで生成し、内容が変化した時だけ配備することを勧める。これは価値ある冪等性で、同一入力による無用なルーター作業を防ぐ。

しかし、何度実行しても同じ最終状態になることと、途中状態を公開しないことは別だ。配備処理は完全に冪等でも、初回には毎回危険な中間状態を通れる。内容が誤ったまま不変なら、誤りを効率よくスキップするだけでもある。

証拠は分けて残す必要がある。生成器の入力、望ましいポリシー、生成済み装置設定、変更前の実効状態、ステージ検証、起動応答、変更後の実効状態、観測された経路差分。それぞれのdigestと時刻を持たせる。「deployed」という一つの成功状態では、どこまで確認したか分からない。

生成失敗時の既定値も経路政策である

規則生成は失敗する。改訂03は、出力が突然巨大化、縮小、空になるといった異常を検査するよう促す一方、失敗時の選択は管理者に委ねる。

全許可は到達性を守る代わりに境界を失う。全拒否は境界を守る代わりにトラフィックを上流へ偏らせ、より大きな障害を起こす可能性がある。旧ルールセットの再利用は安定を保つが、変化したプレフィックスを誤って許可または拒否し続ける。どれも中立なソフトウェア既定値ではない。

顧客、ピア、上流、route serverでは結果が異なる。許容する陳腐化時間、トラフィックへの影響、判断責任者、生成ポリシーへ戻る条件を、障害前に定めるべきだ。

RFC 8212の、ポリシーがないeBGPセッションで既定拒否とする考えは重要な下限である。しかし「存在するポリシーA」から「存在するポリシーB」へどう安全に移るかまでは証明しない。RPKI origin validation、BGP Roles、OTCも有用な判定材料だが、それを導入する操作をトランザクションにはしない。