要約

  • RRDPに失敗した検証器は、以前のキャッシュを使い続けるか、より大きなスナップショットを取得するか、rsyncへ切り替えるかを選ぶ。世界共通の復旧タイマーが決めるわけではない。
  • deltaの保持期間、manifestの鮮度、検証器の閾値は、復旧時間と負荷とリプレイ耐性を異なる事業者へ配分する。
  • 必要なのは単純な死活監視ではなく、リポジトリ単位の復旧レシートと、独立した検証済みペイロードの比較である。

午前9時、RPKI検証器が次の小さなdeltaを取りに行く。通知ファイルには参照があるのに、対象ファイルは取得できない。ある検証器は直前に成功したキャッシュを使う。別の検証器は完全なsnapshotへ進む。三つ目は待ち時間を置いてrsyncを試す。同じ障害でも、三者が同じ時刻に同じ「現在」を持つとは限らない。

ここに、復旧経路がルーティングの制御点になる理由がある。RPKIは通常、署名済みオブジェクトから説明される。資源保有者が起点を承認し、依存当事者が検証し、ルーターが経路起点検証の方針を適用する。しかし運用上は、署名された意思が認証局を出て、公開サービスを通り、リポジトリから検証器へ届き、manifestや証明書、失効情報の検査を経て、初めて検証済みペイロードになる。署名が壊れていなくても、配送の障害は後段が見られる証拠を変える。

delta、snapshot、そしてフォールバック

RFC 8182のRRDPは、通知ファイル、delta、snapshotを定義する。通知にはリポジトリのsessionとserialがあり、deltaは増分変更、snapshotは完全な現行状態を運ぶ。ローカルのserialから現在まで連続したdeltaがあれば、検証器は小さな更新で追いつける。deltaが欠けるか拒否されれば、完全なsnapshotへ移る。

この二つは同じ費用ではない。deltaは小さくても、snapshotは数十MBから数百MBになり得る。2026年5月版のIETF SIDROPS公開サービス草案は、失敗の連鎖を具体的に記す。deltaが失敗すると、依存当事者は通常、より大きなsnapshotを試す。それも失敗すればrsyncへ落ち、次のRRDP実行でもsnapshotから始めやすい。過負荷の最中に、復旧動作が需要を増やすわけだ。障害対応の品目が平常時より重いのは、分散システムらしい冗談である。

この文書は作業中のワーキンググループ草案で、RFCではない。ただし、観測値の範囲は明示されている。2024年1月の一つの大規模リポジトリでは、14時間を覆う144個のdeltaを含む通知ファイルが251GB、総トラフィックが55.5TBで、通知は0.5%未満だった。deltaを長く保持すれば遅れた検証器は増分で回復しやすいが、全検証器が読む通知は長くなる。短くすれば平常時の通知は軽くなり、遅れた検証器がsnapshotへ押し出される。同草案が最低4時間の保持を推奨するのは、2024年に1〜2時間おきにしか同期しないRPが観測されたためだ。

検証器にも独自の政策がある。現在のRoutinatorマニュアルは、RRDP失敗後のrsyncフォールバックにnever、stale、newを用意する。文書上の既定はstaleで、ローカルのRRDPコピーが「現在」と見なされる間はそれを使い、リポジトリごとに無作為化した期限を超えてからrsyncを試す。最大フォールバック時間の既定値は3,600秒で、更新間隔との間で時刻を分散し、代替サービスへの集中を避ける。

同じマニュアルには、100個を超えるdeltaが必要ならsnapshot、通知のdelta一覧が500個を超えれば一覧を空とみなす、RRDP資源の取得は600秒、readは10秒、rsyncコマンドは300秒という既定値もある。これはRoutinatorの設定であり、RPKI全体の定数ではない。設定を変えれば、同じリポジトリ障害でも要求の列とキャッシュ判断が変わる。

キャッシュも証拠の一部である

RFC 9286は、fetchに失敗した場合、次の成功まで以前の成功時のキャッシュを使うべきだとする。不完全なリポジトリ状態を新しいルーティング意図と誤解しないためである。したがって、いまHTTPSが応答するかどうかだけでは、最終的にルーターへ渡る証拠の年齢は分からない。

manifestは、その継続に期限を設ける。発行者が置くはずのオブジェクトを列挙し、削除、置換、更新の抑止を見つける。差異は検出できるが、欠落を修復はできない。thisUpdateとnextUpdate、CRLと各オブジェクトの有効期間が、過去のキャッシュを使える窓を決める。

2026年の公開サービス草案は、長い有効期間が復旧時間を買う一方で、リプレイの許容時間を広げると説明する。短くすれば露出は狭まるが、再発行と配布のchurnは増える。一つの大規模リポジトリでは、manifestとCRLの再発行を24時間ごとから48時間ごとへ変え、データ量が約半分になった。多くの変更が新規ROAやASPAではなく定期再発行だったためだ。これは一例であって世界平均ではない。それでも、CAが時刻を決め、公開サービスと全RPが処理費用を負うという構造は見える。

2026年5月のRFC 9981は、manifest番号が上限に達する例外を処理する。新規則以前は、現在のmanifestが失効するまで後継を受けない実装と、以後ずっと拒否する実装があり得たと記録する。通常の連番で上限へ達するのは現実的ではなく、問題はバグや誤設定である。重要なのは頻度ではない。復旧端の意味が曖昧なら、適合実装でも利用可能な証拠が分かれ得るという直接の例だ。

容量と安全性は同じ方向へ動かない

rsyncへの切り替えは可達性を上げても、転送境界を弱くする。RRDPはHTTPS上で不変のdeltaとsnapshotを配り、キャッシュを利用できる。rsyncは接続ごとにサーバーのCPUやメモリーをより使い、チャネル自体の機密性・完全性も持たない。Routinatorの脅威モデルは、経路上の攻撃者がRRDPを妨害してrsyncへdowngradeさせ得るとする。その後は署名とmanifest検査がさらに重要になる。

NLnet Labsは2020年、15万の検証器が10分ごとに問い合わせれば毎秒約250件となり、当時毎秒約3件だったrsyncサービスへ集中し得るという将来モデルを示した。これは2026年の実測値ではない。即時一斉フォールバックを避け、時刻を分散する設計の由来である。

架空の全世界値を置かず、感度だけを計算できる。検証器1万台、通常delta 1MB、圧縮snapshot 100MBとする。全て増分なら1周期10GBだが、20%だけsnapshotへ移ると約208GBになる。8,000MBのdeltaと200,000MBのsnapshotである。再試行とrsyncのサーバー処理は別勘定だ。ピークを決めるのは台数だけでなく、復旧要求が何秒の幅へ集中するかである。

リポジトリは「稼働中」でも、復旧製品として壊れ得る。あるbackendの通知だけが先に見え、参照されたsnapshotやdeltaが別backendへまだ届いていないことがある。failoverをまたぐ古いkeepaliveが、前のsessionを返すこともある。最新SIDROPS草案はbackend間の一貫した状態を求め、RFC 8182にはserialの後退に対する一つのRP動作がないため、一部実装はsnapshotで再同期すると指摘する。死活監視には200、検証器には切れた時間軸が届く。

この資料群から世界全体の不一致率は算出できない。特定のリポジトリが経路障害を起こしたとも言えない。確認できるのは機構、設定可能な選択、費用の移転であり、運用試験を設計するには十分である。