RPKI and BGP Hijacking: Securing the Internet’s Routing System

The entire Internet is based on a protocol that was created at a time when the network was a small club of mutually trusting institutions. BGP (Border Gateway Protocol) decides where packets travel between networks - and despite its critical role, has no built-in authentication. The result: routes can be “hijacked,” redirecting the traffic of entire organizations through the attacker’s network. This is one of the most underestimated infrastructure risks — and one of the few that can actually be systemically fixed today.

How cross-domain routing works

The Internet is a network of Autonomous Systems (Autonomous System, AS) - large networks (operators, clouds, large companies), each with its own number (ASN). BGP is the language these networks use to announce to each other: “I’ll get you to these address ranges (prefixes).” The router selects a route based on these announcements, preferring, among other things, shorter paths and more specific prefixes.

And herein lies the problem: BGP by default believes what its neighbors announce. There is no mechanism to check whether a given network has the right to advertise a given prefix. Trust is built into the design.

Two types of incidents: hijacking and route leak

Prefix hijacking. The network announces a prefix to which it is not entitled. Traffic directed to these addresses begins to flow there - either intentionally (theft, eavesdropping, redirection to fake services, certificate interception) or by mistake. The variant with a more specific prefix is particularly dangerous (e.g. the announcement /24 instead of someone else’s /16), because routers prefer a more precise route - so the hijacking “wins” globally.

Route leak The network broadcasts routes in a way that is inconsistent with business relationships (e.g., it allows traffic that it shouldn’t), causing traffic to flow along a suboptimal or undesirable path. This is usually a configuration error, but can result in global disruptions and congestion.

History has seen numerous such incidents - from traffic redirection of large websites, through transaction interception, to hours of unavailability - and many of them are simple mistakes, not intentional attacks. The effect for the victim is the same: its movement flows where it should not. As with attacks on critical infrastructure, the issue here is availability and integrity, not just confidentiality.

RPKI: restoring confidence in route origin

The answer is RPKI (Resource Public Key Infrastructure) - a cryptographic infrastructure that allows you to prove who has the right to announce a given prefix. It works in two steps:

1. ROA - Origin Authorization. The holder of the address resources creates in his RIR (in Europe: RIPE NCC) ROA (Route Origin Authorization) - a digitally signed record saying: “prefix X may be advertised by ASN Y (and with maximum length Z)”. This is a public, verifiable statement of who the rightful originator of the route is.

2. ROV - Router Origin Validation. Operators run ROV (Route Origin Validation): the router compares incoming BGP announcements with the ROA database and classifies them as:

• Valid - ad compliant with ROA (correct ASN, correct length),
• Invalid - contrary to ROA (e.g. a foreign ASN announces someone else’s prefix - classic hijacking),
• NotFound - no ROA for this prefix (not signed yet).

A router configured to discard Invalid routes will simply not accept the hijacked announcement - the attack stops working on those validating. The more networks ROV deploys, the less space there is for hijacking.

What RPKI doesn’t do - and what’s next

RPKI as it is currently widely implemented protects the origin of the route (who announces it), but not the entire path (which AS passes through). The attacker can therefore still try to manipulate the path in a more sophisticated way. The answer to this is the following mechanisms:

• BGPsec - cryptographic validation of the entire AS path; powerful but marginally implemented due to cost.
• ASPA (Autonomous System Provider Authorization) - a newer, lighter approach to detecting route leaks by describing allowed supplier-customer relationships.A practical guide is the MANRS (Mutually Agreed Norms for Routing Security) initiative, which collects minimum good practices: filtering, RPKI validation, anti-spoofing and coordination.

What to do in your organization

• Sign your prefixes (create ROA). If you have your own address and ASN resources, create an ROA in RIPE for all prefixes. This is a one-time step that protects your addresses from being hijacked by validating operators. It costs little and is the foundation.
• Enable ROV on your edge routers (if you are running your own routing) and discard Invalid routes.
• Choose carriers that validate. Unless you run your own BGP, choosing an ISP that uses RPKI is a real security decision - element provider ratings.
• Monitor your prefixes. Global routing analysis services let you detect when someone starts advertising your addresses. Early alarm shortens the duration of the incident.
• Include business continuity routing. For regulated entities (e.g. NIS2), connectivity resiliency is part of the responsibility - and a BGP hijack can cut off services as effectively as a DDoS attack.

Summary

BGP is built on trust that today’s internet no longer deserves - and that’s why routes can be hijacked and traffic can be redirected. RPKI, through signed ROA and ROV validation, restores the ability to check who has the right to advertise a given prefix and allows you to reject hijackings. This is one of the few infrastructure risks that can be realistically mitigated with specific, actionable steps: sign your prefixes, validate incoming routes, and choose operators that do the same.

If you want to assess the resiliency of your connectivity and network architecture - including routing and vendor dependencies - let’s talk. Security architecture consulting also covers the network and business continuity layer.

Frequently asked questions (FAQ)

Does RPKI completely eliminate BGP hijacking? Not fully. The widely implemented part of RPKI protects the origin of the route (who announces it) and effectively blocks classic hijackings on the networks it validates. However, it does not protect the entire AS path - newer mechanisms (BGPsec, ASPA) are used for this purpose. Still, prefix signing and validation is the single biggest security gain for routing today.

I don’t run my own BGP - is that even my problem? Yes, in two ways. First, if you have your own address resources and ASNs, you should create an ROA, even if the routing is managed by the carrier. Secondly, the choice of an ISP and transit provider that uses RPKI has a real impact on whether your traffic is protected - a criterion when evaluating a provider.

How much does RPKI implementation cost? Creating an ROA in RIR is usually free or very cheap and one-time - it’s mostly a matter of configuration, not purchase. Enabling ROV validation on your own routers requires operational work, but benefits from ready-made, mature tools. The barrier today is organizational, not technological.

How quickly will I detect that someone has hijacked my prefix? No monitoring - sometimes only after user reports. With global routing monitoring (public services monitoring BGP announcements), an alarm can occur within minutes of an unauthorized announcement, which drastically shortens the duration and effects of the incident.