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

[Nishal Goburdhan]

On 15 Jun 2021, at 9:59, 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 see that as a broken operational process.  moving from ALLOCATED -> 
UNALLOCATED is wrong, and it requires an intermediate step.  in my 
reply, i said that i understand that an intermediate step removes this 
risk, and still keeps “the RPKI system” intact.  would you agree?   
or maybe, we should ask this of afrinic directly?   (madhvi / 
new-amreesh?)
btw, even today, AFRINIC have this as their regular, generic reclamation 
process;  reclaimed resources are *not* added to the pool without going 
through a RESERVED state.  and that was even the case for *new* 
resources from IANA, iirc  (although that might have changed over the 
past decade)


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

.. and as i said, i do not see an optional AS0 TAL as stalling this 
deployment.  if you do, could you explain *how*, please.


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

mark, there’s little incorrect with what you’ve written above.  but 
i’ll point you to the previous discussion of this policy which really 
revolved around a complete misunderstanding of how RPKI works from the 
anon-bots.  and, as the current co-chairs pointed out, *zero* discussion 
since the most recent version of this was posted.  i don’t count this 
exchange with you/job/ben as wasted, because, it’s archived, and, 
hopefully, would pass on as a different type of educational experience 
for dear reader.  at the very least, i’m hoping that *i* learn 
something new out of it.  although, i *do* wish this had happened 
earlier, because this isn’t really the sort of discussion that 
last-call is meant for   :-)


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

so you disagree with the policy, because you think it’s unnecessary.  
this is different to:  “it poses a risk to the rpki”.  for the 
record, i also largely think that the policy is “meh”.  yes, still 
:-)

but i also think that the pushback against it, is not quite justified.  
let’s talk about alternate solutions below..


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

again, i contend that this can be fixed through process.  if there is 
one single thing that i want afrinic to do better, it is to improve her 
processes.  in *everything* that she has to undertake.  so please tell 
me if and how how a well thought-out operational process fixes that 
concern, or not?  caveat:  i don’t know what that process is;  smarter 
people than i, are going to be needed to contribute to that!

but i might be wrong;  maybe it’s too difficult, or intermediate phase 
don’t scale, or ..
so, please educate me;  (i think) i’m reasonable enough to listen, 
and, more importantly, i’m willing to learn how i might be thinking 
about this incorrectly.


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

my point is that, the “loaded gun” argument is moot.  it’s a risk 
attached to rpki.  *not* this policy.  again, dear reader, this policy 
targets **unallocated** space only.  and again, nothing stops that rogue 
government/Mar Novu (that “threat” that’s been tossed about) from 
raiding the 11th floor afrinic headquarters *right now*, and asking the 
afrinic team to inject an AS0 ROA for seacom.  (well, aside from covid, 
and an empty office :-)).  the effects today, would be worse, because it 
would be injected into a non-separate-AS0-TAL, which *is* in wide use.  
so, if anything, the implementation of this policy will give folks an 
opt-out of a future such occurrence!   (ok, ok, that’s a bit of a 
stretch ;-))

[frankly, i don’t even know why this is a discussion matter.  
there’s no afrinic policy on rpki.  there was no policy on processes 
it should use to implement it.  sure there were adhoc meetings and a 
mailing list that’s not used  :-)  so, nothing actually stops afrinic 
from doing this anyway.  and since the space is, by definition 
*unallocated*, and therefore not being used by anyone, afrinic could 
really just do all this on its own, as custodian of unused space.  but 
that argument is also orthogonal to this policy, so let’s not open 
that can of worm, m’kay? ;-)]


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

but there’s no extension needed here.  i stopped read sidr and 
sidr-ops a looooooong time ago, but i’m pretty sure that AS0 was 
always intended to signal “no routing”.  and read in context, the 
key element to this policy is that it targets *unallocated* space.  not 
all space.  so a discussion of future policies, in some random future, 
SHOULD read that AS0 was tied to that key element (*unallocated* space). 
  and in that same future imperfect, who is to say that there won’t be 
a *better* policy to deal with a problem we have not yet thought of, 
that builds on this?  the good thing, is that we will (hopefully) still 
be around to debate those future policies, and, based on their own 
idiosyncratic merits, argue for and/or against.  as it should be.


> In the routing world, I always joke that we are one step away from 
> getting BGP to do DNS.

actually, i know of at least one DNS service that you can query for BGP 
routes, but anyway :-)


> 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?

i don’t think that’s the claim honestly.  just like how rpki itself 
can’t claim to “secure routing”.  but, like rpki, i do think that 
it’s another tool in frank/jordi/blah’s toolbox, and before we say 
you don’t get to use the tool, it’s necessary to have the discussion 
on *why* they shouldn’t get to use it.  and honestly, from where i 
sit, that discussion isn’t really convincing me that there’s a good 
enough reason to deny letting them have access to the tool.


>> 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?

data in the IRR is dirty, inaccurate, and easy to fake.  i’m pretty 
sure i even remember us teaching a class on how to launch a network 
hijack, and doing fake IRR entries as part of that (abuja/cairo/..?)  
team-cymru are fine folk, but there’s no reason to outsource your 
trust to a third-party organisation when you can do this from the 
source, automatically.  and whilst grep’ing allocations-daily.txt from 
all the RIRs is easy enough, if i don’t have to maintain a script to 
do this, but have the RIR auto-signal this to me, in manner that matches 
my technology stack, that’s win!
like you, i can argue both sides of the coin.  but, again, i don’t see 
it as either of our place to point out what does, and does not work for, 
nor to limit what and how people should implement their security 
policies.  what i want to do, is asses the threat of this proposed 
policy, and so far, job’s cited incident at RIPE is, to me, the 
singular credible threat that this policy creates..  but, which, as i 
mentioned, i had already expected to include an “intermediate” 
process, which i think mitigates his concern.  frankly, i don’t see 
how anyone would have seen that implementation differently.

ever mindful that i am missing something obvious, i went over to the 
APNIC archives to see if there were other credible threats that i was 
missing, that was raised in their discussion process.  i see that this 
“intermediate” step was already classified as necessary by at least 
one person (david farmer in [1]).  i couldn’t find anything else in 
their archives about their version of this proposal that i would 
consider worrisome.


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

thusfar, (excluding the anon-bots and shills), i’ve read :
# afrinic will make mistakes (which i say, can be fixed through process 
and a double-verification system, which *MUST* be in place for 
*EVERYTHING* moving forward, anyway. #ErnestGate, we have seen that 
movie, move on and afrinic if you are *not* already peer-review for 
everything, then shame on you!)
# “i don’t think it is necessary”  (really, that’s not my - or 
your - call!)
# it complicates the setup for rpki newbies  (i asked *how*, and i 
haven’t really seen an answer to that;  i agree that adding a separate 
AS0 TAL for experienced operators is more work, but, frankly, i don’t 
care, because it’s opt-in, and you’re not a newbie if you’re 
manually adding a TAL!)
# there’s a legit failure case - aka the aforementioned NCC incident.  
(i contend this can be fixed through process, which should be rigorously 
encouraged *anyway*)
# it’ll open the door to the wrong sort of policies.  (oh boy!  
we’re not the policy police;  but we are also the policy police!  
personally, i’m not scared of future, and judging from the increasing 
number of participants to this mailing list, i think there’s good 
stead for future, intelligent discussion over future possible policies)

so i ask again :  what else?
i can appreciate that you feel that rpki is not the right tool for this. 
  and i think that you/ben/job, are well positioned to explain real 
operational risks, so, please, highlight a legit problem that either 
costs too much to mitigate, or is difficult to mitigate, or comes with a 
doomsday ticker, or ..

policies don’t pass because we like or don’t like them;  or whether 
we individually feel if they are right or not.  (loosely put) they pass 
because there’s consensus that this fixes a problem for enough people, 
and, it’s not going to break the internet while they do it.  what 
i’d really love to see, with the wealth of experience that this list 
has recently gained, is someone explaining/showing the latter.  and as 
i’ve said, whether the risks attached in mitigation are worth it, or 
not.  and, honestly, i (at least) didn’t find a convincing enough 
argument in the summarised five assertions above.  please feel free to 
show me what i missed.


—n.

[1] 
https://mailman.apnic.net/mailing-lists/sig-policy/archive/2019/08/msg00023.html