"Tactical" /24 announcements

Amir Herzberg amir.lists at gmail.com
Fri Aug 13 01:54:24 UTC 2021

On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <baldur.norddahl at gmail.com>

> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg <amir.lists at gmail.com>
> wrote:
>> Bill, I beg to respectfully differ, knowing that I'm just a researcher
>> and working `for real' like you guys, so pls take no offence.
>> I don't think A would be right to filter these packets to; A
>> has announced so should route to that (entire) prefix, or A
>> is misleading its peers.
> You are right that it is wrong but it happens. Some years back I tried a
> setup where we wanted to reduce the size of the routing table. We dropped
> everything but routes received from peers and added a default to one of our
> IP transit providers. This should have been ok because either we had a
> route to a peer or the packet would go to someone who had the full routing
> table, yes?

Baldur, thanks, but, sorry, this isn't the same, or I miss something. If I
get you right, you dropped all announcements from _providers_ except making
one provider your default gateway (essentially, But this is
very different from what I understood from what Bill wrote. Your change
could (and, from what you say next, did) cause a problem if one of these
announcements you dropped from providers was a legit subprefix of a prefix
announced by one of your peers, causing you to route to the peer traffic
whose destination is in the subprefix. But let me be concrete using what
you wrote:

> So we got complaints. One was a company who would advertise a /20 on a
> peering with us. But somewhere else far away they had a site from where
> they would announce a /24 from the same prefix. With no internal routing
> between the peering site with the /20 to the other site with the /24. We
> therefore lost the ability to communicate with that /24.

exactly; but this is since you incorrectly dropped the subprefix
announcement which you evidently received from one of your providers.

If this analysis is correct, you could have solved the problem - reducing
the FIB while avoiding such loss of connectivity - if you retained (only)
the announcements from your providers which were to subprefixes of
announcements you got from your peers. A bit of scripting required, of
course... I'm sure you can do it 100 times faster and better than me :)

> You see variants of this. For example a large telco has a /16 from which
> they many years ago allocated a /24 to a multihomed customer. This customer
> left but took their /24 with them. This fact will seldom make the large
> telco split up their /16. They will keep it as a /16 but will no longer
> route to that /24. The question is also if we really would want a large
> telco to explode a large subnet due to this case.

No way, agreed!

But, as I explained, it's also unnecessary; I mean, that's exactly why we
do `most specific' routing. Just don't kill the subprefix announcement!

btw... yes, this is a possible issue with ROV, when sometimes there's a ROA
for a prefix (say /16) but no roa to a (legitimately announced) subprefix
(e.g. /20). We show such case in our 2015 ROV paper, and also measured how
many such issues exist; it appears their number is much reduced now, based
on more recent measurements. (ah and here, our ROV++ doesn't help; in fact,
it would disconnection even more likely than with ROV, since ROV protection
against subprefix hijacks is rather weak).

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:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210812/2c9c6514/attachment.html>

More information about the NANOG mailing list