Subject: Re: [Sipping] RUCUS / framework-spit-reduction-02

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Feb 2008 22:43:08 -0800

> I think we have a hard time evaluating the proposals unless we do not
> share a common understanding of the environment in which this solution
> is supposed to work.

Care to write a draft discussing those issues?  I doubt we will
find two people in the room of ~200 that would agree on all of
those issues.

-d

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

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 9 Feb 2008 23:11:09 +0100

On 2008/02/01 08:02, Hannes Tschofenig <[email-masked]> wrote:
> Hi Otmar,

Hannes,

> thanks for the detailed response. This is a good discussion at the 
> architectural level.

You're welcome.

> * Vision of the future SIP communication
> 
> I believe there will be a mixture of big players together with very 
> small ones. If we don't provide solutions for the small players 
> (including persons that decide to deploy their own SIP server) then 
> someone else will do it, most likely just using a different protocol.

I consider that to be one of the major challenges the IETF faces with
respect to SIP: Build a common framework where big telcos, corporate
PBXs and private SIP server use the same routing, peering and anti-spit
algorithms. So yes, I agree: we should strive for a solution which 
applies to all these cases.

> * Integration with the legacy infrastructure
> 
> You are certainly right that the aspect of legacy infrastructure (or 
> interworking with other protocols) needs to be addressed. 

The purely technical part may be the easier part. Replacing legacy
technology usually also implies inheriting user expectations. 

That will constrain the solution space.

> 
> * Classification of the communication behavior
>
> I came up with this classification (Closed / Semi-Open / Open groups)
> since I thought it would be useful. It might not be the best and
> most complete one but shows where some of the mechanisms are more
> powerful. I would be happy if someone could point me to a better
> classification of communication behavior -- I am sure that there is
> a lot of literature in that space but I just did not find anything
> appropriate.

The classification is in one way helpful, as it describes some of the
default patterns of behavior. I'm not sure whether they're really
helpful in deriving rules. The actual, observed communication will
include exceptions. Yes, I usually communicate only within my social
sphere, but every now and then I'm called (or I call) someone who does
not fit the usual pattern. Often enough, that's perfectly fine and the
reason why the PSTN is so valuable.

> * Applicability to Email and IM
> 
> I am not an expert in email spam. Hence, I don't know what is applicable 
> to email as well. There are certainly technical and procedural 
> differences between email spam and VoIP / IM spam. Some of the technical 
> aspects are documented in Jonathan's document. There are obviously 
> similarities as well, for example, the work on strong identities (see 
> DKIM in relationship with SIP Identity). As a preparation for the BoF I 
> have had chats with folks working in the email spam space and Jim Fenton 
> was willing to share his experience with the fight against spam with us 
> at the BoF. We should obviously learn from the email spam lesson.

I'm less interested in the pure technological aspects. The crypto varies
and the pattern matching / content filtering does not translate 1:1, but
in general similar technical means exist.

Much more interesting is how anti-spam techniques affect the economics
of of the communication infrastructure. How many proposals have there
been which contained some sort of "If all mail-servers could add XXX to
their processing, everything would be fine" (where XXX is usually some
sort of whitelisting)?

Anyone proposing a technological solution should also have spent some
time thinking about how this solution could be introduced into the
ecosystem. For this to work, there must be immediate benefits for anyone
investing in the new technology. If, on the other hand, the benefits are
only realized once everybody has switched, then this tipping point will
never be reached.

> The IM case / presence case is interesting since most of us already got 
> used to "restricted" communication in the sense that there are policies 
> involved. Try to send me a message; I have to add you to my white list 
> first. Hence, user behavior has changed a lot with respect to the 
> "everyone can contact everyone without restrictions" principle we know 
> from the PSTN.

IMHO that works because IM is a new mode of communication. New medium,
new user-interface, new rules. When you're introducing something new,
you can define your own rules. If you're just changing the underlying 
technology of an old mode of communication, you can't do that so easily.

That's why I asked whether we aim for PSTN replacement or aim for
building something new.

> * Default policy setting
> 
> The specific policy setting is up to the person that writes these 
> policies. Discussions in GEOPRIV and other places lead to the conclusion 
> of many folks that blacklists in general are not that great when the 
> system provides an easy way to mint identities.

Agreed.

> Additionally, one has to consider that the policies are very context 
> dependent. For example, some of us don't want to get called by a 
> co-worker in the middle of the night.

That's actually a good example.

I certainly do not want to get called in the middle of the night. On the
other hand, there are very legitimate reasons for being called in the
middle of the night, where I'd hate to have the call blocked. Imagine a
relative being involved in an accident. You *certainly* will want to
be reachable in case your daughter ends up in an emergency room at 3am.
In that case you don't care whose phone was used to call you. 

I've got my share of "unwanted, but nonetheless important and necessary"
nightly calls. (Security incidents, burst water pipes, ...)

> We are, however, not suggesting to block calls when caller's identity 
> cannot be found in the white list. In that case there need to be ways to 
> execute additional mechanisms, such as leaving a message on an answering 
> machine or running through a turing test to ensure that you are indeed 
> talking to a human and not a bot.

The turing test might work, though I'm not sure whether the user acceptance
will be there.

> Regardless of my comments to some of the issues you raised you seem to 
> have a quite different architectural model in mind. Would you like to 
> explain what you had in mind?

Don't get me started ...

I've been mulling over this problem in the speermint context over the
last two years. The problem there (at least, one of the problems) is the
same: Do I want to peer (i.e. accept a direct call from them) with that
other SIP provider or not?

My approach is the following:

* We cannot assume that any two SIP operators will talk to each other.
  There will not be a full mesh.

  For any number of reason:

  - Settlement (Why should I accept anonymous calls when I can get money
    if they pass the call via PSTN/SS7 links?)
  - carriers might choose to peer only over private interconnects
  - SIP incompatibilities (This is the fun part of ENUM: two system
    talk SIP to each other without prior setup. I could tell you stories
    ...)
  - Lack of trust regarding SPIT
  - Regulatory reasons
  - Business decisions
  - Peering only over QoS enabled links
  - Fear of DoS, thus only static peerings.
  - ...

* We need full reachability, otherwise SIP can't replace the PSTN.
  Any phone needs to be able to call any other phone. (Modulo
  abuse-prevention, payment, local blocks at the destination, ...)

* As of 2008, all the SIP operators in the PSTN replacement business
  solve this by 

  - trying to establish as many direct SIP links as reasonable
  - pass the rest of the calls via the PSTN

  (see e.g. http://tools.ietf.org/html/draft-ietf-enum-softswitch-req-01)

But what happens if we don't want to rely on the PSTN any more?
I see basically two choices: 

a) everybody talks to everybody
b) the establishment of SIP transit networks

I consider b) to be much more likely. It's a much smoother transition
path and helps with a lot of other problems (see list from above) as well.
If you look at what the big boys in carrier-space are doing right now,
then this is precisely what happens.

Once you accept the need for transit, then a number of consequences are
obvious:

* We have the typical network routing problem. Nodes are SIP networks
  and links are peerings. Links need not be symmetrical, some operators
  might run open SIP proxies which accept calls from anyone.

* We need a non-trivial call routing algorithm (RFC3263 only works
  for a full mesh). TRIP was a nice try, but used the wrong identifier
  to base the routing on. (Phone-number these days are more like names
  than addresses. They have miserable aggregation properties.)

-----------

What does this mean for the RUCUS PoV? 

* We can solve the introduction problem the same way it is solved in the
  real world between people: By intermediaries which vouch for people.

* A SIP service can afford to be strict when accepting calls from 
  unknown peers. Blocking the direct peering does not block the call,
  the originating network just has to choose a different path.
  That may cost a fee towards a transit network, but from the RUCUS
  PoV, that's a feature, not a bug.

* If sender and destination network use different anti-SPIT algorithms
  (e.g. different reputation system, different payment-at-risk service),
  then there is a market for services which provide a bridge between
  such systems. Just as banks change your dollars into Euros when
  travelling, such brokers might translate your anti-spit credentials
  from the system that is used in America to one which is accepted in 
  Europe.

  (Side remark: I consider it to be completely unrealistic to assume
  that there will ever be one single dominant social network /
  reputation system / micro-payment provider / payment-at-risk broker /
  certification agency, ... 
  Any anti-SPIT strategy thus needs to cope with incompatible systems,
  especially for international calls. I've we're really lucky we might
  end up with something as homogeneous are the credit card world.)

* The decision which interconnection policy a SIP provider should 
  use is his own choice. 

  Each peering a provider establishes carries a certain cost (e.g.
  configuration, testing, SBCs, private L2 link, or just the risk
  of SPIT and DoS in case of RFC3263 style open proxies) and using a 
  transit operator certainly won't come for free, either.

  Somewhere on the scale from "manual peerings only" to "open SIP
  proxies", each operator will find his own optimum.

  The same happens in the IP layer 3 world and the PSTN world: A direct
  peering might be cheaper that buying transit if there is enough
  traffic to justify the effort.

  If Speermint and the RUCUS effort succeed, then the cost (and risks) of
  establishing peerings will be low, pushing the market towards an
  almost full mesh. If not, transit operators will find a good market for
  their services.

  Just as BGP does enable, but not hardcode, the current Internet
  L3 ecosystem, a SIP routing architecture needs not define the
  interconnection policies of operators. That will evolve all by itself.

  The current IETF SIP RFCs hardcode the full mesh / email model. That
  amounts to decreeing business decisions. 

  Didn't work. Ain't going to work.

  Just look at the peppermint proposal. That's yet another band-aid to
  bludgeon the current RFCs into doing some form of routing which they
  weren't designed to support in the first place.

/ol (who has played court jester to speermint singing this tune.
     See e.g. draft-lendl-speermint-background-00 )
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Feb 2008 15:39:31 -0500

Interesting discussion. I think this is homing in on the right problem - 
how to make it possible, in a practical sense, for sip to replace the pstn.

I see a big problem with the approach of only doing sip peering with 
friends and deferring the rest to the pstn: it only works for voice, and 
to a limited extent IM. One of the value propositions for SIP is that it 
supports other media, and other features that require signaling that 
won't make it through a pstn link. So we have to wait for full mesh to 
get that?

	Thanks,
	Paul

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 11 Feb 2008 13:18:26 +0100

> how to make it possible, in a practical sense, for sip to replace the pstn.

IMHO that is exactly what the big league SIP adopters are trying to do.
Most of the real-life residential VoIP deployment has been a simple
substitution of local loop via POTS or ISDN with SIP over IP, but
without changing the inter-carrier setups.

That is changing very slowly and in a very ad-hoc fashion. I thought
that speermint would help with this process to get standardized, but
right now the proprietary peering fabrics seem to win the race.

> to a limited extent IM. 

This approach wasn't chosen because it's superior. It was chosen by
real-world constraints (plus an unhealthy dose of fear) and simple
economics. Nobody designed it this way.

> One of the value propositions for SIP is that it 
> won't make it through a pstn link. 

How do the current mass deployments of SIP for PSTN replacement look like? 
They are ATA-style adapters to which the same phone gets connected that
once was connected to the incumbents POTS service. Who do people call
with these phones? A good cross-section of the PSTN userbase which for
the most part still uses POTS service.

The only feature I can think of which they could easily offer is
better voice quality to other SIP devices as that degrades seamlessly
when calling PSTN user. 

What other SIP features can be introduced in the current marketplace
without completely confusing the customers?

> So we have to wait for full mesh to get that?

If the question is reduced to either "the PSTN is the only working
transit network and thus the least common denominator in terms of
features" or "full mesh of SIP operators, emulating the e-mail model",
then the former wins. The gap is too big for the market to flip from a)
to b).

In order to get closer to the full mesh, there needs to be a way
for operators to incrementally open up their networks, to test the
waters with a toe before jumping in. 

The IETF protocols currently provide no smooth transition path towards
the full mesh. It's a binary choice for operators now, and the market
is rushing in to provide jury-rigged solutions for selective SIP
interconnection.

Isn't this a sign that something is missing from the RFCs?

As I read the market, the best way forward it to move the transit
function from the PSTN to SIP based networks by establishing a unified
scheme for multihop SIP routing.

As a side-effect, this makes dealing with SPIT a heck of a lot easier
as we can avoid some of the downsides of the e-mail model.

/ol

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 13 Feb 2008 05:25:06 +0100

Dear all,

three short comments:

-- as Cullen suggested, until the RUCUS mailing list is up and running,
please use SPITSTOP mailing list for discussions related to this
(avoid cross posting as I just did)

-- don't we think that we are moving a bit away from the proposed topic?
I know we are supposed to talk about architecture for SPIT but going to
the topic "how to make it possible, in a practical sense, for sip to
replace the pstn", seems a bit ambitious and out of the proposed scope
of RUCUS and any SPIT disussion...

-- do we really think we need so long emails with a lot of text to read 
instead of short and well focused discussion, I think these kind of discussion
would be good in a workshop but not in a mailing list

Just my two cents,
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-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: Monday, February 11, 2008 1:18 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Sipping] RUCUS / framework-spit-reduction-02
> 
> > Interesting discussion. I think this is homing in on the 
> right problem 
> > - how to make it possible, in a practical sense, for sip to 
> replace the pstn.
> 
> Most of the real-life residential VoIP deployment has been a 
> simple substitution of local loop via POTS or ISDN with SIP 
> over IP, but without changing the inter-carrier setups.
> 
> That is changing very slowly and in a very ad-hoc fashion. I 
> thought that speermint would help with this process to get 
> standardized, but right now the proprietary peering fabrics 
> seem to win the race.
> 
> > friends and deferring the rest to the pstn: it only works 
> for voice, 
> > and to a limited extent IM.
> 
> This approach wasn't chosen because it's superior. It was 
> chosen by real-world constraints (plus an unhealthy dose of 
> fear) and simple economics. Nobody designed it this way.
> 
> > One of the value propositions for SIP is that it supports 
> other media, 
> > and other features that require signaling that won't make 
> it through a 
> > pstn link.
> 
> They are ATA-style adapters to which the same phone gets 
> connected that once was connected to the incumbents POTS 
> service. Who do people call with these phones? A good 
> cross-section of the PSTN userbase which for the most part 
> still uses POTS service.
> 
> The only feature I can think of which they could easily offer 
> is better voice quality to other SIP devices as that degrades 
> seamlessly when calling PSTN user. 
> 
> What other SIP features can be introduced in the current 
> marketplace without completely confusing the customers?
> 
> If the question is reduced to either "the PSTN is the only 
> working transit network and thus the least common denominator 
> in terms of features" or "full mesh of SIP operators, 
> emulating the e-mail model", then the former wins. The gap is 
> too big for the market to flip from a) to b).
> 
> In order to get closer to the full mesh, there needs to be a 
> way for operators to incrementally open up their networks, to 
> test the waters with a toe before jumping in. 
> 
> The IETF protocols currently provide no smooth transition 
> path towards the full mesh. It's a binary choice for 
> operators now, and the market is rushing in to provide 
> jury-rigged solutions for selective SIP interconnection.
> 
> As I read the market, the best way forward it to move the 
> transit function from the PSTN to SIP based networks by 
> establishing a unified scheme for multihop SIP routing.
> 
> As a side-effect, this makes dealing with SPIT a heck of a 
> lot easier as we can avoid some of the downsides of the e-mail model.
> 
> /ol
> --
> // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 
> 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft 
> m.b.H // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: 
> Salzburg _______________________________________________
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Dan York <[email-masked]>
Date: Thu, 14 Feb 2008 10:57:05 -0500

> (avoid cross posting as I just did)

On this point, I'll just mention that the RUCUS mailing list was  
requested back when Cullen sent out his note but seems to be hung up  
in the Secretariat transition and we are still waiting for the list  
to be created.

Regards,
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: "Saverio Niccolini" <[email-masked]>
Date: Thu, 14 Feb 2008 17:56:56 +0100

Then let's just use spitstop mailing list by now... it is easier
since most of the people is registered there...

Saverio

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dan York
> Sent: Thursday, February 14, 2008 4:57 PM
> To: Signaling TO Prevent SPIT
> Cc: [email-masked]; Paul Kyzivat; Otmar Lendl
> Subject: [spitstop] RUCUS mailing list status...
> 
> 
> On this point, I'll just mention that the RUCUS mailing list 
> was requested back when Cullen sent out his note but seems to 
> be hung up in the Secretariat transition and we are still 
> waiting for the list to be created.
> 
> Regards,
> Dan
> 
> --

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 19:10:47 +0200

I am sure that these mailing list problems will be solved soon.

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 14 Feb 2008 18:45:34 +0100

Hannes,

on SPITSTOP there are 97 members total, if we wait RUCUS mailing 
list to come up and people to register we can forget discussing
the BoF preparation.

In my opinion discussion should start now on this mailing list,
then let's see when RUCUS mailing list comes up...

As you know i am in the process of finalizing some drafts to support
the discussion, I will forward them to this list on MOnday once they
are submitted together with some considerations how to move forward.

Cheers,
Saverio

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, February 14, 2008 6:11 PM
> To: Saverio Niccolini
> Cc: Signaling TO Prevent SPIT; Otmar Lendl; Paul Kyzivat; 
> [email-masked]
> Subject: Re: [Sipping] [spitstop] RUCUS mailing list status...
> 
> > Then let's just use spitstop mailing list by now... it is 
> easier since 
> > most of the people is registered there...
> >
> > Saverio
> >
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >   
> >
> >   
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >   
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 19:57:54 +0200

I was actually hoping that the mailing list issue would not take forever.

Anyway, I short note about the preparation: I plan to send an updated 
agenda to the list early next week when I have all the confirmations 
from the speakers.

Ciao
Hannes

Saverio Niccolini wrote:
>>>> requested back when Cullen sent out his note but seems to 
>>>>         
>> be hung up 
>>     
>>>> in the Secretariat transition and we are still waiting for 
>>>>         
>> the list 
>>     
>>>> to be created.
>>>>
>>>> Regards,
>>>> Dan
>>>>
>>>> --

---

From: Dan York <[email-masked]>
Date: Fri, 15 Feb 2008 05:42:44 -0500

SIPPING and SPITSTOP members,

FYI, the RUCUS mailing list is now live at:

   http://www.ietf.org/mailman/listinfo/rucus

Please join that mailing list so that we can plan for the upcoming  
BOF in Philadelphia.

Thanks,
Dan

P.S. If you aren't familiar with the RUCUS BoF, here is the approved  
request:  http://www.tschofenig.priv.at/bof-rucus.html  This is "Reducing  
Unwanted Communication Using SIP" and is designed to look at  
architectural issues involved with preventing voice spam, aka Spam  
for Internet Telephony aka SPIT.

On Feb 14, 2008, at 10:57 AM, Dan York wrote:

> requested back when Cullen sent out his note but seems to be hung  
> up in the Secretariat transition and we are still waiting for the  
> list to be created.
>
> Regards,
> Dan
>