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

[Job Snijders]

Dear Internet friends - close-by and far away,

I wish to comment on the proposal at hand. I am NOT in support of this
draft, or future versions of it. This proposal is a type of
weaponization of the RPKI that is harmful to everyone who wishes to make
productive use of AFRINIC's RPKI services.

I believe hands-on experience with RPKI and BGP are a prerequisite to
make informed decisions in this space. The proposal at hands looks great
'in theory', but is detached from operational reality. I will elaborate
on unintended consequences and detrimental effects of this policy
proposal.

Ask yourself whether the proponents of this proposal have experience
developing RPKI software, or have been involved in notable RPKI based
BGP Route Origin Validation deployment projects, or are known for their
work on BGP routing security....

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

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) - the member 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.

ASPECT #2: Any mistake AFRINIC makes in the AS0 publication will result
in significant problems for third parties. (Possibly outside AFRINIC
region) What if a typo is made? The wrong prefix added to the AS0 block
list? Why would we voluntarily increase our global 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.

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.
However, in the proposed model a whole new level of mistakes become
possible!

Lessons from the RIPE Region
============================

The RIPE Routing Working Group considered the AS0 proposal extensively,
and rejected it for sound reasons. JORDI disagrees, but this wouldn't be
the first time that a policy proposer does not receive the support they
hoped for.

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. This shows that the
idea of AS0 policies is at odds with the Internet's architecture.

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

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. 

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.

Conclusion
==========

RPKI has been designed to be used as optional security feature to help
grow the Internet, not as a 'punishment' or 'censorship' tool. 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.

If this policy is accepted - it'll be a waste of AFRINIC engineering and
financial resources (even under a separate TAL!), and needlessly
introduce risk where no risk needs to exist, for no benefit.

Kind regards,

Job

-- 
AS 54113 / Fastly