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

From: [email-masked]
Date: Fri, 25 Jan 2002 09:41:00 -0700

> 
> Hi,
> 
> These are just some thoughts, so please don't flame me :)
> 
> There was once a discussion (open issue #140) if the whole of the To-
> and From headers, or only the tag, should be used as call-leg/dialog
> identifiers. 
> 
> The decission was that they should.
> 
> So, ASSUMING that ONLY the tags of the To- and From headers were used
> for the dialog identifier, I guess it wouldn't matter if proxy would
> modify the SIP-URI part of the To- and From headers? So, the question
> is: would that make the problem we are discussing here any easier? 

 Sounds dangerous for backward compatibility, as most UAs out there still
use these headers to ID the session.

> 
> Also, after the session is established, the whole SIP-URI 
> wouldn't have
> to be included in the SIP message To- and From headers in the first
> place, which could add some security, and which would make 
> the messages
> at least a little shorter, but that's another issue...
> 
> Again, I am NOT proposing anything, and I KNOW #140 is closed - I am
> just asking a simple question :)
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> Mark Watson wrote:
> > 
> > I have to say I am amazed too. But by the idea that the privacy
> > regulations we see in the PSTN/ISDN may not apply in the SIP world.
> > These stem from technology-neutral Data Protection legislation which
> > applies as much to SIP as to ISUP or TUP.
> > 
> > Sure, in a model where there are no trust relationships, then if you
> > want to keep something private you either (a) don't send it 
> at all (b)
> > encrypt so that only people you *do* trust can see it.
> > 
> > It comes back to the trust model argument.
> > 
> > I do think it likely though that there will be models where 
> calls are
> > routed between service providers on the basis of Service Level
> > Agreements between those providers. If your SLA includes that the
> > other provider agrees to provide certain QoS etc. for your
> > subscriber's calls, it can also include provisions 
> regarding trust of
> > user identities etc.
> > 
> > There are also reasons why the Service Providers may wish 
> to exchange
> > the identity/ies of the caller, but the caller may wish to remain
> > anonymous to the called party.
> > 
> > Mayby these Service Providers are incredibly naive ? Mayby 
> they should
> > be happy to rely on networks with which they have no SLA to deliver
> > calls on behalf of their subscribers ? Mayby there is no market for
> > better than best effort service ?
> > 
> > Regards...Mark
> > 
> > > -----Original Message-----
> > > From: Christian Huitema [mailto:[email-masked]]
> > > Sent: 24 January 2002 18:01
> > > To: Juha Heinanen; Dean Willis
> > > Cc: [email-masked]
> > > Subject: RE: [Sipping] calling number blocking at sip/isup gateway
> > >
> > >
> > > > 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
> >

_______________________________________________
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

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Sat, 26 Jan 2002 02:20:22 +0200

Hi,

>use these headers to ID the session.

Well, the UAS would always see the same header values. And, if the proxy
which changes the headers also inserts itself in the route, it could
always by default change the headers back when sending a message
(request or reply) to the UAC, so the header values between the UAC and
that proxy would also always be the same.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Jan 2002 13:32:15 -0500

> that proxy would also always be the same.

Sounds like a B2BUA, which is what I proposed to Juha would be needed
for this particular problem. The proxy/b2bua HAS to modify all messages,
not just for dialog matching, but for privacy! If it modifies the From
only in the INVITE, but the BYE contains the original From field,
privacy has been compromised.

-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: Christer Holmberg <[email-masked]>
Date: Sun, 27 Jan 2002 21:47:06 +0200

Hi,

>for this particular problem.

Well, one could argue you don't have to call it that, since the modified
parts (the SIP-URI) would not be part of the dialog identifier (which
would be the To- and From header TAGS, and Call-ID)

>The proxy/b2bua HAS to modify all messages, not just for dialog matching, but for privacy!

Yes, that was my idea (if it only modifies the INVITE there would be
backward compability issues which nodes still using the WHOLE From
header, and not only the tag, as dialog identifier).

Regards,

Christer Holmberg
Ericsson Finland