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

From: Otmar Lendl <[email-masked]>
Date: Wed, 30 Jan 2008 17:56:16 +0100

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 <[email-masked]>, T: +43 1 5056416 - 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dan York <[email-masked]>
Date: Thu, 31 Jan 2008 10:03:05 -0500

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

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Feb 2008 09:08:30 +0200

Hi Otmar,

thanks for the detailed response. This is a good discussion at the 
architectural level.
I would like to respond to a few of your questions; more comments later.

* Vision of the future SIP communication

I believe there will be a mixture of big players together with very 
small onces. If we don't provide solutions for the small players 
(including persons that decide to deploy their own SIP server) then 
someone else will do it, most likely just using a different protocol.

I certainly agree that the solution space will look differently when we 
just consider 5 really big players operating the entire infrastructure.

* Integration with the legacy infrastructure

You are certainly right that the aspect of legacy infrastructure (or 
interworking with other protocols) needs to be addressed. Many of the 
benefits of the protocols and protocol extensions that are being 
developed in the IETF will not be available to those who just focus on 
legacy technology.

Some of the references we listed in the paper deal with legacy 
infrastructure as well but certainly with very restricted functionality. 
Example: CAPTCHA usage

I can even imagine that legacy equipment attached to VoIP network will 
suffer most since their mechanisms for defense will be limited.

* Classification of the communication behavior

I came up with this classification (Closed / Semi-Open / Open groups) since I thought it would be useful. It might not be the best and most complete one but shows where some of the mechanisms are more powerful. I would be happy if someone could point me to a better classification of communication behavior -- I am sure that there is a lot of literature in that space but I just did not find anything appropriate. 

For me it is clear that for certain groups there is no generic mechanism that can be applied in order to provide a solution. Example: Emergency Services.
There are just cases where aggressive blocking is not really helpful and other techniques need to be applied. 

* Applicability to Email and IM

I am not an expert in email spam. Hence, I don't know what is applicable 
to email as well. There are certainly technical and procedural 
differences between email spam and VoIP / IM spam. Some of the technical 
aspects are documented in Jonathan's document. There are obviously 
similarities as well, for example, the work on strong identities (see 
DKIM in relationship with SIP Identity). As a preparation for the BoF I 
have had chats with folks working in the email spam space and Jim Fenton 
was willing to share his experience with the fight against spam with us 
at the BoF. We should obviously learn from the email spam lesson.

The IM case / presence case is interesting since most of us already got 
used to "restricted" communication in the sense that there are policies 
involved. Try to send me a message; I have to add you to my white list 
first. Hence, user behavior has changed a lot with respect to the 
"everyone can contact everyone without restrictions" principle we know 
from the PSTN.
* Usability of policies

This is a challenging topic. In various places in the IETF we have 
worked on policies that are supposed to be used by at the end host. 
Nevertheless, there is no assumption that they are written (in the form 
of the XML language) by the user itself. Instead, the entire policy 
handling should be invisible to the user as much as possible. How this 
can best be done is something that has certainly to be studied more 
closely; the capabilities of the device will certainly have a lot of 
impact on the user interface as well.

* Default policy setting

The specific policy setting is up to the person that writes these 
policies. Discussions in GEOPRIV and other places lead to the conclusion 
of many folks that blacklists in general are not that great when the 
system provides an easy way to mint identities.

Additionally, one has to consider that the policies are very context 
dependent. For example, some of us don't want to get called by a 
co-worker in the middle of the night.

We are, however, not suggesting to block calls when caller's identity 
cannot be found in the white list. In that case there need to be ways to 
execute additional mechanisms, such as leaving a message on an answering 
machine or running through a turing test to ensure that you are indeed 
talking to a human and not a bot.

* Value of certain technical solutions to deal with the SPIT problem

It is true that some specific solutions have disadvantages when used 
alone. You mentioned the payment approach. The currently described 
approach requires a lot of infrastructure to be in place in order to 
work; unfortunately also infrastructure that is not widely available. 
That's certainly a drawback. Maybe there are other solution approaches 
that would work better -- nothing else has been published in this space 
as far as I know.

The list of theoretically available mechanisms is quite large. Depending 
on the architectural approach, the assumptions and the requirements a 
number of mechanisms have to be dumped into the trashcan.

Regardless of my comments to some of the issues you raised you seem to 
have a quite different architectural model in mind. Would you like to 
explain what you had in mind?

Ciao
Hannes

Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping