One document matched: draft-barnes-ecrit-rough-loc-00.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="yes"?>
<!-- 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="exp" docName="draft-barnes-ecrit-rough-loc-00.txt"
ipr="full3978">
<!-- 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="February" year="2008" />
<!-- 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, in that 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><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
precise information available about its location. Using location
information with maximal precision and accuracy minimizes the chance
that a call will be mis-routed. And 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 the location
provider does not allow precise location to be provided to the endpoint
(e.g. due to privacy considerations). 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 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="I.D-ietf-ecrit-lost"></xref>). 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. <xref target="lbs-section"></xref>
describes how emergency calls are placed in such an environment, and how
non-emergency service 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>
</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 mechanism 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 in either
case.</t>
<t>There are two base requirements for a location to be usable for
emergency services: <list style="numbers">
<t>The location SHOULD be sufficiently precise that a LoST request
with the location and any service URN will return a single URI
mapping value. This may not be possible in all cases, e.g., because
of overlapping service boundaries (leading to areas that do not have
a unique mapping) or positioning limitations (leading to
insufficient precision).</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>
</list>In this section, we describe how to use a "location filter" to
determine whether a given location is usable for emergency call routing,
and how to construct and maintain such a filter.</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 difference services (say, one mapping "urn:service:sos.fire" to
"sip:fire@example.com" and one mapping "urn:service:sos.police" to
"sip:police@example.com"), the intersection of those service
boundaries is the region in which two 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. Said differently,
any region contained in an intersection uniquely determines mappings
for the services used in the intersection, and any two locations
within the same intersection are equivalent for the purpose of LoST
mapping (i.e., emergency call routing).</t>
<t>A location filter is thus a set of regions (optionally, each region
may be assigned a list of (service URN, service URI) pairs). Each
region is the intersection of the service boundaries for all services
available within the region, and the lists represent the mappings that
are valid within that region. A filter is used to determine whether a
location is useable 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 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>
</list>When the regions are bound to lists of URN-URI mappings, the
resulting filter can also be used as a cache for LoST mappings; the
LoST mappings for a location are the URN-URI pairs bound to the
region(s) containing it.</t>
<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 it is within the
provided location (in order to prevent very gross errors in routing).
Nonetheless, any location that (1) contains the known location and (2)
is contained in the same filter region as the known location is
allowable. 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 and maintaining 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". Given a coverage area, server
operated by a location service provider can autonomously compute a
location filter using the following algorithm:</t>
<t>First, the server must obtain mappings for all services and for all
points within the coverage area. When the server uses a LoST server
that is configured to return all mappings for the indicated location,
mapping information for the coverage area can be obtained using a LoST
findService query of the following form:</t>
<t><?xml version="1.0" encoding="UTF-8"?> <findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value">
<location id="6020688f1ce1896d" profile="geodetic-2d"> <!--
Coverage Area --> </location> </findService></t>
<t>When LoST is not configured to return all possible matches (or when
the above query would return more results than the LoST server is
willing to transmit), the server must obtain mapping information for
each service independently by sampling at points within the coverage
area. It must continue sampling until for each service, the union of
the service boundaries covers the coverage area. If the server is
unable to obtain a set of service areas that covers the coverage area
for a particular service, it MUST verify that the service is
unavailable in the uncovered area by performing LoST
listServicesByLocation queries within the uncovered area and verifying
that the service is not in the returned list of available services.
Note that this procedure for obtaining mappings is much less reliable
than allowing LoST to do the decomposition into service boundaries,
since a LoST client cannot establish definitively that a service is
not available throughout an un-covered area (it may be available at
some un-sampled point).</t>
<t>The regions in the location filter are computed by means of URI
tuples: For each service URN, let uris(urn) be the set of PSAP URIs
for that service URN (collected from the mappings). The set of URI
tuples is then the cartesian product of these sets; if the set of
servuce URNs is {urn1,...,urnN}, then the set of URI-tuples is
uris(urn1) x ... x uris(urnN). The server computes the regions in the
filter by iterating through the set of URI tuples, either by
constructing the set of URI tuples and directly iterating, or by using
nested iteration through all the sets uris(urn).</t>
<t>For each URI tuple, the server compute the intersection of the
service boundaries for the URIs in the tuple. This becomes an entry in
the location filter: The stored region is the intersection of the
service boundaries, and the corresponding mapping table is the list of
(URN, URI) pairs, where the URIs are the URIs from the tuple and the
URNs are the services used to obtain them from LoST.</t>
<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
are contained in 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>
<t></t>
</section>
<section anchor="lbs-section" title="Requesting location-based services">
<t>When a location provider deliver endpoints location information that
is below its maximum feasible precision while still supporting emergency
calling, it MUST provide to the endpoint both a location (by value) that
is sufficient for emergency call routing (see 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 location-based services (LBS) as described
below.</t>
<section title="Emergency calling">
<t>The procedure for placing an emergency call is indentical 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 imprise location.</t>
<t>In addition, it should be emphasized that 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-sip-location-conveyance"></xref>. When the
endpoint supports LoST, it SHOULD use the location value to obtain a
PSAP URI for LoST queries (as opposed to attempting to dereference the
location reference) (thus, it would also 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, if 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 PSAP
in its service area.</t>
</section>
<section title="Non-emergency services">
<t>Non-emergency LBSs will generally 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 sufficient 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>One reason for an LIS to provide location information below its
maximum precision is to protect the privacy of the target. Some location
provisioning protocols do not enable the location provider to obtain
strong assurance of the identity of the location recipient; in
particular, the location provider may be unable to verify that the
recipient is the target of the location being provided. Therefore, there
is a risk that a sufisticated attacker might be able to spoof the
identifier (e.g. IP address) used by the location provider to identify
the target, and obtain the target's location in this way. One way to
mitigate this risk is to provide only imprecise location information to
the end-point (without authentication), and to provide precise
information only to trusted entities that can authenticate themselves to
the location provider. Additionally, in some deployment scenarios,
location providers have concerns about the comprimise of endpoint
devices. Providing only imprecise location to the endpoint, prevents
malware on a comprised device from obtaining the precise location of the
target.</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 signficant 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.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<reference anchor="I.D-ietf-ecrit-framework">
<front>
<title>Framework for Emergency Calling using Internet
Multimedia</title>
<author fullname="Brian Rosen" initials="B." surname="Rosen">
<organization></organization>
</author>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>S</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="James Polk" initials="J." surname="Polk">
<organization>P</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Andrew Newton" initials="A." surname="Newton">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="September" year="2007" />
</front>
</reference>
<reference anchor="I.D-ietf-ecrit-phonebcp">
<front>
<title>Best Current Practice for Communications Services in support
of Emergency Calling</title>
<author fullname="Brian Rosen" initials="B." surname="Rosen">
<organization></organization>
</author>
<author fullname="James Polk" initials="J." surname="Polk">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="September" year="2007" />
</front>
</reference>
<reference anchor="I.D-ietf-ecrit-lost">
<front>
<title>LoST: A Location-to-Service Translation Protocol</title>
<author fullname="Ted Hardie" initials="T." surname="Hardie">
<organization></organization>
</author>
<author fullname="Andrew Newton" initials="A." surname="Newton">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H."
surname="Tschofenig">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="September" year="2007" />
</front>
</reference>
<reference anchor="I.D-ietf-sip-location-conveyance">
<front>
<title>Location Conveyance for the Session Initiation
Protocol</title>
<author fullname="James Polk" initials="J." surname="Polk">
<organization></organization>
</author>
<author fullname="Brian Rosen" initials="B." surname="Rosen">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="July" year="2007" />
</front>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author fullname="Scott Bradner" initials="S" surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="I.D-ietf-ecrit-mapping-arch">
<front>
<title>Location-to-URI Mapping Architecture and Framework</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<date month="September" year="2007" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:45:51 |