Search RPD Archives
[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.
pascosoft at gmail.com
Tue Jun 15 09:22:40 UTC 2021
+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
> 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
>> 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
>> 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.
> RPD mailing list
> RPD at afrinic.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the RPD