Subject: RE: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 29 Aug 2005 10:16:06 -0400

Miguel,

Does it matter that an "anonymous" call is showing up at the phone?  How
long do you think before the recipient figures out that only an
"authority" could force such calls to him despite anonymous call
blocking?

That lead me to wonder whether the call had to assert a bogus calling
party number?  And if so, wouldn't it be better to assert an identity
controlled from the original domain of the call?  And if so, why even
bother follow-on networks with additional work to do to manipulate
headers for override, when the originating network could construct a
perfectly "non-anonymous" call?  Seems like this could be simpler.

Perhaps, I didn't understand the fundamental purpose here.

Mike

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: Monday, August 29, 2005 2:50 AM
> To: Michael Hammer (mhammer)
> Cc: Jesske, R; [email-masked]; Alexeitsev, D
> Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN 
> requirements, first requiements
> 
> But this solution of adding a parameter to the 
> P-Asserted-Identity works. IMS supports from day one RFC 
> 3325, so there are procedures to add/delete the 
> P-Asserted-Identity when traversing a trust domain.
> 
> Now, if you add a parameter to that header field, proxies 
> that do not support the extension will not act upon it, so 
> they will forward it if present and if the 
> P-Asserted-Identity header fiedl has to be forwarded. 
> If the header field is stripped, it will include the 
> parameter, which is, in my opinion, the correct behaviour.
> 
> /Miguel
> 
> Michael Hammer (mhammer) wrote:
> 
> > My concern over what gets put into the message, is that those 
> > indicators could potentially be leaked to the UAS because some 
> > intermediate node was not updated with the latest RFC, and 
> according 
> > to SIP merely passed on what it did not understand.
> > 
> > Mike
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[mailto:[email-masked]] On Behalf Of Miguel Garcia
> >>Sent: Friday, August 26, 2005 7:44 AM
> >>To: Jesske, R
> >>Cc: [email-masked]; Alexeitsev, D
> >>Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN 
> requirements, first 
> >>requiements
> >>
> >>Hi Roland:
> >>
> >>If you don't have a P-Asserted-Identity in the signalling, 
> is because 
> >>the trust relationship has been broken at some point, in 
> which case, 
> >>you shouldn't trust also the role parameter independently of the 
> >>header where you put it.
> >>
> >>The nice property of adding a role parameter to the 
> >>P-Asserted-Identity header is that you get the trust for 
> free, which 
> >>is the expected behaviour for this service.
> >>
> >>/Miguel
> >>
> >>Jesske, R wrote:
> >>
> >>
> >>>>>I think it might be worth considering adding role parameters to 
> >>>>>P-Asserted-ID.
> >>>>
> >>>>That is OK with me and solves most of the problems.
> >>>>
> >>>
> >>>
> >>>
> >>>Paul,
> >>>I have to revice my proposal. 
> >>>I thought that is the solution to bind it to the
> >>
> >>P-Asserted-Id. But in the case were we have a anonymous 
> communication 
> >>restricted by the network. We usually have no Calling Party number. 
> >>And therefore also no P-Asserted-Identity.
> >>
> >>>So we cannot bind this to the P-Asserted-Identity.
> >>>
> >>>Perhaps we can bind it to the privacy header?
> >>>
> >>>Or any other?
> >>>
> >>>Best Regards.
> >>>
> >>>Roalnd
> >>>
> >>>_______________________________________________
> >>>Sipping-tispan mailing list
> >>>[email-masked]
> >>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> >>
> >>-- 
> >>Miguel A. Garcia           tel:+358-50-4804586
> >>sip:[email-masked]
> >>Nokia Research Center      Helsinki, Finland
> >>
> >>
> >>_______________________________________________
> >>Sipping-tispan mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/sipping-tispan
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 29 Aug 2005 21:56:20 +0300

Hi Michael:

Inline answers.

> "authority" could force such calls to him despite anonymous call

As I understand the regulatory service, it does not matter if 
"anonymous" is shown at the phone.

I agree that it can be easily derived, but the service does not intend 
to address this issue.

This is the same situation we have today when someone calls me 
anonymous. Actually, there is only one person who typically calls me 
anonymously, so when he calls, I always answer the phone with "Hello 
Jim" (Jim is not actually his name). But you get the idea, right?

> perfectly "non-anonymous" call?  Seems like this could be simpler.

Well, I am not sure if that will work at all. Essentially this requires 
to allocate a bunch of bogus identities to those authorities that can 
bypass ACR. Anonymity will be achieved by having a large number of bogus 
identities, and having the UAC software able to change the identity on 
every call to the same callee (otherwise, the callee will know who is 
ringing the second time).

Still it won't solve the issue of what happens if that authority selects 
the "anonymity" button in his UAC, and does an anonymous call? If you 
read the european privacy act (referred to in this list a few days ago), 
  the call will not go through if the calle has ACR activated, and most 
likely, the operatore will be responsible for it. Perhaps something that 
we shouldn't be taking a risk on.

> Perhaps, I didn't understand the fundamental purpose here.

I am sure you did. Thanks for your comments.

/Miguel

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 29 Aug 2005 16:14:08 -0400

Below.

> we shouldn't be taking a risk on.
[PTT] I still don't understand.  Why would a bunch of bogus identities 
have to be allocated?  Why can't the common identity: "Official" be 
used, for instance?

...

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 30 Aug 2005 15:41:24 +0300

Tom-PT Taylor wrote:

>>
>> Well, I am not sure if that will work at all. Essentially this 
>> requires to allocate a bunch of bogus identities to those authorities 
>> that can bypass ACR. Anonymity will be achieved by having a large 
>> number of bogus identities, and having the UAC software able to change 
>> the identity on every call to the same callee (otherwise, the callee 
>> will know who is ringing the second time).
>>
>> Still it won't solve the issue of what happens if that authority 
>> selects the "anonymity" button in his UAC, and does an anonymous call? 
>> If you read the european privacy act (referred to in this list a few 
>> days ago),  the call will not go through if the calle has ACR 
>> activated, and most likely, the operatore will be responsible for it. 
>> Perhaps something that we shouldn't be taking a risk on.
>>

Because if you allocate an "Official" identity, which is presented to 
the callee, then a second call that will come from the same identit the 
callee would actually know who is calling... Well, perhaps you can argue 
that there is no requirement to tackle this problem (and perhaps you are 
right): it seems that the goal of the regulator is to deliver the call 
to the callee, not to prevent the callee to guess who is calling.

So, ok, perhaps we don't need "a bunch" if bogus identities, but just a 
bogus identity (per category).

/Miguel