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

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