Summary

  • RPKIのrelying partyは、分散リポジトリ、設定されたトラストアンカー、同期結果、検証規則、ローカル制御から、時点付きのローカルビューを生成する。世界共通の判定を受け取る装置ではない。
  • draft-su-sidrops-rpki-rp-requirements-00 は、検証済みキャッシュの機械可読な出力、失敗と拒否の診断、比較・再生できる履歴の保持を新たな運用要件として掲げる。
  • Daniel Kadeは、実行環境、入力と欠落、キャッシュのダイジェスト、ローカル変更、ルータへの配布、保存履歴を結ぶ「検証状態レシート」を提案する。これは編集上の提案でありIETF要件ではない。

キャッシュは世界の写しではなくローカルな生成物

RPKIの署名オブジェクトには発行者がいる。しかしルータが利用する状態は、発行された全オブジェクトをそのまま複製したものではない。RPソフトウェアはトラストアンカーを設定し、複数の公開点を発見し、RRDPやrsyncで取得し、証明書、CRL、マニフェスト、ROAなどを検証してローカルキャッシュを作る。運用者はSLURMによるフィルタや追加のアサーションを適用できる。その後、別のRPKI-to-Routerプロトコルがペイロードをルータへ渡す。

署名が正しいことは、全リポジトリに到達したことを意味しない。現行マニフェストは一つの公開点の現行在庫を示すが、全体の観測完了を示さない。キャッシュから受信したことは、ルータがその情報を使って経路を選んだことを示さない。

RFC 8210のserialも万能な状態番号ではない。同じcache sessionとprotocol versionの中で論理的な版を表すだけで、別キャッシュとは比較できず、リセット後に維持される保証もない。Session IDを失ったserialは、監査で単独利用できない。

したがって「RPKIは正常だった」という主語は大きすぎる。正確には、特定のRP実行が、特定の設定と時刻の下で、観測できた材料と失敗から、特定のローカル状態を生成した、という主張になる。

2026年草案が追加した三つの仕事

2026年6月12日付の個人Internet-Draftは、RFC 8897が担ったRP要件の集約を更新しようとしている。後継トラストアンカーキー、RRDPのsame-origin、desynchronization回復、新しいマニフェストとROA、ASPA、RSC、TAK、CRL処理、キャッシュ配布、ローカル制御まで参照対象が広がったためだ。

文書の地位は限定されている。Datatrackerではactive individual draftであり、RFC stream、担当AD、telechatはない。本文ヘッダはInformationalを意図し、承認された場合にRFC 8897を更新するとしている。進行中のSIDROPS文書への参照も暫定的だ。WG採択、IETF合意、製品実装を示す証拠ではない。

それでも第7節は重要な運用論点を明示する。第一に、検証済みキャッシュを安定した機械可読形式で出力する。第二に、リポジトリ取得、同期、解析、検証の失敗やオブジェクト拒否を理解できる診断を出す。第三に、比較、replay、事後分析に足る過去状態または同等の監査記録を保持する。

出力だけでは不十分だ。出力は採用された結果を示す。診断は除外されたものと理由を示す。履歴は両者が変わった時点を示す。この三点がそろって初めて、現在値が調査可能な証拠になる。

同期経路にも判断が含まれる

RRDPの取得失敗は単純な「オフライン」ではない。RFC 9674のsame-origin検査、RFC 9697のセッション不整合検出と回復、deltaからsnapshotへの移行、場合によってはrsyncへの切替がある。どの経路を通ったかは最終ペイロードだけからは見えない。

マニフェスト処理も負の証拠を作る。取得不能、無効、stale、列挙ファイルの欠落、hash不一致、公開点の不一致はfetch failureとして扱われる。CRLは有効かつ現行のマニフェストとの関係で解釈される。受理した件数だけを残しても、何がなぜ欠けたかは再構成できない。

さらに各層には別の時計がある。証明書やCRLの有効期間、リポジトリ同期時刻、キャッシュのrefresh/retry/expire、ルータが保持する状態は同じではない。現在の成功が、直前の不完全な時間帯を消去してよい理由にはならない。

ローカル例外をグローバル状態と呼ばない

RFC 8416のSLURMは、prefix-origin validationにローカルフィルタやアサーションを加える仕組みを提供する。既知の公開障害を橋渡ししたり、有害な影響を限定したりするために必要な場合がある。だが変更されるのは運用者のローカルビューであり、署名済みのグローバルオブジェクトではない。

例外が見えないと責任の所在が逆転する。RPの出力にだけ存在する判断が、発行CAや資源保有者の判断として語られかねない。ポリシーID、承認、発効期間、変換ダイジェストを残せば、例外は見直し、失効、訂正が可能になる。

二つの緑色キャッシュが同じであるとも限らない。ソフトウェア版、アンカー集合、同期経路、失敗時挙動、SLURMが違えば、同じ公開材料から異なる結果を正当に作りうる。

検証状態レシートの最小構成

このレシートは草案の一部ではない。Daniel Kadeの提案は、秘密を集めずに既存証拠をjoinするためのものだ。

実行欄には製品と版、validation profile、設定ダイジェスト、有効なオブジェクト種別、トラストアンカー集合、時計状態を置く。取得欄には試行した公開点、同期方式、直近成功、今回の結果、fallbackと失敗分類を置く。

検証欄はマニフェストとCRLの状態、種別ごとの受理・拒否数、拒否理由、アンカー移行、規範profile、canonical cache digestを記録する。ローカル制御欄はフィルタまたはアサーションのID、承認、期間、変換ダイジェストを分離する。

配布欄にはRPKI-to-Routerのversion、Session ID、serial、出力時刻、対象ルータ範囲、未完了のconsumerを置く。最後に前状態、保持期限、責任主体、訂正先を結ぶ。秘密鍵、credential、不要なtopologyは含めない。

全履歴を中央へ送る必要はない。公開できるdigestと時刻、内部監査でだけ開示する詳細を分ければよい。必要なのは中央集権ではなく、独立して照合できる証拠だ。

レシートが証明しないこと

レシートは発行内容の現実的正しさを保証せず、ルータの最終選択も証明しない。人がローカル例外を承認した理由には別の記録が要る。実装間の差を自動裁定せず、個人草案を標準へ昇格させるものでもない。

代わりに、ある時間帯に何を根拠としてどのローカルビューがルーティング系へ提供されたかを残す。この狭さが証拠を強くする。後から「現在は緑だから当時も問題なかった」と推測する必要がなくなるからだ。

RPは連続運転する制御部品である。同期し、失敗し、回復し、更新され、設定が変わる。その出力が経路安全性に影響するなら、変化の履歴も制御面の一部だ。緑の表示は残してよい。ただしその下に、輸出可能で説明でき、再生できる状態を残さなければならない。

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. RPKI RP要件草案 revision 00
  5. Datatracker文書状態
  6. Datatracker改版履歴
  7. SIDROPSワーキンググループ
  8. RFC 8897 — RPKI RP要件
  9. RFC 6480 — 安全なインターネット経路制御を支える基盤
  10. RFC 9286 — RPKIマニフェスト
  11. RFC 9674 — RRDP Same-Origin Policy
  12. RFC 9697 — RRDPセッション不整合の検出
  13. RFC 9691 — RPKI Trust Anchor Keys
  14. RFC 8416 — SLURM
  15. RFC 8210 — RPKI-to-Router Protocol v1
  16. RFC 9582 — Route Origin Authorizations
  17. RFC 9829 — RPKI CRL Number Extensions