Introduction
Welcome back to our journey into the realm of Internet routing security! In our previous article, "Securing Internet Routing with Cryptography: Quick Introduction to RPKI," we delved into the foundational concepts of Resource Public Key Infrastructure (RPKI), its role in securing the Border Gateway Protocol (BGP), and real-world examples showcasing the need for robust routing security measures. Now, it's time to dive deeper into the intricate components and processes that make up the RPKI ecosystem.
As a follow-up to our initial exploration, this article aims to take our understanding of RPKI to the next level. Just as a building's foundation provides stability and support for its structure, our grasp of RPKI basics sets the stage for dissecting its moving parts and understanding how they collaboratively ensure secure Internet routing. If you missed the previous article, please read it here.
Now, let's take a step back and draw parallels to the world of orchestral music to help us understand the intricate components and processes that make up the RPKI ecosystem in "RPKI Moving Parts."
The Symphony of Routing Security
Imagine an orchestra, a harmonious group of musicians playing various instruments under the guidance of a conductor. Each musician contributes their unique skills to create a seamless and beautiful musical experience. Similarly, the RPKI ecosystem comprises different components that work together to ensure the security and integrity of Internet routing.
Unveiling the Orchestra: Components of RPKI
In this symphony of routing security, let me first introduce the key players:
- The Regional Internet Registries (RIRs): Our conductors who are the Certificate Authorities (CAs) and also provide the infrastructure for RPKI. The conductor issues digital certificates to validate IP prefixes ownership while providing the infrastructure where Operators document their routing security.
- Relying Parties (RPs): Skilled musicians relying on validated RPKI data for routing decisions.
- Validators: Scrutineers validate ROAs and certificates to maintain routing integrity.
- Route Origin Authorizations (ROAs): The sheet music guiding routers on authorised route origins.
Let’s now unravel and explore each component and its role in depth.
The Conductor: The Regional Internet Registries
In our metaphorical symphony, RIRs, including AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC act as conductors. These five organisations are entrusted by the Internet Assigned Numbers Authority (IANA) with authority over Internet Number Resources (INRs) such as IP addresses and ASNs. In the RPKI realm, they play a crucial role in maintaining the RPKI repository, which stores signed objects such as Route Origin Authorizations (ROAs) and certificates.
- Certificate Authority (CA) Role: With delegated authority from IANA, RIRs function as Certificate Authorities (CAs) within the RPKI framework, they are also referred to as Trust Anchors(TAs). They issue digital certificates to validate the ownership of IP address prefixes, ensuring the authenticity of route announcements.
- Ensuring Integrity and Security: By managing both the infrastructure and acting as CAs/TAs, RIRs ensure the integrity and security of Internet routing. They maintain an open and publicly accessible database containing signed information, enabling stakeholders to make informed routing decisions based on validated data.
By portraying RIRs as conductors managing the RPKI infrastructure and certificates, we highlight their pivotal role in maintaining a secure and reliable routing environment.
The Instruments: Relying Parties and Validators
Let's look into the essential roles played by Relying Parties (RPs) and Validators in the RPKI ecosystem, akin to skilled musicians in our symphony. RPs rely on validated RPKI data for informed routing decisions, while Validators validate Route Origin Authorizations (ROAs) and certificates issued by Certificate Authorities (CAs).
RPKI validators use cryptographic software to scrutinise all ROAs, obtaining Trust Anchor Locators (TALs) for all Regional Internet Registries (RIRs) for comprehensive coverage. Upon startup, an RPKI validator queries all RIR TAs and retrieves published certificates and ROAs using protocols like the RPKI Repository Delta Protocol (RRDP), standardised in RFC 8182.
The primary goal of an RPKI validator is to download ROAs from all TAs, validate them, and present a validated list to routers for secure routing decisions.
Validators act as local caches, regularly processing ROAs into validated ROA payloads (VRPs) containing crucial information such as IP prefixes, maximum lengths, and Origin AS numbers. These VRPs are derived from validated ROAs and form the validated cache necessary for routing decisions.
Various open-source RPKI validator tools such as Routinator, FORT Validator and rpki-client facilitate this process, offering flexibility and compatibility for different network environments.
Relying parties through BGP routers access the validated cache from RPKI validators using the RPKI to router protocol (RPKI-RTR), as described in RFC 6810 and RFC 8210. Offloading cryptographic verification to RPKI validators minimises impact on routers, ensuring efficient routing decisions without significant overhead or convergence time delays.
After receiving the validated cache containing Validated ROA Payloads (VRPs) from the RPKI validator, the router compares routing information in the BGP table with the VRPs. Where prefixes can be categorised into three states:
- Valid: The prefix matches a VRP, indicating it is authorised or more specific according to the maximum length in the VRP.
- Invalid: The prefix is advertised from an unauthorised ASN, possibly due to BGP hijacking or route leaks. This can occur if the ASN in the ROA and that of the VRP do not match or the prefix length in the route is more specific than the maximum length in the VRP.
- Not found: The prefix is not covered by any VRP.
By using the Validated ROA Payloads we ensure that authorised routing information is preferred over potentially compromised or unauthorised announcements.
The Sheet Music: Route Origin Authorisations (ROAs)
ROAs are akin to the sheet music guiding our symphony, specifying which Autonomous System Numbers (ASNs) are authorised to originate routes for specific IP prefixes. These authorisations, signed by Resource Holders (RHs) and validated by Certificate Authorities (CAs), ensure the legitimacy of route announcements and prevent route hijacks and leaks.
RIRs like AFRINIC provide portals such as MyAFRINIC for RHs to manage their resources and create cryptographically signed objects known as ROAs. These ROAs contain three key items, an Authorised ASN, an Originating prefix and a Maximum prefix length (maxLength).
Note: The maxLength parameter sets the maximum allowed prefix length. For instance, if an ROA covers 2001:db8::/32 with a maxLength of /33, the AS can advertise either one /32 prefix (2001:db8::/32) or two adjacent /33 prefixes (2001:db8::/33 and 2001:db8:8000::/33). Any prefixes more specific than /33, such as a /34, would be unauthorised.
Through the RIR portal, RHs can create, modify, or remove ROAs for their allocated prefixes and ASNs, ensuring precise control over routing authorisation and enhancing overall routing security.
The Performance: Processes and Interactions
As our symphony begins, the interactions between CAs, RHs, Validators, and RPs harmonise to validate route announcements and ensure routing integrity.
- CAs issue certificates to RHs, who create and publish ROAs in the RPKI repositories made available by RIRs, also known as Trust Anchors (TAs).
- Validators validate ROAs and certificates, providing validated data AKA validated cache to RPs for secure routing decisions.
- RPs rely on the Validated cache fed by Validators, to verify if a route is either Valid, Invalid or Not found. The routing policy is then informed by this information.
This seamless collaboration and mutual validation among RPKI components mirror a well-rehearsed orchestra, where each musician's precise coordination contributes to a flawless performance. Similarly, the orchestrated processes of RPKI create harmony in Internet routing, enhancing security and reliability across the digital landscape.
Wrapup: Creating Harmony in Internet Routing
Understanding the intricate mechanisms and interactions within the RPKI ecosystem is paramount to leveraging its full potential and fortifying Internet infrastructure against routing anomalies. Just as a symphony requires coordination among musicians and a conductor's guidance, RPKI relies on synchronised processes and trusted authorities to ensure routing security.
As we continue our exploration of RPKI, we unveil the layers of security and resilience it adds to the digital symphony of Internet routing. By embracing these principles while adopting best practices in RPKI deployment, organisations can contribute to a safer, more stable Internet for all users and entities reliant on secure routing protocols.
In our next blog in the RPKI Series, "RPKI Deployment Strategies: Getting Started,", we will delve into actionable steps and best practices for implementing RPKI within organisational networks. Stay tuned as we guide you through the initial stages of RPKI deployment and address common challenges to ensure a smooth and secure transition to enhanced routing security.
If you are interested in learning more on this topic, you can:
- Register for our free online course: Securing Internet Routing with IRR and RPKI
- You can find more detailed information about Internet Routing Security, RPKI, and MANRS compliance, at https://learn.nsrc.org/bgp
