From owner-freebsd-net@FreeBSD.ORG Mon May 10 02:24:26 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 8960016A4CF; Mon, 10 May 2004 02:24:26 -0700 (PDT) Received: from shiva.openaccess.org (shiva.openaccess.org [216.57.214.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1189543D5A; Mon, 10 May 2004 02:24:26 -0700 (PDT) (envelope-from michael@staff.openaccess.org) Received: from [216.57.214.90] ([216.57.214.90]) by shiva.openaccess.org (8.12.9/8.12.3) with ESMTP id i4A9OElC033301; Mon, 10 May 2004 02:24:14 -0700 (PDT) (envelope-from michael@staff.openaccess.org) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 10 May 2004 02:24:14 -0700 From: Michael DeMan To: Darren Reed , Message-ID: In-Reply-To: <200405070834.i478YoHn024117@caligula.anu.edu.au> 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 09:24:26 -0000 I agree with the 3 firewalls being a problem. I would like to point out however that having the 3 firewalls is a classic political issue. >From a purely technical perspective we have IPFW and IPF/PF. Really, only two firewalls. For our company, as an end user that occasionally has to do build/port hacks to provide products to service our customers, ipfw needs to go and the political issues between IPF/PF need to be solved. Currently we use IPF for firewalls and IPFW+DummyNet for bandwidth limiting. Using two different administrative tools and syntax sucks. Ideally for us an IPF/Alt-Q solution is the best. However, egos seem to prevail, and IPFW links with experience makes it a forimidable solution to switch away from. Given the statements above, I am grateful for all the code and work people have done. - Mike Michael F. DeMan Director of Technology OpenAccess Internet Services 1305 11th St., 3rd Floor Bellingham, WA 98225 Tel 360-647-0785 x204 Fax 360-738-9785 michael@staff.openaccess.org P.S. - Thanks for cleaning up the code Darren. We can finally do IPSEC+IPNAT for our WiFi customers. Yes, there are potential security holes but we can run IPSEC 0.0.0.0/0 plus IPNAT which is far better than WEP. On 5/7/04 1:34 AM, "Darren Reed" wrote: > > 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 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >