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

Mon Jan 30 15:43:45 UTC 2023

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 <beecher at 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 at 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 at 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 at iecc.com> wrote:
>>>
>>>> It appears that Chris J. Ruschmann <chris at 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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230130/f5a6c939/attachment.html>