From owner-cvs-all@FreeBSD.ORG Sat May 8 13:42:47 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 6F5C916A4CE; Sat, 8 May 2004 13:42:47 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFFC743D3F; Sat, 8 May 2004 13:42:46 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i48KgTgM045995; Sat, 8 May 2004 16:42:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i48KgSHh045992; Sat, 8 May 2004 16:42:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 8 May 2004 16:42:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Darren Reed In-Reply-To: <20040508152531.GA96827@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: src-committers@FreeBSD.org cc: Andre Oppermann cc: "Jacques A. Vidrine" cc: cvs-src@FreeBSD.org 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 20:42:47 -0000 On Sat, 8 May 2004, 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 packet 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 > log 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. Actually, my impression is that Andre didn't make this change for the reason you may think he did. This isn't about ignoring insecure options, and adding yet more tunables to disable classes on insecure or possibly insecure processing, it's about allowing the administrative disabling of exceptional case "slow path" forwarding as found in most high speed routers. These routers frequently simply ignore options in fast path processing, and also frequently don't have a slow path. Using general purpose packet filtering is precisely what he doesn't want to do in order to have optimized fast path forwarding. Instead, he wants to be able to configure the system to not perform certain sorts of processing that are typically not required in that environment. That's very different from the goal of packet filtering and rewriting for security purposes. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research