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.
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.
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.
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, one of the weaknesses 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 a 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 natively. 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
- UNKNOWN: The prefix in this announcement is not covered (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.