On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <baldur.nordd...@gmail.com> wrote:
> > > On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg <amir.li...@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> >
