<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div>On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com">baldur.norddahl@gmail.com</a>> wrote:<br></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg <<a href="mailto:amir.lists@gmail.com" target="_blank">amir.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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. <br></div></div></div></div></div></div><div class="gmail_quote"><div><br></div><div>I don't think A would be right to filter these packets to <a href="http://10.0.1.0/24" target="_blank">10.0.1.0/24</a>; A has announced <a href="http://10.0.0.0/16" target="_blank">10.0.0.0/16</a> so should route to that (entire) prefix, or A is misleading its peers. </div></div></div></blockquote><div><br></div><div>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?</div></div></div></blockquote><div><br></div><div>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, <a href="http://0.0.0.0/0">0.0.0.0/0</a>). 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:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>exactly; but this is since you incorrectly dropped the subprefix announcement which you evidently received from one of your providers. </div><div><br></div><div>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 :)  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>No way, agreed! </div><div><br></div><div>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!</div><div><br></div><div>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). </div><div><br></div><div>Regards, </div><div>--<br><div>Amir Herzberg<br></div><div><br></div><div>Comcast professor of Security Innovations, Computer Science and Engineering, University of Connecticut</div><div>Homepage: <a href="https://sites.google.com/site/amirherzberg/home" target="_blank">https://sites.google.com/site/amirherzberg/home</a></div><div>`Applied Introduction to Cryptography' textbook and lectures:<a href="https://sites.google.com/site/amirherzberg/applied-crypto-textbook" target="_blank"> https://sites.google.com/site/amirherzberg/applied-crypto-textbook</a></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>