<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">This remains true only so long as the RIR is:<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>1.<span class="Apple-tab-span" style="white-space:pre"> </span>100% accurate</div><div class="">and</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>2.<span class="Apple-tab-span" style="white-space:pre"> </span>Does not issue AS0 ROAs for addresses in active dispute, appeal, etc.</div><div class="">and</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>3.<span class="Apple-tab-span" style="white-space:pre"> </span>Obeys its own rules</div><div class=""><br class=""></div><div class="">In the case of AFRINIC at this time, there appear to be questions about 1 and 3.</div><div class=""><br class=""></div><div class="">The only reason there is no question about 2 is because AFRINIC has not started issuing AS0 ROAs at all yet.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 15, 2021, at 02:46 , Mark Elkins <<a href="mailto:mje@posix.co.za" class="">mje@posix.co.za</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">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."</p><p class="">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.</p><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 6/15/21 9:59 AM, Mark Tinka wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:b025829c-4718-c63b-f489-f0782647bcdf@seacom.com" class="">
<br class="">
<br class="">
On 6/12/21 13:18, Nishal Goburdhan wrote:
<br class="">
<br class="">
<blockquote type="cite" class="">
<br class="">
could you explain the risk to afrinic’s rpki system, as you see
it, so that it’s clearly understood?
<br class="">
</blockquote>
<br class="">
I believe the example Job shared from RIPE's outage last December
refers.
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<br class="">
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 :-)
<br class="">
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?
<br class="">
<br class="">
i haven’t written about validation; because frankly, that is
always optional. and *that* fits into your crawl-walk-run
model.
<br class="">
</blockquote>
<br class="">
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.
<br class="">
<br class="">
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.
<br class="">
<br class="">
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.
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<br class="">
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?
<br class="">
</blockquote>
<br class="">
As per the RIPE incident.
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">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*.
<br class="">
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!
<br class="">
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.
<br class="">
</blockquote>
<br class="">
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.
<br class="">
<br class="">
#AsComplicatedAsItNeedsToBeAndNoMore
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">
<br class="">
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.
<br class="">
</blockquote>
<br class="">
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.
<br class="">
<br class="">
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?
<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">this is a specious argument. you’re
saying that because there is _one_ particular way of doing this,
we should not have another.
<br class="">
</blockquote>
<br class="">
There is more than one way, today, for filtering unallocated
space, Nishal. What is the problem with any or all of those
solutions?
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">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.
<br class="">
<br class="">
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.
<br class="">
</blockquote>
<br class="">
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.
<br class="">
<br class="">
Mark.
<br class="">
<br class="">
_______________________________________________
<br class="">
RPD mailing list
<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<br class="">
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
<br class="">
</blockquote>
<div class="moz-signature">-- <br class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<title class=""></title><p class="">Mark James ELKINS - Posix Systems - (South) Africa<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:mje@posix.co.za">mje@posix.co.za</a> Tel: <a href="tel:+27826010496" class="">+27.826010496</a><br class="">
For fast, reliable, low cost Internet in ZA: <a href="https://ftth.posix.co.za/" class="">https://ftth.posix.co.za</a><br class="">
<br class="">
<span id="cid:part3.2EE9A9D6.11E73E8D@posix.co.za"><abessive_logo.jpg></span><span id="cid:part4.96AB165C.E16E6133@posix.co.za"><QR-MJElkins.png></span><br class="">
</p>
</div>
</div>
_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></div></blockquote></div><br class=""></div></body></html>