[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.

[Nishal Goburdhan]

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 

> legacy

>     resources lost their contractual status in our internal systems. 

> The

>     result of this was that the RPKI ROAs for these resources were

>     revoked."


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 
$period +1
(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 

> reward/risk

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


—n.