From owner-cvs-all@FreeBSD.ORG Sat May 8 11:04:41 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3205D16A4CE; Sat, 8 May 2004 11:04:41 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 579DD43D4C; Sat, 8 May 2004 11:04:40 -0700 (PDT) (envelope-from max@love2party.net) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BMWBh-0008DK-00; Sat, 08 May 2004 20:04:37 +0200 Received: from [217.83.7.6] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BMWBg-0003JS-00; Sat, 08 May 2004 20:04:37 +0200 From: Max Laier To: Luigi Rizzo Date: Sat, 8 May 2004 20:04:40 +0200 User-Agent: KMail/1.6.1 References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <20040508152531.GA96827@hub.freebsd.org> <20040508101459.A98855@xorpc.icir.org> In-Reply-To: <20040508101459.A98855@xorpc.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_/ESnAl5T+IQ53bj"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405082004.47121.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e28873fbe4dbe612ce62ab869898ff08 cc: src-committers@FreeBSD.org cc: Andre Oppermann cc: "Jacques A. Vidrine" cc: cvs-src@FreeBSD.org cc: Darren Reed cc: cvs-all@FreeBSD.org cc: Sam Leffler Subject: Re: cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 18:04:41 -0000 --Boundary-02=_/ESnAl5T+IQ53bj Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I see that there is a different scope of "the generic way" (=3D=3D firewall= ) and=20 the special stuff (=3D=3D sysctl et. al.) in that the sysctl tuneable check= s are=20 more or less blindly killing *everything* while a packet filter allows for= =20 fine-grained rules. I think both has application and I think both should be= =20 available, BUT it should also be possible to get rid of the "kill-all"=20 overhead (even though I might be neglectable for any given change, the=20 agregated overhead is still an issue). So my vote is to have a kernel option, let's call it "NOFIREWALL" (or=20 NO_FIREWALL if that is the fav. color of the bikeshed at the moment) and wr= ap=20 **all** those duplicate bits with #ifdef's. GENERIC would ship with this=20 option turned on, but everybody that wants to build a **router** or box tha= t=20 needs fine-grained packet filtering can get rid of the disturbing code with= =20 one switch. Also it is easy to kill it all at once if we decide that we hav= e=20 default firewall code that is fast and easy enough. Another sidenote on this: I'd like to have the default install to be as RFC= =20 compliant as possible ... additional security levels should be set consciou= s=20 via sysctl or rc.conf. Also I find the naming/numbering of this particular sysctl a bit "not so=20 intuitive" as it should be called "options_process" (as the options-part is= =20 the more significant) and a higher value should mean a higher "security"=20 level. But that are just my 2=A2 as I am on it and is not to be considered = as=20 bylaw bashing. On Saturday 08 May 2004 19:14, Luigi Rizzo wrote: > On the principle, I tend to agree with Darren here... > it is not nice to replicate functionality in multiple places > by using specialized code instead of relying on (and > possibly optimizing) the generic one. It makes a lot harder > to clean up the replication later, and i believe Andre knows > that quite well given the cleanup work he has done in the past > in the network stack. > > I don't think it is worth making a bit fuss about this particular > change, but certainly, as a general principle, we should try as > much as possible to use the generic mechanisms when available -- > especialliy given that performance killers are elsewhere (locking > etc.). > > cheers > luigi > > On Sat, May 08, 2004 at 08:25:31AM -0700, Darren Reed wrote: > > On Fri, May 07, 2004 at 07:55:36AM -0700, Sam Leffler wrote: > > > Employing a packet filter is not equivalent as it requires every pack= et > > > to be processed while this (effectively 7-line change) adds no new > > > overhead to the normal processing path for packets. It would be nice > > > if packet filtering were cheap enough that we could use it in this way > > > but I don't think that's the case just yet. > > > > Using that argument, is that clearance to put all of the normalization > > from pf into the various parts of the networking code (not every type of > > normalisation needs to be done on every packet but it is all useful), > > with sysctls to turn it on or off, and maybe we'll add the ability to l= og > > packets at various points because we don't want the overhead of BPF (it > > has to process every packet too) and that's just for starters. I'm sure > > I can think of some more, in time. How about you? > > > > If there were a core@ for freebsd that was active, this is the kind of > > thing I'd be writing to them about, asking for it to be backed out. > > > > Darren =2D-=20 Best regards, | mlaier@freebsd.org Max Laier | ICQ #67774661 http://pf4freebsd.love2party.net/ | mlaier@EFnet --Boundary-02=_/ESnAl5T+IQ53bj Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAnSE/XyyEoT62BG0RAmgYAJsERWKuZp5TKjfWlcAo7vo9ww7rdQCfaOdh 7lFuSkNs+sSFKB9w55DjByY= =Gwu7 -----END PGP SIGNATURE----- --Boundary-02=_/ESnAl5T+IQ53bj--