RE: [Ecrit] Solution Approaches

["Stastny Richard" <Richard.Stastny at oefeg.at>]

Laura,

In your proposal, you have one ESRP per country (or state)?

Or am I missing something?

Richard

> -----Original Message-----
> From: Liess, Laura [mailto:Laura.Liess at t-systems.com]
> Sent: Tuesday, April 17, 2007 5:37 PM
> To: Hannes.Tschofenig at gmx.net; ecrit at ietf.org
> Subject: AW: [Ecrit] Solution Approaches
> 
> 
> 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

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