RPKI - A Dashboard for BGP Operators

1. Introduction

In the past years it has been shown over and over again that errors made in Border Gateway Protocol (BGP) configurations can lead to large portions of the Internet being unavailable. The most well known example is the outage of Youtube due to a Pakistan Telecom configuration error in 2008. Resource Public Key Infrastructure (RPKI) is a potential solution to this issue. However, in its current form RPKI cannot be used as a source for making routing decisions due to the low adoption rate and large amount of configuration errors.

2. Dashboard

SURFnet proposed to build a dashboard for BGP operators and Regional Internet Registries (RIRs) that shows daily statistics about the cause of invalids, origin of invalids and changes over time on a per Autonomous System (AS), per RIR and world wide basis.
By gathering data on a day to day basis and visualising this data using Google Charts, we try to provide insight into the origin of invalid prefixes and the mistakes that are being made while configuring RPKI. RPKI live data is presented on SURFnet's RPKI Dashboard . Hopefully the dashboard will help to improve the rate of RPKI adoption and improve the correctness of configurations by providing insight into what mistakes are being made.

3. Data Gathering and Presentation

In order to reliably determine which ASes are advertising invalid routes, it is relevant to see which routes are in the routing table and how incoming BGP routes are validated by a router. To do this the tool simulates a real-world BGP router. Information from the routing table is stored in a database. Using this data, statistics can be generated at a later stage.

3.1. Routing Table

The Routing Information Service (RIS) dump provided by RIPE NCC is used as
the source for the routing table. This dump provides the ”IPv4/IPv6 Address to Origin AS Mapping”. It provides a source of all active BGP prefixes that are advertised on the Internet. Each daily dump is imported to a different SQL table, allowing for easy access to historical data.

3.2. Validated ROA Payloads

After the routing information has been imported into the database it is processed. The cryptographically validated Route Authorisations (ROA) Payloads are imported from a running instance of the RIPE NCC RPKI validator and stored in a separate SQL table on a daily basis using the CSV export function of the validator. The validity state of each route is then determined by running a validator script specially built for the dashboard. The script queries the stored routing table for prefixes that match a certain ROA to validate the prefixes.

3.3. Region

Once the validity state has been determined, an RIR is associated with the route by comparing the first bits of the prefix with those defined in the list of IPv4/6 IP-address allocations provided by IANA .  Note that these allocations are not 100% accurate but should give a good indication. A logical overview of the complete process is shown in Figure 1 below.

Figure 1: Logical overview of the complete process

3.4. Generating Statistics

The statistics are generated and shown on a web dashboard using PHP and the Google Charts JavaScript API. The values for all the charts are queried from the database using PHP. The JavaScript charts provide a convenient way to present the graphs in an interactive way.

Different types of statistics are shown on the dashboard to give a good insight into the RPKI statistics. Global RPKI statistics show the number of valid and invalid routes as well as the distribution of causes of routes being invalid (see Figure 2 below).  

Figure 2: Global distribution of RPKI prefixes

Trends for RPKI usage are also shown, giving details about how much the usage of RPKI has increased or decreased over time. The reason for a prefix being invalid is also stored. These reasons are visible in the trends and can be used to determine why a prefix is invalid (see Figure 3 below). The dashboard could for instance point out that a certain reason occurs more than another. More research is needed to reliably determine if an invalid prefix is hijacked or a result of a configuration error in the ROA or routing policy.

Figure 3: Causes of invalids

As some charts require a large amount of database queries, all the dynamic PHP pages are cached into a static HTML page, which is then served to the user. The only pages that are not cached are the statistics pages for each AS, as it would take a considerable amount of time to generate them all and most of the AS pages will likely not be viewed daily.

The code for the data collection and statistics generation scripts can be found at https://github.com/remydb/RPKI-Dashboard .

4. Conclusion

Current statistics (22 July 2013) generated by the RPKI Dashboard , show that RPKI is mainly being adopted in the RIPE NCC  (5.89%) and the LACNIC service region (11.7%) region. All other regions have an adoption rate below 0.5%. There are 14,894 prefixes in the routing table covered by ROAs, of which 2,575 prefixes are invalid. Three ASes are responsible for announcing approximately 40% of the invalid routes, AS10620 (469 invalids), AS6147 (405 invalids) and, AS23752 (120 invalids). The most common reason for invalid routes is a non-matching AS number (711 invalids). This means that there is at least one ROA that covers the prefix but none of the covering ROAs has an AS number that matches the AS that is originating the prefix.

Figure 4: Number of ASes that announce the most validated prefixes

The root cause of most errors remains uncertain, we cannot be sure that all of the invalid routes we encounter are caused by configuration errors. However, the statistics give a good idea of common causes for prefixes being invalid. A common reason is not entering the optional "Max Length" field. When this field is left blank, only the exact same prefix length is accepted. All more specific announcements are invalid, even if it is announced from the authorised AS. Another common reason is configuring ROAs for AS "X" while announcing the prefixes from AS "Y". Although this looks like a hijacking attempt, we've concluded that in most cases this is a configuration error, because both AS numbers are held by the same organisation.

The rate of RPKI adoption is still low and a lot of configuration errors occur without being corrected. The dashboard is able to assist BGP operators by giving them detailed insight in the validation state of their own and global prefixes. The dashboard should also help to improve the rate of RPKI adoption and improve the correctness of configurations by providing insight into what the reasons are for invalid prefixes.

References

This article is a summary of the master thesis from Javy de Koning and Remy de Boer "BGP Origin Validation (RPKI)". This master thesis is done in close cooperation with SURFnet. SURFnet proposed to research the origin of invalid routes, and analysing common mistakes that lead to invalid routes.

About the Authors

Javy and Remy are both finishing their master's degree in System and Network Engineering (SNE) at the University of Amsterdam. SNE is the only academic Master's programme in The Netherlands that focuses on understanding, developing and maintaining complex IT systems and networks.

SURFnet is the Dutch Research and Education network. SURFnet ensures that researchers, instructors, and students can work together simply and effectively with the aid of ICT. It therefore promotes, develops, and operates a trusted, connecting ICT infrastructure that facilitates optimum use of the possibilities offered by ICT. SURFnet is thus the driving force behind ICT-based innovation in higher education and research in the Netherlands.