Date: Tue, 8 Nov 2005 13:14:30 -0800 From: Lars Eggert <lars.eggert@netlab.nec.de> To: Mike Silbersack <silby@silby.com> Cc: net@freebsd.org Subject: Re: TCP RST handling in 6.0 Message-ID: <AD6BF86B-E466-4E3B-8B33-A7A53B3B88F8@netlab.nec.de> In-Reply-To: <20051108130801.Y36544@odysseus.silby.com> References: <E019841F-389F-4B15-942E-F30F6745ECBF@netlab.nec.de> <20051108130801.Y36544@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-13-705931855 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Nov 8, 2005, at 11:23, Mike Silbersack wrote: > > I'm open to discussing the change. I plan to revisit that and the > SYN causing a connection reset issue after eurobsdcon. good to know, thanks! > However, I'm open to clubbing you over the head for not saying > anything throughout the entire 6.0 release cycle and requesting the > change AFTER THE RELEASE HAS SHIPPED. Since 6.0 shipped with this > feature on, I don't think we should flip the setting back to off > until a good reason has been given. Point taken, and I'm very sorry. I no longer follow -current, so I've missed this completely until I looked at 6.0. The argument for switching it back off would be that the RST attack is probably only effective against long-lived connections between well-known ports, the canonical example being BGP sessions. I doubt that the average user has many such connections open and thus will see little benefit from having this on. The change does increase the chances of ignoring valid RSTs, which could lead to all sorts of problems, especially when talking to esoteric TCP stacks. These two effects (attack resistance vs. compatibility) are hard to trade off. I'd personally argue for the conservative approach. Also note that other attacks against long-lived TCP connections are still possible, e.g., through spoofed ICMP packets. I do see the release engineering aspects of switching this off by default. In the end, it's a judgement call. > While we're on the subject of potential problems, I'd like to throw > out an idea. What would people think of a "log perhaps somewhat in > vain" option (turned on by default) that logged unusual looking > packets to /var/log/ip.log - but did it in a ratelimited fashion, > so that it would not be possible for attackers to chew up disk > space. This would of course get written to during an attack, but > it would also log legitimate cases, such as where a RST blocked by > this setting came in. This could also be used to tell if future > changes cause additional incompatibilities. > > Such a feature wouldn't cause performance problems, but I could see > there being privacy concerns. If the log was only root readable, > what would people think? Remember that I'm talking only about > logging "odd" packets, and only their TCP/IP flags and fields, not > the data contents. I think that'd be very useful. I frequently come across entries in the logs that I wish I had some more information about. I'd even go as far as (optionally) dumping all such packets in tcpdump format. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-13-705931855--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD6BF86B-E466-4E3B-8B33-A7A53B3B88F8>