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

[Nishal Goburdhan]

On 9 Jun 2021, at 10:10, Ben Maddison via RPD wrote:



> The draft policy *does not* mandate that a separate TA be used.

> I have previously suggested that this should be mandated in the 

> policy,

> but this was not done.


i am pretty certain that we agreed that this was an operational issue 
and those are not dealt with, in policy.
i’m also pretty certain that, in all discussions we have had, this is 
how we have referred to this  (eg. look at amreesh’s most recent 
explanation).
let the policy explain the gist of what needs to happen;  not the 
“how” ..



> Some scenarios that I can anticipate:

[snip]

i can see why you would think this, but i also think that there is a 
general misconception as to when and how afrinic goes through the 
process of address reclamation.  having seen into that part of the 
kitchen, i can tell you that as a community member that is *often* at 
odds with afrinic, i can’t fault their approach to this.  there is no 
magical “sorry-you-are-one-day-overdue-we-are-disconnecting-you” 
button that they push.  de-registrations is a months-long, and arduous 
process.

ben/job, i’m sorry, but this argument amounts to:  “we don’t trust 
afrinic to do their (administrative) job (of reclamations) correctly”. 
  if that’s truly the case, then, i have two proposals for you:
#1 - get over it;  the chance to mess up occurs in many other areas, in 
many other ways, or,
#2 - get involved in the adhoc group that afrinic will setup for 
consultation before implementation;  ie.  help define a 
checks-and-balances process that deals with any kind of 
operationalisation.  (which, btw, is probably not a bad thing to do 
anyway)
honestly folks, what you’re spreading here is fear-mongering:  “what 
if afrinic does … “ and not a credible argument, that could not be 
mitigated via a thorough implementation plan.  and i have it on good 
authority that afrinic are doing just that - reviewing their processes 
and doubling up on their internal procedures to prevent another 
ErnestGate.  don’t insist on conflating earlier failure with deriving 
good policy.

[snip]


> Automation is simply a means of making typos at scale.


frankly, before de-registration, i would expect no automatic 
de-registration.  and nothing less than senior management approval.  
which, used to be the case anyway.  i am very certain that our friends 
at afrinic take de-registration *very* seriously, and again, i’ll 
point to the mentions by the CEO of how they’ve had to adjust payment 
options, and develope payment plans with members, during the ongoing 
pandemic.

that does not scream of some capitalist organisation that’s waiting to 
weaponise the rpki ..



> The authors and proponents of this policy have consistently failed to

> provide examples of actual operational problems that this policy would

> solve, whilst many examples of potential harm have been provided.


i disagree ben, but perhaps it’s because i am more used to reading 
jordi and frank.  and i don’t agree that there are many examples of 
harm cited, vs. a general misconception of how some of the afrinic 
processes work.  and, frankly, that’s easy to understand, because 
afrinic don’t make a song and dance about _how_ they do reclamations, 
since it’s not something that most of the membership is interested in.



>>> Lessons from the RIPE Region

>>> ============================

>>>

>>> ...

>>>

>>> RIPE NCC is subject to EU Regulations and Sanctions. Iranian and 

>>> Syrian

>>> internet participants would have been at risk of losing internet

>>> connectivity (on top of an already challenging and devastating

>>> situation) if the idea of AS0 TALs was implemented.


in the many years that there have been these sanctions has the NCC *not* 
willingly provided resources to these countries?
does the NCC not _at the time of writing_ still provide secondary DNS 
services to these states?
(don’t worry, i know the answer to both)
i’m sorry if sanctions are new to you, or if you haven’t figured out 
how to deal with them;  but, guess what, afrinic has evidently been 
doing this in a manner that’s acceptable to affected parties for a 
while, Just Fine.




>> That risk is serious and I should think carefully and twice before 

>> using

>> the RIPE AS0-TAL. Thanks for warning me and thanks for giving me the

>> choice.


we’ve beaten this horse to death now;  there’s an AS0 TAL and it’s 
optional.
move along, nothing to see here.



> Why would we ask AFRINIC to spend valuable time and energy 

> manufacturing

> a dangerous foot-gun, which even the designers would "think [...] 

> twice

> before using"?

>

> Don't you have a list of things that would actually be useful? I do!


because it is neither afrinic manufactured, and it is not a difficult 
thing to do (for those that wanted to use it).
and, i don’t see this as a thing that afrinic has to do at the expense 
of something else.

i abhor cigarettes;  i’m pretty certain you don’t feel the same, and 
that is _your_ choice..



>> At this moment I don't see the big difference to a Team-Cymru bogon 

>> feed

>> via bgp. The cymru feed having the extra minus of involving an extra

>> external party.


you are correct.  team-cymru have provided this feed for ages now.
but this is also a non-disputable way to not outsource your trust to a 
third party - like team-cymru.
i don’t understand how you can’t see that removing a third party, is 
better overall design?




>>> Even if this policy proposal is implemented under a distinct TAL, 

>>> there

>>> will be some networks somewhere that misunderstand the risks and

>>> consequences of 'AS0 TAL', and subsequently end up losing 

>>> connectivity

>>> towards some Internet destinations for no good reason.


<sarcasm>
and allowing networks to self-originate is dangerous tool.  there are at 
least a dozen ways they can harm themselves.  make sure all operators 
have their Internet Driver’s License before enabling BGP.
</sarcasm>

the way you fix this, is via education.  which, you probably want to 
have done _before_ any kind of validation is attempted anyway, which is 
pretty much covered by:


>> Reminds me how i advised someone to not enable validation....



:-)




>>> Another aspect: almost no operators are using the APNIC/LACNIC AS 0 

>>> TAL!

>>> It appears many people recognize that it brings additional risk, for 

>>> no

>>> reward. Success stories of the AS0 TAL in LACNIC and APNIC do not 

>>> exist.


that is not a valid argument.  do you feel it would be appropriate if we 
said the same of ipv6 in 2000 (it’s been 4years, and ..) ?



> The best way to ensure a tool is not abused is not to create it.

> Once it exists the potential for abuse exists, regardless of anyone's

> intentions.

>

> In my view, the most important thing to recognize is that a third 

> party

> may *force* AFRINIC to abuse it.


who is the Mar Novu that holds such sway over afrinic?  what if that 
party said:  re-allocate all $party’s address space to $other_org?  
please provide a reasonably strong technical argument, and leave out the 
fear mongering.  and, for bonus points, explain how that threat 
doesn’t exist today, in a multitude of ways?
and so, what _IF_ this mythical god does hold afrinic ransom?   how 
difficult would it be for afrinic to revoke the entire TAL?
and, it still seems that you’re missing that this is all *ENTIRELY 
OPTIONAL*

use it, or not.  that choice exists with you.

-n.