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

[Elwell John <[e-mail]>]

Roland,

What value is the ACR server adding that cannot be provided by the UAS? Or
put it another way, even if the ACR server allows certain authorised callers
to override ACR, an "ACR" capability at the UAS would presumably not allow
this so it would still reject all anonymous calls. So what has the ACR
server achieved?

John

> -----Original Message-----
> From: Jesske, R [mailto:[e-mail]] 
> Sent: 25 August 2005 09:52
> To: [e-mail]
> Cc: [e-mail]; Alexeitsev, D
> Subject: AW: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> 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