要約

  • draft-ietf-grow-downgrade-bgp-community-01は、タグ付きプレフィックス宛て通信を低い優先度で扱い、輻輳時には他の通信より先に廃棄するためのwell-known transitive BGP communityを提案する。
  • 経路上のタグは、受信、分類器、Lower-Effortキュー、DSCP維持、実際の輻輳、被害側の観測のどれも証明しない。
  • RTBHより破壊を抑えられるのは、参加ドメインが動作を実装し、攻撃中にも未使用容量が残り、終了後に通常扱いへ戻したことを確認できる場合だけである。

DDoS対策のブラックホールには明快さがある。標的宛てのパケットを捨てれば、共有リンクを他の利用者へ戻せる。しかし標的は消え、攻撃が終わったかどうかを自分で測る手段まで失いかねない。

DOWNGRADEが目指すのは、全廃棄ではなく損失の順序付けである。空き容量があれば標的宛てのパケットも流す。輻輳が起きた時だけ、その集合を通常通信より先に落とす。残った通信は、最低限のサービスや攻撃継続の判断材料になり得る。

しかしBGPが運ぶのは意図であり、パケットを並べるのは転送装置である。両者を一つの成功として報告してはいけない。

2026年9月24日の第01版はGROW WGの作業項目である。DatatrackerはActive Internet-Draftと表示し、公式通知も公開日と作業文書であることを示す。文書の想定区分はInformationalだが、RFCでも導入実績でもない。

共有番号は既に得られた。著者のIANA申請を受け、BGP Well-known Communitiesレジストリは0xFFFF000AをDOWNGRADEに割り当てている。番号は共通言語を作るだけで、ポリシーやキューを配備しない。第01版のIANA節には確定値がある一方、機器設定例にはまだTBDが残る。例示をそのまま運用設定にしてはならない。

RFC 1997のcommunity属性はoptional transitiveであり、受信側はローカルポリシーに従って利用、変更、配布できる。送信側が遠隔キューを命令する仕組みではない。隣接ASがそのプレフィックスを広告する権限を持つか、タグを受け入れるか、どの転送クラスへ結び付けるかは、それぞれ別の判断となる。

草案では、タグ付き宛先のパケットは低い優先度を受け、輻輳時には先に失われる。次のドメインへ出る際にはRFC 8622のLower-Effort DSCP 000001を付けることも求める。IXのroute serverはcommunityを透明に再配布し、他の運用者も除去すべきでないとする。攻撃源に近い場所で低優先化できれば、共有容量を早く守れるからだ。

ただしroute serverはデータ面にいない。RFC 7947が扱うのは経路交換の制御面である。属性が正しく通過しても、その装置は対象パケットを一つも見ない。経路の伝播は必要だが、キュー動作の証拠ではない。

Lower-Effortも最低帯域を約束しない。RFC 8622は極端に低いスループットや完全なstarvationを許容する。LEキューを持たないドメインはDefault PHBに写し、DSCPは残すべきだとされる。その場所では要求より良い扱いとなり、攻撃通信が通常のBest Effortと競合する可能性がある。DSCPが消去されれば、後続ドメインは意図を読めない。正規通信を誤ってLEに置けば、それ自体がdowngrade attackになる。

観測可能性にも独立した証拠が要る。上流キューを抜けた少数のパケットが、後段の全ボトルネックと受信センサーを通過したとは限らない。被害側の観測がゼロになった時、攻撃終了、上流での完全飢餓、中間ブラックホール、テレメトリー障害を一つのグラフから区別できない。少量が届いても、攻撃の構成やアプリケーション回復を判断できる十分な標本とは限らない。

草案は重要な前提を明記する。攻撃中にも未使用容量が必要である。優先度は帯域を生成しない。分類より手前のリンクが飽和していれば効果はなく、上位クラスが残りを使い切ればDOWNGRADE通信は全て消える。攻撃原因も残る。

これはRFC 7999のBLACKHOLEやRFC 5635のRTBHとは異なる。BLACKHOLEは全廃棄を求め、拡散範囲の制限も勧める。DOWNGRADEは広い伝播と非ゼロの転送可能性を目指す。どちらも助言でありプレフィックス権限が必要だが、片方の受領票で他方の結果を証明できない。

監査記録は段階別に作る。被害プレフィックス、事故責任者、開始時刻、最大期間、広告権限を持つspeakerを保存する。次に、受け入れた隣接網、保持したroute server、communityを転送クラスへ写したポリシーを列挙する。その後、FIBと分類器、キューとscheduler、境界のLE DSCP、輻輳とクラス別廃棄、パケット標本、被害側到達率、アプリケーションcanaryを記録する。最後にタグ撤回と通常配送回復を確かめる。

Heng LuのRunning-Code Primacyはレジストリ値より実パケットの扱いを上位に置く。Reality Layersは経路、キュー、サービス結果を分離する。Minimum Initial Specificationは、共有層が狭い要求を定義しても、実行責任は各ネットワークに残ることを示す。

DOWNGRADEの価値は、通常転送と全消失の間を設計しようとする点にある。その中間を証明できなければ、名前だけが柔らかいブラックホールになる。経路タグは開始通知であり、結果を決めるのはキューである。

情報源