Resource Public Key Infrastructure

Resource Public Key Infrastructure
Name	Resource Public Key Infrastructure
Abbreviation	RPKI
Purpose	Cryptographic verification of Internet number resource origination
Started	2010s
Governing	Regional Internet Registries

Resource Public Key Infrastructure

Resource Public Key Infrastructure provides a cryptographic framework to validate Internet number resource origination and authorization. It connects Internet Assigned Numbers Authority, Internet Corporation for Assigned Names and Numbers, Regional Internet Registry, Internet Engineering Task Force, and routing operators with signed attestations to improve trust in Border Gateway Protocol, Autonomous System Number, and IP prefix announcements. The system complements operational practices used by network operators, Network Time Foundation, Internet Society, and standards bodies to reduce route hijacking, route leaks, and configuration errors.

Overview

RPKI binds Internet number resources to public keys via a hierarchical chain that starts with IANA and extends through American Registry for Internet Numbers, RIPE NCC, Asia Pacific Network Information Centre, Latin American and Caribbean Network Information Centre, and African Network Information Centre to individual holders. The framework produces Route Origin Authorizations and Delegated Certificates that interoperate with routers running software from vendors such as Cisco Systems, Juniper Networks, Arista Networks, Huawei Technologies, and open-source projects like Bird (routing daemon), Quagga, and FRRouting. RPKI integrates with protocols and standards developed by IETF, including Resource Public Key Infrastructure (RFC) specifications, and it relates to operational initiatives led by Mutually Agreed Norms for Routing Security, MANRS, and operator forums such as North American Network Operators' Group and European Network Operators' Group.

History and Development

Early ideas for securing routing trace to work by researchers at IETF and proposals influenced by incidents involving YouTube blackouts, Panama Papers-era routing misconfigurations, and notable outages reported by The New York Times. Formal development advanced through steering and working groups featuring contributors from RIPE NCC, ARIN, APNIC, LACNIC, and AFRINIC as well as vendors like Cisco Systems and researchers at MIT, Stanford University, and ETH Zurich. Pilot deployments and operational experiments occurred alongside efforts by Internet Society and policy debates within registries and governments including European Commission, Federal Communications Commission, and national regulators. The protocol suite became standardized through RFCs adopted by the IETF and saw production rollouts by content providers like Google, Amazon (company), and Facebook to protect their IP announcements.

Architecture and Components

RPKI's architecture relies on a certificate hierarchy rooted at IANA that issues resource certificates to Regional Internet Registry entities and further to resource holders. Key artifacts include Route Origin Authorizations (ROAs), manifests, signed objects, and Certificate Revocation Lists maintained in distributed repositories hosted by registries, cloud providers like Amazon Web Services and Cloudflare, and third-party hosts. Validation software and validators—produced by projects such as RIPE NCC RPKI Validator, Fort Validator, and RPKI.net tools—consume repositories via the RPKI Repository Delta Protocol and publish validated data to routers using mechanisms like RPKI-to-Router protocol. The design interacts with routing stacks implementing BGP, Autonomous System strategies, and policy systems operated by organizations such as Akamai Technologies, Verizon Communications, and research networks like GEANT.

Operation and Validation Processes

Operators create ROAs asserting which Autonomous System Number may originate a given prefix; validators fetch signed objects from repositories run by Regional Internet Registry entities and verify the chain of trust back to IANA. Validated data categorizes route origins as valid, invalid, or unknown; network devices apply route filtering or preference policies in response, using control-plane integrations supported by vendors including Cisco Systems, Juniper Networks, and open-source routers such as BIRD. Monitoring and measurement communities including RouteViews, RIPE RIS, and academic groups at University of Oregon and Carnegie Mellon University study effectiveness via BGP data sets. Operational procedures include certificate issuance, periodic renewal, revocation handling, and contingency planning coordinated with entities like MANRS and regional registries.

Security Considerations and Threats

RPKI mitigates origin spoofing, prefix hijacking, and some route leaks but introduces dependencies on certificate authorities and repositories such as Regional Internet Registry infrastructure and cloud hosts. Threat models consider compromise of private keys, misissuance by registries, repository manipulation, and availability attacks like distributed denial-of-service, affecting reachability for stakeholders including content providers Netflix, Microsoft, and critical infrastructure operators. Security controls draw on best practices from NIST guidance, operational audits by Internet Society, and cryptographic algorithms vetted by standards bodies such as IETF and research at ETH Zurich and University of Cambridge.

Deployment and Adoption

Adoption progressed through mandates, best-current-practice recommendations from IETF and advocacy by MANRS, with major networks and cloud providers deploying validators and publishing ROAs. Large-scale adopters include content delivery networks, cloud platforms, and telecom carriers such as AT&T, Vodafone, Deutsche Telekom, NTT Communications, and backbone providers visible in global routing tables studied by RouteViews and RIPE NCC. Deployment challenges influenced policy debate at forums like ICANN meetings, regional Internet registry meetings, and operator gatherings including NANOG and RIPE community events.

Criticisms and Controversies

Critics highlight centralization risks tied to Regional Internet Registry and IANA roles, potential single points of failure, and operational complexity that may disadvantage smaller operators and research networks. Policy disputes emerged among registries, governments such as United States Department of Commerce, and stakeholders like large content providers over governance, transparency, and dispute resolution. Academic critiques from University of Oxford and practitioners in operator groups question measurement evidence and call for complementary safeguards, transparency logs, and improvements to tooling and policy coordination.

Category:Internet security