RPKI for Beginners: How to Secure Your IP Blocks from BGP Hijacking

An autonomous system on the other side of the world simply announces your subnet as its own, and depending on how widely that announcement propagates, your traffic reroutes - to them. These events are known as BGP hijacking and route leaks, and RPKI is the system the industry built to stop them. Most of them are not even attacks: the single most common cause is an honest mistake - a network announcing a subnet it does not actually hold.

This isn't theoretical. BGP hijacking has significantly disrupted YouTube globally for approximately two hours, rerouted Amazon's DNS traffic to redirect users to a phishing site that drained cryptocurrency wallets, and caused major outages across cloud infrastructure. The attack surface is the internet's routing infrastructure itself, and the default trust model that has run BGP since 1989 offers no cryptographic protection against it.

RPKI - Resource Public Key Infrastructure - has been deployable in the RIPE region since 2011, adoption among major networks has accelerated significantly since 2020, and creating your first ROA takes less than ten minutes once you understand what you're doing. If you own, buy, sell, or lease IP blocks, RPKI now directly affects whether your addresses route, how far other networks trust them, and what they are worth.

This guide explains what RPKI is in plain terms, how BGP hijacking works, how to create a Route Origin Authorization for your subnet, how to validate the routes you receive, and what changes when the IP space you're working with is leased rather than owned. Throughout, we use IP owners (holders) and IP renters (tenants) - the two sides of every lease.

What is RPKI?

RPKI stands for Resource Public Key Infrastructure. It's a cryptographic framework that lets IP owners prove - verifiably, not just by assertion - that a specific autonomous system is authorized to originate a specific subnet in BGP.

It works as a chain of trust. IANA, the top authority for all IP addresses, delegates blocks to the five Regional Internet Registries: ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC. Each RIR then issues a digital certificate to the IP owner holding a block. That certificate is cryptographic proof of holdership. It cannot be faked, and anyone on the internet can check it.

Think of it like a land registry. The registry does not physically stop someone from claiming they own a house. It lets any interested party look at the official record and see who the real owner is. RPKI does the same for IP blocks.

What is a ROA (Route Origin Authorization)?

The certificate on its own does not do much. The useful part is what the IP owner creates with it: a Route Origin Authorization, or ROA. In plain terms, a ROA says: "this subnet may be announced by this network, up to this size."

It records three things:

• the subnet being protected (sometimes called the "prefix"),

• the ASN permitted to announce it, and

• the maximum prefix length - the smallest, most specific sub-block that ASN is allowed to announce.

The ROA is signed using a key chain that traces back to the Regional Internet Registry - RIPE NCC in the case of European and Middle Eastern IP owners - which acts as the cryptographic trust anchor. Once published, a ROA is visible to everyone: any operator can download it and use it to decide whether to trust a route. For the technically precise reader, the current ROA format is defined in RFC 9582, published in 2024.

RPKI validation states: Valid, Invalid, NotFound

When a router receives a BGP route announcement, RPKI validation checks it against the published ROAs. The result is one of three states.

The practical consequence is blunt: an Invalid result gets your traffic dropped by every network that enforces RPKI. A wrong ROA is worse than no ROA at all.

How routers use RPKI: validators and ROV

Routers do not perform the heavy cryptographic work themselves. An operator runs a piece of software called a validator (also called "relying party" software). The validator downloads every ROA from all five RIRs, checks all the signatures, and builds a clean, verified list.

The router then connects to the validator over a simple protocol called RTR - RPKI-to-Router - and pulls that verified list. From that point on, it can label every incoming route Valid, Invalid, or NotFound and act accordingly. This process of checking routes against ROAs is called Route Origin Validation, or ROV.

So RPKI has two halves, and both must happen:

1. IP owners sign their subnets by creating ROAs.

2. Network operators validate incoming routes with ROV.

A ROA only protects you if other networks are validating. Validation only helps if IP owners have created ROAs. The system gets stronger as more people take part.

RPKI protects against route origin hijacking specifically - an attacker falsely originating your subnet from an unauthorized ASN. It doesn't protect against route leaks, where a legitimate ASN redistributes routes it shouldn't. We come back to what's being built for that at the end of this guide.

How BGP hijacking works

BGP - the Border Gateway Protocol - is the routing protocol that connects autonomous systems across the internet. Every autonomous system operates under an ASN, and BGP is how those networks exchange information about which subnets they can reach and through which paths.

The design premise of BGP is that participating networks tell the truth. There is no built-in cryptographic mechanism to verify that the ASN announcing a subnet is actually authorized to do so. When AS64496 announces that it can reach 203.0.113.0/24, the internet's routers have no inherent way to verify whether AS64496 actually holds that address space.

BGP hijacking exploits this gap. A malicious - or misconfigured - autonomous system announces a subnet it doesn't own. If the announcement propagates and is accepted by downstream routers, traffic destined for that subnet gets rerouted to the hijacker.

There are two common variants:

Exact-prefix hijacking. The attacker announces the same subnet as the legitimate holder - say, 203.0.113.0/24. BGP route selection then depends on AS path length and local routing policies. The attack may or may not outcompete the legitimate announcement depending on network topology.

More-specific hijacking. The attacker announces a more-specific prefix - 203.0.113.0/25 - derived from the victim's block. Because BGP always prefers more-specific routes, this variant is more reliable from the attacker's perspective. Traffic for the hijacked /25 will route to the attacker wherever the more-specific announcement is accepted.

The consequences vary. In some cases the hijacker is simply blackholing traffic - causing an outage for the victim. In more targeted attacks, traffic is intercepted, inspected or modified, and reforwarded - making the hijack invisible to end users while allowing passive surveillance or active manipulation in transit.

Misconfiguration accounts for a meaningful share of BGP hijacking incidents. A network engineer makes an error in a route announcement, and the result looks identical to an intentional attack from the outside. The impact is the same regardless of intent.

The 2008 Pakistan Telecom incident - where a misconfigured more-specific /24 announcement of YouTube's /22 propagated globally via PCCW, significantly disrupting access to YouTube for approximately two hours - is the most cited example. The 2018 attack on Amazon Route 53 DNS service, which hijacked DNS queries for myetherwallet.com and redirected users to an attacker-controlled phishing site that drained approximately $150,000 in Ethereum from users who logged in, is a more deliberate one. Neither would have succeeded against a properly RPKI-validated subnet with Invalid-route dropping in place.

Why RPKI matters in 2026

For years RPKI was optional and rarely used. That has changed.

As of May 2024, all but one of the internet's largest transit-free (tier-1) providers reject RPKI Invalid routes - a milestone confirmed by MANRS and NIST's RPKI Monitor. At that enforcement level, an RPKI Invalid announcement's propagation is reduced by one-half to two-thirds compared to a route with no RPKI coverage.

On the signing side, the NIST RPKI Monitor puts ROA coverage of the global routing table at roughly 54% of IPv4 and IPv6 subnets, Kentik estimates around 74% of internet traffic now goes to destinations that are covered, and APNIC put world-average coverage at about 60% at APRICOT 2026. [figures to re-verify before publish]

Enforcement is still concentrated among the large carriers, and adoption across tier-2 and regional networks remains uneven. But the direction is clear, and it has three consequences for anyone working with IP blocks:

More providers now require ROAs. A growing number of upstream providers and internet exchanges will not accept your announcements - and increasingly will not do business with you - unless your subnets are properly signed.

The cloud requires it. If you bring your own IP block into AWS, Google Cloud, or Azure, a correct ROA authorizing the cloud provider's ASN is mandatory. No ROA, no service.

It affects what a subnet is worth. A block with clean, correct RPKI records deploys faster and is trusted more. For IP owners looking to monetize unused IPv4 space, and for buyers doing due diligence before they buy IPv4 blocks, RPKI status now sits alongside abuse history and reputation as a standard check.

How to set up RPKI: for IP owners

You have two models to choose from before you start:

Hosted RPKI - your RIR runs the cryptographic system for you, and you create ROAs by logging into its portal (the RIPE NCC portal, ARIN Online, MyAPNIC, and so on). This is the right choice for almost everyone.

Delegated RPKI - you run your own certificate authority, for example with software called Krill. This suits only large operators that need heavy automation.

The walkthrough below is hosted RPKI in the RIPE region. You need an active RIPE NCC membership (LIR status), and the subnet must be registered under your resource certificate in the RIPE database.

1. Log in to the RIPE NCC portal. Go to my.ripe.net and log in with your LIR credentials. Navigate to the RPKI section under your dashboard.

2. Locate your resource certificate. It lists the IP blocks assigned or allocated to your organization. Confirm the subnet you want to protect appears there before proceeding.

3. Create the ROA. Select the subnet, enter the ASN that will announce it, and set the maximum prefix length.

4. Set the maximum length carefully. This is the most consequential parameter, and it is where nearly every self-inflicted outage in RPKI comes from. The rule: match your real announcements exactly, and no looser. Set it too tightly and your own more-specific announcements turn Invalid. Set it too loosely and you leave a gap an attacker can use - a more-specific sub-block that still passes validation. Both failure modes are covered in the next section.

5. Publish and verify. For RIPE NCC, ROAs typically reach relying parties within 15-30 minutes of publication under normal conditions. Data plane effects follow within roughly the same window; individual validator implementations may take longer. Confirm the ROA is being returned as Valid on bgp.tools before treating the configuration as complete.

For a detailed walkthrough with screenshots and field-by-field guidance, see our ROA creation guide in the help center →

Common mistakes

Max-length too tight: setting it to the full block when you announce sub-blocks. If you hold a /22 and plan to announce it as four /24s, your ROA max-length needs to be /24 - not /22. A ROA covering a /22 with max-length /22 will mark any /24 sub-announcement as Invalid, even from your own ASN. This results in the IP owner accidentally invalidating their own routes.

Max-length too loose: setting it wider than anything you actually announce. The mirror image, and just as damaging. If you hold a /22, announce it as a single /22, and set max-length to /24 "just in case," you have authorized an attacker to announce a /24 out of your block - and it will validate as Valid. Every bit of headroom in the max-length field is headroom handed to a hijacker.

Setting max-length to /32 (or /128 for IPv6) as a catch-all. The extreme version of the same error. It authorizes any more-specific announcement down to a single host address - exactly the class of hijacking RPKI is designed to prevent.

Creating a ROA and not verifying propagation. A ROA that exists in the RIPE NCC portal but hasn't propagated to relying parties provides no protection. Always validate using an external tool after creation, not just the portal's own confirmation.

Using a single ROA for a subnet announced from multiple ASNs. If your subnet will be announced from more than one ASN - for redundancy, for BYOIP on a cloud provider, or for multi-homed setups - you need a separate ROA for each authorized ASN. A ROA covers exactly one subnet-ASN combination.

Forgetting to update ROAs when the announcing ASN changes. If you change upstream providers, migrate to a new ASN, or onboard to a cloud provider's BYOIP program, the ROA needs updating before the new announcement goes live. An Invalid announcement from your own infrastructure is an outage.

Letting a ROA quietly expire. Automate renewals wherever your RIR allows it. An expired ROA does not fail gracefully - it changes your routing state without anyone touching a router.

RPKI when you lease IPv4: who creates the ROA?

This is where most people get confused, so it is worth being exact.

Only the IP owner - the party the RIR recognizes as holding the block - can create or change a ROA. The IP renter cannot. ROAs are created by the resource holder, not by whoever is currently using or announcing the space. So when a subnet is leased, the ROA has to be created to authorize the renter's origin ASN - because the renter is the one who will actually announce the block.

A trustworthy marketplace or broker manages this coordination as part of the lease, together with the LOA and the route object. If you lease IPv4 addresses and this is left entirely to you to figure out, treat that as a warning sign.

On IPbnb, ROA coordination is part of every lease: the holder publishes the ROA for the tenant's ASN before the block is handed over, together with the LOA and route object. It does not replace your own checks - you should still confirm the ROA status in bgp.tools before announcing - but it removes the guesswork.

One nuance: if the IP owner is announcing on your behalf - a common arrangement for hosted or managed leasing - the ROA will cover their ASN and you don't need to manage it directly. Confirm this is the case before assuming it.

BYOIP on cloud providers adds another layer. AWS, GCP, and Azure all have their own RPKI and LOA requirements during onboarding. Subnet validation failures - including RPKI Invalid status - can block or significantly delay cloud provider acceptance.

How to set up RPKI: for network operators

Signing your own subnets protects them only to the extent that other networks check. If you run BGP - which includes most IP renters announcing their own blocks - you should be validating too.

Choosing an RPKI validator

Then:

Install at least two validators. If a router loses contact with all of its validators, every route silently becomes NotFound and filtering stops. A second validator protects against that.

Accept each RIR's trust anchor. ARIN's requires agreeing to its Relying Party Agreement, which is a separate step from the others.

Point your routers at the validators over RTR, and set policy to reject Invalid while accepting Valid and NotFound. Do not reject NotFound - a large share of subnets are still unsigned, and dropping them would cut you off from much of the internet.

Treat RPKI as one layer, not the whole defense. RPKI checks who originates a route, not the full path it travels. Combine it with prefix filters, AS-path filters, and bogon filtering.

Tools to monitor BGP

Creating a ROA is the first step. Ongoing monitoring is what tells you whether your subnet is being announced correctly, whether any unauthorized announcements have appeared, and whether your RPKI configuration is functioning as expected.

RIPEstat (stat.ripe.net) - the most comprehensive free tool for RIPE-region operators. BGP routing data, announcements, AS path information, and RPKI status for any subnet. The routing history view is particularly useful for detecting anomalous announcements that appeared and disappeared - which is often how hijacking incidents present. No account required.

bgp.tools - clean and fast, for subnet visibility, AS information, and routing data. The quickest way to check which ASNs are announcing a given subnet and from where, and to confirm a new ROA is being returned as Valid.

Cloudflare RPKI Validator (rpki.cloudflare.com) - shows the current ROA state for any subnet, along with which ROAs cover it and from which trust anchors. Useful before leasing or acquiring a block. Its companion, isbgpsafeyet.com, tells you whether your own upstreams actually drop Invalids.

Cloudflare Radar (radar.cloudflare.com) - broader BGP and internet health monitoring with RPKI deployment statistics and routing anomaly detection. Less useful per-subnet, more useful for the macro picture.

NIST RPKI Monitor - the reference source for global RPKI coverage and enforcement statistics, and a sanity check on where your subnets sit relative to the rest of the table.

BGPalerter and BGPmon-style alerting - real-time monitoring that tells you when a subnet you're tracking starts being announced from a new ASN, or when your announcements and your ROAs drift out of sync. For production environments, passive tooling isn't sufficient; you want alerting that catches anomalies within minutes, not after you notice a service disruption.

The minimum viable setup: RIPEstat for baseline visibility and history, bgp.tools to confirm ROA status after any change, and at least one alerting mechanism for unexpected announcements.

RPKI vs IRR filtering

IRR - Internet Routing Registry - is the older system. Networks register route objects in IRR databases (RIPE's IRR, RADB, ARIN's IRR, and others) describing which ASN is authorized to announce which subnet. Upstream providers and peers use those route objects to build prefix filters, accepting only announcements that match registered route objects.

The structural weakness of IRR is that it's not cryptographically secured. Anyone can register a route object for a subnet they don't own, and IRR databases have historically had significant amounts of stale, inaccurate, or fraudulent data. The filtering it provides depends entirely on the accuracy of registry data maintained by voluntary self-reporting.

RPKI is cryptographically secured. ROAs are signed by the resource holder using keys that chain back to the RIR, and a ROA can only be created by whoever holds the corresponding resource certificate. That makes RPKI significantly more trustworthy than IRR as a source of routing authorization data.

The relationship is complementary rather than competitive. Many networks use both: IRR route objects for compatibility with older filtering implementations, and RPKI ROAs for cryptographic validation where enforced. Maintaining both is not redundant - they serve different parts of the filtering ecosystem.

For RIPE-region operators, the practical recommendation is to create RPKI ROAs first, then maintain IRR route objects in parallel for networks that filter on IRR but haven't fully deployed ROV. If you're inheriting a subnet - through a lease, acquisition, or transfer - check both its RPKI status and its IRR registrations as part of due diligence. An inconsistency between them (a valid ROA but an outdated IRR route object pointing to a previous ASN, for instance) causes routing issues that are non-obvious to diagnose.

What comes next: ASPA

RPKI validates the origin of a route, not the full path it takes. That leaves the route leak gap: the origin is correct, but traffic travels through networks it should not.

The emerging answer is ASPA - Autonomous System Provider Authorization - a new RPKI object in which a network signs a statement listing its approved upstream providers.

A reality check, because accuracy matters here: as of 2026 ASPA is still being finalized at the IETF, is not yet a published standard, and real-world use remains very small. BGPsec, the older answer to the same problem, has no production deployment either. ASPA is worth watching, not deploying. For now, correct ROAs and active validation are what protect your subnets. [status to re-verify before publish]

RPKI checklist for IP holders

1. Confirm every subnet you hold appears under your resource certificate in your RIR portal.

2. Create a ROA for each subnet, using hosted RPKI unless you have a specific reason not to.

3. Set max-length to match your real announcements exactly - never looser, never tighter.

4. Create a separate ROA for every ASN authorized to announce the subnet (redundancy, multi-homing, BYOIP).

5. Verify propagation externally on bgp.tools or RIPEstat - not just in your RIR portal.

6. Keep the IRR route object consistent with the ROA.

7. Set up alerting (BGPalerter or equivalent) for announcements from unexpected ASNs and for ROA drift.

8. Automate renewals, and update ROAs before any ASN change - not after.

The bottom line

RPKI is effective in proportion to how widely it's deployed. Every IP owner who creates ROAs and every network that enforces Invalid-route dropping makes the system more robust for everyone else.

It has moved from "nice to have" to "expected." For IP owners, a correct ROA protects your subnets from hijacks and keeps them trusted and valuable. For IP renters, confirming that a leased block is properly signed is the difference between addresses that route cleanly and addresses that get dropped. Setting it up takes minutes. The care goes into one detail: getting the maximum prefix length right.

If you own or lease IP blocks and are not certain your RPKI records are correct, that is the first thing to check. Increasingly, the rest of the internet is already checking for you.

Clean IPv4, ready to deploy

Lease Clean IPv4 Fast With Zero Platform Fees

Start leasing

FAQ

What is RPKI in simple terms?

RPKI (Resource Public Key Infrastructure) is a way to prove cryptographically who is allowed to announce a given IP block on the internet. Each Regional Internet Registry issues a digital certificate to the holder of a block, and the holder uses it to sign statements about who may route that space. Think of it as a land registry for IP addresses: it does not physically stop a false claim, but it lets anyone check the official record.

What is a ROA (Route Origin Authorization)?

A ROA is a small, digitally signed statement created by an IP holder. It records three things: the subnet, the ASN authorized to announce it, and the maximum prefix length that ASN may announce. Once published, any network can download it and use it to decide whether to trust a route.

Can an IP renter create a ROA for a leased subnet?

No. Only the IP owner - the party the RIR recognizes as holding the block - can create or modify a ROA. In a lease, the owner must publish a ROA authorizing the renter's origin ASN before the renter starts announcing. If the renter's ASN changes or the lease ends, the owner updates or removes it.

What happens if a route is RPKI Invalid?

An Invalid route is rejected by every network that enforces RPKI, including all but one of the internet's tier-1 transit providers. In practice that means your traffic is dropped. Invalid usually indicates either a hijack or - more often - a misconfiguration, most commonly a max-length that does not match what you actually announce. A wrong ROA is worse than no ROA at all.

Do AWS, Google Cloud, and Azure require RPKI for BYOIP?

Yes. All three require a correct ROA authorizing the cloud provider's ASN as part of BYOIP onboarding, alongside a Letter of Authorization. A subnet with Invalid RPKI status will be rejected or significantly delayed. If you are leasing the space, the ROA must be created by the IP owner before you start the onboarding process.