draft-ietf-grow-irr-routing-policy-considerations-01.txt   draft-ietf-grow-irr-routing-policy-considerations-02.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: November 4, 2013 Level 3 Communications Expires: May 8, 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.
May 3, 2013 November 4, 2013
IRR & Routing Policy Configuration Considerations IRR & Routing Policy Configuration Considerations
<draft-ietf-grow-irr-routing-policy-considerations-01> <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
discussion regarding which of these issues are still problematic in discussion regarding which of these issues are still problematic in
practice, and which are simply artifacts that are no longer practice, and which are simply artifacts that are no longer
applicable but continue to stifle inter-provider policy-based applicable but continue to stifle inter-provider policy-based
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 November 4, 2013. This Internet-Draft will expire on May 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3
4. Accuracy and Integrity of Data Contained within the IRR . . . 4 4. Accuracy and Integrity of Data Contained within the IRR . . . 4
4.1. Lack of Resource Certification . . . . . . . . . . . . . . 4 4.1. Lack of Resource Certification . . . . . . . . . . . . . . 4
4.2. Incentives to Maintain Data within the IRR . . . . . . . . 5 4.2. Incentives to Maintain Data within the IRR . . . . . . . . 5
4.3. Inability for Third Parties to Remove (Stale) 4.3. Inability for Third Parties to Remove (Stale)
Information from the IRRs . . . . . . . . . . . . . . . . 6 Information from the IRRs . . . . . . . . . . . . . . . . 6
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 6 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7
4.5. Conclusions with respect to Data in the IRR . . . . . . . 7 4.5. Conclusions with respect to Data in the IRR . . . . . . . 8
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8
5.1. Replication of Resources Among IRRs . . . . . . . . . . . 8 5.1. Replication of Resources Among IRRs . . . . . . . . . . . 8
5.2. Updating Routing Policies from Updated IRR Resources . . . 9 5.2. Updating Routing Policies from Updated IRR Resources . . . 9
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11 6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11
7. Historical Limitations of Routers . . . . . . . . . . . . . . 12 7. Historical Limitations of Routers . . . . . . . . . . . . . . 12
7.1. Incremental Updates to Policy on 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 7.3. Updating Configuration on Routers . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 4, line 21 skipping to change at page 4, line 21
the methods related to extraction of policy from the IRR and the the methods related to extraction of policy from the IRR and the
input plus activation of that policy within routers. input plus activation of that policy within routers.
4. Accuracy and Integrity of Data Contained within the IRR 4. Accuracy and Integrity of Data Contained within the IRR
The following section will examine issues related to accuracy and The following section will examine issues related to accuracy and
integrity of data contained within the IRR. integrity of data contained within the IRR.
4.1. Lack of Resource Certification 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 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. the data contained within the IRRs is out of date or lacks integrity.
This is largely attributable to the fact that historically there has This is largely attributable to the fact that existing IRR mechanisms
existed no method for developing cryptographically verifiable do not provide ways for a relying party to (cryptographically) verify
bindings of an IP prefix to the originating Autonomous System (AS). the validity of an IRR object. That is, there has never existed a
That is, there has never existed a resource certification resource certification infrastructure that enables a resource holder
infrastructure that enables a resource holder to authorize a to authorize a particular autonomous system to originate network
particular autonomous system to originate network layer reachability layer reachability advertisements for a given IPv4 or IPv6 prefix.
advertisements for a given IPv4 or IPv6 prefix. It should be noted It should be noted that this is not a weakness of the underlying
that this is not a weakness of the underlying Routing Policy Routing Policy Specification Language (RPSL) [RFC2622], but rather,
Specification Language (RPSL) [RFC2622], but rather, was largely the was largely the result of no clear demand by the operator community
result of no clear demand by the operator community for Internet for Internet Number Resource Registries to provide sufficient
Number Resource Registries to provide sufficient resource resource certification infrastructure that would enable a resource
certification infrastructure that would enable a resource holder to holder to develop a cryptographic binding between, for example, a
develop a cryptographic binding between, for example, a given AS given AS number and an IP prefix.
number and an IP prefix.
Another noteworthy (but slightly different) deficiency in the IRR Another noteworthy (but slightly different) deficiency in the IRR
system is the absence of a tangible tie between the resource and the system is the absence of a tangible tie between the resource and the
resource holder. If a resource holder's authorization cannot be resource holder. That is, generally there is no assurance of the
certified, then consumers cannot verify attestations made. In validity of objects at their creation time (except for a subset of,
effect, without resource certification, consumers are basically only for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE
certifying the assertions that the creator / maintainer of the address holders and RIPE ASN holders). If a resource holder's
resource object has made (not if that assertion is valid). 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 The RIPE community addressed this last issue by putting in a
foundation policy [RIPE2007-01], which requires a contractual link foundation policy [RIPE2007-01], which requires a contractual link
between the RIPE NCC and the end user in direct assignment + ASN between the RIPE NCC and the end user in direct assignment + ASN
assignment cases, which weren't previously covered by LIR contracts assignment cases, which weren't previously covered by LIR contracts
for address allocations. There were a couple of intentions with this for address allocations. There were a couple of intentions with this
policy: policy:
1. There was an encumbrance placed in the policy for the LIR to 1. There was an encumbrance placed in the policy for the LIR to
charge the end-user for provider independent resources. This charge the end-user for provider independent resources. This
skipping to change at page 5, line 19 skipping to change at page 5, line 32
2. It guaranteed that all RIPE NCC allocated/assigned space would be 2. It guaranteed that all RIPE NCC allocated/assigned space would be
subject to a contractual link, and that this contractual chain subject to a contractual link, and that this contractual chain
might end up actually meaning something when it came to the issue might end up actually meaning something when it came to the issue
of who made what claim about what number resource. of who made what claim about what number resource.
3. It tied into the RIPE NCC's object grandfathering policy which 3. It tied into the RIPE NCC's object grandfathering policy which
ties the registration details of the end-user to the object ties the registration details of the end-user to the object
registered in the IRR database. 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 One of the central observations of this policy was that without a
chain-of-ownership functionality in IRR databases, the discussion of chain-of-ownership functionality in IRR databases, the discussion of
certifying their contents becomes moot. certifying their contents becomes moot.
4.2. Incentives to Maintain Data within the IRR 4.2. Incentives to Maintain Data within the IRR
A second problem with data contained in the IRRs is that the A second problem with data contained in the IRRs is that the
incentives for resource holders to maintain both accurate and up-to- incentives for resource holders to maintain both accurate and up-to-
date information in one, or more, IRRs; including deletion of out-of- date information in one, or more, IRRs; including deletion of out-of-
date or stale data from the IRRs can diminish rapidly when changing date or stale data from the IRRs can diminish rapidly when changing
skipping to change at page 9, line 6 skipping to change at page 9, line 25
an ISP is evaluating resources in an IRR just to determine if there an ISP is evaluating resources in an IRR just to determine if there
are any modifications to those resources that will ultimately be are any modifications to those resources that will ultimately be
reflected in a new routing policy that will get propagated to (Edge) reflected in a new routing policy that will get propagated to (Edge)
routers in the ISP's network. Cache locality results in reduced routers in the ISP's network. Cache locality results in reduced
bandwidth utilization for each round trip. bandwidth utilization for each round trip.
On the other hand, it is unclear from where the current provider On the other hand, it is unclear from where the current provider
replication interval of 24 hours originated or even whether it still replication interval of 24 hours originated or even whether it still
provides enough freshness in the face of available resources, provides enough freshness in the face of available resources,
particularly in today's environment where a typical IRR system 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. physical connection of 100 Mbps or, more likely, higher bandwidth.
In addition, it can be observed that the most common circuit size In addition, it can be observed that the most common circuit size
used by ISPs is now 10 Gbps, thus eliminating bandwidth as a used by ISPs is now 10 Gbps, thus eliminating bandwidth as a
significant factor in the transfer of data between IRRs. significant factor in the transfer of data between IRRs.
Furthermore, it should be noted that Merit's Internet Routing Furthermore, it should be noted that Merit's Internet Routing
Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default Registry Daemon (IRRd) [MERIT-IRRD], uses 10 minutes as its default
for "irr_mirror_interval". for "irr_mirror_interval".
Lastly, it should be noted that [RFC2769], Routing Policy System Lastly, it should be noted that [RFC2769], Routing Policy System
Replication, attempted to offer a more methodical solution for Replication, attempted to offer a more methodical solution for
skipping to change at page 14, line 32 skipping to change at page 15, line 9
[I-D.ietf-sidr-rpki-rtr] [I-D.ietf-sidr-rpki-rtr]
Bush, R. and R. Austein, "The RPKI/Router Protocol", Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ietf-sidr-rpki-rtr-20 (work in progress), draft-ietf-sidr-rpki-rtr-20 (work in progress),
November 2011. 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]
"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", [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet",
RFC 1787, April 1995. RFC 1787, April 1995.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622, "Routing Policy Specification Language (RPSL)", RFC 2622,
June 1999. June 1999.
[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. [RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
Murphy, "Routing Policy System Security", RFC 2725, Murphy, "Routing Policy System Security", RFC 2725,
December 1999. December 1999.
[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
Secure Internet Routing", RFC 6480, February 2012.
[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/2007-01-asn. Policy http://www.ripe.net/ripe/docs/ripe-452.
Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Verisign, Inc. Verisign, Inc.
Email: dmcpherson@verisign.com Email: dmcpherson@verisign.com
Shane Amante Shane Amante
Level 3 Communications Level 3 Communications
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
USA USA
Email: shane@level3.net Email: shane@level3.net
Eric Osterweil Eric Osterweil
Verisign, Inc. Verisign, Inc.
 End of changes. 15 change blocks. 
29 lines changed or deleted 54 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/