[rpd] New Policy Proposal Received - "Provisions for Resource Hijacking (AFPUB-2019-GEN-001-DRAFT01)"

Wed May 29 06:48:27 UTC 2019

> On May 26, 2019, at 14:40 , JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:
> 
> Hi Owen,
>  
> Let’s state this again. The proposal doesn’t intent to say the operators how to operate their routers.
>  
> The proposal simply states that if an AFRINIC member is granted with uniqueness, as you stated below, other members can’t jump over that.

AfriNIC member is granted with Uniqueness in the registry. I don’t see how another member could possibly “jump over that” without the complicit action of the registry.

As such, that’s a problem that doesn’t exist and therefore doesn’t require a solution in policy.

OTOH, AfriNIC member is not granted (by AfrINIC) uniqueness anywhere else. Any uniqueness granted in the routing system comes from the people who run routers. Again, fortunately for all concerned, the vast majority of those running routers choose to cooperate with the registry system and there is much rejoicing.
>  
> The resources are for exclusive use of the members that got them allocated, under the prescriptions of our rules (the policies). If I’m AFRINIC member, I can’t use other members resources (unless explicitly authorized to by the resource holder).

I suppose we can make that policy, but, here’s the thing…

1.	That is telling people how to run routers. You’re now saying that by AfriNIC policy, we not only register
	number resources for uniqueness, but we restrict members from configuring their routers in such a way
	as to interfere with the use of another members’ resources.

2.	Such a policy moves the RIR from being a registry that records information for voluntary coordination among
	members of the community to being an organization that attempts to impose its will on the business and/or
	operational practices of members.

I suppose neither of those things is necessarily all that problematic (though I think there are pitfalls there), but even if they were completely benign, there’s the issue that the vast majority of events where some party is publicly advertising number resources registered to someone else are cases where the advertising (unregistered) party is NOT A MEMBER of an RIR and therefore not subject to the proposed policy anyway.

> This is a very basic rule of ANY membership organization: Respect the other members and whatever products/rights/services are provided to them. Members not respecting other members at a minimum should be warned about that, and if they persist, there must be consequences.

Can you point to an example where such an event has happened within the AfriNIC region? (Or even outside of the RIPE region)?

> The decision to use a RIR or another is not voluntary, is the only possible way. You must use the registry of your region (small differences here among regions that require or not using the resources in that region).

No, you can, in fact, buy a router without joining an RIR. You can, in fact, configure that router to announce prefixes into BGP without joining an RIR. In some cases, you can even find an ISP willing to accept your announcements (at least for a short time) without joining an RIR.

> Even if only a few hijacking is done by RIR members, and we can avoid that, the result will be good enough.

Well, that’s fine and dandy, but who gets to pay for the overhead of this new process for adding teeth to RIR uniqueness? Does it really avoid enough (even any) actual events such that the cost is worth it?

My inclination is that you are literally attempting create a solution to a problem which doesn’t actually exist in the wild outside of the RIPE region and that even within the RIPE region, the instances are quite few and far between.

Again, I’m not talking about all hijacking instances (those happen everywhere), but strictly the ones where the hijacker is an RIR member, the resources hijacked are not a misconfiguration or a billing or contract dispute, and the member in question refuses to correct the issue when it is brought to their attention.

(Since any event that doesn’t meet all of those requirements will not be prevented or in any way affected by this proposed policy).

Owen

> 
> Regards,
> Jordi
> 
>  
> 
>  
>  
> El 26/5/19 17:59, "Owen DeLong" <owen at delong.com <mailto:owen at delong.com>> escribió:
>  
> As I’ve stated in the other regions where the same authors have floated this, there are a number of fundamental errors in the understanding of the role of the RIR system underlying this proposal. 
>  
> It is apparently a common misconception that RIRs have some authority to grant “rights to use” number resources. That’s an easy mistake to make because the distinction is subtle, but in this context it becomes important. 
>  
> The registry system grants registration for uniqueness. Any right to use is granted not by the registry system, but by those who initiate, accept, and reannounce prefixes in routers. Thus, it is ISPs who control the right to use and not the registry. 
>  
> Fortunately, and to the tremendous benefit of all, the vast majority of ISPs choose to use the data in the RIR registry system as authoritative and base their grants of rights on it. This allows for a much more functional internet than if they each used competing and overlapping registry systems. However, the decision to use the RIR registry system is entirely voluntary on the part of each network operator. 
>  
> The vast majority of resource hijacking in the wild is not committed by RIR members. There seems to be some exception to this in the RIPE region. As such, this policy proposal is unlikely to impact the perpetrators and far more likely to harm the victims it purports to protect. 
>  
> I have tremendous respect for the authors and no doubt whatsoever that they mean well. However, the misconceptions underlying this policy prevent it from having any useful outcome. I would rate it risky, but possibly mostly harmless at best. 
>  
> Therefore, I do not support the proposal. 
>  
> Owen
>  
> 
> On May 26, 2019, at 07:48, haruna adoga <hartek66 at gmail.com <mailto:hartek66 at gmail.com>> wrote:
> 
>> I must start by saying the authors of this proposal have done a great job, considering the negative effect of resource (IPv4, IPv6, ASN) hijacking to our region.
>>  
>> I do believe that since operational errors such as mistakes in BGP configurations can lead to what might be perceived as a resource hijacking activity (policy violation), it is ideal that this proposal gives the suspected resource hijacker a reasonable  amount of time to explain their actions. 
>>  
>> The duration can be deliberated by the policy authors and other members. The suspected hijacker should be given a maximum of 6 weeks rather that 4 weeks to object any conclusions, as proposed by the authors. 
>>  
>> This will further clarify if the activity is an act of persistent intentional hijack or an operational error.
>>  
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>_______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com <http://www.theipv6company.com/>
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net <mailto:RPD at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190528/709d3718/attachment-0001.html>