Subject: [Sipping] Caller ID requirements from 3GPP

From: "Stephen Hayes (EUS)" <[email-masked]>
Date: Wed, 17 Apr 2002 15:40:11 -0500

At the risk of adding fuel to an already huge fire, please find below the requirements on caller-id from the 3GPP.  I call them caller-id requirements as opposed to privacy requirements, because privacy is something bigger.  These have been presented on the CN1 list and there have been no objections to their content.  The 3 requirements are what 3GPP needs for Release 5.  The 3 non-requirements are NOT needed for Release 5.

In general, this is not the way we like to clarify requirements from the 3GPP, however this issue needs resolution quickly to meet our timeframes.  I encourage anyone from the 3GPP to set me right if they think I have mistated the requirements.

Requirement 1: 3GPP DOES need a way of indicating network asserted identity  Given that the To/From headers cannot be trusted, a way of indicating the subscriber identity is needed.  So far 3GPP has assumed the use of RPID for this purpose.

Requirement 2: 3GPP DOES need a way of restricting presentation of network asserted identity.  For purposes of authorization, the network will need to be able to identify a subscriber.  However, the user may not wish this information to be presented to the remote party or passed to an untrusted network.  This is analogus to the GSM CLIR capability.  Note that if the user has not requested that it's identity be suppressed, then the network should have the option of presenting the network asserted identity.

Requirement 3: 3GPP DOES need a way for the UE to pass the network an indication of what public identity it should use.  This identity might be for purposes of being displayed by the called UE or perhaps for processing within the network (e.g., charged to a particular account).  Having the UE populate the RPID has been proposed for this role although other mechanisms could probably also be used. Note that the network cannot rely on this identity information to be valid.

Non-requirement 1: 3GPP does NOT need to address inter-network trust boundaries (at least in this context).  In general, the UEs are considered to not be trusted. This means that the network must not send the network asserted identity to the UE or any other proxy that is not trusted (if the originator requested that it be restricted).  In general roaming relations imply a level of trust (you are after all trusting them to faithfully provide the SIP proxy function).  If all roaming partners are "trusted" then the issue of inter-network trust boundaries is irrelevant for the 3GPP.

Non-requirement 2: 3GPP does NOT need to address call trace across trust boundaries.  Given non-requirement 1, then the trace problem is an internal issue within the trusted boundary.  Trace functionality in 3GPP has also been moved to Release 6.

Non-requirement 3: 3GPP does NOT need to address total privacy in Rel 5.  3GPP needs a draft dealing with the restriction of RPID delivery.  It does not require addressing the general issue of obfuscating other SIP headers (including those supplied by the UE) and other information that could be correlated with a subscriber (such as an IP address).  This might be something that 3GPP would consider in a longer timeframe.

3GPP also assumes that there is integrity protection across all hops (including across trust boundaries), so that tampering with privacy related information is not an issue.  Also, the requirements apply to service platforms which may or may not be inside the trust boundary.

Regards, 
Stephen Hayes
3GPP TSG-CN Chair
Ericsson Inc.
Tel: +1 972 583 5773
Fax: +1 801 409 6319
Mobile: +1 469 360 8500
mailto:[email-masked]