From owner-freebsd-security Fri Jan 21 17: 8:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 115E2156F5 for ; Fri, 21 Jan 2000 17:08:42 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id UAA07744; Fri, 21 Jan 2000 20:08:29 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 20:08:29 -0500 From: Jared Mauch To: Matthew Dillon Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121200829.E4055@puck.nether.net> Mail-Followup-To: Matthew Dillon , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001220035.QAA65392@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 04:35:44PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 04:35:44PM -0800, Matthew Dillon wrote: > > :> RST cases but the above two cases usually handle the vast majority of > :> these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM, > :> we're done. If it isn't then we spend a few seconds extending the cases > :> covered by ICMP_BANDLIM and we are done. > : > :I'd certainly like to see this extended to RST. We can optimize socket searching > :and prevent TCP from sending RSTs (or anything!) to multicast addresses at the > :same time. (We probably also want to block RECEIVED TCP packets from multicast > :addresses, as Wes suggests.) > : > :--Brett > > I wouldn't worry about multicast addresses for several reasons. First, very > few machines actually run a multicast router. No router, no problem. Second, > multicast tunnels tend to be bandwidth limited anyway. Third, from the point > of view of victimizing someone multicast isn't going to get you very far > because we already check for a multicast destination. We don't really need > to check for a multicast source because it's really no different from a > victimizing point of view as a non-multicast source address. > > -Matt > Matthew Dillon I currently show 69695 prefixes on the internet. of those, 7366 are currently multicast capable, which is 10.5%. I take some issue with your statement, as more hosts are currently connected than ever before, and I see it increase daily. I doubt it will reach 100% anytime soon, but it's far more deployed than it has ever been, and continues to be deployed. Attacks related to multicast connectivity need to be taken into account. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message