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

[Paul Kyzivat <[e-mail]>]

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

Otmar Lendl wrote:
> 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 )
_______________________________________________
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