Subject: [Sipping] Example of a meta-issue raised by at least one of the TISPAN requirements

From: David R Oran <[email-masked]>
Date: Thu, 4 Aug 2005 06:08:14 -0400

In reading the TISPAN requirements draft, it struck me that accepting  
some of these requirements raises some additional issues that are  
consequences of those requirements, but unstated.

Here's the example which tickled my "something's badly out of whack"  
bone.

TISPAN has a requirement for MCID (malicious call trace), which  
mirrors the feature in the PSTN of allowing the provider to produce  
the actual calling party identity on an anonymous call and give it to  
an "authorized party" on request of the called party (or perhaps  
somebody else?).

This has the same obvious transitive-trust problems many of the other  
PSTN-oriented features has, but that's the not problem that bothers  
me here.

It's that this feature has the built-in assumption that the calling  
user is the bad guy and the service provider is the good guy and  
always trustworthy. This means that the calling user has no way to  
"opt out" of a call if the provider is going to be able to deliver  
the identity in MCID to a third party.

As a user, unless we have extra machinery not present in the PSTN, I  
have no recourse against a service provider fraudulently claiming I  
made a (supposedly malicious) call I never made.

I believe that in the general SIP environment, there *is* a  
corresponding requirement that the calling user be able to control  
whether an anonymous call should proceed if there is a danger that  
his identity would be disclosed via MCID.

If you believe service providers are above such collusion with  
corrupt legal authorities, think again.

Dave.

P.S. there *are* solutions to these problems if we invoke some of the  
traitz and identity machinery.

_______________________________________________
Sipping mailing list  https://www1.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