ARIN Staff Report on IRR Consultation [Archived]

22 May 2018

Executive Summary

Over the last several years, ARIN has received multiple ARIN Consultation and Suggestion Process (ACSP) requests and fielded many customer complaints about our existing Internet Routing Registry (IRR). Last year, a community consultation was issued to gauge community interest for ARIN to take on the project of improving this service. The consensus response was that the community would like ARIN to:

• Improve the validity of the IRR data
• Work with the other RIR’s on authorization schemes
• Provide appropriate proxy registration services
• Integrate/validate with the registration database

To accomplish these goals, we anticipate that this work effort will involve a fair bit of community involvement (RIR communities, IETF, and operational groups such as NANOG) in order to create the appropriate incremental upgrades to the IRR.

Details

In response to multiple ACSPs regarding IRR route validation, ARIN opened two public consultations, the first to gauge interest in the project from the community and the second to provide a feedback opportunity on ARIN’s proposed plan.

The first consultation, held in March and April of 2017, found the community to be broadly supportive of a re-implementation of the IRR by ARIN staff, encouraged a tighter coupling or authorization of objects in the IRR to resources in the ARIN registry, and acknowledged a need for ARIN staff to engage with the community and the other RIRs during the re-implementation of the IRR.

The second consultation, held between February and May of 2018, brought additional feedback in two areas: the migration of data from ARIN’s legacy IRR and the quality of the data that would result from such a migration, and the juxtaposition of new “validated” IRR with the RPKI.

With regard to migration of data, the community was broadly supportive of a migration path for data in the legacy IRR to the new IRR. However, many in the community believe a blind migration would result in bad data crossing over from the legacy system to the new one, and have asked ARIN staff to investigate various methods to help mitigate against bad data.

Several participants in the second consultation noted that the RPKI is considered the long-term solution for routing security and a new IRR is just a transitional step. While acknowledging this, it was noted in the consultation that tooling available for IRR route filtering is more broadly used and asked ARIN staff to investigate ways to allow RPKI data to be expressed as equivalent IRR objects.

Implementation Experience Regarding ARIN’s Current IRR

ARIN initially set up an RIPE-based IRR years ago. Over the years, we upgraded it based on ACSP suggestions: IPv6 support was implemented in December 2009, and PGP support with additional notifications was released in September 2011. In both of these releases, we replicated the original approach of using the RIPE database software system with loose coupling to our mainline ARIN Online registry system. These upgrades did allow for additional functionality, but it came at a very substantial cost of time and unanticipated functionality issues related to the upgrades.

When we undertook these upgrades, we chose to continue the separation in the hopes of doing minimal environmental changes to ARIN’s infrastructure to add the suggested improvements. However, the RIPE codebase was not modularized, with significant dependencies on RIPE environment, and consequently was not ideal for use in ARIN’s environment. One consequence was the repeated need to pull down the latest release from RIPE, adjust the environment for their software to work, make changes to it to allow functionality that we support, remove out dependencies to resource checks that would not exist in our system, and add dependency links to our system. This has been a very labor-intensive process and it took a lot of engineering time to make the system work.

Adjusting to each upgrade from RIPE has also been challenging because of innate differences between our database structures. RIPE had two systems – one being a front-end database and the other being a back-end database with manual synchronization between these two systems. At ARIN, we have just one system that is placed behind the firewall and replicated out to the publically available ARIN slaves as changes are made. The RIPE IRR codebase provided for limited information to be shared to slaves via its replication schemes. Given that ARIN’s publically available interface is a slave, the output available to our community was not the same as our internal master, and has resulted in some confusion for ARIN IRR users.

ARIN Registration Services Department also has challenges providing customer support to IRR users. Common problems include:

• Maintainers not being notified upon changes
• Cryptic responses to pgp-validation errors
• General lack of customer support features

It was our hope that code re-use would save time and money. Unfortunately, this was not the case, and the result was an awkward, difficult-to-operate, and user-unfriendly system that requires considerable engineering time to maintain.

It should also be noted that the IRR codebase in use by ARIN is no longer supported or maintained by the RIPE NCC, as they have since completely rewritten their IRR software.

ARIN’s Proposed Way Forward

Given the past experience with reusing code for IRR software, ARIN staff proposes a “ground-up” implementation of a validated IRR that will better integrate with ARIN’s current web portal, provisioning system, and other registry functions. This path forward with be a multi-phased approach and will rely on community–defined specifications and global RIR community consensus.

This approach will allow ARIN to field a routing registry incrementally, providing utility to the community much sooner than a monolithic “big-bang” release, and it will provide the community an opportunity to give feedback with respect to features and cost as the project progresses.

1. Produce a Simplified Profile of RPSL: Most of the complexity of RPSL comes from routing registry features rarely used by the community. To reduce the implementation costs around data modeling and parsing of complex RPSL structures, ARIN will work with the operational community to identify the most commonly used features of the language, and this subset will be documented as an simplified RPSL profile to be used to guide development efforts. ARIN will approach this in an iterative fashion, producing an initial simplified RPSL profile and adding to it as the community requests.
2. Schedule Frequent Deployments: ARIN will adopt “continuous deployment” strategies to allow for more frequent deployments, similar to the strategy used today in development of the ARIN Online registry system. This will allow the community to use new features of the IRR as they are developed.
3. Collaborate on Cross-RIR Authentication: Should the need arise, ARIN will work with the other RIRs engineering coordination activities to create an appropriate mechanism for authentication and authorization of routing registry objects for which the resources cross regional boundaries.
4. Provide an Easy IRR integration tool within ARIN Online: ARIN will provide a simple tool within ARIN online for those users who wish to explore the routing of their existing number resources and after successful review, automatically update their corresponding IRR records to match existing routing.
5. Undertake Quality of Data Initiatives. ARIN will provide mechanisms within the IRR to help with maintenance of data. Such mechanisms may include:
6. Reflected RPKI Objects. Users will be given an opportunity to mirror their RPKI data as objects in the IRR.
7. Routing Point of Contact. Resource holders will have the opportunity to delegate maintenance of IRR records to a new object called a Routing POC. This POC will be restricted to only add/modify/delete routing related data.
8. Object Expiration. Objects in the IRR will be given expiration dates, and notices will be sent to users of pending expirations. Expired objects will not be visible to the public, though they will be placed in a “pending” state to ease re-instatement.
9. Migration of Data. Objects that can be migrated from the current IRR will be migrated to the new IRR and placed in the “pending” state (see above) allowing users an opportunity to review objects before they are made publicly available. Users will be notified of objects in the current IRR that cannot be migrated based on not matching the organization within ARIN’s registry, overlapping network ranges with ARIN’s registry , etc.
10. Tight coupling to ARIN’s registry: Objects placed in the IRR must be authorized by the organization who maintains the object in ARIN’s registry.
11. Cooperate on Standards and Best Practices: Where applicable and appropriate, ARIN will work with the IETF and the other RIRs on documenting any resulting operational standards, profiles, and best practices.

We do feel that this effort, once deployed, will help improve routing coordination that exists on the Internet today. The proposed new ARIN IRR will provide a clear and consistent path to allow ISPs to share their routing policies.