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