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

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

Christian Huitema wrote:

> > 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;

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
> 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,

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
> 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.
>

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.

>
> -- 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

--
Flemming Andreasen
Cisco Systems

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

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

Juha Heinanen wrote:
> 
> Flemming Andreasen writes:
> 
>  > > in this example, the sip/isup gw will use one of its own phone
> numbers as
>  > > the calling party number and that number needs privacy, not the
> original
>  > > from uri sip:[email-masked].
>  > >
>  > Fine - just use the gw number instead then.
> 
> but my proxy that would need to insert the Remote-Party-ID on behalf of
> the UA, doesn't know what the gw number will be.
> 
>  > Nothing since there is no such requirement. In fact, if you have
> requested
>  > privacy, you are almost guaranteed that the two will be different.
> 
> i'm talkigng about the case where the UA doesn't understand the privacy
> stuff (like no UA that i have seen doesn't) and i have to in the proxy
> indicate the privacy requirement to the isup gw.  then the from field
> will include the real calling party number and the addr-spec in the
> Remote-Party-ID has no function.

Juha, I think what makes your problem more complex is that you have a UA
that has asked for privacy, but has inserted a valid From header anyway.

Normally, if the caller wanted anonymity, they would insert a From field
with value anonymous (and a bogus URL). If nothing else happens (i.e.,
no proxies insert R-P-ID), everything is fine. If a proxy does insert an
R-P-ID, which is needed to provide services and other functions, it has
to strip it at the edge of the trust boundary, and that is the purpose
of the privacy param.

Now, in your case, here is what I would do:

1. the UA inserts its own ID in the From field
2. proxy determines that the user has privacy features. So, it acts as a
B2BUA. It launches a new INVITE, different in that the From field now
indicates anonymous. An R-P-ID header is present, with privacy
indicated. If the next hop is not trusted, it is stripped. If it is, it
is passed on to the edge of the trust network.
3. If the GW is within the trust boundary, it will see from R-P-ID that
privacy is required, so it can set the ISUP flag appropriately. The URL
in the R-P-ID can contain a telephone number for the user, if the proxy
had one to put in, otherwise, the gateway will likely put in its own
number.
4. If the GW is outside the trust boundary, From indicates anonymous, so
the flag is set in the ISUP. However, there will be no phone number to
deliver, so that gateway will need to use its own. That is the penalty
for being outside the trust boundary.

This process is not different for ISUP termination or SIP termination,
as it should be. The cost of the B2BUA is because of your UA. Even
rfc2543 says to use Anonymous in the From field if anonymity is
required...

-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

---

From: "Holdrege, Matt" <[email-masked]>
Date: Thu, 24 Jan 2002 17:27:20 -0500

>you then need a "chain of trust" between all the proxies; yet, we have
>of the value in the privacy field, which goes contrary to what we see

The mechanism we have is SIP-T, right?

>the telephone network could directly translate.

Again, do we not have that with SIP-T? If SIP is used in a regulated
network, then the proxies can be mandated to use SIP-T to preserve the
regulation on caller-ID privacy. Of course, in a regulated network it might
be required to have "chain of trust" between proxies.

---

From: "Chiou, Mark" <[email-masked]>
Date: Thu, 24 Jan 2002 17:07:04 -0600

SIP-T does not solve the problem. For my understanding, SIP-T is useful
when 2 proxies server served as IWF are configured such that
back-to-back are ISUPs. For example ISUP->PS-(SIP-T)-PS->ISUP.
Otherwise, you want be able to map the cic number to the IP address
correctly.

Mark Chiou

-----Original Message-----
From: Holdrege, Matt [mailto:[email-masked]]
Sent: Thursday, January 24, 2002 4:27 PM
To: [email-masked]'; [email-masked]'
Subject: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway

Again, do we not have that with SIP-T? If SIP is used in a regulated
network, then the proxies can be mandated to use SIP-T to preserve the
regulation on caller-ID privacy. Of course, in a regulated network it
might
be required to have "chain of trust" between proxies.

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 27 Jan 2002 15:54:35 -0600

What a long thread.

The SIP-ISUP mapping draft suggests that if a telephone number is not
available in the From field of an INVITE received by a gateway (either
because the address in the From field is a SIP URI without telephone number
syntax, or if some sort of 'Anonymous' value is present for privacy
reasons), then the Calling Party Number (CgPN) parameter in ISUP should be
excluded when a corresponding IAM is sent to the PSTN. This mapping is
recommended because the CgPN parameter is not a mandatory parameter in the
IAM. Similarly, an originating telephone number is not required to construct
a SIP message.

As Juha points out later in this thread, many nationalities require the
presence of the CgPN parameter in IAMs. In the USA, for example, the CgPN
must be sent over certain types of trunks - though not all, as it happens.
Important exceptions are made in the USA (and elsewhere, I'm sure) for cases
in which ISUP is interworking with another protocol (like old-school MF
signaling). International calls routinely do not provide any information
about the caller. Similar exceptions apply to certain PBXs that do not
possess detailed information about the originator of a call (this is
directly analogous to Dean's SIP gateway). In short, anyone reading this
thread who believes that an ISUP network is going to break if you send an
IAM without a CgPN from a gateway should really talk to some operations
people at a major carrier - or look at how many times 'unavailable' shows up
on their own Caller-ID screen.

I believe that it is perfectly reasonable to look at a SIP-ISUP gateway as
another case along these lines: SIP is substantially a different protocol,
and sometimes SIP requests just don't have a Calling Party's Number -
irregardless of any privacy concerns. No generic mechanism can assume that
there is some 'correct' telephone number that must be associated with a
client. Compensating for this fact by requiring gateways to insert some
'gateway number' in the CgPN is a hack that doesn't assist procedures like
malicious call trace in any obvious way, and it is a hack that is also
forbidden by some interconnection agreements in the USA on account of its
use in grey-legal arbitrage scams. 

So in short, at a protocol level I think it is reasonable for the user's
omission of a 'telephony' identity in the From field (either because they
don't have one or for privacy reasons) to be communicated directly to the
PSTN through the omission of the CgPN. At a policy level, I think gateway
operators would be well advised to cryptographically authenticate users, and
record session parameters in order to provide sufficient data for abuse and
fraud detection. I mean, gateway operators could, if they were so inclined,
reject requests that don't have an originating 'telephony' identity, or even
a specific telephone number in the From field. However, this is quite
plainly orthogonal to the SIP-ISUP mapping process.

The mapping described in the SIP-ISUP draft is designed to work regardless
of whether the call originated at a network-controlled gateway or a
user-controlled client. Note (following Matt Holdrege) that if the session
originates in the ISUP world, then RFC3204 can be used to carry the original
CgPN information with any necessary parameters regarding presentation so
that an IAM can be appropriately constructed when a request returns to the
PSTN. If a call originates and terminates in the PSTN, then I think callers
(and network operators) will expect that the PSTN privacy features will work
- and I believe SIP-T satisfies that expectation.

As a design goal, SIP-T does not require any extensions to SIP or ISUP - it
tries to explain how you map the two protocols, not how you turn one into
the other. Initiatives other than SIP-T have attempted to demonstrate how to
make SIP, with extensions, a functional superset of the PSTN (the
sip-privacy draft clearly comes from that line of thinking). I agree with a
number of the respondents (including Christian) that this is actually very
difficult to do, and I maintain that the more modest SIP-T practice is
sufficient to interwork with the PSTN as I understand it.

Finally, the SIP-ISUP mapping draft does explicitly note that implementers
could make use of a generic SIP privacy mechanism - however, as I've argued
in the past, I'm not sure that one is currently on the table. I do agree
that there should be one.

Jon Peterson
NeuStar, Inc.

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 10:14 AM
> To: [email-masked]
> Subject: [Sipping] calling number blocking at sip/isup gateway
> 
> 
> i didn't find from draft-ietf-sipping-isup-00.txt, how should sip
> originated invite look like in order to prevent the called pstn party
> from seeing the calling sip party's number in the from field of the
> invite.
> 
> can a proxy add something to the invite on behalf of the calling sip
> user in order to get the calling number blocked by the sip/isup gw?
> 
> -- juha
> 
>

---

From: [email-masked]
Date: Wed, 30 Jan 2002 10:41:02 EST

In a message dated 1/29/02 11:57:47 AM Eastern Standard Time, 
[email-masked] writes:

> On Tuesday 29 January 2002 07:27 am, [email-masked] wrote:
>  > However, because of other security concerns, a real IP telephone
>  > service provider would require that it knows the identity of the
>  > calling party and the model for this service must be based on a
>  > presumption that the calling party can trust the service provider.
>  > Therefore, in this case, the From must contain a correct number, and
>  > the gateway may remove it (after verifying it).
>  >
>  > The case of the calling party leaving out the From can not be used in
>  > a "tariffed" (if I can use that term) telephone service. While the
>  > SIP protocol may allow it to be left out, the service provider may
>  > require it before allowing call setup.
>  
>  I run a real IP telephone service. Unknown parties may place calls over 
>  the Internet to my subscribers. My subscribers's profiles may result in 
>  forwarding those calls to a PSTN gateway. PSTN charges originating from 
>  this operation are charged back to the subscriber (the called party), 
>  not the calling party with whom I have no relationship outside the SIP 
>  used to set up the call.
>  
>  It really doesn't matter what the calling party put in their From: 
>  field, I still need to complete the call. Now, if they were kind enough 
>  to put in a phone number, I can map that into the IAM. But if they 
>  didn't, I just can't. Now, there's an interesting question on 
>  "authenticating" the phone number that they might have included., but 
>  that's a different problem.
>  
>  Even more interesting, I'm going to include any referenceable number 
>  from the INVITE in the IAM, regardless of any privacy indicator 
>  suggested by the SIP signaling, because that referencable number would 
>  have been included in the SIP signal delivered to my subscriber anyhow 
>  (The caller DID send it to him), and my job as a gateway oeprator is to 
>  get as much of the SIP experience as possible into the call being 
>  forwarded to the PSTN.
>  
>  So, here we have a real phone service which conflicts with the 
>  behavioral requirements suggested by mpierce's  post, as well as a 
>  whole can of privacy and transitive trust worms.
>  
>  --
>  Dean
>  
I was speaking of the service provider who handles the call origination. They 
must know the identity of the caller. (Note the e-mail from Juha about 
Finland.) I believe you are talking about a service provider who handles the 
destination or someplace in the middle of the call routing. Just like in the 
PSTN today, it only needs to trust the service provider it got the call setup 
from, so it does not require the originating party's ID at the destination. 
(It's nice if it's there, but not required.)

What bothers me is that we are modeling this on current stuff, and yesterday 
I got two copies of the new "Party" virus attached to e-mails from 
"UnknownSender". If we can't stop this in e-mail today, what is the future 
telephony network going to be like?

Mike