Subject: [Ecrit] Location Hiding: Let's Make some Progress

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 02 Jun 2007 11:02:12 +0200

Hi all,

we have had many discussions about this topic but we did not come to a 
conclusion.

At the end it seems to me that we have focused on a small number of 
potential solutions. They are listed at this Wiki page:
http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding

To restart the discussion Henning and myself have written a short draft 
about solution#3:
http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt

Solution#1 does not require too many extensions, only a new location 
profile in LoST to support polygons (from an extension point of view).

We intentially did not publish the above-mentioned draft for the 
following reasons:
* Many working group members have very actively contributed to the 
discussions and it would be unfair to publish the document with our 
names on it only.
* There are many solutions and many variations of the solutions 
possible. We would like to avoid 15+ draft submissions to the working 
group since this would only slow down the progress.

There is potentially an impact for LoST. Hence, it prevents us from 
finishing LoST.

 From a procedural point of view we can do two things:

(1) Finish LoST as is and add potential extensions later.
(2) Wait for the conclusion of the discussion on location hiding, 
potentially update LoST

Today, I personally would lean towards (1) given that more discussions 
are necessary.

I would, however, like to understand what other people think.

I would also like to know what the solution preferences are.

Ciao
Hannes

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 2 Jun 2007 06:28:20 -0500

I personally think that these two discussions are mutually exclusive,
with one problem residing in the geopriv space and the other in ecrit.

What an end-point needs to route is a service URN, a local dial string
and/or PSAP URI. Location is a means to an end. That is, it allows
discovery the URI. If the URI is provided, then location isn't required
by the end-point. ECRIT's charter is to route calls to a PSAP. Providing
the end-point can do that ecrit should be happy.

How an end-point learns location is geopriv space. The blur seems to
occur around what happens if the location provider won't provide
location directly to the end-point. 

Having read the draft below, it suggest that changes to LoST are
required if location is not provided to end-points. This is not
necessarily true. It is true certainly under certain business models,
but not true under others. Let us also be clear, location hiding is the
prerogative of the location provider, and providing the end-point is
able to route an emergency call the location provider's obligation is
met. Changes to LoST are ONLY required, IF the voice service provide
requires proof that the call is to an emergency URI. If this is not the
case, then NO CHANGES to LoST are required. This draft does not point
this out. In fact it does not even consider it.

The issue of destination URI based on location, and the issue of
destination URI and service are totally orthogonal and that neither are
directly in the realm of ECRIT.

If a location provider elects to provide a list of location URIs, a
service URNs and corresponding service URIs, and possibly dial strings,
then this is sufficient for the end-point to launch an emergency call.
So it is a valid solution that requires no changes to LoST.

I think that the location hiding case has several ways to skin the cat,
and I do not thing that supporting both solution 1 and 3 from an
end-point position is hard. On the other hand restricting location
providers to solution 1 only I think will make location hiding difficult
and expensive to provide, which will result in very non-consistent ways
of implementing it.

Cheers
James 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Saturday, 2 June 2007 7:02 PM
> To: ECRIT
> Subject: [Ecrit] Location Hiding: Let's Make some Progress
> 
> Hi all,
> 
http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHidin
g
> To restart the discussion Henning and myself have written a short
draft
http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/dra
ft
> -schulzrinne-ecrit-lost-in-held-00.txt
> 

------------------------------------------------------------------------------------------------
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: Hannes Tschofenig <[email-masked]>
Date: Sat, 02 Jun 2007 14:14:24 +0200

Hi James,

> with one problem residing in the geopriv space and the other in ecrit.
Which two discussions?

> and/or PSAP URI.

It depends on the architecture whether this is true.

>  Location is a means to an end.

That's not quite right since location is used in multiple places for the 
emergency services architecture. This again depends on the architecture.

>  That is, it allows
> by the end-point.
That's true.

>  ECRIT's charter is to route calls to a PSAP. Providing

You understand that the entire story is a bit more complicated.

> location directly to the end-point. 
We all know that the boundary between different working groups regarding 
this subject is fuzzy.
No problem

> required if location is not provided to end-points.
No. That's not true.

>  This is not
> requires proof that the call is to an emergency URI.
There are no changes required in that case either. The VSP could use 
imprecise location information and use it as input to LoST

>  If this is not the
I believe it does and we discussed this aspect already on the mailing list.
Changes are required if we implement a reverse resolution mechanism into 
LoST. Nobody wanted todo that.

> So it is a valid solution that requires no changes to LoST.
Why does it provide a list of location URIs?

Still, this does not provide the entire picture since the VSP still has 
to ensure that this is really a PSAP URI.;

> end-point position is hard.
Having more solutions in an emergency case is not a great thing.

>  On the other hand restricting location
I wonder why this is the case.

Ciao
Hannes

>> To restart the discussion Henning and myself have written a short
>>     
> draft
>   
>> about solution#3:
>>
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 02 Jun 2007 17:29:11 +0200

Hi James,

I have to respond to you again about the architectural aspects.

I think it is fair to say that a solution needs to consider the case 
where the VSP wants to verify whether the emergency call is indeed 
traveling towards a PSAP or not. Additionally, the VSP can never be sure 
whether all end hosts are able to obtain the PSAP URI (for whatever 
reason). For the case where the ISP/ASP is not the same as the VSP then 
all they have to assume is that they get location information in some 
form, either an LbyR or an LbyV.

So, given this the VSP has to run LoST and there has to be a LoST 
mapping infrastructure otherwise the IETF ECRIT emergency service 
architecture just does not work.

The end host might run LoST. If it does so, then there are benefits 
since the resolution step can be done ahead of time before the actual 
emergency call starts.

With respect to the message exchanges shown in Figure 1 of 
http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt
a few variations are possible but they do not change the entire picture 
a lot.

For example, it is possible that the LCS provides LbyR and LbyV whereby 
the LbyV can only be used for routing. In that case the VSP does not 
need to get in contact with the ISP/ASP.

It might also be possible that the VSP does not do the LoST verification 
step (for whatever reason). Step (4) could in that case omitted.

If you additionally consider Figure 2 of the draft than you can have end 
hosts that do not need to obtain location information nor need to 
perform LoST queries. In fact that architecture even allows you to move 
all these functions into the ISP/ASP/VSP operators network and a 
standardized protocol for these interactions may not be needed.

Was that description helpful?

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 02 Jun 2007 15:53:56 -0500

>(1) Finish LoST as is and add potential extensions later.

Let's PLEASE finish LoST, and have location hiding left for a future 
extension - if there is WG consensus.  This offers a very pragmatic 
(and realistic) approach in a number of ways:

#1 - It finishes LoST

#2 - see #1

(just kidding.  well... not really  ;-)

#3 - It prevents someone in the future from stating in an RFP (most 
of us know that is, right?) that supporting LoST mandates support for 
Location Hiding.  This will not be necessary in all cases. Some of us 
don't think it will be that popular in time; however, it could 
be.  Allowing Location Hiding to the sole topic of a new ID (and 
eventually an RFC) gives the industry a singular pointer to vendors 
and SPs to support, without the ability to say they support "LoST" 
(even though they don't do the hiding part of that RFC (to-be)).

#4 - #3 cannot be under-emphasized.  An RFP stating full support for 
Location Hiding (for example, it's RFC 5201), cannot then be avoided, 
or fudged really.  But stating full support for LoST (for example, 
RFC 5010) could have implementations do everything within the RFC 
except for the Hiding part.  Don't laugh or smirk... this happens ALL 
THE TIME...

Location Hiding, IMO, is a unique idea within ECRIT, therefore it 
should be it's own RFC - with no other unique ideas.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 2 Jun 2007 19:34:15 -0500

Hi James,

The only thing I want in ECRIT to do with location hiding is for
phone-bcp to say that if the end-point gets give location URIs (one or
more), is given service URN to URI mappings that it can just send to
those. I see no need to change LoST at this time, and possibly no tin
the future either.

The only case I have heard for changing LoST is so that a VSP somewhere
can check whether to bill for a call or not. I don't think this is
required for iteration one of LoST and may never be required.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Sunday, 3 June 2007 6:54 AM
> To: Hannes Tschofenig; ECRIT
> Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 3 Jun 2007 21:15:32 -0500

Hi Hannes,

Please see responses inline:

> Sent: Saturday, 2 June 2007 10:14 PM
> To: Winterbottom, James
> Cc: ECRIT
[AJW] There are two clear and distinct parts to solution 3. The first
part consists of the end-point being able to obtain location URIs,
service URNs and their corresponding service URIs, and possibly matching
dial strings. This functionality is required to enable the end-point to
make an emergency call.

The second quite different part is to do with how a VSP, no matter where
it is, is able to tell that the call is destined for emergency services
URI. And this, as far as I can tell is done ONLY so that the VSP won't
bill for the call. It is only this part that has bearing in ECRIT, how
an end-point obtains LI is out of scope for ECRIT.

> It depends on the architecture whether this is true.

[AJW] The end-point needs to have something to send the call to, either
a URI or a dial string. Presumably also the persona making the call
knows that they want a specific service, even if they don't know how
that specific service defined under the covers. 

> emergency services architecture. This again depends on the
architecture.

[AJW] My comment here is that location is that means by which an
end-point gets the service/help they want. In and to itself, location is
not what the end-point wants.
 
> You understand that the entire story is a bit more complicated.

[AJW] I do, but I want the scopes kept clear. If ECRIT needs work added
to Georpiv then I would prefer that it does that, rather than expanding
the ECRIT scope. If location providers don't provide a literal location
(obscured or otherwise) to the end-point, and this impacts ECRIT, then
ECRIT need to ask georpiv to address this issue.
 
> We all know that the boundary between different working groups
regarding

[AJW] See previous comment, I think that it can be unfuzzed a bit.
 
> LoST. Nobody wanted todo that.

[AJW] My point is that we only have to do this if the VSP billing is an
issue. Looking at two prominent Internet VSPs this to me seems like a
ridiculous requirement. Many of these are providing international call
rates of like 1 cent per minute for between $17 and $25 a month, with
free national calls, and some international calls also free. I think
that this billing issue is almost not an issue, and so I see little need
for the proposed changes to LoST, making the problem totally in the
location acquisition space.

> Why does it provide a list of location URIs?

[AJW] It provides a list of location URIs as the LIS may support more
than one URI scheme for dereferencing. See
http://tools.ietf.org/html/draft-winterbottom-http-location-delivery-05
section 5.10.1

> to ensure that this is really a PSAP URI.;
[AJW] Only for billing purposes. There are several other ways to skin
this cat. The first is to just bill anyway, at 1c a minute I am not
really going to care if I am bleeding on the floor, and if I care later
I can debate the charge with my VSP. The second is for the VSP to simply
charge a single flat monthly fee rather than have any per-call charging.
There are probably several others that can be thought up by more
creative minds in this area than my own.

> Having more solutions in an emergency case is not a great thing.
[AJW] I generally agree, though this solution is actually very simple.

> I wonder why this is the case.

[AJW] I seriously think that you need to look at what solution 1 is
proposing from a deployment standpoint. We are not talking about small
systems with say a couple of thousand users, we are talking single
systems with several million users. Requiring polygon boundary mappings
per location request is going to be very expensive. I simply don't
believe that a civic solution is even possible (community name won't
work in a huge many places) in many cases.

[AJW] My proposal to move this forward would be:
1) Leave LoST as it is.
2) Adapt Phone BCP to say something along the lines of if the end-point
is provided location URIs and routing data, send the call. A motherhood
statement to the effect that it should request updated information at
call time is fine.
3) Ask Geopriv to pick up the extra piece required in HELD.

> >> I would also like to know what the solution preferences are.
------------------------------------------------------------------------
> ------------------------
------------------------------------------------------------------------
> ------------------------

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 3 Jun 2007 22:29:29 -0400

Solution 1 does not require changing anything in LoST, but needs some "BCP"
words.

Solution 3 doesn't require a change in LoST, but does require "changes" in
LCP.

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Saturday, June 02, 2007 8:34 PM
> To: James M. Polk; Hannes Tschofenig; ECRIT
> Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress
> 
> Hi James,
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 3 Jun 2007 22:20:41 -0500

Please see my not below with regards the operational cost so solution 1.
They will be almost prohibitive!

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, 4 June 2007 12:29 PM
> To: Winterbottom, James; 'James M. Polk'; 'Hannes Tschofenig'; 'ECRIT'
> --
> > ----------------------
> --
> > ----------------------

---

From: Andrew Newton <[email-masked]>
Date: Sun, 3 Jun 2007 23:31:21 -0400

> Solution 1 does not require changing anything in LoST, but needs  

Actually, it does.  But as Henning pointed out, it is a change that  
was requested for other reasons as well.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 09:37:04 -0400

On Jun 2, 2007, at 5:02 AM, Hannes Tschofenig wrote:
> draft about solution#3:
> http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/ 
> LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt

Interesting... you have taken bits of ideas from various parts of  
these discussions and come up with a good proposal.  I appreciate the  
collaborative spirit you and Henning have shown here.

I like this approach.  Here are my comments:

1) One point of the ECRIT architecture is not covered, and that is  
getting LoST information at call time.  The could be done via an  
update from/to the LCS.

2) Perhaps this draft could be made general to all LCPs instead of  
just HELD, or at-least to all XML carrying LCPs.  Even DHCP might be  
able to carry this information in a binary form of XML (perhaps).  To  
do this, maybe a _short_ list of LCP protocol requirements should be  
stated.  Something like this (just a strawman, I'm not wed to it):

    For an LCP to LoST compliant/capable, it must support the  
following protocol interactions between an LCP server and LCP client:
      a) clients MUST be able to assert the service URNs of the  
services they need.
      b) clients MUST be able to refresh their LoST mapping data.
      c) clients MUST be able to obtain a list of LoST service URNs  
that are available.

3) I agree with section 6.  In fact, I'm fairly confident you will  
never need to do this.  Just use the LoST schema.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 10:02:36 -0400

> location acquisition space.

James,

I'm willing to brush aside this requirement if you are willing to pay  
for all the fraudulent calls the occur while this system is  
deployed.  You'll find out real fast how much 1 cent per minute  
costs.  :)

Fraud does occur in VoIP and there are truly people attempting to  
game VSPs.  I see it every day.  And much like a traditional telco,  
we allow disconnected/cancelled customers to make outbound 9-1-1 calls.

There does need to be some means of detecting fraud.  It does not  
have to be realtime and it does not have to be perfect, but it does  
have to be effective.

-andy

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 05 Jun 2007 16:25:31 +0200

Hi Andy,

> collaborative spirit you and Henning have shown here.
Good to hear something nice

> I like this approach.
You like the approach of summarizing the discussion or the idea of 
carrying LoST responses in HELD?

>   Here are my comments:
True. The protocol has to support a way to re-query and to support 
mobility.
Without a service boundary (or a notification mechanism) the client has 
to guess when he moves outside the boundary.
That's certainly a weakness of the mechanism. On the other hand that's 
already a weakness of the LbyR without the concept of a subscription.
>    For an LCP to LoST compliant/capable, it must support the following 
> protocol interactions between an LCP server and LCP client:
Sounds quite reasonable to me.

> never need to do this.  Just use the LoST schema.
But I think you need to profile it. For example: While you need the 
content of the mapping you the usage of the service boundary is not 
required if you only use it with LbyR.
Do you envision that HELD is piggy-backing the entire LoST exhanges? 
Probably that would not be a bad idea.
Furthermore, there is also the question whether you send a single 
request at once or multiple requests at the same time.

Here are some more thoughts:

Service Boundary: The LCP may decide not to return a service boundary. 
That's possible with the current LoST version.

Recursive Attribute: The default points to false. The client can change 
it to whatever it likes best.

Hence, a minimal version of the findService request attached to a LCP 
message would be something like:
(obviously you would have to omit the location info).

<findService xmlns="urn:ietf:params:xml:ns:lost1">
  <service>urn:service:sos.police</service>
</findService>

Requesting information about more than one service is not possible in 
LoST but it is certainly possible to enhance LoST, if necessary.

For example: Something like the example below could return multiple LoST 
mappings for services provided by the local network.
<findService xmlns="urn:ietf:params:xml:ns:lost1">
  <service>urn:service:sos*</service>
</findService>
These are, however, optimizations and potentially subject for a separate 
discussion.

In a response the following details are useful:

<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
  xmlns:p2="http://www.opengis.net/gml">
  <mapping
    expires="2007-01-01T01:44:33Z"
    lastUpdated="2006-11-01T01:00:00Z"
    source="authoritative.example"
    sourceId="7e3f40b098c711dbb6060800200c9a66">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <uri>sip:[email-masked]</uri>
    <uri>xmpp:[email-masked]</uri>
    <serviceNumber>911</serviceNumber>
  </mapping>
  <path>
    <via source="authoritative.example"/>
    <via source="resolver.example"/>
  </path>
</findServiceResponse>

The serviceBoundary is omitted and that is legal with the current LoST 
schema.

What do you think about that?

Ciao
Hannes

---

From: Andrew Newton <[email-masked]>
Date: Tue, 5 Jun 2007 11:14:30 -0400

> carrying LoST responses in HELD?

Both, though I was focusing on the latter.

> required if you only use it with LbyR.

Redacting information from a LoST message is already possible without  
defining an entirely new schema.  The problem with going down the new  
schema road is that it makes protocol and system maintenance a pain.   
When we come out with LoST v2, we'll have to go rev this other schema  
as well, etc....

> Do you envision that HELD is piggy-backing the entire LoST  
> exhanges? Probably that would not be a bad idea.
> Service Boundary: The LCP may decide not to return a service  
> boundary. That's possible with the current LoST version.
>
> Recursive Attribute: The default points to false. The client can  
> change it to whatever it likes best.
>
> Hence, a minimal version of the findService request attached to a  
> LCP message would be something like:
> Requesting information about more than one service is not possible  
> in LoST but it is certainly possible to enhance LoST, if necessary.
>
> For example: Something like the example below could return multiple  
> LoST mappings for services provided by the local network.
> These are, however, optimizations and potentially subject for a  
> separate discussion.
>
> The serviceBoundary is omitted and that is legal with the current  
> LoST schema.
>

It's all possible.  Of course, taking this to its logical conclusion,  
an easier approach would be to just tunnel LoST through the LCP.  But  
once you have done that, you gotta ask why they are not just running  
a LoST server and using the LCP to point to it.  One possible answer  
is that there is a state issue between the LCP and LoST sessions.   
But we may be able to fix that with some fancy foot work in LoST.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 5 Jun 2007 13:58:57 -0400

> Without a service boundary (or a notification mechanism) the client  
> has to guess when he moves outside the boundary.
> That's certainly a weakness of the mechanism. On the other hand  
> that's already a weakness of the LbyR without the concept of a  
> subscription.
>>

Most of the discussion has been on fixed (DSL) infrastructure. Once  
you get into notification of changes in PSAP URL list, you have then  
successfully duplicated the SIP configuration work that is being  
completed in SIPPING. That working group might be interested in this  
competing effort.

Henning