Subject: [Sipping] SPAM, consent & their requirements

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 6 Sep 2005 23:02:18 +0200

All,

It's been some time (last message dates back to 25th of July) since the drafts related to the Consent framework, its requirements and SIP SPAM were discussed on this list. A brief look at the pending drafts overview shows that several are waiting for this work to finish.

Assuming there is still interest in this, I have a question (or rather observation) for discussion:
I think a difference between SPAM and a DoS attack is, that SPAM can be addressed by preventing delivery to the end user, while a DoS attack requires prevention of delivery to the end user's device. Obviously the latter accomplishes the former, so a consent framework that prevents delivery to the device also prevents SPAM

My question is: are any more "lightweight" solutions being considered that would perhaps not solve DoS attacks but could help prevent SPAM?
I could think of some (perhaps obvious) approaches such as an endpoint-based whitelist using requestor Identity or (if not available) a shared secret per buddy

Regards,

Jeroen

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 8 Sep 2005 12:38:48 -0500

On Sep 6, 2005, at 4:02 PM, Jeroen van Bemmel wrote:

> All,
>  
> It's been some time (last message dates back to 25th of July) since 
> the drafts related to the Consent framework, its requirements and SIP 
> SPAM were discussed on this list. A brief look at the pending drafts 
> overview shows that several are waiting for this work to finish.
>  
> I think a difference between SPAM and a DoS attack is, that SPAM can 
> be addressed by preventing delivery to the end user, while a DoS 
> attack requires prevention of delivery to the end user's device. 
> Obviously the latter accomplishes the former, so a consent framework 
> that prevents delivery to the device also prevents SPAM
>  
> My question is: are any more "lightweight" solutions being considered 
> that would perhaps not solve DoS attacks but could help prevent SPAM?
> I could think of some (perhaps obvious) approaches such as an 
> endpoint-based whitelist using requestor Identity or (if not 
> available) a shared secret per buddy
>

The IESG will require us to have an adequate solution to the DoS issues 
for advancing the list-services documents, independently of any SPAM 
issues.

We have a SPAM-related draft at:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-01.txt

--
Dean