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
