Subject: [Rucus] Context for rucus

From: Otmar Lendl <[email-masked]>
Date: Fri, 15 Feb 2008 15:35:13 +0100

As my mails to the sipping WG list exceeded Saverio's attention-span,
I'll repost the main questions I raised here (spitstop & rucus) in short
mails.

Q1:

In my opinion, the requirements for anti-SPIT technology depend a lot on
the environment in and the application for which SIP is used. The most
fundamental question is:

a) Do we envision this technology to be part of a first line service?

or, 

b) will the SIP service be a "second line service" which will exist
in addition, but not as a replacement, for the current PSTN service?

------------------

Examples (not restricted to SIP)

* Skype is b). SkypeIn/Out never succeeded in a). 
* Vonage is a)
* Triple-Plays by cable operators are of type a)
* Google-Talk is b)
* FWD is b)
* IM networks are b)

-----------------

Why is this important? 

b) is a lot easier. You can assume fancier user interfaces and user will
be willing to accept new types of interactions (e.g. buddy-list requests).

a) has established communication procedures and expectations in a large
user-base, plus often hard core requirements regarding call-blocking. 

Thus the solutions which can be workable for b) might not be suitable
for a). Any discussion regarding the merit of protocol features needs
to reflect the intended deployment scenarions.

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

---

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

Hi Otmar,

> in addition, but not as a replacement, for the current PSTN service?

Very good question, now I got what you wanted to say, thanks :-)

Answer to Q1:
I would like to have solutions for b) in a first place to explore the field,
restrictions of the solution that will be working for a) can be worked out
later.

I would then focus for b) in RUCUS.

Since you raised the point.

Q1a:
What about restricting the RUCUS use cases to:
-- single administrative domain
-- if multiple domains are considered then assume a peering/trust agreement
between them (secure bi-lateral connections among them)

This would also help in confining the topic.

Cheers,
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
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: Dorgham Sisalem <[email-masked]>
Date: Fri, 15 Feb 2008 17:00:51 +0100

I very much agree with Otmar that the requirements and possible 
solutions for first and second lines are different. But I am not sure 
that spammers will make this distinction. Actually SPIT is a lot more 
annoying to users with a first-line VoIP service so leaving them out 
would not be helpful. A general framework should therefore address both 
scenarios.

Restricting the environment -only trusted relations or one 
administrative domain- might actually be a good starting point as there 
is still no real peering between VoIP providers and as long as peering 
is done over PSTN, there will still be some -hopefully prohibiting- 
costs for large SPIT actions.

cheers

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 15 Feb 2008 17:10:45 +0100

[I'm keeping spitstop Cc'd for the moment]

> Very good question, now I got what you wanted to say, thanks :-)

Good, then I'm looking forward to your answers on sipping as well.

> restrictions of the solution that will be working for a) can be worked out

No. Most of them can't. 

> This would also help in confining the topic.

Sorry, but if you're restricting the discussions to case b) and just
internal or communication between trusted parties (without transit),
then the focus is so narrow that I don't see a point in doing any work
on this.

In the "single administrative domain" case you don't write fancy "this
call is probably spit"-header into the signalling if you detect spit,
but instead you disable the account of the offender.

In the pure bi-lateral trusted case you do the same. If you know that
this is a likely spit-call, then don't even pass it to your peer.

Such settings don't need protocol solutions, they need passive
monitoring plus good old-fashioned abuse-handling. 

That's no topic for the IETF.

/ol

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 10:52:29 -0800

> but instead you disable the account of the offender.

Existing email-based spam systems, such as most notably SpamAssassin,
create exactly such a header, which the user is then able to filter
at their mail user agent or using a filter in their mail storage
server (using for example .procmailrc to filter).  This provides
the *user*, not the domain administrator, the power to ignore or
automatically delete certain email.

I expect a similar model makes sense for realtime communications.  Do
you believe a similar model makes no sense for realtime communications?

-d

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

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 15 Feb 2008 20:40:50 +0100

> you believe a similar model makes no sense for realtime communications?

It makes sense in a multi-operator environment.

It make little sense within a walled garden of a single operator. 

In the case of SPAM, no operator (expect perhaps the russian business
network and a few other shady outfits) allows customers to spam.
It's against their terms of service, and these are usually enforced.

The problem with spam comes from the fact that e-mail crosses 
open administrative boundaries thus evading any accountability.

Let's take a closer look at your SpamAssassin example: In the 
email case, the recipient's mail provider will tag messages
as they come in. Your ISP has no recourse against the sender
of the spam (other than blocking mail), there is no business
relationship, no contract, no right to sue, no damages. Often
enough, they don't even know the real-world identity of those
who handed them the spam.

If, as Saverio suggested, we look at the insular case, of
just a single, unconnected operator then this changes:
Tagging the incoming mail is equivalent to tagging outgoing
email (remember, everything is internal). Whenever there is mail
tagged as spam in this setup, the provider *knows* the account
of the sender. It's one of his own customers. Hopefully a paying
one, but at least someone with account credentials who agreed
to some Terms&Conditions when signing up. 

So, whenever this provider is capable of telling his customer
that this new mail is probably spam, he also knows which of
his customers just sent this spam. As that's against the T&C,
he can yank the account of the perpetrator and keep his network
clean.

In other words, within a single administrative domain, Spam/Spit
is a policing issue, and not a protocol issue. Yes, the IETF is
full of techies, but that doesn't mean that a new protocol is the
best solution to every problem. Hammer & nails, you know the adage.

(Along the same lines: Within a single domain, you don't need SIP Identity,
the provider can authenticate customers and enforce valid From: headers.)

/ol

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 12:08:27 -0800

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Friday, February 15, 2008 11:41 AM
> To: Dan Wing
> Cc: [email-masked]; 'Signaling TO Prevent SPIT'
> Subject: Re: [Rucus] [spitstop] Context for rucus
> 

Er, I don't follow.

Let's take a specific recent example at my own house.  My wife
and I contribute to a variety of environmental non-profit 
organizations (e.g., World Wildlife Fund, Monterey Bay 
Aquarium).  Occasionally they call the house to invite us
to a special event or solicit special contributions for a
specific cause.

I imagine that some people who contribute to these same
organizations receive similar phone calls.  It is reasonable to 
expect that some number of those people would press the
"SPAM" button on their phones, even though they have a 
previously-established business relationship with that
non-profit organization.

Let us assume the WWF, the Monterey Bay Aquarium, and my
phone are all served by the same phone company.  In my
case with the PSTN, they all are.

You are suggesting that if enough people complain that they
were spammed by WWF or the Monterey Bay Aquarium, that the 
phone company would have some right, or some expectation, 
or some ability, to cut off the ability of that non-profit 
organization to initiate outgoing calls -- that is, to
terminate their service.

I do not believe that is possible, nor is it reasonable
to expect, even within a single phone company.

> he can yank the account of the perpetrator and keep his network

You're viewing spam as a binary operation:  someone is spamming
("1"), and should be cut off from service; everyone else is not
spamming ("0"), and can be allowed to continue as a paying
customer.

It is not nearly so clear cut.  Wish it were.

-d

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 15 Feb 2008 22:47:31 +0100

On 2008/02/15 21:02, Dan Wing <[email-masked]> wrote:
> > > 
> > > I expect a similar model makes sense for realtime communications.
> > > Do you believe a similar model makes no sense for realtime
> > > communications?
> >

> to expect, even within a single phone company.

I agree that turning off PSTN service is not a trivial option.

That is exactly why my first question was: do we deal with a
PSTN-replacement service or a second line (alternative communication)
service?

Your example is using the service expectations and legal framework of
the PSTN. Saverio's answer was different: he wants to consider second
line services first. I still contend that within those, different rules
apply.

E.g. if I send out too much messages within LinkedIn, Skype or some
other Web 2.0 style communication platform, they will kick me off. If
you attract too many complaints for your hotmail account, you're gone.

I'm not sure about the US situation, but here in Austria the same
legal framework which defines your rights and the carrier's duties
with respect to PSTN service also describes what kind of conduct
(e.g. telemarketing) is illegal and even tasks a government
agency with acting on complaints from users. 

That does not apply to any fancy "Free World Dialup" knock-off
that someone might try to establish here.

So yes, I agree with your example (though I don't know what a fancy
header would help), which actually bolsters my claim that we
really need to be clear whether we're building a solution for
PSTN replacement services or just for fancy alternative services.

/ol

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 14:01:51 -0800

> Sent: Friday, February 15, 2008 1:48 PM
> To: Dan Wing

Neither would turning off email -- imagine this is a newsletter,
distributed via email, from those same non-profit organizations.

> PSTN-replacement service or a second line (alternative communication)

I do not follow. 

Today, on the PSTN, there is no requirement, expectation, law, or
rule, that a PSTN provider terminate service for someone that causes
"excessive" phone calls.  Otherwise, the call centers inside of my
own area code, which call other phone numbers in this same area code,
would be shut down.  They are paying customers.

> line services first. I still contend that within those, 
> different rules apply.
> 

There are similar restrictions here in the US, and a national "do not
call" list which telemarketers are required to look up prior to making
phone calls.

However, the phone companies themselves do not enforce this 
restriction or requirement -- rather, it is a government agency
(our Federal Communications Commission) that receives complaints
and takes actions against companies that illegally make unsolicited
phone calls to numbers on the 'do not call' list.

> header would help),

The headers need not be fancy, they only need to be agreed upon.  

If the service provider puts "Spam: Yes", but the SIP User Agent
is looking for "X-Spam: 1.0", we can't have an interoperable system.

I want an interoperable system.  

> which actually bolsters my claim that we

I'm sorry, but I am unable to understand the distinction you
desire, even though we have exchanged several emails on this.

-d

---

From: "Saverio Niccolini" <[email-masked]>
Date: Sat, 16 Feb 2008 23:53:33 +0100

Hi,

> Sorry, but if you're restricting the discussions to case b) 
> and just internal or communication between trusted parties 
> (without transit), then the focus is so narrow that I don't 
> see a point in doing any work on this.

The work needs to address something narrow otherwise we will
never reach consensus.
It is just a way to start working on this, if we think too big
on a topic so controversial then it is better not to start at all.
Thus better think small but achieve something...

> In the "single administrative domain" case you don't write 
> fancy "this call is probably spit"-header into the signalling 
> if you detect spit, but instead you disable the account of 
> the offender.

I think you misunderstood me:
When I was referring to the single domain, I was thinking of 
the scenario that Hannes depicted in his draft (if you see the
figure you see everything happens within a "Domain Boundary").

My point in saying that was focus on technical work needs assuming
that SPIT communications are between trusted entities (to simplify
the scenario and reach faster an agreement on work to be done).

> In the pure bi-lateral trusted case you do the same. If you 
> know that this is a likely spit-call, then don't even pass it 
> to your peer.

You are missing one point here: in the case you want to address
"a", you can not simply suppress communications (not even in a
single domain) because this is not legal, this why you may
need to have SPIT indications (scores and user feedbacks) and
apply policies (that the user needs to agree with).

> That's no topic for the IETF.

I start thinking you are right, but this is not something that can be
decided by me and you.
I am trying to find a scenario where this topic can be for IETF,
if we fail I can just go back and write my papers...

Saverio

---

From: "Saverio Niccolini" <[email-masked]>
Date: Sun, 17 Feb 2008 00:07:48 +0100

Hi again,

> So yes, I agree with your example (though I don't know what a 
> fancy header would help), which actually bolsters my claim 
> that we really need to be clear whether we're building a 
> solution for PSTN replacement services or just for fancy 
> alternative services.

ok, you want to focus on "a: we are building a solution
that assumes the same rules that PSTN has nowadays"

It is fine with me as well, I just think it is going to
be more complicated to get consensus on a solution if we
assume too many restrictions, but I am willing to work on
this

Saverio

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Feb 2008 21:51:05 +0100

(I'm trying to keep this short)

> desire, even though we have exchanged several emails on this.

Quick summary: 

PSTN-like systems have special regulatory status and are unique in
a sense that they are the default pathway for a certain type of
communication (e.g. voice, email). You can't "opt out of the PSTN and
its rules" if you still want to be reachable by the world via the
telephone.

Anybody building something new can define the rules for using this new
setup and they might be different to what others use who build
similar new communication systems. Thus there is competition between
such system, e.g. if I don't like the way company Foo is running and
policing their IM systen, then I (and my friends) can switch to Bar's
system.

I maintain that this distiction is very relevant to the design of 
SPIT-avoidance systems.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Feb 2008 21:55:31 +0100

> assume too many restrictions, but I am willing to work on

I'm not particulary invested in the question which setup RUCUS
should focus on. 

What I really care about is a common understanding on the basic
communication ecosystem for which we try to develop a solution.

(IMHO that's missing in speermint, which might be the most important
reason that speermint hasn't produced any worthwhile output so far.)

/ol

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Feb 2008 12:58:46 -0800

> I maintain that this distiction is very relevant to the design of 

If I create an identity on, say, gmail.com, and it is my identity on
publicly-facing documents, presentations I give, columns I write,
email that I post to mailing lists, hand out dozens of business
cards with my email address, etc., I can't just "pack up my bags" 
(so to speak) and jump to a different email provider.

I expect the same would be true of my identity on Skype, IM networks 
(Yahoo, Hotmail, MSN, etc.).  It's true I could pack up and leave
those, but packing up and leaving those networks is not trivial
or easy.  I would need to get re-added on all of my friend's white
lists (which is the only viable mechanism on those networks for
me and for my friends to avoid getting spammed by advertising when
on those networks).

-d

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Feb 2008 22:05:15 +0100

> the scenario and reach faster an agreement on work to be done).

Actually, this is one point I would ask the email/SPAM people:

What percentage of the SPAM problem is due to the fact that
email is received from non-trusted entities?

Or a bit watered down: What percentage of the SPAM problem is due to the
fact that email is received from unknown entities?

I have this nagging feeling that herein lies the crux of the SPAM
problem: SMTP servers need to accept connections from any host in the
Internet. 

If this is true (as of now, this is my gut feeling, we'd have to confirm
this), then focusing on a case which excludes the basic reason for
the problem in the first place, sounds non-productive.

> apply policies (that the user needs to agree with).

Ah sorry, I was still thinking within your "let's consider case b)"
first frame.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Feb 2008 22:38:02 +0100

> (so to speak) and jump to a different email provider.

Well, the "official solutions" to that problem in email and telephony
are "get your own domain" and "number portability".

Once you de-couple your address from your provider, packing the
bags and moving is no issue.

> me and for my friends to avoid getting spammed by advertising when

... which brings us to a crucial question:

Can the "white list" approach work in a a PSTN-replacement service?

("work" in that context needs to be technical, from a UI perspective,
and from a service expectation point of view.)

/ol

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Feb 2008 13:53:06 -0800

> bags and moving is no issue.

Ok.

> and from a service expectation point of view.)

White lists only work if there is a separate, out-of-band mechanism
to communicate to someone before you are on their white list.

For example, with today's IM systems, you usually email, SMS, or
call your friend and ask to be placed on their whitelist.  Some IM
systems allow you to send a request, through the IM system itself,
to be added to the receiver's white list ("become a friend"); I 
presume those IM systems have some sort of accounting and some sort
of limits on the number of people you can invite, otherwise a spammer
would simply invite everybody on the entire IM system, hoping that 
a few people would accept adding the spammer to the whitelist, and now 
the spammer is able to send spam to those people.

Without a mechanism to add someone to a whitelist, I don't see 
whitelists working.  That mechanism does not necessarily need to
be built into the protocol itself; afterall, emailing or SMS'ing
or calling my friend to ask he add me to his whitelist is not
part of any IM system.

So, if we had a SIP system with a whitelist, how would you ask to
be added to a whitelist?  Send an email??

And clearly, while whitelists work well for individuals, they are
less valuable for for companies.  Consider for example a mail-
order company such as Sears.  They want to accept calls from
potential customers (which are not yet on their whitelist) but
they would naturally prefer to avoid dealing with incoming calls
from spammers.  Identifying a spammer versus a potential customer
is difficult, of course.  My own employer, I would imagine, has
well-known spammers that are also legitimate customers (that is,
who have purchased routers or ethernet switches) and all 
legitimate customers should be able to contact technical 
support.

-d

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 19 Feb 2008 12:27:51 +0100

> What I really care about is a common understanding on the 
> basic communication ecosystem for which we try to develop a solution.
> 
> (IMHO that's missing in speermint, which might be the most 
> important reason that speermint hasn't produced any 
> worthwhile output so far.)

The objective of SPEERMINT was supposed to be on a different plane
than RUCUS.

I agree that this is a problem in SPEERMINT but this does not mean
that we should solve this problem to be able to work on RUCUS.

There is already a kind of "problem statement" for SIP spam (even already an
RFC, RFC 5039), we should rely on this and buld an architecture and
requirements on top of that. That is straightforward for me...

Saverio

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 19 Feb 2008 12:30:47 +0100

> Can the "white list" approach work in a a PSTN-replacement service?

I do not think the "white list" approach on its own is enough.
There are too many problems with it:
-- identity spoofing
-- providers giving away identities for free (or for good money) to
telemarketers
-- virus and trojans in devices

White list and identities are not enough.

Saverio

---

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

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dan Wing
> Sent: Monday, February 18, 2008 10:53 PM
> To: 'Otmar Lendl'
> > Once you de-couple your address from your provider, packing 
> the bags 
> > and moving is no issue.
> 
> Ok.
> 
> > > those, but packing up and leaving those networks is not 
> trivial or 
> > > easy.  I would need to get re-added on all of my friend's white 
> > > lists (which is the only viable mechanism on those 
> networks for me 
> > > and for my friends to avoid getting spammed by 
> advertising when on 
> > > those networks).
> > 
> White lists only work if there is a separate, out-of-band 
> mechanism to communicate to someone before you are on their 
> white list.

Even then they fail in many scenarios (see my previous email)

Saverio