From owner-freebsd-pf@FreeBSD.ORG Sun Jan 22 02:50:46 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46997106566B for ; Sun, 22 Jan 2012 02:50:46 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 7FFA18FC08 for ; Sun, 22 Jan 2012 02:50:45 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2A70625D3899; Sun, 22 Jan 2012 02:50:44 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 40069BD9B0C; Sun, 22 Jan 2012 02:50:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id PU24Tc2sf-rP; Sun, 22 Jan 2012 02:50:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 44755BD9B0E; Sun, 22 Jan 2012 02:50:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local> Date: Sun, 22 Jan 2012 02:50:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local> To: Greg Hennessy X-Mailer: Apple Mail (2.1084) Cc: freebsd-pf@freebsd.org Subject: Re: Getting Involved X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 02:50:46 -0000 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!=