<div><div dir="auto">Dear all,</div><div dir="auto"><br></div><div dir="auto">I support Reudiger’s proposed approach. Thank Reudiger for taking the time to write this up. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Job</div><div dir="auto"><br></div><div dir="auto"><br></div><br><div class="gmail_quote"><div>On Fri, 27 Apr 2018 at 16:10, Ruediger Volk <<a href="mailto:rv@nic.dtag.de">rv@nic.dtag.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After having commented on John's presentation @Atlanta NANOG<br>
and quietly watching the ARIN meeting last week over delayed webcast<br>
I finally got around to contribute this evaluation and suggestion.<br>
I'm happy to discuss further, and left out quite a lot of additional<br>
details. (Though let me apologize in advance for the very limited number<br>
of messages that I actually can process per day.)<br>
<br>
<br>
Mark Kosters wrote Date: Thu Mar 15 09:56:09 EDT 2018<br>
(<a href="http://lists.arin.net/pipermail/arin-consult/2018-March/000958.html" rel="noreferrer" target="_blank">http://lists.arin.net/pipermail/arin-consult/2018-March/000958.html</a>)<br>
in reporting about discussion @Atlanta NANOG<br>
<br>
  > * RPKI was mentioned as a superior system for routing security but many felt that an<br>
  > improvement to the IRR would be a good intermediate step.<br>
  ><br>
  > * Allowing for better tools that leveraged the existing routing system to help <br>
  > users create correct objects in both RPKI and IRR.<br>
<br>
In a February thread between John Curran and Jay Borkenhagen there also was<br>
mentioning of ongoing - but unannounced and so far undocumented - enhancements<br>
to ARIN's RPKI. I would suggest to read Jay's request<br>
"Please announce ARIN's rpki enhancement plans prior to beginning development"<br>
with a wider horizon to actually cover both RPKI enhancements and<br>
IRR changes/new design - I believe that a common plan is reasonable -<br>
if not a requirement - for efficient developement and deployment of<br>
a solution that covers a set of well understood goals to help<br>
improve routing security; piecemeal independantly tinkering<br>
with a number of features in the area is likely to deliver<br>
suboptimal or broken results.<br>
<br>
The first bullet quoted from Mark seems to agree with the view that<br>
broad use of RPKI is the more desirable - and longer time frame - goal<br>
and use of IRR is viewed and intended to be transitional.<br>
I agree with that and believe that carefully looking into the details<br>
(including the specifics of ARIN) that efforts to add authorization<br>
by resource holders into RPSL based IRR are a misguided waste and distraction<br>
(as it likely would extend the IRR transitional use for another decade or more).<br>
<br>
Efforts to improve ARIN's RPKI e.g. for more friendly and helpful user interface<br>
(such as RIPE NCC's service provides to resource holders), reliability,<br>
accessability of validated evaluation of RPKI information make sense and can<br>
make the use of the system more attractive - leading to expanded coverage.<br>
<br>
ARIN's RPKI already has implemented the link from it's authoritative whois <br>
resource registry to enable resource holders to securely document with ROAs<br>
authorized representation of their address space by routes in the public<br>
Internet.  Software to present this information in terms of IRR objects<br>
(route:, route6:, route-set:) is available for free.<br>
With minimum effort and within a few days ARIN thus could make<br>
this information from the existing RPKI system accessible<br>
as a new IRR collection (with a new "source:" distinguisher<br>
to indicate the specific quality).<br>
(As an operator I understand that a committing to a production service<br>
requires more effort and time than this description of a demo service.)<br>
Let's call the approach of making validated ROA information accessible<br>
as RPSL objects in a distinct IRR source ROA2IRR.<br>
<br>
Taking the ROA2IRR approach the second bullet quoted from Mark<br>
becomes somewhat moot, as RPKI and IRR would be automatically<br>
synchronized and consistent (with a bit of time skew similar<br>
to other distributed databases we are used to in networking).<br>
I doubt that there are cases justify extra efforts to freshly create <br>
systems to support inconsistent authorized RPKI ./. IRR style data.<br>
(Support tools to help reconcile inconsistencies in any kind of legacy<br>
data with modern authoritative data makes sense - fixing/removing legacy -<br>
but is entirely different thing).<br>
It also would seem crazy if ARIN were to create in parallel route authorisation <br>
data sets that have different accessability (access&use) rules RPKI ./. IRR.<br>
<br>
Going along ROA2IRR enables operators that are using IRR/RPSL to generate<br>
routing policy configuration (and specifically prefix filters)<br>
with legacy RPSL tooling to make use of high quality information from RPKI<br>
and provides an intermediate step that actually moves forward.<br>
Designing and implementing a new authorization enhanced IRR in contrast<br>
is stepping to the side (or even back) while requiring time, effort,<br>
learning, adaption and later migration efforts, creates over all<br>
higher complexity, [potential for] inconsistency, ...<br>
confusing potential users which system actually to use for what,<br>
diluting the education/learning of tools+environments, ...<br>
<br>
So I think ARIN is best advised to endorse a ROA2IRR approach and focus<br>
on identifying and addressing obstacles to higher take up of members<br>
getting RPKI certificates and creating ROAs.<br>
<br>
Before starting implementation of a revamped ARIN IRR the draft design really<br>
should be evaluated against an ROA2IRR approach.<br>
<br>
We are willing to contribute software for ROA2IRR and explanation of the<br>
small tricks that we figured out to optimize integration in existing<br>
environments.<br>
<br>
<br>
Regards,<br>
  Ruediger<br>
<br>
<br>
Ruediger Volk<br>
_______________________________________________<br>
ARIN-Consult<br>
You are receiving this message because you are subscribed to the ARIN Consult Mailing<br>
List (<a href="mailto:ARIN-consult@arin.net" target="_blank">ARIN-consult@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-consult" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/listinfo/arin-consult</a> Please contact the ARIN Member Services<br>
Help Desk at <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>