What is BGP hijacking?
BGP hijacking is the illegitimate announcement of someone else's IP prefix in BGP, rerouting traffic. See real cases and how RPKI ROV and IRR filtering stop it.
Last updated:
BGP hijacking is when an autonomous system announces an IP prefix in BGP that it is not authorized to originate, causing part of the global traffic destined for that address range to be diverted to the wrong network. Classic BGP does not verify who actually owns an address block, so every announced prefix is accepted on trust by default. A hijack can result from a configuration mistake (a typo in an AS number or mask) or a deliberate attack used for interception, blackholing, or traffic redirection.
How a prefix hijack works
An attacker either originates someone else's prefix directly or announces a more specific prefix (a longer mask) than the legitimate owner. Routers select routes by the longest prefix match rule, so a /24 announcement always beats a legitimate /22 regardless of AS path length. That is why deaggregation is such an effective hijacking technique. Several common variants exist.
- Origin hijack: a foreign AS announces itself as the source of a prefix it has no right to.
- More-specific hijack: announcing a longer mask (e.g. /24 against a /22) that wins via longest prefix match.
- Path manipulation: forging the AS_PATH attribute so the announcement looks legitimate.
- Man-in-the-middle redirect: traffic is intercepted and then forwarded to the real destination so the attack stays hidden.
Real-world examples
In February 2008 Pakistan Telecom (AS17557), trying to block YouTube locally, announced 208.65.153.0/24 and, through a leak to its upstream PCCW, took the service offline globally for about two hours. In April 2018 attackers hijacked Amazon Route 53 DNS prefixes via AS10297 (eNet), redirecting MyEtherWallet users to a fake server and stealing cryptocurrency. The earlier 1997 incident known as AS7007 showed how deaggregation and a full-table leak can destabilise routing on a global scale. In each of these events there was no origin verification on the announcements.
How RPKI ROV and IRR filtering reduce the risk
Two complementary defence layers make hijacking harder. RPKI with Route Origin Validation lets a prefix holder publish a signed ROA stating the correct origin AS and the maximum prefix length. Routers mark routes valid, invalid, or unknown and drop the invalid ones. IRR-based filtering builds prefix lists from route and as-set objects in registries (RADb, RIPE, ARIN), so a neighbour only accepts the ranges you declared. Both methods are foundations of the MANRS initiative.
RPKI ROV protects the prefix origin but not the full AS path, so IRR filtering and ASPA remain necessary as further layers. In practice an operator should simultaneously publish correct ROAs for its own resources, drop invalid routes from neighbours, and keep IRR objects up to date.
BGP hijacking and AS202520 SkyPass
AS202520 SkyPass runs RPKI ROV and drops invalid routes on customer and partner sessions, and bases prefix filtering on IRR objects, so your announcements are not accidentally or maliciously overridden. We help IP transit and peering customers publish correct ROAs and maintain their as-set, while peering at THINX, TPIX, WRIX, and 1-IX plus PoPs in Warsaw and Wrocław shorten the path your traffic takes. Our public looking glass lets you check at any time how your prefixes are seen inside our network.
Frequently asked questions
How is BGP hijacking different from a route leak?
A hijack is announcing a prefix you are not authorized for (false origin or a longer mask). A route leak is propagating otherwise valid routes against relationship policy (e.g. transit between two upstreams), usually without impersonating the owner.
Does RPKI fully eliminate prefix hijacks?
No. RPKI ROV only validates the prefix origin, so it stops simple origin hijacks and out-of-maxLength deaggregation, but it does not protect the whole AS path. For full coverage it is combined with IRR filtering and ASPA.
Why does a /24 announcement beat a legitimate /22?
Routers apply the longest prefix match rule regardless of AS path length. The more-specific prefix takes precedence, which is why deaggregation is an effective way to capture traffic.
How do I detect if my prefix has been hijacked?
Monitor prefix visibility in looking glasses and collectors (RIPE RIS, RouteViews) and use alerting systems that flag an unexpected origin AS or new, more-specific announcements.