Date: Mon, 10 May 2004 02:24:14 -0700 From: Michael DeMan <michael@staff.openaccess.org> To: Darren Reed <avalon@caligula.anu.edu.au>, <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Default behaviour of IP Options processing Message-ID: <BCC4984E.50B05%michael@staff.openaccess.org> In-Reply-To: <200405070834.i478YoHn024117@caligula.anu.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <avalon@caligula.anu.edu.au> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BCC4984E.50B05%michael>