Subject: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30

From: Andres Kütt <[email-masked]>
Date: Wed, 18 Apr 2007 11:08:15 -0700

Hi,

    As I understand it, all of the methods have shortcomings and in an ideal
world, it would probably make sense to use different models in different
scenario. Here come my comments:

> 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.
This implies that the access provider knows how much information is needed
to determine the PSAP which in turn implies that the it also knows about
PSAP topology. Can we make that assumption?

> 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.
We can't make that assumption, I think. The solution has to be invariant
towards whatever charging scheme  the VSP uses.

> 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.
Seems fine as long we can ensure the integrity of the LoST query.

> 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.
Does not seem very architecturally consistent, but might work.

> 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
This does not work with devices that do not use SIP on the client side. Like
yours truly. 

> 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.
Same as above.

> 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)
Do not understand this. The calling infrastructure needs to be authenticated
from end to end anyway if any sort of billing is to happen?

> 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.
How would the ESRP be able to determine the location of the caller?

> 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.
Would not work for devices not using SIP + several issues with certs and
things. Bear in mind that a lot of SIP devices out there can not be updated
easily so anything if an authentication method is compromised, for example.

> 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.
Could you explain that in a little bit more detail?

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Apr 2007 21:07:33 +0200

Hi Andreas,

> PSAP topology. Can we make that assumption?
Yes; I believe we can make this assumption.

> towards whatever charging scheme  the VSP uses.
I wanted to list it for completeness reasons. I also don't believe that 
it is a reasonable design to just ignore security vulnerabilities.

> Does not seem very architecturally consistent, but might work.
This solution will probably not win a beauty contest.

> This does not work with devices that do not use SIP on the client side. Like
That's true. I should have added this part.

The challenge is that for unauthenticated network access you need to 
implement one protocol anyway, very likely SIP, since otherwise you 
introduce EXTREMELY HUGE security vulnerabilities.

> >from end to end anyway if any sort of billing is to happen?
The end host / user is authenticated with a mechanism independent of SIP 
and then the receipt of that authentication action is added to the 
emergency call for consumption at the PSAP (to provide him some identity 
information).

> How would the ESRP be able to determine the location of the caller?
It needs to resolve the reference the LIS in the access network sent to 
the end host and that is then subsequently forwarded to the ESRP.
This reference is dereferenced at the LIS

> easily so anything if an authentication method is compromised, for example.

Note that there aren't problems with CERTs as such. The main issue is 
mostly with the PKI that comes with most certificates.
If you utilize something like SIP Certs then things are different since 
you can use your existing credential infrastructure and you use 
certificates just as a technical vehicle.

Here is the draft:
http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-03.txt

> Could you explain that in a little bit more detail?
This document gives you the details:
http://www.rfc-editor.org/rfc/rfc4740.txt

Here is the relevant picture:

                               +--------+
                  UAR/UAA +--->|Diameter|
                  LIR/LIA |    | server |
                          |    +--------+
                          |             
                          |             
                          v                  
   +------+   SIP     +--------+    SIP   +--------+   SIP     +------+
   | SIP  |<--------->|  SIP   |<-------->| ESRP   |<--------->| PSAP |
   |  UA  |           |server 1|          |        |           |      |
   +------+           +--------+          +--------+           +------+
                       SIP Server
                       in access
                       network

Ciao
Hannes

---

From: Andres Kütt <[email-masked]>
Date: Fri, 20 Apr 2007 14:04:17 -0700

Hi,

    Thank you for answers, have still some comments

On 4/19/07 12:07 PM, "Hannes Tschofenig" <[email-masked]> wrote:

<snip>
> Yes; I believe we can make this assumption.
For APs, this assumption does not hold. How would a $50 wifi AP know of
PSAPs? 

<snip>
> introduce EXTREMELY HUGE security vulnerabilities.
Not really. We can either assume some internal built-in identity or enable
certain functionality without the client being logged in. This has nothing
to do with the protocol that is used.

> emergency call for consumption at the PSAP (to provide him some identity
This is only true for unauthenticated user as for everybody else a VSP
always has an authentication mechanism in place (and thus it does not need
to be described in a standard) and can forward it to PSAP.

<snip>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 22 Apr 2007 12:45:38 +0200

Hi Andres, 

> For APs, this assumption does not hold. How would a $50 wifi 

I guess we would have to discuss what the role of the WiFi AP actually is in this particular scenario. If these Aps belong to the network operator then the network operator would have to 
* decide how much location information they are willing to share
* how the specific PSAP infrastructure looks like (in that country)
* what the regulatory requirements are. 

Depending on the outcome of the above investigation the LoST database is filled with values. 

In any case, LoST would provide the protocol machinery. 

> to do with the protocol that is used.

The problem with unauthenticated network access is that you have to place a SIP proxy in the access network to deal with the security problems.

With unauthenticated network access there is no identity information available. 

> to be described in a standard) and can forward it to PSAP.
In this particular case I do not consider unauthenticated network access. 
It is possible to split the authentication from the actual VoIP signaling.
Since nobody liked this approach anyway it does not really matter too much. 

Ciao
Hannes