diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5582.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5582.txt')
-rw-r--r-- | doc/rfc/rfc5582.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5582.txt b/doc/rfc/rfc5582.txt new file mode 100644 index 0000000..b241d35 --- /dev/null +++ b/doc/rfc/rfc5582.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group H. Schulzrinne +Request for Comments: 5582 Columbia U. +Category: Informational September 2009 + + + Location-to-URL Mapping Architecture and Framework + +Abstract + +This document describes an architecture for a global, scalable, +resilient, and administratively distributed system for mapping +geographic location information to URLs, using the Location-to-Service +Translation (LoST) protocol. The architecture generalizes well-known +approaches found in hierarchical lookup systems such as DNS. + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + + + + + + + + + + + + + + + + +Schulzrinne Informational [Page 1] + +RFC 5582 MapArch September 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 4 + 4.1. The Principal Components . . . . . . . . . . . . . . . . . 4 + 4.2. Minimal System Architecture . . . . . . . . . . . . . . . 6 + 5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8 + 7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8 + 7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10 + 7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11 + 7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11 + 8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 + +1. Introduction + + It is often desirable to allow users to access a service that + provides a common function but that is actually offered by a variety + of local service providers. In many of these cases, the service + provider chosen depends on the location of the person wishing to + access that service. Among the best-known public services of this + kind is emergency calling, where emergency calls are routed to the + most appropriate public safety answering point (PSAP) based on the + caller's physical location. Other services, from food delivery to + directory services and roadside assistance, also follow this general + pattern. This is a mapping problem [RFC5012], where a geographic + location and a service identifier [RFC5031] is translated into a set + of URIs, the service URIs, that allow the Internet system to contact + an appropriate network entity that provides the service. + + The caller does not need to know from where the service is being + provided, and the location of the service provider may change over + time, e.g., to deal with temporary overloads, failures in the primary + service provider location, or long-term changes in system + architecture. For emergency services, this problem is described in + more detail in [ECRIT-FRAME]. + + + + + + +Schulzrinne Informational [Page 2] + +RFC 5582 MapArch September 2009 + + + The overall emergency calling architecture [ECRIT-FRAME] separates + mapping from placing calls or otherwise invoking the service, so the + same mechanism can be used to verify that a mapping exists ("address + validation") or to obtain test service URIs. + + Mapping locations to URIs that describe services requires a + distributed, scalable, and highly resilient infrastructure. + Authoritative knowledge about such mappings is distributed among a + large number of autonomous entities that may have no direct knowledge + of each other. In this document, we describe an architecture for + such a global service. It allows significant freedom to combine and + split functionality among actual servers and imposes few requirements + as to who should operate particular services. + + Besides determining the service URI, end systems also need to + determine the local service numbers. As discussed in Section 9, the + architecture described here can also address that problem. + + The architecture described here uses the Location-to-Service + Translation (LoST) [RFC5222] protocol, although much of the + discussion would also apply for other mapping protocols satisfying + the mapping requirements [RFC5012]. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119] and + indicate requirement levels for compliant implementations. + +3. Definitions + + In addition to the terms defined in [RFC5012], this document uses the + following terms to describe LoST clients and servers: + + authoritative mapping server (AMS): An authoritative mapping server + (AMS) is a LoST server that can provide the authoritative answer + to a particular set of queries, e.g., covering a set of Presence + Information Data Information Location Object (PIDF-LO) civic + labels or a particular region described by a geometric shape. In + some (rare) cases of territorial disputes, two resolvers may be + authoritative for the same region. An AMS may redirect or forward + a query to another AMS within the tree. + + child: A child is an AMS that is authoritative for a subregion of + another AMS. A child can in turn be parent for another AMS. + + + + + +Schulzrinne Informational [Page 3] + +RFC 5582 MapArch September 2009 + + + (tree node) cluster: A node cluster is a group of LoST servers that + all share the same mapping information and return the same results + for queries. Clusters provide redundancy and share query load. + Clusters are fully-meshed, i.e., they all exchange updates with + each other. + + coverage region: The coverage region of an AMS is the geographic + region within which the AMS is able to authoritatively answer + mapping queries. Coverage regions are generally, but not + necessarily, contiguous and may be represented as either a subset + of a civic address or a geometric object. + + forest guide (FG): A forest guide (FG) has knowledge of the coverage + region of trees for a particular top-level service. + + mapping: A mapping is a short-hand for 'mapping from a location + object to either another mapping server or the desired service + URLs'. + + parent: A mapping server that covers the region of all of its + children. A mapping server without a parent is a root AMS. + + resolver: A resolver is contacted by a seeker, consults a forest + mapping server, and then resolves the query using an appropriate + tree. Resolvers may cache query results. + + seeker: A seeker is a LoST client requesting a mapping. A seeker + does not provide mapping services to others but may cache results + for its own use. + + tree: A tree consists of a self-contained hierarchy of authoritative + mapping servers for a particular service. Each tree exports its + coverage region to the forest mapping servers. + +4. Overview of Architecture + +4.1. The Principal Components + + The mapping architecture distinguishes four logical roles: seekers, + resolvers, authoritative mapping servers (AMS), and forest guides + (FGs). End users of the LoST-based [RFC5222] mapping mechanism, + called seekers, contact resolvers that cache query results and know + one or more forest guides. Forest guides form the top level of a + conceptual hierarchy, with one or more trees providing a hierarchical + resolution service for different geographic regions. Forest guides + know the geographic coverage region of all or almost all trees and + direct queries to the node at the top of the appropriate tree. Trees + + + + +Schulzrinne Informational [Page 4] + +RFC 5582 MapArch September 2009 + + + consist of authoritative mapping servers and maintain the + authoritative mapping information. + + Seekers, resolvers, authoritative mapping servers, and forest guides + all communicate using LoST; indeed, it is likely that, in many cases, + the same software can operate as a resolver, authoritative mapping + server, and forest guide. In addition to the basic LoST query + protocol [RFC5222], a synchronization protocol [LOST-SYNC] may be + used to exchange information between forest guides or to push + coverage information from a tree node to its parent. + + Seekers may be part of Voice over IP (VoIP) or other end systems, or + of SIP proxies or similar call routing functions. + + Figure 1 shows the interaction of the components. The lines + indicating the connection between the forest guides are logical + connections, indicating that they are synchronizing their information + via the synchronization protocol [LOST-SYNC]. + + /-\ /-\ +-----+ +-----+ + | S +******* R ********* FG *-----------------+ FG | + \-/ \-/ | |* | | + +--+--+ * +--+--+ + | * | + | * | + | * | + | * | + /-\ +--+--+ * +--+--+ + | R +------>+ FG +-----*-----------+ FG | + \-/ | | * | | + +--+--+ * +--+--+ + | * | + | * | + | * | + |*** ^ + / \ / \ + / \ / \ + / \ / \ + / \ / \ + ----------- ----------- + tree tree + + Architecture diagram, showing seekers (S), resolvers (R), forest + guides (FG), and trees. The star (*) line indicates the flow of the + query and responses in recursive mode, while the lines indicate + synchronization relationships. + + Figure 1 + + + +Schulzrinne Informational [Page 5] + +RFC 5582 MapArch September 2009 + + + The mapping function for the world is divided among trees. The + collection of trees may not cover the whole world, and trees are + added and removed as the organization of mapping data changes. We + call the collection of trees a forest. There is no limit on the + number of trees within the forest, but the author guesses that the + number of trees will likely be somewhere between a few hundred and a + few thousand. The lower estimate would apply if each country + operates one tree, the higher if different governmental or private + organizations within a country operate independent trees. We assume + that tree coverage information changes relatively slowly, on the + order of less than one change per year per tree, although the system + imposes no specific threshold. Tree coverage would change, for + example, if a country is split or merged or if two trees for + different regions become part of a larger tree. (On the other hand, + information within a tree is likely to change much more frequently.) + +4.2. Minimal System Architecture + + It is possible to build a functioning system consisting only of + seekers and resolvers if these resolvers have other means of + obtaining mapping data. For example, a company acting as a mapping + service provider could collect mapping records manually and make them + available to their customers through the resolver. While feasible as + a starting point, such an architecture is unlikely to scale globally. + Among other problems, it becomes very hard for providers of + authoritative data to ensure that all such providers have up-to-date + information. If new trees are set up, they would somehow make + themselves known to these providers. Such a mechanism would be + similar to the old "hosts.txt" mechanism for distributing host + information in the early Internet before DNS was developed. + + Below, we describe the operation of each component in more detail. + +5. Seeker + + Clients desiring location-to-service mappings are known as seekers. + Seekers are consumers of mapping data and originate LoST queries as + LoST protocol clients. Seekers do not answer LoST queries. They + contact either forest guides or resolvers to find the appropriate + tree that can authoritatively answer their questions. Seekers can be + end systems such as SIP user agents, or call routing entities such as + SIP proxy servers. + + Seekers may need to obtain mapping information in several steps, + i.e., they may obtain pointers to intermediate servers that lead them + closer to the final mapping. Seekers MAY cache query results for + later use but otherwise have no obligations to other entities in the + system. + + + +Schulzrinne Informational [Page 6] + +RFC 5582 MapArch September 2009 + + + Seekers need to be able to identify appropriate resolvers. The + mechanism for providing seekers with that information is likely to + differ depending on who operates the resolvers. For example, if the + voice service provider operates the resolver, it might include the + location of the resolver in the SIP configuration information it + distributes to its user agents. An Internet access provider or + enterprise can provide a pointer to a resolver via DHCP [RFC5223]. + In an ad hoc or zero-configuration environment, appropriate service + directories may advertise resolvers. + + Like other entities in the system, seekers can cache responses. This + is particularly useful if the response describes the result for a + civic or geospatial region, rather than just a point. For example, + for mobile nodes, seekers would only have to update their resolution + results when they leave the coverage area of a service provider, such + as a PSAP for emergency services, and can avoid repeatedly polling + for this information whenever the location information changes + slightly. (Mobile nodes would also need a location update mechanism + that is either local or triggered when they leave the current service + area.) This will likely be of particular benefit for seekers + representing a large user population, such as the outbound proxy in a + corporate network. For example, rather than having to query + separately for each cubicle, information provided by the + authoritative node may indicate that the whole campus is covered by + the same service provider. + + Given this caching mechanism and cache lifetimes of several days, + most mobile users traveling to and from work would only need to + obtain service area information along their commute route once during + each cache lifetime. + +6. Resolver + + A seeker can contact a forest guide (see below) directly, but may not + be able to easily locate such a guide. In addition, seekers in the + same geographic area may already have asked the same question. Thus, + it makes sense to introduce another entity, known as a resolver in + the architecture, that knows how to contact one or more forest guides + and that caches earlier queries to accelerate the response to mapping + queries and to improve the resiliency of the system. Each resolver + can decide autonomously which FGs to use, with possibly different + choices for each top-level service. + + ISPs or Voice Service Providers (VSPs) may include the address of a + suitable resolver in their configuration information, e.g., in SIP + configuration for a VSP or DHCP [RFC5223] for an ISP. Resolvers are + manually configured with the name of one or more forest guides. + + + + +Schulzrinne Informational [Page 7] + +RFC 5582 MapArch September 2009 + + +7. Trees: Maintaining Authoritative Knowledge + +7.1. Basic Operation + + The architecture assumes that authoritative knowledge about the + mapping data is distributed among many independent administrative + entities, but clients (seekers) may potentially need to find out + mapping information for any spot on earth. (Extensions to extra- + terrestrial applications are left for future exploration.) + Information is organized hierarchically, in a tree, with tree nodes + representing larger geographic areas pointing to several child nodes, + each representing a smaller area. Each tree node can be a cluster of + LoST servers that all contain the same information and back up each + other. + + Each tree can map a location described by either civic or geographic + coordinates, but not both, for one type of service (such as + 'sos.police', 'sos.fire' or 'counseling') and one location profile, + although nothing prevents re-using the same servers for multiple, + different services or both types of coordinates. The collection of + all trees for one service and location profile is known as a forest. + + Each tree root announces its coverage region to one or more forest + guides. + + Each tree node cluster knows the coverage region of its children and + sends queries to the appropriate server "down" the tree. Each such + tree node knows authoritatively about the service mappings for a + particular region, typically, but not necessarily, contiguous. The + region can be described by any of the shapes in the LoST + specification expressed in geospatial coordinates, such as circles or + polygons, or a set of civic address descriptors (e.g., "country = DE, + A1 = Bavaria"). These coverage regions may be aligned with political + boundaries, but that is not required. In most cases, to avoid + confusion, only one cluster is responsible for a particular + geographic or civic location, but the system can also deal with cases + where coverage regions overlap. + + There are no assumptions about the coverage region of a tree as a + whole. For example, a tree could cover a single city, a state/ + province, or a whole country. Nodes within a tree need to loosely + coordinate their operation, but they do not need to be operated by + the same administrator. + + The tree architecture is roughly similar to the domain name system + (DNS), except that delegation is not by label but rather by region. + (Naturally, DNS does not have the notion of forest guides.) One can + + + + +Schulzrinne Informational [Page 8] + +RFC 5582 MapArch September 2009 + + + also draw analogies to the Lightweight Directory Access Protocol + (LDAP) when deployed in a distributed fashion. + + Tree nodes maintain two types of information -- namely, coverage + regions and mappings. Coverage regions describe the region served by + a child node in the tree and point to a child node for further + resolution. Mappings contain an actual service URI leading to a + service provider or another signaling server representing a group of + service providers, which in turn might further route signaling + requests to more servers covering smaller regions. + + Leaf nodes, i.e., nodes without children, only maintain mappings, + while tree nodes above the leaf nodes only maintain coverage regions. + An example for emergency services of a leaf node entry is shown + below, indicating how queries for three towns are directed to + different PSAPs. Queries for Englewood are directed to another LoST + server instead. + + country A1 A2 A3 resource or LoST server + US NJ Bergen Leonia sip:psap@leonianj.gov + US NJ Bergen Fort Lee sip:emergency@fortleenj.org + US NJ Bergen Teaneck sip:police@teanecknjgov.org + US NJ Bergen Englewood englewoodnj.gov + .... + + Coverage regions are described by sets of LoST-compatible shapes + enclosing contiguous geographic areas or by descriptors enumerating + groups of civic locations. For the former, the LoST server performs + the same matching operation as described in Section 12.2 of the LoST + specification [RFC5222] to find the tree or AMS. + + As a civic location example, a state-level tree node for New Jersey + in the United States may contain the coverage region entries shown + below, indicating that any query matching a location in Bergen + County, for example, would be redirected or forwarded to the node + located at bergen.nj.example.org. + + There is no requirement that all child nodes cover the same level + within the civic hierarchy. As an example, in the table below, the + city of Newark has decided to be listed directly within the state + node, rather than through the county. Longest-match rules allow + partial coverage so that queries for all other towns within Essex + county would be directed to the county node for further resolution. + + + + + + + + +Schulzrinne Informational [Page 9] + +RFC 5582 MapArch September 2009 + + + C A1 A2 A3 LoST server name + US NJ Atlantic * atlantic.nj.example.org/sos + US NJ Bergen * bergen.nj.example.org/sos + US NJ Monmouth * monmouth.nj.example.org/sos + US NJ Essex * essex.nj.example.org/sos + US NJ Essex Newark newark.example.com/sos + .... + + Thus, there is no substantial difference between coverage region and + mapping data. The only difference is that coverage regions return + names of LoST servers, while mapping entries contain service URLs. + Mapping entries may be specific down to the house- or floor-level or + may only contain street-level information. For example, in the + United States, civic mapping data for emergency services is generally + limited to address ranges ("MSAG data"), so initial mapping databases + may only contain street-level information. + + To automate the maintenance of trees, the LoST synchronization + mechanism [LOST-SYNC] allows nodes to query other nodes for mapping + data and coverage regions, both within a cluster and across different + hierarchy levels in a tree. In the example above, the state-run node + would query the county nodes and use the records returned to + distribute incoming LoST queries to the county nodes. Conversely, + nodes could also contact their parent nodes to tell them about their + coverage region. There is some benefit of child nodes contacting + their parents, as this allows changes in coverage regions to + propagate quickly up the tree. + +7.2. Answering Queries + + Within a tree, the basic operation is straightforward. A query + reaches the root of the tree. That node determines which coverage + region matches that request and forwards the request to the server + indicated in the coverage region record, returning a response to the + querier when it in turn receives an answer (recursion). + Alternatively, the node returns the application unique string (server + name) of that child node to the querier (iteration). This process + applies to each node, i.e., a node does not need to know whether the + original query came from a parent node, a seeker, a forest guide, or + a resolver. + + For efficiency, a node MAY return region information instead of a + point answer. Thus, instead of returning that a particular + geospatial coordinate maps to a service URL or server name, it MAY + return a polygon indicating the region for which this answer would be + returned, along with expiration time (time-to-live) information. The + querying node can then cache this information for future use. + + + + +Schulzrinne Informational [Page 10] + +RFC 5582 MapArch September 2009 + + + For civic coordinates, trees may not include individual mapping + records for each floor, house number, or street. To avoid giving the + wrong indication that a particular location has been found valid, + LoST can indicate which parts of the location information have + actually been used to look up a mapping. + +7.3. Overlapping Coverage Regions + + In some cases, coverage regions may overlap, either because there is + a dispute as to who handles a particular geographic region or, more + likely, because the resolution of the coverage map may not be + sufficiently high. For example, a node may "shave some corners" off + its polygon so that its coverage region appears to overlap with its + geographic neighbor. For civic coordinates, houses on the same + street may be served by different PSAPs. The mapping mechanism needs + to work even if a coverage map is imprecise or if there are disputes + about coverage. + + The solution for overlapping coverage regions is relatively simple. + If a query matches multiple coverage regions, the node returns all + URLs or server names, in redirection mode, or queries both children, + if in recursive mode. If the overlapping coverage is caused by + imprecise coverage maps, only one will return a result and the others + will return an error indication. If the particular location is + disputed territory, the response will contain all answers, leaving it + to the querier to choose the preferred solution or try to contact all + services in turn. + +7.4. Scaling and Reliability + + Since they provide authoritative information, tree nodes need to be + highly reliable. Thus, while this document refers to tree nodes as + logical entities within the tree, an actual implementation would + likely replicate node information across several servers, forming a + cluster. Each such node would have the same information. Standard + techniques such as DNS SRV records can be used to select one of the + servers. Replication within the cluster can use any suitable + protocol mechanism, but a standardized, incremental update mechanism + makes it easier to spread those nodes across multiple independently + administered locations. The techniques developed for the meshed + Service Location Protocol (SLP) [RFC3528] are applicable here. + +8. Forest Guides + + Unfortunately, just having trees covering various regions of the + world is not sufficient, as a client of the mapping protocol would + not generally be able to keep track of all the trees in the forest. + To facilitate orientation among the trees, we introduce a forest + + + +Schulzrinne Informational [Page 11] + +RFC 5582 MapArch September 2009 + + + guide (FG), which keeps track of the coverage regions of all the + trees for one service and location profile. For scalability and + reliability, there will need to be a large number of forest guides, + all providing the same information. A seeker can contact a suitable + forest guide and will then be directed to the right tree or, rarely, + set of trees. Forest guides do not provide mapping information + themselves, but rather redirect to mapping servers. In some + configurations, not all forest guides may provide the same + information, due to policy reasons. + + Forest guides fulfill a similar role to root servers in DNS. They + distribute information, signed for authenticity, offered by trees. + However, introducing forest guides avoids creating a global root, + with the attendant management and control issues. + + However, unlike DNS root servers, forest guides may offer different + information based on local policy. Forest guides can also restrict + their data synchronization to parts of the information. For example, + if country C does not recognize country T, C can propagate tree + regions for all but T. + + For authenticity, the coverage regions SHOULD be digitally signed by + the authorities responsible for the region, as discussed in more + detail in Section 10. They are used by resolvers and possibly + seekers to find the appropriate tree for a particular area. All + forest guides should have consistent information, i.e., a collection + of all the coverage regions of all the trees. A tree node at the top + of a tree can contact any forest guide and inject new coverage region + information into the system. One would expect that each tree + announces its coverage to more than one forest guide. Each forest + guide peers with one or more other guides and distributes new + coverage region announcements to other guides. Due to policy and + maybe political reasons, not all forest guides may share the same + coverage region data. + + Forest guides can, in principle, be operated by anybody, including + voice service providers, Internet access providers, dedicated + services providers, and enterprises. + + As in routing, peering with other forest guides implies a certain + amount of trust in the peer. Thus, peering is likely to require some + negotiation between the administering parties concerned, rather than + automatic configuration. The mechanism itself does not imply a + particular policy as to who gets to advertise a particular coverage + region. + + + + + + +Schulzrinne Informational [Page 12] + +RFC 5582 MapArch September 2009 + + +9. Configuring Service Numbers + + The section below is not directly related to the problem of + determining service location but is an instance of the more generic + problem solved by this architecture -- namely, mapping location + information to service-related parameters, such as service numbers. + + For the foreseeable future, some user devices and software will + emulate the user interface of a telephone, i.e., the only way to + enter call address information is via a 12-button keypad with digits + and the asterisk and hash symbols. These devices use service numbers + to identify services. The best-known examples of service numbers are + emergency numbers, such as 9-1-1 in North America and 1-1-2 in + Europe. However, many other public and private service numbers have + been defined, ranging in the United States from 3-1-1 for non- + emergency local government services to 4-1-1 for directory + assistance, to various "800" numbers for anything from roadside + assistance to legal services to home-delivery food. + + Such service numbers are likely to be used until essentially all + communication devices feature IP connectivity and an alphanumeric + keyboard. Unfortunately, for emergency services, more than 60 + emergency numbers are in use throughout the world, with many of those + numbers serving non-emergency purposes elsewhere, e.g., identifying + repair or directory services. Countries also occasionally change + their emergency numbers to conform to regional agreements. An + example is the introduction of "1-1-2" for countries in Europe. + + Thus, a system that allows devices to be used internationally to + place calls needs to allow devices to discover service numbers + automatically. In the Internet-based system proposed in + [ECRIT-FRAME], these numbers are strictly used as a human-user + interface mechanism and are generally not visible in call signaling + messages, which carry the service URN [RFC5031] instead. + + For the best user experience, systems should be able to discover two + sets of service numbers -- namely, those used in the user's home + country and those used in the country the user is currently visiting. + The user is most likely to remember the former, but a companion + borrowing a device in an emergency, say, may only know the local + emergency numbers. + + Determining home and local service numbers is a configuration + problem, but unfortunately, existing configuration mechanisms are + ill-suited for this purpose. For example, a DHCP server might be + able to provide the local service numbers but not the home numbers. + When virtual private networks (VPNs) are used, even DHCP may provide + numbers of uncertain origin, as a user may contact the home network + + + +Schulzrinne Informational [Page 13] + +RFC 5582 MapArch September 2009 + + + or some local branch office of the corporate network. Similarly, SIP + configuration [CONFIG-FRAME] would be able to provide the numbers + valid at the location of the SIP service provider, but even a SIP + service provider with a national footprint may serve customers that + are visiting any number of other countries. + + Also, while initially there are likely to be only a few service + numbers, e.g., for emergency services, the LoST architecture can be + used to support other services, as noted. Configuring every local + DHCP or SIP configuration server with that information is likely to + be error-prone and tedious. + + For these reasons, the LoST-based mapping architecture supports + providing service numbers to end systems based on caller location. + The mapping operation is almost exactly the same as for determining + the service URL. The mapping can be obtained along with the service + URL. The major difference between the two requests is that service + numbers often have much larger regions of validity than the service + URL itself. Also, the service number is likely to be valid longer + than the service URL. Finally, an end system may want to look up the + service number for its home location, not just its current (visited) + location. + +10. Security Considerations + + Security considerations for emergency services mapping are discussed + in [RFC5069], while [RFC5031] discusses issues related to the service + URN, one of the inputs into the mapping protocol. LoST-related + security considerations are naturally discussed in the LoST + specification [RFC5222]. + + The architecture addresses the following security issues, usually + through the underlying transport security associations: + + server impersonation: Seekers, resolvers, fellow tree guides, and + cluster members can assure themselves of the identity of the + remote party by using the facilities in the underlying channel + security mechanism, such as Transport Layer Security (TLS) + [RFC5246]. + + query or query result corruption: To avoid the possibility of an + attacker modifying the query or its result, the architecture + RECOMMENDS the use of channel security, such as TLS. Results + SHOULD also be digitally signed, e.g., using XML digital + signatures [W3C.REC-xmldsig-core-20020212]. Note, however, that + simple origin assertion may not provide the end system with enough + useful information as it has no good way of knowing that a + particular signer is authorized to represent a particular + + + +Schulzrinne Informational [Page 14] + +RFC 5582 MapArch September 2009 + + + geographic area. It might be necessary that certain well-known + Certificate Authorities (CAs) vet sources of mapping information + and provide special certificates for that purpose. In many cases, + a seeker will have to trust its local resolver to vet information + for trustworthiness; in turn, the resolver may rely on trusted + forest guides to steer it to the correct information. + + coverage region corruption: To avoid the possibility of a third + party or an untrustworthy member of a server population claiming a + coverage region that it is not authorized for, any node + introducing a new service boundary MUST sign the object by + protecting the data with an XML digital signature + [W3C.REC-xmldsig-core-20020212]. A recipient MUST verify, through + a local policy mechanism, that the signing entity is indeed + authorized to speak for that region. Determining who can speak + for a particular region is inherently difficult unless there is a + small set of authorizing entities that participants in the mapping + architecture can trust. Receiving systems should be particularly + suspicious if an existing coverage region is replaced with a new + one with a new mapping address. In many cases, trust will be + mediated: a seeker will have a trust relationship with a resolver, + and the resolver, in turn, will contact a trusted forest guide. + + Additional threats that need to be addressed by operational measures + include denial-of-service attacks [PHONE-BCP]. + +11. Acknowledgments + + Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar + Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson, + Schida Schubert, Murugaraj Shanmugam, Richard Stastny, Hannes + Tschofenig, and Karl Heinz Wolf provided helpful comments. + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for + Emergency and Other Well-Known Services", RFC 5031, + January 2008. + + [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. + Tschofenig, "LoST: A Location-to-Service Translation + Protocol", RFC 5222, August 2008. + + + +Schulzrinne Informational [Page 15] + +RFC 5582 MapArch September 2009 + + + [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering + Location-to-Service Translation (LoST) Servers Using the + Dynamic Host Configuration Protocol (DHCP)", RFC 5223, + August 2008. + +12.2. Informative References + + [CONFIG-FRAME] + Channabasappa, S., "A Framework for Session Initiation + Protocol User Agent Profile Delivery", Work in Progress, + February 2008. + + [ECRIT-FRAME] + Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, + "Framework for Emergency Calling using Internet + Multimedia", Work in Progress, March 2009. + + [LOST-SYNC] + Schulzrinne, H. and H. Tschofenig, "Synchronizing + Location-to-Service Translation (LoST) Protocol based + Service Boundaries and Mapping Elements", Work + in Progress, March 2009. + + [PHONE-BCP] + Rosen, B. and J. Polk, "Best Current Practice for + Communications Services in support of Emergency Calling", + Work in Progress, March 2009. + + [RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced + Service Location Protocol (mSLP)", RFC 3528, April 2003. + + [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for + Emergency Context Resolution with Internet Technologies", + RFC 5012, January 2008. + + [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. + Shanmugam, "Security Threats and Requirements for + Emergency Call Marking and Mapping", RFC 5069, + January 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [W3C.REC-xmldsig-core-20020212] + Solo, D., Eastlake, D., and J. Reagle, "XML-Signature + Syntax and Processing", World Wide Web Consortium + FirstEdition REC-xmldsig-core-20020212, February 2002, + <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>. + + + +Schulzrinne Informational [Page 16] + +RFC 5582 MapArch September 2009 + + +Author's Address + + Henning Schulzrinne + Columbia University + Department of Computer Science + 450 Computer Science Building + New York, NY 10027 + US + + Phone: +1 212 939 7004 + EMail: hgs+ecrit@cs.columbia.edu + URI: http://www.cs.columbia.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne Informational [Page 17] + |