Subject: [Ecrit] Location Hiding - another look

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Jun 2007 11:40:26 +0200

Hi all,

with location hiding we assumed that the network operator does not want 
to provide information about the precise location information to the end 
point.
A lot of discussions focused on the question how it can still obtain a 
PSAP URI in that case.

There is, however, the question why the end point needs to obtain this 
PSAP URI in the location hiding case at all.
Why cannot we just assume that the VSP has to obtain some location 
information from the ASP/ISP via LbyR and then it runs a LoST query as 
we specified it.

DONE

Ciao
Hannes

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 Jun 2007 04:57:10 -0500

Hi Hannes,

I would prefer not to have an association between the VSP and ISP/ASP if
we don't need to. If the end-point can obtain the PSAP URI or the ESRP
Uri then the relationship between VSP and ISP doesn't need to exist. The
relationship is between the ISP/ASP and the local PSAP. 

Cheers
James

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, 4 June 2007 7:40 PM
> To: ECRIT
> Subject: [Ecrit] Location Hiding - another look
> 
> Hi all,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Jun 2007 12:00:59 +0200

Hi James,

what relationship do you mean?
Is it because of the ability to obtain location information by the VSP 
such that call routing can take place?
Didn't we discuss the ability of the ASP/ISP to differentiate a request 
and to return precise location only for authorized nodes where as 
unauthorized nodes would only obtain location information that is 
sufficient for emergency call routing.

Ciao
Hannes

Winterbottom, James wrote:
>> with location hiding we assumed that the network operator does not
>>     
> want
>   
>> to provide information about the precise location information to the
>>     
> end
>   
>> point.

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 Jun 2007 05:05:21 -0500

Hi Hannes,

Kind of.
A LIS that is providing location information in a local area is far more
likely to have a relationship with a local emergency authority and be
able to determine that they are entitled to location information, than
it is to be able to determine that a VSP in Sierra Leone is entitled to
location information. To me there is a very sizeable difference in these
approaches.

Hope this helps

James

> Sent: Monday, 4 June 2007 8:01 PM
> To: Winterbottom, James
> Cc: ECRIT
> Subject: Re: [Ecrit] Location Hiding - another look
> 
> Hi James,
> 
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Jun 2007 13:03:28 +0200

Sounds like you envision that only authorized entities are allowed to 
resolve a LbyR regardless of the granularity of the requested information.

Ciao
Hannes

Winterbottom, James wrote:
>> Didn't we discuss the ability of the ASP/ISP to differentiate a
>>     
> request
>   
>>> I would prefer not to have an association between the VSP and
>>>       
> ISP/ASP if
>   
>>> we don't need to. If the end-point can obtain the PSAP URI or the
>>>       
> ESRP
>   
>>> Uri then the relationship between VSP and ISP doesn't need to exist.
>>>       
> The
>   
>>>> to provide information about the precise location information to
>>>>         
> the
>   
>>> end
>>>
>>>       
>>>> point.
>>>> A lot of discussions focused on the question how it can still
>>>>         
> obtain a
>   
>>>> PSAP URI in that case.
>>>>
>>>> There is, however, the question why the end point needs to obtain
>>>>         
> this
>   
>>>> information from the ASP/ISP via LbyR and then it runs a LoST query
>>>>         
> as
>   
>>>> we specified it.
>>>>
>>>> DONE
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 Jun 2007 06:48:09 -0500

Hi Hannes,

In systems where I have to pre-provision locations, per user I only want
one level of granularity. If the location provider wants to hide this,
then I think it reasonable that they will only give it to authorized
entities. The same may be true for systems that need to compute location
at request time. I think that this is a reasonable approach.

Cheers
James

> Sent: Monday, 4 June 2007 9:03 PM
> To: Winterbottom, James
> Cc: ECRIT

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Jun 2007 13:56:49 +0200

It would obviously be fairly trivial to reduce the granularity, 
particularly within a DSL environment where civic location is used.

Ciao
Hannes

Winterbottom, James wrote:
>> resolve a LbyR regardless of the granularity of the requested
>>     
> information.
>   
>> Ciao
>> Hannes
>>
>>> A LIS that is providing location information in a local area is far
>>>       
> more
>   
>>> likely to have a relationship with a local emergency authority and
>>>       
> be
>   
>>> able to determine that they are entitled to location information,
>>>       
> than
>   
>>> it is to be able to determine that a VSP in Sierra Leone is entitled
>>>       
> to
>   
>>> location information. To me there is a very sizeable difference in
>>>       
> these
>   
>>> approaches.
>>>
>>> Hope this helps
>>>
>>> James
>>>
>>>
>>>       
>>>> Is it because of the ability to obtain location information by the
>>>>         
> VSP
>   
>>>>> Uri then the relationship between VSP and ISP doesn't need to
>>>>>           
> exist.
>   
>>> The
>>>
>>>       
>>>>>> with location hiding we assumed that the network operator does
>>>>>>             
> not
>   
>>>>>>             
>>>>> want
>>>>>
>>>>>
>>>>>           
>>>>>> Why cannot we just assume that the VSP has to obtain some
>>>>>>             
> location
>   
>>>>>> information from the ASP/ISP via LbyR and then it runs a LoST
>>>>>>             
> query
>   
>>> as
>>>
>>>       
>>>>>> we specified it.
>>>>>>
>>>>>> DONE
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 Jun 2007 06:59:02 -0500

To what level though?
And it does mean that I have to have at least a ruleset for describing
how to dumb down location in some areas. I prefer a solution that does
not require this.

> Sent: Monday, 4 June 2007 9:57 PM
> To: Winterbottom, James
> Cc: ECRIT

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 4 Jun 2007 14:01:55 +0200

The level depends on the country. 

As we learned a few months ago there is only a single PSAP in Australia. Hence, the country code would be sufficient. The same is true for Finland. In Norway, there are 4 PSAPs (or 5) and hence you need a bit more than just the country level info. 

Complicated? Not really.

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Winterbottom, James [mailto:[email-masked]] 
> Gesendet: Montag, 4. Juni 2007 13:59
> An: Hannes Tschofenig
> Cc: ECRIT
> Betreff: RE: [Ecrit] Location Hiding - another look
> 
> To what level though?
> > > In systems where I have to pre-provision locations, per 
> user I only
> want
> > >> Sounds like you envision that only authorized entities 
> are allowed
> to

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Jun 2007 14:04:21 +0200

Btw, in cellular systems I recall that we already said that the 
dereferencing request includes a parameter that indicates when and at 
what quality level the location info is needed. Hence, I think it is not 
really true that there is only one form of location.

Winterbottom, James wrote:
>>> In systems where I have to pre-provision locations, per user I only
>>>       
> want
>   
>>> one level of granularity. If the location provider wants to hide
>>>       
> this,
>   
>>> entities. The same may be true for systems that need to compute
>>>       
> location
>   
>>>> Sounds like you envision that only authorized entities are allowed
>>>>         
> to
>   
>>>>> A LIS that is providing location information in a local area is
>>>>>           
> far
>   
>>> more
>>>
>>>       
>>>>> it is to be able to determine that a VSP in Sierra Leone is
>>>>>           
> entitled
>   
>>> to
>>>
>>>       
>>>>>> Is it because of the ability to obtain location information by
>>>>>>             
> the
>   
>>> VSP
>>>
>>>       
>>>>>>> we don't need to. If the end-point can obtain the PSAP URI or
>>>>>>>               
> the
>   
>>>>>>>               
>>>>> ESRP
>>>>>
>>>>>
>>>>>           
>>>>>>>> to provide information about the precise location information
>>>>>>>>                 
> to
>   
>>>>>>>>                 
>>>>> the
>>>>>
>>>>>
>>>>>           
>>>>>>> end
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> point.
>>>>>>>> There is, however, the question why the end point needs to
>>>>>>>>                 
> obtain
>   
>>>>>>>>                 
>>>>> this
>>>>>
>>>>>
>>>>>           
>>>>>>> contain privileged, proprietary, or otherwise private
>>>>>>>               
> information.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 Jun 2007 07:08:03 -0500

Oh I entirely agree that where location needs to be calculated that
there is not only one level. But there is a cost involved when it needs
to be calculated and that cost goes up the more precise the location
required is. In these systems I generally only provision things like
cell-sites, I certainly don't provision discrete locations per-user.

> Sent: Monday, 4 June 2007 10:04 PM
> To: Winterbottom, James
> Cc: ECRIT
information.

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 4 Jun 2007 11:27:16 -0400

I think it's important for the end point to be able to get the PSAP URI,
because there may not be a VSP, at all. I don't think the architecture
should require that there be a VSP in order to make a SIP call over the
Internet. Certainly, VSPs are needed to get to PSAPs on the legacy phone
network. But once PSAPs are reachable directly by VoIP, the architecture
should allow end devices with open Internet access, but no VSP, to make
emergency calls.
Barbara 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, June 04, 2007 5:40 AM
To: ECRIT
Subject: [Ecrit] Location Hiding - another look

Hi all,

DONE

Ciao
Hannes

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 04 Jun 2007 22:12:40 +0200

Hi Barbara,

Stark, Barbara wrote:
> because there may not be a VSP, at all.

For the case where there is no VSP, also referred as the unauthenticated 
emergency service architecture, the access network provider has to 
provide emergency service support directly or indirectly (via a 
partnership with another emergency service infrastructure provider).

You additionally have to consider the case where link layer 
authentication can also be bypassed since you might loose more than just 
the credentials of the VSP.

>  I don't think the architecture

Ciao
Hannes

> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 4 Jun 2007 17:22:57 -0400

I'm confused. Having 'no VSP' seems like a completely different issue  
from 'no network authentication', which deals with access to the  
physical/link/network layer. I'm actually not even sure what 'no VSP'  
means. No outbound proxy?

On Jun 4, 2007, at 4:12 PM, Hannes Tschofenig wrote:

> For the case where there is no VSP, also referred as the  
> unauthenticated emergency service architecture, the access network  
> provider has to provide emergency service support directly or  
> indirectly (via a partnership with another emergency service  
> infrastructure provider).
>
> authentication can also be bypassed since you might loose more than  
> just the credentials of the VSP.
>
>> From: Hannes Tschofenig [mailto:[email-masked]] Sent:  
>> Monday, June 04, 2007 5:40 AM
>> To: ECRIT
>> the end
>> query as
>> The information transmitted is intended only for the person or  
>> entity to which it is addressed and may contain confidential,  
>> proprietary, and/or privileged material. Any review,  
>> retransmission, dissemination or other use of, or taking of any  
>> action in reliance upon this information by persons or entities  
>> other than the intended recipient is prohibited. If you received  
>> this in error, please contact the sender and delete the material  
>> from all computers. GA621
>>
>>
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 Jun 2007 21:42:23 -0400

I don't understand where this is going.
If the access network supplies coarse location to a non-authenticated
querier which is sufficient for routing or for validation, then it doesn't
matter if it's the endpoint or the VSP that is doing the routing or the
validating.

Neither the VSP nor the endpoint is an authorized querier to the access
network.  They are of equal status, they get the same result.

Brian

> Sent: Monday, June 04, 2007 4:13 PM
> To: Stark, Barbara
> Cc: ECRIT
> > The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA621
> >
> >
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 4 Jun 2007 22:07:11 -0500

I am at a loss to understand why either needs a coarse location if the
PSAP URI is provided directly to the end-point.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Tuesday, 5 June 2007 11:42 AM
> To: 'Hannes Tschofenig'; 'Stark, Barbara'
> Cc: 'ECRIT'
> Subject: RE: [Ecrit] Location Hiding - another look
> 
> > > I think it's important for the end point to be able to get the
PSAP
> URI,
unauthenticated
> > authentication can also be bypassed since you might loose more than
just
> > > should require that there be a VSP in order to make a SIP call
over
the
obtain a
this
query as
> > > Hannes
entity

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 08:45:37 +0200

If you lost your credentials (or the configuration) then it could mean 
three things:

a) You lost your credentials with your VSP
b) You lost your ASP/ISP credentials
c) You lost all your credentials including (VSP and ASP/ISP)

Here is a past mail on this subject:
http://www1.ietf.org/mail-archive/web/ecrit/current/msg03405.html

Henning Schulzrinne wrote:
>>> proprietary, and/or privileged material. Any review, retransmission, 
>>> dissemination or other use of, or taking of any action in reliance 
>>> upon this information by persons or entities other than the intended 
>>> recipient is prohibited. If you received this in error, please 
>>> contact the sender and delete the material from all computers. GA621
>>>
>>>
>>
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 08:52:24 +0200

Hi Brian,

> matter if it's the endpoint or the VSP that is doing the routing or the
It matters only that much that the end point has to implement LoST in 
this case.

In the 3GPP case that also supports the SIM-less emergency call scenario 
they don't need LoST since the access network runs the P-CSCF and the 
E-CSCF.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 08:54:03 +0200

Brian,

the main discussion here is:

* Some people want to enhance HELD by adding LoST functionality
* Some others want to use LoST as is.

Now we are at the stage where we try to find arguments when one solution 
is better than the other one.

Ciao
Hannes

 Winterbottom, James wrote:
>> querier which is sufficient for routing or for validation, then it
>>     
> doesn't
>   
>> matter if it's the endpoint or the VSP that is doing the routing or
>>     
> the
>   
>> validating.
>>
>> Neither the VSP nor the endpoint is an authorized querier to the
>>     
> access
>   
>>>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy
>>>>         
>> phone
>>     
>>>> network. But once PSAPs are reachable directly by VoIP, the
>>>>         
>> architecture
>>     
>>>> should allow end devices with open Internet access, but no VSP, to
>>>>         
>> make
>>     
>>>> emergency calls.
>>>>
>>>>         
>>> Ciao
>>> Hannes
>>>
>>>       
>>>> Barbara
>>>>
>>> which it is addressed and may contain confidential, proprietary,
>>>       
> and/or
>   
>>> privileged material. Any review, retransmission, dissemination or
>>>       
> other
>   
>>> persons or entities other than the intended recipient is prohibited.
>>>       
> If
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 5 Jun 2007 02:00:28 -0500

I want to use LoST as is.
I just don't see why HELD can't be used as a tool to hide locations from
services that the location provider does not want to offer.

> Sent: Tuesday, 5 June 2007 4:54 PM
> To: Winterbottom, James
> Cc: Brian Rosen; Stark, Barbara; ECRIT
not
location

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 5 Jun 2007 09:01:48 +0200

Where is LoST used as is? 

> > >>> use of, or taking of any action in reliance upon this 
> information
> by

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 5 Jun 2007 07:53:06 -0400

Sorry -- I didn't quote what I was responding to. I was responding to
the statement:
>> this PSAP URI in the location hiding case at all.
>> as we specified it.

I believe it's important for the end point to obtain the PSAP URI,
because there may not be a VSP doing a LoST look-up. By VSP, I'm
referring to the registration server, outbound proxy, etc.

Or am I wrong on this point? If the endpoint has the PSAP URI, does it
still need for these functions to exist between it and the PSAP URI?
Barbara

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, June 04, 2007 5:23 PM
To: Hannes Tschofenig
Cc: Stark, Barbara; ECRIT
Subject: Re: [Ecrit] Location Hiding - another look

On Jun 4, 2007, at 4:12 PM, Hannes Tschofenig wrote:

> Hi Barbara,
>
> Stark, Barbara wrote:
>> I think it's important for the end point to be able to get the PSAP 
>> URI, because there may not be a VSP, at all.
>
>> should require that there be a VSP in order to make a SIP call over 
>> the Internet. Certainly, VSPs are needed to get to PSAPs on the 
>> legacy phone network. But once PSAPs are reachable directly by VoIP, 
>> the architecture should allow end devices with open Internet access, 
>> but no VSP, to make emergency calls.
>>
>
> Ciao
> Hannes
>
>> Barbara
>> want to provide information about the precise location information to

>> the end point.
>> A lot of discussions focused on the question how it can still obtain 
>> a PSAP URI in that case.
>>
>> this PSAP URI in the location hiding case at all.
>> as we specified it.
>> The information transmitted is intended only for the person or entity

>> to which it is addressed and may contain confidential, proprietary, 
>> and/or privileged material. Any review, retransmission, dissemination

>> or other use of, or taking of any action in reliance upon this 
>> information by persons or entities other than the intended recipient 
>> is prohibited. If you received this in error, please contact the 
>> sender and delete the material from all computers. GA621
>>
>>
>
>

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 14:04:06 +0200

Hi Barbara,

> still need for these functions to exist between it and the PSAP URI?
These functions still have to exist since otherwise the end host would 
directly contact the PSAP and there wouldn't be an authenticated 
identity attached to the emergency call. This would be a serious 
security concern.

Someone has to provide emergency service related functionality. From a 
deployment point of view it would be easier to have the VSP to support 
LoST than to have support for it at every end host.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 14:43:36 +0200

Since we have seen these type of messages from time-to-time I suggest 
everyone to take a look at
https://www1.ietf.org/mailman//listinfo/ecrit
when they want to unsubscribe.

It does not help to send a mail to the list saying "Please unsubscribe 
me. I don't want to follow these confused discussions anymore.".

Beyer, Loraine wrote:
> Please remove my name from the distribution list.  I have unsubscribed
> >from [email-masked]. 
>
> Sent: Monday, June 04, 2007 8:42 PM
> To: 'Hannes Tschofenig'; Stark, Barbara
> Cc: 'ECRIT'
> doesn't matter if it's the endpoint or the VSP that is doing the routing
> or the validating.
>
>>> want to provide information about the precise location information 
>>> to the end point.
>>> entity to
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
>
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 5 Jun 2007 08:48:49 -0400

Note that this function would have to also be added to the dereference
mechanism so the VSP could validate the PSAP URI in solution 3.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Tuesday, June 05, 2007 3:00 AM
> To: Hannes Tschofenig

---

From: Richard Barnes <[email-masked]>
Date: Tue, 05 Jun 2007 09:02:33 -0400

> identity attached to the emergency call. This would be a serious 

 From a security perspective, there's no difference between calling a 
PSAP through a proxy or directly: There's no more a relationship between 
the proxy/VSP and the PSAP than between the endpoint and the PSAP. 
E.g., a PSAP in Fairfax, VA has (probably) no way to authenticate a VSP 
Sierra Leone, or the "VSP" that I have running on a box in my basement, 
and likewise, no way to authenticate identities of callers from those VSPs.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Jun 2007 09:10:19 -0400

Unless we agree whether VSP PSAP URI verification is a requirement or  
not, we are unlikely to make much progress.

On Jun 5, 2007, at 2:54 AM, Hannes Tschofenig wrote:

> Now we are at the stage where we try to find arguments when one  
> solution is better than the other one.
>
> Ciao
> Hannes
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Jun 2007 09:19:17 -0400

This goes back to an old debate we have had in several different  
instances (including L2 authentication and location signing): Namely,  
is the ability to verify the identity of some callers useful, even if  
not all legitimate callers can be verified? Brian, and probably  
others, have made the case that it is.

I think we have to be consistent here, even if the percentages vary  
between the various authentication cases. We can only guess at these  
percentages in any event.

I suspect that the vast majority of legitimate calls to a Fairfax  
PSAP will not come from a Sierra Leonian VSP.

On Jun 5, 2007, at 9:02 AM, Richard Barnes wrote:

>> These functions still have to exist since otherwise the end host  
>> would directly contact the PSAP and there wouldn't be an  
>> authenticated identity attached to the emergency call. This would  
>> be a serious security concern.
>
> From a security perspective, there's no difference between calling  
> a PSAP through a proxy or directly: There's no more a relationship  
> between the proxy/VSP and the PSAP than between the endpoint and  
> the PSAP. E.g., a PSAP in Fairfax, VA has (probably) no way to  
> authenticate a VSP Sierra Leone, or the "VSP" that I have running  
> on a box in my basement, and likewise, no way to authenticate  
> identities of callers from those VSPs.
>
> --Richard
>
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 05 Jun 2007 09:28:17 -0400

Hannes,

I would frame the debate a little differently:

* Some people want to provision rough LbyV to the endpoint so that it 
can do LoST queries
--> Requires modification of LoST to handle rough locations (polygons)

* Some people want the access network to do LoST on behalf of the endpoint
--> Requires modification to LCP(s) or trusted LoST servers

That said, I don't see why we can't offer both: As part of endpoint 
configuration (e.g., the LCP), the access network can specify which 
option it's using.  For instance, suppose the LCP could return either

1. LbyR + Rough LbyV, or
2. LbyR + LoST <mapping> elements

(And phonebcp says it MUST do one of those two, not just LbyR).  Then 
the endpoint could look at the LCP response and decide whether it needs 
to do LoST (in case 1) or just cache the returned mappings.

This solution would require the most protocol changes (rough location in 
LoST and <mapping> in LCPs), but I don't think it adds a whole lot of 
additional complexity.

--Richard

Hannes Tschofenig wrote:
>> contain privileged, proprietary, or otherwise private information.  If 
>> you have received it in error, please notify the sender

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 15:42:39 +0200

Hi Richard,

Richard Barnes wrote:
>> authenticated identity attached to the emergency call. This would be 
>> a serious security concern.
>
> PSAP through a proxy or directly: There's no more a relationship 
> between the proxy/VSP and the PSAP than between the endpoint and the 
> PSAP. E.g., a PSAP in Fairfax, VA has (probably) no way to 
> authenticate a VSP Sierra Leone, or the "VSP" that I have running on a 
> box in my basement, and likewise, no way to authenticate identities of 
> callers from those VSPs.
>
You are always so security concerned. Don't you think that the calls 
should typically go through the VSP to have a chance of getting SIP 
identity added?

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 15:47:08 +0200

Hi Richard,

> --> Requires modification of LoST to handle rough locations (polygons)
Correct.

> --> Requires modification to LCP(s) or trusted LoST servers
Correct.

> option it's using.

> For instance, suppose the LCP could return either
>
> 1. LbyR + Rough LbyV, or
> the endpoint could look at the LCP response and decide whether it 
> needs to do LoST (in case 1) or just cache the returned mappings.
Is this your suggestion for compromise or your ideal solution?

>
> This solution would require the most protocol changes (rough location 
> in LoST and <mapping> in LCPs), but I don't think it adds a whole lot 
> of additional complexity.

Don't you think we have too many options for emergency call signaling?

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 09:51:15 -0400

On Jun 5, 2007, at 9:10 AM, Henning Schulzrinne wrote:

> Unless we agree whether VSP PSAP URI verification is a requirement  
> or not, we are unlikely to make much progress.

Good point.  Just backing up a bit, the requirement is really that  
VSPs need to verify that a routed emergency call is really a routed  
emergency call.  Verifying the PSAP URI is just one method, but one  
which seems to hold most promise.

The most common objection to the current method proposed seems to be  
that ASPs/ISPs must then provision both coarse grain and fine grain  
location information -- the coarse grain location info being used by  
the VSP as an input to LoST to verify the PSAP URI.

Just thinking out loud here, but if we could use the PSAP URI as the  
input to LoST then this problem goes away. This is similar to reverse  
DNS lookups.  The input is a PSAP URI and the output is a <mapping>.   
A change to LoST would be required to support this.

-andy

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 5 Jun 2007 10:03:34 -0400

Thanks, Richard. My sentiments, exactly. I don't trust the Sierra Leone
VSP, the box in your basement, or the plethora of Asterisk servers in so
many people's basements and small and home offices, any more or less
than I trust communications directly from end devices. Having a VSP in
the flow does

Unless we want to create an emergency architecture that forces end users
to have relationships with "trustworthy" (certified?) VSPs [although I
salivate at such an idea ... ;-) ], I think the end device needs to
accept personal responsibility for as much as it can, where the need for
emergency services is concerned. The abilities of a VSP (if present) are
simply a redundant back-up to the capabilities of the end device, where
emergency services are concerned.
Barbara

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 9:03 AM
To: Hannes Tschofenig
Cc: Stark, Barbara; ECRIT
Subject: Re: [Ecrit] Location Hiding - another look

and likewise, no way to authenticate identities of callers from those
VSPs.

--Richard

*****

---

From: Richard Barnes <[email-masked]>
Date: Tue, 05 Jun 2007 10:05:46 -0400

> Is this your suggestion for compromise or your ideal solution?

I think this is a good compromise solution for the problem of 
provisioning PSAP URIs when location is given by reference.  At this 
point, I don't regard either of the competing solutions as ideal in all 
use cases.

In terms of PSAP URI validation, this would effectively require reverse 
LoST, since the endpoint doesn't necessarily have its own location.  If 
you really didn't want to do reverse LoST, you could have the endpoint 
include a service boundary (by value or reference) as its location, but 
that seems like a bad idea.

> Don't you think we have too many options for emergency call signaling?

I'm not sure understand the question.  In either case, the call 
signaling is the same.  What changes is how the endpoint gets the data 
to construct the INVITE.  In case (2), you could say that complexity is 
reduced (vs. the non-LbyR case), since th endpoint doesn't have to do 
LoST, and in case (1), it's identical from the endpoint's perspective -- 
it just takes the LbyV and does LoST.  And to determine which case to 
use, the endpoint only needs to look at the structure of the message, 
whether there's an LbyV or a <mapping> present.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Jun 2007 10:09:53 -0400

> which seems to hold most promise.

I can't think of any other, unless you want to administer lie  
detector tests to the caller.

>
> The most common objection to the current method proposed seems to  
> be that ASPs/ISPs must then provision both coarse grain and fine  
> grain location information -- the coarse grain location info being  
> used by the VSP as an input to LoST to verify the PSAP URI.

Some of us believe that this burden is trivial. It also affects only  
those that benefit from location hiding.

>
> Just thinking out loud here, but if we could use the PSAP URI as  
> the input to LoST then this problem goes away. This is similar to  
> reverse DNS lookups.  The input is a PSAP URI and the output is a  
> <mapping>.  A change to LoST would be required to support this.

We've discussed this extensively in the past, so I'm loath to repeat  
this discussion. The changes are fairly significant, as this requires  
more than just adding a message or two, but rather requires global  
and reliable propagation of URLs.

A basic criterion for any network architecture should be that those  
imposing a burden on others should also bear the cost. In other  
words, if somebody wants location hiding, they shouldn't make life  
more difficult for the rest of the world that obtains no benefit from  
that behavior. Forcing LoST maintainers  and VSPs to add complexity  
violates this basic principle.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 05 Jun 2007 10:11:49 -0400

Andy,

We'd discussed this briefly before.  I was thinking even simpler, 
inputting a URI and returning a boolean (is this a PSAP?) or a service 
boundary [reference].

In our previous discussions where we got stuck was changes to the 
mapping architecture (necessary changes to the LoST XML are minimal). 
You end up needing to flood URIs back up the LoST tree, then to a 
cluster of field guides that answer such queries.

ISTM that such an architecture would be reasonable to deploy: The volume 
of data that would need to get passed around is fairly low, and changes 
are not that frequent.  Others disagree with this.

--Richard

Andrew Newton wrote:
> Good point.  Just backing up a bit, the requirement is really that VSPs 
> need to verify that a routed emergency call is really a routed emergency 
> call.  Verifying the PSAP URI is just one method, but one which seems to 
> hold most promise.
> 
> location information -- the coarse grain location info being used by the 
> VSP as an input to LoST to verify the PSAP URI.
> 
> DNS lookups.  The input is a PSAP URI and the output is a <mapping>.  A 
> change to LoST would be required to support this.
> 
> -andy
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Jun 2007 10:22:03 -0400

> than I trust communications directly from end devices. Having a VSP in

Nobody has said that they should be. See my comments on this.

> emergency services are concerned.

This is a false dichotomy. I think there is general agreement that

- not all calls will be originating from VSPs (and that VSPs should  
not be required)
- not all VSPs will be known to PSAPs

In previous discussions in other contexts, it has been claimed that  
even having most or some calls be traceable or location-verifiable is  
useful. Either there is value to "some call" validation in any of  
these scenarios or there isn't, but this then applies across all  
three types of validation.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 16:27:23 +0200

Hi Andy,

> which seems to hold most promise.
Yep.
 
> the VSP as an input to LoST to verify the PSAP URI.
Yep

> A change to LoST would be required to support this.
That's true. But that would require an entirely separate infrastructure....

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 16:35:16 +0200

Hi Richard,

where do you put the PSAP URI as input to?
When doing this with LoST then you essentially create something like a 
reverse lookup mechanism. Flooding as an extreme form was also mentioned 
and is certainly also possible.

Ciao
Hannes

Richard Barnes wrote:
> ISTM that such an architecture would be reasonable to deploy: The 
> volume of data that would need to get passed around is fairly low, and 
> changes are not that frequent.  Others disagree with this.
>
> --Richard
>
>
>
> Andrew Newton wrote:
>>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 11:20:08 -0400

On Jun 5, 2007, at 10:09 AM, Henning Schulzrinne wrote:

> more difficult for the rest of the world that obtains no benefit  
> from that behavior. Forcing LoST maintainers  and VSPs to add  
> complexity violates this basic principle.

Alright, I'll give you this point (though I'm not understanding the  
complexity being foisted upon VSPs).  But this does add additional  
mappings for the system.

However, such a mapping is not a bad idea.  Many communications  
networks maintain these types of mappings to help in administrative  
and troubleshooting issues.  The Internet has reverse DNS and Whois,  
to name just one example.  So there are other benefits to it.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 5 Jun 2007 14:43:55 -0500

Is there a misunderstanding as to what the meaning of PSAP URI is?
I don't see the PSAP URI in almost all cases taking me directly to Bob
at the Denton PSAP. When I think of a PSAP URI, I think of this as being
the (forgive the NENA i3 terminology) ESRP URI. 
The ESRP being a gateway shielding access to the actual emergency
network.

If I got this URI sending things to it directly seems reasonable to me.

Cheers
James

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Wednesday, 6 June 2007 12:04 AM
> To: Richard Barnes; Hannes Tschofenig
> Cc: ECRIT
would
> PSAP through a proxy or directly: There's no more a relationship
between
to
and/or
other
If

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Jun 2007 17:33:31 -0400

In some cases, devices are configured to always use an outbound proxy.

In addition, in other cases, SBCs won't let voice in or out without  
the proxy lifting the gates.

Thus, this is not an issue of technical necessity, but deployment  
realities. I don't see, however, why this matters at all.