Re: [spitstop] [Sipping] RE: leaving it to the user (topic; SPIT)

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Sat, 23 June 2007 16:30 UTC

Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I28Va-0003nD-9F; Sat, 23 Jun 2007 12:30:46 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1I28VZ-0003lR-7l for sipping-confirm+ok@megatron.ietf.org; Sat, 23 Jun 2007 12:30:45 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I28VY-0003lJ-Sd for sipping@ietf.org; Sat, 23 Jun 2007 12:30:44 -0400
Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I28VT-0000NS-SW for sipping@ietf.org; Sat, 23 Jun 2007 12:30:44 -0400
Received: (qmail invoked by alias); 23 Jun 2007 16:30:34 -0000
Received: from p54984EE0.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.78.224] by mail.gmx.net (mp034) with SMTP; 23 Jun 2007 18:30:34 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19w9U4ZEcpw9YXFr4R7yIXZt0B4dGOHIcDSQ3lIqy AysceKC0L8Sx7E
Message-ID: <467D4AA7.2030502@gmx.net>
Date: Sat, 23 Jun 2007 18:30:31 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Signaling TO Prevent SPIT <spitstop@listserv.netlab.nec.de>
Subject: Re: [spitstop] [Sipping] RE: leaving it to the user (topic; SPIT)
References: <0D22E3C1A7D7A843B12BF8C6F0A4075802149661@MCHP7IDA.ww002.siemens.net> <F640B5F5BA19954DB4812EB39575BB0E020915F2@MCHP7I5A.ww002.siemens.net> <113091BD57179D4491C19DA7E10CD6960150E431@mx1.office>
In-Reply-To: <113091BD57179D4491C19DA7E10CD6960150E431@mx1.office>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
Cc: SIPPING LIST <sipping@ietf.org>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org

Hi Saverio,
Hi Joachim,

I guess the important point is

* leave it to the user whether he wants to get something filtered or 
treated differently, but
* you might want to make information available to the VoIP providers 
network to allow some of these statistical methods to produce 
intelligent decisions and you might want to execute the enforcement at 
the VoIP provider rather than at the end host.

Ciao
Hannes


Saverio Niccolini wrote:
> Dear Joachim,
>
> I agree with the argument to see many calls in order to decide.
>
> Anyway, legally speaking there is also the opposite argument why you
> should actually leave it to the user:
> -- if you suppress communications before they reach the end user
> you may have legal troubles (at least in Germany I know about this
> kind of law on suppression of communication), the user needs to 
> give explicit consent to suppress communications on his behalf.
>
> Thus, the evaluation is indeed to be done in the network while the
> final decision has to be on the user if he did not agree to have the 
> communication directed to him suppressed by the operator.
>
> Note that the user can also configure the terminal to suppress
> communication without the phone to ring (if the sapm level estimated
> by your operator is too high for you to accept the call).
>
> For this and similar topics we have been working on the draft about
> signaling interfaces (to share the estimation done in the network with
> the terminal, like X-spam level in email spam), see:
> http://tools.ietf.org/id/draft-niccolini-sipping-spitstop-00.txt
>
> Cheers,
> Saverio
>
> ============================================================
> Dr. Saverio Niccolini
> Senior Research Staff Member
> Network Laboratories, NEC Europe Ltd.
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.     +49 (0)6221 4342-118
> Fax:     +49 (0)6221 4342-155
> e-mail:  saverio.niccolini@netlab.nec.de
> ============================================================
> NEC Europe Limited Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL Registered in England 2832014
>  
>  
> -----Original Message-----
> From: Charzinski, Joachim [mailto:joachim.charzinski@nsn.com] 
> Sent: Monday, June 18, 2007 10:16 AM
> To: Tschofenig, Hannes; SIPPING LIST
> Cc: spitstop@listserv.netlab.nec.de
> Subject: [Sipping] RE: leaving it to the user (topic; SPIT)
>
> there are two more arguments for not "leaving it to the user":
>
> 1. legal: In current telephone regulation, callers have a 
>    right to have their ID hidden from the callee. 
>    Current implementations transport the ID up to the last 
>    (soft) switch etc and then anonymize the caller. That is, 
>    a function in the network can but an end user device cannot 
>    include caller ID (and what else do you really have in the 
>    INVITE message) in evaluating spit probabilities. 
> 2. statistical: A function in the network sees many more calls -  
>    also by the same caller - than a function in an end user 
>    device. For statistical evaluations, you need a LOT of calls 
>    as a basis. 
>
> Best regards
>
> 	Joachim.
>
>   
>> -----Original Message-----
>> From: ext Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]
>> Sent: Monday, June 18, 2007 9:27 AM
>> To: SIPPING LIST
>> Subject: [Sipping] WG: leaving it to the user (topic; SPIT)
>>
>> Here is a forward of a review sent to us. 
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Albert Caruana
>> Gesendet: Freitag, 15. Juni 2007 17:33
>> An: Tschofenig, Hannes; hgs+ecrit@cs.columbia.edu; dwing@cisco.com; 
>> jdrosen@cisco.com; david.schwartz@kayote.com
>> Cc: internet-drafts@ietf.org
>> Betreff: leaving it to the user
>>
>> Hi
>>
>> I am very interested in security issues of emerging technologies.
>>
>> This is my personal opinion.
>>
>> I am both very pleased and somewhat dismayed reading the draft IETF 
>> document.
>>
>> The framweork proposed is great. The current statements to at best 
>> help the user to make the decision as to what to refuse as SPIT and 
>> what to accept I find are decisions being taken without considering 
>> the user. Your mileage may vary.
>> One phrase which i find smacks of choosing the path of least 
>> resistance is:
>> "For example, it is mandatory to pass full control of SPIT filtering 
>> to the end user, as this minimises legal problems".
>>
>> The legalproblems may need to be ironed out in other e.g. ITU and ETSI 
>> task forces but should not be a hindrance to creating mechanisms 
>> properly preventing criminal abuse of computer systems such as the 
>> acts of generating spit and spam.
>>
>> Users i know are furious over the need to set up spam filters e.g. in 
>> outlook client when e.g. gmail shows it can be done at incoming server 
>> level.
>> Even better would be egress capture of spam at the source instead of 
>> at the target server, relieving the internet of spam load before it 
>> happens.
>>
>> In my opinion, while a voip phone looks like a phone, the user is 
>> usually not in a position to understand the legal or technical 
>> differences between voip and PSTN/POTS technology.
>>
>> Leaving decisions up to the user is like assigning the responsibility 
>> for correct functioning of the suspension, braking and fuel injection 
>> system of a car to the driver instead of to the engineer tuning the 
>> car.
>> I do not know whether you could drive one of the first automobiles 
>> where the driver had to adjust the timing so that the engine would run 
>> smoothly at start, later when running - and differently for slow revs 
>> and for high revs... Even Formula 1 drivers are backed by a whole team 
>> of engineers and radio-diagnosis and control tools in order to do such 
>> work on the fly.
>>
>> I would thus like to recommend that you incorporate such preventive 
>> medicinal thinking into the excellent framework being proposed and 
>> which you have submitted, with a view to relieving the ever-increasing 
>> numbers of non-technical users of voip  from the responsibility of 
>> deciding what is the correct level of spit filtering they should 
>> tolerate - and with the aim of preventing spit at source and ensuring 
>> audit trails are created which enable the perpetrators to be located 
>> and punished under no matter what legal system is in place anywhere.
>>
>> regards
>> Albert Caruana
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP Use 
>> sip-implementors@cs.columbia.edu for questions on current sip Use 
>> sip@ietf.org for new developments of core SIP
>>
>>     
> ----------------------------------------------------------
> Nokia Siemens Networks
> Joachim Charzinski
> Principal Innovator
> Machtlfinger Str. 1
> D-81379 Muenchen
> Germany
> Tel: +49 89 722 46803
> Joachim.Charzinski@nsn.com
> http://www.nokiasiemensnetworks.com/global/
>
> Think before you print
>
> Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft: München / Registered office: Munich - Registergericht: München / Commercial registry: Munich, HRA 88537 - WEEE-Reg.-Nr.: DE 52984304 - Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH - Geschäftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer - Sitz der Gesellschaft: München / Registered office: Munich - Registergericht: München / Commercial registry: Munich, HRB 163416 
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
> _______________________________________________
> spitstop mailing list
> spitstop@listserv.netlab.nec.de
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>   



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP