Date: Fri, 21 Jan 2000 22:24:34 -0800 From: gdonl@tsc.tdk.com (Don Lewis) To: Matthew Dillon <dillon@apollo.backplane.com> Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001220624.WAA15869@salsa.gv.tsc.tdk.com> In-Reply-To: Matthew Dillon <dillon@apollo.backplane.com> "Re: stream.c worst-case kernel paths" (Jan 21, 9:51pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001220624.WAA15869>