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
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
