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

["Jitender Arora" <[e-mail]>]

I am slightly confused here , Are we proposing the solution for this problem?

or Are we just trying to capture the requirements?

Because as people have pointed out that we already have the RFC3323/3325/ which talk about the privacy and how we can provide the privacy at the user/network level.

Rgds,
Jitender
----- Original Message -----
From: "Miguel Garcia" <[e-mail]>
To: "Tom-PT Taylor" <[e-mail]>
Subject: Re: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements
Date: Thu, 25 Aug 2005 16:41:02 +0300

> 
> So what is an anonymous user? An anonymous user is one for which 
> his identity is not determined. The reason why a user is anonymous 
> is another story (the user want, or the network can't provide an 
> identity), but they are anonymous in both cases.
> 
> /Miguel
> 
> 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 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.)
> >
> > 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


-- 
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10


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