Subject: [Ecrit] Location hiding: Consensus?

From: Richard Barnes <[email-masked]>
Date: Fri, 04 May 2007 13:34:35 -0400

So, the discussion of location hiding seems to have died down.  Does 
that mean that we've reached some consensus?  Are we going with some 
variant option #1?

--Richard

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 May 2007 20:01:48 +0200

I hope that people have had time to study the Wiki page
http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding

---

From: Andrew Newton <[email-masked]>
Date: Fri, 4 May 2007 14:22:32 -0400

On May 4, 2007, at 1:34 PM, Richard Barnes wrote:

> So, the discussion of location hiding seems to have died down.   
> Does that mean that we've reached some consensus?  Are we going  
> with some variant option #1?

I'd appreciate if some of the issues raised were addressed.  See the  
wiki page.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 4 May 2007 20:22:06 -0400

> Issue HR-1 This should not be a requirement. Not all IP address  
> based location determination systems are that accurate.  
> Additionally, giving away course location information should not be  
> required to hide location. Course location information even at the  
> country level is useful commercially. One such example is Google,  
> which uses IP address location determination at the country level  
> to route users to language specific start pages. Access networks  
> should be allowed to charge for location information that is as  
> course as this, since it is a valuable asset on today's Internet. - 
> andy

We are not in the business of creating business opportunities for  
carriers at the expense of others. As long as our main 'customers'  
don't object, it's not our role to make life difficult and less  
debugable for emergency services. Given that GeoMind and others are  
giving away rough location information, the value of such information  
is in doubt in any event.

> Issue 1-3 UAs must now be forbidden from conveying dereferenced  
> location information.

I don't see why. LocationConveyance supports multiple locations.

> Issue 1-4 The semantic difference regarding authorization/ 
> nonauthorization of location information is lost, making it  
> difficult for UAs to know if they truly are not authorized to get  
> true location information. This introduces ambiquity, which should  
> be avoided for emergency situations.

I can't parse this. There is little ambiguity in a 403 Forbidden HTTP  
response, but in any event, the UA without credentials would get  
location, not a refusal, just not with the same accuracy.

> Issue 2a-2 The work around LoST discovery needs to be completed.  
> This is not specific to location hiding.

The issue is that LoST discovery will likely return multiple servers.  
I had earlier pointed out at least three plausible operators (ISP,  
VSP, general public service), provided by several different  
configuration mechanisms. The UA has to use the right one, as things  
will fail otherwise.

Also, from an operator perspective, here the landline ISP has to  
operate a LoST resolver, instead of dumb "return fixed location" server.

http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ 
LocationHiding

On May 4, 2007, at 2:22 PM, Andrew Newton wrote:

> I'd appreciate if some of the issues raised were addressed.  See  
> the wiki page.
>
> -andy
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 6 May 2007 18:42:13 -0500

No!

I saw at least 3 votes for solution 3.

> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Saturday, 5 May 2007 3:35 AM
> To: ECRIT
> Subject: [Ecrit] Location hiding: Consensus?
> 

------------------------------------------------------------------------------------------------
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: Andrew Newton <[email-masked]>
Date: Mon, 7 May 2007 14:27:56 -0400

On May 4, 2007, at 8:22 PM, Henning Schulzrinne wrote:

>> Additionally, giving away course location information should not  
>> be required to hide location. Course location information even at  
>> the country level is useful commercially. One such example is  
>> Google, which uses IP address location determination at the  
>> country level to route users to language specific start pages.  
>> Access networks should be allowed to charge for location  
>> information that is as course as this, since it is a valuable  
>> asset on today's Internet. -andy
>
> giving away rough location information, the value of such  
> information is in doubt in any event.

What!?  I don't understand your response and can't seem how it is  
even directly relevant to the issue raised.

But while we are on the subject of having to do special things to  
support location hiding (which is what I think you are talking  
about), I'd like to point out that the centroid of the intersection  
idea is a special case needed only for location hiding and imposes an  
implementation burden on everybody else, even though they are doing  
location hiding.

While centroid calculations on polygons may be something we end up  
needing to do, the normal case would not seek to avoid holes - or  
jurisdictions contained entirely in another jurisdiction.  However,  
for location hiding, the centroid calculation would have to  
compensate for any holes to avoid misrouting the call.

> I don't see why. LocationConveyance supports multiple locations.

For the normal case, there is nothing wrong with an end point  
dereferencing an LbyR and passing along the location information as a  
value.  With location-hiding, you don't want an endpoint doing this  
because the coarse location may have compensated for a hole and its  
centroid might not be accurate enough for dispatch.

> I can't parse this. There is little ambiguity in a 403 Forbidden  
> HTTP response, but in any event, the UA without credentials would  
> get location, not a refusal, just not with the same accuracy.

That's exactly the point.  If an endpoint isn't authorized to get  
location, then it should be told so.  It should not be led to believe  
that it has location as accurate as is possible.  The semantics are  
being overloaded in an ambiguous way.

> The issue is that LoST discovery will likely return multiple  
> servers. I had earlier pointed out at least three plausible  
> operators (ISP, VSP, general public service), provided by several  
> different configuration mechanisms. The UA has to use the right  
> one, as things will fail otherwise.

I don't understand your point.  Do you believe codifying the  
preference order is difficult and too burdensome to define?

> operate a LoST resolver, instead of dumb "return fixed location"  

Well, I would hope running a LoST resolver is not much more  
troublesome than running a DNS resolver.  It really isn't that big of  
a deal.  But the LIS cannot be dumb in the first place, as it must  
know about authorization policies, etc.. and know to provide fine  
location vs coarse location.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 8 May 2007 15:25:12 -0400

>> debugable for emergency services. Given that GeoMind and others  
>> are giving away rough location information, the value of such  

Maybe lowering the !? volume would be helpful.

You had written about the commercial usefulness of country-level  
location information as a reason that we should support hiding it.  
This is a business model issue, in my view. Protecting commercial  
value is certainly not a technical requirement.

> idea is a special case needed only for location hiding and imposes  
> an implementation burden on everybody else, even though they are  
> doing location hiding.

Not quite. The same functionality will be needed in the future when  
we have to support location determination techniques that don't  
return points, but rather uncertainty polygons. Earlier in the  
profile discussion, we had talked about deferring this for now, so  
we're simply forced to face this a bit earlier than planned.

> compensate for any holes to avoid misrouting the call.

However, that pothole-avoidance computation only needs to be done by  
the LIS, not the LoST server. Thus, the computational and complexity  
burden is imposed on the party that is restricting access to location  
information, which seems to me to be the right trade-off.

> dereferencing an LbyR and passing along the location information as  
> a value.  With location-hiding, you don't want an endpoint doing  
> this because the coarse location may have compensated for a hole  
> and its centroid might not be accurate enough for dispatch.

I think this is an instance of a general problem, namely that the SIP  
INVITE may contain multiple locations with different characteristics.  
For example, it could contain a (fixed) value and a reference that's  
updated based on movement of the caller. In that case, you also have  
a location (value) that may no longer be suitable for dispatch, and  
another (reference) which is preferable, i.e., exactly the same  
behavior.

We had also earlier heard of the example where, due to the delay in  
location determination, the initial call contains a cell/sector  
value, with a reference that will (hopefully) be more accurate by the  
time first responders are dispatched.

Thus, this isn't a new or hiding-unique problem, as annoying as it  
can be. (In general, I tend to think of the location hiding problem  
as being an artificially-created version of the two-stage cell/ 
sector, followed by AGPS, location determination in cellular systems.)

>>> true location information. This introduces ambiquity, which  
>>> should be avoided for emergency situations.
>>
> location, then it should be told so.  It should not be led to  
> believe that it has location as accurate as is possible.  The  
> semantics are being overloaded in an ambiguous way.

I'd be the last to defend location hiding as desirable, but I fail to  
see why providing no location at all is preferable to providing some  
location. As noted on the Wiki, having some location at least allows  
the end system/user to detect gross errors before placing a call.

> preference order is difficult and too burdensome to define?

Yes, because the LIS won't know what other location sources are  
available to the end user and what services it wants to use. Would  
this special LoST resolver be available for other lookups, e.g.,  
generated from GPS data? Would it support non-emergency services?

> troublesome than running a DNS resolver.  It really isn't that big  
> of a deal.  But the LIS cannot be dumb in the first place, as it  
> must know about authorization policies, etc.. and know to provide  
> fine location vs coarse location.

I agree that this is not a major hurdle, but if I recall correctly,  
some of the operators triggering this discussion have expressed a  
strong preference for as little additional infrastructure as  
possible. The location access issue is relatively easy, as existing  
Apache modules can handle this. In many cases, IP address-based  
authorization is all that's needed, unless the operator is extremely  
paranoid.

I think we're starting to exhaust this topic. It's clear that several  
solutions can be made to work, with different trade-offs in terms of  
protocol linkages, protocol changes necessary only for location  
hiding and infrastructure deployment, as well as the amount of  
debugging information available to end users.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 9 May 2007 10:06:58 -0400

> Maybe lowering the !? volume would be helpful.

I didn't realize your sensitivity to punctuation.

> value is certainly not a technical requirement.

So what is the reason for supporting location hiding?  Otherwise, you  
seem to be arguing that your view location hiding is correct and  
cannot be questioned.  I have simply pointed out that location hiding  
should hide all location information and that there are good reasons  
for it.  I certainly would like to hear your reasons why my arguments  
should not be considered.

>> jurisdictions contained entirely in another jurisdiction.   
>> However, for location hiding, the centroid calculation would have  
>> to compensate for any holes to avoid misrouting the call.
>
> However, that pothole-avoidance computation only needs to be done  
> by the LIS, not the LoST server. Thus, the computational and  
> complexity burden is imposed on the party that is restricting  
> access to location information, which seems to me to be the right  
> trade-off.

I don't think calling jurisdictions contained within other  
jurisdictions "potholes" is a good idea.  But the hole-avoidance  
computation needs to be done by the validating seeker, which is the  
VSP.  And it needs to know when it is to do the hole-avoidance vs.  
just a normal polygon lookup.

If that is not the case, perhaps I misunderstanding how this is to  
work.  Could you describe the inputs, computations, and outputs at  
every step in the process?

>> dereferencing an LbyR and passing along the location information  
>> as a value.  With location-hiding, you don't want an endpoint  
>> doing this because the coarse location may have compensated for a  
>> hole and its centroid might not be accurate enough for dispatch.
>
> I think this is an instance of a general problem, namely that the  
> SIP INVITE may contain multiple locations with different  
> characteristics. For example, it could contain a (fixed) value and  
> a reference that's updated based on movement of the caller. In that  
> case, you also have a location (value) that may no longer be  
> suitable for dispatch, and another (reference) which is preferable,  
> i.e., exactly the same behavior.

Perhaps it is my reading of the phone-bcp document.  Steps 10, 11, &  
12 in section 6.1 talk about what to do here.  There are no steps  
that say "do not dereference an LbyR and use the result as an LbyV".   
Now that must be expressly disallowed, though your example above also  
provides a good reason to disallow it.

> I'd be the last to defend location hiding as desirable, but I fail  
> to see why providing no location at all is preferable to providing  
> some location. As noted on the Wiki, having some location at least  
> allows the end system/user to detect gross errors before placing a  
> call.

Well, I think it would be preferable to fully support location hiding  
rather than to only partially support it.  But suggesting that end  
users will be able to know gross location errors is a bit of wishful  
thinking.  For lat/long, I doubt most users would be able to know.   
As for civic, I always tend to get confused when I've driven into  
Montgomery Co., MD, when I'm in DC -- knowing the demarkation for  
various civic jurisdictions isn't something you can count on an end  
user understanding.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 9 May 2007 10:19:19 -0400

> generated from GPS data? Would it support non-emergency services?

Well, since it would be a LoST resolver just like any other, then it  
could handle lookups from GPS data.  As to which services it  
supports, that is up to the operator of the LoST resolver.

If you are suggesting that they should not have to support the pizza- 
location service, then I would agree.  But the issue of finding a  
LoST resolver for a particular service type is generic and not  
specific to location-hiding.  I would think that for non-emergency  
services, the client would be preconfigured with LoST resolvers  
appropriate for those services.

If that is incorrect and the ECRIT LoST discovery work, such as in  
draft-ietf-ecrit-dhc-lost-discovery, is to be to allow discovery of  
non-emergency LoST resolvers, then I cannot see how that would work.   
Methods of ECRIT LoST discovery should only be about discovering LoST  
resolvers capable of handling emergency services.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 11:22:31 -0400

On May 9, 2007, at 10:06 AM, Andrew Newton wrote:

>
> So what is the reason for supporting location hiding?  Otherwise,  
> you seem to be arguing that your view location hiding is correct  
> and cannot be questioned.  I have simply pointed out that location  
> hiding should hide all location information and that there are good  
> reasons for it.  I certainly would like to hear your reasons why my  
> arguments should not be considered.
>

Location hiding is not an ECRIT charter goal and is not in any of the  
current requirements documents. So far, the only actual user  
requirements are for partial location hiding. Thus, I see no reason  
to support something that no implementors seem to be asking for, but  
which makes the system more brittle, imposes, on end users, costs and  
complexity.

Are you suggesting that, from a technical standpoint, hiding location  
from the end system is a good idea?

We can continue to invent requirements, and continue to make the  
system more complex and less debuggable. I fail to see the value in  
that.

>>> While centroid calculations on polygons may be something we end  
>>> up needing to do, the normal case would not seek to avoid holes -  
>>> or jurisdictions contained entirely in another jurisdiction.   

Unfortunately, in your model, the VSP would have no way to do any  
validation at all, since it is not operating a trusted LoST server,  
according to our 'no business relationship' requirement and thus  
can't resolve the reference. Thus, your model actually fails to  
support the validation requirements. That's certainly good to note.

> every step in the process?

I'm using Brian's variation of my proposal. The LIS computes, based  
on its querying of LoST, a geometric shape such as a polygon or  
circle whose centroid/center lands in the right PSAP and includes the  
current location of the client, presumably somewhere other than in  
the center.

The VSP does exactly the same computation, again taking the center of  
the circle to do the lookup. Thus, it performs no special operation  
and is not concerned with holes in service areas at all.

If the PSAP is a convex polygon, there's no need for the LIS  
computation, but the verifying VSP doesn't care one way or the other.

>> a reference that's updated based on movement of the caller. In  
>> that case, you also have a location (value) that may no longer be  
>> suitable for dispatch, and another (reference) which is  
>> preferable, i.e., exactly the same behavior.
>
> Perhaps it is my reading of the phone-bcp document.  Steps 10, 11,  
> & 12 in section 6.1 talk about what to do here.  There are no steps  
> that say "do not dereference an LbyR and use the result as an  
> LbyV".  Now that must be expressly disallowed, though your example  
> above also provides a good reason to disallow it.

I suspect clarifying text is in order here.

> Well, I think it would be preferable to fully support location  
> hiding rather than to only partially support it.  But suggesting  
> that end users will be able to know gross location errors is a bit  
> of wishful thinking.  For lat/long, I doubt most users would be  
> able to know.  As for civic, I always tend to get confused when  
> I've driven into Montgomery Co., MD, when I'm in DC -- knowing the  
> demarkation for various civic jurisdictions isn't something you can  
> count on an end user understanding.

Civic addresses are primarily of interest for the residential case,  
and I suspect most people know their street address enough to  
recognize that they've been placed in the wrong town or county.

Given the availability of Google Maps, I don't see much of a problem  
with visualizing that location on such a map.

I'm not claiming that everyone will do this, but that doesn't make it  
useless. Discovering some mistakes ahead of time seems to beat  
discovering none.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 9 May 2007 21:31:23 -0400

On May 9, 2007, at 11:22 AM, Henning Schulzrinne wrote:
> Are you suggesting that, from a technical standpoint, hiding  
> location from the end system is a good idea?

I think you misunderstood my point.  Simply put, if you are going  
through the trouble to support location hiding, you should support it  
fully and not partially.

> support the validation requirements. That's certainly good to note.

Hmmm... yet in your model, the PSAP is somehow known as a trusted  
entity when dereferencing location.  In whatever way that occurs,  
which has not been explained, the VSP can also use that trust  
relationship to determine if it is sending calls to a PSAP.

There is another issue with the validation step.  Taking Brian's now- 
infamous VSP in Sierra Leone, how can you be assured that the LoST  
tree used by the VSP is capable of traversing to the LoST tree used  
by the LIS?

> circle whose centroid/center lands in the right PSAP and includes  
> the current location of the client, presumably somewhere other than  
> in the center.
>
> The VSP does exactly the same computation, again taking the center  
> of the circle to do the lookup. Thus, it performs no special  
> operation and is not concerned with holes in service areas at all.

Since the computation is the same, why not just send the point that  
is the centroid?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 21:50:05 -0400

On May 9, 2007, at 9:31 PM, Andrew Newton wrote:

> through the trouble to support location hiding, you should support  
> it fully and not partially.

Why? We're engineering for requirements, not some abstract ideal of  
perfection, particularly since that perfection is about as far away  
from where we want to be without the business issue. After all,  
location hiding isn't the architecture that the working group agreed  
upon. Thus, I think the right model is to what we need to do, but no  
more.

>> validation at all, since it is not operating a trusted LoST  
>> server, according to our 'no business relationship' requirement  
>> and thus can't resolve the reference. Thus, your model actually  
>> fails to support the validation requirements. That's certainly  
>> good to note.
>

PSAPs and ISPs are not competing with each other, ISPs (in their  
often dual role as VSPs) and VSPs are. Also, the number of PSAPs per  
ISP is very small, compared to the number of VSPs. There is no way  
that an ISP can know all the VSPs in the world.

I don't like this trust relationship, but it's been proposed by  
others for other reasons (location signing), and I don't recall you  
objecting at that point.

>
> There is another issue with the validation step.  Taking Brian's  
> now-infamous VSP in Sierra Leone, how can you be assured that the  
> LoST tree used by the VSP is capable of traversing to the LoST tree  
> used by the LIS?
>

For any number of reasons, we need a global LoST tree if the Sierra  
Leonian VSP is to work at all for roaming users, location hiding or  
not. We can't count on every ISP offering LoST services, for example.

>> I'm using Brian's variation of my proposal. The LIS computes,  
>> based on its querying of LoST, a geometric shape such as a polygon  
>> or circle whose centroid/center lands in the right PSAP and  
>> includes the current location of the client, presumably somewhere  
>> other than in the center.
>>

We don't want to lie by pretending that the client is somewhere where  
it isn't. In the centroid model, we simply artificially "fuzz" the  
location information.

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 9 May 2007 21:06:44 -0500

I have tried really hard not to chime on this argument except to try and
point out some of the impracticalities of some aspects. But this email
requires some responses.

Firstly, without the business model this is not going happen
alternatives will be found, and they will likely be local derivatives.
Business requirements are requirements none the less and to ignore this
fact is silly. Two major carriers on this list have indicated that they
will deploy this kind of solution, we can bury our heads in the sand, or
we can solve it. See below that I think any kind of providing partial
location is a bad idea.

I don't really see ISPs necessarily competing with VSPs, they may in
some cases but they certainly don't in others. The example is exactly
the Brian's Sierra Leone case, how is my home VSP in Sierra Leone
competing with my the ISP serving my hotel in Minneapolis?

If I provide an end-point a fuzzed location how do they know what it is
restricted to? If it is good enough for a LoST server to then provide
them with a PSAP URI, how do you ensure without a doubt that it isn't
good enough to get them to a Pizza hut? How do you ensure that the
centroid will get them to the right Pizza hut? How do you stop thw wrong
pizza hut from getting really annoyed because they keeping getting
incorrect calls? The list goes on.  Not to mention, that a LIS that did
not previously need to know anything about service boundaries now needs
to compute them. Please read this as "I really really really hate any
solution that requires a LIS or LIS operator to do this". 

I would also like to stress that I think that this is as much a GeoPriv
problem as it is an ECRIT problem.

Cheers
James

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 10 May 2007 11:50 AM
> To: Andrew Newton
> Cc: ECRIT
> Subject: Re: [Ecrit] Location hiding: Consensus?
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 22:32:06 -0400

> we can solve it. See below that I think any kind of providing partial

If you recall the earlier discussion, we had already agreed that  
revealing the PSAP URL effectively reveals the PSAP coverage area,  
since this is generally public. Thus, trying to hide anything below  
that level is pointless, even if you don't believe in the fact that  
IP address-based location is, in most cases, at least as precise.

> competing with my the ISP serving my hotel in Minneapolis?

They may not be, but the solution has to work even if they are  
competing. Let's say I set up a VSP that believes that location  
information should be freely given to my customers. You are now  
prohibiting me from serving my customers if I don't sign your NDA?  
How would you enforce that the Sierra Leonian VSP doesn't hand out  
location information to their customers? Should every ISP sign an NDA  
with every VSP?

I'm sorry, but we are not going to make progress if we re-argue the  
core ECRIT assumptions for each problem. The 'no business  
relationship' assumption has been in our requirements document from  
the very beginning. It might even be in the charter discussion.

> solution that requires a LIS or LIS operator to do this".

ECRIT is solving the emergency calling problem. Besides, the same  
problem will occur with any non-precise information, whether this is  
cell-sector or this artificially fuzzed data. As far as I can tell,  
you have not been objecting to delivering cell-sector information to  
end users.

> problem as it is an ECRIT problem.

I'm sure that adding another working group is going to help us make  
progress...

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 9 May 2007 22:43:01 -0500

Your responses miss the point in almost all cases.

If you want to use IP to location database outside of my access network
control please go ahead. I will certainly not be held accountable for
providing you incorrect information, so I agree there may be
alternatives, but they are not my concern, and if you choose to use them
on your head be it.

If I give you a series of PSAP URIs and you choose to reverse engineer
the service boundary, again that is your prerogative, and I can't stop
you from doing it. It doesn't however, except in some very special
circumstances, tell you precisely where you are.

As far as I can tell, LoST says currently, if you push in a location, it
can push out a few things, one of which is the uri of a PSAP. It doesn't
say that this MUST be the end-point, if it did, then the whole
retransmission-allowed discussion is moot. I have made no attempt to
change this premise.

I simply do not understand your "business relationships" arguments.
ECRIT is, as far as I am concerned, directed at routing emergency calls.
It has always explicitly stated that how an end-point learns it location
or otherwise is out of scope and a geopriv problem. So I put to you the
following the scenario, and perhaps you can explain to me where the
"business relationship" impact comes into play.

1) I ask the LIS for a location, it gives me back a bunch of dial
strings, a corresponding bunch of PSAP URIs, and a location reference.
(so far no business relationship).

2) I make a call through my VSP in Sierra Leone (UAC to VSP relationship
but this has always been agreed to).

3a) VSP routes call to PSAP (I have a monthly calling plan), PSAP
answers call and uses reference (no business relationship)

3b) VSP wants to check the URI, it uses a yet to be built LoST interface
that does URI to service mapping, and either bills me, or pushes the
call to the PSAP (no business relationship).

This is all in scope for ECRIT, and seems fine to me.

If I want to use location for other services, nobody has said that the
access network provider should not be able to charge for this. are you
saying that they should not be allowed to charge for this?

Cheers
James

> Sent: Thursday, 10 May 2007 12:32 PM
> To: Winterbottom, James
> Cc: ECRIT

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 May 2007 10:15:22 -0400

Just to address the point of relevance to GEOPRIV:

Proposal 1 does raise GEOPRIV concerns because it requires the LIS to 
give out location to unauthorized entities.  Even if there's strong 
randomness in the LbyR, if someone does manage to guess or steal the 
LbyR, then the LIS MUST give that party the endpoint's rough location. 
Speaking with a GEOPRIV hat on, that's not OK.

However, the "rough location" proposal, in the abstract, does not 
require this.  For instance Proposal 1B (that I added to Hannes' wiki 
yesterday) uses the LCP for delivery of rough location to the endpoint only.
<http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding>

--Richard

Henning Schulzrinne wrote:
> revealing the PSAP URL effectively reveals the PSAP coverage area, since 
> this is generally public. Thus, trying to hide anything below that level 
> is pointless, even if you don't believe in the fact that IP 
> address-based location is, in most cases, at least as precise.
> 
> 
> 
> prohibiting me from serving my customers if I don't sign your NDA? How 
> would you enforce that the Sierra Leonian VSP doesn't hand out location 
> information to their customers? Should every ISP sign an NDA with every 
> VSP?
> 
> I'm sorry, but we are not going to make progress if we re-argue the core 
> ECRIT assumptions for each problem. The 'no business relationship' 
> assumption has been in our requirements document from the very 
> beginning. It might even be in the charter discussion.
> 
> 
>>
> cell-sector or this artificially fuzzed data. As far as I can tell, you 
> have not been objecting to delivering cell-sector information to end users.
> 
> 
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 May 2007 10:24:00 -0400

The reference is carried in exactly the same protocols as a value  
would be, so the exposure to third parties is exactly the same. We  
have assumed all along that the URL is not guessable.

On May 10, 2007, at 10:15 AM, Richard Barnes wrote:

> Proposal 1 does raise GEOPRIV concerns because it requires the LIS  
> to give out location to unauthorized entities.  Even if there's  
> strong randomness in the LbyR, if someone does manage to guess or  
> steal the LbyR, then the LIS MUST give that party the endpoint's  
> rough location. Speaking with a GEOPRIV hat on, that's not OK.
>
> require this.  For instance Proposal 1B (that I added to Hannes'  
> wiki yesterday) uses the LCP for delivery of rough location to the  
> endpoint only.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 May 2007 10:32:37 -0400

It should be noted, however, that it will be necessary to standardize 
that assumption, including a definition of "not guessable" and likely 
some documentation of how to make such URLs.

Why not just avoid this pothole and use the LCP instead of the 
dereference protocol?  Architecturally, they're playing the same role 
(delivering rough location to the endpoint), but using the LCP doesn't 
have these privacy concerns.

--Richard

Henning Schulzrinne wrote:
> The reference is carried in exactly the same protocols as a value would 
> be, so the exposure to third parties is exactly the same. We have 
> assumed all along that the URL is not guessable.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 May 2007 10:39:27 -0400

There is already an RFC describing how to build cryptographically  
random numbers, which can be easily cited.

On May 10, 2007, at 10:32 AM, Richard Barnes wrote:

> It should be noted, however, that it will be necessary to  
> standardize that assumption, including a definition of "not  
> guessable" and likely some documentation of how to make such URLs.
>
> dereference protocol?  Architecturally, they're playing the same  
> role (delivering rough location to the endpoint), but using the LCP  
> doesn't have these privacy concerns.
>
> --Richard
>

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 10 May 2007 16:41:54 +0200

Hi Richard, 

I don't see the challenges you describe.
Just reference RFC 4086 and you are fine. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Donnerstag, 10. Mai 2007 15:39
> An: Richard Barnes
> Cc: ECRIT
> Betreff: Re: [Ecrit] Location hiding: Consensus?
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 May 2007 13:22:15 -0400

There are certainly plenty of documented ways to go about this, but 
Proposal 1 would require normative language to enforce it.  And, while 
the requirement seems clear (1. provide unauthorized access to rough 
location, and 2. add cryptographic randomness per RFC 4086), it's not 
clear which reference systems the requirement is levied on.  Does this 
apply to all presence services that include location information useful 
to emergency services?  Does it just apply to a LIS (and for what 
definition of LIS)?  What if a single box is a presence server and a LIS?

Why are you guys attached to using the dereference protocol to deliver 
rough location?  What's wrong with just using the LCP?  This seems like 
a much cleaner design.

--Richard

---

From: Matt Lepinski <[email-masked]>
Date: Thu, 10 May 2007 16:22:21 -0400

I'm really trying to understand the fundamental disagreement between 
James and Henning and I'm failing completely.
Any clarification of the following points would be greatly appreciated.

1) I believe James began by stating that there are business requirements 
for location hiding, and that these are real requirements. I believe 
everyone participating in this thread agrees on that point. (Ignoring 
any value judgement about whether these requirements are good or evil)

2) James seems to believe that providing "fuzzed" location to the 
end-point is a bad idea. This would seem to be a fundamental source of 
disagreement with Henning who has supported sending "fuzzed" location to 
the end-point.

Henning's argument seems to be that PSAP URI is already a form of 
"fuzzed" location that we're already providing, and James seems to be 
concerned with the access network provider being held accountable for 
providing "low quality" location.

Is this understanding correct?

3)The whole business relationships argument is especially confusing to 
me since it seems that both Henning and James agree that ISPs should not 
be required to have business relationships with VSPs. (I don't think 
I've heard anyone in this thread argue against that basic point).

It is reasonable to say that a particular proposal is bad because it 
would require contractual relationships between ISPs and VSPs, but so 
far I don't think I've heard James argue in support of any particular 
proposal.

Thanks for the clarification, sorry if I'm just being dense,
- Matt Lepinski :->

Winterbottom, James wrote:

>If I want to use location for other servic
> network provider should not be able to charge for this. are you
>>>alternatives will be found, and they will likely be local
>>>      
>>>
>derivatives.
>  
>
>>>we can solve it. See below that I think any kind of providing
>>>      
>>>
>partial
>  
>
>>>location is a bad idea.
>>>
>>>      
>>>
>>>some cases but they certainly don't in others. The example is
>>>      
>>>
>exactly
>  
>
>>I'm sorry, 
>ress if we re-argue the
>>>restricted to? If it is good enough for a LoST server to then
>>>      
>>>
>provide
>  
>
>>>them with a PSAP URI, how do you ensure without a doubt that it
>>>      
>>>
>isn't
>  
>
>>>to compute them. Please read this as "I really really really hate
>>>      
>>>
>any
>  
>
>[m

---

From: Andrew Newton <[email-masked]>
Date: Thu, 10 May 2007 16:44:23 -0400

On May 10, 2007, at 4:22 PM, Matt Lepinski wrote:
> 1) I believe James began by stating that there are business  
> requirements for location hiding, and that these are real  
> requirements. I believe everyone participating in this thread  
> agrees on that point. (Ignoring any value judgement about whether  
> these requirements are good or evil)

Well, I thought Henning disagreed with there being real business  
requirements.

> end-point is a bad idea. This would seem to be a fundamental source  
> of disagreement with Henning who has supported sending "fuzzed"  
> location to the end-point.
>
> "fuzzed" location that we're already providing, and James seems to  
> be concerned with the access network provider being held  
> accountable for providing "low quality" location.

I am not a particular fan of fuzzing either.  We've got little  
deployment experience with this architecture and who knows what  
trouble this will invite.

And fuzzing adds fuel to the fire for those that say VoIP 9-1-1  
doesn't work or is not reliable.

> 3)The whole business relationships argument is especially confusing  
> to me since it seems that both Henning and James agree that ISPs  
> should not be required to have business relationships with VSPs. (I  
> don't think I've heard anyone in this thread argue against that  
> basic point).
>
> It is reasonable to say that a particular proposal is bad because  
> it would require contractual relationships between ISPs and VSPs,  
> but so far I don't think I've heard James argue in support of any  
> particular proposal.

I thought James was an advocate of #3.

What we seem to have an issue with is the agreement on the  
requirements, and this is causing people not to agree on a solution.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 10 May 2007 16:28:21 -0500

Matt,

My real concern is that there is a huge difference for an access network
provider between:

1) Getting a LoST server to return a bunch of URIs and corresponding
service URNs for which it is designed to do based on location
information provided.

And

2) The access network asking the LoST server for the service boundaries
of each emergency URN it knows about, performs intersection on these,
and the providing the intersecting service boundary back to the
end-point. Oh, and making sure that this location doesn't have more than
16 vertices and that it addresses any holes.

Option is a practical solution to a real problem, 2 is quite frankly
ridiculous.

Cheers
James

> From: Matt Lepinski [mailto:[email-masked]]
> Sent: Friday, 11 May 2007 6:22 AM
> To: Winterbottom, James
> Cc: Henning Schulzrinne; ECRIT
requirements
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 10 May 2007 16:28:51 -0500

I am an advocate of solution 3

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, 11 May 2007 6:44 AM
> To: Matt Lepinski
> Cc: Winterbottom, James; ECRIT

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 May 2007 18:29:05 -0400

Andy,

I think you're right that we're disagreeing about requirements.  With 
that in mind, here's another shot at requirements (below, and on the 
wiki page).  I think there's pretty broad consensus on the Required 
Components and Requirements.  But differences remaining on the Possible 
Requirements, and each of those could disqualify one or more solutions.

--Richard

Required components:
1. A mechanism to deliver to endpoints, at any time,
    1. All emergency dial strings for their location
    2. PSAP URIs (matched to service URNs) for all services available at 
their location
2. A mechanism to deliver endpoint location to PSAPs/emergency responders.
3. A mechanism by which a VSP can learn whether a URI is a PSAP URI

Requirements:
1. MUST NOT require the ISP to give precise location to the endpoint.
2. MUST NOT require the ISP to give rough location to an unauthorized party.
3. A party in possession of a URL MAY be considered authorized. However, 
in this case,
    1. The solution MUST specify which URLs are required to have this 
property, and
    2. URLs MUST have a cryptographically random component with a 
specified minimum size
4. MUST NOT require a business/trust relationship between ISP and VSP
5. MUST NOT require a business/trust relationship between VSP and PSAPs
6. MAY require a business/trust relationship between ISP and PSAPs
7. MUST NOT require any particular structure for the emergency response 
network
8. MUST NOT require any particular geometric propertise of PSAP boundaries

Possible requirements
1. MUST NOT require the ISP to give location of any granularity to the 
endpoint
2. MUST NOT require the use of a particular LoST resolver by the endpoint

Desiderata:
1. Minimal effect on call setup latency
2. Minimal changes from existing protocols & architectures
3. Minimal difference between provisioning by-value and by-reference
4. Minimal changes to UA configuration mechanisms
5. Maintain separation of protocols for location configuration and mapping
6. Independence of protocol used by the UA for calling / session 
establishment

Andrew Newton wrote:
>> requirements. I believe everyone participating in this thread agrees 
>> on that point. (Ignoring any value judgement about whether these 
>> requirements are good or evil)
> 
>> disagreement with Henning who has supported sending "fuzzed" location 
>> to the end-point.
>>
> deployment experience with this architecture and who knows what trouble 
> this will invite.
> 
> And fuzzing adds fuel to the fire for those that say VoIP 9-1-1 doesn't 
> work or is not reliable.
> 
>> me since it seems that both Henning and James agree that ISPs should 
>> not be required to have business relationships with VSPs. (I don't 
>> think I've heard anyone in this thread argue against that basic point).
>>
> What we seem to have an issue with is the agreement on the requirements, 
> and this is causing people not to agree on a solution.
> 
> -andy
> 
> 
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 11 May 2007 07:49:12 -0400

I think there might be a simpler way to handle the case of different
"sos" services having different service boundaries. It seems to me the
access network could get all the PSAP URIs from the LoST server (for a
given location), and then have a simple mapping that says "if this set
of PSAP URIs, then return this location (point or
city/state/county/country)". The LIS can check once a day, or so, in
non-real-time, to see if there have been any changes to PSAP boundaries
that would invalidate the returned coarse location. But this doesn't
happen very often. In the US, since the spread of 9-1-1, I don't see
there being many (if any?) cases of differing boundaries (at the call
center level) for different emergency services. There are definitely
different boundaries for the responders, but that tends to be obscured
at the call center level. If states implement a state-wide ESRN to
handle routing to individual call centers, then there's really no
problem. I also don't see a particular LIS being local to an
overwhelming number of PSAPs, so the mapping of URI sets wouldn't be
very large.

I, too, would prefer Option 3, but I think Option 1 is do-able.
Barbara

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Thursday, May 10, 2007 5:28 PM
To: Matt Lepinski
Cc: ECRIT
Subject: RE: [Ecrit] Location hiding: Consensus?

Matt,

And

Cheers
James

requirements

> disagreement with Henning who has supported sending "fuzzed" location
to

> me since it seems that both Henning and James agree that ISPs should
not

> >If I want to use location for other servic  network provider should 
> >not be able to charge for this. are you saying that they should not 
> >be allowed to charge for this?
> >
> >Cheers
> >James
> >
> >
> >
> >
> >
> >>>Business requirements are requirements none the less and to ignore 
> >>>this fact is silly. Two major carriers on this list have indicated 
> >>>that they will deploy this kind of solution, we can bury our heads 
> >>>in the sand, or we can solve it. See below that I think any kind of

> >>>providing
--
--

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

*****

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