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>