IAB statement on the RPKI.

= 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