Re: [Rucus] Operator-assisted SPIT filtering (was Re:SPITfromoperator)

["Avasarala Ranjit-A20990" <[e-mail]>]

Hi Luc

Actually operator is in the loop in the sense that by offering the Communication Barring service. This is the enhancement to Incoming Communication Barring service as defined in 3GPP TS 22.173.  Here the operator offers the enhanced ICB service and the terminating users indicate to the network (operator) that a particular caller / call is unwanted in nature and wish to block the caller from further calling. Once the operator receives this request from the user, the operator would create a black list (could be an additional one to if there is already one existing) and add the caller details to the list.

Next time when a call from the same caller arrives, the black list for the called user is checked and if there is an entry for the calling user, his or her call is rejected. 

In SIP based networks, this mechanism can be achieved by proposing a new protocol value "block" for the SIP Reason header which can be appended to SIP BYE message or SIP 4xx message to block the caller either during call termination or call alerting stages.  The sip server at the operator looks for the Reason header in the incoming BYE or 4xx message and if the protocol value is "block" retrieves the block details and updates the black list for the called user.

More details on this mechanism are defined in  http://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00.

Comments welcome

Thanks
 
Regards
Ranjit

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, July 09, 2009 7:42 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re:SPITfromoperator)

When I hear that spit solutions must be "operator independent", I feel that some basic facts from an email perspective need to be recalled, because the points that are being discussed in this thread are only relevant to a nice world with what is still very small amounts of spit.

We would simply not be conversing by email right now if ISPs were not filtering 80% to 99% of abusive emails (notice I did not say "spam" on purpose) and preventing them from reaching your computer. Perhaps we would still be using faxes (?) if the email filtering had been left as an exclusive responsiblity of the end-user. Email would be dead, in short.

Of course the called party must have some control over the filtering, based on his own criteria, which are not those of the operator. Therefore a caller blacklist, managed by the end-user and hosted in the terminal or by the operator, can be an interesting functionality, but its usefulness will depend on how easy it is for the caller to adopt a new identity. A mechanism for reporting spit to the operator or to a third party (like law enforcement for instance) might perhaps be more useful, but only if it can be established that the reported spit is illegal. Legislation on spit is far from being clearly established yet, anywhere in the world, and will probably be late by a couple of battles.

The filtering criteria of the operator are different from the end-user's. The goal of the operator is to protect the service from being submerged by spit, thus destroying its business model (no business model, no service, I'm sorry). Competing email operators do exchange information on abusive email traffic (with FBLs - feedback loops), because what is hurting one is hurting all email providers, small or large. They also use real time blocklists (RBL) which they manage themselves if they have the resources, or which are provided by third parties.

What is interesting is that even though legislation on spam is more mature, email providers strictly speaking do not "block spam" at network level, they block what they consider as "abusive email". That's for 2 reasons: first, in most jurisdictions, fortunately, operators do not have the right to filter content. The second reason is simply the huge scale of the spam phenomenon. However, email is still a comunication tool of acceptable quality and great usefulness to all, citizens and the global economy alike. With most email providers, the amount of false positives or false negatives is exceedingly small in relation to the quantity of trash they have to process every second. And because they know this, authorities tolerate the filtering applied by email providers on their own criteria.

I am sorry if all of the above is obvious, but my number one fear is to see the mistakes of the smtp world be repeated in the sip world. With voip calls gradually becoming so cheap as to become almost as free as email, we must be extra careful, and we must not adopt exclusionary stances before the problem is solved. I sincerely hope that spit will never reach email spam levels and that more control on spit filtering can be handed over to the user, but keeping the operator out would be a mistake.

Regards,
Luc
(true, I work for an operator; true, I am involved in www.maawg.org)

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De la part 
> de Avasarala Ranjit-A20990 Envoyé : jeudi 9 juillet 2009 14:04 À : 
> Pars Mutaf; David Schwartz Cc : Rucus BoF Objet : Re: [Rucus] 
> Operator-assisted SPIT filtering (was Re:
> SPITfromoperator)
> 
> True. That is the reason why an Operator cannot mark any caller or 
> call as spam. Only the target users can mark a particular caller or a 
> call as unwanted or malicious and may want to block the caller from 
> further calling.
> 
> Regards
> Ranjit
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Pars Mutaf
> Sent: Thursday, July 09, 2009 5:31 PM
> To: David Schwartz
> Cc: Rucus BoF
> Subject: Re: [Rucus] Operator-assisted SPIT filtering (was Re: SPIT
> fromoperator)
> 
> Hello,
> 
> On Thu, Jul 9, 2009 at 2:49 PM, David Schwartz<[e-mail]>
> wrote:
> >
> > Hi
> >
> >> What is the advantage of operator marking and forwarding
> the message,
> 
> >> over the cell phone marking the message and storing marked as SPIT?
> >
> > The operator has much more information to base a decision on
> (including input he gets from the endpoint) than the endpoint has.
> > The operator can "share" information better with other users
> (including ones who did not actually mark the particular
> caller) as well. > Email systems have been doing this for years where 
> a spam indication by one of its members is propagated to others.
> 
> Is there any reference for this? (if not too difficult to find any).
> In my view, there may exist messages marked as spam by one user, that 
> may not be considered as spam by other users.
> I mean, users may have different spam criteria.
> 
> In any case I would suggest that these points be clarified. 
> They don't seem obvious to me.
> 
> Thanks,
> 
> pars
> 
> >
> >> Perhaps the operator would have more information about SPITers and 
> >> can perform better filtering on behalf of users? (I'm not
> sure about
> >> that). This could be clarified?
> >
> > My point is, that regardless of the actual SPAM indication
> harvesting
> technique (e.g. the receiving user "blocked" the call), without the 
> ability to warn others as well the information is of limited value - 
> hence my reference to the Wing draft.
> >
> >> Or it is an energy conservation issue?
> >
> > :)
> >
> > Thanks,
> >
> > pars
> >
> >
> _______________________________________________
> Rucus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rucus
> _______________________________________________
> Rucus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rucus
> 
_______________________________________________
Rucus mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rucus