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.

Fernando Frediani fhfrediani at
Tue Jun 8 15:46:34 UTC 2021


I read the full message carefully and was unable to understand well the
difference between a resource holder to issue a AS0 ROA for its assigned
prefixes and for a RIR to do the same for the resources it is currently
responsible for. Operationally for the other side (the organizations who
validate RPKI) nothing.

The argument that the proponents of this proposal must have experience
in developing RPKI software is unnecessary in my view. Otherwise invite
only developers to make this kind of thing which goes much beyond
understanding the developing software.
It was mentioned that AfriNIc would be "Unfit for relying" but did not
justify why. Again what is wrong with it issuing AS0 for space it is
responsible as any other resource holder ?

The argument that a consequence may be that a dispute between members
and AfriNic will result in connectivity problems I don't see any problem
with it, not at all. Look, if there is a dispute in place AfriNic will
not revoke any resources at will and not if under the proper and due
process. If at the very end and after all possible resources and appeals
those resources are finally revoked then AfriNic MUST issue an AS0 for
those resources and yes that member will have connectivity issues
because it will be illegally using a resource that is not assigned to
him anymore, therefore the usage of this policy will be making its main
propose to secure those resources. I don't think is it fair to say that
AfriNic will/can use this policy to issue AS0 to resources while they
are still under dispute or as a 'tool for pressure'. It simply doesn't
make sense to assume that.

Also technically any RIR, and not only AfriNic can issue ROA for
whatever IP space regardless of the existence of this policy or not due
the way RPKI TAs were thought so that should have been a even bigger
concern regarding any RIR in terms of reliance of any TA.

Risks exist and will continue to exist. There are many similar others
that occurs due to wrong information and there is even hijacks due to
typos which big telecom companies don't filter properly and they get
fixed eventually. We cannot eliminate human error, but with proper
technical knowledge and management skills we can reduce it at acceptable
levels. We have been living well so far this way, otherwise things never

Regarding networks that misunderstand the  risks and consequences of AS0
TAL it is reasonable to assume that in order to operate an Autonomous
System and implement RPKI filter it must first have the necessary
knowledge to do so and use the available tools.

What you call punishment or censorship I understand in two different ways:
1) 'punishment' for those members which under proper due process had
their resources revoked and the RIR issued an AS0 for those resources,
so nothing wrong with it
2) censorship I can only see that happening 2 situations: a judicial
order in the country the RIR is established mandating it to issue AS0
for some member resources. For that remote possibly there are 3
important points to consider - a) I think is safe to think that
Mauritius has less chances for that to happen than other maybe more
unstable countries b) That kind of weird decision can always be appealed
to a higher court c) Even if this policy did not exist and there was a
judicial order for that the fact that is technically possible to do
within the existent AfriNic TA would be enough for that to get done anyway.
Still on the censorship topic I guess some people have the concern that
AfriNic may misuse this policy for wrong actions. Well if there even
happened the same Judicial system of Mauritius can fix that, and again
even without the existence of this policy (which doesn't give the power
to AfriNic to use AS0 as a censorship tool) technically it is still
possible to do it.


Em 6/8/2021 11:36 AM, Job Snijders via RPD escreveu:

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




> 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


More information about the RPD mailing list