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

Hi Job, Petrit, All,
(please see inline)


On Fri, 21 Feb 2020, Job Snijders 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.

Which issues exactly do you have in mind?



> Our community could use that money for far more rewarding work.

Such as...?



> 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.

Yes, it's possible, but not as practical as having it embedded in RPKI 
-- some may think.



> 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.

It improves RPKI usage, imho, though.



> 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.

I do see a significant benefit in marking invalids as "INVALID" instead 
of "UNKNOWN".



> 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.

...and over peerings/IXs.



> The numer is so low, the prefixes involved don't really seem to
> pop up on threat radars.

Prefixes (especially those which were not legitimately allocated) can come 
and go, once they have served their purpose........


> I asked the same question in APNIC's policy development community and no 
> answer was provided.

Maybe not the best audience to ask about what's on threat radars?


> 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.

That would mitigate the "will have to duplicate the entire current RPKI 
infrastructure..." phrase on the impact analysis, right? :-)


I do support 2019-08 as it is, but i can easily support a version 3 with 
the above suggestion.


Cheers,
Carlos


> Kind regards,
>
> Job
>