It seems not a day goes by without another routing incident occurring. Whether a resource hijack, a route leak, or an entire network outage, the Internet’s routing system is like any other complex system involving multiple actors each making decisions reflecting their own processes, incentives and costs. In theory, adopting a technology like Resource Public Key Infrastructure (RPKI) [1] would offer operators one way to help secure their networks, and possibly reduce the occurrence of some incidents. But implementation in the real world poses problems that could undermine its effectiveness. By combining research in computer and social science, we are beginning to understand that data governance is the key to improving routing security.
1. Explaining variation across RIRs
Route Origin Authorizations (ROAs) data, which cryptographically links an authorized operator’s Autonomous System Number (ASN) with address prefix(es) they are authorized to originate as a route, is a fundamental piece of the RPKI. ROA data collected by RIPE (shown below) indicate vast differences between regions when looking at the number of prefixes found in ROAs. While the number of prefixes in ROAs remains tiny compared to the overall numbers of allocated, assigned or announced prefixes, the RIPE NCC region stands out with far more prefixes in ROAs.
What accounts for this difference? RPKI is a standardized protocol, and while some RIRs have spent more than others building systems to help operators manage ROAs, the process of creating them with an RIR is largely the same from a technical standpoint no matter the region. However, there are important differences between regions in RIR policies affecting ROA creation.
In particular, the RIPE community pursued a series of policies (shown in Table 1) that correspond to increasing numbers of prefixes in ROAs. In addition to developing a Certification Practice Statement (CPS), steps were taken to ensure that non-RIPE NCC members such as Provider Independent and Legacy Address Space holders could receive resource certificates. RIPE also went out of its way to clarify the delivery of registry services (including resource certification) to legacy address space holders who might prefer not to enter into a formal contract with RIPE NCC. Finally, at the end of last year, the conditions under which resource certificates could be revoked were codified. Each of these policies provided increasing clarity to network operators. In institutional economics speak, they reduced uncertainty about the “property rights” associated with address resources when certified.
| Policy | Date | Title | Summary |
| ripe-549 | Mar 2012 | RIPE NCC RPKI (Resource Public Key Infrastructure) Certification Practice Statement (CPS) | Describes RIPE’s RPKI participants, distribution of certificates and Certificate Revocation Lists, how certificates are issued, managed and revoked, facility management, key management and audit procedures. |
| ripe-596 | Oct 2013 | Policy for Resource Certification for non-RIPE NCC Members | Allows RIPE NCC to issue resource certificate for non-RIPE NCC members such as Provider Independent end users and Legacy Address Space holders. |
| ripe-639 | Mar 2015 | RIPE NCC Services to Legacy Internet Resource Holders | Defines basis for maintenance of registration data and delivery of registry services (including resource certification) to legacy Internet resource holders in the RIPE NCC service region. |
| ripe-676 | Dec 2016 | Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources | Defines conditions under which resource certificates will be revoked. |
Compare this to the ARIN region. ARIN developed a CPS as well. In addition, ARIN requires a terms of service (TOS) agreement to use its RPKI (RIPE actually has one too). The ARIN community failed in an attempt to create a policy equivalent of ripe-639, which would have granted legacy address holders in the region access to resource certification and other registry services. ARIN will only provide resource certification for operators that obtained resources from ARIN and that are under contract (RSA or LRSA). In the ARIN region we have a mixed bag when it comes to uncertainty. Legacy space holders have uncertainty about their address resources if they choose to use ARIN’s RPKI. ARIN’s TOS agreement could reduce uncertainty, but does so overwhelmingly in favor of ARIN. In interviews, operators indicated to us that the indemnification clause, holding ARIN harmless in its entirety, created too much risk for them. Given these differences in approach to RPKI, it is not surprising to see far lower levels of prefixes in ROAs in the ARIN region.
2. Policy differences across RIRs impact ROA validation
Creating ROAs is just one part of RPKI adoption. The other half is validation of ROAs by operators wishing to know the ROA data they observe is authentic. While it is difficult to know quantitatively the extent to which network operators are validating ROAs, there is qualitative evidence that at least one large operator would like to validate ROAs where possible, but variation in governance among the RIRs is apparently impacting that operator’s ability to do so.
In order to validate ROA data, an operator must implement validator software and obtain the trust anchor(s) (i.e., the public key) of the RPKI host(s). Some validators come preconfigured with trust anchor material. E.g., RIPE NCC’s RPKI validator ships with keys from all the RIRs. All, except ARIN’s. According to one large network operator, “the limited availability of the ARIN TAL [is] a showstopper for global RPKI deployment.” The concerns are both operational and legal. In the view of some operators, trust anchor data should be available widely (e.g., mirrored on multiple hosts), with the process for obtaining it reduced down to an automated script. Another sticking point is around ARIN’s Relying Party Agreement (RPA), a common feature of PKI Certificate Authorities. Any operator that wants access to ARIN’s TAL must “agree” to the RPA.
Currently, the ARIN TAL can only be downloaded from the ARIN website. According to ARIN, this explicit action supposedly binds the user to the RPA. This is probably debatable, but the more important issue is to what ARIN thinks operators are agreeing and why. Like ARIN’s RPKI TOS, the RPA also fully indemnifies the organization. ARIN points out that their indemnification clause “is remarkably similar to the indemnification clauses that are contained in many carriers’ Internet service contracts.” ARIN’s justification for their position is that “the introduction of origin validation into an ISP’s routing architecture has many operational considerations, and inherently includes the potential to readily impact the ISP’s primary business.” I.e., there is potentially significant risk involved, and the parties involved need to take it into account. Operators have suggested that ARIN could offer access to RPKI data in a way similar to Whois data, anonymously or with no warranties, or open up each agreement to negotiation. Each option is worth exploring, but could create additional or shift costs.
There are seemingly valid concerns on both sides. But one thing is certain. Understanding operational inter-dependencies, the (mis)alignment of actor incentives, and the transaction costs involved are all important considerations if we are to secure routing. In short, data governance is just as important as technology in improving routing security.
[1] RPKI is a specialized public key infrastructure, designed to allow network operators to make cryptographically verifiable attestations about the networks (identified by autonomous system numbers) and IP address resources they route, and allow other operators to validate those attestations. The RIRs offer “hosted RPKI” as a service where they serve as the root Certificate Authority of their RPKI. RPKI can also be hosted by operators themselves, but that introduces its own set of challenges.
