<div dir="ltr">Tom, I also referred to the same text from 7454! But Baldur is right: the text does NOT clearly state that announcement more specific than /24 should be filtered. <div><br></div><div>If you allow different operators to filter at different lengths, you can get disconnections. We never like to standards to be fixed to some number, but this seems necessary (to me). <br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr">-- <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><br></div><br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 13, 2021 at 5:05 PM Tom Beecher <beecher@beecher.cc> 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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think that the NANOG (or in general, operators) community may do well to state the `/24 rule' clearly in a BCP, preferably an RFC.<br></blockquote><div><br></div><div><a href="https://datatracker.ietf.org/doc/html/rfc7454" target="_blank">https://datatracker.ietf.org/doc/html/rfc7454</a></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="display:inline;font-size:1em;font-weight:bold"><a id="gmail-m_-6480958841388061185gmail-section-6.1.3" href="https://datatracker.ietf.org/doc/html/rfc7454#section-6.1.3" target="_blank">6.1.3</a>. Prefixes That Are Too Specific<br></span>
Most ISPs will not accept advertisements beyond a certain level of<br> specificity (and in return, they do not announce prefixes they<br> consider to be too specific). That acceptable specificity is decided<br> for each peering between the two BGP peers. Some ISP communities<br> have tried to document acceptable specificity. This document does<br> not make any judgement on what the best approach is, it just notes<br> that there are existing practices on the Internet and recommends that<br> the reader refer to them. As an example, the RIPE community has<br> documented that, at the time of writing of this document, IPv4<br> prefixes longer than /24 and IPv6 prefixes longer than /48 are<br> generally neither announced nor accepted in the Internet [<a href="https://datatracker.ietf.org/doc/html/rfc7454#ref-20" title=""RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation"" target="_blank">20</a>] [<a href="https://datatracker.ietf.org/doc/html/rfc7454#ref-21" title=""RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation"" target="_blank">21</a>]. <br><span style="color:rgb(0,0,0);font-size:13.3333px"> These values may change in the future.</span> </blockquote></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 13, 2021 at 4:54 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">On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com" target="_blank">baldur.norddahl@gmail.com</a>> wrote:<br></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><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 13, 2021 at 3:54 AM 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>On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com" target="_blank">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. </div></div></div></blockquote><div><br></div><div>I think it is exactly the same? Our peer is advertising a prefix for which they will not route all addresses covered. Is that route not then a lie? Should they not have exploded the prefix so they could avoid covering the part of the prefix they will not accept traffic to? (ps: not arguing they should!)</div></div></div></blockquote><div><br></div><div>I think it isn't the same. This scenario, of an AS selling part of its IP block, e.g., <a href="http://10.0.1.0/24" target="_blank">10.0.1.0/24</a>, and continuing to announce the block, e.g., <a href="http://10.0.0.0/16" target="_blank">10.0.0.0/16</a>, is the classical example used (e.g. by me) to explain the `most specific' rule. Due to `most specific', it is considered, imho, legit to continue to announce <a href="http://10.0.0.0/16" target="_blank">10.0.0.0/16</a>; if <a href="http://10.0.1.0/24" target="_blank">10.0.1.0/24</a> is reachable, traffic will route to it anyway due to `more specific', so no problem; and if <a href="http://10.0.1.0/24" target="_blank">10.0.1.0/24</a> isn't reachable, then anyway no harm done...</div><div><br></div><div>By dropping a legit <a href="http://10.0.1.0/24" target="_blank">10.0.1.0/24</a> announcement, you may - and in the cited example, did - break connectivity, imho. And quite unnecessarily, too. </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> </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>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" target="_blank">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. </div></div></div></blockquote><div><br></div><div>Your understanding is correct. But this is just the way we ended up in that situation. Does not change the fact that we got a route from a peer that we believed we could use, but turns out part of that announcement was a lie.</div></div></div></blockquote><div><br></div><div>Was not a lie, as I explained. </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>Consider that everyone filters received routes. The most common is to filter at the /24 level but nowhere is there a RFC stating that /24 is anything special. </div></div></div></blockquote><div><br></div><div>Oh that's a point I was quite annoyed with for years - who said one should drop prefixes longer than /24 ??? And I searched for it, and indeed found no RFC. But I did find it mentioned in some BCPs!</div><div>Unfortunately and stupidly, I didn't save these sources, but I did a quick google now and found</div><div><br></div><div><a href="https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf" target="_blank">https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf</a><br></div><div><br></div><div>But that was years ago, and indeed, I also found mention in RFC 7454:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span style="line-height:0pt;display:inline;font-size:1em;font-weight:bold"><a id="gmail-m_-6480958841388061185gmail-m_8914162575914262881gmail-section-6.1.3" href="https://www.rfc-editor.org/rfc/rfc7454.html#section-6.1.3" style="color:black;text-decoration-line:none" target="_blank"><br>6.1.3</a>. Prefixes That Are Too Specific</span>
Most ISPs will not accept advertisements beyond a certain level of
specificity (and in return, they do not announce prefixes they
consider to be too specific). That acceptable specificity is decided
for each peering between the two BGP peers. Some ISP communities
have tried to document acceptable specificity. This document does
not make any judgement on what the best approach is, it just notes
that there are existing practices on the Internet and recommends that
the reader refer to them. As an example, the RIPE community has
documented that, at the time of writing of this document, IPv4
prefixes longer than /24 and IPv6 prefixes longer than /48 are
generally neither announced nor accepted in the Internet [<a href="https://www.rfc-editor.org/rfc/rfc7454.html#ref-20" title=""RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation"" target="_blank">20</a>] [<a href="https://www.rfc-editor.org/rfc/rfc7454.html#ref-21" title=""RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation"" target="_blank">21</a>].
These values may change in the future.</pre></blockquote><div><br></div><div>I also did an experiment that seemed to confirm that most ISPs filter announcements more specific than /24. </div><div><br></div><div>I think that the NANOG (or in general, operators) community may do well to state the `/24 rule' clearly in a BCP, preferably an RFC. A mismatch in the most-specific rule can definitely allow different problems (and attacks). As mentioned above, RIPE has essentially done this (although could be more explicit). I've seen a similar /48 rule for IPv6, btw. </div><div><br></div><div>Theoretically, universal adoption of RPKI (incl ROV) could provide an alternative solution to the disconnections, but will not protect against explosion of the routing tables. </div><div> </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>So what if I was to filter at a different level, say /20 ? The same thing would happen, we would drop the "/24 exception route" and use the route that is a lie.</div></div></div></blockquote><div><br></div><div>Not a lie, but yes, this will lead to loss of connectivity; hence, it's important to standardize this. </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>Regards,</div><div><br></div><div>Baldur</div><div><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 class="gmail_quote"><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>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>