[Ecrit] Solution Approaches

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

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