Re: AW: [Sipping] Re: Question on draft-rosenberg-sipping-acr-code-00

[Paul Kyzivat <[e-mail]>]

Jesske, R wrote:
> John,
> I showed only how TISPAN handle the ACR service, of course other solutions are possible at least also for the UA.
> So I think that there is no problem also to use it as a generic solution.
> The RFC3323 gives guideline how to anonymise the identity of the caller.
> So you can use the privacy header and the From header to do that.
> So from my understanding the privacy header can be sent to the UA so that there is a indication that privacy was required.

That is not how I read 3323. It says that as a token in the Privacy 
header is acted upon the token should be removed from the privacy 
header, and when all are removed the Privacy header should also be 
removed. So in the case of Privacy:id, when a proxy acts upon this by 
removing the P-Asserted-Identity header, it is also to remove the 
Privacy header. The only exception I see to this is Privacy:none, which 
must remain. But that isn't relevant here.

	Paul

> An other possibility is that the URI in the From header is set to Anonymous. In both cases the call can be rejected with the new response code.
> Of course as Paul said there are enough holes to bypass such a mechanism using other names within the From header. Fore these cases I only see the possibility to use a barring mechanism (black/white list).
> 
> I think how it is described within draft-rosenberg-sipping-acr-code-00 fits to the generic approach you are asking for.
> 
> Best Regards
> 
> Roland 
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Elwell, John [mailto:[e-mail]] 
>>Gesendet: Freitag, 13. Januar 2006 09:04
>>An: Jesske, Roland; [e-mail]; [e-mail]
>>Cc: [e-mail]
>>Betreff: RE: [Sipping] Re: Question on 
>>draft-rosenberg-sipping-acr-code-00
>>
>>
>>Roland,
>>
>>The problem is, I thought the sipping-acr-code draft was 
>>intended to be
>>general purpose, not something that was restricted to use in TISPAN
>>networks. Adding something to the main SIP response code 
>>repertoire means
>>that anyone can use it, and we should have procedures that 
>>explain how it
>>should be used in reasonable situations. I think a reasonable 
>>situation is
>>where a UAS receives a request without an identity it can 
>>trust and where
>>that identity has been withheld for privacy reasons. I fail 
>>to see how I can
>>do this at present.
>>
>>If we want a TISPAN specific solution, let's document it as 
>>such - I would
>>have no problem with that. Otherwise let's make sure we have 
>>a solution that
>>works elsewhere.
>>
>>John 
>>
>>
>>>-----Original Message-----
>>>From: Jesske, R [mailto:[e-mail]] 
>>>Sent: 13 January 2006 05:56
>>>To: Elwell, John; [e-mail]; [e-mail]
>>>Cc: [e-mail]
>>>Subject: AW: [Sipping] Re: Question on 
>>>draft-rosenberg-sipping-acr-code-00
>>>
>>>John,
>>>We have only specified the network based/application server 
>>>service. In Europe we have to provide this service within our 
>>>networks.
>>>
>>>For a end device service this would be the best way to 
>>>forward the privacy header, so that a UA based ACR can reject 
>>>the communication. 
>>>
>>>Best Regards
>>>
>>>Roland
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Elwell, John [mailto:[e-mail]] 
>>>>Gesendet: Donnerstag, 12. Januar 2006 21:31
>>>>An: Jesske, Roland; [e-mail]; [e-mail]
>>>>Cc: [e-mail]
>>>>Betreff: RE: [Sipping] Re: Question on 
>>>>draft-rosenberg-sipping-acr-code-00
>>>>
>>>>
>>>>Roland,
>>>>
>>>>Thanks for the clarification. So in TISPAN networks ACR would 
>>>>apply when PAI
>>>>is missing due to privacy reasons. If a UAS receives a 
>>>>request without PAI,
>>>>how does it know whether it is for privacy reasons or not? Is 
>>>>the Privacy
>>>>header forwarded to the UAS?
>>>>
>>>>John
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Jesske, R [mailto:[e-mail]] 
>>>>>Sent: 12 January 2006 12:51
>>>>>To: Elwell, John; [e-mail]; [e-mail]
>>>>>Cc: [e-mail]
>>>>>Subject: AW: [Sipping] Re: Question on 
>>>>>draft-rosenberg-sipping-acr-code-00
>>>>>
>>>>>That what we specified within ETSI is based on the PAI and 
>>>>>the privacy header. When the user expresses his wish to 
>>>>>anonymise it's public ID the ACR service will be invoked.
>>>>>With regard to the from header there is no triggering for the 
>>>>>ACR service.
>>>>>
>>>>>That is the same behaviour as for the equivalent PSTN/ISDN 
>>>>>service and the regarding requirements from regulation.
>>>>>
>>>>>It is not the requirement to block calls where a PAI is 
>>>>>absent due to network reasons like interworking with analogue 
>>>>>networks.
>>>>>
>>>>>The idea of an other response code for an untrusted identity 
>>>>>could be the basis for a new service that is not defined yet. 
>>>>>But thinkable.
>>>>>
>>>>>Best Regards
>>>>>
>>>>>Roland
>>>>>
>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>Von: Elwell, John [mailto:[e-mail]] 
>>>>>>Gesendet: Donnerstag, 12. Januar 2006 08:49
>>>>>>An: Paul Kyzivat; Jonathan Rosenberg
>>>>>>Cc: sipping
>>>>>>Betreff: RE: [Sipping] Re: Question on 
>>>>>>draft-rosenberg-sipping-acr-code-00
>>>>>>
>>>>>>
>>>>>>The point that Paul makes about putting a fictitious or 
>>>>>>meaningless caller
>>>>>>ID in the From header was what I had in mind when I asked 
>>>>>
>>>>>my original
>>>>>
>>>>>>question. If I get an ACR response I just substitute a caller 
>>>>>>ID at will,
>>>>>>and if this gets through my own domain then it will also 
>>>>>>avoid ACR. Without
>>>>>>PAI, Identity or AIB, the called domain or UAS has no way of 
>>>>>>detecting this.
>>>>>>
>>>>>>John
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Paul Kyzivat [mailto:[e-mail]] 
>>>>>>>Sent: 11 January 2006 22:45
>>>>>>>To: Jonathan Rosenberg
>>>>>>>Cc: Elwell, John; sipping
>>>>>>>Subject: Re: [Sipping] Re: Question on 
>>>>>>>draft-rosenberg-sipping-acr-code-00
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Jonathan Rosenberg wrote:
>>>>>>>
>>>>>>>>This is an old mail, my apologies for the really 
>>
>>long time 
>>
>>>>>>>to respond. 
>>>>>>>
>>>>>>>>This draft has started to get some attention 
>>
>>again recently.
>>
>>>>>>>>John raises an interesting point. This basic question has 
>>>>>>>
>>>>>>>been discussed 
>>>>>>>
>>>>>>>>almost endlessly in the SIMPLE/GEOPRIV groups as 
>>
>>well. The 
>>
>>>>>>>issue there 
>>>>>>>
>>>>>>>>was that the common policy/presence policy specs have had 
>>>>>>>
>>>>>>>fields that 
>>>>>>>
>>>>>>>>define an "anonymous" condition, and we've 
>>
>>debated whether 
>>
>>>>>>>>unauthenticated counts as anonymous.
>>>>>>>>
>>>>>>>>Unfortunately this never really concluded; we just got 
>>>>>
>>>>>rid of the 
>>>>>
>>>>>>>>anonymous condition :(
>>>>>>>>
>>>>>>>>In this particular case, I don't think it helps to count 
>>>>>>>
>>>>>>>unauthenticated 
>>>>>>>
>>>>>>>>as anonymous. The reason is, the whole point of the 
>>>>>>>
>>>>>>>resposne code is 
>>>>>>>
>>>>>>>>that the caller can do something different in an 
>>
>>attemtp to 
>>
>>>>>>>get the call 
>>>>>>>
>>>>>>>>through. In this case, the caller has not actually 
>>>>
>>>>TRIED to be 
>>>>
>>>>>>>>anonymous; its just that their service provider didn't 
>>>>>
>>>>>do PAID or 
>>>>>
>>>>>>>>sip-identity. So, if the call is rejected as 
>>
>>anonymous, the 
>>
>>>>>>>caller will 
>>>>>>>
>>>>>>>>be surprised, since it wasn't anonymous as far as 
>>
>>they were 
>>
>>>>>>>concerned, 
>>>>>>>
>>>>>>>>and there is nothing they can do about it to make it not 
>>>>>>
>>>>>>anonymous.
>>>>>>
>>>>>>>The problem is that there is no good way to tell the 
>>>>>>>difference between 
>>>>>>>blocked and unavailable. When using Privacy, the Privacy 
>>>>>
>>>>>header is 
>>>>>
>>>>>>>removed before the request gets to the UAS.
>>>>>>>
>>>>>>>While responding to this I noticed something missing from 
>>>>>>>draft-rosenberg-sipping-acr-code-00: it does not specify 
>>>>>>>proxy behavior. 
>>>>>>>This is significant because it is possible for the ACR 
>>>>>>
>>>>>>feature to be 
>>>>>>
>>>>>>>carried out by a proxy acting on behalf of the callee.
>>>>>>>
>>>>>>>If that is happening, and the proxy is in the same trust 
>>>>>>>domain with the 
>>>>>>>caller, then the situation is a *little* different, because 
>>>>>>>it can see 
>>>>>>>the Privacy header. So some blocked cases are 
>>>>>
>>>>>distinguishable from 
>>>>>
>>>>>>>unavailable cases. But that is still only a limited set, 
>>>>>>
>>>>>>because the 
>>>>>>
>>>>>>>caller could be in a different trust domain. So again, 
>>>>
>>>>it becomes 
>>>>
>>>>>>>necessary to fall back to reading the tea leaves to 
>>>>>
>>>>>decide between 
>>>>>
>>>>>>>blocked and unavailable. (Looking for Anonymous in the 
>>>>>
>>>>>From header.)
>>>>>
>>>>>>>Note that looking at From isn't reliable either. If I don't 
>>>>>>>want to be 
>>>>>>>blocked by ACR, I can just set my Privacy:id and set 
>>>
>>>my From to 
>>>
>>>>>>>something like: From: nobody 
>>>>>
>>>>><sip:[e-mail]>. Then the 
>>>>>
>>>>>>>callee will treat me as having an unavailable 
>>
>>address and let 
>>
>>>>>>>the call 
>>>>>>>through.
>>>>>>>
>>>>>>>I think the fundamental problem here is that 
>>>>>
>>>>>distinguishing between 
>>>>>
>>>>>>>unavailable and blocked can only work when all callers and 
>>>>>>>callees are 
>>>>>>>linked to a single trust domain.
>>>>>>>
>>>>>>>	Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>So, I'd suggest that we not include 
>>
>>unauthenticated in the 
>>
>>>>>>>list of cases.
>>>>>>>
>>>>>>>>-Jonathan R.
>>>>>>>>
>>>>>>>>Elwell, John wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>What if a UAS receives a request containing an 
>>>>
>>>>unauthenticated 
>>>>
>>>>>>>>>identity in the From header? If the UAS or user is not 
>>>>>>
>>>>>>prepared to 
>>>>>>
>>>>>>>>>trust the unauthenticated identity, the source of the 
>>>>>
>>>>>request is 
>>>>>
>>>>>>>>>basically anonymous. Is the new response code 
>>
>>intended for 
>>
>>>>>>>use in this 
>>>>>>>
>>>>>>>>>situation?
>>>>>>>>>
>>>>>>>>>John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>_______________________________________________
>>>>>>Sipping mailing list  
>>>>
>>>>https://www1.ietf.org/mailman/listinfo/sipping
>>>>
>>>>>>This list is for NEW development of the application of SIP
>>>>>>Use [e-mail] for questions on 
>>>
>>>current sip
>>>
>>>>>>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP