Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Jan 2012 02:50:40 +0000
From:      "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To:        Greg Hennessy <Greg.Hennessy@nviz.net>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: Getting Involved
Message-ID:  <E0053250-530D-4ADA-8230-E506814E475D@lists.zabbadoz.net>
In-Reply-To: <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local>
References:  <CAConN%2BkZquK7MJ_6YPtEV=sJdqC%2BniRqMmp2ZgQL%2Bo2m1wvXSQ@mail.gmail.com> <CAPBZQG2S9T4v_4g09mXaukG4o3_4w8h51py6-iPoA%2BgmsuenUw@mail.gmail.com> <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local>

next in thread | previous in thread | raw e-mail | index | archive | help

On 21. Jan 2012, at 23:26 , Greg Hennessy wrote:

>>>=20
>> There is one catch.
>> FreeBSD does not want to break compatibility of old syntax and that =
is why
>> i did not port the latest version of pf(4).
>=20
> Shades of the versioning/maintenance issues surrounding putting Perl =
in the base way back in the day.=20
>=20
>> What is there now makes it 'trivial' to go to the latest pf(4) =
version in
>=20
> Does that include the performance improvements which came with new =
version?=20
> Would be interesting to know what impact if any they would have on the =
FreeBSD PF port.=20

Whatever performance improvements you are talking about is basically =
irrelevant the way pf is written and designed, which is just another =
obstacle in tracking Open.  FreeBSD is no longer a UP-like operating =
system.  We'd need a larger mix of (just to name some) fine grained =
locking (currently the 1 lock basically halts the network stack per =
packet going through pf), a lot more cache friendly data structures, =
affinity, ... in that area.  Taking it to 10G or eventually 40G is =
really a different step than squeezing another 50Mbit/s out of it by =
some optimization and entangling it more and more with the rest of the =
network stack etc.


>> Open but there needs to be a layer of translation
>> for the old syntax to new syntax.
>=20
> As a one off translation when someone upgrades Major version numbers =
to the FreeBSD version hosting the new PF code?=20
> Or run every time when someone loads the security policy for now and =
the foreseeable future?=20

Let's say pf ruleset instead of security policy (which is also used in =
various other ways).  The basic problem is that the syntax is known to =
management tools but also the user space-kernel API is exposed to 3rd =
party tools.  Breaking any is bad.  The latter we can break with major =
versions though preferably we'd love not to.  The way things are written =
it's basically not possible not to break it even when bringing in cherry =
picked features like NAT64 etc.  It's an obstacle to some of our =
consumers though.  The moment you update your kernel and pfctl doesn't =
speak the same language anymore you lost your firewall.  And it's not =
uncommon to upgrade a kernel going from x.y to x.y+n for example, wait a =
week or two before updating all user land etc.

It's the same problem with pfsync; you can have two old version ones, =
reboot the first, not able to sync things to the new as it doesn't =
understand the old anymore and by the time you reboot the 2nd things =
*oops*.  That's not an upgrade path for a HA setup unfortunately and we =
had that happen way too often to our users - once again with 9.


>> That is the only reason its not been done.
>=20
> I can see the issues, hope it's not intractable.=20
> The new syntax is a significant improvement, shame about lack of =
thought given to backward compatibility.

You are preaching to the wrong choir:(


> With your expert knowledge on this Ermal,  is it possible to run both =
old and new PF parsers in there to generate a policy which would run =
against the newer packet filtering engine code?

If you write the translation stub you might succeed.  Have fun... =
*cough*


> Defaulting to the old syntax, with say something like a ' =
later_pf_enable=3D"yes"'' in rc.conf or a single 'use' line at the top =
of pf.conf to switch to the new syntax?=20

You can even have two different pf's loadable by the kernel (at least =
one at a a time) if doing it clever given pfil hooks.  But maintaining =
more than 1 is not going to happen for and in Free.


There are basically two options:  1) we can make it work well or 2) you =
can always have the newest syntax and regularly break and not perform.  =
Pick any single one at this point and let us know which one you'd =
prefer.


A couple of developers lately had this discussion (though not everyone =
was present).  I'll however be curious which way our users want it to be =
...

/bz

--=20
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0053250-530D-4ADA-8230-E506814E475D>