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

["Francois Audet" <[e-mail]>]

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]]
<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
<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 [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