After many unsuccessful attempts to secure the Border Gateway Protocol (BGP), we are now witness an increasing number of networks registering their prefixes in the Resource Public Key Infrastructure (RPKI).
While encouraging, the actual benefit of registering prefixes in the RPKI eventually depends on whether transit providers in the Internet enforce the RPKI’s contents, that is, configure their routers to drop invalid BGP routes (Route Origin Validation).
Recently, some major transit providers such as AT&T, KPN and Telia publicly announced that they started filtering BGP announcements that are invalid as per the RPKI. But are these the only ones? And does filtering invalid BGP announcements actually help in critical situations such as prefix hijacks?
In our recent research paper, we at the Massachusetts Institute of Technology (MIT) and the Center for Applied Internet Data Analysis (CAIDA), drill down into these issues. We first develop a method to determine whether networks enforce the RPKI’s contents and drop invalid routes, and study trends over time. We then study the effect of RPKI enforcement in critical situations where routes with conflicting origin ASes compete for visibility, such as in the case of route hijacks.
Detecting RPKI enforcement
For our study we used BGP data from RIPE RIS and RouteViews collectors and validated RPKI data gathered from the RIPE RPKI validator.
First, we studied whether networks peering with the route collectors do filter RPKI-invalid routes. We considered ASes that feed a full routing table to the collectors, and counted the number of RPKI-invalid routes they propagate.
Networks that feed a full routing table to the collectors are above the threshold in the top region of Figure 1. On the horizontal axis, we plotted the number of RPKI-invalid routes propagated by each network. Using a simple threshold, we can identify networks that propagate only a small number of RPKI-invalid routes (top left region), while still propagating routes to the rest of the Internet.
Read: Rise of the invalids
More networks enforce the RPKI’s contents
We used this method to carry out a longitudinal study and found that as of late April 2020, some 19% of ASes that send a full table to the route collectors filter RPKI-invalid announcements for IPv4 and 16% for IPv6.
More importantly, we saw a strong increase in the number of filtering networks: we found only less than 2% of networks filtering in early 2017, compared with some 20% in 2020 (Figure 2). More transit networks in the Internet enforce the RPKI’s contents, dropping invalid routes, boding well for increased routing security.
Needless to say, our approach can only test those networks that provide a full feed to public route collectors, some 300 ASes. However, these networks include many global transit providers and mid-sized networks: 187 transit and access ASes (of which 12 are Tier-1 ASes), 36 content providers, and 47 educational/non-profit networks. Hence, this set of ASes provides a reasonable approximation to study macroscopic filtering trends of major networks in the Internet.
We validated our approach using public announcements of six networks that started enforcing RPKI filtering: AT&T (AS7018), KPN (AS286), Seacom (AS37100), Workonline Communications (AS37271), Telia (AS1299) and NTT (AS2914). In early 2019, before these networks deployed RPKI filtering, they all propagated thousands of RPKI-invalid routes to our collectors. We measured a substantial decrease in the number of RPKI-invalid routes in line with the networks’ public announcements (Figure 3). This observation highlights the efficacy of a simple threshold-based method to detect whether a network filters RPKI-invalid prefixes.
We note, however, that none of these networks filter all RPKI-invalid BGP announcements. Indeed, on top of differences due to expected synchronization delays, some networks only partially implement RPKI filtering, a result of RIR RPKI policies, AS relationships and operational software issues; see our paper for more details.
Read: Is RPKI ready for the big screen?
RPKI enforcement in action: MOAS conflicts
But how much does the RPKI really help in situations of conflicting route announcements, like those caused by intentional or unintentional prefix hijacks? Would registering my prefixes in the RPKI help to limit the propagation of wrong routing information?
In our paper, we studied several such scenarios. Here, we present the results for a classical case of conflicting announcements: prefixes that are announced with two different origin ASes (MOAS).
Using detailed data (BGP snapshots every five minutes), we identified instances of MOAS conflicts, where one of the advertised origin ASes is valid as per the RPKI, and consequently the other origin AS is not. We then studied the visibility of the conflicting announcements: how many networks that peer with route collectors propagate a route to either of the prefixes? Since two MOAS announcements compete for visibility, typically one of the two announcements ‘wins’, reaching broad visibility, while the other one does not.
Figure 4 (positive dimension) shows what percentage of collectors saw a route to a MOAS prefix, where the blue bars show announcements with a valid origin AS, and the orange bars show their invalid counterparts. We can see that RPKI-valid announcements reach substantially higher levels of visibility compared to their invalid counterparts: RPKI wins in most cases. Registering prefixes in the RPKI indeed helps to limit the spread and visibility of conflicting announcements.
But is that really due to the RPKI? How far do MOAS announcements propagate if the respective prefix is not registered in the RPKI at all?
To contrast such ‘vanilla’ cases, we plot the visibility of MOAS prefixes that are not registered in the RPKI in the negative direction in Figure 4. Here, we’ve split each pair of MOAS conflicts into a stable and an unstable announcement, where the stable announcement was visible for a longer time period when compared to its unstable counterpart during our measurement window. Stable prefixes typically win the race for visibility, and unstable prefixes reach mostly low levels of visibility.
When contrasting the visibility of both ‘winning’ and ‘losing’ prefix announcements of RPKI-registered against unregistered prefixes, we see the impact of the RPKI — in both instances, RPKI-invalid prefixes reach distinctively lower levels of visibility. Even RPKI-invalid announcements that do reach somewhat high visibility, they barely exceed some 60%, whereas many unstable unregistered prefixes reach close to 70% visibility. This is in contrast to RPKI-valid or unregistered stable prefixes, which typically reach visibility of at or higher than 80%.
Thus, already as of today, RPKI registration evidently helps to limit the spread of invalid announcements, such as prefix hijacks. RPKI-invalid prefix announcements propagate less far both compared to their RPKI-valid counterparts, as well as compared to unregistered prefixes.
Looking ahead
Our results show that an increasing number of transit providers perform Route Origin Validation, that is, enforce the RPKI’s contents. Increasing filtering also translates to a direct benefit for networks that register their prefixes in the RPKI, since the RPKI limits the spread of conflicting announcements, such as prefix hijacks, substantially.
However, RPKI filtering is still far from universal, and more ISPs should drop invalid RPKI announcements, further increasing routing security and benefitting networks that opt to register their prefixes. Since major networks such as AT&T, KPN and Telia were able to do it, we hope more networks will follow them.
Cecilia Testart is a PhD student in the Advanced Network Architecture group at MIT.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.