Resource Public Key Infrastructure (RPKI) is technology based on open standards that is aimed at making the Border Gateway Protocol (BGP) more secure. It does this by providing network operators a way to perform Route Origin Validation. NLnet Labs is developing a comprehensive set of tools to generate, publish and validate RPKI data.
RPKI is a community-driven system in which open source software developers, router vendors and all five Regional Internet Registries (RIRs) participate, i.e. ARIN, APNIC, AFRINIC, LACNIC and RIPE NCC. The technology is based on open standards that were developed in the Secure Inter-Domain Routing (sidr) Working Group in the IETF. After standardisation was completed, work continued in the SIDR Operation (sidrops) Working Group.
Using the RPKI system, the legitimate holder of a block of IP addresses can make an authoritative statement about which Autonomous System (AS) is authorised to originate their prefix in the BGP. In turn, other network operators can download and validate these statements and make routing decisions based on them.
Route Origin Validation
The most common routing error on the Internet is the accidental mis-origination of a prefix. This means a network operator unintentionally announces an IP prefix that they are not the holder of. An incorrect announcement can also be the result of malicious activity. Route Origin Validation answers the question:
“Is this particular BGP route announcement authorised by the legitimate holder of the address space?”
By comparing the BGP announcement to the RPKI data set the outcome can be yes, no or undetermined. Based on this information, a network operator can decide to accept the announcement, drop it or treat it in any other way they choose.
A similar system has been in place for many years via the Internet Routing Registry (IRR) system. However, the weakness of the IRR is that it is not a globally deployed system and it lacks the authorisation model to make the system water tight. RPKI solves these two problems, as you can be absolutely sure that an authoritative, cryptographically validatable statement can be made by any legitimate IP resource holder in the world.
The five RIRs are responsible for allocating IP addresses and Autonomous System Numbers in each of their regions. In most cases they allocate resources directly to their members, called Local Internet Registries (LIRs). In turn, LIRs assign resources to ISPs or end user organisations. There is an exception in the APNIC and LACNIC region, where in some countries allocations are handled through National Internet Registry (NIR) organisations to meet particular geographical needs. For example, JPNIC in Japan and NIC.br in Brazil provide these services on a national level.
The RPKI certificate structure matches the allocation model. This means all RIRs run a Root Certificate Authority which has a self-signed root certificate containing all of the resources that they each manage. They issue child certificates to NIRs or LIRs who can, in turn, issue a certificate to each of their customers.
To lower the entry barrier into the technology, each RIR offers a Hosted RPKI system. This allows members to log into a web-based customer portal and instruct the RPKI system to generate a certificate for them, which resides on the systems hosted by the RIR. While this offers some convenience for basic management, the LIR is not truly the holder of their own certificate. Operators who prefer more control, security and have better integration with their own systems can run their own child CA. This is model is usually referred to as Delegated RPKI.
Using either the Hosted or Delegated RPKI, operators can create cryptographically validatable statements about their routing intent, e.g. which ASNs are authorised to originate their IP prefixes. These statements are called Route Origin Authorisations (ROAs). Within a ROA, the operator can also specify what the maximum length of the prefix is that the AS is authorised to advertise. This is a way to enforce aggregation and prevent hijacking through the announcement of a more specific prefix.
All certificates and ROAs are published in a distributed set of repositories. When using the Hosted RPKI system, this is a repository operated by the RIR. When an operator uses Delegated RPKI, they can either publish to a Publication Server that they host themselves, or they can ask a third party to do this on their behalf.
Operators who want to use RPKI data in their BGP decision making process have to fetch and validate all of the published data. As with any Public Key Infrastructure, you have to start with one or more entities you are prepared to trust. In the case of RPKI, these are the five RIRs. When you want to retrieve all RPKI data, you connect to the Trust Anchor that each of them provides.
Relying Party software, also known as an RPKI Validator, will start retrieval at each of the RIR Trust Anchors and follow the certificate tree in order to fetch all published certificates and ROAs. Any object that doesn't pass cryptographic validation will be discarded. All remaining information will result in a list of AS Numbers, IP prefixes and maximum prefix length, known as the validated cache.
The data from the validated cache can be fed directly into RPKI-capable routers via the RPKI-RTR protocol. Many routers, including Cisco, Juniper, Alcatel-Lucent, as well as BIRD and Quagga support processing an RPKI validated cache. Alternatively, Relying Party software can export the validated cache in various useful formats for processing outside of the router in order to set up filters.
When comparing the validated cache to all route announcements seen in BGP, it will have an effect on their RPKI validity. They can be:
- Valid: The route announcement is covered by at least one ROA
- Invalid: The prefix is announced from an unauthorised AS or the announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS
- NotFound: The prefix in this announcement is not, or only partially covered by an existing ROA
Based on these outcomes, operators can make an informed decision what to do with the BGP route announcements they see. For RPKI to succeed in its objective, operators should at least drop all announcements that are RPKI INVALID.
ROA Best Practices
A Route Origin Authorisation object consists of three elements: the AS Number that you authorise, the prefix that is being originated from it and, lastly, the Maximum Length (MaxLength), which determines the most specific prefix that the AS may originate out of the aggregate. Keep in mind that a single ROA makes the announcement of a prefix from an authorised AS valid, but at the same time, it makes the announcement from an unauthorised (hijacking) AS invalid. You should create as many ROAs as needed to make all legitimate announcements valid.
There are several ways to authorise a BGP origin with a ROA. For example, you can authorise the entire aggregate to be originated – including all more specific announcements – with a single ROA. Or you can authorise each announcement with a ROA individually. While creating a single ROA seems convenient, it is not recommended.
For example, if you are the holder of 10.0.0.0/18 and you announce the aggretate as well as several more specifics up to a /24 from AS64500, you could create a ROA for AS64500 authorising 10.0.0.0/18 and set the MaxLength to /24. However, if an adversary now spoofs your ASN and starts announcing any more specific out of your aggregate, they will all be seen as RPKI VALID, because there is a covering ROA for it.
The best practice is to create a ROA for each announcement individually, and set the MaxLength to exactly the prefix length that you actually announce.