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