要約

  • RFC 8212 は EBGP の接続確立を妨げない。その代わり、明示的な受信ポリシーがなければ受信経路を選択対象にせず、送信ポリシーがなければ Adj-RIB-Out に載せない。
  • 受信と送信、さらに AFI/SAFI ごとは別々の権限である。明示的な permit all でも形式要件は満たすため、標準が防ぐのは「設定忘れ」であって、誤った許可そのものではない。
  • 新規導入機とアップグレード機では既定値が異なり得る。安全な移行は、設定名ではなく、実効モード、適用済みポリシー、前後の経路集合、相手側観測、FIB と実パケットで証明する。

深夜、旧ルーターから新ルーターへの切り替えが完了する。TCP 179 は接続し、OPEN で能力を交換し、有限状態機械は Established に到達した。運用者はセッション稼働時間を見て「BGP は上がった」と判断する。ところが FRRouting の表示には (Policy) が付き、IPv4 の利用可能経路はゼロのままだ。別テンプレートを継承した IPv6 だけは、小さな集約経路を広告している。

これはセッション障害ではない。一台の装置の中で、二つのアドレスファミリーと二つの方向に対する権限が別々に決まった結果である。ここで「早く直す」ために全体の要件を無効化したり、無条件許可を貼り付けたりすると、限定的な無経路状態を、境界のない経路漏洩へ変えてしまう。

接続は経路利用の委任状ではない

RFC 4271 は、BGP の状態機械と各 Routing Information Base を分けている。OPEN と KEEPALIVE の交換に成功したことは、相手を BGP 話者として認識した証拠にはなる。しかし、受け取った経路を選択に使うことや、自分の経路を外へ公開することまで承認した証拠にはならない。

受信方向では、UPDATE が Adj-RIB-In または実装上の pre-policy 表に見えても、明示的な Import Policy がなければ Decision Process の候補にしてはならない。したがって、パケットキャプチャに UPDATE があるのに Loc-RIB が空という状態は成立する。「相手が送っていない」と「こちらが採用を許可していない」は、調査上まったく別の命題だ。

送信方向では、経路が Loc-RIB と FIB に存在してローカル転送に使えても、Export Policy がなければ特定の外部隣接に対する Adj-RIB-Out へ入らない。自網内で疎通することは、外部から到達できることの証明ではない。

この分離が RFC 8212 の権限境界である。相手は経路を提示できるが、受信者に採用を強制できない。自分が保有する経路も、外部セッションが存在するだけでは公開の根拠にならない。両方向とも、ローカル側の明示的な行為が必要になる。

二つの門はアドレスファミリーごとに増える

受信と送信は一つの相互スイッチではない。デフォルト経路だけ受け取り、顧客プレフィックスだけを広告する構成もできる。保守用集約だけを送って受信は全拒否することも、IPv6 を先に許可して IPv4 は閉じたままにすることもできる。

この多重性が、非対称な現象を生む。IPv4 の受信ポリシーだけ欠ければ、IPv4 のローカル経路はゼロでも送信は動く。IPv6 の送信だけ欠ければ、学習した IPv6 経路を自網で使えても、相手は戻り経路を受け取れない。単に Established と書かれた監視バッジは、診断に必要な差を潰してしまう。

台帳には、隣接、VRF、ローカル AS、リモート AS、AFI/SAFI、方向、アタッチ位置を明記すべきだ。「neighbor にポリシーあり」では不足する。peer-group が一方向だけを供給し、個別 neighbor の上書きが別方向を消す場合もある。生成設定にオブジェクトが存在しても、実際に動く address-family へ結び付いていないこともある。

Minimum Initial Specification の価値は、ここでは共通の許可内容を決めることではなく、未決定を暗黙の全許可にしないことにある。どのプレフィックス、起点、AS_PATH、コミュニティ、取引関係を認めるかは各運用者が決める。共通の最小条件は「不在は伝播ではない」という一点だ。

明示的であることと安全であることは違う

RFC 8212 が修正するのは、許可設定を忘れたときの危険である。ポリシーの内容までは評価しない。意図的に設定した permit all も明示的なポリシーだ。BIRD の文書も、外部 BGP に入出力ポリシーを要求しながら、明示的な all と none を有効な選択肢として扱う。

これは標準の抜け穴ではない。プロトコルの安全既定値と、各運用者の裁量を分けるために必要な線引きだ。実験環境、route server、短期移行では全許可が合理的な場合もある。同じ文をインターネットトランジット境界に置けば壊滅的になり得る。構文だけでは契約関係を判定できない。

名前付きフィルターも安心材料にはならない。参照先の prefix-set が空、IRR 生成物が古い、コミュニティ体系が違う、旧版のポリシーが読み込まれた、といった失敗がある。peer-group に付いた route-map が個別設定で上書きされることもある。存在確認は最初の門にすぎない。

証拠には名称だけでなく、解決後の内容とハッシュを残す。受信では pre-policy の入力と post-policy の適格経路、選択理由を比較する。送信では export 前の候補、Adj-RIB-Out、実際に相手が観測した集合を比較する。ゼロという結果は、ポリシー不在、明示拒否、有効な許可に一致する経路なし、のどれかが特定されて初めて意味を持つ。

移行期には既定値が二分する

RFC 8212 は実装が逸脱用オプションを提供することを認め、非規範の移行案で N+1/N+2 の段階を説明している。先に insecure mode と警告を導入し、次の段階で新規導入の既定値を拒否側に変える。旧リリースから更新した装置は以前の挙動を保持し、同じバージョンを新規インストールした装置は拒否側になる可能性がある。

そのため、同じソフトウェア版と似た neighbor 設定でも結果が逆になる。片方は移行状態により暗黙に全受信し、もう片方は新規導入なのでゼロになる。表示された設定をコピーしても、導入履歴という見えにくい来歴まではコピーされない。

FRRouting は ebgp-requires-policy、無効化コマンド、ポリシー欠如時の (Policy) 表示を提供する。BIRD 3.3.0 は外部 BGP に明示的な入出力ポリシーを求める。どちらも有用な観測面だが、全環境に共通の保証ではない。証拠となるのは、実際のリリース、起動履歴、生成済み設定、ランタイムで有効な値である。

insecure mode の例外には、所有者、理由、対象 peer と family、実際に許可される経路集合、期限、解除試験を付けるべきだ。期限のない移行用逃げ道は、やがて誰も認識しない恒久アーキテクチャになる。

ポリシー有効化は設定ではなく状態遷移である

フィルターを追加しても、以前に受信した UPDATE が自動的に再評価されたとは限らない。実装は pre-policy 表を保持して再計算することも、Route Refresh を要求することも、保存データを再生することも、セッションリセットを必要とすることもある。RFC 2918 の Route Refresh は相手に現在の広告を再送させるが、能力交渉と相手の現在ポリシーに依存する。

したがって、有効化経路を変更計画に含める。Import Policy が有効になったとき、経路が保存済み Adj-RIB-In、refresh、再接続のどれから現れるかを把握し、件数と属性を事前に予測する。

送信側の有効化はさらに危険になり得る。Loc-RIB にすでにある数千経路が一度に適格化するからだ。ポリシーエンジン側で Adj-RIB-Out の正確な差分を計算し、相手側でも期待した集合を確認する。受信と送信を同時に変えると、到達性や漏洩を生んだ権限がどちらか分からなくなる。

最初は両方向を明示 deny にし、小さな受信 canary、次に小さな送信 canary を許可する。各遷移を観測し、差分が承認済み契約と一致してから範囲を広げる。

default reject は土台であって完成した防御ではない

RFC 7454 は関係別の prefix、AS_PATH、community フィルターを説明する。RFC 7908 は伝播前提に反する route leak を分類する。RFC 9234 は BGP Roles と OTC により一部の関係を機械可読にする。RPKI の origin validation は、ある AS がプレフィックスの起点として承認されているかを検査できる。

いずれも明示的な方針の代わりにはならない。起点が valid でも不要な経路はある。OTC は顧客プレフィックス集合を定義しない。maximum-prefix はある数え方に基づいて状態量を制限するが、どの経路を受け入れるべきかは決めない。default reject が保証するのは、未設定が自動的な許可へ化けないことだけだ。

二次的な利点は組織に現れる。空の既定値は、誰かに許可内容を名付け、所有させる。三次的な危険は儀式化だ。デプロイ表示を緑にするためだけに万能 allow を作り、実際の関係を考えなくなる。

Running Code を優先するなら、設定文は意図の記録にすぎない。コンパイル済みポリシーとアタッチ関係が実行入力を示し、前後の RIB が制御面の効果を示す。相手側観測が境界通過を、FIB とパケットが運用上の到達性を示す。

canary は「何も流れない」状態から始める

影響範囲の小さい peer または隔離した family を用意する。入出力ポリシーなしでセッションを確立し、OPEN と KEEPALIVE は成功するが、適格経路はなく Adj-RIB-Out も空、という期待どおりの基線を確認する。pre-policy 受信が見える実装では、それも記録する。

次に両方向へ明示 deny を付ける。件数はゼロのままだが、ランタイム上は「既定不在」から「意図したゼロ許可」へ変わる。ポリシーの識別子、ハッシュ、有効化経路を保存する。

受信方向で sentinel prefix を一つだけ許可し、属性、post-import 表現、選択結果、FIB next hop を予測する。転送まで主張するならパケットも確認する。その後、送信側で sentinel prefix を一つ許可し、Adj-RIB-Out の正確な符号化と相手側観測を照合する。

全 AFI/SAFI と方向で繰り返す。意図的に不一致にした経路、invalid origin との比較、関係属性、prefix-length 境界を含め、許可の外側も証明する。rollback は狭い許可を外し、withdrawal を確認して既知の空状態へ戻す。RFC 8212 を全体で無効化することは rollback ではなく、すべての未設定 peer に権限を広げる操作だ。

Established で経路ゼロという状態は、未完成なインフラとは限らない。それは「通信路はあるが、経路権限はまだ与えられていない」という精密な宣言になり得る。安全なシステムはその宣言を可視化し、取り消し可能にし、沈黙を到達性へ変える前により強い証拠を要求する。