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.

Frank Habicht geier at
Tue Jun 8 21:38:23 UTC 2021

Hi Job,

[co-author writing]

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

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" [1]

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

> possible!

Yes. agreed.
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
AS0" features.

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


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.

> Conclusion

> ==========


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

> To

> 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 mailing list