ecrit@ietf.org
[Top] [All Lists]

RE: AW: [Ecrit] Location Hiding -- State of the Art

Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art
From: "Dawson, Martin"
Date: Tue, 11 Dec 2007 17:37:43 -0600
Hi Ted,

> so we'd be stuck with two systems that everyone would have to
> implement.  That's all kinds of bad.

They are two different models for location based service - there's also
a third type of location query based on user-identity and made to a
presence service. Location queries to a LIS are largely anonymous.

In keeping with the "nothing new under the sun" principle, these models
already have a precedent.

3GPP defines three categories of location request:

MO-LR - "mobile originated location request". The device requests
location from the access network and obtains it for its own purpose.

NI-LR - "network initiated location request". The network queries the
location server for some network based application (emergency calling be
the classic case).

MT-LR - "mobile terminated location request". Some application external
to the network request the location of the device based on the
subscriber identity (phone number).

A device-initiated LbyV request is really the MO-LR case. LbyR is
different primarily because of the more fundamental access-service split
that occurs in the Internet but, for the types of services being
discussed, it's very like the NI-LR in some cases and the MT-LR in
others. A query for location to a presence service is the MT-LR case.

As opposed to being "all kinds of bad", I'd posit that these models will
inevitably emerge and, in fact, they live together quite comfortably.
While ever we have protocol specifications that don't support all these
models there will be somebody who is experiencing frustration and
discontent with the specifications.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:hardie@xxxxxxxxxxxx] 
Sent: Wednesday, 12 December 2007 9:34 AM
To: Winterbottom, James; Brian Rosen; Liess, Laura; bs7652@xxxxxxx;
Dawson, Martin
Cc: ecrit@xxxxxxxx
Subject: RE: AW: [Ecrit] Location Hiding -- State of the Art

At 4:16 PM -0600 12/11/07, Winterbottom, James wrote:
>Hi ted,
>
>Comments inline.
>
>Given some of your response I think we are talking past each other.
<snip>


>[AJW] Perhaps I should have been consistent in my terminology, I used
>access and location provider inter-changeably. I see location always
>being provided to emergency service providers.
>

Yes, this was a source of confusion.

>On the other front, a location provider can form trust relationships
>with service vendors, for example the local pizza parlor, or the AAA,
or
>whatever. This would require the recipient of a location URI to
>authenticate with the LIS prior to location being handed out.

In this model, the location provider chooses not to provide location
to the end users  at all, since they could then hand it out as they
please,
but to sell it only to those with whom it has business relationships.
That's not really
a location hiding problem; it's entirely a business one.   It's
difficult
to get the end user to support this with subscription revenue, so
the relationships have to be broad enough that selling them pays
for the infrastructure.  This really is well outside the problem space
of this working group, though, and I don't see much use in going down
into this rathole here.

The point I was making before is that eliminating access to the location
doesn't eliminate access to the service; I can still call Pizza Igloo
even
if you will provide a location URI dereference only to Pizza Leanto.
You're not doing anything to stop access to Pizza Leanto's service,
which was what your initial formulation sounded like.


> > As stated, this doesn't make sense, at least to me.  A VSP with
access
>to
>> location
>> can provide exactly the same location-based-routing as the originator
>of
>> that location.
>> If it cannot, some other manipulation of the packet flow must be
>present
>> to prevent
>> it.
>>                                      Ted
>>
>
>[AJW] If all you give the end point is the service URN (+ dial string),
>a destination URI and a location URI, where the latter requires
>authentication to dereference, how does the VSP get location?

The point I was making is that there is no necessary coupling here;
if the  VSP gets location (say, from a form entry by a customer with
a static line), they can do  the same location-based routing
that an access network can.   The access network's knowledge of
that location does not give it any advantages over *any other entity
which has the location*, unless it is willing to couple its knowledge
of location with deep-packet based inspection (think of the parental
controls done via proxy in some family-oriented networks).

I'm increasingly skeptical of the value of protocol changes here.
Going down this road now seems to involve requiring trust relationships
between every ESRP/PSAP and the location-providing access networks.
We've talked about this in the past, and that just doesn't scale to
the enterprise, so there is no way this mechanism can become truly
general.  The truly general mechanism is always going to be to pass
the location through the one common relationship (with the end user),
so we'd be stuck with two systems that everyone would have to
implement.  That's all kinds of bad.

My personal opinion, of course,
                                Ted

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


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

<Prev in Thread] Current Thread [Next in Thread>