<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>