AW: [Ecrit] Solution Approaches

["Liess, Laura" <Laura.Liess at t-systems.com>]

Hannes,

thanks a lot for putting the whole discussion together.  

I can not give you a feedback which is agreed within DT (the internal agreement process would probably take some time). But I roughly discussed the approaches with people working on emergency calling. If we understood the proposal correctly, we have a strong preference for the approach number 8), which could work as follows: 

The ASP/ISP provides to the client the LbyR, the country code (or country and state codes)and the local EC dial string (at login and whenever these data change). 
The client queries LOST and gets back an ESRP URI. 
When the caller dials the emergency calling number, the client queries again the ASP/VSP for the LbyR and the country code and LOST query for the ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared secret with the LIS, gets the user location and the correct PSAP and routes the call with the location info to the PSAP (TLS required). (ESRP or a local LOST does load balancing for PSAPs an all this stuff).

Alternatively, the VSPs SIP proxy can do the LOST queries. 


Laura


> -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net] 
> Gesendet: Dienstag, 17. April 2007 11:12
> An: ECRIT
> Betreff: [Ecrit] Solution Approaches
> 
> 
> Hi all,
> 
> I would like to share some potential solution approaches with you to 
> deal with the problem of not providing precise location to 
> the end host. 
> I had a chance to discuss these aspects with Henning 
> face-to-face last 
> Friday. Here is a short summary.
> 
> Note that the goal was to avoid some form of relationship (e.g., 
> business relationship) between the VSP and the ASP/ISP (since 
> this would 
> impose a significant deployment problem).
> 
> 1) Provide enough location information so that the emergency 
> call can be 
> routed to the correct PSAP. Precise location information would be 
> provided to the PSAP.
> This approach was already discussed on the list. We need 
> feedback from, 
> for example, Barbara and Laura whether they feel comfortable 
> with this 
> approach.
> 
> CONSEQUENCE: No changes needed.
> 
> 2) Provide LbyR + Dial String + PSAP URI to the end host.
> We could ignore the potential security vulnerabilities if 
> charging does 
> not work on a call-by-call basis.
> 
> CONSEQUENCE: No changes needed.
> 
> 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a 
> reverse LoST lookup to verify the PSAP URI.
> 
> CONSEQUENCE: Solution needs to be developed.
> 
> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP 
> verifies 
> the PSAP URI with the PSAP URIs being flooded (using the LoST 
> synchronization mechanism). This mechanism is potentially 
> similar to (3) 
> -- details might vary. (3) might use a distributed approach 
> whereas this 
> is brute force.
> 
> CONSEQUENCE: Solution needs to be developed.
> 
> 5) Emergency calls are routed via the SIP proxy of the VSP and 
> subsequently via a SIP proxy in the ASP/ISP (redirect mode)
> SIP Location Conveyance would be used instead of GEOPRIV L7 LCP
> Assumption: No service level agreement (or business 
> agreement) between 
> VSP and ISP/ASP for this type of SIP emergency message 
> routing required.
>  
> CONSEQUENCE: No changes needed. Potential problems with SIP Identity 
> possible
> 
> 6) Emergency calls are routed via the SIP proxy of the VSP and 
> subsequently via a SIP proxy in the ASP/ISP (no redirect 
> mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP
> Assumption: No service level agreement (or business 
> agreement) between 
> VSP and ISP/ASP for this type of SIP emergency message 
> routing required.
>  
> CONSEQUENCE: No changes needed.
> 
> 7) Decoupled authentication for SIP message routing 
> Authentication exchange between the end host and the VSP 
> (e.g., TLS to 
> obtain a SAML assertion)
> Authentication credentials are then added to the SIP 
> emergency message 
> that is routed via the SIP proxy in the VSP/ISP.
> No service level agreement (or business agreement) between VSP and 
> ISP/ASP needed.
> 
> CONSEQUENCE: Security extension for this purpose needs to be 
> progressed 
> (already available in draft form)
> 
> 8) Country Code Routing
> 
> LIS provides country code to the end host. The end host 
> routes the SIP 
> emergency message via the VSP towards a ESRP that corresponds to the 
> country code. Then, ESRP fetches more detailed location 
> information todo 
> routing within the country.
> 
> CONSEQUENCE: No changes to the protocol mechanisms. 
> Deployment of ESRPs 
> that work this way are needed. Establishment of ESRP <-> 
> ISP/ASP is more 
> difficult than with PSAP <-> ISP/ASP since there are far more 
> nodes to 
> consider.
> 
> 9) Assume end hosts have certs for emergency services; 
> routing via SIP 
> proxy in ISP/ASP without traversing VSP in the emergency 
> case. Existing credential infrastructure can be used when 
> utilizing SIP Cert.
> 
> CONSEQUENCE: Architectural aspects need to be developed. A little bit 
> more difficult to deploy for VSP. Potential issues with callback (to 
> AoR) since end host is not registered with VSP.
> 
> 10) Routing via SIP proxy in ISP/ASP. Diameter SIP 
> application used to 
> authenticate end host
> Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter 
> SIP interaction.
> 
> CONSEQUENCE: Problems with legacy credentials, previously 
> mentioned call 
> back problems since end host is not registered with VSP, Diameter SIP 
> application would need to be profiled.
> 
> Thoughts?
> 
> Ciao
> Hannes
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit