Search RPD Archives
[rpd] Last Call - RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space AFPUB-2019-GEN-006-DRAFT03.
geier at geier.ne.tz
Tue Jun 8 21:38:23 UTC 2021
On 08/06/2021 17:36, Job Snijders via RPD wrote:
> At the moment of writing, the AFRINIC Trust Anchor has excellent
> standing in the global community. If AFRINIC starts publishing RPKI
> ROAs for Unallocated or Unassigned space, unfortunately, I'll have to
> consider the AFRINIC RPKI Trust Anchor to be UNFIT FOR RELYING.
I believe the current Trust Anchor will not be touched.
A new one will be created.
Why would your opinion about the current TA change?
It is acceptable that you will consider the new TA unfit.
I would think the first one could still be fine for you.
> Implementation of this proposal will put years of AFRINIC's work and
> investment in RPKI at risk, ... a pretty crazy situation! :-(
> Danger to AFRINIC members
> If this policy proposal is implemented, the ultimate consequences is
> that certain types of disputes between members and AFRINIC will result
> in severe connectivity problems for the member. Some members might
> think, "that will never happen to me, I always pay my bills on time!"
I have the tendency to look for root-causes.
Why would the "certain types of disputes" come into existence...?
Can it be avoided? ;-)
> But we cannot know the future! If five years from now there is a banking
> issue between AFRINIC's bank and a member's bank (for example, because
> of sanctions, war conflict, or any other issue)
I understand AfriNIC staff do contact members before any
de-registration. I know first-hand that they also contact upstream
In terms of time-line, I also believe (i guess staff can confirm) that
de-registrations done in February 2021 were for members where fees are
not paid for 2020. Did the members have 11 months? or 12 months to sort
I know of two (EU-PI) members in this-here country whose inetnums were
removed and following that it was just a matter of ongoing RIPE-NONAUTH
cleanup for them to have zero route objects and "impact".
So somebody had to talk sense into these resource members. This won't
> - the member suddenly
i object to 'suddenly'.
> might find themselves in a situation where not only the AFRINIC
> registration of IP addresses falters (a serious problem), but
> additionally the member's internet connectivity is forcefully taken
> offline (an even bigger problem!). This seems disproportional.
There are those in the world who advertise "fail fast and hard" 
Also: above is the case if _all_ of the upstreams of the member actively
choose the AS0-TAL, and don't implement any manual overrides/workarounds
for the customer.
> ASPECT #2: Any mistake AFRINIC makes in the AS0 publication will result
> in significant problems for third parties.
those that actively choose the AS0-TAL.
> (Possibly outside AFRINIC
> region) What if a typo is made?
one would expect a lot of automation.
> The wrong prefix added to the AS0 block
> list? Why would we voluntarily increase our global risk?
I think this is not an argument against _having_ the 2nd TAL.
I think it's against _using_ it.
Some operators might weigh and see more benefits than cost+risk.
> The proposal
> authors will blow off these concerns as 'surely AFRINIC will never make
> a mistake', ... but that simply is not how things work.
I wrote "This chance is not exactly zero. As with any other change
anywhere." on this list about 51h ago. So: no. I still believe we live
in the same reality.
> In the current RPKI service model, most problems can only be caused by
> AFRINIC members themselves, and only related to their own prefixes. It
> is a Good Thing [tm] when people can only negatively impact themselves.
I absolutely agree. Also well put.
> However, in the proposed model a whole new level of mistakes become
But we have to note that this is for network operators to decide on
whether they want to use the *optional* new TAL with new-shiny "includes
> 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.
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. Oh. not?
> This shows that the
> idea of AS0 policies is at odds with the Internet's architecture.
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
It's sad that RIPE NCC and members have to worry about sanctions.
I have no idea how (better or worse?) that would be different in
Mauritius. And well, i don't know where that leaves scope of this list.
> 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.
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.
It's new and optional.
> RPKI has been designed to be used as optional security feature to help
> grow the Internet, not as a 'punishment' or 'censorship' tool.
ehm: that's also not the intention here.
And in my opinion AfriNIC is not allowed to use RPKI in that way.
> reclaim unassigned space, AFRINIC can continue to work with global
> carriers on a case-by-case basis. The 'problem' this proposal 'solves'
> is NOT proportional to the risks the proposal introduces.
I could name you a carrier that's validating and advertising space from
the de-registered customer ("bogon AS"). Did they have a talk to their
customer to get reinstated at AfriNIC? Would AfriNIC staff confirm that
they contacted that upstream?
Vixie on [dns-operations] comes to mind.
More information about the RPD