Re: ROV concern for hyper-specific prefixes (renamed from `Re: Smaller than a /24 for BGP?')

[Tom Beecher <beecher () beecher cc>]

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