要約

  • 新しいDOA案は、プレフィックスと長さ、起点AS、任意の中継AS、BGP CommunityをRPKI署名に結び付け、破棄要求の範囲を示す。
  • DOAとROVの判定は独立し、デフォルトの経路動作は発生しない。文書はIETF未承認の個人ドラフトで、安全性、運用、RPKI-RTR輸送が未完成である。

DDoS対策として上流ネットワークにトラフィックを捨ててもらうには、攻撃対象だけを示す長いプレフィックスをBGPで通知することが多い。ところが、その長さがROAのmaxLengthを超えると、資源保有者が意図した通知であってもRoute Origin ValidationではInvalidになり得る。緊急制御と起点検証が同じ長さ制約を取り合う構図だ。

draft-spaghetti-grow-rpki-doa-00は、ROAを緩めるのではなく別の認可を置こうとする。Discard Origin AuthorizationはRPKIの署名オブジェクトとして、どの起点ASが、どのアドレス範囲とプレフィックス長で、どのClassicまたはLarge BGP Communityを付けて破棄を要求できるかを記す。必要なら、要求を一段中継できるASも列挙する。

ただし、これはIETFの決定ではない。Datatrackerは個人Internet-Draftと表示し、IETFの支持も標準化上の正式な地位もないと明記している。2022年のSIDROPS向け名称の提案をGROW向けに移したが、GROWのワーキンググループ文書として採択された証拠はない。

今回の版では、旧稿の未決事項が一つ具体化した。複数Communityの扱いは論理ORとなり、リスト中のどれか一つが受信経路にあればCommunity条件を満たす。発行者が別の値を指定しない場合、署名ツールはRFC 7999のwell-known BLACKHOLE Communityを標準値として入れてよい。

判定はCommunityだけでは完了しない。Matchedになるには、起点AS、許可されたプレフィックス長、受信元のAS、Communityの四条件が一致する必要がある。受信元は起点AS本人か、DOAに記載されたpeerAsIDsの一つでなければならない。対象オブジェクトはあるが条件が違えばUnmatched、カバーする検証済みオブジェクトがなければNotFoundとなる。

ROVの結果はそのまま残る。より具体的な正当なブラックホール経路がDOAではMatched、ROVではInvalidという組み合わせも想定される。草案はDOAを早い段階で評価し、合わない経路はROVを含む通常の方針へ流す考えを示す。同時に、DOAまたはROVの状態だけで実装がデフォルト動作を取ることを禁じている。破棄や拒否を決めるのは明示的な運用方針である。

この線引きは重要だ。署名済みDOAが示すのは、資源保有者が一定の経路表現を許可したという事実に限られる。攻撃が実在すること、通知者の現在の意図、AS path全体の正しさ、破棄が最善の応答であることまでは証明しない。

経路の外部伝播にも制限がある。RFC 7999は通常、ブラックホール経路を受信ASの外へ広げないよう求める。DOA案は、ローカルASがpeerAsIDsに明示されたときだけ隣接ASへの中継を許す。これは一段の委任であり、連鎖的な無制限委任ではない。

別オブジェクトを使う理由はROA側の副作用にある。ブラックホール用の長い経路をROVで有効にするためROAのmaxLengthを広げると、通常の起点権限まで広がる。RFC 9319は過大な最大長を避ける運用を勧めている。DOAは破棄用途だけを切り出すことで、この権限拡大を避けようとする。

一方、配備可能性を裏付ける材料は足りない。DOAをRPKI-RTRで配る拡張は別文書に先送りされ、運用上の考慮事項とセキュリティ上の考慮事項はまだ書かれていない。IANA値も未割当である。Python署名実装が一件挙げられているが、情報は独立検証されておらず、検証器やルーターとの相互運用を示さない。

今回の公開で明確になったのは、緊急時の権限を誰がどこまで持つかという設計である。実際の安全性は、失効がどれだけ速く伝わるか、異なるソフトウェアが同じ結果を出すか、そして運用者が自動化を監査できるかで決まる。

情報源