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

[Nishal Goburdhan]

On 11 Jun 2021, at 18:49, Mark Tinka wrote:


> Hi all.

>

> TL;DR - I do not support this policy proposal.

>

> The purpose of this proposal is to give operators another method to 

> identify routes they should either ignore or filter from their routing 

> domain. It is, already, feasible to do this using the data available 

> from the AFRINIC WHOIS database. Implementing this policy does present 

> the potential to introduce some risk in the RPKI system operated by 

> AFRINIC. On the basis that the use of this policy is largely optional, 

> I am not convinced that the additional risk to the AFRINIC 

> infrastructure - and the folk who rely on it - outweighs the benefit.


mark,

could you explain the risk to afrinic’s rpki system, as you see it, so 
that it’s clearly understood?



> Getting RPKI out there is already significantly challenging. 

> Personally, I would spend more time and energy on that, before we try 

> to complicate it with a policy proposal such as this.


i disagree with a few things here.  from where i sit, and from the 
classes we’ve taught, getting networks to generate ROAs isn’t 
difficult.  getting networks to avoid, and where necessary to fix their 
INVALIDs, is also, surprisingly easy.  navigating afrinic’s BPKI 
process, to start using the system, *is* confusing and *that* is the 
barrier to entry.  but that is already being worked on separately.  so, 
i’m not clear why you think this policy takes away time and energy 
from encouraging adoption?  i mean, i know it’s frustrating and 
time-consuming replying to the anon-bots that copy+paste fantastical and 
illegitimate arguments, and that consumes time, so i, for one, have 
stopped replying to them  :-)
but, i am curious because i don’t see this clearly defined in your 
opening remarks;  what additional risk is an AS0-TAL to future adoption?

i haven’t written about validation;  because frankly, that is always 
optional.  and *that* fits into your crawl-walk-run model.


> I am less-than-interested in what the other RIR's have decided to do 

> or not to do with similar policy proposals within their regions. 

> Speaking purely with an African bias, I do not see how this proposal 

> moves the RPKI needle forward in a meaningful and impactful way. For 

> me, it's a nice-to-have, for which solutions that are well-documented 

> are already in sufficient existence.


i agree with this entire paragraph!  :-)



> I'd prefer that we did not encourage thought processes that could turn 

> RPKI into a loaded gun that may very well lead to unintended 

> consequences.


but i disagree with the manner that you frame this.  that’s a very 
charged sentence, that does not point to a specific problem.  what are 
the unintended consequences?  and, the RPKI is *already* a loaded gun.  
that ship sailed a decade ago.  and all the arguments made about the 
“… but what if … “ exist today *anyway*.
i, honestly, can not see why people don’t understand this.  if (heaven 
forbid) a rogue-government/Mar Novu held eddy and his team hostage, and 
*forced* them at gun-point inject an AS0 for, say, SEACOM’s space, 
they would likely do it.  absent a policy.  because life > your routing. 
  how does this policy change that at all?  the reality check is that we 
don’t make policies about who gets to carry the guns;  just, where and 
how INRs are registered.  guns are *always* going to win!
i’m already on record as saying i’m “meh” about this policy.  
but what i can’t be quiet about, is the disinformation that’s being 
spread about the risks attached here.  it’s ok to say “i don’t 
like this” and “i won’t use it”, but it’s not ok to pretend 
that this policy does anything new and shockingly bad.  and if you think 
there is something new and shockingly bad, please write it out in 
simple, unemotional language.

i would really sincerely appeal to you, to process what i’ve written 
in the paragraph above.  the threat from RPKI is non-zero;  we knew this 
10years ago, and we went ahead with it.  the threat from this policy 
does not add to the threat from RPKI.  and what needs to be discussed 
here is not a general overview of RPKI, and its threat model, but, 
specifically, *just this policy*.  and since this policy is purely meant 
to deal with space this is not meant meant to be routed - ie. no 
legitimate users - i can’t see the fuss.



> Suggest we focus our efforts on actually getting RPKI more widely 

> deployed. A case of "crawl before we can run", type-thing.


and again, this comment has nothing to do with this particularly 
policy..unless you are going to point to a clause in this policy that 
shows how this policy prohibits adoption.



> A policy such as this could set a precedent for significantly more 

> (well-intentioned, but) disastrous use-cases for the RPKI.


<sarcasm> well, if you want to do proper root cause analysis, we should 
simply decommission the RPKI to protect ourselves from it ..!  
</sarcasm>
but that’s not likely to happen.  otoh, what if this policy sparks 
better, and more defined use cases (ie. the counter of what you write).  
neither of us has a crystal ball, mark, and so, we should stick to the 
discussion of _this_ policy.

which roughly equates to:  what’s bad about having unallocated space 
be marked as AS0?



> I'd err on the side of avoiding situations where centralized control 

> of gratuitous blackouts of part or all of the Internet, on purpose or 

> by mistake, are not given roots to emerge. Keeping the genie in the 

> bottle is, for me, far better than thinking you can cage it once it 

> has been set free.


again - and i feel like i’m on repeat here - this policy doesn’t do 
that.



> AS0 is unlikely to help me stop paying the annual subscription for my 

> anti-spam and anti-virus system. If there is some other practical 

> problem - for which a solution currently does not exist - that this 

> policy proposal is looking to fix, I'd be most obliged to hear it. 

> Thanks.


this is a specious argument.  you’re saying that because there is 
_one_ particular way of doing this, we should not have another.  i 
can’t agree with that.  i’d prefer to equip people with sufficient 
and varied tools such that they could choose to use what they themselves 
want to.  preferably after some education  :-)   some tools may require 
more working parts than others (eg. anti-spam is not trivial);  and some 
people may opt to use all/none of them.  it’s not my place to say what 
tool someone should use.  and that’s what i see this policy as - an 
optional tool that someone could opt use.  it’s clear that you, ben, 
and job don’t want to, and that’s fine.  but frank, jordi, and 
ferdinand, do want the option to.

our job here isn’t to tell frank that he can’t use it just because 
you don’t want to.  our job is to help provide afrinic with a 
framework for making the information available to frank in a safe, and 
predicable manner.

—n.