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

[Otmar Lendl <[e-mail]>]

On 2008/02/01 08:02, Hannes Tschofenig <[e-mail]> 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 <[e-mail]>, T: [phone] - 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP