[ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap

[Job Snijders]

Dear ARIN,

Where do I sign up to help?

Kind regards,

Job

On Tue, Jan 09, 2018 at 04:27:58PM -0500, ARIN wrote:
> Over the last several years, ARIN has received multiple ARIN Consultation
> and Suggestion Process (ACSP) requests and fielded many customer suggestions
> about our existing Internet Routing Registry (IRR), and as a result, 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
> forums such as NANOG and CaribNOG) in order to create the appropriate
> incremental upgrades to the IRR.
> 
> We are opening a new Community Consultation to solicit feedback on the ARIN
> IRR Roadmap, detailed below.
> 
> Please provide comments to arin-consult at arin.net.
> 
> This consultation will remain open through 5:00 PM EST on Friday, 9 February
> 2018.
> 
> Regards,
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers (ARIN)
> 
> *ARIN IRR Roadmap**
> **
> **Background*
> 
> In response to multiple ACSPs regarding IRR route validation (i.e. the
> function whereby route objects are validated via the authorization of the
> appropriate number resource holder), ARIN conducted an IRR community
> consultation in April 2015. This consultation was opened because the issues
> around IRR route validation are complex, and implementation was anticipated
> to exceed the cost of most ACSP implementations.
> Within the consultation, the ARIN community was asked three questions:
> 
>     * Should ARIN begin a new project to enable IRR route object validation
> to the ARIN registry database?
>     * If yes, should this effort be coordinated with other RIRs to help
> facilitate cross-registry authentication?
>     * If yes, should this effort also support third party IRR route object
> authentication?
> 
> There were eighteen individual participants in the consultation. Thirteen
> were in favor of ARIN creating a more robust IRR, two were publicly against,
> and three were unclear in their support or opposition.
> 
> Nine participants expressed support for efforts to facilitate inter-RIR
> authentication, and eight participants expressed support for 3rd party or
> proxy registrations for authentication of route objects.
> 
> Two participants suggested ARIN provide facilities for
> authentication/authorization or delegation to IRRs not operated by an RIR.
> Several participants had concerns regarding the implementation of an
> ARIN-validated IRR. Three noted ARIN's past experience with the
> implementation and cost of RPKI with respect to both community adoption and
> opportunity-cost, and one participant expressed concerns for contractual
> obligations that ARIN may place on resource holders provisioning information
> in a validated IRR.
> 
> *Implementation Experience Regarding ARIN's Current IRR*
> 
> ARIN initially setup a 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 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.
> 
> *Proposed Roadmap*
> 
> Given the community feedback received in the consultation, and with due
> regard to 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 will 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 provide
> feedback with respect to features and cost as the project progresses.
> 
>     * 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.
>     * 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.
> 
>     * Collaborate on Cross-RIR Authentication: 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.
> 
>     * Provide an Easy IRR integration tool within ARIN Online: ARIN will
> provide an 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.
> 
>     * Migrate Data to the New IRR: Where possible, ARIN will create tools
> and practices to help migrate data from the existing IRR to the new IRR
> under the authority of resource holders in the ARIN registry.
> 
>     * 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.