要約

  • ROAのmaxLengthは、指定ASがどこまで長いプレフィックスを起点としてよいかを示すが、実際にどの経路を広告する計画なのかは示さない。
  • 厳密すぎる認可は準備されていない正当な緊急経路をInvalidにし、広すぎる認可は承認されていない経路をValidに見せ得る。
  • 各起点をプレフィックス、ASN、目的、有効期間、ROA変更、伝播観測、撤回責任者、ロールバック期限に結び付ける記録が必要である。

平常時、AS 64496は203.0.0.0/16を広告し、ROAもその/16だけを認可している。障害対応で203.0.113.0/24をDDoS対策サービスへ向けることになった。BGP変更は承認済みだが、RPKI側の準備はなかった。起点検証を行うネットワークから見ると、この/24は認可された長さを超えるためInvalidになり得る。

そこで/16にmaxLength 24を付ければ、緊急の/24は検証を通る。だが同時に、指定ASは/16配下のどの/24でも起点にできるという認可を得る。候補は256個ある。設定は、事故対応に必要な一つと、サービスも監視も撤回責任者も存在しない残りを区別しない。

RFC 9582が定める意味は限定的である。ROAは、アドレス資源の保有者が指定ASに対し、列挙されたプレフィックスの起点となることを認める。任意要素maxLengthは認可する最長のプレフィックス長を示し、省略時は列挙された長さだけが対象となる。変更番号、利用目的、インシデント終了時刻、トラフィック誘導の指示は含まれない。

RFC 6811の起点検証も、受信経路を、それを覆う検証済みROAペイロード、起点AS、許容長と照合する処理である。Validという結果は、AS_PATH全体の真正性、パケット到達性、トラフィックエンジニアリングの効果、あるいは人間による継続承認を証明しない。

最小限の認可は意図を読める形にする

RFC 9319は、可能な限り「最小ROA」を使い、BGPで実際に起点となるプレフィックスだけを認可するよう勧告している。一般にはmaxLengthを避ける一方、明確な運用上の例外も認めている。問題は機能そのものではない。省略表現が実際の起点計画より大きな権限を与える点にある。

例えば、通常の/16に加えて、地域別の入口として四つの特定/24を広告するとする。四つの厳密な認可なら、その設計がそのまま見える。/16–24の一項目でも四つを含められるが、/24の粒度では計画外の252個も認可する。RPKIの起点検証は経路全体を認証しないため、攻撃者が認可ASを末尾に置いた偽のパスを作り、未使用だが認可済みのサブプレフィックスを狙う余地が残る。

厳密なROAを維持するには、資源管理者、ルーティング担当、セキュリティ担当、対策事業者の連携が要る。しかし、その手間こそが、誰がどの起点を何のためにいつまで認めたのかという証拠を作る。

緊急時の柔軟性には恒久的な余白ではなく手順が要る

DDoS対策では例外が必要になる。事業者がより具体的な経路、別の起点ASN、宛先ベースの破棄経路を求める場合がある。RFC 9319はこうした場面を扱っている。利用者は事前に正確な要件を確認し、RPKIの変更とBGP広告の順序を試験しておくべきだ。

まずプレフィックス、ASN、範囲、期限を承認する。次にROAを作成または置換し、独立したバリデータに期待するペイロードが現れるのを待つ。その後、限定範囲で経路を広告し、検証状態と伝播を観測してから広げる。終了時はBGP経路を先に撤回し、消失を確認したうえで、一時的認可を計画どおり削除する。

RPKIリポジトリ、バリデータ、ルータへの結果配布、BGP伝播は同じ時刻には収束しない。公開RFCだけでは、各ネットワークがInvalidをどう扱うかも分からない。RFC 7115が示すように、起点検証は運用ポリシーの導入であり、影響観測、例外の理解、段階的な適用が必要になる。

出典