Date: Thu, 5 Jul 2001 09:20:04 -0700 (PDT) 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: <200107051620.f65GK4j62827@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: Luigi Rizzo <luigi@info.iet.unipi.it> Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/28713: NEW IPFW FEATURE [PATCHES]: Dynamic rule expiration lifetime fine-grained control Date: Thu, 5 Jul 2001 10:13:29 -0600 On Thursday 05 July 2001 05:51, Luigi Rizzo wrote: > > When using stateful ipfw rules, the dynamic rule expiration times > > are governed by the values of the net.inet.ip.fw.dyn_*_lifetime > > variables. This is an excellent attribute of the ipfw stateful > > It is actually just half of what is needed. In addition to the > 'lifetime', and to avoid early expiration for idle sessions, you'd > need someone (maybe the firewall) to send around keepalives to > probe the session. > > > Your patch slightly improves the situation, but does not radically > change it or solve the problem. You still need the firewall > administrator to do a special configuration for your session, pick > a timeout value (and what do you pick ? anything less than 24hrs > is maybe not that significant for a session that you might forget > idle and you want to find active the day after), and you need > additional firewall rules to override the default for the specific > sessions. Hi, Thanks for taking time to look at this. While I will politely disagree with your characterization "..slightly improves the situation, but does not radically change it.." your point is valid: the administrator does indeed have to choose large enough time-outs so that either keepalives keep the session open, or the protocol running across the TCP or UDP session itself keeps the session open. However, the patches do far more than make a slight improvement. From my own use (an office firewall and an several medium volume Internet server hosts) the difference between having absolutely fine-grained no cotrol exept tweaking a global value which I did NOT wish to touch made the difference between choosing to use stateful firewall rules and rejecting them completely in favor of an older stateless ruleset that worked but not as elegantly. I have heard from several other administrators who said the same thing to me: per-rule expiration overrides were the difference that made stateful ipfw rules useful. As for it being only "half" the solution, let me tell that from practical experience, it ends up being more like 90-99% of the solution. Yes, the administrator does have to make smart rule lifetime expiration decisions, but that's not too hard since there are usually only a very few protocols that don't use the defaults. It works on much the same principle that the default settings do: the majority of the traffic will flow correctly. So the defaults catch 90-99% of the sessions, then the per-rule expiration catches another 90-99% of the remaining traffic/sessions. > > This is why i do not consider this patch that urgent and i am not so > inclinded to commit it. You're right, it isn't urgent. The characterization of the "Severity:" field was due to a typo on my part which caused GNATS to put in the default value. I had intended it to be "non-critical", not "serious" which was the GNATS system default. I quickly appended a note to my GNATS report to indicate this. Sorry about that. > > In cases like this, i'd rather suggest a better approach which is > to raise the default to something larger (like 1-2hr) and set the > keepalive interval on your client to a value that is shorter than > the expire interval. This does work, but there are others like me who find doing things like this on a global scale really grates against the underlying security ethic that "that which is not explicity permitted is denied" in that I am permitting a longer expiration on sessions that I don't wish to, just to get some few minority of sessions to not timeout. It bothers me in something of the same way that making all directories world-writable just to give one user write access would (even though the security implecations are vastly different). > The reason why a large timeout is not so problematic is that as soon > as the firewall sees a FIN or a RST on one side, it reverts to > using a much shorter timeout so in most cases, a regular or abortive > shutdown of the connection will result in a quick expire of the rule. A large timeout is not terribly problematic, but it is irritating since I have to increase the maximum number of dynamic rules on my firewall just to account for the additional rules that aren't expiring (those few sessions that don't see a FIN or RST - and they do exists though few in number compared to normal sessions and to those sessions that will see a FIN/RST on an aborted connection). The longer my global expiration setting, the more they will eat up rule space in my table in proportion to the overall traffic/session load on my firewall, which for a large firewall behind which sit many machines/networks could become considerable. Again, it goes against the ethic of permitting more than I really need to. As for setting the keep-alive settings on the client side, that is virtually impossible. I would have to do it on clients on many Windows95/98/2000/ME/XP, Mac OS9, Mac OS X, Linux, and FreeBSD hosts behind the firewall that that solution quickly becomes an administration nightmare. Or I would have to do it on all possible Internet server hosts that serve as the end-point to clients behind the firewall. Either solution is not a solution, but a virtual impossibility. > > cheers > luigi Thank you for looking at the patch. And thank you as well for your excellent stateful firewal work. Stateful rules are wonderful to use and I heartily recommend going stateful to anyone and everyone. (Of course I'll plug my 'lifetime' patch to those same folks... *grin*). Aaron Gifford 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?200107051620.f65GK4j62827>