In February 2008, a Pakistani telecom accidentally hijacked YouTube’s IP address space. Traffic destined for YouTube from across the internet briefly routed through Pakistan Telecom, where it vanished into a black hole. YouTube was inaccessible for roughly two hours across many regions. Pakistan Telecom didn’t do anything particularly clever. They announced a more specific prefix for YouTube’s address space, and the internet’s routing protocol did exactly what it was designed to do: follow the more specific route.
That incident was one of the first times I really understood how fragile the internet’s routing layer is. I had spent years building application resilience, adding redundant load balancers, multi-region deployments, database replication setups. None of that matters when the network layer itself lies about where your IP addresses are.
Twenty years into working on cloud infrastructure, BGP security remains one of the most underappreciated risks in the industry. Most engineers focus on the layers above IP, where the security tools are familiar and the mental models are comfortable. The routing layer gets treated as someone else’s problem. That assumption is getting more dangerous, and I want to explain why, and what you can actually do about it.
Why BGP Has No Built-In Security
BGP (Border Gateway Protocol) was designed in the late 1980s and standardized in RFC 1771 in 1995. The engineers who built it were solving a real coordination problem: how do you enable thousands of independently operated networks to exchange routing information and collectively figure out how to forward packets across the global internet?
The design choice they made was to build on trust. Each Autonomous System (AS), a network operated by a single organization under a single routing policy, announces which IP prefixes it owns and has connectivity to. Other ASes decide whether to accept and propagate those announcements. The protocol assumes that network operators tell the truth about which prefixes they control.
There is no cryptographic verification. There is no central authority that validates prefix ownership before an announcement propagates. When AS64497 announces 192.0.2.0/24, the only thing stopping the global routing system from believing that announcement is each individual network operator’s manual filter configuration and the general goodwill of the internet community.
That worked reasonably well when the internet was a small community of academic and government institutions who all knew each other. It works considerably less well now, with over 70,000 active ASes exchanging routes.
How BGP Hijacking Actually Works
A BGP hijack happens when an AS announces a prefix it does not actually own or have legitimate authority to announce. There are two main flavors.
The first is a direct prefix hijack: an AS announces the exact same prefix as the legitimate owner. BGP’s path selection algorithm prefers shorter AS paths, so traffic from networks closer to the attacker will follow the malicious route while traffic from networks near the legitimate owner continues reaching the right destination. This kind of hijack is partial, but it can still intercept or disrupt significant traffic volumes depending on where the attacker’s network sits.
The second is a more specific prefix hijack: an AS announces a longer (more specific) prefix carved out of the legitimate owner’s block. If the legitimate owner announces 203.0.113.0/24, the attacker announces 203.0.113.0/25 and 203.0.113.128/25. BGP always prefers the more specific match, so the attacker’s routes win globally, not just from nearby networks. This is the technique Pakistan Telecom used against YouTube.
Once traffic is routed to the wrong AS, several things can happen depending on the attacker’s goals. A misconfiguration creates a black hole where traffic just disappears. A malicious actor can intercept traffic for eavesdropping, particularly for unencrypted protocols. Or traffic can be transparently forwarded to the legitimate destination after inspection, a man-in-the-middle scenario that is particularly concerning for DNS or certificate validation flows.
In 2018, attackers hijacked Amazon Route 53’s IP address space specifically to intercept DNS queries for MyEtherWallet, a cryptocurrency service. By controlling DNS resolution, they redirected users to a phishing site that drained wallets. The attack lasted about two hours and stole roughly $160,000 in cryptocurrency. The target’s application was fine. The attacker had even registered a valid TLS certificate for the phishing site. The compromise happened entirely at the routing layer, beneath all the application-layer security controls.
I have written before about how BGP powers anycast routing for CDNs and global services. The same mechanism that makes anycast so effective, multiple ASes announcing the same prefix with traffic automatically routing to the nearest instance, is what makes BGP hijacking so dangerous. The protocol does not distinguish between a legitimate anycast announcement and a malicious one. It just picks the best route by its own metrics.
RPKI: Cryptographic Trust for Routing
Resource Public Key Infrastructure (RPKI) is the cryptographic framework designed to solve BGP’s trust problem. It was standardized by the IETF through a series of RFCs starting around 2012, and adoption has accelerated meaningfully over the past several years.
The core idea is straightforward: IP address space ownership is already tracked by Regional Internet Registries (RIRs). There are five of them: ARIN for North America, RIPE NCC for Europe, APNIC for Asia-Pacific, LACNIC for Latin America, and AFRINIC for Africa. These registries maintain authoritative databases of which organization owns which IP address space. RPKI extends this by creating a certificate hierarchy that cryptographically binds IP address blocks to Autonomous System numbers.
An organization that owns a block of IP address space creates a Route Origin Authorization (ROA): a digitally signed object stating “AS64497 is authorized to originate the prefix 192.0.2.0/24 with a maximum prefix length of /24.” The ROA is signed with a private key, and the certificate chain leads back to the relevant RIR, which serves as a trust anchor for the entire hierarchy.
Network operators run RPKI validators, software that fetches all the ROAs from the five RIR repositories, verifies the cryptographic signatures, and builds a validated cache of which ASes are authorized to originate which prefixes. This is the Relying Party infrastructure. When a BGP router receives a route announcement, it checks the announcement against the validator’s cache and assigns one of three states.
A route is Valid if an ROA exists that matches the origin AS and the announced prefix falls within the ROA’s maximum length. A route is Invalid if an ROA exists for that prefix but the announcing AS is different from what the ROA authorizes, or the announced prefix is more specific than the maximum length the ROA permits. A route is Not Found if no ROA covers the announced prefix at all.
The trust model borrows from the same X.509 certificate infrastructure that TLS uses, with a chain of certificates from RIR trust anchors through intermediate certificates down to the ROA objects. If you understand how SSL/TLS and PKI work for HTTPS, the RPKI model will feel familiar. You have trust anchors at the top, a chain of delegation, and end-entity objects that assert specific facts about specific resources.
The Gap Between ROAs and Enforcement
This is the part most RPKI explanations gloss over, and it is the most important thing to understand when making decisions about routing security.
Creating ROAs protects others from being victimized by fraudulent announcements of your prefixes. When a legitimate network operator has ROAs for all their prefixes, any fraudulent announcement of those prefixes gets marked Invalid by validators everywhere, giving networks that enforce Route Origin Validation (ROV) a clear signal to reject the route.
But the protection only works end-to-end if the networks receiving route announcements actually drop Invalid routes. As of 2025, roughly 45% of internet prefixes have RPKI ROAs covering them. The harder problem is that many networks still do not enforce ROV: they run a validator and track which routes are Invalid, but accept those routes anyway, treating Invalid as informational rather than as a drop signal.
Several major networks have committed to ROV enforcement. Cloudflare was an early and vocal adopter. Amazon Web Services enforces ROV. Google, DE-CIX, and AMS-IX (major internet exchanges) have implemented it. Tier-1 carriers including Cogent, Lumen, and Telia have committed to it. In early 2026, Sparkle (AS6762), a major global transit provider, began rejecting RPKI-invalid routes, a significant step because transit providers carry traffic from many downstream networks that have not yet deployed ROV themselves.
The practical implication: even if you have not created ROAs for your prefixes yet, a significant and growing portion of internet traffic already passes through ROV-enforcing networks that would discard Invalid routes targeting your space. But it is not comprehensive enough to rely on as your only protection, especially for high-value targets like financial services, DNS providers, or cryptocurrency infrastructure.
Creating ROAs for Your Address Space
If you are responsible for IP address space of any kind, this is the most direct action you can take. Log into your RIR’s portal (ARIN Online for North America, the RIPE NCC portal for Europe, and so on), create an RPKI-enabled resource certificate for your organization, and create ROA objects for each of your prefixes.
Two mistakes I see consistently. First, operators create ROAs with an overly permissive maximum prefix length. If you set max-length to /32 on a /24 ROA, you have effectively blessed every /25, /26, and longer prefix that anyone could announce from your block. Keep max-length equal to the most specific prefix you actually announce in production. If you announce /24s from a /22 allocation, set max-length to /24.
Second, operators forget to create ROAs for all the Autonomous Systems that legitimately originate their prefixes. Many large organizations have multiple ASes or use transit providers who announce their space under a different AS number. Each valid origin AS needs its own ROA for each prefix it originates.
The process itself is not technically demanding. For most organizations it takes fifteen to thirty minutes per RIR. The certificate creation and ROA signing happen entirely within the RIR’s web interface. There is no software to install for this part.
Running Your Own RPKI Validator
If you operate a network with external BGP peering, running your own RPKI validator gives your routers the validated cache they need to make routing decisions. The two most widely deployed validators are Routinator (from NLnet Labs) and FORT Validator. Both are open source and straightforward to operate.
The validator periodically fetches all RPKI repositories from the five RIRs using the RRDP or rsync protocols, validates the cryptographic chain from each trust anchor, and serves the result to your BGP routers using the RTR protocol (RFC 8210). Your routers query the validator over RTR and use the validated cache to annotate incoming route announcements.
Router configuration then determines what to do with Invalid routes. Best practice is to drop them outright. Many operators start by adding a reduced local preference to Invalid routes before committing to dropping, which lets you monitor how much traffic would have been affected before flipping the switch. Running in informational mode for two to four weeks while watching logs is a reasonable way to build confidence before enabling enforcement.
The operational overhead is minimal. Routinator running on a small VM can serve dozens of routers without issue. The validation process is asynchronous: your router works from a local cache of validated results, so there is no latency impact on BGP route processing or convergence time.
What Cloud Architects Need to Know
Most engineers working on cloud infrastructure are not directly operating BGP. They are using managed services from AWS, GCP, or Azure, and those providers handle the routing layer. But there are several scenarios where RPKI matters to you specifically.
If you are running a hybrid or multi-cloud network with Direct Connect or ExpressRoute connections, you are peering BGP with your cloud provider. Understand which prefixes you are announcing into those sessions and create ROAs for your provider-independent address space. Even though the Direct Connect traffic itself is private, the BGP peering often involves prefixes that are also announced publicly, and your private routing depends on the underlying public routing table being correct.
If you are evaluating CDN or DDoS protection providers, RPKI adoption is a meaningful indicator of their security posture. DDoS mitigation capabilities become significantly weaker if the provider’s own routing is vulnerable to hijacking. A DDoS scrubbing provider that gets route-hijacked is not scrubbing your traffic; it is letting someone else see it.
For SD-WAN and SASE deployments, where traffic routes over the public internet between branches and cloud workloads, BGP route leaks and hijacks are a real threat to traffic confidentiality. RPKI does not replace your encrypted tunnels, but a hijacked route can disrupt tunnel endpoints even when the data inside is encrypted.
One argument I hear regularly is that because we encrypt everything with TLS, BGP hijacking no longer matters. This is wrong for two reasons. First, certificate validation itself can be manipulated if an attacker controls routing for the CA’s OCSP endpoint or for certificate transparency log infrastructure. Second, DNS infrastructure that is critical to routing HTTPS traffic correctly is often not encrypted end-to-end, and DNS services are prime hijacking targets. Understanding how DNS resolution works makes it clear how many trust assumptions sit beneath that TLS padlock. Your certificates do not help if DNS is poisoned via a routing attack.
This connects to the broader zero-trust security model: the principle of never trusting the network needs to be applied at the routing layer too, not just at the application and identity layers. RPKI is how you start enforcing cryptographic trust for internet routing.
If you run WireGuard or any other VPN between sites, remember that those tunnels rely on correct routing to reach their endpoints. A BGP hijack that redirects your VPN endpoint’s IP address to the wrong network can disrupt the tunnel setup even if the data inside it remains encrypted. Defense in depth requires correct routing as a foundation.
Beyond Route Origin Validation: ASPA and BGPsec
RPKI with ROV addresses one threat model: forged origin ASes. An attacker can still manipulate the AS path in ways that ROV does not catch, specifically by inserting a legitimate-looking path that routes traffic through unintended networks.
BGPsec (RFC 8205) extends cryptographic signing to cover the entire AS path, requiring each AS that propagates a route to sign it. Downstream networks can then verify that every hop in the path is authentic. BGPsec adoption has been essentially zero in practice, for a clear reason: it requires every AS in the path to implement signing. A single non-BGPsec AS breaks the chain of verification. With 70,000+ ASes on the internet, this is a coordination problem that has proven intractable.
The more promising near-term development is ASPA (Autonomous System Provider Authorization), an RPKI-based mechanism for validating customer-to-provider relationships in AS paths. ASPA objects let you assert “my upstreams are AS64498 and AS64499,” enabling detection of route leaks and path manipulation even without full BGPsec. ASPA is currently in the IETF standardization process and sees growing implementation interest from major operators.
Internet Routing Registry (IRR) filtering, which has been around since the 1990s, also remains relevant as a complementary layer. IRR and RPKI validate different things and have different trust models: IRR is based on registered routing policies (often self-attested and inconsistently maintained), while RPKI provides cryptographic proof of ownership. Using both gives you defense in depth at the routing layer.
Practical Recommendations
If you manage IP address space: create ROAs today. It costs nothing, takes about thirty minutes, and it protects your prefixes from being hijacked while protecting the rest of the internet from accidental origination of your space. There is no good reason not to.
If you operate network equipment with external BGP peering: deploy Routinator or FORT Validator, start by logging Invalid routes as informational, watch the data for a few weeks, then move to dropping Invalid routes. The performance impact is negligible and the security improvement is real.
If you are a pure cloud customer without your own BGP peering: factor RPKI enforcement into your provider evaluations. AWS, GCP, and Cloudflare enforce ROV. The more of your traffic path runs through ROV-enforcing networks, the better protected you are even without taking action yourself.
If you are a security engineer auditing your organization’s posture: check whether your IP address space has ROAs in the RIPE NCC RPKI Dashboard or Cloudflare’s RPKI validator. If it does not, that is a gap worth closing. It probably takes less effort than the last three-page risk assessment you wrote about something less fixable.
Where This Is Heading
RPKI momentum is real and accelerating. The major cloud providers, the largest CDNs, and a growing number of Tier-1 carriers now enforce ROV. Prefix coverage has grown from under 30% in 2019 to roughly 45% in 2025, and the percentage of internet traffic that passes through ROV-enforcing networks has grown even faster because the major adopters carry a disproportionate share of global traffic.
The internet will not be fully secured from routing attacks overnight. BGP’s design means that incidents can still occur through misconfiguration or through networks that have not deployed ROV. But the attack surface is meaningfully smaller than it was five years ago, and it will continue shrinking as large transit providers join the enforcement camp.
The routing layer is your infrastructure, even if you never touch a BGP router directly. The routes that your traffic traverses affect your security, your reliability, and your users’ experience. Understanding RPKI, creating ROAs for your address space, and selecting providers with strong routing security posture are concrete actions you can take right now to reduce a real risk that most of the industry is still ignoring.
Get Cloud Architecture Insights
Practical deep dives on infrastructure, security, and scaling. No spam, no fluff.
By subscribing, you agree to receive emails. Unsubscribe anytime.