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

[Otmar Lendl <[e-mail]>]

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