Re: [Ecrit] GRUUs for callbacks

On 12/5/11 11:46 PM, Brian Rosen wrote:
> phonebcp and NENA i3 docs differentiate between callbacks that are immediate (within minutes of the call) and later.
>
> The former is (currently) to Contact, and the latter is to AoR (P-A-I  or From, ideally with Identity).
>
> The requirement for the former is pretty simple - that which is in Contact gets back to the device that made the call.  That's basic 3261 isn't it?

Yep, its basic 3261. But GRUU was an admission that people weren't 
implementing basic 3261. The lack of widespread support of GRUU may mean:
- some don't see it as important to support out-of-dialog callback
   to the contact of a dialog
- a perceived alternate way of implementing that makes the callback
   to the contact work without gruu. (E.g. an SBC substituting an
   address and supporting callbacks to it for some time, or supplying
   the AOR as the contact address in the call.)

Maybe Hadriel will comment on what he has seen in the wild, or Robert 
will comment on what he has seen at sipit.

> While priority is a nice to have, and free is a nice to have, neither is essential, and if they were available, they would only apply to the URI in Contact.

Is there an expectation that the psap will try a callback to the AOR if 
callback to the Contact fails? ISTM that would be an expedient strategy. 
If so, it would be good if the callback to the AOR also could request 
priority, and to suppress features. Perhaps this could be at the 
discretion of the psap caller.

> It doesn't matter to the emergency call system what is in Contact.  It's just a URI that if called, gets to the right device.  phonebcp says it should remain valid for several minutes beyond the call unless the subscription expires and is not renewed.

If GRUU is not supported, and the native contact of the calling UA isn't 
globally routable, then callback to the contact might not work at all, 
or it may only work while the dialog is still up.

> It would be straightforward in my opinion to have PSAPs sign (Identity) for callbacks if that would be helpful.

I guess the problem with this is that it likely won't survive transit 
through an SBC.

> Any reasonable marking (some urn in R-URI with actual target in Route, the particulars of the Identity header, or anything else straightforward is fine.  They can have any RPH, any Priority header, and populating In-Response-To is easy.

I figured that was the case. The trick is to find something that has a 
high probability of working in real deployments. (Possibly with 
adjustments to SBC policies to make it work.)

This perhaps needn't be unforgeable, if the consequences of forging it 
are acceptable. That probably means that a forgeable mark not bestow 
free calls.

A forgeable mark providing priority and/or bypassing call blocking on 
the receiving side might be tolerable. Conceivably the provider could 
only allow this some limited number of times to mitigate it.

A forgeable mark bypassing features that screen callers or otherwise 
limit direct access to the callee is more problematic. Possibly this 
could be handled by the emergency caller's UA itself - by remembering 
that it made an emergency call recently or not. It could then reject 
calls with this marking if it hasn't recently made an emergency call. 
This isn't ideal, since it bothers the UA, but it avoids bothering the 
user. (But it still provides a vector for a DOS attack on the UA.)

	Thanks,
	Paul

> None of that applies to the later call back to P-A-I or From.  They are just calls.
>
> Brian
>
> On Dec 3, 2011, at 2:13 PM, Paul Kyzivat wrote:
>
>> On 12/4/11 1:28 AM, Henning Schulzrinne wrote:
>>> That's roughly what I said below (last paragraph), so I'm a bit confused by your response. Both the ARID and the signed call mechanism rely on identifying the privileged caller (PSAP), rather than identifying a callback. However, from a deployability perspective, this requires significant changes in a number of places. If we're complaining about GRUUs not being widely deployed, we can't exactly call deploying a completely new solution an improvement.
>>>
>>> This is why I'm trying to suggest that searching for a single magic solution that is
>>>
>>> - secure
>>> - works everywhere
>>> - works with broken implementations
>>> - works with no changes anywhere
>>>
>>> is a fool's errand. Rather, by combining solutions, we might allow different providers/enterprise/UAs to pick their own trade-off and migrate to better solutions over time.
>>
>> Its possible we are not disagreeing much, but just thinking about things differently, or focusing on different things.
>>
>> But I am a bit concerned that a scatter gun approach, where providers pick the pieces they like, may just result in needless differences and systems that don't work well.
>>
>> If we agree that it isn't feasible to get an ideal system that meets all our wishes, then perhaps we can get a general agreement on a lesser set of requirements. E.g.
>>
>> - its most important for the psap to be able, on explicit request,
>>   to achieve expedited access to an arbitrary AOR.
>>   (This might be a callback to an emergency call, via Contact AOR
>>   or From AOR, or whatever of the emergency call. It might also
>>   be some other AOR.)
>>
>> - its nearly as important that the expedited access be able to reach
>>   devices that have recently made an emergency call but are normally
>>   not permitted or able to receive calls.
>>
>> - its important (but less so) to minimize fraud by preventing non-
>>   psaps from getting the sort of expedited access mentioned above.
>>
>> - it may be desirable that callees not be charged for receiving these
>>   expedited calls. (Decisions about this are based on policy.)
>>
>> If we were to agree to the above, then we could start identifying mechanisms to support each. But some of them might be incomplete.
>>
>> For instance, to achieve the first, we come up with a mechanism to indicate this is a psap expedited call. (e.g. urn:sos in From or P-A-ID.)
>>
>> For the second, maybe nothing else is required in signaling if the contact address is reachable - just some policy adjustments. In other cases it might require allowing some sort of emergency registration, and then would only work as long as that registration remains in effect.
>>
>> Some might not bother to minimize fraud at all. Others might depend on transitive trust to prevent unauthorized parties from making the indication for a psap expedited call. Or something like ARID might be used.
>>
>> The disabling of fees could presumably be driven by one of the above mechanisms if desired.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Henning
>>>
>>> On Dec 3, 2011, at 12:11 PM, Paul Kyzivat wrote:
>>>
>>>> Why not forget about detecting and verifying that the call is a *callback* to an emergency call. Instead, simply give the psap a way to initiate a "priority" call to some URI. Then expect the elements on the path to take special action on these, such as bypassing features like VM.
>>>>
>>>> We can rely on policy to restrict such calls to callbacks, or comparably compelling reasons.
>>>>
>>>> There is still work to be done to satisfy this, but some hard things are avoided.
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>> On 12/4/11 12:40 AM, Henning Schulzrinne wrote:
>>>>> We seem to have difficulty finding a single mechanism that meets all requirements (such as non-forgeability and reach-the-same UA) in all situations:
>>>>> - SBCs that destroy session identity
>>>>> - UAs and/or proxies that don't support GRUUs
>>>>> - call route divergence (route asymmetry), where the initial outbound emergency call and the call back traverse different paths.
>>>>>
>>>>> Thus, maybe we need a more probabilistic approach that will work in most situations, relying on *multiple* markers and indicators. We may not achieve 100% coverage, but I suspect that the only way of doing that would be a 100% deployment of an end-to-end cryptographic mechanism that is recognized by all parties. (Since it seems close to impossible for the caller to convey an element that survives round-trip, you would probably have to identify the PSAP, not the call, since there's nothing that can be signed by the caller and be recognized by third parties.)
>>>>>
>>>>> I can think of a few ingredients that are plausible and "survive" under different circumstances, two of which we have been discussing before:
>>>>>
>>>>> (1) normal GRUUs, where the inbound proxy remembers that the outbound call was an emergency call; may fail under some route asymmetry cases and is subject to GRUU deployment issues.
>>>>>
>>>>> (2) In-Reply-To and Priority; does not require any GRUU or new SIP elements, but fails with call-ID mangling SBCs and does not address asymmetric call paths.
>>>>>
>>>>> (3) ARID (draft-ono-dispatch-attribute-validation), which allows entities on the call path to validate that the call originated from a PSAP, with pretty minimal infrastructure.
>>>>>
>>>>> (4) PSAP-signed calls (see below).
>>>>>
>>>>> I suspect there are others, but the basic goal seems to be that the caller, the only one knowing reliably that an emergency call was placed, needs to tell various elements responsible for inbound call handling to provide special handling for a specific call, identified by some element that survives the trip to and from the PSAP. If there was a standard protocol that allowed a UA to request per-call features, we could leverage that, but I haven't heard of such a thing. (Just to illustrate the spirit: The caller could create a CPL rule that bypasses call treatments just after placing the emergency call, but it seems fanciful to suggest this as a general mechanism, given the additional complexity in lots of places.)
>>>>>
>>>>> The usual other way of proving yourself is a challenge-response mechanism, but that assumes that all the call handling elements share a secret with the caller. I can't think of a way to build such a system without a whole lot of new protocol machinery.
>>>>>
>>>>> I also wonder whether for the more complicated IMS scenarios, it wouldn't be easier to just rely on PSAP signed requests, given that the number of IMS operators is likely to be not that large and that they are likely to be reasonably sophisticated operators. In other words, we don't try to identify return calls, just PSAP-originated calls.
>>>>>
>>>>> Henning
>>>>>
>>>>> On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote:
>>>>>
>>>>>> On 12/2/11 6:30 AM, Marc Linsner wrote:
>>>>>>
>>>>>>>> I'm finding this a little confusing.
>>>>>>>> Are you are saying that the UA making the emergency call will get an
>>>>>>>> egruu from the registrar/scscf in the visited network, but the resulting
>>>>>>>> call will be processed by the scscf of the home network?
>>>>>>>
>>>>>>> No, it was intended the eGRUU would be minted by the home network and
>>>>>>> passed to the UA upon registration.
>>>>>>
>>>>>> So, if the UA was registered normally, to its home scscf, then it would get the gruu from there? But the emergency call might not traverse the home scscf? But the callback, because it uses a gruu from the home scscf, will traverse that one?
>>>>>>
>>>>>> In such a case, the home scscf won't know that an emergency call has been made (as Hadriel mentioned). And while it could apply some expiration time to the gruu, the clock for that would start ticking when the registration that minted the gruu was done. That could be a long time ago. (I gather it is not considered desirable to force a special registration just prior to the emergency call - due to the extra time it might take and the possibility that it might fail.)
>>>>>>
>>>>>> OTOH, IIUC  for some IMS cases its also necessary to support emergency calls from SIMless devices that don't have a normal registration. In that case I gather there will be an emergency registration, possibly to a visited network. That is probably the easier case.
>>>>>>
>>>>>> 	Thanks,
>>>>>> 	Paul
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> Ecrit@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>
>