Subject: [Ecrit] [ecrit] #4: Untrusted location and provider intent

From: "ecrit issue tracker" <[email-masked]>
Date: Sun, 20 Mar 2011 01:46:57 -0000

#4: Untrusted location and provider intent

 A location cannot be considered trusted for emergency services use if the
 location provider doesn't warrant its use for that purpose.  The document
 currently does not discuss this point, but it seems like a quite important
 issue.

 For example, "location based services" which might provide location via a
 platform or Javascript API will not necessarily meet the reliability or
 accuracy requirements for emergency location.  In fact, the terms of
 service might explicitly disclaim the fitness for such uses.

 Yet existing location APIs typically do not make a distinction between
 location providers who consider their location data unfit for use in an
 emergency, and an enterprise or carrier LIS that might be deployed
 specifically for the purpose of providing location for use in an
 emergency.  Thus while it might be possible to construst a PIDF-LO by
 calling such an API, the validity of conveying such a PIDF-LO to the PSAP
 might be suspect.

 If an application can determine that a location is not warranted for use
 in an emergency, a number of workarounds might be possible.  For example,
 the location might not be automatically conveyed without confirmation, or
 might be flagged as potentially suspect, or the uncertainty might be set
 to a very high value.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  blocker                    |   Milestone:  milestone1
Component:  trustworthy-location       |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/ecrit/trac/ticket/4>
ecrit <http://tools.ietf.org/ecrit/>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 21 Mar 2011 09:02:24 -0400

The general rule I have for this is "send it, but let us know what you know about it".
No entity should withhold location information unless it is certain that the information it is withholding is fraudulent.
While the PSAP doesn't like having to decide what to do, it's better that it has the information and knows that some of it MAY be suspect.

Let me cite an example: a telematics equipped car with an accurate GPS, large antenna, always on, can provide far superior location than the cell phone through which an emergency call is placed.  We want the GPS from the car.  What we get is what the network thinks.

It's okay that the network use its location to route.  The PSAP would prefer that it used the telematics location, but it's acceptable to use the network location.  It's certainly acceptable to send the network location.  However, we also want the telematics location.

Of course, we want whatever location to be accurately labeled (source, method, uncertainty).

Brian

On Mar 19, 2011, at 9:46 PM, ecrit issue tracker wrote:

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Mar 2011 16:49:32 -0700

This seems reasonable.  Any recommendations on how we might ensure that location would be accurately labeled in situations where it originates from a "location based service" that might be designed for use within the ECRIT architecture? Also, any thoughts on the circumstances in which user confirmation might make sense? 

I am reminded of an experience at the IETF meeting in Stockholm where one of the "location based services" which shall remain nameless identified the IETF meeting as being located in San Francisco because the IETF access points were scanned during the previous IETF meeting.   If you were looking for a pizza restaurant that might be humorous, but maybe not so much if you were using the location for routing to the PSAP.  

> Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent
> From: [email-masked]
> Date: Mon, 21 Mar 2011 09:02:24 -0400
> CC: [email-masked]
> To: [email-masked]
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 21 Mar 2011 16:52:49 -0700

Sorry, I meant "not designed for use within the ECRIT architecture". 

From: [email-masked]
To: [email-masked]; [email-masked]
Date: Mon, 21 Mar 2011 16:49:32 -0700
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent

---

From: Brian Rosen <[email-masked]>
Date: Mon, 21 Mar 2011 20:01:25 -0400

The PIDF contains fields for method and source, and mechanisms to indicate uncertainty.  That will do.

Brian

On Mar 21, 2011, at 7:52 PM, Bernard Aboba wrote:

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 22 Mar 2011 10:00:11 +0800

>From the location service perspective, the response time attribute in the HELD location request allows the client to indicate that the intent is to use the location for emergency services (routing and/or dispatch). Depending on jurisdiction policy then the LIS may choose to provide a location or not depending on whether the operator is required to warrant such information. The client still has the opportunity to ask for location without these qualifiers if it wants to proceed on that basis; in that situation the operator does not know that the intent is to use the location for emergencies.

When it comes to a de-reference between the local emergency service and the network operator, there should be a clear understanding of obligations and undertakings outside the scope of the protocols anyway. I think that de-referencing is always valuable for this sort of validation and it's good policy to always provide and convey a reference for this purpose.

In any case, Bernard's anecdote below helps to underscore why it's important to include the network operator in the process and not rely on locations independently determined and reported by the device.

Cheers,
Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Tuesday, 22 March 2011 11:01 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent

Brian

Sorry, I meant "not designed for use within the ECRIT architecture".
________________________________
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Date: Mon, 21 Mar 2011 16:49:32 -0700
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent

> From: [email-masked]<mailto:[email-masked]>
> CC: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
>
> > Reporter: bernard_aboba@... | Owner:
> > [email-masked]<mailto:[email-masked]>

_______________________________________________ Ecrit mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Marc Linsner <[email-masked]>
Date: Tue, 22 Mar 2011 10:01:05 -0400

Martin,
> 
> 
> In any case, Bernard¹s anecdote below helps to underscore why it¹s important
> to include the network operator in the process and not rely on locations
> independently determined and reported by the device.
>  
Have any SPs entertained offering a general location discovery service?

I've only seen full location-based services/apps being offered to date.  It
makes one think that the end device using the cell tower db, 802.11 AP db,
and gps may remain the predominant location discovery mechanism.

-Marc-

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 22 Mar 2011 10:25:35 -0400

I think the answer is "Yes, kinda".  Multiple carriers are offering up location access via third-party services, such as LocationLabs [1] and LOC-AID [2].  There's also an effort in GSMA to standardize a similar API, under the aegis of the OneAPI effort [3].  Also lacking in discoverability.

Differences relative to ECRIT/GEOPRIV:
-- Not provided directly to subscriber devices
-- Not discoverable through automated means
-- Limited to cellular networks
-- Each service uses its own interface/API/protocol

All of which means serious headaches for a device that wants to roam across multiple networks, especially if those networks include non-cellular networks.

--Richard

[1] <http://www.locationlabs.com/>
[2] <http://www.loc-aid.com/>
[3] <http://www.gsmworld.com/oneapi/>

On Mar 22, 2011, at 10:01 AM, Marc Linsner wrote:

> Martin,
>> 
>> In any case, Bernard’s anecdote below helps to underscore why it’s important to include the network operator in the process and not rely on locations independently determined and reported by the device.
>>  
> I've only seen full location-based services/apps being offered to date.  It makes one think that the end device using the cell tower db, 802.11 AP db, and gps may remain the predominant location discovery mechanism.
> 
> -Marc-

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Mar 2011 11:06:38 -0400

> In any case, Bernard’s anecdote below helps to underscore why it’s important to include the network operator in the process and not rely on locations independently determined and reported by the de…
Sure, if the network operator location is wildly different from some other location, then perhaps the network's location might be better to route on. 

On the other hand, if the device has an on-board GPS that had been on for a long time and tracking, then the cell based is far inferior to the on board GPS.  You use the best data you can get, as long as there isn't a really serious conflict.

Mark it with where it came from, and how it was determined, and keep the uncertainty accurate, and we'll figure it out.

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 23 Mar 2011 08:27:04 +0800

Agreed - and this comes down to nuances of policy as well.

Do you trust a precise location from a device if the network reference suggests they are in a different country? Well, maybe not. Do you trust the precise location of the device if it falls within the uncertainty indicated by the network location - well, maybe you do.

The key point is that the network location should be a key arbitration parameter. We don't have to wheel out the anecdotes about swatting again do we.

Cheers,
Martin

From: Brian Rosen [mailto:[email-masked]]
Sent: Wednesday, 23 March 2011 2:07 AM
To: Dawson, Martin
Cc: Bernard Aboba; [email-masked]
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent

Brian

---

From: Marc Linsner <[email-masked]>
Date: Wed, 23 Mar 2011 09:07:56 -0400

> 
>  
> The key point is that the network location should be a key arbitration
> parameter. We don¹t have to wheel out the anecdotes about swatting again do
> we.
>  
Until the network location is made available, it has no value.

If location data is going to be held hostage to utilizing only SP provided
apps, OTT providers will continue to use device discovered location
information.

-Marc-

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 23 Mar 2011 09:24:01 -0400

I think you guys are talking past each other, in two ways:

1. On the one hand, what Martin is saying is yet another argument that SPs should provide location to OTT applications -- by reference if nothing else.  So he's arguing your point.

2. On the other hand, it kind of doesn't matter what location an OTT application uses.  The PSAP can also perform the verification using location information it acquires directly from the SP, third-party-query style.  

The approach of draft-ietf-ecrit-rough-loc is relevant here: The SP can provide the OTT application with a degraded value, as long as there's a reference that the PSAP can use to obtain the real goods.

--Richard

On Mar 23, 2011, at 9:07 AM, Marc Linsner wrote:

>> 
>>  
>> The key point is that the network location should be a key arbitration parameter. We don’t have to wheel out the anecdotes about swatting again do we.
>>  
> If location data is going to be held hostage to utilizing only SP provided apps, OTT providers will continue to use device discovered location information.
> 
> -Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 24 Mar 2011 06:18:56 +0800

Yeah - what he said.

I'm concerned that there's a mechanism for independently verifiable location for emergency calls; I think we have the mechanisms for that. I thought this was an ECRIT discussion - but if we're talking about other kinds of apps, my actual view is that it would be good for OTT providers to have access to both sources of location information. Conventional (generally just mobile) location architectures make that difficult but the geopriv architecture makes it much more straightforward.

Cheers,
Martin

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Thursday, 24 March 2011 12:24 AM
To: Marc Linsner
Cc: Dawson, Martin; [email-masked]
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent

--Richard