Subject: RE: [Sipping] calling number blocking at sip/isup gateway

From: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Jan 2002 10:01:28 -0800

> ok, i tried again and still can't figure out how my proxy can tell to
a
> trusted sip/isup gw that the calling user doesn't want his/her phone
> number to be shown to the called pstn user.  i would like to be able
to
> do something simple in the proxy, like adding a header
> 
> Anonymity: from
> 
> to the invite, but that kind of thing is not available.  my suggestion
> is that the authors of the privacy i-d and the sip-isup i-d figure it
> out how to map isup Calling party indicator "Address presentation
> restricted" to/from sip.  before that is done, i would not vote going
> forward with either i-d.

There is an obvious tension between four issues:

- The fact that when an UA is under the user's control, the content of
the header fields can be set to arbitrary values, and that any header
field can be expected to be read by the final user;
- The legal requirement in many countries for "traceability", i.e. the
possibility for law enforcement to find the source of any phone call;
- The desire in many cases to place anonymous calls, i.e. without
disclosing the identity and/or the location of the caller (Think
"whistle blower");
- The desire in even more cases to block anonymous calls (Think spam).

The mix of the four makes for an unsavory soup. In the privacy draft,
the law enforcement requirement can only be met by letting a proxy
insert a "Remote-Party-ID" header; but the moment you do that, you
enable every party down the chain to see and display that header. To
prevent abuse, the draft creates a "RPID-Privacy" header that the caller
should set to the appropriate value if it does not want the information
casually displayed. 

Frankly, I am amazed by the naivety of the proposal. To make this work,
you then need a "chain of trust" between all the proxies; yet, we have
no mechanism to determine this level of trust. We also need to assume
that the information will not be displayed by the called UA regardless
of the value in the privacy field, which goes contrary to what we see
with e-mail, and also goes contrary to the obvious desire to fight spam.

Frankly, I don't find this privacy draft useful or adequate. It attempts
to comply with telephony-era regulations that have basically no meaning
in the Internet. In fact, we could probably meet these regulations by
having a much simpler solution that directly target ISUP compatibility:
a calling telephone number header, with a privacy tag, that gateways to
the telephone network could directly translate.

-- Christian Huitema 

_______________________________________________
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

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 24 Jan 2002 20:16:25 +0200

> field can be expected to be read by the final user;

if our customer makes a call via our proxy, it checks the validity of
the user's from field, i.e., makes sure that it corresponds to one of
the identities that the customer has agreed to use.

 > possibility for law enforcement to find the source of any phone call;

that's why we do the above.

 > disclosing the identity and/or the location of the caller (Think

this is why i ask on the sip side a capability that we can map to
"restricted" calling party number capability.

 > - The desire in even more cases to block anonymous calls (Think spam).

yes.

 > In fact, we could probably meet these regulations by

i fully support this.  the privacy i-d is a hyge overkill for this
simple purpose.

-- juha

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Jan 2002 13:53:32 -0500

Christian Huitema wrote:

> you then need a "chain of trust" between all the proxies;

Not all the proxies - only the proxies within your trust boundary. As a
special case of this, a proxy may not trust any other proxies and hence
always encrypt the Remote-Party-Id with privacy indication before forwarding
the message.

> yet, we have
> of the value in the privacy field,

No. There is an explicit distinction between forwarding messages to trusted
and non-trusted entities. Whenever you forward a message to an untrusted
entity, and privacy has been requested, you will encrypt the Remote-Party-ID
information. It's never passed in clear to an untrusted entity.

> which goes contrary to what we see

This doesn't change any of the fundamental problems and solutions in the
draft. All you are saying, is that the only identity information that can be
provided and protected are telephone-numbers. The more general SIP-URLs will
not have this ability and hence cannot be used if we wanted to provide a
similar service. I don't think that's very compelling.

-- Flemming

PS: This discussion should probably be moved to the SIP list.

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 24 Jan 2002 14:01:20 -0500

> the identities that the customer has agreed to use.

The only problem with that is you can't provide any privacy now, since you
can't change the contents of the From header field. That may work as long as
you are only considering a pure toll bypass information where the SIP messages
never make it to untrusted entities. However, it doesn't work in general.

> i fully support this.  the privacy i-d is a hyge overkill for this

Well, the privacy draft is not just for ISUP interworking.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 24 Jan 2002 21:23:20 +0200

Flemming Andreasen writes:

 > you are only considering a pure toll bypass information where the SIP
 > messages never make it to untrusted entities. However, it doesn't work in
 > general. 

today i don't know any commercial sip ua that would support the privacy
stuff.  this means that i can hide the calling party identity only from
pstn called parties.  i agree that in order to hide the calling party
identity from sip called parties, then the sip ua must participate in
the privacy stuff.  but the feasibility of it may be questioned, which i
think was christian's point.

anyway, since even in the sip/isup case it is not obvious how the
mapping is done, it should be documented in the sip-isup i-d like any
other mapping.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 16:48:24 -0500

Christian Huitema wrote:

> with e-mail, and also goes contrary to the obvious desire to fight spam.

Christian, where were you when the DCS stuff was first introduced to
IETF, and the same exact arguments and debates were made? I recall
making these same arguments over a year back ;) The issue of trust
boundaries has been the one and only real issue of debate and discussion
on this draft.

As Flemming has pointed out, the R-P-ID header can stay so long as it is
within a trust boundary. Now, what one of those is, is a good question.
Practically speaking, for any inter-domain call, there will not be
sufficient trust, and the header is stripped. Thus, anonymous calls work
as they should - the From field says anonymous, and there is no other
identifying information about the caller (except IP addresses for RTP
and SIP Contact, that is somewhat separate). Because I believe the data
will pretty much always be stripped as soon as it leaves the calling
domain, the draft is far less silly as it might appear. It does solve an
important problem - which is a placeholder for a network authenticated
identity, used to drive services and features in the user's domain.

> the telephone network could directly translate.

How would that solve the problem? If I want to be anonymous, this
information would be inside the INVITE from the caller, and thus no
privacy assured, for the exact reasons you point out above.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com