cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h

[Darren Reed]

Unfortunately I don't subscribe to freebsd-net so this email is caught
up in some moderator's file, somewhere, I imagine, but since it was
meant to be public, and Andre hasn't responded, I'll include those comments
here...the rationale being given, is performance.  Being able to have a
kernel that doesn't need to do "expensive processing".  Being able
to not do processing on packets that might tickle bugs.  Being able
to filter them out without "expensive" processing.
i.e. This is aimed at allowing people to hide from bugs - security &
performance related.

Is that what FreeBSD is about, these days ?

The rationale for this code is split over two emails:
http://lists.freebsd.org/pipermail/freebsd-net/2004-May/003887.html
http://lists.freebsd.org/pipermail/freebsd-net/2004-May/003912.html

And, btw, at least to my knowledge, IP options do have a use on live
networks today.  If they were so useless then people wouldn't have
designed them back into IPv6 as extension headers, would they ?

My apologies if my language has been rash on this, but this change
really rubs me the wrong way.  Some of that may be because of ipfilter
but some of it most definately is not.

Darren

Subject: Re: Default behaviour of IP Options processing
To: andre at freebsd.org
Date: Fri, 7 May 2004 18:34:50 +1000 (Australia/ACT)
Cc: freebsd-net at freebsd.org


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.  Doing (a) leads to real security.  What this
patch provides, does not.

Darren