Date: Wed, 30 Jan 2002 17:10:02 -0800 (PST) From: "Aaron D. Gifford" <agifford@infowest.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/28713: NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime fine-grained control Message-ID: <200201310110.g0V1A2C49318@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/28713; it has been noted by GNATS. From: "Aaron D. Gifford" <agifford@infowest.com> To: freebsd-gnats-submit@FreeBSD.org, agifford@infowest.com Cc: Subject: Re: kern/28713: NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime fine-grained control Date: Wed, 30 Jan 2002 18:02:46 -0700 An updated version of this patchset against 4.5-RELEASE (and I hope to also keep updated versions against 4.5-STABLE as it evolves) can be had at: http://www.aarongifford.com/computers/ipfwpatch.html Let me add my encouragement to Luigi or any other ipfw maintainers to merge this into the FreeBSD code base. There are several users of these patches who think this is a good idea. REASONS FOR fine grained (per rule) timeout control: * It adds the ability to avoid frozen TCP sessions (SSH is the classic complaint) when the global sysctl timeout is short * It can be desirable to use a short timeout for global rule settings in certain cases (particularly with a host or firewall handling UDP dynamic rules) to prevent dynamic rule table bloat. These patches permit the system administrator to set up specific exceptions (I use it to permit ICQ UDP sessions through a firewall while keeping all other UDP protocols I permit on a short, tight leash). * There is something asthetically pleasing about having an option for more fine grained control available at virtually no additional cost (CPU/memory) and then using that control in harmony with the computer security maxim, "Everything not explicitly permitted is denied." These extra controls give admins. the power to do exactly that with their IPFW rule sets: I can use the global sysctl variables as my default security policy very tightly (short timeouts for most things), then make exceptions as needed. REASONS AGAINST fine grained (per rule) timeout control: * It is unnecessary - just set your global sysctl timeouts high enough that none of the services your FreeBSD host or firewall or router handles are interrupted by premature timeouts. Thank you for your time and energy spent advancing FreeBSD! Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201310110.g0V1A2C49318>