Re: NPF on 8.1 and pcap-filter expressions

[Frank Kardel <kardel%netbsd.org@localhost>]

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
> > we
> >
> > 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.
> Greetings,

Greetings

  Frank