From info at arin.net Wed Jun 7 14:38:41 2023 From: info at arin.net (ARIN) Date: Wed, 07 Jun 2023 14:38:41 -0400 Subject: [ARIN-Suggestions] ACSP Suggestion 2021.10 Closed Message-ID: The following suggestion has been marked as completed: ACSP Suggestion 2021.10: API Enhancement to Return RPKI roaHandle https://www.arin.net/participate/community/acsp/suggestions/2021/2021-10/ ARIN Response: Thank you for your suggestion, numbered 2021.10 on confirmed receipt, asking that we develop an API Enhancement to return the Resource Public Key Infrastructure (RPKI) roaHandle. Development of this functionality was released with a new RESTful API on 13 May 2023. Because this work is completed, we are closing this suggestion. Thank you for participating in the ARIN Consultation and Suggestion Process. Regards, American Registry for Internet Numbers (ARIN) From info at arin.net Tue Jun 27 16:50:59 2023 From: info at arin.net (ARIN) Date: Tue, 27 Jun 2023 16:50:59 -0400 Subject: [ARIN-Suggestions] New ACSP Suggestion Received Message-ID: One new suggestion has been received (2023.8). You may find the new suggestion and link in full below. Regards, American Registry for Internet Numbers (ARIN) --------- ACSP Suggestion 2023.8: 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 Timeframe: Not specified Status: Confirmed