Matthias Wählisch

One Day in the Life of RPKI

Matthias Wählisch
Contributors: Fabian Holler, Thomas Schmidt

6 min read

0 You have liked this article 0 times.
2

In this article, we report about a one-day measurement of the RPKI and BGP infrastructure.


We monitor BGP Updates and analyse the outcome of the prefix origin validation process, i.e., is the origin AS authorised to announce the IP prefix with respect to the existing Route Origin Authorisations (ROAs) in the currently deployed RPKI infrastructure. This measurement gives first insights into what a router experiences when enabling RPKI-based verification, and may also help to expose misleading ROA configurations.

Short Background

BGP routers receive cryptographically validated ROA data from RTR Caches/Servers. Using this information (prefix, mask length and maximum length, origin AS number) a router is able to verify the prefix origin AS announced via BGP Updates. The outcome of the BGP prefix origin validation is either VALID, INVALID, or NOT FOUND/UKNOWN. Based on this, the router may apply different local policies to the route (e.g., accept or reject the route update).

Measurement Setup

We performed a one-day measurement on 13 December 2011. The measurement setup is as follows: BGP Updates were received via BGPmon live data . BGPmon provides a real-time BGP Update stream. It maintains nine direct peerings (including SWISSCOM and Tiscali) as well as indirect peerings via the RouteViews project . The indirect peering includes routing updates from more than 100 peers such as AOL, Hurricane Electric, and AT&T.

From each BGP Update, IP prefix, mask length, and AS path have been extracted and passed on to the RTRlib . The RTRlib validates prefixes according to the current ROA data set received from an RTR Server. We established a plain TCP connection to rpki.realmv6.org:4242. This RTR Server runs rcynic + rtr-origin and considers the trust anchors AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC.

Results

Overall, during the measurement we received more than 3,201,253 IPv4/IPv6 prefix updates. Most of them (98%) have been evaluated as NOT_FOUND, i.e., there is no ROA available for the announced prefix. This is not surprising as only the minority of prefixes has been added to the RPKI infrastructure until now.

The following figure shows the overall number of prefix verfications over time and the outcome with respect to valid and invalid prefix origin ASes.

Validation Statistic

Aggregated Results

In the second step, we focused on the verification outcome per unique prefix. That means, a prefix that is announced multiple times will be counted as valid or invalid at most once. Note, we consider state changes (e.g., from valid to invalid) as two separate events.

2,709 unique prefixes have been evaluated as valid and 4,839 unique prefixes as invalid.

Invalid Prefix Originations in Detail

The RPKI infrastructure may help to protect from the illegitimate announcement of more specific prefixes. Regarding the invalid unique prefixes, only 8% have been announced by a correct origin AS but with an incorrect netmask (i.e., prefixes have been announced with a longer netmask as defined by the max length in the ROA).

For the remaining 92% of the invalid unique prefixes, there exists at least one ROA in which the BGP origin AS does not match any of the ROA ASes. This may have several reasons. If all ROAs have been configured correctly, the validation outcome indicates a prefix hijack because none of the authorised ASes originates the IP prefix. However, the current state of deployment of the RPKI infrastructure also includes incomplete configurations of the ROAs.

Looking into the case of incorrect origin ASes in more detail, we found the following: Approximately 50% of the invalid prefix announcements concerns the (super-)block 12.0.0.0/8. There is only one ROA that covers this entire address space:

 ASN     Prefix        Maximum Length    Trust Anchor
 
7018 12.0.0.0/8 9 ARIN Test Lab

Only AS 7018 (ATT-Internet4) has been authorised to announce 12.0.0.0/8 and corresponding sub-prefixes. However, more than 2,400 sub-prefixes seem to belong to different ASes. This is not a problem as the ROA is part of a test trust anchor. However, it illustrates two things: First, the RTR Server should select the right trust anchors, otherwise the router will be fed with cryptographically valid but doubtful data. Second, any creator of a ROA must ensure that legitimate sub-allocations have been authorised as well. Any ISP that delegates IP prefixes to customers must ensure that customers have been authorised to announce their prefixes before the ISP creates a ROA for the covering prefix. In this case, a ROA might also be created for

 ASN                                                 Prefix
 
27487 (FHLBNY-AS - FEDERAL HOME LOAN BANK OF NY) 12.0.19.0/24

The same should be applied when the sub-prefix will be announced by another AS of the company, e.g.:

 ASN                                                  Prefix
 
2386 (INS-AS - AT&T Data Communications Services) 12.1.216.0/24

Note, the measurement has been performed at 13 December 2011. The RPKI data set is still under development towards a complete, correct view. The AT&T case is just an example and the operators continuously refine their data.

Further analysis of all invalid prefixes reveals that in the majority of cases at least one ROA Origin is part of the announced AS path. It is usually only one hop away from the origin AS. These peerings are customer-to-provider relations. This again indicates that the corresponding ISPs did not authorise customers to announce their prefixes.

Take-away

The main conclusion is: Make sure that you consider all legitimate prefix origins before you create a ROA. Once there is a valid ROA within the RPKI infrastructure that covers the announced prefix and either the origin AS or the prefix length does not match the ROA entry, the BGP prefix update will be considered as invalid.

To sum up:

  1. Start and create your ROAs!
  2. Authorise all of your Autonomous Systems that originate the ROA prefix.
  3. Before you create a ROA for an IP block where parts are announced by customers, ensure that a valid ROA exists for this sub-prefix and customer AS.
  4. The Maximum Length in the ROA should cover the most specific prefix that you authorise to announce.

Further References:

Acknowledgments

We would like to thank Kotikalapudi Sriram for discussions and pointing us to the RPKI-Based Origin Validation Operation document.

0 You have liked this article 0 times.
2

You may also like

View more

About the author

Matthias Wählisch Based in Dresden, Germany

Matthias is a full professor and holds the Chair of Distributed and Networked Systems at the Faculty of Computer Science at TU Dresden. He is also a Research Fellow of the Barkhausen Institut. His research and teaching focus is on efficient, reliable, and secure Internet communication. This includes the design and evaluation of networking protocols and architectures, as well as Internet measurements and analysis. His efforts are driven by the hope of improving Internet communication based on sound research. He is actively involved in the IETF since 2005 and co-founded some successful open source projects such as RIOT (https://riot-os.org/) and RTRlib (https://rtrlib.rpki.net/). Matthias is a member of the Advisory Board of BCIX, the Berlin Internet Exchange Point, and INSO, the Internet Namespace Security Observatory supported by the Internet Society (ISOC), and a co-founder of DD-IX, the Dresden Internet Exchange.

Comments 2