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

[Frank Habicht]

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


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


> https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html


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?


> ..


Greetings,
Frank


[1]
https://en.wikipedia.org/wiki/Fail-fast
Vixie on [dns-operations] comes to mind.