idnits 2.17.1 draft-ietf-ecrit-mapping-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 397 has weird spacing: '... Leonia sip...' == Line 398 has weird spacing: '...ort Lee sip:e...' == Line 399 has weird spacing: '...Teaneck sip:...' -- 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 (March 5, 2009) is 5529 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-08 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-08 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Informational March 5, 2009 5 Expires: September 6, 2009 7 Location-to-URL Mapping Architecture and Framework 8 draft-ietf-ecrit-mapping-arch-04.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 6, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes an architecture for a global, scalable, 47 resilient and administratively distributed system for mapping 48 geographic location information to URLs, using the Location-to- 49 Service (LoST) protocol. The architecture generalizes well-known 50 approaches found in hierarchical lookup systems such as DNS. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 5 58 4.1. The Principal Components . . . . . . . . . . . . . . . . . 5 59 4.2. Minimal System Architecture . . . . . . . . . . . . . . . 7 60 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8 63 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 64 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 11 65 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11 66 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 12 67 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 It is often desirable to allow users to access a service that 80 provides a common function, but is actually offered by a variety of 81 local service providers. In many of these cases, the service 82 provider chosen depends on the location of the person wishing to 83 access that service. Among the best-known public services of this 84 kind is emergency calling, where emergency calls are routed to the 85 most appropriate public safety answering point (PSAP), based on the 86 caller's physical location. Other services, from food delivery to 87 directory services and roadside assistance, also follow this general 88 pattern. This is a mapping problem [RFC5012], where a geographic 89 location and a service identifier (URN) [RFC5031] is translated into 90 a set of URIs, the service URIs, that allow the Internet system to 91 contact an appropriate network entity that provides the service. 93 The caller does not need to know where the service is being provided 94 from, and the location of the service provider may change over time, 95 e.g., to deal with temporary overloads, failures in the primary 96 service provider location or long-term changes in system 97 architecture. For emergency services, this problem is described in 98 more detail in [I-D.ietf-ecrit-framework]. 100 The overall emergency calling architecture [I-D.ietf-ecrit-framework] 101 separates mapping from placing calls or otherwise invoking the 102 service, so the same mechanism can be used to verify that a mapping 103 exists ("address validation") or to obtain test service URIs. 105 Mapping locations to URIs describing services requires a distributed, 106 scalable and highly resilient infrastructure. Authoritative 107 knowledge about such mappings is distributed among a large number of 108 autonomous entities that may have no direct knowledge of each other. 109 In this document, we describe an architecture for such a global 110 service. It allows significant freedom to combine and split 111 functionality among actual servers and imposes few requirements as to 112 who should operate particular services. 114 Besides determining the service URI, end systems also need to 115 determine the local service numbers. As discussed in Section 9, the 116 architecture described here can also address that problem. 118 The architecture described here uses the Location-to-Service 119 Translation (LoST) [RFC5222] protocol, although much of the 120 discussion would also apply for other mapping protocols satisfying 121 the mapping requirements [RFC5012]. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119] and 128 indicate requirement levels for compliant implementations. 130 3. Definitions 132 In addition to the terms defined in [RFC5012], this document uses the 133 following terms to describe LoST clients and servers: 135 authoritative mapping server (AMS): An authoritative mapping server 136 (AMS) is a LoST server that can provide the authoritative answer 137 to a particular set of queries, e.g., covering a set of PIDF-LO 138 civic labels or a particular region described by a geometric 139 shape. In some (rare) cases of territorial disputes, two 140 resolvers may be authoritative for the same region. An AMS may 141 redirect or forward a query to another AMS within the tree. 142 child: A child is an AMS that is authoritative for a subregion of 143 another AMS. A child can in turn be parent for another AMS. 144 (tree node) cluster: A node cluster is a group of LoST servers that 145 all share the same mapping information and return the same results 146 for queries. Clusters provide redundancy and share query load. 147 Clusters are fully-meshed, i.e., they all exchange updates with 148 each other. 149 coverage region: The coverage region of an AMS is the geographic 150 region within which the AMS is able to authoritatively answer 151 mapping queries. Coverage regions are generally, but not 152 necessarily, contigous and may be represented as either a subset 153 of a civic address or a geometric object. 154 forest guide (FG): A forest guide (FG) has knowledge of the coverage 155 region of trees for a particular top-level service. 156 mapping: A mapping is a short-hand for 'mapping from a location 157 object to one or more URLs describing either another mapping 158 server or the desired service URLs'. 159 parent: A mapping server that covers the region of all of its 160 children. A mapping server without a parent is a root AMS. 161 resolver: A resolver is contacted by a seeker, consults a forest 162 mapping server and then resolves the query using an appropriate 163 tree. Resolvers may cache query results. 164 seeker: A seeker is a LoST client requesting a mapping. A seeker 165 does not provide mapping services to others, but may cache results 166 for its own use. 168 tree: A tree consists of a self-contained hierarchy of authoritative 169 mapping servers for a particular service. Each tree exports its 170 coverage region to the forest mapping servers. 172 4. Overview of Architecture 174 4.1. The Principal Components 176 The mapping architecture distinguishes four logical roles: seekers, 177 resolvers, authoritative mapping servers (AMS) and forest guides 178 (FGs). End users of the LoST-based [RFC5222] mapping mechanism, 179 called seekers, contact resolvers that cache query results and know 180 one or more forest guides. Forest guides form the top level of a 181 conceptual hierarchy, with one or more trees providing a hierarchical 182 resolution service for different geographic regions. Forest guides 183 know the geographic coverage region of all or almost all trees and 184 direct queries to the node at the top of the appropriate tree. Trees 185 consist of authoritative mapping servers and maintain the 186 authoritative mapping information. 188 Seekers, resolvers, authoritative mapping servers and forest guides 189 all communicate using LoST; indeed, it is likely that in many cases, 190 the same software can operate as a resolver, authoritative mapping 191 server and forest guide. In addition to the basic LoST query 192 protocol [RFC5222], a synchronization protocol 193 [I-D.schulzrinne-ecrit-lost-sync] may be used to exchange information 194 between forest guides or to push coverage information from a tree 195 node to its parent. 197 Seekers may be part of VoIP or other end systems, or SIP proxies or 198 similar call routing functions. 200 Figure 1 shows the interaction of the components. The lines 201 indicating the connection between the forest guides are logical 202 connections, indicating that they are synchronizing their information 203 via the synchronization protocol [I-D.schulzrinne-ecrit-lost-sync]. 205 /-\ /-\ +-----+ +-----+ 206 | S +******* R ********* FG *-----------------+ FG | 207 \-/ \-/ | |* | | 208 +--+--+ * +--+--+ 209 | * | 210 | * | 211 | * | 212 | * | 213 /-\ +--+--+ * +--+--+ 214 | R +------>+ FG +-----*-----------+ FG | 215 \-/ | | * | | 216 +--+--+ * +--+--+ 217 | * | 218 | * | 219 | * | 220 |*** ^ 221 / \ / \ 222 / \ / \ 223 / \ / \ 224 / \ / \ 225 ----------- ----------- 226 tree tree 228 Architecture diagram, showing seekers (S), resolvers (R), forest 229 guides (FG) and trees. The star (*) line indicates the flow of the 230 query and responses in recursive mode, while the lines indicate 231 synchronization relationships. 233 Figure 1 235 The mapping function for the world is divided among trees. The 236 collection of trees may not cover the whole world and trees are added 237 and removed as the organization of mapping data changes. We call the 238 collection of trees a forest. There is no limit on the number of 239 trees within the forest, but the author guesses that the number of 240 trees will likely be somewhere between a few hundred and a few 241 thousand. The lower estimate would apply if each country operates 242 one tree, the higher if different governmental or private 243 organizations within a country operate independent trees. We assume 244 that tree coverage information changes relatively slowly, on the 245 order of less than one change per year per tree, although the system 246 imposes no specific threshold. Tree coverage would change, for 247 example, if a country is split or merged or if two trees for 248 different regions become part of a larger tree. (On the other hand, 249 information within a tree is likely to change much more frequently.) 251 4.2. Minimal System Architecture 253 It is possible to build a functioning system consisting only of 254 seekers and resolvers if these resolvers have other means of 255 obtaining mapping data. For example, a company acting as a mapping 256 service provider could collect mapping records manually and make them 257 available to their customers through the resolver. While feasible as 258 a starting point, such an architecture is unlikely to scale globally. 259 Among other problems, it becomes very hard for providers of 260 authoritative data to ensure that all such providers have up-to-date 261 information. If new trees are set up, they would somehow make 262 themselves known to these providers. Such a mechanism would be 263 similar to the old "hosts.txt" mechanism for distributing host 264 information in the early Internet before DNS was developed. 266 Below, we describe the operation of each component in more detail. 268 5. Seeker 270 Clients desiring location-to-service mappings are known as seekers. 271 Seekers are consumers of mapping data and originate LoST queries as 272 LoST protocol clients. Seekers do not answer LoST queries. They 273 contact either forest guides or resolvers to find the appropriate 274 tree that can authoritatively answer their questions. Seekers can be 275 end systems such as SIP user agents or call routing entities such as 276 SIP proxy servers. 278 Seekers may need to obtain mapping information in several steps, 279 i.e., they may obtain pointers to intermediate servers that lead them 280 closer to the final mapping. Seekers MAY cache query results for 281 later use, but otherwise have no obligations to other entities in the 282 system. 284 Seekers need to be able to identify appropriate resolvers. The 285 mechanism for providing seekers with that information is likely to 286 differ depending on who operates the resolvers. For example, if the 287 voice service provider operates the resolver, it might include the 288 location of the resolver in the SIP configuration information it 289 distributes to its user agents. An Internet access provider or 290 enterprise can provide a pointer to a resolver via DHCP [RFC5223]. 291 In an ad-hoc or zero-configuration environment, appropriate service 292 directories may advertise resolvers. 294 Like other entities in the system, seekers can cache responses. This 295 is particularly useful if the response describes the result for a 296 civic or geospatial region, rather than just a point. For example, 297 for mobile nodes, seekers would only have to update their resolution 298 results when they leave the coverage area of a service provider, such 299 as a PSAP for emergency services, and can avoid repeatedly polling 300 for this information whenever the location information changes 301 slightly. (Mobile nodes would also need a location update mechanism 302 that is either local or triggered when they leave the current service 303 area.) This will likely be of particular benefit for seekers 304 representing a large user population, such as the outbound proxy in a 305 corporate network. For example, rather than having to query 306 separately for each cubicle, information provided by the 307 authoritative node may indicate that the whole campus is covered by 308 the same service provider. 310 Given this caching mechanism and cache lifetimes of several days, 311 most mobile users traveling to and from work would only need to 312 obtain service area information along their commute route once during 313 each cache lifetime. 315 6. Resolver 317 A seeker can contact a forest guide (see below) directly, but may not 318 be able to easily locate such a guide. In addition, seekers in the 319 same geographic area may already have asked the same question. Thus, 320 it makes sense to introduce another entity, known as a resolver in 321 the architecture, that knows how to contact one or more forest guides 322 and caches earlier queries to accelerate the response to mapping 323 queries and to improve the resiliency of the system. Each resolver 324 can decide autonomously which FGs to use, with possibly different 325 choices for each top-level service. 327 ISPs or VSPs may include the address of a suitable resolver in their 328 configuration information, e.g., in SIP configuration for a VSP or 329 DHCP [RFC5223] for an ISP. Resolvers are manually configured with 330 the name of one or more forest guides. 332 7. Trees: Maintaining Authoritative Knowledge 334 7.1. Basic Operation 336 The architecture assumes that authoritative knowledge about the 337 mapping data is distributed among many independent administrative 338 entities, but clients (seekers) may potentially need to find out 339 mapping information for any spot on earth. (Extensions to extra- 340 terrestrial applications are left for future exploration.) 341 Information is organized hierarchically, in a tree, with tree nodes 342 representing larger geographic areas pointing to several child nodes 343 each representing a smaller area. Each tree node can be a cluster of 344 LoST servers that all contain the same information and back up each 345 other. 347 Each tree can map a location described by either civic or geographic 348 coordinates, but not both, for one type of service (such as 349 'sos.police', 'sos.fire' or 'counseling'), although nothing prevents 350 re-using the same servers for multiple different services or both 351 types of coordinates. The collection of all trees for one service is 352 known as a forest. 354 Each tree root announces its coverage region to one or more forest 355 guides. 357 Each tree node cluster knows the coverage region of its children and 358 sends queries to the appropriate server "down" the tree. Each such 359 tree node knows authoritatively about the service mappings for a 360 particular region, typically, but not necessarily, contiguous. The 361 region can be described by any of the shapes in the LoST 362 specification expressed in geospatial coordinates, such as circles or 363 polygons, or a set of civic address descriptors (e.g., "country = DE, 364 A1 = Bavaria"). These coverage regions may be aligned with political 365 boundaries, but that is not required. In most cases, to avoid 366 confusion, only one cluster is responsible for a particular 367 geographic or civic location, but the system can also deal with cases 368 where coverage regions overlap. 370 There are no assumptions about the coverage region of a tree as a 371 whole. For example, a tree could cover a single city, or a state/ 372 province or a whole country. Nodes within a tree need to loosely 373 coordinate their operation, but they do not need to be operated by 374 the same administrator. 376 The tree architecture is roughly similar to the domain name system 377 (DNS), except that delegation is not by label, but rather by region. 378 (Naturally, DNS does not have the notion of forest guides.) One can 379 also draw analogies to LDAP, when deployed in a distributed fashion. 381 Tree nodes maintain two types of information, namely coverage regions 382 and mappings. Coverage regions describe the region served by a child 383 node in the tree and point to a child node for further resolution. 384 Mappings contain an actual service URI leading to a service provider 385 or another signaling server representing a group of service 386 providers, which in turn might further route signaling requests to 387 more servers covering smaller regions. 389 Leaf nodes, i.e., nodes without children, only maintain mappings, 390 while tree nodes above the leaf nodes only maintain coverage regions. 391 An example for emergency services of a leaf node entry is shown 392 below, indicating how queries for three towns are directed to 393 different PSAPs. Queries for Englewood are directed to another LoST 394 server instead. 396 country A1 A2 A3 resource or LoST server 397 US NJ Bergen Leonia sip:psap@leonianj.gov 398 US NJ Bergen Fort Lee sip:emergency@fortleenj.org 399 US NJ Bergen Teaneck sip:police@teanecknjgov.org 400 US NJ Bergen Englewood englewoodnj.gov 401 .... 403 Coverage regions are described by sets of LoST-compatible shapes 404 enclosing contiguous geographic areas or by descriptors enumerating 405 groups of civic locations. For the former, the LoST server performs 406 the same matching operation as described in Section 12.2 of the LoST 407 specification [RFC5222] to find the tree or AMS. 409 As a civic location example, a state-level tree node for New Jersey 410 in the United States may contain the coverage region entries shown 411 below, indicating that any query matching a location in Bergen 412 County, for example, would be redirected or forwarded to the node 413 located at bergen.nj.example.org. 415 There is no requirement that all child nodes cover the same level 416 within the civic hierarchy. As an example, in the table below, the 417 city of Newark has decided to be listed directly within the state 418 node, rather than through the county. Longest-match rules allow 419 partial coverage, so that for queries for all other towns within 420 Essex county would be directed to the county node for further 421 resolution. 423 C A1 A2 A3 LoST server name 424 US NJ Atlantic * atlantic.nj.example.org/sos 425 US NJ Bergen * bergen.nj.example.org/sos 426 US NJ Monmouth * monmouth.nj.example.org/sos 427 US NJ Essex * essex.nj.example.org/sos 428 US NJ Essex Newark newark.example.com/sos 429 .... 431 Thus, there is no substantial difference between coverage region and 432 mapping data. The only difference is that coverage regions return 433 names of LoST servers, while mapping entries contain service URLs. 434 Mapping entries may be specific down to the house or floor level or 435 may only contain street-level information. For example, in the 436 United States, civic mapping data for emergency services is generally 437 limited to address ranges ("MSAG data"), so initial mapping databases 438 may only contain street-level information. 440 To automate the maintenance of trees, the LoST synchronization 441 mechanism [I-D.schulzrinne-ecrit-lost-sync] allows nodes to query 442 other nodes for mapping data and coverage regions, both within a 443 cluster and across different hierarchy levels in a tree. In the 444 example above, the state-run node would query the county nodes and 445 use the records returned to distribute incoming LoST queries to the 446 county nodes. Conversely, nodes could also contact their parent 447 nodes to tell them about their coverage region. There is some 448 benefit of child nodes contacting their parents, as this allows 449 changes in coverage region to propagate quickly up the tree. 451 7.2. Answering Queries 453 Within a tree, the basic operation is straightforward: A query 454 reaches the root of the tree. That node determines which coverage 455 region matches that request and forwards the request to the URL 456 indicated in the coverage region record, returning a response to the 457 querier when it in turns receives an answer (recursion). 458 Alternatively, the node returns the URL of that child node to the 459 querier (iteration). This process applies to each node, i.e., a node 460 does not need to know whether the original query came from a parent 461 node, a seeker, a forest guide or a resolver. 463 For efficiency, a node MAY return region information instead of a 464 point answer. Thus, instead of returning that a particular 465 geospatial coordinate maps to a service or mapping URL, it MAY return 466 a polygon indicating the region for which this answer would be 467 returned, along with expiration time (time-to-live) information. The 468 querying node can then cache this information for future use. 470 For civic coordinates, trees may not include individual mapping 471 records for each floor, house number or street. To avoid giving the 472 wrong indication that a particular location has been found valid, 473 LoST can indicate which parts of the location information have 474 actually been used to look up a mapping. 476 7.3. Overlapping Coverage Regions 478 In some cases, coverage regions may overlap, either because there is 479 a dispute as to who handles a particular geographic region or, more 480 likely, since the resolution of the coverage map may not be 481 sufficiently high. For example, a node may "shave some corners" off 482 its polygon, so that its coverage region appears to overlap with its 483 geographic neighbor. For civic coordinates, houses on the same 484 street may be served by different PSAPs. The mapping mechanism needs 485 to work even if a coverage map is imprecise or if there are disputes 486 about coverage. 488 The solution for overlapping coverage regions is relatively simple. 489 If a query matches multiple coverage regions, the node returns all 490 URLs, in redirection mode, or queries both children, if in recursive 491 mode. If the overlapping coverage is caused by imprecise coverage 492 maps, only one will return a result and the others will return an 493 error indication. If the particular location is disputed territory, 494 the response will contain all answers, leaving it to the querier to 495 choose the preferred solution or trying to contact all services in 496 turn. 498 7.4. Scaling and Reliability 500 Since they provide authoritative information, tree nodes need to be 501 highly reliable. Thus, while this document refers to tree nodes as 502 logical entities within the tree, an actual implementation would 503 likely replicate node information across several servers, forming a 504 cluster. Each such node would have the same information. Standard 505 techniques such as DNS SRV records can be used to select one of the 506 servers. Replication within the cluster can use any suitable 507 protocol mechanism, but a standardized incremental update mechanism 508 makes it easier to spread those nodes across multiple independently- 509 administered locations. The techniques developed for meshed SLP 510 [RFC3528] are applicable here. 512 8. Forest Guides 514 Unfortunately, just having trees covering various regions of the 515 world is not sufficient as a client of the mapping protocol would not 516 generally be able to keep track of all the trees in the forest. To 517 facilitate orientation among the trees, we introduce a forest guide 518 (FG) which keeps track of the coverage regions of all the trees for 519 one service. For scalability and reliability, there will need to be 520 a large number of forest guides, all providing the same information. 521 A seeker can contact a suitable forest guide and will then be 522 directed to the right tree or, rarely, set of trees. Forest guides 523 do not provide mapping information themselves, but rather redirect to 524 mapping servers. In some configurations, not all forest guides may 525 provide the same information, due to policy reasons. 527 Forest guides fulfill a similar role to root servers in DNS. They 528 distribute information, signed for authenticity, offered by trees. 529 However, introducing forest guides avoids creating a global root, 530 with the attendant management and control issues. 532 However, unlike DNS root servers, forest guides may offer different 533 information based on local policy. Forest guides can also restrict 534 their data synchronization to parts of the information. For example, 535 if country C does not recognize country T, C can propagate tree 536 regions for all but T. 538 For authenticity, the coverage regions SHOULD be digitally signed by 539 the authorities responsible for the region, as discussed in more 540 detail in Section 10. They are used by resolvers and possibly 541 seekers to find the appropriate tree for a particular area. All 542 forest guides should have consistent information, i.e., a collection 543 of all the coverage regions of all the trees. A tree node at the top 544 of a tree can contact any forest guide and inject new coverage region 545 information into the system. One would expect that each tree 546 announces its coverage to more than one forest guide. Each forest 547 guide peers with one or more other guides and distributes new 548 coverage region announcements to other guides. Due to policy and 549 maybe political reasons, not all forest guides may share the same 550 coverage region data. 552 Forest guides can, in principle, be operated by anybody, including 553 voice service providers, Internet access providers, dedicated 554 services providers and enterprises. 556 As in routing, peering with other forest guides implies a certain 557 amount of trust in the peer. Thus, peering is likely to require some 558 negotiation between the administering parties concerned, rather than 559 automatic configuration. The mechanism itself does not imply a 560 particular policy as to who gets to advertise a particular coverage 561 region. 563 9. Configuring Service Numbers 565 The section below is not directly related to the problem of 566 determining service location, but is an instance of the more generic 567 problem solved by this architecture, namely mapping location 568 information to service-related parameters, such as service numbers. 570 For the foreseeable future, some user devices and software will 571 emulate the user interface of a telephone, i.e., the only way to 572 enter call address information is via a 12-button keypad with digits 573 and the asterisk and hash symbol. These devices use service numbers 574 to identify services. The best-known examples of service numbers are 575 emergency numbers, such as 9-1-1 in North America and 1-1-2 in 576 Europe. However, many other public and private service numbers have 577 been defined, ranging in the United States from 3-1-1 for non- 578 emergency local government services to 4-1-1 for directory assistance 579 to various "800" numbers for anything from roadside assistance to 580 legal services to home-delivery food. 582 Such service numbers are likely to be used until essentially all 583 communication devices feature IP connectivity and an alphanumeric 584 keyboard. Unfortunately, for emergency services, more than 60 585 emergency numbers are in use throughout the world, with many of those 586 numbers serving non-emergency purposes elsewhere, e.g., identifying 587 repair or directory services. Countries also occasionally change 588 their emergency numbers to conform to regional agreements. An 589 example is the introduction of "1-1-2" for countries in Europe. 591 Thus, a system that allows devices to be used internationally to 592 place calls needs to allow devices to discover service numbers 593 automatically. In the Internet-based system proposed here 594 [I-D.ietf-ecrit-framework], these numbers are strictly used as a 595 human user interface mechanism and are generally not visible in call 596 signaling messages, which carry the service URN [RFC5031] instead. 598 For the best user experience, systems should be able to discover two 599 sets of service numbers, namely those used in the user's home country 600 and in the country the user is currently visiting. The user is most 601 likely to remember the former, but a companion borrowing a device in 602 an emergency, say, may only know the local emergency numbers. 604 Determining home and local service numbers is a configuration 605 problem, but unfortunately, existing configuration mechanisms are 606 ill-suited for this purpose. For example, a DHCP server might be 607 able to provide the local service numbers, but not the home numbers. 608 When virtual private networks (VPNs) are used, even DHCP may provide 609 numbers of uncertain origin, as a user may contact the home network 610 or some local branch office of the corporate network. Similarly, SIP 611 configuration [I-D.ietf-sipping-config-framework] would be able to 612 provide the numbers valid at the location of the SIP service 613 provider, but even a SIP service provider with national footprint may 614 serve customers that are visiting any number of other countries. 616 Also, while initially there are likely to be only a few service 617 numbers, e.g., for emergency services, the LoST architecture can be 618 used to support other services, as noted. Configuring every local 619 DHCP or SIP configuration server with that information is likely to 620 be error-prone and tedious. 622 For these reasons, the LoST-based mapping architecture supports 623 providing service numbers to end systems based on caller location. 624 The mapping operation is almost exactly the same as for determining 625 the service URL. The mapping can be obtained either along with the 626 service URL or through a separate request. The major difference 627 between the two requests is that service numbers often have much 628 larger regions of validity than the service URL itself. Also, the 629 service number is likely to be valid longer than the service URL. 631 Finally, an end system may want to look up the service number for its 632 home location, not just its current (visited) location. 634 10. Security Considerations 636 Security considerations for emergency services mapping are discussed 637 in [RFC5069], while [RFC5031] discusses issues related to the service 638 URN, one of the inputs into the mapping protocol. LoST-related 639 security considerations are naturally discussed in the LoST [RFC5222] 640 specification. 642 The architecture addresses the following security issues, usually 643 through the underlying transport security associations: 645 Server impersonation: Seekers, resolvers, fellow tree guides and 646 cluster members can assure themselves of the identity of the 647 remote party by using the facilities in the underlying channel 648 security mechanism, such as TLS [RFC5246]. 649 Query or query result corruption: To avoid that an attacker can 650 modify the query or its result, the architecture RECOMMENDS the 651 use of channel security, such as TLS. Results SHOULD also be 652 digitally signed, e.g., using XML digital signatures 653 [W3C.REC-xmldsig-core-20020212]. Note, however, that simple 654 origin assertion may not provide the end system with enough useful 655 information as it has no good way of knowing that a particular 656 signer is authorized to represent a particular geographic area. 657 It might be necessary that certain well-known Certificate 658 Authorities (CAs) vet sources of mapping information and provide 659 special certificates for that purpose. In many cases, a seeker 660 will have to trust its local resolver to vet information for 661 trustworthiness; in turn, the resolver may rely on trusted forest 662 guides to steer it to the correct information. 663 Coverage region corruption: To avoid that a third party or an 664 untrustworthy member of a server population claims a coverage 665 region that it is not authorized for, any node introducing a new 666 region map MUST sign the object by protecting the data with an XML 667 digital signature [W3C.REC-xmldsig-core-20020212]. A recipient 668 MUST verify, through a local policy mechanism, that the signing 669 entity is indeed authorized to speak for that region. Determining 670 who can speak for a particular region is inherently difficult 671 unless there is a small set of authorizing entities that 672 participants in the mapping architecture can trust. Receiving 673 systems should be particularly suspicious if an existing coverage 674 region is replaced with a new one with a new mapping address. In 675 many cases, trust will be mediated: A seeker will have a trust 676 relationship with a resolver. The resolver, in turn, will contact 677 a trusted forest guide. 679 Additional threats that need to be addressed by operational measures 680 include denial-of-service attacks [I-D.ietf-ecrit-phonebcp]. 682 11. IANA Considerations 684 Since this document describes an architecture, not a protocol, it 685 does not ask IANA to register any protocol constants. 687 12. Acknowledgments 689 Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar 690 Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson, 691 Schida Schubert, Murugaraj Shanmugam, Richard Stastny, and Hannes 692 Tschofenig provided helpful comments. 694 13. References 696 13.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 702 Emergency and Other Well-Known Services", RFC 5031, 703 January 2008. 705 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 706 Tschofenig, "LoST: A Location-to-Service Translation 707 Protocol", RFC 5222, August 2008. 709 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 710 Location-to-Service Translation (LoST) Servers Using the 711 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 712 August 2008. 714 13.2. Informative References 716 [RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced 717 Service Location Protocol (mSLP)", RFC 3528, April 2003. 719 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 720 Emergency Context Resolution with Internet Technologies", 721 RFC 5012, January 2008. 723 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 725 Shanmugam, "Security Threats and Requirements for 726 Emergency Call Marking and Mapping", RFC 5069, 727 January 2008. 729 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 730 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 732 [I-D.ietf-sipping-config-framework] 733 Channabasappa, S., "A Framework for Session Initiation 734 Protocol User Agent Profile Delivery", 735 draft-ietf-sipping-config-framework-15 (work in progress), 736 February 2008. 738 [I-D.ietf-ecrit-framework] 739 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 740 "Framework for Emergency Calling using Internet 741 Multimedia", draft-ietf-ecrit-framework-08 (work in 742 progress), February 2009. 744 [I-D.ietf-ecrit-phonebcp] 745 Rosen, B. and J. Polk, "Best Current Practice for 746 Communications Services in support of Emergency Calling", 747 draft-ietf-ecrit-phonebcp-08 (work in progress), 748 February 2009. 750 [I-D.schulzrinne-ecrit-lost-sync] 751 Schulzrinne, H., "Synchronizing Location-to-Service 752 Translation (LoST) Servers", 753 draft-schulzrinne-ecrit-lost-sync-01 (work in progress), 754 February 2008. 756 [W3C.REC-xmldsig-core-20020212] 757 Reagle, J., Solo, D., and D. Eastlake, "XML-Signature 758 Syntax and Processing", World Wide Web Consortium 759 FirstEdition REC-xmldsig-core-20020212, February 2002, 760 . 762 Author's Address 764 Henning Schulzrinne 765 Columbia University 766 Department of Computer Science 767 450 Computer Science Building 768 New York, NY 10027 769 US 771 Phone: +1 212 939 7004 772 Email: hgs+ecrit@cs.columbia.edu 773 URI: http://www.cs.columbia.edu