--- 1/draft-ietf-grow-irr-routing-policy-considerations-01.txt 2013-11-04 08:14:27.299418761 -0800 +++ 2/draft-ietf-grow-irr-routing-policy-considerations-02.txt 2013-11-04 08:14:27.339419773 -0800 @@ -1,25 +1,25 @@ GROW Working Group D. McPherson Internet-Draft Verisign, Inc. Intended status: Standards Track S. Amante -Expires: November 4, 2013 Level 3 Communications +Expires: May 8, 2014 Level 3 Communications E. Osterweil Verisign, Inc. L. Blunk Merit Network, Inc. D. Mitchell Twitter, Inc. - May 3, 2013 + November 4, 2013 IRR & Routing Policy Configuration Considerations - + Abstract The purpose of this document is to catalog past issues influencing the efficacy of Internet Routing Registries (IRR) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 4, 2013. + This Internet-Draft will expire on May 8, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,32 +63,32 @@ 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3 4. Accuracy and Integrity of Data Contained within the IRR . . . 4 4.1. Lack of Resource Certification . . . . . . . . . . . . . . 4 4.2. Incentives to Maintain Data within the IRR . . . . . . . . 5 4.3. Inability for Third Parties to Remove (Stale) Information from the IRRs . . . . . . . . . . . . . . . . 6 - 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 6 - 4.5. Conclusions with respect to Data in the IRR . . . . . . . 7 + 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7 + 4.5. Conclusions with respect to Data in the IRR . . . . . . . 8 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8 5.1. Replication of Resources Among IRRs . . . . . . . . . . . 8 5.2. Updating Routing Policies from Updated IRR Resources . . . 9 6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11 7. Historical Limitations of Routers . . . . . . . . . . . . . . 12 7.1. Incremental Updates to Policy on Routers . . . . . . . . . 12 - 7.2. Storage Requirements for Policy on Routers . . . . . . . . 12 + 7.2. Storage Requirements for Policy on Routers . . . . . . . . 13 7.3. Updating Configuration on Routers . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . . 14 @@ -150,44 +150,57 @@ the methods related to extraction of policy from the IRR and the input plus activation of that policy within routers. 4. Accuracy and Integrity of Data Contained within the IRR The following section will examine issues related to accuracy and integrity of data contained within the IRR. 4.1. Lack of Resource Certification + Internet number resources include IPv4 addresses, IPv6 addresses, + Autonomous System Numbers (ASNs), and more. While these resources + are generally allocated by hierarchical authorities, a general + mechanism for formally verifying (such as through cryptographic + mechanisms) when parties have been allocated resource remains an open + challenge. We generally define such a system a Resource + Certification System, and we note that some candidate examples of how + such a general system might be implemented and deployed exist + [RC_HotNetsX], [RFC6480]. + One of the largest weaknesses often cited with the IRR system is that the data contained within the IRRs is out of date or lacks integrity. - This is largely attributable to the fact that historically there has - existed no method for developing cryptographically verifiable - bindings of an IP prefix to the originating Autonomous System (AS). - That is, there has never existed a resource certification - infrastructure that enables a resource holder to authorize a - particular autonomous system to originate network layer reachability - advertisements for a given IPv4 or IPv6 prefix. It should be noted - that this is not a weakness of the underlying Routing Policy - Specification Language (RPSL) [RFC2622], but rather, was largely the - result of no clear demand by the operator community for Internet - Number Resource Registries to provide sufficient resource - certification infrastructure that would enable a resource holder to - develop a cryptographic binding between, for example, a given AS - number and an IP prefix. + This is largely attributable to the fact that existing IRR mechanisms + do not provide ways for a relying party to (cryptographically) verify + the validity of an IRR object. That is, there has never existed a + resource certification infrastructure that enables a resource holder + to authorize a particular autonomous system to originate network + layer reachability advertisements for a given IPv4 or IPv6 prefix. + It should be noted that this is not a weakness of the underlying + Routing Policy Specification Language (RPSL) [RFC2622], but rather, + was largely the result of no clear demand by the operator community + for Internet Number Resource Registries to provide sufficient + resource certification infrastructure that would enable a resource + holder to develop a cryptographic binding between, for example, a + given AS number and an IP prefix. Another noteworthy (but slightly different) deficiency in the IRR system is the absence of a tangible tie between the resource and the - resource holder. If a resource holder's authorization cannot be - certified, then consumers cannot verify attestations made. In - effect, without resource certification, consumers are basically only - certifying the assertions that the creator / maintainer of the - resource object has made (not if that assertion is valid). + resource holder. That is, generally there is no assurance of the + validity of objects at their creation time (except for a subset of, + for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE + address holders and RIPE ASN holders). If a resource holder's + authorization cannot be certified, then consumers cannot verify + attestations made. In effect, without resource certification, + consumers are basically only certifying the assertions that the + creator / maintainer of the resource object has made (not if that + assertion is valid). The RIPE community addressed this last issue by putting in a foundation policy [RIPE2007-01], which requires a contractual link between the RIPE NCC and the end user in direct assignment + ASN assignment cases, which weren't previously covered by LIR contracts for address allocations. There were a couple of intentions with this policy: 1. There was an encumbrance placed in the policy for the LIR to charge the end-user for provider independent resources. This @@ -196,20 +209,25 @@ 2. It guaranteed that all RIPE NCC allocated/assigned space would be subject to a contractual link, and that this contractual chain might end up actually meaning something when it came to the issue of who made what claim about what number resource. 3. It tied into the RIPE NCC's object grandfathering policy which ties the registration details of the end-user to the object registered in the IRR database. + While this policy specifically addressed PI/portable space holders, + other regions address this issue, too. Further, it is indeed a + prerequisite for resource certification, though it does not directly + address the IRR deficiencies. + One of the central observations of this policy was that without a chain-of-ownership functionality in IRR databases, the discussion of certifying their contents becomes moot. 4.2. Incentives to Maintain Data within the IRR A second problem with data contained in the IRRs is that the incentives for resource holders to maintain both accurate and up-to- date information in one, or more, IRRs; including deletion of out-of- date or stale data from the IRRs can diminish rapidly when changing @@ -376,21 +394,21 @@ an ISP is evaluating resources in an IRR just to determine if there are any modifications to those resources that will ultimately be reflected in a new routing policy that will get propagated to (Edge) routers in the ISP's network. Cache locality results in reduced bandwidth utilization for each round trip. On the other hand, it is unclear from where the current provider replication interval of 24 hours originated or even whether it still provides enough freshness in the face of available resources, particularly in today's environment where a typical IRR system - consists of a (multi-core) multi-Ghz CPU connected to a network via a + consists of a (multi-core) multi-GHz CPU connected to a network via a physical connection of 100 Mbps or, more likely, higher bandwidth. In addition, it can be observed that the most common circuit size used by ISPs is now 10 Gbps, thus eliminating bandwidth as a significant factor in the transfer of data between IRRs. Furthermore, it should be noted that Merit's Internet Routing Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default for "irr_mirror_interval". Lastly, it should be noted that [RFC2769], Routing Policy System Replication, attempted to offer a more methodical solution for @@ -639,51 +657,58 @@ [I-D.ietf-sidr-rpki-rtr] Bush, R. and R. Austein, "The RPKI/Router Protocol", draft-ietf-sidr-rpki-rtr-20 (work in progress), November 2011. [MERIT-IRRD] Merit, "IRRd - Internet Routing Registry Daemon", http://www.irrd.net. + [RC_HotNetsX] + "The Great IPv4 Land Grab: Resource Certification for the + IPv4 Grey Market", + HotNets-X http://dl.acm.org/citation.cfm?id=2070574. + [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995. [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999. [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999. [RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. Meyer, "Routing Policy System Replication", RFC 2769, February 2000. [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. + [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support + Secure Internet Routing", RFC 6480, February 2012. + [RIPE2007-01] RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment Policies and Procedures", Foundation - Policy http://www.ripe.net/ripe/docs/2007-01-asn. + Policy http://www.ripe.net/ripe/docs/ripe-452. Authors' Addresses Danny McPherson Verisign, Inc. Email: dmcpherson@verisign.com - Shane Amante Level 3 Communications 1025 Eldorado Blvd Broomfield, CO 80021 USA Email: shane@level3.net Eric Osterweil Verisign, Inc.