Resource Public Key Infrastructure (RPKI)

On the Internet, we use BGP for routing. BGP has no built-in security mechanisms to check whether a prefix belongs to a specific autonomous system (AS). It’s all based on trust. You can advertise whatever you want; the only thing stopping those prefixes is outbound or inbound filters if you have any. The Internet is vulnerable to bogus routing information. This is a problem, such as BGP hijacking or route leaking.

Prefixes belong to specific ASes with matching autonomous system numbers (ASN). You can look them up in the Internet Routing Registry (IRR).  You can look at the IRR using services such as RADb.

You could configure your routers to use the data from the IRR to filter prefixes. That sounds nice, but the data in IRR is unreliable. There is invalid data, stale records, and even typos. There are multiple data suppliers, and there is not enough control over the creation and verification of data.

A central list with prefixes and matching ASNs is a good idea, which led the Internet Engineering Task Force (IETF) to create Resource Public Key Infrastructure (RPKI), defined in RFC 6480.

RPKI is a security framework to ensure that BGP routing information is authentic. With RPKI, you can validate BGP announcements. As you’ll see, most of it works outside of BGP.

The “resource” part refers to Internet number resource information, such as ASNs and IP addresses. The “PKI” part means we use a cryptographic method with certificates and signing. RPKI uses X.509 certificates as described in RFC 5280. Normally, we use X.509 for user authentication or websites. These include an identity. RPKI certificates don’t, so there is an extension for IP addresses and AS identifiers, as explained in RFC 3779.

The resource holder owns the prefix and ASN, so this is the only entity that can create a signed object with the prefix and ASN. These signed objects are added to central lists, which we can use for verification.

Only allowing recourse holders to create objects and using PKI with certificates to enforce and validate the trustworthiness of this data is what IRR lacks and what makes RPKI a reliable solution.

RPKI makes the Internet more secure because you can check which prefixes belong to what ASes. Another benefit is that when you peer with a remote AS or assign IP addresses to customers, you have proof that you are the legitimate owner of one or more prefixes.

Now you have an idea of what RPKI is about, to understand its inner workings, we have to dive into two main components:

• Certificates and signing: We need certificates and tools so resource holders can create objects with prefixes and ASNs.
• Validating origins: We need something to validate those prefixes and ASNs, and our routers need to compare it with their BGP table.

We’ll take a look at these two in detail.

Certificates and Signing

We’ll start with the certificates.

With most certificates, such as those we use for HTTPS, we use root certificates pre-installed with a browser or operating system. We don’t use these for RPKI.

Trust Anchors (TA)

The Internet Assigned Numbers Authority (IANA) is responsible for all Internet number resources, such as IP addresses and AS numbers.  IANA further assigns resources to the five Regional Internet Registries (RIR):

• ARIN
• RIPE NCC
• APNIC
• LACNIC
• AFRINIC

Since these organizations are responsible for IP addresses and ASNs anywhere, they are also the certificate authorities (CA) for RPKI. In RPKI terminology, a CA is called a trust anchor (TA).

The TAs have these responsibilities:

• Provider the infrastructure so that resource holders can sign their prefixes and ASNs.
• Provide a public list so that others can verify these prefixes and ASNs.

Each RIR operates its own RPKI repository that publishes digital certificates and objects containing prefixes and ASNs. These repositories are accessible over the Internet. To authorize an AS to route prefixes, the resource holder must obtain a resource certificate from their RIR to verify the prefixes allocated to them.

Route Origin Authorization (ROA)

Most RIRs offer dashboards that resource holders can use to log in and find the ASN and prefixes they own. This is also where they can create a signed object with public key cryptography, which contains three items:

• The authorized AS number.
• The prefix that the AS can originate
• The maximum prefix length (maxLength).

This object is called a Route Origin Authorization (ROA) and defines which AS is authorized to originate a prefix. If you have access to a RIR because you own a prefix and ASN, you can create, edit, or delete ROAs for these. If a prefix is deallocated from you, the ROA will be revoked.

As the name implies, the maximum length specifies the maximum prefix length. For example, if the ROA contains 192.0.1.0/24 and the maximum length is /25, the AS can advertise one /24 or two adjacent /25 prefixes. Any more specific prefixes, such as a /26, are unauthorized.

Here is an example of how you can create a ROA for ARIN:

https://www.youtube.com/watch?v=BLQENAh4WT0

Here is an example of RIPE NCC:

Now you know who is responsible for signing and how we create ROAs.

Route Origin Validation (ROV)

The second part of RPKI is to validate ROAs. Route Origin Validation (ROV) is the validation of ROA objects and is explained in RFC 6483.

If you want to access all RPKI data, you connect to the TA of each RIR. The root certificate has pointers to the certificate tree with subordinate certificates, pointers to more subordinate certificates, and so on.

The RIR TA is in a static trust anchor locator (TAL). This file contains the URL to the TA and a public key to verify if it is authentic.

RPKI Validator

To verify an ROA, you need to check the certificate(s), and running cryptographic software to check hundreds of thousands of ROAs on a router’s control plane is not a good idea.

Instead, to validate ROAs, we can use an RPKI validator. It is also known as a relying party software package. Most RPKI validators include the TALs for all RIRs.

When an RPKI validator starts, it looks up all RIR TAs and downloads all published certificates and ROAs. Originally, this was done with rsync, but most RPKI validators nowadays use RPKI Repository Delta Protocol (RRDP), standardized in RFC 8182.

The goal of an RPKI validator is:

• Download ROAs from all TAs.
• Validate all ROAs.
• Present a list to routers so they can validate prefixes and ASNs.

The RPKI validator acts as a local cache. The RPKI validator periodically downloads and processes all ROAs. When a ROA is validated, an object is created that contains these items:

• IP Prefix
• Maximum length
• Origin AS number

These items are the same as the ROA but validated by the RPKI validator. This object is called a validated ROA payload (VRP) and is added to a list.

The difference between an ROA and a VRP is the context. When the RPKI validator processes the ROA, it checks the digital certificate and certificate chain to ensure the ROA’s authenticity and integrity. When the ROA is validated, the RPKI validator extracts the information and converts it into a VRP. The collection of VRPs is called the validated cache.

There are many open-source RPKI validator tools. For example:

• FORT Validator
• OctoRPKI
• Routinator

In the BGP Prefix Origin AS Validation with RPKI lesson, I use Routinator. It has a GUI to manually validate prefixes and ASNs and see some statistics. RIPE has a hosted version so you can see it for yourself.

Routers

Routers can download the validated cache from the RPKI validator using the RPKI to router protocol (RPKI-RTR) as described in RFC 6810 and RFC 8210. Because the RPKI validator does the hard cryptographic work of checking all signatures, RPKI has minimal overhead on routers and doesn’t impact the convergence time much.

The router will download a list with VRPs and compare the routing information in the BGP table with the VRP. There can be one of three states per prefix:

• Valid: The prefix announcement is found in at least one VRP. This means that the prefix is equal or more specific than the prefix in the VRP.
• Invalid: The prefix is advertised from an unauthorized AS. This can have two causes:
  • There is a VRP for this prefix, but it has another AS number. This is BGP hijacking or a route leak.
  • The advertised prefix is more specific than what is allowed in the maximum length of the VRP.
• Not found: The advertised prefix is not covered by a VRP.

Unless you override this behavior, invalid prefixes can’t be used as a BGP best path. It is possible to use not-found prefixes, but BGP prefers valid over not-found prefixes. This selection happens before the best path selection, where we check weight, local preference, AS path length, etc.

Conclusion

You have now learned what RPKI is and how it validates BGP prefixes:

• BGP doesn’t have a built-in security mechanism to check if prefixes belong to the correct AS.
• Possible issues are BGP hijacking or route leaking.
• The IRR has records with prefixes and AS numbers but is unreliable.
• RPKI is a security framework that uses certificates, and only resource holders can create objects named ROAs.
• The five RIRs are the RPKI CAs, named TAs.
• A ROA contains:
  • Prefix
  • ASN
  • Maximum prefix length
• Route origin validation is the validation of ROA objects.
• The TAL contains the URLs to the different TAs.
• The RPKI validator checks all ROAs from all TAs and stores them as VRPs in the validated cache.
• Routers download VRPs from the RPKI validator so they can check their BGP prefixes.
• Each prefix can have one of three states:
  • Valid
  • Invalid
  • Not Found

RPKI is a key component of MANRS compliance but not the only security mechanism for BGP. It offers origin validation but doesn’t check the entire AS path. That’s something that BGPsec does.

If you want to see how widespread and the adoption rate of RPKI is, MANRS has a state of routing security overview, and Cloudflare also has an RPKI dashboard, which offers something similar.

I hope you enjoyed this lesson. If you have any questions, please leave a comment.