Re: Proposal to apply mask to IP address set on rule

[Greg Troxel <gdt%lexort.com@localhost>]

Christoph Badura <bad%bsd.de@localhost> writes:

> On Sat, May 24, 2025 at 01:23:41PM +0200, Martin Neitzel wrote:
>> GT> So far nobody has given examples of actual misconfigurations that would
>> GT> benefit from warnings.
>> 
>> Let's firewall a subnet for 16 hosts -- QUICK!:
>> Is 192.168.33.136/28 on a /28 boundary or not?

I was trying to distinguish actual misconfigurations that actual people
have experienced, from situations that people can think of.

> I can't even answer your question "QUICK!".  I've never been able to
> convert number to bit patterns instantly, it's always a slow process for
> me.
>
> On the other hand, if someone asks you to make a risky change QUICK! and
> to forego due diligence that's on them and you and not on the tool.

I also tend to look at the network interface that has the subnet.
because if you are trying to block an actual subnet, you almost
certainly have it configured, and are doing some kind of internal/dmz.

When you are trying to block a neighborhod around an offender, you are
just guessing at the subnet size that is likely under the same
administrative control.

> Warnings might be nice.  If you do stuff interactively.  But warnings
> tend do be ignored.  Especially under automation.

They're also spam to humans.

I would say there is sentiment for warnings, and I think more against.
If somebody wants to add a warning, with an npf config to disable it,
that seems ok, and I don't even really care which is default.   As long
as I can just put in my npf.conf

  warn_subnet_nonzero_host = 0

or whatever, and be done.

> I can imagine that some kind of validation mode or maby an option that
> turns such warnings into an error (and causes the program to exit with
> non-zero status!) could be useful, though.

Definitely needs to be opt in.  It is not reasonable to tell people who
configure by taking an addr and adding a prefix that they are wrong.

> Or perhaps some kind of i-mean-it indicator in the configuration syntax
> that makes the warning disappear.

Could be that we use two // for this, like

  192.168.100.37//28

but I think that's awkward, and is an unnecessary accomodation for those
who want others not to configure like this.  I'd rather just add a
single "make npf behave reasonably" line.