Search RPD Archives
[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.
nishal at controlfreak.co.za
Sun Jun 13 17:47:15 UTC 2021
On 12 Jun 2021, at 14:15, Job Snijders wrote:
> On Sat, Jun 12, 2021 at 01:18:39PM +0200, Nishal Goburdhan wrote:
>> which roughly equates to: what’s bad about having unallocated
>> space be
>> marked as AS0?
> It introduces new failure modes that previously did not exist. It
> introduces failure modes that do not *need* to exist.
> A relevant example from a few months ago, at another RIR:
> "On Wednesday, 16 December 2020 from 18:00-19:00 (UTC+1), some
> resources lost their contractual status in our internal systems.
> result of this was that the RPKI ROAs for these resources were
thanks for pointing to a specific problem!
> It is of course suboptimal to lose your ROAs for a period of time,
> because during that period of time you are not enjoying the protection
> of BGP Origin Validation.
> But... It is an entirely different matter if in such a situation not
> only your ROAs disappear, but your resources are added to the AS 0 TAL
> automatically, and the internet starts rejecting your BGP routes.
> Deregistration (for ANY reason) - leads to IP blackholing!
yes, a direct and automatic migration would certainly pose a problem,
and which is certainly an argument against immediate automation without
an intermediate ROA “does not exist” state. i won’t pretend to
answer for the authors, but i think that this can be achieved through an
operational process that goes something like:
192.0.2.0/24 -> in use -> marked as ALLOCATED -> in use by AS65000
(with possible ROA but this isn’t important)
192.0.2.0/24 -> reclaimed -> marked as RESERVED -> no ROA for $period
192.0.2.0/24 -> reclaimed -> marked as UNALLOCATED -> AS0 ROA after
(these are my terms for showing the different states; actual afrinic-db
terms may be different)
practically, i for one, never thought that there would be an automatic
migration from “ALLOCATED” to “UNALLOCATED”; in the same way
that when afrinic deals with reclaimed space now, they don’t put it
immediately back into the pool for allocation, but hold it in
reserved/quarantine/whatever-they-call-it state. and yes, there’s a
period where these addresses may still be hijacked, but hat can be short
enough to validate that no errors were made, and more importantly, due
process was followed, whilst the rest of the unallocated space remains
“safe” (heh!). but those are just my thoughts; i don’t know
what the authors, nor afrinic were thinking..
although the example you suggested didn’t deal with reclaimed space, i
imagine that the programmable logic that says there is no direct path
from ALLOCATED -> UNALLOCATED in any scenario is not difficult to
achieve. either way, i would still say that all of these are still
operational issues, that need not be codified in resource policy. it
certainly should be operational policy that afrinic codifies and
publishes as part of its operations (which, tbf, i did not look for, but
then, with that horrible website, do you blame me? :-))
> When analysing cybersecurity proposals, we have to gauge the
> ratio, and based on my experiences so far with RPKI, this policy does
> not look good.
> We should not create a situation where the consequences
> of small errors are amplified into internet-wide outages.
absolutely. but we also have a duty to ensure that policies are created
to create and prevent abuse, and fix obvious glaring holes. it is not a
good fit to ask : “is this exploited today?” it’s a better fit to
say: “how do we prevent this from happening in a possible future”.
More information about the RPD