ARIN at CHI-NOG 13: The State of Routing Security

I sat in Brad Gorman’s RPKI workshop at CHI-NOG 13 with the kind of attention you give a talk when somebody on stage just admitted the security model has known holes. He’d been laying out the standard origin-validation story for forty minutes when I asked the obvious question. “What stops a bad actor from spinning up a sub-AS that masquerades as the legitimate origin?”

Brad’s answer was one word.

“Nothing.”

Then he kept going. “That is a current vulnerability.”

That moment is where this post lives. We’ve been bolting routing security onto BGP for fifteen years because the alternative, actually authenticating the protocol, turned out to be operationally impossible. BGPSec was the elegant cryptographic answer. It’s dead. What’s shipping is a pragmatic compromise that makes attacks more expensive without making them impossible.

That’s the version of routing security ARIN was teaching at CHI-NOG 13. ROAs you can trust, ASPA shipping in production at two RIRs with the others promising to follow by year-end, and a clear-eyed acknowledgment that none of this is perfect.

Why BGPSec didn’t ship

BGP4 was published in 1995. The designers were optimizing for “make the internet work between mutually distrustful networks” and reasonably figured the security layer could come later. Decades passed. Several billion dollars of internet commerce later, the security layer still hadn’t arrived.

BGPSec, formalized in RFC 8205 in 2017, was supposed to be the security layer. The model is intuitive. Every AS in a path signs the path with its private key. Every receiving router verifies the chain back to the origin. Cryptographic certainty that the path you see is the path the packet took. If you’ve taken Networking 201 since 2010, you’ve heard the pitch.

Then operators tried to deploy it. IMHO, three problems killed it.

One: crypto operations per BGP UPDATE. A modern internet router sees hundreds of thousands of route changes per hour during convergence events. Every BGPSec-protected UPDATE requires a signature operation by the sending router and a verification by every receiving router along the path. At internet scale, with default elliptic-curve signing (ECDSA P-256, per RFC 8208), this is non-trivial CPU load on hardware that’s already busy doing actual routing.

Two: path-length signature bloat. Every AS in the path appends a signature block to the UPDATE. A signature block is roughly 70 to 80 bytes once you count the AS number, algorithm identifier, public key key ID, and the signature itself. For a typical ten-AS internet path, you’ve just added the better part of a kilobyte to every route. Multiply by half a million routes in the global table. That’s significant RAM, significant inter-router bandwidth, significant FIB pressure.

Three: aggregation is incompatible with the signature chain. When an upstream provider aggregates several customer prefixes into a summary route, the BGPSec signature chain for the underlying prefixes is severed. The aggregate has no valid signature path. Operators aggregate routes all the time, both for table-size discipline and for traffic engineering. BGPSec essentially forbids it. RFC 8205 Section 4.2 acknowledges the limitation and offers no good answer.

A fourth problem, worth mentioning. BGPSec only protects between BGPSec-speaking routers. If any hop in the path doesn’t speak it, the security chain breaks at that hop. So the deployment story is “everyone has to upgrade hardware and software simultaneously,” which is the same story we told for IPv6, and we know how that’s going.

The verdict in practice, if not on paper. Nobody deployed BGPSec. RIPE-NCC stopped advocating for it years ago. Cisco never built mainline support. The IETF SIDROps working group quietly pivoted to a different model. The standard exists, the spec is correct, the code samples compile. None of that makes it real.

What survived: RPKI and ROAs

The pragmatic move was to give up on signing the BGP update path entirely and instead pre-publish authoritative statements out of band. That’s RPKI. Cryptographically signed objects in a global repository, published by the entity that actually owns the resources, validated by independent software, fed into router policy as an out-of-band data stream. No crypto in the data plane. No signatures in the BGP messages. Aggregation works fine.

The objects you publish today are ROAs (Route Origin Authorizations). A ROA says: “prefix X is announced from ASN Y, up to maximum length Z.” Validators (Routinator, RPKI-Client, FORT, take your pick) fetch all ROAs globally, compare them to what BGP is announcing, and assign each route a validity state. Valid, invalid, or unknown.

“Unknown” is doing important work. Roughly 60% of globally routable IP space is covered by ROAs today. The other 40% gets unknown status, and routers running origin validation typically still accept those routes, because if “unknown” were treated as “invalid,” half the internet would stop working. Origin validation today is essentially “block the things actively flagged as bad, accept the things explicitly approved, and route everything in the middle the old-fashioned way.”

This works. Real BGP hijacks get blocked. The classic 2008 Pakistan Telecom / YouTube hijack, where Pakistan’s incumbent ISP announced YouTube prefixes and accidentally propagated them globally, would be cleanly stopped by an origin-validating downstream today. So would the 2018 MyEtherWallet hijack, where attackers routed Amazon Route 53 DNS prefixes through their own infrastructure for a few minutes and walked away with roughly $150,000 in Ethereum.

This is also where Brad’s “that’s a current vulnerability” admission lives. Origin validation doesn’t actually prove the path is legitimate. It only proves the origin AS in the path is the one authorized to announce the prefix. A sophisticated attacker can announce a forged path that ends at the legitimate origin AS while routing through their own infrastructure. As long as the last hop of the announced AS path matches the ROA, validity passes. Some of the traffic ends up at the real destination. Some ends up at the attacker. Sufficient for most criminal use cases.

There’s also the MaxLength gotcha. A ROA can authorize a prefix at a maximum prefix length. “This /16 can be announced as anything up to a /24.” Seemed convenient when the standard was written. Now it’s a known vulnerability called forced-origin sub-prefix hijack. An attacker who finds a ROA with permissive MaxLength can announce more-specifics that pass validation, because the ROA explicitly allows them, and inherit traffic for those more-specifics. Recommendation across the industry is now: don’t use MaxLength unless you have a specific reason. One ROA per actually-announced prefix.

Then there’s the deployment-time reality. ROAs propagate slowly. ARIN regenerates its repository every five minutes. Validators typically poll every ten minutes. Operators take additional time to fold validity state into policy. End to end, you’re staring at up to a sixty-minute window between creating a ROA and the rest of the internet acting on it. If you misconfigure something, particularly the AS0 ROA (which says “this prefix should not be announced from anywhere”), you’ve got a sixty-minute hole in your reachability while the correction propagates. As Brad put it: “Know that going in. People have fingers, and fingers find ways to type the wrong number.”

ASPA is shipping

The next layer is ASPA. Autonomous System Provider Authorization. It’s a path-validation answer that avoids every problem that killed BGPSec.

An ASPA is a signed statement: “ASN X has these N upstream providers.” That’s the whole object. It lives in the same RPKI repository system as ROAs. Validators compare what’s in BGP against the declared provider relationships and flag paths that violate them.

The validation logic is more involved than origin validation. The shorthand. AS paths should look like a single peak. Customer-to-provider for the rising side, peer-to-peer at the top (allowed once), provider-to-customer for the falling side. A path that goes customer-to-provider, then back down to customer, then back up to provider violates the algorithm and gets flagged as invalid. An attacker announcing your prefix through a path that goes through them, then back down through a different provider you didn’t declare, fails validation.

The reason ASPA works where BGPSec didn’t:

• No crypto in the BGP update path. Updates carry no signatures.
• No bloat. The ASPA object lives in the repository, not in the route announcement.
• Compatible with aggregation. ASPA is about provider relationships at the AS level, not exact-path matching.
• Incrementally deployable. ASPA-aware validators can use the data. Non-aware routers ignore it. Partial deployment provides partial benefit instead of zero benefit.

Two RIRs let you publish ASPAs today. ARIN and APNIC both added customer ASPA creation in late 2025. The other three (RIPE-NCC, LACNIC, AFRINIC) have publicly committed to shipping the capability before the end of 2026.

The standards process has an interesting wrinkle here. The IETF SIDROps working group refuses to advance the algorithm-finalization draft past working-group last call until there’s a working proof-of-concept implementation that consumes real ASPA data. So the RIRs are publishing ASPAs in production so the standards process can validate the algorithm. The standard is being shaped by deployed reality rather than the other way around. Worth noting after fifteen years of BGPSec sitting on the shelf because nothing about it survived contact with production.

The number of published ASPAs is small today. Brad noted around 500 in ARIN’s repository against 210,000-plus ROAs. But each ASPA can declare many upstream providers in a single object. One ASPA can cover a lot of policy ground.

None of this is perfect

Worth keeping in mind, especially when somebody on stage at a conference is telling you routing security is solved.

ROAs without ASPA can still be defeated by AS-path spoofing. Origin validation only checks the last hop. Sophisticated attackers split traffic by announcing forged paths that terminate at the legitimate origin AS. Sub-prefix hijacks with MaxLength-permissive ROAs are an easier version of the same attack.

ASPA without ROAs is also incomplete. Path validation only works against providers you’ve declared. If you haven’t published your ASPAs, every path going through you is “unknown,” which validators treat as “let it through.” Cross-RIR coverage is uneven during the rollout. Until 2027 or so, “ASPA” effectively means “ASPA at ARIN and APNIC” for most resources.

Both together can still be defeated by a determined attacker with sufficient peering relationships. Brad’s quote on this: “It’s still possible, but it makes it much harder. It makes them take the effort.” The strategic posture is raise the cost of attack, not eliminate the possibility. Routing security is risk management, not certainty.

The cross-RIR coordination gap is real. A delegate asked Brad whether you can audit your routing-security posture across registries. Enterprise with resources in ARIN and RIPE wants a single dashboard. Answer: not yet. The RIRs are individually quite good at their own data. The cross-RIR view is on someone’s roadmap somewhere. For now, if you have resources in multiple registries, you maintain ROAs and ASPAs in each, manually.

The 60% global coverage means the entire system is currently in permissive mode. If we ever get to 95%-plus ROA coverage, the discussion changes. At that point “unknown” can plausibly become “treat with suspicion” instead of “treat as normal.” We’re not there. Possibly we never will be.

Implementation is still uneven. ARIN and APNIC are ahead. RIPE is generally fast. LACNIC and AFRINIC have committed but haven’t shipped ASPA yet. Until they do, an enterprise with global resources can’t get full coverage no matter how diligent they are.

None of this means RPKI and ASPA aren’t worth doing. They are. The 2008 YouTube hijack and the 2018 MyEtherWallet hijack would both be blocked by today’s deployment, and that’s a meaningful improvement over what we had a decade ago. But the marketing copy that suggests we’ve solved routing security is dishonest. We’ve made it harder. The cost of a successful attack is higher than it was. Some classes of attack are foreclosed. Other classes are still wide open.

What to actually do

If you have resources from any RIR and you’re not already publishing ROAs, publish ROAs. ARIN’s hosted RPKI portal takes about ten minutes to set up. Match your ROAs exactly to what you’re announcing. Don’t use MaxLength unless you have a specific reason. The largest networks on the internet (Comcast, AT&T, Verizon) use hosted RPKI, so you’re not missing anything by skipping the delegated complexity unless your security team has a hard requirement.

While you’re in there, check the IRR Auto-Manager option. It creates a matching IRR route object for the same origin AS and prefix at the moment you create the ROA. If you’ve been maintaining IRR by hand, this is the feature you’ve been waiting for.

If you have an ASN and you’re an ARIN or APNIC member, publish your ASPAs. The barrier is small. One object per ASN, listing your upstream providers. The data is what’s letting the standards process complete.

If you have resources at multiple RIRs, do this work in each. The cross-RIR view isn’t coming soon.

And if you’re tempted to use the AS0 ROA as a “nothing should announce these prefixes” big hammer, know that the sixty-minute propagation tail means undoing a mistake takes time you may not have. Test in OT&E first. ARIN’s test environment exists for exactly this reason.

If you’re managing tens or hundreds of ROAs, the Reg-RWS API is what scripts against. Nobody needs the API. The lab manual itself says so. But doing bulk changes through the web UI gets inefficient fast. For a CI/CD-friendly RPKI workflow against ARIN’s repository, Reg-RWS is the right tool.

There’s another technical question lurking under all of this. Whether there’s a path-validation answer that lives inside MP-BGP rather than out-of-band in RPKI. There might be. But that’s a different post.

Tools worth bookmarking

A handful of free tools came up in Brad’s workshop manual that I’ve now folded into my BGP & routing tools page. The ones I’d reach for first:

• RPKI ROA Planner for sketching changes before you commit them in ARIN Online.
• NIST RPKI Monitor for tracking how operators globally are actually behaving with invalid routes.
• Routinator web UI or the Cloudflare RPKI portal when you need to spot-check a single prefix without standing up your own validator.
• BGP Filter Guide for the router policy patterns to actually use once you have validation in place.

The full set (plus the BGP tools I already kept on the page) lives at /tools/?filter=bgp.

Disclosure: I attended Brad Gorman’s RPKI workshop at CHI-NOG 13 in Chicago. CHI-NOG didn’t comp my registration or travel. ARIN didn’t buy me anything. The opinions here are mine. For more, please read my full disclaimer.