Re: [Asrg] SICS

Barry Shein <bzs@world.std.com> Thu, 23 December 2004 04:09 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16816 for <asrg-web-archive@ietf.org>; Wed, 22 Dec 2004 23:09:47 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChKSE-0005qK-2k for asrg-web-archive@ietf.org; Wed, 22 Dec 2004 23:19:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChKBH-0007au-Et; Wed, 22 Dec 2004 23:02:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChK5t-00062w-LC for asrg@megatron.ietf.org; Wed, 22 Dec 2004 22:56:53 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15847 for <asrg@ietf.org>; Wed, 22 Dec 2004 22:56:50 -0500 (EST)
Received: from pcls1.std.com ([192.74.137.141] helo=TheWorld.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChKFg-0005WJ-HX for asrg@ietf.org; Wed, 22 Dec 2004 23:07:01 -0500
Received: from world.std.com (root@world-e.std.com [69.38.147.5]) by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id iBN3updW014897; Wed, 22 Dec 2004 22:56:51 -0500
Received: (from bzs@localhost) by world.std.com (8.12.8p1/8.12.8) id iBN3uoFA008351; Wed, 22 Dec 2004 22:56:50 -0500 (EST)
From: Barry Shein <bzs@world.std.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16842.16898.474019.377692@world.std.com>
Date: Wed, 22 Dec 2004 22:56:50 -0500
To: laird@lbreyer.com
Subject: Re: [Asrg] SICS
In-Reply-To: <20041223005806.GA15433@ender>
References: <41C675BB.9070702@elvey.com> <20041220181336.7580.qmail@xuxa.iecc.com> <20041221005258.GA4474@ender> <20041221044652.GA28562@m450> <20041221053754.GB5590@ender> <16840.42312.450617.720509@world.std.com> <20041221233651.GC10900@ender> <16840.54485.186606.533464@world.std.com> <20041222040940.GA11810@ender> <16841.64877.977185.534337@world.std.com> <20041223005806.GA15433@ender>
X-Mailer: VM 7.07 under Emacs 21.2.2
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Content-Transfer-Encoding: 7bit
Cc: ASRG list <asrg@ietf.org>
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
Sender: asrg-bounces@ietf.org
Errors-To: asrg-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Content-Transfer-Encoding: 7bit

On December 23, 2004 at 10:58 laird@lbreyer.com (Laird Breyer) wrote:
 > On Dec 22 2004, Barry Shein wrote:
 > > 
 > > So, your comments are only true if the hardware and software expands
 > > at some rate to match the request rate. It doesn't have to be linearly
 > > expanded, but when you hit a knee in the curve you either move that
 > > knee (i.e., expand resources) or suffer the consequences (exponential
 > > growth in response time.)
 > 
 > That's true, but you aren't seriously suggesting that ISPs won't upgrade
 > their equipment over time? The internet hasn't finished growing yet,
 > and service providers are middle men, so their incoming traffic
 > is bound to grow.

Yes, but upgrading equipment just to handle spam load is a bad thing,
like any crime no one wants to pay for it yet it must be paid for
nonetheless.

The increased resource pressure from spammers isn't just "in the
noise", it's quite significant. Right now I think what we're seeing is
a mixture of upgrading anyhow and trying to adjust, and just putting
more bread crumbs in the hamburger (slower mail delivery, fooling
around with filters/blocks that are questionable, etc.)

 > It's perfectly reasonable (don't you think?) to expect an ISP to
 > deploy resources proportional to their number of users, which brings
 > us back to the question of the mail request rate per legitimate user
 > and how it can be eventually limited(*). Some real numbers have
 > already been offered on the list.

I don't think the "per legitimate user" is a realistic measure any
longer since some huge percentage, I'll guess more than half, is to
unknown users and other mischief like endless probes etc.

 > (*) why not (still) consider mail requests for non-users? Verifying
 > whether an address corresponds to a local user is cheap in principle
 > nevertheless.

It's not all that cheap. Remember there are aliases and mailing lists
and so on to deal with.

Cheap is a relative thing. Don't sell "cheaper" (than a full delivery)
as "cheap".

I've been hit by 1500 zombie pc's simultaneously pumping the same
exact spam at us.

How cheap does cheap have to be to deal with an attack like that?

 Yes, you'll be seeing very many incoming socket
 > connections, but you don't need to set up a full SMTP service
 > connection until you already know that the recipient is valid.

I don't get you, SMTP is SMTP, until I talk some SMTP with them I
don't know who their intended recipient is.

 Now
 > cheap connections together with Moore's law ought(comment?) to handle
 > the increase in requests over time at a constant upgrade cost for the
 > front end.

My experience sez that spammers seem to follow a parkinsonian law of
resource exploitation which means if you get more resources they'll
use more resources.

Otherwise how could they be such a nuisance to garageshopisp.com and
AOL simultaneously?

I don't think Moore's law covers it, not by a long shot.

Moore's law mostly applies to processing power (specifically,
transistor density.)

Disk speed and network bandwidth costs, two very critical factors in
mail server scaling, don't go up anything like Moore's law.

 > 
 > > 
 > > To bring this back to earth, spammers' behavior is such that, barring
 > > response (blocking them, killing them, increasing resources, pulling
 > > the plug on your internet connection, etc) they will find the knee in
 > > that curve.
 > 
 > That's a lot of different responses, with different costs and
 > benefits. How can we get an overview without numbers? Or is the idea
 > that ASRG offers a grab bag of solutions and implementors silently
 > pick and choose what works for them without giving feedback? I don't
 > have a preference, just wondering how it's supposed to work.
 > 

ASRG is a research group.

Anxious as we may be for a solution I still think we're quite a ways
away from any meeting of the minds on what the problem is or, perhaps
put better, what a solution might look like.


-- 
        -Barry Shein

Software Tool & Die    | bzs@TheWorld.com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg