Suspect folks here might be interested in this.. -danny
Begin forwarded message: > From: IAB Chair <[email protected]> > Date: February 12, 2010 3:55:43 AM MST > To: IETF Announcement list <[email protected]> > Cc: [email protected] > Subject: IAB statement on the RPKI. > Reply-To: [email protected] > > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
