Re: [Sipping] [spitstop] Reducing Unwanted Communications using SIP (RUCUS)

[Cullen Jennings <[e-mail]>]

Hi All,

We are going to approve this BOF request thought I think we still need  
to refine many details about the BOF.  We are in the process of  
forming an [e-mail] mailing list for the BOF but  due to the  
transition of the ietf services from NSS to AMS, I'm not sure how long  
this will take, In the meantime I would like to ask folks to use the  
spitstop mailing list for discussion of this BOF.

(and please don't do what I just did and CC sipping)


Thanks, Cullen


On Jan 21, 2008, at 12:54 AM, Hannes Tschofenig wrote:

> Hi all,
>
> I have submitted a BoF request to form an Exploratory Group, an
> experiment introduced in RFC 5111. The main idea for this time-limited
> project is to work out the larger picture for dealing with unwanted
> communication attempts in SIP.
>
> Here is the most recent BoF proposal description:
> http://www.tschofenig.priv.at/bof-rucus.txt
>
> Feedback appreciated.
>
> Ciao
> Hannes
>
> _______________________________________________
> spitstop mailing list
> [e-mail]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop

_______________________________________________
Sipping mailing list  http://www.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
From [e-mail]  Thu Jan 31 23:07:04 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4C2133A6865;
	Thu, 31 Jan 2008 23:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.047
X-Spam-Level: 
X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=0.093,
	BAYES_20=-0.74, J_CHICKENPOX_32=0.6]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id B-1LHinYzJtR; Thu, 31 Jan 2008 23:07:02 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9CB983A6840;
	Thu, 31 Jan 2008 23:07:02 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5B0F43A6841
	for <[e-mail]>; Thu, 31 Jan 2008 23:07:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id LjKdKnF0csB8 for <[e-mail]>;
	Thu, 31 Jan 2008 23:07:00 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by core3.amsl.com (Postfix) with SMTP id 549113A67E1
	for <[e-mail]>; Thu, 31 Jan 2008 23:06:59 -0800 (PST)
Received: (qmail invoked by alias); 01 Feb 2008 07:08:31 -0000
Received: from proxy1-nsn.nsn-inter.net (EHLO [217.115.75.229])
	[217.115.75.229]
	by mail.gmx.net (mp001) with SMTP; 01 Feb 2008 08:08:31 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19KhQo1WkNKvRNLbMgBgNZMsOomESanX+AAKWToEr
	vNpoStJH4D/DuL
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2008 09:08:30 +0200
From: Hannes Tschofenig <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Otmar Lendl <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Y-GMX-Trusted: 0
Cc: [e-mail]
Subject: Re: [Sipping] RUCUS / framework-spit-reduction-02
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/sipping>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/sipping>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

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





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
>   

_______________________________________________
Sipping mailing list  http://www.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