From owner-freebsd-net@FreeBSD.ORG Mon May 10 00:26:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE3EB16A4CF; Mon, 10 May 2004 00:26:34 -0700 (PDT) Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1980C43D31; Mon, 10 May 2004 00:26:34 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: from caligula.anu.edu.au (localhost [127.0.0.1]) by caligula.anu.edu.au (8.12.9/8.12.9) with ESMTP id i4A7PCch022658; Mon, 10 May 2004 17:26:33 +1000 (EST) Received: (from avalon@localhost) by caligula.anu.edu.au (8.12.9/8.12.8/Submit) id i478YoHn024117; Fri, 7 May 2004 18:34:50 +1000 (EST) From: Darren Reed Message-Id: <200405070834.i478YoHn024117@caligula.anu.edu.au> To: andre@freebsd.org Date: Fri, 7 May 2004 18:34:50 +1000 (Australia/ACT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 07:26:34 -0000 I think this is getting absurd/stupid. What do we have 3 firewalls for in FreeBSD if people are going to add knobs like this that just duplicate that behaviour ? Is there something lacking in all of those firewalls that make this necessary ? Are they all too hard to use ? Do they all impact performance so badly that people want hacks in IP in preference ? Who lets packets through their firewall with IP options, anyway ? Or is this for defence against the "evil insider" ? If the only people who are likely to use them are the security concious, ie the type of people who will use firewall rules, anyway, then this further suggests that it is just bloat and unwarranted bloat. Personally, if I want to block IP options, I won't be using these sysctl's - ever. By the time you add enough usability to them in order to make them do the equivalent of any of the firewalls, you will have added more complexity and code than is worth it. If all you're doing is trying to streamline ip_input(), then IMHO it fits into the category of "gross hack" - and there are probably other ways to better achieve this than what's being done here. Write a whole new ip_input_options() or something, just to deal with it (and start duplicating code). Same with the issue of packet copies due to the size of the packet with options. Is a matching set of ioctls going to be added for IPv6 ? Oh what, you hadn't heard of extension headers for IPv6 ? Start reading... Then again, if the rationale for having these sysctl's is because we don't trust those code paths then: a) why don't we audit or do walk throughs or code inspections to fix this; b) why don't we add sysctl's to disable all code paths that we have similar doubts about elsewhere in the kernel. Doing (b) is just stupid but if there are real concerns then there is a lot more to gain by doing (a) than adding these sysctl's as a defence mechanism. Darren