One document matched: draft-ietf-ecrit-rough-loc-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ecrit-rough-loc-01.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="ECRIT with Rough Location">Using Imprecise Location for
Emergency Context Resolution</title>
<!--add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Pkwy, Suite 400</street>
<!-- Reorder these if your country does things differently -->
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>USA</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Matt Lepinski" initials="M." surname="Lepinski">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>USA</country>
</postal>
<phone>+1 617 873 5939</phone>
<email>mlepinski@bbn.com</email>
</address>
</author>
<date month="January" year="2010" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>Emergency calling works best when precise location is available for
emergency call routing. However, there are situations in which a
location provider is unable or unwilling to provide precise location,
yet still wishes to enable subscribers to make emergency calls. This
document describes the level of location accuracy that providers must
provide to enable emergency call routing. In addition, we descibe how
emergency services and non-emergency services can be invoked by an
endpoint that does not have access to its precise location.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Information about the location of an emergency caller is a critical
input to the process of emergency call establshment. Endpoint
location is used to determine which Public Safety Answering Point (PSAP)
should be the destination of the call. (The entire emergency calling
process is described in detail in <xref
target="I-D.ietf-ecrit-framework"></xref> and <xref
target="I-D.ietf-ecrit-phonebcp"></xref>.) This process is most likely
to work properly when the endpoint is provided with the most accurate and
precise information available about its location. Using location
information with maximal precision and accuracy minimizes the chance
that a call will be mis-routed. In addition, when that location is provided to
the endpoint, the endpoint is able to verify that the location is
correct (to the extent of the endpoint's knowledge of its own location)
prior to an emergency call, and is able to perform emergency call
routing functions on its own, providing redundancy for network-provided
functions.</t>
<t>However, there may be situations in which it is not feasible for
endpoints to be provided with maximally precise and accurate location.
These cases may arise when computing precise location is an expensive or
time-consuming operation (e.g., in the case of wireless triangulation),
and location is needed quickly, as is often the case in emergency
situations. Or they may arise because the policy of a location
provider does not allow precise location to be provided to the endpoint.
While it is undesirable to use
imprecise location for emergency call routing, the possibility that
precise location may not be available to the calling device must be
accomodated in order to make emergency calling possible in the largest
possible set of circumstances.</t>
<t>This document is concerned with imprecise location only in the context of
routing emergency calls, i.e., for determining the correct PSAP to
receive a given call (e.g., via a LoST query <xref
target="RFC5222"></xref>). Depending on the the structure of the local emergency service network, the location information provided to the endpoint may also be used to route the call to an entity that is authorized to request precise location, e.g., an Emergency Services Routing Proxy. The requirements and processes described in this document are the same for both cases.
</t>
<t>Location information may also be
used in the emergency calling framework to direct the dispatch of
emergency responders. This usage is treated separately from call routing
for purposes of this document, and this document does not place
requirements on the location provided for dispatch, although it should
obviously be as precise as possible. The only provision for dispatch in
this document is a recommendation that the location provider supply
endpoints with a URI that can be used by a PSAP or other emergency
authority to obtain a different location for use in dispatch, hopefully
more precise than the one used for routing.</t>
<t>This document describes the use of imprecise location information in
the emergency call routing system. <xref target="det-section"></xref>
describes how location providers can determine the precision necessary
to support emergency call routing, and how they can use this information to optimize location delivery. <xref target="lbs-section"></xref>
describes how emergency calls are placed in such an environment, and how
non-emergency services can be invoked when precise location is not
available to the endpoint by value.</t>
</section>
<section anchor="term-section" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>We consider in this document patterns of interaction as described in
<xref target="I-D.ietf-ecrit-framework"></xref>. The two main parties of
interest are endpoints and location providers. Endpoints are hosts
connected to the Internet that originate emergency calls in the
emergency calling architecture, while location providers are entities
that supply location information that is used for emergency calling. In
addition, we will discuss how these parties interact with the LoST
mapping infrastructure <xref
target="I-D.ietf-ecrit-mapping-arch"></xref>, and with emergency and
non-emergency location-based service providers.</t>
<t>For convenience, we say that location information, either in LoST queries or in service boundaries, is provided "in geodetic form" if it is provided in the "geodetic-2d" LoST location profile, and "in civic form" if it is provided in the "civic" profile.</t>
</section>
<section anchor="det-section"
title="Determining sufficient location precision">
<t>A location provider wishing to provide location information usable
for emergency call routing requires a mechanism for determining when a
description of location (e.g., a polygon) is precise enough to be used
for emergency call routing. This mechanism might be used to decide when
to terminate a positioning process that converges over time, or to
choose a polygon larger than the known location of the endpoint (in
order to obscure the known location of the endpoint), while preserving
the utility of the location for emergency call routing.</t>
<t>There are three basic requirements for a location to be usable for
emergency call routing: <list style="numbers">
<t>The location SHOULD be sufficiently precise that a LoST request
with the location and any service URN will return a unique URI
mapping value. This may not be possible in all cases, e.g., because
of overlapping service boundaries creating areas with non-unique mappings, or because of positioning limitations that prevent sufficiently precise positioning.</t>
<t>When the location of the endpoint is known by the provider to
greater precision than is being provided, the provided location MUST
return the same mappings from LoST, for all service URNs, as the
known location.</t>
<t>When the location of the endpoint is known by the provider to
greater precision than is being provided, the provided location MUST
contain the precise location (as a geographic subset).</t>
</list>
</t>
<t>These requirements lead naturally to the idea of a "location filter".
A location filter is a collection of geographical regions satisfying the
following criteria:
<list style="numbers">
<t>For any location value that is a subset of a filter region, a LoST
request for any service will return a unique mapping result.</t>
<t>Any two locations within the same filter region receive the same
LoST results for all services</t>
</list>
Given a location filter, it is easy to determine when a given location value
is sufficiently precise, or to create a less precise version of location that
is still precise enough. Namely, a location value is precise enough when
if fits within a given filter region, and any superset of a location value
(e.g., a polygon containing a point) can be used as a less precise version of
the location value as long as it still fits within the same filter region.
</t>
<t>
For example, a simple fuzzing algorithm that maintains sufficient precision for
emergency services is to replace a given location value with the filter region
that contains it. This way, the server can compute the filter off-line (as
described below), then provision the location of each possible target by
storing a pointer to the filter region that contains the target's location.
</t>
<t>The remainder of this section discusses the concept of location filtering in more detail, and describes how a location server can construct and maintain a location filter based on information from the LoST mapping infrastructure.</t>
<section anchor="filter-use-section" title="Location filtering">
<t>With each service-to-URI mapping, a LoST query provides a service
boundary that represents the set of locations in which that mapping is
valid. A consequence of this is that given a set of service boundaries
for different services, the intersection of those service
boundaries is the region in which two mappings are valid. If one service
boundary corresponds to the area where "urn:service:sos.fire" is served by
"sip:fire@example.com" and another maps "urn:service:sos.police" to
"sip:police@example.com", then the intersection is the are where both of
these mappings are valid
("urn:service:sos.fire" maps to "sip:fire@example.com" and
"urn:service:sos.police" maps to "sip:police@example.com"). Outside
that area, one or more of the mappings is invalid. So as was suggested above,
the intersection of two service boundaries defines a set of mappings,
and any two locations within that intersection are equivalent for the
purpose of LoST mapping (i.e., emergency call routing).</t>
<figure anchor="filter-fig"
title="Generating a filter from service boundaries">
<artwork>
Service boundaries for individual services
urn:service:sos.police urn:service:sos.fire
+-------+ +-------+
| A | | C |
| +---+ | +---+---+
| | | | X | |
+---+---+ | +---+ |
| B | | D |
+-------+ +-------+
| |
| |
+-----------+------------+
|
V
+-------+
| A,C |
| +---+
| | +---+
+---+ |A,D| +---+
+---+ | |
+---+ |
| B,D |
+-------+
Resulting Location Filter Regions
</artwork>
</figure>
<t>The regions in a location filter can thus be constructed by taking
intersections of service boundaries. <xref target="filter-fig"/> shows
a simple location filter: Starting with a set of four service boundaries
for two different services. The filter that results from taking intersections
of these boundaries has three regions:
<list style="numbers">
<t>A region where police calls are directed to A and fire calls are directed to C.</t>
<t>A region where police calls are directed to A and fire calls are directed to D.</t>
<t>A region where police calls are directed to B and fire calls are directed to D.</t>
</list>
These regions satisfy the criteria for a location filter because each one
has a unique set of mappings and those mappings are valid across the entire
region. The service regions for B and C do not overlap -- there is no place where
police calls go to B and fire calls to C -- so there is no (B,C) region.
</t>
<t>More generally, a filter region is the intersection of the service boundaries
for all services available within the region. A filter can used to determine whether a
location is usable for emergency call routing in the following
way:<list style="numbers">
<t>The location SHOULD be contained in exactly one of the regions
in the filter. This guarantees that LoST mappings are unique.</t>
<t>When the precise location of the endpoint is known, the provided
location MUST be contained in the same region(s) of the filter as
the known location. This guarantees that LoST queries with the
provided location return the same results as those done with the
known location.</t>
<t>When the precise location of the endpoint is known, the provided
location MUST contain the precise location (as a geographic subset).</t>
</list>
Filter regions can be deduced constructed from LoST mappings for a sample location
by intersecting all the service boundaries for services available at that point.
<xref target="sample-fig"></xref> illustrates how the filter region containing the
point X is the intersection of the service boundaries for police and fire
services that serve X. </t>
<t>If the server also stores the lists of URN-URI mappings for each region, x
then the filter can also be used as a cache for LoST mappings; the
LoST mappings for a location are the mappings bound to the
region(s) containing it. </t>
<figure anchor="sample-fig"
title="Generating a filter region from a sample point">
<artwork>
sos.police sos.fire sos.ambulance
+-------+ +---------------+
| A | | B |
| | | | +-------+
| X | | X | | X |
+-------+ +---------------+ | |
| C |
+-------+
| | |
| | |
+-------------------+-------------------+
|
V
+-------+-------+
| A | B |
| +-------+ |
| | X | | |
+-------+-------+
| C |
+-------+
|
|
V
+---+
| X |
+---+
Resulting filter region
(police=>A, fire=>B, ambulance=>C)
</artwork>
</figure>
<t>When the location of the endpoint is known to more precision than
the location provided to the endpoint, although any location meeting
the two criteria above is equivalent to the known location for
purposes of LoST, the provided location MUST contain the known
location in order to avoid errors if the location is used for other
purposes in the course of an emergency (e.g., if the location is
provided to first responders for dispatch). This guarantee also allows
the endpoint to do some course verification that the provided location
is correct (in order to prevent very gross errors in routing).
Thus, any location that (1) contains the known location and (2)
is contained in the same filter region as the known location is
allowable. Locations that also are contained in only one filter region
are preferred. Adding randomness to the provided locations may have
privacy benefits in some cases, as discussed in the security
considerations below.</t>
</section>
<section title="Constructing location filters">
<t>For simplicity, we assume that the entity performing filtering will
only be using the filter to test locations contained within a
particular geographic "coverage area". In principle, this coverage area
could be the entire world, but assuming a more limited coverage area allows
for a filter to be built more quickly. </t>
<t>Given a coverage area and the ability
to act as a LoST client, a location service provider can autonomously compute a
location filter by constructing regions around
sample points until it has a collection of filter regions that collectively
cover its service region. (The process for an individual point is
illustrated in <xref target="sample-fig"></xref>.)</t>
<t>In order to ensure that all services boundaries are taken into account,
the server starts by issuing a <listServicesByLocation> query, and
caching the list of services that it returns, along with the corresponding
service list boundary <xref target="I-D.ietf-ecrit-lost-servicelistboundary"></xref>.
The server then samples points within that service list boundary, retrieving
mappings with service boundaries for each service in the service list and
intersecting the service boundaries to obtain a new filter region. In
pseudocode, the algorithm is as follows:</t>
<figure>
<artwork>
<![CDATA[
Set FILTER = the empty set
While filter does not cover LS coverage area
Choose a random uncovered point X in the LS coverage area
Perform a LoST <listServicesByLocation> query for X
Set SL = <serviceList> from LoST response
Set SLB = <serviceListBoundary> from LoST response
If SLB is not provided, choose new point X and re-query
If more than 100 points X have been tried
Set R = uncovered area
Add R to FILTER
END
While filter does not cover SLB
Choose a random uncovered point Y in SLB
Set R = SLB
For each service S in SL
Perform a LoST <findService> query for Y and S
Set SB = <serviceBoundary> from LoST response
If SB is not provided, return an error
Else set R = intersection( R, SB(S,Y) )
Add R to FILTER
]]>
</artwork>
</figure>
<t>If the LoST servers have been provisioned properly then this
algorithm will terminate successfully. If LoST mapping do not cover
part of the service region, then the <serviceListBoundary> will not
be returned, and the algorithm will give up after 100 queries. This
limit on queries introduces some risk that a small covered area will
be left out of the filter and marked as uncovered; if this is a concern,
then the query limit can be increased. </t>
<t>Of course, if the location server operator has information about service
boundaries through some channel other than LoST, then the LoST queries
above can be replaced by queries to a local store of mapping information.
The choice of random points can also be guided to ensure that all mapped
areas are covered even if there are some uncovered areas. The location
server can also cache service boundaries acquired during the algorithm
to avoid unnecessary LoST queries.</t>
<section title="Civic address considerations">
<t>This algorithm actually results in two filters -- one for geodetic service
boundaries and one for civic service boundaries -- since civic and geodetic
boundaries cannot be directly compared or intersected. It is RECOMMENDED that
location servers always compute a geodetic filter for use with emergency
services, since the notion of civic service boundaries have some inherent
ambiguity.</t>
<t>Indeed, the notion of intersection of civic service boundaries has
some dependence on the jurisdiction within which the service boundaries are
defined. Civic service boundaries are comprised of a set of <civicAddress>
elements, each defining a set of civic addresses that are within the boundary,
namely those that match the civic elements provided.</t>
<t>When computing the intersection of two civic service boundaries, any
<civicAddress> elements that are shared between the two service
boundaries MUST be included in the resulting intersection. When two
<civicAddress> elements in the service boundaries being compared are
different from each other, then their intersection must be computed according
to local addressing standards.</t>
<t>Note that the resulting filter regions SHOULD still cover the location
server's coverage area, i.e., there should be a filter region that contains
every civic address within the coverage area. In particular, the server
SHOULD NOT use a specific address to represent a filter region: Such an
address would not include many points in the service region (i.e., it would
not meet the third rules from the lists of rules above). If the server
creates a PIDF-LO document describing a civic address that does not
contain the precise location of the target, then it MUST set the 'method'
element of the PIDF-LO it returns to value 'area-representative' registered
in <xref target="iana-sec"></xref>. </t>
</section>
</section>
<section title="Maintaining location filters">
<t>As the LoST mappings that underlie the filter change, the filter
will need to be updated. The entity maintaining the filter MUST obtain
a new mapping for a region when an existing mapping expires. The
service boundary from the new mapping is compared to the service
boundary from the old mapping: If they are the same, then the filter
need not be updated. If they differ, then regions in the filter that
intersect either the old service boundary or the new service
boundary will need to be recomputed. Note that since this operation
only requires the server to determine if two service boundaries are
identical, the server need only store a hash of the old boundary to
which it can compare a hash of the new boundary.</t>
</section>
<section title="Applying location filters">
<t>
After constructing a location filter, a location server can use it to
optimize how it delivers location. When the location server is using a
positioning algorithm that grows more accurate with time, the filter
tells it how long to run the algorithm. Namely, the algorithm can be
terminated when the estimated location (that is, an uncertainty region
containing the target's location) is within one of the regions in the filter.
</t>
<t>
When the location provider knows the precise location of the caller, a
location filter can also be used as a "location cache". That is, the
location provider can simply look up which of the filter regions contains
the caller's precise location and return that region as the caller's
location, or some subset that contains the precise location.
</t>
<t>
This caching strategy allows an additional optimization in some cases:
If the location server knows that the caller's precise location will be
within the same region for a period of time, it can instruct the client
not to re-query in that time. For instance, if the server is delivering
location over HELD, then it can use the HTTP cache-control headers (e.g.,
Expires). However, the location server MUST NOT instruct the client to
wait for longer than the current filter is valid; the expiry time of the
location MUST be before the earliest expiry of a LoST mapping used
in the filter.
</t>
</section>
</section>
<section anchor="lbs-section" title="Requesting emergency and non-emergency services">
<t>When a location provider wishes to deliver endpoints location information that
is below its maximum available precision while still supporting emergency
calling, it MUST provide to the endpoint both a location (by value) that
is sufficient for emergency call routing (as defined above) and a location
reference (i.e., a URI) that can subsequently be used by authorized
parties to obtain more precise information about the location of the
endpoint. The endpoint then can then use both the location value and the
location reference to request emergency services and other location-based
services (LBS).</t>
<section title="Emergency calling">
<t>The overall procedure for placing an emergency call is identical to
that described in <xref target="I-D.ietf-ecrit-framework"></xref>. In
particular, the endpoint requirements in Sections 8 and 9 of <xref
target="I-D.ietf-ecrit-phonebcp"></xref> still apply to an endpoint
that receives imprecise location.</t>
<t>In addition, an endpoint that receives
location both by value and by reference from its location provider
MUST include both the location value and the location reference in the
SIP INVITE message that initiates an emergency call, as specified in
<xref target="I-D.ietf-sipcore-location-conveyance"></xref>. When the
endpoint supports LoST, it MUST use the location value to obtain a
PSAP URI for LoST queries before attempting to dereference the
location reference. Note that the caller would also have to add the "used-for-routing"
parameter to the geolocation header that points to the location value
as inserted into the INVITE message. Note that this process crucially
relies on the location value having sufficient precision for routing
emergency calls (see <xref target="det-section"></xref> for techniques
to ensure the location value is suitable for emergency call
routing).</t>
<t>When a PSAP receives a SIP INVITE that contains both a location
value and a location reference, and the value is too imprecise for use
in dispatch then the PSAP SHOULD dereference the LbyR to obtain more
precise information. In turn, the location provided by the location
provider MUST allow access by all PSAPs whose service boundaries
overlap with the region served by the location provider. This means
that either the provider must supply a reference that can be
dereferenced by any party, or else the provider must establish
explicit authentication and authorization relationships with all PSAPs
in its service area. It is RECOMMENDED that location providers establish
similar relationships with other PSAPs in adjoining jursidictions --
even if their service regions do not overlap with the location provider's
-- in case such a PSAP needs access to precise location information,
for example, if it is acting as a backup for one of the location provider's
normal PSAPs.
</t>
</section>
<section title="Non-emergency services">
<t>Non-emergency LBSs may require more precise information
than is required for emergency call routing. Therefore, when
requesting a non-emergency LBS, the endpoint SHOULD include the
location reference provided by its location provider, and MAY
additionally provide the location value. If the provided location
value is not sufficiently precise to deliver the requested service, then
the LBS provider should then dereference the location value to request
location information of sufficient precision from the location
provider. If the dereference fails, then the request for service may
fail as well.</t>
<t>Note that when the location reference provided by the location
provider is access-controled, this dereference may require a
pre-existing authentication and authorization agreement between the
LBS provider and the location provider. In such a case, the endpoint
may not know whether a given non-emergency service is authorized to
obtain the endpoint's precise location using the location reference.
The endpoint is always capable of requesting services without knowing
whether they are authorized; in this way, the endpoint can discover
authorized services by trial and error. In order to simplify this
process, a location provider may supply the endpoint with references
to authorized service providers, although there is currently no
standard protocol for this transaction.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document generalizes the concept of "rough location" that was
originally discussed in the context of the location hiding problem. This
concept was put forward by Henning Schulzrinne and Andy Newton, among
many others, in a long-running ECRIT discussion. </t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The use of imprecise location provides a security trade-off for location
providers. When location providers are required to provide location in
support of emergency services, they have to balance that requirement against
the risk that location information will be disclosed to an unauthorized party.
The use of location configuration protocols inherently introduces some risk
that an entity other than the target will be able to masquerade as the target
(e.g., another host behind the same NAT or malicious software on the host)
<xref target="I-D.ietf-geopriv-l7-lcp-ps"></xref>.
In some cases, the location provider may not authorize the target itself
to access precise location. At the same time, because endpoints can roam
between networks, it is not generally possible to have strong client
authentication for LCPs.</t>
<t>Using of rough location to support emergency calling enables a location
provider to provide low-precision location with low assurance (e.g., without
client authentication)and high-precision location with higher assurance.
Because lower-precision location generally has lower value
-- to location providers and LBS providers as a commercial asset, and to
targets as private information -- this trade-off allows a location provider
to avoid the cost of protecting location with high-assurance access controls
when this location has low value. </t>
<t>However, in order to support emergency services, location providers cannot
provide only low-precision location; they also have to provide PSAPs with
access to high-precision location information. Because PSAPs require
high-precision location for emergency response, a location provider
that normally provides imprecise location to clients MUST also provide them
a location URI that a PSAP can use to obtain high-precision location.
This constraint means that the provided URI MUST have either no
access control at all or a policy that allows access by appropriate PSAPs
and other emergency response systems, e.g., ESRPs. That is, if such a
location URI is access controlled, then the
location provider MUST be able to authenticate requests from PSAPs.</t>
<t>The use of location by reference introduces some risk that the reference
will be used by an attacker to gain unauthorized access to the target's
location. These risks are not specific to emergency service, however;
general risks and mitigations for location by reference are discussed in
<xref target="I-D.ietf-geopriv-lbyr-requirements"></xref></t>
<t>As described in <xref target="filter-use-section"></xref> above, the
location provider choosing to provide a less precise location than a
known location has a significant amount of choice in deciding which
location to provide: Any location that contains the known location and
is in the same filter region will do. When the provider is reducing
precision for privacy purposes, there is a some privacy benefit to
choosing a random location meeting these criteria. If a watcher is
interested in whether or not the endpoint is moving, an imprecise
location may still reveal that fact if it is constant when the endpoint
is at rest. If the provided location is randomized each time it is
provided, then the watcher is unable to obtain even this level of
information. An algorithm for securely fuzzing a target's location
can be found in <xref target="I-D.ietf-geopriv-policy"></xref>; for
emergency services, the additional constraint must be added that the
fuzzed location must remain in the same filter region as the original.</t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document requests that IANA register a new PIDF-LO 'method' token in the registry defined by RFC 4119 <xref target="RFC4119"></xref>
<list style="hanging">
<t hangText="area-representative:">Location chosen as a representative of a region in which the target is located; may not be the target's location.</t>
</list>
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost-servicelistboundary.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-framework.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-mapping-arch.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-l7-lcp-ps.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipcore-location-conveyance.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:23 |