One Day in the Life of RPKI

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.

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:

• RPKI-Based Origin Validation Operation, IETF Internet Draft
• BGP Prefix Origin Validation, IETF Internet Draft
• RTRlib - The RPKI RTR Client C Library

Acknowledgments

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