What is RPKI & How to Use it?

According to Wikipedia, Resource Public Key Infrastructure (RPKI) is a specialized public key infrastructure framework to support improved security for the Internet's BGP routing infrastructure. RPKI provides a way to connect Internet number resource information to a trust anchor. Essentially, RPKI ensures that the network saying, “We are the place to send traffic for network A.B.C.D” really is the right place. It is a way of improving the security of the Border Gateway Protocol (BGP), which uses the Autonomous System Number (ASN) to identify a network, which is a block of IP addresses. It doesn’t matter whether they are IPv6 or IPv4 addresses.

RPKI will validate the origin of the IP prefix (the IP address block in CIDR notation) (“Send traffic for A.B.C.D to ASN 55555”) but can’t do path validation (“The way to get to ASN 55555 is through ASN 55556”).  The RIPE.net defines RPKI as “prov[ing] the association between specific IP address blocks or ASNs and the holders of those Internet number resources. The certificates are proof of the resource holder’s right to use their resources and can be validated cryptographically. RPKI is based on an X.509 certificate profile defined in RFC3779.

If you’ve ever gone to a website and gotten an error saying that the browser can’t confirm that the website is real, and looked for more information to find that it had an invalid or expired certificate, this is the same thing. The certificate is a document with a cryptographic key in it, and your browser (or RPKI validator) can ask the Certificate Authority (CA) “Is this the right key for what I’m looking at?” The actual cryptography is more complex but isn’t necessary to use the tools.

Why bother with RPKI? Without it, anyone anywhere in the world can just start using your IP addresses. The best current practice is for Internet Service Providers (ISPs) only to accept route announcements that they have checked are correct, but not everyone does that. It’s a bad day when your addresses get hijacked. You’re at least partly off the Internet, and the hijacker is probably spamming the world, so even when they stop, mail servers and firewalls may reject your traffic as having a bad reputation.

How to use RPKI

Using RPKI is very simple in concept and consists of two parts. You will need access to your account at one of the Regional Internet Registries (RIRs) (ARIN Online, myAPNIC, RIPE NCC Access, miLACNIC, AFRINIC login). You will need to be the authoritative contact for some IP addresses and you’ll need to know the originating ASN. A server running validator software. A virtual server is fine. A router-speaking BGP with RPKI functionality was implemented.

1. Signing Your IP Resources

First, you need to sign your IP resources. Login to your RIR LIR portal and find instructions on how to sign your resources. The process is very simple at most RIRs, and once you’ve done the first one it should only take a few seconds per prefix.

Visit the below site for information on how to sign your prefixes per RIR:

RIPE – https://www.ripe.net/manage-ips-and-asns/resource-management/certification

LACNIC – https://www.lacnic.net/1151/2/lacnic/rpki-faq

ARIN – https://www.arin.net/resources/manage/rpki/

APNIC – https://www.apnic.net/community/security/resource-certification/

AFRINIC – https://afrinic.net/resource-certification

Signing your resources means creating a ROA (Route Origin Authorization), which authorizes an ASN to originate a route announcement.

Once you sign your IP resources, everyone that is doing RPKI validation can tell if your IP prefix was announced from the right AS number and if the prefix size matches the size, specified in the ROA.

2. Validating Your Prefixes

The second part of RPKI is validation. Earlier, we made sure that the rest of the world can validate your announcements and distinguish your announcement from attackers. By validating the incoming prefixes we make sure that we can also distinguish other networks’ announcements from attackers. What you need for RPKI validation is a (virtual) server to run a validator and a BGP router that has RPKI functionality implemented.

You can choose between several RPKI validator implementations; this RIPE Labs article describes how to install some of the more popular ones.

Once you have a validator in place, it’s time to configure your BGP router to create an RPKI-to-Router (RTR) session to validate and start validating. Here is a list of routers that support RPKI,  and here are some configuration examples provided by RIPE NCC.

Once you have validation set up, you can decide how exactly to implement the route validation. An RPKI check will either tell you that the route is valid (has a signed ROA that checks out), invalid (there’s a ROA, but this route announcement doesn’t match), or unknown (ROA not found). Generally, if you receive three route announcements, you would prefer one that is signed over one that is unsigned, but either is better than an invalid route.

One option is to install prefixes with different local preferences, for instance valid = 110, not_found = 100, invalid = 90. In this case, a valid announcement will always take precedence over the attacker, who also announces prefix, but a false announcement will be installed with lower local preference and will never be used if there is a route with higher local preference. Unfortunately, this option will not protect you if an attacker starts announcing smaller prefixes than yours: a /24 route is more specific, and therefore always preferred, over a /8. An increasing number of operators find this consistently less useful as it’s no real protection.

An alternative that is getting more vocal support by major operators is not installing invalid prefixes at all (rather than assigning them a lower local_pref). This variant is the safest because invalid route announcements have nothing to do with the routing table. But you have to trust the RIR. Let’s say the federal police come to an RIR and require that it replace Company_X’s ROA with a different one (pointing to their network, so they can intercept all the traffic). Company_X is off the Internet—to the rest of the world, their signed route announcements are invalid.

There are pros and cons to both options. Typically, operators start with the first option (invalid = lower local_pref) and watch their log files. When they are confident that dropping invalids would not break their connectivity (or some local laws or legal agreements in some cases), then they can reconfigure the system to start dropping invalids. In case the central RPKI database gets fiddled with, they can always reconfigure the RPKI policy back to whatever suits them at that moment.

Consider another failure case, that happened at the RIPE NCC. All ROA records disappeared for a couple of hours. Anyone checking ROAs would get a “not_found” error (“unknown”) and set local_pref to that level. No routes would be dropped (including malicious ones that should be).

Am I Protected by RPKI?

Recently, Cloudflare published an RPKI testing tool that everyone can use. Test your network to see if it’s properly implementing RPKI. The test tries to get a web page from two different web servers, one from a prefix with a valid ROA, and one with an invalid ROA. If both works, your network (or your ISP) is accepting and using an invalid prefix announcement.

RPKI is rapidly becoming an essential part of MANRS, the Mutually Agreed Norms for Routing Security and while you are looking into RPKI – have a look also in MANRS and join the increasing pool of operators that takes the routing hygiene and security seriously. Every network is run independently and each network operator makes its own decisions.

Your IP addresses are a valuable resource: you should protect them! We hope that you have learned through our article. If you are interested to know more, feel free to read our blog or follow us on LinkedIn.