"Tactical" /24 announcements

Fri Aug 13 21:04:51 UTC 2021

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

https://datatracker.ietf.org/doc/html/rfc7454

6.1.3 <https://datatracker.ietf.org/doc/html/rfc7454#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://datatracker.ietf.org/doc/html/rfc7454#ref-20>] [21
> <https://datatracker.ietf.org/doc/html/rfc7454#ref-21>].
>    These values may change in the future.

On Fri, Aug 13, 2021 at 4:54 PM Amir Herzberg <amir.lists at gmail.com> wrote:

> 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/9c8c2b6a/attachment.html>