The curious policies in NIST’s proposed RPKI study

As part of its effort to improve the security of inter-domain routing traffic exchange, NIST has issued a request for comments on a proposed project to test RPKI and Route Origin Validation (ROV), a process by which route advertisements can be authenticated as originating from an expected Autonomous System (AS). The project’s results will feed into the development of a NIST Special Publication (SP 800-189 – in preparation) that will provide security recommendations for the use of inter-domain protocols and routing technologies.

Soliciting comments on the NANOG list, the project’s manager noted:

The objective of the project is to examine and demonstrate the state of the RPKI and BGP Origin Validation technologies in realistic scenarios and to address identified concerns with their deployment and use (e.g., security, robustness, management / monitoring, multi-vendor inter-operation)…This request is for industry input on the the proposed project plan. In particular we seek input from both network operators and enterprises on practical issues and barriers to adoption and suggestions for how these could be addressed in the project.

The project will explore two scenarios for ROV, “Hosted RPKI for ROV” and “Delegated RPKI for ROV”. Hosted RPKI is pretty much a turn-key deployment for address holders, relying heavily on the Regional Internet Registry (RIR) to generate and host key material used in ROV and the creation of Route Origin Authorizations (ROAs), i.e., the digitally signed information linking an AS and prefix(es).  Under the delegated RPKI, a more operator-controlled approach, the RIR is not required to host the private key of an AS’s delegated RPKI key pair. In this scenario, the address holder can host and delegate RPKI services to its customers who participate in BGP. Despite the relative independence that the address holder maintains under the delegated arrangement, the draft project description lays out certain requirements (lines 264-268):

To participate, the organization must have IPv4 or IPv6 prefixes that are obtained from an RIR. It also needs to have signed a Registration Services Agreement (RSA) to cover all resources (or ROAs) it needs to certify. The organization must have an account with its RIR to manage the resources it plans to certify.

One explanation for the requirements is that the RIRs operate the RPKI systems available to test, they also maintain registry information for address resources. However, these policy-like requirements also seem to prevent a large portion of address holders in the ARIN region from participating in the project. Many legacy address space holders got their numbers before the RIRs existed and have not signed an RSA. Isn’t the point of global standards adoption to have as wide a deployment as possible?

For the uninitiated, legacy space is IP address space obtained prior to the creation of the RIRs. Some estimate legacy space holders account for more than 40% of the address space in North America. They enjoy stronger property rights than operators who contract with RIRs for address space, and because of this legacy holders can be reluctant to enter a standard RSA contract with an RIR that might dilute those rights.  As we have previously reported, there are important policy differences between the RIRs. These differences appear to be affecting ROA creation. For example, the RIPE region has been the most successful at inducing network operators to create ROAs. This is, we believe, because “steps were taken to ensure that non-RIPE NCC members such as Provider Independent and Legacy Address Space holders could receive resource certificates.” We noted that “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.” Similar policies have not been pursued in the ARIN region, which lags far behind RIPE in ROA creation.

In summary, policy differences between the RIRs and their effects on Internet security remain an open and important area of research. It will not be surprising if the NIST project’s outcomes are unable to explain continued variation in RPKI deployment between regions.

[Update: According to ARIN, almost 25,000 IPv4 nets in ARIN region (or nearly 50%) are legacy. Another relevant tidbit, 50% of those legacy nets have no validated point of contact in ARIN Whois. The takeaway, ARIN policies that encourage legacy space holder engagement could help ensure accurate registry data and in turn support wider ROV and better Internet security.]


One comment

  1. Jean Camp

    I question the value of RIR and RPKI. What level of adoption is necessary for the protocols to reliably work? There are entities that must be trusted but may not be trustworthy, like the national CAs in the X.509 infrastructure. Many hijacks have been caused by subverted Tier 3 entities. The protocols do not defend against all kinds of attacks.
    The crypto is nice but the solutions may be expensive and not address the actual threats.