Date: Sat, 8 May 2004 08:52:49 -0700 From: Darren Reed <darrenr@hub.freebsd.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_fastfwd.c ip_input.c ip_var.h Message-ID: <20040508155249.GB96827@hub.freebsd.org> In-Reply-To: <20040508152531.GA96827@hub.freebsd.org> References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <20040506185854.GB1777@madman.celabo.org> <20040507072031.GA48708@hub.freebsd.org> <200405070755.36055.sam@errno.com> <20040508152531.GA96827@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org Date: Fri, 7 May 2004 18:34:50 +1000 (Australia/ACT) Cc: freebsd-net@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040508155249.GB96827>