Date: Fri, 21 Jan 2000 22:39:03 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: gdonl@tsc.tdk.com (Don Lewis) Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001220639.WAA68014@apollo.backplane.com> References: <200001220624.WAA15869@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:} 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. But he can't. We drop packets sent to multicast destinations and any RST responses back to multicast sources will be rate-limited. OSPF has its own protocol, it will ignore any TCP garbage on its multicast address. -Matt Matthew Dillon <dillon@backplane.com> 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?200001220639.WAA68014>