draft-ietf-grow-irr-routing-policy-considerations-03.txt   draft-ietf-grow-irr-routing-policy-considerations-04.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: Informational S. Amante
Expires: November 1, 2014 Level 3 Communications Expires: February 27, 2015 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.
April 30, 2014 August 26, 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-04>
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 1, 2014. This Internet-Draft will expire on February 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 4
4. Accuracy and Integrity of Data Contained within the IRR . . . 4 4. Accuracy and Integrity of Data Contained within the IRR . . . 5
4.1. Lack of Resource Certification . . . . . . . . . . . . . . 4 4.1. Lack of Resource Certification . . . . . . . . . . . . . . 5
4.2. Incentives to Maintain Data within the IRR . . . . . . . . 5 4.2. Incentives to Maintain Data within the IRR . . . . . . . . 6
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 . . . . . . . . . . . . . . . . 7
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 8
4.5. Conclusions with respect to Data in the IRR . . . . . . . 8 4.5. Conclusions with respect to Data in the IRR . . . . . . . 9
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 9
5.1. Replication of Resources Among IRRs . . . . . . . . . . . 8 5.1. Replication of Resources Among IRRs . . . . . . . . . . . 9
5.2. Updating Routing Policies from Updated IRR Resources . . . 9 5.2. Updating Routing Policies from Updated IRR Resources . . . 10
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11 6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 12
7. Historical Limitations of Routers . . . . . . . . . . . . . . 12 7. Historical Limitations of Routers . . . . . . . . . . . . . . 13
7.1. Incremental Updates to Policy on Routers . . . . . . . . . 12 7.1. Incremental Updates to Policy on Routers . . . . . . . . . 13
7.2. Storage Requirements for Policy on Routers . . . . . . . . 13 7.2. Storage Requirements for Policy on Routers . . . . . . . . 14
7.3. Updating Configuration on Routers . . . . . . . . . . . . 13 7.3. Updating Configuration on Routers . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Informative References . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
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 still pose problems in discussion regarding which of these issues still pose problems in
practice, and which are no longer obstacles, but whose perceived practice, and which are no longer obstacles, but whose perceived
drawbacks continue to stifle inter-provider policy-based filtering drawbacks continue to stifle inter-provider policy-based filtering
skipping to change at page 8, line 32 skipping to change at page 9, line 32
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
employ any security mechanisms. The NRTM protocol relies on a pull employ any security mechanisms. The NRTM protocol relies on a pull
mechanism and is generally is configured with a poll interval of 5 to mechanism and is generally configured with a poll interval of 5 to 10
10 minutes. There is currently no mechanism to notify an IRR when an minutes. There is currently no mechanism to notify an IRR when an
update has occurred in a mirrored IRR so that an immediate update can update has occurred in a mirrored IRR so that an immediate update can
be made. be made.
Some providers employ a process of mirroring an instance of an IRR Some providers employ a process of mirroring an instance of an IRR
that involves downloading a flat text file copy of the IRR that is that involves downloading a flat text file copy of the IRR that is
made available via FTP. These FTP files are exported at regular made available via FTP. These FTP files are exported at regular
intervals of typically anywhere between 2 and 24 hours by the IRRs. intervals of typically anywhere between 2 and 24 hours by the IRRs.
When a provider fetches those text files, it will process them to When a provider fetches those text files, it will process them to
identify any updates and reflect changes within its own internally identify any updates and reflect changes within its own internally
maintained database. The use of an internally maintained database is maintained database. The use of an internally maintained database is
out-of-scope of this document, but is generally used to assist with out-of-scope of this document, but is generally used to assist with
more straightforward access to or modification of data by the IRR more straightforward access to or modification of data by the IRR
operator. Providers typically employ a 24 hour cycle to pull updated operator. Providers typically employ a 24 hour cycle to pull updated
resources from IRRs. Thus, depending on when resource holders resources from IRRs. Thus, depending on when resource holders
submitted their changes to an IRR, it may take up to 24 hours for submitted their changes to an IRR, it may take up to 24 hours for
those changes to be reflected in their policy configurations. In those changes to be reflected in their policy configurations. In
practice, it appears that the RPKI will also employ a 24 hour cycle practice, it appears that the RPKI will also employ a 24 hour cycle
whereby changes in resources are pushed out to other RPKI caches whereby changes in resources are pushed out to other RPKI caches
[REF?]. [RPKI_SIZING].
IRRs originated from Section 7 of [RFC1787], specifically: "The scale IRRs originated from Section 7 of [RFC1787], specifically: "The scale
of the Internet implies that the [routing requirements] information of the Internet implies that the [routing requirements] information
should be distributed." Regardless, the practical effect of an should be distributed." Regardless, the practical effect of an
organization maintaining its own local cache of IRR resources is an organization maintaining its own local cache of IRR resources is an
increase in resource resiliency (due to multiple copies of the same increase in resource resiliency (due to multiple copies of the same
resource being geographically distributed), a reduction in query time resource being geographically distributed), a reduction in query time
for resources and, likely, a reduction in bandwidth consumption and for resources and, likely, a reduction in inter-domain bandwidth
associated costs. This is particularly beneficial when, for example, consumption and associated costs. This is particularly beneficial
an ISP is evaluating resources in an IRR just to determine if there when, for example, an ISP is evaluating resources in an IRR just to
are any modifications to those resources that will ultimately be determine if there are any modifications to those resources that will
reflected in a new routing policy that will get propagated to (Edge) ultimately be reflected in a new routing policy that will get
routers in the ISP's network. Cache locality results in reduced propagated to (Edge) routers in the ISP's network. Cache locality
bandwidth utilization for each round trip. results in reduced inter-domain 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.
skipping to change at page 13, line 34 skipping to change at page 14, line 34
long times to write out these configuration changes and, sometimes, long times to write out these configuration changes and, sometimes,
due to bugs would result in loss of protocol keep-alives, thus due to bugs would result in loss of protocol keep-alives, thus
causing an impact to routing or forwarding of packets through the causing an impact to routing or forwarding of packets through the
platform. platform.
The above limitations have largely been resolved with more modern The above limitations have largely been resolved with more modern
equipment from the last few years shipping with increasing amounts of equipment from the last few years shipping with increasing amounts of
non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk
Drives or Solid State Disk Drives. Drives or Solid State Disk Drives.
However, as capacities and technologies have evolved on modern
routing hardware, so have the some of the scaling requirements of the
data. In some large networks, configuration growth has begun to
"pose challenges" [IEPG89_NTT]. While the enhancements of hardware
have overcome some historical limitations, evidence suggests that
further optimizations in configuration processing may be needed in
some cases. Some of the more recent operational issues include
scheduler slips and protracted commit times. This suggests that even
though many historical hurdles have been overcome, there are still
motivations to optimize and modernize IRR technologies.
7.3. Updating Configuration on Routers 7.3. Updating Configuration on Routers
Historically, there has not been a standardized network configuration Historically, there has not been a standardized network configuration
modeling language or an associated method to update router modeling language or an associated method to update router
configurations. When an ISP detected a change in resources within configurations. When an ISP detected a change in resources within
the IRR, it would fashion a router vendor dependent BGP policy and the IRR, it would fashion a router vendor dependent BGP policy and
upload that to the router usually via the following method. upload that to the router usually via the following method.
First, an updated BGP policy configuration 'snippet' is generated via First, an updated BGP policy configuration 'snippet' is generated via
processes running on an offline server. Next, the operator uses processes running on an offline server. Next, the operator uses
skipping to change at page 14, line 25 skipping to change at page 15, line 37
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 [RFC6810] protocol. However, this will not allow operators RPKI-RTR [RFC6810] protocol. However, this will not allow operators
the ability to upload other configuration information such as BGP the ability to upload other configuration information such as BGP
policy information, such as AS_PATH's, BGP communities, etc. that policy information, such as AS_PATH's, BGP communities, etc. that
might be associated with that ROA information, like they can from IRR might be associated with that ROA information, like they can from IRR
generated BGP policies. generated BGP policies.
8. Security Considerations 8. Summary
9. IANA Considerations As discussed above, many of the problems that have historically
stifled IRR deployment have, themselves, become historical. However,
there are still real operational considerations that limit IRR usage
from realizing its full effectiveness. The potential for IRRs to
express inter-domain routing policy, and to allow relying parties to
learn policy, has always positioned it as a strong candidate to aid
the security postures of operators. However, while routing density
and complexity have grown, so have some of the challenges facing IRRs
(even today). Because of this state increase, the potential to model
all policies for all ASes in all routers may still remain illusive.
In addition, without an operationally deployed resource certification
framework that can tie policies to resource holders, there is a
fundamental limitation that still exists.
10. Acknowledgements 9. Security Considerations
TBD. One of the central concerns with IRRs is the ability of an IRR
operator to remotely influence the routing operations of an external
consumer. Specifically, if the processing of IRR contents can become
burdensome, or if the policy statements can be crafted to introduce
routing problems or anomalies, then operators may want to be
circumspect about ingesting contents from external parties. However,
in regards to routing anomalies, as mentioned in Section 4.1 a
resource certification framework should be used to address the
authorization issues of IRR statements to make attestations and
assertions.
11. Informative References Additionally, the external and systemic dependencies introduced by
IRRs and other such systems employed to inform routing policy, and
how tightly or loosely coupled those systems are to the global
routing system and operational networks, introduces additional
vectors that operators and system architects should consider when
evaluating attack surface and service dependencies associated with
those elements. These attributes and concerns are certainly not
unique to IRRs, and operators should evaluate the implications of
external systems and varying degrees of coupling and operational
buffers that might be installed in their environments.
10. IANA Considerations
There are no IANA considerations.
11. Acknowledgements
The editors would like to acknowledge and thank Chris Morrow, Jeff
Haas, and Wes George for their help and constructive feedback.
12. Informative References
[IEPG89_NTT]
"NTT BGP Configuration Size and Scope", IEPG 89 http://
iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf.
[IRR_LIST]
Merit Network, Inc., "List of Routing Registries", List of
Routing Registries http://www.irr.net/docs/list.html.
[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]
Osterweil, E., Amante, S., McPherson, D., and D. Massey,
"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",
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,
skipping to change at page 15, line 36 skipping to change at page 17, line 43
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013. 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.
[RPKI_SIZING]
Osterweil, E., Manderson, T., White, R., and D. McPherson,
"Sizing Estimates for a Fully Deployed RPKI", Verisign
Labs Technical Report 1120005 version 2 http://
techreports.verisignlabs.com/
tr-lookup.cgi?trid=1120005&rev=2.
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
 End of changes. 28 change blocks. 
42 lines changed or deleted 112 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/