経路を守る検証が、経路を消すとき――JANOG の RPKI 実験が残した「安全な失敗」の宿題

Summary

2013年1月22日から7月31日まで活動した JANOG の一時的な RPKI Routing WG は、証明書と ROA の操作、キャッシュ構築、RTR を介したルータ側の観察を演習した。初回には環境・ソフトウェアの不具合があり、修正後の回では完了できる範囲が広がったが、これは本番網での全国的な導入試験ではない。
JANOG32 では、複数キャッシュ、RTR 断、ルータ再起動、壊れた検証データ、「すべてが Invalid」に見える事態、異常な割合に応じて更新を止める案が議論された。ただし数値も正式な採用も確認できず、RFC 6810は会合より前から複数キャッシュ、データ保持、代替キャッシュへの接続を規定していた。
後年の IIJ、NTT、JPNIC、JPIX などの記録は、監視、段階導入、実装と拠点の分散、ロールバック、ローカル例外という方向への収斂を示す。2022年の JPNIC 事故は、ROA オブジェクトの無効化により影響経路がNotFoundと観測された事故であり、「全経路が Invalid になった」事故でも、利用者障害数が測られた事故でもない。

空になったディスクから見えるもの

2022年1月26日、経路表そのものではなく、経路の正当性を確かめる材料を置く側で時計が止まり始めた。JPNIC の RPKI リポジトリでディスク容量が尽き、証明書失効リスト（CRL）とマニフェスト（manifest）の新しい版が公開されなくなったのである。2月2日の復旧までに、JPNIC が発行した ROA のほぼすべては、リポジトリ上のオブジェクトとして有効性を失った。JPNIC の事故告知は、影響を受けた BGP 経路がNotFoundと観測されたと記す。

ここでは言葉を一段ずつ確かめる必要がある。「ROA がオブジェクトとして無効」は、「その ROA に関係するすべての BGP 経路が検証状態Invalidになった」と同じではない。検証に使える ROA 由来の情報、すなわち VRP が得られなければ、経路は照合先を失ってNotFoundになり得る。さらにNotFoundは、ルータがその経路を捨てたという意味でもない。採用するか、優先度を下げるか、印を付けるか、そのまま受けるかは、各ネットワークのローカルポリシーに残る。

事故告知からは、影響を受けた経路数、接続していたリライングパーティ（relying party、RP）の数、トラフィック量、到達不能になった利用者数を数えられない。利用者からの連絡が発見の契機になったことと、利用者障害の母数が測定されたことも別である。したがって、この事故は「RPKI がインターネットを落とした」という見出しの根拠にはならない。一方で、検証材料の供給が一つの運用依存であり、その依存の故障が広い範囲へ静かに波及し得ることは示した。

この出来事の九年前、日本のネットワーク運用者が集まる JANOG の会場では、同じ構造の不安が言葉になっていた。ただし、2013年の記録を2022年の事故の予言として読むのは正確ではない。前者は期限付きの演習と議論、後者は JPNIC の実リポジトリで起きた障害であり、JANOG が事故を起こしたわけでも、後年の対策を命じたわけでもない。共通するのは因果の鎖ではなく、検証情報が経路判断へ届くまでの各層を、どこまで故障に耐えられる系として設計できるかという問いである。

七月末に終わるワーキンググループ

JANOG のワーキンググループ記録には、活動期間が2013年1月22日から7月31日までと明記されている。この日付は些細な事務情報ではない。RPKI Routing WG は永続的な権限機関ではなく、限定された期間に運用者が試行し、知見を持ち寄るための場だった。その後も資料や議論の記録は残ったが、WG 自体が日本の番号資源を割り当てたり、認証局として証明書を発行し続けたり、各社のルータを統制したりしたのではない。

JANOG が担ったのは招集と公開技術交流である。JPNIC は日本のインターネットレジストリとして、実験環境や後の RPKI 試行サービス、リポジトリ、指針の側に立った。APNIC などの RIR は、それぞれのサービス地域で資源認証とリポジトリの役割を持つ。検証器やキャッシュのソフトウェアは、公開された認証データを取得して VRP を生成する。何をルータへ送り、受け取った検証状態を経路選択へどう反映するかは、最終的には各運用者の設計である。

この役割分担を曖昧にすると、コミュニティ会合での発言が全国ルールに化ける。あるいは、レジストリが ROA を扱うことが、個々のネットワークで経路を拒否する権限を持つことに化ける。公開記録からは、期限付き WG に独立した法人格、契約権限、財務支配があったとも確認できない。JANOG の価値を大きく見せるために、JANOG が持っていなかった権限まで付け足す必要はない。むしろ、強制権限を持たない運用者コミュニティが、まだ粗い実装を実際に動かし、失敗の言葉を公開の場へ持ち出した点に意味がある。

当時の RPKI は、経路情報に「正しさ」の印章を直接押す魔法ではなかった。IP アドレス資源の保有関係を証明する証明書階層があり、正当な資源保持者が「このプレフィックスはこのオリジン AS から広告されてよい」と ROA で表明する。それを検証する側がリポジトリを巡回し、有効な情報から VRP を作り、RPKI-to-Router、通称 RTR でルータへ渡す。ルータは BGP 広告と照合し、Valid、Invalid、NotFoundの状態を得る。だが、この状態は命令ではない。経路をどう扱うかという判断の一材料である。

手を動かしたこと、まだ動かしていないこと

WG は説明会だけでは終わらなかった。改訂版活動報告とJPNIC Newsletter No.55によれば、参加者は二度のハッカソンに取り組み、その後にハンズオンとチュートリアルを重ねた。証明書や ROA を操作し、検証のためのキャッシュを組み、RTR を通して BGP ルータ側でオリジン検証の結果を見るという、端から端までの流れに触れた。

最初のハッカソンでは、環境やシステムの不具合が記録された。すべてが滑らかに動いた成功物語ではない。参加した開発者による修正を経て、二度目にはキャッシュ構築などを完了できる範囲が広がったと、WG 側と JPNIC 側の資料は報告している。ハンズオンでは、扱いやすい事前構築済みの仮想環境も使われ、証明書・ROA 発行の GUI 操作や、ルータ側での検証結果の観察へ進んだ。

ただし、これらは同じ関係者による制度内記録である。生のキャッシュログ、ルータ設定、利用したすべてのソフトウェア版、障害注入手順、完了した参加者の正確な人数、所要時間の全測定値は公開資料に伴っていない。「二度目には改善した」という報告は重要だが、失敗率を数値化できる外部監査ではない。テスト環境で画面に状態が表示されたことは、本番トラフィックを流す網でInvalidを拒否し、安全にフェイルオーバーできたことの証明でもない。

それでも、手を動かした範囲には固有の意味がある。証明書の発行だけを試すなら、経路制御までの距離は見えにくい。キャッシュを作るだけなら、その結果をルータがどう受けるかは分からない。ルータに状態が見えて初めて、検証情報が更新されないとき、再起動の順番がずれたとき、複数のキャッシュが異なる答えを持ったとき、運用者は何を信頼するのかという問いが具体性を持つ。ラボは本番の代わりにはならないが、抽象的な安全論を設定と観察の問いへ下ろす装置にはなる。

逆に、公開記録が示さないことも明確である。2013年に、日本の本番ネットワークを意図的に「全経路Invalid」へ追い込む障害試験が行われたとは確認できない。JANOG が本番フィルタを一括導入したとも、参加者全員が同じポリシーを採用したとも言えない。演習で起きた実装不具合と、会場で仮定された大規模異常を一続きの「実証済み事故」にしてしまえば、せっかくの記録から最も大事な境界が消える。

「全部 Invalid ならどうする」という問い

2013年7月4日のJANOG32 セッション記録は、運用者が恐れたものを珍しいほど率直に残している。複数のキャッシュをどう持つか。RTR の接続が切れたらどうなるか。ルータを再起動したとき、経路と検証情報の収束順がずれないか。壊れたキャッシュデータが届き、すべてがInvalidに見える可能性はないか。参加者からは、異常な割合を検知したら更新を止める考えも提示された。

ここで「提示された」と「採用された」を分けなければならない。公開された議論記録は、割合に基づいて停止する発想が会場にあったことを示す。しかし、何パーセントなら止めるのかという数値は確認できない。WG がその閾値を正式な規則として採用した記録も、ベンダー機能として実装された記録も、日本の本番網で共通運用された記録も見つかっていない。数字を補ってしまえば、未解決だった設計問題を架空の制度へ変えてしまう。

吉田友哉の当時の資料は、障害の場所をさらに細かく分けた。外部キャッシュへの依存、RTR 断、ルータ再起動時の収束、壊れたキャッシュ情報、そしてローカル経路ポリシーである。資料が強調した「Validな経路でも受け取ってよいかは別問題」という指摘は、オリジン検証の限界をよく表す。Validが確かめるのは、手元の VRP に対して、広告元 AS、プレフィックス、最大長の関係が整合するかである。AS パス全体が正当か、経路リークでないか、顧客・ピア関係に沿うかまでは保証しない。

同じように、Invalidも「攻撃」と同義ではない。ROA の最大長設定、オリジン AS の移行、集約・細分化、運用手順のずれによって、正当な経路がInvalidになることはあり得る。だから運用者には、観測し、原因を分類し、連絡し、必要なら例外を置き、元へ戻せる手順が要る。RPKI が判断材料を強くするほど、その材料と最終判断の間にあるローカルポリシーの責任は、むしろ見えやすくなる。

フェイルセーフを発明したのは誰か

JANOG32 の議論を、複数キャッシュやデータ保持という仕組みの発祥として語ることはできない。IETF のRFC 6810は2013年1月、つまり7月の会合より前に公開されていた。同 RFC は、ルータが一つ以上のキャッシュへ接続できることを規定し、接続が失われた場合のデータ保持や、代替キャッシュへの接続、リセットと更新の振る舞いを記述していた。

先に標準があったという事実は、JANOG の演習を無価値にしない。標準文書は、正しい実装と運用の前提を文章で与える。一方、会場で実装を組み合わせれば、どの設定が必要で、どのエラーが分かりにくく、再起動や切断のとき何を監視すべきかが露出する。JANOG の功績を慎重に言うなら、連続性の仕組みを発明したことではなく、標準に書かれた仕組みが現場の複数製品と運用判断へ渡る際の疑問を、公開の記録にしたことである。

標準の存在は、安全が自動的に保証されたという意味でもない。ルータが複数キャッシュへつながっていても、二つのキャッシュが同じ壊れたリポジトリを読み、同じソフトウェア欠陥を持ち、同じ拠点や電源に依存すれば、見かけの冗長性は相関故障を残す。保持したデータも、いつまでも正しいとは限らない。古い情報を保持することで急な空集合を避けられても、正当な大規模変更を取り込めない時間が延びれば別の危険になる。

また、複数キャッシュから異なるデータが来たとき、単純な多数決が真実を決めるわけではない。差分は、取得時刻、リポジトリの公開順、検証実装の厳格さ、失効情報の扱い、局所例外の有無から生じ得る。必要なのは「二台ある」という在庫数ではなく、故障領域、実装、取得先、更新時刻を含む独立性と、その差を人間が理解できる観測面である。

翌2014年1月のRFC 7115は、検証状態をどう経路制御へ適用するかはローカルポリシーの問題だと明記した。変更前に影響を予測し、測り、監視し、段階的に扱いを強める。NotFoundを直ちに排除せず、Invalidについても一足飛びに全相手へ同じ拒否を広げない。これは消極策ではない。セキュリティ制御を、観測可能で可逆な運用変更として導入するための手順である。ただし、ベスト・カレント・プラクティスにそう書かれていることは、どの運用者もその通りに実装したという観測証拠ではない。

レジストリからルータまでの責任の継ぎ目

2015年3月3日、JPNIC は実際の割り振り・割り当て情報に結び付いた RPKI 試行環境を始めた。JANOG35.5 の説明は、ROA を作るだけでオリジン検証が完成するのではなく、別途 BGP ルータの設定などが必要だと明記する。ここに、レジストリ側サービスとネットワーク運用者側の境界がよく現れている。

JPNIC は資源情報と認証・リポジトリの面を提供できる。だが、どのキャッシュをどこに置くか、ルータを何台つなぐか、Invalidへどのローカルプリファレンスを与えるか、いつ拒否へ進むか、障害時に例外を入れるかは、各運用者の領域である。JANOG はその選択を議論する場を設けられるが、各社の設定を代行する全国オペレータではない。

この継ぎ目は、責任逃れのための線引きではない。むしろ、障害対応の担当を決めるために必要だ。証明書やマニフェストの公開が止まったなら、リポジトリ運用者が直す。検証器が異常な VRP を生成するなら、実装と入力の双方を調べる。RTR セッションが落ちたなら、キャッシュとルータの接続、保持時間、代替経路を調べる。Invalidが急増したなら、経路広告と ROA 設定、ポリシー変更のどこに原因があるかを見る。利用者が到達不能になったなら、RPKI のラベルだけでなく、実際の BGP 選択と転送経路を追う。

どこか一つを「RPKI の責任」と呼ぶと、復旧の糸口はかえって遠のく。リポジトリオブジェクトの異常、VRP 集合の欠落、経路状態、ルータの拒否、エンドユーザー障害は、連鎖する可能性はあっても同じ出来事ではない。安全な失敗の設計は、この連鎖を途中で止められ、どこで止まったかを観測できる状態を目指す。

後年の IIJ が測った導入の現実

2013年の WG から後年の導入へ、一本の因果線を引く資料はない。IIJ、NTT、JPNIC、JPIX、IETF、RIR、ベンダー、研究者は、それぞれ独立した経験と動機を持ち得る。後年の記録は、JANOG32 の「成果」ではなく、同じ失敗類型に運用がどう答えたかを見る対照材料として読むべきである。

IIJ の JANOG47 報告は、その意味で具体的だ。IIJ は2020年3月から12月にかけ、検証と影響確認を重ねながら、ピアや上流のグループごとに段階的に拒否へ進んだと報告した。各ルータは二台のキャッシュへ接続され、キャッシュは国内の異なる拠点に置かれ、異なる実装が選ばれたという。初期に観測されたInvalid経路は約3000、フルテーブルのおよそ0.3％だった。

導入対象は10ノード、BGP ピアは2000未満と報告された。ここで分母を曖昧にしてはならない。約3000は利用者数でも障害数でもなく、特定時点・特定条件でのInvalid経路の概数である。10ノードと2000未満のピアは IIJ が公開した展開範囲であり、日本全体のネットワーク数ではない。外部監査用の全設定や、経路ごとの判定記録が公開されたわけでもない。

それでも設計の方向は読める。二台という数だけでなく、拠点と実装を分ける。観測から始め、相手の種類ごとに段階を踏む。誤設定と疑われる経路をいきなり「攻撃」と断定せず、影響を確かめてから拒否範囲を広げる。これは、オリジン検証の価値を弱めずに、誤ったデータや実装故障の爆発半径を抑えるやり方である。

同時に、IIJ の資料は運用者自身による報告である。異なる二実装が、共有リポジトリの故障から独立しているとは限らない。別拠点でも上流接続や管理系が共通なら、相関故障は残る。公表された成功例だけから、試験で見つかったすべての問題や顧客影響を逆算することもできない。良い実例は、普遍的な保証ではなく、他者が問い直せる具体的な設計例として使うべきだ。

八十万経路の再起動試験が否定した恐れ、残した恐れ

2022年の JANOG50 に関連するJPNIC の実験報告は、80万に近い経路を入れた模擬環境を使った。そこでのルータ再起動は、通常の BGP 再起動と比べて大きく異ならない挙動だったと報告されている。2013年に語られた「経路が先に来て、検証情報が追い付かず、長い混乱になるのではないか」という恐れに対する、重要な限定的反証である。

だが、約80万という経路数は、あらゆるルータ、検証器、ソフトウェア版、CPU・メモリ条件、ポリシー規模を代表しない。公開報告には生の時系列ログや、すべての収束時間が添えられていない。模擬環境で通常の BGP 再起動と大差がなかったことは、試した構成で一つの懸念が小さかったことを示すのであって、再起動問題が世界中で解決済みだという証明ではない。

この試験の価値は、「怖いから導入しない」と「標準に書いてあるから安全だ」の中間に測定を置いたことにある。大きな経路表を入れて再起動する。通常時との差を見る。複数キャッシュ、監視、段階的なInvalid処理、ローカルキャッシュの必要を議論する。安全性は形容詞ではなく、構成と条件を付けた試験結果として語るほど強くなる。

2023年7月のJANOG52 プログラムでも、複数種類の ROA キャッシュと複数のルータベンダーを比べ、Invalidをどう扱うかが引き続き課題として掲げられた。これは完全な結果報告ではなく、会合ページの要約にすぎない。それでも、2013年に一度答えが出て終わった問題ではなく、実装と運用条件の変化に応じて再試験される問題だったことは分かる。

指針が求めるのは「二台」より広い可観測性

2024年11月13日に発効し、2026年3月27日まで更新されたJPNIC の運用ガイドラインは、後年の実務がどこへ収斂したかを示す。キャッシュのプロセスや資源使用量を監視し、リポジトリ取得が失敗した後に回復したかを確認する。複数キャッシュのデータを一日一回比較する。影響を見ながら段階的に導入し、ロールバック、再起動、再接続を試す。必要に応じて SLURM などによるローカル例外を扱う。

この文書は JPNIC の推奨であって、日本の全ネットワークが同じ通りに実装したという調査結果ではない。2013年の WG がこの指針を直接生んだと示す資料もない。2022年から2023年の調査、コミュニティでの検討、海外を含む障害や実装成熟など、複数の経路が指針へ影響した可能性がある。

それでも、推奨項目を一つの安全モデルとして読むことはできる。入力データの有無だけでなく、更新の鮮度と回復を監視する。複数系統の答えを比べ、ポリシー変更は小さな範囲から始める。誤判定時に戻せる手順とローカル例外を準備し、平常時に再起動・切断・再接続を試す。障害が起きてから初めて手順を読む構成では、二台という数だけを満たしても可観測性は得られない。

特に SLURM のようなローカル例外は、RPKI を無視する裏口と単純化できない。正当な経路がデータ問題でInvalidになり、資源保持者やリポジトリ側の修正に時間がかかるとき、限定的な救済を行う道具になり得る。ただし例外は、期限、根拠、承認、棚卸しがなければ恒久的な盲点にもなる。フェイルセーフとは常に開け放すことではなく、通常の検証を保ちながら、狭く、記録可能で、取り消せる逃げ道を持つことである。

二つの実事故が示した相関故障

JPNIC の2022年事故をもう一度、層を追って読む。ディスク枯渇はリポジトリの公開処理を止めた。CRL とマニフェストが古くなり、JPNIC 発行 ROA のほぼすべてがオブジェクトとして無効になった。検証器は、それらから有効な VRP を作れなくなる。影響を受けた BGP 経路はNotFoundとして観測された。そこから先、各ルータが経路を受け入れたか、トラフィックにどれほど影響したかは、告知に母数がないため断定できない。

重要なのは、キャッシュを二台にしていても、二台とも同じ JPNIC リポジトリから同じ期限切れの公開物を取得すれば、入力側の共通故障を避けられないことだ。異なる実装は、同じ異常データを違う仕方で扱うかもしれない。それは多様性の利点にも、結果不一致の原因にもなる。したがって、冗長性の設計単位はキャッシュ台数だけでなく、信頼アンカー、リポジトリ公開、取得経路、検証実装、運用監視、ルータポリシーにまたがる。

日本の外で起きたRIPE NCC の2021年1月7日の不整合は、別の角度から同じ故障類型を示した。親子証明書の公開に一貫性がなくなり、マニフェストを厳格に扱う一部の古い RP 実装は、RIPE の資源証明書をすべて拒否した。RIPE NCC は影響を受けた RP インスタンスを327と報告し、原子的な公開へ改善するとした。

327という数は、327のネットワークでも、327本の経路でも、327人の利用者でもない。RP のインスタンス数である。事後報告は障害につながった可能性に触れるが、到達不能になった利用者数を測ってはいない。また、RIPE NCC の事故は日本の外であり、JANOG32 が原因でもない。ここから言えるのは、リポジトリ公開の一時的不整合と実装差が、広い証明書集合の拒否へつながり得るということまでである。

二件を並べると、同じ「リポジトリ障害」でも結果が一様でないことが分かる。JPNIC では、ROA オブジェクトが使えず、影響経路がNotFoundと観測された。RIPE NCC では、厳格な実装が広い証明書集合を拒否した。入力データ、公開順、マニフェストの扱い、保持動作、ローカルポリシーによって、故障がどの状態へ落ちるかが変わる。だから「RPKI が壊れたら何になるか」を単一の矢印で描くことはできない。

技術は成熟した――それでも故障設計は要る

初期の不具合と事故だけを積み上げれば、RPKI 導入を先延ばしする議論になりかねない。しかし、それは証拠の半分しか見ていない。2019年の査読付き研究“RPKI Is Coming of Age”は、八年にわたる ROA と BGP のデータを分析し、初期に多かった誤設定が後には非常にまれになったと報告した。世界規模のデータであり、日本固有の採用や JANOG の影響を示すものではないが、「初期に不具合があったから恒久的に使えない」という推論への強い反証である。

オリジン検証の経路セキュリティ上の効用も具体的だ。資源保持者が許可したオリジン AS とプレフィックス長を公開し、観測された広告と機械的に照合できれば、誤ったオリジンからの広告を識別しやすくなる。監視だけでも、設定ミスや不審な変更を早く見つけ、当事者へ連絡する共通言語になる。拒否まで進めば、条件を満たす誤経路が選ばれる可能性を減らせる。AS パス全体を守れないから無意味なのではなく、守れる範囲を明確にした一つの防御層である。

APNIC がまとめた NTT Communications の事例は、継続監視とソフトウェア・手順の改善によって、Invalid広告を86.84％減らしたと報告する。これは APNIC によるケーススタディで、生データを独立監査した研究ではない。減少率は JANOG32 の効果でも、日本全体の率でもない。それでも、Invalidをただ捨てるのでなく、原因を把握し、誤設定を直し、運用プロセスを改善することでセキュリティ信号の品質を高められることを示す。

成熟を認めることと、障害を軽視することは両立しない。誤設定が減れば、Invalidという信号は以前より信頼しやすくなる。信号が信頼され、多くの運用者が拒否に使うほど、誤った大規模データ更新の影響は大きくなる。普及は障害設計を不要にするのではなく、障害設計の重要度を上げる。防御が有効であるほど、その入力と停止条件を吟味する必要も増す。

中央キャッシュを退かせ、代替を増やす

JPNIC は2015年に始めた公開 RPKI キャッシュの試行を、2025年12月に終了すると告知した。理由として、集中点になる懸念、運用指針の整備、他の選択肢、利用の少なさが挙げられた。これは JPNIC 自身の説明であり、利用者数、稼働率、障害率の独立した前後比較は示されていない。

一方、JPIX の JANOG55 資料は、東京と大阪の AWS リージョンに、IPv4・IPv6 で利用できる TCP 323番の公開キャッシュ接続先を示した。具体的な接続面が公開されたことは、運用者が選べる代替の存在を確かめる材料になる。ただし二リージョンという地理表現だけでは、管理系、実装、上流、クラウド障害、リポジトリ入力まで独立しているかは分からない。顧客数や実測稼働率も資料からは監査できない。

中央サービスの終了と代替サービスの登場を「分散化が完成した」と読むのは早い。公共キャッシュには、小規模運用者が自前の検証基盤を持たずに始めやすい利点がある。他方で、多数が同じサービスを唯一の入力にすれば集中点になる。安全な構成は、公共か自前かの二者択一ではなく、自組織が許容できる故障時間、運用能力、接続多様性、監視責任を踏まえて、依存を可視化し複数の回復路を持つことだ。

JPNIC の試行終了が JANOG32 から一直線に決まったとする資料はない。JPIX のサービスも、2013年の WG が設計したものではない。両者は、外部キャッシュへの依存をどう扱うかという古い問いが、サービスのライフサイクルと市場の選択肢という別の形で現れた例である。

更新を止める「ブレーカー」は答えになったか

2026年7月16日のJANOG58 プログラムには、不完全な VRP 集合が誤ったInvalid判定を生む危険に対し、異常を検知したら VRP 配布を一時停止する「VRP breaker」の提案が掲載された。2013年の会場で出た、異常割合に応じて更新を止める発想と響き合う。しかし、2026年7月20日の参照時点で公開デッキ、詳細手法、導入結果、独立検証はなく、特許出願中の提案とプログラム要旨の段階だった。

したがって、2013年に JANOG が閾値を定め、それが2026年に実装されたという系譜は作れない。2013年の提案に採用済みの数値はなく、2026年の提案にも公開された成果はない。確認できるのは、異常な VRP 更新をそのままルータへ広げない停止点をどこに置くかが、十三年を隔てても設計課題として現れたということだけである。

ブレーカーには難しい反作用もある。閾値が低すぎれば、正当な大規模 ROA 更新やリポジトリ再編を異常と誤認して、新しい正しい VRP を凍結するかもしれない。高すぎれば、世界全体では小さくても特定地域や大手ネットワークには重大な変化を見逃すかもしれない。攻撃者が閾値を意図的に発火させ、古い VRP の保持を利用する可能性も検討対象になる。公開資料は、2013年案についてこれらの偽陽性・偽陰性を評価していない。

実用的な停止条件を考えるなら、単一の割合以上の文脈が要るだろう。変化した VRP の総数、信頼アンカーやリポジトリごとの偏り、増加か減少か、同じプレフィックス群への集中、複数検証器間の差、更新の署名と時刻、既知の保守情報、過去の変動幅を組み合わせる必要がある。そして停止は、永続的な凍結ではなく、担当者への通知、別経路での検証、期限付き保持、段階的な解除と結び付かなければならない。これは公開資料にある採用済みの製品仕様ではなく、未採用の提案から導ける設計上の問いである。

フェイルセーフは「何もしない」ことではない

安全な失敗を、障害時にはすべての経路を無条件で受けることだと理解すれば、RPKI の防御価値は消える。逆に、Invalidなら事情を問わず即時にすべて拒否することだと理解すれば、データ供給や実装の故障を到達不能へ変換しかねない。必要なのは、正常時には検証を実効的に使い、異常時には故障の範囲に応じて影響を限定する状態遷移である。

出発点は、状態と行動を分けることである。Valid、Invalid、NotFoundは観測結果であり、受容、優先度変更、タグ付け、拒否はポリシー行動だ。この二つを同じログ項目に潰さなければ、データの異常と運用判断を後から検証できる。監視も最終結果だけを見てはいけない。リポジトリ取得の成否、CRL とマニフェストの時刻、検証器が生成した VRP 数、前回との差、キャッシュ間差分、RTR セッション、ルータが受け取ったシリアル、各状態の経路数を追う。急なInvalid増加に加え、NotFoundの増加や VRP 総数の減少も異常の兆候になる。

冗長性は台数ではなく故障領域で評価する。二台のキャッシュが別プロセスであるだけでは足りず、実装、拠点、管理プレーン、上流接続、取得タイミングをどこまで分けるかを決める必要がある。異なる実装が違う結果を出した場合には、差を比較し、どちらを採るか判断できる運用面も要る。変更は小さく、戻せる形で進める。監視のみから始め、プリファレンス調整、限定した相手やアドレスファミリーでの拒否へ移り、各段階でInvalidの原因、経路数、顧客影響、問い合わせを測る。ロールバック条件は導入前に決め、例外には期限と所有者を付ける。

故障試験は事故の最中ではなく平時に行う。キャッシュを一台ずつ止め、RTR を切り、ルータを再起動し、保持時間を超えた状態を作り、リポジトリ取得が戻った後の回復を測る。全系統へ同じ壊れた入力を与える破壊的試験は隔離環境で行い、本番では観測と段階制御を優先する。JANOG50 の約80万経路試験のように、恐れを測定可能な条件へ変えることが重要になる。

最後に測るべきなのは、拒否した本数だけではない。誤設定が修正された割合、連絡から修復までの時間、例外の残存期間、誤検知、実際に防いだ疑わしい広告を追う。NTT の86.84％という報告は、手順改善を数値にする一例である。数字の出典と母数を保ったまま、他の運用者が再検証できる指標へ広げる余地がある。

これらは、単一のコミュニティ規則にまとめなければ実行できないものではない。RFC 7115が示すように、経路状態の扱いはローカルポリシーであり、ネットワークごとに顧客、ピア、上流、重要サービス、規制要件が違う。共通にできるのは、状態の意味、観測項目、障害記録の形式、試験方法、連絡経路である。判断の違いを許しながら、事故時に比較できる公開言語を作ることが、NOG の得意な役割である。

異常後の時間軸をどう設計するか

ここからの時間区分は、公開資料にある採用済みの手順でも、JANOG の規則でもない。前節までの証拠から導く運用上の試案であり、「十五分」や「十五時間」は数値基準ではなく、初動と長期化を分けて考えるための例である。この境界を明記しなければ、2013年に存在しなかった正式な停止規則を別の形で作り出すことになる。

たとえば最初の十五分には、変更を加える前の状態を保存する。キャッシュごとの VRP 総数と差分、リポジトリ取得の最終成功時刻、RTR セッションの状態、ルータごとのValid、Invalid、NotFoundの増減を記録する。同時に、直前の自組織の設定変更、予定された資源移転、大規模な ROA 更新がなかったかを確認する。証拠を残さずに再起動を重ねれば、一時的な公開不整合だったのか、検証器固有の欠陥だったのかを後から区別できない。

次の一時間には、異常の境界を狭める。同じ信頼アンカーの下だけで起きているのか、ある実装だけか、ある取得地点だけか、IPv4 と IPv6 の双方か、Invalidの増加なのかNotFoundの増加なのかを比べる。ルータに届いた結果と検証器内の結果が一致しなければ、RTR 転送やシリアルの同期を疑う。複数キャッシュが同じ結果なら入力の共通故障の可能性は高まるが、それだけでリポジトリを原因と断定はできない。共通の設定変更や時刻ずれもあり得るからだ。

経路への措置は、原因究明と並行して爆発半径を制御する。新しい VRP 集合が明らかに不完全だと疑われる場合でも、全ルータで一斉に古い集合へ固定する前に、保持データの時刻と有効期間を確かめる。特定の正当な経路だけが巻き込まれているなら、根拠と期限を付けた局所例外の方が、検証全体を無効化するより狭い。広い異常なら、顧客、ピア、上流、内部経路でポリシー変更を分け、重要な到達性を確認しながら段階を戻す。どの操作も、実施者、時刻、対象、解除条件を記録する。

十五時間を越えて長期化すれば、暫定措置が新しい平常運用へ固まる危険が出る。保持した VRP は古くなり、緊急例外は所有者を失い、監視の警告は常態化する。そこで、交代要員を含む担当、次の再評価時刻、資源保持者やリポジトリ運用者への連絡状況、利用者影響の計測方法を明文化する必要がある。復旧の判定も「プロセスが起動した」だけでは足りない。公開物の時刻が進み、複数地点から同じ有効な集合を取得でき、キャッシュ間差分が説明でき、RTR 経由でルータの状態分布が戻り、例外を撤去しても到達性が保たれるところまで確かめたい。

事故後の検証では、分母を必ず残す。影響した RP インスタンス数を運用者数と呼ばず、Invalid経路数を障害利用者数と呼ばず、問い合わせ件数を到達不能の全件数と呼ばない。経路数なら、観測した全経路、アドレスファミリー、時刻、コレクタ、重複の扱いを示す。利用者影響なら、監視地点、失敗した宛先、継続時間、代替経路の有無を示す。2021年の327インスタンスや、IIJ の約3000経路と0.3％が意味を持つのは、それぞれ何を数え、何を数えていないかが区別されているからである。

この運用台帳は、単なる社内手順ではなく、コミュニティが比較可能な知識を作る基礎になる。機密のルータ設定や顧客情報を公開しなくても、異常が発生した層、検出方法、状態遷移、措置、復旧条件、測定できなかった影響は共有できる。2013年の記録に生ログがなく、後年の多くの報告も自己申告にとどまるという限界を、次の事故で繰り返さないための現実的な改善である。公開できない詳細があることと、再現に必要な条件を一切残さないことは同じではない。

異常を判定するには、正常時の幅も知らなければならない。VRP 総数やInvalid率は日々一定ではなく、資源移転、経路集約、保守、ROA 更新で動く。平常時の変動を信頼アンカー別、アドレスファミリー別、時間帯別に蓄積しなければ、「いつもと違う」という警報は作れない。しかも全体の比率だけでは、少数の重要プレフィックスに集中した異常を隠す。総量の変化と、個別の重要度を別々に見る必要がある。

本番ポリシーを変更する前には、同じ BGP 入力を使って新旧の VRP 集合を並行評価する方法も考えられる。新しい集合でのみInvalidになる経路、逆にNotFoundへ変わる経路を抽出し、資源保持者の公開情報や運用連絡と突き合わせる。この比較系は実際の経路選択へ影響させず、判断材料だけを作る。十分に説明できない差が大きければ展開を止め、説明できた差だけなら範囲を限定して進める。ここでも「止める」の対象はインターネット経路そのものではなく、未確認の検証データや新しいポリシーの拡散である。

そして復旧には、正常値へ戻ったという一点だけでなく、故障原因が再発しにくくなる変更が要る。ディスク枯渇なら容量監視と公開処理の失敗通知、親子オブジェクトの不整合なら公開の原子性、実装差なら互換性試験、運用判断の遅れなら連絡先と権限委譲を直す。原因ごとの対策を区別しなければ、キャッシュを追加するだけの万能薬へ逃げてしまう。2013年の演習が実装不具合を修正して次の回へ進んだという小さな循環は、この意味で本番運用にも通じる。失敗を見つけることより、修正後に同じ条件をもう一度試し、結果を記録することが成熟を示す。

公開の場が持てる権威、持てない権威

JANOG は資源配分機関ではない。RIR でも、認証局でも、規制当局でもない。各社の本番ルータへ設定を押し込む全国オペレータでもない。そのため、JANOG32 の議論には法的な強制力も、全ネットワークを同時に止める制御面もなかった。

しかし、運用者コミュニティには別の種類の権威がある。実装が失敗したことを資料に残し、修正後にもう一度試す。会場で「すべてがInvalidに見えたらどうする」と問い、答えが未採用であることも含めて記録する。後年には、別の運用者が二台・二拠点・二実装という構成や、10ノード、2000未満のピア、約3000のInvalid経路を公表する。約80万経路の再起動試験や、二地域のキャッシュ接続面を示す。こうした記録は命令ではないが、主張を検証可能にする。

NOG が最も危うくなるのは、その公開記録を歴史的な発明や全国的な実施権限へ膨らませたときである。複数キャッシュは RFC 6810に先行して書かれていた。ローカルポリシーは各運用者のものだった。2015年の試行サービスは JPNIC が提供し、ルータ設定は別途必要だった。2022年のリポジトリ事故は JPNIC の運用面で起きた。後年の IIJ や NTT の措置を JANOG32 が原因だとする証拠はない。

反対に、権限がないから会合は無力だという見方も狭い。強制権限がない場だからこそ、異なる運用者、レジストリ、実装者、研究者が、失敗を制度防衛に変えずに比較できる。採用されなかった案を採用済みと書かず、自己報告を外部監査と呼ばず、測っていない利用者影響を想像で埋めない。その節度が、公開技術記録の信頼を作る。

結論――守るための信号を、止められる形で信頼する

2013年の期限付き WG が残した核心は、特定の装置や閾値ではない。二度のハッカソンとハンズオンで、証明書・ROA、キャッシュ、RTR、ルータ観察を一つの流れとして触ったこと。初回の不具合と修正後の改善を記録したこと。JANOG32 で、切断、再起動、壊れたデータ、「全 Invalid」、更新停止という、実運用へ進めば避けて通れない質問を公開したことである。

同時に、その記録には限界がある。全 Invalid の本番事故を起こしたわけではなく、停止割合を採用したわけでもない。複数キャッシュと保持動作は RFC 6810が先に規定していた。JANOG は割り当てや認証の主体ではなく、JPNIC のサービスや各運用者のポリシーを支配しなかった。後年の実装と指針は同じ問題へ収斂したが、2013年からの直接の系譜は証明されていない。

その後の記録は、問いに部分的な答えを与える。IIJ は拠点と実装を分けた二キャッシュ、段階導入、具体的な経路・ノード・ピアの概数を示した。JANOG50 の模擬試験は、約80万経路の条件で再起動への恐れを限定した。JPNIC の指針は監視、比較、ロールバック、再接続、ローカル例外を並べた。NTT の事例と長期研究は、誤設定を減らし、オリジン検証を実際の防御へ育てられることを示した。

事故は、残る空白を示す。JPNIC のディスク枯渇では、ほぼすべての JPNIC 発行 ROA がオブジェクトとして無効になり、影響経路はNotFoundになった。RIPE NCC の公開不整合では、327の RP インスタンスが影響を受けた。どちらも、測定されていない利用者障害を断定する材料ではない。しかし、入力側の共通故障と実装差が、複数キャッシュの数だけでは消えないことは教える。

RPKI を安全に使うとは、検証を弱めることではない。オリジンの誤りを見分ける信号を強くしながら、その信号が急変した理由を観測でき、影響を段階化でき、必要なときに限定的かつ可逆的に止められるようにすることである。信頼とは、絶対に壊れないと仮定することではない。どこで壊れ、どこまで届き、誰が直し、何を保持し、いつ通常運用へ戻すかを、事前に決めておくことだ。

2013年の会場で数値のないまま残った「止める」案は、2026年にも提案として姿を変えて現れた。答えが十三年間見つからなかったというより、インターネットの規模、実装、普及度が変わるたびに、停止条件を測り直す必要があるのだろう。期限付き WG が持てたのは命令権ではなく、未完成の問いを公にする力だった。その問いへ答える責任は、リポジトリ運用者、実装者、ネットワーク運用者、そして結果を測るコミュニティの間に、今も分散している。

メタデータ

SEO タイトル: 経路を守る検証が経路を消すとき――JANOG と RPKI の安全な失敗
SEO 説明: 2013年の JANOG RPKI Routing WG が実際に試した範囲と、議論に残った障害シナリオを分け、RFC、後年の運用、JPNIC と RIPE NCC の事故からフェイルセーフなオリジン検証を考える。
OG タイトル: RPKI の検証系が壊れても、経路を失わないために
OG 説明: JANOG の期限付き実験、複数キャッシュ、再起動、NotFound 事故、段階導入をたどる日本語調査長編。
Twitter タイトル: JANOG の RPKI 実験が残した「安全な失敗」の宿題
Twitter 説明: オリジン検証の防御力と、リポジトリ・キャッシュ・ルータ障害の爆発半径をどう両立させるか。
フォーカスキーワード: RPKI フェイルセーフ
スラッグ: janog-rpki-fail-safe
画像代替テキスト: 複数の RPKI リポジトリと異なる実装の検証キャッシュから、RTR で二台のルータへ検証情報が流れ、途中に監視点と異常配布の一時停止を検討する地点が描かれた編集用概念図
画像キャプション: RPKI の安全性は一台のキャッシュでは完結しない。リポジトリ、検証、RTR、ルータポリシーを分けて監視し、異常の波及を限定する必要がある。
アクセシビリティ説明: 左側のリポジトリ群から中央の異なる二種類の検証キャッシュへ線が伸び、そこから二台のルータへ接続する。各段階に状態監視の印があり、異常な VRP 更新の配布を一時停止する検討点が強調されている。色だけに依存せず、正常、警告、停止を文字と線種でも区別する。
画像プロヴェナンス: 本稿で参照した公開技術資料を基に BTW 編集部が作成する非写実的な概念図。実在の障害画面、特定ベンダー製品、人物、未公開ネットワーク構成を再現せず、JANOG または JPNIC の公式図版・ロゴを複製しない。