RFC 7682

Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration

📅 published December 2015, from ietf

RFC 7682: Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration 💖

okay bestie, this one is a Category: Informational doc 🎀 (so it's published for info, not as a standard), and it's dated December 2015. The ISSN is 2070-1721. It's written by five people: D. McPherson from Verisign, Inc., S. Amante from Apple, Inc., E. Osterweil also from Verisign, Inc., L. Blunk from Merit Network, Inc., and D. Mitchell from Singularity Networks 🧚. The header doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC ✨.

Abstract 🌸

this doc is a big catalogue 📚 of all the stuff that messed with how well Internet Routing Registries (IRRs) worked for inter-domain routing policy, across the global routing system, over the last two decades. it also talks about which of those problems are still a real issue in practice, and which are old leftovers that don't apply anymore but still scare people off from inter-provider policy-based filtering and keep IRR from being super useful even today 💅.

Status of This Memo 🦋

this is not an Internet Standards Track spec. it's just published for info 💁‍♀️.

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7682 🔗.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. please read these carefully bc they explain your rights and restrictions for this doc 📜. code components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🫶.

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

1. Introduction ✨

okay so the point of this doc is to catalog the issues that affected how well IRRs worked for inter-domain routing policy specification and application in the global routing system over the past two decades 🦋. it also talks about which of those issues still cause problems in practice, and which ones are no longer obstacles but whose perceived drawbacks still stifle inter-provider policy-based filtering support and IRR utility to this day 💀.

2. Background 🍓

IRRs can be used to express a whole bunch of Internet number bindings and policy objectives. that includes bindings between 1) an origin AS and a given prefix, 2) a given AS and its AS and community import and export policies, and 3) a given AS and the AS macros (as-sets in Routing Policy Specification Language (RPSL)) that show the set of ASes it wants 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 gets thrown around, incorrectly, as a giant catch-all 🙈. people use it to describe issues about the accuracy of data in the IRR, RPSL, and the operational deployment of policy (derived from RPSL in the IRR) onto routers. it's super important to sort these issues into distinct categories so readers can tell which ones are historical artifacts that no longer apply, and which ones still exist and might be addressed by the IETF 🧚.

the next sections split the IRR challenges into these 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 doc covers how policy gets pulled out of the IRR and put in, plus how that policy gets activated within routers 👑.

4. Accuracy and Integrity of Data Contained within the IRR 💜

this section looks at issues about the accuracy and integrity of data inside the IRR 🔍.

4.1. Lack of Resource Certification 🔐

Internet number resources include IPv4 addresses, IPv6 addresses, Autonomous System Numbers (ASNs), and more. these resources are usually handed out by hierarchical authorities, but a general way to formally verify (like with cryptographic mechanisms) when parties have been given resources is still an open challenge 😭. we call that kind of system a Resource Certification System, and some candidate examples of how one might be built and deployed already exist: [TASRS], [RC_HotNetsX], and [RFC6480] 🌸.

one of the biggest complaints about the IRR system is that the data in the IRRs is out of date or lacks integrity 📉. this is mostly because existing IRR mechanisms don't let a relying party (cryptographically) verify whether an IRR object is valid. basically, there has never been a resource certification infrastructure that lets a resource holder authorize a particular autonomous system to originate network-layer reachability advertisements for a given IPv4 or IPv6 prefix. it's worth noting this isn't a flaw in the underlying RPSL [RFC2622]. it mostly happened because the operator community never clearly asked Internet Number Resource Registries for enough resource certification infrastructure to let a resource holder build a cryptographic binding between, say, a given AS number and an IP prefix 🫶.

another noteworthy (but slightly different) problem in the IRR system is that there's no solid tie between the resource and the resource holder ⚠️. generally, there's no assurance that objects are valid when they're created. the exception is a subset of things like the RIPE IRR, where RPSS [RFC2725] vouches for RIPE address holders and RIPE ASN holders. if a resource holder's authorization can't be certified, consumers can't verify the attestations made. so without resource certification, consumers are basically only certifying the assertions the creator or maintainer of the resource object has made, not whether those assertions are actually valid 🙃.

the RIPE community dealt with that last issue by adopting a foundation policy [RIPE638]. it requires a contractual link between the RIPE NCC and the end user in direct assignment and ASN assignment cases, which weren't previously covered by Local Internet Registry (LIR) contracts for address allocations. this policy had a few goals:

  1. there was an encumbrance placed in the policy for the LIR to charge the end user for provider-independent (PI) resources. this made 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 actually mean something when it came to who made what claim about what number resource 📝.
  3. it tied into the RIPE NCC's object grandfathering policy, which ties the registration details of the end user to the object registered in the IRR database 🧾.

while this policy specifically dealt with PI/portable space holders, other regions handle this issue too 🌍. also, a tangible tie between the resource and the resource holder really is a prerequisite for resource certification, though it doesn't directly fix the IRR deficiencies 🤷‍♀️.

one of the central takeaways from this policy was that without a chain-of-ownership functionality in IRR databases, talking about certifying their contents is pointless 💀✨.

4.2. Incentives to Maintain Data within the IRR

Okay so bestie, problem number two 😭 Keeping IRR data accurate and up to date (including deleting the stale stuff) can totally lose its motivation when people switch peering policies, like swapping transit providers 🔄. Here's the tea: there is a very strong incentive for an ISP's customers to register new routing info in the IRR, because some ISPs have a strict rule that they will only build or update a customer's prefix-lists for the inbound eBGP sessions based off what they find in the IRRs 💅. But there's basically little incentive to remove out-of-date info, most likely because some ISPs don't use (or enforce using) IRR data to build incoming policy for the customer's eBGP sessions 🙈. For example, if a customer is leaving an ISP that needs IRR data for its incoming policy and, at the same time, signing up with an ISP that doesn't need IRR data, then that customer will likely let the IRR data go stale or inaccurate. Not the vibe 💀

Further, policy filters are almost exclusively generated from the origin AS info in IRR route objects, and providers use them to filter downstream transit customers ✨. Since providers only look for route objects containing their downstream customer's origin AS, stale route objects with historical and possibly incorrect origin AS info just get ignored 🫠. Assuming the downstream customer doesn't keep announcing those routes with historical or incorrect origin AS info in BGP to the upstream provider, there's no significant incentive to remove them, since they don't affect offline policy filter generation or routing on the Internet 🤷‍♀️. On the other hand, the main thing that gets the Service Provider to work with downstream customers is when the resulting filter list gets so large that it's hard to store on PE routers 📦. But that's more of an operational issue with very old, legacy PE routers, not newer PE router hardware with more robust control-plane engines 💪.

4.3. Inability for Third Parties to Remove (Stale) Information from the IRRs

Third challenge 🫣: IRR operators, and the ISPs who use them, can't proactively remove (perceived) out-of-date or "stale" resources from an IRR on behalf of resource holders who aren't diligent about maintaining their own info. Why? According to the RPSL [RFC2622], only the resource holder ('mntner') named in a 'mnt-by' value field of an RPSL resource is authorized to add, modify, or delete their own resources within the IRR 🔒. To fix this, the 'auth-override' mechanism [RFC2725] was developed later, and it would have let a third party update and/or remove "stale" resources from the IRR. It's unclear if this was ever implemented or deployed, but it does provide the language semantics needed to get around this obstacle 🧩.

Still, even with such a mechanism in place, there's a risk that the original RPSL resource holder wouldn't receive notifications (via the 'notify' attribute in various RPSL resources) about the pending or actual removal in time to halt it if those resources were still being used 😬.

In that case, if the removal of a resource wasn't suspended, it could unintentionally cause a denial of service for the RPSL resource holder 🚫. For example, ISPs might automatically generate and deploy 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. Sadly, given a specific resource (e.g., a specific IPv4 or IPv6 prefix), it's usually impossible to figure out a priori which authoritative IRR to query to retrieve an authoritative copy 😩.

This makes it hard for consumers of IRR data to automatically know the authoritative IRR of a resource holder that has the most up-to-date set of resources. This is typically not a problem for an ISP with a direct (customer) relationship with the resource holder, because the ISP will just ask the resource holder which (authoritative) IRR to pull their resources from on, for example, a "Customer BGP Order Form" 📝. But third parties without a direct relationship have a tough time inferring the authoritative IRR, preferred by the resource holder, that likely contains the most up-to-date set of resources 🕵️‍♀️. So 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 🔁.

Right now, this is worked around by individual IRR operators storing a local copy of other IRRs' resources through periodic mirroring 🪞. That lets the individual IRR 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. The catch: an individual IRR operator is under no obligation to mirror all other IRRs, and in practice some IRRs don't mirror resources from all other IRRs 🙃. That could lead to the false impression that a particular resource isn't registered or maintained at a particular IRR 👀. Also, the authentication process for accepting updates at any given IRR may or may not be robust enough to overcome impersonation attacks 🥷. So there's no rigorous assurance that a mirrored RPSL statement was actually made by the authorized resource holder 😤.

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 wasn't part of the protection calculus when it was designed 🤷‍♀️. Still, the use of Transport Layer Security (TLS) [RFC5246] would address protection of query information 🔐.

4.6. Conclusions with Respect to Data in the IRR

All of the issues above about integrity and accuracy of IRR data stem from one big thing: 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 🧪, and this could also aid in certification of resources within the IRR ✅.

Heads up: the RPKI is currently only able to support signing of Route Origin Authorization (ROA) resources, which are the equivalent of 'route' resources in the IRR ⚠️.

Some folks feel the RPKI isn't 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 ✨

Okay so, several IRRs [IRR_LIST] use a Near-Real-Time Mirroring (NRTM) protocol to copy each other's contents 🪞. But ngl, this protocol has some real weaknesses 😭. There's no way to validate that the copy of the mirrored source is correct, and synchronization issues have happened a lot. The NRTM protocol also doesn't employ any security mechanisms 💀. It relies on a pull mechanism and is generally configured with a poll interval of 5 to 10 minutes. And there's currently no way to notify an IRR when an update has happened in a mirrored IRR, so it can't make an immediate update 🙈.

Some providers mirror an IRR by downloading a flat text file copy of it that's made available via FTP [RFC959]. These FTP files get exported by the IRRs at regular intervals of typically anywhere between 2 and 24 hours 🕰️. When a provider fetches those text files, it processes them to identify any updates and reflects the changes within its own internally maintained database. The internally maintained database is out of scope for this document, but it's generally used to make straightforward access to or modification of data easier for the IRR operator 🧚. Providers typically employ a 24-hour cycle to pull updated resources from IRRs. So depending on when resource holders submitted their changes to an IRR, it may take up to 24 hours for those changes to show up in their policy configurations ⏳. In practice, it appears that the RPKI will also employ a 24-hour cycle, where 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." 🌐 Anyway, the practical effect of an organization keeping its own local cache of IRR resources is more resource resiliency (because multiple copies of the same resource are geographically distributed 🗺️), a reduction in query time for resources, and, likely, a reduction in inter-domain bandwidth consumption and its 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 gets 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's unclear where the current provider replication interval of 24 hours came from, or even whether it still provides enough freshness in the face of available resources 🤔. This is especially true in today's environment, where a typical IRR system is a (multi-core) multi-GHz CPU connected to a network via a physical connection of 100 Mbps or, more likely, higher bandwidth 🖥️. Plus, because of demand for bandwidth, ISP circuit sizes have increased to 10 Gbps, which means bandwidth is no longer a significant factor in the transfer of data between IRRs 🚀. Also, 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, "Routing Policy System Replication" [RFC2769] attempted to offer a more methodical solution for distributed replication of resources between IRRs 📚. It's unclear why that RFC failed to gain traction, but it's 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's 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 the policy that's eventually applied within the control plane of routers 🎯. How long it takes to update network elements varies a lot depending on the size of the ISP and the number of IRR resources that were updated during any given interval 📏. There are, however, a variety of common techniques (outside the scope of this document) that allow this automated process to be optimized so it takes way less time to update policies in the ISP's network 🏎️.

An ISP starts the process of updating the policy in its network by first fetching IRR resources associated with, for example, a customer ASN attached to its network 📥. Next, the ISP constructs a new policy associated with that customer and then evaluates whether that new policy is different from the existing policy associated with that same customer 🔍. If there are no changes between the new and existing policy for that customer, then the ISP doesn't make any changes to the policy in its routers specific to that customer 😌. On the other hand, if the new policy reflects changes from the existing policy for that customer, then the ISP begins uploading the new policy to the routers attached to that customer 📤.

Constructing a new policy involves 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 as MED, AS_PATH prepend value, LOCAL_PREF, etc., either at 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 because 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 isn't 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'll 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 attached to that customer's Attachment Circuits (ACs) ⚡. It's 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 are being used by third-party ISPs to perform filtering on their peering circuits 😬. Typically, no such policies are employed today for this very reason 🙅‍♀️. It's likely that the length of time it takes IRRs to mirror changes will have to be dramatically reduced. There will also need to be a corresponding reduction in the time ISPs require 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 ✨

Okay so, like I mentioned before 💅, once a resource holder changed their resources in an IRR, those changes would automatically get distributed to other IRRs. ISPs would then learn about them, generate new BGP policies, and apply those to the right subset of routers in their ASes. BUT, in the past there was one more step needed before any of those new BGP policies could actually take effect in the control plane 😭. Something had to make BGP on each router apply the new policy (often by hand), which meant learning about a newly announced or changed IP prefix, or dropping a deleted one. Honestly? Most of these methods were super impactful operationally, and they also messed with traffic forwarding to IP destinations that had nothing to do with the latest BGP policy change. Not it. 🙈

Historically, a customer had to (re-)announce the new IP prefix toward their ISP, but only after the ISP had put the new BGP policies into effect. The other option was for the ISP 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 were, of course, the most highly impactful, so they could generally only be done off-hours during a maintenance window 💀.

Once the new IP prefix had 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, which are attached to peers at the perimeter of the ISP network. Here's where it gets messy 🥲. If those peers hadn't yet learned about the changes to resources in the IRR, or had pushed out new BGP policies (and reset their BGP sessions right afterward) incorporating those changes, then the newly announced route would also get dropped at the ingress ASBRs of the peers.

So, ultimately, either of the two scenarios above further lengthens the effective time it takes for changes in IRR resources to take effect within BGP in the network. BUT the good news is that BGP has been upgraded over the last several years so that changes within BGP policy take effect without 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 make BGP apply a new policy while leaving both the existing eBGP session active and the (unaffected) routes active in both the Loc-RIB and, even more importantly, the FIB of the router. 🦋 So now, using either of these mechanisms, an ISP or its peers can deploy a newly generated BGP policy, based on changes to resources within the IRR, and immediately trigger a notification to the BGP process that does not impact service. That makes the changes take effect in their control plane, either allowing a new IP prefix to be announced or an old one to be dropped. This dramatically reduces the time from when changes are propagated throughout the IRRs to when they're actually operational within BGP policy in an ISP's network. Iconic, honestly 👑.

7. Historical Limitations of Routers 🧚

7.1. Incremental Updates to Policy on Routers

Okay, routers in the mid 1990s rarely supported incrementally updatable prefix filters for BGP 😩. So if new information came in 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 had to be deleted, rewritten, compiled, and installed all over again. Super tedious, and it commonly led to leaked routes while the policy was being rewritten, compiled, and applied on a router 🙃. It also meant a new policy would not automatically result in new ingress or egress reachability advertisements, because routers at the time needed an eBGP session reset before routing information could be evaluated by the new policy. And of course, resetting an eBGP session had implications for traffic forwarding while the session was re-established and new routing information was learned. Yikes 💀.

Routers now support incremental, in situ updates to filter lists made up of IP prefixes and/or AS_PATHs that are used within an ingress or egress BGP policy 🌈. Routers can also apply those incremental policy updates with no traffic disruption, using BGP soft-reconfiguration or BGP Route Refresh, as discussed in the previous section. Main character energy for real ⭐.

7.2. Storage Requirements for Policy on Routers

Historically, routers had very limited storage capacity, so they had trouble storing an extremely large BGP policy on-board 📦. This was typically because router hardware vendors used an extremely limited amount of NVRAM to store router configurations.

Another challenge with old router hardware was that writing to NVRAM was extremely slow 🐢. So when the router configuration changed as a result of updating a BGP policy to accommodate changes in IRR resources, writing those configuration changes out could take extremely long. Sometimes, due to bugs, this even caused loss of protocol keep-alives, which then impacted routing or forwarding of packets through the platform 😭.

The above limitations have largely been resolved with equipment from the last few years, which 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, some of the scaling requirements of the data have evolved too. In some large networks, configuration growth has begun to "pose challenges" [IEPG89_NTT]. Hardware enhancements have overcome some historical limitations, but 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. So 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 was no standardized modeling language for network configuration, and no associated method for updating router configurations 🤷‍♀️. When an ISP detected a change in resources within the IRR, it would craft a vendor-dependent BGP policy and upload it to the router, usually via the following method.

First, an updated BGP policy configuration snippet was generated by processes running on an out-of-band server. Next, the operator used either telnet or SSH [RFC4253] to log in to the CLI of a target router and issue vendor-dependent CLI commands. Those commands triggered the target router to fetch the new configuration snippet via TFTP, FTP, or Secure Copy (SCP) from the out-of-band server. The target router then performed syntax checking on that configuration snippet and, if that passed, merged it into the running configuration of the router's control software. At this point, the new BGP policy configuration snippet was active within the control plane of the router. One last step remained: the operator issued 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. That triggered the router to apply the new policy to routes learned from that BGP session without disrupting traffic forwarding. Whew, that's a lot of steps 😅.

More recently, operators have been able to use NETCONF [RFC6241] / SSH (or, TLS) from an out-of-band server to push a BGP configuration snippet toward a target router that has that capability 💜. However, this is still dependent on generating, via the out-of-band server, a vendor-dependent XML configuration snippet that gets uploaded via SSH or TLS to the target router.

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 let operators upload other configuration information, such as BGP policy information (AS_PATHs, BGP communities, etc.) that might be associated with that ROA information, the way they can with IRR-generated BGP policies 🙈.

8. Summary 🌸

As discussed above, many of the problems that traditionally stifled IRR deployment have themselves become historical 🎉. But 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 let relying parties learn that 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 increase in state, 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, a fundamental limitation still exists. Literally the one thing holding everything back, bestie 🥹.

9. Security Considerations 🚨

Okay, this one is SERIOUS, so please read it carefully 🫶. 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 processing IRR contents becomes burdensome, or if 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 by other such systems employed to inform routing policy, are a big deal. How tightly or loosely those systems are coupled to the global routing system and operational networks introduces additional vectors that operators and system architects should consider when evaluating attack surface and service dependencies associated with those elements 😱. These attributes and concerns are certainly not unique to IRRs. Operators should evaluate the implications of external systems, and the varying degrees of coupling and operational buffers that might be installed in their environments. Stay safe out there, babe 💖🔐.

10. Informative References ✨

okay bestie, here are the receipts 📚 every doc this RFC leans on, with all the details so you can go find them yourself 🧚

Acknowledgements 🫶

the authors wanna give a huge shoutout 📣 to Chris Morrow, Jeff Haas, Wes George, and John Curran for their help and constructive feedback 💖 literally the best squad 👑

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
📦 where this page comes from