Subject: RE: [Sip] draft-jennings-sip-hashcash-01

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Feb 2005 14:30:42 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen
Jennings
Sent: Tuesday, February 22, 2005 16:46
To: [email-masked]
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
<http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcas
h-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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: David R Oran <[email-masked]>
Date: Thu, 24 Feb 2005 15:53:09 -0500

On Feb 24, 2005, at 2:30 PM, Francois Audet 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.
>  
That's the whole point! It's to prevent too many calls from one place.  
It's always under the calling UACs prerogative to give up with "what a  
bozo who wants me to blow smoke out of my Pentium for 2000ms. Guess he  
doesn't want to get the call, huh"?

I suspect a decently managed UA would only force you not the puzzle  
palace if you weren't on the buddy list, or some other whitelist.

> functionality, so that a UAC could "opt out"?
If the UAC can opt out the whole exercise is useless.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of  
> Cullen Jennings
> 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
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 25 Feb 2005 08:03:28 -0800

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. 

Cullen

On 2/24/05 11:30 AM, "Francois Audet" <[email-masked]> wrote:

> 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.
>  
>> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash-
>> 01.html
>> 
>> Cullen
> 
>

---

From: Dan Wing <[email-masked]>
Date: Fri, 25 Feb 2005 17:31:17 -0800

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