要約

  • Breizh-IXは、毎晩厳格な経路フィルターを生成し、RIRのROAなどを確認し、PeeringDBの「Never via route servers」設定を尊重すると説明する。RIPE 93で紹介するRS-API案は、AS-SET照合、経路数の妥当性、参加者の再広告意思を三つの確認事項に分ける。
  • PeeringDBはその設定を交換点へのヒントと呼ぶ。意思表示を実際のBGPポリシーに反映し、いつ有効になったかを示す責任は交換点の運用側にある。

三つ目の検査は、照合では終わらない

経路サーバーに届いたプレフィックスが、参加者のAS-SETからたどれる。登録されたrouteオブジェクトもある。件数も想定内だ。そこで自動化を完了させると、最後の問いが置き去りになる。参加者はその経路を、サーバー経由で他のネットワークへ配ってほしいのか。

Breizh-IXのEvann DreumontとAlarig Le LayがRIPE 93の公式概要に並べたのは、まさにこの三段階だ。IRRのAS-SETへの所属、経路数の整合性、そして顧客の再広告の希望。集合の中に別の巨大な集合が入れば、展開した経路数は一気に膨らむ。件数の検査はその事故を拾うためにある。しかし、少ない件数も正確な登録も、相手への配布を承諾した証明にはならない。

RFC 7947にある経路サーバーの役割は、複数のBGP参加者の間で経路情報を仲介することだ。各社が一社ずつ接続を設定する手間を減らせる反面、仲介点のポリシーが再配布の範囲を決める。登録簿を更新する人、経路を出す人、他の参加者に見せる設定を行う人は同一とは限らない。RS-APIの課題は、これらの判断を一つの「正しい経路」というラベルで覆わず、別々に記録することにある。

データベースのチェックと、動いている設定

Breizh-IXの公式サイトは現行運用を具体的に記している。レンヌに拠点を置く非営利のボランティア団体で、bgpq4のstrictモードを使い毎晩プレフィックス一覧を生成する。routeオブジェクトのないプレフィックスは拒否する。RIRのRPKIによるROAとOTC属性も検査し、二台目のサーバーではASPAを確認する。PeeringDBの「Never via route servers」も尊重すると明記している。これは運用者による説明であり、RS-APIの導入実績を示す資料ではない。

PeeringDBの公式FAQでは、同じ設定のAPI項目名はinfo_never_via_route_serversだ。FAQはこの項目を交換点への「ヒント」と表現し、交換点が定期的に確認して反映する必要があるとする。画面上のチェックは参加者の意向を伝える。経路サーバーの設定を変えるのは交換点だ。この間に、読み取り、評価、設定の配布、動作確認という四つの行為が入る。

時刻も重要になる。参加者が午後に設定を変え、IRR由来の一覧は夜間に更新されるとして、PeeringDBの値が何時に読み込まれ、どちらのサーバーに何時に届くのか。今回確認した公開資料には、その一件ごとの時刻は載っていない。Breizh-IXで問題が起きたという話ではない。参加者が「もう配らない」と決めた時刻と、経路が実際に止まった時刻を結ぶ記録が必要だ、という設計上の話である。

経路数の上限も、単純な数字では済まない。AS-SETを正確に再帰展開しても、途中の集合が意図しない大量の経路を含めば、生成されたフィルターは大きくなる。上限を高く設定すれば検出の役に立たない。RIPE 93の概要はRS-APIを既存の道具を束ねる代理層として紹介するが、公開コード、採用件数、誤判定率は示していない。今あるのは検証可能な設計課題だ。

受理と再配布を同じ一行にしない

参加者に渡せる判断記録なら、参照したAS-SETとrouteオブジェクト、展開後の件数、上限値、PeeringDBの取得時刻、稼働中の設定版、実際に広告した相手をつなげられる。拒否された経路については、どの検査で止まったかを示す。通った経路については、なぜ他の参加者へ配ったかを示す。後者を省くと、技術的に受理された経路が、いつの間にか参加者の代理発言になる。

資料に残る欠落は、情報がないときの既定動作だ。PeeringDBに接続できない場合、古い設定だけが残る場合、複数の情報が食い違う場合にRS-APIは何を優先するのか。公開された規則と、その規則が適用された時刻の証拠が出れば評価できる。経路数は機械が数えればよい。誰の意思で配ったかは、機械を動かす組織が答える番だ。

出典