On Jan. 30th, 2008, I sent the following to the sipping list. It is a good summary of some of my thoughts on the RUCUS problem statement and on which basic premises need to be sorted out first.
…
Triggered by Hannes’ posting of the rucus BoF proposal, I had a closer look at framework-spit-reduction-02. Here are my thoughts on the whole framework.
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 on 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.
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 provides an 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 it 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.
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 number of users which will be willing to configure their anti-SPIT rules is in the low single digit percents. 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.
(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. Or think of Asterisk installations with IAX phones.)
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), …
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? 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?
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 some of the larger operators don’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.