1. The Sad Clown of Routing Security
Look at that image for a moment. It didn't take me long to craft a prompt to generate it because it genuinely captures how I felt for a long time after realizing, day after day, that most operators and ISPs couldn't care less about routing security. I’ve felt like a clown. A really sad one.
BGP as a tired clown on a bench, clutching balloons labeled IPv6 and RPKI, sitting under a dim streetlight with MANRS and PeeringDB posters peeling off the wall behind him. In the other frame, the same clown is at a wooden table, trying to stitch together a patchwork coat labeled RPSL, IRR, RPKI, BGPsec, Routing Security, with a piece of fragile thread. That was the prompt.
And that’s the Internet in 2026.
On paper, we have an impressive arsenal: IRR and RPSL for declared intent, RPKI and Route Origin Validation to stop origin hijacks, emerging tools like ASPA to catch leaks, heavyweight proposals like BGPsec, and architectural responses like FC-BGP. We have communities, “Down-Only” semantics, MANRS, PeeringDB, and half a dozen best-practice documents.
In practice, we’re still running a 1980s trust model at a global scale and hoping people behave.
This article isn’t just a tour of acronyms; it's a reality check. We’ll walk through what each of these mechanisms actually does, where they fall short, why adoption is so stubbornly slow, and what a realistic path forward looks like for operators who genuinely care about routing security.
And along the way, we’ll ask a blunt question:
If the industry has struggled for decades to deploy something as straightforward as IPv6, what are the odds that far more complex BGP security mechanisms will suddenly succeed by magic?
2. BGP by Design: A 1980s Trust Model in a 2026 Threat Landscape
BGP was never designed for the demands placed on it today.
It was built in an era where the Internet was a federation of universities, research labs, and a handful of carriers. People knew each other by name; misconfigurations were usually accidents, and the idea of weaponizing BGP for profit or geopolitical leverage wasn’t really on the radar.
The protocol’s “security model” is basically: everyone is honest, and we’ll fix it on the mailing list if they’re not.
There’s no built-in cryptography, no concept of ownership of prefixes or ASNs, and no embedded notion of business relationships, no formal policy semantics. Just:
“Here’s a path to this prefix. I heard it from someone I think is trustworthy. Want it?”
When you look at common incidents, most of them fall into a few categories:
Origin hijacks – an AS originates a prefix it doesn’t actually own. Sometimes malicious (to sinkhole or intercept traffic), sometimes a fat-fingered configuration that accidentally advertises someone else’s space.
Route leaks – a customer learns full routes from a provider and then leaks them to another provider or peer, turning itself into an accidental global transit. Or a misconfigured iBGP/EBGP boundary pushes internal routes out to the world.
Bogus or doctored paths – AS_PATH manipulation, poisoning, or simply false advertising of which networks traffic will traverse.
BGP accepts all of this at face value. There’s no native way to say:
“Is this AS actually allowed to originate this prefix?”
“Is this AS_PATH consistent with real provider–customer relationships?”
“Is this announcement consistent with what the origin AS previously said it would export?”
Everything we’re about to discuss, such as IRR, RPKI, ASPA, BGPsec, FC-BGP, communities, BCPs, and MANRS, is bolted onto this fundamentally naive substrate.
The clown isn’t sad because he has no tools. He’s sad because the shoes he’s wearing were never meant to run a global economy.
3. First-Generation Band-Aids: IRR, RPSL, PeeringDB, MANRS
Before we added cryptography, we tried to add declarations.
The Internet Routing Registry (IRR) and the Routing Policy Specification Language (RPSL) were early attempts to make operators publish what they intend to do:
“These prefixes belong to me.”
“These ASNs are my customers.”
“These are the import/export policies I apply at each boundary.”
IRR and RPSL gave us objects like route, route6, aut-num, as-set. With the right tooling, you could build prefix filters and customer/peer policies from those databases. In principle, that meant fewer fat-fingered announcements and more consistent policies.
In reality, IRR turned into a graveyard of stale entries and half-maintained databases. Some operators keep their records pristine; many don’t. Some regional registries run authoritative IRRs; others rely on third-party mirrors and legacy data. Objects rarely expire. People forget to clean up after mergers, acquisitions, or address transfers.
The result: IRR-based filtering is still useful, but you always have to ask, “Which IRR? Whose data? How current?”
PeeringDB and public policy documents try to complement this by answering:
“Where is this AS present?”
“Which IXPs and facilities?”
“What are their peering policies and traffic profiles?”
Again, when they’re accurate, they’re powerful. But plenty of networks still don’t bother to maintain a profile, or have one that reflects 2015, not 2026.
MANRS (Mutually Agreed Norms for Routing Security) emerged as a social pressure mechanism: a set of baseline behaviors, such as prefix filtering, anti-spoofing, and coordination, that operators can publicly commit to. Joining MANRS says, “We at least care enough to try.”
It’s a good initiative. But like IRR and PeeringDB, it’s voluntary and measured in pockets, not universals.
These first-generation mechanisms help in three ways:
They make intent more visible.
They enable better filtering and policy generation where the data is clean.
They create some social incentives for doing the right thing.
What they don’t do is provide hard cryptographic assurances or consistent global coverage. They’re band-aids on a protocol that still fundamentally trusts whatever it hears.
4. RPKI and Route Origin Validation: A Necessary but Incomplete Upgrade
RPKI (Resource Public Key Infrastructure) is the first time we addressed BGP’s trust problem by applying real cryptography.
At a high level, RPKI lets Regional Internet Registries issue resource certificates that prove:
“These IP addresses and ASNs belong to this entity.”
From there, the holder of those resources can create ROAs (Route Origin Authorizations), which say:
“AS X is allowed to originate prefix P, with a maximum prefix length of L.”
Validators download the global RPKI data set, verify the cryptography, and expose a list of valid prefix/origin combinations. Routers then connect to these validators using the RPKI-to-Router protocol (RTR) and perform Route Origin Validation (ROV) for incoming BGP updates.
If a router receives an announcement for prefix P originated by AS Y, it can ask:
“Do I have a ROA that says AS Y is allowed to originate P (or a less-specific with acceptable
maxLength)?”
Based on the answer, the route becomes:
Valid – matches a ROA.
Invalid – conflicts with a ROA.
NotFound/Unknown – no relevant ROA.
Operators can choose to:
Drop invalids.
De-prefer invalids.
Only log them initially, then ramp up.
That’s a massive upgrade compared to pure trust. Many “classic” origin hijacks are either prevented outright or at least made very visible.
But RPKI has sharp edges and critical blind spots.
It does not:
Validate the path—only the origin.
Prevent route leaks (a valid origin advertised through an unintended upstream is still “valid”).
Understand business relationships; it doesn’t know who is a customer, peer, or provider.
Solve operational challenges:
What happens when RPKI infrastructure is unreachable?
Do you “fail open” and accept everything, or “fail closed” and risk self-inflicted outages?
How do you manage keys, ROA lifecycles, and delegations without becoming your own worst enemy?
And, crucially, adoption is incomplete:
Plenty of prefixes still have no ROAs.
Many networks validate but only log or de-prefer invalids rather than drop them.
Misconfigured ROAs can themselves cause reachability problems, making operators skittish.
RPKI is necessary. It’s not sufficient.
We needed something that looks beyond the origin.
5. Path Security Attempts: BGPsec, ASPA, and the FC-BGP Perspective
If RPKI answers, “Is this AS allowed to originate this prefix?”, the next logical question is:
“Is this AS_PATH even plausible?”
That’s where BGPsec and ASPA come into play, and where architectural ideas like FC-BGP start to matter.
BGPsec: Cryptographically Sealing the Path
BGPsec aims to provide path integrity.
Each AS along the path signs the update, effectively saying:
“I, AS N, received this route from AS N-1 and am now forwarding it to AS N+1.”
Routers that support BGPsec can then validate the signature chain and detect tampering.
In theory, this is beautiful:
Fake AS_PATH segments become hard to inject.
Complex hijacks that rely on path forgery are mitigated.
You maintain cryptographic proof that the path was actually traversed.
In practice, it’s brutal:
Each update now includes signatures; each participating AS adds more.
Validation requires heavy CPU and memory, which routers are not generously endowed with at Internet scale.
Key management explodes: every AS must maintain signing keys, roll them safely, and ensure hardware keeps up.
Incremental deployment is rough: if only a handful of ASes participate, the security benefit is minimal.
BGPsec is academically elegant and operationally… aspirational. The Internet has not adopted it at scale, and there’s little sign that it will anytime soon.
ASPA: Relationship-Aware Sanity Checks
ASPA—Autonomous System Provider Authorization—is a more targeted and deployable idea.
Instead of signing the entire path, ASPA allows an AS to publish, in RPKI, which providers it has. In other words:
“I, AS X, authorize AS P1, P2, P3 as my legitimate upstream providers.”
Given ASPA data, a validator can look at a BGP path and ask:
“Does this sequence of provider/customer relationships make sense given what each AS claimed in ASPA?”
If a path claims a provider that the customer never authorized, or violates valley-free routing norms, ASPA-aware systems can flag or reject it.
ASPA doesn’t give you perfect path integrity, but it’s much lighter-weight than BGPsec and squarely attacks:
Route leaks – announcements flowing through providers/peers in ways that violate declared relationships.
Bogus upstream claims – pretending to be or to transit through a provider that never authorized you.
It’s also incrementally deployable: even partial ASPA coverage improves detection of obvious leaks in the wild.
FC-BGP: Architecting Around BGP’s Limits
Where BGPsec and ASPA are protocol-level tools, approaches like FC-BGP (Forwarding Commitment BGP) and similar fast-convergence/controller-assisted designs are architectural responses.
The core idea:
Accept that BGP itself is a slow, gossip-driven, hop-by-hop protocol.
Move heavy lifting, such as validation, policy computation, and convergence orchestration, into a separate system:
A controller, PCE, or set of validators that:
Ingest BGP state (via BMP, streaming telemetry, etc.).
Cross-check it against RPKI, ASPA, IRR, and policy models.
Decide what should be installed or advertised.
Push refined policies and updates back to routers.
An FC-BGP-style system can:
Enforce ROV and ASPA-based relationship checks off-box.
Detect leaks and anomalies in near real-time.
Coordinate rapid convergence by precomputing alternative paths and controlling advertisement timing.
Centralize logic that would otherwise be duplicated and fragile on every router.
Where BGPsec attempts to embed security semantics directly into BGP updates, FC-BGP decouples security from BGP: keep BGP as the distribution channel, but wrap it with an intelligent, security-aware control plane that has more context and more compute.
None of these alone is “the answer”. But together, RPKI, ASPA, communities, controller-assisted validation, you name it, you start to see a path toward a saner BGP universe without melting routers.
6. Policy Hints and New Attributes: Communities, Down-Only, and Containers
While the crypto crowd has been working on RPKI, BGPsec, and ASPA, the operational crowd has been quietly evolving another tool: policy hints.
BGP communities originated as simple 32-bit tags that could be attached to routes. Over time, they turned into an informal signaling language:
“Lower local-pref for this route.”
“Do not announce this to peers.”
“Blackhole this prefix for DDoS mitigation.”
“This prefix belongs to customer X.”
The problem is obvious: it’s a free-form language. Each operator invents their own dialect; documentation is inconsistent; mis-tagging can have severe consequences.
Recent work is about making this more structured and security-aware.
The Down-Only community (DO) is one example: a standardized way for an AS to say:
“This route should only flow downwards within a customer cone, not up or sideways.”
If providers and peers respect DO, they can prevent many route leaks by design: anything marked DO shouldn’t be transited upward to other providers or lateral peers. It’s a simple way of encoding valley-free expectations directly into the route.
The proposed Community Container Attribute takes it further by trying to impose structure on the chaos:
Group sets of communities into containers.
Namespacing them, adding metadata, making them easier for machines to parse and reason about.
Turning “a bag of opaque tags” into something more like a typed policy schema.
On their own, DO, and community containers don’t “secure” BGP. But they make intent more explicit and automatable:
Controllers and routers can apply consistent policies based on structured attributes.
Route-leak detection and prevention can be implemented as concrete logic rather than brittle regular expressions on raw community values.
Security tooling can see what traffic was supposed to do, not just what it did.
They’re part of the same pattern: moving from “tribal knowledge and documentation” to “machine-interpretable semantics.” That’s a prerequisite for any serious automation or security posture.
7. 2026 Reality Check: Adoption Gaps and Security Theater
This all sounds promising. On a whiteboard, you can draw a gorgeous picture:
IRR and RPSL for declared intent.
RPKI and ROV stopping origin hijacks.
ASPA catching leaks and bogus providers.
Communities and DO encoding policy.
FC-BGP-like controllers orchestrating the whole thing.
Then you look at the actual Internet and realize we’re not there.
In 2026, we still see:
Networks with no meaningful IRR presence, or objects untouched for a decade.
ASes with no PeeringDB page, or one that lists IXPs they left years ago.
Significant parts of the global table with no ROAs, or badly misconfigured ROAs.
Operators who validate RPKI but only log invalids because they’re afraid to drop them.
ASPA only beginning to appear, with patchy support and limited operator familiarity.
Virtual non-existence of BGPsec at Internet scale.
MANRS membership that’s growing, but still far from universal.
And sitting behind all of this is the IPv6 analogy you touched on.
IPv6 has been around for decades. The address space exhaustion narrative has been beaten to death. All vendors support it, and all certification paths teach it.
And yet, global IPv6 deployment is still uneven and, in many places, half-hearted.
If that’s the adoption curve for a technology that is conceptually simple, “new address family, same basic routing concepts,” what does that say about our chances of deploying multi-layered cryptographic security frameworks on top of BGP, with complex PKI operations, monitoring, and failure modes?
That’s where the “routing security theater” feeling comes from:
A handful of serious operators do the work.
Many others put a logo on their slides, perhaps configure a partial ROA set, and move on.
The global Internet remains a patchwork of “good citizens,” “best effort,” and “hope nobody notices.”
The clown isn’t sad because the mechanisms are bad. He’s sad because adoption and discipline are lagging far behind protocol design.
8. Why We Don’t Deploy What We Design: Incentives, Fear, and Operational Reality
So why is this so hard?
It’s not that the industry is stupid. It’s that incentives are misaligned, and operational reality is unforgiving.
First, incentives.
The cost of deploying routing security improvements—RPKI, ASPA, better IRR hygiene, controller-based validation—is concentrated:
You need people.
You need time.
You need lab space.
You need to risk touching your core routing policies.
But the benefits are diffuse and often external:
The whole Internet becomes incrementally safer.
Hijacks against third parties get harder.
Global routing stability ticks up by some small percentage.
There’s rarely a direct revenue line on your P&L that says “routing security investment paid off here.” Meanwhile, everyone is busy shipping new services, standing up new regions, or trimming budgets.
Second, fear.
Routing is one of the highest-blast-radius systems you operate. A misconfigured route policy, a botched ROA set, a badly designed ASPA deployment; any of these can cause outages you own, even if the protocols are sound.
For many organizations:
It feels safer to do nothing than to risk breaking things with RPKI/ROV or new policy machinery.
People remember early incidents where invalid ROAs took down prefixes and think, “Let’s not be that headline.”
Third, complexity and tooling gaps.
PKI is not trivial. Certificate lifecycles, key management, revocation; most network teams aren’t staffed like a crypto shop.
Tooling is fragmented: each RIR has its own UI and quirks; validators differ; integration into existing NMS/OSS is uneven.
Training and documentation lag behind protocol design; many engineers have never run a serious RPKI or ASPA pilot in a lab.
The net effect:
Protocols move faster than operational maturity.
The clown accumulates more patches, but the coat still doesn’t fit.
9. A Pragmatic Operator Roadmap: What You Can Actually Do Today
Despite all this, it’s not hopeless. You don’t need to wait for global consensus or full BGPsec deployment to make your corner of the Internet safer.
You just can’t do it in one jump.
Think of it as a staged roadmap.
Stage 1: Hygiene and visibility
Start with basics that cost little and reduce chaos:
Clean your IRR objects. Ensure route/route6/aut-num/as-set entries correspond to reality. Remove cruft.
Maintain a correct PeeringDB entry: facility/IXP presence, AS-SET, max-prefix guidelines, NOC contacts.
Document your routing policies publicly.
Implement baseline MANRS actions: anti-spoofing, prefix filtering, and coordination.
These don’t require new protocols. They require discipline.
Stage 2: Origin validation
Move into cryptography, but start where risk is manageable:
Register ROAs for your prefixes. Start with your most visible or critical address space.
Deploy RPKI validators and ROV on edge routers.
Initially, log and de-prefer invalids while you clean up ROAs.
Once you’re confident, move specific edges or customer cones to “drop invalids.”
Now you’re actively reducing the attack surface for simple origin hijacks.
Stage 3: Relationship and leak protection
Layer in ASPA and leak-aware policies:
Model your provider–customer relationships correctly.
Publish ASPA objects that reflect reality.
Configure or plan for validators and routers to use ASPA for leak detection and policy hints.
Start using DO and other standardized communities consistently to express “only down” propagation intent.
At this stage, you’re no longer just asking “can AS X originate this prefix?” but also “does this path make sense for our relationship graph?”
Stage 4: Architecture and automation
Finally, introduce an architecture that can digest and enforce all of the above:
Deploy controllers or “routing guardians” that subscribe to BGP state (via BMP/telemetry), combine it with RPKI, ASPA, IRR, and internal policy, and generate route-maps/filter-lists.
Make routing policy code-driven: version-controlled, reviewed, linted, and pushed via automation.
Integrate routing security checks into your change pipelines:
No new prefix/AS combo gets deployed without ROAs/ASPA/IRR entries.
No major policy change is exempt from review and automated verification.
This is where FC-BGP-like designs shine: not as magic protocols, but as platforms that encode and enforce your security intent at scale.
You don’t have to be a Tier-1 to start this journey. You just have to be willing to make one part of your network a little less clownish every quarter.
10. A Plausible Future: What “Good” Might Look Like in 2030
If you extrapolate the best of what’s happening today, a realistic “good” Internet in 2030 might look like this:
RPKI ROA coverage is strong for most globally significant prefixes. Major eyeballs and content networks validate and drop invalids by default.
ASPA is widely deployed: large transit providers and many regional operators publish accurate provider lists. Leak detection is baked into standard tooling.
IRR databases increasingly derive from authoritative systems of record; staleness decays over time. Automation ensures that, when policies change, IRR and RPKI are updated in tandem.
Controllers and FC-BGP-style systems are common in large networks: they continuously verify route announcements against policy, RPKI, ASPA, and service intent, and automatically synthesize filters.
Communities, DO, and the Community Container Attribute are consistently used to express routing intent in a machine-interpretable manner.
BGPsec finds niche adoption where its overhead is justified: critical infrastructures, specialized financial networks, or federated environments with controlled membership.
Is it perfect? Of course not.
There will still be misconfigurations, partial deployments, and people who ignore best practices. But the default state of the Internet will be less trusting, more verifiable, and more automated than today.
For that to happen, though, we need fewer “clever RFCs that nobody deploys” and more operators taking pragmatic steps in their own networks.
11. Taking the Makeup Off the BGP Clown
We’ve stitched IRR, RPSL, RPKI, ASPA, BGPsec, communities, and MANRS onto a protocol that still fundamentally believes whatever it’s told. We continue to sew new patches onto the costume, but we rarely commit to wearing it properly.
The core message is simple:
Tools exist.
They are imperfect but useful.
Their impact is gated far more by human factors than by protocol design.
From a career perspective, this is an opportunity.
Anyone can configure BGP sessions and accept defaults. Far fewer engineers can:
Explain how IRR, RPKI, ASPA, and FC-BGP-style architectures fit together.
Lead a staged adoption plan: hygiene → ROV → ASPA/leak controls → automation.
Quantify risk and explain tradeoffs to leadership: what happens if we drop invalids, how we mitigate, why ASPA matters, and why controllers are worth the investment.
If you can do that, you’re not just “the BGP person.” You’re the one who can move your organization from routing security theater to routing security practice.
So the next time someone shrugs and says, “RPKI will never be fully deployed,” or cracks a joke about how nobody cares about PeeringDB or MANRS, you can smile, nod, and then quietly lead the work to make your own network a counter-example.
One clean IRR set.
One set of ROAs.
One ASPA deployment.
One controller experiment.
That’s how the clown stops looking tragic and starts looking like a professional in a slightly ridiculous costume.
The Internet won’t fix itself. But piece by piece, operator by operator, we can at least make sure BGP isn’t going on stage completely naked.
See you in the next episode!
Leonardo Furtado