Summary

  • RFC 9674 requires RRDP Snapshot and Delta references, and every HTTP redirect used to retrieve them, to stay within the Update Notification File's origin: the same scheme, host and port.
  • A relying party must reject a cross-origin reference or redirect even when the target is reachable and returns the expected bytes; accessibility does not grant retrieval authority.
  • Same-origin acceptance is only the first receipt. RRDP structure and hashes, RPKI object validation, validated-cache output, router ingestion, route policy and observed traffic still require independent evidence.

The redirect returned 200. The file arrived quickly. Its SHA-256 matched the value in the notification. Every availability graph was green. The RRDP session still had to fail.

The disqualifying fact was not in the bytes. It was in the path used to obtain them. The Update Notification File came from one origin; the redirect ended at another. Under RFC 9674, a relying party must not follow that transition. If it does encounter the cross-origin target, it must reject the RRDP session and cannot use RRDP for that repository interaction.

This can feel perverse to an operations team trained to celebrate successful delivery. The alternate host may belong to the same organization. It may present a valid certificate, sit behind a faster CDN and serve the exact object named by the notification. None of those facts changes the protocol's authority boundary. Reachability answers whether a request completed. The origin check answers whether this notification was allowed to cause that request.

The notification names a protection domain

RFC 8182 defines RRDP around an Update Notification File. A resource certificate carries an rpkiNotify SIA access location pointing to that file. The notification identifies the current session and serial, one Snapshot and, when available, a sequence of Deltas. Relying parties can use those immutable files to synchronize a local repository copy without repeatedly downloading everything.

The first RRDP specification required HTTPS and file hashes, but it did not explicitly prohibit the notification from pointing to Snapshot or Delta files on another origin. It was also silent about redirecting requests to another origin. RFC 9674 closes that gap on both sides.

For the repository server, every referenced uri must share the notification URI's scheme, host and port, and redirects must not leave that origin. For the relying party, the comparison is mandatory. A cross-origin reference makes the notification unusable. A cross-origin redirect makes the session unusable. Implementations should log what they detected.

The triple comes from RFC 6454, which groups URIs into origins that represent principals. Host alone is insufficient. The HTTPS and HTTP forms of repo.example are not the same origin; changing the scheme changes the security boundary. The default HTTPS service and port 8443 on that host are not the same origin; changing the port exposes a different service boundary. The hosts repo.example and cdn.example are also different, even if contracts, certificates or DNS administration connect the two names.

RFC 9674 borrows that origin concept for RRDP. It does not turn RRDP into a browser protocol. There is no claim here about cookies, JavaScript or CORS. The imported mechanism is narrower: a document reached through one certified referral must not make validators consume repository resources from a different principal.

A redirect is an action, not a clerical footnote

RFC 9110 treats a redirect as a response that asks the user agent to take further action at another URI. In ordinary operations, a redirect is easy to describe as plumbing. A storage migration, CDN change or traffic-management rule moves the request, and the client follows.

RFC 9674 makes the origin of that next request material. The server cannot delegate RRDP retrieval authority merely by returning a Location field. The client cannot infer permission from the fact that the redirect was received over the original HTTPS connection. Every hop remains subordinate to the origin named by the notification referral.

This is more than a content-integrity rule. A matching object hash can show that the retrieved Snapshot or Delta bytes are those referenced by the notification. It does not erase the resource-consumption effect of causing relying parties to contact another server. RFC 9674 addresses the ability of one repository to impose work on clients and on a referenced repository. The restriction therefore applies before the tempting shortcut: “the bytes matched, so the path no longer matters.”

The leadership mistake is to retain only the terminal status. A row that says download=success has discarded the evidence needed to judge the session. The durable record needs the SIA notification URI, its normalized origin, every reference, every redirect hop, the comparison result and the decision taken. Without that chain, a later reviewer cannot distinguish a permitted retrieval from a successful violation.

Same origin is necessary, not sufficient

Passing the origin gate does not make an RRDP object trustworthy. RFC 8182 still requires the notification to be well formed and schema-conformant. The session identifier must be interpreted with the notification location, not treated as globally authoritative on its own. Delta serials must form a usable chain. Retrieved Snapshot and Delta bytes must match the hashes in the notification. Their session and serial values must fit the state being applied.

Failure at one stage does not magically certify another. A rejected Delta can lead the relying party to the current Snapshot. A rejected Snapshot means RRDP cannot be used. Section 3.4.5 of RFC 8182 allows an implementation to try another repository access method exposed by the certificate SIA. That fallback is a new retrieval process, with its own evidence and failure modes, not retroactive approval of the rejected RRDP path.

Even a fully coherent RRDP synchronization only makes repository material available for validation. RFC 8182 explicitly leaves RPKI object validation out of scope. This is the line an executive dashboard most often erases: delivery of signed material and validation of signed material are adjacent operations, not one state.

RFC 6480 describes the architecture as a resource certificate PKI, signed objects and a distributed repository system. RFC 6487 supplies certificate and CRL profiles and path-validation rules. RFC 9286 gives manifests their own number, time and file-name/hash inventory. A same-origin Snapshot may still contain material that fails those later checks. The origin tells the client where retrieval was authorized; it does not sign every semantic conclusion the client might draw.

The green chain has at least five different subjects

RFC 7115 calls a validated cache the set of RPKI objects that a relying party has actually verified. That state is downstream from repository synchronization. RFC 8210 then defines another protocol by which validated payloads reach routers. It has its own protocol version, cache session and serial behavior. RFC 6811 defines prefix-origin validation states used as an input to local routing policy.

A single “RPKI healthy” indicator can therefore conceal several subjects:

  1. the RRDP reference stayed within its authorized origin;
  2. the referenced file was retrieved and matched its notification hash;
  3. the certificates, CRLs, manifests and signed objects validated;
  4. a particular router received a particular validated payload from a particular cache session;
  5. local routing policy used that state and produced an observed route and forwarding result.

Each can be green while a later one is red. Each can be red for a reason that says nothing about the earlier one. RFC 9674 improves the first boundary. It does not collapse the remaining four.

That distinction also limits incident language. A cross-origin log entry proves that a URI or redirect violated the policy. It does not, by itself, prove hostile intent, compromise or exploitation. A same-origin log entry proves the opposite narrow fact. It does not prove that the repository operator was honest, that the bytes were current or that the route chosen by a router was correct.

Historical deployability is not a current inventory

RFC 9674 reports a bounded historical observation. In the cited archives, one RRDP server used a same-origin redirect during the April-to-September 2024 period, and no cross-origin notification references were observed in the October 2021-to-October 2024 period. The document uses those observations to argue that the new requirement would not disrupt then-common repository operations.

That is useful evidence with an explicit clock and sample. It is not a 2026 census. It does not prove every current server and client conforms, or that no cross-origin reference has appeared since. A Leadership Alliance report should preserve the observation exactly where it belongs: deployability evidence in the standard's publication context, not a current market claim.

The same discipline applies to internal tests. A successful same-origin session yesterday does not prove the current notification, redirect chain, validated cache, router session or route. The evidence must be refreshed at the layer where the claim is made.

The minimum receipt keeps refusal intelligible

The minimum useful RRDP origin record is small enough to automate. Capture the resource certificate and exact SIA rpkiNotify URI; normalize its scheme, host and port; retain the notification bytes and hash; list every Snapshot and Delta URI; retain every HTTP status and redirect target; record the origin comparison; then attach RRDP file hashes, session and serial decisions.

After that, start a new ledger rather than extending the label. Record certificate path, CRL, manifest and signed-object outcomes at a named relying-party build and time. Record the validated payload set emitted by the cache. Record the router-facing protocol version, cache session and serial. Record the local policy decision and the route or traffic result actually observed.

This separation follows the doctrine in Minimum initial specification: keep the shared invariant narrow enough to enforce, and leave local deployment decisions visible rather than pretending they are universal. Reality layers explains why a symbolic “same repository” label cannot replace the scheme-host-port tuple or the execution that follows. Running-code primacy supplies the last constraint: a standards claim is not a router receipt.

RFC 9674's success is modest and important. It tells an RRDP notification where its authority stops. The more dangerous failure would be to take that clarity and turn it into a larger promise the standard never made.

Sources