available atwww.sciencedirect.com
journal homepage:www.elsevier.com/locate/ijcip
How secure is the next generation of IP-based emergency
services architecture?
Hannes Tschofenig
a
, Mayutan Arumaithurai
b
,
∗
, Henning Schulzrinne
c
, Bernard Aboba
d
aNokia Siemens Networks and University of Göttingen, Germany bUniversity of Göttingen, Germany
cColumbia University, USA dMicrosoft, USA
A R T I C L E I N F O
Article history:
Received 30 August 2009 Received in revised form 25 January 2010
Accepted 6 February 2010
Keywords:
Emergency services architecture Ecrit
A B S T R A C T
For some location-based applications, such as emergency calling or roadside assistance, it appears that the identity of the requester is less important than accurate and trustworthy location information for accomplishing the main function. Accurate and genuine location is important for these applications to avoid misuse.
In this paper we point to some ongoing efforts regarding transition emergency service architectures that could introduce security vulnerabilities unless countermeasures are developed. Furthermore, we summarize the ongoing work in providing cryptographic assertions for location.
We argue that many of the currently proposed ideas are difficult to deploy and to operate. Additionally, when used without ensuring that the underlying assumptions are met these mechanisms do not provide any additional benefit, but costs.
We conclude this article with a suggestion on what the research community and industry should be investigating to avoid potential problems with IP-based emergency services.
c
2010 Elsevier B.V. All rights reserved.
1.
Introduction
Users of the legacy telephone network can summon emergency services such as ambulance, fire and police using a well-known emergency service number (e.g., 9-1-1 in North America and 1-1-2 in Europe). Location information is used to route emergency calls to the appropriate regional Public Safety Answering Point (PSAP) to serve the caller. The PSAP then dispatches local responders to the emergency site as per the requirements.
∗Corresponding author.Tel.: +49 17620322049.
E-mail addresses:[email protected](H. Tschofenig),[email protected](M. Arumaithurai), [email protected](H. Schulzrinne),[email protected](B. Aboba).
Regulators have put in place regulations requiring emergency services support for “fixed” Voice Over IP (VOIP) services and are now looking at extending these requirements to “nomadic” and “mobile” VOIP services. However, enabling such critical public services using the Internet is challenging, as many of the assumptions of the Public Switched Telephone Network (PSTN)/Public Land Mobile Network (PLMN) no longer hold true. In particular, while the local telephone company provides both the physical access and the phone service, VoIP allows and encourages a split of these two roles
1874-5482/$ - see front matter c2010 Elsevier B.V. All rights reserved. doi:10.1016/j.ijcip.2010.02.001
between the Internet Service Provider (ISP)1 and the Voice Service Provider (VSP).2The VSP may be located far away from the ISP and may either have no business relationship with the ISP or may even be a competitor. It is also likely that the VSP has no relationship with the PSAP either.
Standardization organizations, such as the Internet En-gineering Task Force (IETF), the National Emergency Num-ber Association (NENA) and the 3rd Generation Partnership Project (3GPP), have developed architectures to enable emer-gency services for IP-based devices. These standardized archi-tectures represent the ideal end state of emergency services deployments in IP networks and are either based on the as-sumption that end devices are upgraded to support new pro-tocol functionality or that the ISP is turned into a VSP (at least for the purpose of emergency calling).
Needless to mention, to build these architectures one is required to provide sufficient monetary investment and time. Emergency Services funding models, which differ among nations and states, are typically governed by regulations and legislations that may interact in complex ways, limit-ing funds available for deployment of next generation emer-gency services infrastructure. Hence, organizations such as NENA and independent activities within individual countries (e.g., Canada, UK, Sweden) have done work on transition ar-chitectures. These architectures largely assume that the end devices have not been enhanced to support emergency ser-vices capabilities. Therefore, these architectures also consider the interoperating of the end hosts with legacy PSAPs, at least from a call handling point of view. This includes cases where ISPs do not provide location information to the end device, for example, because there is explicit legal requirement to with-hold it.
Hence, without the ability for the end device to obtain lo-cation information the task is essentially pushed to the VSP where that call is initially routed to. Our subsequent descrip-tion will focus on two cases of such an initial transidescrip-tion phase, namely legacy end points and minimally upgraded end hosts.
1.1. Legacy end points
Fig. 1graphically represents an emergency services architec-ture with legacy end points. When the emergency caller dials 112, for example, the device treats it as any other call without recognizing it as an emergency call. The dial string provided by the end point may conform to RFC 4967 [1] or RFC 3966 [2] and is signaled in the call setup procedure to the Voice ser-vice Provider (VSP). Session Initiation Protocol (SIP) [3] is one of the most commonly used signaling protocols andFig. 1 de-picts some example SIP usage. Recognition of the dial string, retrieving location information, and routing to the nearest 1In this article we furthermore ignore the potential separation between the Internet access provider, i.e. an organization that provides physical and data link layer network connectivity to its customers, and the ISP.
2We use the term VSP for readability purposes throughout the document instead of using the more generic term Application Server Provider. At least within the IETF and NENA the solutions support multi-media and not just voice-based emergency services.
Fig. 1 – Interim architecture with legacy end points.
PSAP are all left as obligations to the VSP. It is easier for an ISP co-located with a VSP to provide location-based voice services than in the case of the VSP and ISP existing as dif-ferent entities. For example, tasks such as dial string recog-nition, location determination and call routing to the nearest PSAP is easier to achieve in cases where the ISP provides the fixed devices with voice services too. IP devices that can only be used with a specific ISP can, for example, be found with some triple-play offerings and are becoming more and more common.
There are two main challenges that appear when dealing with legacy devices: First, the VSP has to discover the Location Information Server (LIS) that knows the location of the IP-based end host. Secondly, the VSP has to identify the PSAP that is in charge of serving the user’s area.
The VSP is likely to only know the IP address of the device as seen in the call signaling messages arriving at the VSP. Using the IP address to find the ISP is challenging and may, in the case of mobility protocols and VPNs, lead to wrong results. In addition, the potentially large number of VSPs that should be able to retrieve location information from ISPs purely based on information like the IP address may lead to a significant privacy challenge. Privacy laws prevent uncontrolled access to location information thereby limiting the access to such information to authorized VSPs only. Scaling such a mechanism beyond the boundaries of a single country is difficult, and thus the scenario of roaming users is still unsolved.
As mentioned above, LIS discovery via IP address or other means is just the first challenge. Once a LIS is discovered and contacted and some amount of location information is exchanged, the second challenge arises, namely how to route the emergency call to the nearest PSAP. To accomplish the latter task it is necessary for the VSP to have some information about the PSAP boundaries, i.e. information about the geographical region served by each PSAP for each emergency service.
Due to the inherent differences in VOIP architectures as compared with the PSTN, certain functionality important for emergency services purposes (such as call-backs from the PSAP) may not be available without modifications to end points and/ or VSP equipments. Since many of these aspects relate to non-security features the reader is referred to [4] for a detailed description of the functionality that has to be provided by end hosts.
1.2. Minimally upgraded end hosts
A big step forward in reliably handling IP-based emergency calls is to provide the end host with some information about the LISs operated by the ISPs so that the discovery by the VSP can be simplified. The end host may learn the ISP’s domain name, for example using the mechanisms described in [5]. The VSP is then able to use the domain name to discover a LIS using the Domain Name System.
Additional software upgrades at the end device might allow it to recognize emergency calls based on some pre-configured emergency numbers (e.g., ‘1-1-2’ and ‘9-1-1’) and to react appropriately during an emergency call situation (e.g., by disabling silence suppression). Making location infor-mation available to the VSP, if it is already available at the end host, is possible with this approach as well. Built-in GPS is increasingly common with modern cellular phones, and hence detailed location information may be available at the end point.
2.
Threats
Prank calls have been a problem for emergency services, dating back to the time of street corner call boxes. Individual prank calls waste scarce emergency service resources and possibly endanger bystanders or emergency service personnel as they rush to the reported scene of a fire or accident. Risks to human life are not a typical security threat withing communication protocols. Emergency services are, however, different in this regard. Recent 9-1-1 “swatting” incidents with life threatening consequences have captured media attention [6]. Some of these incidents have involved spoofing of the originating phone number when calling 9-1-1 leading to a false location being obtained via the phone number-to-location lookup used in fixed line environments. This could result in a SWAT team being dispatched to the location of a completely innocent citizen, if the swatter is able to convince the call taker that a serious crime is under way. Recently the FBI has warned about the increasing prevalence of swatting incidents [7].
A further concern in context of homeland security is that massive prank calls can be used to disrupt emergency services, for example, during a mass-casualty event, and thus be used as a means to amplify the effect of a terror attack.
Emergency services have at least three finite resources subject to denial of service attacks: The network and server infrastructure, call takers and dispatchers, and the first re-sponders, such as fire fighters and police officers. Protecting the network infrastructure is similar to protecting other high-value service providers, except that application-specific loca-tion informaloca-tion may be used to filter call setup requests, for example to weed out requests that are out of area. Large cities might also have PSAPs with only a handful of PSAP call takers on duty. Even if the call takers attempt to question the caller to reduce prank calls, they would be quickly overwhelmed by even a small-scale attack. Finally, first responder resources are scarce, particularly during mass-casualty events.
IP-based emergency calling faces many security threats, most of which are well known from other realms, such
as eavesdropping, man-in-the-middle, or denial-of-service attacks using packet flooding. Here, we focus specifically on threats toward the higher-layer protocol stacks that are unique to emergency services rather than applicable to IP net-works in general.
Currently, it seems that the security for today’s emergency services system appears to rely on the fact that identity and location spoofing are difficult to mount by ordinary users. Additionally, the identity of most callers can be ascertained, so that the threat of severe punishments reduces prank calls. This is at least true in those countries that do not allow SIM-less emergency calls, i.e. emergency calls that are made with-out any authentication. PSAP operators in some countries in Europe already have to deal with more than 50% of their calls being prank calls due to the need to support SIM-less emer-gency calls [8]. Mechanically placing a large number of emer-gency calls that appear to come from different locations is also difficult. Calls from pay-phones are subject to greater scrutiny by the call taker. In the current emergency system, it would also be very difficult for an attacker located in one country to attack the emergency services infrastructure lo-cated in a different country.
The motivations of adversaries might vary. One motiva-tion is to prevent callers from utilizing emergency services support. This can be done by a variety of means, such as im-personating a PSAP or a directory server, or attacking Session Initiation Protocol (SIP) signaling elements and location servers.
Attackers may also want to modify, prevent or delay emer-gency calls. In some cases, this will lead the PSAP to dispatch emergency personnel to an emergency that does not exist and, hence, the personnel might not be available to other callers. It might also be possible for an attacker to impede the users from reaching an appropriate PSAP by modifying the lo-cation of an end host or the information returned from the mapping protocol.
If identities can easily be crafted (as it is the case with many VoIP offerings today), then the value of emergency caller authentication itself might be limited. As a conse-quence, attackers can forge emergency call information with-out the chance of being held accountable for their actions.
The above-mentioned attacks are mostly targeting indi-vidual emergency callers or a very small fraction of them. If attacks are, however, launched against the mapping architec-ture [9] or against the emergency services IP network that in-cludes PSAPs and call routing elements, a larger region and a large number of potential emergency callers are affected. The call takers themselves are a particularly scarce resource and if human interaction by these call takers is required then this can very quickly have severe consequences.
2.1. Adversary models
To provide a structured analysis we distinguish between three adversary models:
2.1.1. External adversary model
The end host, e.g., an emergency caller whose location is going to be communicated, is honest and the adversary may be located between the end host and the location server or between the end host and the PSAP. None of the emergency service infrastructure elements act maliciously.
2.1.2. Malicious infrastructure adversary model
The emergency call routing elements, such as the LIS, the Location-to-Service Translation (LoST) infrastructure [10,9], used for mapping locations to a PSAP address, or call routing elements, may act maliciously.
2.1.3. Malicious end host adversary model
The end host itself acts maliciously, whether the owner is aware of this or whether it is acting as a bot.
We will focus only on the malicious end host adversary model since it follows today’s most common adversary model on the Internet that includes bot nets.
2.2. Location spoofing
An adversary can provide false location information in order to fool the emergency personnel. Such an attack is particu-larly easy if location information is attached to the emergency call by the end host and is either not verified or cannot be ver-ified by anyone. Only entities that are close to the caller can verify the correctness of the location information.
The following list presents threats specific to location information handling:
• Place shifting: The adversary pretends to be at an arbitrary location. In some cases, place shifting can be limited in range, e.g., to the coverage area of a particular cell tower. • Time shifting: The adversary pretends to be at a location
he was a while ago.
• Location theft: The adversary observes someone else’s location and replays it as his own.
• Location swapping: The adversary and his friend, located in different places, can collude and swap location informa-tion and pretend to be in each other’s locainforma-tion.
2.3. Manipulating location determination
An adversary who wants to provide false location to a PSAP has a number of choices. Tampering with location informa-tion is one possible choice discussed in Secinforma-tion2.2. Impacting the location determination procedure itself is another possi-ble approach.
The process of determining location information heavily depends on the specific network deployment. On an abstract level, however, the process is fairly simple. An entity called the Location Recipient, like the end host or a SIP proxy at the VSP, transmits a request for location information to a LIS. Some information about the device to be located has to be provided in that request to allow the LIS to do its job. Unfortu-nately, there is no unique device identifier available that ide-ally fulfills that purpose. The Location Recipients have a few identifiers to choose from and the IP address is a commonly used identifier. In other cases more identifiers are available, for example those listed in [11] include a MAC address, a Network Access Identifier, and the DHCP Unique Identifier. When a LIS receives such a request for location information it will have to associate the obtained identifier with informa-tion available as part of the network operator. For example, imagine that a LIS obtains an IP address with the request mes-sage and the user is located in a DSL network. The IP address may be allocated from a pool of addresses maintained by the Authentication, Authorization and Accounting (AAA) server
and therefore the AAA server has to be queried. However, the AAA may know the current attachment point of the end host or may use available information about the DSL Access Module (DSLAM) and Access Node (AN) and the related iden-tifiers (e.g., to determine the position of the end host Ethernet VLAN tags, Layer 2 tunnel identifiers, virtual port ID (VPI) and virtual circuit ID (VCI)). Further examples of such measure-ment identifiers are provided in [12].
Consequently, there are various methods by which an adversary can interfere with the mapping of the identifier to provide wrong information. If the adversary succeeds in feeding wrong information in the lookup step, it might be able to fool a LIS into handing out wrong location information. Examples of interfering with identifier mapping include the sending of a false MAC address or an IP address to obtain a different location information. It should also be noted that wiremap maintenance is prone to errors thereby resulting in wrong information being handed out even in the absence of malice.
2.4. Call identity spoofing
If an adversary can place emergency calls without disclosing its identity, then determining the source of prank calls nay be more difficult. There are at least two different forms of authentication in this context:
• Network access authentication (e.g., using the Extensible Authentication Protocol (EAP) [13])
• Authentication of the emergency caller at the VoIP appli-cation layer.
This differentiation is created by the split between the ISP and the VSP. Note that different identities are involved since they are managed by different parties. Thus linking the two identities is in general quite difficult.
Trying to identify an adversary that did not authenticate itself to the VSP is difficult, although if network access au-thentication occurred, then this may still be possible. If there is no authentication (neither to the VSP nor to the ISP) then it is very challenging to trace the call back to the individual who can be held accountable. This might, for example, be the case with an open IEEE 802.11 WLAN access point, even if the owner of the access point can be determined.
However, unlike the existing telephone system, it is possi-ble to imagine that VoIP emergency calls could require strong authentication. Even the introduction of additional creden-tials, for example an emergency certificate, is imaginable; although dedicated certificates increase costs, introduce a significant administrative overhead and are only, from a se-curity point of view, useful if widely used. Note that providing such additional identity information is not necessarily related to a business relationship with the ISP or VSP. Due to the time-critical nature of emergency calls the performance of multi-layered authentication still requires further research.
3.
State-of-the-art solution approaches
Existing work has focused almost exclusively on location spoofing as described below. The authors believe that this is
largely due to the fact that the existing emergency services specifications have set requirements that lean toward that direction. NENA, which represents a large community of emergency services professionals within North America, has done pioneering work on emergency services and has included requirements for trusted location within its specifications.
Section 3.7 of ‘NENA Interim VoIP Architecture for En-hanced 9-1-1 Service (i2)’ [14] describes the goals for trust-worthy location as follows:
The intent of the NENA i2 solution is to provide functional equivalency to the existing network services in an IP-based environment, and this includes ensuring that the location information is valid and secure. Current networks use location information to route calls to the local PSAP, and to provide a location to which emergency responders may be dispatched. Three important characteristics of existing networks contribute to the security of these functions:
1. The source of the location is attributable to a specific trusted source. Location is provided by the access/voice service provider.
2. The location information is applicable to a specific point in time. The location information is either used to directly route the call (as may be the case for wireless), or indirectly via the called number/ Automatic Number Identification (ANI) (as for wirelines). It is always retrieved at the time of call receipt.
3. The location information can be identified as belonging to a specific endpoint. This may be a direct association as is the case with wireline, or it may be an indirect association, as is the case with Emergency Services Routing Keys (ESRKs) in wireless. The location information is known to apply specifically to the calling device; another device’s location cannot be misrepresented as the calling device’s location.
This section presents three solution approaches that have been discussed in order to meet the above-stated requirements.
3.1. Location signing
One way to avoid location spoofing is to let a trusted location server sign the location information before it is sent to the end host, i.e., the entity subject to the location determination process. The location signature is verified by the location recipient and not by the target. It is still possible for the target to verify the correctness of the location provided by the LIS. Of course this raises the question of what happens if the LIS-provided location is wrong (perhaps due to a wiremap error). Fig. 2shows the communication model with the target (end-host) requesting signed location in step (1), the location server returns it in step (2) and it is then conveyed to the location recipient in step (3) who verifies it. HTTP-Enabled Location Delivery (HELD) [15] can, for example, be used to provide the necessary functionality for step (1) and (2). The IETF has drafted procedures [16] to accomplish step (3) with the use of SIP signaling protocol.
Additional information, such as a timestamp or an expira-tion time, has to be included together with the signed loca-tion to limit replay attacks. If the localoca-tion is retrieved from a
Fig. 2 – Location signing.
location server, even a stationary end host has to periodically obtain a fresh signed location, or incur the additional delay of querying during the emergency call.
Bot nets are unlikely to be deterred by location signing. However, accurate location information would limit the usable subset of the bot net, as only hosts within the PSAP serving area would be useful in placing calls.
To prevent location-swapping attacks it is necessary to in-clude some target specific identity information tied to the calling party within the data covered by the signature. The included information depends on the purpose, namely either real-time verification by the location recipient or for the pur-pose of a post-mortem analysis when the location recipient wants to determine the legal entity behind the target for pros-ecution (if this is possible). The operational considerations make a real-time verification difficult. A strawman proposal for location signing is described in [17].
Location signing is also difficult when the host provides its own location via GPS, which is likely to be a common oc-currence for mobile devices. Trusted computing approaches, with tamper-proof GPS modules, may be needed in that case. After all, a device can always pretend to have a GPS device and the recipient has no way of verifying this or forcing disclosure of non-GPS-derived location information.
Location verification may be most useful if it is used in conjunction with other mechanisms. For example, a call taker can verify that the region that corresponds to the IP address of the media stream roughly corresponds to the location in-formation reported by the caller. To make the use of bot nets more difficult, a CAPTCHA-style test may be applied to suspi-cious calls, although this idea is quite controversial for emer-gency services, at the danger of delaying or even rejecting valid calls. It is quite easy to understand the discomfort when considering a hearing impaired emergency caller being pre-sented an audio CAPTCHA, considering that he or she is likely to be in stress and not expecting such a Turing test.
3.2. Location by reference
The location-by-reference concept was developed so that end hosts could avoid having to periodically query the location server for up- to-date location information in a
Fig. 3 – Location by reference.
mobile environment. Additionally, if operators do not want to disclose location information to the end host without charging them, location-by-reference provides a reasonable alternative.
Fig. 3 shows the communication model with the target (end-host) requesting a location reference in step (1), the location server returns the reference in step (2), and it is then conveyed to the location recipient in step (3). The location recipient needs to resolve the reference with a request in step (4). Finally, in step (5) location information is returned to the Location Recipient afterward. For location conveyance in SIP, the procedures described in [16] are applicable.
The details for the dereferencing operations vary with the type of reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. HELD [15] is an example of a protocol that is able to return such references. In case of references utilizing HTTP/HTTPS URI schemes the approach described in [18] may be used for dereferencing.
For location-by-reference, the location server needs to maintain one or several URIs for each target, timing out these URIs after a certain amount of time. References need to expire to prevent the recipient of such a URI from being able to permanently track a host, and they need to expire to offer garbage collection functionality for the location server. With additional functionality introduced with [19] the end host is also offered the possibility to revoke the previously created reference and to attach authorization policies. If an emergency services situation is completed then the emergency caller may revoke the right for everyone to track its location. Note that during the time of the emergency situation itself regulatory requirements to make location information available to the PSAP override any location privacy setting.
Off-path adversaries must be prevented from obtaining the target’s location. The reference contains a randomized component that prevents third parties from guessing it. This randomized reference is a very powerful concept that serves as a privacy-enabling device identifier. Unlike other identifiers discussed in previous section it allows a VSP to easily discover the location server and to reliably determine location for a specific device. When the location recipient fetches up-to-date location information from the location server, it can also be assured that the location information is fresh and not replayed. However, this does not address location swapping.
The target could use this method to advertise a location it has previously visited, which leads to a time-shifting attack.
However, location-by-reference does not offer significant security benefits if the end host uses GPS to determine its location even when the GPS determined location is uploaded to the location server. At best, a network provider can use cell tower or triangulation information to limit the inaccuracy of user-provided location information.
3.3. Proxy adding location
Instead of making location information available to the end host, it is possible to allow an entity at the ISP, or associated with the ISP, to retrieve the location information on behalf of the end point. This solution is possible when the emergency services call setup messages are routed through an entity with the ability to determine the location information of the end point, for example based on the end host’s IP or MAC address.
When the untrustworthy end host does not have the ability to access location information, it cannot modify it either. It also does not provide the host with a mechanism for manually overriding incorrect location provided by the LIS. This is unlikely to work for GPS-based location determination techniques.
The obvious disadvantage of this approach is that there is a need to deploy application layer entities, such as SIP prox-ies, at ISPs or associated with ISPs. This requires a standard-ized VoIP profile to be deployed at every end device and at every ISP, for example, based on SIP. This might impose a cer-tain interoperability challenge. Additionally, the ISP more or less takes the responsibility for emergency calls, even for cus-tomers they have no direct or indirect relationship with. To provide identity information about the emergency caller from the VSP it would be necessary to let the ISP and the VSP to interact for authentication (see, for example, [20]). This inter-action along the Authentication, Authorization and Account-ing infrastructure is often based on business relationships between the involved entities. The ISP and a VSP are very un-likely to have such a business relationship, particularly when talking about an arbitrary VSP somewhere on the Internet. In case that the interaction between the ISP and the VSP fails due to the lack of a business relationship then the procedures described in [21] could become applicable (depending on the regularity of the situation) and typically a fall-back would be provided where no emergency caller identity information is made available to the PSAP and the emergency call still has to be completed.
4.
Operational considerations
4.1. Attribution to a specific trusted sourceThe NENA i2 specification [14] proposes that the LIS becomes the source for distributing location information within an ISP and the validity, integrity and authenticity of this information are directly attributed to the LIS operator.
The following subsections discuss the some of the opera-tional challenges that operators might encounter when pro-viding that functionality.
4.1.1. Validity
In existing networks, such as the PSTN network, where location information is both determined by the ISP/VSP as well as communicated by the ISP/ VSP, responsibility for location validity can be attributed entirely to a single party, namely the ISP/VSP.
As mentioned, on the Internet, not only may the ISP and VSP represent different parties, but location determination may depend on information contributed by parties trusted by neither the ISP nor VSP, or even the operator of the LIS. In such circumstances, mechanisms for enhancing the integrity or authenticity of location data contribute little toward ensuring the validity of that data.
It should be understood that the means by which loca-tion is determined may not necessarily relate to the means by which the end host communicates with the LIS. Just be-cause a Location Configuration Protocol (LCP), the protocol used between the end host and the LIS, operates at a particu-lar layer does not imply that the location data communicated by that protocol is derived solely based on information ob-tained at that layer. In some circumstances, LCP implementa-tions may base their location determination on information gathered from a variety of sources which may merit varying levels of trust, such as information obtained from the calling endpoint, or wiremap information that is time consuming to verify or may rapidly go out of date.
For example, consider the case of a LIS that utilizes LLDP-MED [5] end host move detection notifications in determining the location. Regardless of whether the LIS implementation utilizes an LCP operating above the link layer (such as HELD [15], an application layer protocol), the validity of the location information conveyed would be dependent on the security properties of LLDP-MED [5].
Section 13.3 of [5] defines the endpoint move detection notification as follows: lldpXMedTopologyChangeDetected NOTIFICATION-TYPE OBJECTS { lldpRemChassisIdSubtype, lldpRemChassisId, lldpXMedRemDeviceClass } STATUS current DESCRIPTION
"A notification generated by the local device sensing a change in the topology that indicates a new remote device attached to a local port, or a remote device disconnected or moved from one port to another." ::= { lldpXMedNotifications 1 }
As noted in Section 7.4 of [5], the lldpRemChassisIdSub-type, lldpRemChassisId and lldpXMedRemDeviceClass vari-ables are determined from the Chassis ID (1) and LLDP-MED Device Type Type-Length-Value (TLV) tuples provided within the LLDP advertisement of the calling device. As noted in Section 9.2.3 of [5], all Endpoint Devices use the Network ad-dress ID subtype (5) by default. In order to provide topology change notifications in a timely way, it cannot necessarily be assumed that a Network Connectivity device will validate the network address prior to transmission of the move detection
notification. As a result, there is no guarantee that the net-work address reported by the end host will correspond to that utilized by the device.
The discrepancy need not be due to nefarious reasons. For example, an IPv6-capable endpoint may utilize multiple IPv6 addresses. Similarly, an IPv4-capable endpoint may initially utilize a Link- Local IPv4 address [22] and then may subsequently acquire a DHCP-assigned routable address. All addresses utilized by the end host may not be advertised in LLDP, or even if they are, end host move detection notification may not be triggered, either because no LinkUp/LinkDown notifications occur (e.g., the host adds or changes an address without rebooting) or because these notifications were not detectable by the Network Connectivity device (the endpoint device was connected to a hub rather than directly to a switch).
Similar issues may arise in situations where the LIS utilizes DHCP lease data to obtain location information. Where the endpoint address was not obtained via DHCP (such as via manual assignment, stateless auto-configuration [23] or Link-Local IPv4 self- assignment), no lease information will be available to enable determination of device location. This situation should be expected to become increasingly common as IPv6-capable endpoints are deployed, and Location Configuration Protocol (LCP) interactions occur over IPv6.
Even in scenarios in which the LIS relies on location data obtained from the IP MIB [24] and the Bridge MIB [25], avail-ability of location determination information is not assured. In an enterprise scale network, maintenance of current loca-tion informaloca-tion depends on the ability of the management station to retrieve data via polling of network devices. As the number of devices increases, constraints of network latency and packet loss may make it increasingly difficult to ensure that all devices are polled on a sufficiently frequent interval. In addition, in large networks, it is likely that tables will be large so that when UDP transport is used, query responses will fragment, resulting in increasing packet loss or even dif-ficulties in firewall or NAT traversal.
Furthermore, even in situations where the location data can be presumed to exist and be valid, there may be issues with the integrity of the retrieval process. For example, where the LIS depends on location information obtained from a MIB notification or query, unless SNMPv3 [26] is used, data integrity and authenticity is not assured in transit between the network connectivity device and the LIS.
From these examples, it should be clear that the availabil-ity or validavailabil-ity of location data is a property of the LIS system design and implementation rather than an inherent property of the LCP. As a result, mechanisms utilized to protect the in-tegrity and authenticity of location data do not necessarily provide assurances relating to the validity or provenance of that data.
4.1.2. Location signing
Section 3.7 of [14] includes recommendations relating to location signing, the preferred solution within the NENA i2 specification.
Location determination is out of scope for NENA, but we can offer guidance on what should be considered when designing mechanisms to report location:
2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VoIP Positioning Center (VPC) and Emergency Response Database (ERDB) operators should issue certificates to LIS operators.
3. The signature should include a timestamp.
4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence.
5. Anti-spoofing mechanisms should be applied to the Location Reporting method.
[Note: The term Valid Emergency Services Authority (VESA) refers to the root certificate authority.]
Signing of location objects implies the development of a trust hierarchy that would enable a certificate chain provided by the LIS operator to be verified by the PSAP. Rooting the trust hierarchy in VESA can be accomplished either by having the VESA directly sign the LIS certificates, or by the creation of intermediate CAs certified by the VESA, which will then issue certificates to the LIS. In terms of the workload imposed on the VESA, the latter approach is highly preferable. However, this raises the question of who would operate the intermediate CAs and what the expectations would be.
In particular, the question arises as to the requirements for LIS certificate issuance, and whether they are significantly different from say, requirements for issuance of an SSL/TLS web certificate.
4.1.3. Location by reference (LbyR)
Where location by reference is provided, the recipient needs to deference the LbyR in order to obtain location. With the introduction of location by reference concept two authorization models were developed, see [18], namely the “Authorization by Possession” and “Authorization via Access Control Lists” model. With the “Authorization by Possession” model everyone in possession of the reference is able to obtain the corresponding location information. This might, however, be incompatible with other requirements typically imposed by ISPs, such as location hiding (see [27]). As such, the “Authorization via Access Control Lists” model is likely to be the preferred model for many ISPs and subject for discussion in the subsequent paragraphs.
Just as with Presence Information Data Format-Location Object (PIDF-LO) signing, the operational considerations in managing credentials for use in LbyR dereferencing can be considerable without the introduction of some kind of hierarchy. It does not seem reasonable for a PSAP to manage client certificates or Digest credentials for all the LISs in its coverage area, so as to enable it to successfully dereference LbyRs. In some respects, this issue is even more formidable than the validation of signed PIDF-LOs. While PIDF-LO signing credentials are provided to the LIS operator, in the case of dereferencing, the PSAP needs to obtain credentials compatible with the LIS configuration, a potentially more complex operational problem.
As with PIDF-LO signing, the operational issues of LbyR can be addressed to some extent by introduction of hierarchy. Rather than requiring the PSAP to obtain credentials for accessing each LIS, the local LIS could be required to upload location information to location aggregation points who would in turn manage the relationships with the PSAP. This would shift the management burden from the PSAPs to the location aggregation points.
4.2. Application to a specific point in time
PIDF-LO objects contain a timestamp, which reflects the time at which the location was determined. Even if the PIDF-LO is signed, the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISs. As a result, recipients need to validate the timestamp in order to determine whether it is credible.
4.3. Linkage to a specific endpoint
As noted in Section 6.6 of “HTTP Enabled Location Delivery (HELD)” [15]:
The LIS MUST NOT include any means of identifying the De-vice in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain iden-tity are either omitted or contain unlinked pseudonyms [28]. A unique, unlinked presence URI SHOULD be generated by the LIS for the mandatory presence “entity” attribute of the PIDF document. Optional parameters such as the “contact” element and the “deviceID” element [29] are not used.
Given the restrictions on inclusion of identification infor-mation within the PIDF-LO, it may not be possible for a re-cipient to verify that the entity on whose behalf location was determined represents the same entity conveying location to the recipient.
Where “Enhancements for Authenticated Identity Man-agement in the Session Initiation Protocol (SIP)” [30] is used, it is possible for the recipient to verify the identity assertion in the From: header. However, if PIDF-LO parameters that con-tain identity are omitted or concon-tain an unlinked pseudonym, then it may not be possible for the recipient to verify whether the conveyed location actually relates to the entity identi-fied in the From: header. It is also important to note that SIP Identity does not protect the newly introduced geoloca-tion headers in a SIP message but all payloads in the body of the message. Without protection of the geolocation header lo-cation references (and other geololo-cation related information) inserted by a SIP proxy are unprotected and an attack by a malicious call routing entity cannot be detected.
This lack of binding between the entity obtaining the PIDF-LO and the entity conveying the PIDF-PIDF-LO to the recipient enables cut and paste attacks which would enable an attacker to assert a bogus location, even where both the SIP message and PIDF-LO are signed. As a result, even implementation of both [30] and location signing does not guarantee that location can be tied to a specific endpoint.
5.
Conclusion
Today’s emergency services architecture is already under heavy pressure from the lack of strong identity and the
unfortunate introduction of SIM-less emergency calls. Today a number of efforts are being undertaken to define the next generation emergency services architecture based on IP and SIP. This raises a number of architectural questions and security challenges, see [31,21,27,32]. The separation between Internet Service Provider and Voice Service Provider introduces additional problems.
Presented with the unclear regulatory situation and diffi-cult funding models the transition to a full IP-based emer-gency services environment, particularly for ISPs and VSPs, will take some time. In the meanwhile transition architec-tures are being defined that consider “legacy” end hosts, i.e. end devices that have not been upgraded to support any emergency services functionality.
Unfortunately, this comes at a certain price as mentioned in this article with LIS discovery, location retrieval and emergency call routing as the most difficult problems. As a side effect of the location retrieval function on behalf of the end point, additional privacy and security problems are introduced. The security solutions that are being proposed today, including the most favored location signing approach, do not help to mitigate the threats but may instead not add any additional value but costs.
The authors argue that the usage of a location by refer-ence, as a privacy enabling identifier provided to the end host solves a number of problems (such as the discovery of a LIS at the ISP and the reliable identification of the target) and it serves as a privacy-enabling device identifier.
A reference to location information stored at the LIS does, however, not address all security threats nor can it make the operational challenges of trustworthy location information go away. Hence, the authors furthermore suggest to let the community investigate what a suitable and accomplishable goal of ‘trustworthy location’ can be, considering the operationally costs associated with it.
Finally, the authors urge the community to consider the bigger picture by taking identity information into account. Although identity information is not required for the main functioning of emergency services it serves an important piece of information that can help law enforcement agents in the prosecution of adversaries. The goal of auditability should be the focus in order to provide accountability.
The goal of auditability is to enable an investigator to de-termine the source of a rogue emergency call after the fact. Since such an investigation can rely on audit logs provided under court order, the information available to the investiga-tor could be considerably greater than that present in mes-sages conveyed in the emergency call. As a consequence the emergency caller becomes accountable for his actions. For ex-ample, in such a situation, information relating to the owner of the unlinked pseudonym could be provided to investiga-tors, enabling them to unravel the chain of events that led to the attack. Auditability is likely to be of most benefits in sit-uations where attacks on the emergency services system are likely to be relatively infrequent, since the resources required to pursue an investigation are likely to be considerable.
Where attacks are frequent and continuous, a reliance on non-automated mechanisms is unlikely to be satisfactory. As such, mechanisms to exchange audit trails information in a standardized format between ISPs and PSAPs/VSPs and
PSAPs or heuristics to distinguish potentially fraudulent emergency calls from real emergencies might be valuable for the emergency services community.
R E F E R E N C E S
[1] B. Rosen, Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier, RFC 4967 (Proposed Standard), 2007 (Online). Available: http://www.ietf.org/rfc/ rfc4967.txt.
[2] H. Schulzrinne, The tel URI for Telephone Numbers, RFC 3966 (Proposed Standard), 2004, Updated by RFC 5341 (Online). Available:http://www.ietf.org/rfc/rfc3966.txt.
[3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, SIP: Session Initiation Protocol, RFC 3261 (Proposed Standard), 2002, Updated by RFCs 3265, 3853, 4320, 4916, 5393. (Online). Available:http://www.ietf.org/rfc/rfc3261.txt.
[4] B. Rosen, J. Polk, Best Current Practice for Communications Services in support of Emergency Calling, Internet Engineer-ing Task Force, Internet-Draft draft-ietf-ecrit-phonebcp-05, Jul. 2008, in preparation. (Online). Available:http://www.ietf. org/internet-drafts/draft-ietf-ecrit-phonebcp-05.txt. [5] Telecommunications: IP Telephony Infrastructure: Link Layer
Discovery Protocol for Media Endpoint Devices, ANSI/TIA-1057-2006, Apr. 2006.
[6] (Online). Available:http://www.govtech.com/gt/615493. [7] (Online). Available: http://www.fbi.gov/page2/feb08/
swatting020408.html.
[8] (Online). Available: http://www.eena.org/ressource/static/ files/cocom_table.pdf.
[9] H. Schulzrinne, Location-to-URL Mapping Architecture and Framework, Internet Engineering Task Force, Internet-Draft draft-ietf-ecrit-mapping-arch-03, Sep. 2007, in preparation, (Online). Available: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt.
[10] T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig, LoST: A Location-to-Service Translation Protocol, RFC 5222 (Proposed Standard), Aug. 2008 (Online). Available: http://www.ietf.org/rfc/rfc5222.txt.
[11] J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes, Use of Target Identity in HTTP-Enabled Location Delivery (HELD), Internet Engineering Task Force Internet-Draft draft-winterbottom-geopriv-held-identity-extensions-09, Feb. 2009, in preparation. (Online). Available: http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-09.
[12] M. Thomson, J. Winterbottom, Using Device-provided Location-Related Measurements in Location Configuration Protocols, Internet Engineering Task Force Internet-Draft draft-thomson-geopriv-held-measurements-04, May 2009, in preparation (Online). Available:http://tools.ietf.org/html/ draft-thomson-geopriv-held-measurements-04.
[13] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Extensible Authentication Protocol (EAP), RFC 3748 (Proposed Standard), Jun. 2004, updated by RFC 5247. (Online). Available: http://www.ietf.org/rfc/rfc3748.txt.
[14] 08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2), 2005.
[15] M. Barnes, J. Winterbottom, M. Thomson, B. Stark, HTTP Enabled Location Delivery (HELD), Internet Engineering Task Force, Internet-Draft draft-ietf-geopriv-http-location-delivery-09, Sep. 2008, in preparation (Online). Available: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-09.txt.
[16] J. Polk, B. Rosen, Location Conveyance for the Session Initia-tion Protocol, Internet Engineering Task Force, Internet-Draft
draft-ietf-sip-location-conveyance-10, Sep. 2008, in prepa-ration (Online). Available: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-10.txt.
[17] M. Thomson, J. Winterbottom, Digital Signature Meth-ods for Location Dependability, Internet Engineering Task Force, Internet-Draft draft-winterbottom-geopriv-deref-protocol-02, Jul. 2008, in preparation (Online). Available: http://www.ietf.org/internet-drafts/draft-winterbottom-geop riv-deref-protocol-02.txt.
[18] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, M. Dawson, An HTTPS Location Dereferencing Protocol Using HELD, Internet Engineering Task Force, Internet-Draft draft-winterbottom-geopriv-deref-protocol-02, Jul. 2008, Work in progress (Online). Available: http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-deref-protocol-02.txt. [19] J. Winterbottom, H. Tschofenig, M. Thomson, Establishing
Location URI Contexts using HTTP-Enabled Location Delivery (HELD), Internet Engineering Task Force, Internet-Draft draft-ietf-ecrit-mapping-arch-03, Apr. 2007, in preparation (Online). Available: http://www.ietf.org/internet-drafts/draft-winterbottom-geopriv-held-context-04.txt.
[20] M. Garcia-Martin, M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi, Diameter Session Initiation Protocol (SIP) Application, RFC 4740 (Proposed Standard), Nov. 2006 (Online). Available:http://www.ietf.org/rfc/rfc4740.txt. [21] H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig,
Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices, Internet Engineering Task Force, Internet-Draft draft-schulzrinne-ecrit-unauthenticated-access-03, Jul. 2008, in preparation (Online). Available: http://www.ietf.org/internet- drafts/draft-schulzrinne-ecrit-unauthenticated-access-03.txt.
[22] S. Cheshire, B. Aboba, E. Guttman, Dynamic Configuration of IPv4 Link-Local Addresses, RFC 3927 (Proposed Standard) May 2005. (Online). Available:http://www.ietf.org/rfc/rfc3927.txt. [23] S. Thomson, T. Narten, T. Jinmei, IPv6 Stateless Address
Autoconfiguration, RFC 4862 (Draft Standard), Sep. 2007. (Online). Available:http://www.ietf.org/rfc/rfc4862.txt.
[24] S. Routhier, Management Information Base for the Internet Protocol (IP), RFC 4293 (Proposed Standard), Apr. 2006 (Online). Available:http://www.ietf.org/rfc/rfc4293.txt. [25] K. Norseth, E. Bell, Definitions of Managed Objects for
Bridges, RFC 4188 (Proposed Standard), Sep. 2005. (Online). Available:http://www.ietf.org/rfc/rfc4188.txt.
[26] D. Harrington, R. Presuhn, B. Wijnen, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks, RFC 3411 (Standard), Dec. 2002, updated by RFC 5343 (Online). Available: http://www.ietf.org/rfc/rfc3411.txt.
[27] H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett, Location Hiding: Problem Statement and Requirements, In-ternet Engineering Task Force, InIn-ternet-Draft draft-ietf-ecrit-location-hiding-req-02, Jul. 2009, in preparation (Online). Available: http://tools.ietf.org/html/draft-ietf-ecrit-location-hiding-req-02.txt.
[28] J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk, Geopriv Requirements, RFC 3693 (Informational), Feb. 2004 (Online). Available:http://www.ietf.org/rfc/rfc3693.txt.
[29] J. Rosenberg, A Data Model for Presence, RFC 4479 (Proposed Standard), Jul. 2006. (Online). Available:http://www.ietf.org/ rfc/rfc4479.txt.
[30] J. Peterson, C. Jennings, Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP), RFC 4474 (Proposed Standard), Aug. 2006. (Online). Available: http://www.ietf.org/rfc/rfc4474.txt.
[31] B. Rosen, H. Schulzrinne, J. Polk, A. Newton, Framework for Emergency Calling using Internet Multimedia, Internet Engineering Task Force, Internet-Draft draft-ietf-ecrit-frame-work-06, Jul. 2008, in preparation (Online). Available: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framewo rk-06.txt.
[32] H. Tschofenig, H. Schulzrinne, Emergency Services Ar-chitecture Overview: Sharing Responsibilities, Internet Engineering Task Force Internet-Draft draft-tschofenig-ecrit-architecture-overview-00, Jul. 2007, in preparation (Online). Available: http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-00.txt.
