From owner-freebsd-security Fri Jan 21 22:33:56 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1BF1D1561A for ; Fri, 21 Jan 2000 22:33:47 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA87928; Fri, 21 Jan 2000 23:09:29 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA18444; Fri, 21 Jan 2000 23:09:39 -0700 (MST) Message-Id: <200001220609.XAA18444@harmony.village.org> To: gdonl@tsc.tdk.com (Don Lewis) Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.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> Date: Fri, 21 Jan 2000 23:09:39 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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