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

["Tschofenig, Hannes" <[e-mail]>]

Hi Saverio, 

> 
> Hi all,
>   
> > * leave it to the user whether he wants to get something 
> > filtered or treated differently, but
> 
> I think we all agree on this point and this is also what makes the
> solution legally-compliant:
> the user is anyway in control and the operator/provider just offer
> a set of functionality to the user, either the users wants to
> use themor it leaves to the operator/provider to make decision
> on his/her behalf, but an agreement has to be in place
Sounds good to me. 

> 
> > * 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.
> 
> this is a completely different point, and I think info exchange
> between provider is important.

I also agree that this is a somewhat different story. 

 As Hannes said maybe not so important
> to be standardized first, anyway this info exchange is exactly what is
> detailed in our "scenarios" draft (see interface 'b'):
> http://tools.ietf.org/id/draft-niccolini-sipping-spitstop-00.txt

I have read it. I don't agree that it is only interface 'b' but the interface language is maybe confusing as such. 
For example, a receiving side wants to return information about the fact that a call or message was SPIT. 
Then, there is the question whether this information is only made available to his/her outbound proxy (his/her VoIP provider) or all the way towards the other end (mostly useful for debugging purpose; needs to be analysed whether an adversary could make use of it somehow).

Ciao
Hannes

> Cheers,
> Saverio
> 
> > 
> > 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.     [phone]
> > > Fax:     [phone]
> > > e-mail:  [e-mail] 
> > > ============================================================
> > > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > > London W3 6BL Registered in England 2832014
> > >  
> > >  
> > > -----Original Message-----
> > > From: Charzinski, Joachim [mailto:[e-mail]]
> > > Sent: Monday, June 18, 2007 10:16 AM
> > > To: Tschofenig, Hannes; SIPPING LIST
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > >> 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; [e-mail]; 
> > [e-mail]; 
> > >> [e-mail]; [e-mail]
> > >> Cc: [e-mail]
> > >> 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 
> > >> [e-mail] for questions on 
> current sip Use 
> > >> [e-mail] for new developments of core SIP
> > >>
> > >>     
> > > ----------------------------------------------------------
> > > Nokia Siemens Networks
> > > Joachim Charzinski
> > > Principal Innovator
> > > Machtlfinger Str. 1
> > > D-81379 Muenchen
> > > Germany
> > > Tel: [phone]
> > > [e-mail]
> > > 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 
> > > [e-mail] for questions on current sip Use 
> > > [e-mail] for new developments of core SIP 
> > > _______________________________________________
> > > spitstop mailing list
> > > [e-mail]
> > > https://listserv.netlab.nec.de/mailman/listinfo/spitstop
> > >   
> > 
> > _______________________________________________
> > spitstop mailing list
> > [e-mail]
> > https://listserv.netlab.nec.de/mailman/listinfo/spitstop
> > 
> 
> ============================================================
> Dr. Saverio Niccolini
> Senior Research Staff Member
> Network Laboratories, NEC Europe Ltd.
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.     [phone]
> Fax:     [phone]
> e-mail:  [e-mail]
> ============================================================
> NEC Europe Limited Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL Registered in England 2832014
>  
> 


_______________________________________________
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