| TOC |
|
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.
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.
1.
Introduction
2.
Terminology
3.
Participants in IP-based emergency call establishment
4.
Fraud risk in IP-based emergency calling
4.1.
Callers
4.2.
VSPs
4.3.
LSPs
4.4.
PSAPs
4.5.
Requirements of the LoST Infrastructure
5.
Mitigating Fraud against VSPs
5.1.
Problem Statement
5.2.
Risk at different stages of emergency calling
5.3.
A verification mechanism
6.
Acknowledgements
7.
Security Considerations
8.
IANA Considerations
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
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.
| TOC |
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.
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.
| TOC |
At a high level, there are four steps in emergency call establishment:
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] (Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, “Framework for Emergency Calling using Internet Multimedia,” September 2007.) and [I.D‑ietf‑ecrit‑phonebcp] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” September 2007.). 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 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).
| TOC |
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.
| TOC |
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:
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.
| TOC |
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.
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.
| TOC |
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.
| TOC |
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 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.
| TOC |
The proper functioning of the emergency calling system depends on the LoST infrastructure having three critical properties:
The LoST mapping architecture as specified in [I.D‑ietf‑ecrit‑mapping‑arch] (Schulzrinne, H., “Location-to-URI Mapping Architecture and Framework,” September 2007.) 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] (Schulzrinne, H., “Location-to-URI Mapping Architecture and Framework,” September 2007.)) 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.)
| TOC |
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.
| TOC |
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] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” September 2007.), 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.
| TOC |
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:
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 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.
| TOC |
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] (Polk, J. and B. Rosen, “Location Conveyance for the Session Initiation Protocol,” July 2007.) 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 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:
| TOC |
This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project..
| TOC |
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.
| TOC |
This document makes no request of IANA.
| TOC |
| TOC |
| [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. |
| TOC |
| [I.D-ietf-ecrit-mapping-arch] | Schulzrinne, H., “Location-to-URI Mapping Architecture and Framework,” September 2007. |
| TOC |
| 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 |
| TOC |
Copyright © 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.
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.