Re: Any way to P-T-P Distribute the RBL lists?
Drew Weaver <drew.weaver@thenap.com> inquired:
I know you all have probably already thought of this, but can anyone think of a feasible way to run a RBL list that does not have a single point of failure? Or any attackable entry?
Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT cartridges barreling along the highway at 70mph"... Seriously, as has already been pointed out, the distribution side of the equation is the easy part. Server admins can use an out-of-band technique like ordinary dialup to get access to the blocklist. But generating the blocklist requires real-time reporting back to a central server. Even if the server is decentralized, it will still require a relatively small handful of accessable IP addresses. An out of band layer-2 network could be created for that at the peering points, so as to prevent outside attack. Probably worth doing among major ISPs. Wouldn't scale to end users, of course. But end users could still subscribe to the blocklist through periodic updates. The other obvious thing that could be done would work pretty much like caller ID: create a set of SMTP enhancements that allow email recipients to accept mail from those who have provided traceable ID to the ISPs that participate, and who have agreed to acceptable-use policies that place strict limits on bulk email. Wait, hasn't that been done? The pre-1987 ARPAnet? Oh yeah, we've outgrown that... Public humiliation might also work. Bring back the stockades so we can place spammers out front of courthouses everywhere. Too bad society's outgrown that too... -rich
On Thu, 25 Sep 2003, Rich Braun wrote:
Drew Weaver <drew.weaver@thenap.com> inquired:
I know you all have probably already thought of this, but can anyone think of a feasible way to run a RBL list that does not have a single point of failure? Or any attackable entry?
Fedex. "Never underestimate the bandwidth of a station wagon loaded with DLT cartridges barreling along the highway at 70mph"...
Seriously, as has already been pointed out, the distribution side of the equation is the easy part. Server admins can use an out-of-band technique like ordinary dialup to get access to the blocklist. But generating the blocklist requires real-time reporting back to a central server.
I respectfully disagree. What it requires is some mechanism to get updates back to "authorized" server(s), and those "authorized" servers need to determine what to do with the reports. This does not need to be real-time. Near-time would suffice IMO. The interesting issue with regards to this component is indeed not the transport mechanism, but rather dealing with the influx of reports, and mitigating DOS's through floods of bogus reports. This is where things like the "web-of-trust" concept comes in handy. Sorry, but this is definitely getting off the operational charter of NANOG, so I'll stop. :-) There are a few people that have expressed interest in exploring this further. If anyone is interested drop me a line privately. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Asking the wrong questions is the leading cause of wrong answers \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
At 07:08 AM 9/25/2003, Rich Braun wrote:
But generating the blocklist requires real-time reporting back to a central server. Even if the server is decentralized, it will still require a relatively small handful of accessable IP addresses.
I seem to recall a distributed server network, something called USENET, uses NNTP for sharing data with other servers in the network... Last I heard there were over 30,000 such servers netwide/worldwide, all sharing data with one or more neighbors, automagically sharing data that is input into one system to all systems in a relatively and reasonably short amount of time. I propose that a private spamrbl nntp server system be established. Only allow feeds from those you know, use PGP authentication for all feeds and all submissions. If there is a personally verifiable web of trust built around personally verified signed PGP keys, it should prevent spammers from infiltrating the system. Perhaps the only way you can get approved/added to the network is to be approved by your upstream or a peer, and so they are held accountable for letting you into the system. This system could house a number BLs, each as a "newsgroup", allowing each network to then utilize the BLs that they want to implement in their network at any given time. Some of the newsgroups could be open, anyone can add a listing, others would be moderated (e.g. Monkeys or Spamhaus) and only the moderator(s) could add or remove listings. It seems too easy. I must be overlooking something really stupid and obvious about why this won't work. jc
participants (3)
-
JC Dill -
Patrick -
Rich Braun