[ARIN-Suggestions] New ACSP Suggestion Received

[ARIN]

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