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

[Paul Kyzivat <[e-mail]>]

Michael Hammer (mhammer) wrote:
> Paul, Roland,
> 
> It seems like there are three parts to this model:
> What does the caller (police) send to indicate invocation of ACR-override,

I believe that has so far been unmentioned, though it probably should 
be. Of course we presumably don't trust a sender to identify that he is 
a police officer - that attribute would need to be authorized or added 
by the network acting on his behalf. But the police phone does at least 
have to populate the From header properly, and may need to do more to 
indicate an the choice of an option.

> What does the network do to the message to ensure it does not appear as anonymous,

I haven't seen that as a requirement, though perhaps it should be.

I'm going to guess that they expect the address to show up as 
"unavailable" rather than "blocked", but I don't think that is specified 
anywhere. In any case, that is probably not such a great strategy. Right 
now there are still (in the PSTN anyway) a fair number of call sources 
that are unable to provide caller identification, so a police call can 
hide among those. But as time goes on there become less and less of 
those. (There may not be any among VoIP callers.) So as time goes on, an 
attempt by police to hide their identity will fail because any call that 
gets through ACR with an identity of "unavailable" will be understood to 
be "blocked"+"privileged".

So perhaps Mike is right, that such calls should provide some 
identification, even if bogus.

> What does the message need to look like when handled by the called party.

I don't think we need specify how it is presented to a user. We only 
need specify how it looks when presented to the callee UA, and how that 
differs from other calls.

I think the following mechanism is getting a little too far out ahead of 
our understanding of the problem.

	Paul

> I would suggest that the first part is for the police sender to submit a message to the network that provides a valid yet bogus From: header, but with a convention-following P-Preferred-ID header that indicates it is from police and that override is to be invoked.
> 
> Second, on ingress, the network may authenticate and authorize the police sender to do ACR override.  The ingress would then form the P-A-ID header to match the From header.  Another indicator could be included to indicate that this was intentionally forged.  That additional indicator would need to be removed on egress.  The usefulness of that is perhaps more for back-end systems to record and not confuse with something fraudulent occurring.
> 
> On egress, the network is sending a message where the From: and P-A-ID header matches.  In this case, the message arrives at the UAS with From: and P-A-ID header the same.  Would that permit the UAS to *not* treat it as anonymous?
> 
> This does not solve the question of whether the indication should be enshrined explicitly by generalizing the role indicatory versus leaving this as an implicit indication derived from convention of URI construction.
> 
> Mike
> 
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Paul 
>>Kyzivat (pkyzivat)
>>Sent: Friday, August 26, 2005 1:03 AM
>>To: Miguel Garcia
>>Cc: [e-mail]; Alexeitsev, D
>>Subject: Re: AW: [Sipping-tispan] TISPAN requirements, first 
>>requiements
>>
>>Miguel,
>>
>>Yes, I think something is missing, having to do with how 
>>callers entitled to override of ACR are determined. But I 
>>still don't know what that requirement should say.
>>
>>	Paul
>>
>>Miguel Garcia wrote:
>>
>>>Paul, once Roland has explained the issue, what is your 
>>
>>proposal for 
>>
>>>clarification of the existing text? Do you think something 
>>
>>is missing?
>>
>>>/Miguel
>>>
>>>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.
>>>>
>>>>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 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-sipping-tisp
>>
>>>>>an-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