How to Protect Your IP Prefixes from BGP Hijacking

#networking #security #devops

BGP has no built-in mechanism to verify that the ASN announcing a prefix is actually authorized to do so. Any autonomous system can claim any address space. If the announcement propagates and downstream routers accept it, traffic follows.

This isn't academic. In 2008, Pakistan Telecom announced a more-specific /24 of YouTube's /22. It propagated globally through PCCW. YouTube traffic routed to a blackhole for two hours. In 2018, attackers hijacked Amazon's Route 53 DNS service — redirected queries for myetherwallet.com to a phishing site, drained ~$150,000 in Ethereum from users who logged in. Neither attack required compromising a single system. Both exploited the same BGP design assumption from 1989: that peers tell the truth.

RPKI fixes this. Here's how it works and what you need to do.

How RPKI works

Resource Public Key Infrastructure lets IP holders cryptographically prove that a specific ASN is authorized to originate a specific prefix. The core object is a Route Origin Authorization — a signed certificate containing three fields:

The protected prefix
The ASN permitted to announce it
The maximum prefix length allowed

The certificate chains back to your RIR (RIPE NCC for European and Middle Eastern operators) as the trust anchor. Routers check incoming BGP announcements against published ROAs and assign one of three validation states:

State	Meaning
Valid	Prefix and ASN match a ROA; length within max
Invalid	ROA exists but ASN doesn't match, or prefix exceeds max-length
Not Found	No ROA covers this prefix

Networks running Route Origin Validation (ROV) drop Invalid routes. As of May 2024, all but one transit-free tier-1 provider does this — reducing a hijacked route's propagation by one-half to two-thirds. Adoption across tier-2 and regional networks is still uneven, but the major transit providers enforcing ROV carry the majority of global internet traffic. An attack that would have propagated everywhere in 2010 now stalls at most of the networks that matter.

Creating a ROA in RIPE NCC

You need LIR access to my.ripe.net and the prefix must appear under your resource certificate before you start.

The process:

Log in to my.ripe.net → navigate to the RPKI section
Confirm your prefix appears in your resource certificate
Select the prefix, enter the announcing ASN, set max-length
Publish and verify with an external validator

ROAs reach relying parties within 15-30 minutes for RIPE NCC under normal conditions. Always verify with an external tool — don't rely on the portal's own confirmation.

Max-length: where most mistakes happen

Max-length is the most consequential parameter and the most commonly misconfigured.

Mistake 1: Too tight

You hold a /22. You set max-length to /22. You announce it as four /24s. Every /24 sub-announcement returns Invalid — including from your own ASN. You've caused your own outage.

Fix: if you plan to announce /24s from a /22, set max-length to /24.

Mistake 2: Too loose

You set max-length to /32 to avoid the above. You've now authorized any more-specific announcement down to a single host address — which is exactly what more-specific hijacking exploits. RPKI's prefix-length protection is disabled.

Fix: set max-length to match the most-specific prefix you actually intend to announce, nothing beyond that.

Other common mistakes:

Creating a ROA for a prefix that will be announced from multiple ASNs using a single ROA. One ROA covers exactly one prefix-ASN combination. You need a separate ROA per authorized ASN.
Forgetting to update ROAs when changing upstream providers, migrating ASNs, or onboarding to a cloud BYOIP program. The ROA needs updating before the new announcement goes live — not after.
Not verifying propagation after creation. A ROA in the portal that hasn't reached relying parties provides no protection.

RPKI with leased IPv4

ROAs can only be created by the resource certificate holder — the IP owner, not the user. In a leasing arrangement this means:

If you're announcing leased space from your own ASN: the lessor must create a ROA covering your ASN before you start announcing. Confirm this is in the leasing agreement and that it happens before go-live.
If the lessor is announcing on your behalf: the ROA covers their ASN. Confirm this explicitly — don't assume.
BYOIP on AWS, GCP, or Azure: cloud providers validate RPKI status during onboarding. A prefix that returns Invalid during validation stalls or blocks the onboarding process, and you can't retry quickly. RPKI status needs to be clean before you start the cloud provider's validation flow.

A leasing provider who can't clearly explain their ROA creation process for lessee ASNs is adding operational risk to your setup. It should be a standard part of onboarding, not an afterthought.

RPKI vs IRR — and why you need both

	IRR	RPKI
Cryptographic verification	No	Yes
Who can register	Anyone	Resource holder only
Data quality	Variable — stale/fraudulent entries common	Tied to RIR allocation
Filtering basis	Route objects	ROA validation states
Deployment	Widespread	Growing — near-complete at tier-1

IRR is the older system. Upstreams use route objects to build prefix filters. The weakness: no cryptographic enforcement. Anyone can register a route object for a prefix they don't own, and the databases have historically had significant stale and fraudulent data.

RPKI is cryptographically secured — a ROA can only be created by the actual resource holder.

They're complementary. Create RPKI ROAs as primary protection. Maintain IRR route objects in parallel for compatibility with networks that filter on IRR but haven't fully deployed ROV. If you're inheriting a prefix through a lease or transfer, check both — a valid ROA alongside an outdated IRR entry pointing to a previous ASN produces routing problems that take time to diagnose.

Minimum viable monitoring setup

RIPE Stat (stat.ripe.net) — BGP routing data, prefix announcements, AS path history, RPKI status. The routing history view catches announcements that appeared and disappeared, which is how most hijacking incidents present.
Cloudflare RPKI Validator (rpki.cloudflare.com) — quick ROA state check after creation or modification. Also useful for due diligence on a prefix before leasing it.
BGP.tools (bgp.tools) — fast prefix visibility and ASN data. Useful for checking what ASNs are currently announcing a given prefix.
Alerting — passive tooling isn't enough for production. You want real-time alerts when a prefix starts being announced from an unexpected ASN, not discovery after a service disruption.

Quick reference

Task	Where
Create ROA	my.ripe.net → RPKI
Check ROA state	rpki.cloudflare.com
BGP prefix visibility	stat.ripe.net, bgp.tools
BYOIP setup guide	ipbnb.com/blog
ROA creation walkthrough	ipbnb.com/help-center