[arin-ppml] RPKI for Reallocations

[Richard Laager]

On 2023-06-23 12:03, August Yang via ARIN-PPML wrote:
> It's worth noting that this issue primarily stems from technical 
> constraints of the hosted RPKI implementation, rather than being a 
> direct policy matter related to NRPM.

Intentionally provocative, but semi-serious: can we use policy to force 
ARIN to fix their technical implementation?

When this has been brought up to them (by me, and others), they make 
sympathetic noises, but it's never actually been implemented.

That said, I did just now make this a written suggestion through the 
ARIN Consultation and Suggestion Process per an off-list email from an 
ARIN staffer.

For "Value to the Community", I wrote:


----

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

----

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20230623/b785eaca/attachment.htm>