Subject: [Rucus] Draft RUCUS charter

From: Juergen Quittek <[email-masked]>
Date: Tue, 19 Feb 2008 17:51:09 +0100

Dear all,

I had a look at the draft charter that Hannes set up on his RUCUS
web page and I think it is targeting the right direction.  However,
I suggest extending the scope and have attached a modified version
of the draft charter below.

My only major problem with the current version is that it fully
builds on the recommendations given in RFC 5039, namely

  - Strong Identity
  - White Lists
  - Solve the Introduction Problem
  - Don't Wait Until It's Too Late

I do not think that these approaches are wrong, but that they
do not cover what I consider to be the most important issue in
reducing SIP spam.

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.

Below please find my suggestion for extending the charter.
Main  differences to the current draft are the new third
paragraph  (starting with "Strong identities ...") and some
additions to the end of the fifth paragraph.

Thanks,

    Juergen

====================

The Session Initiation Protocol (SIP) defines a system for
user-to-user multimedia communications. Therefore, it is
susceptible to unwanted communication attempts.  RFC 5039
analyzes the problem of spam in SIP and examines various
possible solutions that have been discussed for email and
considers their applicability to SIP.

RFC 5039 gives good, high-level recommendations regarding
future work, namely

    * Strong Identity
    * White Lists
    * Solve the Introduction Problem
    * Don't Wait Until It's Too Late

Strong identities and white lists will be essential in a well
protected environment but do not solve the problem in the open
Internet. In the open Internet compromised accounts and bot-nets
are the major source of email spam today and expected to be the
major source of SIP spam in the future.

Among the many individual solution building blocks that are
discussed in RFC 5039 (including content filtering, black lists,
white lists, consent-based communication, reputation systems,
address obfuscation, limited use addresses, turing tests,
computational puzzles, payments at risk, circles of trust, and
many others) there is no framework outlined how various
mechanisms work together to produce a complete solution nor
does the document attempt to offer a ranking to determine
which solutions could form an initial set of candidate for
subsequent standardization.

This exploratory group chartered for one year aims to create a
venue where discussions on unwanted communication in SIP can
take place. The main goal of the group is to produce an
architecture document that outlines the interworking between
identified potential building blocks. The architecture will be
general to cover a range of scenarios including well protected
environment as well as the open Internet.

The group will consider prior work on SIP identity and related
techniques and will consult with privacy experts to deal with
the legal aspects of filtering communication attempts.

Out of the scope;
-- PSTN replacement
-- concrete algorithms for SIP spam prevention

_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 20:57:47 +0200

Hi Juergen,

thanks for your feedback.

The current charter proposal does not say indicate that

  - Strong Identity
  - White Lists

are the solution to the problem; it just indicates what RFC 5039 says.

I do,however, agree with you that we should explicitly indicate that we 
want to explore different architectural approaches. Even though white 
lists are quite common in today's instant messaging world they are more 
or less unknown in the PSTN. The user's behavior will be quite important 
to understand with some of these different approaches.

I agree that looking at botnets and similar mechanisms is useful. Still, 
I would avoid the term "open Internet" since it is somewhat fuzzy.

Regarding your paragraph:
"
"

We might need to ask the DKIM folks to better understand the current
state of the art in email spam. For example: Are compromised accounts 
really a major source of email spam today?

FROM:
The architecture will be

TO:
The architectural investigations should cover different threat
models, including those of compromised end hosts.

You wrote:
"
Out of the scope;

-- PSTN replacement
"

I agree with the second one but what exactly have you had in mind with 
PSTN replacement in this context?

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 19 Feb 2008 20:31:05 +0100

> protected environment but do not solve the problem in the 
> open Internet. In the open Internet compromised accounts and 
> bot-nets are the major source of email spam today and 
> expected to be the major source of SIP spam in the future.
> "
> 
> We might need to ask the DKIM folks to better understand the 
> current state of the art in email spam. For example: Are 
> compromised accounts really a major source of email spam today?

Compromised hosts are a source of spam today:
http://www.heise.de/newsticker/meldung/103711

the majority of email spam is coming from botnets:
http://www.marketwire.com/mw/release.do?id=817241

Thus we can not ignore this threat in RUCUS.

Cheers,
Saverio

---

From: Dan York <[email-masked]>
Date: Tue, 19 Feb 2008 15:23:37 -0500

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

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 22:25:06 +0200

Hi Saverio,

> Thus we can not ignore this threat in RUCUS.

I am certainly not ignoring this aspect.

I want to make sure that we capture the current state-of-the-art correctly.

Ciao
Hannes

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 19 Feb 2008 23:09:44 +0100

Hi Hannes,

> to understand with some of these different approaches.

I fully agree. This is an important study item.

> I would avoid the term "open Internet" since it is somewhat fuzzy.

Yes, there may be better terms. I just would like to express, that
outside of well protected environment, there may be a need for means
beyond strong identities and white lists. And these should be
investigated by the RUCUS EG.

> really a major source of email spam today?

Well, using 'compromized hosts' as you do below would be fine.
We can investigate the relevance of compromized accounts when
RUCUS is established.  (In Germany leading IT journals reported
today that compromized accounts are becoming relevant for email spam.)

> models, including those of compromised end hosts.

That's fine and probably less controversial.

> PSTN replacement in this context?

Sorry, these were my notes what to exclude.
But it is not yet elaborated.

Thanks,

    Juergen

---

From: "Brian Azzopardi" <[email-masked]>
Date: Wed, 20 Feb 2008 09:37:40 +0100

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 <http://team.gfi.com/www.gfi.com> 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan York
Sent: 19 February 2008 21:24
To: Juergen Quittek
Cc: [email-masked]; Signaling TO Prevent SPIT
Subject: [Rucus] Botnets, take 2... Re: Draft RUCUS charter

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:

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.

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.)

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.

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

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

-- 

 

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

---

From: "Fischer, Kai" <[email-masked]>
Date: Wed, 20 Feb 2008 10:20:38 +0100

Hi,
I think, in the past discussions two different issues (botnet and
identity theft) are combined, but need to be discussed / addressed
separately.

Most people consider with the term 'botnet' a number of captured hosts,
which will be used for attacks like DoS, SPAM or SPIT. They are using
the IP address identity of the captured host but not usually the
authenticated application identity. Here, mechanism like DKIM for email
SPAM or other approaches can counter such threats.

Identity theft is even more challenging to solve regardless if an attack
is initiated by a single captured host or in worst case a botnet of
captured host including identity thefts.

Kai

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dan York
	Sent: Dienstag, 19. Februar 2008 21:24
	To: Juergen Quittek
	Cc: [email-masked]; Signaling TO Prevent SPIT
	Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS
charter

	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:

	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

		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     [email-masked]
	Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
	Blogs: http://blogs.voxeo.com
http://www.disruptivetelephony.com

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 20 Feb 2008 11:17:43 +0100

> 
> I do,however, agree with you that we should explicitly 
> indicate that we want to explore different architectural 
> approaches. Even though white lists are quite common in 
> today's instant messaging world they are more or less unknown 
> in the PSTN. The user's behavior will be quite important to 

Ehm, yes and no. Whitelisting might be somewhat unknown for the PSTN network but not for PSTN end devices (i.e., phones). My phones at home, plus my mobile, can do whitelisting. However, the feature is not called whitelisting, but has different various names. The feature allows to define a set of phone numbers that are allowed to call my phone. If no phone number is provided during a call setup or the number is not listed, the call is not accepted or immediately rejected (configuration issue).  This is also configurable on a time of day basis.

> understand with some of these different approaches.
> 
> I agree that looking at botnets and similar mechanisms is 
> useful. Still, I would avoid the term "open Internet" since 
> it is somewhat fuzzy.

Aren't we in the IETF, i.e., have to deal with the Internet anyhow?

> compromised accounts really a major source of email spam today?

Yes, they are. See Dan's and my emails to this. Read the heise.de news message.

Regards,

  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: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Feb 2008 08:21:44 -0500

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,
>
> GFI Software - www.gfi.com
>
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Dan York
> 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:
>
> 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.
>
> 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.
>
> 2. a presentation about SIP botnets, how they are constructed and  
> the threats they pose.
> 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  
> 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  
> 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
>

---

From: Dan York <[email-masked]>
Date: Wed, 20 Feb 2008 09:28:46 -0500

Brian,

Again, I absolutely agree that botnets will potentially be the  
largest source of SIP spam in the future when the financial  
conditions are right for the botnet operators to branch out into SIP  
spam.

My point is this - today, in February 2008, why in the world would  
any botnet operator waste their time on doing so?  Where is the market?

Asked another way, how many of us *on this list* can accept SIP  
connections from **any random SIP endpoint** on the Internet?

That is the necessary condition for there to be a market for a botnet  
operator to spend the time to move into SIP spam. Otherwise, why  
bother? Email spam is undoubtedly far more financially lucrative.

Let's look at this another way:

1. How many of us are candidates for email spam? (i.e. our email  
address can accept email from any random email sender)
      - Answer: 100%  (subject to whatever anti-email-spam measures  
we've already got in place, but we are *candidates* anyway)

2. How many of us are candidates for PSTN voice spam? (a.k.a.  
telemarketers)
      - Answer: 100%  (we all have phones and can receive calls from  
anyone else out there on the PSTN)

3. How many of us are candidates for SIP voice spam?  (i.e. our SIP  
UA can accept SIP connections from any other random SIP endpoint)
      - Answer:  ???   1%?  2%?  5%?  10%?

In casual conversations with other people *within IETF* I have found  
that most folks I have spoken with cannot receive incoming SIP calls  
from any random SIP endpoint.  In some cases it is blocked by  
firewalls. In some cases their PBX, IP-PBX or home system simply  
isn't using SIP.

How many of us here on this RUCUS list can accept inbound SIP calls  
from any random SIP endpoint?
(I can, but anecdotally I seem to be in a minority.)

When the number of SIP endpoints that can be reached by any other  
random SIP endpoint is sufficiently large to be of interest, *that*  
is when I believe the botnet operators and other entities doing  
automated spam will pay attention to SIP spam.  Before that point,  
there is simply no ROI.

And if we don't have sufficient mechanisms in place by that time to  
deal with botnet-spewed SIP spam, we and our industry will suffer.

When is that "point"?  2008? 2009?  2010? 2020?  I don't know. I  
would expect it's probably not this year or next, but beyond that my  
crystal ball gets really murky.

So yes, we need to consider the potential future impact of botnets in  
our discussions and in our architecture decisions, etc.

But what I don't want to personally see is that this mailing list and/ 
or the RUCUS session in Philadelphia becomes so focused on SIP  
botnets that we don't deal with the more current issues that we can  
address today.

Dan

On Feb 20, 2008, at 3:37 AM, Brian Azzopardi wrote:

> 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,
>
> marketplace. Companies/entities set up server farms to just send  
> out tons of email messages. (Defenders blacklist those servers.)
> 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.
>
> as early adopters who like to explore cutting edge technologies.   
> We like to chase bright shiny objects and what is new and sexy and  
> talk. (No disrespect intended to the spam-score folks, just using  
> an example.) The reality, though, is that the spam score discussion  
> connecting to my SIP server and pumping our voicemail system full  
> of SPIT.
>
> 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,

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 20 Feb 2008 15:35:06 +0100

Hi,

just a small comment, RFC 5111 says:
"the goal of an Exploratory Group is to put in place the
prerequisites for formation of a Working Group"

Thus I do not think we should start excluding any direction
from the beginning, we are here to explore. RUCUS is not going
to be a normal WG but an exploratory one.

We should think of an architecture that is able to accomodate
many potential building blocks.

If, after the approval of RUCUS and during its lifetime, we realize
that some building blocks do not fit the big picture then we can drop
them. But not exclude them a priori.

Saverio

============================================================
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 2832014

> -----Original Message-----
> Sent: Tuesday, February 19, 2008 9:24 PM
> To: Juergen Quittek
> Subject: [spitstop] Botnets, take 2... Re: [Rucus] Draft RUCUS charter
> 
> 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:
> 
> Let's say that this is the (incredibly simplistic view of 
> the) evolution of email spam:
> 
> 3. Tools are developed that automate the collection of 
> addresses and the sending out of messages.
> 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.
> 
> 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 
> 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.
> 
> 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.
> 
> 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
>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 20 Feb 2008 15:40:26 +0100

Dan,

> Again, I absolutely agree that botnets will potentially be 
> the largest source of SIP spam in the future when the 
> financial conditions are right for the botnet operators to 
> branch out into SIP spam.
 
> So yes, we need to consider the potential future impact of 
> botnets in our discussions and in our architecture decisions, etc.

Then we have "Consensus"!
It seems we all agree then, let's just be sure that this is 
reflected in the charter proposal and we are all happy and
we will be able to have RUCUS as an exploratory WG.

> But what I don't want to personally see is that this mailing 
> list and/or the RUCUS session in Philadelphia becomes so 
> focused on SIP botnets that we don't deal with the more 
> current issues that we can address today.

Nobody is saying that, people only want to do not exclude some
building blocks from the beginning and work on the big picture
exactly as you want.

Saverio

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 20 Feb 2008 16:04:02 +0100

On 2008/02/20 15:02, Dan York <[email-masked]> wrote:

[.. good points ..]

> (I can, but anecdotally I seem to be in a minority.)

I am. (well, if you're selling user-ENUM, you kind of have to be.)

> crystal ball gets really murky.

My freshly polished crystal ball tells me that this point simply will
not be reached until a solution to the SPIT threat has been found and
deployed. (100% effectiveness is not needed, it just needs to be in the
same ballpark to what people tolerate in the PSTN world. The email
experience isn't tolerable.)

It's also conceivable that some intermediate equilibrium will establish
itself which is neither as closed/firewalled as today, nor as completely
open as the email world.

/ol
-- 
-=-  Otmar Lendl  --  [email-masked]  -=-
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: Dan York <[email-masked]>
Date: Wed, 20 Feb 2008 12:38:52 -0500

Saverio,

Point taken.  Count me as one who will look forward to the primer at  
the beginning of the RUCUS session about Exploratory Groups and their  
differentiation from Working Groups.

I guess my concern is that we've been doing a whole lot of  
"exploration" of the whole area of SIP spam/SPIT for several years,  
as can been seen by the numerous drafts that have been written by a  
host of folks on this list (including yourself) as well as RFC 5039.   
Admittedly, and perhaps this is the key point, the exploration has  
been done in an *unstructured* way as people investigated topics  
related to SPIT that were of interest to them.  The role of the RUCUS  
"EG" may be to provide the *structure* for that continued exploration.

I do, though, believe that we do need to move as best we can toward  
identifying the key actions we can start to take and the guidance we  
can start to give people for how to potentially address the issue.   
Hence my interest in an achievable plan and architecture.  I don't  
know when that magic point will be when we start seeing large volumes  
of SIP spam, but given as RFC 5039 points out: "Don't Wait Until It's  
Too Late". (And we know that any proposals we develop *do* take time  
to be first standardized and then actually deployed.)

Thanks for the feedback,
Dan

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 20 Feb 2008 10:14:06 -0800

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fischer, Kai
> Sent: Wednesday, February 20, 2008 1:21 AM
> To: [email-masked]; Juergen Quittek
> Cc: Signaling TO Prevent SPIT
> Subject: Re: [Rucus] [spitstop] Botnets, take 2... Re: Draft 
> RUCUS charter
> 
> Hi,

That is an excellent separation.

-d

> SIP server
> be included

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:00:53 +0200

Hi Juergen,

> investigated by the RUCUS EG.
I understand your motivation.

> today that compromized accounts are becoming relevant for email spam.)
The solution space for dealing with compromised hosts can become pretty 
large. I fear that we extend the work without bounds.
BUT:  I  do believe there is value in discussing this in the 
architecture phase even when we then have to conclude that most of the 
work that needs to be happening does not really belong in the IETF.

> But it is not yet elaborated.
OK.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:05:59 +0200

Kai, I believe it is useful to differentiate between these two cases.

Martin and Juergen indicate that botnets using identity theft are 
already getting common.
 
This would reduce the usefulness of white lists a bit. If such a botnet 
includes Alice's machine and her SIP UA calls me then this does not 
necessarily mean that my whitelist is ineffective; it would only be true 
if I Alice is in my buddy list.

Ciao
Hannes

Fischer, Kai wrote:
> spitstop mailing list
> [email-masked]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:06:13 +0200

Do you have some ideas on what should be done against botnets? Just 
wondering....

Ciao
Hannes

Brian Azzopardi wrote:
> ------------------------------------------------------------------------
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:15:47 +0200

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-spam-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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:33:19 +0200

I agree with Dan but at the same time I also agree with Saverio.

Here is the issue: Difficult security challenges often require 
complicated solutions.

The evil guy will pick the easy target's first. For me, an easy 
indication about the success of a specific technology is when you get 
the first spam. For example, when I look at my blog, Wiki, or roundup 
issue tracker then I have to admit that they are pretty successful on 
the Internet. Spammer exploit them. It would not make sense to target 
them if only a few folks use them. Hence, you raise the bar. Instead of 
allowing everyone to post comments and to register themself you put some 
additional mechanisms in place -- these mechanisms will typically be 
inconvenient for the users (for example, they have to go through a 
CAPTCHA test before posting something, posting is only allowed for 
members; I have to add them manually to the access control list, etc.).

The XMPP experience tells us something about this already and they use 
an email alike style of communication (hence they don't even have 
something like SIP Identity). The simple techniques work fine at the 
beginning but you have to raise the bar for the adversary as your 
technology becomes more successful. Email Spammers could just easily use 
their existing botnets and apply them to XMPP; sure. They did not do it 
because it does not create enough revenue for them -- email, Wiki's and 
Weblogs are much better. It might sound ironic but we have to make sure 
that the evil guys pick someone else and not SIP.

In our work we clearly need to differentiate between implementing and 
deploying it vs. writing documents. We can obviously quite easily write 
documents that address almost every problem we can imagine. That's not 
the issue. The challenge begins when all the stuff has to be deployed. 
When someone who hasn't followed IETF mailing list discussions suddenly 
sees 50 different mechanisms and extensions they will be confused. What 
should they do? They will not implement all; particularly not if they do 
not yet have a lot of problems. They will have to implement things 
incrementally. What should they start with?

Ciao
Hannes

Dan York wrote:
> "exploration" of the whole area of SIP spam/SPIT for several years, as 
> can been seen by the numerous drafts that have been written by a host 
> of folks on this list (including yourself) as well as RFC 5039.

---

From: "Jan Seedorf" <[email-masked]>
Date: Fri, 22 Feb 2008 12:42:47 +0100

Dear Hannes,

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

> > help, but at least the sender can be identified and 
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

> [mailto:[email-masked]] On Behalf Of 
> Hannes Tschofenig
> Sent: Friday, February 22, 2008 12:16 PM
> To: Signaling TO Prevent SPIT
> Cc: Brian Azzopardi; [email-masked]; Juergen Quittek
> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft 
> RUCUS charter
> 
> 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 
> 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
> 
> >> 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 - 
> >> Brian Azzopardi - Senior Business Analyst GFI Software - 
> www.gfi.com
> >>
> >>
> "mailing  
> http://www.hackingvoip.com/tools/spitter.tar.gz 
> the fact  
> categorized  
> botnet talk.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 13:50:57 +0200

Hi Jan,

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

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....)

> 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

>>> - Uses credentials, spams addresses in addressbook: 
>>>       
>> whitelists don't 
>>     
>>> help, but at least the sender can be identified and 
>>>       
>> fixed/fined/taken 
>>     
>>> offline.
>>>
>>>> I am afraid that we may have to hit the ground running. 
>>>>         
>> Email spam is 
>>     
>>>> botnets are both incredibly fascinating and incredibly 
>>>>         
>> terrifying.   
>>     
>>>> 1. Someone figures out that they can send advertisements 
>>>>         
>> to a range  
>>     
>> addresses and  
>>>> 4. At a certain time, there are enough people using email 
>>>>         
>> out there  
>>     
>>>> marketplace. Companies/entities set up server farms to 
>>>>         
>> just send out  
>>     
>>>> 5. Those "servers" get distributed into massive botnets 
>>>>         
>> and are then  
>>     
>>>> I have absolutely no doubt that SIP spam will 
>>>>         
>> unfortunately follow  
>>     
>>>> using SIP *with publicly accessible SIP addresses* that it 
>>>>         
>> becomes  
>>     
>>>> as early adopters who like to explore cutting edge 
>>>>         
>> technologies.  We  
>>     
>>>> interesting.  Let's say that you have a choice at the next 
>>>>         
>> IETF to  
>>     
>>>> listen to either:
>>>> 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  
>>     
>>>> 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  
>>     
>>>> and, yes, the potential existence of SIP botnets should be 
>>>>         
>> included  
>>     
>>>> in our thinking about an architecture to address SIP spam 
>>>>         
>> (so that  
>>     
>>>> 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  
>>     
>>>> 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  
>>     
>>>> develops anti-spam software (GFI MailEssentials), a fax 
>>>>         
>> server (GFI  
>>

---

From: "Fischer, Kai" <[email-masked]>
Date: Fri, 22 Feb 2008 13:03:53 +0100

> (Just to reflect my experience with email problems in the company....)

I don't assume that the sender of spam usually is a person I personally
know and whom I want to contact directly (still more personal
disturbance and effort). Applying very restrictive white lists allowing
only personal known people to contact me may be yes, but I expect that
this is not usual scenario (I have no email white list).

> Sent: Freitag, 22. Februar 2008 12:51
> To: Jan Seedorf
> Cc: Brian Azzopardi; [email-masked]; Signaling TO Prevent 
> SPIT; Juergen Quittek
> > I also like Henning's classification because it narrows 
> down where the problem with botnets regarding SPIT is.
> >
> >   
> > 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
> > 
> > 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,
> > 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.
> >   
> 
> start to

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 22 Feb 2008 13:07:29 +0100

Hannes, all,

> end host and the VoIP provider but between two VoIP providers).

Right, actually this is why we inserted this potential communication
interface in the SPITSTOP draft, see interface "b" among providers
in:
http://tools.ietf.org/html/draft-niccolini-sipping-spitstop-01#page-6

Saverio

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 22 Feb 2008 13:19:15 +0100

Hannes, all,

> 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.
> 

You do not contact Henning directly to tell him that something
is wrong. You have to rely on your infrastructure to take the
necessary countermeasures otherwise it is the anarchy...

That is why exchanging reputation of identities (as perceived by
end-users or domains) is an important building block.
Such reputation system (one of the points of RFC 5039) can be built
using mechanisms like feedbacks:
http://tools.ietf.org/html/draft-niccolini-sipping-spam-feedback-00
and spam scores:
http://tools.ietf.org/html/draft-wing-sipping-spam-score-01
of course there are privacy issues that apply (but this is 
a problem of reputation systems as well) :-)

It seems this list is converging to the point we tried to raise 
since 2006, I should be happy :-)

Saverio

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 14:29:46 +0200

Hi Kai,

Fischer, Kai wrote:
>> Henning's account 
>> -- such as 

The spammer is not known; however, for the case we are considering here 
the account of someone from your buddy list is being used for spamming. 
If you are spamming me then I would obviously get in touch with you and 
ask you what you want.

It is true that you have no email white list -- this is, however, a 
drawback for email that we don't need to repeat again.
Consider Instant Messaging, for example, many people us a mixture 
between white lists and black lists. Very common today!
For the PSTN there are obviously no white lists either

Ciao
Hannes

>> http://www.ietf.org/internet-drafts/draft-niccolini-sipping-sp
>>     
> am-feedback-00.txt
>   
>>>   
>>>       
>> Let's take an example:
>> Henning's account 
>> -- such as 
>> http://www.ietf.org/internet-drafts/draft-seedorf-sipping-spam
>>     
> -score-semantics-00.txt
>   
>>>>> - Just uses host, without credentials: identity-based 
>>>>>           
>> whitelisting 
>>     
>>>>> - Uses credentials, but spews randomly: unlikely that the 
>>>>>           
>> recipient 
>>     
>>>>>> they are the principal means of sending spam and have 
>>>>>>             
>> been for at 
>>     
>>>>>> least the last 2 years.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>  ).  At some point we will hit my #4 when there are 
>>>>>>             
>> enough people  
>>     
>>>>>> financially lucrative enough for the larger automation 
>>>>>>             
>> to occur -  
>>     
>>>>>> and following on the heels of that will be the botnets.  
>>>>>>             
>> It will  
>>     
>>>>>> 2. a presentation about SIP botnets, how they are 
>>>>>>             
>> constructed and  
>>     
>>>>>> the threats they pose.
>>>>>> example.) The reality, though, is that the spam score 
>>>>>>             
>> discussion  
>>     
>>>>>> might be far more useful in moving us toward solutions 
>>>>>>             
>> that will  
>>     
>>>>>> Yes, we should consider botnets as a potential source of 
>>>>>>             
>> SIP spam  
>>     
>>>>>> of GFI. Unauthorized use of the contents is strictly 
>>>>>>             
>> prohibited.  
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 14:30:05 +0200

Hi Jan,

Jan Seedorf wrote:
> 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
"

"

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

>> From: Hannes Tschofenig [mailto:[email-masked]] 
>> Sent: Friday, February 22, 2008 12:51 PM
>> To: Jan Seedorf
>> Cc: Signaling TO Prevent SPIT; Brian Azzopardi; 
>> [email-masked]; Juergen Quittek
>> 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:
>>> 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://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.
>>     
>>>   
>>>       
>>>> [mailto:[email-masked]] On Behalf 
>>>>         
>> Of Hannes 
>>     
>>>> Tschofenig
>>>> Subject: Re: [spitstop] [Rucus] Botnets, take 2... Re: Draft RUCUS 
>>>> charter
>>>>
>>>> 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 
>>>> would be useful (expect that it would not be run between 
>>>>         
>> the end host 
>>     
>>>>>> tons of email messages. (Defenders blacklist those servers.) 5. 
>>>>>> Those "servers" get distributed into massive botnets
>>>>>>         
>>>>>>             
>>>> and are then
>>>>     
>>>>         
>>>>>> between a SIP proxy and a UA; or 2. a presentation about SIP 
>>>>>> botnets, how they are constructed and the threats they pose.
>>>>>> 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.
>>>>>>
>> 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.
>>>>>>
>> target worth to 
>>>>>> be attacked by the IETF.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 14:33:46 +0200

I know. These mechanisms are known from the email world and also from XMPP.

But there is a some way to go between today's state of the art, namely 
largely no end-to-end SIP usage to a state where botnets steal your 
identity to bypass white lists.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 14:40:08 +0200

Hi Saverio,

> necessary countermeasures otherwise it is the anarchy...
Why wouldn't I contact him directly?

> a problem of reputation systems as well) :-)
There is a long way to go between a global reputation system and the 
drafts you mention above.

> since 2006, I should be happy :-)

Nobody is saying that these mechanisms do not exist on paper. They just 
have a quite challenging deployment story and the protocol issue is the 
least problematic thing to worry about: it is the trust relationships 
you have to establish between the VoIP provider. If you think about a 
model similar to email then you will have a hard time to establish such 
an infrastructure.

Ciao
Hannes

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 22 Feb 2008 13:49:53 +0100

> and the VoIP provider but between two VoIP providers).

That's correct. An early version is here:

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

> PS: I put Peter on CC in case I misunderstood something.

I'm on both spitstop and rucus, but I confess to finding the continued
sending to both lists a bit annoying. Can't we all just send to rucus
(and not spitstop) now? :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Fischer, Kai" <[email-masked]>
Date: Fri, 22 Feb 2008 13:55:58 +0100

Hi Hannes,

> Sent: Freitag, 22. Februar 2008 13:30
> To: Fischer, Kai
> Cc: rucus BoF; Jan Seedorf; Brian Azzopardi; [email-masked]; 
> Juergen Quittek

I think the assumption that a spammer is using only the buddies of the
captured account might be too limited. What does a spammer prevent to
spam also other persons, for whom he found the addresses in public
sources (and these people won't contact the 'captured' person directly
to give feedback since it is not known to them).
A countermeasure would be a white list, which configures that only buddy
are allowed to make a call to me. But than I don't get calls from
unknown persons, which I want to still receive. Yes, I can do an
authorization request in advance, but is this not also a form of spam
(and again I won't contact these persons directly).

> between white lists and black lists. Very common today!

Yes and it is the grey zone between white and black which causes
trouble.

Kai

---

From: Dan York <[email-masked]>
Date: Fri, 22 Feb 2008 08:00:45 -0500

> (and not spitstop) now? :)

+10

At this point in time RUCUS is now at 74 members and anyone on  
SPITSTOP who is NOT over on RUCUS has had **plenty** of notice that  
the discussion is moving to RUCUS (including Saverio's email to  
SPITSTOP directly mentioning this fact).

Can we all please take the action that if we are replying to a  
message with BOTH lists on it that we *remove* SPITSTOP from the  
recipients?

All of our already-overflowing inboxes will be much better for that.

Thanks,
Dan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 22 Feb 2008 14:12:59 +0100

> that the evil guys pick someone else and not SIP.

The way I put it is this: you don't have to be the fastest antelope in
the pack, but you had better not be among the slowest. :)

The main spam we've seen has been in groupchat rooms. In part this may
be because some of our rooms are archived, so that the conversations are
viewable on the web -- post links and have your spam immortalized for
all time (except we scrub the logs). In part it may be because rooms
feel semi-anonymous or IRC-like. In part it may be because you can annoy
more people this way.

We have also seen abusive traffic of a more nebulous nature (is it a
file sharing network, is it a botnet, is it some kind of distributed
application?), but that has not been spam-like as far as we can tell.

> incrementally. What should they start with?

IMHO it's critically important to have very good communication and
collaboration between developers, spec writers, and operators. I know
we've tried to maintain that in the XMPP community, but I don't have as
clear a handle on that in the SIP world.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 15:25:27 +0200

Hi Kai,

Fischer, Kai wrote:
>>>> (Just to reflect my experience with email problems in the 
>>>>         
>> company....)
>>     
>>>>     
>>>>         
>>> I don't assume that the sender of spam usually is a person 
>>>       
>> I personally
>>     
>>> disturbance and effort). Applying very restrictive white 
>>>       
>> lists allowing
>>     
>>> only personal known people to contact me may be yes, but I 
>>>       
>> expect that
>>     
> captured account might be too limited.

I was not saying that. We started with a discussion about botnets and 
there were claims that whitelists are useless with botnets.
Henning clarified that and described in what cases botnets have a 
negative impact on whitelist behavior.

>  What does a spammer prevent to
That's obviously something they can easily do.
Here comes the overall story into play: What are the underlying 
mechanisms we assume that are present?
If you assume that there are white lists in place then this will not 
cause too many problems;
If you assume that there are no white lists (as it is the case for the 
PSTN today) then you obviously run into a couple of challenges.

> (and again I won't contact these persons directly).
True. It is also a form of spam but certainly less annoying than calls 
in the middle of the night. There is obviously a tradeoff here.

Consider current Instant Messaging behavior: You can change your context 
when you like. Sometimes you want to get contacted from unknown persons 
and sometimes you don't. If you disable your whitelist and you suddenly 
get contacted by someone and it turns out that you don't like that 
person then it is your problem.
This is, however, a bit oversimplified since there are user types that 
cannot reject calls, such as people those folks answering your emergency 
call. They obviously have a hard time with white lists. Hence, we are 
looking at ways how to deal with these special user groups separately -- 
this is, for example, work done in ECRIT.
One important aspect is to deal with unauthenticated emergency calls or 
with calls that have contain faked location information since the attack 
would be primarily against the first responders (not the call taker 
itself).

> Yes and it is the grey zone between white and black which causes
Sure. Both forms of access control lists have drawbacks.
We discussed these aspects extensively when we worked on Common Policy 
and Presence Authorization Policy.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Feb 2008 15:42:34 +0200

> collaboration between developers, spec writers, and operators. 

We are extremely good at that part.

---

From: Dan York <[email-masked]>
Date: Fri, 22 Feb 2008 09:07:59 -0500

> the pack, but you had better not be among the slowest. :)

DY> The other way I've heard it is - what do you do if you and a  
friend are being chased by a bear? Just make sure you run faster than  
he does!

> application?), but that has not been spam-like as far as we can tell.

DY> Thank you for sharing the XMPP experience.  As others have  
already said, learning from how other protocols have dealt with this  
is critical so you feedback and insight is definitely appreciated.

> clear a handle on that in the SIP world.

DY>  If only we could....   The reality is that everybody and their  
brothers/sisters/mothers/fathers/uncles/aunts are all working with  
SIP in various forms.  The larger vendors and operators realize the  
value of standards and participate in the IETF and other SDOs to  
varying degrees. The larger they are, the more interop they do and  
therefore the more they care about standards.  Some startups are very  
concerned about standards, too, as well as a range of companies in  
between.

DY> Those of us who *are* involved with IETF are well connected and I  
think there is a high degree of good communication and collaboration.

DY> But then there are the zillion other companies that don't really  
care about standards (or don't understand them), simply want to make  
a buck, and take whatever paths they need to in order to get ahead.   
The world of "SIP trunking" is a bit like the proverbial "Wild West"  
right now with a whole crop of companies throwing softswitch/PBX  
software on some cheap PCs, buying upstream connectivity from one of  
the larger operators and... ta da... they're in the "SIP trunking"  
business offering cheaper PSTN connectivity.  You have a ton of new  
entrants offering SIP wired or WiFi handsets. Some of those companies  
are attentive to standards. Some don't understand IETF and just  
implement whatever RFCs or I-Ds they think they need to.  There's a  
lot of software companies out there that want to get into the  
"unified communications" game or want to tag along with Microsoft OCS  
or IBM Sametime that are throwing SIP interfaces onto applications  
without really understanding it all. As the results of the recent  
SIPit events show, we're getting *better* with SIP interop but we've  
still got a long way to go on many aspects.  (And of course we don't  
really help this in some ways... how many RFCs are we up to for  
"SIP"? How many pages was Jonathan's last "Hitchhiker's Guide to SIP"?)

DY> I believe we do need to encourage MORE companies to become  
involved (and make it easier for them to understand HOW to become  
involved).  I like the work groups like SIP Forum are doing with  
their SIPconnect initiative to try to help companies understand the  
"correct" way to implement SIP.  More efforts  like that and  
introductory/howto documents will only continue to help.

DY> In the meantime, I think there will continue to be the natural  
tension between those of us who implement RFCs correctly and are  
involved with the standards efforts and those out there who (out of  
lack of understanding or lack of caring) implement whatever they feel  
they need to in whatever way they think they need to.

Regards,
Dan

---

From: "Charzinski, Joachim (NSN - DE/Muenich)" <[email-masked]>
Date: Fri, 22 Feb 2008 16:07:32 +0100

Hi Hannes,

> For the PSTN there are obviously no white lists either
not quite. A lot of PSTN switches should have white lists 
already, it is just a question 
- if the operators allow user administration and
- if the users really appreciate using a voice interface 
  or a separate web login to administer those lists

Best regards

	Joachim.
 
----------------------------------------------------------
Nokia Siemens Networks

Joachim Charzinski
Principal Innovator

Visitor address: Machtlfinger Str. 1 / D-81379 Muenchen / Germany
Postal address: D-80240 Muenchen / Germany

Tel: +49 89 722 46803 / [email-masked] / http://www.nokiasiemensnetworks.com/global/ 

Think before you print

Nokia Siemens Networks GmbH & Co. KG - Sitz der Gesellschaft: München / Registered office: Munich - Registergericht: München / Commercial registry: Munich, HRA 88537 - WEEE-Reg.-Nr.: DE 52984304 - Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH - Geschäftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer - Sitz der Gesellschaft: München / Registered office: Munich - Registergericht: München / Commercial registry: Munich, HRB 163416
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 22 Feb 2008 19:07:35 +0100

> > 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 
> > 
> > ack-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).
> 

Then we agree that similar things should be there also for SIP
and for RUCUS.

Saverio

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 22 Feb 2008 19:22:40 +0100

> > You do not contact Henning directly to tell him that something is 
> > wrong. You have to rely on your infrastructure to take the 
> necessary 
> > countermeasures otherwise it is the anarchy...
> >   

-1- you are saying that if people in the world receive 1.000.000 spam
calls then they should generate an equal number of calls to let the
other people know? I am sure there are more intelligent things to do
than that...
-2- have you ever heard of reflection attacks when reading about DoS,
what if the purpose of the compromised account is not only to deliver
you a telemarketing call but also to move people to bring down
Henning's phone by calling him back?

I hope these two are enough to understand that what you 
suggest is in principle NOT the solution...

> There is a long way to go between a global reputation system 
> and the drafts you mention above.

I thought we are talking about the general architecture and its
building blocks... Those are building blocks that belong to the
general architecture. The way is long and if we wait until it is
too late there will be no end to the road, better start now then...

> > It seems this list is converging to the point we tried to 
> raise since 
> > 2006, I should be happy :-)
> >    
> Nobody is saying that these mechanisms do not exist on paper. 
> They just have a quite challenging deployment story and the 
> protocol issue is the least problematic thing to worry about: 
> it is the trust relationships you have to establish between 
> the VoIP provider. If you think about a model similar to 
> email then you will have a hard time to establish such an 
> infrastructure.

Are you saying that a model with white lists for calls would be
more acceptable then? That my mother (even if she learnt how to use
the PC since I am living abroad just to stay in contact with me)
would configure her white list and switch its authorization policies
every time she wants to be contacted by unknown people?
Are you aware of how many people nowadays do not use properly
presence indicators? (even skilled people)

I would say my mother would rely on the provider to filter the
vary bad calls on her behalf (using some sort of spam score and
reputation system) and if she receives a spam call every now and then
she would be able to press a button on her phone for "spam feedback"

And of course, she has some authorization policies (but not the one:
receive call only from white list...)

That is why the "white list" concept is not enough without the
"black list" concept. and I think it would be nonsense for RUCUS
to focus only on "white list" and related architecture
(remember that reputation is both "white" and "black"...)

Saverio

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 22 Feb 2008 21:49:32 +0100

> and the VoIP provider but between two VoIP providers).

I'm wondering what these kinds of feedback systems can do if either

* it's easy for the spitter to create new identities within the same
  domain

* it's easy for the spitter to create his own domain, and thus he 

  - can follow the protocol, and mint new indentities for each SPIT-run
  - or just forge the anti-spit feedback headers to indicate that no bad
    feedback had been received for this identity

In other words, don't all these ideas assume the the miscreants are
misbehaving clients using trustworthy service providers (which don't
allow mass-minting of accounts?)?

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 22 Feb 2008 21:56:42 +0100

> I also like Henning's classification because it narrows down where the problem with botnets regarding SPIT is.

Same here, Henning's classification is really helpful.

Reading the last 30 mails here on the list I have the feeling that we
first need a good classification of the possible scenarios in order
to be sure that whenever someone proposes an idea it can be made clear
in which setting this idea is supposed to help.

We shouldn't go into the details of SIP headers now.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 22 Feb 2008 22:18:44 +0100

> necessary countermeasures otherwise it is the anarchy...

No, not when strong identity is used. Just translate the scenario
to email: when I receive a PGP-signed mail (using a trusted key)
from a friend which contains a typical spam (V!ag_ra, 419, ...) then
I'll phone him up to tell him that he has a security problem.

> end-users or domains) is an important building block.

Yes, it can be helpful to simplify the initial contact problem. 

Positive reputation is useful, negative one will just lead to
the spitter getting a new account.

> a problem of reputation systems as well) :-)

Another trouble here is that if you want worldwide calling based on
a reputation system, you also need a reputation system which is used
worldwide and not a plethora of these. 

Who will be trusted to run it?

/ol

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Feb 2008 20:52:37 -0500

> other people know? I am sure there are more intelligent things to do

You are mis-understanding Hannes case. He was addressing the case  
where the sender is authenticated and known to the callee, i.e., a  
friend.

> suggest is in principle NOT the solution...

Please re-read the classification; you are talking about the 'random  
spewing' attack, in which case your concern is indeed valid. That  
attack is likely only stoppable by rate-limiting calls near the origin.

> presence indicators? (even skilled people)

White list configuration is a problem, but it can be largely  
automated. For example, we have proposed that successful bidirectional  
email communication and certain types of secured web interactions can  
be used to populate white lists.

This does mean that you'll have to use a lower-impact means to  
initially contact somebody. But that's pretty much how things work  
today, given that many phones are not listed in public directories. I  
admit that I much prefer people emailing me first, so that I can  
decide whether to give out my phone number.

> (remember that reputation is both "white" and "black"...)

For reasons others have mentioned, black lists are largely useless  
unless identities become extremely expensive and scarce. They are,  
however, useful to prevent the same compromised host from calling me  
again and again. (This is a well-known PSTN problem: Somehow, a fax  
machine gets hold of your voice number. The call fails, and then the  
fax machine dutifully redials once every 5 minutes. You either have to  
learn how to whistle like a modem, or you need a blacklist.)

Henning

---

From: "Jan Seedorf" <[email-masked]>
Date: Sat, 23 Feb 2008 11:20:12 +0100

Dear Otmar,

> Reading the last 30 mails here on the list I have the feeling 
> that we first need a good classification of the possible 
> scenarios in order to be sure that whenever someone proposes 
> an idea it can be made clear in which setting this idea is 
> supposed to help.
That is a very good point, I agree. Depending on the attack scenario (and there can be different ones as discussed on this list) and certain assumptions (e.g., attacker is using user credentials) we need to find out what architectural setting can help best. Differentiating between such scenarios would give us "a common ground" for discussion and help to avoid some confusion.

> We shouldn't go into the details of SIP headers now.
I agree.

 - Jan

> On Behalf Of Otmar Lendl
> Sent: Friday, February 22, 2008 9:57 PM
> To: [email-masked]
> Reading the last 30 mails here on the list I have the feeling 
> that we first need a good classification of the possible 
> scenarios in order to be sure that whenever someone proposes 
> an idea it can be made clear in which setting this idea is 
> supposed to help.
>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Sat, 23 Feb 2008 13:19:00 +0100

> Another trouble here is that if you want worldwide calling 
> based on a reputation system, you also need a reputation 
> system which is used worldwide and not a plethora of these. 
> 

You can have reputation system run among a federations of
providers.
And if you are assuming there are strong identities, you
are assuming you are using PKI then you must trust someone,
the same someone can be used to provide the reputation
system.

Anyway I must admit that I was making confusions among scenarios.

I agree that it is better to work on fixing scenarios and then
analyze architectures and solutions.

My only point is that I do not want to exclude any technical
solution now that we are starting exploring.

Saverio

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 23 Feb 2008 17:27:41 +0100

> the same someone can be used to provide the reputation

Sorry, but in order to run an effective and secure whitelist, no
PKI is needed. A centralized PKI to sign keys is just needed
if you want to base the whitelist on URIs and not on key-fingerprints.

> analyze architectures and solutions.

Ok, who writes the draft?

> solution now that we are starting exploring.

That's a fair point.

/ol

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Feb 2008 19:59:44 +0200

Interesting; I have never been able to configure white lists even I 
thought I sometimes would have liked to do so

The user interfaces with some of these phones is just horrible; without 
changing this we will never see widespread usage of white lists.