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 [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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 > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
