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

[Hannes Tschofenig <[e-mail]>]

Hi Jan,

Jan Seedorf wrote:
> Hi Hannes,
>
>   
>> Let's take an example:
>> When Henning's host is compromised and a bot is using 
>> Henning's account to send me spam then I would contact 
>> Henning (by using various ways) to tell him that something is 
>> wrong with his PC/phone/etc. I would not tell my VoIP 
>> provider that there is something wrong with Henning's account. 
>> Typically, this will lead to more problems rather than less 
>> -- such as no communication to Columbia University anymore 
>> because my VoIP provider just blocks all calls from that domain.
>>
>> (Just to reflect my experience with email problems in the company....)
>>     
> I understand these problems. And we need to discuss them. My point was just that with respect to "but at least the sender can be identified and fixed/fined/taken offline" the spam-feedback draft is a building block. You are suggesting that when a user presses a "this was SPIT" button, this does not trigger a message to the provider of the callee but instead an offline (e.g., email) message to the caller saying "hey, I received SPIT from your account, do something!". That is another way of using the feedback-mechanism, and quite interesting I would say.
>
> I fully agree that "automatic" and "aggressive" blocking as today in the e-mail world is a probelm we need to consider.
>
>   
The usage case of the SPIT reporting between the end host and the VoIP 
provider is not for Henning's case
"

- Uses credentials, spams addresses in addressbook: whitelists don't  
help, but at least the sender can be identified and fixed/fined/taken  
offline.

"

I don't want folks in my buddy list to get fined; I want to tell them 
that they have a problem with their PC. I don't need a protocol to tell 
them that.

However, I see it being useful for reporting SPIT between providers in 
case of the following category:

"
- Uses credentials, but spews randomly: unlikely that the recipient will 
have that person in their whitelist, so still manageable.

"

and in the case where someone does not use a white list then he can obviously report something to it's VoIP provider when he does not know that person. 


Ciao
Hannes

>  - Jan
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]] 
>> Sent: Friday, February 22, 2008 12:51 PM
>> To: Jan Seedorf
>> Cc: Signaling TO Prevent SPIT; Brian Azzopardi; 
>> [e-mail]; Juergen Quittek
>> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft 
>> RUCUS charter
>>
>> Hi Jan,
>>
>>
>> Jan Seedorf wrote:
>>     
>>> 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-feedb
>>     
>>> ack-00.txt
>>>   
>>>       
>> Let's take an example:
>> When Henning's host is compromised and a bot is using 
>> Henning's account to send me spam then I would contact 
>> Henning (by using various ways) to tell him that something is 
>> wrong with his PC/phone/etc. I would not tell my VoIP 
>> provider that there is something wrong with Henning's account. 
>> Typically, this will lead to more problems rather than less 
>> -- such as no communication to Columbia University anymore 
>> because my VoIP provider just blocks all calls from that domain.
>>
>> (Just to reflect my experience with email problems in the company....)
>>
>>     
>>> 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-s
>>     
>>> emantics-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.
>>     
>>>   
>>>       
>> I haven't read draft-seedorf-sipping-spam-score-semantics-00.txt yet. 
>> Comments later.
>>
>>
>> Ciao
>> Hannes
>>
>>     
>>>  - 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