On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl <baldur.nordd...@gmail.com> wrote:
> > On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg <amir.li...@gmail.com> > wrote: > >> 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. >> > > 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!) > I think it isn't the same. This scenario, of an AS selling part of its IP block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g., 10.0.0.0/16, 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 10.0.0.0/16; if 10.0.1.0/24 is reachable, traffic will route to it anyway due to `more specific', so no problem; and if 10.0.1.0/24 isn't reachable, then anyway no harm done... By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited example, did - break connectivity, imho. And quite unnecessarily, too. > > >> 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. >> > > 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. > Was not a lie, as I explained. > > 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. > 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! Unfortunately and stupidly, I didn't save these sources, but I did a quick google now and found https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf But that was years ago, and indeed, I also found mention in RFC 7454: > 6.1.3 <https://www.rfc-editor.org/rfc/rfc7454.html#section-6.1.3>. Prefixes > That Are Too Specific > > 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 [20 > <https://www.rfc-editor.org/rfc/rfc7454.html#ref-20>] [21 > <https://www.rfc-editor.org/rfc/rfc7454.html#ref-21>]. > These values may change in the future. > > I also did an experiment that seemed to confirm that most ISPs filter announcements more specific than /24. 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. 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. > 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. > Not a lie, but yes, this will lead to loss of connectivity; hence, it's important to standardize this. > > Regards, > > Baldur > >
