Subject: [Sipping] WG: leaving it to the user (topic; SPIT)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 18 Jun 2007 09:27:08 +0200

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; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Charzinski, Joachim" <[email-masked]>
Date: Mon, 18 Jun 2007 10:16:18 +0200

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:[email-masked]] 
> Sent: Monday, June 18, 2007 9:27 AM
> To: SIPPING LIST
> Subject: [Sipping] WG: leaving it to the user (topic; SPIT)
> 
> An: Tschofenig, Hannes; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
----------------------------------------------------------
Nokia Siemens Networks
Joachim Charzinski
Principal Innovator
Machtlfinger Str. 1
D-81379 Muenchen
Germany
Tel: +49 89 722 46803
[email-masked] 
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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 19 Jun 2007 12:31:48 +0200

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:  [email-masked]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

-----Original Message-----
From: Charzinski, Joachim [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 10:16 AM
To: Tschofenig, Hannes; SIPPING LIST
Cc: [email-masked]
Subject: [Sipping] RE: leaving it to the user (topic; SPIT)

Best regards

	Joachim.

> An: Tschofenig, Hannes; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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
> 

Think before you print

_______________________________________________
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: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jun 2007 18:30:31 +0200

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:
> spitstop mailing list
> [email-masked]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 23 Jun 2007 12:56:44 -0400

Just to add to this: Instead of thinking just about consumer ISPs,  
consider the typical case of how email spam filtering works in large  
enterprises. At Columbia, for example, the IT department runs  
SpamAssasin. Anything with a score about 9 is rejected by the server  
and the user doesn't get a choice. Other email is labeled, but  
delivered. I suspect that some variation of this approach is fairly  
common practice.

Feedback about the call (for example, including blocking information  
in the BYE message) would be useful.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jun 2007 20:09:17 +0200

Hi Henning,

Henning Schulzrinne wrote:
> and the user doesn't get a choice. 

I don't think that this approach is allowed in all jurisdictions. But it 
would be easy to improve that situation.

> Other email is labeled, but delivered. I suspect that some variation 
> of this approach is fairly common practice.
Labeling is certainly a good idea. Whether you need to return more 
information -- I don't know.

> in the BYE message) would be useful.
I think so too.

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 26 Jun 2007 13:27:50 +0200

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

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

Cheers,
Saverio

> > -- 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.
> >
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >  
> [email-masked]; 
> >> I am both very pleased and somewhat dismayed reading the 
> draft IETF 
> >> document.
> >>
> >> 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 
> >> outlook client when e.g. gmail shows it can be done at incoming 
> >> server level.
> >> 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.
> >>
> >> 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
> > 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
> >
> >

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 26 Jun 2007 13:38:30 +0200

Hannes, Henning,

> I don't think that this approach is allowed in all 
> jurisdictions. But it would be easy to improve that situation.

I do not think the situation is too easy to improve, as soon
as you get into legal matters it is always going to be longer
and more difficult than what you expect.
Anyway this is the kind of scenario where a 'SPIT oracle' just
computes the scores and the call gets filtered depending on
this, I think Hannes' draft on authorization policies requirements
and solution can be an example of this. We also support this 
kind of solution, actually it is exactly what we have been
implementing and running in the last one and a half year
(the scoring system and the blocking of calls over a certain threshold),
we will be having a demo at IPTCOMM (http://iptcomm.org/)
showing exactly this system (VoIP SEAL: http://iptcomm.org/page10/page10.html)
This also happens to be in New york before next IETF, maybe
it is easy for some of you to just drop by there...
 
> Labeling is certainly a good idea. Whether you need to return 
> more information -- I don't know.
> 

Then we kind of agree that this fits into the SPIT prevention and
mitigation work, since this work is described in:
http://tools.ietf.org/id/draft-niccolini-sipping-feedback-spit-03.txt
maybe I should submit a new version extracting only th epart related to
feedback from user to server and we can discuss this next time.

Cheers,
Saverio

> providers 
> >> intelligent decisions and you might want to execute the 
> enforcement 
> >> at the VoIP provider rather than at the end host.
> >>
> >> Ciao
> >> Hannes
> >>
> >
> >
> >

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 26 Jun 2007 13:45:54 +0200

Hi Saverio, 

> on his/her behalf, but an agreement has to be in place
Sounds good to me. 

> between provider is important.

I also agree that this is a somewhat different story. 

 As Hannes said maybe not so important
> 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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 26 Jun 2007 13:55:06 +0200

Hi Hannes,

> 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

> > > >> Onephrase which i find smacks of choosing the path of least 
> > > >> resistance is: