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 Homepage: https://sites.google.com/site/amirherzberg/home `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 <beec...@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.li...@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 >> Homepage: https://sites.google.com/site/amirherzberg/home >> `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 <lpr...@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 <jo...@iecc.com> wrote: >>> >>>> It appears that Chris J. Ruschmann <ch...@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 >>>> >>>
