RFC 5582
Location-to-URL Mapping Architecture and Framework
RFC 5582: Location-to-URL Mapping Architecture and Framework 🗺️✨
Okay bestie, this one is from September 2009 and it's written by H. Schulzrinne from Columbia U. 🎓 It's an Informational doc, which means it provides information for the Internet community and does not specify an Internet standard of any kind 📖. It's RFC 5582, and the title block doesn't list anything it obsoletes or updates, so it's a standalone vibe 💅.
Abstract ✨
This doc describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs 🌍. The mapping happens using the Location-to-Service Translation (LoST) protocol 🔁. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS, so if you know DNS, you're already halfway there 🧠🎀.
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, because they describe your rights and restrictions with respect to this document 👀.
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 . . . . . . . . . . . . . . . . . . 161. Introduction 🌟
It's super common for users to want to access a service that does a common job but is actually run by a bunch of different local service providers 🏪. In a lot of these cases, which provider you get depends on where you are 📍. The best-known example is emergency calling, where calls get routed to the most appropriate public safety answering point (PSAP) based on the caller's physical location 🚨. Other services, like food delivery, directory services, and roadside assistance, follow the same general pattern 🍕🚗. This is a mapping problem [RFC5012], where a geographic location and a service identifier [RFC5031] get translated into a set of URIs, called the service URIs, so the Internet system can contact the right network entity that provides the service 🔍✨.
The caller doesn't need to know where the service is being provided from 🙈. The location of the service provider can also change over time, for example to deal with temporary overloads, failures in the primary service provider location, or long-term changes in system architecture 🔄. For emergency services, this is described in more detail in [ECRIT-FRAME] 🚑.
The overall emergency calling architecture [ECRIT-FRAME] keeps mapping separate from placing calls or otherwise invoking the service 🧩. That means the same mechanism can be used to verify that a mapping exists ("address validation") or to get test service URIs 🧪.
Mapping locations to URIs that describe services needs a distributed, scalable, and highly resilient infrastructure 💪. The authoritative knowledge about these mappings is spread across a large number of autonomous entities that may have no direct knowledge of each other 🌐. In this document, the architecture for such a global service is described 🌍. It allows a lot of freedom to combine and split functionality among actual servers, and it imposes few requirements on who should operate particular services 🦋.
End systems also need to figure out the local service numbers, not just the service URI 📞. As discussed in Section 9, the architecture described here can also handle that problem 💖.
The architecture described here uses the Location-to-Service Translation (LoST) [RFC5222] protocol 🔐. A lot of the discussion would also apply to other mapping protocols that satisfy 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 🧐. These are the words that matter most, so treat them like sacred text 💅.
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, for example, 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, meaning 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 they may be represented either as a subset of a civic address or as 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 it 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 🎀
okay so the mapping architecture has four logical roles 💅: seekers, resolvers, authoritative mapping servers (AMS), and forest guides (FGs). End users of the LoST-based [RFC5222] mapping mechanism are called seekers, and they contact resolvers that cache query results and know one or more forest guides. Forest guides sit at the top level of a conceptual hierarchy, with one or more trees giving a hierarchical resolution service for different geographic regions. They know the geographic coverage region of all or almost all trees and send queries to the node at the top of the right tree. Trees are made of authoritative mapping servers, and those servers keep the authoritative mapping information 🌸
all four roles talk to each other using LoST, and ngl it's very likely that in lots of cases the same software can act as a resolver, an AMS, and a forest guide 🧚 on top of the basic LoST query protocol [RFC5222], there's also a synchronization protocol [LOST-SYNC] that may be used to swap info between forest guides, or to push coverage info from a tree node up to its parent 💜
seekers can be part of Voice over IP (VoIP) or other end systems, or part of SIP proxies or similar call routing functions 📞✨
okay here's the picture (Figure 1) of how everything connects 👀
/-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | |
+--+--+ * +--+--+
| * |
| * |
| * |
| * |
/-\ +--+--+ * +--+--+
| R +------>+ FG +-----*-----------+ FG |
\-/ | | * | |
+--+--+ * +--+--+
| * |
| * |
| * |
|*** ^
/ \ / \
/ \ / \
/ \ / \
/ \ / \
----------- -----------
tree treeArchitecture 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 lines between the forest guides are logical connections, which just means they're syncing their info through the synchronization protocol [LOST-SYNC] 🦋
the mapping function for the whole world gets split up among trees 🌍 the collection of trees might not cover the entire world, and trees get added and removed whenever the organization of mapping data changes. We call that whole collection of trees a forest 🌲 there's no limit on how many trees are in the forest, but the author guesses it'll probably be somewhere between a few hundred and a few thousand. The low end would happen if each country runs one tree, and the high end would happen if different government or private organizations inside a country run independent trees 🇺🇳
we assume tree coverage info changes pretty slowly, like less than one change per year per tree 🐢 the system doesn't set a specific threshold though. Tree coverage would change if, for example, a country gets split or merged, or if two trees for different regions become part of a bigger tree 🫶 (meanwhile, info inside a tree changes way more often, fr 🔥)
4.2. Minimal System Architecture 🧃
it's possible to build a working system with only seekers and resolvers, as long as the resolvers have some other way of getting mapping data 🙈 for example, a company acting as a mapping service provider could collect mapping records by hand and make them available to its customers through the resolver. That's a feasible starting point, but this kind of setup is unlikely to scale globally 💀 one big problem is that it gets super hard for providers of authoritative data to make sure every provider has up-to-date info. And if new trees get set up, they'd somehow have to make themselves known to these providers. Honestly that's giving the old "hosts.txt" mechanism for passing around host info in the early Internet, before DNS was developed 📜
we'll go through what each component does in more detail below 👇
5. Seeker 🌷
clients that want location-to-service mappings are known as seekers 💖 they're the consumers of mapping data, and they send LoST queries as LoST protocol clients. Seekers never answer LoST queries 🙅♀️ they contact either forest guides or resolvers to find the right tree that can answer their questions authoritatively. Seekers can be end systems like SIP user agents, or call routing entities like SIP proxy servers 📱
sometimes seekers need several steps to get the mapping info, since they might get pointers to intermediate servers that lead them closer to the final answer 🗺️ seekers MAY cache query results for later use, but otherwise they don't owe anything to anyone else in the system 🧁
seekers need a way to find appropriate resolvers ✨ how they get that info is probably going to depend on who runs the resolver. For example, if the voice service provider runs the resolver, it might put the resolver's location in the SIP configuration info it hands out to its user agents 📲 an Internet access provider or enterprise can point seekers to a resolver through DHCP [RFC5223]. And in an ad hoc or zero-configuration environment, appropriate service directories may advertise resolvers 📣
seekers can cache responses too, just like everyone else in the system 🧠 this is especially handy when the response describes a result for a civic or geospatial region instead of just a single point 🗺️ for example, mobile nodes only have to update their resolution results when they leave the coverage area of a service provider, like a PSAP for emergency services 🚨 that means they can skip repeatedly polling for this info every time their location shifts a little bit 🙌 (mobile nodes would also need a location update mechanism, either local or triggered when they leave the current service area) This is going to be a big win for seekers that represent a large user population, like the outbound proxy in a corporate network 🏢 for instance, instead of querying separately for every single cubicle, the info from the authoritative node might show that the whole campus is covered by the same service provider 💼
with this caching and cache lifetimes of several days, most mobile users who travel to and from work only need to grab service area info along their commute route once per cache lifetime 🚗💨 no cap, that's so efficient 🫶
6. Resolver 🦋
a seeker can contact a forest guide directly, but it might not be able to easily find one 🔍 plus, seekers in the same geographic area may have already asked the same question 👯 so it makes sense to add another entity, called a resolver in this architecture 💅 resolvers know how to contact one or more forest guides, and they cache earlier queries to speed up responses to mapping queries and make the system more resilient 💪 each resolver can decide for itself which FGs to use, and it can make different choices for each top-level service ✨
ISPs or Voice Service Providers (VSPs) may include the address of a suitable resolver in their configuration info, like in the SIP configuration for a VSP or DHCP [RFC5223] for an ISP 🎀 resolvers are manually configured with the name of one or more forest guides 🛠️
7. Trees: Maintaining Authoritative Knowledge 🌳✨
7.1. Basic Operation
okay so the big idea 💅 is that authoritative knowledge about mapping data is spread across tons of independent admin entities, but seekers (clients) might need mapping info for literally any spot on earth 🌍. (Extending this to extra-terrestrial apps is left for future exploration 👽🚀.) The info is organized hierarchically, like a tree 🌳. Tree nodes for bigger geographic areas point to several child nodes, and each child covers a smaller area. Each tree node can be a cluster of LoST servers that all hold the same info and back each other up 🫶.
Each tree can map a location described by either civic or geographic coordinates, but not both, for one type of service (like 'sos.police', 'sos.fire' or 'counseling') and one location profile. Nothing stops you from reusing the same servers for different services or both coordinate types though 🙌. 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 right server "down" the tree ⬇️. Each 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 LoST shapes expressed in geospatial coordinates, like circles or polygons, or by a set of civic address descriptors (e.g., "country = DE, A1 = Bavaria"). Coverage regions may line up with political boundaries, but that's not required. Usually, to avoid confusion, only one cluster is responsible for a particular geographic or civic location, but the system can also handle cases where coverage regions overlap 💜.
There are no assumptions about the coverage region of a tree as a whole. A tree could cover a single city, a state/province, or an entire country 🗺️. Nodes within a tree need to loosely coordinate, but they don't need to be run by the same administrator.
The tree setup is kinda similar to the domain name system (DNS), except delegation is by region instead of by label 🧠. (DNS doesn't have the notion of forest guides, obvi.) You can also draw comparisons to the Lightweight Directory Access Protocol (LDAP) when it's deployed in a distributed fashion ✨.
Tree nodes keep two types of info: coverage regions and mappings. Coverage regions describe the region served by a child node and point to that child 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 route signaling requests further to servers covering smaller regions 🎀.
Leaf nodes (nodes without children) only maintain mappings, while the tree nodes above them only maintain coverage regions. Here's an emergency services leaf example showing how queries for three towns get directed to different PSAPs. Queries for Englewood get sent 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 does 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 might contain the coverage region entries shown below. Any query matching a location in Bergen County, for example, would be redirected or forwarded to the node located at bergen.nj.example.org 🗺️:
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
....There's no requirement that all child nodes cover the same level within the civic hierarchy 🙃. In the table above, the city of Newark decided to be listed directly within the state node, rather than through the county. Longest-match rules allow partial coverage, so queries for all other towns within Essex county get directed to the county node for further resolution 💅.
So honestly, there's no big difference between coverage region data and mapping data 🤓. The only difference is that coverage regions return names of LoST servers, while mapping entries contain service URLs. Mapping entries can be specific all the way down to the house or floor level, or they might only contain street-level info. 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 tree maintenance, the LoST synchronization mechanism [LOST-SYNC] lets nodes 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. Nodes can also go the other way and contact their parent nodes to tell them about their coverage region. It's a win when child nodes contact their parents, because changes in coverage regions can then propagate quickly up the tree 🚀.
7.2. Answering Queries
Within a tree, the basic operation is pretty straightforward 😌. A query reaches the root of the tree. That node figures out which coverage region matches the request and forwards the request to the server indicated in that coverage region record, then returns a response to the querier once it gets an answer back. That's recursion 🔁. Alternatively, the node returns the application unique string (server name) of that child node to the querier. That's iteration 🎯. This process applies to every node, so a node doesn't 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 🌟. So instead of saying that a particular geospatial coordinate maps to a service URL or server name, it MAY return a polygon showing the region where this answer would be returned, along with expiration time (time-to-live) info ⏰. The querying node can then cache this info for future use 💾.
For civic coordinates, trees may not include individual mapping records for each floor, house number, or street 🏠. To avoid giving the wrong impression that a particular location has been found valid, LoST can indicate which parts of the location information were actually used to look up a mapping 👀.
7.3. Overlapping Coverage Regions
Sometimes coverage regions overlap 🫣, either because there's a dispute over who handles a particular geographic region or, more likely, because the coverage map's resolution isn't high enough. For example, a node might "shave some corners" off its polygon so it appears to overlap with its geographic neighbor ✂️. For civic coordinates, houses on the same street may be served by different PSAPs 🏘️. The mapping mechanism still needs to work even if a coverage map is imprecise or there are disputes about coverage 💪.
The fix for overlapping coverage regions is pretty simple 🙌. If a query matches multiple coverage regions, the node returns all URLs or server names in redirection mode, or queries both children in recursive mode. If the overlap 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 the answers, and it's up to the querier to choose the preferred solution or try to contact all services in turn ⚖️.
7.4. Scaling and Reliability
Since tree nodes provide authoritative information, they need to be highly reliable 💖. So while this document refers to tree nodes as logical entities within the tree, a real implementation would likely replicate node information across several servers, forming a cluster 🖥️🖥️🖥️. Each of those servers would have the same information. Standard techniques like DNS SRV records can be used to pick 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 🌲✨
Okay so just having trees covering all the regions of the world is NOT enough 😭, because a mapping client usually can't keep track of every single tree in the forest. 🌳 So we bring in a forest guide (FG) 🧭, which keeps track of the coverage regions of all the trees for one service and location profile. For scalability and reliability there needs to be a large number of forest guides, all giving out the same info 💅. A seeker can contact a suitable forest guide and then get pointed to the right tree (or, rarely, a set of trees) 🎯. Forest guides don't hand out mapping info themselves. They just redirect you to mapping servers 🔁. In some setups, not every forest guide gives the same info, and that's down to policy reasons 🤷♀️.
Forest guides have a similar vibe to root servers in DNS 🌸. They distribute information that trees offer, signed for authenticity 🔏. The fun part is that introducing forest guides means we avoid creating a global root, and all the management and control drama that comes with one 🙅♀️.
Unlike DNS root servers though, forest guides can offer different information depending on local policy 🎀. They can also limit their data sync to only parts of the information. For example, if country C doesn't recognize country T, then C can propagate tree regions for everything except T 🫣.
For authenticity, the coverage regions SHOULD be digitally signed by the authorities responsible for the region, and we dig into that more in Section 10 🔐. Resolvers and maybe seekers use these to find the right tree for a particular area 🗺️. All forest guides should have consistent information, so basically 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 info into the system 💉. You'd expect each tree to announce its coverage to more than one forest guide 👯. Each forest guide peers with one or more other guides and passes new coverage region announcements along to them 📣. And because of policy (and maybe politics) 🙃, not all forest guides have to share the same coverage region data.
Anybody can, in principle, run a forest guide 🙌. That includes voice service providers, Internet access providers, dedicated services providers, and enterprises 💼.
Peering with other forest guides implies a certain amount of trust in the peer, just like in routing 🤝. So peering will likely need some negotiation between the administering parties, rather than automatic configuration 📝. The mechanism itself doesn't imply any particular policy about who gets to advertise a particular coverage region 🚫.
9. Configuring Service Numbers 📞💖
This section isn't directly about figuring out service location 🙈. It's an example of the more generic problem this architecture solves, which is mapping location info to service-related parameters, like service numbers 🔢.
For the foreseeable future, some user devices and software will copy the user interface of a telephone 📱. So the only way to enter call address info is with a 12-button keypad that has digits plus the asterisk and hash symbols 🔣. These devices use service numbers to identify services. The best-known ones are emergency numbers, like 9-1-1 in North America and 1-1-2 in Europe 🚨. But tons of other public and private service numbers exist too 😮💨. In the United States, that ranges from 3-1-1 for non-emergency local government services, to 4-1-1 for directory assistance, to various "800" numbers for everything from roadside assistance to legal services to home-delivery food 🍕.
Service numbers will probably stick around until basically every communication device has IP connectivity and an alphanumeric keyboard ⌨️. And honestly, for emergency services it's a mess 💀: more than 60 emergency numbers are in use around the world, and many of those numbers are used for non-emergency stuff somewhere else, like repair or directory services 📖. Countries also sometimes change their emergency numbers to match regional agreements. The introduction of "1-1-2" for countries in Europe is one example 🇪🇺.
So a system that lets devices be used internationally to place calls needs to let devices 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 they're generally not visible in call signaling messages. Those messages carry the service URN [RFC5031] instead 📨.
For the best user experience, systems should be able to discover two sets of service numbers: the ones used in the user's home country, and the ones used in the country the user is currently visiting 🌍. The user will most likely remember the home ones, but a companion borrowing a device in an emergency might only know the local emergency numbers 🥺.
Figuring out home and local service numbers is a configuration problem, and unfortunately the existing configuration mechanisms aren't a great fit 😩. For example, a DHCP server might be able to provide the local service numbers but not the home ones 🙃. When virtual private networks (VPNs) are used, even DHCP might hand over numbers of uncertain origin, since a user could be contacting the home network or some local branch office of the corporate network 🏢. SIP configuration [CONFIG-FRAME] would be able to provide the numbers valid where the SIP service provider is located. But even a SIP service provider with a national footprint may serve customers visiting any number of other countries ✈️.
Also, while there are initially likely to be only a few service numbers (for example, for emergency services), the LoST architecture can be used to support other services too, as noted. Configuring every local DHCP or SIP configuration server with that info would be error-prone and tedious 😵💫.
So 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 the one for determining the service URL 🔄. The mapping can be obtained along with the service URL. The big difference between the two requests is that service numbers often have much larger regions of validity than the service URL itself 🗺️. The service number is also likely to stay valid longer than the service URL ⏳. And 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 🔐🛡️
Okay this section is SERIOUS, bestie 😤. Security considerations for emergency services mapping are discussed in [RFC5069], while [RFC5031] covers issues related to the service URN, which is 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 make sure they're talking to the right party by using the facilities in the underlying channel security mechanism, like Transport Layer Security (TLS) [RFC5246] 🪪.
- query or query result corruption: To stop an attacker from messing with the query or its result, the architecture RECOMMENDS the use of channel security, like TLS 🔒. Results SHOULD also be digitally signed, for example using XML digital signatures [W3C.REC-xmldsig-core-20020212] ✍️. But heads up: simple origin assertion might not give the end system enough useful info, because it has no good way of knowing that a particular signer is authorized to represent a particular geographic area 🤔. It might be necessary for certain well-known Certificate Authorities (CAs) to vet sources of mapping info and issue special certificates for that purpose 🏅. In many cases, a seeker will have to trust its local resolver to vet info for trustworthiness, and in turn the resolver may rely on trusted forest guides to steer it to the correct info 🧭.
- coverage region corruption: To stop a third party, or an untrustworthy member of a server population, from claiming a coverage region they aren't 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 actually authorized to speak for that region 🕵️♀️. Figuring out who can speak for a particular region is inherently difficult, unless there's 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 gets replaced with a new one that has 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] 🚨💀. Not optional, bestie!
11. Acknowledgments 🎀
Huge thank-yous to 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 for providing 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.
- [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 ✨
okay so these are the "good to know" references, not the must-reads 💅 bookmark them for later bestie 🧚
- [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>. 🌸
Author's Address 🎀
Here's where to find the author, iykyk 🫶
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.eduAnd that's a wrap on the whole doc, bestie 🌈👑 we made it!! 💖
📦 where this page comes from
- ietf: rfc5582 2009-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms