Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead ofeGRUU

From: "Carlberg, Kenneth G." <[email-masked]>
Date: Thu, 1 Dec 2011 08:10:10 -0500

Unless I missed something, there isn't anything in the approach that
identifies the UAs as being associated with a PSAP, and so nothing to
distinguish it from any other UA.  As a result, while item 3 below
points out that the approach does not promote abuse risk, its still
subject to malicious DoS attacks.  Correct?

-ken

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On
Behalf
>  Of Henning Schulzrinne
>  Sent: Wednesday, November 30, 2011 8:33 PM
>  To: Christer Holmberg
>  Cc: Adam Roach; ECRIT
>  Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority
instead
>  ofeGRUU
>  
>  Here's a slightly different model:
>  
>  (1) The UA requests (or automatically gets) a special emergency
(temp)
>  GRUU; we can request this in some way, probably using a Contact
>  parameter. sip.priority=emergency would probably work if we want to
re-
>  use something.
>  
>  (2) The UA uses that GRUU in the emergency call. There is no need to
>  mark it - the PSAP has no control over call handling at the emergency
>  caller anyway, so it does the same thing whether the UA knows about
>  special handling or not.
>  
>  (3) The PSAP places a normal call-back. The proxy knows that this is
a
>  special GRUU that will only be used for emergency calls, so it can do
>  all bypass actions it wants. Since the UA won't use this GRUU for
>  "normal" calls, there is no abuse risk.
>  
>  Henning
>  
>  On Nov 30, 2011, at 4:43 PM, Christer Holmberg wrote:
>  
>  >
>  > Hi,
>  >
>  >>> I think you still need a GRUU (at least).
>  >>
>  >> Maybe gruu helps here, maybe not. It seems that gruu isn't
sufficient
>  to bypass call barring policies. If something else is needed for that
>  then gruu may be irrelevant.
>  >
>  > The proposal was that the emergency gruu would contain a "psapcb"
>  token, which would have been used as an indicator for bypassing
policies
>  etc.
>  >
>  > (But, yes, the verification of the sender still applies also to the
>  egruu)
>  >
>  > Regards,
>  >
>  
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 1 Dec 2011 08:15:23 -0500

Not really, at least not any more than any other URL that can be contacted. (I'm leaving out resource-prioritization in intermediate proxies here, since (a) I don't think that's all that important in practice for call backs and (b) makes the problems even harder.)

Henning

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Dec 2011 14:24:03 +0100

As well as the potential routing off to another endpoint, I think we should also be aware that some of the inline application of policy within either a proxy or, dare I say it, SBC may also be inappropriate for a callback call. 

For example, an SBC may suppress some header fields. Is that always appropriate for a PSAP callback. I believe a common action is to suppress REFER requests.

Should the normal policy restrictions on SDP media lines requested apply (thereby the PSAP potentially getting a 488 response from the terminating users network entities) apply to a callback call.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christer Holmberg
> Sent: 30 November 2011 21:40
> To: 'Paul Kyzivat'; Dwight, Timothy M (Tim)
> Cc: [email-masked]
> Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead
> of eGRUU
> 
> 
> Hi,
> 
> >> "call barring" is a standard GSM service.  You can invoke it yourself
> with a "star code" or "hash code".
> >> It's also possible to bar incoming calls only when roaming.  Similarly
> there are various flavors of call
> >> diversion (aka call forwarding) that can be set similarly.  This is
> what I meant.  Services the user
> >> invokes or to which he is subscribed, that have the effect of
> preventing delivery of a call.
> >
> > OK. These examples are much more helpful.
> 
> Yes, this is a good example of where the service logic would be different.
> 
> But, in general, the idea is to not forward requests to application
> servers at all (even if the call would eventually still reach the correct
> device), e.g. due to the the risk of congestion etc (as indicated by
> James).
> 
> >> So it seems you are looking for another attribute that can be input to
> a policy engine that makes such decisions.
> >
> > So, on one hand its desired to indicate that the caller wants this call
> to receive special treatment, and then there is the issue of determining
> if the caller is entitled to ask for such treatment.
> 
> Correct.
> 
> > ISTM that Priority:emergency should be sufficient as an indicator that
> the treatment is required. Its been stated that this is intended for use
> by the UAS. But the kinds of services we are discussing
> > bypassing are in general provided on behalf of the UAS, so I think it
> still applies.
> 
> Agree (I earlier indicated the same).
> 
> > The Resource-Priority header probably also has a role here in cases
> where there are resource constraints in the network.
> >
> > Deciding if the caller is permitted to request this then becomes the
> hard part.
> 
> Yes. There needs to be a way for the network, when it receives a request
> claiming to be a PSAP Callback, to determine that the call comes from a
> PSAP. There might be different ways of doing that, depending on networks,
> environments, operator agreements etc.
> 
> Regards,
> 
> Christer
> 
> 
> >> From: Paul Kyzivat [mailto:[email-masked]]
> >> Sent: Wednesday, November 30, 2011 2:52 PM
> >> To: Dwight, Timothy M (Tim)
> >> Subject: Re: [Ecrit] PSAP Callback indication:
> >> Resrouce-Priority instead of eGRUU
> >>
> >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote:
> >>> Paul,
> >>>
> >>> I assume this "mumble mumble" refers to features in the
> >> service provider network that might otherwise prevent the callback
> >> from being delivered.  The subscriber might have incoming calls
> >> barred for example.
> >>
> >> Do you mean that the provider has barred calls because the bill has
> >> not been paid? I wouldn't consider this a "service" to the user of
> >> the phone, but its a reality to deal with.
> >>
> >> I guess that is a significant issue in the case where outgoing
> >> emergency calls are allowed.
> >>
> >> This needs to be mentioned on the list.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>
> >>
> >>> tim
> >>>
> >>>> Behalf Of Paul Kyzivat
> >>>> Sent: Wednesday, November 30, 2011 2:06 PM
> >>>> To: Christer Holmberg
> >>>> Cc: Adam Roach; ECRIT
> >>>> Subject: Re: [Ecrit] PSAP Callback indication:
> >>>> Resrouce-Priority instead of eGRUU
> >>>>
> >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>>>>> ISTM that a callback to the Contact address of a prior
> >>>> call should
> >>>>>>>> typically bypass many treatments, regardless of who it is from.
> >>>>>>>>
> >>>>>>>> In particular, it ought to go to the specific device
> >>>> identified by the
> >>>>>>>> contact address, not to some other device, VM server, etc.
> >>>>>>>>
> >>>>>>>> Perhaps that isn't what happens with IMS right now, but
> >>>> then maybe that
> >>>>>>>> ought to be re-thought.
> >>>>>>>>
> >>>>>>>> If that was normal behavior, then what else would be
> >> required for
> >>>>>>>> callbacks by a psap?
> >>>>>>>>
> >>>>>>>> There may need to be special treatment by the UA itself, but
> >>>>>>>> that can be handled by using a unique temp
> >>>> gruu for the
> >>>>>>>> emergency call and remembering it in order to detect
> >>>> emergency callbacks
> >>>>>>>> in the UA.
> >>>>>>>>
> >>>>>>>> What am I missing? What sort of disruptive services do
> >>>> you expect will
> >>>>>>>> be applied to calls to a gruu?
> >>>>>>>
> >>>>>>> I don't think one can assume that any type of call,
> >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same
> >>>> special treatment by the network, just because they are addressed
> >>>> using a Contact.
> >>>>>>>
> >>>>>>> And, it is not only about routing to another device, but
> >>>> also other services that normally would be applied.
> >>>>>>
> >>>>>> Rather than talk generically about "services", can we get
> >>>> tangible about
> >>>>>> what sorts of things the network might do that would be
> >>>> detrimental to a
> >>>>>> psap callback?
> >>>>>>
> >>>>>> AFAIK about the only thing that the network can do
> >>>> involves routing to
> >>>>>> some device other than the one addressed by the r-uri. E.g.
> >>>>>> - route to a VM server or message server that responds
> >> in some way.
> >>>>>> - forward to some other configured address
> >>>>>>
> >>>>>> IMO neither of those are appropriate if the URI is a gruu
> >>>> for a specific
> >>>>>> device and that device is reachable. They would be
> >>>> appropriate even for
> >>>>>> a psap callback if the device is not reachable.
> >>>>>
> >>>>> Again, it's not only about routing to a specific device.
> >>>>>
> >>>>> Before the request even reaches the device, it might e.g.
> >>>> be routed to different application servers in the network,
> >>>> triggering different kind of non-routing related services. A
> >>>> "normal" gruu addressed call could still be routed to such
> >>>> application servers, while a PSAP callback wouldn't.
> >>>>
> >>>> Without some tangible examples, what you say is just so much
> >>>> "mumble,mumble" to me.
> >>>>
> >>>> Either it is routed to some alternative device that terminates the
> >>>> call instead of the intended device, or else it is routed through
> >>>> some device that simply acts as an intermediary, still allowing the
> >> call to reach
> >>>> the intended device, or else it fails the call.
> >>>>
> >>>> Anything that acts as an intermediary, still allowing the call to
> >>>> reach the intended destination, is probably benign. (Do you have a
> >>>> counter-example?)
> >>>>
> >>>> Anything that routes to someplace other than the intended device is
> >>>> of dubious appropriateness when the r-uri is a GRUU. Again I'd be
> >>>> interested to hear some examples.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Dec 2011 15:34:24 +0100

Hi Henning, 

> Not really, at least not any more than any other URL that can 
> be contacted. (I'm leaving out resource-prioritization in 
> intermediate proxies here, since (a) I don't think that's all 
> that important in practice for call backs and (b) makes the 
> problems even harder.)

As far as I know (needs to be double checked), there are no 3GPP/IMS requirements regarding network resource priorization for callbacks. The requirements are more related to special treatment and policies.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Dec 2011 14:36:42 +0000

[changing subject title because this thread is going all over the place]

Right, so call-barring, call-forwarding, do-not-disturb, and such are network features/services that might need to be exempted for PSAP callbacks.  

But there are also network policies (rather than services) that might need to be exempted: blocking calls if the UA does not have inbound call service, blocking the call if the UA does not have credit/paid-minutes left, restricting UA's to only one call at a time, restricting the bandwidth for media (ie, bandwidth CAC), blocking the early media from a UA, restricting the codecs allowed, and certain privacy rules/logic for information coming back from the UA - all of which might need to be exempted for PSAP callbacks.

And then of course there're the logs - providers/carriers will definitely want to log these calls as being PSAP callbacks in particular.

None of the above has anything to do with GRUUs, though.

-hadriel

On Nov 30, 2011, at 4:29 PM, Paul Kyzivat wrote:

> On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote:
>> Paul,
>> 
>> "call barring" is a standard GSM service.  You can invoke it yourself with a "star code" or "hash code".  It's also possible to bar incoming calls only when roaming.  Similarly there are various flavors of call diversion (aka call forwarding) that can be set similarly.  This is what I meant.  Services the user invokes or to which he is subscribed, that have the effect of preventing delivery of a call.
> 
> So it seems you are looking for another attribute that can be input to a policy engine that makes such decisions.
> 
> So, on one hand its desired to indicate that the caller wants this call to receive special treatment, and then there is the issue of determining if the caller is entitled to ask for such treatment.
> 
> ISTM that Priority:emergency should be sufficient as an indicator that the treatment is required. Its been stated that this is intended for use by the UAS. But the kinds of services we are discussing bypassing are in general provided on behalf of the UAS, so I think it still applies.
> 
> The Resource-Priority header probably also has a role here in cases where there are resource constraints in the network.
> 
> Deciding if the caller is permitted to request this then becomes the hard part.
> 
> 	Thanks,
> 	Paul
> 
>> tim
>> 
>>> service provider network that might otherwise prevent the
>>> callback from being delivered.  The subscriber might have
>>> incoming calls barred for example.
>>> 
>>> Do you mean that the provider has barred calls because the
>>> bill has not
>>> been paid? I wouldn't consider this a "service" to the user of the
>>> phone, but its a reality to deal with.
>>> 
>>> I guess that is a significant issue in the case where
>>> outgoing emergency
>>> calls are allowed.
>>> 
>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>> On Behalf Of Paul Kyzivat
>>>>>>>>> There may need to be special treatment by the UA
>>>>>>>>> itself, but that can be handled by using a unique temp
>>>>> gruu for the
>>>>> special treatment by the network, just because they are
>>>>> addressed using a Contact.
>>>>>>>> 
>>>>> Either it is routed to some alternative device that
>>>>> terminates the call
>>>>> instead of the intended device, or else it is routed through
>>>>> some device
>>>>> that simply acts as an intermediary, still allowing the
>>> call to reach
>>>>> Anything that acts as an intermediary, still allowing the
>>>>> call to reach
>>>>> the intended destination, is probably benign. (Do you have a
>>>>> counter-example?)
>>>>> 
>>>>> Anything that routes to someplace other than the intended
>>>>> device is of
>>>>> dubious appropriateness when the r-uri is a GRUU. Again I'd be