[routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

For your information, we are producing a SLURM file as part of our
implementation. This is noted in the slides.

Purely as an informational and with no intent to otherwise engage in
your policy proposal process, It has been my intention to bring our
implementation report to the RIPE meeting in Berlin and present it in
the routing WG.

Please let me know if this would be useful or interesting, or is not helpful.

-George

On Fri, Feb 21, 2020 at 2:54 PM Job Snijders <job at ntt.net> wrote:
>
> Dear working group,
>
> On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote:
> > The goal of the proposal is to ask the RIPE NCC to create ROAs with
> > origin AS0 for all unallocated and unassigned address space under its
> > control.
> >
> > The proposal has been updated following the last round of discussion.
> > Version 2 of the proposal includes a specification for the RIPE NCC to
> > create all AS0 ROAs under a specific Trust Anchor.
> >
> > The RIPE NCC has prepared an impact analysis on this latest proposal
> > version to support the community’s discussion.
> >
> > You can find the proposal and impact analysis at:
> > https://www.ripe.net/participate/policies/proposals/2019-08
> > https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
>
> I oppose the policy proposal. I think this is a Bad Idea [tm].
>
> The cost/benefit analysis seems to show that substantial cost is
> involved to achieve what appears to be a very minor benefit at best, and
> a great potential for issues down the road. Our community could use that
> money for far more rewarding work.
>
> It should also be noted that anyone wishing to reject unallocated and
> unassigned address space can easily do so by converting the data
> available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP
> prefix-filters. There are many ways to suppress the propagation of
> routing information related to not-yet-assigned space, using the RPKI
> seems far too big of a hammer.
>
> The moment address space is assigned by the RIPE NCC to an end user or
> LIR, that entity will be able to create RPKI ROAs (if they wish to do
> so) to glean the very same benefits that AS 0 ROAs for unassigned space
> would provide up front. But that that point in time it'll be the end
> users choice to do so. Shifting that moment forward in time doesn't
> seem to have tangible benefits to me.
>
> Nobody has been able to show me that what operational issues arise from
> the presence of a handful of unassigned prefixes in the BGP Default-Free
> Zone. The numer is so low, the prefixes involved don't really seem to
> pop up on threat radars. I asked the same question in APNIC's policy
> development community and no answer was provided.
>
> Perhaps a different direction can be taken? One of the authors of
> 2019-08 experimented with generating a SLURM file based on the list of
> unassigned / unallocated address space, which can easily be incorporated
> into Origin Validation pipelines. I'm in support of modifying the
> proposal to not instantiate a new TAL, but rather have the RIPE NCC
> publish a SLURM [RFC 8416] file. This approach would yield the exact
> same results at a much lower cost.
>
> Kind regards,
>
> Job
>