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