One document matched: draft-barnes-ecrit-auth-01.txt
Differences from draft-barnes-ecrit-auth-00.txt
Internet Engineering Task Force R. Barnes
Internet-Draft M. Lepinski
Intended status: Informational BBN Technologies
Expires: April 24, 2008 October 22, 2007
Fraud mitigation for IP-based emergency calling
draft-barnes-ecrit-auth-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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.
Barnes & Lepinski Expires April 24, 2008 [Page 1]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Participants in IP-based emergency call establishment . . . . 4
4. Fraud risk in IP-based emergency calling . . . . . . . . . . . 5
4.1. Callers . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. VSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. PSAPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Requirements of the LoST Infrastructure . . . . . . . . . 8
5. Mitigating Fraud against VSPs . . . . . . . . . . . . . . . . 10
5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 10
5.2. Risk at different stages of emergency calling . . . . . . 11
5.3. A verification mechanism . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Barnes & Lepinski Expires April 24, 2008 [Page 2]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
1. Introduction
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.
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.
2. Terminology
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.
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.
Internet Service Provider (ISP) - An entity that provides
connectivity to the Internet to its subscribers.
Access Network - An ISP to which a network endpoint is physically
attached. An access network will often also act as an LSP.
Barnes & Lepinski Expires April 24, 2008 [Page 3]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
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.
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.
3. Participants in IP-based emergency call establishment
At a high level, there are four steps in emergency call
establishment:
1. VSP or caller recognizes that a call is an emergency call and
tags it with a service URN
2. 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
3. Call is routed through normal signaling channels (possibly via
multiple VSPs) to the PSAP
4. PSAP receives call and exchanges multimedia with caller
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 [I.D-ietf-ecrit-framework] and
[I.D-ietf-ecrit-phonebcp]. The remainder of this section follows the
general structure described in those documents, but is not
necessarily specific to SIP calling.
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
Barnes & Lepinski Expires April 24, 2008 [Page 4]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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).
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).
4. Fraud risk in IP-based emergency calling
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
Barnes & Lepinski Expires April 24, 2008 [Page 5]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
4.1. Callers
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:
1. LSPs that provide LoST routing entities with inaccurate location
information, or no location information at all
2. VSPs that mis-route emergency calls
3. VSPs (or ISPs) that restrict the communications resources
available for call traffic
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.
4.2. VSPs
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
Barnes & Lepinski Expires April 24, 2008 [Page 6]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
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.
4.3. LSPs
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.
4.4. PSAPs
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.
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
Barnes & Lepinski Expires April 24, 2008 [Page 7]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
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).
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.
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.
4.5. Requirements of the LoST Infrastructure
The proper functioning of the emergency calling system depends on the
LoST infrastructure having three critical properties:
1. Accuracy. Information returned by LoST queries is trusted by all
parties to be an accurate reflection of current PSAP assignments.
2. 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.
Barnes & Lepinski Expires April 24, 2008 [Page 8]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
3. Uniformity. If two different entities both submit the same query
(within a reasonable period of time), then both queries will
return the same results.
The LoST mapping architecture as specified in
[I.D-ietf-ecrit-mapping-arch] 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.
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.
Fortunately, once the mapping infrastructure is fully deployed (as
described in [I.D-ietf-ecrit-mapping-arch]) 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
Barnes & Lepinski Expires April 24, 2008 [Page 9]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.)
5. Mitigating Fraud against VSPs
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.
5.1. Problem Statement
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.
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.
This system verifies that a call is an emergency call in the sense
that it is structured as an emergency call described in
[I.D-ietf-ecrit-phonebcp], 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
Barnes & Lepinski Expires April 24, 2008 [Page 10]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
5.2. Risk at different stages of emergency calling
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:
1. The call has not been recognized as an emergency call (and has
therefore has also not been routed).
The Request-URI of the call contains a Dial String URI.
2. The call has been recognized as an emergency call but has not
been routed.
The Request-URI of the call contains an appropriate emergency
services URN.
3. The call has been recognized as an emergency call and has been
routed via the LoST protocol.
The Request-URI of the call contains an appropriate emergency
services URN and the Route header contains the URI of PSAP.
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.
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.
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.
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
Barnes & Lepinski Expires April 24, 2008 [Page 11]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
5.3. A verification mechanism
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).
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.
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.
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
[I.D-ietf-sip-location-conveyance] 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.
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
Barnes & Lepinski Expires April 24, 2008 [Page 12]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
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.
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:
o 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 [I.D-ietf-ecrit-phonebcp].)
o 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.
o 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.
o 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
Barnes & Lepinski Expires April 24, 2008 [Page 13]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
URI.
o 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.
6. Acknowledgements
This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project..
7. Security Considerations
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.
8. IANA Considerations
This document makes no request of IANA.
9. References
9.1. Normative References
[I.D-ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet
Multimedia", September 2007.
[I.D-ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
September 2007.
[I.D-ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", July 2007.
9.2. Informative References
[I.D-ietf-ecrit-mapping-arch]
Schulzrinne, H., "Location-to-URI Mapping Architecture and
Barnes & Lepinski Expires April 24, 2008 [Page 14]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
Framework", September 2007.
Authors' Addresses
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
USA
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
Matt Lepinski
BBN Technologies
10 Moulton St
Cambridge, MA 02138
USA
Phone: +1 617 873 5939
Email: mlepinski@bbn.com
Barnes & Lepinski Expires April 24, 2008 [Page 15]
Internet-Draft draft-barnes-ecrit-auth-01 October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes & Lepinski Expires April 24, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 03:40:14 |