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
