svn commit: r349929 - head/sys/contrib/ipfilter/netinet

[Cy Schubert]

In message <20190806011317.GG1398 at FreeBSD.org>, Gleb Smirnoff writes:
>   Hi,
>
> On Fri, Jul 12, 2019 at 01:59:09AM +0000, Cy Schubert wrote:
> C> Log:
> C>   Move the new ipf_pcksum6() function from ip_fil_freebsd.c to fil.c.
> C>   The reason for this is that ipftest(8), which still works on FreeBSD-11,
> C>   fails to link to it, breaking stable/11 builds.
> C>   
> C>   ipftest(8) was broken (segfault) sometime during the FreeBSD-12 cycle.
> C>   glebius@ suggested we disable building it until I can get around to
> C>   fixing it. Hence this was not caught in -current.
> C>   
> C>   The intention is to fix ipftest(8) as it is used by the netbsd-tests
> C>   (imported by ngie@ many moons ago) for regression testing.
>
> AFAIR, maintaining ipftest always was a PITA, as it wants to compile
> lots of kernel code into a userland utility. Of course, once disabled
> it will bitrot very quickly.
>
> I'd suggest to achive functionality of ipftest in a different way. Add
> a new ioctl() to the pfil(9), that will read a packet from the userland
> and match it against a given pfil head and report the result. This will
> make a universal tool for packet against ruleset checking for all existing
> firewalls, including ipfw and pf. Let's call it pfiltest utility. It can
> also be a part of existing pfilctl, invoked as "pfilctl test".

This would make firewall testing more consistent. The approach 
currently used by SoC project uses VNET jails. An ioctl() to inject 
packets into pfil(9) is intriguing. ipftest(8) uses pcap file for 
testing, providing serially reproducible input.

OTOH, a userland utility can be rebuilt at will without affecting the 
running system. A person could test yet to be implemented changes 
without affecting the currently running packet filter.

Still this is an interesting idea. When I was an MVS systems programmer 
I had developed extensions to the JES2 job entry subsystem. MVS allowed 
for a primary and secondary subsystem allowing the primary to process 
jobs while the secondary could be used for testing or other purposes. 
In a similar vein, possibly having a primary and secondary pfil(9) to 
which alternate packet filters could attach for would allow for testing 
without the disruption of kldload/kldunload of the primary packet 
filters or even worse, reboot. (And reboots for the sake of testing are 
annoying for the impatient.)

Anticipating the next point, why not a VM? Again, time.

>
> The second missing bit of functionality is that ipftest can test against
> not the running ruleset, but some other ruleset. This can be achieved by
> adding multiple ruleset feature into existing firewalls. The pfil(9) already
> has notion of ruleset names, but so far ipfw, pf and ipf provide only "defaul
> t".

ipfilter already uses a active and inactive rulesets. Best practice is 
to clear and load new rules into the inactive ruleset and switch it to 
active. If it causes problems, switch back. One could extend this 
functionality to multiple rulesets or map the active/inactive rulesets 
back to pfil(9).

> Once a firewall is able to make alternative rulesets, we can match this
> functionality: ipftest would install temporary ruleset, don't connect it
> to any head, run the new ioctl() on it, then destroy the ruleset.
>
> I'm sorry to come with a suggestion but can't contribute any time into it.

Thanks for giving me more things to ponder.

Lastly, in defense of ipftest, the NetBSD tests that ngie@ imported 
uses ipftest, as do our friends at NetBSD. If anything I'd like to at 
least maintain the same UI such that sharing of scripts, tests, and 
ideas would still be possible.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.