"Tactical" /24 announcements

Fri Aug 13 20:52:56 UTC 2021

On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl <baldur.norddahl at gmail.com>
wrote:

>
> On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg <amir.lists at gmail.com>
> wrote:
>
>> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl <
>> baldur.norddahl at gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg <amir.lists at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210813/1bd0ffbd/attachment.html>