From owner-freebsd-security Fri Jan 21 22:24:39 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 1AE1314EA1 for ; Fri, 21 Jan 2000 22:24:37 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA18846; Fri, 21 Jan 2000 22:24:35 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id WAA53304; Fri, 21 Jan 2000 22:24:35 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA15869; Fri, 21 Jan 2000 22:24:34 -0800 (PST) Message-Id: <200001220624.WAA15869@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 22:24:34 -0800 In-Reply-To: Matthew Dillon "Re: stream.c worst-case kernel paths" (Jan 21, 9:51pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Matthew Dillon Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 9:51pm, Matthew Dillon wrote: } Subject: Re: stream.c worst-case kernel paths } No matter what you do there will always be something the attacker can } shoot at you. The only thing you care about is making sure that it } doesn't take down your servers. Since multicast packets have to } go through multicast routers to get anywhere, and those routers are } already band-limited, a multicast attack is not likely to kill your } network or your machine. I doubt an attacker would be able to push } enough mcast packets through the router to matter since if the ISP } is smart the bandwidth will be limited to something reasonable. On } the otherhand, non-multicast packets are almost *never* band limited. } So guess what the IRC weenie is going to use! But won't incoming packets with a multicast source address and non-multicast destination address be treated like non-multicast packets and escape the bandwidth limits? I don't want my server to act as an amplifier that converts a high bandwidth stream of bogus unicast packets into a high bandwidth stream of multicast packets. Imagine what the IRC weenie could do if he could convert a stream of unicast packets to a multicast stream flood on your local network addressed to 224.0.0.5 (OSPF) which all the routers on your network are sniffing the wire for. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message