<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 8, 2021 at 5:43 PM Job Snijders via RPD <<a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Internet friends - close-by and far away,<br></blockquote><div><br></div><div>Hi Job,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Ask yourself whether the proponents of this proposal have experience<br>
developing RPKI software, or have been involved in notable RPKI based<br>
BGP Route Origin Validation deployment projects, or are known for their<br>
work on BGP routing security....<br></blockquote><div><br></div><div>Yes many of us have real world deployment projects across real networks in AFRICA.[1] </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Danger to AFRINIC members<br>
=========================<br>
<br>
If this policy proposal is implemented, the ultimate consequences is<br>
that certain types of disputes between members and AFRINIC will result<br>
in severe connectivity problems for the member. Some members might<br>
think, "that will never happen to me, I always pay my bills on time!"<br></blockquote><div><br></div><div>This already happens and Covid was one such situation that affected most businesses but like with any responsible organization, AFRINIC has had to adjust on how it deals with its members including those that have struggled as a result of the Covid force majeure. </div><div><br></div><div>In anycase, AFRINIC is not a briefcase organization, it has processes which it follows to the benefit of its members whether they pay in time or delay payment for there is always a reason.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But we cannot know the future! If five years from now there is a banking<br>
issue between AFRINIC's bank and a member's bank (for example, because<br>
of sanctions, war conflict, or any other issue) - </blockquote><div><br></div><div>In our region, this is already happening as some countries within AFRINIC service region have faced civil wars in the recent past (Somalia, South Sudan, Libya, CAR, DRC) and some Sanctions (Sudan) yet AFRINIC members in this countries forge on and AFRINIC whose responsibility is known to us all, has continued to serve this countries.  The AFRINIC website I believe has a members list across its service region, please look at it.</div><div><br></div><div>Nothing new.... All it takes is being realistic to the situation as no single country wishes to find itself in some civil war or sanctions yet our people can not be denied services for explanations that are reasonable to us all.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">the member suddenly<br>
might find themselves in a situation where not only the AFRINIC<br>
registration of IP addresses falters (a serious problem), but<br>
additionally the member's internet connectivity is forcefully taken<br>
offline (an even bigger problem!). This seems disproportional.<br></blockquote><div><br></div><div>None has happened and I stand to be corrected. Has AFRINIC cancelled memberships in our AFRICAN countries of CAR, Libya, Tunisia, Egypt, South Sudan, Somalia etc...? which have faced conflicts in recent years.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
ASPECT #2: Any mistake AFRINIC makes in the AS0 publication will result<br>
in significant problems for third parties. (Possibly outside AFRINIC<br>
region) What if a typo is made? The wrong prefix added to the AS0 block<br>
list? Why would we voluntarily increase our global risk? The proposal<br>
authors will blow off these concerns as 'surely AFRINIC will never make<br>
a mistake', ... but that simply is not how things work.<br></blockquote><div><br></div><div>There have been so many global Internet outages in the past 24hrs and as recently as earlier today [2].  </div><div><br></div><div>I wonder if they are all related to the RPKI AS0 TAL implementation gone south due to human error.</div><div><br></div><div>Yet they have been fixed because we humans error and we humans fix mistakes and we have been doing that since the beginning of time. </div><div><br></div><div>So nothing new hey....</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In the current RPKI service model, most problems can only be caused by<br>
AFRINIC members themselves, and only related to their own prefixes. It<br>
is a Good Thing [tm] when people can only negatively impact themselves.<br>
However, in the proposed model a whole new level of mistakes become<br>
possible!<br></blockquote><div><br></div><div>And yet mistakes never stop after all.  But we fix them, that is why they are referred to us as MISTAKES.</div><div><br></div><div>That does not mean that we don't have the capacity to be cautious while following BCP's. </div><div><br></div><div>We will error brother, because we are human.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Lessons from the RIPE Region<br>
============================<br>
<br>
The RIPE Routing Working Group considered the AS0 proposal extensively,<br>
and rejected it for sound reasons. JORDI disagrees, but this wouldn't be<br>
the first time that a policy proposer does not receive the support they<br>
hoped for.<br></blockquote><div><br></div><div>That is the RIPE region and this is the AFRINIC region.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
RIPE NCC is subject to EU Regulations and Sanctions. Iranian and Syrian<br>
internet participants would have been at risk of losing internet<br>
connectivity (on top of an already challenging and devastating<br>
situation) if the idea of AS0 TALs was implemented. This shows that the<br>
idea of AS0 policies is at odds with the Internet's architecture.<br></blockquote><div><br></div><div>Do you mean RIPE members who have been rightfully allocated INR.?</div><div><br></div><div>Or do you mean those using unallocated RIPE INR.?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<a href="https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html" rel="noreferrer" target="_blank">https://www.ripe.net/ripe/mail/archives/routing-wg/2020-June/004131.html</a><br>
<br>
Even if this policy proposal is implemented under a distinct TAL, there<br>
will be some networks somewhere that misunderstand the risks and<br>
consequences of 'AS0 TAL', and subsequently end up losing connectivity<br>
towards some Internet destinations for no good reason.</blockquote><div><br></div><div>Nothing new. Operational mistakes happen all the time and they are fixed while lessons are taken.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
Another aspect: almost no operators are using the APNIC/LACNIC AS 0 TAL!<br>
It appears many people recognize that it brings additional risk, for no<br>
reward. Success stories of the AS0 TAL in LACNIC and APNIC do not exist.<br></blockquote><div><br></div><div>It is proposed that operators shall have a choice.  It ain't mandatory. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Conclusion<br>
==========<br>
<br>
RPKI has been designed to be used as optional security feature to help<br>
grow the Internet, not as a 'punishment' or 'censorship' tool. </blockquote><div><br></div><div>Can you please share any such real world situation in APNIC or LACNIC who have implemented the same policy, and there has been a resource member in those regions who was punished or censored.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To<br>
reclaim unassigned space, AFRINIC can continue to work with global<br>
carriers on a case-by-case basis. The 'problem' this proposal 'solves'<br>
is NOT proportional to the risks the proposal introduces.<br></blockquote><div><br></div><div><br></div><div>AFRINIC has been reporting to the community and members about recovered address space that had been misappropriated from the free pool. Please check the mailing list archives in case you missed the announcements. </div><div><br></div><div> Anything that further helps with dealing with bogons is welcome to say the least. Why should an LIR suffer because the newly allocated space had been blacklisted in the past because it had been hijacked and used to SPAM or DDOS or used in some Internet related Abuse.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If this policy is accepted - it'll be a waste of AFRINIC engineering and<br>
financial resources (even under a separate TAL!), and needlessly<br>
introduce risk where no risk needs to exist, for no benefit.<br></blockquote><div><br></div><div>This remains for AFRINIC staff to proclaim as such.</div><div><br></div><div>Just to state on the record, that I am yet to find any of the reasons you have stated, as valid objections.</div><div><br></div><div>Cheers,</div><div>Noah</div><div><div>[1] My boss would confirm the same</div><div>[2] <a href="https://downdetector.com/">https://downdetector.com/</a></div><div> </div></div></div></div>