要約

  • ARTEMIS は通信事業者が運用するオープンソースシステムで、リアルタイムの BGP 観測とローカルなルーティング方針を比較し、公開コレクターだけでは得られない文脈をネットワークに提供する。
  • FORTH と CAIDA による2018年の研究では、試験条件下で数秒以内の検知と1分以内の無効化が報告された。ただし、これはあらゆる本番環境に適用できる保証ではない。
  • 緩和策として、より具体的な経路の広告や独自ワークフローの起動が可能だが、フィルター、古いポリシー、不完全な可視性、広範な権限を持つ認証情報によって、迅速な対応が第二のインシデントに変わる可能性もある。
  • 現在のプロジェクトには、規律あるリリース、信頼できる導入実績、そして Code BGP との透明な境界が必要である。同社による商業的な保守は、研究の歴史を置き換えることなくオープンソフトウェアを支え得る。

実際の経路変更が示した、数秒は始まりにすぎないという現実

CAIDA の2019年年次報告書によると、ARTEMIS は Internet2 の/30に影響した実際のハイジャックを数秒以内に検知した。この事例が重要なのは、研究者が設計した合成的な経路広告を超える証拠だからである。導入に参加していたネットワークで実際の経路が変化し、システムは調査を支援できる速さで逸脱を認識した。

ただし、この報告書は普遍的な検知時間の分布を示すものではない。/30は、特定のルーティング状況にある特定のプレフィックスであり、その導入環境が利用できたフィードを通じて観測された。別の事象は異なる形で伝播し、より短時間で終わるか、接続されたコレクターの観測範囲外にとどまる可能性がある。また、この報告書だけでは悪意やデータプレーン上のすべての影響を立証できない。安全に導ける結論は、CAIDA の導入プログラムにおいて、ARTEMIS が報告対象となった一つの実際の事象を数秒以内に検知したということに限られる。

事例研究は、その限界を維持してこそ価値を持つ。実際の変化に対してソフトウェアがどう動作したか、通信事業者がどのように警告を受け取り、事後にどの証拠を利用できたかを示すからである。誤検知、見逃し、緩和結果を含むより多くのインシデント記録は、タイミングを強調する新たな見出しよりも、本番運用への成熟度を示すうえで有用である。

BGP 警告が数秒で届いても、最も重要な疑問が未解決のまま残ることがある。経路コレクターは、見慣れない自律システムがプレフィックスを広告したことや、より具体的な経路が出現して伝播を始めたことを示せる。その証拠は、コントロールプレーンが期待されたパターンと一致しなくなったことを通信事業者に伝える。しかし、それだけでは誰が変更したのか、事故だったのか、トラフィックが新しい経路を通ったのか、利用者に被害が生じたのか、別の問題を起こさずにサービスを復旧できる対応は何かを確定できない。

ARTEMIS は、この検知と行動の間にある隔たりを前提として設計された。名称は Automatic and Real-Time dEtection and MItigation System の略だが、大文字を組み合わせた略称よりも運用モデルが重要である。ARTEMIS は、インターネット全体を監視し、遠隔から他のネットワークを修復する中央サービスではない。組織は、自ら管理する基盤にソフトウェアを導入し、正当と考えるルーティング状態を定義し、公開および非公開の観測情報を接続し、それらがポリシーから外れたときにシステムへどこまでの行動を許すかを決める。プロジェクトが約束するのは文脈を伴う速度であり、その文脈と権限がローカルにあることが制約となる。

したがって、ARTEMIS はインターネット警察というより、通信事業者が所有する管制室の計器に近い。証拠を整理し、経路更新を探す時間を短縮し、事前に協議された対応を準備できる。しかし、通信事業者の判断を不要にはできない。最終判断はグローバルルーティング、上流事業者との関係、顧客トラフィックに影響し得るため、対応の質は検知機能だけでなく、人員、設定、訓練済みの権限にも左右される。

BGP は到達可能性を伝えられても、権限を証明できるとは限らない

Border Gateway Protocol は、独立運用されるネットワーク間で到達可能性情報を交換し、ローカルポリシーを適用できるようにする。自律システムは一群の IP プレフィックスへ到達できると広告し、隣接ネットワークはその経路を受け入れ、優先し、さらに伝えるかを決める。この仕組みにより、単一の制御装置を共有しない組織間でもインターネットを拡張できたが、元来のプロトコルは、起点や経路に関するすべての主張へ暗号学的証明を付与しない。そのため、誤った経路送出、古い設定、意図的な広告によって、本来存在すべきでない経路が導入され得る。

経路選択によって、不正な広告が魅力的になる場合がある。同じプレフィックス長を対象とする二つの経路があれば、ネットワークは通信事業者ごとに異なるポリシーと経路選択規則を適用する。攻撃者または誤設定したネットワークが、より具体的なサブプレフィックスを広告すると、通常の最長一致により、その経路を受け入れた場所ではトラフィックが狭い範囲の経路へ向かう。これは攻撃専用の機能ではなく、ルーターが最も具体的な宛先を選択する通常の規則である。このため、正当な集約経路が見え続けていても、一見小さな広告がトラフィックを急速に迂回させる可能性がある。

「ハイジャック」は便利な略称だが、ルーティングメッセージからは分からない意図まで示唆し得る。未承認の起点は、悪意、事故、または監視ポリシーに反映されていない正当な商業上の変更による可能性がある。偽造経路はトラフィック傍受に利用できるが、コントロールプレーンの更新だけでは傍受を立証できない。そのため ARTEMIS は、警告を観測されたルーティングと意図されたルーティングの不一致として扱い、帰属と影響の判断をより広いインシデント対応に委ねるときに最も有効となる。

同一プレフィックスの事象では、予期しない経路と正当な経路が同じプレフィックス長で競合する。影響範囲は、両方の広告を受け取るネットワークのポリシーと経路選択に依存する。インターネットの一部では予期しない経路が優先され、別の部分では正当な起点が使われ続ける場合がある。その結果、単純な全面停止ではなく、部分的な到達性、地域差、成功と失敗が混在する分かりにくい状況が生じ得る。したがって検知では、経路の存在だけでなく、どこへどのように伝播したかにも注意する必要がある。

サブプレフィックス事象では、最長一致によってより狭い経路が優先されるため、影響が直接的になりやすい。通常/20を広告するネットワークの内部について別の起点が/24を広告した場合、その/24を受け入れたルーターは通常、対象アドレスへのトラフィックをサブプレフィックス側へ送る。デアグリゲーションも一般的な防御策であり、正当な通信事業者が同等またはさらに具体的な経路を広告して優先度を取り戻す。しかし、多くのネットワークが IPv4 では/24より長い経路、IPv6 では/48より長い経路をフィルターするため、防御には明確な限界がある。すでにその長さで広告している通信事業者には、世界的に受け入れられる、より狭い経路が存在しない場合がある。

ARTEMIS は、スクワッティングや、プロジェクト資料で説明されている no-export パターンを含む一部のポリシー違反も対象とする。ルーティングインシデントは、第三者が被害者のプレフィックスを起点にする場合だけではないため、これらの分類は重要である。起点が承認済みでも、想定外の関係を通じて経路が送出される場合がある。監視システムには、BGP データがネットワーク間のあらゆる非公開契約を明らかにするかのように装うことなく、こうした事例を区別できる十分なポリシー上の文脈が必要である。

ARTEMIS は通信事業者自身のルーティング方針を検知機能に組み込む

外部監視サービスには、各ネットワークに完全なシステムの運用を求めず、インターネットの多くの地点から情報を収集できるという明確な利点がある。一方、第三者は広告されたプレフィックスと経路を確認できても、通信事業者が正当とみなす起点変更、予備事業者、トラフィックエンジニアリング経路、緊急広告を把握していない可能性がある。一般的な規則では、微妙なポリシー違反を見逃したり、計画された変更に警報を出したりすることがある。

ARTEMIS は視点を反転させた。検知機能はアドレス空間が危険にさらされる組織自身によって運用され、その組織が正解となる情報を提供する。公開コレクターは広範な外部可視性を引き続き提供するが、その観測は、保護対象プレフィックス、承認済み起点 AS、許容される隣接先、選択された経路関係に関する非公開知識を通じて解釈される。ローカルルーターのフィードは、公開コレクターから見えない事象を追加できる。不完全なグローバル証拠も、明示されたローカルな意図と比較すれば有用性が高まるという組み合わせが、プロジェクトの中核となる考え方である。

検知機能を防御対象ネットワーク内に置くと、責任も内部へ移る。ARTEMIS を維持するネットワークは、誰がポリシーファイルを管理するのか、変更をどう審査するのか、どの警告をネットワーク運用センターへ送るのか、セキュリティチームが何を推定してよいのか、新しい経路を誰が承認できるのかを決めなければならない。ソフトウェアはその責任を可視化できるが、組織に適切な履行を強制することはできない。

ARTEMIS は、保護対象プレフィックス、正当な起点 AS、許容される隣接関係、一部のルーティング規則を通信事業者に定義させる。この正解情報により、一般的な監視サービスより正確な問いを立てられる。経路が世界的な履歴と比べて異常かを判断するのではなく、ネットワークが表明した意図に違反しているかを判定できる。

ただし、この利点の信頼性は定義内容に依存する。ネットワークは事業者を変更し、anycast 拠点を追加し、起点 AS を切り替え、一時的な予備経路を設け、障害時に緊急広告を行う。1月に正確だったポリシーが6月には誤っている可能性がある。運用変更がルーターには反映されても ARTEMIS へ届かなければ、重大度の高い誤検知が生じ得る。ノイズを抑えるためにポリシーを不用意に広げれば、実際の違反が書面上は承認済みになる可能性もある。

したがって、このシステムは技術設定を組織的な契約へ変える。ルーティング技術、セキュリティ運用、変更管理の各部門は、ファイルの意味、編集権限、本番環境への追随速度について合意しなければならない。ローカルな文脈は誤検知や見逃しをなくすのではなく、その主要因を通信事業者が管理できる場所へ移す。

ルーティングセキュリティ規則には、顧客トラフィックへ影響するソフトウェアと同等の規律が必要である。変更には、明確な責任者、審査、バージョン履歴、テスト、承認されたネットワーク変更に結び付く理由を持たせるべきだ。通信事業者は、プレフィックス、起点、隣接先がいつ追加され、誰が承認し、どのインシデントまたはプロジェクトが判断の根拠だったかを説明できる必要がある。通常の設定ファイルでもこの手続きを支えられるが、組織が一度限りの導入作業以上のものとして扱う場合に限られる。

テストには正常系と異常系の両方を含めるべきである。計画された正当な経路は警告なしで通過しなければならない。未承認の起点による同一プレフィックス広告は、想定された分類を作動させる必要がある。サブプレフィックス事象は適切な重大度を示し、no-export 違反を起点ハイジャックと混同してはならない。履歴の再生によってこれらを確認でき、ステージング環境では通知機能と緩和用ラッパーが意図したデータを受け取るかを検証できる。

この規律は組織的な知識の散逸による危険も抑える。ARTEMIS を最初に導入した担当者が退職しても、次の通信事業者担当者がポリシーを理解できなければならない。ロジックが文書化されていない記憶に依存する検知機能は、コードが公開されフィード遅延が小さくても、信頼できる基盤とはいえない。

FORTH と CAIDA は研究上の問いを通信事業者向けワークフローへ変えた

このプロジェクトは、University of Crete の研究環境に属する Foundation for Research and Technology-Hellas の研究者と、University of California San Diego の CAIDA による共同研究から始まった。FORTH はルーティングセキュリティとシステム研究を担った。CAIDA はインターネット計測基盤、BGPStream の専門知識、設計を研究・教育ネットワークへ展開するのに役立つ関係を提供した。したがって、このプロジェクトは単なる検知アルゴリズムではなく、プロトコル知識、計測システム、通信事業者への接点を結び付けたものだった。

資金も同様に複数機関の組み合わせだった。プロジェクト記録には、欧州および米国の研究プログラム、RIPE NCC Community Projects Fund の支援、NSF EAGER 導入プロジェクト、US Department of Homeland Security、Comcast Innovation Fund が記載されている。2017年の RIPE による支援は試作版を通信事業者向けツールへ移行するのに役立ち、2019年の5万ユーロの助成は RIPE Atlas を使ったデータプレーン検証に充てられた。これらは公益研究が導入可能なソフトウェアへ変化した過程を示すが、現在の本番導入を維持する費用までは明らかにしない。

組織的な歴史は帰属を理解するうえで重要である。ARTEMIS は、独立法人化された財団でも、CAIDA のサービスでも、FORTH が所有するグローバル検知サービスでもない。BSD 3-Clause ライセンスで提供されるオープンソースソフトウェアであり、研究上の系譜と現在の商業的な保守担当者を持つ。その開発経路は、一つの組織の所有物というより、連続する共同作業として理解するのが適切である。

最初の公開上の節目は、2016年の ACM SIGCOMM でのデモンストレーションだった。この段階で重要だったのは、監視と緩和を一つのループに結び付けたことである。多くのシステムは、十分な証拠を集めた後に不審な経路を特定できる。ARTEMIS は、通信事業者が事象を十分に早く検知し、実用的な対抗策を事前に用意することで、インシデントがダッシュボード、電子メール、手動のルーター操作の間を何時間も移動する事態を避けられるかを問うた。

デモンストレーションは成熟した本番導入ではない。定義された構成で構成要素が連携でき、研究課題を具体的に実演できることを示すものにすぎない。それでも2016年の研究は、その後の方向性を定めた。リアルタイム観測、正当なルーティングに関する内部の見解、分類、準備済みの広告という流れにより、対応時間は組織上の後付け事項ではなく、システムの特性になった。

設計には、ハイジャック対応に数時間を要する場合があるという通信事業者の証拠が反映された。遅延は経路コレクターが遅いことだけから生じるのではない。チームは所有権を確認し、伝播を調べ、計画された事象かを判断し、適切な上流連絡先を探し、安全な緩和策を構成する必要があった。ARTEMIS はポリシーとワークフローを監視システムの近くに置くことで複数の手順を短縮できるが、経路を取り巻く人的・商業的関係はコードの外側に残る。

2018年の IEEE/ACM Transactions on Networking 論文は、「1分以内に BGP ハイジャックを無効化する」という ARTEMIS の最も印象的な主張を示した。研究者は実環境の実験で手法を評価し、試験条件下で数秒以内の検知と1分以内の緩和を報告した。この結果は、被害ネットワークが必ずしも第三者サービス、電話連絡網、手作業で作成する対抗広告を待つ必要がないことを示した点で重要だった。

しかし、この表現は実験条件から切り離すと誤解を招く。検知時間は、事象が接続済みモニターへ届くか、フィードが更新を届ける速度、検知規則との一致、システムの正常性に左右される。緩和時間は、被害者のプレフィックス長、ルーティング権限、上流フィルター、伝播、承認手続きに依存する。人による確認を必要とするネットワークは、より安全な判断と引き換えに時間を要する場合がある。即時自動化するネットワークは、より速く対応できても、より多くのリスクを負う。

責任ある結論には範囲を設ける必要がある。ARTEMIS は、緊密に統合された通信事業者側のシステムが、従来はるかに長時間を要した手続きを短縮できることを実証した。あらゆるハイジャックを観測できること、すべての対抗経路が受け入れられること、すべての本番チームが自律的なデアグリゲーションを許可すべきことを証明したわけではない。この結果は普遍的保証ではなく、実験に裏付けられた設計目標として読むべきである。

複数の不完全な視点から利用可能なインシデント記録を構築する

単一のコレクターがすべての経路を観測できないため、ARTEMIS は複数の公開情報源を利用できる。RIPE RIS と University of Oregon の RouteViews プロジェクトは、分散した収集地点で選択されたピアから BGP 更新を受信する。CAIDA BGPStream は、複数の情報源からルーティングデータへアクセスし、正規化するための枠組みを提供する。各サービスは通信事業者の視野を広げるが、コレクターとのピアリングを選択したネットワーク、セッションの場所、フィードのタイミングを反映する。

この部分的な可視性には実務上の影響がある。事象が一つの地域に伝播しても、導入環境で使用されるコレクターへ届かない場合がある。非常に短い広告は、フィードが配信する前に取り下げられる可能性がある。公開データに表れない非公開の関係を通じて、被害者の顧客へ影響する経路もあり得る。複数のコレクターを組み合わせれば一部の死角は減るが、得られるのはより大きな標本であり、グローバルなコントロールプレーンの全知的な複製ではない。

したがって、適切な運用上の問いは「ARTEMIS はインターネットを観測したか」ではない。「どの観測者がこの広告を確認し、どれだけ早く確認し、事象のどの部分がまだ標本外にある可能性があるか」である。この表現により、通信事業者は各警告の出所を保持し、一つのフィードに存在しないことを経路が存在しなかった証明として扱わずに済む。

RIPE NCC は2019年2月、定期的なアーカイブ処理より大幅に低遅延で BGP メッセージを配信する公開 RIS Live 試作版を導入した。ARTEMIS は、この種のフィードが重要である理由を示す事例の一つとなった。主要な観測結果が何分も遅れて届くなら、セキュリティシステムは数秒では対応できない。ライブストリームなら、コレクターが受け取った更新を検知機能が随時評価できる。

低遅延になっても、コレクターが観測できる対象は変わらない。RIS Live は、RIPE Routing Information Service へ接続されたピアと、それらが送出する経路を反映する。ハイジャックが局所にとどまる場合、コレクターへ届く前にフィルターされる場合、別の関係の背後にある経路へ影響する場合、フィードは決定的証拠を伝えない可能性がある。信頼性も重要であり、監視サービスが「不審な経路なし」と「データなし」を区別しなければ、ストリーム停止や形式変更が無反応に見えることがある。

このため、フィードの健全性はセキュリティモデルに含まれる。通信事業者は、各モニターが最新か、遅延しているか、切断されているか、異常な量の更新を生成しているかを把握する必要がある。入力が劣化しているのに一つの確信的な状態を示す検知機能は、明示的な停止より危険な無知を生み出し得る。

リアルタイム監視は現在出現しているものを示し、経路情報ベースと更新アーカイブは文脈を提供する。RIPE RIS と RouteViews は、インシデント前に確認された起点と経路、変更の開始時刻、継続時間を示せる履歴データを公開している。CAIDA BGPStream は共通の枠組みでそれらを処理しやすくし、ARTEMIS による事象の再生と過去のルーティング動作に対する規則の検査を可能にする。

再生は技術検証と審査に有用である。チームは、新しいポリシーが既知の事象を検知できたかを確認し、警告に至った流れを再現し、本番経路を操作せずに対応担当者を訓練できる。履歴証拠は、単独では異常に見えても実際には確立された予備構成である繰り返し広告を明らかにすることもある。ただし、アーカイブが保存するのはコレクターの視点であって事象全体ではなく、過去のトポロジーですべての現在の関係を再現することはできない。

成熟した導入では、変更管理の一部として再生を利用できる。新しい起点、上流、送出規則を本番へ入れる前に、修正済みの正解情報を代表的な履歴に対してテストし、通常のルーティングが恒常的な警報へ変わらないことを確認できる。この実務により、検知設定はノイズが発生した後にだけ編集されるファイルではなく、監査可能なセキュリティ資料となる。

公開データは設計の一面にすぎない。ARTEMIS は ExaBGP または非公開の BGP Monitoring Protocol セッションを通じてローカル更新を受信できる。ExaBGP はプログラム可能な BGP スピーカーとして動作し、経路事象を別のソフトウェアへ送れる。BMP を使うと、監視システムを転送判断に参加させずに、ルーターからルーティング情報を送出できる。これらは、公開コレクターから見える前の、保護対象ネットワーク自身の隣接関係と経路状態を示し得る。

ローカルフィードは即時性と文脈を改善するが、機密性の高い基盤情報をシステムへ取り込む。BMP データは大量になり、内部のルーティング関係を明らかにする可能性がある。ExaBGP との統合には慎重な制御が必要である。同じプログラム可能なインターフェースが、経路の観測だけでなく広告にも使えるからだ。認証情報、ネットワーク到達性、メッセージ検証、監視と緩和の分離がセキュリティ境界となる。

適切に設計された導入では、公開フィードと非公開フィードを異なる目的に使う。公開コレクターは、広告が通信事業者の直近の周辺を越えてどう広がっているかを示す。ローカル情報源は、通信事業者とそのルーターが直接観測したものを示す。両者の不一致は必ずしも誤りではなく、伝播が止まった場所やポリシーが作用した場所を理解するための証拠になり得る。

アプリケーションは観測、検知、証拠を分離する

現在のシステムは、一つのスクリプトがストリームを読む構成ではなく、複数コンテナから成るマイクロサービスアプリケーションである。監視サービスが公開・非公開フィードへ接続し、受信した BGP 情報を正規化して事象を配信する。検知サービスがそれを受け取り、通信事業者の規則を適用する。ストレージ、API、ウェブ画面、通知、監督機能が中核部分を取り囲む。この分離により構成要素を独立して拡張または障害処理でき、アプリケーション全体を書き換えずに新しいフィードを追加しやすくなる。

モジュール化は依存関係も増やす。モニターが正常でも検知機能が停止している場合がある。メッセージバスが事象を受け入れても、データベースを利用できないことがある。リアルタイム処理が壊れている一方で、ウェブ画面が古いインシデントを表示する場合もある。コンテナ管理機能がサービスを再起動し、繰り返す異常終了を隠す可能性もある。したがって運用には、個別コンテナの起動状態だけでなく、情報源から警告までの経路全体を示す健全性確認が必要である。

Docker Compose は管理された導入の障壁を下げ、Kubernetes 対応は既にコンテナ基盤を運用する組織に適する。どちらもシステムを管理付きのグローバルサービスへ変えるものではない。導入するネットワークが、処理能力、更新、秘密情報、ストレージ、バックアップ、インシデント時のアクセスを引き続き管理する。

メッセージバスにより、監視、検知、通知サービスは一つの処理が他を直接制御することなく事象を交換できる。この設計は更新の急増を吸収し、受信側が異なる速度で処理できるようにする。一方、順序、重複、処理滞留に関する問題も生じる。ルーティングインシデントには数千件の更新、取り下げ、経路変更が含まれ得るため、通信事業者が事後に経緯を再構築できるだけの順序と出所を保存しなければならない。

永続ストレージは、一時的な警報にはない利点を ARTEMIS へ与える。更新、警告、設定状態、インシデント判断を保存して審査できる。プロジェクトの構成では、PostgreSQL 関連部品、Timescale 型ストレージ、Hasura API 環境が使われてきた。これらは検索と統合を支える一方、保存期間、アクセス制御、信頼できるバックアップを必要とする、ルーティングおよび運用証拠の機密性の高い保管場所も生み出す。

監査可能性は確実性と同じではない。システムが受信した内容の完全な記録は、ARTEMIS が警告へ至った理由を証明できる。しかし、関連するすべての経路を受信したことや通信事業者の規則が正しかったことは証明できない。したがって、データベースには最終的なインシデント分類だけでなく、情報源と確信度も保存すべきである。

ウェブ画面は、ネットワークまたはセキュリティ運用チームが利用できる形で、インシデント、システム状態、ルーティング観測を表示する。通知は電子メール、モバイル経路、独自統合へ警告を送り、Grafana ダッシュボードはサービスの健全性と事象傾向を示せる。対応チームには生の BGP 更新ではなく、優先順位、履歴、共通の視点が必要であり、これらの機能が研究上の仕組みを運用製品へ変える。

画面は誤った安心感を生むこともある。赤色のインシデントカードは観測と規則から得た分類であり、悪意を独立に認定したものではない。地図や経路表示は、選択されたコレクターだけを表していても完全に見える場合がある。計画変更がポリシーへ反映されなければ通知がノイズ化し、警告疲れによって重要な一件が無視される可能性もある。

適切な運用では、利用画面と検証を結び付ける。対応担当者は、情報源となる更新を確認し、公開フィードとローカルフィードを比較し、現在の RPKI 状態を調べ、データプレーンテストを実行し、インシデントをエスカレーション、無視、解決した理由を記録できる必要がある。ダッシュボードはその経路を短縮するときに有用であり、検証を置き換えるものではない。

経路パターンだけでは動機や影響を証明できない

ARTEMIS の研究では、プレフィックス関係、AS パス操作、ポリシー、考えられるデータプレーン影響によって事象を区別する分類体系が開発された。実装は、同一プレフィックスおよびサブプレフィックスの起点事例、スクワッティング、一部の送出違反など、コントロールプレーンの証拠から判定できる定義済みの一部パターンを扱う。分類体系は通信事業者に一貫した言葉を与え、検知機能が事象ごとに異なる規則を適用するのに役立つ。

分類はデータが示す範囲に結び付けておく必要がある。予期しない隣接先から始まる経路は、偽造された区間、経路漏えい、またはポリシーに記録されていない承認済み変更を示す可能性がある。未承認の起点も、攻撃ではなく誤りの場合がある。意図的な広告であっても、トラフィック遮断、サービス偽装、通過トラフィックの観測など目的は複数考えられ、BGP 更新だけでは区別できない。

慎重な表現は、正確性と対応品質の両方を守る。警告段階では「疑いのあるハイジャック」または「ポリシー違反」の方が通常、「攻撃」より安全である。経路の所有権、通信事業者との連絡、データプレーン証拠が裏付けた後に、より強い表現を使える。この抑制はセキュリティを弱めるのではなく、インシデントシステムが不確実性を、他のチームが事実として繰り返す主張へ変えてしまうことを防ぐ。

BGP メッセージは、ネットワーク間で交換される到達可能性の主張と経路情報を示す。選択された経路を通るすべてのパケットを示すものではない。不審な広告の後、トラフィックは遮断され、傍受された後に転送され、偽装サービスから応答される可能性がある一方、関連利用者を運ぶネットワークへ経路が伝播せず影響を受けない場合もある。インターネットの異なる部分が同時に異なる結果を経験し得る。

この境界は ARTEMIS の中核である。検知機能は、経路が通信事業者のポリシーに違反し、特定された観測地点に出現したことを示せる。しかし、AS パスから動機を推測することはできず、traceroute がアプリケーショントラフィックと同じ方向を通ることも保証できない。暗号化、DNS 動作、キャッシュ、anycast、アプリケーションのフェイルオーバーによって利用者の体験はさらに変化する。そのため、コントロールプレーン警告はインシデントの証拠ではあるが、インシデント全体ではない。

有用な対応では複数の記録を結び付ける。BGP 証拠は広告と伝播を明らかにする。データプレーンテストは選択された場所から到達性と経路を調べる。サービステレメトリーはエラー、遅延、顧客への影響を示す。上流事業者との連絡により、経路が承認済みだったか誤りだったかを確認する。どの記録も完全ではないが、組み合わせれば一つのフィードだけでは得られない判断を支えられる。

2019年の RIPE Community Projects Fund 助成は、検知事象の影響を調べるために RIPE Atlas の traceroute 測定を利用する ARTEMIS 拡張を支援した。この研究は、当初のコントロールプレーンループの限界を認識したものだった。BGP 上は危険に見える経路でも観測可能な影響がほとんどない場合があり、伝播範囲が小さくても重要な顧客層へ影響する可能性がある。データプレーンのプローブは、トラフィックがどこへ向かっているように見えるか、エンドポイントへ到達できるかについて証拠を追加する。

RIPE Atlas は分散したプローブ網を持つが、配置は均等ではなく、選択した対象が経路を明らかにする形で応答しない場合がある。traceroute はフィルタリング、負荷分散、トンネル、非対称ルーティングの影響を受ける。プローブから宛先までの往路が、反対方向の顧客トラフィックと同じ経路とは限らない。測定失敗は、障害、応答しない中継点、テスト固有の制約のいずれも意味し得る。

実務上の利点は確実性ではなく、より良い初動判断である。BGP コレクターが未承認のサブプレフィックスを示し、複数地域のプローブで到達性喪失または予期しない起点方向への変化が確認されれば、通信事業者にはエスカレーションのより強い証拠が得られる。コントロールプレーン上の事象が一つのコレクターだけに見え、データプレーンテストが安定していれば、チームはグローバル広告を変更する前に調査できる。判断は依然として文脈依存だが、見えないままではない。

デアグリゲーションでトラフィックを回復できるのは、ルーティングシステムが許す場合に限られる

ARTEMIS で最もよく知られる対応はデアグリゲーションである。広いプレフィックスを広告している被害者は、より具体的な経路を起点として広告し、通常の最長一致によってトラフィックを正当なネットワークへ引き戻せる。この方法は既存の BGP 動作を利用して速く伝播できるため、プロジェクトの実験的な「1分以内」という目標に適していた。また、サービス回復を始める前に予期しない起点の協力を待たず、被害者側に権限を維持できる。

デアグリゲーションには厳しい限界がある。多くのネットワークは、ルーティングテーブルの増大と運用上の乱用を抑えるため、IPv4 では/24より長い経路、IPv6 では/48より長い経路をフィルターする。すでに/24または/48を広告している被害者は、より広いインターネットが受け入れる具体的な経路を生成できない場合がある。上流事業者が顧客の広告範囲を制限していることもあり、経路オブジェクト、プレフィックスフィルター、RPKI データが緩和用経路を許可している必要もある。伝播は即時でも均一でもないため、古い経路と新しい経路が併存し得る。

準備のできた通信事業者は、インシデント前にこれらの境界を把握しておくべきである。どのプレフィックスをデアグリゲーションできるか。どの上流事業者が受け入れるか。緊急状態をどの経路フィルターと Route Origin Authorisation が既に対象としているか。復旧後に経路をどう取り下げるか。ARTEMIS はラッパーを起動できるが、成功はアプリケーション外で整備された取り決めに依存する。

プロジェクト資料は自動緩和という表現を使い、研究には検知が対抗広告を作動させる閉ループが含まれる。一方、詳細な運用説明には手動確認と独自ラッパーも記載されている。導入環境が異なる自律性を選ぶため、どちらも正しい場合がある。安全な表現は、ARTEMIS が設定可能なワークフローを通じて、自動または通信事業者の承認を経た緩和を支援するというものである。

リスクは非対称である。対応の遅れは停止または傍受を長引かせる。誤った自動対応は、不要な具体的経路を広告し、上流ポリシーに違反し、内部の前提を漏らし、元の事象を調査中に不安定性を生む可能性がある。古い正解規則により、計画変更が緊急事態に見える場合もある。ラッパーが広範なルーター認証情報を持つなら、ARTEMIS の侵害そのものがルーティング攻撃になり得る。

より安全な自動化は段階的である。まず警告へ情報を追加し、複数のフィードを確認し、RPKI 状態を検証し、データプレーンテストを行い、正確な経路変更を準備できる。影響の大きい行動は人が承認し、低リスクの事例にはポリシーに基づく自動化を適用できる。速度制限、限定された認証情報、シミュレーション、変更記録、検証済みのロールバック経路は、「自動」という名称より重要である。目的は手作業そのものを維持することではなく、速度によって説明責任を失わないようにすることである。

RPKI は証拠連鎖の一部を強化する

Resource Public Key Infrastructure を利用すると、アドレス保有者は、指定プレフィックスと最大長をどの自律システムが起点にできるかを示す Route Origin Authorisation を作成できる。ルーターまたはポリシーシステムは Route Origin Validation を行い、経路を有効、無効、未登録に分類できる。これにより、分散した信頼に依存していた BGP の一部分へ暗号学的証拠が追加される。他のネットワークがトラフィックを追従させる前に未承認の起点を拒否または低優先化できるため、予防的な管理策である。

ARTEMIS はインシデントの別の層で機能する。RPKI 検証状態を証拠として利用できるが、非公開の通信事業者規則との比較、事象の記録、公開・ローカルフィードの統合、検知と対応の接続も行う。RPKI は AS パス全体を検証せず、導入ポリシーも普遍的ではない。RPKI 上有効な経路でも、想定された隣接関係に違反したり、通信事業者が意図しない経路を通じて漏えいしたりする場合がある。正当な運用変更が ROA へ反映されていなければ、経路が無効と判定されることもある。

したがって両システムは補完的である。RPKI は、より広いインターネットで受け入れられる未承認の起点経路を減らせる。ARTEMIS は被害者に観測状況を示し、単純な起点有効性を超える一部パターンを検知し、対応を整理できる。ASPA のような将来の経路承認機構は関係についての証拠を強化し得るが、ネットワークが実際に何を広告し、インシデントがサービスへどう影響するかを監視する必要はなくならない。

試験導入は ARTEMIS を研究室の外へ進めたが、市場規模を証明してはいない

CAIDA は、2018～2019年に Internet2、Great Plains Network、Merit と実施した、NSF 支援による ARTEMIS の実験導入を報告した。研究・教育ネットワークには実際のプレフィックス、上流事業者、変更手続き、サービス上の責任があるため、これらの試験は重要だった。通信事業者は、ソフトウェアが既存の監視へ適合するか、規則がルーティング方針を捉えるか、警告をインシデント対応へどう取り込むかを試せた。

この記録は信頼できるが、範囲は限定される。試験導入は、設置、技術的な意見、一部の運用利用を示せる。しかし、継続的な本番対象範囲、現在のバージョン状況、あらゆる種類のネットワークでの性能は証明しない。プロジェクトサイトには AMS-IX、Internet2、ESnet に関係する技術者の発言と組織ロゴも掲載されている。これらは試験または利用を示すが、すべての組織が現在の有料顧客であることや、プロジェクトが既知の世界シェアを持つことを意味しない。

この区別が重要なのは、ルーティングセキュリティソフトウェアの導入が外部から見えないことが多いためである。通信事業者は内部フォークを運用し、緩和なしで監視だけを利用し、試用後に停止する場合がある。完全な調査がないことはプロジェクトが無関係であることを意味しないが、導入状況を正確に述べることはできない。裏付けのない大きな数字より、名称が明らかな事例の方が強い証拠となる。

通信事業者による管理には、統合とソフトウェア供給網の負担が伴う

ARTEMIS は BSD 3-Clause ライセンスで配布される。通信事業者はコードを検査し、管理された基盤で実行し、統合を調整し、機密性の高いポリシーを単一の必須中央事業者へ送らずに済む。このモデルは、最も価値の高い正解情報をネットワーク内部へ置くというプロジェクトの中核的な利点に合致する。また、商業利用とフォークが認められ、Code BGP などがオープンな基盤の上にサービスを構築できる。

管理には作業が伴う。システムにはコンテナ、メッセージバス、データベース、API、ウェブアプリケーション、通知システム、フィード統合が含まれる。それぞれに修正、認証情報、ネットワーク分離、バックアップ、監視が必要である。システムは機密性の高いルーティングポリシーを保存し、経路広告に影響できる認証情報を持つ可能性もある。本番導入のセキュリティ対象範囲は、元の検知アルゴリズムよりはるかに広い。

オープンライセンスは通信事業者に特定保守担当者から離れる選択肢を与えるが、自動的に支援組織を提供するものではない。フィードまたはルーターのインターフェースが変わったとき、更新をテストし、依存関係を審査し、コードを理解する担当者が必要である。小規模ネットワークでは、ローカルな管理能力が弱くても、より単純な警告ツールや管理付き商業サービスの方が運用しやすい場合がある。

本番 ARTEMIS サービスは、通信事業者がそれを必要とする原因となるネットワーク不安定時にも利用できなければならない。フィード接続、メッセージバス、データベース、API、画面、通知経路、認証層が一つのサービス連鎖を構成する。コンテナ単位の冗長性が有効なのは、状態、ストレージ、外部依存関係も障害を前提に設計されている場合に限られる。再起動したモニターは保存されなかった更新を回復できず、複製された画面も、検知処理が扱えなかったインシデントを表示できない。

したがって運用設計には、明示的な縮退モードを含めるべきである。一つの公開フィードが失われた場合、区別のない正常状態を表示し続けるのではなく、観測範囲が狭まったことを示す必要がある。データベースを利用できない場合、検知機能は事象をローカル保存するか、監査証拠を書き込めないため緩和を停止する必要があるかもしれない。ID 管理サービスが停止した場合は、恒久的な無管理アカウントを残さず緊急アクセスを可能にすべきである。これらはハイジャック分類では説明されないが、研究上の着想が信頼できる基盤になるかを決める。

システムには独自の性能上限も必要である。大規模なルーティング変更に伴う正当な更新の急増は、単一のハイジャックより監視機能とストレージへ負荷をかける場合がある。アプリケーション内部のキューによって、遅延を可視化しないまま準リアルタイムフィードが遅いインシデントへ変わってはならない。処理能力テスト、データベース保存期間、メッセージバスの処理滞留は、経路フィルターやプレフィックス長と同じく、システムが誠実に約束できる対応範囲を定めるため、導入計画に含める必要がある。

ARTEMIS はウェブソフトウェア、コンテナイメージ、データベース、メッセージング部品、API、認証、ネットワークライブラリを統合する。この構成は拡張性をもたらすが、すべての依存関係が脆弱性または障害点になり得る。利用画面の欠陥がルーティングポリシーを漏らし、侵害されたイメージが警告を改変する可能性がある。過度な権限を持つ API トークンはインシデントを漏えいし、緩和用ラッパーに付与された認証情報は経路変更を可能にする。検知機能の安全性は、運用に使うソフトウェアの安全性と切り離せない。

オープンソースであれば、通信事業者は構成要素を検査し、バージョンを固定し、イメージを自ら構築できる。ただし、すべての間接依存関係が審査済みであることや、公開された脆弱性がネットワークの必要な日程で修正されることは保証されない。本番チームには、イメージとライブラリの一覧、再構築手順、読み取り専用監視と書き込み可能な緩和の分離、インシデント履歴を失わずにセキュリティ更新を試す方法が必要である。

この要件により、プロジェクトの保守は別の基準でも評価される。新しい検知機能はデータベース更新や認証修正より注目を集めやすいが、サービスの完全性には後者の方が重要な場合がある。セキュリティ勧告、再現可能なビルド、依存関係の更新、支援対象のリリースブランチは、ダッシュボードへ目に見える選択肢を追加しなくても、運用成熟度の証拠となる。

リリースと Code BGP が現在の保守能力を測る基準となる

調査資料で確認された最新の正式なタグ付きリリースは、2022年11月24日付のバージョン2.3.0、名称 Cadmus である。2026年8月5日の基準日時点で、公開デモはそれより後のコミットに基づくビルドを表示し、現在のプロジェクトサイトも稼働していた。これらは、最後の正式リリース後も作業が続いたとの結論を支える一方、どのバージョンがテスト済みで、支援対象で、更新に適しているかという正当な本番上の疑問を生む。

コミット活動と稼働中のデモは開発を示す。セマンティックなリリースは、名称付きの基準、リリースノート、依存関係の想定、通信事業者がテストする基点という別の保証を提供する。正式なリリース手続きが遅れていてもプロジェクトが活動中である場合はあり、現在のデモが、本番通信事業者が審査なしに採用すべきでないコードを動かしている可能性もある。

ルーティングセキュリティ基盤では、リリース規律もセキュリティモデルの一部である。通信事業者は、どのブランチが修正を受け、移行がどう扱われ、古い依存関係が脆弱なままかを知る必要がある。新しいタグだけで普遍的な信頼性は証明できないが、公開された支援・セキュリティ方針は、現行サイトの存在だけより不確実性を減らす。

プロジェクトサイトは Code BGP を ARTEMIS の現在の保守担当者として示し、同社をプロジェクトから派生したスタートアップと説明している。商業化は、オープンソースが抱える現実的な問題を解決し得る。ルーティングセキュリティソフトウェアには、統合を維持し、脆弱性へ対応し、導入を支援し、当初の助成終了後も研究機能を信頼できる運用へ変える人材が必要だからである。

ただし、Code BGP はより広い製品および顧客関係を持つ独立した商業企業である。FORTH、CAIDA、すべてのオープンソース導入の別名として扱うべきではない。調査資料の公開証拠は、同社の売上高、評価額、顧客一覧、コミュニティ機能と商業機能の正確な境界を開示していない。これは批判ではなく、プロフィールで主張できる範囲の限界である。

この関係には、一致する場合も分かれる場合もある二つの動機がある。商業スタッフがテスト済みコードと文書へ貢献すれば、オープンプロジェクトは恩恵を受ける。オープンプロジェクトが信頼、導入、技術的基盤を構築すれば、企業は有料サービスに活用できる。長期的な判断基準は、商業顧客でない通信事業者にも、リリース、セキュリティ修正、開発方針が十分に見える状態が維持されるかである。

寛容なライセンスは、ソースの複製、変更、商業化を可能にする。しかし、別のチームが構成を理解し、リリースを再現し、現在の専門家が離れた後に保守を引き継げることまでは保証しない。プロジェクトの長期継続性は、文書、テスト、課題履歴、依存関係の知識、元の研究システムを構築した人々以外にも開かれた貢献経路に依存する。

Code BGP による管理は、経験豊富な技術者をシステムへとどめ、継続性を強化する可能性がある。一方、リポジトリが公開されていても、実務知識が商業組織内へ集中する可能性がある。この違いは、リリースノート、公開設計協議、コミュニティ報告への対応、非顧客の導入環境が安全な運用に十分な情報を得られるかによって確認できる。

目的は商業価値を妨げることではない。健全なオープンコア関係では、有料支援と公開保守を一致させられる。リスクは、オープンプロジェクトが歴史的デモになり、運用経路が文書化されていない非公開部品へ移ったときに生じる。したがって可搬性は実際に検査すべきである。独立した通信事業者が、その時点で利用できる公開記録だけを用いて、システムを導入、更新、監査、復旧できるかが問われる。

ARTEMIS はルーティングセキュリティの中でも要求の厳しい中間領域に位置する

ルーティングセキュリティ分野には、公開コレクター、研究上の推定システム、オープンソース警告ツール、RPKI 検証機能、商業監視サービスがある。RIPE RIS、RouteViews、BGPStream は、通信事業者固有のインシデントワークフローではなくデータを提供する。BGPalerter は別のオープンソース監視モデルを提供する。MANRS は運用規範を定めるが、リアルタイム事象を検知しない。商業サービスは広範な監視と分析担当者による支援を提供できる一方、顧客が統合しなければ非公開のローカルな文脈を持たない場合がある。

ARTEMIS の独自性は、通信事業者による管理、明示的な正解情報、複数の公開・ローカルフィード、公開コード、任意の緩和機能の組み合わせにある。同時に、その位置付けは要求が厳しい。ネットワークにはルーティングの専門知識、ポリシーの維持、複数サービスから成るシステムの運用が必要である。そのため、ダッシュボード購読ではなく、ルーティングセキュリティを中核能力と考える組織に最も適している可能性がある。

比較を機能表だけに還元すべきではない。モデルごとに、信頼と作業を置く場所が異なる。管理付きサービスは専門知識と観測を集中させる。通信事業者運用型システムは、ポリシーと行動をネットワークの近くに保つ。重要なのは、証拠が不完全なときに、どの当事者が十分に観測し、安全に行動し、説明責任を維持できるかである。

ARTEMIS Lite は2023年の RIPE コミュニティ資料に、導入負担の一部を軽減する関連する簡易手法として登場した。Lite 版の存在は、完全版システムの広範な機能が小規模チームには難しい可能性を示す。永続ストレージ、複数フィード、独自緩和を備えた複数コンテナ構成は、大規模通信事業者には適切でも、まず明確な可視性と信頼できる警告を必要とするネットワークには過剰な場合がある。

名称と目的を共有するだけで、簡易システムを同等と説明すべきではない。調査資料は ARTEMIS Lite の機能が削減されているとしており、発表資料の主張には独立した確認が必要である。重要な比較は、運用費用の削減と、不足し得る文脈、統合、履歴、対応機構との間にある。小規模導入でも、その境界を正直に定義すれば価値を持ち得る。

導入は、ツールが必要とする組織的な仕組みの量に左右される。技術的に公開されていても、コンテナ、データベース、ルーティングセキュリティの専門家がいない通信事業者には利用しにくい場合がある。パッケージ化、妥当な初期設定、監視から検知、緩和へ進む段階的な経路が、この構成が研究論文を超えて広く普及するかを決める可能性がある。

本当の製品は、統制されたフィードバックループである

ARTEMIS は一度の手順で BGP を信頼できるものにするわけではない。完全な承認機能なしに作られたプロトコルの周囲へループを構築する。通信事業者が意図するルーティングを表明する。公開・ローカルフィードが観測されたルーティングの一部を示す。検知機能が逸脱を特定する。ストレージと画面が証拠を整理する。人または承認済み自動処理が対応を選び、その後のフィードが伝播の変化を示す。インシデントは、理由を記録したうえで解決、無視、取り下げ、エスカレーション、休止状態の維持のいずれかとなる。

このループがプロジェクトの最も永続的な貢献である。ルーティングセキュリティは一度限りの証明書でも、遠隔から届く警報でもない。ポリシーを明示し、観測の出所を保持し、緊急事態の前に対応権限を準備する必要がある運用実務である。システムの価値は、不確実性が消えたかのように装うことではなく、ネットワークが行動できる速さまで不確実性を狭めることにある。

限界も同様に示唆的である。経路コレクターの観測は部分的である。正解情報は古くなり得る。コントロールプレーン証拠は動機やすべてのトラフィック結果を証明できない。技術的に有効な緩和策でも、フィルターされたり有害になったりする可能性がある。オープンソースコードにも継続的な保守が必要である。ARTEMIS が最も有効なのは、こうした限界を1分対応という見出しの背後へ隠さず、ワークフローへ組み込む場合である。

BGP 異常は、ネットワーク運用センター、セキュリティ運用センター、またはその両方へ届く。ルーティングチームはプレフィックス、上流ポリシー、経路広告変更のリスクを理解する。セキュリティチームは、ID、サービステレメトリー、悪意の可能性を関連付ける準備がより整っている場合がある。ARTEMIS は両領域を横断するが、各チームが異なる前提で別々の調査を始めるのではなく、同じ事象を扱えるだけの証拠を警告が持つ場合にのみ有用である。

引き継ぎでは、観測、ポリシー、影響を区別すべきである。システムは名称が明らかなフィードで経路を観測した。その経路は特定の正解規則に違反した。サービス確認または RIPE Atlas プローブが明確な影響を示した、あるいは影響はまだ確認されていない。通信事業者は上流事業者または経路起点へ連絡し、回答を待っている。この構造により、NOC がセキュリティ上の懸念を通常のルーティングとして退けることや、SOC が運用上の事実を確認する前に未承認広告を攻撃と呼ぶことを防げる。

共通の言葉は事後学習も改善する。事例は、ポリシーから漏れた計画変更、偶発的な経路漏えい、疑いのあるハイジャック、確認済みの悪意ある事象、未解決の異常として終了できる。その結果を規則、手順書、上流事業者との取り決めへ反映すべきである。このループがなければ、検知機能はルーティング管理を改善するシステムではなく、チケットを生成する機械になり得る。

最速の警告が常に最も有用とは限らない。検知機能は最初の予期しない更新で作動しても、その後、フィードが古い、経路が計画済みだった、被害者とされた組織が新しい起点を承認していたと判明する場合がある。反対に、すべてのコレクターとデータプレーンテストを待てば、早期対応の利点を失い得る。ARTEMIS には、生の検知遅延と最終的なインシデント終了の間に位置する尺度が必要である。それは、権限を持つ通信事業者担当者が説明可能な判断を下せるだけの信頼できる証拠を集めるまでの時間である。

この尺度は分解できる。最初の観測はどれだけ早く届いたか。独立したフィードはいくつ確認したか。関連ポリシーは最新だったか。RPKI またはローカル BMP は証拠を追加したか。サービス確認にはどれだけかかったか。責任者はいつ警告を受け、いつ対応を承認したか。緩和策は意図した伝播を実現し、問題なく取り下げられたか。これらの問いは、結果全体を検知アルゴリズムだけへ帰属させず、遅延が実際にどこに存在するかを明らかにする。

信頼できる判断までの時間を測る指標は、危険な最適化も抑える。少ない証拠で行動したり、不要なルーティング変更を生んだりした場合に、単に速かったという理由でシステムを評価すべきではない。最良の導入とは、不確実性と対応時間を同時に減らしながら、インシデント後に審査できる記録を維持するものである。