idnits 2.17.1 draft-schulzrinne-ecrit-unauthenticated-access-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-12 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-09 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-09 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-15 == Outdated reference: A later version (-10) exists of draft-winterbottom-geopriv-held-identity-extensions-09 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia University 4 Intended status: Standards Track S. McCann 5 Expires: January 14, 2010 Siemens/Roke Manor Research 6 G. Bajko 7 Nokia 8 H. Tschofenig 9 Nokia Siemens Networks 10 July 13, 2009 12 Extensions to the Emergency Services Architecture for dealing with 13 Unauthenticated and Unauthorized Devices 14 draft-schulzrinne-ecrit-unauthenticated-access-05.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 14, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 The IETF emergency services architecture assumes that the calling 53 device has acquired rights to use the access network or that no 54 authentication is required for the access network, such as for public 55 wireless access points. Subsequent protocol interactions, such as 56 obtaining location information, learning the address of the Public 57 Safety Answering Point (PSAP) and the emergency call itself are 58 largely decoupled from the underlying network access procedures. 60 In some cases, the device does not have credentials for network 61 access, does not have a VoIP provider, or the credentials have become 62 invalid, e.g., because the user has exhausted their prepaid balance 63 or the account has expired. 65 This document provides a problem statement, introduces terminology 66 and describes an extension for the base IETF emergency services 67 architecture to address these scenarios. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. No Access Authorization (NAA) . . . . . . . . . . . . . . 5 73 1.2. No VoIP Service Provider (NVP) . . . . . . . . . . . . . . 6 74 1.3. Zero-Balance VoIP Service Provider (ZBP) . . . . . . . . . 6 75 2. A Warning Note . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4. Considerations for ISPs to support Unauthenticated 78 Emergency Services without Architecture Extensions . . . . . . 7 79 5. Considerations for ISPs to support Unauthenticated 80 Emergency Services with Architecture Extensions . . . . . . . 8 81 6. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 12 83 6.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 12 84 6.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 12 85 6.1.3. Location Determination and Location Configuration . . 12 86 6.1.4. Emergency Call Identification . . . . . . . . . . . . 12 87 6.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 13 88 6.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 13 89 6.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 13 90 6.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 13 91 6.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 13 92 6.2.2. Location Determination and Location Configuration . . 13 93 6.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 14 94 6.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 14 95 6.3.2. Emergency Call Identification . . . . . . . . . . . . 14 96 6.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 14 97 6.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 14 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 106 1. Introduction 108 Summoning police, the fire department or an ambulance in emergencies 109 is one of the fundamental and most-valued functions of the telephone. 110 As telephone functionality moves from circuit-switched telephony to 111 Internet telephony, its users rightfully expect that this core 112 functionality will continue to work at least as well as it has for 113 the older technology. New devices and services are being made 114 available that could be used to make a request for help, which are 115 not traditional telephones, and users are increasingly expecting them 116 to be used to place emergency calls. 118 Roughly speaking, the IETF emergency services architecture (see 119 [I-D.ietf-ecrit-phonebcp] and [I-D.ietf-ecrit-framework]) divides 120 responsibility for handling emergency calls between the access 121 network (ISP), the VoIP service provider (VSP) and the provider of 122 emergency signaling services, the emergency service network (ESN). 123 The access network may provide location information to end systems, 124 but does not have to provide any VoIP signaling functionality. The 125 emergency caller can reach the ESN either directly or through the 126 VoIP provider's outbound proxy. Any of the three parties can provide 127 the mapping from location to PSAP URI by offering LoST [RFC5222] 128 services. 130 In general, a set of automated configuration mechanisms allows a 131 device to function in a variety of architectures, without the user 132 being aware of the details on who provides location, mapping services 133 or call routing services. However, if emergency calling is to be 134 supported when the calling device lacks access network authorization 135 or does not have a VoIP provider, one or more of the providers may 136 need to provide additional services and functions. 138 In all cases, the end device MUST be able to perform a LoST lookup 139 and otherwise conduct the emergency call in the same manner as when 140 the three exceptional conditions discussed below do not apply. 142 We distinguish between three conditions: 144 No access authorization (NAA): The current access network requires 145 access authorization and the caller does not have valid user 146 credentials. (This includes the case where the access network 147 allows pay-per-use, as is common for wireless hotspots, but there 148 is insufficient time to pay for access.) 150 No VoIP provider (NVP): The caller does not have a VoIP service 151 provider (VSP) at the time of the call. 153 Zero-balance VoIP provider (ZBP): The caller has valid credentials 154 with a VSP, but is not allowed to place calls, e.g., because the 155 user has a zero balance in a prepaid account. 157 A user may well suffer from both NAA and NVP or ZBP at the same time. 158 Depending on local policy and regulations, it may not be possible to 159 place emergency calls in the NAA case. Unless local regulations 160 require user identification, it should always be possible to place 161 calls in the NVP case, with minimal impact on the ISP. Unless the 162 ESN requires that all calls traverse a known set of VSPs, a caller 163 should be able to place an emergency call in the ZBP case. We 164 discuss each case in separate sections below. 166 1.1. No Access Authorization (NAA) 168 In the NAA (No Access Authorization) case, the emergency caller does 169 not posses valid credentials for the access network. If local 170 regulations or policy allows or require, the access network may or 171 needs to cooperate in providing emergency calling services. 172 Generally, the ISP will want to ensure that devices do not pretend to 173 place emergency calls, but then abuse the access for obtaining more 174 general services fraudulently. 176 In particular, the ISP MUST allow emergency callers to acquire an IP 177 address and to reach a LoST server, either provided by the ISP or 178 some third party. It SHOULD also provide location information via 179 one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without 180 requiring authorization unless it can safely assume that all nodes in 181 the access network can determine their own location, e.g., via GPS. 183 The details of how filtering is performed depends on the details of 184 the ISP architecture and are beyond the scope of this document. We 185 illustrate a possible model. If the ISP runs its own LoST server, it 186 would maintain an access control list including all IP addresses 187 contained in responses returned by the LoST server, as well as the 188 LoST server itself. (It may need to translate the domain names 189 returned to IP addresses and hope that the resolution captures all 190 possible DNS responses.) Since the media destination addresses are 191 not predictable, the ISP also has to provide a SIP outbound proxy so 192 that it can determine the media addresses and add those to the filter 193 list. 195 1.2. No VoIP Service Provider (NVP) 197 In the second case, the emergency caller has no current VoIP service 198 provider (VSP). This case poses no particular difficulties unless it 199 is assumed that only VSPs provide LoST server or that ESNs only 200 accept calls that reach it through a set of known VSPs. However, 201 since the calling device cannot obtain configuration information from 202 its VSP, the ISP MUST provide the address of a LoST server via DHCP 203 [RFC5223] if this model is to be supported. The LoST server may be 204 operated either by the ISP or a third party. 206 1.3. Zero-Balance VoIP Service Provider (ZBP) 208 In the case of zero-balance VoIP service provider, the VSP can 209 authenticate the caller, but the caller is not authorized to place 210 regular VoIP calls, e.g., because the contract has expired or the 211 prepaid account for the customer has been depleted. Naturally, a VSP 212 can simply disallow access by such customers, so that all such 213 customers find themselves in the NVP situation described above. If 214 VSPs desire or are required by regulation to provide emergency 215 calling services to such customers, they need to provide LoST 216 services to such customers and may need to provide outbound SIP proxy 217 services. As usual, the calling device looks up the LoST server via 218 SIP configuration. 220 Unless the emergency call traverses a PSTN gateway or the VSP charges 221 for IP-to-IP calls, there is little potential for fraud. If the VSP 222 also operates the LoST server, the outbound proxy MAY restrict 223 outbound calls to the SIP URIs returned by the LoST server. It is 224 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 225 change. 227 2. A Warning Note 229 At the time of writing there is no regulation in place that demands 230 the functionality described in this memo. SDOs have started their 231 work on this subject in a proactive fashion in the anticipation that 232 national regulation will demand it for a subset of network 233 environments. 235 There are also indications that the functionality of unauthenticated 236 emergency calls (called SIM-less calls) in today's cellular system in 237 certain countries leads to a fair amount of hoaks or test calls. 238 This causes overload situations at PSAPs with . 240 As an example, Federal Office of Communications (OFCOM, 241 Switzerland) provided statistics about 112 calls in Switzerland 242 from Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less 243 emergency calls except for almost a month in July 2000 where a 244 significant increase in hoaks and test calls was reported. As a 245 consequence, the functionality was disabled again. More details 246 can be found in the panel presentations of the 3rd SDO Emergency 247 Services Workshop [esw07]. 249 3. Terminology 251 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 252 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 253 and "OPTIONAL" are to be interpreted as described in RFC 2119 254 [RFC2119]. 256 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] 257 and [RFC5012], namely Internet Access Provider (IAP), Internet 258 Service Provider (ISP), Application Service Provider (ASP), Voice 259 Service Provider (VSP), Emergency Service Routing Proxy (ESRP), 260 Public Safety Answering Point (PSAP), Location Configuration Server 261 (LCS), (emergency) service dial string, and (emergency) service 262 identifier. 264 4. Considerations for ISPs to support Unauthenticated Emergency 265 Services without Architecture Extensions 267 On a very high-level, the steps to be performed by an end host not 268 being attached to the network and the user starting to make an 269 emergency call are the following: 271 o Some radio networks have added support for unauthenticated 272 emergency access, some other type of networks advertise these 273 capabilities using layer beacons. The end host learns about these 274 unauthenticated emergency services capabilities either from the 275 link layer type or from advertisement. 276 o The end host uses the link layer specific network attachment 277 procedures defined for unauthenticated network access in order to 278 get access to emergency services. 279 o When the link layer network attachment procedure is completed the 280 end host learns basic configuration information using DHCP from 281 the ISP, including the address of the LoST server. 282 o The end host MUST use a Location Configuration Protocol (LCP) 283 supported by the IAP or ISP to learn its own location. 285 o The end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] to 286 query the LoST server and ask for the PSAP URI responsible for 287 that location. 288 o After the PSAP URI has been returned to the end host, the SIP UA 289 in the end host directly initiates a SIP INVITE towards the PSAP 290 URI. 292 The IAP and the ISP will probably want to make sure that the claimed 293 emergency caller indeed performs an emergency call rather than using 294 the network for other purposes, and thereby acting fraudulent by 295 skipping any authentication, authorization and accounting procedures. 296 By restricting access of the unauthenticated emergency caller to the 297 LoST server and the PSAP URI, traffic can be restricted only to 298 emergency calls. 300 Using the above procedures, the unauthenticated emergency caller will 301 be successful only if: 303 o the ISP (or the IAP) support an LCP that the end host can use to 304 learn its location. A list of mandatory-to-implement LCPs can be 305 found in [I-D.ietf-ecrit-phonebcp]). 306 o the ISP configures it's firewalls appropriately to allow emergency 307 calls to traverse the network towards the PSAP. 309 Some IAPs/ISPs may not be able to fulfill the above requirements. If 310 those IAPs/ISPs want to support unauthenticated emergency calls, then 311 they can deploy an extended architecture as described in Section 5. 313 5. Considerations for ISPs to support Unauthenticated Emergency 314 Services with Architecture Extensions 316 For unauthenticated emergency services support it is insufficient to 317 provide mechanisms only at the link layer in order to bypass 318 authentication for the cases when: 320 o the IAP/ISP does not support any Location Configuration Protocol 321 o the IAP/ISP does not have knowledge of a LoST server (which would 322 assist the client to find the correct PSAP) 324 A modification to the emergency services architecture is necessary 325 since the IAP and the ISP need to make sure that the claimed 326 emergency caller indeed performs an emergency call rather than using 327 the network for other purposes, and thereby acting fraudulent by 328 skipping any authentication, authorization and accounting procedures. 329 Hence, without introducing some understanding of the specific 330 application the ISP (and consequently the IAP) will not be able to 331 detect and filter malicious activities. This leads to the 332 architecture described in Figure 1 where the IAP needs to implement 333 extensions to link layer procedures for unauthenticated emergency 334 service access and the ISP needs to deploy emergency services related 335 entities used for call routing, such as the Emergency Services 336 Routing Proxy (ESRP), a Location Configuration Server (LCS) and a 337 mapping database. 339 On a very high-level, the interaction is as follows starting with the 340 end host not being attached to the network and the user starting to 341 make an emergency call. 343 o Some radio networks have added support for unauthenticated 344 emergency access, some other type of networks advertise these 345 capabilities using layer beacons. The end host learns about these 346 unauthenticated emergency services capabilities either from the 347 link layer type or from advertisement. 348 o The end host uses the link layer specific network attachment 349 procedures defined for unauthenticated network access in order to 350 get access to emergency services. 351 o When the link layer network attachment procedure is completed the 352 end host learns basic configuration information using DHCP from 353 the ISP, including the address of the ESRP, as shown in (2). 354 o When the IP address configuration is completed then the SIP UA 355 initiates a SIP INVITE towards the indicated ESRP, as shown in 356 (3). The INVITE message contains all the necessary parameters 357 required by Section 6.1.5. 358 o The ESRP receives the INVITE and processes it according to the 359 description in Section 6.3.3. The location of the end host may 360 need to be determined using a protocol interaction shown in (4). 361 o Potentially, an interaction between the LCS of the ISP and the LCS 362 of the IAP may be necessary, see (5). 363 o Finally, the correct PSAP for the location of the end host has to 364 be evaluated, see (6). 365 o The ESRP routes the call to the PSAP, as shown in (7). 366 o The PSAP evaluates the initial INVITE and aims to complete the 367 call setup. 368 o Finally, when the call setup is completed media traffic can be 369 exchanged between the PSAP and the emergency caller. 371 For editorial reasons the end-to-end SIP and media exchange between 372 the PSAP and SIP UA are not shown in Figure 1. 374 Two important aspects are worth to highlight: 376 o The IAP/ISP needs to understand the concept of emergency calls and 377 the SIP profile described in this document. No other VoIP 378 protocol profile, such as XMPP, Skype, etc., are supported for 379 emergency calls in this particular architecture. Other profiles 380 may be added in the future, but the deployment effort is enormous 381 since they have to be universally deployed. 382 o The end host has no obligation to determine location information. 383 It may attach location information if it has location available 384 (e.g., from a GPS receiver). 386 Figure 1 shows that the ISP needs to deploy SIP-based emergency 387 services functionality. It is important to note that the ISP itself 388 may outsource the functionality by simply providing access to them 389 (e.g., it puts the IP address of an ESRP or a LoST server into an 390 allow-list). For editorial reasons this outsourcing is not shown. 392 +---------------------------+ 393 | | 394 | Emergency Network | 395 | Infrastructure | 396 | | 397 | +----------+ +----------+ | 398 | | PSAP | | ESRP | | 399 | | | | | | 400 | +----------+ +----------+ | 401 +-------------------^-------+ 402 | 403 | (7) 404 +------------------------+-----------------------+ 405 | ISP | | 406 | | | 407 |+----------+ v | 408 || Mapping | (6) +----------+ | 409 || Database |<----->| ESRP / | | 410 |+----------+ | SIP Proxy|<-+ | 411 |+----------+ +----------+ | +----------+| 412 || LCS-ISP | ^ | | DHCP || 413 || |<---------+ | | Server || 414 |+----------+ (4) | +----------+| 415 +-------^-------------------------+-----------^--+ 416 +-------|-------------------------+-----------|--+ 417 | IAP | (5) | | | 418 | V | | | 419 |+----------+ | | | 420 || LCS-IAP | +----------+ | | | 421 || | | Link | |(3) | | 422 |+----------+ | Layer | | | | 423 | | Device | | (2)| | 424 | +----------+ | | | 425 | ^ | | | 426 | | | | | 427 +------------------------+--------+-----------+--+ 428 | | | 429 (1)| | | 430 | | | 431 | +----+ | 432 v v | 433 +----------+ | 434 | End |<-------------+ 435 | Host | 436 +----------+ 438 Figure 1: Overview 440 It is important to note that a single ESRP may also offer it's 441 service to several ISPs. 443 6. Profiles 445 6.1. End Host Profile 447 6.1.1. LoST Server Discovery 449 The end host MAY attempt to use [I-D.ietf-ecrit-lost] to discover a 450 LoST server. If that attempt fails, the end host SHOULD attempt to 451 discover the address of an ESRP. 453 6.1.2. ESRP Discovery 455 The end host only needs an ESRP when location configuration or LoST 456 server discovery fails. If that is the case, then the end host MUST 457 use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option 458 for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6) 459 and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options 460 for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover 461 the address of an ESRP. This SIP proxy located in the ISP network 462 will be used as the ESRP for routing emergency calls. There is no 463 need to discovery a separate SIP proxy with specific emergency call 464 functionality since the internal procedure for emergency call 465 processing is subject of ISP internal operation. 467 6.1.3. Location Determination and Location Configuration 469 The end host SHOULD attempt to use the supported LCPs to configure 470 its location. If no LCP is supported in the end host or the location 471 configuration is not successful, then the end host MUST attempt to 472 discover an ESRP, which would assist the end host in providing the 473 location to the PSAP. 475 The SIP UA in the end host SHOULD attach the location information in 476 a PIDF-LO [RFC4119] when making an emergency call. When constructing 477 the PIDF-LO the guidelines in PIDF-LO profile 478 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. For civic 479 location information the format defined in [RFC5139] MUST be 480 supported. 482 6.1.4. Emergency Call Identification 484 To determine which calls are emergency calls, some entity needs to 485 map a user entered dialstring into this URN scheme. A user may 486 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 487 mapping SHOULD be performed at the endpoint device. 489 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 490 as emergency calls for their home emergency dial string (if known). 491 For visited emergency dial string the translation into the Service 492 URN mechanism is not mandatory since the ESRP in the ISPs network 493 knows the visited emergency dial strings. 495 6.1.5. SIP Emergency Call Signaling 497 SIP signaling capabilities [RFC3261] are mandated for end hosts. 499 The initial SIP signaling method is an INVITE. The SIP INVITE 500 request MUST be constructed according to the requirements in Section 501 9.2 [I-D.ietf-ecrit-phonebcp]. 503 Regarding callback behavior SIP UAs MUST have a globally routable URI 504 in a Contact: header. 506 6.1.6. Media 508 End points MUST comply with the media requirements for end points 509 placing an emergency call found in Section 14 of 510 [I-D.ietf-ecrit-phonebcp]. 512 6.1.7. Testing 514 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully 515 applicable to this document. 517 6.2. IAP/ISP Profile 519 6.2.1. ESRP Discovery 521 An ISP hosting an ESRP MUST implement the server side part of 522 "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for 523 Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and / 524 or the "Dynamic Host Configuration Protocol (DHCPv6) Options for 525 Session Initiation Protocol (SIP) Servers" [RFC3319]. 527 6.2.2. Location Determination and Location Configuration 529 The ISP not hosting an ESRP MUST support at least one widely used 530 LCP. The ISP hosting an ESRP MUST perform the neccesary steps to 531 determine the location of the end host. It is not necessary to 532 standardize a specific mechanism. 534 The role of the ISP is to operate the LIS. The usage of HELD 536 [I-D.ietf-geopriv-http-location-delivery] with the identity 537 extensions [I-D.winterbottom-geopriv-held-identity-extensions] may be 538 a possible choice. It might be necessary for the ISP to talk to the 539 IAP in order to determine the location of the end host. The work on 540 LIS-to-LIS communication may be relevant, see 541 [I-D.winterbottom-geopriv-lis2lis-req]. 543 6.3. ESRP Profile 545 6.3.1. Emergency Call Routing 547 The ESRP must route the emergency call to the PSAP responsible for 548 the physical location of the end host. However, a standardized 549 approach for determining the correct PSAP based on a given location 550 is useful but not mandatory. 552 For cases where a standardized protocol is used LoST 553 [I-D.ietf-ecrit-lost] is a suitable mechanism. 555 6.3.2. Emergency Call Identification 557 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 558 the 'urn:service:sos' tree) and additionally the national emergency 559 dial strings. The ESRP SHOULD perform a mapping of national 560 emergency dial strings to Service URNs to simplify processing at 561 PSAPs. 563 6.3.3. SIP Emergency Call Signaling 565 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 566 ESRP MUST process the messages sent by the client, according to 567 Section 6.1.5. Furthermore, the ESRP MUST be able to add a reference 568 to location information, as described in SIP Location Conveyance 569 [I-D.ietf-sip-location-conveyance], before forwarding the call to the 570 PSAP. The ISP MUST be prepared to receive incoming dereferencing 571 requests to resolve the reference to the location information. 573 6.3.4. Location Retrieval 575 The ESRP acts a location recipient and the usage of HELD 576 [I-D.ietf-geopriv-http-location-delivery] with the identity 577 extensions [I-D.winterbottom-geopriv-held-identity-extensions] may be 578 a possible choice. The ESRP would thereby act as a HELD client and 579 the corresponding LIS at the ISP as the HELD server. 581 The ESRP needs to obtain enough information to route the call. The 582 ESRP itself, however, does not necessarily need to process location 583 information obtained via HELD since it may be used as input to LoST 584 to obtain the PSAP URI. 586 7. Security Considerations 588 The security threats discussed in [RFC5069] are applicable to this 589 document. A number of security vulnerabilities discussed in 590 [I-D.barnes-geopriv-lo-sec] around faked location information are 591 less problematic in this case since location information does not 592 need to be provided by the end host itself or it can be verified to 593 fall within a specific geographical area. 595 There are a couple of new vulnerabilities raised with unauthenticated 596 emergency services since the PSAP operator does is not in possession 597 of any identity information about the emergency call via the 598 signaling path itself. In countries where this functionality is used 599 for GSM networks today this has lead to a significant amount of 600 misuse. 602 The link layer mechanisms need to provide a special way of handling 603 unauthenticated emergency services. Although this subject is not a 604 topic for the IETF itself but there are at least a few high-level 605 assumptions that may need to be collected. This includes security 606 features that may be desirable. 608 8. Acknowledgments 610 Section 6 of this document is derived from [I-D.ietf-ecrit-phonebcp]. 611 The WiMax Forum contributed parts of the terminology. Participants 612 of the 2nd and 3rd SDO Emergency Services Workshop provided helpful 613 input. 615 9. IANA Considerations 617 This document does not require actions by IANA. 619 10. References 621 10.1. Normative References 623 [I-D.ietf-sip-location-conveyance] 624 Polk, J. and B. Rosen, "Location Conveyance for the 625 Session Initiation Protocol", 626 draft-ietf-sip-location-conveyance-13 (work in progress), 627 March 2009. 629 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 630 Emergency and Other Well-Known Services", RFC 5031, 631 January 2008. 633 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 634 Format", RFC 4119, December 2005. 636 [I-D.ietf-geopriv-pdif-lo-profile] 637 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 638 PIDF-LO Usage Clarification, Considerations and 639 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 640 (work in progress), November 2008. 642 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 643 Format for Presence Information Data Format Location 644 Object (PIDF-LO)", RFC 5139, February 2008. 646 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 647 (DHCP-for-IPv4) Option for Session Initiation Protocol 648 (SIP) Servers", RFC 3361, August 2002. 650 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 651 Protocol (DHCPv6) Options for Session Initiation Protocol 652 (SIP) Servers", RFC 3319, July 2003. 654 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 655 A., Peterson, J., Sparks, R., Handley, M., and E. 656 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 657 June 2002. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [I-D.ietf-ecrit-phonebcp] 663 Rosen, B. and J. Polk, "Best Current Practice for 664 Communications Services in support of Emergency Calling", 665 draft-ietf-ecrit-phonebcp-12 (work in progress), 666 July 2009. 668 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 669 Tschofenig, "LoST: A Location-to-Service Translation 670 Protocol", RFC 5222, August 2008. 672 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 673 Location-to-Service Translation (LoST) Servers Using the 674 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 675 August 2008. 677 10.2. Informative References 679 [I-D.ietf-ecrit-lost] 680 Hardie, T., Newton, A., Schulzrinne, H., and H. 681 Tschofenig, "LoST: A Location-to-Service Translation 682 Protocol", draft-ietf-ecrit-lost-10 (work in progress), 683 May 2008. 685 [I-D.ietf-geopriv-l7-lcp-ps] 686 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 687 Location Configuration Protocol; Problem Statement and 688 Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in 689 progress), February 2009. 691 [I-D.ietf-ecrit-framework] 692 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 693 "Framework for Emergency Calling using Internet 694 Multimedia", draft-ietf-ecrit-framework-09 (work in 695 progress), March 2009. 697 [I-D.ietf-geopriv-http-location-delivery] 698 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 699 "HTTP Enabled Location Delivery (HELD)", 700 draft-ietf-geopriv-http-location-delivery-15 (work in 701 progress), June 2009. 703 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 704 Emergency Context Resolution with Internet Technologies", 705 RFC 5012, January 2008. 707 [I-D.winterbottom-geopriv-held-identity-extensions] 708 Thomson, M., Tschofenig, H., Barnes, R., and J. 709 Winterbottom, "Use of Target Identity in HTTP-Enabled 710 Location Delivery (HELD)", 711 draft-winterbottom-geopriv-held-identity-extensions-09 712 (work in progress), February 2009. 714 [I-D.winterbottom-geopriv-lis2lis-req] 715 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 716 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 717 (work in progress), November 2007. 719 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 720 Shanmugam, "Security Threats and Requirements for 721 Emergency Call Marking and Mapping", RFC 5069, 722 January 2008. 724 [I-D.barnes-geopriv-lo-sec] 725 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 726 Tschofenig, H., and H. Schulzrinne, "An Architecture for 727 Location and Location Privacy in Internet Applications", 728 draft-barnes-geopriv-lo-sec-05 (work in progress), 729 March 2009. 731 [esw07] "3rd SDO Emergency Services Workshop, 732 http://www.emergency-services-coordination.info/2007Nov/", 733 October 30th - November 1st 2007. 735 Authors' Addresses 737 Henning Schulzrinne 738 Columbia University 739 Department of Computer Science 740 450 Computer Science Building 741 New York, NY 10027 742 US 744 Phone: +1 212 939 7004 745 Email: hgs+ecrit@cs.columbia.edu 746 URI: http://www.cs.columbia.edu 748 Stephen McCann 749 Siemens/Roke Manor Research 751 Email: stephen.mccann@roke.co.uk 753 Gabor Bajko 754 Nokia 756 Email: Gabor.Bajko@nokia.com 758 Hannes Tschofenig 759 Nokia Siemens Networks 760 Linnoitustie 6 761 Espoo 02600 762 Finland 764 Phone: +358 (50) 4871445 765 Email: Hannes.Tschofenig@gmx.net 766 URI: http://www.tschofenig.priv.at