要約

  • BGP Role により、隣接ネットワークは経路交換前に Provider、Customer、Peer、Route Server の想定を照合でき、確認された不一致は eBGP セッションの成立を止められる。
  • OTC は経路とともに伝搬境界を運ぶが、商業契約を認証せず、明示的な import/export ポリシーを代替せず、プレフィックスごとに変わる複雑な関係も表せない。

分析

経路リークは偽の起点と同義ではない。RFC 7908 は、学習した BGP 経路が意図した範囲を越えて伝搬することと定義する。宛先と起点が正しくても、ある上流から別の上流へ、あるいは Peer から Provider へ、本来許されない向きに経路が渡ればリークになる。問題は宛先名ではなく引き渡しの連鎖にある。

従来、その連鎖は主に片側の設定に依存していた。運用者が隣接先を Customer、Provider、Peer のいずれかと見なし、その前提でルートポリシーを組む。相手側が同じ関係を記述しているかをセッション自体が比較する必要はなかった。設定ミス、欠けたフィルター、自動化の不具合が、局所的な誤りを遠方で受理される経路に変え得た。

RFC 9234 は経路交換前に小さく重要な照合を加える。BGP OPEN メッセージは Role Capability を運べる。通常の Role は Provider、Customer、Route Server、Route Server Client、Peer である。双方が Role を通知した場合、Provider と Customer、Route Server と Route Server Client、Peer と Peer という許可された組でなければならない。不整合なら Role Mismatch 通知で接続を拒否する。

これはプロトコル上の整合性検査であって、商取引の判定装置ではない。ルーターはトランジット契約、請求書、トラフィック条件を読まない。双方が一致していても、現実には誤った Role を設定できる。また、プレフィックス、サービス、地域によって関係が変わることもある。RFC はこれを Complex と呼び、そのセッションで Role を使わないよう求める。通常関係ごとにセッションを分割できなければ、プレフィックス単位のポリシーが引き続き必要である。

二つ目の仕組みは UPDATE とともに働く。Only to Customer、略して OTC は、型コード 35 の optional transitive Path Attribute で、4 オクテットの値に ASN を入れる。経路が Customer、Peer、Route Server Client 側へ一度渡ると、その後は Customer 側だけへ進むべきことを示す。

OTC 付きの経路を Customer または Route Server Client から受信した場合、その経路はリークとして不適格になる。Peer から受けた場合も、RFC が定める OTC 値の不整合があれば同様である。送信時には、すでに OTC がある経路を Provider、Peer、Route Server へ広告してはならない。このため、ローカルの誤送信を防ぐだけでなく、数ホップ先でリークを検出できる。

部分導入にも意味がある。Provider、Peer、Route Server から OTC なしで届いた経路に、対応する受信側が属性を付加できる。RFC はこれを早期導入者の利点とする。ただし OTC は暗号学的に保護されない。途中の AS が削除・変更でき、誤った印は正当な到達性を狭める。

後方互換性にも判断がある。一方だけが Role を送り、相手が送らない場合、通常はローカル設定 Role を使ってセッションを続ける。strict mode なら能力を送らない隣接先を拒否できる。RFC 9234 は、ソフトウェア更新後にセッションが立ち上がらなくなる恐れから、strict mode を既定値にしないよう強く注意する。

土台は RFC 8212 である。明示的ポリシーがなければ eBGP 経路を import も export もしない。Role と OTC は起点を検証せず、寛容すぎるポリシーを安全にせず、プレフィックスや AS path の制御を置き換えない。IANA の登録は OTC が属性 35、Role Mismatch が OPEN エラー副コード 11 であることを確認するだけで、特定ネットワークや製品版での導入を証明しない。

情報源