Summary

  • On 28 August 2026, the IETF opened Last Call through 11 September for a proposed Best Current Practice on operating RPKI publication engines and their RRDP and rsync repositories. It remains a draft under review, not an approved BCP.
  • The draft says a new RRDP notification file must not become visible before its referenced snapshot and delta files. With several backends, either requests must remain on one coherent timeline or every backend must receive the data before any backend exposes the notification.
  • Seeing a new session or serial proves that one endpoint returned one index. It does not prove that all referenced bytes are retrievable, that an RPKI object validates, that a relying party changed its output, that a router applied it or that packets moved.

An RPKI relying party asks a load-balanced service for its notification file. The answer names a new serial and a delta. The next HTTP request reaches another backend. That machine has the notification but not the delta. It returns 404. On a later connection, a stale node presents an older serial.

No cryptography has failed in this scene. The repository has broken the order in which it disclosed its own state.

That narrow failure explains why the IETF's 28 August Last Call matters beyond server tuning. The proposed publication-services BCP turns visibility order into an accountability boundary. A notification is not merely a small file to cache aggressively. It is a promise that the material it references can already be obtained along the path a relying party will actually take.

The timing must be described carefully. The IESG has solicited comments until 11 September. It has not yet approved a BCP, and the draft supplies no evidence that any named repository has suffered this failure. What exists today is a proposed coordination rule and a window in which operators, implementers and users can test whether it is precise enough.

Publish the objects, then publish the claim about them

RRDP separates an index-like notification from snapshot and delta files. The notification identifies a session and serial and points to the material from which a relying party can synchronize. In a single quiet server, writing the data first and the notification last may look trivial. Load balancing, CDNs, caches and maintenance connections turn it into a distributed commit problem.

The draft offers two ways to preserve a coherent view. One is affinity: subsequent requests from a client follow the same backend and therefore the same local timeline. The other is global ordering: all backends receive the new snapshot and deltas before any backend receives the new notification. Either design must make the public service behave as though the reference and the referent changed in the correct order.

This is stronger than checking whether files exist on the origin host. The relevant view includes the load balancer and any cache a relying party can reach. A CDN that has cached a 404 for a future path can make newly created data appear absent. A notification cached too long can hold clients behind. A stale keepalive connection can continue directing requests to a server removed from active service. The system's public state is the set of paths clients can actually traverse, not the deployment controller's intended inventory.

RFC 8182 defines RRDP's protocol objects and update process. The draft adds operational discipline around cases the protocol alone does not settle. In particular, RFC 8182 does not prescribe what an RP must do when a serial regresses. Some implementations may fetch a full snapshot. That is a recovery action, not proof that the older or newer view was authoritative.

A green notification can trigger more load, not less

Missing material changes the load shape. If a delta fetch fails, an RP can attempt the larger snapshot. If that fails, it can fall back to rsync. On its next RRDP run it may start with another snapshot. One misplaced notification can therefore turn a small incremental transfer into repeated full transfers across many clients.

This is why bandwidth cannot be read only as capacity. A spike may be demand, recovery, cache churn or repeated work caused by inconsistent publication. The proposed guide recommends outside-network canary RPs, logs for unexpected snapshot fallback, and monitoring of memory, disk I/O and consumed capacity. Those signals become useful only when joined to session, serial, backend, object URI and response outcome.

The draft also recommends retaining unreferenced snapshot and delta files for two hours. That grace period addresses slow clients and request races after a new notification supersedes old references. It does not repair the opposite ordering error. Keeping old files longer cannot make a new delta available before its notification is exposed.

Similarly, the recommendation to avoid producing deltas more often than once per minute is a load and efficiency control. Batching publisher changes can reduce the number of files clients fetch. It does not authorize a batch index to appear before the batch contents.

Publication has several receipts

The chain begins before RRDP. A certification authority creates signed material and submits a change to a publication engine through RFC 8181. A list query before change can reveal divergence. Multiple PDUs in one multi-element query can keep an intended changeset together. The engine then prepares RRDP and rsync views for public retrieval.

Each boundary speaks with limited authority. A CA's local record states intended objects. An RFC 8181 success states what the publication server accepted. A notification response states what one endpoint advertised. Successful snapshot or delta fetches state which bytes were delivered. An RP validation result states what that implementation accepted under its trust anchors, cached state and policy. A router feed and local RIB or FIB state speak later still. Packet observation is the final separate layer.

No receipt can inherit the authority of the next one. A repository can make bytes available that fail manifest, certificate, CRL or signed-object validation. A valid ROA payload can exist without a corresponding BGP announcement. A router can receive validated payloads and apply a local policy that leaves forwarding unchanged. This is Heng Lu's reality-layer distinction in a concrete protocol: an index, an object, a validation output and a packet are different facts.

The rsync section of the draft exposes the same problem through a different mechanism. If a repository tree changes while a client is reading it, the client can receive a phantom mixture of old and new objects. The proposed operating pattern is to build a complete new directory, fix timestamps, and switch one symbolic link. That single exposure point gives one session one coherent snapshot. The mechanism differs from RRDP notification-last, but the governance principle is the same: finish the state before announcing it.

Monotonic does not mean current

A rising serial is valuable because it lets clients recognize sequence within a session. It is not a freshness clock. A backend can monotonically serve delayed material. A notification can increase while referring to an object that later fails validation. Conversely, an RRDP session reset after restored data regresses can be the honest recovery action, even though a dashboard that rewards uninterrupted serial growth may call it failure.

The proposed BCP explicitly says a restore that causes content regression must trigger an RRDP session reset and that dependent CAs should be notified so they can resynchronize. That records discontinuity instead of disguising an older state as the next step in the old sequence. Leadership should treat this as evidence preservation: a reset says the continuity claim ended; it does not silently repair CA intent, reissue stale manifests or reconstruct lost publisher registrations.

The strongest operational test is therefore not “did the serial go up?” It is: for each advertised state, could independent canaries fetch every referenced object through the real service path; did hashes and protocol relationships validate; did expected CA changes appear; did RP output change as predicted; and did downstream routing observations agree?

Heng Lu's running-code primacy makes the test empirical. The configuration that says all backends are synchronized is an intention. Requests made across each backend and cache boundary are observations. His distinction between formal and practical control asks who can freeze notification exposure, purge a bad cache, drain stale connections, reset the session, preserve old bytes and explain the resulting validation changes.

The draft's notification-last rule is small because it should be enforceable. It asks operators to make one claim only after its prerequisites exist. That does not finish RPKI validation or routing. It creates a trustworthy place for those later processes to begin.

Sources