Re: [Ecrit] Location hiding: Consensus?

[Henning Schulzrinne <hgs at cs.columbia.edu>]

> > 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.
>
> What!?  I don't understand your response and can't seem how it is  
> even directly relevant to the issue raised.

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.


> 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.

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.


> 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.

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.


> > > Issue 1-3 UAs must now be forbidden from conveying dereferenced  
> > > location information.
> >
> > 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 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.)



> > > 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.
>
> 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.

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.


> > > 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.
>
> I don't understand your point.  Do you believe codifying the  
> 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?



> > Also, from an operator perspective, here the landline ISP has to  
> > operate a LoST resolver, instead of dumb "return fixed location"  
> > server.
>
> 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.

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.





> -andy


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