draft-ietf-grow-irr-routing-policy-considerations-06.txt   rfc7682.txt 
GROW Working Group D. McPherson Internet Engineering Task Force (IETF) D. McPherson
Internet-Draft Verisign, Inc. Request for Comments: 7682 Verisign, Inc.
Intended status: Informational S. Amante Category: Informational S. Amante
Expires: January 21, 2016 Apple, Inc. ISSN: 2070-1721 Apple, Inc.
E. Osterweil E. Osterweil
Verisign, Inc. Verisign, Inc.
L. Blunk L. Blunk
Merit Network, Inc. Merit Network, Inc.
D. Mitchell D. Mitchell
Singularity Networks Singularity Networks
July 20, 2015 December 2015
IRR & Routing Policy Configuration Considerations Considerations for Internet Routing Registries (IRRs)
<draft-ietf-grow-irr-routing-policy-considerations-06> and Routing Policy Configuration
Abstract Abstract
The purpose of this document is to catalog past issues influencing The purpose of this document is to catalog issues that influenced the
the efficacy of Internet Routing Registries (IRR) for inter-domain efficacy of Internet Routing Registries (IRRs) 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
filtering adoption and IRR utility to this day. filtering adoption and IRR utility to this day.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 21, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7682.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 3
4. Accuracy and Integrity of Data Contained within the IRR . . . 4
3. Historical Artifacts Influencing IRR Efficacy . . . . . . . . 4 4.1. Lack of Resource Certification . . . . . . . . . . . . . 4
4.2. Incentives to Maintain Data within the IRR . . . . . . . 5
4. Accuracy and Integrity of Data Contained within the IRR . . . 5 4.3. Inability for Third Parties to Remove (Stale) Information
4.1. Lack of Resource Certification . . . . . . . . . . . . . . 5 from the IRRs . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Incentives to Maintain Data within the IRR . . . . . . . . 6 4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 7
4.3. Inability for Third Parties to Remove (Stale) 4.5. Client-Side Considerations . . . . . . . . . . . . . . . 8
Information from the IRRs . . . . . . . . . . . . . . . . 7 4.6. Conclusions with Respect to Data in the IRR . . . . . . . 8
4.4. Lack of Authoritative IRR for Resources . . . . . . . . . 8 5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 8
4.5. Client-Side Considerations . . . . . . . . . . . . . . . . 9 5.1. Replication of Resources among IRRs . . . . . . . . . . . 8
4.6. Conclusions with respect to Data in the IRR . . . . . . . 9 5.2. Updating Routing Policies from Updated IRR Resources . . 10
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 11
5. Operation of the IRR Infrastructure . . . . . . . . . . . . . 9 7. Historical Limitations of Routers . . . . . . . . . . . . . . 13
5.1. Replication of Resources Among IRRs . . . . . . . . . . . 9 7.1. Incremental Updates to Policy on Routers . . . . . . . . 13
5.2. Updating Routing Policies from Updated IRR Resources . . . 11 7.2. Storage Requirements for Policy on Routers . . . . . . . 13
7.3. Updating Configuration on Routers . . . . . . . . . . . . 14
6. Historical BGP Protocol Limitations . . . . . . . . . . . . . 12 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Historical Limitations of Routers . . . . . . . . . . . . . . 14 10. Informative References . . . . . . . . . . . . . . . . . . . 16
7.1. Incremental Updates to Policy on Routers . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Storage Requirements for Policy on Routers . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Updating Configuration on Routers . . . . . . . . . . . . 15
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. Informative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The purpose of this document is to catalog past issues influencing The purpose of this document is to catalog issues influencing the
the efficacy of Internet Routing Registries (IRR) for inter-domain efficacy of Internet Routing Registries (IRRs) 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
support and IRR utility to this day. support and IRR utility to this day.
2. Background 2. Background
IRRs can be used to express a multitude of Internet number bindings IRRs can be used to express a multitude of Internet number bindings
and policy objectives, to include bindings between an origin AS and a and policy objectives, i.e., to include bindings between 1) an origin
given prefix, AS and community import and export policies for a given AS and a given prefix, 2) a given AS and its AS and community import
AS, as well as AS macros (as-sets in RPSL-speak) that convey the set and export policies, as well as 3) a given AS and the AS macros (as-
of ASes for which a given AS intends to include in some common group. sets in Routing Policy Specification Language (RPSL)) that convey the
set of ASes that it intends to include in some common group.
As quoted from Section 7 of [RFC1787], Routing in a Multi-Provider As quoted from Section 7 of "Routing in a Multi-Provider Internet"
Internet: [RFC1787]:
While ensuring Internet-wide coordination may be more and more While ensuring Internet-wide coordination may be more and more
difficult, as the Internet continues to grow, stability and difficult, as the Internet continues to grow, stability and
consistency of the Internet-wide routing could significantly consistency of the Internet-wide routing could significantly
benefit if the information about routing requirements of various benefit if the information about routing requirements of various
organizations could be shared across organizational boundaries. organizations could be shared across organizational boundaries.
Such information could be used in a wide variety of situations Such information could be used in a wide variety of situations
ranging from troubleshooting to detecting and eliminating ranging from troubleshooting to detecting and eliminating
conflicting routing requirements. The scale of the Internet conflicting routing requirements. The scale of the Internet
implies that the information should be distributed. Work is implies that the information should be distributed. Work is
currently underway to establish depositories of this information currently underway to establish depositories of this information
(Routing Registries), as well as to develop tools that analyze, as (Routing Registries), as well as to develop tools that analyze, as
well as utilize this information. well as utilize this information.
3. Historical Artifacts Influencing IRR Efficacy 3. Historical Artifacts Influencing IRR Efficacy
The term IRR is often used, incorrectly, as a broad catch-all term to The term IRR is often used, incorrectly, as a broad catch-all term to
categorize issues related to the accuracy of data in the IRR, the categorize issues related to the accuracy of data in the IRR, RPSL,
Routing Policy Specification Language (RPSL) and the operational and the operational deployment of policy (derived from RPSL contained
deployment of policy (derived from RPSL contained within the IRR) to within the IRR) to routers. It is important to classify these issues
routers. It is important to classify these issues into distinct into distinct categories so that the reader can understand which
categories so that the reader can understand which categories of categories of issues are historical artifacts that are no longer
issues are historical artifacts that are no longer applicable and applicable and which categories of issues still exist and might be
which categories of issues still exist and might be addressed by the addressed by the IETF.
IETF.
The following sections will separate out challenges related to the The following sections will separate out challenges related to the
IRR into the following categories. First, accuracy and integrity of IRR into the following categories: first, accuracy and integrity of
data contained within the IRR. Second, the Resource Policy data contained within the IRR; second, operation of the IRR
Specification Language (RPSL) used to represent various types of data infrastructure, i.e., synchronization of resources from one IRR to
in the IRR. Third, operation of the IRR infrastructure, i.e.: other IRRs; and finally, this document covers the methods related to
synchronization of resources from one IRR to other IRRs. Finally, extraction of policy from the IRR and the input, plus activation of
the methods related to extraction of policy from the IRR and the 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, Internet number resources include IPv4 addresses, IPv6 addresses,
Autonomous System Numbers (ASNs), and more. While these resources Autonomous System Numbers (ASNs), and more. While these resources
are generally allocated by hierarchical authorities, a general are generally allocated by hierarchical authorities, a general
mechanism for formally verifying (such as through cryptographic mechanism for formally verifying (such as through cryptographic
mechanisms) when parties have been allocated resource remains an open mechanisms) when parties have been allocated resources remains an
challenge. We generally define such a system a Resource open challenge. We generally call such a system a Resource
Certification System, and we note that some candidate examples of how Certification System, and we note that some candidate examples of how
such a general system might be implemented and deployed exist such a general system might be implemented and deployed exist --
[TASRS], [RC_HotNetsX], [RFC6480]. [TASRS], [RC_HotNetsX], and [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 existing IRR mechanisms This is largely attributable to the fact that existing IRR mechanisms
do not provide ways for a relying party to (cryptographically) verify do not provide ways for a relying party to (cryptographically) verify
the validity of an IRR object. That is, there has never existed a the validity of an IRR object. That is, there has never existed a
resource certification infrastructure that enables a resource holder resource certification infrastructure that enables a resource holder
to authorize a particular autonomous system to originate network to authorize a particular autonomous system to originate network-
layer reachability advertisements for a given IPv4 or IPv6 prefix. layer reachability advertisements for a given IPv4 or IPv6 prefix.
It should be noted that this is not a weakness of the underlying It should be noted that this is not a weakness of the underlying RPSL
Routing Policy Specification Language (RPSL) [RFC2622], but rather, [RFC2622], but rather, was largely the result of no clear demand by
was largely the result of no clear demand by the operator community the operator community for Internet Number Resource Registries to
for Internet Number Resource Registries to provide sufficient provide sufficient resource certification infrastructure that would
resource certification infrastructure that would enable a resource enable a resource holder to develop a cryptographic binding between,
holder to develop a cryptographic binding between, for example, a for example, a given AS number and an IP prefix.
given AS 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. That is, generally there is no assurance of the resource holder. That is, generally there is no assurance of the
validity of objects at their creation time (except for a subset of, validity of objects at their creation time (except for a subset of,
for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE
address holders and RIPE ASN holders). If a resource holder's address holders and RIPE ASN holders). If a resource holder's
authorization cannot be certified, then consumers cannot verify authorization cannot be certified, then consumers cannot verify
attestations made. In effect, without resource certification, attestations made. In effect, without resource certification,
consumers are basically only certifying the assertions that the consumers are basically only certifying the assertions that the
creator / maintainer of the resource object has made (not if that creator/maintainer of the resource object has made (not if that
assertion is valid). 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 [RIPE638], 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 Local Internet
for address allocations. There were a couple of intentions with this Registry (LIR) contracts for address allocations. There were a
policy: couple of intentions with this 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 (PI) resources.
action created a collection mechanism for PI address resources This action created a collection mechanism for PI address
(IPv4 / IPv6 space, ASNs). resources (IPv4/IPv6 space, ASNs).
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 that
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, While this policy specifically addressed PI/portable space holders,
other regions address this issue, too. Further, it is indeed a other regions address this issue, too. Further, a tangible tie
prerequisite for resource certification, though it does not directly between the resource and the resource holder is indeed a prerequisite
address the IRR deficiencies. 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
their peering policies (such as switching transit providers). their peering policies (such as switching transit providers).
Specifically, there is a very strong incentive for an ISP's customers Specifically, there is a very strong incentive for an ISP's customers
to register new routing information in the IRR, because some ISPs to register new routing information in the IRR, because some ISPs
enforce a strict policy that they will only build or update a enforce a strict policy that they will only build or update a
customer's prefix-lists applied to the customer's inbound eBGP customer's prefix-lists applied to the customer's inbound eBGP
sessions based off information found within the IRRs. Unfortunately, sessions based off information found within the IRRs. Unfortunately,
there is little incentive for an ISP's customers to remove out-of- there is little incentive for an ISP's customers to remove out-of-
date information from an IRR, most likely attributed to the fact that date information from an IRR, most likely attributed to the fact that
some ISPs do not use, or enforce use of, data contained within the some ISPs do not use, or enforce use of, data contained within the
IRRs to automatically build incoming policy applied to customer's IRRs to automatically build incoming policy applied to the customer's
eBGP sessions. For example, if a customer is terminating service eBGP sessions. For example, if a customer is terminating service
from one ISP that requires use of IRR data to build incoming policy from one ISP that requires use of IRR data to build incoming policy
and, at the same time, enabling service with another ISP that does and, at the same time, enabling service with another ISP that does
not require use of IRR data, then that customer will likely let the not require use of IRR data, then that customer will likely let the
data in the IRR become stale or inaccurate. data in the IRR become stale or inaccurate.
Further, policy filters are almost exclusively generated based on the Further, policy filters are almost exclusively generated based on the
origin AS information contained within IRR route objects and used by origin AS information contained within IRR route objects and used by
providers to filter downstream transit customers. Since providers providers to filter downstream transit customers. Since providers
only look for route objects containing the origin AS of their only look for route objects containing the origin AS of their
downstream customer(s), stale route objects with historical and, downstream customer(s), stale route objects with historical and,
possibly, incorrect origin AS information are ignored. Assuming that possibly, incorrect origin AS information are ignored. Assuming that
the downstream customer(s) do not continue to announce those routes the downstream customer(s) do not continue to announce those routes
with historical, or incorrect, origin AS information in BGP to the with historical, or incorrect, origin AS information in BGP to the
upstream provider, there is no significant incentive to remove them upstream provider, there is no significant incentive to remove them
as they do not impact offline policy filter generation nor routing on as they do not impact offline policy filter generation nor routing on
the Internet. On the other hand, the main incentive that causes the the Internet. On the other hand, the main incentive that causes the
Service Provider to work with downstream customer(s) is when the Service Provider to work with downstream customer(s) is when the
resultant filter list becomes too large that it is difficult for it resultant filter list becomes so large that it is difficult for it to
to be stored on-board PE routers; however, this is more practically be stored on PE routers; however, this is more practically an
an operational issue with very old, legacy PE routers, not more operational issue with very old, legacy PE routers, not more modern
modern PE router hardware with more robust Control Plane Engines. PE router hardware with more robust control-plane engines.
4.3. Inability for Third Parties to Remove (Stale) Information from the 4.3. Inability for Third Parties to Remove (Stale) Information from the
IRRs IRRs
A third challenge with data contained in IRRs is that it is not A third challenge with data contained in IRRs is that it is not
possible for IRR operators, and ISPs who use them, to proactively possible for IRR operators, and ISPs who use them, to proactively
remove (perceived) out-of-date or "stale" resources in an IRR, on remove (perceived) out-of-date or "stale" resources in an IRR, on
behalf of resource holders who may not be diligent in maintaining behalf of resource holders who may not be diligent in maintaining
this information themselves. The reason is that, according to the this information themselves. The reason is that, according to the
Resource Policy Specification Language (RPSL) [RFC2622], only the RPSL [RFC2622], only the resource holder ('mntner') specified in a
resource holder ('mntner') specified in a 'mnt-by' value field of an 'mnt-by' value field of an RPSL resource is authorized to add,
RPSL resource is authorized to add, modify or delete their own modify, or delete their own resources within the IRR. To address
resources within the IRR. To address this issue, the 'auth-override' this issue, the 'auth-override' mechanism [RFC2725] was later
mechanism [RFC2725] was later developed that would have enabled a developed that would have enabled a third party to update and/or
third party to update and/or remove "stale" resources from the IRR. remove "stale" resources from the IRR. While it is unclear if this
While it is unclear if this was ever implemented or deployed, it does was ever implemented or deployed, it does provide language semantics
provide language semantics needed to overcome this obstacle. needed to overcome this obstacle.
Nevertheless, with such a mechanism in place, there is still a risk Nevertheless, with such a mechanism in place, there is still a risk
that the original RPSL resource holder would not receive that the original RPSL resource holder would not receive
notifications (via the 'notify' attribute in various RPSL resources) notifications (via the 'notify' attribute in various RPSL resources)
about the pending or actual removal of a resource from the IRR in about the pending or actual removal of a resource from the IRR in
time to halt that action if those resources were still being used. time to halt that action if those resources were still being used.
In this case, if the removal of a resource was not suspended, it In this case, if the removal of a resource was not suspended, it
could potentially result in an unintentional denial of service for could potentially result in an unintentional denial of service for
the RPSL resource holder when, for example, ISPs automatically the RPSL resource holder when, for example, ISPs automatically
generated and deployed a new policy based on the newly removed generated and deployed a new policy based on the newly removed
resources from the IRR, thus dropping any reachability announcement resources from the IRR, thus dropping any reachability announcement
for the removed resource in eBGP. for the removed resource in eBGP.
4.4. Lack of Authoritative IRR for Resources 4.4. Lack of Authoritative IRR for Resources
According to [RFC2622], within an RPSL resource "the source attribute According to [RFC2622], within an RPSL resource "the source attribute
skipping to change at page 8, line 18 skipping to change at page 7, line 17
the RPSL resource holder when, for example, ISPs automatically the RPSL resource holder when, for example, ISPs automatically
generated and deployed a new policy based on the newly removed generated and deployed a new policy based on the newly removed
resources from the IRR, thus dropping any reachability announcement resources from the IRR, thus dropping any reachability announcement
for the removed resource in eBGP. for the removed resource in eBGP.
4.4. Lack of Authoritative IRR for Resources 4.4. Lack of Authoritative IRR for Resources
According to [RFC2622], within an RPSL resource "the source attribute According to [RFC2622], within an RPSL resource "the source attribute
specifies the registry where the object is registered." Note that specifies the registry where the object is registered." Note that
this source attribute only exists within the RPSL resource itself. this source attribute only exists within the RPSL resource itself.
Unfortunately, given a specific resource, (e.g.: a specific IPv4 or Unfortunately, given a specific resource (e.g., a specific IPv4 or
IPv6 prefix), most of the time it is impossible to tell a priori the IPv6 prefix), most of the time it is impossible to determine a priori
authoritative IRR where to query and retrieve an authoritative copy the authoritative IRR where to query and retrieve an authoritative
of that resource. copy of that resource.
This makes it difficult for consumers of data from the IRR to This makes it difficult for consumers of data from the IRR to
automatically know the authoritative IRR of a resource holder, which automatically know the authoritative IRR of a resource holder that
will contain their most up-to-date set of resources. This is will contain the most up-to-date set of resources. This is typically
typically not a problem for an ISP that has a direct (customer) not a problem for an ISP that has a direct (customer) relationship
relationship with the resource holder, because the ISP will ask the with the resource holder, because the ISP will ask the resource
resource holder which (authoritative) IRR to pull their resources holder which (authoritative) IRR to pull their resources from on, for
from on, for example, a "Customer BGP Order Form". However, third example, a "Customer BGP Order Form". However, third parties that do
parties that do not have a direct relationship with the resource not have a direct relationship with the resource holder have a
holder, have a difficult time attempting to infer the authoritative difficult time attempting to infer the authoritative IRR, preferred
IRR, preferred by the resource holder, that likely contains the most by the resource holder, that likely contains the most up-to-date set
up-to-date set of resources. As a result, it would be helpful for of resources. As a result, it would be helpful for third parties if
third parties if there was a robust referral mechanism so that a there were a robust referral mechanism so that a query to one IRR
query to one IRR would be automatically redirected toward the would be automatically redirected toward the authoritative IRR for
authoritative IRR for the most up-to-date and authoritative copy of the most up-to-date and authoritative copy of that particular
that particular resource. This problem is worked around by resource. This problem is worked around by individual IRR operators
individual IRR operators storing a local copy of other IRR's storing a local copy of other IRRs' resources, through periodic
resources, through periodic mirroring, which allows the individual mirroring, which allows the individual IRR to respond to a client's
IRR to respond to a client's query with all registered instances of a query with all registered instances of a particular IRR resource that
particular IRR resource that exist in both the local IRR and all exist in both the local IRR and all other IRRs. Of course, the
other IRRs. Of course, the problem with this approach is that an problem with this approach is that an individual IRR operator is
individual IRR operator is under no obligation to mirror all other under no obligation to mirror all other IRRs and, in practice, some
IRRs and, in practice, some IRRs do not mirror the resources from all IRRs do not mirror the resources from all other IRRs. This could
other IRRs. This could lead to the false impression that a lead to the false impression that a particular resource is not
particular resource is not registered or maintained at a particular registered or maintained at a particular IRR. Furthermore, the
IRR. Furthermore, the authentication process of accepting updates by authentication process of accepting updates by any given IRR may or
any given IRR may, or may not, be robust enough to overcome may not be robust enough to overcome impersonation attacks. As a
impersonation attacks. As a result, there is no rigorous assurance result, there is no rigorous assurance that a mirrored RPSL statement
that a mirrored RPSL statement was actually made by the authorized was actually made by the authorized resource holder.
resource holder.
4.5. Client-Side Considerations 4.5. Client-Side Considerations
There are no provisions in the IRR mode for ensuring the There are no provisions in the IRR mode for ensuring the
confidentiality component for clients issuing queries. The overall confidentiality component for clients issuing queries. The overall
Confidentiality, Integrity, and Availability (CIA) model of the Confidentiality, Integrity, and Availability (CIA) model of the
system does lack this component, because the interface to IRRs is system does lack this component, because the interface to IRRs is
over an unencrypted TCP connection to port 43. This leaves the over an unencrypted TCP connection to port 43. This leaves the
transaction open to inspection such that an adversary could be able transaction open to inspection such that an adversary could be able
to inspect the query and the response. However, the IRR system is to inspect the query and the response. However, the IRR system is
intended to be composed of public policy information, and protection intended to be composed of public policy information, and protection
of queries was not part of the protection calculus when it was of queries was not part of the protection calculus when it was
designed, though the use of Transport Layer Security (TLS) [RFC5246] designed, though the use of Transport Layer Security (TLS) [RFC5246]
would address protections of query information. would address protections of query information.
4.6. Conclusions with respect to Data in the IRR 4.6. 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 testbed that reports to provide this function (under the
the auspices of the Resource PKI [RFC6480]) being formally discussed, auspices of the Resource PKI [RFC6480]) being formally discussed;
which could also aid in certification of resources within the IRR. this could also aid in certification of resources within the IRR. It
It should be noted that the RPKI is only currently able to support should be noted that the RPKI is only currently able to support
signing of Route Origin Authorization (ROA) resources that are the signing of Route Origin Authorization (ROA) resources that are the
equivalent of 'route' resources in the IRR. There has been some equivalent of 'route' resources in the IRR. There has been some
sentiment that the RPKI currently is not scoped to address the same sentiment that the RPKI currently is not scoped to address the same
set of issues and the nuanced policy applications that providers set of issues and the nuanced policy applications that providers
leverage in RPSL. It is unclear if, in the future, the RPKI will be leverage in RPSL. It is unclear if, in the future, the RPKI will be
extended to support additional resources that already exist in the extended to support additional resources that already exist in the
IRR, e.g.: aut-num, as-net, route-set, etc. Finally, a seemingly IRR, e.g., aut-num, as-net, route-set, etc. Finally, a seemingly
equivalent resource certification specification for all resources in equivalent resource certification specification for all resources in
the IRR has already been developed [RFC2725], however it is unclear the IRR has already been developed [RFC2725]; however, it is unclear
how widely it was ever implemented or deployed. how widely it was 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 other's contents. However, this
protocol has a several weaknesses. Namely, there is no way to protocol has several weaknesses. Namely, there is no way to validate
validate that the copy of mirrored source is correct and that the copy of mirrored source is correct, and synchronization
synchronization issues have often resulted. Furthermore, the NRTM issues have often resulted. Furthermore, the NRTM protocol does not
protocol does not employ any security mechanisms. The NRTM protocol employ any security mechanisms. The NRTM protocol relies on a pull
relies on a pull mechanism and is generally configured with a poll mechanism and is generally configured with a poll interval of 5 to 10
interval of 5 to 10 minutes. There is currently no mechanism to minutes. There is currently no mechanism to notify an IRR when an
notify an IRR when an update has occurred in a mirrored IRR so that update has occurred in a mirrored IRR so that an immediate update can
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 [RFC0959]. These FTP files are exported at made available via FTP [RFC959]. These FTP files are exported at
regular intervals of typically anywhere between 2 and 24 hours by the regular intervals of typically anywhere between 2 and 24 hours by the
IRRs. When a provider fetches those text files, it will process them IRRs. When a provider fetches those text files, it will process them
to identify any updates and reflect changes within its own internally to 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 for 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
[RPKI_SIZING]. [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 inter-domain bandwidth for resources, and, likely, a reduction in inter-domain bandwidth
consumption and associated costs. This is particularly beneficial consumption and associated costs. This is particularly beneficial
when, for example, an ISP is evaluating resources in an IRR just to when, for example, an ISP is evaluating resources in an IRR just to
determine if there are any modifications to those resources that will determine if there are any modifications to those resources that will
ultimately be reflected in a new routing policy that will get ultimately be reflected in a new routing policy that will get
propagated to (edge) routers in the ISP's network. Cache locality propagated to (edge) routers in the ISP's network. Cache locality
results in reduced inter-domain bandwidth utilization for each round results in reduced inter-domain bandwidth utilization for each round
trip. 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, increasing bandwidth demands have shifted demand towards In addition, due to demand for bandwidth, circuit sizes used by ISPs
circuit sizes used by ISPs to 10 Gbps, thus eliminating bandwidth as have increased to 10 Gbps, thus eliminating bandwidth as a
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 "Routing Policy System Replication"
Replication, attempted to offer a more methodical solution for [RFC2769] attempted to offer a more methodical solution for
distributed replication of resources between IRRs. It is unclear why distributed replication of resources between IRRs. It is unclear why
this RFC failed to gain traction, but it is suspected that this was that RFC failed to gain traction, but it is suspected that this was
due to that specification's reliance on [RFC2725], Routing Policy due to its reliance on "Routing Policy System Security" [RFC2725],
System Security, that addressed "the need to assure integrity of the which addressed "the need to assure integrity of the data by
data by providing an authentication and authorization model." providing an authentication and authorization model." Indeed,
Indeed, [RFC2725] attempts to add an otherwise absent security model [RFC2725] attempts to add an otherwise absent security model to the
to the integrity of policy statements made in RPSL. Without formal integrity of policy statements made in RPSL. Without formal
protections, it is possible for anyone to author a policy statement protections, it is possible for anyone to author a policy statement
about an arbitrary set of resources, and publish it (as discussed about an arbitrary set of resources, and publish it (as discussed
above in Section Section 4.1. above in Section 4.1.
5.2. Updating Routing Policies from Updated IRR Resources 5.2. Updating Routing Policies from Updated IRR Resources
Ultimately, the length of time it takes to replicate resources among Ultimately, the length of time it takes to replicate resources among
IRRs is, generally, the dominant factor in reflecting changes to IRRs is, generally, the dominant factor in reflecting changes to
resources in policy that is eventually applied within the Control resources in policy that is eventually applied within the control
Plane of routers. The length of time to update network elements will plane of routers. The length of time to update network elements will
vary considerably depending on the size of the ISP and the number of vary considerably depending on the size of the ISP and the number of
IRR resources that were updated during any given interval. However, IRR resources that were updated during any given interval. However,
there are a variety of common techniques, that are outside the scope there are a variety of common techniques, that are outside the scope
of this document, that allow for this automated process to be of this document, that allow for this automated process to be
optimized to considerably reduce the length of time it takes to optimized to considerably reduce the length of time it takes to
update policies in the ISP's network. update policies in the ISP's network.
An ISP will begin the process of updating the policy in their An ISP will begin the process of updating the policy in its network,
network, by first fetching IRR resources associated with, for first by fetching IRR resources associated with, for example, a
example, a customer ASN attached to their network. Next, the ISP customer ASN attached to its network. Next, the ISP constructs a new
constructs a new policy associated to that customer and then policy associated to that customer and then evaluates if that new
evaluates if that new policy is different from existing policy policy is different from existing policy associated with that same
associated with that same customer. If there are no changes between customer. If there are no changes between the new and existing
the new and existing policy associated with that customer, then the policy associated with that customer, then the ISP does not make any
ISP does not make any changes to the policy in their routers specific changes to the policy in their routers specific to that customer. On
to that customer. On the other hand, if the new policy does reflect the other hand, if the new policy does reflect changes from the
changes from the existing policy for that customer, then the ISP existing policy for that customer, then the ISP begins a process of
begins a process of uploading the new policy to the routers attached uploading the new policy to the routers attached to that customer.
to that customer.
The process of constructing a new policy involves use of a set of The process of constructing a new policy involves use of a set of
programs, e.g.: IRRtoolset, that performs recursive expansion of an programs, e.g., IRRtoolset, that performs recursive expansion of an
RPSL aut-num resource, that comprises an arbitrary combination of RPSL aut-num resource that comprises an arbitrary combination of
other RPSL aut-num, as-set, route and route-set resources, according other RPSL aut-num, as-set, route, and route-set resources, according
to procedures defined by RPSL. The end result of this process is, to procedures defined by RPSL. The end result of this process is,
traditionally, a router vendor dependent configuration snippet that traditionally, a vendor-dependent configuration snippet that defines
defines the routing policy for that customer. This routing policy the routing policy for that customer. This routing policy may
may consist of the set of IPv4 or IPv6 prefixes, associated prefix consist of the set of IPv4 or IPv6 prefixes, associated prefix
lengths and AS_PATH's that are supposed to be accepted from a lengths, and AS_PATHs that are supposed to be accepted from a
customer's eBGP session. However, if indicated in the appropriate customer's eBGP session. However, if indicated in the appropriate
RPSL resource, the policy may also set certain BGP Attributes, such RPSL resource, the policy may also set certain BGP Attributes, such
as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the
incoming eBGP session from the customer or on static routes that are incoming eBGP session from the customer or on static routes that are
originated by the resource holder. originated by the resource holder.
An ISP's customers may not adequately plan for pre-planned An ISP's customers may not adequately plan for pre-planned
maintenance or, more likely, need to rapidly begin announcing a new maintenance, or, more likely, they may need to rapidly begin
IP prefix as a result of, for example, an emergency turn-up of the announcing a new IP prefix as a result of, for example, an emergency
ISP customer's new downstream customer. Unfortunately, the routine, turn-up of the ISP customer's new downstream customer.
automated process employed by the ISP means that they may not begin Unfortunately, the routine, automated process employed by the ISP
updating their routing policy on their network for up to 24 hours, means that it may not begin updating its routing policy on its
because the ISP or the IRRs the ISP uses might only mirror changes to network for up to 24 hours, because the ISP or the IRRs the ISP uses
IRR resources once every 24 hours. The time interval for the might only mirror changes to IRR resources once every 24 hours. The
routine/automated process is not responsive to the needs of directly time interval for the routine/automated process is not responsive to
paying customer(s) who need rapid changes in their policy in rare the needs of directly paying customer(s) who need rapid changes in
situations. In these situations, when a customer has an urgent need their policy in rare situations. In these situations, when a
for updates to take effect immediately, they will call the Network customer has an urgent need for updates to take effect immediately,
Operations Center (NOC) of their ISP and request that the ISP they will call the Network Operations Center (NOC) of their ISP and
immediately fetch new IRR objects and push those changes out to their request that the ISP immediately fetch new IRR objects and push those
network. This is often accomplished in as little as five minutes changes out to its network. This is often accomplished in as little
from the time a customer contacts their ISP's NOC to the time a new as 5 minutes from the time a customer contacts their ISP's NOC to the
filtering policy is pushed out to the PE routers that are attached to time a new filtering policy is pushed out to the Provider Edge (PE)
that customer's Attachment Circuits (AC's). It is conceivable that routers that are attached to that customer's Attachment Circuits
some ISPs automate this using out-of-band mechanisms as well, (ACs). It is conceivable that some ISPs automate this using out-of-
although the authors are unaware of any existing mechanisms that band mechanisms as well, although the authors are unaware of any
support this. existing mechanisms that support this.
Ultimately, the aforementioned latency with respect to "emergency Ultimately, the aforementioned latency with respect to "emergency
changes" in IRR resources that need to be reflected in near-real-time changes" in IRR resources that need to be reflected in near-real-time
in the network is compounded if the IRR resources were being used by in the network is compounded if the IRR resources were being used by
third party ISPs to perform filtering on their peering circuits, third-party ISPs to perform filtering on their peering circuits,
where typically no such policies are employed today for this very where typically no such policies are employed today for this very
reason. It is likely that the length of time that it takes IRRs to reason. It is likely that the length of time that it takes IRRs to
mirror changes will have to be dramatically reduced. There will need mirror changes will have to be dramatically reduced. There will need
to be a corresponding reduction in the time needed by ISPs to to be a corresponding reduction in the time required by ISPs to
evaluate whether those changes need to be re-compiled and reflected evaluate whether those changes should be recompiled and reflected in
in router policies, which would then get pushed out to ASBR's and router policies that would then get pushed out to Autonomous System
connected to peering circuits on their network. Border Routers (ASBRs) connected to peering circuits on their
network.
6. Historical BGP Protocol Limitations 6. Historical BGP Protocol Limitations
As mentioned previously, after a resource holder made changes to As mentioned previously, after a resource holder made changes to
their resources in an IRR, those changes would automatically be their resources in an IRR, those changes would automatically be
distributed to other IRRs, ISPs would then learn of those changes, distributed to other IRRs, ISPs would then learn of those changes,
generate a new BGP policies, and then apply those to the appropriate generate new BGP policies, and then apply those to the appropriate
subset of routers in their ASes. However, in the past, one subset of routers in their ASes. However, in the past, one
additional step is necessary in order to have any of those new BGP additional step is necessary in order to have any of those new BGP
policies take effect in the Control Plane and to allow/deny the policies take effect in the control plane and to allow/deny the
updated resource from a customer to their ISP and from their updated resource from a customer to their ISP and from their
immediately upstream ISP to the ISP's peers. It was necessary (often immediately upstream ISP to the ISP's peers. It was necessary (often
manually) to actually induce BGP on each router to apply the new manually) to actually induce BGP on each router to apply the new
policy within the Control Plane, thus learning of a newly announced/ policy within the control plane, thus learning of a newly announced/
changed IP prefix (or, dropping a deleted IP prefix). Unfortunately, changed IP prefix (or, dropping a deleted IP prefix). Unfortunately,
most of these methods were not only highly operationally impactful, most of these methods not only were highly impactful operationally,
but also affected traffic forwarding to IP destinations that were but they also affected traffic forwarding to IP destinations that
unrelated to the most recent changes to the BGP policy. were unrelated to the most recent changes to the BGP policy.
Historically, a customer would have to (re-)announce the new IP Historically, a customer would have to (re-)announce the new IP
prefix toward their ISP, but only after the ISP had placed the new prefix toward their ISP, but only after the ISP had put the new BGP
BGP policies into affect. Alternatively, the ISP would have to reset policies into effect. Alternatively, the ISP would have to reset the
the entire PE-CE eBGP session either by: a) bouncing the entire entire eBGP session from Provider Edge to Customer Edge either by: a)
interface toward the customer, (e.g.: shutdown/no shutdown); or, b) bouncing the entire interface toward the customer (e.g., shutdown /
clearing the eBGP session toward the customer, (e.g.: clear ip bgp no shutdown) or b) clearing the eBGP session toward the customer
neighbor >IP address of CE router<). The latter two cases were, of (e.g., clear ip bgp neighbor <IP address of CE router>, where <IP
course, the most highly impactful and thus could generally only be address of CE router> represents a specific IP address). The latter
performed off-hours during a maintenance window. two cases were, of course, the most highly impactful impact and thus
could generally only be performed off-hours during a maintenance
window.
Once the new IP prefix has been successfully announced by the Once the new IP prefix has been successfully announced by the
customer and permitted by the newly updated policy at the ISP's PE's customer and permitted by the newly updated policy at the ISP's PEs
(attached to that customer), it would be propagated to that ISP's (attached to that customer), it would be propagated to that ISP's
ASBR's, attached to peers, at the perimeter of the ISP network. ASBRs, attached to peers, at the perimeter of the ISP network.
Unfortunately, if those peers had either not yet learned of the Unfortunately, if those peers had either not yet learned of the
changes to resources in the IRR or pushed out new BGP policies (and, changes to resources in the IRR or pushed out new BGP policies (and,
reset their BGP sessions immediately afterward) incorporating those reset their BGP sessions immediately afterward) incorporating those
changes, then the newly announced route would also get dropped at the changes, then the newly announced route would also get dropped at the
ingress ASBR's of the peers. ingress ASBRs of the peers.
Ultimately, either of the two scenarios above further lengthen the Ultimately, either of the two scenarios above further lengthens the
effective time it would take for changes in IRR resources to take effective time it would take for changes in IRR resources to take
effect within BGP in the network. Fortunately, BGP has been enhanced effect within BGP in the network. Fortunately, BGP has been enhanced
over the last several years in order that changes within BGP policy over the last several years in order that changes within BGP policy
will take affect without requiring a service impacting reset of BGP will take effect without requiring a service-impacting reset of BGP
sessions. Specifically, BGP soft-reconfiguration ([RFC2918] Section sessions. Specifically, BGP soft-reconfiguration (Section 1 of
1) and, later, Route Refresh Capability for BGP-4 [RFC2918] were [RFC2918]) and, later, Route Refresh Capability for BGP-4 [RFC2918]
developed so that ISPs, or their customers, could induce BGP to apply were developed so that ISPs, or their customers, could induce BGP to
a new policy while leaving both the existing eBGP session active as apply a new policy while leaving both the existing eBGP session
well as (unaffected) routes active in both the Loc-RIB and, more active as well as (unaffected) routes active in both the Loc-RIB and,
importantly, FIB of the router. Thus, using either of these more importantly, FIB of the router. Thus, using either of these
mechanisms, an ISP or its peers currently will deploy a newly mechanisms, an ISP or its peers currently will deploy a newly
generated BGP policy, based on changes to resources within the IRR, generated BGP policy, based on changes to resources within the IRR,
and immediately trigger a non-service impacting notification to the and immediately trigger a notification -- which does not impact
BGP process to have those changes take effect in their Control Plane, service -- to the BGP process to have those changes take effect in
either allowing a new IP prefix to be announced or an old IP prefix their control plane, either allowing a new IP prefix to be announced
to be dropped. This dramatically reduces the length of time after or an old IP prefix to be dropped. This dramatically reduces the
changes are propagated throughout the IRRs to when those changes are length of time from when changes are propagated throughout the IRRs
actually operational within BGP policy in an ISP's network. to when those changes are actually operational within BGP policy in
an ISP's network.
7. Historical Limitations of Routers 7. Historical Limitations of Routers
7.1. Incremental Updates to Policy on Routers 7.1. Incremental Updates to Policy on Routers
Routers in the mid 1990's rarely supported incrementally updatable Routers in the mid 1990s rarely supported incrementally updatable
prefix filters for BGP, and therefore, if new information was prefix filters for BGP; therefore, if new information was received
received from a policy or internal configuration database that would from a policy or internal configuration database that would impact a
impact a policy applied to a given eBGP peer, the entire prefix list policy applied to a given eBGP peer, the entire prefix list or access
or access list would need to be deleted and rewritten, compiled, and list would need to be deleted and rewritten, compiled, and installed.
installed. This was very tedious and commonly led to leaked routes This was very tedious and commonly led to leaked routes during the
during the time when the policy was being rewritten, compiled, and time when the policy was being rewritten, compiled, and applied on a
applied on a router. Furthermore, application of a new policy would router. Furthermore, application of a new policy would not
not automatically result in new ingress or egress reachability automatically result in new ingress or egress reachability
advertisements, from that new policy, because routers at the time advertisements from that new policy, because routers at the time
would require a reset of the eBGP sessions for routing information to would require a reset of the eBGP sessions for routing information to
be evaluated by the new policy. Of course, resetting of an eBGP be evaluated by the new policy. Of course, resetting of an eBGP
session had implications on traffic forwarding during the time the session had implications on traffic forwarding during the time the
eBGP session was reestablished and new routing information was eBGP session was reestablished and new routing information was
learned. learned.
Routers now support the ability to perform incremental, and in situ, Routers now support the ability to perform incremental, and in situ,
updates to filter lists consisting of IP prefixes and/or AS_PATH's updates to filter lists consisting of IP prefixes and/or AS_PATHs
that are used within an ingress or egress BGP policy. In addition, that are used within an ingress or egress BGP policy. In addition,
routers also can apply those incremental updates to policy, with no routers also can apply those incremental updates to policy, with no
traffic disruption, using BGP soft-reconfiguration or BGP Route traffic disruption, using BGP soft-reconfiguration or BGP Route
Refresh, as discussed in the previous section. Refresh, as discussed in the previous section.
7.2. Storage Requirements for Policy on Routers 7.2. Storage Requirements for Policy on Routers
Historically, routers had very limited storage capacity and would Historically, routers had very limited storage capacity and would
have difficulty in storing an extremely large BGP policy on-board. have difficulty in storing an extremely large BGP policy on-board.
This was typically the result of router hardware vendors using an This was typically the result of router hardware vendors using an
skipping to change at page 14, line 50 skipping to change at page 14, line 5
Another challenge with historical router hardware was that writing to Another challenge with historical router hardware was that writing to
NVRAM was extremely slow. For example, when the router configuration NVRAM was extremely slow. For example, when the router configuration
had changed as a result of updating a BGP policy that needed to had changed as a result of updating a BGP policy that needed to
accommodate changes in IRR resources, this would result in extremely accommodate changes in IRR resources, this would result in extremely
long times to write out these configuration changes. Sometimes, due long times to write out these configuration changes. Sometimes, due
to bugs, this would result in loss of protocol keep-alives. This to bugs, this would result in loss of protocol keep-alives. This
would cause an impact to routing or forwarding of packets through the would cause 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 equipment from
equipment from the last few years shipping with increasing amounts of the last few years that ships with increasing amounts of non-volatile
non-volatile storage such as: PCMCIA or USB Flash Cards, Hard Disk storage such as PCMCIA or USB flash cards, hard disk drives, or
Drives or Solid State Disk Drives. solid-state disk drives.
However, as capacities and technologies have evolved on modern However, as capacities and technologies have evolved on modern
routing hardware, so have some of the scaling requirements of the routing hardware, so have some of the scaling requirements of the
data. In some large networks, configuration growth has begun to data. In some large networks, configuration growth has begun to
"pose challenges" [IEPG89_NTT]. While the enhancements of hardware "pose challenges" [IEPG89_NTT]. While the enhancements of hardware
have overcome some historical limitations, evidence suggests that have overcome some historical limitations, evidence suggests that
further optimizations in configuration processing may be needed in further optimizations in configuration processing may be needed in
some cases. Some of the more recent operational issues include some cases. Some of the more recent operational issues include
scheduler slips and protracted commit times. This suggests that even scheduler slips and protracted commit times. This suggests that even
though many historical hurdles have been overcome, there are still though many historical hurdles have been overcome, there are still
motivations to optimize and modernize IRR technologies. 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 modeling language for
modeling language or an associated method to update router network configuration 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 vendor-dependent BGP policy and upload
upload that to the router usually via the following method. 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 out-of-band server. Next, the operator uses processes running on an out-of-band server. Next, the operator uses
either telnet or SSH [RFC4253] to login to the CLI of a target router either telnet or SSH [RFC4253] to log in to the CLI of a target
and issue router vendor dependent CLI commands that will trigger the router and issue vendor-dependent CLI commands that will trigger the
target router to fetch the new configuration snippet via TFTP, FTP or target router to fetch the new configuration snippet via TFTP, FTP,
Secure Copy (SCP) stored on the out-of-band server. The target or Secure Copy (SCP) stored on the out-of-band server. The target
router will then perform syntax checking on that configuration router will then perform syntax checking on that configuration
snippet and, if that passes, merge that configuration snippet into snippet and, if that passes, merge that configuration snippet into
the running configuration of the router's Control Software. At this the running configuration of the router's control software. At this
point, the new BGP policy configuration 'snippet' is active within point, the new BGP policy configuration snippet is active within the
the Control Plane of the router. One last step remains, which is the control plane of the router. One last step remains -- the operator
operator will issue a CLI command to induce the router to perform a will issue a CLI command to induce the router to perform a "soft
"soft reset", via BGP soft-reconfiguration or BGP Route Refresh, of reset", via BGP soft-reconfiguration or BGP Route Refresh, of the
the associated BGP session in order to trigger the router to apply associated BGP session in order to trigger the router to apply the
the new policy to routes learned from that BGP session without new policy to routes learned from that BGP session without disrupting
disrupting traffic forwarding. traffic forwarding.
More recently, operators have the ability to use NETCONF [RFC6241] / More recently, operators have the ability to use NETCONF [RFC6241] /
SSH (or, TLS) from an out-of-band server to push a BGP configuration SSH (or, TLS) from an out-of-band server to push a BGP configuration
'snippet' from an out-of-band server toward a target router that has snippet from an out-of-band server toward a target router that has
that capability. However, this activity is still dependent on that capability. However, this activity is still dependent on
generating, via the out-of-band server, a router vendor dependent XML generating, via the out-of-band server, a vendor-dependent XML
configuration snippet that would get uploaded via SSH or TLS to the configuration snippet that would get uploaded via SSH or TLS to the
target router. 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 (AS_PATHs, BGP communities, etc.) that might be
might be associated with that ROA information, like they can from IRR associated with that ROA information, as they can from IRR-generated
generated BGP policies. BGP policies.
8. Summary 8. Summary
As discussed above, many of the problems that have traditionally As discussed above, many of the problems that have traditionally
stifled IRR deployment have, themselves, become historical. However, stifled IRR deployment have, themselves, become historical. However,
there are still real operational considerations that limit IRR usage there are still real operational considerations that limit IRR usage
from realizing its full effectiveness. The potential for IRRs to from realizing its full effectiveness. The potential for IRRs to
express inter-domain routing policy, and to allow relying parties to express inter-domain routing policy, and to allow relying parties to
learn policy, has always positioned it as a strong candidate to aid learn policy, has always positioned them as a strong candidate to aid
the security postures of operators. However, while routing density the security postures of operators. However, while routing density
and complexity have grown, so have some of the challenges facing IRRs and complexity have grown, so have some of the challenges facing IRRs
(even today). Because of this state increase, the potential to model (even today). Because of this state increase, the potential to model
all policies for all ASes in all routers may still remain illusive. all policies for all ASes in all routers may still remain illusive.
In addition, without an operationally deployed resource certification In addition, without an operationally deployed resource certification
framework that can tie policies to resource holders, there is a framework that can tie policies to resource holders, there is a
fundamental limitation that still exists. fundamental limitation that still exists.
9. Security Considerations 9. Security Considerations
One of the central concerns with IRRs is the ability of an IRR One of the central concerns with IRRs is the ability of an IRR
operator to remotely influence the routing operations of an external operator to remotely influence the routing operations of an external
consumer. Specifically, if the processing of IRR contents can become consumer. Specifically, if the processing of IRR contents can become
burdensome, or if the policy statements can be crafted to introduce burdensome, or if the policy statements can be crafted to introduce
routing problems or anomalies, then operators may want to be routing problems or anomalies, then operators may want to be
circumspect about ingesting contents from external parties. A circumspect about ingesting contents from external parties. A
resource certification framework should be used to address the resource certification framework should be used to address the
authorization of IRR statements to make attestations and to authorization of IRR statements to make attestations and assertions
assertions (as mentioned in Section 4.1, and discussed above in (as mentioned in Section 4.1, and discussed in Section 5.1).
Section Section 5.1).
Additionally, the external and systemic dependencies introduced by Additionally, the external and systemic dependencies introduced by
IRRs and other such systems employed to inform routing policy, and IRRs and other such systems employed to inform routing policy, and
how tightly or loosely coupled those systems are to the global how tightly or loosely coupled those systems are to the global
routing system and operational networks, introduces additional routing system and operational networks, introduce additional vectors
vectors that operators and system architects should consider when that operators and system architects should consider when evaluating
evaluating attack surface and service dependencies associated with attack surface and service dependencies associated with those
those elements. These attributes and concerns are certainly not elements. These attributes and concerns are certainly not unique to
unique to IRRs, and operators should evaluate the implications of IRRs, and operators should evaluate the implications of external
external systems and varying degrees of coupling and operational systems and the varying degrees of coupling and operational buffers
buffers that might be installed in their environments. 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, Wes George, and John Curran for their help and constructive
feedback.
12. Informative References 10. Informative References
[IEPG89_NTT] [IEPG89_NTT]
"NTT BGP Configuration Size and Scope", IEPG 89 http:// Mauch, J., "NTT BGP Configuration Size and Scope", IEPG
iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf. meeting before IETF 89, March 2014,
<http://iepg.org/2014-03-02-ietf89/
ietf89_iepg_jmauch.pdf>.
[IRR_LIST] [IRR_LIST] Merit Network, Inc., "List of Routing Registries",
Merit Network, Inc., "List of Routing Registries", List of <http://www.irr.net/docs/list.html>.
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, Osterweil, E., Amante, S., Massey, D., and D. McPherson,
"The Great IPv4 Land Grab: Resource Certification for the "The Great IPv4 Land Grab: Resource Certification for the
IPv4 Grey Market", IPv4 Grey Market", DOI 10.1145/2070562.2070574,
HotNets-X http://dl.acm.org/citation.cfm?id=2070574. <http://dl.acm.org/citation.cfm?id=2070574>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<http://www.rfc-editor.org/info/rfc959>. <http://www.rfc-editor.org/info/rfc959>.
[RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet",
RFC 1787, DOI 10.17487/RFC1787, April 1995, RFC 1787, DOI 10.17487/RFC1787, April 1995,
<http://www.rfc-editor.org/info/rfc1787>. <http://www.rfc-editor.org/info/rfc1787>.
[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 18, line 24 skipping to change at page 17, line 10
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
DOI 10.17487/RFC2918, September 2000, DOI 10.17487/RFC2918, September 2000,
<http://www.rfc-editor.org/info/rfc2918>. <http://www.rfc-editor.org/info/rfc2918>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>. January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[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, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[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,
DOI 10.17487/RFC6810, January 2013, DOI 10.17487/RFC6810, January 2013,
<http://www.rfc-editor.org/info/rfc6810>. <http://www.rfc-editor.org/info/rfc6810>.
[RIPE2007-01] [RIPE638] RIPE NCC, "Autonomous System (AS) Number Assignment
RIPE NCC, "DRAFT: Autonomous System (AS) Number Assignment Policies", March 2015,
Policies and Procedures", Foundation <https://www.ripe.net/publications/docs/ripe-638>.
Policy http://www.ripe.net/ripe/docs/ripe-452.
[RPKI_SIZING] [RPKI_SIZING]
Osterweil, E., Manderson, T., White, R., and D. McPherson, Osterweil, E., Manderson, T., White, R., and D. McPherson,
"Sizing Estimates for a Fully Deployed RPKI", Verisign "Sizing Estimates for a Fully Deployed RPKI", Verisign
Labs Technical Report 1120005 version 2 http:// Labs Technical Report 1120005 version 2, December 2012,
techreports.verisignlabs.com/ <http://techreports.verisignlabs.com/
tr-lookup.cgi?trid=1120005&rev=2. tr-lookup.cgi?trid=1120005&rev=2>.
[TASRS] Osterweil, E., Amante, S., and D. McPherson, "TASRS: [TASRS] Osterweil, E., Amante, S., and D. McPherson, "TASRS:
Towards a Secure Routing System Through Internet Number Towards a Secure Routing System Through Internet Number
Resource Certification", Verisign Labs Technical Report Resource Certification", Verisign Labs Technical
1130009 http://techreports.verisignlabs.com /tr- Report 1130009, February 2013,
lookup.cgi?trid=1130009&rev=1. <http://techreports.verisignlabs.com/
tr-lookup.cgi?trid=1130009&rev=1>.
Acknowledgements
The authors would like to acknowledge and thank Chris Morrow, Jeff
Haas, Wes George, and John Curran for their help and constructive
feedback.
Authors' Addresses Authors' Addresses
Danny McPherson Danny McPherson
Verisign, Inc. Verisign, Inc.
Email: dmcpherson@verisign.com Email: dmcpherson@verisign.com
Shane Amante Shane Amante
Apple, Inc. Apple, Inc.
Email: amante@apple.com
Eric Osterweil Eric Osterweil
Verisign, Inc. Verisign, Inc.
Email: eosterweil@verisign.com Email: eosterweil@verisign.com
Larry J. Blunk Larry J. Blunk
Merit Network, Inc. Merit Network, Inc.
Email: ljb@merit.edu Email: ljb@merit.edu
Dave Mitchell Dave Mitchell
Singularity Networks Singularity Networks
Email: dave@singularity.cx
 End of changes. 92 change blocks. 
347 lines changed or deleted 334 lines changed or added

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