This is an invited article to describe a specific implementation and operational perspective on a developing IETF specification, RPKI.
Routing on the Internet is a system that depends on every network operator working together, and in most cases working around other people’s mistakes by routing differently until the source problem is fixed. Today, the vast majority of mis-announcements are accidental originations of someone else’s prefix. But routing errors have a high customer impact because entire networks can become unreachable. In a sense, we are lucky that more problems do not occur, and we can still point to the YouTube vs. Pakistan Telecom incident as a recent example, even though that happened in early 2008. Still, there is an urgent need to make this system more robust before a routing event occurs that causes major, widespread problems.
Now that there are no longer any IPv4 addresses in the IANA pool, the registry function of the five regional Internet registries (RIRs) is more important to the Internet community than ever. People are going to be searching all nooks and crannies for the remaining IPv4 addresses and this may not always be done in an orderly fashion. It is extremely important to know who is the legitimate holder of a block of IP addresses.
This has always been one of the main drivers behind the RIRs’ plans to deploy a system that attaches digital certificates to Internet number resources (IP address blocks and AS numbers). This resource certification system is based on PKI (Public Key Infrastructure) principles. A resource certificate is an electronic document proving that its holder has been officially assigned or allocated a particular Internet resource, which means a block of IPv4 or IPv6 addresses, or an AS Number. This takes shape in the form of an X.509 certificate with “Extensions for IP Addresses and AS Identifiers” as described in RFC 3779.
Even though the vulnerabilities of Border Gateway Protocol (BGP) were identified in the 1980s, work on making it more robust started in 2000, when Stephen Kent, Charles Lynn, and Karen Seo published Secure Border Gateway Protocol (S-BGP), their paper on Secure-BGP. The goal is to perform origin validation to prevent damage caused by accidental misconfiguration and misorigination. Preventing malicious attacks requires path validation, which is a lot more complex to solve. Discussions on arecharter of the IETF Secure Inter-Domain Routing working group to cover this aspect have recently started.
In 2006, the RIPE NCC started working on a resource certification system. ARIN and APNIC had started work on an implementation a year before that. Resource certification mirrors the way in which Internet number resources are distributed. That is, resources are initially distributed by the IANA to the RIRs, which in turn distribute them to local Internet registries (and, in some regions, national Internet registries), which then distribute the resources to their customers. In this implementation, initially the RIRs become certificate authorities, issuing X.509 certificates along with Internet resources.
Since the launch of the Resource Certification service in the beginning of this year, hundreds of local Internet registries (LIRs) have enabled the service, providing them with several benefits. First, certification verifies the legitimacy of a resource’s allocation or assignment by an RIR. In other words, it offers validated proof of holdership. This can be vital when transferring Internet resources between parties. How can you confirm who is the rightful holder of the addresses? How can you be sure this block hasn’t already been sold? Certification helps to make resource transfers reliable and secure.
Second, there is the routing aspect. It’s one thing to have people claim address blocks that are not theirs, it’s another for them to actually use those addresses on the Internet. We live in a world where any network operator can announce any prefix on their router, either intentionally or by mistake. We currently have Internet routing registries (IRRs) to help mitigate this issue, but there are more than 30 IRRs, with no means of confirming that all of the information in those IRRs is actually correct.
The resource certification system allows for the prefix holder checking to be automated in a dependable, transparent, and standardized way. It has the potential to streamline ISP workflows while facilitating better routing security.
The system works through the creation of Route Origin Authorization (ROA) objects. An ROA is a standardized document stating that the holder of a certain prefix authorizes a particular Autonomous System (AS) to announce that prefix. A valid ROA can only be created by the holder of the certificate for that address space. Anyone on the Internet can now validate if a route announcement is authorized by the legitimate holder of the address space. Several router manufacturers have committed to building certification support into their hardware, further expanding the potential.
When building the roadmap for the certification service the RIPE NCC offers, we had to make critical decisions on which features to offer that the standards describe. We made a conscious choice to start with a limited feature set, and expand it over time as the IETF standards matured. In order to make the entry barrier into the system as low as possible, initially we are providing a hosted solution only. This means an LIR can log into a secured portal and generate a resource certificate covering their Internet number resources. The certificate is generated on the system and it not retrievable from the hardware security modules (HSM) we have in place. This creates a dilemma, because anyone who understands security will argue that you should always be the holder of your own private key, in all cases.
In the end, though, we felt that quite a number of organizations would understand and accept the security trade-off of not being the owner of the private key for their resource certificate and trust their RIR to run a properly secured and audited service. Moving forward, we will focus on expanding the feature set of the service by making it possible for LIRs to run their own, local certificate authority that interfaces with the RIPE NCC.
Second, we will build a notification system that warns the user if ROAs do not match real-world routing and lastly, we will work on a more comprehensive validator.
Find more information here.
Alex Band is product manager at the RIPE NCC