Why BGP hijacks and route leaks are often confused
Route leaks and BGP hijacks are two types of BGP incidents that are often confused even by cybersecurity professionals. The confusion arises because the consequences of these incidents are largely similar: in both route leaks and BGP hijacks, traffic begins to follow an unintended route.
Both types of incidents can result in increased network latency (RTT), packet loss, interception, analysis, or manipulation of data, the redirection of traffic to malicious websites, as well as denial-of-service (DoS) conditions. Despite these similarities, route leaks and BGP hijacks are caused by different mechanisms and therefore require different mitigation approaches.
This situation can be compared to the difference between a dam breach and a tsunami. In both cases, a large volume of water is suddenly redirected along an unintended path, resulting in widespread destruction and flooding. However, even a non-specialist can understand that these two types of disasters have completely different causes and require very different safety measures.
What a BGP route leak is
A route leak is a type of BGP incident in which route announcements propagate beyond their intended scope, causing traffic to be redirected through the autonomous system (AS) responsible for the incident. Such situations may occur either intentionally or unintentionally, but in most cases they result from configuration errors.
A route leak most commonly occurs when a smaller AS passes routes learned from one of its providers to another of its providers, violating established routing policies. As a result, traffic that should not pass through that AS begins to flow through its infrastructure. This can lead to traffic interception, network congestion, and denial-of-service conditions.
The key reason route leaks occur is that BGP does not verify who is allowed to propagate which routes. If an autonomous system mistakenly advertises the routes it has learned beyond their intended scope, the protocol does nothing to prevent their further propagation.
What a BGP hijack is
A BGP hijack is a type of BGP incident in which an autonomous system (AS) announces an IP prefix that does not belong to it, causing traffic intended for the legitimate network to be redirected to an unauthorized AS. Such announcements may be either intentional or the result of a configuration error, but in both cases they lead to incorrect changes in traffic routing.
In practice, the AS responsible for the incident begins receiving traffic intended for other networks, creating significant risks to both security and service stability. BGP hijacks can lead to the leakage of sensitive data, the redirection of users to malicious resources, and disruptions to online services.
The key reason such incidents occur is the trust-based model of the BGP protocol: by default, routing participants accept each other’s announcements without built-in verification of their legitimacy.
The key difference between route leaks and BGP hijacks
Despite their similar consequences, route leaks and BGP hijacks arise from fundamentally different mechanisms.
In the case of a route leak, an autonomous system propagates the routes it has learned further than permitted by routing policy — typically due to errors in filter configuration or the lack thereof. It does not claim ownership of someone else’s address space but instead improperly passes legitimate routes to other ASes. As a result, traffic is routed through the autonomous system responsible for the incident.
BGP hijacking works differently. In this case, an AS announces an IP prefix it is not authorized to advertise, effectively claiming to be its origin. As a result, traffic is routed to the autonomous system responsible for the incident, since other network participants treat it as the legitimate owner of the prefix.
Thus, in the case of a route leak, the problem lies in the violation of route propagation rules, whereas in a BGP hijack it stems from the unauthorized announcement of address space itself. The way traffic is redirected also differs: in the first case it passes through the AS, making it a transit network, while in the second it is directed to the AS as the destination.
How to prevent and mitigate BGP hijacks and route leaks
To protect against BGP hijacks, the ROA (Route Origin Authorization) mechanism has been developed and is now widely used. Operating within the RPKI (Resource Public Key Infrastructure) framework, ROA records use cryptographic signatures that allow operators to verify whether a particular AS is authorized to announce a specific IP prefix. Thanks to the adoption of RPKI and ROA, the telecommunications industry has made significant progress in combating BGP hijacks.
However, ROA does not address the problem of route leaks. Preventing such incidents requires other mechanisms. The most important of these are BGP Roles and the OTC (Only To Customer) attribute, defined in RFC 9234. This standard allows operators to explicitly specify the type of relationship between neighboring ASes (for example, provider–customer) and use this information to filter routes propagated in the wrong direction.
The BGP Roles mechanism helps mitigate unintentional route leaks caused by configuration errors. However, it is not sufficient to counter deliberately created route leaks. Addressing those requires the deployment of ASPA (Autonomous System Provider Authorization) — a mechanism for cryptographically verifying relationships between autonomous systems based on RPKI.
Why BGP monitoring is critical for detecting route leaks and hijacks
While the adoption of RPKI and ROA has progressed significantly, the mechanisms of BGP Roles and ASPA are still in the early stages of deployment. As a result, continuous monitoring of routing and rapid response to incidents remain essential.
Qrator.Radar helps address this challenge. It is a BGP monitoring tool designed to detect network anomalies, including route leaks and BGP hijacks. Through detailed analysis and a notification system, Qrator.Radar enables operators to promptly identify incidents affecting their networks and minimize potential impact.
