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

[Michael Thomas <[e-mail]>]

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,

 Jonathan Rosenberg wrote:
> 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:[e-mail]]
> >     *Sent:* Friday, February 25, 2005 08:03
> >     *To:* Audet, Francois [SC100:9T51:EXCH]; [e-mail]
> >     *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" <[e-mail]> 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:*  [e-mail] [mailto:[e-mail]]
> >             *On Behalf Of *Cullen  Jennings
> >             *Sent:* Tuesday, February 22, 2005 16:46
> >             *To:*  [e-mail]
> >             *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 [e-mail] for questions on current sip
> >         Use [e-mail] 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 [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip