doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc7682.txt b/doc/rfc/rfc7682.txt
new file mode 100644
index 0000000..7667fb6
--- /dev/null
+++ b/doc/rfc/rfc7682.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      D. McPherson
+Request for Comments: 7682                                Verisign, Inc.
+Category: Informational                                        S. Amante
+ISSN: 2070-1721                                              Apple, Inc.
+                                                            E. Osterweil
+                                                          Verisign, Inc.
+                                                                L. Blunk
+                                                     Merit Network, Inc.
+                                                             D. Mitchell
+                                                    Singularity Networks
+                                                           December 2015
+
+
+         Considerations for Internet Routing Registries (IRRs)
+                    and Routing Policy Configuration
+
+Abstract
+
+   The purpose of this document is to catalog issues that influenced the
+   efficacy of Internet Routing Registries (IRRs) for inter-domain
+   routing policy specification and application in the global routing
+   system over the past two decades.  Additionally, it provides a
+   discussion regarding which of these issues are still problematic in
+   practice, and which are simply artifacts that are no longer
+   applicable but continue to stifle inter-provider policy-based
+   filtering adoption and IRR utility to this day.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 1]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Historical Artifacts Influencing IRR Efficacy . . . . . . . .   3
+   4.  Accuracy and Integrity of Data Contained within the IRR . . .   4
+     4.1.  Lack of Resource Certification  . . . . . . . . . . . . .   4
+     4.2.  Incentives to Maintain Data within the IRR  . . . . . . .   5
+     4.3.  Inability for Third Parties to Remove (Stale) Information
+           from the IRRs . . . . . . . . . . . . . . . . . . . . . .   6
+     4.4.  Lack of Authoritative IRR for Resources . . . . . . . . .   7
+     4.5.  Client-Side Considerations  . . . . . . . . . . . . . . .   8
+     4.6.  Conclusions with Respect to Data in the IRR . . . . . . .   8
+   5.  Operation of the IRR Infrastructure . . . . . . . . . . . . .   8
+     5.1.  Replication of Resources among IRRs . . . . . . . . . . .   8
+     5.2.  Updating Routing Policies from Updated IRR Resources  . .  10
+   6.  Historical BGP Protocol Limitations . . . . . . . . . . . . .  11
+   7.  Historical Limitations of Routers . . . . . . . . . . . . . .  13
+     7.1.  Incremental Updates to Policy on Routers  . . . . . . . .  13
+     7.2.  Storage Requirements for Policy on Routers  . . . . . . .  13
+     7.3.  Updating Configuration on Routers . . . . . . . . . . . .  14
+   8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   10. Informative References  . . . . . . . . . . . . . . . . . . .  16
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 2]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+1.  Introduction
+
+   The purpose of this document is to catalog issues influencing the
+   efficacy of Internet Routing Registries (IRRs) for inter-domain
+   routing policy specification and application in the global routing
+   system over the past two decades.  Additionally, it provides a
+   discussion regarding which of these issues still pose problems in
+   practice, and which are no longer obstacles, but whose perceived
+   drawbacks continue to stifle inter-provider policy-based filtering
+   support and IRR utility to this day.
+
+2.  Background
+
+   IRRs can be used to express a multitude of Internet number bindings
+   and policy objectives, i.e., to include bindings between 1) an origin
+   AS and a given prefix, 2) a given AS and its AS and community import
+   and export policies, as well as 3) a given AS and the AS macros (as-
+   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 "Routing in a Multi-Provider Internet"
+   [RFC1787]:
+
+      While ensuring Internet-wide coordination may be more and more
+      difficult, as the Internet continues to grow, stability and
+      consistency of the Internet-wide routing could significantly
+      benefit if the information about routing requirements of various
+      organizations could be shared across organizational boundaries.
+      Such information could be used in a wide variety of situations
+      ranging from troubleshooting to detecting and eliminating
+      conflicting routing requirements.  The scale of the Internet
+      implies that the information should be distributed.  Work is
+      currently underway to establish depositories of this information
+      (Routing Registries), as well as to develop tools that analyze, as
+      well as utilize this information.
+
+3.  Historical Artifacts Influencing IRR Efficacy
+
+   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, RPSL,
+   and the operational deployment of policy (derived from RPSL contained
+   within the IRR) to routers.  It is important to classify these issues
+   into distinct categories so that the reader can understand which
+   categories of issues are historical artifacts that are no longer
+   applicable and which categories of issues still exist and might be
+   addressed by the IETF.
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 3]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   The following sections will separate out challenges related to the
+   IRR into the following categories: first, accuracy and integrity of
+   data contained within the IRR; second, operation of the IRR
+   infrastructure, i.e., synchronization of resources from one IRR to
+   other IRRs; and finally, this document covers the methods related to
+   extraction of policy from the IRR and the input, plus activation of
+   that policy within routers.
+
+4.  Accuracy and Integrity of Data Contained within the IRR
+
+   The following section will examine issues related to accuracy and
+   integrity of data contained within the IRR.
+
+4.1.  Lack of Resource Certification
+
+   Internet number resources include IPv4 addresses, IPv6 addresses,
+   Autonomous System Numbers (ASNs), and more.  While these resources
+   are generally allocated by hierarchical authorities, a general
+   mechanism for formally verifying (such as through cryptographic
+   mechanisms) when parties have been allocated resources remains an
+   open challenge.  We generally call such a system a Resource
+   Certification System, and we note that some candidate examples of how
+   such a general system might be implemented and deployed exist --
+   [TASRS], [RC_HotNetsX], and [RFC6480].
+
+   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.
+   This is largely attributable to the fact that existing IRR mechanisms
+   do not provide ways for a relying party to (cryptographically) verify
+   the validity of an IRR object.  That is, there has never existed a
+   resource certification infrastructure that enables a resource holder
+   to authorize a particular autonomous system to originate network-
+   layer reachability advertisements for a given IPv4 or IPv6 prefix.
+   It should be noted that this is not a weakness of the underlying RPSL
+   [RFC2622], but rather, was largely the result of no clear demand by
+   the operator community for Internet Number Resource Registries to
+   provide sufficient resource certification infrastructure that would
+   enable a resource holder to develop a cryptographic binding between,
+   for example, a given AS number and an IP prefix.
+
+   Another noteworthy (but slightly different) deficiency in the IRR
+   system is the absence of a tangible tie between the resource and the
+   resource holder.  That is, generally there is no assurance of the
+   validity of objects at their creation time (except for a subset of,
+   for example, the RIPE IRR where RPSS [RFC2725] attests for RIPE
+   address holders and RIPE ASN holders).  If a resource holder's
+   authorization cannot be certified, then consumers cannot verify
+   attestations made.  In effect, without resource certification,
+
+
+
+McPherson, et al.             Informational                     [Page 4]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   consumers are basically only certifying the assertions that the
+   creator/maintainer of the resource object has made (not if that
+   assertion is valid).
+
+   The RIPE community addressed this last issue by putting in a
+   foundation policy [RIPE638], which requires a contractual link
+   between the RIPE NCC and the end user in direct assignment + ASN
+   assignment cases, which weren't previously covered by Local Internet
+   Registry (LIR) contracts for address allocations.  There were a
+   couple of intentions with this policy:
+
+   1.  There was an encumbrance placed in the policy for the LIR to
+       charge the end user for provider-independent (PI) resources.
+       This action created a collection mechanism for PI address
+       resources (IPv4/IPv6 space, ASNs).
+
+   2.  It guaranteed that all RIPE NCC allocated/assigned space would be
+       subject to a contractual link, and that this contractual chain
+       might end up actually meaning something when it came to the issue
+       of who made what claim about what number resource.
+
+   3.  It tied into the RIPE NCC's object grandfathering policy that
+       ties the registration details of the end user to the object
+       registered in the IRR database.
+
+   While this policy specifically addressed PI/portable space holders,
+   other regions address this issue, too.  Further, a tangible tie
+   between the resource and the resource holder is indeed a prerequisite
+   for resource certification, though it does not directly address the
+   IRR deficiencies.
+
+   One of the central observations of this policy was that without a
+   chain-of-ownership functionality in IRR databases, the discussion of
+   certifying their contents becomes moot.
+
+4.2.  Incentives to Maintain Data within the IRR
+
+   A second problem with data contained in the IRRs is that the
+   incentives for resource holders to maintain both accurate and up-to-
+   date information in one or more IRRs (including deletion of out-of-
+   date or stale data from the IRRs) can diminish rapidly when changing
+   their peering policies (such as switching transit providers).
+   Specifically, there is a very strong incentive for an ISP's customers
+   to register new routing information in the IRR, because some ISPs
+   enforce a strict policy that they will only build or update a
+   customer's prefix-lists applied to the customer's inbound eBGP
+   sessions based off information found within the IRRs.  Unfortunately,
+   there is little incentive for an ISP's customers to remove out-of-
+
+
+
+McPherson, et al.             Informational                     [Page 5]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   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
+   IRRs to automatically build incoming policy applied to the customer's
+   eBGP sessions.  For example, if a customer is terminating service
+   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
+   not require use of IRR data, then that customer will likely let the
+   data in the IRR become stale or inaccurate.
+
+   Further, policy filters are almost exclusively generated based on the
+   origin AS information contained within IRR route objects and used by
+   providers to filter downstream transit customers.  Since providers
+   only look for route objects containing the origin AS of their
+   downstream customer(s), stale route objects with historical and,
+   possibly, incorrect origin AS information are ignored.  Assuming that
+   the downstream customer(s) do not continue to announce those routes
+   with historical, or incorrect, origin AS information in BGP to the
+   upstream provider, there is no significant incentive to remove them
+   as they do not impact offline policy filter generation nor routing on
+   the Internet.  On the other hand, the main incentive that causes the
+   Service Provider to work with downstream customer(s) is when the
+   resultant filter list becomes so large that it is difficult for it to
+   be stored on PE routers; however, this is more practically an
+   operational issue with very old, legacy PE routers, not more modern
+   PE router hardware with more robust control-plane engines.
+
+4.3.  Inability for Third Parties to Remove (Stale) Information from the
+      IRRs
+
+   A third challenge with data contained in IRRs is that it is not
+   possible for IRR operators, and ISPs who use them, to proactively
+   remove (perceived) out-of-date or "stale" resources in an IRR, on
+   behalf of resource holders who may not be diligent in maintaining
+   this information themselves.  The reason is that, according to the
+   RPSL [RFC2622], only the resource holder ('mntner') specified in a
+   'mnt-by' value field of an RPSL resource is authorized to add,
+   modify, or delete their own resources within the IRR.  To address
+   this issue, the 'auth-override' mechanism [RFC2725] was later
+   developed that would have enabled a third party to update and/or
+   remove "stale" resources from the IRR.  While it is unclear if this
+   was ever implemented or deployed, it does provide language semantics
+   needed to overcome this obstacle.
+
+   Nevertheless, with such a mechanism in place, there is still a risk
+   that the original RPSL resource holder would not receive
+   notifications (via the 'notify' attribute in various RPSL resources)
+   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.
+
+
+
+McPherson, et al.             Informational                     [Page 6]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   In this case, if the removal of a resource was not suspended, it
+   could potentially result in an unintentional denial of service for
+   the RPSL resource holder when, for example, ISPs automatically
+   generated and deployed a new policy based on the newly removed
+   resources from the IRR, thus dropping any reachability announcement
+   for the removed resource in eBGP.
+
+4.4.  Lack of Authoritative IRR for Resources
+
+   According to [RFC2622], within an RPSL resource "the source attribute
+   specifies the registry where the object is registered."  Note that
+   this source attribute only exists within the RPSL resource itself.
+   Unfortunately, given a specific resource (e.g., a specific IPv4 or
+   IPv6 prefix), most of the time it is impossible to determine a priori
+   the authoritative IRR where to query and retrieve an authoritative
+   copy of that resource.
+
+   This makes it difficult for consumers of data from the IRR to
+   automatically know the authoritative IRR of a resource holder that
+   will contain the most up-to-date set of resources.  This is typically
+   not a problem for an ISP that has a direct (customer) relationship
+   with the resource holder, because the ISP will ask the resource
+   holder which (authoritative) IRR to pull their resources from on, for
+   example, a "Customer BGP Order Form".  However, third parties that do
+   not have a direct relationship with the resource holder have a
+   difficult time attempting to infer the authoritative IRR, preferred
+   by the resource holder, that likely contains the most up-to-date set
+   of resources.  As a result, it would be helpful for third parties if
+   there were a robust referral mechanism so that a query to one IRR
+   would be automatically redirected toward the authoritative IRR for
+   the most up-to-date and authoritative copy of that particular
+   resource.  This problem is worked around by individual IRR operators
+   storing a local copy of other IRRs' resources, through periodic
+   mirroring, which allows the individual IRR to respond to a client's
+   query with all registered instances of a particular IRR resource that
+   exist in both the local IRR and all other IRRs.  Of course, the
+   problem with this approach is that an individual IRR operator is
+   under no obligation to mirror all other IRRs and, in practice, some
+   IRRs do not mirror the resources from all other IRRs.  This could
+   lead to the false impression that a particular resource is not
+   registered or maintained at a particular IRR.  Furthermore, the
+   authentication process of accepting updates by any given IRR may or
+   may not be robust enough to overcome impersonation attacks.  As a
+   result, there is no rigorous assurance that a mirrored RPSL statement
+   was actually made by the authorized resource holder.
+
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 7]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+4.5.  Client-Side Considerations
+
+   There are no provisions in the IRR mode for ensuring the
+   confidentiality component for clients issuing queries.  The overall
+   Confidentiality, Integrity, and Availability (CIA) model of the
+   system does lack this component, because the interface to IRRs is
+   over an unencrypted TCP connection to port 43.  This leaves the
+   transaction open to inspection such that an adversary could be able
+   to inspect the query and the response.  However, the IRR system is
+   intended to be composed of public policy information, and protection
+   of queries was not part of the protection calculus when it was
+   designed, though the use of Transport Layer Security (TLS) [RFC5246]
+   would address protections of query information.
+
+4.6.  Conclusions with Respect to Data in the IRR
+
+   All of the aforementioned issues related to integrity and accuracy of
+   data within the IRR stem from a distinct lack of resource
+   certification for resources contained within the IRR.  Only now is an
+   experimental testbed that reports to provide this function (under the
+   auspices of the Resource PKI [RFC6480]) being formally discussed;
+   this could also aid in certification of resources within the IRR.  It
+   should be noted that the RPKI is only currently able to support
+   signing of Route Origin Authorization (ROA) resources that are the
+   equivalent of 'route' resources in the IRR.  There has been some
+   sentiment that the RPKI currently is not scoped to address the same
+   set of issues and the nuanced policy applications that providers
+   leverage in RPSL.  It is unclear if, in the future, the RPKI will be
+   extended to support additional resources that already exist in the
+   IRR, e.g., aut-num, as-net, route-set, etc.  Finally, a seemingly
+   equivalent resource certification specification for all resources in
+   the IRR has already been developed [RFC2725]; however, it is unclear
+   how widely it was ever implemented or deployed.
+
+5.  Operation of the IRR Infrastructure
+
+5.1.  Replication of Resources among IRRs
+
+   Currently, several IRRs [IRR_LIST]  use a Near-Real-Time Mirroring
+   (NRTM) protocol to replicate each other's contents.  However, this
+   protocol has several weaknesses.  Namely, there is no way to validate
+   that the copy of mirrored source is correct, and synchronization
+   issues have often resulted.  Furthermore, the NRTM protocol does not
+   employ any security mechanisms.  The NRTM protocol relies on a pull
+   mechanism and is generally configured with a poll interval of 5 to 10
+   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
+   be made.
+
+
+
+McPherson, et al.             Informational                     [Page 8]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   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
+   made available via FTP [RFC959].  These FTP files are exported at
+   regular intervals of typically anywhere between 2 and 24 hours by the
+   IRRs.  When a provider fetches those text files, it will process them
+   to identify any updates and reflect changes within its own internally
+   maintained database.  The use of an internally maintained database is
+   out of scope for this document but is generally used to assist with
+   more straightforward access to or modification of data by the IRR
+   operator.  Providers typically employ a 24-hour cycle to pull updated
+   resources from IRRs.  Thus, depending on when resource holders
+   submitted their changes to an IRR, it may take up to 24 hours for
+   those changes to be reflected in their policy configurations.  In
+   practice, it appears that the RPKI will also employ a 24-hour cycle
+   whereby changes in resources are pushed out to other RPKI caches
+   [RPKI_SIZING].
+
+   IRRs originated from Section 7 of [RFC1787], specifically: "The scale
+   of the Internet implies that the [routing requirements] information
+   should be distributed."  Regardless, the practical effect of an
+   organization maintaining its own local cache of IRR resources is an
+   increase in resource resiliency (due to multiple copies of the same
+   resource being geographically distributed), a reduction in query time
+   for resources, and, likely, a reduction in inter-domain bandwidth
+   consumption and associated costs.  This is particularly beneficial
+   when, for example, an ISP is evaluating resources in an IRR just to
+   determine if there are any modifications to those resources that will
+   ultimately be reflected in a new routing policy that will get
+   propagated to (edge) routers in the ISP's network.  Cache locality
+   results in reduced inter-domain bandwidth utilization for each round
+   trip.
+
+   On the other hand, it is unclear from where the current provider
+   replication interval of 24 hours originated or even whether it still
+   provides enough freshness in the face of available resources,
+   particularly in today's environment where a typical IRR system
+   consists of a (multi-core) multi-GHz CPU connected to a network via a
+   physical connection of 100 Mbps or, more likely, higher bandwidth.
+   In addition, due to demand for bandwidth, circuit sizes used by ISPs
+   have increased to 10 Gbps, thus eliminating bandwidth as a
+   significant factor in the transfer of data between IRRs.
+   Furthermore, it should be noted that Merit's Internet Routing
+   Registry Daemon (IRRd) [MERIT-IRRD] uses 10 minutes as its default
+   for "irr_mirror_interval".
+
+   Lastly, it should be noted that "Routing Policy System Replication"
+   [RFC2769] attempted to offer a more methodical solution for
+   distributed replication of resources between IRRs.  It is unclear why
+
+
+
+McPherson, et al.             Informational                     [Page 9]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   that RFC failed to gain traction, but it is suspected that this was
+   due to its reliance on "Routing Policy System Security" [RFC2725],
+   which addressed "the need to assure integrity of the data by
+   providing an authentication and authorization model."  Indeed,
+   [RFC2725] attempts to add an otherwise absent security model to the
+   integrity of policy statements made in RPSL.  Without formal
+   protections, it is possible for anyone to author a policy statement
+   about an arbitrary set of resources, and publish it (as discussed
+   above in Section 4.1.
+
+5.2.  Updating Routing Policies from Updated IRR Resources
+
+   Ultimately, the length of time it takes to replicate resources among
+   IRRs is, generally, the dominant factor in reflecting changes to
+   resources in policy that is eventually applied within the control
+   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
+   IRR resources that were updated during any given interval.  However,
+   there are a variety of common techniques, that are outside the scope
+   of this document, that allow for this automated process to be
+   optimized to considerably reduce the length of time it takes to
+   update policies in the ISP's network.
+
+   An ISP will begin the process of updating the policy in its network,
+   first by fetching IRR resources associated with, for example, a
+   customer ASN attached to its network.  Next, the ISP constructs a new
+   policy associated to that customer and then evaluates if that new
+   policy is different from existing policy associated with that same
+   customer.  If there are no changes between the new and existing
+   policy associated with that customer, then the ISP does not make any
+   changes to the policy in their routers specific to that customer.  On
+   the other hand, if the new policy does reflect changes from the
+   existing policy for that customer, then the ISP begins a process of
+   uploading the new policy to the routers attached to that customer.
+
+   The process of constructing a new policy involves use of a set of
+   programs, e.g., IRRtoolset, that performs recursive expansion of an
+   RPSL aut-num resource that comprises an arbitrary combination of
+   other RPSL aut-num, as-set, route, and route-set resources, according
+   to procedures defined by RPSL.  The end result of this process is,
+   traditionally, a vendor-dependent configuration snippet that defines
+   the routing policy for that customer.  This routing policy may
+   consist of the set of IPv4 or IPv6 prefixes, associated prefix
+   lengths, and AS_PATHs that are supposed to be accepted from a
+   customer's eBGP session.  However, if indicated in the appropriate
+   RPSL resource, the policy may also set certain BGP Attributes, such
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 10]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   as MED, AS_PATH prepend value, LOCAL_PREF, etc., at either the
+   incoming eBGP session from the customer or on static routes that are
+   originated by the resource holder.
+
+   An ISP's customers may not adequately plan for pre-planned
+   maintenance, or, more likely, they may need to rapidly begin
+   announcing a new IP prefix as a result of, for example, an emergency
+   turn-up of the ISP customer's new downstream customer.
+   Unfortunately, the routine, automated process employed by the ISP
+   means that it may not begin updating its routing policy on its
+   network for up to 24 hours, because the ISP or the IRRs the ISP uses
+   might only mirror changes to IRR resources once every 24 hours.  The
+   time interval for the routine/automated process is not responsive to
+   the needs of directly paying customer(s) who need rapid changes in
+   their policy in rare situations.  In these situations, when a
+   customer has an urgent need for updates to take effect immediately,
+   they will call the Network Operations Center (NOC) of their ISP and
+   request that the ISP immediately fetch new IRR objects and push those
+   changes out to its network.  This is often accomplished in as little
+   as 5 minutes from the time a customer contacts their ISP's NOC to the
+   time a new filtering policy is pushed out to the Provider Edge (PE)
+   routers that are attached to that customer's Attachment Circuits
+   (ACs).  It is conceivable that some ISPs automate this using out-of-
+   band mechanisms as well, although the authors are unaware of any
+   existing mechanisms that support this.
+
+   Ultimately, the aforementioned latency with respect to "emergency
+   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
+   third-party ISPs to perform filtering on their peering circuits,
+   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
+   mirror changes will have to be dramatically reduced.  There will need
+   to be a corresponding reduction in the time required by ISPs to
+   evaluate whether those changes should be recompiled and reflected in
+   router policies that would then get pushed out to Autonomous System
+   Border Routers (ASBRs) connected to peering circuits on their
+   network.
+
+6.  Historical BGP Protocol Limitations
+
+   As mentioned previously, after a resource holder made changes to
+   their resources in an IRR, those changes would automatically be
+   distributed to other IRRs, ISPs would then learn of those changes,
+   generate new BGP policies, and then apply those to the appropriate
+   subset of routers in their ASes.  However, in the past, one
+   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
+
+
+
+McPherson, et al.             Informational                    [Page 11]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   updated resource from a customer to their ISP and from their
+   immediately upstream ISP to the ISP's peers.  It was necessary (often
+   manually) to actually induce BGP on each router to apply the new
+   policy within the control plane, thus learning of a newly announced/
+   changed IP prefix (or, dropping a deleted IP prefix).  Unfortunately,
+   most of these methods not only were highly impactful operationally,
+   but they also affected traffic forwarding to IP destinations that
+   were unrelated to the most recent changes to the BGP policy.
+
+   Historically, a customer would have to (re-)announce the new IP
+   prefix toward their ISP, but only after the ISP had put the new BGP
+   policies into effect.  Alternatively, the ISP would have to reset the
+   entire eBGP session from Provider Edge to Customer Edge either by: a)
+   bouncing the entire interface toward the customer (e.g., shutdown /
+   no shutdown) or b) clearing the eBGP session toward the customer
+   (e.g., clear ip bgp neighbor <IP address of CE router>, where <IP
+   address of CE router> represents a specific IP address).  The latter
+   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
+   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
+   ASBRs, attached to peers, at the perimeter of the ISP network.
+   Unfortunately, if those peers had either not yet learned of the
+   changes to resources in the IRR or pushed out new BGP policies (and,
+   reset their BGP sessions immediately afterward) incorporating those
+   changes, then the newly announced route would also get dropped at the
+   ingress ASBRs of the peers.
+
+   Ultimately, either of the two scenarios above further lengthens the
+   effective time it would take for changes in IRR resources to take
+   effect within BGP in the network.  Fortunately, BGP has been enhanced
+   over the last several years in order that changes within BGP policy
+   will take effect without requiring a service-impacting reset of BGP
+   sessions.  Specifically, BGP soft-reconfiguration (Section 1 of
+   [RFC2918]) and, later, Route Refresh Capability for BGP-4 [RFC2918]
+   were developed so that ISPs, or their customers, could induce BGP to
+   apply a new policy while leaving both the existing eBGP session
+   active as well as (unaffected) routes active in both the Loc-RIB and,
+   more importantly, FIB of the router.  Thus, using either of these
+   mechanisms, an ISP or its peers currently will deploy a newly
+   generated BGP policy, based on changes to resources within the IRR,
+   and immediately trigger a notification -- which does not impact
+   service -- to the BGP process to have those changes take effect in
+   their control plane, either allowing a new IP prefix to be announced
+   or an old IP prefix to be dropped.  This dramatically reduces the
+
+
+
+McPherson, et al.             Informational                    [Page 12]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   length of time from when changes are propagated throughout the IRRs
+   to when those changes are actually operational within BGP policy in
+   an ISP's network.
+
+7.  Historical Limitations of Routers
+
+7.1.  Incremental Updates to Policy on Routers
+
+   Routers in the mid 1990s rarely supported incrementally updatable
+   prefix filters for BGP; therefore, if new information was received
+   from a policy or internal configuration database that would impact a
+   policy applied to a given eBGP peer, the entire prefix list or access
+   list would need to be deleted and rewritten, compiled, and installed.
+   This was very tedious and commonly led to leaked routes during the
+   time when the policy was being rewritten, compiled, and applied on a
+   router.  Furthermore, application of a new policy would not
+   automatically result in new ingress or egress reachability
+   advertisements from that new policy, because routers at the time
+   would require a reset of the eBGP sessions for routing information to
+   be evaluated by the new policy.  Of course, resetting of an eBGP
+   session had implications on traffic forwarding during the time the
+   eBGP session was reestablished and new routing information was
+   learned.
+
+   Routers now support the ability to perform incremental, and in situ,
+   updates to filter lists consisting of IP prefixes and/or AS_PATHs
+   that are used within an ingress or egress BGP policy.  In addition,
+   routers also can apply those incremental updates to policy, with no
+   traffic disruption, using BGP soft-reconfiguration or BGP Route
+   Refresh, as discussed in the previous section.
+
+7.2.  Storage Requirements for Policy on Routers
+
+   Historically, routers had very limited storage capacity and would
+   have difficulty in storing an extremely large BGP policy on-board.
+   This was typically the result of router hardware vendors using an
+   extremely limited amount of NVRAM for storage of router
+   configurations.
+
+   Another challenge with historical router hardware was that writing to
+   NVRAM was extremely slow.  For example, when the router configuration
+   had changed as a result of updating a BGP policy that needed to
+   accommodate changes in IRR resources, this would result in extremely
+   long times to write out these configuration changes.  Sometimes, due
+   to bugs, this would result in loss of protocol keep-alives.  This
+   would cause an impact to routing or forwarding of packets through the
+   platform.
+
+
+
+
+McPherson, et al.             Informational                    [Page 13]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   The above limitations have largely been resolved with equipment from
+   the last few years that ships with increasing amounts of non-volatile
+   storage such as PCMCIA or USB flash cards, hard disk drives, or
+   solid-state disk drives.
+
+   However, as capacities and technologies have evolved on modern
+   routing hardware, so have 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
+
+   Historically, there has not been a standardized modeling language for
+   network configuration or an associated method to update router
+   configurations.  When an ISP detected a change in resources within
+   the IRR, it would fashion a vendor-dependent BGP policy and upload
+   that to the router usually via the following method.
+
+   First, an updated BGP policy configuration snippet is generated via
+   processes running on an out-of-band server.  Next, the operator uses
+   either telnet or SSH [RFC4253] to log in to the CLI of a target
+   router and issue vendor-dependent CLI commands that will trigger the
+   target router to fetch the new configuration snippet via TFTP, FTP,
+   or Secure Copy (SCP) stored on the out-of-band server.  The target
+   router will then perform syntax checking on that configuration
+   snippet and, if that passes, merge that configuration snippet into
+   the running configuration of the router's control software.  At this
+   point, the new BGP policy configuration snippet is active within the
+   control plane of the router.  One last step remains -- the operator
+   will issue a CLI command to induce the router to perform a "soft
+   reset", via BGP soft-reconfiguration or BGP Route Refresh, of the
+   associated BGP session in order to trigger the router to apply the
+   new policy to routes learned from that BGP session without disrupting
+   traffic forwarding.
+
+   More recently, operators have the ability to use NETCONF [RFC6241] /
+   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
+   that capability.  However, this activity is still dependent on
+   generating, via the out-of-band server, a vendor-dependent XML
+   configuration snippet that would get uploaded via SSH or TLS to the
+   target router.
+
+
+
+McPherson, et al.             Informational                    [Page 14]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   In the future, the ability to upload new Route Origin Authorization
+   (ROA) information may be provided from the RPKI to routers via the
+   RPKI-RTR [RFC6810] protocol.  However, this will not allow operators
+   the ability to upload other configuration information such as BGP
+   policy information (AS_PATHs, BGP communities, etc.) that might be
+   associated with that ROA information, as they can from IRR-generated
+   BGP policies.
+
+8.  Summary
+
+   As discussed above, many of the problems that have traditionally
+   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 them 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.
+
+9.  Security Considerations
+
+   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.  A
+   resource certification framework should be used to address the
+   authorization of IRR statements to make attestations and assertions
+   (as mentioned in Section 4.1, and discussed in Section 5.1).
+
+   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, introduce 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 the varying degrees of coupling and operational buffers
+   that might be installed in their environments.
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 15]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+10.  Informative References
+
+   [IEPG89_NTT]
+              Mauch, J., "NTT BGP Configuration Size and Scope", IEPG
+              meeting before IETF 89, March 2014,
+              <http://iepg.org/2014-03-02-ietf89/
+              ietf89_iepg_jmauch.pdf>.
+
+   [IRR_LIST] Merit Network, Inc., "List of Routing Registries",
+              <http://www.irr.net/docs/list.html>.
+
+   [MERIT-IRRD]
+              Merit, "IRRd - Internet Routing Registry Daemon",
+              <http://www.irrd.net>.
+
+   [RC_HotNetsX]
+              Osterweil, E., Amante, S., Massey, D., and D. McPherson,
+              "The Great IPv4 Land Grab: Resource Certification for the
+              IPv4 Grey Market", DOI 10.1145/2070562.2070574,
+              <http://dl.acm.org/citation.cfm?id=2070574>.
+
+   [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
+              STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
+              <http://www.rfc-editor.org/info/rfc959>.
+
+   [RFC1787]  Rekhter, Y., "Routing in a Multi-provider Internet",
+              RFC 1787, DOI 10.17487/RFC1787, April 1995,
+              <http://www.rfc-editor.org/info/rfc1787>.
+
+   [RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
+              Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
+              "Routing Policy Specification Language (RPSL)", RFC 2622,
+              DOI 10.17487/RFC2622, June 1999,
+              <http://www.rfc-editor.org/info/rfc2622>.
+
+   [RFC2725]  Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
+              Murphy, "Routing Policy System Security", RFC 2725,
+              DOI 10.17487/RFC2725, December 1999,
+              <http://www.rfc-editor.org/info/rfc2725>.
+
+   [RFC2769]  Villamizar, C., Alaettinoglu, C., Govindan, R., and D.
+              Meyer, "Routing Policy System Replication", RFC 2769,
+              DOI 10.17487/RFC2769, February 2000,
+              <http://www.rfc-editor.org/info/rfc2769>.
+
+   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
+              DOI 10.17487/RFC2918, September 2000,
+              <http://www.rfc-editor.org/info/rfc2918>.
+
+
+
+McPherson, et al.             Informational                    [Page 16]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
+              January 2006, <http://www.rfc-editor.org/info/rfc4253>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <http://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
+              February 2012, <http://www.rfc-editor.org/info/rfc6480>.
+
+   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
+              Infrastructure (RPKI) to Router Protocol", RFC 6810,
+              DOI 10.17487/RFC6810, January 2013,
+              <http://www.rfc-editor.org/info/rfc6810>.
+
+   [RIPE638]  RIPE NCC, "Autonomous System (AS) Number Assignment
+              Policies", March 2015,
+              <https://www.ripe.net/publications/docs/ripe-638>.
+
+   [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, December 2012,
+              <http://techreports.verisignlabs.com/
+              tr-lookup.cgi?trid=1120005&rev=2>.
+
+   [TASRS]    Osterweil, E., Amante, S., and D. McPherson, "TASRS:
+              Towards a Secure Routing System Through Internet Number
+              Resource Certification", Verisign Labs Technical
+              Report 1130009, February 2013,
+              <http://techreports.verisignlabs.com/
+              tr-lookup.cgi?trid=1130009&rev=1>.
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 17]
+
+RFC 7682           IRR & Routing Policy Considerations     December 2015
+
+
+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
+
+   Danny McPherson
+   Verisign, Inc.
+
+   Email: dmcpherson@verisign.com
+
+
+   Shane Amante
+   Apple, Inc.
+
+   Email: amante@apple.com
+
+
+   Eric Osterweil
+   Verisign, Inc.
+
+   Email: eosterweil@verisign.com
+
+
+   Larry J. Blunk
+   Merit Network, Inc.
+
+   Email: ljb@merit.edu
+
+
+   Dave Mitchell
+   Singularity Networks
+
+   Email: dave@singularity.cx
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 18]
+