<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2023-06-23 12:03, August Yang via
ARIN-PPML wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d256d210-beeb-ce4d-442b-a49cfda34f30@august.tw">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.</blockquote>
<p>Intentionally provocative, but semi-serious: can we use policy to
force ARIN to fix their technical implementation?</p>
<p>When this has been brought up to them (by me, and others), they
make sympathetic noises, but it's never actually been implemented.</p>
<p>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.</p>
<p>For "Value to the Community", I wrote:</p>
<p><br>
</p>
<p>----</p>
<p>It would be easier for networks with reallocated IP space to
implement RPKI.<br>
<br>
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:<br>
<br>
- 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.<br>
- 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.)<br>
- The upstream resource holder doesn't see RPKI as a priority.<br>
<br>
These are not hypotheticals, but actual things I am directly aware
of (not necessarily for me personally).<br>
<br>
This is even more important for RPKI than other things (e.g.
reverse DNS delegations), for at least two reasons:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
1 + 2 = rock & hard place</p>
<p>----<br>
</p>
<pre class="moz-signature" cols="72">--
Richard</pre>
</body>
</html>