Resource Public Key Infrastructure (RPKI) is a relatively new standard for establishing BGP route origination. I wrote a brief introductory article here. Apologies for the self-promotion, but rather than rehash the basics here, I raise another issue that needs community attention: ARIN’s Relying Party Agreement (RPA: PDF link).
Having said that, some basics are needed. RPKI uses extensions to X.509 to contain IP address origination information and has two primary components: Route Origin Attestations (ROAs), which are certificates that attest to the validity of an Autonomous System originating an IP prefix. The second part is the route validation process, whereby network operators collect the ROAs of other operators, validate them, and then feed the results to the routing infrastructure for use in route policies. Collecting the ROAs uses rsync from Trust Anchor Locators (TALs), which are run by the five regional registries. One program used for such a purpose is RIPE’s RPKI Validator . LACNIC has a publicly accessible installation of the Validator. RIPE has a publicly accessible Juniper router. RPKI Validator comes with TALs preconfigured and active from the RIRs, all except for one: ARIN. ARIN requires that organizations wishing to use its TAL accept (via click-through) the RPA.
There was a lively discussion on NANOG recently on this topic. (in the interest of fairness: I started it). There are more than a couple of large organizations that have indicated they will not, or cannot, accept the RPA in its current form. The heart of the issue is the risk associated with running a relying service.
The goal of RPKI to provide a cryptographically secure and traceable method to assure that a specific ASN has the authority to announce one ore more IP prefixes. The RPKI ecosystem is designed with interfaces to allow operators to easily integrate this information into the routing infrastructure, making policy decisions based on validation state extremely easy. While not directly in the forwarding plane, or even directly in the control plane, RPKI has the potential to more tightly couple service provided by the registries with the operation of the global network. Ensuring that the service is both highly available and provides correct information is a concern for the registries (and of course, all operators).
The question is, what is the real risk to the organization providing the relying service? Are the implied agreements used by the world outside of the ARIN region enough?
Without RPKI, an operator either must trust that routes are properly originated or use some other method to attempt to validate the origin. Some operators have home-grown systems for using routing registry databases (such as RADB) and/or whois data. This is almost like RPKI except: a) it doesn’t have a cryptographically traceable trust chain to a recognized authority; and b) doesn’t have the standards based, multivendor interfaces among the various components. The irony is that the RIRs are, in the case of whois data, providing information that is being used in the near-real time policy process. We can infer that operators that have built such systems believe that this improves availability and service despite the possibility that the data may not always be available or even correct. ARIN’s whois service has an implied agreement (meaning, just using the service binds you to the agreement) disclaiming any risk from outages or incorrect information.
While I can see the concern about providing RPKI services, I would think an implied agreement indicating the service is provided AS-IS with no warranty would be enough. Do our equipment, or even more appropriate, software service, providers need indemnification clauses when purchasing? Mistakes and outages will happen with RPKI as happens with all technology. As operators, it is up to us to build systems that can withstand outages. I think at this stage in the Internet timeline, we’re fairly well versed in building highly available systems from unreliable components.
A thornier issue is the validity of information provided, and the possibility that a valid route may be mischaracterized as invalid, or a hijack one (misorigination) be marked as valid. Who is the victim in this situation (obviously the rightful originator, but also people trying to use services of the originator)- there could be many victims in different jurisdictions.
As the number and length of messages in the NANOG thread attest, there are greatly differing opinions. As it stands, with operators silently rejecting the RPA, RPKI, at least for ARIN resources, may not become fully functional. The very nature of the technology requires a high level of participation. Until most routes can be validated, it will be difficult to make good policy decisions. This creates an interesting situation: in order for my organization’s routes to be validated, your organization needs to accept the RPA. Your organizations relationship with ARIN is now of great concern to my organization.
Even with the widely varying opinions, I’m hopeful this problem can be solved. We need to enumerate the risks, mitigate them where possible, and where not, determine who bears the risk. My take on RPKI is that that current situation, with no origin validation, is a much riskier proposition than with it. I encourage you to share your opinion- there are any number of forums, but the most important one is going to be directly to ARIN.