July 10, 202611 min read

BGP Security and RPKI: Defending Against Route Hijacking and Prefix Leaks

Sources:ARIN RPKI Resource Center|Cloudflare RPKI Portal|MANRS (Mutually Agreed Norms for Routing Security)

Eric Bang

Founder & Cybersecurity Evangelist

50,000+

BGP route hijacking incidents occur annually — most are accidental route leaks, but a meaningful percentage are deliberate interception attacks

2018

year of the Amazon Route 53 BGP hijack: attackers hijacked MyEtherWallet's IP addresses for 2 hours, redirecting user cryptocurrency wallet traffic to steal credentials

50%

of global BGP prefixes now have valid RPKI Route Origin Authorization records — up from under 10% in 2020, demonstrating rapid adoption

5 RIRs

Regional Internet Registries (ARIN, RIPE, APNIC, LACNIC, AfriNIC) all provide RPKI infrastructure — the starting point for ROA creation is your RIR portal

BGP hijacking: how attacks work

Understanding the attack mechanism clarifies what RPKI does and does not protect against.

Prefix hijacking (exact match)

An attacker's autonomous system announces routes for a victim's IP prefix — for example, announcing that 192.0.2.0/24 (owned by the victim) is reachable through AS-ATTACKER. Neighboring networks receive this announcement. If they lack RPKI validation, they may accept the fraudulent route — particularly if the attacker's announcement appears to have a shorter AS-path (fewer hops) than the legitimate announcement. Traffic to 192.0.2.0/24 begins routing to the attacker instead of the victim.

Sub-prefix hijacking (more-specific attack)

More-specific announcements take precedence in BGP route selection. An attacker announces a more-specific sub-prefix (192.0.2.0/25 inside the victim's 192.0.2.0/24 range) even without announcing the full prefix. Because /25 is more specific than /24, routers prefer the more-specific announcement — traffic to the first half of the victim's address space routes to the attacker, while the second half continues normally. This selective redirection can be invisible to the victim for hours.

Route leak (accidental hijacking)

Route leaks are not malicious but have similar impact. An ISP or enterprise accidentally announces routes received from one upstream provider to another, causing traffic that should route directly to transit through an unintended path. The 2019 Cloudflare route leak (via Verizon's failure to filter announcements from a small ISP) caused widespread internet outages. Route leaks are not blocked by RPKI ROA alone — they require additional filtering controls at the network level.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

RPKI and Route Origin Authorization: the technical mechanism

RPKI is a public key infrastructure that uses the RIR (Regional Internet Registry) chain of trust to cryptographically sign routing information. ROAs (Route Origin Authorizations) are signed records that state: 'AS X is authorized to originate routes for prefix P with maximum prefix length L.'

How ROA validation works

A ROA is a cryptographically signed object stored in the RPKI repository distributed by RIRs. When a router receives a BGP route announcement for prefix P from AS X, it checks: does a valid ROA exist for P authorizing AS X? If yes (RouteValid): accept the route. If no ROA exists (RouteNotFound): accept or drop based on policy. If a ROA exists but does not authorize AS X or the prefix is more specific than the ROA's maxLength (RouteInvalid): the route should be dropped. Networks configured to drop RouteInvalid announcements are effectively blocking BGP hijacking attempts that target prefixes with valid ROAs.

Creating ROAs for your IP space at your RIR

Log into your RIR portal (arin.net for North American IP space, ripe.net for European, apnic.net for Asia-Pacific, lacnic.net for Latin America, afrinic.net for Africa). Navigate to the RPKI section. Create ROAs for each of your announced prefixes: specify the prefix, your ASN, and the maximum prefix length. For a /24 that you announce only as a /24, set maxLength to 24. If you also announce more-specific prefixes (/25s for traffic engineering), set maxLength to 25 or the most-specific you announce.

MaxLength: the most common ROA configuration error

MaxLength determines the most-specific prefix length that the ROA authorizes. A ROA for 192.0.2.0/24 with maxLength=24 only covers exact /24 announcements — a /25 sub-announcement from your own ASN would be RouteInvalid. A ROA with maxLength=32 authorizes any sub-prefix (including /32 host routes), potentially allowing sub-prefix attacks from your own ASN. Set maxLength to the most specific prefix you actually announce — no longer than necessary.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Deployment steps: protecting your own prefixes

There are two distinct RPKI deployment actions: creating ROAs to protect your prefixes (origin protection), and configuring your routers to reject invalid routes (route origin validation). Both are necessary for complete protection.

Step 1: Create ROAs for all your announced prefixes

In your RIR portal: create a ROA for every IP prefix you announce from your ASN. Verify your ROAs using the RIPE RPKI Validator (validator.ripe.net) or Cloudflare's RPKI portal (rpki.cloudflare.com) — search for your prefixes and confirm they show as Valid. Gaps (prefixes that show as NotFound when you know they should be Valid) indicate ROAs not yet created or incorrect ASN/prefix specification.

Step 2: Configure routers to drop RouteInvalid announcements

On your BGP routers, enable RPKI route origin validation. The configuration syntax varies by vendor: Cisco IOS-XR: bgp origin-as validation; Juniper JunOS: routing-options validation group with RPKI cache server configuration; Bird2: rpki connection with a validator server. Connect your routers to an RPKI validator/cache server (Routinator, OctoRPKI, or Cloudflare's validator) that retrieves ROA data from the RIR repositories. Set routing policy to reject routes with RPKI status Invalid.

Step 3: Monitor for invalid routes targeting your prefixes

Even before you configure your own routers to drop invalid routes, you can monitor for hijack attempts: RIPE NCC BGPmon, Cloudflare Radar, and bgpstream.com track global BGP updates. Sign up for prefix monitoring services that alert when unexpected ASes announce routes for your prefixes. This provides hijack detection even before full RPKI validation deployment.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

RPKI limitations: what it does not protect against

RPKI ROA prevents prefix hijacking by unauthorized ASes for prefixes with valid ROAs. It does not protect against all BGP attacks.

Route leaks are not blocked by RPKI

Route leaks (accidentally propagating routes between the wrong peers) involve valid routes from authorized ASes — they pass RPKI validation. Preventing route leaks requires BGP prefix filters (filtering what you accept from peers and customers) and AS-path filtering. The MANRS (Mutually Agreed Norms for Routing Security) framework includes route leak prevention as a separate action from RPKI deployment.

BGPsec for path validation is not widely deployed

BGPsec extends RPKI to validate the entire AS-path — not just the origin AS — preventing path manipulation attacks where an attacker inserts their AS into a legitimate route. BGPsec is standardized (RFC 8205) but not widely deployed due to operational complexity and router hardware requirements. RPKI ROA origin validation is the practical current standard; BGPsec path validation remains a future capability for most networks.

Prefixes without ROAs remain vulnerable

RPKI only protects prefixes that have valid ROAs. Routes with NotFound status (no ROA exists) are still accepted by most networks even with RPKI validation enabled — dropping all NotFound routes would break connectivity to a large portion of the internet that has not yet created ROAs. The protection gap narrows as global ROA coverage increases (currently ~50%); the practical solution is to ensure your own prefixes always have ROAs.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

BGP hijacking is a real, documented attack that has affected cryptocurrency exchanges, CDN providers, and major internet services. For organizations controlling public IP address space, creating ROAs through your RIR is a one-time configuration that takes under an hour and protects your prefixes from origin hijacking by unauthorized autonomous systems. Enabling route origin validation on your routers (dropping RouteInvalid announcements) protects your network from accepting hijacked routes for other organizations' prefixes. Both are now considered operational security hygiene for organizations operating their own ASN.

Frequently asked questions

Does my organization need to worry about BGP security if we just use a cloud provider?

If your organization uses IP addresses leased from a cloud provider (AWS Elastic IPs, Azure Public IPs) rather than your own registered IP space, the cloud provider manages BGP routing and RPKI for those addresses. Your exposure to BGP hijacking in this case is the cloud provider's problem to manage, not yours. BGP security becomes your responsibility when you use your own registered IP address blocks (your own ASN, your own IP allocation from an RIR), typically when operating your own internet-facing infrastructure.

What is the difference between RPKI and DNSSEC?

RPKI secures the routing layer — it validates which autonomous systems are authorized to announce BGP routes for which IP prefixes, preventing traffic redirection attacks. DNSSEC secures the DNS layer — it validates that DNS responses are authentic and have not been tampered with, preventing DNS spoofing and cache poisoning. They protect different layers of the same problem (redirecting users to malicious destinations) and are complementary. A BGP hijack can redirect traffic even if DNSSEC is deployed; DNSSEC does not protect against routing-layer attacks.

How do I check if my prefixes have valid RPKI ROAs?

Use the Cloudflare RPKI portal at rpki.cloudflare.com — enter your IP prefix and it shows the validation status (Valid, Invalid, or NotFound) and the ROA details if one exists. RIPE's routing information service at stat.ripe.net also provides RPKI status for any prefix. If your prefixes show as NotFound, log into your RIR portal and create ROAs. If they show as Invalid, the existing ROA has an incorrect ASN or maxLength — correct the ROA in your RIR portal.

Sources & references

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

BGP security RPKI deployment route origin authorization BGP hijacking defense prefix hijack prevention BGP route leak internet routing security 2026 RPKI ROA configuration

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

BGP Security and RPKI: Defending Against Route Hijacking and Prefix Leaks

BGP hijacking: how attacks work

RPKI and Route Origin Authorization: the technical mechanism

Deployment steps: protecting your own prefixes

RPKI limitations: what it does not protect against

The bottom line

Frequently asked questions

Does my organization need to worry about BGP security if we just use a cloud provider?

What is the difference between RPKI and DNSSEC?

How do I check if my prefixes have valid RPKI ROAs?

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway