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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Mar 2005 05:15:40 -0500

Even with whitelists, I think its a fair problem to ask as to whether 
one can come up with an amount of hashcash that is sufficiently 
expensive to stop the rate of spam, yet cheap enough not to totally 
disrupt legitimate new calls, given the disparity of endpoints. Keep in 
mind we also have low end UA that run in cell phones and other things, 
and these may prove even more problematic than a gateway. Unclear which 
one has the least amount of CPU density, that is, the amount of CPU 
power available per call.

The most recent spam draft is kind of lukewarm on hashcash for these 
reasons.

There are some other issues that one needs to consider, ignoring the big 
elephant in the corner above:

1. The mechanism interacts badly with forking at the moment. One problem 
is HERFP. If I have a mix of endpoints, some of which support this (and 
thus send a 419), and others that don't (and thus ring the phone), then 
you'll end up always completing the call on the endpoints that don't 
support the extension.

2. THe mechanism doesn't provide a way for a proxy to aggregate multiple 
Puzzle headers from forked branches. It needs to do something like 
WWW-Authenticate where a proxy collects these from the various 419 and 
places all of them in the 419 forwarded upstream. That will also require 
something akin to realm, that allows a UA/proxy to pull out its own puzzle.

Thanks,
Jonathan R.

Francois Audet wrote:

> Yeah, a white list approach might work.
>  
> The practical scenario that I am thinking about is with a typical VoIP 
> service provider.
>  
> Today, the vast majority of calls from subscribers terminate on gateways 
> (owned by the operator of the service).  These calls are not to a 
> specific "user" but really to a gateway, using presumably something like 
> the tel-URI-in-SIP-URI approach. In this case then, the white list is 
> not to a whole URI but to "something" that is related to the gateway 
> itself. This is different from the IM-scenario you quote.
>  
> Now, if we only have to worry about one set of gateways (like the ones 
> owned by the service provider), I guess you could base the white list on 
> the domain name or find some other solution. It may be more difficult 
> when gateways are scattered all over the place (like in an enterprise 
> for example, or a federation of enterprise, or when it terminates to 
> another service provider).
>  
> I believe we should make sure that we describe white list properly 
> before we publish the puzzle mechanism. I have a fear that we could 
> define something where the people who make the SIP end-devices have an 
> incentive to do something that is good for them (i.e., limit 
> vulnerability to spam) but could be very problematic for the Gateways 
> (or Proxies). Somehow we have to be able to mandate a white list 
> capabily (or some other mechanism). Otherwise software upgrades could 
> kill the operator of the service.
>  
> PS: Note that this is a recurring problem with gateways (I think certs 
> has the same issue).
> 
>     -----Original Message-----
>     *From:* Cullen Jennings [mailto:[email-masked]]
>     *Sent:* Friday, February 25, 2005 08:03
>     *To:* Audet, Francois [SC100:9T51:EXCH]; [email-masked]
>     *Subject:* Re: [Sip] draft-jennings-sip-hashcash-01
> 
> 
>     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:
> 
>         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
> 
>             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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Dan Wing <[email-masked]>
Date: Wed, 2 Mar 2005 07:31:33 -0800

I agree that proper whitelisting is important to discuss, and maybe  
even write into an I-D, but not in -hashcash-.  Cullen's Hashcash is  
but one way to handle an incoming call that isn't on your whitelist --  
send them a computational challenge.  -ietf-sipping-spam- lists other  
mechanisms.

-d

On Feb 28, 2005, at 11:26 AM, Francois Audet wrote:

> Today, the vast majority of calls from subscribers terminate on  
> gateways (owned by the operator of the service).  These calls are not  
> to a specific "user" but really to a gateway, using presumably  
> something like the tel-URI-in-SIP-URI approach. In this case then, the  
> white list is not to a whole URI but to "something" that is related to  
> the gateway itself. This is different from the IM-scenario you quote.
>   
> owned by the service provider), I guess you could base the white list  
> on the domain name or find some other solution. It may be more  
> difficult when gateways are scattered all over the place (like in an  
> enterprise for example, or a federation of enterprise, or when it  
> terminates to another service provider).
>   
> From: Cullen Jennings [mailto:[email-masked]]
>  Sent: Friday, February 25, 2005 08:03
> To: Audet, Francois [SC100:9T51:EXCH]; [email-masked]
> Subject: Re: [Sip] draft-jennings-sip-hashcash-01
>
>
> 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.
>
> 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  
> 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.
>
> 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"?
>
>
>  
> 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:
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Mar 2005 10:52:27 -0800

The big problem I have with hashcash is the advent of 
zombie armies. With them in mind, about them only
thing you do is punish legitimate UA's with itsy-bitsy
CPU's, and leave the spammers essentially unaffected 
with their near limitless CPU resources.

		Mike

On Wed, 2005-03-02 at 02:15,

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Mar 2005 13:59:58 -0500

Also, applications like "reverse 911" (community emergency alert 
systems) would be severely hampered by such approaches. With verifiable 
source domains and domain-level trust mechanisms, I think we have better 
tools at hand that don't require the 'make everyone suffer' approach.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 02 Mar 2005 12:28:42 -0800

Presumable these services would be white listed and use Identity.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 02 Mar 2005 12:15:46 -0800

> you'll end up always completing the call on the endpoints that don't

Good point. I think will mention this in the draft but clearly I won't
attempt to solve the well studied HERFP problem. As a separate issues, some
day the WG should discuss the limitations of the "If it hurts don't do it"
solution to the HERFP problem.

> something akin to realm, that allows a UA/proxy to pull out its own puzzle.

Oops. Excellent point. Thanks, will fix this.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Mar 2005 16:21:39 -0500

They could, but are unlikely to be, simply because people won't remember 
to put all of the services they subscribed to into their whitelists, 
particularly ones that they are not going to hear from regularly. Even 
if the large majority of people were to whitelist the service, a modest 
fraction of forgetful users would significantly slow down the system as 
it would have to deal with thousands of destinations. (Similar 
considerations, with less of life-and-death flavor, apply to all kinds 
of notification systems, from airline flight notification to school 
closings.) Depending on where the hashcash is computed, one would have 
to do the whitelisting on every new device. We can't even synchronize 
cell phone address books reliably...

Before we recommend that we waste computing resources across the 
Internet, with dubious performance, it seems appropriate to investigate 
socially more responsible alternatives.