Re: [Sip] draft-jennings-sip-hashcash-01

Dan Wing <dwing@cisco.com> Sat, 26 February 2005 01:34 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 UAA22699 for <sip-web-archive@ietf.org>; Fri, 25 Feb 2005 20:34:10 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qqh-0008Ja-7U for sip-web-archive@ietf.org; Fri, 25 Feb 2005 20:34:27 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qnp-00040v-MG; Fri, 25 Feb 2005 20:31:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qnn-0003u8-O5 for sip@megatron.ietf.org; Fri, 25 Feb 2005 20:31:27 -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 UAA22525 for <sip@ietf.org>; Fri, 25 Feb 2005 20:31:26 -0500 (EST)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qo2-0008Go-7D for sip@ietf.org; Fri, 25 Feb 2005 20:31:42 -0500
Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 17:32:14 -0800
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="3.90,118,1107763200"; d="scan'208"; a="163895486:sNHT29837084"
Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1Q1VFwN020983; Fri, 25 Feb 2005 17:31:15 -0800 (PST)
Received: from [10.32.240.197] ([10.32.240.197] (may be forged)) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA14592; Fri, 25 Feb 2005 17:31:14 -0800 (PST)
In-Reply-To: <BE448C50.2AA3D%fluffy@cisco.com>
References: <BE448C50.2AA3D%fluffy@cisco.com>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="ISO-8859-1"; delsp="yes"; format="flowed"
Message-Id: <1C38EAC8-8796-11D9-AD2A-0003938AF740@cisco.com>
Content-Transfer-Encoding: quoted-printable
From: Dan Wing <dwing@cisco.com>
Subject: Re: [Sip] draft-jennings-sip-hashcash-01
Date: Fri, 25 Feb 2005 17:31:17 -0800
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Content-Transfer-Encoding: quoted-printable
Cc: "sip@ietf.org" <sip@ietf.org>, Francois Audet <audet@nortel.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de
Content-Transfer-Encoding: quoted-printable

On Feb 25, 2005, at 8:03 AM, Cullen Jennings wrote:

>
>  The idea would be to have a very skewed amount of computation to help  
> rate limit attacks. Whatever amount of computation is "reasonable" for  
> a valid client to do, an attacker is going to be able to apply a lot  
> more computation to the problem. However, this still limits the number  
> of messages the attacker can do and thus raises the cost. I discuss  
> this some what in the SPAM draft.
>
>  This could all happen in different ways. Imagine a case where my  
> enterprise proxy compute the puzzles on behalf of my phone when I call  
> another domain. Say in a large enterprise, it has 10,000 people and  
> during a busy hour makes 10 calls per second that are to an address  
> external to the domain. Of these only 2 are not whitelists. If the  
> enterprise proxy was willing to spend say 3GHz worth of CPU at  
> computing challenges for these 2cps, well that is a pretty hefty  
> amount of hash that could be required.
>
> Another ways is perhaps all the UAC are willing to do about the amount  
> of hashing that 1 second of G.729 compression would take. It's hard to  
> imagine that most UAs (even large GWs) could not do this. This would  
> limit the rate of attack of a single computer to in the 100s of  
> messages per second. This is a lot less hashing that the example above  
> but contrast this to what is possible today. Today I can send in the  
> order of 100,000 message per second. Increasing the cost of an attack  
> by 1000 is good. It slows it down and give you time to trace the  
> source and cut it off before it is everywhere. It makes is less worth  
> while to advertise products that a very very small percentage of the  
> receivers would buy.
>
>  As discussed in the SPAM draft, you would always want to use white  
> lists first then if the person was not on the white list fallback to  
> something else like this.

Unstated in either document is the assumption that every legitimate  
caller and every spammer has, at their disposal, one and only one  
machine that has the CPU capacity of a modern off-the-shelf PC -- "1  
Pentium Unit".  If a legitimate user has less, or a spammer has more, I  
don't see hashcash being very valuable.

If a legitimate caller has less than 1 Pentium Unit, it seems that  
person is SOL -- they either upgrade their UA, upgrade their SIP proxy  
to solve the puzzle for them, buy puzzle-solving MIPS from someone  
else, or simply not complete a call to someone with a difficult  
challenge?

I do agree that hashcash makes spamming more expensive, but  
significantly more expensive.  Today, email spammers own botnets which  
are used to send email spam.  Tomorrow, SIP spammers can modify those  
same botnets to solve hashcash puzzles _and_ send (SIP or email) spam  
-- afterall, it isn't computationally-expensive to send email spam  
(it's mostly bandwidth), so each PC can do a computational puzzle in  
addition to its normal spam duties.  And the PCs that a spammer 'owns',  
which can't send spam due to a clueful ISP, can still solve hashcash  
puzzles on behalf of a SIP spammer.

And ven without a botnet of PCs, a spammer can buy a workstation with  
substantially more than 1 Pentium Unit.  And I expect spammers will  
write software running on off-the-shelf speciality hardware, such as  
graphics accelerators, to solve hashcash puzzles faster than 1 Pentium  
Unit.

-d


>  Cullen
>
>
>  On 2/24/05 11:30 AM, "Francois Audet" <audet@nortel.com> wrote:
>
>
> We may need to explain some of the limitations of this. It seems to me  
> that this mechanism would not be terribly appropriate for applications  
> that aggregate a large number of clients onto a single platform. For  
> example, this may be too computationally intensive for a large PSTN  
> Gateway, or even a large Proxy.
>
> Any ideas of how a UAS would make the decision to send the 419 without  
> burdening the UAC? Should there be a supported/require header for this  
> functionality, so that a UAC could "opt out"?
>
>
>   
> -----Original Message-----
> From:  sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of  
> Cullen  Jennings
> Sent: Tuesday, February 22, 2005 16:46
> To:  sip@ietf.org
> Subject: [Sip]  draft-jennings-sip-hashcash-01
>
>
>  I updated  this draft on "SIP Computational Puzzles" so it has enough  
> detail to implement  it. (Previous version did not). It is in the  
> drafts directory and also in HTML  form at:
>
> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip- 
> hashcash-01.html
>
>  Cullen
>
>
>
> _______________________________________________
>  Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>  This list is for NEW development of the core SIP Protocol
>  Use sip-implementors@cs.columbia.edu for questions on current sip
>  Use sipping@ietf.org for new developments on the application of sip
>
>
>   _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip