Date: Fri, 21 Jan 2000 22:14:44 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: keramida@ceid.upatras.gr Cc: brett@lariat.org (Brett Glass), dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), avalon@coombs.anu.edu.au (Darren Reed), security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001220614.WAA59998@gndrsh.dnsmgr.net> In-Reply-To: <20000122044638.B27337@hades.hell.gr> from Giorgos Keramidas at "Jan 22, 2000 04:46:38 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.)
>
> So what needs to be done is:
>
> (a) drop all multicast packets that reach the tcp stack.
> (b) extend ICMP_BANDLIM to RST packets, and
> (c) avoid sending anything tcp to a multicast address
>
> Do I forget something here?
(d) Audit the whole ip stack top to bottom for conformance to rfc, and
good coding practices like bounds checking, and invalid data handling.
(Your (a) above is invalid data between the ip layer and tcp, handled at
either output from ip or as input to tcp in the upwards stack direction,
and (c) is output from tcp to ip in the downward stack direction.)
There is also a nice bandwidth limiter that can be apply to almost any
packet by using dummynet, just write your filter carefully :-)
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net
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?200001220614.WAA59998>