要約

  • RRDP の session_id と serial は同期状態を指す座標であり、全ての relying party が同じ bytes を得た証明ではない。同じ session、同じ既知 serial に別の delta hash が現れれば、差分履歴は再現可能性を失う。
  • 検出後の限定された回復は、警告を出し最新 snapshot から再同期し、RPKI 検証をやり直すことである。snapshot の成功は ROA の有効性や経路拒否の命令を意味しない。manifest、証明書、CRL、署名データ、router cache、ローカルポリシーは別の判定面を持つ。

これは実事故の報告ではなく、運用訓練としての例である。二つの拠点が、同じ RRDP update notification を参照する独立した RPKI 検証器を持っている。画面には同じ session_id が出ており、次の poll では両方とも同じ最新 serial に達した。通常の版比較なら「同期済み」となる。

ところが拠点 A は、以前に delta serial 1774 の hash を A として記録していた。拠点 B が後で取得した notification では、同じ session の serial 1774 に hash B が記載されている。各検証器が取得した delta は、その時に見た notification の hash と一致するかもしれない。個別のログだけなら両方とも成功である。

それでもローカルリポジトリは異なり、そこから作られる Validated Payload も分かれ得る。現在の番号が違うのではない。過去の一つの番号が、二つの内容を指してしまったのである。

RFC 9697 はこの session desynchronization を検出するため、前回成功した notification に含まれる serial と hash の組を保持する方法を定める。次の notification と重なる serial を比較し、既知 serial の hash が変わっていれば予期しない mutation と判断する。RP は警告を出し、最新 snapshot を処理して同期状態へ戻るべきである。

RRDP の状態機械は変化を再生する

RFC 6480 の RPKI は、resource certificate、CRL、ROA などの署名データと、それらを公開する分散リポジトリから成る。リポジトリは relying party がデータを取得するための clearing house である。データを保管することと、データの暗号学的権限を持つことは同じではない。

RFC 8182 の RRDP は、HTTPS でその公開状態を効率よく同期する。安定した notification URL は現在の session、serial、snapshot、利用可能な delta を示す。snapshot は一時点の publish 要素を全て含み、delta は一つの serial 増分で生じた publish、replace、withdraw を含む。

初回または再初期化では snapshot を使う。session が同じで、最後に処理した serial から現在値まで全 delta が連続して存在するなら、RP は番号順に適用できる。各 delta は notification と同じ session を持ち、serial は直前値より正確に一つ大きく、download した bytes は通知中の hash と一致しなければならない。

これにより一台の検証器の状態遷移は再現できる。しかし全検証器が同時に commit するわけではない。poll 時刻、cache、通信障害は異なる。RFC 6811 が RPKI の全体像を loosely consistent とするのは、この分散時間差のためである。

通常の時間差なら、A が 1775、B が 1774 にいるだけで、B が進めば同じ履歴へ収束できる。mutation では「1774 が何だったか」が一致しない。最新 serial への追随だけでは分岐は消えない。

Session ID は場所と組み合わせて初めて意味を持つ

RFC 8182 は UUID だけを session の一意な識別子として使うことを禁じている。別の悪意ある server が既存値を再利用できるからである。RP は update notification の location と session_id を組み合わせる。

location が repository の範囲を定め、session がその場所での一回の初期化履歴を分け、serial が履歴内の順序を示し、hash が snapshot または delta の実 bytes を固定する。どれか一つだけでは証拠が不足する。

したがって監視項目は「session と最新 serial」では足りない。notification の origin と URL、snapshot hash、delta の serial/hash 一覧、前回成功時との重複、実際に適用した結果が必要である。VRP 数の差だけを見つけても原因は分からないが、この証拠なら配送、履歴、manifest、証明書検証、実装差を切り分けられる。

不変の bytes が CDN の前提を作る

RRDP は少数の publication point から多数の RP へ配る構造を想定する。RFC 8182 が snapshot と delta を HTTP cache や CDN に置けるのは、notification に載せた後は URL も内容も変えないからである。同じ URL を取得した RP が同じ状態遷移を再生できるため、配信負荷を共有できる。

同じ座標の bytes を変更すると、この前提が壊れる。ある CDN edge は旧 delta、別の edge は新 delta を保持し、接続時刻によって検証器が別の履歴へ入る。session が長く続けば、最新 serial が一致した後も分岐は長期間残り得る。

RFC 9697 の保持対象は無限の archive ではない。前回と今回の notification に重複して残る delta の serial/hash だけでも、過去が変化したことを検出できる。小さな履歴保管が repository の大きな主張を検査可能にする。

警告には violated invariant を残すべきである。単なる fetch failure ではなく、同じ location、session、既知 serial が新しい hash を主張した、という事実である。これがあって初めて、なぜ差分継続を拒否したかを後から説明できる。

Snapshot は履歴をリセットするが、検証を省略しない

delta が欠ける、または reject された場合、RFC 8182 は現在 snapshot の処理へ移る。RFC 9697 は既知 hash の mutation に同じ回復を適用する。完全な publish 集合を取り直すことで、争いのある差分列を使わず現在状態を構築する。

snapshot にも条件がある。format と notification hash を検査し、session が一致し、serial が処理規則を満たす必要がある。snapshot まで reject されれば、RRDP から新しい利用可能状態を得ることはできない。

この回復は容量上も無料ではない。通常は小さな delta だけを取る多数の RP が一斉に full snapshot へ移ると、origin、CDN、回線、memory、CPU へ負荷が集中する。retry の backoff、段階実行、余裕容量、停止条件が必要であり、無限 reset は回復ではない。

再同期前には旧新 notification、取得時刻、origin 判定、重複 serial/hash、reject 理由を保存する。証拠を消してから成功しても、publication error、CDN inconsistency、software defect、意図的干渉のどれだったか判断できない。

snapshot 成功が証明するのは、この notification と整合するローカル repository を再構成したことだけである。世界で最も新しい、全ての署名データが有効、他の RP も収束済み、という証明ではない。

Same-Origin は配送責任を一つの origin に閉じる

初期 RRDP は notification から別 origin の snapshot/delta を参照することや、redirect が origin を越えることを明示的に禁じていなかった。RFC 9674 は scheme、host、port が同じであることを server と client の双方に要求する。

これにより一つの repository が RP を利用して別 server の resource を消費させる経路を閉じる。cross-origin URI または redirect を見つけた RP は RRDP session を reject し、記録すべきである。

ただし同一 origin は内容の正当性ではない。期待した HTTPS host から来た bytes に、期限切れや撤回済みのデータが含まれることはある。RRDP hash は notification と file の一致を示す。CA certificate、CRL、manifest、署名データの規則は、その後に別途適用される。

Publication service は CA の代わりに署名しない

RFC 8181 は CA engine が publication service に publish、replace、withdraw を要求する protocol を定める。CA と repository は別組織でもよく、message authentication に使う BPKI と、公開された RPKI データの認証は別である。

publication の success は、許可された client の repository 操作が完了したことを示す。relying party がその certificate、CRL、ROA を受け入れることまでは示さない。逆に CA の withdrawal intent が正しくても、RRDP/CDN が全 RP に一つの履歴を直ちに見せる保証はない。

障害を「RPKI failure」の一語にまとめてはいけない。CA の意図、repository state、RRDP distribution、RP validation、RPKI-to-Router delivery、local policy のどこで差が生じたかを特定しなければ、修復する主体も rollback する状態も決まらない。

署名は freshness と completeness を単独では証明しない

RFC 6488 は RPKI 署名データに共通する CMS、EE certificate、content type、message digest、signature の検査を定める。これらは必要条件だが十分条件ではなく、データ型ごとの追加検証が必要である。

正しく署名された file でも、後の版に置き換えられた古い状態かもしれない。新しい file の withholding や、存在すべき file の omission は、個別 signature だけでは分からない。

RFC 9286 の manifest は、CA publication point に存在すべき file と各 hash を署名付きで列挙する。列挙された file を全て取得できなければ fetch は失敗であり、偶然届いた一部だけを通常状態として使ってはならない。

Manifest には manifestNumber、thisUpdate、nextUpdate、filename、file hash の検査がある。RFC 9981 は replay 関連の manifest number 処理と限定的な reset 条件を更新した。これらは RRDP serial とは別の state machine である。

RFC 6481 の repository structure は、CA の publication point と manifest の関係、および変更途中の不整合を RP に見せない必要を示す。RRDP が point-in-time view を運べても、CA と repository の publication choreography が誤っていれば根本状態は直らない。

RP の信頼性は結果ではなく経路の再現性から生まれる

RFC 8897 は、trust anchor、certificate、repository、manifest、signed data、router cache に分散した RP の要件を整理する。取得と検証を別 component に分けても、どの bytes がどの Validated Payload を生んだかを追える必要がある。

二つの検証器が違うとき、権威ある一台を選ぶのではなく、notification、delta hash、snapshot、manifest、certificate/CRL、reject reason、trust-anchor input、software version を比較する。現在の規則で再現でき、uncertainty と fallback が見える経路を採用する。

その先の経路判断は operator に残る。RFC 6811 は prefix-to-origin mapping が変われば affected route を再検証し、必要に応じて BGP decision process を実行するよう求める。同時に validation state を local route policy で扱えることを要求する。Invalid を reject するか、preference を下げるか、観測に留めるかは network の決定である。

RRDP mutation を直接 mass route withdrawal に結び付けてはならない。snapshot、manifest、certificate、signed data、payload diff、router delivery、RIB、FIB、packet の順に証拠を進める。validator の green は経路の終点ではない。

情報源