AW: [Ecrit] Solution Approaches

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

> -----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