[sig-policy] Fwd: IAB statement on the RPKI.
..T
> From: IAB Chair <iab-chair at ietf dot org>
> Date: February 12, 2010 3:55:43 AM MST
> To: IETF Announcement list <ietf-announce at ietf dot org>
> Cc: iab at iab dot org
> Subject: IAB statement on the RPKI.
> Reply-To: iab at iab dot org
>
>
>
> 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
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf dot org
> https://www.ietf.org/mailman/listinfo/ietf-announce