Date: Fri, 21 Jan 2000 23:09:39 -0700 From: Warner Losh <imp@village.org> To: gdonl@tsc.tdk.com (Don Lewis) Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001220609.XAA18444@harmony.village.org> In-Reply-To: Your message of "Fri, 21 Jan 2000 21:51:44 PST." <200001220551.VAA15775@salsa.gv.tsc.tdk.com> References: <200001220551.VAA15775@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200001220551.VAA15775@salsa.gv.tsc.tdk.com> Don Lewis writes: : (b) still needs to be generalized to cover other paths that generate : RST packets. Matt has a patch for (b). You two might want to merge the two. I think that the discarding of multi-cast packets is one of those can't hurt sorts of things. I'm less sure about the wildcard stuff. What's the measurable results on this change? : I think ACK packets also might need to be rate limited, because an attacker : can spoof a SYN packet to a listening socket to create a socket in the : SYN_SENT state, then send a large number of packets with the same source : and destination addresses, to which the victim will respond with ACKs. : This will be trickier to implement without causing performance problems : under heavy traffic conditions where a large number of ACKs should actually : be sent. Agreed. Longer term it may make sense to work on this, but before the release, it sounds dangerous. : I'm less enthusiastic about deferring the checksum. It complicates the : code and the CPU really should be sized to have enough cycles so that : it can checksum legitimate data at full bandwidth. I don't see much : advantage of optimizing the code so that the machine has more idle cycles : when it is under attack than when it is occupied doing useful work. I'd agree. Checksum for the tcp packets costs about 1 x len cycles per packet on most machines. At 10MB/s, we're looking at 10,000,000 cycles out of 400,000,000-700,000,000, or < 2% at full speed. : This patch has only been lightly tested under benign conditions. Cool. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001220609.XAA18444>