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

["Saverio Niccolini" <[e-mail]>]

Hi Hannes,

>  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).

I agree that there is the need to define up to which level
this info get propagated to the sender domain, I think this
requires special considerations and if this info is part of the
SIP message terminating a call (e.g. BYE) then the proxy
should be ablew to strip it out if need (or if policies decide
to do so)

Cheers,
Saverio

> 
> 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.
> > > >> Onephrase 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
> >  
> > 
> 

============================================================
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