Skip to main content

IAB statement on the RPKI
statement-iab-2010-statement-on-the-rpki-00

Document Type IAB Statement
Title IAB statement on the RPKI
Published 2010-01-27
Metadata last updated 2023-08-09
State Active
Send notices to (None)
statement-iab-2010-statement-on-the-rpki-00

RPKI as a prerequisite for improving the security of the global routing system

To date, the Internet has operated without a secure means to certify the allocation of Internet number resources, particularly Autonomous System (AS) numbers and IP addresses. The pending exhaustion of the IPv4 address space, coupled with a pressing need to improve the security of the global Internet routing system, has given impetus to the development of a resource certification infrastructure for the Internet. A consistent shared view around the world of which number resources are allocated to whom is essential for the reliable operation of the Internet as it continues to grow. The IETF Secure Inter-domain Routing (SIDR) Working Group (WG) has been working with the various stakeholders to specify a Resource Public Key Infrastructure (RPKI) system that can be used to certify these resource allocations in order to substantially improve the security of the routing system.

The IAB considers a properly designed and deployed RPKI to be an absolute prerequisite to having a secure global routing system, which is in turn a prerequisite to having a reliable worldwide Internet. In its absence, there is no formally verifiable authoritative source to determine the allocation for any Internet number resource. Consequently, before originating, propagating, or accepting an IP address prefix, each routing domain must individually assess the consistency of that prefix with whatever information can be obtained about actual allocations. This loose “routing by rumor” approach provides considerable flexibility to each routing domain, but the negative consequences are severe. The global routing system is vulnerable to large-scale disruptions through both misconfiguration and malice. These vulnerabilities can be substantially reduced through the use of an RPKI. Through proper design and wide-scale deployment, an RPKI enables network operators to generate their routing policies from securely verifiable allocation data, providing much higher confidence in the authenticity of routing information.

Technical considerations with respect to the design of the PKI

For any PKI, a certification hierarchy must exist that allows parties to ascertain the validity of a given certificate. The SIDR architecture uses a certification hierarchy, and relying parties must explicitly place trust in the top-level of the hierarchy, commonly called a trust anchor. The SIDR architecture and protocols have been designed to support a single trust anchor as well as multiple trust anchors. The IAB however, is in strong agreement with the Number Resource Organization (NRO) (made up of the five Regional Internet Registries (RIRs)) regarding the number of trust anchors as well as what and whom they represent:

  1. the RPKI should have a single authoritative trust anchor

  2. this trust anchor should be aligned with the registry of the root of the allocation hierarchy

The reasoning is of a technological nature and is as follows. A single root for the certification hierarchy significantly reduces the risk of two or more parties accidentally (or maliciously) issuing conflicting certifications for the same address block, because a single authoritative entity at the top-level of the allocation hierarchy is authoritative for both (a) the allocation of the address block and (b) the cryptographic certification of the fact that it did indeed allocate that address block.

Thus, the IAB strongly recommends a single root aligned with the root of the address allocation hierarchy (now part of the IANA function). Doing so will minimize unnecessary complexity in the system, in particular virtually eliminating the possibility of resource conflicts in the system, reducing substantially the likelihood of errors as the allocation and certificate generation can be done together by the same operator.

Implementation considerations

The notion of having a certification hierarchy with multiple equally trusted roots may be appealing from a social and political perspective because of ‘fairness’ and ‘equality’ arguments. But that notion allows different organizations to make inconsistent and conflicting assertions about to whom a particular address block has been allocated. In the case of conflicting assertions, the conflict would need to be solved by each relying party, requiring each relying party to have their own security policy and the associated increased  complexity. Such an approach does not provide any guarantee that the outcome would lead to a globally coherent view of which resources have been allocated to whom.

It should be noted that mistakes in and attacks on the allocation process are possible, and that sensible caution and fallback plans still remain necessary. Therefore, architecturally, the set of trust anchors employed by a relying party application remains strictly a local matter. In practice relying parties will likely employ local policy files (e.g., for local address spaces such as RFC 1918 spaces used internally) and trust anchors that reflect local security decisions. Therefore the existence of a single root for the certification hierarchy does not give that root unilateral control over the Internet. Individual network operators choose to trust the information given by that root, based on operational experience that the information given by that root is trustworthy. If they find it to be untrustworthy, they are free to ignore it and instead enforce policy based on what they believe to be more appropriate data. The fact that the relying parties choose to trust the root only so long as it proves itself to be trustworthy gives the organization operating the root a strong incentive to ensure that the information they give is accurate and correct, thereby making it rare for network operators to have any reason to distrust it.

Mechanisms to support local decisions about trust anchors, while still maintaining compatibility with RFC 3779 certificate processing, are currently being considered by the SIDR working group. This statement is not to be interpreted as in conflict with these goals; rather, it is concerned solely with the structure of the RPKI certification hierarchy, as represented in the public repository system and aligned with the Internet number resource allocation hierarchy.

Concluding remarks

The IAB commends the RIRs for their investment and leadership in developing an RPKI system that can be used for digital certification of Internet number resources, as well as enabling a foundation upon which a secure Internet routing system can be developed.

– IAB, Jan 27, 2010