--- 1/draft-ietf-grow-irr-routing-policy-considerations-02.txt 2014-04-30 07:14:21.048166043 -0700 +++ 2/draft-ietf-grow-irr-routing-policy-considerations-03.txt 2014-04-30 07:14:21.084166930 -0700 @@ -1,22 +1,22 @@ GROW Working Group D. McPherson Internet-Draft Verisign, Inc. Intended status: Standards Track S. Amante -Expires: May 8, 2014 Level 3 Communications +Expires: November 1, 2014 Level 3 Communications E. Osterweil Verisign, Inc. L. Blunk Merit Network, Inc. D. Mitchell Twitter, Inc. - November 4, 2013 + April 30, 2014 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 @@ -33,25 +33,25 @@ 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 May 8, 2014. + This Internet-Draft will expire on November 1, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -332,31 +332,30 @@ impersonation attacks. As a result, there is no rigorous assurance that a mirrored RPSL statement was actually made by the authorized resource holder. 4.5. Conclusions with respect to Data in the IRR All of the aforementioned issues related to integrity and accuracy of data within the IRR stem from a distinct lack of resource certification for resources contained within the IRR. Only now is an experimental test bed that reports to provide this function (under - the auspices of the Resource PKI [I-D.ietf-sidr-arch]) being formally - discussed, which could also aid in certification of resources within - the IRR. It should be noted that the RPKI is only currently able to - support signing of Route Origin Authorization (ROA) resources that - are the equivalent of 'route' resources in the IRR. It is unclear - if, in the future, the RPKI will be extended to support additional - resources that already exist in the IRR, e.g.: aut-num, as-net, - route-set, etc. Finally, a seemingly equivalent resource - certification specification for all resources in the IRR has already - been developed [RFC2725], however it is unclear how widely it was - ever implemented or deployed. + the auspices of the Resource PKI [RFC6480]) being formally discussed, + which could also aid in certification of resources within the IRR. + It should be noted that the RPKI is only currently able to support + signing of Route Origin Authorization (ROA) resources that are the + equivalent of 'route' resources in the IRR. It is unclear if, in the + future, the RPKI will be extended to support additional resources + that already exist in the IRR, e.g.: aut-num, as-net, route-set, etc. + Finally, a seemingly equivalent resource certification specification + for all resources in the IRR has already been developed [RFC2725], + however it is unclear how widely it was ever implemented or deployed. 5. Operation of the IRR Infrastructure 5.1. Replication of Resources Among IRRs Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring (NRTM) protocol to replicate each others contents. However, this protocol has a several weaknesses. Namely, there is no way to validate that the copy of mirror is correct and synchronization issues have often resulted. Furthermore, the NRTM protocol does not @@ -627,46 +627,36 @@ More recently, operators have the ability to use NETCONF/SSH (or, TLS) from an offline server to push a BGP configuration 'snippet' from an offline server toward a target router that has that capability. However, this activity is still dependent on generating, via the offline server, a router vendor dependent XML configuration snippet that would get uploaded via SSH or TLS to the target router. In the future, the ability to upload new Route Origin Authorization (ROA) information may be provided from the RPKI to routers via the - RPKI-RTR [I-D.ietf-sidr-rpki-rtr] protocol. However, this will not - allow operators the ability to upload other configuration information - such as BGP policy information, such as AS_PATH's, BGP communities, - etc. that might be associated with that ROA information, like they - can from IRR generated BGP policies. + RPKI-RTR [RFC6810] protocol. However, this will not allow operators + the ability to upload other configuration information such as BGP + policy information, such as AS_PATH's, BGP communities, etc. that + might be associated with that ROA information, like they can from IRR + generated BGP policies. 8. Security Considerations 9. IANA Considerations 10. Acknowledgements TBD. 11. Informative References - [I-D.ietf-sidr-arch] - Lepinski, M. and S. Kent, "An Infrastructure to Support - Secure Internet Routing", draft-ietf-sidr-arch-13 (work in - progress), May 2011. - - [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", @@ -684,20 +674,24 @@ [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. + [RFC6810] Bush, R. and R. Austein, "The Resource Public Key + Infrastructure (RPKI) to Router Protocol", RFC 6810, + January 2013. + [RIPE2007-01] RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment Policies and Procedures", Foundation Policy http://www.ripe.net/ripe/docs/ripe-452. Authors' Addresses Danny McPherson Verisign, Inc.