Subject: [Sipping] updated sip-spam I-D

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Oct 2004 06:45:15 -0400

Folks,

I've just submitted an update to the sip-spam draft. Until it appears in 
the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-spam-01.txt

Here are the diffs:

* added Jon Peterson as co-author

* added text on reputation services as a means for preventing spam

* added text on using address obfuscation in websites as a technique. 
Included
a discussion on enum as a target for spammers

* added text on limited use addresses and the way in which presence and
buddy list systems can help with them

* add recommendation for a transition mechanism to strong identity

* added a discussion on session vs. page mode and the implications on
spam prevention

* made it clear that white lists are superior to black lists, due to the
ease of changing addresses. Refocused the white list discussion on IM 
systems
as the prototypical example.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: "David" <[email-masked]>
Date: Mon, 25 Oct 2004 15:43:17 +0200

Hi Jonathan.

It would appear to me that the consent models are being derived from both
email and IM and as such have a yes/no criteria for acceptance or rejection
of messages. Person X can either contact me or not. 

Why not explore a more web like model where pages are classified into zones
vis-à-vis security. In this implementation, a user defines the security
policy of his browser (e.g. accepting cookies etc,) and can then browse
unhindered in "secure"
zones while being prompted in suspicious ones.

In applying this to voice, let's introduce levels of trust (similar to the
reputation score you mention) using some sort of tag (perhaps attached to
the Asserted ID). The callee would then be able to custom define his
preferences in the end device based on these levels - each end user is
empowered to set his own policy regarding spam or other security related
issues. The level can be set high for calls with certificate asserted IDs,
lower for calls coming from trusted zones, lower still for untrusted
callers, and lowest for spam or other security violations. Security level
screening can be implemented either at some downstream proxy or at the UA.

As an example, in the case of voice spam a user can decide that any call
with security level 1 (not verified) should be automatically blocked, calls
with level 2 (bad reputation or few praises) should be automatically sent to
voice mail, calls with level 3 (so so reputation or positive reputation)
could be sent a Turing test and calls with level 4 could be automatically
accepted (white list). The value of making this decision in the end device
is that the user could then take advantage of phone features such as for
example, different rings for the varying levels of security.

David Schwartz 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Monday, October 25, 2004 12:45 PM
> To: sipping
> Subject: [Sipping] updated sip-spam I-D
> 
> Folks,
> 
> I've just submitted an update to the sip-spam draft. Until it 
> appears in the archives, you can pick up a copy at:
> 
> * added text on limited use addresses and the way in which 
> presence and buddy list systems can help with them
> 
> * added a discussion on session vs. page mode and the 
> implications on spam prevention
> 
> * made it clear that white lists are superior to black lists, 
> due to the ease of changing addresses. Refocused the white 
> list discussion on IM systems as the prototypical example.
> 
> 
> Thanks,
> Jonathan R.
> -- 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/2004
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/2004