Tom, thanks. I forget to mention the problem of this case ( AS 10 creates an ROA for X.X.X.X/24 , maxLength 28). Security-wise, this may actually be the worst solution: 
- An attacker can abuse this ROA to perform origin-hijack of the /28 subprefix, just like the origin hijack if AS 10 publishes ROA for the /28
- The max-length also allows similar origin-hijack of `intermediate prefixes' (e.g., /25), which may be allowed by ASes which will not allow /28, so there may be an even higher chance for the attacker to succeed in attracting traffic.

Of course, this is basically what is discussed in the `maxlength considered harmful' paper and RFC (RFC 9319), nothing really new here. 

Best, Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut
`Applied Introduction to Cryptography' textbook and lectures:https://sites.google.com/site/amirherzberg/cybersecurity




On Mon, Jan 30, 2023 at 9:39 AM Tom Beecher <beecher@beecher.cc> wrote:
- 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. 

AS 10 creates an ROA for X.X.X.X/24 , maxLength 28. This means AS10 can announce any /28 in that /24, and any validator should return valid. (This ignores if the longer than /24s would be accepted by policy or not. ) 

On Mon, Jan 30, 2023 at 9:19 AM Amir Herzberg <amir.lists@gmail.com> wrote:
Thanks to Lars for this interesting input and results (which I wasn't familiar with). 

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:

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

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

Just a thought... Amir
--
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut
`Applied Introduction to Cryptography' textbook and lectures:https://sites.google.com/site/amirherzberg/cybersecurity




On Wed, Jan 25, 2023 at 1:17 PM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:

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

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

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.

Best regards,
Lars

[1] https://blog.apnic.net/2022/09/01/measuring-hyper-specific-prefixes-in-the-wild/
[2] https://dl.acm.org/doi/pdf/10.1145/3544912.3544916
[3] https://www.gin.ntt.net/support-center/policies-procedures/routing/


On 25.01.23 05:12, Forrest Christian (List Account) wrote:
I have two thoughts in relation to this:

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.

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

And yes. I know #2 is precluded from actually ever happening because of #1.   The irony is not lost on me.


On Tue, Jan 24, 2023, 7:54 PM John Levine <johnl@iecc.com> wrote:
It appears that Chris J. Ruschmann <chris@scsalaska.net> said:
>-=-=-=-=-=-
>How do you plan on getting rid of all the filters that don’t accept anything less than a /24?
>
>In all seriousness If I have these, I’d imagine everyone else does too.

Right. Since the Internet has no settlements, there is no way to
persuade a network of whom you are not a customer to accept your
announcements if they don't want to, and even for the largest
networks, that is 99% of the other networks in the world. So no,
they're not going to accept your /25 no matter how deeply you believe
that they should.

I'm kind of surprised that we haven't seen pushback against sloppily
disaggregated announcements.  It is my impression that the route table
would be appreciably smaller if a few networks combined adjacent a
bunch of /24's into larger blocks.

R's,
John