View source for Resource Public Key Infrastructure

{{Short description|Internet routing security framework}}
'''Resource Public Key Infrastructure''' ('''RPKI'''), also known as '''Resource Certification''', is a specialized [[public key infrastructure]] (PKI) framework to support improved security for the [[Internet]]'s [[BGP]] [[routing]] infrastructure.

RPKI provides a way to connect Internet number resource information (such as [[Autonomous System (Internet)|Autonomous System]] numbers and [[IP address]]es) 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 [[Internet Assigned Numbers Authority|IANA]] to the [[regional Internet registry|regional Internet registries]] (RIRs), who in turn distribute them to [[local Internet registry|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 protocol]]s to prevent [[route hijacking]] and other attacks. In particular, RPKI is used to secure the [[Border Gateway Protocol]] (BGP) through BGP Route Origin Validation (ROV), as well as [[Neighbor Discovery Protocol]] (ND) for [[IPv6]] through the [[Secure Neighbor Discovery]] protocol (SEND).

The RPKI architecture is documented in RFC 6480.  The RPKI specification is documented in a spread out series of RFCs: RFC 6481, RFC 6482, RFC 6483, RFC 6484, RFC 6485, RFC 6486, RFC 6487, RFC 6488, RFC 6489, RFC 6490, RFC 6491, RFC 6492, and RFC 6493. SEND is documented in RFC 6494 and RFC 6495.  These RFCs are a product of the [[IETF]]'s SIDR ("Secure Inter-Domain Routing") working group,<ref>{{Cite web|url=https://datatracker.ietf.org/wg/sidr/charter/|title=Secure Inter-Domain Routing (SIDR) |website=datatracker.ietf.org}}</ref> and are based on a threat analysis which was documented in RFC 4593. These standards cover BGP origin validation, while path validation is provided by [[BGPsec]], which has been standardized separately in RFC 8205. Several implementations for prefix origin validation already exist.<ref>[http://tools.ietf.org/html/rfc7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report (RFC 7128)], R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch, February, 2014</ref>

== 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 registry|regional Internet registries]], known as [[local Internet registry|local Internet registries]] (LIRs), to obtain a resource certificate listing the [[Internet number]] resources they hold. This offers them validatable proof of holdership, though 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 and ASNs they hold. These attestations are described below.

=== Route Origin Authorizations ===
A ''Route Origin Authorization'' (ROA)<ref>[https://www.rfc-editor.org/rfc/rfc9582.html A Profile for Route Origin Authorizations (ROAs)], J. Snijders, B. Maddison, M. Lepinski, S. Kent, D. Kong, May, 2024</ref> states which [[Autonomous system (Internet)|autonomous system]] (AS) is authorised to originate certain [[IP prefix]]es. 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 {{IPaddr|10.0.0.0|16}} and the maximum length is 22, the AS is authorised to advertise any prefix under {{IPaddr|10.0.0.0|16}}, as long as it is no more specific than {{IPaddr||22}}. So, in this example, the AS would be authorised to advertise {{IPaddr|10.0.0.0|16}}, {{IPaddr|10.0.128.0|20}} or {{IPaddr|10.0.252.0|22}}, but not {{IPaddr|10.0.255.0|24}}.

=== Autonomous System Provider Authorizations ===
An ''Autonomous System Provider Authorization'' (ASPA) states which networks are permitted to appear as direct upstream adjacencies of an autonomous system in BGP AS_PATHs.<ref>{{cite web |last1=Azimov |first1=Alexander |last2=Bogomazov |first2=Eugene |last3=Bush |first3=Randy |last4=Patel |first4=Keyur |last5=Snijders |first5=Job |last6=Sriram |first6=Kotikalapudi |title=BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects |url=https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-16 |publisher=Internet Engineering Task Force |date=29 August 2023}}</ref>

=== 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<ref>{{Cite report |url=https://datatracker.ietf.org/doc/rfc6483/ |title=Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) |last1=Huston |first1=Geoff |last2=Michaelson |first2=George G. |date=Feb 2012 |publisher=Internet Engineering Task Force |issue=RFC 6483}}</ref> of one or more route announcements. They can be:

* '''VALID'''
** The route announcement is covered by at least one ROA
* '''INVALID'''
** 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
* '''UNKNOWN'''
** 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.<ref>{{cite book |last1=Wählisch |first1=Matthias |last2=Maennel |first2=Olaf |last3=Schmidt |first3=Thomas C. |title=Proceedings of the ACM SIGCOMM  |chapter=Towards detecting BGP route hijacking using the RPKI |location=New York, NY, USA |publisher=Association for Computing Machinery |date=13 August 2012 |pages=103–104 |doi=10.1145/2342356.2342381}}</ref>

== Management ==
There are open source tools<ref>{{Cite web|url=https://github.com/dragonresearch/rpki.net|title=GitHub - dragonresearch/rpki.net: Dragon Research Labs rpki.net RPKI toolkit|date=November 23, 2019|via=GitHub}}</ref> 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.

== Publication ==
The system does not use a single repository publication point to publish RPKI objects. Instead, the RPKI repository system consists of multiple distributed and delegated 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.

== Validation ==
Relying party software will fetch, cache, and validate repository data using [[rsync]] or the RPKI Repository Delta Protocol (RFC 8182).<ref>{{Cite journal|url=https://datatracker.ietf.org/doc/rfc8182/|title=RFC 8182 - The RPKI Repository Delta Protocol|website=datatracker.ietf.org|date=July 2017 |last1=Bruijnzeels |first1=Tim |last2=Muravskiy |first2=Oleg |last3=Weber |first3=Bryan |last4=Austein |first4=Rob }}</ref>  It is important for a relying party to regularly synchronize with all the publication points to maintain a complete and timely view of repository data.  Incomplete or stale data can lead to erroneous routing decisions.<ref>{{Cite book |last1=Kristoff |first1=John |last2=Bush |first2=Randy |last3=Kanich |first3=Chris |last4=Michaelson |first4=George |last5=Phokeer |first5=Amreesh |last6=Schmidt |first6=Thomas C. |last7=Wählisch |first7=Matthias |title=Proceedings of the ACM Internet Measurement Conference |chapter=On Measuring RPKI Relying Parties |date=2020-10-27 |chapter-url=https://doi.org/10.1145/3419394.3423622 |series=IMC '20 |location=New York, NY, USA |publisher=Association for Computing Machinery |pages=484–491 |doi=10.1145/3419394.3423622 |isbn=978-1-4503-8138-3|s2cid=225042016 }}</ref><ref>{{Cite book |last1=Kristoff |first1=John |last2=Bush |first2=Randy |last3=Kanich |first3=Chris |last4=Michaelson |first4=George |last5=Phokeer |first5=Amreesh |last6=Schmidt |first6=Thomas C. |last7=Wählisch |first7=Matthias |title=Proceedings of the ACM Internet Measurement Conference |chapter=On Measuring RPKI Relying Parties |date=2020-10-27 |chapter-url=https://dl.acm.org/doi/10.1145/3419394.3423622 |language=en |publisher=ACM |pages=484–491 |doi=10.1145/3419394.3423622 |isbn=978-1-4503-8138-3|s2cid=225042016 }}</ref>

== 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),<ref>{{Cite journal|url=https://datatracker.ietf.org/doc/rfc6810/|title=RFC 6810 - The Resource Public Key Infrastructure (RPKI) to Router Protocol|website=datatracker.ietf.org|date=January 2013 |last1=Bush |first1=Randy |last2=Austein |first2=Rob }}</ref> [[Cisco Systems]] offers native support on many platforms<ref>{{cite web|url=http://www.ripe.net/lir-services/resource-management/certification/router-configuration#Cisco|title=RPKI Configuration with Cisco IOS|work=[[RIPE]]|access-date=2014-03-24|archive-date=2015-03-24|archive-url=https://web.archive.org/web/20150324121745/http://www.ripe.net/lir-services/resource-management/certification/router-configuration#Cisco|url-status=dead}}</ref> for fetching the RPKI data set and using it in the router configuration.<ref>{{Cite web|url=https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html|title=Cisco IOS IP Routing: BGP Command Reference - BGP Commands: M through N [Support]|website=Cisco}}</ref> Juniper offers support on all platforms<ref>{{Cite web|url=https://www.juniper.net/documentation/en_US/junos12.2/topics/topic-map/bgp-origin-as-validation.html|title=Example: Configuring Origin Validation for BGP - Technical Documentation - Support - Juniper Networks|website=www.juniper.net}}</ref> that run version 12.2 or newer. [[Quagga (software)|Quagga]] obtains this functionality through BGP Secure Routing Extensions (BGP-SRx)<ref>{{Cite web|url=https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-prototype|title=BGP Secure Routing Extension (BGP‑SRx) Prototype|date=August 15, 2016|website=NIST}}</ref> or a RPKI implementation<ref>{{Cite web|url=https://github.com/rtrlib/quagga-rtrlib|title=Quagga with RPKI-RTR prefix origin validation support: rtrlib/quagga-rtrlib|date=May 10, 2019|via=GitHub}}</ref> fully RFC-compliant based on RTRlib. The RTRlib<ref>{{Cite web|url=http://rpki.realmv6.org/|title=RTRlib - The RPKI RTR Client C Library|website=rpki.realmv6.org}}</ref> 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.<ref>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.</ref> 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.

== References ==
{{Reflist}}

== External links ==
* [https://isbgpsafeyet.com/ Tool provided by Cloudflare to test if ISP is doing RPKI validation]
* [https://rpki.cloudflare.com/ Tool by Cloudflare to explore RPKI]
* [https://rpki.readthedocs.io/ Open source RPKI Documentation]
* [https://web.archive.org/web/20140324124241/http://isoc.org/wp/ietfjournal/?p=2438 IETF Journal - Securing BGP and SIDR]
* [https://www.rpki-client.org/ rpki-client, a RPKI Cache Validator developed as part of the OpenBSD operating system]
* [https://github.com/dragonresearch/rpki.net/ An open source implementation of the complete set of RPKI protocols and tools]
* [https://rpki.realmv6.org/ RTRlib - Open source RPKI-Router Client C Library]
* [https://nlnetlabs.nl/projects/rpki/about/ NLnet Labs open source RPKI tools developed in Rust]
* [https://github.com/rtrlib/quagga-rtrlib Quagga RPKI implementation]
* [https://www.nist.gov/services-resources/software/bgp-secure-routing-extension-bgp-srx-prototype BGP-SrX - Quagga router implementation of RPKI-based Origin and Path validation.]
* [http://rpki-monitor.antd.nist.gov/ RPKI-Monitor - Global and regional monitoring and analysis of RPKI deployment and use.]
* [https://certification-stats.ripe.net/ RPKI Deployment statistics for all RIRs]
* [http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png Global ROA deployment heatmap]
* [https://web.archive.org/web/20120404014109/http://rpki01.fra2.de.euro-transit.net/ EuroTransit GmbH RPKI Testbed]
* [http://bgpmon.net/blog/?p=414 BGPMON - Validating BGP announcement with RPKI] {{Webarchive|url=https://web.archive.org/web/20110120212349/http://bgpmon.net/blog/?p=414 |date=2011-01-20 }}
* [http://www.apnic.net/services/services-apnic-provides/resource-certification/RPKI An APNIC primer on RPKI]
* [https://www.ripe.net/manage-ips-and-asns/resource-management/rpki RIPE NCC Resource Certification (RPKI) information]
* [https://www.lacnic.net/640/2/lacnic/resource-certification-system-rpki LACNIC RPKI Information]
* [https://www.arin.net/resources/manage/rpki/ ARIN RPKI Information]
* [https://www.nro.net/nro-declaration-on-rpki NRO statement on RPKI]
* [https://mailarchive.ietf.org/arch/msg/ietf-announce/yp84S3_x2P9knQoQtIqRrVhnAKI/ Internet Architecture Board statement on RPKI]
* [https://web.archive.org/web/20110810202155/http://blog.internetgovernance.org/blog/_archives/2010/9/7/4624281.html Building a new governance hierarchy: RPKI and the future of Internet routing and addressing]
* [https://web.archive.org/web/20120206105421/http://www.ir.bbn.com/sbgp/IEEE-JSAC-April2000/IEEE-JSAC-S-BGP.html Secure Border Gateway Protocol (Secure-BGP)]
* [https://datatracker.ietf.org/doc/html/rfc7128 RPKI Router Implementation Report]

[[Category:Public-key cryptography]]
[[Category:Routing protocols]]
[[Category:Internet architecture]]