"Tactical" /24 announcements

Fri Aug 13 01:54:24 UTC 2021

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

>
>
> 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 10.0.1.0/24; A
>> has announced 10.0.0.0/16 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, 0.0.0.0/0). 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).

Regards,
--
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/applied-crypto-textbook
<https://sites.google.com/site/amirherzberg/applied-crypto-textbook>

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