One document matched: draft-barnes-ecrit-auth-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="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="info" docName="draft-barnes-ecrit-auth-01" 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="draft-barnes-ecrit-auth-01">Fraud mitigation for IP-based
emergency calling</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="October" year="2007" />
<!-- 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>The use of Internet technologies for emergency calling creates
opportunities for fraud, relative to traditional circuit-switched
emergency calling. This document describes the context for IP-based
emergency calling, and the types of fraud which are possible within the
system. A mitigation strategy for fraud against voice service providers
is described; techniques for detecting or preventing other types of
fraud will be incorporated in this document as they are available.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Entities that participate in emergency calling (e.g., callers, voice
networks, or emergency authorities) expose themselves to abuse by
fraudulent parties. For example, when voice networks provide special
service such as priority or preemption to emergency calls, fraudulent
callers could mark non-emergency calls as emergency calls in order to
receive special treatment. In the traditional, circuit-switched
emergency calling system, the types of fraud that are technically
feasible are very limited because the system is very rigid. The
transition to a next-generation IP-based emergency calling system has
the potential to broaden the spectrum of possible attacks. In order to
prevent this, it is necessary to identify the specific fraud risks to
which entities in IP-based emergency calling are exposed, and to enhance
to the emergency calling system to address these risks. The first step
in this process, an analysis of the structure of the emergency calling
system from the perspective of fraud risk, is the subject of this
document.</t>
<t>This document discusses the fraud risks introduced by the transition
from the current circuit-switched emergency calling architecture to
next-generation, packet-switched emergency calling. After introducing
some necessary terminology, we describe the different roles that
entities play in the emergency calling process, and the types of fraud
to which the entities playing those roles are exposed. As an example of
one type of fraud mitigation, we describe a system for voice networks to
verify that call signaling that appears to be for an emergency call is
actually for an emergency call.</t>
</section>
<section title="Terminology">
<t>Caller – The entity that initiates an emergency call. For
purposes of this document, this term includes both the calling party
(e.g., a person in distress or a vehicle that has been involved in a
collision) and any hardware or software used to initiate the call.</t>
<t>Voice Service Provider (VSP) - An entity that provides services that
enable IP-based telephony. In the SIP context, a VSP might operate a set
of proxies; in the 3GPP/IMS context, a VSP is an IMS network
operator.</t>
<t>Internet Service Provider (ISP) - An entity that provides
connectivity to the Internet to its subscribers.</t>
<t>Access Network - An ISP to which a network endpoint is physically
attached. An access network will often also act as an LSP.</t>
<t>Location Service Provider (LSP) - An entity that provides information
about the location of Internet endpoints. In many cases, the LSP used to
geolocate an endpoint will be the access network to which it is
connected.</t>
<t>Public Safety Answering Point (PSAP) - An entity that receives
emergency calls. Some PSAPs receive all calls from callers within a
specified geographic area; others are dedicated to calls related to
specific emergency services.</t>
<t>Emergency Services Routing Proxy (ESRP) - A signaling entity that
routes calls within the emergency services network. In particular, an
ESRP is a part of the emergency services infrastructure, and not
operated by a VSP.</t>
</section>
<section title="Participants in IP-based emergency call establishment">
<t>At a high level, there are four steps in emergency call
establishment:<list style="numbers">
<t>VSP or caller recognizes that a call is an emergency call and
tags it with a service URN</t>
<t>VSP or caller obtains location information from LSP, queries the
LoST infrastructure to obtain the PSAP URI, and sends the call to
this PSAP URI</t>
<t>Call is routed through normal signaling channels (possibly via
multiple VSPs) to the PSAP</t>
<t>PSAP receives call and exchanges multimedia with caller</t>
</list>At the application layer (ignoring physical and network access
providers), there are thus four types of entities that participate in
this process: Callers, VSPs, LSPs, and PSAPs. (The LoST infrastructure
is a background player, to be discussed below) The process of emergency
call establishment in the SIP context is described in detail in <xref
target="I.D-ietf-ecrit-framework"></xref> and <xref
target="I.D-ietf-ecrit-phonebcp"></xref>. The remainder of this section
follows the general structure described in those documents, but is not
necessarily specific to SIP calling.</t>
<t>Callers and VSPs are responsible for recognizing calls as emergency
calls and routing calls to the appropriate PSAPs. Once a caller or VSP
recognizes that a call is an emergency call, it embeds in the call
signaling a service URN to indicate the type of emergency service being
requested. There are two steps in the routing of a call: First, the URN
for the desired service is combined with information on the location of
the caller in a query to the LoST infrastructure, which provides contact
information for the appropriate PSAP for that service and location.
Second, the call is directed to the PSAP via the normal routing
mechanisms for the signaling protocol. In some cases, VSPs will be
required to provide special services to signaling and/or media packets
related to emergency calls. LSPs provide the location information that
is used as an input to LoST in the call routing process. Frequently, the
LSP used for emergency calling will be the access network to which the
calling endpoint is physically connected, since this network naturally
has a physical relationship to the endpoint which can be used to
determine the endpoint’s location. In other situations, the
LSP’s role may be played by a positioning function internal to a
VSP network, or by an independent location server on which the
endpoint’s location has been previously stored. It is generally
understood that location information will be provided without
restriction to appropriate entities for emergency call routing purposes,
even when the LSP might otherwise restrict access to that information
(e.g., for business or privacy purposes).</t>
<t>PSAPs are the recipients of emergency calls. They are responsible for
answering emergency calls and using information provided via signaling
or media to determine how best to respond to an emergency. Location
information is a critical component of this decision. In many cases, the
endpoint’s location will be carried in the call signaling messages
that initiate the emergency call, but the PSAP may also obtain location
through other mechanisms. For example, the signaling may contain a
reference to an LSP that is able to provide up-to-date information on
the location of a mobile endpoint. PSAPs must also discriminate between
calls that are genuine emergencies and calls that are not (while all
calls are usually answered, callers who call without an emergency may be
subject to subsequent investigation or prosecution).</t>
</section>
<section title="Fraud risk in IP-based emergency calling">
<t>Each type of entity described in Section 3 above puts valuable
resources at risk by participating in the emergency call-establishment
process. VSPs may give priority to emergency calls transiting their
network, or allocate bandwidth for them. LSPs need to provide location,
which they may be unwilling to give out (due to business or privacy
reasons) in a non-emergency setting. PSAPs need to optimize their
limited resources for responding to emergency calls. And, most
importantly, emergency callers entrust their safety to the proper
functioning of the emergency calling infrastructure. This section
describes in more detail the requirements that each party has of the
others, and discusses how these requirements can be violated by
fraudulent actors. This section also briefly discusses how these threats
may be addressed, but proposes no complete solutions. The LoST
infrastructure is also a central, trusted component of the emergency
calling system; we describe below certain assurances that emergency
calling entities require of the LoST infrastructure.</t>
<section title="Callers">
<t>Emergency callers generally have more to lose from a failed
emergency call than other entities that participate in emergency call
establishment, since they are by definition in distress. A
caller’s primary requirement is to be able to communicate with
the appropriate PSAP for their emergency, and to receive any necessary
emergency services. In order to receive the requested emergency
services as quickly as possible, the caller must be directed to the
PSAP that is responsible for the requested service in the
caller’s current location. This requires that the entity that
does LoST routing (whether the caller or a VSP) have access to
accurate, timely location, and that LoST routing be done correctly.
Once the appropriate PSAP has been identified and contacted, there
must be sufficient communications resources available for the caller
and the PSAP to exchange any further necessary media or signaling
traffic. The fraud risks faced by callers are thus:<list
style="numbers">
<t>LSPs that provide LoST routing entities with inaccurate
location information, or no location information at all</t>
<t>VSPs that mis-route emergency calls</t>
<t>VSPs (or ISPs) that restrict the communications resources
available for call traffic</t>
</list> Fortunately, these risks are all relatively improbable.
Users often have business relationships with their LSPs, VSPs, and
ISPs that oblige these service providers to provide reliable service.
Additionally, these service providers are often subject to legal and
regulatory requirements that they faithfully execute their roles in
emergency calling.</t>
</section>
<section title="VSPs">
<t>By handling emergency calls, VSPs impose additional load on their
infrastructure, and by providing priority to emergency call signaling
or media traffic (or allocating bandwidth for it), they risk degrading
the quality of service experienced by other users. In order to protect
their infrastructure, VSPs require assurance that calls receiving
special treatment as emergency calls are in fact emergency calls. That
is, they require a reliable means for determining which calls are
emergency calls.</t>
<t>The primary fraud risk for VSPs is that callers will be able to
obtain special treatment for non-emergency calls that is usually only
provided to emergency calls, i.e., that non-emergency calls will be
able to masquerade as emergency calls in order to get special
treatment. VSPs thus require reliable mechanisms for verifying that a
call is an emergency call. These mechanisms must be reliable in the
sense that a call so verified will necessarily be delivered by the
signaling system to a PSAP. An example of such a mechanism is
described in Section 5 below.</t>
</section>
<section title="LSPs">
<t>Location providers have the right to control access to the location
information they hold. They may restrict access to location in order
to protect users’ privacy, or they may do it in order to enable
a pay-for-location business model. On the other hand, location
providers in many jurisdictions have a legal or regulatory requirement
to provide location information for the purpose of routing emergency
calls or for directing emergency responders. The primary fraud that
concerns an LSP is thus that an entity (a caller or VSP) that would
not otherwise have access to location information will be able to
obtain it by claiming to need it for emergency purposes. This problem
is exacerbated by the fact that LSPs are generally unable to
authenticate the entities (e.g. VSPs) that might request location
information for LoST routing. This is because while LSPs tend to be
physically local entities, serving a specific geographical area, VSPs
can handle a call originated anywhere on the Internet. Thus it is not
sufficient for an LSP to have relationships with VSPs in its local
area, as the callers served by an LSP may use a VSP based in another
country, or even on another continent.</t>
</section>
<section title="PSAPs">
<t>PSAPs have limited resources to devote to answering emergency calls
– in particular, they have a limited number of human
call-takers. Many emergencies require emergency responders to be
dispatched, often at significant cost. PSAPs need to optimize their
limited resources, and ensure to the greatest extent possible that
emergency responses are timely and appropriate to the emergency.</t>
<t>The two most significant fraud risks to PSAPs are false emergency
calls and false location information. A false emergency call is a call
placed to a PSAP by a caller who is not in distress. In the current
system, these are often prank calls or inadvertently placed calls. In
the Internet context, there is a much larger risk that PSAPs will
receive a high volume of such false calls, as the process of making a
false call can be more easily automated. A high volume of false calls
can exhaust the limited resources of the PSAP, causing legitimate
calls not to be answered, therefore false calls can be used as a
denial of service attack against the PSAP and legitimate emergency
callers.</t>
<t>Likewise, false location information is location information that
points to something other than the location of an ongoing emergency.
If a PSAP dispatches first responders based on false location, then
these responders may not be available to respond to actual
emergencies. While false calls can by definition only be launched by
fraudulent callers, false location information can be provided by
either callers or LSPs (possibly in collusion with each other).</t>
<t>The cost of not responding to a legitamate emergency call is
obviously quite high, and so PSAPs generally respond to all emergency
calls. Thus, a mechanism for discriminating false calls from
legitimate calls is not useful (unless it can be clearly proven not to
identify legitimate calls as false ones). Mechanisms that provide
reliable information for forensic analysis are preferable, for
instance mechanisms that reliably identifying callers for subsequent
investigation or prosecution.</t>
<t>On the other hand, it is essential to determine whether location
information has been falsified before emergency responders are
dispatched. This is a more tractable problem: Since PSAPs and LSPs are
both inherently local entities, with well-defined geographical
coverage areas, PSAPs will likely be able to establish trust
relationships with LSPs that serve the same geographical area as the
PSAP. These trust relationships can be used together with Internet
security technologies to prove that location objects originated from a
trusted LSP.</t>
</section>
<section title="Requirements of the LoST Infrastructure">
<t>The proper functioning of the emergency calling system depends on
the LoST infrastructure having three critical properties: <list
style="numbers">
<t>Accuracy. Information returned by LoST queries is trusted by
all parties to be an accurate reflection of current PSAP
assignments.</t>
<t>Completeness. A URI belongs to an emergency services entity if,
and only if, it is returned in a LoST response from an
authoritative LoST server.</t>
<t>Uniformity. If two different entities both submit the same
query (within a reasonable period of time), then both queries will
return the same results.</t>
</list>The LoST mapping architecture as specified in <xref
target="I.D-ietf-ecrit-mapping-arch"></xref> mostly satisfies these
requirements. However, there may be limited cases in which it does
not, primarily due to territorial disputes or incomplete deployment.
The latter can be expected to improve as the LoST infrastructure is
more completely deployed; the former is likely to be long-term
issue.</t>
<t>The accuracy assumption is necessary for the emergency calling
system to function at all: If the LoST infrastructure is not trusted
then there are much more serious problems than user fraud. (In
particular, an attacker could redirect all emergency calls in an area
to an attacker controlled fake PSAP.) The completeness and uniformity
assumptions mean that the LoST infrastructure can be used to
authenticate PSAP URIs. In the absence of an authentication
infrastructure for PSAPs, verifying that a URI is returned by a LoST
query is a convenient mechanism that provides reasonable assurance
that a given URI is a PSAP URI. The completeness and uniformity
assumptions may not be valid in the early stages of the deployment of
the LoST infrastructure. In particular, a VSP may receive a different
answer to a LoST query than the end device (or another LoST routing
entity) because either (A) the LoST forest-guide system is incomplete
and the VSP's LoST resolver is unable to identify the authoritative
tree for a given location; or (B) the location is in a contested
region, there are two trees that claim to be authoritative for this
region, and the VSP and the device disagree as to which tree has a
legitimate claim to represent the region.</t>
<t>Fortunately, once the mapping infrastructure is fully deployed (as
described in <xref target="I.D-ietf-ecrit-mapping-arch"></xref>) it
should be very rare for a VSP to fail to locate the authoritative tree
for a given location. In the meantime, one possible strategy to
mitigate this problem is for the device to include in the signaling
the <source> element from the LoST response. In such a case, if
the VSP fails to locate an authoritative tree for a given location, it
can extract the authoritative LoST server from the <source>
element in the signaling traffic and query that server to verify that
URI belongs to an emergency services entity. Even when the LoST
infrastructure is fully deployed, there will likely always be
territorial disputes that result in two distinct trees claiming to be
authoritative for a given region. However, in most such cases, it is
likely that a user will select a VSP that agrees with him as to who
legitimately controls a given region. In situations where a user
disagrees with his VSP as to which tree is authoritative for a given
region, then the VSP will likely not give special consideration to
calls destined for a PSAP it deems illegitimate (even if the user
deems the PSAP to be legitimate). There can be no technical solution
that resolves such a dispute. (For example, it is unlikely that a
Israeli VSP will give special treatment to a call destined for a
Palestinian PSAP in a contested territory, no matter what protocol
specifications we might produce.)</t>
</section>
</section>
<section title="Mitigating Fraud against VSPs">
<t>One type of fraud that can reasonably be mitigated is fraud against
VSPs, in which callers are able to obtain special services usually
reserved for emergency calls by crafting non-emergency calls that look
like emergency calls. In this section, we describe a mechanism to
mitigate this fraud. Although we describe our solution here in terms of
SIP signaling, the same technique could be adapted to other signaling
protocols with appropriate semantics.</t>
<section title="Problem Statement">
<t>In the case of the signaling network, fraud occurs when a call is
placed to a non-emergency services entity, but signaling elements
(e.g. SIP Proxies) believe that that the call is an emergency call. In
particular, consider a VSP that provides special preference to
emergency calls (e.g. emergency calls are free of charge, or are given
high priority access to signaling elements). If a malicious user of
such a VSP is able to cause calls to an arbitrary recipient to be
treated as emergency calls, then the user could fraudulently gain
access to VSP resources. Clearly this is a situation the VSP wishes to
avoid.</t>
<t>Note that in this document, we are not concerned with non-emergency
calls to emergency services entities. Although such calls are also
fraudulent, they (1) are very difficult to detect; and (2) have a very
limited impact on VSP resource consumption, since they may only be
placed to emergency services entities.</t>
<t>This system verifies that a call is an emergency call in the sense
that it is structured as an emergency call described in <xref
target="I.D-ietf-ecrit-phonebcp"></xref>, and it is directed to a PSAP
URI. The structural verification is performed simply be examining the
contents of the SIP INVITE message. Verifying that a given URI is a
PSAP URI is done via a LoST query, so this mechanism depends heavily
on the above-listed assumptions about the LoST infrastructure. If LoST
information can be manipulated by an attacker, then he can thwart this
verification procedure by making any URI look like a PSAP URI. If
there are PSAPs who are not listed in the LoST infrastructure, then
this system will not be able to verify that their URIs are PSAP URIs,
and will not regard calls to them as emergency calls. And if different
entities receive different answers to the same query, then there is a
risk that the entity that the query that is used to verify the PSAP
URI will return a different result than the one used to find the PSAP
URI in the first place.</t>
</section>
<section title="Risk at different stages of emergency calling">
<t>Recall that in the ECRIT framework for emergency calling, there are
three distinct stages of an emergency call. The three stages and their
corresponding markings are listed below:<list style="numbers">
<t>The call has not been recognized as an emergency call (and has
therefore has also not been routed). <vspace blankLines="1" />The
Request-URI of the call contains a Dial String URI.</t>
<t>The call has been recognized as an emergency call but has not
been routed.<vspace blankLines="1" />The Request-URI of the call
contains an appropriate emergency services URN.</t>
<t>The call has been recognized as an emergency call and has been
routed via the LoST protocol.<vspace blankLines="1" />The
Request-URI of the call contains an appropriate emergency services
URN and the Route header contains the URI of PSAP.</t>
</list>Note that in the context of fraud targeting the VSP, there is
only risk of fraud when the VSP receives a call in the third of these
stages.</t>
<t>When a VSP receives a call in the first stage, it will attempt to
recognize the dial string as a valid emergency dial string. If the
recognition is successful it will process the call as it would process
a second-stage call and thus there is no opportunity for fraud.</t>
<t>When a VSP receives a call in the second stage, the VSP will make a
LoST query (which will return a valid PSAP URI) and the VSP will
proceed to route the call to this URI. Therefore, there is no
opportunity for fraud.</t>
<t>The possibility of fraud only exists when the VSP receives a call
in the third stage. In such a case, the URI in the route header may or
may not be a valid PSAP URI returned by LoST query. Therefore, to
prevent fraud against the VSP it suffices to ensure that a VSP can
verify that the URI in the route header of a third-stage call is a
valid PSAP URI returned by a LoST query. Note that this problem is
tractable becuase in order for a VSP to receive a third-stage call,
some upstream signaling entity must possess location information of
sufficient precision for use with LoST, and this location can be used
by the VSP (in conjunction with the LoST infrastructure) to verify the
validity of the URI in the Route header. A mechanism for performing
such verification is described in the next section. </t>
</section>
<section title="A verification mechanism">
<t>Here we propose a signaling mechanism for emergency calls that have
been recognized and routed (see Section 5.2) that allows a VSP to
verification that the URI in the Route header is a valid PSAP URI
(returned by a LoST query).</t>
<t>Note that we are not proposing that VSPs reject emergency calls
that fail verification (or are not marked using this mechanism).
Instead the failure of verification or the absence of this mechanism
may be used as an indication of possible fraud. Further (forensic)
analysis may be necessary to determine that fraud did indeed occur.
Nonetheless, this mechanism should be useful to detect large scale
fraud and take appropriate action.</t>
<t>In describing our mechanism, we distinguish the following two
cases: (1) the emergency call is routed by the calling device; and (2)
the emergency call is routed by a SIP proxy. These two cases differ
slightly in the actions perfromed by the entity who does the call
routing. However, the verification procedure performed by the VSP is
identical in both cases.</t>
<t>When the emergency call is routed by the calling device, if the
calling device has access to its location, then it MUST include its
location (either by value or by reference) in a geolocation header
<xref target="I.D-ietf-sip-location-conveyance"></xref> in the SIP
INVITE used to initiate the emergency call. This geolocation header
must include the “used-for-routing” parameter. If the
calling device does not have access to its location, then it must
include the PSAP service area boundary (returned by LoST) in the body
of the SIP INVITE. This boundary must be referenced by a SIP
geolocation header and that header must contain the
“used-for-routing” parameter.</t>
<t>When the emergency call is routed by a SIP proxy, if the calling
device’s location is already present in the SIP INVITE, then the
proxy must add the “used-for-routing” parameter to the
appropriate geolocation header. If the calling device’s location
is not present in the SIP INVITE, then the proxy must add a
geolocation header containing either a reference to the device’s
location, or else a reference to the PSAP service area boundary
(returned by LoST). This geolocation header must include the
“used-for-routing” parameter. This reference must be able
to be dereferenced by any entity on the public internet. If the SIP
proxy possesses an appropriate, universally-dereferencable reference
to the device's location or the PSAP service area boundary, it may use
this reference in the geolocation header. However, if the SIP proxy
does not possess an appropriate reference, then it must create a new
reference to either the location of the calling device or the service
boundary of the PSAP. Note that this requires the SIP proxy (or
another machine in the domain of the SIP proxy) to maintain state for
the lifetime of this newly created location reference (which should
not be less than several minutes). This introduces the possibility of
a denial of service attack against the SIP proxy in which an entities
served by the SIP proxy make a large number of emergency calls to
exhaust the storage available for maintaining such reference bindings.
Therefore, it is recommended that the SIP proxy creates references to
PSAP service boundaries and not device locations, since these service
bondary references can be reused whenever the SiP proxy routes
multiple calls to the same PSAP. </t>
<t>We now describe the actions taken to verify that a (previously
recognized and routed) emergency call is being routed to a valid PSAP
URI. Upon receiving a SIP INVITE for such a call, the VSP does the
following: <list style="symbols">
<t>Examine the Request-URI header to obtain a service URN. If the
Request-URI header does not contain a service URN then
verification fails. (Note that service URNs act as universal
identifiers for emergency calls, and any call that has been
recognized as an emergency call must be tagged with a service URN
in the Request-URI header <xref
target="I.D-ietf-ecrit-phonebcp"></xref>.)</t>
<t>Examine the SIP headers and attempt to find a geolocation
header containing the “used-for-routing” parameter. If
such a geolocation header does not exist then verification
fails.</t>
<t>If the geolocation header contains a location reference,
attempt to dereference the reference to obtain a location object.
If the deference fails then verification fails. Otherwise, if the
location is included by-value then obtain the location object from
the body of the SIP message.</t>
<t>If the location object is a point, then make a LoST query using
that point and the service URN from the Request-URI header to
obtain a PSAP URI. If the location object is a service boundary,
then make a LoST query using an arbitrary point within the
boundary and the URN from the Request-URI header to obtain a PSAP
URI.</t>
<t>Compare the PSAP URI obtained from the LoST query to the URI in
the Route header. If the two URIs do not match, then verification
fails. If the two URIs do match, then verification succeeds.</t>
</list></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project..</t>
</section>
<section anchor="IANA" title="Security Considerations">
<t>This document outlines a mechanism for the mitigation fraud against
VSPs with respect to IP-based emergency calls. The trust model and the
security concerns related to the mechanism are presented in the
appropriate sections.</t>
</section>
<section anchor="Security" 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-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>
</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 08:25:25 |