You are here: Home > Publications > RIPE Labs > Matthias Wählisch > One Day in the Life of RPKI

One Day in the Life of RPKI

Matthias Wählisch — 21 Dec 2011
Contributors: Fabian Holler, Thomas Schmidt
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.

2 Comments

Alex Band says:
21 Dec, 2011 01:53 PM
We have been in contact with AT&T over the last couple of days and it turned out they did not realise that creating a single ROA for the 12/8 superblock for AS7018 would render all the other announcements from all the other ASs INVALID. Instead, their reasoning was that since no statement was made about these other ASs specifically, the status of the announcements would remain UNKNOWN. Now that that has been clarified, AT&T have removed the ROA for AS7018 today.

I advised them that when they want to start creating ROAs, they would be better off starting small by authorising for example 12.1.216.0/24 from AS2386 and then expand from there. This is because ROAs covering partial overlaps of prefixes will give the announcement the status UNKNOWN, so the 12/8 announcement from AS7018 is not affected by this.

Looking at the bigger picture, it is important that the user interface for ROA management indicates to the user what the effects of creating a ROA are on all related route annoucements. We do this in the LIR Portal through the comparison of the existing ROAs to the BGP route announcements seen by the RIPE NCC Route Collectors and displaying their validity state. Our RPKI Validator offers the same functionality. In addition, especially for an organisation the size of AT&T – with the amount of address space they hold and the amount of announcements they do – it is important that ROA management integrates well with IP address and routing management for it be usable in practice.
Arturo Servin says:
22 Dec, 2011 04:03 PM
We have seen similar results. A lot of invalids because wrong origin or bad max len in the ROA.

We also created a simple tool to verify if an announce is valid or invalid.

http://www.labs.lacnic.net/rpkitools/looking_glass/

-as
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.