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.

Mark Elkins mje at
Tue Jun 15 09:46:43 UTC 2021

From below - you stated......  "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."

The less ways that are needed to achieve a goal, the less decisions (or
suites of software) you need. If you are already using ROA & RPKI - then
that solution will automatically block unallocated space, then you don't
need to use something else to do that job (e.g. Team Cymru's BGP feeds -
which I used to use). I would also have thought that what the RIR is
doing would always be the most up to date (in real time) method of
filtering unallocated RIR space.

On 6/15/21 9:59 AM, Mark Tinka 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



Mark James ELKINS  -  Posix Systems - (South) Africa
mje at       Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA:

Posix SystemsVCARD for MJ Elkins

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abessive_logo.jpg
Type: image/jpeg
Size: 6410 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QR-MJElkins.png
Type: image/png
Size: 2163 bytes
Desc: not available
URL: <>

More information about the RPD mailing list