BGP Route leaks vs BGP Hijacks

Since 2014 Qrator Labs has developed a BGP monitoring and analytics service called Qrator.Radar.  One of its main features is monitoring specific BGP anomalies that could result in an incident that we would further call either a BGP route leak or BGP hijack.

Both of them reroute traffic to third parties, compared to the no-anomaly state, but differently. Over the last few years, a lot of efforts have been invested in solving those issues, but there are still misunderstandings about what is what and how different tools are helping resolve different problems.

Our company started collecting the BGP relationships model a couple of years before RFC 7908 appeared, trying to define what a BGP route leak is.
The two main differences between those time of events were described as:

• Routes redirected through wrong ASNs/links (Route leaks), described as types 1-4 RFC 7908;
• Routes redirected to wrong ASNs (Hijack), described as types 5 and 6 RFC 7908.

During a BGP route leak, traffic destined to your network will most likely flow in an inefficient way, which could lead to increased network latency and packet loss. Nevertheless, it will reach your network almost certainly if there is no critical network congestion due to some reason (like the bad intention of a malfunctor).

During a BGP Hijack, traffic destined to your network is rerouted to a third party and stays there.

Furthermore, the mechanisms for creating those types of anomalies are different as well.
To create a route leak, you need to transfer a good route to an inappropriate neighbour ISP.
To create a hijack, you either need to announce a route with a sub prefix/more specific of a valid prefix (to attract all the traffic from ISPs that received such an announcement with whatever AS_PATH you like) or to create a route announcement with a third party prefix from your network.

Because mechanisms for creating routing anomalies vary, incident detection mechanisms and prevention/mitigation should be different.

To detect the cause of a route leak, you need to find out the relationship between each of the two connected operators and find out such BGP routes (from a BGP collector) which are breaking the Gao-Rexford formal model, for more information please refer to CAIDA’s “AS relationships”.
To detect hijacks, you need a ground truth about which prefixes belong to which ISPs, and in most cases when an unregistered pair of prefix ISP appears - create an alarm or take action.

To prevent/mitigate hijacks, there are two standard approaches within a single Prefix Origin Validation framework. You can register a Route object in your IRR or create a ROA object. Our team described the differences between these approaches during RIPE79. However, what is common - they both state which prefixes belong to which operators (by operators themselves) and try to block routes from an ISP with unregistered prefixes (by transit ISPs).

To prevent/mitigate pure route leaks, we take part in creating a BGP open policy. Another approach is peer locking - block routes with unexpected neighbours/ISPs in AS_PATH.

ASPA IETF draft stands a little aside from pure hijack/route leaks prevention because it is more about blocking bad AS_PATHs (route leaks cases and hijacks without/with bad AS_PATH manipulation).

ROA vs route leaks

So, is your network safe if you implement ROA signing and ROA filtering? No, because without ASPA or any equivalent, ROA by itself will not stop others from route leaking. We hope that now you see how complex this problem is, where separate approaches are needed to secure the basis of modern inter-domain routing - Border Gateway Protocol.

ROA signing vs ROA filtering

Another common misconception is connected with ROA. There are two parties in ROA algorithms: the signing party - operator, which provides ground truth about prefixes he owns; and there is a filtering party - transit operator, which filters out bad routes according to information provided by the signing party.

As a stub operator (meaning an AS with only one upstream provider), you are limited in the number of ways you could influence the number of filtering parties. The more of them there are, the more secure your prefixes will be (the fewer regions will be affected if a hijacker decides to attack your prefixes). If you decide to sign your prefixes, you can use an existing filtering infrastructure, which will only grow in the nearest future. Moreover, we encourage you to do exactly that anyway, meaning regardless of the size of the network behind your ASN.

This article would still end with a warning: current filtering infrastructure could still be imperfect, and in some cases, you cannot return your traffic from an affected region because of the chosen max length option and ROA filtering on the side of your ISP.