For more than four decades, the internet has relied on a routing protocol built largely on trust — a system where networks announce their presence and connectivity to one another with little verification. That era may finally be drawing to a close. Cloudflare announced this month that it has deployed Autonomous System Provider Authorization (ASPA) across its entire global network, a move that represents one of the most significant steps yet toward eliminating a class of vulnerabilities that has plagued the Border Gateway Protocol (BGP) since its inception.
The announcement, detailed in a Cloudflare blog post, lays out both the technical architecture and the strategic reasoning behind the company’s decision. BGP, the protocol that determines how data packets travel between networks on the internet, was designed in the late 1980s without built-in authentication mechanisms. Any autonomous system (AS) — the term for a network operated by a single organization — can announce routes to any IP address prefix, and neighboring networks have historically accepted those announcements at face value. This design flaw has enabled both accidental misconfigurations and deliberate attacks known as BGP hijacks, where traffic is rerouted through unauthorized networks, enabling surveillance, data theft, or service disruption.
The Two-Pronged Problem: Origin Validation and Path Verification
Securing BGP requires solving two distinct problems. The first is origin validation — ensuring that the network announcing a particular IP prefix is actually authorized to do so. The second is path validation — confirming that the sequence of networks through which a route passes is legitimate and hasn’t been manipulated. The internet community has spent years developing solutions for both, but progress has been uneven.
Resource Public Key Infrastructure (RPKI), specifically Route Origin Authorizations (ROAs), addresses the first problem. A ROA is a cryptographically signed object that states which autonomous system is authorized to originate a given IP prefix. When combined with Route Origin Validation (ROV), networks can reject announcements from unauthorized origins. According to Cloudflare, ROV deployment has reached meaningful scale — the company itself has been performing ROV since 2018 and publishing ROAs for its prefixes since 2019. NIST data cited in the blog post indicates that ROV filtering now covers a substantial and growing portion of internet routes.
Where ROV Falls Short: The Case for ASPA
But origin validation alone leaves a critical gap. Even if a network verifies that an announcement comes from the correct origin AS, it cannot verify whether the path the announcement took to reach it is authentic. An attacker can insert themselves into the AS path — a technique known as a route leak or path manipulation attack — without triggering ROV-based defenses. This is where ASPA enters the picture.
ASPA objects, defined in IETF RFC 9582, allow an autonomous system to cryptographically declare its upstream transit providers. When a receiving network performs ASPA-based verification (described in the draft specification for AS path verification), it can check whether each hop in the announced AS path is consistent with the declared provider relationships. If an AS appears in the path but is not listed as an authorized provider, the route can be flagged as invalid and rejected. This mechanism directly addresses route leaks and many forms of path manipulation that ROV cannot detect.
Cloudflare’s Implementation: Filtering and Publishing
Cloudflare’s deployment encompasses both sides of the ASPA equation. The company has created and published ASPA objects for its own autonomous systems, declaring its legitimate transit providers to the world. Simultaneously, it has enabled ASPA-based path verification on inbound routes, meaning it now actively filters announcements that fail ASPA validation. According to the blog post, this makes Cloudflare one of the first major networks to implement ASPA filtering at scale.
The technical implementation builds on Cloudflare’s existing RPKI infrastructure. The company operates its own RPKI validator and has integrated ASPA verification into its route processing pipeline. The blog details how ASPA objects are fetched from the global RPKI repositories, validated against the trust anchors maintained by the five Regional Internet Registries (RIRs), and used to evaluate incoming BGP announcements in near real-time. Cloudflare reports that the computational overhead of ASPA verification is minimal, an important consideration for a network that operates in over 330 cities worldwide and handles a significant percentage of global internet traffic.
A History of BGP Incidents Underscores the Urgency
The urgency behind these efforts is well documented. In 2018, a BGP hijack redirected traffic destined for Amazon’s Route 53 DNS service through a network in Ohio, enabling attackers to steal approximately $150,000 in cryptocurrency from users of the MyEtherWallet service. In 2022, a routing incident involving a Russian network briefly redirected traffic for major social media platforms. These are not isolated events — researchers at organizations like MANRS (Mutually Agreed Norms for Routing Security) have cataloged thousands of routing anomalies each year, ranging from fat-finger configuration errors to suspected state-sponsored interception.
The Cloudflare blog post specifically references the limitations exposed by incidents where ROV alone would not have prevented the disruption. Route leaks, where a network inadvertently or deliberately re-announces routes learned from one provider to another in violation of normal routing policy, are particularly pernicious. The 2019 incident in which a small Pennsylvania ISP leaked routes through Verizon’s network, causing widespread disruption, is a textbook example. ASPA, by encoding provider-customer relationships cryptographically, provides a mechanism to detect and reject such leaks automatically.
Industry Momentum and the Standards Process
Cloudflare’s move comes amid growing momentum in the standards community. The IETF’s SIDR (Secure Inter-Domain Routing) Operations working group has been refining the ASPA specifications, with RFC 9582 defining the ASPA object profile and companion drafts specifying the verification procedures. The five RIRs — ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC — have been building or deploying support for ASPA object creation in their hosted RPKI platforms. RIPE NCC, in particular, has been among the more active registries in enabling ASPA functionality for its members.
The U.S. government has also signaled interest in routing security. The Federal Communications Commission and the Office of the National Cyber Director have both highlighted BGP vulnerabilities as a national security concern. A 2023 White House roadmap on internet routing security called for broader adoption of RPKI-based technologies, including path validation mechanisms. While the roadmap stopped short of mandating specific technologies, it created political cover and institutional motivation for large network operators to accelerate deployment.
Challenges to Widespread Adoption Remain Significant
Despite the progress, significant obstacles remain. ASPA’s effectiveness depends on broad adoption — a verification mechanism is only as good as the data available to it. If most autonomous systems have not published ASPA objects, the verification process will produce “unknown” results for most paths rather than clear “valid” or “invalid” determinations. This creates a chicken-and-egg problem familiar to anyone who has followed RPKI deployment: networks are reluctant to enforce filtering until sufficient data exists, and operators are slow to publish objects until filtering creates a tangible incentive to do so.
Cloudflare acknowledges this dynamic in its blog post but argues that early adopters must lead by example. The company draws a parallel to the trajectory of ROV adoption, which followed a similar pattern — slow initial uptake followed by accelerating deployment once major networks demonstrated that filtering was operationally viable and produced measurable security benefits. Cloudflare’s position as one of the internet’s largest networks by traffic volume gives its endorsement particular weight. When a network of Cloudflare’s scale implements filtering, it creates pressure on upstream and downstream networks to publish their own ASPA objects or risk having their routes treated with suspicion.
What This Means for Enterprise Networks and ISPs
For enterprise network operators and internet service providers, Cloudflare’s deployment carries practical implications. Organizations that have not yet created ROAs for their IP prefixes should treat this as an immediate priority — ROV filtering is already widespread enough that unsigned prefixes face reachability risks. Beyond ROAs, operators should begin planning for ASPA object creation, particularly those who operate multi-homed networks with multiple upstream providers. The process of documenting and cryptographically attesting provider relationships requires accurate internal records of transit agreements, which many organizations have not maintained with the rigor that ASPA demands.
Network equipment vendors also face pressure to ensure their platforms support ASPA verification. While much of the processing can be handled by external RPKI validators feeding data to routers via the RPKI-to-Router (RTR) protocol, router software must be capable of acting on the validation results. Major vendors including Cisco, Juniper, and Nokia have been tracking the ASPA specifications, but production-ready implementations vary in maturity.
The Road Ahead for Routing Security
Cloudflare’s ASPA deployment is not a silver bullet. BGP security is a layered problem that requires coordinated action across thousands of independent network operators, each with different resources, incentives, and technical capabilities. But the deployment represents a concrete, measurable step forward — one backed by a company with the technical credibility and network scale to influence industry behavior. As the Cloudflare blog puts it, the goal is to make the internet’s routing system “trust but verify” rather than simply “trust.”
The coming months will reveal whether Cloudflare’s move catalyzes broader adoption or remains an isolated achievement. History suggests that routing security advances in fits and starts, driven by a combination of high-profile incidents, regulatory pressure, and the willingness of major operators to absorb the costs of early deployment. With ASPA, the technical foundation is now in place. The question is whether the rest of the internet will build on it.
WebProNews is an iEntry Publication