Erik Protocol: A Third Way to Fetch RPKI Data, and Why That Worries Me

"A new way to synchronize RPKI repositories" reads like the dullest possible headline. A transport detail, a plumbing tweak, the kind of thing two engineers argue about and nobody else notices. That framing is wrong, and not for the reason you would guess. The fetch path is where revoked routing authorizations quietly stay trusted longer than they should, so the boring layer is exactly the one carrying real exposure. The protocol called Erik is Job Snijders' attempt to fix that fetch, and the question I keep landing on is not whether it works but where it belongs on an operator's list.

I picked up the design from George Michaelson's PING podcast recap on the APNIC blog, where Snijders walks through why the fetch is slow and what a Merkle-tree-based transport buys you. The recap is a conversation, not a deployment guide, and that distinction matters for everything that follows. Erik is an in-progress Internet-Draft in the IETF SIDROPS working group, funded by the NGI0 Commons Fund through NLnet. It is not a standard, not a mandate, and not something any operator has to "adopt by a deadline." I take the idea seriously and still push back on where it sits in an operator's priority list.

The protocol is named for Erik Bais, who chaired the RIPE Address Policy Working Group and died in May 2024. That naming is worth pausing on. The people building routing-security plumbing are a small community, and Erik is as much a memorial as a spec.

What RSYNC and RRDP actually got wrong

RPKI works because every relying party collects all the signed statements, the ROAs and the certificates above them, from publication points across the world, then validates them locally. Two transports move that data today. RSYNC was designed in the mid-1990s for filesystem synchronization and was never meant for this; it reconstructs a repository's state from the sequence of bytes the server holds, which forces retrieval into a strict order. RRDP came later, a SIDR-specific delta protocol that borrowed from the NRTM mechanism the RIRs use to copy Whois data. RRDP runs over HTTP, which is already a real improvement.

Snijders' point in the recap is that both still serialize the work. The client and server have to agree on what changed since the last fetch and ship it in order, and that ordering is the bottleneck. The system, in his words, "does not scale as well as we'd like" as the volume of signed data and the number of validating parties grow.

The supplementary IETF draft figures put rough numbers on the scale this has to serve. They land on the order of a few thousand cache instances and around fifty repository servers, with churn measured at roughly two new objects per second as of mid-2025. Those are draft estimates, not field measurements, and I would not anchor a procurement decision on them.

What Erik changes, in plain terms

Erik replaces ordered byte-fetch with content-addressable naming. Objects are indexed by cryptographic hash rather than by filesystem path, and a client fetches an index that points at partitions, which point at manifests. Because identity is the hash, a client can request exactly the objects it is missing instead of re-walking a directory tree, and concurrency is managed with monotonically increasing sequence numbers rather than file ordering. The signal layer uses DER encoding, chosen for compatibility with cache implementations that already parse RPKI objects.

The genuinely interesting consequence is the one the recap emphasizes: because objects are named by content, ordinary CDN and HTTP caching infrastructure can serve them without breaking the cryptographic guarantees. A relying party validates each object against its hash regardless of who handed it over, so an untrusted intermediary cannot forge data. At worst it can withhold it. That is the property that lets a provider like Fastly, where Snijders works, sit in front of a publication point. It is a clean idea.

Read the right-hand column for what it is. It describes a design intent stated in a draft, not a measured deployment result. Treating it as the latter is exactly the mistake I see in most write-ups of this protocol, and it is worth catching before you repeat it. If you are evaluating Erik, the first discipline is to keep draft intent and field result in separate columns of your own head.

The position I will defend: transport was never the binding constraint

Here is where I part company with the breathless framing. A faster fetch is good. But the data that matters for routing security is not bottlenecked on transport, it is bottlenecked on enforcement. ROAs cover more than half of announced prefixes, yet only about a quarter of networks actually enforce Route Origin Validation in strict mode. The gap between data existing and anyone actually dropping invalid routes on it is the real exposure, and no synchronization protocol closes it. A validator that fetches twice as fast but feeds a router that does not filter has changed nothing an attacker cares about.

So my read is that Erik solves a real but second-order problem elegantly, and the elegance risks pulling attention toward plumbing and away from the unfinished enforcement work. This is also the decision rule I would hand any operator reading the hype. If you have not turned on strict ROV at your borders, that is the work that dominates your real risk, and Erik is optional polish you can simply track. If you have spare engineering hours this quarter, strict ROV at your borders moves your risk further than swapping a working RRDP fetch for a draft transport. I would make that trade every time.

That is not an argument against Erik. It is an argument against treating it as urgent. An expiring draft funded to explore an approach is precisely the thing you track on the side while your roadmap stays pointed at enforcement.

Where a content-addressable transport genuinely earns its place

There is a real operational lesson buried in the cache-friendliness, and it is worth stating without the hype. The recurring failure with any centralized fetch path is the single slow publication point: one origin server degrades, and every relying party that depends on it stalls behind it, widening the window where revoked or changed authorizations are still trusted. Content addressing plus CDN fan-out attacks that specific failure, because the data can be served from many edges instead of one origin, and any copy is self-verifying.

So the second question to ask yourself is whether your current RRDP fetch is keeping validators fresh. If it is, there is no urgency, and you revisit when Erik is an If it is not, diagnose the slow publication point before you reach for a different transport.

The tradeoff is the one nobody advertises. You move from trusting one transport endpoint to managing a distributed cache, and distributed caches have their own failure surface: stale edges, inconsistent views, invalidation timing. Whether that is a net win depends on operator scale, which is the third thing to weigh honestly. A large validator fleet behind a CDN plausibly comes out ahead, and the cache model may genuinely pay off there. A single regional ISP running one Routinator instance over working RRDP gains little and inherits new moving parts, so the added complexity likely outweighs the gain. The protocol does not make that judgment for you, and the draft does not pretend to.

One more filter belongs on anything you read about Erik, and it catches more bad commentary than the technical questions do. If a number is sourced from a market forecast rather than the draft itself, discard it; if it traces to the source, keep it and cite where it came from. A great deal of the commentary around this protocol launders forecast-style statistics, enterprise modernization percentages, vendor "must upgrade by" deadlines, into the technical story. None of that is in the source. The grant has a funding milestone; that is a project schedule, not an industry mandate, and the distinction is the difference between a straight summary and a sales pitch.