RPKI

RPKI
Name	RPKI
Full name	Resource Public Key Infrastructure
Introduced	2011
Subtype of	Public Key Infrastructure
Purpose	Route Origin Validation for IP address space and Autonomous System Numbers
Maintained by	Regional Internet Registries, Internet Assigned Numbers Authority

RPKI

RPKI provides a cryptographic framework that binds Internet number resources to public keys to enable validation of route origination in the Border Gateway Protocol. It is designed to reduce prefix hijacking and misconfiguration by allowing network operators to verify that an Autonomous System is authorized to announce specific IP prefixes. Major stakeholders include Regional Internet Registries, network operators, standards bodies, and hardware vendors who integrate validation into routing stacks.

Overview

RPKI emerged from Internet Engineering Task Force efforts and coordination among Internet Assigned Numbers Authority, American Registry for Internet Numbers, RIPE NCC, Asia-Pacific Network Information Centre, African Network Information Centre, Latin America and Caribbean Network Information Centre, and initiatives like MANRS. The system issues cryptographic attestations called Route Origin Authorizations that reference Internet number resources administered by those registries. RPKI complements operational practices promoted by IETF documents, and its deployment intersects with protocols and implementations by vendors such as Cisco Systems, Juniper Networks, Arista Networks, and routing suites like BIRD and OpenBGPD.

Architecture and Components

RPKI's architecture rests on a hierarchical certificate model mapped to Regional Internet Registries and resource holders. Core components include Certificate Authorities managed by IANA and RIRs, Route Origin Authorizations issued by resource holders, signed manifests, and a distributed repository system. Software implementations and validators are produced by projects such as RIPE NCC RPKI Validator, NLnet Labs Routinator, Isbgp-rpki-client, Cisco RPKI Validator, and academic prototypes from institutions like MIT and Stanford University. The architecture leverages standards from working groups like IETF SIDROPS and tools integrated with routing suites including FRRouting and control-plane systems used by providers like AT&T, Verizon Communications, NTT Communications, and cloud operators such as Amazon Web Services, Google, and Microsoft Azure.

Operation and Workflow

In practice, a resource holder uses a repository or RIR portal to create a digitally signed attestation that authorizes an Autonomous System Number to originate a prefix. Network operators run RPKI validators to fetch Certificate Revocation Lists, manifests, and ROAs from distributed publication points maintained by RIRs, network operators, or repositories like those operated by APNIC, ARIN, LACNIC, AFRINIC, and RIPE NCC. Validators propagate validated state to routers using protocols and mechanisms supported by vendors and communities including IETF BGP Monitoring Protocol extensions and Router APIs used by Juniper Networks and Cisco Systems. Operational workflows are discussed in operational forums such as NANOG, RIPE Meetings, APRICOT, and IETF Meetings and adopted by large networks including Level 3 Communications, CenturyLink, Deutsche Telekom, and content providers like Cloudflare and Akamai Technologies.

Security and Trust Model

The trust anchor of the system is rooted in Internet number registries that allocate prefixes and Autonomous System Numbers; these trust anchors are managed by organizations such as IANA and the Regional Internet Registries. Cryptographic algorithms standardized by IETF provide signature and certificate formats aligned with suites supported by implementations from OpenSSL-based stacks and alternatives developed in research from University of Cambridge and ETH Zurich. The model establishes a chain of trust from RIR-signed certificates down to ROAs and signed objects; validation results categorize route announcements as valid, invalid, or unknown, influencing routing policy. Threat models and mitigations have been analyzed in academic venues including USENIX Security Symposium, SIGCOMM, and ACM CCS, with operational incident handling coordinated through operator communities such as FIRST and CERT Coordination Center.

Deployment and Adoption

Adoption accelerated after RIRs and major operators endorsed route origin validation as best current practice. Large-scale deployments by backbone providers, content delivery networks, and cloud providers increased reliance on validated state in routing decisions. National and regional initiatives, including efforts by European Commission-linked programs and national registries, influenced uptake. Measurement studies from groups like CAIDA, RIPE Atlas, Merit Network, and university labs tracked deployment and impact on global routing tables. Commercial network equipment vendors, open-source routing suites, and managed validation services from operators such as NTT, Telia Company, and T-Mobile support operators of all sizes.

Criticisms and Limitations

Critiques focus on risks tied to centralization of trust in registries, operational complexity for multi-homed networks, and potential failures or misconfigurations leading to valid routes being marked invalid. Incidents involving mistaken ROAs and repository outages have been documented by operator forums including NANOG and RIPE Mailing Lists. Political and legal questions arise when number resource allocations intersect with disputes involving entities such as ICANN and national regulators. Research from UCLA, University of Twente, and ETH Zurich highlights issues in coverage, false positives, prefix granularity, and the need for complementary mechanisms like BGPsec and secure provenance proposals discussed at IETF SIDROPS and IETF IDR. Deployment remains uneven across regions and smaller networks despite progress among major providers.

Category:Internet architecture