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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
