Re: [Ecrit] GRUUs for callbacks
Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 03 December 2011 17:11 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0A321F91AB for <ecrit@ietfa.amsl.com>; Sat, 3 Dec 2011 09:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4uYUWOuKQpk for <ecrit@ietfa.amsl.com>; Sat, 3 Dec 2011 09:11:40 -0800 (PST)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4821F8E8E for <ecrit@ietf.org>; Sat, 3 Dec 2011 09:11:40 -0800 (PST)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id 4h8h1i0020mv7h057hBhFq; Sat, 03 Dec 2011 17:11:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id 4hBg1i01N07duvL3XhBguS; Sat, 03 Dec 2011 17:11:40 +0000
Message-ID: <4EDA584E.2050604@alum.mit.edu>
Date: Sun, 04 Dec 2011 01:11:42 +0800
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
References: <CAFD6962.2CB02%mlinsner@cisco.com> <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu>
In-Reply-To: <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] GRUUs for callbacks
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2011 17:11:41 -0000
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 >> > >
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- Re: [Ecrit] GRUUs for callbacks James M. Polk
- Re: [Ecrit] GRUUs for callbacks Hadriel Kaplan
- Re: [Ecrit] GRUUs for callbacks Marc Linsner
- Re: [Ecrit] GRUUs for callbacks Marc Linsner
- Re: [Ecrit] GRUUs for callbacks Richard L. Barnes
- [Ecrit] GRUUs for callbacks Hadriel Kaplan
- Re: [Ecrit] GRUUs for callbacks Christer Holmberg
- Re: [Ecrit] GRUUs for callbacks Hadriel Kaplan
- Re: [Ecrit] GRUUs for callbacks Christer Holmberg
- Re: [Ecrit] GRUUs for callbacks Marc Linsner
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- Re: [Ecrit] GRUUs for callbacks Hadriel Kaplan
- Re: [Ecrit] GRUUs for callbacks Marc Linsner
- Re: [Ecrit] GRUUs for callbacks Brian Rosen
- Re: [Ecrit] GRUUs for callbacks Marc Linsner
- Re: [Ecrit] GRUUs for callbacks Hadriel Kaplan
- Re: [Ecrit] GRUUs for callbacks Brian Rosen
- Re: [Ecrit] GRUUs for callbacks Hadriel Kaplan
- Re: [Ecrit] GRUUs for callbacks Christer Holmberg
- Re: [Ecrit] GRUUs for callbacks Henning Schulzrinne
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- Re: [Ecrit] GRUUs for callbacks Henning Schulzrinne
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- Re: [Ecrit] GRUUs for callbacks Brian Rosen
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- Re: [Ecrit] GRUUs for callbacks Brian Rosen
- Re: [Ecrit] GRUUs for callbacks Henning Schulzrinne
- Re: [Ecrit] GRUUs for callbacks Paul Kyzivat
- [Ecrit] IETF82 Taipei ECRIT Minutes have been pos… Roger Marshall
- [Ecrit] PSAP Callback - A New Beginning Christer Holmberg
- Re: [Ecrit] PSAP Callback - A New Beginning Brian Rosen
- Re: [Ecrit] PSAP Callback - A New Beginning Christer Holmberg
- Re: [Ecrit] PSAP Callback - A New Beginning Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] PSAP Callback - A New Beginning Christer Holmberg
- [Ecrit] Nonce value -- RE: PSAP Callback - A New … Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Henning Schulzrinne
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Paul Kyzivat
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Paul Kyzivat
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … James M. Polk
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Henning Schulzrinne
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Brian Rosen
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … John-Luc Bakker
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Brian Rosen
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … John-Luc Bakker
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Paul Kyzivat
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Brian Rosen
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Paul Kyzivat
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … John-Luc Bakker
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Christer Holmberg
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … Paul Kyzivat
- Re: [Ecrit] Nonce value -- RE: PSAP Callback - A … John-Luc Bakker
- Re: [Ecrit] PSAP Callback - A New Beginning Hadriel Kaplan