Resource Public Key Infrastructure
RPKI provides a way to connect Internet number resource information (such as Autonomous System numbers and IP addresses) to a trust anchor. The certificate structure mirrors the way in which Internet number resources are distributed. That is, resources are initially distributed by the IANA to the Regional Internet Registries (RIRs), who in turn distribute them to Local Internet registries (LIRs), who then distribute the resources to their customers. RPKI can be used by the legitimate holders of the resources to control the operation of Internet routing protocols to prevent route hijacking and other attacks. In particular, RPKI is used to secure the Border Gateway Protocol (BGP) through BGPSEC, as well as Neighbor Discovery Protocol (ND) for IPv6 through the Secure Neighbor Discovery Protocol (SEND).
Work on standardizing RPKI is currently (late 2011) ongoing at the IETF in the sidr working group, based on a threat analysis which was documented in RFC 4593. The standards cover BGP origin validation, while work on path validation is underway. Several implementations for the prefix origin validation already exist.
Resource Certificates and child objects
RPKI uses X.509 PKI Certificates (RFC 5280) with Extensions for IP Addresses and AS Identifiers (RFC 3779). It allows the members of Regional Internet Registries, known as Local Internet Registries (LIRs), to obtain a resource certificate listing the Internet number resources they hold. This offers them validatable proof of holdership, though it should be noted that the certificate does not contain identity information. Using the resource certificate, LIRs can create cryptographic attestations about the route announcements they authorise to be made with the prefixes they hold. These attestations are called Route Origination Authorizations (ROAs).
Route Origination Authorizations
A Route Origination Authorization states which Autonomous System (AS) is authorised to originate certain IP prefixes. In addition, it can determine the maximum length of the prefix that the AS is authorised to advertise.
Maximum Prefix Length
The maximum prefix length is an optional field. When not defined, the AS is only authorised to advertise exactly the prefix specified. Any more specific announcement of the prefix will be considered invalid. This is a way to enforce aggregation and prevent hijacking through the announcement of a more specific prefix.
When present, this specifies the length of the most specific IP prefix that the AS is authorised to advertise. For example, if the IP address prefix is 10.0/16 and the maximum length is 22, the AS is authorised to advertise any prefix under 10.0/16, as long as it is no more specific than /22. So, in this example, the AS would be authorised to advertise 10.0/16, 10.0.128/20 or 10.0.252/22, but not 10.0.255.0/24.
RPKI Route Announcement Validity
When a ROA is created for a certain combination of origin AS and prefix, this will have an effect on the RPKI validity of one or more route announcements. They can be:
- The route announcement is covered by at least one ROA
- The prefix is announced from an unauthorised AS. This means:
- There is a ROA for this prefix for another AS, but no ROA authorising this AS; or
- This could be a hijacking attempt
- The announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS
- The prefix is announced from an unauthorised AS. This means:
- The prefix in this announcement is not covered (or only partially covered) by an existing ROA
Note that invalid BGP updates may also be due to incorrectly configured ROAs.
There are open source tools available to run the Certificate Authority and manage the resource certificate and child objects such as ROAs. In addition, the RIRs have a hosted RPKI platform available in their member portals. This allows LIRs to choose to rely on a hosted system, or run their own software.
The system does not use a single repository publication point to publish RPKI objects. Instead, the RPKI repository system consists of multiple repository publication points. Each repository publication point is associated with one or more RPKI certificates' publication points. In practice this means that when running a Certificate Authority, an LIR can either publish all cryptographic material themselves, or they can rely on a third party for publication. When an LIR chooses to use the hosted system provided by the RIR, in principle publication is done in the RIR repository.
Relying parties run local RPKI validation tools, which are pointed at the different RPKI trust anchors and using rsync gather all cryptographic objects from the different repositories used for publication. This creates a local validated cache which can be used for making BGP routing decisions.
After validation of ROAs, the attestations can be compared to BGP routing and aid network operators in their decision making process. This can be done manually, but the validated prefix origin data can also be sent to a supported router using the RPKI to Router Protocol (RFC 6810). Cisco Systems offers native support on many platforms for fetching the RPKI data set and using it in the router configuration. Juniper offers support on all platforms that run version 12.2 or newer. Quagga obtains this functionality through BGP Secure Routing Extensions (BGP-SRx) or a fully RFC-compliant RPKI implementation based on RTRlib. The RTRlib provides an open source C implementation of the RTR protocol and prefix origin verification. The library is useful for developers of routing software but also for network operators. Developers can integrate the RTRlib into the BGP daemon to extend their implementation towards RPKI. Network operators may use the RTRlib to develop monitoring tools (e.g., to check the proper operation of caches or to evaluate their performance).
RFC 6494 updates the certificate validation method of the Secure Neighbor Discovery Protocol (SEND) security mechanisms for Neighbor Discovery Protocol (ND) to use RPKI for use in IPv6. It defines a SEND Certificate Profile utilizing a modified RFC 6487 RPKI Certificate Profile which must include a single RFC 3779 IP Address Delegation extension.
- Security Requirements for BGP Path Validation, S. Bellovin, R. Bush, D. Ward, October 19, 2011
- Resource Public Key Infrastructure (RPKI) Router Implementation Report (RFC 7128), R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch, February, 2014
- A Profile for Route Origin Authorizations (ROAs), M. Lepinski, S. Kent, D. Kong, May 9, 2011
- Validation of Route Origination using the Resource Certificate PKI and ROAs, G. Huston, G. Michaelson, November 11, 2010
- M. Wählisch, O. Maennel, T.C. Schmidt: "Towards Detecting BGP Route Hijacking using the RPKI", Proc. of ACM SIGCOMM, pp. 103–104, New York:ACM, August 2012.
- M. Wählisch, F. Holler, T.C. Schmidt, J.H. Schiller: "RTRlib: An Open-Source Library in C for RPKI-based Prefix Origin Validation, Proc. of USENIX Security Workshop CSET'13, Berkeley, CA, USA:USENIX Assoc., 2013.
- IETF Journal - Securing BGP and SIDR
- An open source implementation of the complete set of RPKI protocols and tools
- RTRlib - Open source RPKI-Router Client C Library
- Quagga RPKI implementation
- RPKI Deployment statistics for all RIRs
- Global ROA deployment heatmap
- EuroTransit Czech Republic
- BGPMON - Validating BGP announcement with RPKI
- An APNIC primer on RPKI
- RIPE NCC Resource Certification (RPKI) information
- LACNIC RPKI Information
- ARIN RPKI Information
- NRO statement on RPKI
- Internet Architecture Board statement on RPKI
- Building a new governance hierarchy: RPKI and the future of Internet routing and addressing
- Secure Border Gateway Protocol (Secure-BGP)
- RPKI Router Implementation Report