[rpd] Policy Impact (was Re: Cloud Innovation Displays Very Poor, If Not Criminal, Netizenship)

[ALAIN AINA]

Hello,

Let us be alert to detect and address issues like this affecting our networks and Internet resources.

Good that  old human networking helped to immediately stop this hijacking, but It was the time when one could expect to rely on accurate and responsive abuse contacts.

Yes, ROA and ROV could not have helped here. They are designed to help with accidental mis-configuration of origin. But let imagine that the LoAs issued for the origination of this prefix by upstreams were turned into ROAs. Wouldn’t it be different?

The adoption of solution like Autonomous System Origin Authorization could have prevented the hijacking. But until we get there, shall we continue to refuse to improve the system with the little we have ?

An existing adoption and large scale experience with ROV would definitely help with the adoption of new solutions. 

Adoption and implementation of accurate and responsive abuse contacts would be a critical tool in hand to quickly resolve this kind of issues.

The discussions over the incident also raised questions about policies and RSA compliance.

Policy-wise where do we stand ?

- an Abuse contact proposal was introduced in August 2018 and has been opposed

 -an AS0 ROA proposal introduced in November last year, which is meant to protect against hijacking of unallocated prefixes in Afrinic free pools and to encourage the same for members unused space was also opposed. You may have remembered the saga of the appeal against co-chairs decision of no- consensus after last the recent call period of this proposal

- a review of INRs usage proposal was submitted in May 2016 and was also opposed. The WG failed to design a consensual version

  - a policy compliance proposal has been submitted recently and we wait to see what will happen

RPD archives and PPMs notes give enough information on the discussions around these proposals.

While we wait for new proposals which will probably come from the current discussions, shouldn’t we revive and fix what went wrong with these proposals?

We knew that the post IPv4 exhaustion period will be delicate and supposed to be prepared for it.

Every little improvement we add to the infrastructure shall be welcome

Hope this helps

-Alain


> On 26 May 2020, at 20:34, Mike Silber <silber.mike at gmail.com> wrote:

> 

> Thanks Anthony 

> 

> In response to several other comments as well - 

> 

> I appreciate Mark Tinka raising this issue

> this sordid tale seems to have more than one side

> I do not believe I (or possibly anyone else on this list) is able to pass judgement on this particular incident - as we lack all of the relevant facts or technical or legal background, or have conflicts.

> 

> However there may be some useful learning from this incident and the need for new policies, revision to existing policies or better enforcement of policies.

> 

> Rather than debate if this was a personal attack (or not), or out of scope of the RPD list (or not), let us try bring this back to the purpose of this list - a discussion of AfriNIC’s policy environment.

> 

> Can someone please extrapolate from this regrettable incident what *policy* changes (or implementation changes) are required? If possible with some analysis of whether the consequences thereof are justified to prevent the harm being sought to be addressed.

> 

> Regards

> 

> Mike

> 

>> On 26 May 2020, at 20:03, Anthony Ubah <ubah.tonyiyke at gmail.com <mailto:ubah.tonyiyke at gmail.com>> wrote:

>> 

>> I feel this is gradually brewing up and steering up an unnecessary tension within the community.

>> 

>> I took time to go through the trail, the post shared by the CEO of Cloud Innovation contained a email by IPDC in which they have already openly apologized for their mistake(s).

>> 

>> On the other hand, heaping all blame on Cloud Innovation isn’t totally logical.

>> 

>> From my understanding, IPDC hijacked SEACOM’s ASN, IPDC being Cloud Innovation’s customer. However, I don’t clearly see what role it plays in the whole process. Predict ing it’s customer’s behaviour is scarcely possible, hardly any company can. Also is the company in the position/business to care of it per se, and without violation of privacy?

>> 

>> A typical example is a Kitchenware store; If the store sells a knife to an individual, and the individual uses the same knife to commit a crime, would the hardware store also be held partly accountable for the crime?

>> 

>> Thus, whatever the problem is IPDC should settle its differences directly with SEACOM

>> 

>> 

>> 

>> Best Regards,

>> 

>> Anthony

>> 

>> E-mail: anthony.ubah at goldspine.com <mailto:anthony.ubah at gloworld.com>.ng

>> 

>> 

> Snip

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20200603/890b8873/attachment.html>