idnits 2.17.1 draft-barnes-ecrit-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 677. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 533: '...its location, then it MUST include its...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2007) is 6024 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Barnes 3 Internet-Draft M. Lepinski 4 Intended status: Informational BBN Technologies 5 Expires: April 24, 2008 October 22, 2007 7 Fraud mitigation for IP-based emergency calling 8 draft-barnes-ecrit-auth-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The use of Internet technologies for emergency calling creates 42 opportunities for fraud, relative to traditional circuit-switched 43 emergency calling. This document describes the context for IP-based 44 emergency calling, and the types of fraud which are possible within 45 the system. A mitigation strategy for fraud against voice service 46 providers is described; techniques for detecting or preventing other 47 types of fraud will be incorporated in this document as they are 48 available. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Participants in IP-based emergency call establishment . . . . 4 55 4. Fraud risk in IP-based emergency calling . . . . . . . . . . . 5 56 4.1. Callers . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2. VSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.3. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.4. PSAPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.5. Requirements of the LoST Infrastructure . . . . . . . . . 8 61 5. Mitigating Fraud against VSPs . . . . . . . . . . . . . . . . 10 62 5.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 10 63 5.2. Risk at different stages of emergency calling . . . . . . 11 64 5.3. A verification mechanism . . . . . . . . . . . . . . . . . 12 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 72 Intellectual Property and Copyright Statements . . . . . . . . . . 16 74 1. Introduction 76 Entities that participate in emergency calling (e.g., callers, voice 77 networks, or emergency authorities) expose themselves to abuse by 78 fraudulent parties. For example, when voice networks provide special 79 service such as priority or preemption to emergency calls, fraudulent 80 callers could mark non-emergency calls as emergency calls in order to 81 receive special treatment. In the traditional, circuit-switched 82 emergency calling system, the types of fraud that are technically 83 feasible are very limited because the system is very rigid. The 84 transition to a next-generation IP-based emergency calling system has 85 the potential to broaden the spectrum of possible attacks. In order 86 to prevent this, it is necessary to identify the specific fraud risks 87 to which entities in IP-based emergency calling are exposed, and to 88 enhance to the emergency calling system to address these risks. The 89 first step in this process, an analysis of the structure of the 90 emergency calling system from the perspective of fraud risk, is the 91 subject of this document. 93 This document discusses the fraud risks introduced by the transition 94 from the current circuit-switched emergency calling architecture to 95 next-generation, packet-switched emergency calling. After 96 introducing some necessary terminology, we describe the different 97 roles that entities play in the emergency calling process, and the 98 types of fraud to which the entities playing those roles are exposed. 99 As an example of one type of fraud mitigation, we describe a system 100 for voice networks to verify that call signaling that appears to be 101 for an emergency call is actually for an emergency call. 103 2. Terminology 105 Caller - The entity that initiates an emergency call. For purposes 106 of this document, this term includes both the calling party (e.g., a 107 person in distress or a vehicle that has been involved in a 108 collision) and any hardware or software used to initiate the call. 110 Voice Service Provider (VSP) - An entity that provides services that 111 enable IP-based telephony. In the SIP context, a VSP might operate a 112 set of proxies; in the 3GPP/IMS context, a VSP is an IMS network 113 operator. 115 Internet Service Provider (ISP) - An entity that provides 116 connectivity to the Internet to its subscribers. 118 Access Network - An ISP to which a network endpoint is physically 119 attached. An access network will often also act as an LSP. 121 Location Service Provider (LSP) - An entity that provides information 122 about the location of Internet endpoints. In many cases, the LSP 123 used to geolocate an endpoint will be the access network to which it 124 is connected. 126 Public Safety Answering Point (PSAP) - An entity that receives 127 emergency calls. Some PSAPs receive all calls from callers within a 128 specified geographic area; others are dedicated to calls related to 129 specific emergency services. 131 Emergency Services Routing Proxy (ESRP) - A signaling entity that 132 routes calls within the emergency services network. In particular, 133 an ESRP is a part of the emergency services infrastructure, and not 134 operated by a VSP. 136 3. Participants in IP-based emergency call establishment 138 At a high level, there are four steps in emergency call 139 establishment: 141 1. VSP or caller recognizes that a call is an emergency call and 142 tags it with a service URN 144 2. VSP or caller obtains location information from LSP, queries the 145 LoST infrastructure to obtain the PSAP URI, and sends the call to 146 this PSAP URI 148 3. Call is routed through normal signaling channels (possibly via 149 multiple VSPs) to the PSAP 151 4. PSAP receives call and exchanges multimedia with caller 153 At the application layer (ignoring physical and network access 154 providers), there are thus four types of entities that participate in 155 this process: Callers, VSPs, LSPs, and PSAPs. (The LoST 156 infrastructure is a background player, to be discussed below) The 157 process of emergency call establishment in the SIP context is 158 described in detail in [I.D-ietf-ecrit-framework] and 159 [I.D-ietf-ecrit-phonebcp]. The remainder of this section follows the 160 general structure described in those documents, but is not 161 necessarily specific to SIP calling. 163 Callers and VSPs are responsible for recognizing calls as emergency 164 calls and routing calls to the appropriate PSAPs. Once a caller or 165 VSP recognizes that a call is an emergency call, it embeds in the 166 call signaling a service URN to indicate the type of emergency 167 service being requested. There are two steps in the routing of a 168 call: First, the URN for the desired service is combined with 169 information on the location of the caller in a query to the LoST 170 infrastructure, which provides contact information for the 171 appropriate PSAP for that service and location. Second, the call is 172 directed to the PSAP via the normal routing mechanisms for the 173 signaling protocol. In some cases, VSPs will be required to provide 174 special services to signaling and/or media packets related to 175 emergency calls. LSPs provide the location information that is used 176 as an input to LoST in the call routing process. Frequently, the LSP 177 used for emergency calling will be the access network to which the 178 calling endpoint is physically connected, since this network 179 naturally has a physical relationship to the endpoint which can be 180 used to determine the endpoint's location. In other situations, the 181 LSP's role may be played by a positioning function internal to a VSP 182 network, or by an independent location server on which the endpoint's 183 location has been previously stored. It is generally understood that 184 location information will be provided without restriction to 185 appropriate entities for emergency call routing purposes, even when 186 the LSP might otherwise restrict access to that information (e.g., 187 for business or privacy purposes). 189 PSAPs are the recipients of emergency calls. They are responsible 190 for answering emergency calls and using information provided via 191 signaling or media to determine how best to respond to an emergency. 192 Location information is a critical component of this decision. In 193 many cases, the endpoint's location will be carried in the call 194 signaling messages that initiate the emergency call, but the PSAP may 195 also obtain location through other mechanisms. For example, the 196 signaling may contain a reference to an LSP that is able to provide 197 up-to-date information on the location of a mobile endpoint. PSAPs 198 must also discriminate between calls that are genuine emergencies and 199 calls that are not (while all calls are usually answered, callers who 200 call without an emergency may be subject to subsequent investigation 201 or prosecution). 203 4. Fraud risk in IP-based emergency calling 205 Each type of entity described in Section 3 above puts valuable 206 resources at risk by participating in the emergency call- 207 establishment process. VSPs may give priority to emergency calls 208 transiting their network, or allocate bandwidth for them. LSPs need 209 to provide location, which they may be unwilling to give out (due to 210 business or privacy reasons) in a non-emergency setting. PSAPs need 211 to optimize their limited resources for responding to emergency 212 calls. And, most importantly, emergency callers entrust their safety 213 to the proper functioning of the emergency calling infrastructure. 214 This section describes in more detail the requirements that each 215 party has of the others, and discusses how these requirements can be 216 violated by fraudulent actors. This section also briefly discusses 217 how these threats may be addressed, but proposes no complete 218 solutions. The LoST infrastructure is also a central, trusted 219 component of the emergency calling system; we describe below certain 220 assurances that emergency calling entities require of the LoST 221 infrastructure. 223 4.1. Callers 225 Emergency callers generally have more to lose from a failed emergency 226 call than other entities that participate in emergency call 227 establishment, since they are by definition in distress. A caller's 228 primary requirement is to be able to communicate with the appropriate 229 PSAP for their emergency, and to receive any necessary emergency 230 services. In order to receive the requested emergency services as 231 quickly as possible, the caller must be directed to the PSAP that is 232 responsible for the requested service in the caller's current 233 location. This requires that the entity that does LoST routing 234 (whether the caller or a VSP) have access to accurate, timely 235 location, and that LoST routing be done correctly. Once the 236 appropriate PSAP has been identified and contacted, there must be 237 sufficient communications resources available for the caller and the 238 PSAP to exchange any further necessary media or signaling traffic. 239 The fraud risks faced by callers are thus: 241 1. LSPs that provide LoST routing entities with inaccurate location 242 information, or no location information at all 244 2. VSPs that mis-route emergency calls 246 3. VSPs (or ISPs) that restrict the communications resources 247 available for call traffic 249 Fortunately, these risks are all relatively improbable. Users often 250 have business relationships with their LSPs, VSPs, and ISPs that 251 oblige these service providers to provide reliable service. 252 Additionally, these service providers are often subject to legal and 253 regulatory requirements that they faithfully execute their roles in 254 emergency calling. 256 4.2. VSPs 258 By handling emergency calls, VSPs impose additional load on their 259 infrastructure, and by providing priority to emergency call signaling 260 or media traffic (or allocating bandwidth for it), they risk 261 degrading the quality of service experienced by other users. In 262 order to protect their infrastructure, VSPs require assurance that 263 calls receiving special treatment as emergency calls are in fact 264 emergency calls. That is, they require a reliable means for 265 determining which calls are emergency calls. 267 The primary fraud risk for VSPs is that callers will be able to 268 obtain special treatment for non-emergency calls that is usually only 269 provided to emergency calls, i.e., that non-emergency calls will be 270 able to masquerade as emergency calls in order to get special 271 treatment. VSPs thus require reliable mechanisms for verifying that 272 a call is an emergency call. These mechanisms must be reliable in 273 the sense that a call so verified will necessarily be delivered by 274 the signaling system to a PSAP. An example of such a mechanism is 275 described in Section 5 below. 277 4.3. LSPs 279 Location providers have the right to control access to the location 280 information they hold. They may restrict access to location in order 281 to protect users' privacy, or they may do it in order to enable a 282 pay-for-location business model. On the other hand, location 283 providers in many jurisdictions have a legal or regulatory 284 requirement to provide location information for the purpose of 285 routing emergency calls or for directing emergency responders. The 286 primary fraud that concerns an LSP is thus that an entity (a caller 287 or VSP) that would not otherwise have access to location information 288 will be able to obtain it by claiming to need it for emergency 289 purposes. This problem is exacerbated by the fact that LSPs are 290 generally unable to authenticate the entities (e.g. VSPs) that might 291 request location information for LoST routing. This is because while 292 LSPs tend to be physically local entities, serving a specific 293 geographical area, VSPs can handle a call originated anywhere on the 294 Internet. Thus it is not sufficient for an LSP to have relationships 295 with VSPs in its local area, as the callers served by an LSP may use 296 a VSP based in another country, or even on another continent. 298 4.4. PSAPs 300 PSAPs have limited resources to devote to answering emergency calls - 301 in particular, they have a limited number of human call-takers. Many 302 emergencies require emergency responders to be dispatched, often at 303 significant cost. PSAPs need to optimize their limited resources, 304 and ensure to the greatest extent possible that emergency responses 305 are timely and appropriate to the emergency. 307 The two most significant fraud risks to PSAPs are false emergency 308 calls and false location information. A false emergency call is a 309 call placed to a PSAP by a caller who is not in distress. In the 310 current system, these are often prank calls or inadvertently placed 311 calls. In the Internet context, there is a much larger risk that 312 PSAPs will receive a high volume of such false calls, as the process 313 of making a false call can be more easily automated. A high volume 314 of false calls can exhaust the limited resources of the PSAP, causing 315 legitimate calls not to be answered, therefore false calls can be 316 used as a denial of service attack against the PSAP and legitimate 317 emergency callers. 319 Likewise, false location information is location information that 320 points to something other than the location of an ongoing emergency. 321 If a PSAP dispatches first responders based on false location, then 322 these responders may not be available to respond to actual 323 emergencies. While false calls can by definition only be launched by 324 fraudulent callers, false location information can be provided by 325 either callers or LSPs (possibly in collusion with each other). 327 The cost of not responding to a legitamate emergency call is 328 obviously quite high, and so PSAPs generally respond to all emergency 329 calls. Thus, a mechanism for discriminating false calls from 330 legitimate calls is not useful (unless it can be clearly proven not 331 to identify legitimate calls as false ones). Mechanisms that provide 332 reliable information for forensic analysis are preferable, for 333 instance mechanisms that reliably identifying callers for subsequent 334 investigation or prosecution. 336 On the other hand, it is essential to determine whether location 337 information has been falsified before emergency responders are 338 dispatched. This is a more tractable problem: Since PSAPs and LSPs 339 are both inherently local entities, with well-defined geographical 340 coverage areas, PSAPs will likely be able to establish trust 341 relationships with LSPs that serve the same geographical area as the 342 PSAP. These trust relationships can be used together with Internet 343 security technologies to prove that location objects originated from 344 a trusted LSP. 346 4.5. Requirements of the LoST Infrastructure 348 The proper functioning of the emergency calling system depends on the 349 LoST infrastructure having three critical properties: 351 1. Accuracy. Information returned by LoST queries is trusted by all 352 parties to be an accurate reflection of current PSAP assignments. 354 2. Completeness. A URI belongs to an emergency services entity if, 355 and only if, it is returned in a LoST response from an 356 authoritative LoST server. 358 3. Uniformity. If two different entities both submit the same query 359 (within a reasonable period of time), then both queries will 360 return the same results. 362 The LoST mapping architecture as specified in 363 [I.D-ietf-ecrit-mapping-arch] mostly satisfies these requirements. 364 However, there may be limited cases in which it does not, primarily 365 due to territorial disputes or incomplete deployment. The latter can 366 be expected to improve as the LoST infrastructure is more completely 367 deployed; the former is likely to be long-term issue. 369 The accuracy assumption is necessary for the emergency calling system 370 to function at all: If the LoST infrastructure is not trusted then 371 there are much more serious problems than user fraud. (In 372 particular, an attacker could redirect all emergency calls in an area 373 to an attacker controlled fake PSAP.) The completeness and 374 uniformity assumptions mean that the LoST infrastructure can be used 375 to authenticate PSAP URIs. In the absence of an authentication 376 infrastructure for PSAPs, verifying that a URI is returned by a LoST 377 query is a convenient mechanism that provides reasonable assurance 378 that a given URI is a PSAP URI. The completeness and uniformity 379 assumptions may not be valid in the early stages of the deployment of 380 the LoST infrastructure. In particular, a VSP may receive a 381 different answer to a LoST query than the end device (or another LoST 382 routing entity) because either (A) the LoST forest-guide system is 383 incomplete and the VSP's LoST resolver is unable to identify the 384 authoritative tree for a given location; or (B) the location is in a 385 contested region, there are two trees that claim to be authoritative 386 for this region, and the VSP and the device disagree as to which tree 387 has a legitimate claim to represent the region. 389 Fortunately, once the mapping infrastructure is fully deployed (as 390 described in [I.D-ietf-ecrit-mapping-arch]) it should be very rare 391 for a VSP to fail to locate the authoritative tree for a given 392 location. In the meantime, one possible strategy to mitigate this 393 problem is for the device to include in the signaling the 394 element from the LoST response. In such a case, if the VSP fails to 395 locate an authoritative tree for a given location, it can extract the 396 authoritative LoST server from the element in the signaling 397 traffic and query that server to verify that URI belongs to an 398 emergency services entity. Even when the LoST infrastructure is 399 fully deployed, there will likely always be territorial disputes that 400 result in two distinct trees claiming to be authoritative for a given 401 region. However, in most such cases, it is likely that a user will 402 select a VSP that agrees with him as to who legitimately controls a 403 given region. In situations where a user disagrees with his VSP as 404 to which tree is authoritative for a given region, then the VSP will 405 likely not give special consideration to calls destined for a PSAP it 406 deems illegitimate (even if the user deems the PSAP to be 407 legitimate). There can be no technical solution that resolves such a 408 dispute. (For example, it is unlikely that a Israeli VSP will give 409 special treatment to a call destined for a Palestinian PSAP in a 410 contested territory, no matter what protocol specifications we might 411 produce.) 413 5. Mitigating Fraud against VSPs 415 One type of fraud that can reasonably be mitigated is fraud against 416 VSPs, in which callers are able to obtain special services usually 417 reserved for emergency calls by crafting non-emergency calls that 418 look like emergency calls. In this section, we describe a mechanism 419 to mitigate this fraud. Although we describe our solution here in 420 terms of SIP signaling, the same technique could be adapted to other 421 signaling protocols with appropriate semantics. 423 5.1. Problem Statement 425 In the case of the signaling network, fraud occurs when a call is 426 placed to a non-emergency services entity, but signaling elements 427 (e.g. SIP Proxies) believe that that the call is an emergency call. 428 In particular, consider a VSP that provides special preference to 429 emergency calls (e.g. emergency calls are free of charge, or are 430 given high priority access to signaling elements). If a malicious 431 user of such a VSP is able to cause calls to an arbitrary recipient 432 to be treated as emergency calls, then the user could fraudulently 433 gain access to VSP resources. Clearly this is a situation the VSP 434 wishes to avoid. 436 Note that in this document, we are not concerned with non-emergency 437 calls to emergency services entities. Although such calls are also 438 fraudulent, they (1) are very difficult to detect; and (2) have a 439 very limited impact on VSP resource consumption, since they may only 440 be placed to emergency services entities. 442 This system verifies that a call is an emergency call in the sense 443 that it is structured as an emergency call described in 444 [I.D-ietf-ecrit-phonebcp], and it is directed to a PSAP URI. The 445 structural verification is performed simply be examining the contents 446 of the SIP INVITE message. Verifying that a given URI is a PSAP URI 447 is done via a LoST query, so this mechanism depends heavily on the 448 above-listed assumptions about the LoST infrastructure. If LoST 449 information can be manipulated by an attacker, then he can thwart 450 this verification procedure by making any URI look like a PSAP URI. 451 If there are PSAPs who are not listed in the LoST infrastructure, 452 then this system will not be able to verify that their URIs are PSAP 453 URIs, and will not regard calls to them as emergency calls. And if 454 different entities receive different answers to the same query, then 455 there is a risk that the entity that the query that is used to verify 456 the PSAP URI will return a different result than the one used to find 457 the PSAP URI in the first place. 459 5.2. Risk at different stages of emergency calling 461 Recall that in the ECRIT framework for emergency calling, there are 462 three distinct stages of an emergency call. The three stages and 463 their corresponding markings are listed below: 465 1. The call has not been recognized as an emergency call (and has 466 therefore has also not been routed). 468 The Request-URI of the call contains a Dial String URI. 470 2. The call has been recognized as an emergency call but has not 471 been routed. 473 The Request-URI of the call contains an appropriate emergency 474 services URN. 476 3. The call has been recognized as an emergency call and has been 477 routed via the LoST protocol. 479 The Request-URI of the call contains an appropriate emergency 480 services URN and the Route header contains the URI of PSAP. 482 Note that in the context of fraud targeting the VSP, there is only 483 risk of fraud when the VSP receives a call in the third of these 484 stages. 486 When a VSP receives a call in the first stage, it will attempt to 487 recognize the dial string as a valid emergency dial string. If the 488 recognition is successful it will process the call as it would 489 process a second-stage call and thus there is no opportunity for 490 fraud. 492 When a VSP receives a call in the second stage, the VSP will make a 493 LoST query (which will return a valid PSAP URI) and the VSP will 494 proceed to route the call to this URI. Therefore, there is no 495 opportunity for fraud. 497 The possibility of fraud only exists when the VSP receives a call in 498 the third stage. In such a case, the URI in the route header may or 499 may not be a valid PSAP URI returned by LoST query. Therefore, to 500 prevent fraud against the VSP it suffices to ensure that a VSP can 501 verify that the URI in the route header of a third-stage call is a 502 valid PSAP URI returned by a LoST query. Note that this problem is 503 tractable becuase in order for a VSP to receive a third-stage call, 504 some upstream signaling entity must possess location information of 505 sufficient precision for use with LoST, and this location can be used 506 by the VSP (in conjunction with the LoST infrastructure) to verify 507 the validity of the URI in the Route header. A mechanism for 508 performing such verification is described in the next section. 510 5.3. A verification mechanism 512 Here we propose a signaling mechanism for emergency calls that have 513 been recognized and routed (see Section 5.2) that allows a VSP to 514 verification that the URI in the Route header is a valid PSAP URI 515 (returned by a LoST query). 517 Note that we are not proposing that VSPs reject emergency calls that 518 fail verification (or are not marked using this mechanism). Instead 519 the failure of verification or the absence of this mechanism may be 520 used as an indication of possible fraud. Further (forensic) analysis 521 may be necessary to determine that fraud did indeed occur. 522 Nonetheless, this mechanism should be useful to detect large scale 523 fraud and take appropriate action. 525 In describing our mechanism, we distinguish the following two cases: 526 (1) the emergency call is routed by the calling device; and (2) the 527 emergency call is routed by a SIP proxy. These two cases differ 528 slightly in the actions perfromed by the entity who does the call 529 routing. However, the verification procedure performed by the VSP is 530 identical in both cases. 532 When the emergency call is routed by the calling device, if the 533 calling device has access to its location, then it MUST include its 534 location (either by value or by reference) in a geolocation header 535 [I.D-ietf-sip-location-conveyance] in the SIP INVITE used to initiate 536 the emergency call. This geolocation header must include the "used- 537 for-routing" parameter. If the calling device does not have access 538 to its location, then it must include the PSAP service area boundary 539 (returned by LoST) in the body of the SIP INVITE. This boundary must 540 be referenced by a SIP geolocation header and that header must 541 contain the "used-for-routing" parameter. 543 When the emergency call is routed by a SIP proxy, if the calling 544 device's location is already present in the SIP INVITE, then the 545 proxy must add the "used-for-routing" parameter to the appropriate 546 geolocation header. If the calling device's location is not present 547 in the SIP INVITE, then the proxy must add a geolocation header 548 containing either a reference to the device's location, or else a 549 reference to the PSAP service area boundary (returned by LoST). This 550 geolocation header must include the "used-for-routing" parameter. 551 This reference must be able to be dereferenced by any entity on the 552 public internet. If the SIP proxy possesses an appropriate, 553 universally-dereferencable reference to the device's location or the 554 PSAP service area boundary, it may use this reference in the 555 geolocation header. However, if the SIP proxy does not possess an 556 appropriate reference, then it must create a new reference to either 557 the location of the calling device or the service boundary of the 558 PSAP. Note that this requires the SIP proxy (or another machine in 559 the domain of the SIP proxy) to maintain state for the lifetime of 560 this newly created location reference (which should not be less than 561 several minutes). This introduces the possibility of a denial of 562 service attack against the SIP proxy in which an entities served by 563 the SIP proxy make a large number of emergency calls to exhaust the 564 storage available for maintaining such reference bindings. 565 Therefore, it is recommended that the SIP proxy creates references to 566 PSAP service boundaries and not device locations, since these service 567 bondary references can be reused whenever the SiP proxy routes 568 multiple calls to the same PSAP. 570 We now describe the actions taken to verify that a (previously 571 recognized and routed) emergency call is being routed to a valid PSAP 572 URI. Upon receiving a SIP INVITE for such a call, the VSP does the 573 following: 575 o Examine the Request-URI header to obtain a service URN. If the 576 Request-URI header does not contain a service URN then 577 verification fails. (Note that service URNs act as universal 578 identifiers for emergency calls, and any call that has been 579 recognized as an emergency call must be tagged with a service URN 580 in the Request-URI header [I.D-ietf-ecrit-phonebcp].) 582 o Examine the SIP headers and attempt to find a geolocation header 583 containing the "used-for-routing" parameter. If such a 584 geolocation header does not exist then verification fails. 586 o If the geolocation header contains a location reference, attempt 587 to dereference the reference to obtain a location object. If the 588 deference fails then verification fails. Otherwise, if the 589 location is included by-value then obtain the location object from 590 the body of the SIP message. 592 o If the location object is a point, then make a LoST query using 593 that point and the service URN from the Request-URI header to 594 obtain a PSAP URI. If the location object is a service boundary, 595 then make a LoST query using an arbitrary point within the 596 boundary and the URN from the Request-URI header to obtain a PSAP 597 URI. 599 o Compare the PSAP URI obtained from the LoST query to the URI in 600 the Route header. If the two URIs do not match, then verification 601 fails. If the two URIs do match, then verification succeeds. 603 6. Acknowledgements 605 This template was derived from an initial version written by Pekka 606 Savola and contributed by him to the xml2rfc project.. 608 7. Security Considerations 610 This document outlines a mechanism for the mitigation fraud against 611 VSPs with respect to IP-based emergency calls. The trust model and 612 the security concerns related to the mechanism are presented in the 613 appropriate sections. 615 8. IANA Considerations 617 This document makes no request of IANA. 619 9. References 621 9.1. Normative References 623 [I.D-ietf-ecrit-framework] 624 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 625 "Framework for Emergency Calling using Internet 626 Multimedia", September 2007. 628 [I.D-ietf-ecrit-phonebcp] 629 Rosen, B. and J. Polk, "Best Current Practice for 630 Communications Services in support of Emergency Calling", 631 September 2007. 633 [I.D-ietf-sip-location-conveyance] 634 Polk, J. and B. Rosen, "Location Conveyance for the 635 Session Initiation Protocol", July 2007. 637 9.2. Informative References 639 [I.D-ietf-ecrit-mapping-arch] 640 Schulzrinne, H., "Location-to-URI Mapping Architecture and 641 Framework", September 2007. 643 Authors' Addresses 645 Richard Barnes 646 BBN Technologies 647 9861 Broken Land Pkwy, Suite 400 648 Columbia, MD 21046 649 USA 651 Phone: +1 410 290 6169 652 Email: rbarnes@bbn.com 654 Matt Lepinski 655 BBN Technologies 656 10 Moulton St 657 Cambridge, MA 02138 658 USA 660 Phone: +1 617 873 5939 661 Email: mlepinski@bbn.com 663 Full Copyright Statement 665 Copyright (C) The IETF Trust (2007). 667 This document is subject to the rights, licenses and restrictions 668 contained in BCP 78, and except as set forth therein, the authors 669 retain all their rights. 671 This document and the information contained herein are provided on an 672 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 673 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 674 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 675 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 676 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 677 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 679 Intellectual Property 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org. 703 Acknowledgment 705 Funding for the RFC Editor function is provided by the IETF 706 Administrative Support Activity (IASA).