Implementing RPKI: It’s Easier Than You Think [Archived]

By Andrew Gallo

At a recent Internet2 Technology Exchange, I gave a hands-on demonstration of Resource Public Key Infrastructure (RPKI) jointly with Internet2 Cyberinfrastructure Security Engineer, Karl Newall.  The goal of this demonstration, which was part of a year-long effort to increase RPKI adoption in the higher education and research community, was to show community members how easy it is to implement RPKI for campus networks.

Why Implement RPKI?

RPKI addresses a fundamental flaw in inter-domain routing: the lack of an authoritative relationship between a route announcement to the organization making the announcement.  The Internet route table is built through the cooperative effort of thousands of networks using the Border Gateway Protocol (BGP).  However, there is no mechanism in the protocol to verify the validity of the information it carries.  There are several mechanisms to protect the protocol itself.  For example, RFC 7454: BGP Operations and Security (aka Best Current Practice 194) discusses Generalized TTL Security Mechanisms (GTSM) and TCP Authentication Option (TCP-AO), both methods of securing the BGP application.  Also discussed in this RFC, are methods to filter the contents of BGP advertisements, including special purpose and unallocated prefixes. However, there is still a large gap in security: is the organization making a specific announcement in the global routing table the authorized entity allowed to make such an announcement?  RPKI addresses this shortcoming.

What’s involved in an RPKI Deployment?

There are two parts to an RPKI deployment: creating and distributing Route Origin Authorizations (ROAs), and collection and validation of ROAs.  We demonstrated both at this meeting.

There are two methods that can be used for creating ROAs: hosted, where ARIN runs the Certificate Authority (CA) and distribution infrastructure, and delegated, where a resource holder requests “up-down” access with ARIN and deploys its own CA.  Mark Kosters, ARIN CTO, recently presented at ARIN 40 and noted that only two organizations had requested delegated access, and only one had implemented it.  For the Internet2 meeting, we demonstrated hosted access in the Operational Test and Evaluation (OT&E) Environment. Recently, ARIN made access to the OT&E easier by allowing anyone with an ARIN Online account to access the environment without submitting a request for access.

We discussed the process of initially requesting hosted RPKI access.  Specifically, a Hosted Resource Certificate needs to be created by ARIN, which requires the requesting organization to provide the public portion of a 2048-bit RSA key pair.  Specific instructions can be found here.  This part of the process couldn’t be demonstrated in real-time, as it requires action from ARIN staff.  However, after this one-time activity is completed, requesting ROAs takes no more than a minute or two to complete a simple web form, and then just a few seconds for a ticket to be automatically opened, acted upon, and closed with the ROA created.

The goal of this exercise was to demonstrate how quickly and easily it is for an organization to generate the cryptological artifacts (ROAs) that can be used to verify its BGP announcements.  This is a low-effort, zero-cost way to announce to the world that your Autonomous System is authorized to announce a specific IPv4 or IPv6 prefix. I showed the RPKI Deployment Monitor operated by the National Institute of Standards and Technology (NIST), highlighting two key facts: 1) currently, less than 8% of the prefixes in the global route table are covered by ROAs; and 2) a regional analysis of RPKI shows that ARIN members lag behind our RIPE NCC colleagues by every measure (for example, number of ROAs and space covered.) In some cases we’re lagging behind LACNIC and AFRINIC.

The second major component of RPKI, ROA validation, was demonstrated by my peer, Karl Newall.  He showed RIPE’s validator and how it is configured and connected to both a Juniper and Cisco router. He presented the configurations necessary to get each router to use the information generated by the validating cache in BGP policy.  The challenge at this point is, of course, with over 90% of the route table not covered by ROAs, what is the appropriate routing policy for RPKI?  We discussed possible options such as setting LOCALPREF low for invalid routes, or setting LOCALPREF higher for valid vs. unknown routes.

How does this impact legacy space holders?

A few people in attendance raised a potential impediment to RPKI adoption: the issue of legacy address space.  Many organizations in the US research and education space received address space prior to ARIN’s creation.  As John Curran, ARIN President and CEO, has explained several times, including at the meeting where this demonstration was held, legacy address holders get the same services they had the day ARIN was created.  Any new ARIN services require some type of Registry Services Agreement (RSA) or Legacy RSA (LRSA) for legacy number resources).  The good news is that all IPv6 space is definitely covered by some type of agreement, allowing organizations to start participating in RPKI, at least for those resources. ARIN staff is also happy to assist legacy address holders if they want to bring their IPv4 resources under an RSA so they can utilize RPKI.

Ultimately, the goal of my RPKI demonstration was to encourage the creation of ROAs so that more of the route table is covered.  While not as challenging of a problem as IPv6 deployment, we appear to be suffering from a chicken-and-egg problem with RPKI.  By showing how easy it is to create ROAs, we’re encouraging our peers in the education and research network community to address the shortcomings in route origin validation.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.