Re: [Sipping] RUCUS / framework-spit-reduction-02

[Dan York <[e-mail]>]

Otmar,

I think those are all excellent questions to discuss at the RUCUS EG  
meeting in March!   (As well as in advance through this list.)

Dan

On Jan 30, 2008, at 11:56 AM, Otmar Lendl wrote:

>
> Triggered by Hannes' posting of the rucus BoF proposal, I had a closer
> look at draft-tschofenig-sipping-framework-spit-reduction-02. Here are
> my thoughts on the whole framework. Let the discussion begin.
>
>> From a pure technical point of view, this is a solid proposal. It can
> certainly be implemented and deployed. It's an engineering approach to
> SPIT, which by itself is fine, and that's what the IETF is supposed  
> to do.
>
> On a second reading, I became a lot more sceptical about whether these
> ideas and protocols can have an effect on the real-world deployment of
> SIP.  The documents are quite narrow and describes the technical part,
> what I'm missing is the overall vision on how the toolset provided
> by these drafts works together to create a worldwide communication
> framework which has the potential to take over the role of the  
> current PSTN.
> (If that actually is what we want to do.)
>
> The first unanswered question to me is thus:
>
> Looking ten years into the future, what is our vision of the
> communication landscape in which this SPIT framework must work in?
>
> * Will that be a communication system which exists in addition to
>   old systems? Will it provide a new mode of communication?
>   (as e.g. the IM networks are. Or as e-mail was)
>
> * Or will SIP be used as the baseline technology of an existing  
> mode of
>   communication? In other words: will people replace their old phones
>   with SIP phones and expect that they works seamlessly with  
> communication
>   partners who are still on the old technology?
>
> * Who will deploy these solutions? Will it be the big operators?  
> Within
>   walled gardens or over the public Internet? Or will it be like e- 
> mail,
>   where enterprises and even private enthusiasts run their own systems
>   which directly interact with any other installation?
>
> * What kind of reliability and connectivity expectations do people  
> place
>   on the system? Will it be tolerated that sometimes a legitimate call
>   gets blocked by the system? ("I lost my bag so I need to call my  
> wife
>   from a borrowed phone of a stranger to arrange <whatever>?", ...)
>
>   Which rate of false positives is acceptable to people?
>
>   This ties very much into "will this be a complementory mode of
>   communication or replace an existing one with all the current
>   expectations?".
>
> I think we have a hard time evaluating the proposals unless we do not
> share a common understanding of the environment in which this solution
> is supposed to work.
>
> The discussion of Closed / Semi-Open / Open groups is helpful, but  
> does
> not cover the full complexity and the background needed.
>
> Second point: Yes, outsourcing the decision to the user is the safe
> answer from a legal point of view, but end-users are in most cases not
> up to the task.
>
> In my opinion, the percentage of users which will be willing to
> configure their anti-SPIT rules is in the low single digits. A good
> number might cope with a single knob with five positions ranging from
> "open" to "restrictive", but a significant number of users just will
> not be able to do any configuration on their side. (This of course
> also depends on the answer to the first question.) Just imagine that
> you might be replacing the phone your grandmother uses. Don't assume
> Web-access (let alone web-savviness) at the user side. We're not  
> talking
> about IM clients with their rich user interface and PC-affine  
> userbase.
>
> (I wouldn't even assume SIP to the UA. Just because a PBX or a telco
> accepts calls via SIP, it doesn't mean the phone itself is using
> SIP. For example, our PBX at nic.at uses H.323 internally, but is SIP
> (+ENUM) enabled when talking to the outside world. Think of Asterisk
> installations with IAX phones. Or gateways bridging SIP calls into
> legacy PBXs.)
>
> Third question: Why do we hope that this framework can address the
> (potential) SPIT-problem and why wouldn't it also be applicable to
> e-mail and IM?  Maybe there is a good answer to this, e.g. the legacy
> deployment, strong identity, communication structure (few big players
> vs. lots of small systems), willingness to work with buddy-lists, ...
>
> What are really the differences? If the same principles also apply to
> email, then why don't we formulate the solution in a more protocol
> independent way?  Wouldn't it be a lot better to have a generic RUCUS
> framework, covering both SMTP and SIP and whatever else might be  
> needed?
>
> Applying the same logic to email is also a good reality-check with
> regards to deployment. I see this as a good "defend your thesis" -
> question.
>
> Forth questions: What is the 0-hypothesis? SPIT or legit call? Or is
> this completely left to the user's preference?
>
> Most of the proposed criteria are indications for legit calls  
> (hashcash,
> payment-at risk, ID, captcha) which only make sense if the default
> action is "block". This means that plain old SIP is likely to be
> blocked. Is this correct? Can we live with that?
>
> Question 5: The list of proposed anti-spit mechanisms is quite long,
> and if a positive handshake using one of these is needed (e.g.
> payment-at-risk) to let the call proceed, then what happens if sender
> and receiver support disjunct sets of algorithms? Bad luck, call
> blocked?
>
> What does this imply for the introduction of new algorithms?
> At what point can I as a user start to require a RFC9999-style
> reputation score > 42? What happens if one of the larger operators
> doesn't support that? Can I afford to block them? Do I have to  
> manually
> whitelist them? Given that, what's their incentive to actually  
> implement
> RFC9999?
>
> 5a) The most effective SPIT-prevention methods (except whitelists)
> will be those which make the sender to put something valuable on the
> table when placing a call.  That can be a reputation score, some
> payment-at-risk scheme, or plain old termination fees (which are
> marvelously effective against SPIT).
>
> For any scheme which involves real money, some sort of contractual
> relation must exist between the parties (at minimum, via some common
> settlement platform), which significantly raises the chance that both
> parties do not find a common method. Such methods might thus work
> between larger enterprises and telcos, but I strongly doubt that these
> schemes can work in a communication structure which resembles the e- 
> mail
> world.
>
> /ol
> -- 
> // Otmar Lendl <[e-mail]>, T: [phone] - 33, F: - 933
> // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
> // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [e-mail]
Phone: [phone]  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP