From owner-freebsd-security Tue Jan 25 9: 9:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 2A3651526D for ; Tue, 25 Jan 2000 09:09:42 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA08657; Tue, 25 Jan 2000 10:09:33 -0700 (MST) Message-Id: <4.2.2.20000125095042.01a5aba0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 10:09:32 -0700 To: Warner Losh , security@FreeBSD.ORG From: Brett Glass Subject: Re: Merged patches In-Reply-To: <200001251637.JAA04226@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a very, VERY concervative patch. As such, it doesn't include rate limiting of RSTs independently of ICMP_BANDLIM (which is really a different beast -- on a router, you might NOT want to limit ICMP but want to limit bandwidth). The patch also does not prevent a non-SYN packet from matching a listening socket (this condition is caught later, but piecemeal with many individual tests; the coverage isn't comprehensive). And it does not shield the entire TCP stack from sending or receiving multicast packets -- just this path. It's still possible to emit a TCP packet with a multicast source or destination address after this patch. The source addresses of packets are still tested to see if they're muticast addresses in MANY places instead of in one place.... It seems to me that it pays to use a flag in the mbuf (as is done with B_CAST) to centralize the test. (A new flag called, say, SRC_B_CAST would do this. There's room in the flag word.) Also, in at least one place (maybe more), the code does multiple tests of the TCP option flags in succession. Several tests of this kind should generally be merged into a switch for speed (the many conditional jumps cause pipeline stalls on many processors, especially older ones) and readability. In short, I'd only go with this patch as-is if my purpose were to minimize the changes made before release. If this were the goal, I'd go back to the code immediately thereafter and try to tackle some of the inefficiencies and holes in this key input path more aggressively. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message