[ARIN-consult] Consultation an ARIN IRR Roadmap

[Ruediger Volk]

After having commented on John's presentation @Atlanta NANOG
and quietly watching the ARIN meeting last week over delayed webcast
I finally got around to contribute this evaluation and suggestion.
I'm happy to discuss further, and left out quite a lot of additional
details. (Though let me apologize in advance for the very limited number
of messages that I actually can process per day.)


Mark Kosters wrote Date: Thu Mar 15 09:56:09 EDT 2018
(http://lists.arin.net/pipermail/arin-consult/2018-March/000958.html)
in reporting about discussion @Atlanta NANOG

  > * RPKI was mentioned as a superior system for routing security but many felt that an
  > improvement to the IRR would be a good intermediate step.
  >
  > * Allowing for better tools that leveraged the existing routing system to help 
  > users create correct objects in both RPKI and IRR.

In a February thread between John Curran and Jay Borkenhagen there also was
mentioning of ongoing - but unannounced and so far undocumented - enhancements
to ARIN's RPKI. I would suggest to read Jay's request
"Please announce ARIN's rpki enhancement plans prior to beginning development"
with a wider horizon to actually cover both RPKI enhancements and
IRR changes/new design - I believe that a common plan is reasonable -
if not a requirement - for efficient developement and deployment of
a solution that covers a set of well understood goals to help
improve routing security; piecemeal independantly tinkering
with a number of features in the area is likely to deliver
suboptimal or broken results.

The first bullet quoted from Mark seems to agree with the view that
broad use of RPKI is the more desirable - and longer time frame - goal
and use of IRR is viewed and intended to be transitional.
I agree with that and believe that carefully looking into the details
(including the specifics of ARIN) that efforts to add authorization
by resource holders into RPSL based IRR are a misguided waste and distraction
(as it likely would extend the IRR transitional use for another decade or more).

Efforts to improve ARIN's RPKI e.g. for more friendly and helpful user interface
(such as RIPE NCC's service provides to resource holders), reliability,
accessability of validated evaluation of RPKI information make sense and can
make the use of the system more attractive - leading to expanded coverage.

ARIN's RPKI already has implemented the link from it's authoritative whois 
resource registry to enable resource holders to securely document with ROAs
authorized representation of their address space by routes in the public
Internet.  Software to present this information in terms of IRR objects
(route:, route6:, route-set:) is available for free.
With minimum effort and within a few days ARIN thus could make
this information from the existing RPKI system accessible
as a new IRR collection (with a new "source:" distinguisher
to indicate the specific quality).
(As an operator I understand that a committing to a production service
requires more effort and time than this description of a demo service.)
Let's call the approach of making validated ROA information accessible
as RPSL objects in a distinct IRR source ROA2IRR.

Taking the ROA2IRR approach the second bullet quoted from Mark
becomes somewhat moot, as RPKI and IRR would be automatically
synchronized and consistent (with a bit of time skew similar
to other distributed databases we are used to in networking).
I doubt that there are cases justify extra efforts to freshly create 
systems to support inconsistent authorized RPKI ./. IRR style data.
(Support tools to help reconcile inconsistencies in any kind of legacy
data with modern authoritative data makes sense - fixing/removing legacy -
but is entirely different thing).
It also would seem crazy if ARIN were to create in parallel route authorisation 
data sets that have different accessability (access&use) rules RPKI ./. IRR.

Going along ROA2IRR enables operators that are using IRR/RPSL to generate
routing policy configuration (and specifically prefix filters)
with legacy RPSL tooling to make use of high quality information from RPKI
and provides an intermediate step that actually moves forward.
Designing and implementing a new authorization enhanced IRR in contrast
is stepping to the side (or even back) while requiring time, effort,
learning, adaption and later migration efforts, creates over all
higher complexity, [potential for] inconsistency, ...
confusing potential users which system actually to use for what,
diluting the education/learning of tools+environments, ...

So I think ARIN is best advised to endorse a ROA2IRR approach and focus
on identifying and addressing obstacles to higher take up of members
getting RPKI certificates and creating ROAs.

Before starting implementation of a revamped ARIN IRR the draft design really
should be evaluated against an ROA2IRR approach.

We are willing to contribute software for ROA2IRR and explanation of the
small tricks that we figured out to optimize integration in existing
environments.


Regards,
  Ruediger


Ruediger Volk