要約

  • RFC 9674 は、RRDP notification が参照する Snapshot と Delta、および HTTP redirect の target に、notification と同じ scheme、host、port を要求する。
  • 同一企業、同一 CDN 契約、正常な TLS、期待どおりの bytes は、別 origin への取得権限を作らない。
  • Origin check の通過後にも、RRDP format/session/serial/hash、certificate、CRL、manifest、signed object、validated cache、router session、route policy の判定が残る。

CDN の移行計画には「所有者は変わらない」と書かれていた。Snapshot の bytes も変わらない。新しい host は HTTPS で応答し、旧 host はそこへ redirect する。人間の組織図では一つの service である。ところが RFC 9674 にとって重要なのは、その説明ではなく URI の origin である。

RRDP client は別 host への redirect を追ってはならない。到達できることは理由にならない。Hash が一致しても例外にはならない。Notification が与えられた origin の外側へ request を発生させる権限を持たないからだ。

Origin は組織の同一性を推測しない

RFC 6454 は scheme、host、port の組で origin を分ける。http と https は同じ host でも別である。二つの host は親 domain が同じでも別である。443 と 8443 も別 service boundary になる。

この機械的な比較には価値がある。「同じ担当部署」「同じ契約」「同じ certificate」「同じ storage」という説明は、監査可能な protocol rule ではない。配置換えのたびに例外を推測すれば、notification の権限は際限なく広がる。

RFC 8182 では、resource certificate の SIA にある rpkiNotify が Update Notification File を示す。Notification は session、serial、現在の Snapshot、利用可能な Delta を示し、それぞれの hash を持つ。初期仕様は HTTPS と hash を求めたが、cross-origin reference と redirect を明示的に禁止していなかった。

RFC 9674 は server と client の両方を修正する。Server は Snapshot/Delta URI を notification と同じ origin に置き、別 origin へ redirect してはならない。Relying Party は reference と redirect を検査し、違反があれば file または session を reject し、log を残すことが推奨される。

正しい bytes でも取得方法は正しくないことがある

RFC 9110 の redirect は、別 URI に対する追加 action である。Monitoring が最終 200 だけを保存すると、その action の列が消える。RRDP の audit では、SIA URI、正規化した origin、全 reference、全 HTTP response、全 Location、follow 前の判断を残さなければならない。

Notification hash は別の問いに答える。取得した Delta または Snapshot が参照された bytes と一致するかを示す。しかし他の server に負荷を送る権限は与えない。RFC 9674 が抑える attack surface は、一つの repository が多数の RP と別 repository の resource consumption を増やせる点にある。

逆も同じである。同じ origin なら content が正しい、という意味ではない。同一 origin の server も malformed XML、誤った hash、古い state を返せる。権限と整合性は別々に失敗する。

RRDP session の検査はここから始まる

RFC 8182 は notification の well-formedness と schema、location と session_id の組、Delta の連続性、serial の進行、Snapshot/Delta の hash、各 file の session/serial を検査する。Delta が reject されれば Snapshot に移ることができる。Snapshot も reject されれば RRDP は使えない。

Certificate SIA に他の access method があれば RP は fallback を試せる。しかし fallback は新しい取得 chain である。失敗した RRDP session を後から正当化するものではない。

さらに、RRDP 同期は RPKI object validation ではない。RFC 6480 は resource certificate PKI、signed object、distributed repository を分ける。RFC 6487 は certificate/CRL profile と path validation を定義する。RFC 9286 は manifest number、time、file name と hash の inventory を要求する。

したがって同一 origin から hash 一致の Snapshot を得ても、certificate、CRL、manifest、ROA などが validation に失敗し得る。Origin は「どこから取ってよいか」の record であって、「何を信じるか」の最終 record ではない。

Router はさらに下流にいる

RFC 7115 の validated cache は RP が実際に検証した object 集合である。RFC 8210 は cache から router への別 protocol を定義し、version、session、serial を持つ。RFC 6811 の prefix origin validation state は local routing policy への input でしかない。

そこで必要な receipt は少なくとも五つに分かれる。Origin-policy receipt、RRDP-integrity receipt、RPKI-validation receipt、router-ingestion receipt、route/outcome receipt である。一つの green badge がすべてを表すなら、どの subject が変化したかを説明できない。

Cross-origin log も攻撃者の identity を証明しない。確認できるのは policy violation である。同じく same-origin pass も repository の善意、freshness、router 反映、forwarding を証明しない。

2024 年の観測は現在値ではない

RFC 9674 は、調査対象 archive の 2021 年 10 月から 2024 年 10 月までに notification の cross-origin URI を観測しなかったと報告する。また 2024 年の別 window で same-origin redirect を使う server を一つ観測した。この evidence は当時の deployability を支えた。

それを現在の全世界 conformance に変換してはならない。Sample、期間、問いを失った数字は、precision ではなく誤った authority になる。

最小初期仕様 は一つの origin という小さな共通線を守る。現実の層 は企業名、URI、bytes、validated object、route を分離する。running code の優先 は、実際の RP と router の execution evidence がない routing claim を止める。

RFC 9674 の境界は狭い。しかし狭いから実行できる。問題は、その一枚の receipt に system 全体の真実を背負わせることである。

情報源