Default behaviour of IP Options processing

[Darren Reed]

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