Re: "Tactical" /24 announcements

[Baldur Norddahl <baldur.norddahl () gmail com>]

On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg <amir.lists () gmail com> wrote:

> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <baldur.norddahl () gmail com>
> wrote:
>
> > On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg <amir.lists () 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!)


> 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.

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. 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.

Regards,

Baldur