Subject: [Ecrit] An alternative proposal

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Apr 2007 13:49:50 -0400

Using LbyR to provision location raises two problems that I'd like to 
address separately:
1. Endpoint acquisition of a appropriate PSAP URI, and
2. VSP verification of a supposed PSAP URI.

Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6 apply to 
problem 2.

===== Endpoint acquisition of a appropriate PSAP URI =====
Proposal 1(a): Extend LoST to carry LbyR.
Proposal 1(b): Require that every LIS act as a LoST server for endpoints 
that it serves.

[Proposal 1(b) could be softened with "... or explicitly delegate to a 
LoST server that is authorized to dereference, e.g., with an SIP or HTTP 
3xx response"].

Scenario:
1. The endpoint uses an LCP to request location.
2. The LIS returns an LbyR.
3. The endpoint sends a LoST query to the LIS containing this LbyR.
4. The LIS does the same LoST query, but with LbyR replaced with LbyV.
5. The LIS sends the LoST response back to the endpoint.

Call flow:
Client         LIS            LoST
    |  LCP Req.  |               |
    |----------->|               |
    |    LbyR    |               |
    |<-----------|               |
    | LoST/LbyR  |               |
    |----------->|               |
    |            |   LoST/LbyV   |
    |            |-------------->|
    |            |   LoST Resp.  |
    |            |<--------------|
    | Lost Resp. |               |
    |<-----------|               |
    |            |               |

Requirements:
3. No magic configuration for UAs.
No configuration necessary beyond LIS discovery.

4. Multiple LoST server hierarchies, with resolvers that have no trust 
relationship with the PSAP or the ISP.
Depends on your semantics.  The endpoint effectively uses the LIS as a 
resolver, but beyond that there are no extraordinary trust 
relationships.  In the "rough location" proposal, the client implicitly 
trusts the LIS to LoST anyway; this just makes it explicit.

5. Minimal impact on UAs; in particular, fail-and-try-something-else is 
not acceptable.
Not sure what this means in this case.

6. Bonus points for avoiding modifications to LoST, SIP location 
conveyance, DHCP.
This only requires a small modification to LoST, so it's pretty 
straightforward, but no bonus points.

===== VSP verification of a supposed PSAP URI =====
There are two questions a VSP could ask:
1. Is this URI the URI of any PSAP?
2. Is this URI the URI of the PSAP that this UA should be calling?

Note that the first question is independent of whether location is 
carried byV or byR, and thus a much simpler mechanism could be used to 
answer it.
Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP URI as 
input and returns a service area (or even just a boolean).

Requirements:
1. No business or trust relationship between ISPs and VSPs
None required.

2. VSPs can be outside the jurisdiction of the PSAP and can be Joe's 
Bakery and Car Repair.
Anyone can do the verification, so in particular, Joe's Bakery and Car 
Repair can.

4. Multiple LoST server hierarchies, with resolvers that have no trust 
relationship with the PSAP or the ISP.
No trust relationships necessary, as no sensitive data is passed.

6. Bonus points for avoiding modifications to LoST, SIP location 
conveyance, DHCP.
I guess this one gets bonus points, but at the expense of a new protocol.

IMHO, the first question is the only reasonable one to support:
1. It is not the role of the VSP to distinguish among emergency calls; 
that's the job of the routing infrastructure.  It's entirely possible 
for this verification to fail because the endpoint has crossed into a 
neighboring PSAP coverage area, and I think we agree that the call 
shouldn't fail in this case.
2. Trying to support the second question often leads to unacceptable 
privacy consequences. The privacy risks incurred by the "rough location" 
proposal are due to the fact that it tries to answer the second 
question: Since VSPs can be (effectively) anyone, the LIS has to give 
out location to everyone in order for VSPs to be able to use location 
for this purpose.

It's tempting to say that either question could be answered by a query 
to the LoST function of the LIS, or via LoST/LbyR, with some LoST server 
authenticating itself to the LIS, but both of these introduce the same 
privacy risks as the "rough location" proposal.

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

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Apr 2007 15:23:09 -0500

this should be in a draft, to give the WG the ability to focus and 
comment on a fixed target (the contents of the ID) and not a moving 
thread that can change as often as the wind

James

At 12:49 PM 4/20/2007, Richard Barnes wrote:
>Using LbyR to provision location raises two problems that I'd like 
>to address separately:
>Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6 apply 
>to problem 2.
>
>Proposal 1(b): Require that every LIS act as a LoST server for 
>endpoints that it serves.
>
>[Proposal 1(b) could be softened with "... or explicitly delegate to 
>a LoST server that is authorized to dereference, e.g., with an SIP 
>or HTTP 3xx response"].
>
>Scenario:
>4. Multiple LoST server hierarchies, with resolvers that have no 
>trust relationship with the PSAP or the ISP.
>Depends on your semantics.  The endpoint effectively uses the LIS as 
>a resolver, but beyond that there are no extraordinary trust 
>relationships.  In the "rough location" proposal, the client 
>implicitly trusts the LIS to LoST anyway; this just makes it explicit.
>
>5. Minimal impact on UAs; in particular, fail-and-try-something-else 
>is not acceptable.
>carried byV or byR, and thus a much simpler mechanism could be used 
>to answer it.
>Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP 
>URI as input and returns a service area (or even just a boolean).
>
>Requirements:
>Anyone can do the verification, so in particular, Joe's Bakery and 
>Car Repair can.
>
>4. Multiple LoST server hierarchies, with resolvers that have no 
>trust relationship with the PSAP or the ISP.
>1. It is not the role of the VSP to distinguish among emergency 
>calls; that's the job of the routing infrastructure.  It's entirely 
>possible for this verification to fail because the endpoint has 
>crossed into a neighboring PSAP coverage area, and I think we agree 
>that the call shouldn't fail in this case.
>privacy consequences. The privacy risks incurred by the "rough 
>location" proposal are due to the fact that it tries to answer the 
>second question: Since VSPs can be (effectively) anyone, the LIS has 
>to give out location to everyone in order for VSPs to be able to use 
>location for this purpose.
>
>It's tempting to say that either question could be answered by a 
>query to the LoST function of the LIS, or via LoST/LbyR, with some 
>LoST server authenticating itself to the LIS, but both of these 
>introduce the same privacy risks as the "rough location" proposal.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 16:36:39 -0400

I'll split my response in two, since there are two problems.

> URI as input and returns a service area (or even just a boolean).

This can be done, but requires significant, non-trivial extensions to  
LoST, unlike the existing proposal summarized by Brian and Hannes. So  
far, the only concrete proposal along these lines that has more than  
handwaving behind it is to flood all PSAP URLs, at least within a  
single tree.

> I guess this one gets bonus points, but at the expense of a new  

LoST modifications are required.

> 2. Trying to support the second question often leads to  
> unacceptable privacy consequences. The privacy risks incurred by  
> the "rough location" proposal are due to the fact that it tries to  
> answer the second question: Since VSPs can be (effectively) anyone,  
> the LIS has to give out location to everyone in order for VSPs to  
> be able to use location for this purpose.

As has been stated many times before, the privacy content of the PSAP  
URL and the boundary are exactly the same. In other words, as soon as  
an emergency call reaches the VSP, the VSP can determine that the  
caller is in the coverage area of the PSAP. Nothing new here.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 16:40:28 -0400

On Apr 20, 2007, at 1:49 PM, Richard Barnes wrote:

> Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6  
> apply to problem 2.
>

This, as I've tried to explain to you numerous times, serves no purpose.

> endpoints that it serves.

This violates the requirement that LoST servers can be operated by  
multiple, independent entities.

>
> [Proposal 1(b) could be softened with "... or explicitly delegate  
> to a LoST server that is authorized to dereference, e.g., with an  
> SIP or HTTP 3xx response"].

This requires, as I've stated several times before, that LoST servers  
know about each other. They don't. If I contact the LoST server  
operated by my VSP, it has no clue about my ISP or its favored LoST  
server. Thus, this violates the 'no trust/business relationship  
between ISP and VSP' requirement and is thus disqualified.

> Depends on your semantics.  The endpoint effectively uses the LIS  
> as a resolver, but beyond that there are no extraordinary trust  
> 5. Minimal impact on UAs; in particular, fail-and-try-something- 
> else is not acceptable.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Apr 2007 12:54:28 -0400

James,

Good idea.  I've written down my perception of the problem statement and 
requirements (with some of the below analysis) in a short I-D: 
<http://tools.ietf.org/id/draft-barnes-ecrit-lbyr-reqs-00.txt>
Until it posts, a copy is attached.

--Richard

James M. Polk wrote:
>> LoST server that is authorized to dereference, e.g., with an SIP or 
>> HTTP 3xx response"].
>>
>> Scenario:
>> Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP URI 
>> as input and returns a service area (or even just a boolean).
>>
>> Requirements:
>> to the LoST function of the LIS, or via LoST/LbyR, with some LoST 
>> server authenticating itself to the LIS, but both of these introduce 
>> the same privacy risks as the "rough location" proposal.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

Network Working Group                                          R. Barnes
Internet-Draft                                          BBN Technologies
Intended status: Informational                                April 2005
Expires: October 3, 2005

     Requirements for Emergency Calling with Location by Reference
                    draft-barnes-ecrit-lbyr-reqs-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 3, 2005.

Copyright Notice

   Copyright (C) The IETF Trust (2005).

Abstract

   It is anticipated that there will be networks in which endpoints will
   not be provided their own location via a location reference that they
   cannot dereference, so that endpoints will not have access to their
   own location.  In order to ensure that emergency calling services are
   available to endpoints in such environments, it may be necessary to
   modify existing or proposed ECRIT protocols, and to recommend a high-
   level architecture in which these protocols are used together for
   emergency calling in such an environment.  This document describes

Barnes                   Expires October 3, 2005                [Page 1]

Internet-Draft          L-by-R Emergency Calling              April 2005

   the problem, lists requirements for such protocol modifications and
   architectures, and examines some privacy implications of the
   requirements.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  PSAP URI Verification & Privacy . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7

Barnes                   Expires October 3, 2005                [Page 2]

Internet-Draft          L-by-R Emergency Calling              April 2005

1.  Introduction

   As the location-provisioning functions necessary for VoIP emergency
   calling are deployed, it is anticipated that some networks will
   choose not to provision location information directly to end hosts,
   instead provisioning location references (that the endpoint may not
   be able to dereference).  (A discussion of motivations for such a
   policy is outside the scope of this document.)  On the other hand,
   several existing or candidate IETF protocols that support emergency
   calling depend on the assumption that endpoints have explicit
   knowledge of their own location.  Thus, there is some question as to
   whether existing protocols can be used to support emergency calling
   in an environment where this assumption may be false.

   For clarity, we recall here the steps for making an emergency call
   when an endpoint is provisioned with its own location:

   1.  The endpoint acquires its location via a Location Configuration
       Protocol (LCP)

   2.  The endpoint queries a Location to Service Translation (LoST)
       server with its location and a desired emergency service to
       obtain the URI of a PSAP providing that service

   3.  The endpoint sends a SIP INVITE message with that PSAP URI in the
       Request-URI field, and with its location in the body of the
       INVITE

   4.  Any proxy handling this INVITE can verify that the Request-URI in
       the INVITE is a valid PSAP by performing the same LoST query that
       the client did.

   (Note that although in this example the client performs the mapping
   operation and uses SIP, it is straightforward to adapt it to
   scenarios in which a SIP proxy performs the mapping operation (based
   on a service URN and location in the INVITE), or in which a protocol
   other than SIP is used to place the call.)

   In order to ensure support for emergency calling in environments
   where location is provisioned by reference, two problems need to be
   solved.  First, corresponding to step 2 above, there must be a
   mechanism by which the endpoint can obtain a URI for the PSAP that
   serves it.  And second, corresponding to step 4, there must be a
   mechanism by which third parties (e.g.  SIP proxies handling an
   emergency call) can verify that a URI that is claimed to be a PSAP
   URI actually is one.  (The latter problem, PSAP URI verification, is
   more general; it could arise, for example, if the location
   transmitted in a call were encrypted with the public key of a PSAP.)

Barnes                   Expires October 3, 2005                [Page 3]

Internet-Draft          L-by-R Emergency Calling              April 2005

   The most significant obstacles to solving these problems are
   authenticity and privacy.  There are four classes of entities
   involved in emergency call setup: endpoints, Internet service
   providers (ISPs, i.e., access networks), voice service providers
   (VSPs), and PSAPs.  The first three of these classes are expected to
   be so numerous, autonomous, and widely dispersed that it is
   infeasible to construct an infrastructure to authenticate them to
   each other, so solutions must not depend on such relationships.
   However, at the same time, privacy restrictions imposed by endpoints
   and ISPs must remain in force.

2.  Requirements

   Provisioning-1.  Minimal configuration: Any necessary configuration
   of UAs SHOULD be possible using existing protocols for that purpose.

   Provisioning-2.  LoST servers involved in the mapping operation
   SHOULD NOT need to have a trust relationship with either the PSAP or
   the ISP.

   Verification-1.  Trust relationships between ISPs and VSPs SHOULD NOT
   be required.

   Verification-1.  It SHOULD be possible for any VSP to verify a PSAP
   URI, in particular VSPs outside of the PSAP's jurisdiction and
   without any credential attesting to their status as a VSP.

   Common-1.  The solution(s) MUST NOT require that any participant
   disclose the location of an endpoint to an unauthorized party, even
   at the granularity of PSAP boundaries.

   Common-2.  The solutions(s) SHOULD avoid modification to existing
   protocols (e.g., LoST, SIP location conveyance, or DHCP options)

3.  PSAP URI Verification & Privacy

   There are three questions that a VSP might ask about a URI that is
   claimed to be a PSAP URI in an emergency call, each with with
   different implications for location privacy:

   1.  Is this URI the URI for a PSAP (i.e., any PSAP, anywhere)?

   2.  What is the PSAP service area for this URI (empty if it is not a
       PSAP URI)?

Barnes                   Expires October 3, 2005                [Page 4]

Internet-Draft          L-by-R Emergency Calling              April 2005

   3.  Is this URI the URI for the PSAP serving the caller?

   Answering the first question involves no sensitive location data.
   The location of the caller is irrelevant to this question, and the
   answer contains only a binary true/false value.  The second question
   does expose the location of the caller, at PSAP service-area
   granularity, by virtue of the fact that a given PSAP URI is included
   in call signaling that identifies the caller.  However, this
   correlation between PSAP and identity is only available to entities
   that participate in emergency call setup, who are required to know
   the caller's location (at that granularity) for the call to be
   properly routed.

   To answer the third question, the querier (hereafter assumed to be a
   VSP) must know the location of the caller (at PSAP service-area
   granularity) so that the proper PSAP and PSAP URI for the caller can
   be determined, and this requires that the VSP to be authorized by the
   ISP and the endpoint to have access to this location information.
   However, in order for this authorization to be made, VSPs and PSAPs
   must be able to authenticate themselves to the entity that grants
   access to location (presumably a location server operated by the
   ISP), since otherwise any host that knows or can guess the location
   reference would be able to obtain the endpoint's location.  Thus,
   answering question three while protecting the privacy of the
   endpoint's location requires that VSPs and PSAPs be able to
   authenticate to the endpoint's ISP; i.e, a system that answers
   question three cannot simultaneously comply with requirements
   Common-1 and Verification-1.

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

6.  Acknowledgements

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Barnes                   Expires October 3, 2005                [Page 5]

Internet-Draft          L-by-R Emergency Calling              April 2005

Author's Address

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy
   Columbia, Maryland  21046
   USA

   Phone: +1-410-290-6169
   Email: [email-masked]

Barnes                   Expires October 3, 2005                [Page 6]

Internet-Draft          L-by-R Emergency Calling              April 2005

Full Copyright Statement

   Copyright (C) The IETF Trust (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Barnes                   Expires October 3, 2005                [Page 7]

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Apr 2007 13:27:04 -0400

> handwaving behind it is to flood all PSAP URLs, at least within a single 
> tree.

This doesn't have to be done with LoST, if that's not convenient.  You 
could define a really tiny XML protocol to do it, or you might even be 
able to do something clever with NAPTR records in the DNS.

In any case, it's just not that big a problem.  If the U.S., with 300M 
people, has 6K PSAPs, then we're talking about a database with something 
like 120K entries to cover the whole world.  Even if it scales up two 
more orders of magnitude in the long run, that's only a little over a GB 
of data.

For that size, you could create a dedicated FG (or FG cluster) that 
could collect flooded URIs from trees and handle queries.

> URL and the boundary are exactly the same. In other words, as soon as an 
> emergency call reaches the VSP, the VSP can determine that the caller is 
> in the coverage area of the PSAP. Nothing new here.

If you're determining the location of a caller based on the fact that a 
PSAP URI is in an INVITE, you need to have both the PSAP URI and the 
INVITE.  These only get sent out to proxies involved in call setup, in 
which a certain amount of trust is vested anyway.  In effect, the VSP is 
authorized to have that information because the caller sent it to him.

On the other hand, if an unauthorized dereference returns a rough 
location, then any host that knows or can guess the reference can track 
the caller (with PSAP service-area granularity); the caller/target has 
no say.  You can't restrict this sort of dereference to VSPs since 
you've assumed that you can't authenticate VSPs.

So the novelty is that instead of revealing the caller's location to 
signaling entities, the you end up revealing it to everybody.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Apr 2007 13:38:17 -0400

> you've assumed that you can't authenticate VSPs.
How many times, and in how many ways, do we have to say this:
The security of a reference is THE SAME as the security of the value.
You cannot treat the reference with any less care than you treat the value.

Somehow, we don't seem to be able to get through to people that you can't
distribute the reference widely and expect the dereference system to control
privacy.  If you want a secure location treat the reference as if it were
the value and don't give it to anyone you don't want to have the value.

There is no such thing as an "unauthorized dereference" with respect to the
user/target.  If an entity has the reference, then you must assume they can
acquire the value.  

Brian

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Apr 2007 14:06:03 -0400

I thought we'd been through this in the LbyR design team.  There are 
requirements in draft-marshall-geopriv-lbyr-requirements-01 that say 
that location-by-reference needs to support authentication and 
authorization of both dereference clients and servers, and the 
dereference servers need to abide by privacy rules.

Even if that weren't the case, it's not enough to just say "don't hand 
out your reference to anyone you don't want to have it."   People can 
guess references so you need significant amounts of randomness in your 
references, so you can't have convenient references like 
<pres:[email-masked]>.  And you'll have to keep inventing new 
references all the time, unless you want Domino's to be able to keep 
track of you.  Expiration is a form of access control; are expiring 
references allowed?

In any case, if there's no control on dereference, then we shouldn't be 
in this thread anyway, since the endpoint can just dereference to get 
its location.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Apr 2007 15:47:04 -0400

On Apr 23, 2007, at 1:27 PM, Richard Barnes wrote:

>> This can be done, but requires significant, non-trivial extensions  
>> to LoST, unlike the existing proposal summarized by Brian and  
>> Hannes. So far, the only concrete proposal along these lines that  
>> has more than handwaving behind it is to flood all PSAP URLs, at  
>> least within a single tree.
>
> This doesn't have to be done with LoST, if that's not convenient.   
> You could define a really tiny XML protocol to do it, or you might  
> even be able to do something clever with NAPTR records in the DNS.

Concrete proposals would be most helpful. The syntax is not the  
problem (we can all whip up some XML to do this), but how global  
distribution would work. It is, as noted, yet another protocol that  
needs to be implemented, secured and deployed, for no gain.

>
> In any case, it's just not that big a problem.  If the U.S., with  
> 300M people, has 6K PSAPs, then we're talking about a database with  
> something like 120K entries to cover the whole world.  Even if it  
> scales up two more orders of magnitude in the long run, that's only  
> a little over a GB of data.
>

The data volume is not the problem, as I have pointed out in an early  
message on this thread. Getting every VSP to recognize every  
legitimate PSAP URL in a timely fashion is slightly harder, as you  
really want to avoid false negatives.

> could collect flooded URIs from trees and handle queries.

The normal query volume is relatively low, but it's another vector  
for DOS attacks. (Send calls to random URLs claiming to be emergency  
calls, every single one of which generates a query to the FG.)

>>> the "rough location" proposal are due to the fact that it tries  
>>> to answer the second question: Since VSPs can be (effectively)  
>>> anyone, the LIS has to give out location to everyone in order for  
>>> VSPs to be able to use location for this purpose.
>> As has been stated many times before, the privacy content of the  
>> PSAP URL and the boundary are exactly the same. In other words, as  
>> soon as an emergency call reaches the VSP, the VSP can determine  
>> that the caller is in the coverage area of the PSAP. Nothing new  
>> here.
>
> If you're determining the location of a caller based on the fact  
> that a PSAP URI is in an INVITE, you need to have both the PSAP URI  
> and the INVITE.  These only get sent out to proxies involved in  
> call setup, in which a certain amount of trust is vested anyway.   
> In effect, the VSP is authorized to have that information because  
> the caller sent it to him.
>
> location, then any host that knows or can guess the reference can  
> track the caller (with PSAP service-area granularity); the caller/ 
> target has no say.  You can't restrict this sort of dereference to  
> VSPs since you've assumed that you can't authenticate VSPs.
>
> So the novelty is that instead of revealing the caller's location  
> to signaling entities, the you end up revealing it to everybody.

I'm confused. It's not revealed to everybody, just to everybody who  
has access to the LbyR. If the call is protected by TLS, that would  
only be the signaling entities. If not, it is only the entities that  
can physically intercept the call. As Brian has pointed out,  
references are cryptographically-random. If they are not, it doesn't  
really matter, either. Say, an ISP returns

http://lis.isp.net/psap1
http://lis.isp.net/psap2
...

which return the polygons and service URLs for PSAP1, PSAP2, etc.  
These can be published on a web page - all they reveal to anybody  
querying is the URL of PSAP1 and its service boundary, which we  
assume to be public information. Thus, in this particular instance,  
the reference doesn't even have to be random. (Obviously, this  
wouldn't work for the fine-grained resolution, but the information  
that's public is exactly the same.)

---

From: Richard Barnes <[email-masked]>
Date: Tue, 24 Apr 2007 15:52:41 -0400

~trimmed to contain message length~

> Concrete proposals would be most helpful. The syntax is not the problem 
> (we can all whip up some XML to do this), but how global distribution 
> would work. It is, as noted, yet another protocol that needs to be 
> implemented, secured and deployed, for no gain.

How about this:
1. Whip up some XML to do the queries as part of LoST
2. Create a set of FGs to store PSAP URIs (possibly with their coverage
areas).  This set can be large and distributed for fault-tolerance.
3. These FGs peer with as many tree roots as possible; each tree sends
its PSAP URIs (+coverage) to the FG, and the FGs share with each other.
  Note that this doesn't have to be done using LoST -- it could be an
extension to LoST-sync, or just rsync on a flat list of URIs.
4. Any "Reverse LoST" queries go to one of these FGs

> The normal query volume is relatively low, but it's another vector for 
> DOS attacks. (Send calls to random URLs claiming to be emergency calls, 
> every single one of which generates a query to the FG.)

The total query volume will probably be significantly smaller than the
volume of regular LoST queries, since endpoints query LoST peridically,
while VSPs would only query at emergency call time.  In any case, you
can address this by clustering FGs.

> I'm confused. It's not revealed to everybody, just to everybody who has 
> access to the LbyR. If the call is protected by TLS, that would only be 
> the signaling entities. If not, it is only the entities that can 
> physically intercept the call.

This is only true if the references are in fact cryptographically 
random.  This would have to be specified.

You also have to address the issue of people accessing the reference 
after the fact.  I thought that one requirement was that even the PSAP 
shouldn't have access to the callers location forever, but it seems like 
this proposal would give it to him, at least for the lifetime of the 
reference.

So even though you adopted LbyR so you wouldn't have to constantly push 
LbyV to the client, you end up having to push expiring, 
cryptographically random references.

> If they are not, it doesn't really matter, 
> either. Say, an ISP returns
> 
> http://lis.isp.net/psap1
> http://lis.isp.net/psap2

If you're going to do that, then you might as well just hand out LbyV 
with coarse resolution.  The point of LbyR is to provide a mechanism 
that (1) gives the user's current location, and (2) has access controls.

--Richard