Date: Thu, 12 Dec 1996 09:03:43 -0800 From: Jim Binkley <jrb@cs.pdx.edu> To: freebsd-security@FreeBSD.ORG Subject: Re: Risk of having bpf0? Message-ID: <199612121703.JAA11713@sirius.cs.pdx.edu> In-Reply-To: Your message of "Thu, 12 Dec 1996 10:31:46 %2B1030." <199612120001.KAA29724@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
question: does rarpd turn i/fs on in promiscuous mode? or can it just use bpf to "read" lan broadcast packets off of a particular i/f. The problem with rarpd of course is that it wants ARP lan/bcast queries and how it is going to "read those" with ordinary sockets? Maybe I haven' t noticed that there is an AF_LINK socket and a way to bind it to an i/f? You may consider the following abstruse, but I don't... I'm in general not very thrilled by any networking protocol or sw daemon that absolutely must use promiscous mode to read all packets in order to find the occasional packet Z. Consider the underpowered laptop that got stuck on a lan where two p166 or sun ultras decide to have a multimedia festival. It might be a tad busier than it needs to be. Consider the near future when said lan may go much faster. People commonly use this line of reasoning to explain why multicast is better than broadcast (better other systems that don't care are less bothered). It applies here too. From a survivability viewpoint, I believe Bellovin opined somewhere, sometime that every net stack/o.s. has at least one killer packet out there with its name on it. Not necessarily just the famous large ping packet, but any packet. Why try to suck them all down just in case you haven't found it yet? It is not unreasonable to expect network protocol designers to minimize such needs. It is not unreasonable to expect o.s. designers to make i/fs so that routing daemons (which is what rarpd is in a tiny way) can have reasonable i/fs to get at stuff they need to function. Bruce Schneier has pointed out recently in comp.risks that security flaws are mostly bad sw engineering, not "bad crypto" algorithms. Old engineering can be improved I think. Sorry for the rant! :-> regards, Jim Binkley jrb@cs.pdx.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612121703.JAA11713>