BGP and RPKI: A Path Made Clear with Kentik

Border Gateway Protocol (more commonly known as BGP) is the routing protocol that makes the internet work. It is the language spoken by routers to determine how packets can be sent from one router to another to reach their final destination.

In its early days, BGP didn’t include any method to ensure whether a prefix from a peer had the correct ASN originating it in its AS_PATH attribute. In simpler terms, any BGP-speaking network could announce itself (deliberately or not) as the origin of any prefix.

Time and time again, this resulted in a “BGP prefix hijack,” where, in many cases, part of the internet was unreachable. In the most recent incident, which happened last week, an ISP incorrectly accepted invalid routes into their network from one of their customers. While this event included multiple issues, one of them was related to invalid prefixes being announced throughout the internet. In this case it was due to more specific prefixes that should not have been advertised.

However, an improved routing security mechanism to make the internet routing world safer does exist. It’s called RPKI.

Without RPKI, the only way to arm yourself and your network against propagation of BGP hijacks and other erroneous routing information is to parse the IRR (Internet Routing Registry), which even then relies on blind trust of whether or not the IRRs are correct.

What is RPKI (Resource Public Key Infrastructure)?

RPKI stands for Resource Public Key Infrastructure. It is defined by RFC6480 and is a cryptographic method that was designed to sign BGP route prefix announcements with the correct originating AS number.

One way to think about it is that RPKI is to BGP what DNSSEC is to DNS. It offers a way to sign and validate origination of BGP prefixes against an official and signed list of prefixes by origin ASN.

(For more background, check out Cloudflare’s very comprehensive article around RPKI and its benefits.)

How Does RPKI Work?

The entire RPKI process stands outside of the BGP routing protocol itself. What that means is that the use of RPKI to validate BGP advertised data doesn’t involve the BGP protocol at all.

Generating and signing ROAs

The first step for RPKI to work is that networks need to sign their prefixes. The result of an ASN cryptographically signing a prefix is called an ROA (Route Authorization) record. The current signing infrastructure and process is handled by the five independent regional internet registries (RIRs)—AFRINIC, APNIC, ARIN, LACNIC, and RIPE—which therefore act as CAs (Certificate Authorities).

Besides the certificate part, ROA contains the attributes listed below, which we’ll look at in detail via a Kentik ROA:

{
   "prefix": "141.193.36.0/22",
   "maxLength": 24,
   "asn": "AS6169",
   "ta": "Cloudflare - ARIN"
 }   

The components of this ROA are as follows:

• prefix describes the prefix being signed in the ROA.
• maxLength gives the highest mask that a prefix can take within the aforementioned prefix in order for it to be considered valid. In this specific example, all prefixes contained within 141.193.36.0/22 with netmasks equals to 22, 23, and 24 are considered valid. If a prefix is contained within the aforementioned one and has a /25 mask, it will then be considered invalid even though it is within a broader, valid one.
• asn defines the certified origin ASN for all prefixes included in the prefix attribute, provided their mask is broader or equal to the maxLength attribute. This allows for route validation to compare Origin ASN of a received prefix vs. True Ownership for said received prefix—a discrepancy is then seen as a hijack. (AS6169 is Kentik’s ASN.)
• ta this attribute points to the Trusted Anchor that the ROA comes from. In this example, it shows as coming from ARIN with the additional “Cloudflare” prefix showing that the list of ROAs it comes from has been pulled from ARIN by “Cloudflare.”

Trusted Anchors

In RPKI verbiage, Certificate Authorities are called Trusted Anchors, aka TAs, but they are basically the same. As explained earlier, today’s five RIRs are the TAs in the RPKI world.

What that means is that you can only sign your own prefixes and, if they somehow get deallocated from you, the associated ROAs will get revoked.

TAs are responsible for two elements of the RPKI chain:

1. To provide the infrastructure for members to sign their prefixes, and
2. To provide the consolidated list of ROAs for public consumption.

How are ROAs used?

The overarching goal of RPKI is for networks to be able to compare the BGP announcements they receive to the aggregated list of ROAs and be able to drop them in case they aren’t from whoever they are actually supposed to be from.

Since BGP has no knowledge of RPKI, another method is needed to leverage a consolidated, global list of ROAs to use it for route validation. This method pairs routers with a server, which is aptly called a “validator”.

Validators are tasked with:

1. Pulling ROA updates from all of the known TAs, and
2. Presenting it to the routers they are paired with. They handle all the crypto processing of the data pulled from TAs.

In order for this to work at scale, router vendors agreed on a lightweight protocol for routers to query validators. That protocol is called RTR (meaning “RPKI-to-router” protocol). It has been defined in the successive RFC6810 and RFC8210 standards.

RTR-capable routers are able to query validators for ROA data and use the resulting info for route validation (in essence, deciding to keep or drop a given prefix based on ROA data).

The process described above can be summarized in the following diagram:

How Does Kentik Fit into the RPKI Ecosystem?

To support the community’s initiative to secure BGP via RPKI, Kentik has now added RPKI status visibility into our product. This provides another option for network engineers desiring to join in the RPKI journey. It also helps network operators understand how their routing plane would react when and if they turn on “Strict Route Validation.”

Until everyone adopts RPKI, the RPKI information Kentik provides helps users determine two critical things:

1. If traffic is being originated by ASNs that don’t own them (i.e. hijacks) and/or if it is being announced by the right origin more specifically than it should.

2. What would happen if strict route validations were to be enabled on the routers where Kentik gets the flows and BGP feeds from.

For more detail on using RPKI in Kentik, please see the related blog post, ”Technical Guide: Using RPKI in Kentik”. It provides a step-by-step example with screenshots to guide you. Not a Kentik user yet? Request a demo.

Special Thanks Department

Kentik would not be able to tackle the RPKI challenge without the help of our industry peers. For that, we extend our thanks to Cloudflare who (among other things) offered their help from the beginning to bootstrap and perfect Kentik’s understanding of RPKI. Additionally, they have made a great deal of well-supported, open source tooling available to the community for free. (Kentik’s RPKI implementation is built on Cloudflare’s open source library, as well as the curated list of ROAs Cloudflare offers via https://rpki.cloudflare.com/rpki.json.)

A special thanks goes out to Louis Poinsignon, who leads the development of Cloudflare’s RPKI tool-chain (twitter.com/lpoinsig), for his phenomenal support and willingness to help. Additionally, Jerome Fleury who runs the network team at Cloudflare (twitter.com/jerome_uz) for suggesting our two companies should team up when Cloudflare were about to announce their involvement in the RPKI community initiative last year.

Thanks also to Job Snijders (twitter.com/JobSnijders) and Paulo Lucente from NTT and the PMACCT project, who kindly pointed us to the PMACCT code to guide us through the implementation.

Lastly, to Aaron Weintraub from Cogent for his time in reviewing and testing our early, iterative versions for accuracy and usefulness. Thanks!