BGP needs a blockchain

The Border Gateway Protocol (BGP) holds the internet together. It is the system by which autonomous systems (ASes) — ISPs, cloud providers, enterprises, and governments — announce which IP address blocks they own and how traffic should reach them. BGP has no built-in mechanism to verify that these announcements are true. If an AS announces that it owns address space it does not own, traffic destined for those addresses will flow to the wrong place. This is not theoretical. It happens regularly, sometimes by accident, sometimes not.

Resource Public Key Infrastructure (RPKI) was designed to fix this. The idea is straightforward: the five Regional Internet Registries (RIRs) — ARIN, RIPE NCC, APNIC, AFRINIC, LACNIC — act as trust anchors. They sign certificates that bind IP prefixes to the autonomous systems authorised to originate them. Routers can then validate BGP announcements against these certificates and reject anything that doesn’t match. It works, and adoption is growing.

But RPKI has a structural vulnerability — one that the internet community has largely chosen not to talk about.

The trust anchor problem

RPKI’s security model is a hierarchy. At the root of each hierarchy sits a Regional Internet Registry. Every certificate, every Route Origin Authorisation (ROA), every validation decision ultimately traces back to the trustworthiness of these five organisations. If you trust the RIRs, the system works. If one of them becomes untrustworthy, the system doesn’t just degrade — it actively works against you.

Consider what happens if a RIR goes rogue. Not a hypothetical rogue — a real one, acting under the direction of a state actor, or compromised internally, or pressured into issuing fraudulent certificates. That RIR can sign ROAs for any prefix globally — even ones it does not control. It can authorise illegitimate origins for address space belonging to thousands of networks. And every router in the world that trusts that RIR’s trust anchor will accept those announcements as valid.

This is not a bug in the implementation. It is a consequence of the architecture.

Why current mitigations don’t work

The standard response to a compromised trust anchor is to remove it. In RPKI terms, this means operators would need to update their validation configurations to stop trusting the compromised RIR’s root certificate. In practice, this is a manual process that requires action from every network operator running RPKI validation — thousands of organisations across every jurisdiction on earth.

This takes time. Days at minimum. Weeks or months for full coverage. During that window, an attacker holding seemingly valid certificates can hijack traffic at will. Every minute the old trust anchor remains active is a minute the attacker can redirect, intercept, or black-hole traffic for any prefix in the affected region.

But it gets worse.

The routing paradox

Here is the part that should keep network engineers up at night: if an attacker has the ability to issue fraudulent ROAs and manipulate BGP routing, they may also have the ability to prevent the very updates needed to stop them.

Think about how a network operator would respond to a compromised RIR. They need to push configuration changes to their routers — updating trust anchor lists, modifying RPKI validator settings, potentially adjusting route filters. In most modern networks, this is done remotely. Management traffic flows over the same IP infrastructure that BGP controls.

If the attacker can manipulate the routing table, they can redirect or drop management traffic. The operator tries to SSH into a border router to remove the compromised trust anchor, but the packets never arrive — because the routing table has been poisoned to send that traffic somewhere else. The operator tries to push an update through their automation platform, but the API calls are swallowed by a black hole.

Possibly, a network operator considered such a scenario. They pinned their own certificates, locking down the address space that matters. Within their own network, this works. But management traffic does not always stay within one network. A session to a border router in another city may traverse transit providers, Internet Exchange Points (IXPs), and peers the operator does not control — infrastructure subject to the same poisoned routing table. The moment packets leave the AS, their fate is no longer the operator’s to decide.

You cannot rely on the network when the network itself is compromised. This is the routing paradox, and it is the fundamental reason why RPKI’s hierarchical trust model is insufficient for the world we are entering.

A fragmenting world

None of this mattered much when the implicit assumption held: that the organisations managing internet infrastructure would remain broadly cooperative, broadly aligned, and broadly trustworthy. For most of the internet’s history, that assumption was reasonable.

That assumption is beginning to break down. The global order is fragmenting along geopolitical lines. States are asserting sovereignty over internet infrastructure within their borders. Regulatory regimes are diverging. The idea that five organisations, operating under five different legal jurisdictions, subject to five different sets of political pressures, will all continue to act in the collective interest of the global internet is an assumption we can no longer depend on.

We need a trust model for the internet that does not collapse when a single authority is compromised; one that does not require coordinated manual action across thousands of operators in the event of a failure. We need one that continues to function even when the routing infrastructure itself is under attack.

The solution?

I believe a blockchain-based approach can provide this. Not blockchain as a buzzword — blockchain as a specific technical mechanism for decentralised consensus over a shared state, where no single entity holds root authority and revocation is a protocol-level operation rather than an administrative one.

The existing power structures do not need to change. RIRs still allocate and revoke IP space. Operators still manage their resources. The difference is that every action is recorded on-chain with cryptographic proof. An RIR can manage the resources it controls — and only the resources it controls. It cannot issue a certificate for address space that belongs to another registry. That constraint is not a policy; it is enforced by the protocol.

Resource owners — the networks that actually hold IP allocations — get something they have never had: direct, verifiable, cryptographic control over their own resources. An operator can authorise an AS to originate their prefix, and that authorisation is a signed transaction on the ledger — visible, auditable, irrevocable without the owner’s key. They can delegate sub-allocations. They can transfer address space to another party with a single on-chain transaction that both sides can independently verify. No paperwork. No email chains. No waiting for a registry to process a ticket.

This alone would be worth building. The Letter of Authorisation (LOA) process — the mechanism by which an IP holder tells an ISP “yes, I really do own this space, please route it” — is a document workflow in 2026. An email with a PDF. Sometimes a phone call. Entire classes of BGP hijacks start with a forged LOA that nobody bothered to verify, because verification is manual and slow. A blockchain replaces this with a cryptographic fact: the resource owner signed a transaction authorising the origination, and anyone can check it in seconds.

I am building this as a proof of concept — a module for FRR on Linux. More on the design in a follow-up post.