Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft RUCUS charter

["Jan Seedorf" <[e-mail]>]

Dear Hannes,

> I think we should put Henning's classification somewhere in 
> our documents.
I also like Henning's classification because it narrows down where the problem with botnets regarding SPIT is.

> > - Uses credentials, spams addresses in addressbook: 
> whitelists don't 
> > help, but at least the sender can be identified and 
> fixed/fined/taken 
> > offline.
I fully agree: this is the problem and the "compromised identity" then needs to be identified and blocked. One question then is, how can we share the identification of a not-trustworthy identity (as perceived by end-users or domains) among SIP-entities/domains. One building block I see here clearly is
http://www.ietf.org/internet-drafts/draft-niccolini-sipping-spam-feedback-00.txt
for giving users the possibility to indicate that some identity may not be trustworthy anymore (e.g., because it got compromised in the sense Henning describes above). Additionally,
http://tools.ietf.org/html/draft-wing-sipping-spam-score-01
and
http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam-score-semantics-00.txt
offer a solution for signalling such information between entities. Note that in the semantics draft we tried to point the importance of having a precise meaning associated with a SPIT score.

 - Jan

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> Hannes Tschofenig
> Sent: Friday, February 22, 2008 12:16 PM
> To: Signaling TO Prevent SPIT
> Cc: Brian Azzopardi; [e-mail]; Juergen Quittek
> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft 
> RUCUS charter
> 
> I think we should put Henning's classification somewhere in 
> our documents.
> 
> I had a chat with Peter Saint-Andre this week and he reported 
> me about problems they had with malicious users (potentially 
> using the XMPP servers for file sharing) in their XMPP server 
> infrastructure. He told me that their community is looking 
> into a mechanism to allow one domain to report problems to 
> another domain. This would correspond to Henning's 2nd 
> category below and a mechanisms similar to the one described 
> in 
> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp
> am-feedback-00.txt
> would be useful (expect that it would not be run between the 
> end host and the VoIP provider but between two VoIP providers).
> 
> Ciao
> Hannes
> 
> PS: I put Peter on CC in case I misunderstood something.
> 
> Henning Schulzrinne wrote:
> > There are three sub-cases of bot nets:
> >
> > - Just uses host, without credentials: identity-based whitelisting 
> > works (subject to the usual problems with whitelisting)
> >
> > - Uses credentials, but spews randomly: unlikely that the recipient 
> > will have that person in their whitelist, so still manageable.
> >
> > - Uses credentials, spams addresses in addressbook: 
> whitelists don't 
> > help, but at least the sender can be identified and 
> fixed/fined/taken 
> > offline.
> >
> > I'm not trying to downplay bot nets, just that this is a bit more 
> > nuanced.
> >
> > Henning
> >
> > On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote:
> >
> >   
> >> Dan,
> >>
> >> I am afraid that we may have to hit the ground running. 
> Email spam is 
> >> already a big industry with well established operators. 
> Spewing out 
> >> SPIT instead of email spam is just another 'product' for them.
> >> Only amateur SPITers will use spitter and other such tools - the 
> >> professional ones already have the infrastructure in place 
> and they'd 
> >> be irrational not to reuse it for SPIT - they will just short- 
> >> circuit to your step 5.  We do need to think deeply about 
> botnets - 
> >> they are the principal means of sending spam and have been for at 
> >> least the last 2 years.
> >>
> >> Regards,
> >>
> >> Brian Azzopardi - Senior Business Analyst GFI Software - 
> www.gfi.com
> >>
> >>
> >> From: [e-mail] [mailto:[e-mail]] On  
> >> Behalf Of Dan York
> >> Sent: 19 February 2008 21:24
> >> To: Juergen Quittek
> >> Cc: [e-mail]; Signaling TO Prevent SPIT
> >> Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter
> >>
> >> Juergen (and Saverio and others),
> >>
> >> I appreciate the point you are raising here.  My interest and  
> >> passion are in networking, communication and security.  To me,  
> >> botnets are both incredibly fascinating and incredibly 
> terrifying.   
> >> I agree with you that botnets very certainly may be the biggest  
> >> source of SIP spam in the future.
> >>
> >> Here's my problem:
> >>
> >>      We have to crawl before we can walk and before we can run.
> >>
> >> Let's say that this is the (incredibly simplistic view of the)  
> >> evolution of email spam:
> >>
> >> 1. Someone figures out that they can send advertisements 
> to a range  
> >> of email addresses they have collected.
> >> 2. Someone realizes that they can add those addresses to a 
> "mailing  
> >> list" to easily send to a large number of addresses.
> >> 3. Tools are developed that automate the collection of 
> addresses and  
> >> the sending out of messages.
> >> 4. At a certain time, there are enough people using email 
> out there  
> >> that this whole area of email advertising is a huge financial  
> >> marketplace. Companies/entities set up server farms to 
> just send out  
> >> tons of email messages. (Defenders blacklist those servers.)
> >> 5. Those "servers" get distributed into massive botnets 
> and are then  
> >> able to avoid blacklisting, etc.
> >>
> >> I have absolutely no doubt that SIP spam will 
> unfortunately follow  
> >> the exact same trajectory. We're already seeing the tools to  
> >> automate SPIT (here's one: 
> http://www.hackingvoip.com/tools/spitter.tar.gz 
> >>  ).  At some point we will hit my #4 when there are enough people  
> >> using SIP *with publicly accessible SIP addresses* that it 
> becomes  
> >> financially lucrative enough for the larger automation to occur -  
> >> and following on the heels of that will be the botnets.  It will  
> >> happen.  To me it's not a question of IF but rather WHEN.
> >>
> >> Right now, though, we're still in my steps 1-3 as people start to  
> >> get SIP endpoints and realize how they can abuse them.
> >>
> >> My concern about adding the focus on botnets into RUCUS is 
> the fact  
> >> that we can easily get distracted into looking at how to solve  
> >> bigger issues and not get done the smaller issues that we can  
> >> perhaps address today.
> >>
> >> Let's face it, probably all of us on this list would be 
> categorized  
> >> as early adopters who like to explore cutting edge 
> technologies.  We  
> >> like to chase bright shiny objects and what is new and sexy and  
> >> interesting.  Let's say that you have a choice at the next 
> IETF to  
> >> listen to either:
> >> 1. a presentation on a SIP header to pass a "spam score" value  
> >> between a SIP proxy and a UA; or
> >> 2. a presentation about SIP botnets, how they are constructed and  
> >> the threats they pose.
> >> I would expect that probably 90% of us would choose the 
> botnet talk.  
> >> (No disrespect intended to the spam-score folks, just using an  
> >> example.) The reality, though, is that the spam score discussion  
> >> might be far more useful in moving us toward solutions that will  
> >> help us with the people abusing SIP systems today.  I 
> don't want to  
> >> wake up some day and find out that while we've been having 
> a ton of  
> >> discussions about botnets, some idiot meanwhile is repeatedly  
> >> connecting to my SIP server and pumping our voicemail 
> system full of  
> >> SPIT.
> >>
> >> Maybe it's crazy on my part, but I want to see RUCUS have 
> a charter  
> >> that results in an achievable plan and architecture.
> >>
> >> Yes, we should consider botnets as a potential source of SIP spam  
> >> and, yes, the potential existence of SIP botnets should be 
> included  
> >> in our thinking about an architecture to address SIP spam 
> (so that  
> >> any architecture we come up with does not discount dealing with  
> >> botnets).  But I also think we need to stay focused on 
> what we can  
> >> do now about the threats that are out there today (before 
> it's too  
> >> late).   Let's crawl first, then walk, then run.
> >>
> >> My 2 cents,
> >> Dan
> >>
> >> On Feb 19, 2008, at 11:51 AM, Juergen Quittek wrote:
> >> Today, most of the spam email comes from bot-nets and recently
> >> email spammers started to send massively from compromized
> >> valid email accounts.  I do not see why this would not become
> >> also the biggest source of SIP spam in the future.
> >>
> >> Consequently, we should address this issue when developing an
> >> architecture for reducing SIP spam in the RUCUS WG.  The
> >> architecture should be general enough for covering also means
> >> that reduce SIP spam from bot nets and compromized accounts
> >>
> >> Whether or not to work on this problem is being discussed
> >> highly controversially in the IETF. But considering that the
> >> RUCUS BoF is targeted at establishing not a regular working
> >> group, but an RFC 5111 Exploratory Group, I do not think it
> >> would be appropriate to exclude such work from the beginning.
> >>
> >> It should rather be part of the exploratory work to find out
> >> whether or not reducing SIP spam from bot nets is a target
> >> worth to be attacked by the IETF.
> >>
> >> -- 
> >> Dan York, CISSP, Director of Emerging Communication Technology
> >> Office of the CTO    Voxeo Corporation     [e-mail]
> >> Phone: [phone]  Skype: danyork  http://www.voxeo.com
> >> Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
> >>
> >> Bring your web applications to the phone.
> >> Find out how at http://evolution.voxeo.com
> >>
> >>
> >>
> >>
> >>
> >>
> >> DISCLAIMER
> >> The information contained in this electronic mail may be  
> >> confidential or legally privileged. It is for the intended  
> >> recipient(s) only. Should you receive this message in 
> error, please  
> >> notify the sender by replying to this mail. Unless 
> expressly stated,  
> >> opinions in this message are those of the individual 
> sender and not  
> >> of GFI. Unauthorized use of the contents is strictly prohibited.  
> >> While all care has been taken, GFI is not responsible for the  
> >> integrity of the contents of this electronic mail and any  
> >> attachments included within.
> >>
> >> This mail was checked for viruses by GFI MailSecurity. GFI also  
> >> develops anti-spam software (GFI MailEssentials), a fax 
> server (GFI  
> >> FAXmaker), and network security and management software (GFI  
> >> LANguard) - www.gfi.com
> >>
> >> _______________________________________________
> >> Rucus mailing list
> >> [e-mail]
> >> http://www.ietf.org/mailman/listinfo/rucus
> >>     
> >
> > _______________________________________________
> > spitstop mailing list
> > [e-mail]
> > https://listserv.netlab.nec.de/mailman/listinfo/spitstop
> >   
> 
> _______________________________________________
> spitstop mailing list
> [e-mail]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
> 
_______________________________________________
Rucus mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/rucus