idnits 2.17.1 draft-polk-newton-ecrit-arch-considerations-02.txt: -(277): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 748. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 567 has weird spacing: '...version opera...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 162, but not defined == Missing Reference: 'ID-DHCP-URI' is mentioned on line 353, but not defined == Unused Reference: 'RFC2119' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC3825' is defined on line 690, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group James Polk 3 Internet-Draft Cisco Systems 4 Expires: Sept 6th, 2006 Andrew Newton 5 VeriSign 6 March 6th, 2006 8 Emergency Context Routing of Internet Technologies 9 Architecture Considerations 10 draft-polk-newton-ecrit-arch-considerations-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6th, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document discusses architectural considerations for emergency 44 context routing of Internet technologies. The purpose of this 45 document is to provide a systemic view of emergency context routing, 46 discuss unresolved issues, and explain the relationship of some of 47 the proposals to these issues, while discussing potential directions 48 that might be still be necessary for the working group to 49 investigate. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1 Division of Labor . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Terminology, Acronyms and Definitions . . . . . . . . . . 4 56 2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. LCMS Mapping . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Conveyance . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.1 Location Conveyance . . . . . . . . . . . . . . . . . . . 8 61 5.2 Identity Conveyance . . . . . . . . . . . . . . . . . . . 8 62 6. Universal Emergency Identifiers . . . . . . . . . . . . . . . 9 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7.1 Security of the LCMS . . . . . . . . . . . . . . . . . . 10 65 7.2 Security of Location Conveyance . . . . . . . . . . . . . 11 66 7.3 Security of Bootstrapping . . . . . . . . . . . . . . . . 11 67 7.4 Security of Conversion . . . . . . . . . . . . . . . . . 11 68 8. Data distribution . . . . . . . . . . . . . . . . . . . . . . 12 69 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13 70 10. Conflation . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 11. Rerouting/Transfer . . . . . . . . . . . . . . . . . . . . . 13 72 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 13.1 Normative References . . . . . . . . . . . . . . . . . . 14 75 13.2 Informative References . . . . . . . . . . . . . . . . . 14 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 77 A. Appendix A. Additional stuff . . . . . . . . . . . . . . . . 15 78 Intellectual Property and Copyright Statements . . . . . . . 15 80 1. Introduction 82 The solution to proper emergency call identification, management and 83 routing over the Internet involves many components and coordination 84 between them. This document describes the necessary interaction 85 between these components. The information given in this document 86 may not be complete, and some of the issues presented in this 87 document may not be resolved by the community. The intent of this 88 document is to describe a "big picture" view of the process, 89 describe prevailing thoughts on this subject and describe unresolved 90 issues in hopes of bringing about consensus within the community on 91 these topics. 93 The current architecture of Emergency Context Routing of Internet 94 Technologies is composed of the following: 96 Bootstrapping: delivery of configuration and location information to 97 the client at or near power-up time. 99 Conversion: conversion of location information into forms usable in 100 mapping and conveyance, if necessary. 102 LCMS Mapping: conversion of endsystem location information into 103 addresses usable to initiate or progress communication towards an 104 emergency call center (a PSAP). 106 Conveyance: delivery of endsystem location information to an 107 emergency call center during the emergency call (used for 108 first responder dispatch). 110 There are many unresolved issues regarding these steps and related 111 matters. The following list is not exhaustive, but includes most of 112 the issues brought grouping discussions to date (and a few new 113 ones). 115 Universal emergency identifier: there needs to be a universal 116 emergency identifier to prevent highly localized usage and 117 confusion by users and systems of what applies to a certain 118 region, and what does not. 120 Security: the security properties necessary for the proper 121 protection of LCMS data are not well understood. 123 Data distribution: the distribution of LCMS data closer to the 124 points of queries within the Internet. 126 Extensibility: the methods for extensibility in all components of 127 the system must be well understood. 129 Conflation: many of the components proposed for use in the routing 130 of emergency calls have other uses and most have not been 131 primarily designed for the emergency call routing case. 133 1.1 Division of Labor 135 As stated above, not all of the components used in the process of 136 routing an emergency call to the correct emergency call center over 137 the Internet have been defined for the exclusive use of this case, 138 and therefore not all of the specification work is being conducted 139 within the scope of the charter of the ECRIT working group. 141 Bootstrapping of location information, both geospatial and civic, 142 via DHCP is work in progress in the GEOPRIV working group. 143 Bootstrapping of URI references via DHCP is work in progress in the 144 DHC working group. 146 The definition of location objects and the use of schemas to 147 describe location is work in progress in the GEOPRIV working group. 148 The specification of conveyance of location objects via SIP is work 149 in progress in the SIP working group. 151 The mapping of location information to URIs is the primary function 152 of the ECRIT working group. The set of mechanisms and services 153 working in conjunction with each other to conduct this mapping is 154 referred to as the Location Context Mapping System, or LCMS by this 155 document for the purposes of clarity. 157 1.2 Terminology, Acronyms and Definitions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC 2119]. 163 The following terms and definitions will be used throughout this 164 document: 166 Application (Layer) Provider (ALP) - provider of application level 167 services such as a voice over IP service that is completely 168 divorced from the Link provider, and may be divorced from the 169 Internet Attachment Provider of an endsystem that is merely 170 providing a layer 3 connectivity service. 172 ALP - Application (Layer) Provider 174 Emergency Services Gateway (ESGW) - The special IP to circuit- 175 switched gateway that front-ends an emergency services Selective 176 Router (SR) (which directs all TDM based 911/112 type calls to 177 the appropriate PSAP within a given physical region) 179 Emergency Services Routing Proxy (ESRP) - a special instance of a 180 SIP Proxy that understands emergency routing of messages 181 identified as emergency messages to a PSAP based on 182 the location of the caller that is included in the message 184 ESGW - Emergency Services Gateway 186 ESRP - Emergency Services Routing Proxy 188 IAP - Internet Attachment Provider 190 Internet Attachment Provider (IAP) - typically the organization that 191 provides Internet or IP access to the client (i.e. assigns the 192 client an IP address and/or provides the client with IP transit. 194 Location Context Mapping System � A set of coordinated mechanisms 195 and services that map a physical location (geospatial or civic) 196 to a network address. 198 LCMS � Location Context Mapping System 200 LIS - Location Information Server 202 PSAP - Public Safety Answering Point 203 Location Information Server (LIS) � Provides a mapping function to 204 relate unique identifiers for IP devices at physical network 205 access points and the geographic descriptions of their location 206 (e.g., civic location/street addresses or geographic 207 coordinates). Responds to queries for location information. 209 Public Safety Answering Point (PSAP) - the emergency response call 210 center talking the local emergency calls from people in distress. 211 This facility can be logical, and can transfer (reroute) any 212 request sent to it to another facility deemed more appropriate to 213 receive the request. 215 2. Bootstrapping 217 Bootstrapping delivers configuration information to the 218 client. The most obvious use of bootstrapping is for an endsystem 219 to ask for and receive its IP address, Subnet Mask and Default 220 Gateway addresses. This could also be used to deliver the 221 geospatial or civic address of the client to it for future use. 222 This is typically done at device or individual application 223 boot times. Unlike other parts of the architecture, bootstrapping 224 is the only phase of the emergency call routing process that does 225 not have a single solution. This is due to the many network 226 configuration techniques used by access networks. 228 There are three well-known methods of bootstrapping: 230 1. Using the DHCP protocol 231 2. Using the PPP protocol 232 3. Using IEEE 802.1 LLDP-MED 234 For location information, there are two types: location information 235 regarding a civic address (e.g. 123 Main St ) and geospatial 236 information (e.g. x, y, z coordinates). 238 The set of configuration data types has not been discussed or 239 resolved. But the following types of configuration information have 240 been noted: 1) references to LCMS servers, 2) references to PSAPs, 241 and 3) references to location information servers. 243 References to LCMS servers obviate the need for global hierarchies 244 of LCMS data directories (which have proven politically difficult in 245 other voice over IP matters) and reduce the coordination to only the 246 necessary jurisdictional boundaries. 248 References to PSAPs obviate the need for the mapping steps in cases 249 where location is not likely to be a determining factor in emergency 250 call routing (e.g. location is fixed and the emergency call center 251 is known). 253 References to location information servers enable better separation 254 for knowledge of location from the access network. 256 3. Conversion 258 Conversion of location information from one format to the other 259 format is conducted for the benefit of the LCMS servers and 260 conveyance of the location information. There are two aspects to 261 this conversion: syntactic conversion of the location information 262 from the binary formats used in bootstrapping to the XML format used 263 in PIDF-LO, and conversion of the civic location information to 264 geospatial location information or vice versa. 266 Syntactic conversion is a necessary function, and it can take two 267 different forms: conversion from the binary DHCP format to the 268 PIDF-LO conveyance format and conversion to a LCMS format if the 269 LCMS interface does not use PIDF-LO. 271 Conversion of location information from a civic address to 272 geospatial coordinates or from geospatial coordinates to a civic 273 address is much more controversial. There is no doubt that civic 274 addresses are much easier to consume by humans than geospatial 275 coordinates, however conversion from geospatial coordinates to a 276 civic address can be error prone and in cases involving large areas 277 (e.g. a farm, an outdoor park, etc�) the resulting civic address can 278 be of limited utility. Further, civic coordinates only address 279 a fraction of the land of this planet, as civic addresses are to a 280 great degree tied to the existence of a nearby street, which are 281 prevalent in cities, but are scarce to non-existent in rural areas. 282 Therefore, a combination of the two formats will be required 283 regardless of mankind's consumption preference. 285 4. LCMS Mapping 287 The creation of an LCMS, which will convert location information 288 into references (i.e. URIs) to emergency call centers, is the 289 primary area of work for the ECRIT working group. There are two 290 times in which this LCMS function can occur successfully: 292 1. before the device attempts contact with a PSAP, and 294 2. after the device initiates contact with the PSAP, but before the 295 correct PSAP is determined by the ESRP making the LCMS query. 297 Accomplishing mapping of a device's location with the proper PSAP 298 can be done statically or dynamically, or in a layered - combination 299 - approach. 301 Statically - If a site is small enough, for example residential or 302 Small or single building business scale, all devices in either of 303 these types of locations can be configured to download, or have 304 downloaded to them, their location information and the SIP or 305 SIPS URI for contacting the appropriate PSAP for that location. 307 Dynamically - for the above types of locations, or for larger 308 locations, the client's location can be used to "look up" the 309 appropriate PSAP SIP or SIPS URI, and have this configuration 310 information downloaded to each client requesting it. This can 311 also be pushed to all clients regardless of whether they asked 312 for the information or not. This pushing of the PSAP URI(s) can 313 be at some interval to maintain freshness of the URI(s), as stale 314 URI(s) are a concern to some. 316 For the static configuration, for each given endpoint or section of 317 a network, a known PSAP SIP or SIPS URI is downloaded to the 318 client(s) without the clients providing their individual location to 319 perform the LCMS function. In the case of dynamic configuration of 320 a URI, the client provides their location to an LCMS server to do 321 this look-up, with the answer sent to the client for future use by 322 any application on that client, including for emergency services. 324 In a layered approach, there does not need to be a one-size-fits-all 325 solution, but a combination of ways in which the mapping resolution 326 is accomplished towards the goal of having the emergency call set-up 327 reach the appropriate PSAP. For example, a solution with the most 328 risk can be used last, but in a way it does not rely on any other 329 steps to have occurred to function properly. In this scenario, the 330 simplest means of mapping with the least risk can be performed 331 initially, before the device ever knows it will generate an 332 emergency call set-up message. In this way, this first mechanism is 333 done at boot-time, and the mapping during the actual emergency call 334 can still happen whether or not the bootstrapping took place or not. 335 This layered approach would be with a goal of solving the function 336 of mapping one of the independent steps towards entering the 337 appropriate PSAP SIP or SIPS URI into the INVITE message. When this 338 URI is learned should not matter, as long as it is the appropriate 339 URI. 341 Another combined approach can be attained in the following scenario: 342 if the endsystem knows of an authoritative LCMS server regardless of 343 which network or domain the client is connected to, the endsystem 344 can contact this server to get its PSAP SIP/SIPS URI based on its 345 location provided by the local access network. In this scenario, an 346 endsystem can have a trust association established with a particular 347 server (or server service) that it contacts as soon as it either 348 learns its location from a local network/domain or somehow 349 determines it has moved while remaining "connected" to that 350 network/domain. 352 For the device configuration of a PSAP SIP or SIPS URI, currently 353 only DHCP is being proposed as a solution [ID-DHCP-URI]. This 354 proposal is not an LCMS function because it does not send location 355 to a server and receive the mapping answer containing a URI. DHCP 356 is used here to only deliver the URI to be used as the Request-URI 357 of the emergency SIP INVITE. 359 To date there are three protocol proposals for LCMS: LUMP, ECON, and 360 DNS SOS. LUMP is an XML-based, SOAP solution with emphasis on data 361 distribution. ECON is an XML-based, IRIS solution with emphasis on 362 lightweight data exchange, and DNS SOS is a DNS-based solution with 363 emphasis on re-using DNS semantics. 365 Finally, some jurisdictions may find it necessary to withdraw the 366 LCMS protocol from public view and place its function within an 367 ESRP. At the option of the jurisdiction, more than one ESRP function 368 may be implemented in series, to provide increasingly precise 369 routing to the appropriate PSAP. 371 5. Conveyance 373 5.1 Location Conveyance 375 Once the address of the PSAP is known, either through bootstrapping 376 or through LCMS mapping, a call can be initiated with the PSAP. 377 Location information is sent to the PSAP as meta-data of the call 378 using PIDF-LO. This facet is not part of the ECRIT WG, but cannot 379 be overlooked. Even if the caller contacts the appropriate PSAP, 380 that PSAP will still require knowledge of where the caller is in 381 order to dispatch emergency responders (i.e. help). Issues 382 regarding the acquisition of this knowledge are discussed in Section 383 7.2. 385 Passing location information within the voice application protocol 386 is commonly referred to as "location-by-value". There exists 387 another concept where a reference to a location server is passed 388 within the voice application protocol instead of the actual location 389 information. This is known a "location-by-reference". Location-by- 390 reference is not without controversy, and its plusses and minuses 391 will be discussed in a future version of this document. 393 5.2 Identity Conveyance 395 There is a general desire on behalf of PSAP operators to have the 396 identity of a caller conveyed within a call. This identity has two 397 parts: an identity asserted to be authentic and a call-back 398 reference for re-establishment of communications. 400 Of the two parts of this identity conveyance, the authentication of 401 the identity is the most contentious and burdensome to solve. For 402 example, if a traveler with a phone purchased in London were to make 403 an emergency phone call in New York, what trust relationship exists 404 between the authorities of New York and a phone retailer in London? 406 Making matters more complicated, conveyance of identity for 407 emergency calling is not a work item for any IETF working group. 409 6. Universal Emergency Identifiers 411 Throughout the world, there are many different numbers in use to 412 signal emergency phone calls. Some counts have this number as high 413 as 60 unique number sequences worldwide. This lack of uniformity 414 also leads to collision. For example, in some areas of the world, 415 dialing the number 0 is used for calling for help, whereas in other 416 parts of the world, this would not accomplish its intended emergency 417 meaning, resulting in the caller being told to hang up and dial 418 another number. 420 Therefore, one of the ECRIT requirements is for a universal 421 emergency identifier to signal an emergency. The need for it to be 422 universal (or well-known) is threefold: so that all the components 423 in the emergency call routing process may properly operate based on 424 its presence in a message, to avoid collisions with other purposes 425 (as stated above), and so that clients may localize its meaning to 426 end users. The issue is that there is not just one single 427 identifier related to emergency calls, but that there are many 428 identifiers related to emergency calls for various specific types of 429 emergencies. 431 Multiple identifiers lead to confusion and many have overlapping 432 meaning. For example, the separate identifiers "mountain" and 433 "rescue" could mean the same thing to a user needing to be rescued 434 from a mountainous area. Additionally, some jurisdictions have 435 custom identifiers that are either unused globally or have a limited 436 applicability. 438 Each LCMS proposal takes a different approach to solving this 439 problem. ECON takes the simplest approach, specifying a simple list 440 of 3 identifiers. DNS SOS specifies a list of six identifiers. LUMP 441 specifies a hierarchy of identifiers. 443 What is not clear, or has not been well defined, is the need for 444 even the simplest of these approaches. It is not even well 445 understood if end users, in an emergency situation, will be able to 446 rationalize the difference between "emergency" and a simple list of 447 "police", "fire", and "medical". While some have suggested this is 448 in practice in some parts of the world today, that does not 449 necessarily mean this will become universal in usage. It appears 450 that if there is a single master identifier with more than one sub- 451 identifier, that this arrangement should be used where it is 452 understood, and perhaps adopted elsewhere as jurisdictions decide to 453 segment this capability based on education within that area. 455 What appears obvious to avoid is to have different identifiers for 456 help in different parts of the world moving forward. If only 457 'sos.police@...' reaches the police in a country where Alice does 458 not live when she sends a SIP INVITE to 'sos@...', ECRIT as a WG has 459 not likely accomplished its goal. 461 Locales that choose to have sub-identifiers for granularity must 462 have an architected solution for the higher level identifier as 463 well. 465 7. Security Considerations 467 7.1 Security of the LCMS 469 It is the goal of the working group to develop a dynamic LCMS 470 protocol that is both secure and responsive, two features that tend 471 to conflict with each other. Security for this mapping solution has 472 fallen into two broad categories: object signing and channel 473 security. 475 Object signing has three benefits: integrity of data during 476 distribution, the potential for utilization in UDP packets, and pre- 477 calculation of cryptographic data. However, in cases where partial 478 matching of the query are to be allowed (i.e. parts of a civic 479 address are to be ignored in the query) or the query cannot be known 480 ahead of time (i.e. the whole set of geospatial coordinates is 481 known but not in practical terms), object signing will require "on- 482 line" signing which negates advantages in data distribution and 483 cryptographic pre-calculations. 485 In addition, the use case regarding the invalidity of a signed 486 object may be no different from that of a validly signed object. 487 Users confronted with an emergency may not be able to appreciate the 488 difference in validity, and even if they did, may not alter their 489 course of action (i.e. they continue with the emergency call 490 anyway). 492 Channel security requires expensive cryptographic calculations that 493 cannot be computed ahead of time and requires multiple packet 494 exchanges (i.e. roundtrips) to establish. However, this approach 495 has the benefit of securing all parts of the transaction, and unlike 496 object signing, is well used and well understood on the Internet. 498 The security properties of each of the three LCMS proposals is as 499 follows: 501 LUMP uses both channel security (TLS connections to the query 502 server) and object signing (signed entries in the database). 504 DNS SOS uses both channel security (TLS in connections to fetching 505 polygons and other information) and object signing (in DNSSEC 506 for the protection of NAPTR records). 508 ECON uses channel security (TLS connections to the query server) as 509 an option setup by the operator of the service and a lightweight 510 UDP transfer protocol for scenarios where security is not 511 needed. 513 7.2 Security of Location Conveyance 515 There is a general desire to protect PSAPs from malicious calls. 516 Yet, how this is to be accomplished is not clear or well defined. 518 Complicating this issue is the simple fact that many PSAPs will 519 accept a call without location information related to the caller. 520 Additionally, many PSAPs give priority or parity to location 521 information collected by a human operator from a human caller. Due 522 to this fact, it has been observed that any security mechanism put 523 into place by ECRIT can simply be routed around by directly 524 contacting a PSAP. 526 In cases where a PSAP would wish to disregard calls of unknown 527 provenance, no guidelines have clearly been stated as to how such 528 trust relationships would be erected. 530 7.3 Security of Bootstrapping 532 Where critical decisions might be based on the value(s) of the 533 bootstrapping process, such as a URI option from [ID-DHC-URI], DHCP 534 authentication in [RFC3118] SHOULD be used to protect the integrity 535 of the DHCP options. 537 Since there is no privacy protection for DHCP messages, an 538 eavesdropper who can monitor the link between the client and 539 destination DHCP server to capture any URIs in transit. 541 When implementing a DHC server that will serve clients across an 542 uncontrolled network, one should consider the potential security 543 risks. 545 All that said, if DNS is not secure, and bootstrapping is difficult 546 to secure based on what it takes to accomplish [RFC3118], is 547 securing the mapping service worth the effort and pain to achieve? 549 7.4 Security of Conversion 551 Location is a vital part of emergency messaging. As discussed 552 earlier, an endsystem will not likely be in control of which format 553 of location it receives from a roamed to network. For more fixed 554 endsystems, this should not be the case. If an endsystem does 555 receive location in a format it knows an application on that 556 endsystem does not prefer, the endsystem can contact a server or 557 service, if one is known, to convert this format to the other 558 format. 560 As a non-emergency example, most humans understand street addresses 561 much better than GPS coordinates. If a roaming device, say using 562 802.11 at a hotspot, acquires its location via DHCP Option 123 [RFC 563 3825], it can determine if an application used by that device 564 prefers the civic format when using an instant messaging application 565 on that device. Before the IM application is launched, or as the 566 app is launched, the device can seek a conversion server to perform 567 this format conversion operation. How does a client learn of a 568 server that can do this? [ID-DHC-URI] provides one means for a 569 device to learn the URL of a server that can do this function, or 570 this can be preconfigured in the device as a trusted source for this 571 conversion, wherever it is - as long as there is connectivity to 572 that trusted source. 574 In the emergency case, perhaps the device knows it needs to convert 575 to the civic format to have an ESRP perform an LCMS query, but the 576 local network gave it a geospatial location only. If the conversion 577 server is preconfigured, this provides the ability to have the two 578 devices, say the phone and the conversion server, establish a trust 579 relationship, perhaps with pre-shared keys. This reduces the round 580 trip times, making it more efficient. This also provides a more 581 secure means of communication since both entities 'know' each other. 583 8. Data distribution 585 There is a desire to locate LCMS data in the LCMS close to the 586 points of query in the Internet for performance reasons. In 587 addition, some jurisdictions distribute authority for this data upon 588 hierarchical lines. However, the needs for data distribution beyond 589 these high-level requirements are not well known. For instance, the 590 known life expectancy of data distributed to caches is not well 591 known, nor are update procedures in the distribution of this data. 593 Each of the three LCMS proposals addresses this problem in a 594 different way: 596 DNS SOS relies upon the cache machinery of DNS. The population of 597 DNS caches with location information is accomplished through 598 validation of caller locations (a process during provisioning of 599 a callers location and before any emergency call). This proposal 600 does not address early cache expiration due to limited cache 601 memory, by accepted practices of DNS operations, or by routine 602 maintenance of DNS servers. 604 LUMP defines a caching mechanism that identifies objects by hash 605 value in order to accomplish a mesh of caches between nodes. The 606 population of the caches with location information is 607 accomplished through validation of caller locations (a process 608 conducted during provisioning of a callers location and before 609 any emergency call). 611 ECON defines no preference for data distribution due to the limited 612 requirements available. However, it does describe two methods 613 that could be employed: the serialization of data to files for 614 distribution via standard transfer protocols and an on-line, 615 incremental approach capable of distributing entries before their 616 activation date. 618 9. Extensibility 620 Within the ECRIT working group, there appears to be rough consensus 621 on the need for extensible mechanisms, and hence an extensible LCMS 622 protocol capable of extensions in its query interface and resulting 623 output. This desire for extensibility is born from a general sense 624 that not all the problems of emergency call routing over the 625 Internet will be fully exposed until deployment of a first 626 generation solution and from a more specific sense of the 627 incompleteness of the civic address schema in PIDF-LO. 629 As an example of the more general case, the document [ID-ECRIT- 630 JAPAN] describes a numeric address code equivalent to the civic 631 elements through in PIDF-LO used in conjunction with 632 geospatial coordinates to conduct emergency call handling in Japan. 633 As an example of the more specific case, PIDF-LO does not contain an 634 element to describe street section numbers as used in Taiwan. 636 10. Conflation 638 As mentioned in the introduction, many of the components used in the 639 process of routing emergency calls were not designed primarily for 640 this task and are being developed in working groups that do not have 641 emergency call routing explicitly defined in their chartered scope. 643 As a general example, conveyance of location information within a 644 call also has applicability to delivery businesses, such as pizza 645 restaurants that need to know the location of the caller for 646 delivery purposes. In a more technical sense, much of what is known 647 about civic addresses worldwide is a result of the study of postal 648 delivery, and therefore schemas used as location input for emergency 649 call routing may not be tuned properly. 651 Within the ECRIT working group, there are no requirements regarding 652 the resilience of the emergency call routing process as it relates 653 to inputs that have not been designed for this specific purpose. 655 11. Rerouting/Transfer 657 Another facet of the ECRIT WG that has not been addressed is what to 658 do if a PSAP receives an emergency call and the call should not have 659 been routed to that PSAP. What does the PSAP do next, and can this 660 action be automated? Does the PSAP have an additional screening 661 capability in some ESRP at the PSAP interior edge to do a final 662 check that the call set-up is to the appropriate PSAP, taking steps 663 not yet defined if this PSAP is not the appropriate one for this 664 particular call set-up? 666 This is more a rerouting function of the call set-up, or of a call 667 transfer function if the call is answered before determining this is 668 an inappropriate PSAP. For example, VPNs will likely cause some 669 emergency calls to go erroneously to the city that the caller's 670 corporate offices are located in rather than to where the caller is. 671 This has not been considered to date, yet likely should be - as 672 message reroute should be possible anytime an ESRP misdirects a 673 message towards a PSAP, just not he appropriate PSAP. 675 12. Acknowledgements 677 Nadine Abbott provided text regarding ESRP usage and comments 678 regarding the inclusion of discussion of location-by-value vs. 679 location-by-reference. Richard Statsny suggested this document 680 would be a more complete introduction to the problem space if it 681 included information regarding identity conveyance. 683 13. References 685 13.1 Normative References 687 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 688 Requirement Levels", RFC 2119, March 1997 690 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 691 Configuration Protocol Option for Coordinate-based Location 692 Configuration Information", RFC 3825, July 2004 694 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 695 Messages", RFC 3118, June 2001. 697 13.2 Informative References 699 [ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option 700 for Requesting and Receiving Uniform Resource Identifiers", 701 draft-polk-dhc-uri-03.txt, "work in progress", March 2006 703 [ID-ECRIT-JAPAN] H. Arai, M. Kawanishi, draft-arai-ecrit-japan-req- 704 01.txt, "work-in-progress", May 2005 706 Author's Address 708 James M. Polk 709 3913 Treemont Circle 710 Colleyville, Texas 76034 711 USA 713 Phone: +1-817-271-3552 714 Fax: none 715 Email: jmpolk@cisco.com 717 Andrew Newton 718 21345 Ridgetop Circle 719 Dulles, VA 20166 721 Phone: +17039483382 722 Email: andy@hxr.us 724 Appendix A. Additional stuff 726 Intellectual Property Statement 728 The IETF takes no position regarding the validity or scope of any 729 Intellectual Property Rights or other rights that might be claimed 730 to pertain to the implementation or use of the technology described 731 in this document or the extent to which any license under such 732 rights might or might not be available; nor does it represent that 733 it has made any independent effort to identify any such rights. 734 Information on the procedures with respect to rights in RFC 735 documents can be found in BCP 78 and BCP 79. 737 Copies of IPR disclosures made to the IETF Secretariat and any 738 assurances of licenses to be made available, or the result of an 739 attempt made to obtain a general license or permission for the use 740 of such proprietary rights by implementers or users of this 741 specification can be obtained from the IETF on-line IPR repository 742 at http://www.ietf.org/ipr. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights that may cover technology that may be required to implement 747 this standard. Please address the information to the IETF at 748 ietf-ipr@ietf.org. 750 Disclaimer of Validity 752 This document and the information contained herein are provided on 753 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 754 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 755 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 756 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 757 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 760 Copyright Statement 762 Copyright (C) The Internet Society (2006). This document is subject 763 to the rights, licenses and restrictions contained in BCP 78, and 764 except as set forth therein, the authors retain all their rights. 766 Acknowledgment 768 Funding for the RFC Editor function is currently provided by the 769 Internet Society.