Technical Guide: Using RPKI in Kentik

Summary

Crystal Li’s new Technical Guide walks you through new Kentik features for supporting Resource Public Key Infrastructure (RPKI), explaining Kentik’s new RPKI Validation Status and RPKI Quick Status dimensions.

This Technical Guide will walk you through new Kentik features for supporting Resource Public Key Infrastructure (RPKI), explaining the new RPKI Validation Status and RPKI Quick Status dimensions. For a more general introduction to Kentik’s RPKI capabilities, please see the related blog post, ”BGP and RPKI: A Path Made Clear with Kentik.”

Resource Public Key Infrastructure (RPKI), defined by RFC6480, is a cryptographic method that was designed to sign BGP route prefix announcements with the originating AS number.

Kentik has now integrated RPKI support via new dimensions “RPKI Validation Status” and “RPKI Quick Status” (see screenshot below), to allow users to precisely determine what would happen to the existing network traffic if they were to turn on RPKI validation for their networking equipment.

These two dimensions are “destination-directional” because they correspond to routes received by routers from external peering sessions. We’ll describe these dimensions in more detail, below.

RPKI Validation Status

This dimension contains the full RPKI state for a given flow, values it can take are:

RPKI Unknown

No ROA has been found to associate to the incoming traffic. While this doesn’t mean that the related destination traffic was announced using an ROA certified ASN, a route validator will not have the router drop this traffic.

RPKI Valid

There is an existing ROA found for the traffic under that destination prefix, and the BGP announcements for it are announced by the correct, certified ASN. This type of traffic represents the highest level of certainty around the legitimacy of the origin ASN (i.e., it’s the safest and will not be dropped).

RPKI Invalid

There are multiple sub-cases for this dimension as described below:

• RPKI Invalid: valid covering prefix: While traffic is seen as RPKI-invalid, Kentik has determined that there is a covering BGP announcement to make it RPKI-valid with a secondary announcement. In practice, this means that the initial prefix for this traffic will be dropped following in the case of RPKI strict route validation, but a covering RPKI-valid prefix will take over, making traffic uninterrupted.

• RPKI Invalid: unknown covering prefix: Similar to the aforementioned case, the current BGP origin for the traffic is invalid, but there’s an existing backup one covering it that will prevent this traffic from being dropped as it has an RPKI-validation status of unknown. (Unknowns are not dropped: They correspond to the vast majority of traffic over the internet, until such time as RPKI is widely adopted and everyone signs all of their prefixes).

• RPKI Invalid: prefix length out of bounds: Traffic under this label will be dropped in the case of strict route validation. Each ROA comes with a maxLength that doesn’t contain the prefix seen in the BGP table.

Let’s take one of Kentik’s ROAs as an example:

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

The 141.193.36.0/22 ROA comes with a maxLength attribute of 24. Practically, what that means is that all prefixes inside the /22 with a netmask between /22 and /24 will be seen as valid. With this in mind, 141.193.26.0/25 will be considered RPKI-invalid because /25 is outside of the /24 max length.

• RPKI Invalid: incorrect Origin ASN (should be AS<AS_Number>): If the preferred BGP route for traffic behind specific traffic isn’t originated by the ASN specified by the ROA, an “Incorrect Origin ASN (should be AS<AS_NUMBER>)” label will be associated with this traffic. In practice, this means that the preferred BGP route appears to be announced by a Hijacking ASN. This also means that there is no valid or unknown alternative for this traffic in the BGP table. Therefore, traffic corresponding to this prefix will be entirely dropped if Strict Route Validation is enabled.

• RPKI Invalid: explicit ASN 0: The RPKI standard also allows us to statically define prefixes that shouldn’t be trusted at all. Trust Anchors, and anyone else who leverages RPKI, can inject artificial ROAs that contain an origin ASN value of 0. An ROA with ASN = 0 means that any traffic coming from that prefix, and all prefixes contained within it as defined by maxLength will be considered explicitly invalid.

RPKI Quick Status

While the “RPKI Validation Status” provides a lot of granularity with respect to reasons why traffic is valid or invalid, it may not provide the best view for quickly determining what traffic will be dropped and what will not.

The “RPKI Quick Status” dimension serves this purpose. It can help operators determine how traffic is going to behave globally by aggregating the previously mentioned “RPKI validation Statuses” into more legible aggregates of a given network.

RPKI Quick Status

An Example: Leveraging “RPKI Quick Status”

When considering Strict Route Validation, the most common task at hand is to evaluate the amount of traffic that will be dropped once it is enforced throughout the network.

As a result, what most users will likely want to do is focus on the RPKI Invalid cases that will end up being dropped. Filtering on the Quick Status validation can help with that task, by simply setting the following filter:

A sample query like the one below can yield useful information on what traffic will eventually get dropped:

• Site provides a broad level of grouping.
• RPKI Validation Status displays all the different associated RPKI Statuses for traffic that will end up being dropped.
• Destination Route Prefix/LEN provides a reference to the prefixes that will get dropped for further investigation.
• Destination AS Number allows us to detect mismatches between the BGP announcement and the what RPKI expects as the “official” origin for this prefix.

Here’s sample output from this query (click image to zoom):

In this example, we notice that prefix 45.239.121.0/24 will be dropped, but also that:

• Site: This drop will be localized on the ATL1 pop
• The BGP announcement seen on ATL1 pop says the Origin ASN is AS61503, from the Destination AS Number dimension
• However, the official origin ASN for this prefix based on ROAs is AS266852 from the RPKI Validation Status Dimension

We can also drill down further to help identify, more precisely, where this issue comes from and even warn involved parties (from official origin ASN to Transit Provider conveying the hijack).

Clicking the “Show by” contextual menu at the end of this row will allow to show its AS PATH (click image to zoom):

This AS PATH will eventually tell us that this specific 45.239.121.0/24 prefix is currently seen as originated and prepended multiple times by AS61503 via the former Global Crossing ASN and finally by a peering session with Level3’s AS3356 (click image to zoom):

RPKI Dashboard

To improve the efficiency in obtaining an overview of RPKI traffic you can create a Dashboard and share it within organizations. Below is an example:

RPKI Alerting (Available soon)

Finally, in the near future you will be able to use Kentik Alerts to monitor invalid RPKI traffic and be proactively notified in the event of a rise in this traffic. Stay tuned for more details as additional RPKI features are enabled!