A new response from ARIN has been posted for the following suggestions, and these suggestions are now closed. You may find the original suggestions and the responses from ARIN below.
2023.08: Allow Customers with reallocated resources to create ROAs 2023.09: Require ARIN Online account to view Points of Contact in Whois Regards, American Registry for Internet Numbers (ARIN) ----------- 2023.08: Allow Customers with reallocated resources to create ROAs https://www.arin.net/participate/community/acsp/suggestions/2023/2023-08/ Author: Anonymous Description: Hosted RPKI should allow holders of reallocated resources (with an ARIN OrgID) to create ROAs for those resources, rather than requiring them to ask the direct resource holder to create the ROAs. Value to Community: It would be easier for networks with reallocated IP space to implement RPKI. They would not need to reach out to their upstream IP resource holder. I realize that seems simple, but sometimes things are complicated in the real world. Even in the best case where the upstream resource holder is clueful, agreeable, and responsive, being able to do it directly saves time and effort. But sometimes things are even more complicated. - There has been merger/divesture activity, so the upstream resource holder is no longer someone with whom the downstream resource holder has a related contract. - The downstream resource holder is afraid that drawing attention to it will result in the upstream resource holder revoking the space. For example, maybe the downstream resource holder is no longer a customer of the upstream resource holder, has not been for a decade, and the IP space may have been obtained at a time when it was unclear whether the downstream resource holder was expected to return the space. (Related — I’m told, but have not verified, that at one time ARIN Policy REQUIRED small ISPs to get their space from their upstream ISP, which is how they ended up in this position.) - The upstream resource holder doesn’t see RPKI as a priority. These are not hypotheticals, but actual things I am directly aware of (not necessarily for me personally). This is even more important for RPKI than other things (e.g. reverse DNS delegations), for at least two reasons — 1. If the upstream resource holder creates a ROA for the parent allocation that doesn’t properly cover the downstream announcements, the downstream resource holder’s space will NO LONGER BE ROUTABLE (via networks that do RPKI validation). This means that RPKI plus reallocated space place downstream resource holders in a potentially dangerous position. They may very well want to mitigate this risk by publishing proper ROAs, but they cannot. 2. If the downstream resource holder is successful in getting the upstream resource holder to create a ROA at time T, they are potentially in a worse position than without ROAs at all — if something changes and the upstream provider is no longer agreeable at time T+N. For example, if the downstream resource holder needs to deaggregate an announcement, it will not be accepted (at places that do RPKI validation). This can be mitigated by the downstream resource holder asking for maxLength=24 (assuming IPv4) initially. However, there are other scenarios where maxLength=24 is not a solution. For example, imagine the downstream resource holder signs on to a DDoS Mitigation service that originates routes under attack from the DDoS Mitigation company’s ASN. (This is how my DDoS scrubbing provider operates, for example.) This would require a second ROA with the other ASN as the origin. Again, if the upstream provider is not responsive to this subsequent request, the downstream resource holder is in a bad spot. Another example would be if the downstream provider wants to further reallocate the space to another AS that will start originating that announcement. Or, imagine the space is already further allocated to someone who is not currently multihomed and they now want to multihome and start announcing the route themselves. This can act as a perverse incentive for the downstream resource holder to NOT want to do ROAs, because they might fear the upstream resource holder will not update the ROA when asked in the future. 1 + 2 = rock & hard place Status: Closed ARIN Comment: Thank you for your suggestion, numbered 2023.08 upon confirmed receipt, asking that ARIN allow customers with reallocated customers to create ROAs for their resources. We are investigating the options and implications for adding this functionality and will be presenting our recommendations to the community for consultation. We are closing your suggestion as referred to community consultation. Thank you for participating in the ARIN Consultation and Suggestion Process. ----------------- 2023.09: Require ARIN Online account to view Points of Contact in Whois https://www.arin.net/participate/community/acsp/suggestions/2023/2023-09/ Author: Sam Dibrell Description: Protect POC contacts from harvesting and abuse by malicious third parties Protecting ARIN POC email addresses from harvesting by malicious third parties can be accomplished by requiring an ARIN user account to view the POC email address. Logging of POC email address views can then provide insight as to which user accounts are harvesting large amounts of contact information. Making logs available to POCs of registered users which viewed POC contact information, when cross referenced to malicious email campaigns to POC email addresses, can assist in identifying malicious users. Requiring an ARIN account adds an initial layer of protection, as it moves the bar closer to only authorized individuals with legitimate reasons accessing POC email addresses. However, if this step alone doesn’t effectively deter harvesting practices, providing access logs to POC contact information can serve as an additional deterrent. These logs would allow POCs to monitor and track which user account accessed POC contact information, creating accountability and discouraging improper use. By combining these measures, ARIN strengthens the security of POC email addresses and increases the transparency and traceability of interactions, thereby reducing the risk of harvesting by malicious entities and enhancing overall privacy and protection for the ARIN community. Value to Community: Protecting point of contact (POC) email addresses from being harvested and exploited by spammers and scammers is of immense value to the ARIN community. By implementing protective measures, ARIN reduces the bandwidth and resource loss caused by spam and scams. Email harvesting techniques employed by malicious actors lead to an influx of unsolicited emails, spam, phishing attempts, and fraudulent activities. This not only consumes valuable network bandwidth but also wastes resources, including time and effort, in dealing with and mitigating these threats. By safeguarding POC email addresses, ARIN ensures that its members can allocate their resources efficiently, focus on legitimate activities, and maintain a secure and productive Internet environment. Status: Closed ARIN Comment: Thank you for your suggestion, numbered 2023.09 on confirmed receipt, asking that ARIN require an ARIN Online account to view Point of Contact data in Whois to eliminate harvesting by malicious third-parties. While we understand that the data in the ARIN Whois system can be a target for bad actors, it also has legitimate use by network operators, law enforcement, anti-abuse, and cybersecurity operators in enabling timely Internet operations globally – and consequentially, is relied upon by many parties unlikely to have ARIN Online accounts and who access ARIN Whois data through a wide variety of methods. Because of the legitimate public utility of the ARIN Whois system (and the ability of organizations to control the information they choose to be shared publicly via their Point-of-Contact data), ARIN will not implement the proposed restriction to access this information and this suggestion will be closed. If you are experiencing difficulties with misuse of your published Point of Contact data in the ARIN Whois system, it is recommended that you switch to unique emails for this purpose and report misuse of your Whois data (violations of the ARIN’s Whois Terms of Use) to ARIN by sending email to [email protected]. ARIN does investigate and pursue parties that engage in clear misuse of ARIN Whois data. Thank you for participating in the ARIN Consultation and Suggestion process. _______________________________________________ arin-suggestions mailing list [email protected] https://lists.arin.net/mailman/listinfo/arin-suggestions
