Subject: [Ecrit] Comments on location-hiding-requirements-01

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Aug 2007 15:31:57 -0500

This document does not go far enough to discourage location hiding. 
In fact, it, if nothing else, advocates location hiding as a practice 
- which I couldn't disagree with more.

If an ISP doesn't want to enable LoST, they have a right to make that 
business decision. We shouldn't promote something to a standard that 
disables desired capabilities from the rest of the IP world who want this.

I believe this effort will cause problems for the emergency calling 
public, because the ISPs that do not wish to provide sufficient 
location to endsystems will not know exactly how little location they 
can provide universally and still aid the emergency calling service. 
In fact, I read no requirement stating location of any kind is 
necessary to satisfy this "solution".  I take this to mean an ISP 
doesn't have to provide any location, and yet be in full compliance 
with this effort. I find that deeply troubling.

I find no mention of providing the UA with any location in sections 
3.1 (high level reqs) or 3.2 (detailed reqs) or 3.3 (desirable 
reqs).  So, this allows a UA to have no idea where it is (therefore 
it cannot do a LoST query), therefore it cannot know the PSAP's URI, 
therefore the INVITE to the PSAP is completely blind as to where it's 
going physically and logically. And someone thinks this is a good idea?

This document mentions it is a cost issue (to provide location), yet 
I suspect what this is, is a charge and control issue, in which the 
ISPs want to charge for providing the location to the endsystem.  I 
don't remember this being a protocol issue for non-IP systems.  Why 
is *doing it over IP* raising the barrier of entry?

nits and comments and questions

section 1.2
s/Hence, they do not to disclose.../Hence, they do not want to disclose...

section 3.1 - Req C.  What's a "bona fide URI", verses an otherwise 
valid URI?  Why does this requirements have an additional condition 
that this URI came from LoST?  Can't a PSAP URI be learned or 
hardcoded in an endpoint outside of a LoST transaction?

Section 3.2, Req-2 says "a solution...", yet the rest of 3.2 says 
"the solution", as if there is only one expected.

Section 3.2, Req-3, what does "The solution MUST offer automated 
discovery of servers ..." have to do with location hiding? Which 
servers? Which type of servers? Whose servers?  need text...

Section 3.2, Req-4, "The steps needed by the endpoint for emergency 
calling SHOULD be no different when location is withheld vs. when 
location is not withheld." Location-Conveyance already covers this 
scenario, so this req is unnecessary and confusing. That LoST cannot 
be performed to give the UA a URI as a R-URI is troubling (mentioned 
above already).

BTW - doesn't this mean the INVITE will only ever be default routed, 
since no location information is available to perform any LoST query?

In other words, I don't read any req stating "some form of location" 
MUST be sent to the UA (to perform LoST).

Section 3.2, Req-8, I'm not sure how this req is applicable, at least 
from the endsystem's pov. Therefore, delete it or add text to explain 
it better.

Section 3.2, Req-9, I'm not parsing why the word "fail" is here in 
this req, and why it's where it is in the req. Please explain

Section 3.2, Req-9, What constitutes a "...significantly increase..." 
in call set-up time?

Section 3.2, Req-12, what would this look like if accomplished?  I 
cannot envision it the way this is written.

James

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>         Title           : Location Hiding: Problem Statement and Requirements
>         Author(s)       : H. Schulzrinne, et al.
>         Filename        : 
> draft-schulzrinne-ecrit-location-hiding-requirements-01.txt
>         Pages           : 9
>         Date            : 2007-8-29
>
>The emergency services architecture developed in the IETF Emergency
>    Context Resolution with Internet Technology (ECRIT) working group
>    describes an architecture where location information is provided by
>    access networks to end points in order to determine the correct dial
>    string and information to route the call to a Public Safety Answering
>    Point (PSAP).  For determining the PSAP Uniform Resource Identifier
>    (URI) the usage of the Location-to-Service Translation (LoST)
>    Protocol is envisioned.
>
>    This document explores the architectural impact for the IETF
>    emergency services architecture for situations where the Internet
>    Access Provider (IAP) and/or the Internet Service Provider (ISP) are
>    only willing to disclose limited or no location information.
>
>    This document provides a problem statement and lists requirements.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body of
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
>username "anonymous" and a password of your e-mail address. After
>logging in, type "cd internet-drafts" and then
>"get draft-schulzrinne-ecrit-location-hiding-requirements-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE 
> /internet-drafts/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE 
>/internet-drafts/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Aug 2007 16:56:16 -0400

While I too do not want to encourage location hiding, I do think ISPs can
provide enough location to make emergency calls work.  One way to do so is
to take the boundary polygons for all the emergency services that are in the
LoST database for the actual location, intersect them, and pick any point in
the intersection.  That is a practical solution that would permit the
endpoint or calling network proxy to do a LoST query with the ("coarse")
location.

I agree the document must cover the case of a UA that does the LoST dip, as
well as the need of the calling network proxy to validate the call as an
emergency call one way or another when location is hidden.

The answer to your question is that it is the fact that we ARE requiring
location to be provided to the UA and/or the calling network that makes IP
different.  In the current PSTN, the access network provides the location
directly to the PSAP.  In the Internet, we don't do that.

Brian

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2007 4:32 PM
> To: [email-masked]'
> Subject: [Ecrit] Comments on location-hiding-requirements-01
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 29 Aug 2007 16:22:52 -0500

I don't want us to talk solutions at this time.
The solution you describe Brian is only one of them, and is not the
preferred solution by those people that are likely to build LIS
products.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 30 August 2007 6:56 AM
> To: 'James M. Polk'; [email-masked]
> Subject: RE: [Ecrit] Comments on location-hiding-requirements-01
> 
> to take the boundary polygons for all the emergency services that are
in
> the
> LoST database for the actual location, intersect them, and pick any
point
> in
> I agree the document must cover the case of a UA that does the LoST
dip,
> as
> > >    Access Provider (IAP) and/or the Internet Service Provider
(ISP)
> are
> > >You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> > >Internet-Drafts can also be obtained by e-mail.
/internet-drafts/draft-schulzrinne-ecrit-location-hiding-requirements-
> > 01.txt".
> > >         command.  To decode the response(s), you will need
"munpack"
> or
> > >         a MIME-compliant mail reader.  Different MIME-compliant
mail
> > readers
> > >         up into multiple messages), so check your local
documentation
> on

------------------------------------------------------------------------------------------------
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: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 31 Aug 2007 16:11:22 +0100

> directly to the PSAP.  In the Internet, we don't do that.

Actually, I think that the point is that in the PSTN the location is
provided *only* to genuine PSAPs - the access network provides that
(unwritten) guarantee.

I don't believe ISPs are objecting to providing location information to
PSAPs. They're objecting to providing it to any Tom, Delila, and Harry who
can look enough like a PSAP to fool the UA or who can extract the
information along the way.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 31 Aug 2007 11:26:15 -0400

Nah, the UA can't be fooled easily, especially if it does the dial string
interpretation.  The information can't easily be extracted along the way if
the bcp guidelines are followed (the location would be encrypted).

Agree that the ISP doesn't have a problem giving location to a PSAP.  

It has a problem giving it to a UA who can then use it for things other than
an emergency call.  It has the same problem giving it to the ASP who runs
the calling network.

This is not a security problem, it is an economic problem.  That doesn't
make it any less real, and we're going to have to solve it.

Brian

> From: Clive D.W. Feather [mailto:[email-masked]]
> Sent: Friday, August 31, 2007 11:11 AM
> To: Brian Rosen
> Cc: 'James M. Polk'; [email-masked]
> Subject: Re: [Ecrit] Comments on location-hiding-requirements-01
> 
> Brian Rosen said:

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 31 Aug 2007 17:00:27 -0500

Yes, but we MUST choose an implementation such that the cost of
implementing and it running doesn't exceed the revenue or costs of just
giving location away for free in the first place. 

> Sent: Saturday, 1 September 2007 1:26 AM
> To: 'Clive D.W. Feather'
> Cc: [email-masked]
> interpretation.  The information can't easily be extracted along the
way
> if
> It has a problem giving it to a UA who can then use it for things
other
> than
> > > location to be provided to the UA and/or the calling network that
> makes
> > IP
> > PSAPs. They're objecting to providing it to any Tom, Delila, and
Harry
> who
> > Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20
8495
> > 6138
> > Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870
051
> > 9937

---

From: Ted Hardie <[email-masked]>
Date: Fri, 31 Aug 2007 15:29:10 -0700

>giving location away for free in the first place.

Mind clarifying who the "we" is in the statement above?

			thanks,
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 31 Aug 2007 17:30:46 -0500

I meant the "we" in the IETF sense need to consider the potential
operational costs in any solution we propose.

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Saturday, 1 September 2007 8:29 AM
> To: Winterbottom, James; Brian Rosen; Clive D.W. Feather
> Cc: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Fri, 31 Aug 2007 15:47:57 -0700

>> >giving location away for free in the first place.

We can and should make sure that our protocols are as efficient as
possible, and that includes  a healthy sense of the operational costs
and realities of deploying them in the real world.  But that's not
a comparative.  Making the implementation of location hiding
less expensive than giving location away may well be impossible
in many deployments without artificially raising the cost of giving
it away.  And there's a naughty, naughty name for that. 

				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 31 Aug 2007 17:55:03 -0500

Perhaps less expensive is not the right term.
We must not make the deployment cost of location hiding so exorbitant
that no amount of charging for value added service can recoup the cost.

I think we also need to be very mindful of who is paying for the
location infrastructure in the first place. These are people that I am
talking about, and a solution that is best for them, the access
providers, may well not be best for further down consumers such as
net-based VSPs. I see the resolution of the problem for the VSPs as a
different problem, which may require a different solution.

Cheers
James

> Sent: Saturday, 1 September 2007 8:48 AM
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Aug 2007 19:01:09 -0400

In the (landline) PSTN, reverse directories are widely available,  
which essentially map the identifier to a location.

Also, the note below seems to assume that we're talking about  
delivering location information to random third parties. The issue is  
delivering the location information to the customer himself or  
herself, i.e., for a landline, telling the customer where they live.  
I suspect that in European jurisdictions, customers even have a legal  
right to their own personal information that is stored about them.

Also, it is untrue that this is somehow completely new with IP-based  
systems. Many cell phones, typically those using GPS or A-GPS,  
deliver location information to the customer today, for free, at any  
time. (Sprint/Boost in the US, to cite an example I'm familiar with,  
since my son has the phone.)

We certainly don't want to go through the whole hiding discussion  
again, but I'm surprised that such basic misunderstandings still  
persist after the amount of discussion we've had. This is an  
indication that the hiding document needs to more clearly define what  
is meant by the term location hiding and in particular distinguish it  
from privacy concerns.

Henning

On Aug 31, 2007, at 11:11 AM, Clive D.W. Feather wrote:

>> makes IP
> Harry who
> 8495 6138
> 051 9937