Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NPF on 8.1 and pcap-filter expressions

On 08/22/19 17:44, Michael van Elst wrote:
On Thu, Aug 22, 2019 at 04:02:43PM +0200, Frank Kardel wrote:
I found that in the mean time - thanks for looking.

That leaves me probably with no generic way in npf to detect/determine
broadcast addresses.

NPF does not seem to have PF's :network/:broadcast/:peer mechanism and all

can access is the IP layer information.

This looks a bit clumsy.

Ideally I would like a generic way to determine networks, broadcast
addresses and maybe peers statically and dynamically
npfctl already reads IP information from interfaces, also reading the
netmask wouldn't be much of a problem. It wouldn't be magic though,
But it would allow the npfctl reload strategy after changing things. Though the reload strategy opens a small time frame where installed filter rules do not match the interface configuration.
rules aren't necessarily bound to an interface, so pcap-filter() would
need an explicit netmask argument, which makes it obvious that the
filter might not work correctly if applied to an interface with a
different netmask.
Yes. But we currently have the situation the NPF does not seem to have any means right now to handle netmasks and broadcasts related to interface addresses. As NPF works at the IP level I think supporting netmask/broadcast/network should be part of NPF even if we start out with the static solution in npfctl and supporting a dynamic one later.

In many situations it might be easier to just match the list of broadcast
addresses without pcap-filter.
And what mechanisms does NPF provide to access the broadcast address except for manually coding it - did I overlook something? (I am currently looking in 8.1 as that is productional an try to convert our pf router configuration to NPF with very limited success right
now - more on that in another thread).

for my case where the IP address/network is configured via DHCP and I'd
rather like to avoid dhcpcd's hooks to rewrite/reload the
Also partial interface names like tun for tun0...tun<n> could be helpful
especially as these interfaces can come and go.
That's more a question on how much code should be pushed into the
kernel. I'd rather trigger userland to reload the config.
Leaving small time windows of inconsistent configurations.
I think it depends more on the mechanisms/primitives we can think of for efficient dynamic access to interface properties.

Using partial interface names doesn't sound like a security feature to
me. Matching the new interface descriptions instead is probably safer
but then descriptions must also be supported by the program that manages
the interfaces.
Yes, interface descriptions are the right/better thing here. But how do we handle groups for an interface description when these interfaces appear and disappear? Should be compile these groups anyway? How do we handle groups for interface names and interface descriptions - looks like we might have two different groups for one interface - which rule do we run? This needs more thought or just a decision to use either interface names or interface descriptions.




Home | Main Index | Thread Index | Old Index