Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

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

Nishal Goburdhan nishal at
Sat Jun 12 10:21:14 UTC 2021

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
let the policy explain the gist of what needs to happen; not the
“how” ..

> Some scenarios that I can anticipate:


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

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


> 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

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

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.

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

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


More information about the RPD mailing list