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

[Miguel Garcia <[e-mail]>]

It does not change anything, you are assuming a solution: "the 
signalling carries some information that... "

/Miguel

Tom-PT Taylor wrote:

> Perhaps I should have used the phrase "SIP signalling must include the 
> information that ...".  Your phrasing itself puts the focus on the 
> anonymous users.  This is relevant to the actions at the point where my 
> piece of information is inserted, but not to anything downstream of 
> that.  I believe the downstream aspects are what matter in our current 
> discussion, because these are where new mechanisms, if any, may be 
> required.
> 
> Miguel Garcia wrote:
> 
>> Tom:
>>
>> I agree with you in the essence, but you are referring to a solution, 
>> not to a requirement. Essentially, whenever you need to speak about an 
>> "indicator", it raises an alarm in my head that you are speaking about 
>> a possible solution rather than a requirement.
>>
>> So the requirement is tha there are certain anonymous users that are 
>> not subject to be filtered by ACR. Then we can further discuss the 
>> solution, which is probably going in the direction you suggest.
>>
>> /Miguel
>>
>> Tom-PT Taylor wrote:
>>
>>> Let's just summarize the requirement.  You've tied it to other 
>>> mechanism below.  I think it will be less confusing to abstract out 
>>> the actual information that is needed.
>>>
>>> So: the requirement is that it be possible to include in SIP 
>>> signalling an indicator that network-provided Anonymous Call 
>>> Rejection should be overridden.  This is needed in two circumstances: 
>>> when the caller identity is unavailable in the first place, and when 
>>> Privacy is invoked.  There is an obvious ancillary requirement that 
>>> this indicator be acted on only if it comes from a trusted source.
>>>
>>> Jesske, R wrote:
>>>
>>>> Paul,
>>>> I hope we do understand in future. Next Try. See below.
>>>>
>>>>
>>>>
>>>>
>>>>> -----Ursprüngliche Nachricht-----
>>>>> Von: Paul Kyzivat [mailto:[e-mail]] Gesendet: Donnerstag, 
>>>>> 25. August 2005 05:31
>>>>> An: Jesske, Roland
>>>>> Cc: [e-mail]; [e-mail]; 
>>>>> Alexeitsev, Denis
>>>>> Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first 
>>>>> requiements
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Jesske, R wrote:
>>>>>
>>>>>> Paul,
>>>>>> With regard to this feature it must be based on trust 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> relationship as defined within RFC3325 for the P-Asserted-Identity.
>>>>>
>>>>>> So the indication that this is a authorised user is 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> included by a network entity like it is done for the 
>>>>> P-Asserted-Identiy.
>>>>>
>>>>>> So the network entity knows it via a database that this 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> registered user is a authorised one.
>>>>>
>>>>> Either I don't understand you, or you don't understand me.
>>>>>
>>>>> RFC3325 is a way for some trusted element of the network that knows 
>>>>> the source of the request to assert a trusted identity for the 
>>>>> source of the message. It doesn't provide any authorization for 
>>>>> anything.
>>>>
>>>>
>>>>
>>>>
>>>> For the Marking of a call with a bypass allowance a network element 
>>>> must include on behalf of the user this element so that a 
>>>> Police-call is really a police call.
>>>> I will try it with some flows:
>>>>
>>>>
>>>> Police
>>>>   UA:A        Proxy            ACR          UA:B
>>>>    ------------->  ----------->   ----------->    F1:INVITE         
>>>> F2:INVITE     F3:INVITE
>>>>
>>>>
>>>> F1: INVITE
>>>> No indications From: Anonymous
>>>>
>>>> F2: INVITE
>>>> A indication is added indicating that this communication comes from 
>>>> a official authority (Police)
>>>> From: Anonymous
>>>> P-Asserted-Identity with privacy Id
>>>>
>>>>
>>>> F3: INVITE
>>>> ACR server forwards the communication due to the  bypass indication
>>>> From: Anonymous
>>>>
>>>> PSTN         PSTN/ISDN
>>>>   User A         GW           ACR          UA:B
>>>>    ------------->  ----------->   ----------->    F1:IAM           
>>>> F2:INVITE     F3:INVITE
>>>>
>>>> F1: IAM:
>>>> No Calling Party number is included
>>>> Call is marked as restricted by the network
>>>>
>>>> F2: INVITE
>>>> A indication is included that points to the fact that the call is 
>>>> Anonymous because of a network restriction
>>>>  From: Anonymous
>>>> P-Asserted-Identity absent
>>>> F3: INVITE
>>>> ACR server forwards the communication due to the  indication that 
>>>> the communication is anonymous because of network restriction
>>>> From: Anonymous
>>>>
>>>> Untrusted    my network
>>>>  ProxyA       Proxy B            ACR          UA:B
>>>>    ------------->  ----------->      F1:INVITE         F2:INVITE   
>>>> F1: INVITE
>>>> No indications From: Anonymous
>>>> No P-Asserted-Identity
>>>>
>>>> F2: INVITE
>>>> No indication will be added because the request comes from an 
>>>> untrusted proxy
>>>> From: Anonymous
>>>> No Privacy
>>>>
>>>> ACR rejects the communication
>>>>
>>>>
>>>>
>>>>> Ultimately, the ACR service must be implemented near and on behalf 
>>>>> of the recipient of the message. It isn't until there that it is 
>>>>> known that there is any service to authorize. At that point, the 
>>>>> P-Asserted-ID header may be present, but that just says who the 
>>>>> caller is, not what role the caller is playing. It seems that you 
>>>>> want to do role based authorization, where the role is 
>>>>> "entitled-to-override-ACR".
>>>>>
>>>>> So how is this role determined? Surely the recipient can't have a 
>>>>> DB of all values of P-Asserted-ID that are authorized. The 
>>>>> alternative seems to be that the source inserts not just a simple 
>>>>> P-Asserted-ID with a name, but rather also inserts some kind of 
>>>>> role identification.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> That could be the way out. That such a indication shall be bind to 
>>>> the P-Asserted identity and is included by the originating 
>>>> network-entity.
>>>> Because we bind the ACR service to the P-Asserted-Identity.
>>>>
>>>> We reject the communication if a P-Asserted-Identity is included and 
>>>> the priv value is "Id", "user","header" and /or ""critical" and if 
>>>> the P-Asserted-Identity is absent.
>>>>
>>>>
>>>>> I'm looking for more indication of what the expectations are in 
>>>>> this regard. Is it the expectation that the source will annotate 
>>>>> every call with an indication that the caller is permitted to 
>>>>> override ACR? 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yes.
>>>>
>>>>
>>>>> Or with some other more generic categorization of caller type? 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> That could be also a possibility. For solving the police 
>>>> communications but it makes it not easy with the ISDN/PSTN 
>>>> interworking. Because if we have such a caller type (What is also 
>>>> another requirement) than we have to distinguish at the Interworking 
>>>> Unit. Because some caller types can be mapped to the Calling parties 
>>>> category and others must be mapped to the network restriction 
>>>> indication.
>>>>
>>>>
>>>>> Or what?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> With regard to the PSTN/ISDN this was solved via a 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> indication that the Calling Party Number is restricted by the 
>>>>> network. The network included this indication in three cases:
>>>>>
>>>>>> 1. The call was originated within a network that cannot 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> provide a originating number (e.G.) analogue.
>>>>>
>>>>>> 2. The call has no originated number due to interworking 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> with international networks
>>>>>
>>>>>> 3. The call was send from a authorised user (e.G. police). 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This indication was then set by the network. This feature is 
>>>>> especially used in UK.
>>>>>
>>>>> So you are looking for some kind of enhancement to Privacy, that 
>>>>> indicates *why* privacy is requested?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> From my point of view YES.
>>>>
>>>>
>>>>
>>>>
>>>> First Idea was to have a privacy value that says "network 
>>>> restricted" (as it is in the PSTN/ISDN) to express that the Id is 
>>>> missing because of some network restrictions (like interworking, 
>>>> Analogue originating or such police calls). Because to add such 
>>>> value to the privacy header would be easy.
>>>> But people had the opinion that this has nothing to do with privacy. 
>>>> So we looked fore some other possibility. That is what I have showed 
>>>> you above.
>>>>
>>>> I hope that this was better that we can come together and you 
>>>> understand me.
>>>>
>>>> Roland
>>>>
>>>>
>>>>
>>>>>     Paul
>>>>>
>>>>>
>>>>>> So with the requirement proposed by Miguel we hope to find 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> a solution to cover the 3 above mentioned cases.
>>>>>
>>>>>> With regard to trust we want to have such a indication bind 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> to a trust relationship as it is described within RFC3325.
>>>>>
>>>>>> So trust for interconnection to an other network is based 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> on bilateral agreement.
>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>> Roland
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>> Von: [e-mail] 
>>>>>>> [mailto:[e-mail]] Im Auftrag von Paul Kyzivat
>>>>>>> Gesendet: Mittwoch, 24. August 2005 05:07
>>>>>>> An: Miguel Garcia
>>>>>>> Cc: [e-mail]; Alexeitsev, Denis
>>>>>>> Betreff: Re: [Sipping-tispan] TISPAN requirements, first requiements
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Miguel Garcia wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Folks:
>>>>>>>>
>>>>>>>> Since we are tasked to re-draft the TISPAN requirements 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> adding as much
>>>>>>>
>>>>>>>> clarifications as possible, we would like to start checking 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> with you if
>>>>>>>
>>>>>>>> the requirements related to the Annonymous Communication 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Rejection (ACR)
>>>>>>>
>>>>>>>> service is OK and understandable by everyone.
>>>>>>>>
>>>>>>>> So please take a look at the first version of the (much 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> incomplete and
>>>>>>>
>>>>>>>> short) draft in either text or HTML:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> g-tispan-requirements-02a.txt
>>>>>>
>>>>>>> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp
>>>>
>>>>
>>>>
>>>>
>>>> ing-tispan-requirements-02a.html
>>>>
>>>>>>
>>>>>> The document is fairly short at the moment. Please post your 
>>>>>> comments here.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regarding REQ-ACR-2:
>>>>>
>>>>>
>>>>>
>>>>>>  REQ-ACR-2: It must be possible that authorized callers are not
>>>>>>             subject to the ACR service, thus, allowing the callee to
>>>>>>             receive anonymous requests from authorized callers.  This
>>>>>>             effectively requires a mechanism to override the ACR
>>>>>>             service depending on the identity and authorization of 
>>>>>> the
>>>>>>             caller.  This is needed, e.g., when a police officer or
>>>>>>             any other authority is anonymously calling to a user
>>>>>>             having the ACR simulation service activated.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> How is a caller authorized? Is the mechanism for determining and 
>>>>> conveying this authorization in scope for this service? There is 
>>>>> mention specifically of Police Officers, among others, as being 
>>>>> authorized. Are there a list of attributes like that which must be 
>>>>> used to characterize a caller and that are used to determine the 
>>>>> authorization?
>>>>>
>>>>> How is this affected by peering and PSTN interconnect? Is an 
>>>>> authorization on one side to be conveyed to the other side and then 
>>>>> trusted their?
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>> _______________________________________________
>>>>> Sipping-tispan mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Sipping-tispan mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Sipping-tispan mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>
>>
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


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