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

[Miguel Garcia <[e-mail]>]

Hmmm... I think we don't have the second requirement. The call presented 
to teh UAS could still be anonymous, at least, this was my understanding.

Michel, do you think we have to change any of the 3 listed requirements in
http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02b.html

BR,

     Miguel

Michael Hammer (mhammer) wrote:

> Miguel,
> 
> Although my other message outlined a solution, the requirements might be driving the wrong solution.
> 
> My requirements:
> 
> 1) The police UAC needs a means to inform the network that it needs present a call to the UAS that will not be rejected as anonymous.
> 
> 2) The network needs to present a non-anonymous call to the UAS.
> 
> I would be curious to know why the call needs to be anonymous.  If someone calls the number back, it could be answered with some bogus business name, if the intent was to not answer "so-and-so police department".
> 
> Mike
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Miguel Garcia
>>Sent: Friday, August 26, 2005 3:23 AM
>>To: Paul Kyzivat (pkyzivat)
>>Cc: [e-mail]; Alexeitsev, D
>>Subject: Re: AW: AW: [Sipping-tispan] TISPAN requirements, 
>>first requiements
>>
>>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
> 
> 

-- 
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