<div dir="ltr"><div dir="ltr">Thanks to Lars for this interesting input and results (which I wasn't familiar with). </div><div dir="ltr"><br></div><div dir="ltr">I want to mention another concern with the possible use of hyper-specific IP prefixes, i.e., longer than /24, which I haven't seen discussed in the thread (maybe I missed it?). Namely, if you allow say /28 announcements, then what would be the impact of ROV? Seems this can cause few problems:</div><div dir="ltr"><br></div><div>- If origin, say AS 10, makes a ROA for the /28, this would allow an attacker, e.g., AS 666, to do origin-hijack (announce path 666-10 to the /28), and attract traffic for the /28 from anybody accepting /28 announcements (that didn't receive the legit announcement). Plus, of course, you get more overhead in ROA distribution and validation. </div><div><br></div><div>- If origin makes a ROA only for covering prefix (say /24) then the /28 announcement would be considered invalid by ROV and (even more likely) dropped. Also you get more instances of `invalid' announcements, making adoption of ROVs and ROAs harder. </div><div><br></div><div>Just a thought... Amir</div><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr">-- <br><div>Amir Herzberg<br></div><div><br></div><div>Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut</div><div>Homepage: <a href="https://sites.google.com/site/amirherzberg/home" target="_blank">https://sites.google.com/site/amirherzberg/home</a></div><div>`Applied Introduction to Cryptography' textbook and lectures:<a href="https://sites.google.com/site/amirherzberg/cybersecurity" target="_blank">https://sites.google.com/site/amirherzberg/cybersecurity</a></div><div><br></div><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn <<a href="mailto:lprehn@mpi-inf.mpg.de">lprehn@mpi-inf.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>We performed some high-level analyses on these hyper-specific
prefixes about a year ago and pushed some insights into a blog
post [1] and a paper [2].<br>
<br>
While not many ASes redistribute these prefixes, some accept and
use them for their internal routing (e.g., NTT's IPv4 filtering
policy [3]). Rob already pointed out that this is often sufficient
for many traffic engineering tasks. In the remaining scenarios,
announcing a covering /24 and hyper-specific prefixes may result
in some traffic engineering, even if the predictability of the
routing impact is closer to path prepending than usual
more-specific announcements. In contrast to John's claim, some
transit ASes explicitly enabled redistributions of up to /28s for
their customers upon request (at least, they told us so during
interviews).<br>
<br>
Accepting and globally redistributing all hyper-specifics
increases the routing table size by >100K routes (according to
what route collectors see). There are also about 2-4
de-aggregation events every year in which some origin
(accidentally) leaks some large number of hyper-specifics to its
neighbours for a short time. <br>
<br>
Best regards, <br>
Lars <br>
<br>
[1]
<a href="https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/" target="_blank">https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/</a><br>
[2] <a href="https://dl.acm.org/doi/pdf/10.1145/3544912.3544916" target="_blank">https://dl.acm.org/doi/pdf/10.1145/3544912.3544916</a><br>
[3]
<a href="https://www.gin.ntt.net/support-center/policies-procedures/routing/" target="_blank">https://www.gin.ntt.net/support-center/policies-procedures/routing/</a><br>
<br>
<br>
</p>
<div>On 25.01.23 05:12, Forrest Christian
(List Account) wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">I have two thoughts in relation to this:<br>
<div dir="auto"><br>
</div>
<div dir="auto">1) It's amazing how many threads end up ending
in the (correct) summary that making an even minor global
change to the way the internet works and/or is configured to
enable some potentially useful feature isn't likely to happen.</div>
<div dir="auto"><br>
</div>
<div dir="auto">2) I'd really like to be able to tag a BGP
announcement with "only use this announcement as an absolute
last resort" so I don't have to break my prefixes in half in
those cases where I have a backup path that needs to only be
used as a last resort. (Today each prefix I have to do this
with results in 3 prefixes in the table where one would do).</div>
<div dir="auto"><br>
</div>
<div dir="auto">And yes. I know #2 is precluded from actually
ever happening because of #1. The irony is not lost on me.</div>
<br>
<br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Tue, Jan 24, 2023, 7:54
PM John Levine <<a href="mailto:johnl@iecc.com" target="_blank">johnl@iecc.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It appears
that Chris J. Ruschmann <<a href="mailto:chris@scsalaska.net" rel="noreferrer" target="_blank">chris@scsalaska.net</a>>
said:<br>
>-=-=-=-=-=-<br>
>How do you plan on getting rid of all the filters that
don’t accept anything less than a /24?<br>
><br>
>In all seriousness If I have these, I’d imagine everyone
else does too.<br>
<br>
Right. Since the Internet has no settlements, there is no
way to<br>
persuade a network of whom you are not a customer to accept
your<br>
announcements if they don't want to, and even for the
largest<br>
networks, that is 99% of the other networks in the world. So
no,<br>
they're not going to accept your /25 no matter how deeply
you believe<br>
that they should.<br>
<br>
I'm kind of surprised that we haven't seen pushback against
sloppily<br>
disaggregated announcements. It is my impression that the
route table<br>
would be appreciably smaller if a few networks combined
adjacent a<br>
bunch of /24's into larger blocks.<br>
<br>
R's,<br>
John<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote></div></div>