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

[ARIN]

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. You can subscribe to 
this mailing list at:
http://lists.arin.net/mailman/listinfo/arin-consult.

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-announce/attachments/20180109/dffe1d16/attachment.html>