[ARIN-consult] Consultation an ARIN IRR Roadmap

[Job Snijders]

Dear all,

I support Reudiger’s proposed approach. Thank Reudiger for taking the time
to write this up.

I think this direction would provide a good bridge between old and new
tools, provide tangible value to the community in terms of offering an
authoritative routing data source - and it closes the loophole and risk
that the current ARIN IRR represent to our businesses.

I believe LACNIC is on a similar trajectory (to expose RPKI data via IRR
interfaces), so the ROA2IRR approach is not drawn from thin air.

Kind regards,

Job



On Fri, 27 Apr 2018 at 16:10, Ruediger Volk <rv at nic.dtag.de> wrote:

> 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
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the
> ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180427/e31130af/attachment.html>