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

[Miguel Garcia <[e-mail]>]

So Paul seems to be suggesting to add a requirement indicating that 
someone has to authorize the identities, (perhaps based in roles, 
perhaps in URIs) who can bypass ACR. I think this is a role ACR service 
provider. So what about if we add one more requirement along these lines:

"It must be possible for the the ACR service provider to determine the 
callers who can bypass the ACR service of the callee."

On the solution space, I think we are heading to adding something like a 
  role parameter to the P-Asserted-Identity. Using the trust required by 
P-Asserted-Identity, it is possiblet that the ACR service provider if it 
trusts a P-Asserted-Identity it will also trust the role parameter, than 
can take the format of "police", "fire", or whatever is needed.

Comments?

/Miguel

Paul Kyzivat wrote:

> 
> 
> Tom-PT Taylor wrote:
> 
>> I think your requirement is not quite accurate even at this level of 
>> abstraction.  Roland has identified two different cases.  One is your 
>> "certain anonymous users", but the other is the case where the user 
>> identity is unable due to the network's inability to provide it.
> 
> 
> I agree with Tom on that. But in addition I think there is another 
> requirement lurking there: *somebody* has to decide *who* the "certain 
> anonyous users" are who qualify. I can't yet tell whether this decision 
> is made entirely at the originating end, or partly at the terminating 
> end. For instance, as I mentioned in another message, it could be that 
> the originating end determines that the caller has the role "police" 
> while it is the terminating end that determines that the role "police" 
> is entitled to bypass ACR. Or, it could be that the originating end 
> explicitly determines that the caller, for whatever reason, is entitled 
> to bypass ACR if need be. Or it could be that the terminating end has to 
> make the entire decision about whether this caller is entitled to bypass 
>  ACR.
> 
> So I think something about who is expected to make what part of the 
> decision needs to be a requirement.
> 
>> I guess I can see your point about pushing too hastily to mechanism. 
>> Roland actually identified the information that might be used to 
>> resolve the issue at the rejection point: on the one hand, the 
>> identity of the caller if present in a P-A-Id, and on the other hand, 
>> the absence of a P-A-Id.  It may be that this is all that is needed, 
>> and no further discussion is required in SIPPING.  (Of course, that's 
>> assuming that the number of authorized caller identities any one 
>> rejection point has to keep track of is limited and provisionable.)
> 
> 
> I don't think it is very plausible that the receiving end would have 
> access to a list of all the police officers (anywhere in world?) that 
> are entitled to this treatment.
> 
>     Paul
> 
>> 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
>>>>
>>>
>>
>>
>> _______________________________________________
>> 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