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 11:18:39 UTC 2021

On 11 Jun 2021, at 18:49, Mark Tinka wrote:

> Hi all.


> TL;DR - I do not support this policy proposal.


> The purpose of this proposal is to give operators another method to

> identify routes they should either ignore or filter from their routing

> domain. It is, already, feasible to do this using the data available

> from the AFRINIC WHOIS database. Implementing this policy does present

> the potential to introduce some risk in the RPKI system operated by

> AFRINIC. On the basis that the use of this policy is largely optional,

> I am not convinced that the additional risk to the AFRINIC

> infrastructure - and the folk who rely on it - outweighs the benefit.


could you explain the risk to afrinic’s rpki system, as you see it, so
that it’s clearly understood?

> Getting RPKI out there is already significantly challenging.

> Personally, I would spend more time and energy on that, before we try

> to complicate it with a policy proposal such as this.

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.

> I am less-than-interested in what the other RIR's have decided to do

> or not to do with similar policy proposals within their regions.

> Speaking purely with an African bias, I do not see how this proposal

> moves the RPKI needle forward in a meaningful and impactful way. For

> me, it's a nice-to-have, for which solutions that are well-documented

> are already in sufficient existence.

i agree with this entire paragraph! :-)

> I'd prefer that we did not encourage thought processes that could turn

> RPKI into a loaded gun that may very well lead to unintended

> consequences.

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

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.

> Suggest we focus our efforts on actually getting RPKI more widely

> deployed. A case of "crawl before we can run", type-thing.

and again, this comment has nothing to do with this particularly
policy..unless you are going to point to a clause in this policy that
shows how this policy prohibits adoption.

> A policy such as this could set a precedent for significantly more

> (well-intentioned, but) disastrous use-cases for the RPKI.

<sarcasm> well, if you want to do proper root cause analysis, we should
simply decommission the RPKI to protect ourselves from it ..!
but that’s not likely to happen. otoh, what if this policy sparks
better, and more defined use cases (ie. the counter of what you write).
neither of us has a crystal ball, mark, and so, we should stick to the
discussion of _this_ policy.

which roughly equates to: what’s bad about having unallocated space
be marked as AS0?

> I'd err on the side of avoiding situations where centralized control

> of gratuitous blackouts of part or all of the Internet, on purpose or

> by mistake, are not given roots to emerge. Keeping the genie in the

> bottle is, for me, far better than thinking you can cage it once it

> has been set free.

again - and i feel like i’m on repeat here - this policy doesn’t do

> AS0 is unlikely to help me stop paying the annual subscription for my

> anti-spam and anti-virus system. If there is some other practical

> problem - for which a solution currently does not exist - that this

> policy proposal is looking to fix, I'd be most obliged to hear it.

> Thanks.

this is a specious argument. you’re saying that because there is
_one_ particular way of doing this, we should not have another. 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.


More information about the RPD mailing list