要約

  • Qrator の監視記録では、2020年4月1日 UTC 19:28頃に事象の開始時点が示され、観測はおおよそ1時間続いたと報告している。これは属性付きの外部観測ウィンドウであり、後に影響を受けた全ネットワークでの完全な内部時系列や、各 AS での厳密な開始・終了時刻の証明を意味しない。 [1]

  • Qrator は、ほぼ200の自律システムに属する8,870の影響を受けたプレフィックスを報告した。CERT-EU は、200以上のネットワークから8,800を超える経路を別途集計している。[1][2] これらは観測手法の違いによる規模の記述であり、どのルートでも同一の起点検証結果があったこと、または商用影響が同一だったことを示すものではない。

  • Qrator は、AS12389 の発表が Rascom AS20764、Cogent AS174、Level 3 AS3356 を経由して伝搬したことを報告した。この連鎖は、事象が独立して運用されるルーティングドメインを横断したことを示すが、各対象ネットワークの正確なインポートフィルタ、契約、検証状態、ルータ設定を直接示すものではない。

  • ルーティング証拠は少なくとも4つのカテゴリを分離して扱う必要がある。意図されたポリシー範囲外に学習した経路、未許可の起点アナウンス、再起点化されたより詳細プレフィックス、起点は有効でも AS パスが想定関係を逸脱する経路である。これらのカテゴリは、フィルタリングや RPKI 起点検証に対する作用が異なる。

  • 別件として、RIPE NCC の RPKI コントロールプレーンでの登録ソフトウェア更新が発生した。プロバイダ非依存(PI)割当の一部が証明不可と分類され、2,669件の ROA が削除された。RIPE NCC は4月2日に欠落した ROA を復旧した。

  • 時点の一致は因果関係を確定しない。RIPE NCC の遡及レビューと独立の Routing Working Group 分析では、ROA 削除と Rostelecom のルーティング事象との直接的関連は示されなかった。

  • 両事象の交差は限定的で、PI 保有者3者と12プレフィックスにとどまる。この重複から8,870プレフィックス全体に一般化することはできない。公開記録は、すべての影響経路を RPKI Invalid と記載する根拠を与えていない。

  • Route Origin Validation(ROV)は、プレフィックスと起点 ASN を検証済み ROA と照合し、Valid、Invalid、NotFound の結果を返す。これは AS 経路全体を検証せず、すべての輸出が商用関係を満たしたかを判定せず、構成変更の再構成や意図の確定も行わない。

  • 実務上の統制は分散されていた。Rostelecom は自己のアナウンスと輸出ポリシーを制御し、受け入れ側ネットワークは各社のインポート・エクスポート・検証方針を制御し、プレフィックス保有者は自らの登録情報と ROA を制御し、RIPE NCC は認証サービスと ROA 管理を制御し、利用者側ネットワークはキャッシュ鮮度と適用方針を制御し、監視事業者は観測と警報を制御した。

  • 重要な事実は依然として不明である。内部の起点トリガーの具体的な手順、学習経路リークと再起点化されたより詳細プレフィックスの正確な比率、各受け入れネットワークの RPKI 表示、各ホップで適用されたフィルタ、完全な対応時系列、データプレーンでの実影響、そして事象の事故・故意の別の確定は不明のままである。

  • したがって説明責任は、個人や組織を断定するよりも実務的な運用管理に基づくべきである。登録と ROA 情報は資源と起点権限の記録を示したが、実行中構成、最新キャッシュ、隣接ポリシー、監視、協調復旧が、証拠を実運用上のルーティング挙動に変換した。

責任の焦点

2020年4月1日の事象が重要なのは、記録上の権限と実行中の制御の分離が露わになった点である。RIPE Database は AS12389 に関連する管理オブジェクトを同定でき、RPKI は一部プレフィックス保有者の起点認可を表現できた。どちらの仕組みも、全てのルータが何を受け取り、優先し、再広告するかを単独で決めるものではない。BGP スピーカは UPDATE を交換し、ローカルポリシーに従って経路を選択し、許可された結果を隣接に広告した。

この構造のため、単一の登録情報、単一のセキュリティ機構、あるいは単一の機関が結果全体を決定したという説明は成り立たない。Qrator の AS20764、AS174、AS3356 を通過した伝搬観測は、観測された連鎖内に複数の実行制御プレーンを置いた。[1] AS12389 が直接の対象となる公告に現れたため、Rostelecom 側の役割は中心的である。しかし、その到達範囲は、受け入れた隣接、再送信したルート、下流ネットワークの選択方針に依存して拡大した。

この事象が起点検証の限界テストになった理由はここにある。公告が未許可起点であったり、ROA で許容される長さを超えるプレフィックスであれば、最新の検証データと実施ポリシーを持つ事業者は Invalid として拒否し得る。起点が許可されていて、AS パス上の順序が不適切でも、同じ起点は Valid となる場合がある。対応する ROA が存在しない場合は通常 NotFound となり、Invalid ではない。したがって技術制御は観測事象の異なる側面に異なる効力を持つ。

公開証拠で説明責任を支えるには、これらの区別が維持されることが前提である。BGP 公告、AS12389 観測、伝搬観測、ROA 状態、上流受け入れ判断、監視、インシデント調整を除外してしまうと、一般論のセキュリティ論に留まり、この事象の説明にならない。逆に、すべての経路を同種の障害として扱うと、ROV が本来持たない能力を誤って過大評価することになる。

ここでの説明責任とは、測定可能な意思決定を実際に誰が行ったか、そしてその決定を示す証拠は何かを示すことである。外部観測から、過失、犯罪性、個人の過失、違反、法的責任、傍受意図といった断定を導くものではない。CERT-EU は、事象が偶発であったかを明らかにできないとしている。[2] 公開記録は不確実性を解消しないため、分析はそこを覆してはならない。

フォレンジック・タイムライン

フォレンジック再構成では、直接報告された観測と推論、未解決の内部事象を分離する必要がある。公開のルートコレクタと監視基盤は選択されたコントロールプレーン視点を提供するが、普遍的な記録ではない。RIPEstat の資料も、利用可能な観測源に基づくデータであり、観測点とカバレッジの制約を前提とする。[9] 以下の時系列は、報告内容、独立事象、未確定部分を明示する。

時刻証拠となる出来事
2020年4月1日 UTC 19:28以前公開記録は、内部での起点設定変更、実行ルータ、実行コマンド、担当者、または内部承認手順を特定していない。後にその経路を受け入れたネットワークそれぞれの事故前フィルタと RPKI 状態の全体も同様に示していない。
UTC 19:28頃Qrator は観測開始時刻をおおよそ19:28 UTC とした。AS12389 が複数の他ネットワークと関連するルートを広告していたことを報告している。[1] この時刻は Qrator の監視記録であり、影響を受けた全ルータがその瞬間に初初回更新を見たことを示す証拠ではない。
直後の伝搬期間Qrator は、Rascom AS20764、Cogent AS174、Level 3 AS3356 へ AS12389 の広告が伝搬したと報告した。[1] この観測は、これらの自律システムを通した実際の移送を示すが、セッション毎の判断、ルートマップ評価、各商用関係の全体像は示さない。
おおむね1時間の観測窓Qrator は、ほぼ200 AS の8,870プレフィックスを算定した。[1] CERT-EU は後に、200以上のネットワークから8,800経路超を要約した。[2] これは報告者の測定であり、各経路の起点検証結果が同一であったことや同一のデータプレーン影響を生んだことを示すものではない。
インシデント対応期間Qrator は、Rostelecom がリアルタイム警告を受け取り、Qrator と共同でトラブルシュート・復旧を行ったと述べた。[1] CERT-EU も報告企業との協力を記録している。[2] ただし Rostelecom 内部のエスカレーション、緩和、ロールバックの具体的列は公開されていない。
初回観測後の約1時間Qrator は、事象が約1時間続いたと記述した。[1] 観測区間内での復旧は示されるが、どの構成変更または撤回が各影響ルートを終了させたか、収束が全ネットワークで同時に完了したかは示されない。
同時期の RPKI 事象別件として RIPE NCC の登録ソフトウェア更新が、PI 割当の一部を非証明可能と判断し、2,669件の ROA 削除を誘発した。[3][5] これは AS12389 のルーティング挙動とは別のコントロールプレーン記録管理事象である。
4月2日RIPE NCC は欠落していた ROA を復元した。[3][5] この復旧は独立した RPKI サービス回復であり、Rostelecom 事象が終息した直接メカニズムとして扱うべきではない。
その後の分析Routing Working Group 分析と RIPE NCC の後続レビューは、2つの事象間の直接関係を見出さなかった。重複は PI 保有者3者と12プレフィックスに限定された。

この時系列は、同時に進行した2つの独立した障害系列を示す。1つは BGP 広告とネットワーク境界を越えた受け入れ、もう1つは起点認可記録の整備と可用性の問題である。前者は実行中ポリシーに依存し、後者は有効な ROA データが利用者側に提供される可否に影響する。重複が限定的だからといって、欠落 ROA が8,870経路全体の原因だと推定することは正当化されない。

時系列は検知時刻と起点時刻を分離する。Qrator の19:28前後観測は、監視拠点で事象が可視化された時点を示す証拠であり、内部で変更が入力・確定・配布された時点を示すものではない。同様に約1時間という観測期間は外部から見える幅を示すが、各経路が全 BGP 情報ベースでいつまで存在したかの厳密時刻は特定できない。

ルータ単位の時系列欠落は重大である。これがないため、最初に受け入れた隣接、どの経路評価が先に実施されたか、どのルートが先に撤回・修正されたか、あるネットワークでは継続し別のネットワークは停止したかを確度高く断定できない。責任ある再構成は、観測ログを想像上の内部ログに置き換えることなく、このギャップを残しておく。

観測された経路拡散が示すこと

AS パス観測は、予期しない到達性情報が単一ネットワークに留まらないことを示す。BGP は分散型のプロトコルであり、ある AS で受信し許可された UPDATE は別の経路判定プロセスの入力となり、ポリシーに基づいて隣接へ再広告され得る。[12] AS12389–AS20764–AS174–AS3356 の報告された拡散は、別個の管理ドメインを横断した運用判断の連鎖を示すものにすぎない。

この連鎖は、すべての対象ネットワークが8,870経路を受け入れたことや、単一の同一 AS パスがインターネット全体へ達したことを意味しない。どのインポートポリシーが個別ルートを許容したかも明示しない。運用者は顧客プレフィックスフィルタ、RIR データ、RPKI 検証、手動例外、広域の制限、契約前提など複数を組み合わせて判断していた可能性がある。公開された記録は2020年4月時点の特定上流・ピアの設定値を明らかにしない。

それでも拡散観測には価値がある。AS12389 は広告を発生・輸出する可否を制御した。各直接接続受信ネットワークは受け入れを制御し、各次段階広告者はさらに送出判断を行い、下流ネットワークは経路選択とローカル検証ポリシーを制御した。これは明確に分散した制御であり、複数の運用者がそれぞれ一定範囲でルーティング結果を変えうることを示す。

分散制御は自動的に分散責任を意味しない。観測可能な AS パスのみから、ルーティング関係の契約条件、保有者のプレフィックス精度、キャッシュ状態、あるルートが学習ルートリークか再起点化かを特定することはできない。観測は意思決定点を示すが、その法的・道義的意味を直接含意しない。

混同してはいけない4つの経路分類

「リーク」という語は広く使われるが、この事象は4つの条件を分離しないと正確に読めない。RFC 7908では、経路が本来意図しない範囲へ伝搬し、結果として AS パス順序が顧客・プロバイダ・ピア関係の想定と一致しない場合をルートリークとして定義する。[17] これは起点権限検証とは別概念である。

  1. 学習ルートポリシーリーク。あるネットワークが隣接から正当な経路を学習し、意図されたものではない隣接へエクスポートする場合。起点 ASN とプレフィックス長は ROA 上で整合している可能性があり、ROV はルートを Valid に判定し得る。誤りは主として輸出スコープにあり、中間ネットワークが本来許可されていない転送をしている点に起因する。

  2. 未許可起点アナウンス。関連する資源保有者が起点を許可していない ASN がプレフィックスを広告するケース。現在有効な ROA が他 ASN を許可しており、利用者側が最新かつ検証済みのデータを持っている場合、起点不一致として Invalid 判定される。口語的に「origin hijack」と呼ばれる場合があるが、このラベルだけで悪意、傍受、犯罪行為、所有権の確定はできない。

  3. 再起点化されたより詳細経路。一つの AS が別ネットワークの集約内により長いプレフィックスを広告し、自らを起点として提示する。対応する ROA が存在する場合、起点 ASN 不一致または ROA のmaxLength超過によって Invalid になる可能性がある。より詳細なプレフィックスは、最長一致により優先選択される場合があり、BGP 比較で優位になる。ただし、各再起点化が意図的か、各プレフィックスのデータプレーン影響を公開記録がすべて示しているわけではない。

  4. 有効起点のポリシーリーク。プレフィックス、起点 ASN、長さは認可されているが、AS パスや輸出関係が意図しないポリシーを満たしていないもの。これは ROV の境界を最も端的に示す。起点検証は認可の有無を示すが、中間 AS が通過権限を持つか、経路が許可された関係であるか、特定隣接に再広告してよいかといった点は示さない。

公開分析は、2020年の観測が「学習ルート」と「再起点化されたより詳細経路」の混在を示すが、実際の比率は未確定である。したがって、8,870経路を一様に未許可起点とすること、もしくは全てを起点許可済みポリシーリークとすること、または全てを RPKI Invalid とすることは不正確である。いずれも未確定の分布を一枚岩にする誤解を生む。

NotFound は別概念として維持すべきである。カバーする検証済み ROA が存在しない場合、起点検証は通常 NotFound を返す。[14] これは、カバレッジの有無を示すだけで、起点が正当であることの肯定でも、Invalid ではないことの否定でもない。運用ネットワークは NotFound に対するローカル方針を持つことはあるが、この状態自体は「利用可能な ROA 集合に該当する認可がない」ことを示すのみである。

これらの分類は、対処可能な制御の範囲を定義する。顧客プレフィックス台帳に基づくエッジフィルタは、未許可起点や誤ってエクスポートされた学習ルートの一部を抑止できる。ROV は、適切な ROA が存在する範囲で未許可起点や長さ不適合を特定できる。AS 関係ベースの経路制御は有効起点ポリシーリークに対応する。単一のフィルタ群ですべての混在ケースを完全に網羅できるわけではない。

RPKI 起点検証で確認できること

RPKI は、アドレス資源保有者が Route Origin Authorisation(ROA)を作成できる暗号的な枠組みを提供する。ROA は、特定 ASN がプレフィックスを起点起用できることと、最大プレフィックス長を定義する。利用者側は RPKI 資材を取得・検証し、Validated ROA Payload を作成して、経路システムやポリシーエンジンへ提供する。RIPE NCC はそのサービス圏内の資源に対し認証と ROA 管理を提供するが、参加ネットワークのすべてのルータを一元的に設定することはしない。[10]

特定の検証済みデータ集合に対して、起点検証は3種類の結果を返す。観測された起点 ASN とプレフィックス長がカバーする認可を満たす場合はValid、同一目的に対し適合認可がなく長さも一致しない場合はInvalid、カバーする認可が存在しない場合はNotFoundとなる。[14] これらは経路自体に内在する普遍的な性質ではなく、利用者側がその時点で保持するデータセットに対する判定である。

この限定は、記録管理事象時に重要になる。利用者によっては検証結果を同期する時間やキャッシュ状態、期限処理、運用反応が異なり、検証ビューが一時的に一致しないことがある。RFC 7115は、利用者側処理と検証情報の運用的重要性を強調している。[15] 公開証拠は、1時間観測中に各ネットワークが実際に保持していたキャッシュ内容を明示しない。したがって「特定事業者が Invalid を見た」と断定するには、当該時点でのその事業者の有効データとポリシー実装が必要になる。

ROV は実用的な起点証拠を与える。AS12389 に対し、対象プレフィックスの ROA と起点 ASN が不一致、またはmaxLength超過があれば、実装側が制限を有効化していれば Invalid として拒否し得る。この条件付き記述は、当該 ROA が存在し、正しく表現され、最新の利用者キャッシュに到達し、経路ポリシーへ反映され、例外処理で上書きされないことを前提とする。どこか1つでも欠ければ、実効結果は変化する。

Valid は「安全な経路」を意味しない。中間 AS 列の検証を行わず、顧客・プロバイダやピア関係の適合を保証しない。中間ネットワークが学習ルートを輸出してよいかを示すものでもない。データパスが想定宛先に到達したか、傍受されなかったか、担当者が対応したかを保証しない。許可された起点でも意図しない経路構造の背後に現れることがある。

Invalid にも限定的な意味しかない。Invalid はその利用者の検証集合とカバレッジ情報の衝突を示すだけで、未許可起点、過剰なプレフィックス長、運用意図の陳腐化、ROA の記述誤りのどれかで発生し得る。動機、傍受、犯罪行為をそれ単体で示すものではない。攻撃か設定誤りか、記録誤差かを切り分けるには、変更管理・例外運用・インシデント調査が必要である。

NotFound は起点情報として最も限定的である。利用者側の視点でカバーする認可がないため、ROV は ROA から起点を確認・否定できない。すべての NotFound を悪性と見なすなら、ローカルポリシーの判断であり ROV 状態を一般化した主張になり、ROA の無いアドレス帯に対する通常経路の誤拒否を招く。

RIPE NCC の ROA 削除はこの違いを示した。2,669件の削除は、同期後、特定ルートを Valid/Invalid から NotFound へ変化させる可能性を持つが、AS12389 の BGP 広告自体を作成したり、中間ネットワークへ輸出させたり、AS パス全体を変更したりはしない。[3][5] Rostelecom 事象における重複は PI 保有者3件と12プレフィックスに限定され、後続分析でも両事象の直接因果関係は確認されなかった。

したがって ROV がこの事象全体を予防したと一般化できるわけではない。条件付きで Invalid が成立する経路は一定範囲で制御される可能性があるが、起点が認可されたままのポリシーリークは自動的には除去できない。これは ROV が弱いからではなく、設計上の判定対象が起点認可に限定されるためである。

根本原因

Rostelecom 側の開始時の内部順序は不明である。公開資料は特定の設定変更、コマンド、ルータ、担当者、承認決定、または自動化失敗を特定しない。外部で観測された AS12389 の公告行動と伝搬、内部でそれを生成した機構との間の分離は維持されている。従って、このルーティング事故の根本原因を、公開証拠から1つの行為や個人へ縮約することはできない。

観測可能なレベルでは、AS12389 起点または輸出動作から、2020年4月の経路異常が予想外のルートとして導入された。これには学習ルートの漏えいと再起点化の混在が含まれる可能性があると解釈された。[1][4] その後、他ネットワークの受け入れと再広告が可視範囲を拡大した。これは経路観測で支持される事象系列であって、完全な根本原因特定ではない。

RIPE NCC の事象は異なる技術系列である。レジストリソフト更新で一部 PI 割当が非証明可能と分類され、2,669件の ROA が削除された。[3][5] このソフト更新と記録管理の失敗は RPKI データを変化させた。一方、Rostelecom 事象はライブの BGP 広告を変えた。双方を結合して1つの根本原因として扱うことは、公開記録と一致しない。

寄与要因

第一の要因は、BGP が各ネットワーク境界でローカルポリシーに依存する点である。BGP は到達性を配布するが、運用者が受け入れ・優先・広告を決める。[12] ある方針に本来止まるべき経路が、継続的に許可された設定を通じて連鎖することがある。AS20764、AS174、AS3356 への観測伝搬は複数の受け入れ・送信ポイントを示すが、各ポイントの具体的ポリシーは明かされない。[1]

第二の要因は、起点権限の影響範囲の非一様性である。競合する ROA を持つ経路は ROV で拒否対象になり得るが、起点有効なポリシーリークは拒否対象にならない。ROA 非対応経路は NotFound となる。カテゴリが混在しているため、全体に同一の検証処方を適用することは防御上妥当でない。

第三の要因は、現在の運用データへの依存である。ROA が正しく作成されても、利用者が取得・検証し、キャッシュを新鮮に保ち、ルータへ反映し、ローカル方針が実行されなければ、到達効果は生じない。RIPE NCC の削除は記録層を一時的に変え、キャッシュ同期とローカル検証の有無が、各ネットワークの判断へ影響した。[3][10][15]

第四の要因は、フィルタの分散性である。顧客プレフィックスフィルタ、最大プレフィックス制御、ルートレジストリ、RPKI 検証、輸出ポリシーチェックは相補的に働く可能性がある。[11][16] ただし公開記録は、2020年4月の Rostelecom 側や伝搬ネットワークで、これらのどの制御が存在し、欠落し、または除外されていたかを確定しない。

第五の要因は可視性の断片化である。監視事業者は一部観測点から異常アナウンスを検知し警告できるが、各ルータの Adj-RIB-In、ローカル RIB、転送テーブル、構成履歴までは持たない。Qrator の警報は実行可能な外部証拠を提供したが、初期の内部故障を独自に再構成したり、全ネットワークの同時収束を保証したりはしない。

トリガーイベント

Rostelecom 内部の直近トリガーは未同定であり、公開証拠から人物、コマンド、ルータ、契約、意図へ責任を特定できない。公開で最初に確定できる外部イベントは、Qrator 観測点で AS12389 の該当広告が UTC19:28頃に現れた点である。

「トリガー」と「寄与要因」は区別する。寛容な隣接ポリシー、ROA カバレッジ不足、古いデータ、監視制約は、事象の拡大や収束遅延の条件になり得るが、広告開始そのものを示さない。逆に、ROA 削除事象は同時代に起きたが、AS12389 経路挙動の直接トリガーとして記録されていない。[4][5]

検知

Qrator は事象をリアルタイムで検知し、Rostelecom へ警告を送った。[1] 測定は開始時刻、持続時間、規模、可視伝搬の観点を提供し、公開再構成の基礎を形成した。CERT-EU は事後に事象を要約し、偶発性の不確実性と Rostelecom の協力を記載している。[2]

外部検知は重要な継続制御である。内部ビューでは隣接や遠隔ネットワークの受信状況が見えないため、監視アラートは補完的である。一方で、監視警報は監視点での可視性を示すのみで、内部トリガー時点、下流の各選択判断、完全なデータプレーン影響は示さない。実用的な検知には、ローカルのセッション/ポリシー計測と独立観測を組み合わせる必要がある。

対応

Qrator は、リアルタイム警報受領後に Rostelecom が自社と協調し、トラブルシュートおよび復旧を行ったと報じている。[1] これはインシデント協調の存在を示すが、内部エスカレーション、対応担当、検査した構成、採用した是正措置、各ステップの時刻は開示していない。

伝搬ネットワーク側の対応は、公開記録では同等の詳細がない。実装上の選択肢には、広告のフィルタ、経路優先度の調整、隣接との連絡、修正更新の待機などが含まれる可能性があるが、特定の運用者がどの方法を採用したと断定するには証拠が不足する。説明責任は、使用可能な制御と実施が確認された行為を分離して扱うことを要請する。

RIPE NCC の対応は別系列である。欠落 ROA の調査、4月2日の復旧、以後の監視改善の説明が行われた。[3][5] その対応は RPKI 記録の整合性と可用性に向けられており、AS12389 広告が是正されるまでの直接経路制御対応とは別である。

復旧

Qrator の約1時間観測とトラブルシュート・復旧の記録は、可視のルーティング事象がその時間帯に収束方向へ向かったことを示す。[1] しかし、回復が撤回、広告修正、経路フィルタ変更、隣接連携のどれにより生じたかは明示されない。全ネットワークで同時収束したかどうかも確定しない。

運用上の回復には少なくとも3層がある。第一に、公告層で想定外の経路を停止・修正すること。第二に、伝搬層で隣接・下流が変更を処理すること。第三に、監視層で異常経路が有効な観測点から消えたことを確認する。ローカルルータの宣言だけでは残留伝搬を見落とし、外部コレクタだけの宣言では内部状態の不足を見落とす。

RPKI サービス回復は別経路であり、RIPE NCC は4月2日に削除 ROA を復旧した。[3][5] 利用者側は、その後自らの同期と検証プロセスで修復状態を受け取る。リポジトリ復旧と各利用者ネットワークの収束は連動しうるが同一ではない。

実務上の統制配分

説明責任は、広い組織ラベルではなく、意思決定単位で配分される。

アクター実務上の制御証拠上の限界
Rostelecom / AS12389ルート起点と広告方針、隣接別フィルタ、プレフィックス台帳、構成レビュー、展開手順、監視、エスカレーションとロールバック開始時の構成変更と内部対応時系列は公開されていない
Rascom AS20764、Cogent AS174、Level 3 AS3356、およびその他の伝搬ネットワーク各社のインポート/エクスポートフィルタ、関係ポリシー、プレフィックス上限、ROV 利用、例外、異常対応、再広告2020年4月時点の構成、キャッシュ状態、契約は不明
プレフィックス保有者資源情報の正確性、ROA 作成、起点 ASN とmaxLength選定、連絡体制、独立監視ほぼ200の影響 AS 全体で、個別決定を一律推定できない
RIPE NCC認証・ROA 管理システム、ソフトウェア検証、監視、ロールバック、復旧、インシデント開示独立運用ルータがどの AS パスを採用するかを一元的に制御しない
利用者側ネットワークリポジトリ同期、キャッシュ鮮度、検証結果配信、ローカルの Invalid/NotFound 方針、例外、最終経路決定ある時点で各利用者が持つ検証ビューを全体監視から直接推定できない
ルート監視事業者観測点収集、異常解析、アラート配信、協調証拠、事後報告観測点は限定的で、公告の原因内部処理を制御できない

この配分は2つの誤りを避ける。第一に、起点ネットワークに全責任を集中し、独立した受け入れ判断で拡散が成立したことを見落とす誤り。第二に、配分を過剰に希薄化し、どの決定にも責任者がいないとする誤りである。Rostelecom は AS12389 が広告・送出したことを統制し、各隣接は受け入れを統制した。各継続広告ネットワークは次段階の伝搬を統制した。レジストリ運用者は起点記録の可用性を統制し、利用者はそれがルーティングに反映されるかを統制した。

制御は1つの層で有効なら別層でも有効とは限らない。プレフィックス保有者は正しい ROA を公開しても、各ネットワークが取得・適用することを強制できない。RIPE NCC は ROA を復旧できても、無関係な別 AS から BGP ルートを回収する権限を持たない。監視事業者は Rostelecom を警告できてもロールバックを実行しない。上流は境界でルート拒否できても、起点側設定を直すことはできない。運用連鎖はこれらの統制が同時に機能して成立する。

この配分は推論の限界も与える。報告経路に出現した AS がその意思決定者の心情や契約違反、法的責任を直接示すわけではない。そうした結論には、ここで扱う経路証拠を超える記録が必要である。

根本原因証拠と寄与証拠の分離

根本原因証拠は、想定外の AS12389 挙動を初めて生成した内部機構を示す必要がある。たとえば設定差分、内向きログ、コミット履歴、セッショントレース、整合時刻である。公開記録にはこれらがない。公開ルート観測は事象そのものと拡散を示すが、内部メカニズムの空白は埋めない。

寄与証拠は別の機能を持つ。連続するネットワークで受け入れ・送出された経路は、その境界でのポリシーが当時それを許容していたことを示す。Invalid 経路が検証済みネットワーク境界を越えて見える場合、データ鮮度、適用方針、例外処理を検証できるが、そのためには該当ネットワークの RPKI 状態が必要になる。Valid 起点リークが ROV で通過するなら、その部分では起点認可ではなくパスポリシー制御が主対象だったことが示される。

トリガー、検知、対応、回復は証拠クラスとして区別されるべきで、検知時刻をトリガー時刻として代用してはならない。

測定可能な是正策

この事象は層別の是正策を支持するが、対策は行為の有無を断定する主張ではなく、観測可能な制御として記述する必要がある。

第一に、起点または中継ネットワークは隣接別のプレフィックスインベントリを維持し、導入前にインポートとエクスポートポリシーを検証すべきである。測定すべき指標には、隣接ごとの許可プレフィックス数、ベースラインからの変更量、想定外の起点 ASN、より詳細広告、承認されたポリシー分類変更の有無が含まれる。ローカル起点と学習起点を区別する検査が必要である。

第二に、境界側での封じ込め能力を測定する。顧客とピアのセッションについて、デフォルト拒否、許可リスト、最大プレフィックス閾値、誤った関係先への学習経路送出を抑制する規則を確認する。一般的なフィルタ・検証実務を組み合わせることで、単一の万能チェックで代替しない階層化モデルを実装できる。[11][16]

第三に、RPKI 運用をエンドツーエンドで測定する。リポジトリ同期の年齢、キャッシュ系列進行、検証フィード可用性、セッション別の Valid/Invalid/NotFound 数、例外設定、ROA カバレッジの急変アラームは有効な指標である。発行側に ROA があっても、古いキャッシュや分断されたポリシー経路があれば実運用効果は得られない。[10][15]

第四に、プレフィックス保有者は ROA 内容が最新の起点を反映し、maxLengthが運用上必要最小限になっているかを確認する。適切に設定すれば一部の不正なより詳細経路を Invalid 化しやすくなるが、過度に厳しくすると正規のトラフィック工学経路まで無効化し得る。適切な値は実運用計画に依存し、後続分析はこの精密な運用選択の重要性を示した。

第五に、インシデント応答は時間指標で評価する。初回異常更新から内部警報まで、外部での相互確認までの時間、関連隣接との接触時間、影響ポリシーの特定時間、新規伝搬停止時間、複数観測点での回復確認時間を測定する。Qrator 報告はリアルタイム警報と協調の価値を示すが、これらの全区間は示さない。[1]

有用な事後記録は、最初の観測更新、構成状態、経路ポリシー評価結果、RPKI キャッシュ状態、関係者連絡、是正変更、最終外部検証を保持する。これにより、起点障害、輸出障害、受け入れ障害、古い RPKI データ、調整遅延を区別したレビューが可能になる。欠落したままでは、内部原因を部分的観測から推定せざるを得ない。

こうした措置は意図や責任追及を前提とせず、制御が存在したか、動作したか、出力が観測されたか、収束速度がどうだったかを問う。これは、単純な路線上の異常を悪意とみなすより、実運用の継続性を高める上で強い説明責任手法である。

レジストリ証拠と実装現実

レジストリオブジェクトと ROA は重要な証拠である。レジストリはネットワークリソースと行政情報を関連付け、ROA は資源保有者の起点認可を表現する。[8][13] 正確性、一意性、現在のセキュリティメタデータは運用者と調査者に価値を与える。誰が資源に対して登録され、誰がどの ASN で起点を許可されるかが示される。

ただし、レコード自体は宣言であり、インターネットを自動制御する命令ではない。BGP スピーカは受け取った更新に対し実行中ポリシーを適用する。利用者側は現在の RPKI データを取得する。ルータは検証結果を受信する。運用者は拒否・優先・調査の方針を決める。輸出フィルタは意図された関係をエンコードし、監視は実際の伝搬が意図と乖離するかを検知する。協調回復がその後、証拠を是正行動へ変換する。

別件の RIPE NCC 削除は、2つの層を同時に示す。レジストリと RPKI サービスは、認可削除が利用者の起点証拠利用に影響する点で重要である。一方で、削除だけで AS パスを再定義し、AS12389 広告を各ネットワークに強制したわけではない。実務継続は、記録回復、最新キャッシュ、ローカルルーティング方針、アクティブフィルタ、対応協調の連鎖で成立する。

この認識は、レジストリを主権的な経路統制機関として扱う誤りを避ける。一方で、制御がローカルであるからといって記録の価値を切り捨てるのも誤りである。ROA は起点の競合を機械的に検証可能な形で与え、運用側の分散制御が測定可能であれば意味が高まる。

後続設計文脈、遡及的要件ではない

RFC 8212は、インポート/エクスポートポリシーが明示されない外部 BGP セッションでのデフォルト拒否姿勢を示している。[18] これは設計上の事故リスク低減として有効であり、未設定関係の経路交換を抑止し得る。しかし、2020年4月の各ネットワークが同設定を採用していたと示す証拠にはならず、この RFC が当該事象の責任基準になるわけでもない。

RFC 9234は後続で BGP Roles や Only-to-Customer 機能を定義し、経路リークの一部を宣言的に検出するための構造情報を追加した。[19] これは ROV が扱わない「関係構造との整合」問題に対処する。これを2020年の観測セッションに適用された過去要件として扱うことはできない。技術的な発表時期と運用事実は別である。

RFC 9319は後続で RPKImaxLengthと偽装起点より詳細広告の運用含意を論じている。[20] これにより、カバー認可がどの範囲まで制約するかを理解しやすくなるが、2020年時点で各対象プレフィックスの ROA 設定を決定する証拠にはならない。また、8,870件を一律 Invalid とする根拠にもならない。

これらの後続文書は、単一技術では全ルート特性を検証できないため、層別設計が必要であることを示す。デフォルト拒否は未設定関係を補完し、BGP Roles は一定のポリシーリーク対策を補う。ROV は起点不一致や長さ違反を扱う。監視と協調は依然として必須である。

この記事が混同しないこと

2020年のこの事象は、Rostelecom の2017年の財務ルート異常とは別である。前者は時期、影響ルート、継続時間、帰属論点が異なる。再利用は行わず、当時の証拠を本件へ外挿して意図や継続因果を推定することはできない。本稿は、AS12389 の観測された伝搬鎖、約1時間の観測窓、当該事象に関連する制御のみを扱う。

本記事は一般的な ROA 誤設定の抽象論とも切り分ける。RIPE NCC の削除事象は、3人の PI 保有者と12プレフィックスという限定的重複に限定する。ROA 作成エラーの一般論を拡張して、当該事象における8,870件すべてを Invalid に分類したり、起点側か経路側かだけで議論を抽象化したりしてはならない。実際の問題は、どの経路群で起点検証が有効になり、どこで経路ポリシーと境界制御が必要だったかである。

この区別が、分析の中心を保つ。2020年の説明責任検証は、AS12389 の広告、AS20764/AS174/AS3356 への伝搬、4分類、時変 ROA 状態、独立運用判断という要素で成立する。これらがなければ、議論は別の Rostelecom 事例への流用か、抽象的な RPKI 論文化になってしまう。

重要な不確実性

内部の起点障害順序は不明である。学習ルートリークと再起点化されたより詳細経路の正確な比率は不明である。影響を受けた中継経路とエンドユーザー症状の完全集合も不明である。各時間点で各利用者に見える RPKI 状態も不明である。各伝搬ネットワークのインポート/エクスポートフィルタの構成は不明である。

完全な対応時系列も公開されない。Qrator はリアルタイム警報、協力、トラブルシュート、復旧を記録したが、全ての内部判断は開示していない。[1] 記録は、特定人物の責任、意図的傍受、犯罪行為、違反、法的責任を確定しない。また、8,870件に含まれるサービスのすべてで障害が生じたという計測も示していない。

これらは軽微な注意点ではなく、観測インフラと推測の境界を決める要素である。精密な記述は制御の所在と抑制機会を明示しつつ、意図・法的結論は未解決のまま残す。

結論

Rostelecom の2020年4月1日事象は、起点認証情報と経路ポリシー情報が解くべき質問を分けることを示した。Qrator は、AS12389 の大規模事象開始(UTC19:28頃)、約1時間の観測、Rascom・Cogent・Level 3経由の伝搬、8,870プレフィックス・ほぼ200AS、Rostelecom とのリアルタイム協力を報じた。[1] これらは規模、伝搬、対応を確立するが、完全な内部原因は示さない。

同時期の ROA2,669件削除は別の運用障害であり、後続分析は Rostelecom リークと直接因果は見ていない。重複は PI 保有者3者と12プレフィックスに限定された。[3]-[5] この証拠は、因果の混同と、全経路を Invalid と断定する主張を排する。

ROV は、現時点で同時的に有効な ROA と施行済みポリシーが存在する一部の未許可起点や過剰長経路に対して実用的な証拠を提供できる。だが、AS パス全体を検証することはできず、有効な起点でもローカルでポリシーを逸脱した経路を全件拒否しない。残りの制御責任は、送受信ポリシー、関係考慮フィルタ、最新キャッシュ、経路監視、協調復旧で担保される。

説明責任は分散しているが、具体的である。Rostelecom は広告・輸出判断を管理し、伝搬ネットワークは境界判断を管理し、プレフィックス保有者は認可記録と連絡を管理し、RIPE NCC は認証と ROA 管理の信頼性を管理し、利用者側はキャッシュ鮮度と施行を管理し、監視事業者は観測と警報の品質を管理する。全体を一体化して制御していないが、それぞれが運用継続の一部を実務的に担っている。

情報源

  1. https://qrator.net/blog/details/how-you-deal-route-leaks/
  2. https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  3. https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004072.html
  4. https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004083.html
  5. https://labs.ripe.net/author/nathalie_nathalie/lessons-learned-on-improving-rpki/
  6. https://manrs.org/2021/03/a-regional-look-into-bgp-incidents-in-2020/
  7. https://qrator.net/blog/details/2020-report/
  8. https://apps.db.ripe.net/db-web-ui/lookup?key=AS12389&source=ripe&type=aut-num
  9. https://stat.ripe.net/docs/
  10. https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
  11. https://manrs.org/netops/
  12. https://www.rfc-editor.org/rfc/rfc4271
  13. https://www.rfc-editor.org/rfc/rfc6480
  14. https://www.rfc-editor.org/rfc/rfc6811
  15. https://www.rfc-editor.org/rfc/rfc7115
  16. https://www.rfc-editor.org/rfc/rfc7454
  17. https://www.rfc-editor.org/rfc/rfc7908
  18. https://www.rfc-editor.org/rfc/rfc8212
  19. https://www.rfc-editor.org/rfc/rfc9234
  20. https://www.rfc-editor.org/rfc/rfc9319