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

[Mark Tinka]

On 6/12/21 13:18, Nishal Goburdhan wrote:


>

> could you explain the risk to afrinic’s rpki system, as you see it, so 

> that it’s clearly understood?


I believe the example Job shared from RIPE's outage last December refers.



>

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


Teaching classes is one thing, Nishal. Translating that into the real 
world so it has the desired impact is a much larger issue. Tutorials and 
presentations abound, the world over, about RPKI, what it is, what it 
does, how it works, how to enable it and how to operate it. But this 
only matters if folk are actually deploying it.

If key folk in the community are spending time back & forth pushing 
through something such as AS0, that is less time we can spend promoting 
basic RPKI deployment into the operations that are either ambivalent 
about it, or need a bit of encouragment from those who are more 
confident about it.

Yes, chewing while walking is not impossible, but there is simply less 
time going around for all of us nowadays. Solutions for filtering 
unallocated space already exist. If those solutions have not yielded the 
desired result (whatever benchmark one may use to quantify that), it is 
not because solutions do not exist.



>

> 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?


As per the RIPE incident.



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


Hardly emotional, Nishal - and very simple language I used there. I also 
understand the RPKI to a reasonable degree, having operated it since 
2014. RPKI does quite a bit to centralize routing, a concern the 
community have had about it since its inception, even though that was 
never its intention. My message is unless it is absolutely necessary - 
for which pre-existing solutions do not exist - let us resist the urge 
to make those concerns come true.

#AsComplicatedAsItNeedsToBeAndNoMore



>

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


The framework of previous policies can be used to assert the purpose and 
usefulness of new ones. If it can be shown that the RPKI has been 
extended to support AS0, that lays the groundwork for different (but 
similar) proposals that follow the framework. In the routing world, I 
always joke that we are one step away from getting BGP to do DNS.

But coming back just this policy, I ask again - we already have a ton of 
solutions today that would give us all the tools and power to filter 
unallocated RIR space. Why do we think those tools aren't doing the job, 
and by extension, that RPKI will magically solve that problem with AS0?




> this is a specious argument.  you’re saying that because there is 

> _one_ particular way of doing this, we should not have another.


There is more than one way, today, for filtering unallocated space, 
Nishal. What is the problem with any or all of those solutions?



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


I have no problem with yet-another solution amongst the multitude that 
currently exist to be developed so that we can filter unallocated space. 
I am just not convinced that riding the back of the RPKI is the right one.

Mark.