idnits 2.17.1 draft-schulzrinne-ecrit-unauthenticated-access-00.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 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 853. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Bad filename characters: the document name given in the document, 'draft-ietf-ecrit-framework;', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ecrit-framework;', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ecrit-framework;', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-ecrit-framework;', but the file name used is 'draft-schulzrinne-ecrit-unauthenticated-access-00' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 19, 2007) is 6094 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) == Unused Reference: 'RFC4776' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC3825' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'I-D.marshall-geopriv-lbyr-requirements' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ecrit-mapping-arch' is defined on line 744, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-08 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-08 == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-revised-civic-lo-05 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-14 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3984 (Obsoleted by RFC 6184) == Outdated reference: A later version (-09) exists of draft-ietf-sipping-toip-07 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-toip (ref. 'I-D.ietf-sipping-toip') ** Obsolete normative reference: RFC 3920 (Obsoleted by RFC 6120) == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-01 == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-06 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-03 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-02 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-01 == Outdated reference: A later version (-04) exists of draft-ietf-ecrit-mapping-arch-02 == Outdated reference: A later version (-10) exists of draft-winterbottom-geopriv-held-identity-extensions-02 == Outdated reference: A later version (-01) exists of draft-winterbottom-geopriv-lis2lis-req-00 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-04 == Outdated reference: A later version (-01) exists of draft-schulzrinne-ecrit-location-hiding-requirements-00 == Outdated reference: A later version (-05) exists of draft-barnes-geopriv-lo-sec-00 Summary: 9 errors (**), 1 flaw (~~), 24 warnings (==), 7 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 Updates: S. McCann 5 draft-ietf-ecrit-framework; Siemens/Roke Manor Research 6 draft-ietf-ecrit-phonebcp G. Bajko 7 (if approved) Nokia 8 Intended status: Standards Track H. Tschofenig 9 Expires: February 20, 2008 Nokia Siemens Networks 10 August 19, 2007 12 Extensions to the Emergency Services Architecture for dealing with 13 Unauthenticated and Unauthorized Devices 14 draft-schulzrinne-ecrit-unauthenticated-access-00.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 February 20, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 The IETF emergency services architecture assumes that access to a 48 network has already happened using the traditional network access 49 authentication procedures or that no authentication for network 50 access is needed (e.g., in case of public hotspots). Subsequent 51 protocol interactions, such as obtaining location information, 52 learning the address of the Public Safety Answering Point (PSAP) and 53 the emergency call itself are largely decoupled from the underlying 54 network access procedures. 56 There are, however, cases where a device is not in possession of 57 credentials for network access, does not have a VoIP provider, or 58 where the credentials are available but became invalid due to various 59 reasons (e.g., credit exhaustion, expired accounts, etc.). 61 This document provides a problem statement, introduces terminology 62 and describes an extension for the base IETF emergency services 63 architecture. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. End Host Profile . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 9 73 4.1.2. Location Determination and Location Configuration . . 9 74 4.1.3. Emergency Call Identification . . . . . . . . . . . . 9 75 4.1.4. SIP Emergency Call Signaling . . . . . . . . . . . . . 9 76 4.1.5. Media . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1.6. Testing . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.2. ISP Profile . . . . . . . . . . . . . . . . . . . . . . . 11 79 4.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . . 11 80 4.2.2. Location Determination and Location Configuration . . 11 81 4.2.3. Emergency Call Routing . . . . . . . . . . . . . . . . 11 82 4.2.4. Emergency Call Identification . . . . . . . . . . . . 12 83 4.2.5. SIP Emergency Call Signaling . . . . . . . . . . . . . 12 84 4.2.6. Quality of Service . . . . . . . . . . . . . . . . . . 12 85 4.3. PSAP Profile . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.3.1. Location Retrieval . . . . . . . . . . . . . . . . . . 12 87 4.3.2. Emergency Call Routing . . . . . . . . . . . . . . . . 12 88 4.3.3. Emergency Call Identification . . . . . . . . . . . . 13 89 4.3.4. SIP Emergency Call Signaling . . . . . . . . . . . . . 13 90 4.3.5. Media . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4.3.6. Testing . . . . . . . . . . . . . . . . . . . . . . . 13 92 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 95 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 100 Intellectual Property and Copyright Statements . . . . . . . . . . 20 102 1. Introduction 104 Summoning police, the fire department or an ambulance in emergencies 105 is one of the fundamental and most-valued functions of the telephone. 106 As telephone functionality moves from circuit-switched telephony to 107 Internet telephony, its users rightfully expect that this core 108 functionality will continue to work at least as well as it has for 109 the older technology. New devices and services are being made 110 available that could be used to make a request for help, which are 111 not traditional telephones, and users are increasingly expecting them 112 to be used to place emergency calls. 114 Based on the communication model of the Session Initiation Protocol 115 (SIP) as excerised in the IETF it is not necessary to deploy SIP 116 entities in access networks (or associated to them). Instead, VoIP 117 provider may deploy their SIP entities at any place on the Internet. 118 The IETF emergency services architecture acknowledges this deployment 119 model and even goes a step further by recognizing that there are 120 potentially other, non-SIP VoIP provider, that might want to offer 121 emergency service support to their customers. Hence, the interaction 122 between a SIP User Agent and its VoIP provider does not need to be 123 standarized although [I-D.ietf-ecrit-phonebcp] provides best current 124 practise recommendations regarding the usage of certain features as 125 excerised in the case of SIP. 127 This flexibility has implications for the architecture, as briefly 128 described in [I-D.tschofenig-ecrit-architecture-overview], but allows 129 access networks to be application layer agnostic. Furthermore, since 130 the normal VoIP communication exchanges do not traverse these 131 entities in the access network it is quite likely that 132 interoperability problems will occur especially in an emergency case. 134 There are essentially three environments that need to be considered: 136 1. The emergency caller does not credentials for access to the 137 network but it still has credentials for his VoIP provider. 139 This is often the case with enterprise networks, home networks, 140 or governmental networks. In other cases the user might be able 141 to obtain such credentials, for example in hotspots found in 142 hotels, at airports, and in many coffee shops. Unfortunately, 143 users have to go through a lengthy procedure (often involving 144 captive portals) to obtain a temporary account in exchange of 145 money. In emergency situations it is certainly not desirable to 146 let the user find their way through a number of webpages and to 147 type-in their credit card details. 149 2. The emergency caller has credentials for network access but does 150 not have credentials for a VoIP provider. This case is rather 151 unlikely. 152 3. The emergency caller has credentials (for either network access 153 or it's VoIP provider) but they do not provide enough 154 authorization to make a call. This use case essentially refers 155 to lack of authorization. Examples are: Insufficient credits, 156 lack of a roaming agreement (between visited network and home 157 network), disabled account, and other authorization failures. 159 Scenario (1) is the most likely scenario and the main focus of this 160 document. 162 In all these cases it is not possible to place an emergency call as 163 envisioned in the IETF emergerency services architecture, described 164 in [I-D.ietf-ecrit-framework]. 166 Note that at the time of writing there is currently no regulation in 167 place that demands the functionality described in this memo. Since 168 many SDOs have started their work on this subject in a proactive 169 fashion in the anticipation that national regulation in some 170 countries might demand this functionality for a subset of network 171 types. 173 2. Terminology 175 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 176 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 177 and "OPTIONAL" are to be interpreted as described in RFC 2119 178 [RFC2119]. 180 This document introduces new terminology: 182 Unauthenticated Emergency Service: We use this term in this document 183 to refer to all the cases where the emergency caller does not have 184 credentials or are not authorized to access a network. This also 185 includes cases where a device is not in possession of credentials 186 for network access, does not have a VoIP provider (as it is the 187 case for uninitialized phones), or where the credentials are 188 available but became invalid due to various reasons (e.g., credit 189 exhaustion, expired accounts, etc.). 191 This document reuses terminology from [I-D.ietf-geopriv-l7-lcp-ps] 192 and [I-D.ietf-ecrit-requirements]. 194 3. Architecture 196 For unauthenticated emergency services support it is insufficient to 197 provide mechanisms only at the link layer in order to bypass 198 authentication. A modification to the emergency services 199 architecture is necessary since the IAP and the ISP need to make sure 200 that the claimed emergency caller indeed performs an emergency call 201 rather than using the network for other purposes, and thereby acting 202 fraudulent by skipping any authentication, authorization and 203 accounting procedures. Hence, without introducing some understanding 204 of the specific application the ISP (and consequently the IAP) will 205 not be able to detect and filter malicious activities. This leads to 206 the architecture described in Figure 1 where the IAP needs to 207 implement extensions to link layer procedures for unauthenticated 208 emergency service access and the ISP needs to deploy emergency 209 services related entities used for call routing, such as the 210 Emergency Services Routing Proxy (ESRP), a Location Configuration 211 Server (LCS) and a mapping database. 213 On a very high-level, the interaction is as follows starting with the 214 end host not being attached to the network and the user starting to 215 make an emergency call. 217 o Some radio networks have added support for unauthenticated 218 emergency access, some other type of networks advertise these 219 capabilities using layer beacons. The end host learns about these 220 unauthenticated emergency services capabilities either from the 221 link layer type or from advertisement. 222 o The end host uses the link layer specific network attachment 223 procedures defined for unauthenticated network access in order to 224 get access to emergency services. 225 o When the link layer network attachment procedure is completed the 226 end host learns basic configuration information using DHCP from 227 the ISP, including the address of the ESRP, as shown in (2). 228 o When the IP address configuration is completed then the SIP UA 229 initiates a SIP INVITE towards the indicated ESRP, as shown in 230 (3). The INVITE message contains all the necessary parameters 231 required by Section 4.1.4. 232 o The ESRP receives the INVITE and processes it according to the 233 description in Section 4.2.5. The location of the end host may 234 need to be determined using a protocol interaction shown in (4). 235 o Potentially, an interaction between the LCS of the ISP and the LCS 236 of the IAP may be necessary, see (5). 237 o Finally, the correct PSAP for the location of the end host has to 238 be evaluated, see (6). 239 o The ESRP routes the call to the PSAP, as shown in (7). 241 o The PSAP evaluates the initial INVITE and acts according to SIP 242 and the description in Section 4.3.4 in order to complete the call 243 setup. 244 o Finally, when the call setup is completed media traffic can be 245 exchanged between the PSAP operator and the emergency caller, 246 according to Section 4.3.5 and Section 4.1.5. 248 For editorial reasons the end-to-end SIP and media exchange between 249 the PSAP and SIP UA are not shown in Figure 1. 251 Two important aspects are worth to highlight: 253 o The IAP/ISP needs to understand the concept of emergency calls and 254 the SIP profile described in this document. No other VoIP 255 protocol profile, such as XMPP, Skype, etc., are supported for 256 emergency calls in this particular architecture. Other profiles 257 may be added in the future, but the deployment effort is enormous 258 since they have to be universally deployed. 259 o The end host has no obligation to determine location information. 260 It may attach location information if it has location available 261 (e.g., from a GPS receiver). 263 Figure 1 shows that the ISP needs to deploy SIP-based emergency 264 services functionality. It is important to note that the ISP itself 265 may outsource the functionality by simply providing access to them 266 (e.g., it puts the IP address of an ESRP or a LoST server into an 267 allow-list). For editorial reasons this outsourcing is not shown. 269 +---------------------------+ 270 | | 271 | Emergency Network | 272 | Infrastructure | 273 | | 274 | +----------+ +----------+ | 275 | | PSAP | | ESRP | | 276 | | | | | | 277 | +----------+ +----------+ | 278 +-------------------^-------+ 279 | 280 | (7) 281 +------------------------+-----------------------+ 282 | ISP | | 283 | | | 284 |+----------+ v | 285 || Mapping | (6) +----------+ | 286 || Database |<----->| ESRP / | | 287 |+----------+ | SIP Proxy|<-+ | 288 |+----------+ +----------+ | +----------+| 289 || LCS-ISP | ^ | | DHCP || 290 || |<---------+ | | Server || 291 |+----------+ (4) | +----------+| 292 +-------^-------------------------+-----------^--+ 293 +-------|-------------------------+-----------|--+ 294 | IAP | (5) | | | 295 | V | | | 296 |+----------+ | | | 297 || LCS-IAP | +----------+ | | | 298 || | | Link | |(3) | | 299 |+----------+ | Layer | | | | 300 | | Device | | (2)| | 301 | +----------+ | | | 302 | ^ | | | 303 | | | | | 304 +------------------------+--------+-----------+--+ 305 | | | 306 (1)| | | 307 | | | 308 | +----+ | 309 v v | 310 +----------+ | 311 | End |<-------------+ 312 | Host | 313 +----------+ 315 Figure 1: Unauthenticated Emergency Services Architecture 317 4. Profile 319 4.1. End Host Profile 321 4.1.1. ESRP Discovery 323 The end host MUST use the "Dynamic Host Configuration Protocol (DHCP- 324 for-IPv4) Option for Session Initiation Protocol (SIP) Servers" 325 [RFC3361] (for IPv6) and / or the "Dynamic Host Configuration 326 Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) 327 Servers" [RFC3319]. This SIP proxy located in the ISP network will 328 be used as the ESRP for routing emergency calls. There is no need to 329 discovery a separate SIP proxy with specific emergency call 330 functionality since the internal procedure for emergency call 331 processing is subject of ISP internal operation. 333 4.1.2. Location Determination and Location Configuration 335 There is no requirement for end hosts to support any Location 336 Configuration Protocol. If clients are in possession of location 337 information, for example, based on a built-in GPS receiver then they 338 SHOULD attach the location information in a PIDF-LO. When 339 constructing the PIDF-LO the guidelines in PIDF-LO profile 340 [I-D.ietf-geopriv-pdif-lo-profile] MUST be followed. For civic 341 location information the format defined in 342 [I-D.ietf-geopriv-revised-civic-lo] MUST be supported. 344 4.1.3. Emergency Call Identification 346 To determine which calls are emergency calls, some entity needs to 347 map a user entered dialstring into this URN scheme. A user may 348 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 349 mapping SHOULD performed at the endpoint device, but MAY be performed 350 at an intermediate entity. 352 End host MUST use the Service URN mechanism 353 [I-D.ietf-ecrit-service-urn] to mark calls as emergency calls for 354 their home emergency dial string. For visited emergency dial string 355 the translation into a the Service URN mechanism is not mandatory 356 since the ESRP in the ISPs network knows the visited emergency dial 357 strings. 359 4.1.4. SIP Emergency Call Signaling 361 SIP signaling capabilities [RFC3261] are mandated for end hosts. 363 The initial SIP signaling method is an INVITE. 365 1. The To: MUST be either a service URN in the "sos" tree or the 366 visited emergency dial string. [I-D.rosen-iptel-dialstring] with 367 the dialed digits. The sips URI [RFC3261] MUST NOT be used. 368 2. The From: header MUST be present and SHOULD be the AoR of the 369 caller, if available. 370 3. A Via: header MUST be present and SHOULD include the URI of the 371 device 372 4. A Route header SHOULD be present with the service URN in the 373 "sos" tree, and the loose route parameter. 374 5. A Contact header MUST be present, which might contain a GRUU 375 [I-D.ietf-sip-gruu], to permit an immediate call-back to the 376 specific device that placed the emergency call. 377 6. Other headers MAY be included as per normal sip behavior 378 7. A Supported: header MUST be included with the 'geolocation' 379 option tag [I-D.ietf-sip-location-conveyance], if the device 380 understands the concept of SIP Location. In case that the device 381 understands the SIP Location Conveyance 382 [I-D.ietf-sip-location-conveyance] extension and has its location 383 available, it MUST include location by-value. In this case, the 384 INVITE contains a Supported header with a "geolocation" option 385 tag, and a "cid-URL" [RFC2396] as the value in the Geolocation 386 header, indicating which message body part contains the PIDF-LO. 387 SIP Location Conveyance also requires that the UA MUST support 388 multipart message bodies, since SDP will likely be also in the 389 INVITE. 390 8. A normal SDP offer SHOULD be included in the INVITE. The offer 391 MUST include the G.711 codec. 393 4.1.5. Media 395 End points MUST send and receive media streams on RTP [RFC3550]. The 396 SIP offer/answer [RFC3264] negotiations MUST be used to agree on the 397 media streams to be used. 399 End points supporting voice MUST support G.711 A law (and mu Law in 400 North America) encoded voice as described in [RFC3551]. It is 401 desirable to support wideband codecs in the offer. Silence 402 suppression (Voice Activity Detection methods) MUST NOT be used on 403 emergency calls. 405 End points SHOULD support Instant Messaging using either [RFC3428] or 406 [RFC3920]. End points SHOULD support real-time text [RFC4103]. The 407 expectations for emergency service support for the real-time text 408 medium, described in [I-D.ietf-sipping-toip], Section 7.1 SHOULD be 409 fulfilled. 411 Video may be important to support Video Relay Service (Sign language 412 interpretation). End points supporting video MUST support H.264 per 414 [RFC3984]. Support for video, instant messaging and real-time text 415 is optional. 417 4.1.6. Testing 419 The description in Section 9 of [I-D.ietf-ecrit-phonebcp] is 420 applicable to this document as well. 422 4.2. ISP Profile 424 4.2.1. ESRP Discovery 426 The ISP MUST implement the server side part of "Dynamic Host 427 Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation 428 Protocol (SIP) Servers" [RFC3361] (for IPv6) and / or the "Dynamic 429 Host Configuration Protocol (DHCPv6) Options for Session Initiation 430 Protocol (SIP) Servers" [RFC3319]. 432 4.2.2. Location Determination and Location Configuration 434 The ISP must perform the necesary steps to determine the location of 435 the end host. It is not necessary to standardize a specific 436 mechanism. 438 The usage of HELD [I-D.ietf-geopriv-http-location-delivery] with the 439 identity extensions 440 [I-D.winterbottom-geopriv-held-identity-extensions] may be a possible 441 choice. It might be necessary for the ISP to talk to the IAP in 442 order to determine the location of the end host. The work on LIS-to- 443 LIS communication may be relevant, see 444 [I-D.winterbottom-geopriv-lis2lis-req]. 446 The ESRP (or a associated entity making location information 447 available to the PSAP) MUST understand the PIDF-LO format [RFC4119], 448 the PIDF-LO profile [I-D.ietf-geopriv-pdif-lo-profile] and the 449 revised civic format [I-D.ietf-geopriv-revised-civic-lo]. 451 Note that this architecture also fulfills the requirements for 452 location hiding, see 453 [I-D.schulzrinne-ecrit-location-hiding-requirements]. 455 4.2.3. Emergency Call Routing 457 The ISP must route the emergency call to the PSAP responsible for the 458 physical location of the end host. However, a standardized approach 459 for determining the correct PSAP based on a given location may not be 460 necessary. 462 For cases where a standardized protocol should be used LoST 463 [I-D.ietf-ecrit-lost] is a suitable mechanism. 465 4.2.4. Emergency Call Identification 467 The ESRP MUST understand the Service URN mechanism 468 [I-D.ietf-ecrit-service-urn] (i.e., the 'urn:service:sos' tree) and 469 additionally the national emergency dial strings. The ESRP SHOULD 470 perform a mapping of national emergency dial strings to Service URNs 471 to simplify processing at PSAPs. 473 4.2.5. SIP Emergency Call Signaling 475 SIP signaling capabilities [RFC3261] are mandated for the ESRP. The 476 ESRP MUST process the messages sent by the client, as indicated in 477 Section 4.1.4. Furthemore, the ESRP MUST be able to add a reference 478 to location information, as described in SIP Location Conveyance 479 [I-D.ietf-sip-location-conveyance], before forwarding the call to the 480 PSAP. The ISP MUST be prepared to receive incoming dereferencing 481 requests to resolve the reference to the location information. 483 4.2.6. Quality of Service 485 The ISP may provide QoS mechanisms to ensure the preferential 486 treatment of emergency calls. The specific mechanisms depend on the 487 network, may not require standardization and are outside the scope of 488 this document. 490 4.3. PSAP Profile 492 4.3.1. Location Retrieval 494 The PSAP MUST act according to SIP Location Conveyance when 495 processing a request with location information. In particular, it 496 MUST understand PIDF-LO format [RFC4119], the PIDF-LO profile 497 [I-D.ietf-geopriv-pdif-lo-profile] and the revised civic format 498 [I-D.ietf-geopriv-revised-civic-lo]. Furthermore, the PSAP MUST 499 understand the SIP or SIPS dereference scheme. 501 4.3.2. Emergency Call Routing 503 There might be additional emergency call routing applied within the 504 PSAP operators network. This aspect is, however, outside the scope 505 of this document. 507 LoST [I-D.ietf-ecrit-lost] might be an appropriate way to determine 508 the next ESRP or the final PSAP for routing the emergency call. 510 4.3.3. Emergency Call Identification 512 The ESRP MUST understand the Service URN mechanism 513 [I-D.ietf-ecrit-service-urn] (i.e., the 'urn:service:sos' tree) and 514 SHOULD understand national emergency dial strings. 516 4.3.4. SIP Emergency Call Signaling 518 SIP signaling [RFC3261] is expected be supported by the PSAP. The 519 ESRP MUST process the messages sent by the client, as indicated in 520 Section 4.1.4. When receiving an emergency call the ESRP will 521 dereference the reference to location information for dispatch. It 522 MUST use the SIP or SIPS derefencing scheme todo so. 524 4.3.5. Media 526 PSAPs MUST send and receive media streams on RTP [RFC3550]. The SIP 527 offer/answer [RFC3264] negotiations MUST be used to agree on the 528 media streams to be used. 530 PSAPs supporting voice MUST support G.711 A law (and mu Law in North 531 America) encoded voice as described in [RFC3551]. It is desirable to 532 support wideband codecs in the offer. Silence suppression (Voice 533 Activity Detection methods) MUST NOT be used on emergency calls. 535 Depending on national regulations PSAPs MAY need to support Instant 536 Messaging. If they need to provide this support then they MUST us 537 either [RFC3428] or [RFC3920]. 539 Depending on national regulations PSAPs MAY need to support real-time 540 text [RFC4103]. If they need to provide this support then they MUST 541 fulfill Section 7.1 of [I-D.ietf-sipping-toip]. 543 Depending on national regulations PSAPs MAY need to video support for 544 Video Relay Service (Sign language interpretation). If they need to 545 provide this support then they MUST support H.264 per [RFC3984]. 547 4.3.6. Testing 549 The description in Section 9 of [I-D.ietf-ecrit-phonebcp] is 550 applicable to this document as well. 552 5. Example 554 [Editor's Note: A WLAN hotspot or a DSL home network example could go 555 in here.] 557 6. Security Considerations 559 The security threats discussed in [I-D.ietf-ecrit-security-threats] 560 are applicable to this document. A number of security 561 vulnerabilities discussed in [I-D.barnes-geopriv-lo-sec] around faked 562 location information are less problematic in this case since location 563 information does not need to be provided by the end host itself or it 564 can be verified to fall within a specific geographical area. 566 There are a couple of new vulnerabilities raised with unauthenticated 567 emergency services since the PSAP operator does is not in possession 568 of any identity information about the emergency call via the 569 signaling path itself. In countries where this functionality is used 570 for GSM networks today this has lead to a significant amount of 571 misuse (see [reference-to-be-added]). 573 The link layer mechanisms need to provide a special way of handling 574 unauthenticated emergency services. Although this subject is not a 575 topic for the IETF itself but there are at least a few high-level 576 assumptions that may need to be collected. This includes security 577 features that may be desireable. 579 7. Acknowledgments 581 We would like to thank the authors of [I-D.ietf-ecrit-phonebcp] 582 (James Polk and Brian Rosen) for their good work. This document 583 makes heavy use of their document. 585 From an editorial point of view a lot of text in this document can be 586 replaced by references to [I-D.ietf-ecrit-phonebcp]. In order todo 587 so it is necessary to make the text in that document easier to 588 reference. This is subject of ongoing work. 590 8. Open Issues 592 The following three high-level topics have been determined as open 593 issues: 594 o NAT Traversal: A certain NAT traversal story needs to be described 595 and mandated. Most likely ICE for both the PSAP and the end host. 596 o A DNS-based discovery procedure that discovers an ESRP in the 597 local access network may need to be provided. 598 o Text about link layer requirements are missing. These are 599 necessary to make the "big picture" complete. 601 9. References 602 9.1. Normative References 604 [I-D.ietf-sip-location-conveyance] 605 Polk, J. and B. Rosen, "Location Conveyance for the 606 Session Initiation Protocol", 607 draft-ietf-sip-location-conveyance-08 (work in progress), 608 July 2007. 610 [I-D.ietf-ecrit-service-urn] 611 Schulzrinne, H., "A Uniform Resource Name (URN) for 612 Emergency and Other Well-Known Services", 613 draft-ietf-ecrit-service-urn-07 (work in progress), 614 August 2007. 616 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 617 (DHCPv4 and DHCPv6) Option for Civic Addresses 618 Configuration Information", RFC 4776, November 2006. 620 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 621 Configuration Protocol Option for Coordinate-based 622 Location Configuration Information", RFC 3825, July 2004. 624 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 625 Format", RFC 4119, December 2005. 627 [I-D.ietf-geopriv-pdif-lo-profile] 628 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 629 Considerations and Recommendations", 630 draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), 631 July 2007. 633 [I-D.ietf-geopriv-revised-civic-lo] 634 Thomson, M. and J. Winterbottom, "Revised Civic Location 635 Format for PIDF-LO", 636 draft-ietf-geopriv-revised-civic-lo-05 (work in progress), 637 February 2007. 639 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 640 (DHCP-for-IPv4) Option for Session Initiation Protocol 641 (SIP) Servers", RFC 3361, August 2002. 643 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 644 Protocol (DHCPv6) Options for Session Initiation Protocol 645 (SIP) Servers", RFC 3319, July 2003. 647 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 648 A., Peterson, J., Sparks, R., Handley, M., and E. 649 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 650 June 2002. 652 [I-D.rosen-iptel-dialstring] 653 Rosen, B., "Dialstring parameter for the Session 654 Initiation Protocol Uniform Resource Identifier", 655 draft-rosen-iptel-dialstring-05 (work in progress), 656 March 2007. 658 [I-D.ietf-sip-gruu] 659 Rosenberg, J., "Obtaining and Using Globally Routable User 660 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 661 (SIP)", draft-ietf-sip-gruu-14 (work in progress), 662 June 2007. 664 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 665 Resource Identifiers (URI): Generic Syntax", RFC 2396, 666 August 1998. 668 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 669 with Session Description Protocol (SDP)", RFC 3264, 670 June 2002. 672 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 673 Jacobson, "RTP: A Transport Protocol for Real-Time 674 Applications", STD 64, RFC 3550, July 2003. 676 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 677 Video Conferences with Minimal Control", STD 65, RFC 3551, 678 July 2003. 680 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 681 and D. Gurle, "Session Initiation Protocol (SIP) Extension 682 for Instant Messaging", RFC 3428, December 2002. 684 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 685 Conversation", RFC 4103, June 2005. 687 [RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, 688 M., and D. Singer, "RTP Payload Format for H.264 Video", 689 RFC 3984, February 2005. 691 [I-D.ietf-sipping-toip] 692 Wijk, A. and G. Gybels, "Framework for real-time text over 693 IP using the Session Initiation Protocol (SIP)", 694 draft-ietf-sipping-toip-07 (work in progress), 695 August 2006. 697 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 698 Protocol (XMPP): Core", RFC 3920, October 2004. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [I-D.ietf-ecrit-phonebcp] 704 Rosen, B. and J. Polk, "Best Current Practice for 705 Communications Services in support of Emergency Calling", 706 draft-ietf-ecrit-phonebcp-01 (work in progress), 707 March 2007. 709 9.2. Informative References 711 [I-D.ietf-ecrit-lost] 712 Hardie, T., "LoST: A Location-to-Service Translation 713 Protocol", draft-ietf-ecrit-lost-06 (work in progress), 714 August 2007. 716 [I-D.tschofenig-ecrit-architecture-overview] 717 Tschofenig, H. and H. Schulzrinne, "Emergency Services 718 Architecture Overview: Sharing Responsibilities", 719 draft-tschofenig-ecrit-architecture-overview-00 (work in 720 progress), July 2007. 722 [I-D.ietf-geopriv-l7-lcp-ps] 723 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 724 Location Configuration Protocol; Problem Statement and 725 Requirements", draft-ietf-geopriv-l7-lcp-ps-03 (work in 726 progress), July 2007. 728 [I-D.ietf-ecrit-framework] 729 Rosen, B., "Framework for Emergency Calling using Internet 730 Multimedia", draft-ietf-ecrit-framework-02 (work in 731 progress), July 2007. 733 [I-D.marshall-geopriv-lbyr-requirements] 734 Marshall, R., "Requirements for a Location-by-Reference 735 Mechanism used in Location Configuration and Conveyance", 736 draft-marshall-geopriv-lbyr-requirements-02 (work in 737 progress), July 2007. 739 [I-D.ietf-geopriv-http-location-delivery] 740 Barnes, M., "HTTP Enabled Location Delivery (HELD)", 741 draft-ietf-geopriv-http-location-delivery-01 (work in 742 progress), July 2007. 744 [I-D.ietf-ecrit-mapping-arch] 745 Schulzrinne, H., "Location-to-URL Mapping Architecture and 746 Framework", draft-ietf-ecrit-mapping-arch-02 (work in 747 progress), July 2007. 749 [I-D.ietf-ecrit-requirements] 750 Schulzrinne, H. and R. Marshall, "Requirements for 751 Emergency Context Resolution with Internet Technologies", 752 draft-ietf-ecrit-requirements-13 (work in progress), 753 March 2007. 755 [I-D.winterbottom-geopriv-held-identity-extensions] 756 Winterbottom, J. and M. Thomson, "HELD End-Point identity 757 Extensions", 758 draft-winterbottom-geopriv-held-identity-extensions-02 759 (work in progress), July 2007. 761 [I-D.winterbottom-geopriv-lis2lis-req] 762 Winterbottom, J. and S. Norreys, "LIS to LIS Protocol 763 Requirements", draft-winterbottom-geopriv-lis2lis-req-00 764 (work in progress), June 2007. 766 [I-D.ietf-ecrit-security-threats] 767 Taylor, T., "Security Threats and Requirements for 768 Emergency Call Marking and Mapping", 769 draft-ietf-ecrit-security-threats-04 (work in progress), 770 April 2007. 772 [I-D.schulzrinne-ecrit-location-hiding-requirements] 773 Schulzrinne, H., "Location Hiding: Problem Statement and 774 Requirements", 775 draft-schulzrinne-ecrit-location-hiding-requirements-00 776 (work in progress), July 2007. 778 [I-D.barnes-geopriv-lo-sec] 779 Barnes, R., "Threats to GEOPRIV Location Objects", 780 draft-barnes-geopriv-lo-sec-00 (work in progress), 781 July 2007. 783 Authors' Addresses 785 Henning Schulzrinne 786 Columbia University 787 Department of Computer Science 788 450 Computer Science Building 789 New York, NY 10027 790 US 792 Phone: +1 212 939 7004 793 Email: hgs+ecrit@cs.columbia.edu 794 URI: http://www.cs.columbia.edu 796 Stephen McCann 797 Siemens/Roke Manor Research 799 Email: stephen.mccann@roke.co.uk 801 Gabor Bajko 802 Nokia 804 Email: Gabor.Bajko@nokia.com 806 Hannes Tschofenig 807 Nokia Siemens Networks 808 Otto-Hahn-Ring 6 809 Munich, Bavaria 81739 810 Germany 812 Email: Hannes.Tschofenig@nsn.com 813 URI: http://www.tschofenig.com 815 Full Copyright Statement 817 Copyright (C) The IETF Trust (2007). 819 This document is subject to the rights, licenses and restrictions 820 contained in BCP 78, and except as set forth therein, the authors 821 retain all their rights. 823 This document and the information contained herein are provided on an 824 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 825 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 826 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 827 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 828 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 829 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 831 Intellectual Property 833 The IETF takes no position regarding the validity or scope of any 834 Intellectual Property Rights or other rights that might be claimed to 835 pertain to the implementation or use of the technology described in 836 this document or the extent to which any license under such rights 837 might or might not be available; nor does it represent that it has 838 made any independent effort to identify any such rights. Information 839 on the procedures with respect to rights in RFC documents can be 840 found in BCP 78 and BCP 79. 842 Copies of IPR disclosures made to the IETF Secretariat and any 843 assurances of licenses to be made available, or the result of an 844 attempt made to obtain a general license or permission for the use of 845 such proprietary rights by implementers or users of this 846 specification can be obtained from the IETF on-line IPR repository at 847 http://www.ietf.org/ipr. 849 The IETF invites any interested party to bring to its attention any 850 copyrights, patents or patent applications, or other proprietary 851 rights that may cover technology that may be required to implement 852 this standard. Please address the information to the IETF at 853 ietf-ipr@ietf.org. 855 Acknowledgment 857 Funding for the RFC Editor function is provided by the IETF 858 Administrative Support Activity (IASA).