Subject: [Ecrit] Location Hiding

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 7 Dec 2007 15:32:54 -0500

Now that I've had a few days to calm down after having been accused of
unethical behavior, I'd like to state that:

Location Hiding is a required for me to support (and convince my company
to support) the IETF location configuration methodology and its use in
the ecrit architecture.

For the near-term, I'm willing to accept the "coarse location" method
for civic-only.

This is because my near-term needs deal largely with civic locations:
 - cellular is handled by current cellular technology; emergency calls
over the cellular data network are not supported and not mandated at
this time
 - Wi-Fi hotspots and mesh can be handled with civic location of the
access point
 - the few places where fixed pre-WiMAX is offered will need to be
handled with static (stored by the VSP) or manual location, or through
some other method; there aren't that many, so we can perhaps have a
special solution for them, if necessary

If and when we really support emergency calls over WiMAX and/or the data
cellular connection, it is likely that we would not want to hand out
precise location values to end devices.

If this upsets some people and they go and get devices that can
completely do their own GPS location determination, then so be it.
People are free to use whatever devices they want to, that can accept a
SIM card.

But if some agency wants to place a new mandate on the wireless
provider, to provide location to be used for emergency calling over a
data connection, then we will want location hiding supported in the
wireless environment. 

If IETF doesn't want to work this case, we can probably work it in 3GPP
and the WiMAX Forum. My understanding is, it's been a known item in 3GPP
IMS for awhile -- just not a high enough priority to actually get worked
on.

If IETF does want to work it, I would like to see the following new work
items (which do not need to hold up existing work):
 - Once LoST is published, I would like to see work done to provide a
mechanism to verify if a particular URI is valid for a given service. 
 - I'd like to see a HELD extension defined that would send back LoST
response items

Barbara

*****

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

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Dec 2007 13:36:01 -0800

> - I'd like to see a HELD extension defined that would send back LoST

So I'm a bit confused about what you mean by the first, can you
clarify?

I also think that what you are asking for the second is actually
two services (held/lost) that may happen to be on the same box.
Doing  that combination in a single box is no problem; combining
the protocol interfaces may not make sense.
			regards,
				Ted

---

From: Richard Barnes <[email-masked]>
Date: Fri, 07 Dec 2007 14:00:34 -0800

Ted,

>> mechanism to verify if a particular URI is valid for a given service.

This mechanism has sometimes gone under the name "reverse LoST". 
Currently, in order to ask LoST whether a URI is a PSAP URI, you have to 
know a URN and a location to ask for in order to obtain that URI (as the 
URI for that service at that location).  "Reverse LoST" would remove the 
need for the URN+location by having an explicit request/response where 
the request contains a URI and the response contains a 
URN+serviceBoundary if the URI is known, and an error if it's not.

>> - I'd like to see a HELD extension defined that would send back LoST

In talking with James about this, we've referred to it as "tunneling 
LoST through HELD".  The major problem with location hiding is that you 
want the LoST server to have access to precise location, but not the 
user.  Tunneling LoST through HELD enables this by using the HELD server 
as a "dereferencing proxy" -- it dereferences the location, does the 
LoST query with the precise location, and returns the results.

I much prefer a "mirror image" approach, where we add location URIs as a 
location profile to LoST -- adding LbyR to LoST instead of the other way 
around.  At the cost of requiring a mechanism to discover the local LoST 
server, it maintains the greatest possible degree of separation between 
the two interfaces.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Dec 2007 17:18:25 -0500

To expand on this, there are three mechanisms that have been proposed for
location hiding:

1. Deliver coarse location to anyone but a PSAP.  No protocol changes
needed.

2. Don't ask anyone but a PSAP to dereference.  This requires two changes.
One returns the LoST response with the LCP return (HELD) so the endpoint
never needs location.  However, it also requires a reverse LoST lookup
(validate a PSAP URI) so that a VSP can validate that the call is a bona
fide emergency call

3. Allow location reference in the query to LoST, LoST can get high accuracy
location.

The arguments around these have to do with who has the burden to support
location hiding.  In the first case (coarse location), the LIS has the
burden.  Everyone else pays nothing.  James W doesn't like this, because he
wants the VSP to pay for the necessity to validate that the call is bona
fide.  In the second case, the LoST server has to support the reverse
lookup.  It requires the LIS to support the combination of HELD+LoST.  Of
course, it makes HELD the only LCP that can support location hiding, but
that may not be a problem.  The third approach puts all of the burden on the
LoST server.

Brian

> -----Original Message-----

> From: Richard Barnes [mailto:[email-masked]]

> Sent: Friday, December 07, 2007 5:01 PM

> To: Ted Hardie

> Cc: ECRIT

> Subject: Re: [Ecrit] Location Hiding

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Dec 2007 14:24:11 -0800

At 2:00 PM -0800 12/7/07, Richard Barnes wrote:
>This mechanism has sometimes gone under the name "reverse LoST". Currently, in order to ask LoST whether a URI is a PSAP URI, you have to know a URN and a location to ask for in order to obtain that URI (as the URI for that service at that location).  "Reverse LoST" would remove the need for the URN+location by having an explicit request/response where the request contains a URI and the response contains a URN+serviceBoundary if the URI is known, and an error if it's not.

I will leave it to others who deal with PSAPs to see whether they would really
be very happy about this, but I'll note that having the request be URI + service
is far more likely to give you a reasonable answer than the URI alone.  A URI
alone would force a full-scale search of all the service space to get a full result.
Even with a service urn, any answer that doesn't happen to already be in
the cache of the LoST server is going to be ugly to determine; the only way
around it being a flood is to force people to store the information that way.
That gets into jurisdictional issues fast.

>In talking with James about this, we've referred to it as "tunneling LoST through HELD".  The major problem with location hiding is that you want the LoST server to have access to precise location, but not the user.  Tunneling LoST through HELD enables this by using the HELD server as a "dereferencing proxy" -- it dereferences the location, does the LoST

This is still a 2 service approach, combining them into a single box.  In this case,
the HELD server acts as a LIS and LoST proxy. 

>query with the precise location, and returns the results.
>
>I much prefer a "mirror image" approach, where we add location URIs as a location profile to LoST -- adding LbyR to LoST instead of the other way around.  At the cost of requiring a mechanism to discover the local LoST server, it maintains the greatest possible degree of separation between the two interfaces.

I'd need to see something concrete on this, but my initial reaction is that
both tunneling and location URIs as a location profile don't make much sense.
But I may well be misunderstanding your intent, based on a misreading of the
email.
			regards,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 7 Dec 2007 18:16:24 -0600

Okay there is another problem that seems not be being talked about here.

One of the key aims of location hiding is being able to restrict who can
get access to location. And one reason that you may want to do this is
so you can charge the recipient. I am not saying that this is the only
reason.

For this to work, the Target, the thing retrieving the token (URI) that
points to their location, needs to know what can dereference the
location. To my mind this translates to a destination URI and a URN.
This is the reason that I have suggested tunnelling LoST through HELD.
The LIS knows, or can find out where the Target it. It gives the Target
a location URI set, and a set of service URNs and associated destination
URIs.

Providing a coarse location as has been suggested by simply won't work
for the majority of value added cases, or the LIS is going to have to
suck down every single service boundary for every single possible
service, intersect them, and then pass that on to the Target. This is
crazy particularly if the LIS has some 2 million or so devices hanging
off it.

Using this approach the only VSP issue is now how it determines whether
the call is really emergency or not. There is no issue with calls bound
to non-emergency service URNs. Henning and Hannes presented the solution
to this yesterday with their unauthenticated access slide. The Device
has the address of the ESRP, and a location URI, simple send it
directly. I would stress also that if we are worried about hop counters
etc, this is going to be far safer than trunking emergency signalling
around the globe, and keeps the local service local.

So when we consider this location hiding we need to consider why we are
doing, and the solution must work for final intent, which is incremental
value added services.

Cheers

James

________________________________

From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 8 December 2007 9:18 AM
To: 'Richard Barnes'; 'Ted Hardie'
Cc: 'ECRIT'
Subject: RE: [Ecrit] Location Hiding

To expand on this, there are three mechanisms that have been proposed
for location hiding:

2. Don't ask anyone but a PSAP to dereference.  This requires two
changes.  One returns the LoST response with the LCP return (HELD) so
the endpoint never needs location.  However, it also requires a reverse
LoST lookup (validate a PSAP URI) so that a VSP can validate that the
call is a bona fide emergency call

3. Allow location reference in the query to LoST, LoST can get high
accuracy location.

The arguments around these have to do with who has the burden to support
location hiding.  In the first case (coarse location), the LIS has the
burden.  Everyone else pays nothing.  James W doesn't like this, because
he wants the VSP to pay for the necessity to validate that the call is
bona fide.  In the second case, the LoST server has to support the
reverse lookup.  It requires the LIS to support the combination of
HELD+LoST.  Of course, it makes HELD the only LCP that can support
location hiding, but that may not be a problem.  The third approach puts
all of the burden on the LoST server.

Brian

> https://www1.ietf.org/mailman/listinfo/ecrit

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Dec 2007 16:32:55 -0800

At 6:16 PM -0600 12/7/07, Winterbottom, James wrote:
>One of the key aims of location hiding is being able to restrict who can get access to location. And one reason that you may want to do this is so you can charge the recipient. I am not saying that this is the only reason.

Nothing says you can't charge people for their location even if it is an emergency
call, refund the usual charge if they make an emergency call, or do something
else on the billing side to make this work (give it free twice a month, then charge
for it, as used to be the case for 411 calls).  If this is a billing problem, please be
willing to consider solving it in the billing domain. 

I think you have been given ways to solve this problem that do not induce
fragility in the overall system and require no protocol changes.  Pushing for
more seems like it is going to make the system even more fragile, without
any gain but systems simplicity in billing.

Possibly, of course, I am misunderstanding you, but that seems like the upshot
of your message.
				regards,
					Ted

>For this to work, the Target, the thing retrieving the token (URI) that points to their location, needs to know what can dereference the location. To my mind this translates to a destination URI and a URN. This is the reason that I have suggested tunnelling LoST through HELD. The LIS knows, or can find out where the Target it. It gives the Target a location URI set, and a set of service URNs and associated destination URIs.
> 
>Providing a coarse location as has been suggested by simply won't work for the majority of value added cases, or the LIS is going to have to suck down every single service boundary for every single possible service, intersect them, and then pass that on to the Target. This is crazy particularly if the LIS has some 2 million or so devices hanging off it.
> 
>Using this approach the only VSP issue is now how it determines whether the call is really emergency or not. There is no issue with calls bound to non-emergency service URNs. Henning and Hannes presented the solution to this yesterday with their unauthenticated access slide. The Device has the address of the ESRP, and a location URI, simple send it directly. I would stress also that if we are worried about hop counters etc, this is going to be far safer than trunking emergency signalling around the globe, and keeps the local service local.
> 
>So when we consider this location hiding we need to consider why we are doing, and the solution must work for final intent, which is incremental value added services.
> 
>Cheers
>James
>  
> 
>
>To expand on this, there are three mechanisms that have been proposed for location hiding:
>1. Deliver coarse location to anyone but a PSAP.  No protocol changes needed.
>2. Don't ask anyone but a PSAP to dereference.  This requires two changes.  One returns the LoST response with the LCP return (HELD) so the endpoint never needs location.  However, it also requires a reverse LoST lookup (validate a PSAP URI) so that a VSP can validate that the call is a bona fide emergency call
>3. Allow location reference in the query to LoST, LoST can get high accuracy location.
> 
>The arguments around these have to do with who has the burden to support location hiding.  In the first case (coarse location), the LIS has the burden.  Everyone else pays nothing.  James W doesn't like this, because he wants the VSP to pay for the necessity to validate that the call is bona fide.  In the second case, the LoST server has to support the reverse lookup.  It requires the LIS to support the combination of HELD+LoST.  Of course, it makes HELD the only LCP that can support location hiding, but that may not be a problem.  The third approach puts all of the burden on the LoST server.
> 
>Brian
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 7 Dec 2007 18:37:09 -0600

Ted,

I think the problems is a billing issue only at the VSP.
If charging at the VSP were not an issue I believe that the problem
largely goes away.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Saturday, 8 December 2007 11:33 AM
> To: Winterbottom, James; Brian Rosen; Richard Barnes
> Cc: ECRIT
so
> you can charge the recipient. I am not saying that this is the only
> reason.
> 
> Nothing says you can't charge people for their location even if it is
an
> emergency
> else on the billing side to make this work (give it free twice a
month,
> then charge
> fragility in the overall system and require no protocol changes.
Pushing
> for
> Possibly, of course, I am misunderstanding you, but that seems like
the
> upshot
location.
> To my mind this translates to a destination URI and a URN. This is the
> reason that I have suggested tunnelling LoST through HELD. The LIS
knows,
> or can find out where the Target it. It gives the Target a location
URI
> set, and a set of service URNs and associated destination URIs.
> >
suck
> down every single service boundary for every single possible service,
> intersect them, and then pass that on to the Target. This is crazy
> particularly if the LIS has some 2 million or so devices hanging off
it.
> the call is really emergency or not. There is no issue with calls
bound to
> non-emergency service URNs. Henning and Hannes presented the solution
to
> this yesterday with their unauthenticated access slide. The Device has
the
> address of the ESRP, and a location URI, simple send it directly. I
would
> stress also that if we are worried about hop counters etc, this is
going
> to be far safer than trunking emergency signalling around the globe,
and
> keeps the local service local.
> >
for
> changes.  One returns the LoST response with the LCP return (HELD) so
the
> endpoint never needs location.  However, it also requires a reverse
LoST
> lookup (validate a PSAP URI) so that a VSP can validate that the call
is a
> bona fide emergency call
reverse
> that may not be a problem.  The third approach puts all of the burden
on
> the LoST server.
> > > >> - Once LoST is published, I would like to see work done to
provide
> a
> > > Currently, in order to ask LoST whether a URI is a PSAP URI, you
have
> to
> > > know a URN and a location to ask for in order to obtain that URI
(as
> the
> > > URI for that service at that location).  "Reverse LoST" would
remove
> the
> > > LoST through HELD".  The major problem with location hiding is
that
> you
> > > I much prefer a "mirror image" approach, where we add location
URIs as
> a
> > > location profile to LoST -- adding LbyR to LoST instead of the
other
> way
> > > around.  At the cost of requiring a mechanism to discover the
local
> LoST
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 7 Dec 2007 23:03:18 -0500

James,
 
in-line...

  _____  

From: Winterbottom, James [mailto:[email-masked]] 
Sent: Friday, December 07, 2007 7:16 PM
To: Brian Rosen; Richard Barnes; Ted Hardie
Cc: ECRIT
Subject: RE: [Ecrit] Location Hiding

One of the key aims of location hiding is being able to restrict who can get
access to location. And one reason that you may want to do this is so you
can charge the recipient. I am not saying that this is the only reason.

For this to work, the Target, the thing retrieving the token (URI) that
points to their location, needs to know what can dereference the location.
To my mind this translates to a destination URI and a URN. This is the
reason that I have suggested tunnelling LoST through HELD. The LIS knows, or
can find out where the Target it. It gives the Target a location URI set,
and a set of service URNs and associated destination URIs.

Providing a coarse location as has been suggested by simply won't work for
the majority of value added cases, or the LIS is going to have to suck down
every single service boundary for every single possible service, intersect
them, and then pass that on to the Target. This is crazy particularly if the
LIS has some 2 million or so devices hanging off it. 

This may in fact be the burden you are proposing, but this burden is placed
on the entity desiring the cause.

-Marc-

Using this approach the only VSP issue is now how it determines whether the
call is really emergency or not. There is no issue with calls bound to
non-emergency service URNs. Henning and Hannes presented the solution to
this yesterday with their unauthenticated access slide. The Device has the
address of the ESRP, and a location URI, simple send it directly. I would
stress also that if we are worried about hop counters etc, this is going to
be far safer than trunking emergency signalling around the globe, and keeps
the local service local.

Cheers

James

  _____  

Brian

> https://www1.ietf.org/mailman/listinfo/ecrit

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