Subject: Re: SIP Spam Prevention (was Re: [Sip] calling number blocking at sip/isup ga...

From: "Dean Willis" <[email-masked]>
Date: Fri, 1 Feb 2002 19:35:07 -0600

Warning! This response contains philosophical ranting. Please take a large
dose of humour supplement to help ease the pain.

----- Original Message -----
From: <[email-masked]>
> Dean mumbled:
> >  Ah. In the case I referenced, there WAS no service provider originating
the
> >  call. It was produced by a SIP UA on the Internet. From that point of
view,
> >  every PC is a service provider . . .
>
> Interesting, but this points out the basic difference in network
> architectures that we are addressing. You talk as if the telephone call
> originates out of nowhere, like some Spam seems to today. I am talking of
a
> network architecture view in which every telephone call must begin and end
> under control of a "service provider". (And that doesn't mean a provider
with
> a physical netwok like today's telephone companies.) In this network
> architecture, all the privacy issues (calling party ID, called party ID,
> names, etc.) are dealt with by the choosen service provider. (You don't
get
> service from someone you don't trust, nor do they provide service to
someone
> if they don't have a way to verify who is trying to originate a call.) And
at
> the same time, the legal invasions of privacy, to support wire-tapping,
would
> be dealt with by this same service provider.

 I believe you have us confused with the ITU ;-) . .

Mike, this is the INTERNET Engineering Task Force. We're concerned with the
Internet -- it's a big packet-switching thing that allows arbitrary
communications between arbitrary endpoints. Being a "Service Provider"
fundamentally means to take packets from a customer, insert them into the
switching fabric, and swish them on their merry way -- or, to take packets
from the switching fabric as appropriate and hand them to your customer. Of
course, there can be higher-level service providers. VeriSign is a good
example of a service provider who provides tools to cope with the issues you
raise, without being "Big Brother" and controlling everybody. I should give
my speech on the difference between "control" and "service" for you someday
. . .

As for the rest, please see RFC 2804 for the IETF policy on wiretapping and
RFC 1984 for the general policy on crypto. Good recreational reads, right up
there with the Magna Carta and the Declaration of Independence, which are
also probably useful reads for someone with too much background in
tradtional telephony.

> Yes, someone could agree to handle originations of telephone calls from
> unknown parties, but I can't imagine these calls ever being allowed to
> interwork into the PSTN or into a comercial IP-based telephony service
> provider's network. And laws on electronic surveillance will eventually
> forbid it anyway.

Try setting up a session to sip:[email-masked]. If I'm not sitting
at my desk, said call will be interworked into the PSTN and delivered to my
cell phone. Right now, and every day for the past year and a half, except
when the phone company broke the ISDN lines for a while. I suppose it could
be spammed in a denial-of-service attack, but the last guy to do that is
still suffering. Of course, you just just call my cell phone directly from
outside the US with the same effect. On the other hand, we are working on
triocks to verify that the request you've sent really came from the IP
address that's claiming to send it, and barring the Zombie Attacks
engendered by flawed Redmondian security systems will probably be adequate
for my purposes.

> >
> >  > What bothers me is that we are modeling this on current stuff, and
> yesterday
> >  > I got two copies of the new "Party" virus attached to e-mails from
> >  > "UnknownSender". If we can't stop this in e-mail today, what is the
> future
> >  > telephony network going to be like?
> >
> >  Absoultely correct. This is why I want cryptographic support for the
RPID
> >  header, and transitive vouching techniques thereon. If you get a call
whose
> >  RPID can't be verified, it becomes perfectly legitimate to do something
> >  nasty to it like forward it to a robot that explains your policy about
> >  anonymmous calls. Or, you can listen if you want -- some people LIKE to
> live
> >  dangerously.
>
> Again, in the network architecture I'm referring to, cryptographic
procedures
> are not the answer to privacy for calling party ID. Yes, such procedures
may
> be used by the originating service provider to verify that the calling
party
> is legitimate, and by the terminating party to determine that the call
> attempt comes from their choosen service provider, then these procedures
do
> not need to be applied to the calling party ID iteself. In an enterprise
> network, we may use cryptographic measures between parties in that closed
> set, but for the general telephony environment, the end user who receives
a
> call shouldn't be required to apply cryptographic procedures with the
> originator to verify contents of the call setup message.

You have to do the crypto, either with the originator or with a trusted
intermediary who vouches for the originator. Sounds like a service provider
opportunity to me. What you're proposing is not really different than the
fundamental PKI model -- it's just a question of who does the crypto, and
since your "phone" is going to have to do crypto just to recognize the
service provider, there's not much of a difference in the scope of the
problem. It's all just a big "proxy" business.

For example, let's say I want to trade some stocks. I fire up my browser and
point it at Schwab. How do I know that it's really the Schwab site
responding, and not my ex-wife's attorney trying to figure out where I hid
my last 37 cents? Well, Schwab has a cert. It was signed by VeriSign. Thru
other channels, I got a copy of VeriSign's cert (Chairman Bill was kind
enough to include it with the OS on my office PC, and some guys in Red Hats
packaged it up for my house). I use VeriSign's cert to check that my
connection with Schwab was signed with Schwab's cert. Transitive trust,
right? So why don't we use this approach for everything? Simple, really --
people are too cheap to pay for their own cert, too lazy to deal with it, or
to ignorant to care (I suffer from all three). Or they just don't trust Big
Guys, and would rather weave their own web of transitive trust with
something like PGP, which also tends to run afoul of the "lazy" and
"ignorant" set. And very occasionally because the device involved is just a
little too small to run the crypto (the threshold is a code size somwhere
around 64kB).

 . . .  much elided . . .

> Concerning your comment above that the call may start at any SIP UA on the
> Internet (someone's PC). I firmly believe that it will eventually be
admitted
> that the issues of verification, privacy, service provisioning,
accounting,
> wiretap, etc. require that every "end user" of SIP have a dedicated SIP
proxy
> to handle originating and terminating calls. This UA-SIP proxy
relationship
> must be established when the device is turned on, makes the first call,
etc.
> Thereafter, all interactions for individual phone calls are between this
> trusted SIP proxy and the end-user (SIP UA). The SIP Proxy is then the
> service provider (and responsible for all the above functions). I believe
> this architecture is beginning to be recognized as required for various
> purposes and we can't move forward until it is accepted for all cases.

Wow. I really hope you're completely wrong in the general case, otherwise
I've wasted most of the last twenty years working on the Internet.
Especially since I'm my own service provider and run my own proxy and my own
PSTN interconnects. I also run my own web server and my own email exchanger
and do all sorts of other stuff you would probably expect to reserve for
"service providers". Hey, you better reject this email, because it just came
from an Unknown Source! Yep, I use service providers, but I choose to do so
at a different level than you're proposing, and that's OK, because this is
the Internet, not a government-sponsored work camp for the political
re-education of people who have expressed libertarian sympathies in a public
forum.

On the other hand, there IS substance in much of what you're saying. It's
just that we hope to offer solutions that don't require fixed "wires", or
the virtual equivalent thereof, between the slaves and the masters. In fact,
I think most of the community would happily do without the "slaves" and the
"masters" as well.

And it now being Friday evening, I'm going to go work from the other desk.
Good night.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip