要約

  • draft-geng-grow-bmp-monitor-options-00 は、BMP の RIB ビューと統計項目について Enable／Disable を帯域内で宣言する仕組みを提案する。00 版は個人提出の作業中ドラフトであり、メッセージ型 TBD2 は未割り当てである。
  • RIB の Disable は破壊的な状態変更である。コレクターは該当する <Peer, AFI, SAFI> の保存済みビューを直ちに purge する。相互認証は通信路を守るが、運用者の承認、正確な範囲、消去証跡、再有効化後の完全性までは証明しない。

一時間、新しいルートが届かなかった。経路表が安定していた可能性もあれば、ルーターが特定アドレスファミリーの監視出力を止めた可能性もある。BMP セッションはどちらでも正常に見える。原因を示す信号がなければ、古い表が「現在の観測」として残り続ける。

2026 年 9 月 30 日付の BMP Extension for Monitoring Options (MO) Notification は、この違いをプロトコル上で表そうとする。Standards Track を想定した個人 Internet-Draft の revision 00 で、有効期限は 2027 年 4 月 3 日。RFC でも、ワーキンググループ合意でも、実装実績でもない。TBD2 は IANA による割り当てを求める仮値にすぎない。

「何も届かない」には理由が含まれない

RFC 7854 は BGP のピア状態、ルート、統計を構造化して出力できるようにした。RFC 8671 は Adj-RIB-Out、RFC 9069 は Local RIB の観測を追加した。それでも、送信側の監視設定が変更された事実をセッション内で伝える方法はなかった。

提案される RIB Options PDU は、Adj-RIB-In、Adj-RIB-Out、Loc-RIB を区別し、Pre-Policy と Post-Policy を分け、Enable／Disable フラグと AFI/SAFI のリストを運ぶ。Common Header の後に Per-Peer Header が付く場合もある。統計向けには別の形式がある。

これらのフィールドが影響範囲を決める。「BMP を停止した」という一行だけでは監査証跡にならない。送信者、ピア、RIB の面、ポリシー段階、AFI、SAFI、時刻を保持して初めて、何が対象だったかを説明できる。

通知がデータベースを変更する

ドラフトの手順は明確だ。運用者があるファミリーの監視を無効にすると、送信側は直ちに MO Disable を送る。受信したコレクターは、無効化された <Peer, AFI, SAFI> ビューに属する保存済み RIB エントリーをすべて直ちに purge しなければならない。

観測を失ったデータを現行情報として残さないための合理的な措置である。同時に、メッセージの性質は単なるテレメトリーから破壊的な管理命令へ変わる。トポロジー解析、経路漏えい検知、ポリシー検査、フォレンジックは、正しい purge で古い情報から守られる一方、範囲を誤った purge では視界を失う。BMP セッションの緑表示だけでは区別できない。

ドラフト自身も、偽の Disable を送る未承認 MO によって監視データベース全体を purge させられる危険を挙げ、相互認証と TLS などのトランスポート保護を必須としている。

ただし TLS が証明するのは、保護されたセッションの相手と通信中の完全性である。誰が変更を承認したか、AFI/SAFI が正しいか、認証済みルーターが侵害されていないかは証明しない。メッセンジャーの身元と、指定できるすべての削除への権限は別物だ。

ライブ状態と履歴証拠を分離する

「直ちに purge」は、運用中の保存 RIB ビューに対する規定である。00 版は完全な保存制度を定めず、別系統の改変不能な履歴を禁じてもいない。

したがって、観測されなくなったビューをライブ系から即座に外しながら、直前のハッシュ、履歴コピー、変更記録をローカル方針で保管できる。履歴は明確に historical とし、現行ビューとして利用してはならない。逆に「削除成功」だけのログも弱い。対象ビューと件数が分からなければ、何が変わったかを立証できない。

強い証跡は、承認済み変更、認証済みセッション、ワイヤ上の範囲を結び付け、削除した項目、意図して残した項目、処理結果を残す。コレクターは状態を変える前に、形式不正や送信者の役割を超える範囲を拒否できなければならない。

Enable は復旧開始であって完了ではない

再有効化では、Enable を送り、続いて Route Monitoring メッセージを再開する。コレクターは到着するメッセージからビューを再構成する。

しかし revision 00 は、スナップショット開始、期待件数、終了、完全性判定を定義していない。最初の一経路は取り込み再開を証明するだけで、全現行ルートの到着や欠落のなさを証明しない。

部分的に新しい表は、明確に disabled と表示された表より信頼されやすく、かえって危険だ。状態を disabled、rebuilding、current に分け、明示した完全性条件が満たされるまで下流の信頼を戻さない設計が必要になる。

別文書 draft-geng-grow-bmp-rr-sync-00 は、限定ビューの再同期を BoRR と EoRR で囲む BMP Route-Refresh を提案する。これは完全な再同期が別のプロトコル課題であることを示すが、MO の一部ではない。同じく revision 00 の個人提案で、利用可能な標準機能とみなせない。

消去権限には連続した証跡が要る

仕様と実装の正確な版、相互認証された両端、承認済み変更、Peer・RIB type・policy subtype・AFI/SAFI、送信者の権限、削除と保持の実績、履歴保全、対応する Enable、再構築期間と完全性条件、その後の下流利用再開を順に記録する。

前段は後段を証明しない。有効な証明書は範囲を検証しない。正しい形式の Disable は承認を証明しない。成功した purge は履歴保全を保証しない。Enable は完全な表を意味しない。

Lu Heng の「最小初期仕様・将来判断の局所化・自発的採用」は、この境界を整理する。共通仕様は相互運用に必要な決定的フィールドと遷移だけを定めればよい。保存、承認、影響範囲、再信頼の基準はリスクを負う運用者が決める。採用を証明するのは文書の公開ではなく、稼働コード、処理証跡、閉じた再構築である。

観測メッセージが観測結果を消せるようになった時点で、それは証拠システムの制御面に属する。

出典