Subject: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 22:08:31 -0500

Thanks for writing this, its a good topic to discuss.

One thing that wasn't clear; what is the benefit of signaling something 
as spam to my proxy, as opposed to just putting the sender on a black 
list. We have mechanisms defined already for that, for example. I 
suspect its around sharing of the spam classification with other users 
in the domain. Its worth discussing this.

Seems easier if you just send the entire sip message as content rather 
than picking apart pieces of it.

The mechanism is clearly intended to be between a UA and a proxy in its 
own domain; however I didn't find that stated till much deeper in the 
document. This should be clear up front.

In terms of specific protocols, I think SUB/NOT is a very poor choice. 
The proxy will require a subscription to EVERY UA, and the events will 
be infrequent. This means a lot of overhead for little data. I think you 
are much better off with an asynchronous push, either PUBLISH or even 
non-sip. Maybe a REST interface or something.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Feb 2008 10:16:04 +0200

Hi Jonathan,

thanks for your feedback.

You are right that this mechanism does not make a lot of sense if you 
consider an architecture that uses authorization policies and whitelists 
in particular.
It makes some sense when you consider these statistical learning 
techniques that require "good" and "bad" examples to learn.

This is obviously a -00 draft and I believe we should end up with this 
work is more something along the lines of Peter's work

http://www.xmpp.org/extensions/inbox/error-abuse.html
where there is communication between proxies rather than between the end host and the proxy. 

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 26 Feb 2008 09:47:56 +0100

Hannes,

> You are right that this mechanism does not make a lot of 
> sense if you consider an architecture that uses authorization 
> policies and whitelists in particular.

Wrong...
In the case a spammer will get through the "white list and authorization
policies" framework then you have an additional weapon to just report abuse
which is automatic and not manual (call my friend and tell him).

Telling it to your proxy could be a way of updating your authorization 
policies (maybe even update your personal black list at the domain)
and to share info on the caller with the domain (to get to a domain-wide
reputation system, with all pros and cons)

> It makes some sense when you consider these statistical 
> learning techniques that require "good" and "bad" examples to learn.

Again wrong...
The feedback can be also linked to "binary" decisions like:
if I send a bad feedback for a caller "deny him from calling me
for today" or "next time challenge him with a CAPTCHA"

> This is obviously a -00 draft and I believe we should end up 
> with this work is more something along the lines of Peter's work
> 

I agree there must be many updates to the draft (proxy to proxy
communication is one of them) and I will take into account
the valuable point of Jonathan when submitting the next version.

Saverio

> > One thing that wasn't clear; what is the benefit of signaling 
> > something as spam to my proxy, as opposed to just putting 
> the sender 
> > on a black list. We have mechanisms defined already for that, for 
> > example. I suspect its around sharing of the spam 
> classification with 
> > other users in the domain. Its worth discussing this.
> >
> > The mechanism is clearly intended to be between a UA and a proxy in 
> > its own domain; however I didn't find that stated till much 
> deeper in 
> > the document. This should be clear up front.
> >
> > be infrequent. This means a lot of overhead for little 
> data. I think 
> > you are much better off with an asynchronous push, either 
> PUBLISH or 
> > even non-sip. Maybe a REST interface or something.
> >
> > Thanks,
> > Jonathan R.
> >
> >
> >   
> 

============================================================
Dr. Saverio Niccolini
Senior Researcher
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 283201
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 26 Feb 2008 10:21:17 +0100

Hi Jonathan, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jonathan Rosenberg
> Sent: Tuesday, February 26, 2008 4:09 AM
> To: [email-masked]
> Subject: [Rucus] comments on draft-niccolini-sipping-spam-feedback-00
> 
> something as spam to my proxy, as opposed to just putting the 
> sender on a black list. We have mechanisms defined already 
> for that, for example. I suspect its around sharing of the 
> spam classification with other users in the domain. Its worth 
> discussing this.

Putting senders on a black list might be good for a subset of users but not others. This also depends on how those blacklists are managed. Therefore, the approach to give feedback from users to a spam system, i.e., sharing knowledge among users. 

> 
> Seems easier if you just send the entire sip message as 
> content rather than picking apart pieces of it.
> 
> The mechanism is clearly intended to be between a UA and a 
> proxy in its own domain; however I didn't find that stated 
> till much deeper in the document. This should be clear up front.
> 
> The proxy will require a subscription to EVERY UA, and the 
> events will be infrequent. This means a lot of overhead for 
> little data. I think you are much better off with an 
> asynchronous push, either PUBLISH or even non-sip. Maybe a 
> REST interface or something.

We're open to discuss the protocol choice for doing this. The SUB/NOT approach is a first attempt to integrate this with SIP and is open for further discussions.

  Martin

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 26 Feb 2008 10:26:26 +0100

Hi Hannes, 

> On Behalf Of Hannes Tschofenig
> Sent: Tuesday, February 26, 2008 9:16 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Rucus] comments on 
> draft-niccolini-sipping-spam-feedback-00
> 
> Hi Jonathan,
> 

Not fully true. I would call authorization policies and whitelists as the first line of defense, but not the ultimate. Authorization policies and whitelists are also known from email spam mitigation. However, we all know that they help but they are not the overall cure for the spam problem.

> http://www.xmpp.org/extensions/inbox/error-abuse.html

Yet another early work at a different venue.

> between the end host and the proxy. 

That is another area of interest which does not preclude what we are talking about

  Martin

> events will

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 26 Feb 2008 13:08:03 +0200

Hi Saverio,

being wrong twice could be a post-submission deadline syndrome...

Some comments inline:

> which is automatic and not manual (call my friend and tell him).
Hmmm. Might be.
Certainly not my personal #1 choice.

> reputation system, with all pros and cons)
regarding the updating of the authorization policies: but then this 
would be another mechanism for updating policies in additional to the 
already standardized and already implemented way of doing it.

> for today" or "next time challenge him with a CAPTCHA"

But this would be another way of modifying policies in addition to XCAP.

Ciao
Hannes

>> content rather 
>>> In terms of specific protocols, I think SUB/NOT is a very 
>>>       
>> poor choice. 
>>