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

[Paschal Ochang]

+1 Mark. Excellently said.

On Tuesday, June 15, 2021, Mark Tinka <mark.tinka at seacom.com> 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

>



-- 
Kind regards,

Paschal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20210615/2609d451/attachment-0001.html>