draft-ietf-grow-irr-routing-policy-considerations-02.txt   draft-ietf-grow-irr-routing-policy-considerations-03.txt 
GROW Working Group D. McPherson GROW Working Group D. McPherson
Internet-Draft Verisign, Inc. Internet-Draft Verisign, Inc.
Intended status: Standards Track S. Amante Intended status: Standards Track S. Amante
Expires: May 8, 2014 Level 3 Communications Expires: November 1, 2014 Level 3 Communications
E. Osterweil E. Osterweil
Verisign, Inc. Verisign, Inc.
L. Blunk L. Blunk
Merit Network, Inc. Merit Network, Inc.
D. Mitchell D. Mitchell
Twitter, Inc. Twitter, Inc.
November 4, 2013 April 30, 2014
IRR & Routing Policy Configuration Considerations IRR & Routing Policy Configuration Considerations
<draft-ietf-grow-irr-routing-policy-considerations-02> <draft-ietf-grow-irr-routing-policy-considerations-02>
Abstract Abstract
The purpose of this document is to catalog past issues influencing The purpose of this document is to catalog past issues influencing
the efficacy of Internet Routing Registries (IRR) for inter-domain the efficacy of Internet Routing Registries (IRR) for inter-domain
routing policy specification and application in the global routing routing policy specification and application in the global routing
system over the past two decades. Additionally, it provides a system over the past two decades. Additionally, it provides a
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 8, line 11 skipping to change at page 8, line 11
impersonation attacks. As a result, there is no rigorous assurance impersonation attacks. As a result, there is no rigorous assurance
that a mirrored RPSL statement was actually made by the authorized that a mirrored RPSL statement was actually made by the authorized
resource holder. resource holder.
4.5. Conclusions with respect to Data in the IRR 4.5. Conclusions with respect to Data in the IRR
All of the aforementioned issues related to integrity and accuracy of All of the aforementioned issues related to integrity and accuracy of
data within the IRR stem from a distinct lack of resource data within the IRR stem from a distinct lack of resource
certification for resources contained within the IRR. Only now is an certification for resources contained within the IRR. Only now is an
experimental test bed that reports to provide this function (under experimental test bed that reports to provide this function (under
the auspices of the Resource PKI [I-D.ietf-sidr-arch]) being formally the auspices of the Resource PKI [RFC6480]) being formally discussed,
discussed, which could also aid in certification of resources within which could also aid in certification of resources within the IRR.
the IRR. It should be noted that the RPKI is only currently able to It should be noted that the RPKI is only currently able to support
support signing of Route Origin Authorization (ROA) resources that signing of Route Origin Authorization (ROA) resources that are the
are the equivalent of 'route' resources in the IRR. It is unclear equivalent of 'route' resources in the IRR. It is unclear if, in the
if, in the future, the RPKI will be extended to support additional future, the RPKI will be extended to support additional resources
resources that already exist in the IRR, e.g.: aut-num, as-net, that already exist in the IRR, e.g.: aut-num, as-net, route-set, etc.
route-set, etc. Finally, a seemingly equivalent resource Finally, a seemingly equivalent resource certification specification
certification specification for all resources in the IRR has already for all resources in the IRR has already been developed [RFC2725],
been developed [RFC2725], however it is unclear how widely it was however it is unclear how widely it was ever implemented or deployed.
ever implemented or deployed.
5. Operation of the IRR Infrastructure 5. Operation of the IRR Infrastructure
5.1. Replication of Resources Among IRRs 5.1. Replication of Resources Among IRRs
Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring Currently, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring
(NRTM) protocol to replicate each others contents. However, this (NRTM) protocol to replicate each others contents. However, this
protocol has a several weaknesses. Namely, there is no way to protocol has a several weaknesses. Namely, there is no way to
validate that the copy of mirror is correct and synchronization validate that the copy of mirror is correct and synchronization
issues have often resulted. Furthermore, the NRTM protocol does not issues have often resulted. Furthermore, the NRTM protocol does not
skipping to change at page 14, line 19 skipping to change at page 14, line 19
More recently, operators have the ability to use NETCONF/SSH (or, More recently, operators have the ability to use NETCONF/SSH (or,
TLS) from an offline server to push a BGP configuration 'snippet' TLS) from an offline server to push a BGP configuration 'snippet'
from an offline server toward a target router that has that from an offline server toward a target router that has that
capability. However, this activity is still dependent on generating, capability. However, this activity is still dependent on generating,
via the offline server, a router vendor dependent XML configuration via the offline server, a router vendor dependent XML configuration
snippet that would get uploaded via SSH or TLS to the target router. snippet that would get uploaded via SSH or TLS to the target router.
In the future, the ability to upload new Route Origin Authorization In the future, the ability to upload new Route Origin Authorization
(ROA) information may be provided from the RPKI to routers via the (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 RPKI-RTR [RFC6810] protocol. However, this will not allow operators
allow operators the ability to upload other configuration information the ability to upload other configuration information such as BGP
such as BGP policy information, such as AS_PATH's, BGP communities, policy information, such as AS_PATH's, BGP communities, etc. that
etc. that might be associated with that ROA information, like they might be associated with that ROA information, like they can from IRR
can from IRR generated BGP policies. generated BGP policies.
8. Security Considerations 8. Security Considerations
9. IANA Considerations 9. IANA Considerations
10. Acknowledgements 10. Acknowledgements
TBD. TBD.
11. Informative References 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]
Merit, "IRRd - Internet Routing Registry Daemon", Merit, "IRRd - Internet Routing Registry Daemon",
http://www.irrd.net. http://www.irrd.net.
[RC_HotNetsX] [RC_HotNetsX]
"The Great IPv4 Land Grab: Resource Certification for the "The Great IPv4 Land Grab: Resource Certification for the
IPv4 Grey Market", IPv4 Grey Market",
HotNets-X http://dl.acm.org/citation.cfm?id=2070574. HotNets-X http://dl.acm.org/citation.cfm?id=2070574.
[RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet",
skipping to change at page 15, line 36 skipping to change at page 15, line 27
[RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D. [RFC2769] Villamizar, C., Alaettinoglu, C., Govindan, R., and D.
Meyer, "Routing Policy System Replication", RFC 2769, Meyer, "Routing Policy System Replication", RFC 2769,
February 2000. February 2000.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000. September 2000.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. 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] [RIPE2007-01]
RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment
Policies and Procedures", Foundation Policies and Procedures", Foundation
Policy http://www.ripe.net/ripe/docs/ripe-452. Policy http://www.ripe.net/ripe/docs/ripe-452.
Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Verisign, Inc. Verisign, Inc.
 End of changes. 8 change blocks. 
30 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/