要約

  • BGP Flow Specification はパケット条件とフィルター動作を配布する。経路が見えることは制御面の証拠であって、転送結果ではない。
  • 外部ルールは通常ユニキャスト経路で検証され、最良一致経路が変われば再検証が必要になる。
  • 複数ルールや動作は競合し得る。IPv6 の解析深度や機器の制約で、正しいルールを実行できない場合もある。
  • 完了判定には、正確な NLRI と動作を、機器への反映、カウンター、パケット標本、被害側と正常通信の測定へ結び付けた記録が要る。

DDoS 制御装置が一つの宛先とポートを対象にルールを発行したとする。数秒後、ルートリフレクターと三台のエッジ制御面でルールが確認され、事故画面は緑になった。しかし、大容量の入力回線では、ラインカードが上位層条件をコンパイルできず、対象トラフィックが流れ続けた。BGP の観測は正しい。それだけから導いた「遮断済み」という結論が誤りだった。

これは特定事業者の事例ではなく、仮想的な運用場面である。配布された指示と、パケットに対して実行された動作を区別するためのものだ。

経路が実際に運ぶもの

RFC 8955 は、Flow Specification を BGP NLRI 内の n 項組として符号化する。宛先・送信元プレフィックス、プロトコル、ポート、TCP フラグ、パケット長、DSCP、フラグメントなどを条件にできる。パケットは、含まれる全要素の共通条件を満たして初めて一致する。したがって保存すべき最初の証拠は、画面上のルール名ではなく、復号した論理式である。

拡張コミュニティは、バイトまたはパケット単位のレート制限、サンプリング、ルートターゲットへのリダイレクト、マーキングなどの動作を運ぶ。既定動作は通常の転送に従う受け入れで、レートゼロが破棄を表す。期待した動作が失われれば、経路が存在しても遮断は起きない。

同じフローに複数ルールが一致することもある。比較順は BGP の到着順に依存しないが、動作同士は競合し得る。転送段階まで競合が残れば、採用する動作は実装依存となる。制御面の配布が同じでも、装置ごとの結果は同じとは限らない。

検証はユニキャスト状態に追随する

明示設定がない場合、外部 Flow Specification には宛先プレフィックスが必要で、その発信元は最良一致ユニキャスト経路の発信元と一致し、別の隣接 AS から受けたより具体的な経路を巻き込んではならない。設定で最初の条件を緩められるため、検証ポリシーそのものも証拠になる。

最良一致経路は FlowSpec とは独立に変化する。RFC 8955 はそのたびに再検証を求める。収集装置に公告が残っていても、経路変更後には実行対象外となり得る。どこで、どのユニキャスト状態に基づいて検証したかを記録しなければならない。

RFC 8956 は IPv6 用の符号化を定義し、AFI 2 と SAFI 133 または 134 を使う。宛先プレフィックスの offset はゼロでなければならない。さらに、異常に長い IPv6 ヘッダーチェーンやルーターのハードウェア制約によって、上位層条件を適用できない場合があると明記する。制御面での受理は物理的な限界を解消しない。

パケットで結果を確かめる

RFC 8955 は、フィルター対象パケットのヘッダー記録とルール別一致カウンターを推奨する。各装置、VRF、インターフェース、ラインカードについて、ルールがコンパイル済みか、拒否されたか、近似されたか、どの優先順位と動作が残ったかを保存し、カウンターを攻撃標本と照合する。

さらに被害側へ届く量、正常通信の損失、リダイレクト先の容量、撤回後の変化を別に測る。破棄カウンターの増加が誤った集約への一致を示す場合も、攻撃低下と同時に過剰な巻き添えが起きる場合もある。FlowSpec 経路だけでは判定できない。

情報源