Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Paschal Ochang pascosoft at
Tue Jun 15 09:22:40 UTC 2021

+1 Mark. Excellently said.

On Tuesday, June 15, 2021, Mark Tinka <mark.tinka at> wrote:



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


> _______________________________________________

> RPD mailing list

> RPD at



Kind regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list