Network Working Group H. Schulzrinne Request for Comments: 5582 Columbia U. Category: Informational September 2009 Location-to-URL Mapping Architecture and Framework
AbstractThis 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.
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 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].
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]. RFC2119] and indicate requirement levels for compliant implementations. 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.
(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. 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
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
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.)
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. RFC5223] for an ISP. Resolvers are manually configured with the name of one or more forest guides.
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:firstname.lastname@example.org US NJ Bergen Fort Lee sip:email@example.com US NJ Bergen Teaneck sip:firstname.lastname@example.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.
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.
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. RFC3528] are applicable here.
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.
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
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. 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
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]. [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.
[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. [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>.