要約

  • 11月2日付のdraft-ietf-idr-fsv2-content-filter-00は、FlowSpec v1とv2に固定パケット内容の照合を提案する。IETFのIDR作業部会によるInternet-Draftだ。
  • 条件は起点、オフセット、バイト列、マスクで構成される。FSv2では必須の構成要素となり、実装できない装置は規則全体のローカル導入を拒む。
  • バイト条件だけ外すと適用対象が広がる。信頼するBGPピア、規則の権限、伝播範囲、資源上限は運用者が決める。

狙いを外した網は、広く捕りすぎる

FlowSpecはBGPを通じてトラフィックのフィルター規則を伝える。基本的なIP条件が主に見てきたのはアドレスやポートなどのヘッダーだ。IDRの新草案は、既知の攻撃に特徴的な固定バイト列をパケットから探す方法を追加する。精密な条件を入れるなら、その条件が失われたときの扱いまで決めなければならない。

規則はOTypeでIPヘッダー、IPペイロード、UDPペイロード、TCPペイロードのどこから数えるかを選び、Offsetで位置を進める。内容バイトとマスクが、比較するビットを定める。草案にはTCPペイロード先頭の2バイトと宛先プレフィックスを組み合わせる例がある。アプリケーションの意味を理解する仕組みではなく、選んだ位置のビットを照合する仕組みだ。

焦点は機器の限界にある。形式上の長さは1から255バイトだが、実際の装置は解析能力やフィルター資源によってそれより短い上限を設けられる。FSv2では内容照合の構成要素を必須として符号化する。装置がそれを実装できなければ、FlowSpecの経路全体をローカルに導入できない。条件を黙って捨て、残りの条件と破棄・転送・速度制限の処理だけを動かすことは許されない。狭い攻撃パターンを狙ったはずの命令が、無関係な通信まで巻き込むからだ。

位置の解釈にも罠がある。IPv6でIPペイロードの起点は固定ヘッダーの後だが、拡張ヘッダーが続けばそこも計数に入る。途中で構成が変わると、同じオフセットが別のバイトを指す。トンネルの外側を読めば起点が曖昧になる場合もある。草案は適切な場面でカプセル化を解いた内側のIPパケットを使い、基準位置を明確にするよう求める。

著者らは管理できる場所での導入、他のヘッダー条件との併用、信頼するBGPピアと限定的な伝播を勧める。ACLやTCAMなどの容量も有限だ。OpenBGPD、FRRouting、プログラム可能なスイッチでの試験は記されているが、実運用の採用数や事故数は示されていない。草案の線引きは明快だ。細い条件を実行できない装置に、太いフィルターを代役として動かす権限はない。

一次資料