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

[Mark Elkins]

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

> https://lists.afrinic.net/mailman/listinfo/rpd

-- 

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

Posix SystemsVCARD for MJ Elkins

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210615/6f72b30e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abessive_logo.jpg
Type: image/jpeg
Size: 6410 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210615/6f72b30e/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QR-MJElkins.png
Type: image/png
Size: 2163 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210615/6f72b30e/attachment-0001.png>