RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

Wed Mar 8 14:09:47 UTC 2023

>
> That doesn't mean publically available blocklists need to misrepresent
> their use-case.
>
>
Respectfully, this is exceptionally ignorant.

Team Cymru is not misrepresenting anything. They are very specific and
detailed about which addresses the bogons and fullbogons lists contain.
They also clearly state that individual networks MAY need to make
adjustments based on their circumstances.

Team Cymru CEO, Rob Thomas, studied a frequently attacked website to
> discover that 60% of the bad packets were obvious bogons (e.g. 127.1.2.3,
> 0.5.4.3, etc.). Your mileage may vary, and you may opt to filter more
> conservatively or more liberally. As always, you must KNOW YOUR NETWORK to
> understand the effects of such filtering.
>
> Bogon filtering is a component of anti-spoofing filtering
>

> The concern is not about networks that know what they are doing, the
> concern is about the rest (and more specifically entities that don't
> operate their own ASN).
>

If someone is blindly filtering a list of prefixes from a 3rd party without
understanding what that list is, and why they are filtering with it, then
they are likely to transition from 'don't know what they are doing' to
'educated on the subject' soon enough.

On Wed, Mar 8, 2023 at 7:34 AM Lukas Tribus <lukas at ltri.eu> wrote:

> >> They talk about bogon prefixes "for hosts", provide configuration
> >> examples for Cisco ASA firewalls,
> >
> > Which are perfectly valid use cases for some networks / situations.
>
> Absolutely, everybody's free to drop whatever they like on their gear,
> I'm sure there are networks, gear, applied and documented
> configurations out there that block 1.1.1.0/24.
>
> That doesn't mean publically available blocklists need to misrepresent
> their use-case.
>
> The concern is not about networks that know what they are doing, the
> concern is about the rest (and more specifically entities that don't
> operate their own ASN).
>
> Thanks,
> Lukas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230308/2c187f5f/attachment.html>