Default behaviour of IP Options processing

[Michael DeMan]

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