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