[rpd] Policy Impact

[Owen DeLong]

> On  3 June 2020, at 21:06, Alain Aina wrote:

> 

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


First, calling it a hijacking really isn’t appropriate. It was an erroneous configuration and accidental misuse of an ASN, but there was no abuse. No harmful traffic was emitted from the addresses in question, no traffic disrupted, just a lot of noise about a very minor error.

Upon discovery, the error was corrected very quickly.


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


ROAs might have helped here and we are planning to deploy ROAs for all future LOAs. Development of the systems necessary to facilitate that process is ongoing as I write this.

In order for ROAs to have helped, the upstream providers would need to have done ROV. Of course, given that Seacom left stale route objects in the IRR, it’s just as likely they would have left stale ROAs sitting in the database which would have rendered any ability for RPKI to address this event useless.


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


Perhaps. Perhaps not. All of these systems still depend on proper configuration. The same things that led to this error could just have easily led to configuration errors in those other systems as well.


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


Hard to say, really. But this really has nothing to do with RIR resource policy at this point. The policies to enable this are already present. The fact that the market has not chosen to adopt this supposed solution is not a policy matter.


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


There was no problem contacting the parties in question and had Mark reached out to the registered contacts on the resources (vs. publicly posting a tirade without the facts), it would have been promptly addressed without all the fanfare. It was promptly addressed once the matter was communicated.


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


Really? What questions were those? No RSA violation occurred. No policy violation occurred.


> Policy-wise where do we stand ?

> 

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


Yes… It failed to gain consensus because of multiple flaws that were pointed out. That’s how the process is supposed to work.


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


This one was a narrow judgment call by the co-chairs. While I still don’t agree with their decision, I cannot say in good conscience that it was an invalid conclusion. People of good conscience can arrive at different answers legitimately even when presented with the same record. This is such a case. The policy will be reviewed again at the next meeting and I expect it will achieve consensus then. The open question here is when will said next meeting occur?


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


Right… There were multiple flaws with the proposal and many of the proposed fixes made it worse instead of better. Further, the proposal did not confer any new capabilities to AfriNIC, but attempted to weaponize AfriNIC staff against large providers in a kind of RIR political DDOS.

The community rightly saw this for what it was and rejected it.

Again, that’s how the process is supposed to work.


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


You’ll need to be more specific here… Can you link the text of what you are calling a “policy compliance proposal”?

In general, I find the recursion inherent in such a concept amusing… “A policy that requires you to comply with policies.”???


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


You’d first have to show me what went wrong. From my perspective, the process worked as intended and proposals that you liked, but a significant fraction of the community did not were abandoned without achieving consensus.
That’s a perfectly legitimate outcome of the policy development process.


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


Actually, I think that the post IPv4 exhaustion period will be more like the wild west than “delicate”. I think it will be harsh, dog eat dog, and expensive. I think it will be disruptive and that the continuing escalation of costs and declining functionality of IPv4 due to its limited address space will cause a great deal of difficulty. I don’t see anything delicate about it.


> Every little improvement we add to the infrastructure shall be welcome


If you want to improve the infrastructure, post on a NOG list, that’s their focus. Here, on this list, it’s about the fair and objective administration of IP number resources through open and transparent community-driven process.

Please, let us now return to the discussion of number resource policies.

Owen