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

[Dan Wing <[e-mail]>]

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:

> 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