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 prefix as its own, and depending on how widely that announcement propagates, your traffic reroutes - to them.

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 - is the fix the industry has converged on. It's 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.

This guide explains how BGP hijacking works, what RPKI actually does to prevent it, how to create a Route Origin Authorization for your prefix, and what changes when the IP space you're working with is leased rather than owned.

What is RPKI?

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

The core mechanism is the Route Origin Authorization, or ROA. A ROA is a signed certificate that records three things: the IP prefix being protected, the ASN that is permitted to announce it, and the maximum prefix length that announcement can cover. That certificate is signed using a key chain that traces back to your Regional Internet Registry - RIPE NCC in the case of European and Middle Eastern operators - which acts as the cryptographic trust anchor.

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

• Valid: the prefix and ASN match a published ROA, and the prefix length is within the authorized maximum

• Invalid: a ROA exists for this prefix, but the originating ASN doesn't match, or the prefix length exceeds the authorized maximum

• Not Found: no ROA exists for this prefix

The critical point is what networks do with Invalid routes. Networks that have deployed RPKI Route Origin Validation (ROV) and configured it to drop Invalid routes will reject announcements that fail validation. This is what makes RPKI effective: not just the existence of ROAs, but the growing proportion of the internet's routing infrastructure that actively enforces them.

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. That's meaningful protection - particularly because the providers enforcing ROV carry the majority of global internet traffic - though it doesn't mean Invalid routes are blocked universally. Adoption across tier-2 and regional networks remains uneven.

RPKI protects against route origin hijacking specifically - an attacker falsely originating your prefix from an unauthorized ASN. It doesn't protect against route leak attacks (where a legitimate ASN redistributes routes it shouldn't) or path manipulation attacks. BGPsec addresses those, but it has no production deployment as of 2025. For the threat model that affects most operators - unauthorized prefix origination - RPKI is the right tool.

How BGP hijacking works

BGP - the Border Gateway Protocol - is the routing protocol that connects autonomous systems across the internet. Every autonomous system - each independently managed network - operates under an ASN, and BGP is how those networks exchange information about which IP prefixes 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 prefix 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. The attack is straightforward in principle: a malicious - or misconfigured - autonomous system announces a prefix it doesn't own. If the announcement propagates and is accepted by downstream routers, traffic destined for that prefix gets rerouted to the hijacker.

There are two common variants:

Exact-prefix hijacking. The attacker announces the same prefix 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 prefix with Invalid-route dropping in place.

A managed IPv4 leasing marketplace for holders

Monetize IPv4 Without Selling the Asset

Monetize your IPv4

Step-by-step ROA creation

Creating a ROA for your prefix in the RIPE region is done through the RIPE NCC portal. You need an active RIPE NCC membership (LIR status) and the prefix must be registered under your resource certificate in the RIPE database.

Here's the process:

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

Your resource certificate lists the IP prefixes assigned or allocated to your organization. Confirm the prefix you want to protect appears there before proceeding.

3. Create the ROA

Select the prefix, enter your ASN (the autonomous system that will announce the prefix), and set the maximum prefix length.

4. Set the maximum length carefully

This is the most consequential parameter. The maximum length field specifies the most-specific prefix that the authorized ASN is permitted to announce. If you set it incorrectly, you either leave part of your address space unprotected or create validation conflicts.

5. Publish and verify

For RIPE NCC, ROAs typically reach relying parties within 15-30 minutes of publication under normal conditions. Data plane effects - the point at which BGP actually reflects the new validation state - follow within roughly the same window. Individual validator implementations may take longer. Use a validator tool to confirm the ROA is being returned as Valid before treating the configuration as complete.

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

Common mistakes

Setting max-length to the full block and assuming you're covered for sub-announcements. 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 is one of the most common configuration errors and results in the operator accidentally invalidating their own routes.

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 prefix that will be announced from multiple ASNs. If your prefix 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 prefix-ASN combination. Announcements from an ASN not listed in any ROA for that prefix will return Invalid.

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.

Setting max-length to /32 (or /128 for IPv6) as a catch-all. This effectively disables the prefix-length protection that makes RPKI useful. A ROA with max-length /32 authorizes any more-specific announcement down to a single host address, which allows the exact class of more-specific hijacking that RPKI is designed to prevent.

RPKI + leased IPv4

RPKI introduces a specific complication when the IP space you're working with is leased rather than owned outright. Understanding it upfront avoids operational problems.

In the RIPE region, IP address resources are registered to the LIR or end-user that holds them in the RIPE database. ROAs are created by the resource holder - not by whoever is currently using or announcing the space. This means that in a leasing arrangement, the IP owner (lessor) holds the resource certificate and is the only party that can create or modify ROAs for the leased prefix.

What this means in practice:

If you're leasing space and announcing it from your own ASN, the lessor needs to create a ROA that lists your ASN as the authorized origin for the leased prefix. This is a routine part of a well-structured leasing agreement, but it requires the lessor to take action - and the ROA needs to be in place before you start announcing.

If the lessor 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.

When evaluating a leasing provider, ask specifically whether ROA creation for your ASN is included and what the process and timeline look like. A provider that can't clearly answer this question adds operational risk to your setup.

At IPbnb, ROA configuration and RPKI setup are part of the onboarding process for every lease. IP reputation and routing documentation - including RPKI status - are verified before a subnet is listed. If you're leasing through a platform that doesn't address this explicitly, it's worth raising before you sign.

BYOIP on cloud providers adds another layer. AWS, GCP, and Azure all have their own RPKI and LOA requirements during the BYOIP onboarding process. Prefix validation failures - including RPKI Invalid status - can block or significantly delay cloud provider acceptance. For a detailed walkthrough of BYOIP-specific requirements, see our guide on BYOIP with leased IPv4 on AWS, GCP, and Azure →

For a broader view of what IP block owners should verify and monitor to protect their leased space, the IPv4 leasing safety guide for block owners → covers reputation monitoring, abuse handling, and documentation hygiene alongside RPKI.

If you're looking for a subnet with clean routing history and RPKI documentation already in place, browse available IPv4 blocks on IPbnb →

Tools to monitor BGP

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

These are the tools worth knowing:

• RIPE Stat (stat.ripe.net)

The most comprehensive free tool for RIPE-region operators. Provides visibility into BGP routing data, prefix announcements, AS path information, and RPKI status for any prefix. 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.

• Cloudflare RPKI Validator (rpki.cloudflare.com)

Cloudflare's public RPKI validation tool shows the current ROA state for any prefix - Valid, Invalid, or Not Found - along with which ROAs are covering it and from which trust anchors. Useful for quick verification after creating or modifying a ROA, and for checking the RPKI status of a prefix before leasing or acquiring it.

• BGP.tools (bgp.tools)

A clean, fast tool for BGP prefix visibility, AS information, and routing data. Useful for checking what ASNs are announcing a given prefix and from where. Maintained by an independent operator; often faster to load than larger institutional tools.

• Cloudflare Radar (radar.cloudflare.com)

Broader BGP and internet health monitoring with RPKI deployment statistics and routing anomaly detection. Less useful for per-prefix monitoring, more useful for understanding the macro environment your routing decisions sit within.

• BGPmon-style alerting

Real-time BGP monitoring services - some commercial, some free at smaller scale - alert you when a prefix you're tracking starts being announced from a new ASN or when routing changes are detected. 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 monitoring setup for most operators: RIPE Stat for baseline visibility and historical data, Cloudflare's RPKI validator to confirm ROA status after any configuration change, and at least one alerting mechanism for unexpected announcement changes.

RPKI vs IRR filtering

Operators new to routing security often encounter both RPKI and IRR filtering and need to understand how they relate.

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 prefix. 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 prefix 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 the underlying registry data, which is maintained by voluntary self-reporting.

RPKI is cryptographically secured. ROAs are signed by the resource holder using keys that chain back to the RIR. A ROA for a prefix can only be created by whoever holds the corresponding resource certificate - which is tied to the actual IP allocation. This makes RPKI significantly more trustworthy than IRR as a source of routing authorization data.

The relationship between the two 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 - they provide the strongest protection and adoption among the largest transit providers is now near-complete. Maintain IRR route objects in parallel to ensure compatibility with networks that filter on IRR but haven't fully deployed RPKI ROV.

If you're inheriting a prefix - 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 outdated IRR route object pointing to a previous ASN, for instance) can cause routing issues that are non-obvious to diagnose.

Getting started

RPKI is one of those protocol-level improvements that is effective in proportion to how widely it's deployed. Every operator that creates ROAs and every network that enforces Invalid-route dropping makes the system more robust for everyone else.

The barrier to getting started is low. If you hold your resources in the RIPE NCC portal, you can create your first ROA today. The step-by-step ROA creation guide in our help center walks through the process from login to verification.

If you're working with leased IPv4 and need a provider that handles RPKI configuration as part of the setup rather than as an afterthought, browse available blocks on IPbnb - RPKI status and routing documentation are part of every listing.