idnits 2.17.1 draft-schulzrinne-ecrit-unauthenticated-access-04.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 771. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. 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 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 (November 3, 2008) is 5652 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) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-13 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-05 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-08 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-06 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-10 == Outdated reference: A later version (-10) exists of draft-winterbottom-geopriv-held-identity-extensions-06 == Outdated reference: A later version (-05) exists of draft-barnes-geopriv-lo-sec-03 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 8 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: May 7, 2009 Siemens/Roke Manor Research 6 G. Bajko 7 Nokia 8 H. Tschofenig 9 Nokia Siemens Networks 10 November 3, 2008 12 Extensions to the Emergency Services Architecture for dealing with 13 Unauthenticated and Unauthorized Devices 14 draft-schulzrinne-ecrit-unauthenticated-access-04.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 7, 2009. 41 Abstract 43 The IETF emergency services architecture assumes that the calling 44 device has acquired rights to use the access network or that no 45 authentication is required for the access network, such as for public 46 wireless access points. Subsequent protocol interactions, such as 47 obtaining location information, learning the address of the Public 48 Safety Answering Point (PSAP) and the emergency call itself are 49 largely decoupled from the underlying network access procedures. 51 In some cases, the device does not have credentials for network 52 access, does not have a VoIP provider, or the credentials have become 53 invalid, e.g., because the user has exhausted their prepaid balance 54 or the account has expired. 56 This document provides a problem statement, introduces terminology 57 and describes an extension for the base IETF emergency services 58 architecture to address these scenarios. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. No Access Authorization (NAA) . . . . . . . . . . . . . . 5 64 1.2. No VoIP Service Provider (NVP) . . . . . . . . . . . . . . 6 65 1.3. Zero-Balance VoIP Service Provider (ZBP) . . . . . . . . . 6 66 2. A Warning Note . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4. Considerations for ISPs to support Unauthenticated 69 Emergency Services without Architecture Extensions . . . . . . 7 70 5. Considerations for ISPs to support Unauthenticated 71 Emergency Services with Architecture Extensions . . . . . . . 8 72 6. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 12 74 6.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 12 75 6.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 12 76 6.1.3. Location Determination and Location Configuration . . 12 77 6.1.4. Emergency Call Identification . . . . . . . . . . . . 12 78 6.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 13 79 6.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 13 82 6.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 13 83 6.2.2. Location Determination and Location Configuration . . 13 84 6.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.3.1. Emergency Call Routing . . . . . . . . . . . . . . . . 14 86 6.3.2. Emergency Call Identification . . . . . . . . . . . . 14 87 6.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . . 14 88 6.3.4. Location Retrieval . . . . . . . . . . . . . . . . . . 14 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 Intellectual Property and Copyright Statements . . . . . . . . . . 19 98 1. Introduction 100 Summoning police, the fire department or an ambulance in emergencies 101 is one of the fundamental and most-valued functions of the telephone. 102 As telephone functionality moves from circuit-switched telephony to 103 Internet telephony, its users rightfully expect that this core 104 functionality will continue to work at least as well as it has for 105 the older technology. New devices and services are being made 106 available that could be used to make a request for help, which are 107 not traditional telephones, and users are increasingly expecting them 108 to be used to place emergency calls. 110 Roughly speaking, the IETF emergency services architecture (see 111 [I-D.ietf-ecrit-phonebcp] and [I-D.ietf-ecrit-framework]) divides 112 responsibility for handling emergency calls between the access 113 network (ISP), the VoIP service provider (VSP) and the provider of 114 emergency signaling services, the emergency service network (ESN). 115 The access network may provide location information to end systems, 116 but does not have to provide any VoIP signaling functionality. The 117 emergency caller can reach the ESN either directly or through the 118 VoIP provider's outbound proxy. Any of the three parties can provide 119 the mapping from location to PSAP URI by offering LoST [RFC5222] 120 services. 122 In general, a set of automated configuration mechanisms allows a 123 device to function in a variety of architectures, without the user 124 being aware of the details on who provides location, mapping services 125 or call routing services. However, if emergency calling is to be 126 supported when the calling device lacks access network authorization 127 or does not have a VoIP provider, one or more of the providers may 128 need to provide additional services and functions. 130 In all cases, the end device MUST be able to perform a LoST lookup 131 and otherwise conduct the emergency call in the same manner as when 132 the three exceptional conditions discussed below do not apply. 134 We distinguish between three conditions: 136 No access authorization (NAA): The current access network requires 137 access authorization and the caller does not have valid user 138 credentials. (This includes the case where the access network 139 allows pay-per-use, as is common for wireless hotspots, but there 140 is insufficient time to pay for access.) 142 No VoIP provider (NVP): The caller does not have a VoIP service 143 provider (VSP) at the time of the call. 145 Zero-balance VoIP provider (ZBP): The caller has valid credentials 146 with a VSP, but is not allowed to place calls, e.g., because the 147 user has a zero balance in a prepaid account. 149 A user may well suffer from both NAA and NVP or ZBP at the same time. 150 Depending on local policy and regulations, it may not be possible to 151 place emergency calls in the NAA case. Unless local regulations 152 require user identification, it should always be possible to place 153 calls in the NVP case, with minimal impact on the ISP. Unless the 154 ESN requires that all calls traverse a known set of VSPs, a caller 155 should be able to place an emergency call in the ZBP case. We 156 discuss each case in separate sections below. 158 1.1. No Access Authorization (NAA) 160 In the NAA (No Access Authorization) case, the emergency caller does 161 not posses valid credentials for the access network. If local 162 regulations or policy allows or require, the access network may or 163 needs to cooperate in providing emergency calling services. 164 Generally, the ISP will want to ensure that devices do not pretend to 165 place emergency calls, but then abuse the access for obtaining more 166 general services fraudulently. 168 In particular, the ISP MUST allow emergency callers to acquire an IP 169 address and to reach a LoST server, either provided by the ISP or 170 some third party. It SHOULD also provide location information via 171 one of the mechanisms specified in [I-D.ietf-ecrit-phonebcp] without 172 requiring authorization unless it can safely assume that all nodes in 173 the access network can determine their own location, e.g., via GPS. 175 The details of how filtering is performed depends on the details of 176 the ISP architecture and are beyond the scope of this document. We 177 illustrate a possible model. If the ISP runs its own LoST server, it 178 would maintain an access control list including all IP addresses 179 contained in responses returned by the LoST server, as well as the 180 LoST server itself. (It may need to translate the domain names 181 returned to IP addresses and hope that the resolution captures all 182 possible DNS responses.) Since the media destination addresses are 183 not predictable, the ISP also has to provide a SIP outbound proxy so 184 that it can determine the media addresses and add those to the filter 185 list. 187 1.2. No VoIP Service Provider (NVP) 189 In the second case, the emergency caller has no current VoIP service 190 provider (VSP). This case poses no particular difficulties unless it 191 is assumed that only VSPs provide LoST server or that ESNs only 192 accept calls that reach it through a set of known VSPs. However, 193 since the calling device cannot obtain configuration information from 194 its VSP, the ISP MUST provide the address of a LoST server via DHCP 195 [RFC5223] if this model is to be supported. The LoST server may be 196 operated either by the ISP or a third party. 198 1.3. Zero-Balance VoIP Service Provider (ZBP) 200 In the case of zero-balance VoIP service provider, the VSP can 201 authenticate the caller, but the caller is not authorized to place 202 regular VoIP calls, e.g., because the contract has expired or the 203 prepaid account for the customer has been depleted. Naturally, a VSP 204 can simply disallow access by such customers, so that all such 205 customers find themselves in the NVP situation described above. If 206 VSPs desire or are required by regulation to provide emergency 207 calling services to such customers, they need to provide LoST 208 services to such customers and may need to provide outbound SIP proxy 209 services. As usual, the calling device looks up the LoST server via 210 SIP configuration. 212 Unless the emergency call traverses a PSTN gateway or the VSP charges 213 for IP-to-IP calls, there is little potential for fraud. If the VSP 214 also operates the LoST server, the outbound proxy MAY restrict 215 outbound calls to the SIP URIs returned by the LoST server. It is 216 NOT RECOMMENDED to rely on a fixed list of SIP URIs, as that list may 217 change. 219 2. A Warning Note 221 At the time of writing there is no regulation in place that demands 222 the functionality described in this memo. SDOs have started their 223 work on this subject in a proactive fashion in the anticipation that 224 national regulation will demand it for a subset of network 225 environments. 227 There are also indications that the functionality of unauthenticated 228 emergency calls (called SIM-less calls) in today's cellular system in 229 certain countries leads to a fair amount of hoaks or test calls. 230 This causes overload situations at PSAPs with . 232 As an example, Federal Office of Communications (OFCOM, 233 Switzerland) provided statistics about 112 calls in Switzerland 234 from Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less 235 emergency calls except for almost a month in July 2000 where a 236 significant increase in hoaks and test calls was reported. As a 237 consequence, the functionality was disabled again. More details 238 can be found in the panel presentations of the 3rd SDO Emergency 239 Services Workshop [esw07]. 241 3. Terminology 243 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 244 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 245 and "OPTIONAL" are to be interpreted as described in RFC 2119 246 [RFC2119]. 248 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] 249 and [RFC5012], namely Internet Access Provider (IAP), Internet 250 Service Provider (ISP), Application Service Provider (ASP), Voice 251 Service Provider (VSP), Emergency Service Routing Proxy (ESRP), 252 Public Safety Answering Point (PSAP), Location Configuration Server 253 (LCS), (emergency) service dial string, and (emergency) service 254 identifier. 256 4. Considerations for ISPs to support Unauthenticated Emergency 257 Services without Architecture Extensions 259 On a very high-level, the steps to be performed by an end host not 260 being attached to the network and the user starting to make an 261 emergency call are the following: 263 o Some radio networks have added support for unauthenticated 264 emergency access, some other type of networks advertise these 265 capabilities using layer beacons. The end host learns about these 266 unauthenticated emergency services capabilities either from the 267 link layer type or from advertisement. 268 o The end host uses the link layer specific network attachment 269 procedures defined for unauthenticated network access in order to 270 get access to emergency services. 271 o When the link layer network attachment procedure is completed the 272 end host learns basic configuration information using DHCP from 273 the ISP, including the address of the LoST server. 274 o The end host MUST use a Location Configuration Protocol (LCP) 275 supported by the IAP or ISP to learn its own location. 277 o The end host MUST use the LoST protocol [I-D.ietf-ecrit-lost] to 278 query the LoST server and ask for the PSAP URI responsible for 279 that location. 280 o After the PSAP URI has been returned to the end host, the SIP UA 281 in the end host directly initiates a SIP INVITE towards the PSAP 282 URI. 284 The IAP and the ISP will probably want to make sure that the claimed 285 emergency caller indeed performs an emergency call rather than using 286 the network for other purposes, and thereby acting fraudulent by 287 skipping any authentication, authorization and accounting procedures. 288 By restricting access of the unauthenticated emergency caller to the 289 LoST server and the PSAP URI, traffic can be restricted only to 290 emergency calls. 292 Using the above procedures, the unauthenticated emergency caller will 293 be successful only if: 295 o the ISP (or the IAP) support an LCP that the end host can use to 296 learn its location. A list of mandatory-to-implement LCPs can be 297 found in [I-D.ietf-ecrit-phonebcp]). 298 o the ISP configures it's firewalls appropriately to allow emergency 299 calls to traverse the network towards the PSAP. 301 Some IAPs/ISPs may not be able to fulfill the above requirements. If 302 those IAPs/ISPs want to support unauthenticated emergency calls, then 303 they can deploy an extended architecture as described in Section 5. 305 5. Considerations for ISPs to support Unauthenticated Emergency 306 Services with Architecture Extensions 308 For unauthenticated emergency services support it is insufficient to 309 provide mechanisms only at the link layer in order to bypass 310 authentication for the cases when: 312 o the IAP/ISP does not support any Location Configuration Protocol 313 o the IAP/ISP does not have knowledge of a LoST server (which would 314 assist the client to find the correct PSAP) 316 A modification to the emergency services architecture is necessary 317 since the IAP and the ISP need to make sure that the claimed 318 emergency caller indeed performs an emergency call rather than using 319 the network for other purposes, and thereby acting fraudulent by 320 skipping any authentication, authorization and accounting procedures. 321 Hence, without introducing some understanding of the specific 322 application the ISP (and consequently the IAP) will not be able to 323 detect and filter malicious activities. This leads to the 324 architecture described in Figure 1 where the IAP needs to implement 325 extensions to link layer procedures for unauthenticated emergency 326 service access and the ISP needs to deploy emergency services related 327 entities used for call routing, such as the Emergency Services 328 Routing Proxy (ESRP), a Location Configuration Server (LCS) and a 329 mapping database. 331 On a very high-level, the interaction is as follows starting with the 332 end host not being attached to the network and the user starting to 333 make an emergency call. 335 o Some radio networks have added support for unauthenticated 336 emergency access, some other type of networks advertise these 337 capabilities using layer beacons. The end host learns about these 338 unauthenticated emergency services capabilities either from the 339 link layer type or from advertisement. 340 o The end host uses the link layer specific network attachment 341 procedures defined for unauthenticated network access in order to 342 get access to emergency services. 343 o When the link layer network attachment procedure is completed the 344 end host learns basic configuration information using DHCP from 345 the ISP, including the address of the ESRP, as shown in (2). 346 o When the IP address configuration is completed then the SIP UA 347 initiates a SIP INVITE towards the indicated ESRP, as shown in 348 (3). The INVITE message contains all the necessary parameters 349 required by Section 6.1.5. 350 o The ESRP receives the INVITE and processes it according to the 351 description in Section 6.3.3. The location of the end host may 352 need to be determined using a protocol interaction shown in (4). 353 o Potentially, an interaction between the LCS of the ISP and the LCS 354 of the IAP may be necessary, see (5). 355 o Finally, the correct PSAP for the location of the end host has to 356 be evaluated, see (6). 357 o The ESRP routes the call to the PSAP, as shown in (7). 358 o The PSAP evaluates the initial INVITE and aims to complete the 359 call setup. 360 o Finally, when the call setup is completed media traffic can be 361 exchanged between the PSAP and the emergency caller. 363 For editorial reasons the end-to-end SIP and media exchange between 364 the PSAP and SIP UA are not shown in Figure 1. 366 Two important aspects are worth to highlight: 368 o The IAP/ISP needs to understand the concept of emergency calls and 369 the SIP profile described in this document. No other VoIP 370 protocol profile, such as XMPP, Skype, etc., are supported for 371 emergency calls in this particular architecture. Other profiles 372 may be added in the future, but the deployment effort is enormous 373 since they have to be universally deployed. 374 o The end host has no obligation to determine location information. 375 It may attach location information if it has location available 376 (e.g., from a GPS receiver). 378 Figure 1 shows that the ISP needs to deploy SIP-based emergency 379 services functionality. It is important to note that the ISP itself 380 may outsource the functionality by simply providing access to them 381 (e.g., it puts the IP address of an ESRP or a LoST server into an 382 allow-list). For editorial reasons this outsourcing is not shown. 384 +---------------------------+ 385 | | 386 | Emergency Network | 387 | Infrastructure | 388 | | 389 | +----------+ +----------+ | 390 | | PSAP | | ESRP | | 391 | | | | | | 392 | +----------+ +----------+ | 393 +-------------------^-------+ 394 | 395 | (7) 396 +------------------------+-----------------------+ 397 | ISP | | 398 | | | 399 |+----------+ v | 400 || Mapping | (6) +----------+ | 401 || Database |<----->| ESRP / | | 402 |+----------+ | SIP Proxy|<-+ | 403 |+----------+ +----------+ | +----------+| 404 || LCS-ISP | ^ | | DHCP || 405 || |<---------+ | | Server || 406 |+----------+ (4) | +----------+| 407 +-------^-------------------------+-----------^--+ 408 +-------|-------------------------+-----------|--+ 409 | IAP | (5) | | | 410 | V | | | 411 |+----------+ | | | 412 || LCS-IAP | +----------+ | | | 413 || | | Link | |(3) | | 414 |+----------+ | Layer | | | | 415 | | Device | | (2)| | 416 | +----------+ | | | 417 | ^ | | | 418 | | | | | 419 +------------------------+--------+-----------+--+ 420 | | | 421 (1)| | | 422 | | | 423 | +----+ | 424 v v | 425 +----------+ | 426 | End |<-------------+ 427 | Host | 428 +----------+ 430 Figure 1: Overview 432 It is important to note that a single ESRP may also offer it's 433 service to several ISPs. 435 6. Profiles 437 6.1. End Host Profile 439 6.1.1. LoST Server Discovery 441 The end host MAY attempt to use [I-D.ietf-ecrit-lost] to discover a 442 LoST server. If that attempt fails, the end host SHOULD attempt to 443 discover the address of an ESRP. 445 6.1.2. ESRP Discovery 447 The end host only needs an ESRP when location configuration or LoST 448 server discovery fails. If that is the case, then the end host MUST 449 use the "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option 450 for Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv6) 451 and / or the "Dynamic Host Configuration Protocol (DHCPv6) Options 452 for Session Initiation Protocol (SIP) Servers" [RFC3319] to discover 453 the address of an ESRP. This SIP proxy located in the ISP network 454 will be used as the ESRP for routing emergency calls. There is no 455 need to discovery a separate SIP proxy with specific emergency call 456 functionality since the internal procedure for emergency call 457 processing is subject of ISP internal operation. 459 6.1.3. Location Determination and Location Configuration 461 The end host SHOULD attempt to use the supported LCPs to configure 462 its location. If no LCP is supported in the end host or the location 463 configuration is not successful, then the end host MUST attempt to 464 discover an ESRP, which would assist the end host in providing the 465 location to the PSAP. 467 The SIP UA in the end host SHOULD attach the location information in 468 a PIDF-LO [RFC4119] when making an emergency call. When constructing 469 the PIDF-LO the guidelines in PIDF-LO profile 470 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. For civic 471 location information the format defined in [RFC5139] MUST be 472 supported. 474 6.1.4. Emergency Call Identification 476 To determine which calls are emergency calls, some entity needs to 477 map a user entered dialstring into this URN scheme. A user may 478 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 479 mapping SHOULD be performed at the endpoint device. 481 End hosts MUST use the Service URN mechanism [RFC5031] to mark calls 482 as emergency calls for their home emergency dial string (if known). 483 For visited emergency dial string the translation into the Service 484 URN mechanism is not mandatory since the ESRP in the ISPs network 485 knows the visited emergency dial strings. 487 6.1.5. SIP Emergency Call Signaling 489 SIP signaling capabilities [RFC3261] are mandated for end hosts. 491 The initial SIP signaling method is an INVITE. The SIP INVITE 492 request MUST be constructed according to the requirements in Section 493 9.2 [I-D.ietf-ecrit-phonebcp]. 495 Regarding callback behavior SIP UAs MUST have a globally routable URI 496 in a Contact: header. 498 6.1.6. Media 500 End points MUST comply with the media requirements for end points 501 placing an emergency call found in Section 14 of 502 [I-D.ietf-ecrit-phonebcp]. 504 6.1.7. Testing 506 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] is fully 507 applicable to this document. 509 6.2. IAP/ISP Profile 511 6.2.1. ESRP Discovery 513 An ISP hosting an ESRP MUST implement the server side part of 514 "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for 515 Session Initiation Protocol (SIP) Servers" [RFC3361] (for IPv4) and / 516 or the "Dynamic Host Configuration Protocol (DHCPv6) Options for 517 Session Initiation Protocol (SIP) Servers" [RFC3319]. 519 6.2.2. Location Determination and Location Configuration 521 The ISP not hosting an ESRP MUST support at least one widely used 522 LCP. The ISP hosting an ESRP MUST perform the neccesary steps to 523 determine the location of the end host. It is not necessary to 524 standardize a specific mechanism. 526 The role of the ISP is to operate the LIS. The usage of HELD 528 [I-D.ietf-geopriv-http-location-delivery] with the identity 529 extensions [I-D.winterbottom-geopriv-held-identity-extensions] may be 530 a possible choice. It might be necessary for the ISP to talk to the 531 IAP in order to determine the location of the end host. The work on 532 LIS-to-LIS communication may be relevant, see 533 [I-D.winterbottom-geopriv-lis2lis-req]. 535 6.3. ESRP Profile 537 6.3.1. Emergency Call Routing 539 The ESRP must route the emergency call to the PSAP responsible for 540 the physical location of the end host. However, a standardized 541 approach for determining the correct PSAP based on a given location 542 is useful but not mandatory. 544 For cases where a standardized protocol is used LoST 545 [I-D.ietf-ecrit-lost] is a suitable mechanism. 547 6.3.2. Emergency Call Identification 549 The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e., 550 the 'urn:service:sos' tree) and additionally the national emergency 551 dial strings. The ESRP SHOULD perform a mapping of national 552 emergency dial strings to Service URNs to simplify processing at 553 PSAPs. 555 6.3.3. SIP Emergency Call Signaling 557 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 558 ESRP MUST process the messages sent by the client, according to 559 Section 6.1.5. Furthermore, the ESRP MUST be able to add a reference 560 to location information, as described in SIP Location Conveyance 561 [I-D.ietf-sip-location-conveyance], before forwarding the call to the 562 PSAP. The ISP MUST be prepared to receive incoming dereferencing 563 requests to resolve the reference to the location information. 565 6.3.4. Location Retrieval 567 The ESRP acts a location recipient and the usage of HELD 568 [I-D.ietf-geopriv-http-location-delivery] with the identity 569 extensions [I-D.winterbottom-geopriv-held-identity-extensions] may be 570 a possible choice. The ESRP would thereby act as a HELD client and 571 the corresponding LIS at the ISP as the HELD server. 573 The ESRP needs to obtain enough information to route the call. The 574 ESRP itself, however, does not necessarily need to process location 575 information obtained via HELD since it may be used as input to LoST 576 to obtain the PSAP URI. 578 7. Security Considerations 580 The security threats discussed in [RFC5069] are applicable to this 581 document. A number of security vulnerabilities discussed in 582 [I-D.barnes-geopriv-lo-sec] around faked location information are 583 less problematic in this case since location information does not 584 need to be provided by the end host itself or it can be verified to 585 fall within a specific geographical area. 587 There are a couple of new vulnerabilities raised with unauthenticated 588 emergency services since the PSAP operator does is not in possession 589 of any identity information about the emergency call via the 590 signaling path itself. In countries where this functionality is used 591 for GSM networks today this has lead to a significant amount of 592 misuse. 594 The link layer mechanisms need to provide a special way of handling 595 unauthenticated emergency services. Although this subject is not a 596 topic for the IETF itself but there are at least a few high-level 597 assumptions that may need to be collected. This includes security 598 features that may be desirable. 600 8. Acknowledgments 602 Section 6 of this document is derived from [I-D.ietf-ecrit-phonebcp]. 603 The WiMax Forum contributed parts of the terminology. Participants 604 of the 2nd and 3rd SDO Emergency Services Workshop provided helpful 605 input. 607 9. IANA Considerations 609 This document does not require actions by IANA. 611 10. References 613 10.1. Normative References 615 [I-D.ietf-sip-location-conveyance] 616 Polk, J. and B. Rosen, "Location Conveyance for the 617 Session Initiation Protocol", 618 draft-ietf-sip-location-conveyance-11 (work in progress), 619 October 2008. 621 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 622 Emergency and Other Well-Known Services", RFC 5031, 623 January 2008. 625 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 626 Format", RFC 4119, December 2005. 628 [I-D.ietf-geopriv-pdif-lo-profile] 629 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 630 PIDF-LO Usage Clarification, Considerations and 631 Recommendations", draft-ietf-geopriv-pdif-lo-profile-13 632 (work in progress), September 2008. 634 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 635 Format for Presence Information Data Format Location 636 Object (PIDF-LO)", RFC 5139, February 2008. 638 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 639 (DHCP-for-IPv4) Option for Session Initiation Protocol 640 (SIP) Servers", RFC 3361, August 2002. 642 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 643 Protocol (DHCPv6) Options for Session Initiation Protocol 644 (SIP) Servers", RFC 3319, July 2003. 646 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 647 A., Peterson, J., Sparks, R., Handley, M., and E. 648 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 649 June 2002. 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [I-D.ietf-ecrit-phonebcp] 655 Rosen, B. and J. Polk, "Best Current Practice for 656 Communications Services in support of Emergency Calling", 657 draft-ietf-ecrit-phonebcp-05 (work in progress), 658 July 2008. 660 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 661 Tschofenig, "LoST: A Location-to-Service Translation 662 Protocol", RFC 5222, August 2008. 664 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 665 Location-to-Service Translation (LoST) Servers Using the 666 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 667 August 2008. 669 10.2. Informative References 671 [I-D.ietf-ecrit-lost] 672 Hardie, T., Newton, A., Schulzrinne, H., and H. 673 Tschofenig, "LoST: A Location-to-Service Translation 674 Protocol", draft-ietf-ecrit-lost-10 (work in progress), 675 May 2008. 677 [I-D.ietf-geopriv-l7-lcp-ps] 678 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 679 Location Configuration Protocol; Problem Statement and 680 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 681 progress), June 2008. 683 [I-D.ietf-ecrit-framework] 684 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 685 "Framework for Emergency Calling using Internet 686 Multimedia", draft-ietf-ecrit-framework-06 (work in 687 progress), July 2008. 689 [I-D.ietf-geopriv-http-location-delivery] 690 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 691 "HTTP Enabled Location Delivery (HELD)", 692 draft-ietf-geopriv-http-location-delivery-10 (work in 693 progress), October 2008. 695 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 696 Emergency Context Resolution with Internet Technologies", 697 RFC 5012, January 2008. 699 [I-D.winterbottom-geopriv-held-identity-extensions] 700 Winterbottom, J., "HELD Identity Extensions", 701 draft-winterbottom-geopriv-held-identity-extensions-06 702 (work in progress), July 2008. 704 [I-D.winterbottom-geopriv-lis2lis-req] 705 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 706 Requirements", draft-winterbottom-geopriv-lis2lis-req-01 707 (work in progress), November 2007. 709 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 710 Shanmugam, "Security Threats and Requirements for 711 Emergency Call Marking and Mapping", RFC 5069, 712 January 2008. 714 [I-D.barnes-geopriv-lo-sec] 715 Barnes, R., Lepinski, M., Tschofenig, H., and H. 716 Schulzrinne, "Additional Location Privacy Considerations", 717 draft-barnes-geopriv-lo-sec-03 (work in progress), 718 July 2008. 720 [esw07] "3rd SDO Emergency Services Workshop, 721 http://www.emergency-services-coordination.info/2007Nov/", 722 October 30th - November 1st 2007. 724 Authors' Addresses 726 Henning Schulzrinne 727 Columbia University 728 Department of Computer Science 729 450 Computer Science Building 730 New York, NY 10027 731 US 733 Phone: +1 212 939 7004 734 Email: hgs+ecrit@cs.columbia.edu 735 URI: http://www.cs.columbia.edu 737 Stephen McCann 738 Siemens/Roke Manor Research 740 Email: stephen.mccann@roke.co.uk 742 Gabor Bajko 743 Nokia 745 Email: Gabor.Bajko@nokia.com 747 Hannes Tschofenig 748 Nokia Siemens Networks 749 Linnoitustie 6 750 Espoo 02600 751 Finland 753 Phone: +358 (50) 4871445 754 Email: Hannes.Tschofenig@gmx.net 755 URI: http://www.tschofenig.priv.at 757 Full Copyright Statement 759 Copyright (C) The IETF Trust (2008). 761 This document is subject to the rights, licenses and restrictions 762 contained in BCP 78, and except as set forth therein, the authors 763 retain all their rights. 765 This document and the information contained herein are provided on an 766 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 767 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 768 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 769 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 770 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 771 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 773 Intellectual Property 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org.