RFC 9138

Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

📅 published December 2021, from ietf

RFC 9138: Design Considerations for Name Resolution Service in Information-Centric Networking (ICN) 🎀

Okay bestie, let's set the scene 💅 This is RFC 9138, published in November 2021. It's Informational, which means it's for sharing knowledge and not a standard 📚 It comes from the IRTF (Internet Research Task Force), and the ISSN is 2070-1721. The authors are J. Hong and T. You (ETRI), L. Dong and C. Westphal (Futurewei Technologies Inc.), and B. Ohlman (Ericsson). The title block doesn't say it obsoletes or updates anything, so it's standing on its own 🦋

Abstract ✨

This doc gives the functions and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking (ICN) 🧚 The whole point of an NRS in ICN is to take an object name and translate it into some other information, like a locator or another name, so the object request can actually be forwarded 🍓 This document is a product of the Information-Centric Networking Research Group (ICNRG).

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes 🌈

This document is a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development activities. Those results might not be suitable for deployment, so keep that in mind 🙈 This RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 💅

Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc9138 🔗

Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents 🗂️

   1.  Introduction
   2.  Name Resolution Service in ICN
     2.1.  Explicit Name Resolution Approach
     2.2.  Name-Based Routing Approach
     2.3.  Hybrid Approach
     2.4.  Comparisons of Name Resolution Approaches
   3.  Functionalities of NRS in ICN
     3.1.  Support Heterogeneous Name Types
     3.2.  Support Producer Mobility
     3.3.  Support Scalable Routing System
     3.4.  Support Off-Path Caching
     3.5.  Support Nameless Object
     3.6.  Support Manifest
     3.7.  Support Metadata
   4.  Design Considerations for NRS in ICN
     4.1.  Resolution Response Time
     4.2.  Response Accuracy
     4.3.  Resolution Guarantee
     4.4.  Resolution Fairness
     4.5.  Scalability
     4.6.  Manageability
     4.7.  Deployed System
     4.8.  Fault Tolerance
     4.9.  Security and Privacy
       4.9.1.  Confidentiality
       4.9.2.  Authentication
       4.9.3.  Integrity
       4.9.4.  Resiliency and Availability
   5.  Conclusion
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction 🦋

Today's Internet runs on a host-centric networking model. Hosts are identified by IP addresses, and any pair of hosts can talk to each other. So the information on today's Internet is identified by the name of the host (or server) where it's stored 💻 Information-Centric Networking (ICN) flips that. Its main communication objects are the named data objects (NDOs), and each one is uniquely identified by a location-independent name ✨ ICN is all about getting NDOs around efficiently and at global scale. It's been recognized as a promising candidate for a future Internet architecture that fixes limitations of today's Internet, like scalability and mobility [Ahlgren] [Xylomenos]. ICN is also showing up as a candidate in the Internet of Things (IoT) because IoT cares about data and information [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2] 🌷

Naming data separately from where it's stored is a core ICN idea, so the big challenge is how to find any NDO using a location-independent name 🧩 ICN routing may involve three steps [RFC7927]:

  1. Name resolution: matches or translates a content name to the locator of the content producer or source that can provide the content 🔍
  2. Content request routing: routes the content request toward the content's location, based on either its name or its locator 🛣️
  3. Content delivery: transfers the content to the requester 📦

This document only looks at the name resolution step, which translates a content name into a content locator 💖 It also covers the different kinds of name resolution in ICN, like name to name, name to locator, name to manifest, name to metadata, and so on 🌈

The star of this doc is the Name Resolution Service (NRS) itself, as a service or system in ICN. It gives the functions and design considerations for an NRS in ICN, plus an overview of the NRS approaches in ICN ✨ Its companion document, [NRSarch], looks at the ICN architecture and routing system from the angle of using an NRS in ICN 🧚

This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It was reviewed extensively by the Research Group (RG) members who are actively working on the technology it covers 🫶 It is not an IETF product and it is not a standard.

2. Name Resolution Service in ICN 💅

An NRS in ICN is the service that handles name resolution, which translates an object name into some other information, like a locator, another name, metadata, or next-hop info, that's used to forward the object request 🍓 In other words, an NRS is a service the ICN infrastructure can offer to help a consumer reach a specific piece of information (or named data object) 🎀 The consumer gives the NRS a persistent name, and the NRS returns a name or locator (or potentially several names and locators) that can reach a current instance of the requested object 🔑

Name resolution is a necessary part of ICN routing 🌸 It can either be split off from content request routing as an explicit process, or it can be blended into content request routing as an implicit process. The first is called the "explicit name resolution approach" in this document, and the second is called the "name-based routing approach" 💜

2.1. Explicit Name Resolution Approach 🌷

An NRS could take the explicit name resolution approach. It returns the content's locators to the client, and the underlying network then uses those locators as identifiers to route the client's request to one of the producers or to a copy of the content 🚀 Several ICN projects use this approach, including Data-Oriented Network Architecture (DONA) [Koponen], PURSUIT [PURSUIT], Network of Information (NetInf) [SAIL], MobilityFirst [MF], IDNet [Jung], and more 🌈 The explicit name resolution approach has also been allowed for 5G control planes [SA2-5GLAN] 📡

2.2. Name-Based Routing Approach 🦋

An NRS could take the name-based routing approach, which folds name resolution into content request message routing. Named Data Networking / Content-Centric Networking (NDN/CCNx) does this [NDN] [CCNx] ✨

When the content request also specifies the reverse path, like in NDN/CCNx, the name resolution mechanism also works out the routing path for the data 🧠 That adds a requirement: the name resolution service has to propagate the request in a way that matches the later data forwarding. Basically, the request must select a path for the data based on finding a copy of the content, but it also has to make sure the data actually gets delivered 💀

2.3. Hybrid Approach 🍓

An NRS could also take a hybrid approach. For example, it can try the name-based routing approach first. If that fails at a certain router, the router can fall back to the explicit name resolution approach 🔄 The hybrid NRS approach also works the other way around: it first does explicit name resolution to find the locators of routers, then routes the client's request using the name-based routing approach 🧚

A hybrid approach would combine name resolution over a subset of routers on the path with some tunneling in between (say, across an administrative domain). That way, only a few of the nodes in the ICN network have to do name resolution in the name-based routing approach 🫧

2.4. Comparisons of Name Resolution Approaches

okay so let's compare the explicit name resolution and name-based routing approaches across a few aspects 💅✨

  • Overhead due to the maintenance of the content location: content reachability is super dynamic 🌊 new content gets cached, old content expires from a cache, producers can move around, and so on. Keeping everyone's view of where content lives consistent across the network costs some overhead, and that overhead is different for each approach. The name-based routing approach may need to flood parts of the network to propagate updates. In the worst case it may flood the whole network (but mitigating techniques can be used to scope the flooding 🫶). The explicit name resolution approach only needs to propagate updates within part of the name resolution system, which could be an overlay with a limited number of nodes 🦋
  • Resolution capability: if the explicit name resolution approach is designed and deployed with sufficient robustness, it can offer at least weak guarantees that resolution will succeed for any content name in the network, as long as that name is registered to the name resolution overlay 💜. With name-based routing, resolution depends on the flooding scope of the content names (that is, the content publishing message and the resulting name-based routing tables) 🌸. For example, when content is cached, the router may only notify its direct neighbors about it. So only those neighboring routers can build a name-based entry for this cached content. But if those neighbors keep propagating the information, the other nodes can direct traffic to this cached copy too 🧚
  • Node failure impact: in the explicit name resolution approach, the nodes involved are the name resolution overlay servers (for example, resolution handlers in DONA) 🖥️. In the name-based routing approach, the nodes involved are routers that forward messages based on name-based routing tables (for example, NDN routers). Node failures in the explicit name resolution approach may cause some content request routing to fail even though the content is available 😭. This problem does not exist in the name-based routing approach, because other alternative paths can be discovered to bypass the failed ICN routers, given the assumption that the network is still connected 🛣️
  • Maintained databases: the storage usage differs between the two approaches 🗄️. The explicit name resolution approach typically needs to maintain two databases: the name-to-locator mapping in the name resolution overlay, and the routing tables in the routers on the data forwarding plane. The name-based routing approach only needs to maintain the name-based routing tables 🍓

Additionally, some other intermediary step may be included in name resolution, namely the mapping of one name to other names, in order to help retrieve named content by way of a manifest [Westphal] [RFC8569] 📜. The manifest is resolved using one of the two approaches above, and it may include further mapping of names to content and location. So the steps for name resolution become the following: first, translate the manifest name into a location of a copy of the manifest, which includes further names of the content components and potentially locations for the content. Then retrieve the content using these names and/or location, which can potentially result in additional name resolutions 🔁

Thus, no matter which approach an NRS in ICN takes, name resolution is the essential function that shall be provided by the ICN infrastructure 👑

3. Functionalities of NRS in ICN ✨

okay, this section is where we get into what an NRS in ICN actually has to do 🎀

3.1. Support Heterogeneous Name Types

in ICN, a name is used to identify the data object and is bound to it [RFC7927] 🏷️. ICN needs uniqueness and persistency of the name of the data object so the object stays reachable within a certain scope. There are heterogeneous approaches to designing ICN naming schemes [Bari] 🌈. Ideally, a name can include any form of identifier, whether it's flat or hierarchical, human readable or non-readable.

even though there are lots of naming schemes out there, they all need to provide the basic functions of identifying a data object, supporting named data lookup, and routing 🧩. An NRS may combine the best bits of different schemes. Basically, an NRS should be able to support a generic naming schema, so it can resolve any type of content name, whether it's flat, hierarchical, attribute based, or anything else 💖

in PURSUIT [PURSUIT], names are flat, and the rendezvous functions are defined for an NRS. These are implemented by a set of rendezvous nodes (RNs), known as the rendezvous network (RENE) 🌐. A name consists of a sequence of scope IDs, and a single rendezvous ID is routed by the RNs in RENE. So PURSUIT decouples name resolution and data routing, with the NRS performed by the RENE 🫧

in MobilityFirst [MF], a name known as a "Global Unique Identifier (GUID)" is derived from a human-readable name via a global naming service. It's a flat typed 160-bit string with self-certifying properties 🔐. So MobilityFirst defines a Global Name Resolution Service (GNRS), which resolves GUIDs to network addresses and decouples name resolution and data routing in a similar way to PURSUIT 💅

in NetInf [Dannewitz], information objects are named using Named Information (NI) names [RFC6920]. These consist of an authority part and a digest part (a content hash) 🔍. The NI names can be flat, since the authority part is optional. So the NetInf architecture also includes a Name Resolution System (NRS), which can be used to resolve NI names to addresses in an underlying routable network layer 🗺️

in NDN [NDN] and CCNx [CCNx], names are hierarchical and may look similar to URLs 🔗. Each name component can be anything, including a human-readable string or a hash value. NDN/CCNx adopts the name-based routing approach 🦋. The NDN router forwards the request by doing a longest-match lookup in the Forwarding Information Base (FIB) based on the content name, and the request is stored in the Pending Interest Table (PIT) 📋

3.2. Support Producer Mobility

ICN inherently supports mobility by consumers 🏃‍♀️. Namely, consumer or client mobility is handled by re-requesting the content in case a mobility event (say, a handover) happens before the corresponding content is received from the network. Since ICN can ensure that content reception continues without disruption in ICN applications, seamless mobility from the consumer's point of view can be easily supported 🥰

however, producer mobility doesn't come out naturally from the ICN forwarding model the way consumer mobility does 🙈. If a producer moves to a different network location or a different name domain (one assigned by another authoritative publisher), it would be difficult for mobility management to update the Routing Information Base (RIB) and FIB entries in ICN routers with the new forwarding path in a very short time. That's why various ICN architectures in the literature have proposed adopting an NRS to achieve producer or publisher mobility. The NRS can be implemented in different ways, such as rendezvous points and/or overlay mapping systems 🛸

in NDN [Zhang2], for producer mobility support, rendezvous mechanisms have been proposed to build interest rendezvous (RV) with data generated by a mobile producer (MP) 🌙. This can be classified into two approaches: chase mobile producer and rendezvous data. For MP chasing, the rendezvous acts as a mapping service that provides the mapping from the name of the data produced by the MP to the name of the MP's current point of attachment (PoA). Alternatively, the RV serves as a home agent, as in IP mobility support, so the RV lets the consumer's Interest message tunnel towards the MP at the PoA 🚇. For rendezvous data, the solution involves moving the data produced by the MP to a data depot instead of forwarding Interest messages. So a consumer's Interest message can be forwarded to a stationary place called a "data rendezvous," which would either return the data or fetch it using another mapping solution 📦. Therefore, RV or other mapping functions play the role of an NRS in NDN 💜

in [Ravindran], the forwarding label (FL) object is used to split the identifier (ID) and locator (LID) namespaces in ICN 🧭. Generally, IDs are managed by applications, while locators are managed by a network administrator. That way, IDs are mapped to heterogeneous name schemes, and LIDs are mapped to network domains or to specific network elements. So the proposed FL object acts as a locator (LID) and provides the flexibility to forward Interest messages through a mapping service between IDs and LIDs. Therefore, the mapping service in the control plane infrastructure can be considered an NRS in this draft 🎀

in MobilityFirst [MF], both consumer and publisher mobility can be mainly handled by the global name resolution service (GNRS), which resolves GUIDs to network addresses. So the GNRS must be updated for mobility support when a network-attached object changes its point of attachment. This differs from NDN/CCNx 🌷

in NetInf [Dannewitz], mobility is handled by an NRS in a very similar way to MobilityFirst 🫶

besides consumer and producer mobility, ICN also faces challenges supporting other dynamic features, such as multi-homing, migration, and replication of named resources like content, devices, and services 🌀. So an NRS can help support these dynamic features too 🦄

3.3. Support Scalable Routing System

in ICN, the name of a data object is used for routing, either through a name resolution step or a routing table lookup 🗺️. So routing information for each data object should be maintained in the routing base, such as the RIB and FIB. Since the number of data objects would be very large, the size of these information bases would be significantly larger as well [RFC7927] 📈

the hierarchical namespace used in the CCNx [CCNx] and NDN [NDN] architectures reduces the size of these tables through name aggregation, which improves the scalability of the routing system 🌳. A flat naming scheme, on the other hand, would aggravate the scalability problem of the routing system 😬. The non-aggregated name prefixes injected into the Default Route Free Zone (DFZ) of ICN would create a more serious scalability problem than the scalability issues of the IP routing system. So an NRS may play an important role in reducing the routing scalability problem, regardless of the type of namespace 💫

in [Afanasyev], to address the routing scalability problem in NDN's DFZ, a well-known concept called "map-and-encap" is applied to provide a simple and secure namespace mapping solution 🎁. In the proposed map-and-encap design, data whose name prefixes don't exist in the DFZ forwarding table can be retrieved by a distributed mapping system called NDNS. NDNS maintains and looks up the mapping information from a name to its globally routed prefixes, and NDNS is a kind of NRS 🌟

3.4. Support Off-Path Caching 🌸

okay so in-network caching is basically a core building block of any ICN architecture, no cap 🧚 It can give users a better quality-of-service (QoS) experience, cut down overall network traffic, help stop network congestion and denial-of-service (DoS) attacks, and boost availability ✨ Caches can be sorted into off-path and on-path caches depending on where they sit relative to the forwarding path between the original server and the consumer. Off-path caching, also called "content replication" or "content storing", is all about copying content around the network to make it more available, and it doesn't care whether the cache is on the forwarding path or not 💅 That's why finding off-path cached objects isn't trivial with name-based routing in ICN 🙈 To support off-path caches, replicas are usually advertised into a name-based routing system or into an NRS.

In [Bayhan], an NRS is used to find off-path copies around the network, even ones that name-based routing mechanisms can't reach 👑 This is so helpful for an Autonomous System (AS): it can avoid costly inter-AS traffic for external content, get better bandwidth efficiency for intra-AS traffic, and cut the data access latency for a smoother user experience 🫶

3.5. Support Nameless Object 🦋

okay this one is so cool. In CCNx 1.0 [Mosko2], there's a concept called a "Nameless Object", which is a Content Object without a name 🤯 The whole point is to move content between storage replicas without having to rename or re-sign the Content Objects for a new name. Nameless Objects can be addressed by the ContentObjectHash, which is used to restrict Content Object matching with a SHA-256 hash 🔐

So an Interest message still carries both a name and a ContentObjectHash. The name is used for routing, and the ContentObjectHash is used for matching ✨ On the reverse path, if the Content Object's name is missing, then it's a "Nameless Object" and it only matches against the ContentObjectHash 💜 That means a consumer needs to resolve the proper name and hashes through an outside system, which can be considered an NRS. iykyk 😭

3.6. Support Manifest 🎀

for collections of data objects that are organized as large, file-like contents [FLIC], manifests are the data structures that carry this info around 📁 Manifests can contain hash digests of signed Content Objects or of other manifests, so that large Content Objects representing a big piece of application data can be collected using one manifest 🌈

To request Content Objects, a consumer needs to know a manifest root name so it can acquire the manifest. In the case of File-Like ICN Collections (FLIC), a manifest name can be represented by a nameless root manifest, so an outside system such as an NRS may get involved to hand this info to the consumer 🧚

3.7. Support Metadata 🍓

when resolving the name of a Content Object, an NRS could return a rich set of metadata along with a locator 🤩 The metadata could include alternative object locations, supported object transfer protocol(s), caching policy, security parameters, data format, hash of object data, etc. The consumer could use this metadata to pick an object transfer protocol, a security mechanism, an egress interface, and so on 💅 An example of how metadata can be used like this is in the Networked Object (NEO) ICN architecture [NEO], which is giving main character energy ⭐

4. Design Considerations for NRS in ICN ✨

this section is where we talk about the design considerations for NRS in ICN 🫶

4.1. Resolution Response Time ⏱️

the name resolution process should give a response within a reasonable amount of time 🌸 The response should either be a proper mapping of the name to a copy of the content, or an error message saying no such object exists. If name resolution doesn't map to a location, the system may not issue any response at all, so the client should set a timer when it sends a request and treat the resolution as incomplete once the timer expires ⏰

The acceptable response delay could be on the order of a round-trip time between the client sending the request and the NRS servers that answer it. This RTT can vary a lot depending on how close the two endpoints are, so some upper bound needs to be used 🦋 Especially in delay-sensitive scenarios like the industrial Internet and telemedicine, the upper bound of the response delay must be guaranteed 🚑

The response time includes all the steps of the resolution, including potentially a hop-by-hop resolution or a hierarchical forwarding of the resolution request 🧩

4.2. Response Accuracy 🎯

an NRS must provide an accurate response, meaning a proper binding of the requested name (or prefix) with a location 💖 The response can be either a (prefix, location) pair or the actual forwarding of a request to a node holding the content, which then sends the content back 📬

an NRS must also provide an up-to-date response, meaning an NRS should be updated within a reasonable time when new copies of the content are stored in the network. Not every transient cache addition or eviction should trigger an NRS update, but some origin servers may move and need the NRS to be updated 🚚

an NRS must provide mechanisms to update the mapping of content to its location. Specifically, an NRS must provide a way for a content provider to add new content, revoke old, dated, or obsolete content, and modify existing content. Any content update should then be propagated through the NRS system within a reasonable delay 🔄

Content that is highly mobile may require specifying some type of anchor that is kept at the NRS instead of the content location 🪝

4.3. Resolution Guarantee 🔒

an NRS must ensure that name resolution succeeds with high probability if the name-matching content exists in the network, no matter how popular it is or how many cached copies exist 💯 As we said in Section 4.1, some resolutions may not happen in a timely manner, but the probability of that should be minimized 📉 The NRS system may provide a probability (five 9s or five sigmas, for instance) that a resolution will be satisfied 🧮

4.4. Resolution Fairness ⚖️

an NRS could provide this service for all content in a fair way, no matter the specific content properties (content producer, content popularity, availability of copies, content format, etc.) 🌈 Fairness may be defined as a per-request delay to complete the NRS steps that doesn't depend on the properties of the content itself. Fairness may also be defined as the number of requests answered per unit of time 💅

it's notable, though, that content (or its associated producer) may request a different level of QoS from the network (see [RFC9064], for instance), and that can include the NRS too 👑 In that case, fairness considerations may be limited to content within the same class of service 🎀

4.5. Scalability 🚀

the NRS system must scale up to support a very large user population, including human users as well as machine-to-machine communications 🤖 As an idea of the scale, it's expected that 50 billion devices will be connected in 2025 (per ITU projections) 😳 The system must be able to respond to a very large number of requests per unit of time. Message forwarding and processing, routing table buildup, and name record propagation must all be efficient and scalable 💪

the NRS system must scale up with the number of pieces of content (content names), and it should be able to support a content catalog that is extremely large 📚 Internet traffic is on the order of zettabytes per year (10^21 bytes). Since NRS is tied to actual traffic, the number of pieces of content should scale with the amount of traffic 📈 Content size may range from a few bytes to several GB, so the NRS should be expected to scale up to a catalog of the size of 10^21 in the near future, and larger beyond 🌌

the NRS system must be able to scale up, meaning it must be possible to add NRS servers to the NRS system in a way that's transparent to users 🧚 Adding a new server should have a limited negative impact on the other NRS servers (or a negative impact on only a small subset of them). Adding new servers may cause some overhead at the other servers as they rebuild a hierarchy or exchange messages to include the new server in the service 🔧 Data may also be shared among the new servers for load balancing or fault tolerance. These steps should not disrupt the service the NRS provides, and they should improve quality of service in the long run 🌷

The NRS system may support access from a heterogeneity of connection methods and devices. In particular, the NRS system may support access from constrained devices, and interacting with the NRS system would not be too costly 🔋 An IoT node, for instance, should be able to access the NRS system just as well as a more powerful node 🫶

The NRS system should scale up in its responsiveness to the increased request rate expected from applications like IoT or machine-to-machine (M2M), where data is frequently generated and/or requested 📡

4.6. Manageability 🛠️

the NRS system must be manageable, since parts of the system may grow or shrink dynamically and an NRS system node may be added or deleted frequently 🌱

The NRS system may support an NRS management layer that allows NRS nodes to be added or subtracted. To work out the circumstances, the management layer can measure the network status 📊

4.7. Deployed System 🌍

the NRS system must be deployable, since deployability matters a lot for a real-world system 🙌 The NRS system must be deployable in network edges and cores so that consumers and ICN routers can both perform name resolution with very low latency ⚡

4.8. Fault Tolerance 🛡️

the NRS system must ensure resiliency when NRS servers fail. The failure of a small subset of nodes should not significantly impact NRS performance 💪

After an NRS server fails, the NRS system must be able to recover and/or restore the name records stored in that server 💾

4.9. Security and Privacy 🔐

okay, bestie, this part is serious 💀 There are real security considerations for the NRS servers/nodes and for the name mapping records stored in the NRS system, so pay close attention.

when using an NRS in ICN, there are some security considerations for the NRS servers/nodes and name mapping records stored in the NRS system. This subsection describes them 🙈

4.9.1. Confidentiality ✨

okay bestie, confidentiality is the big one 🔒💖 name mapping records in the NRS system must be given proper access rights, so the info inside them never gets revealed to unauthorized users. no peeking, periodt 💅

the NRS system may support access control for certain records 🎀 one way is a reference monitor that uses client authentication, so only users with the right credentials can access those records, and they don't get shared with unauthorized users. another way is encryption-based techniques, where you control the keys to control how the mappings get propagated 🗝️✨

the NRS system may also support obfuscation and/or encryption mechanisms so the content of a resolution request isn't accessible to third parties outside the NRS system 🦋 hiding the request from outsiders is giving main character energy

the NRS system must keep confidentiality to stop sensitive name mapping records from being reached by unauthorized data requesters 🔐 this is even more required in IoT environments, where tons of sensitive data gets produced 😭

the NRS system must also keep confidentiality of metadata and NRS usage to protect users' privacy 🫶 for example, one user's NRS requests should not be shared outside the NRS system, unless it's legal intercept 🙈

4.9.2. Authentication 🧚

NRS server authentication: new NRS servers and nodes that want to register with the NRS system must be required to authenticate, so only authenticated entities can store and update name mapping records 💜 the NRS system should also detect an attacker pretending to be a fake NRS server, whether they're trying to cause service disruption or manipulate name mapping records. not me spotting the fake 💀

Producer authentication: the NRS system must support authenticating content producers 🌸 this makes sure the updates, additions, and removals of name mapping records that producers ask for are actually valid, and that producers are authorized to modify or revoke those records or add new ones 👑

Mapping record authentication: the NRS should verify new mapping records as they're being registered 🍓 that way the system can't get polluted with falsified information or invalid records. ngl this is the bouncer at the door ✨

4.9.3. Integrity 🌈

the NRS system must be protected from malicious users who try to hijack or corrupt the name mapping records. hands off, no cap 🚫💅

4.9.4. Resiliency and Availability ⭐

the NRS system should be resilient against denial-of-service attacks and other common attacks 🛡️ the goal is to isolate the impact of an attack and prevent collateral damage to the entire system. so if part of the NRS system fails, that failure should only affect a local domain 🧱 and fast recovery mechanisms need to be in place to bring the service back to normal ⚡ the comeback is everything

5. Conclusion 🌸

okay so ICN routing may be made up of three steps: name resolution, content request routing, and content delivery 🛤️ this document looks at name resolution, which is the first step and the most important one for ICN routing to actually work 👑

the Name Resolution Service (NRS) in ICN is defined as the service that does name resolution. it translates an object name into some other info, like a locator, another name, metadata, next-hop info, and so on, which is then used to forward the object request 🦋

this document sorts the NRS approaches by whether the name resolution step is separated from content request routing as an explicit process or not 🎀 it also explains the NRS functions that support heterogeneous name types, producer mobility, scalable routing systems, off-path caching, nameless objects, manifests, and metadata 🧚 finally, it presents design considerations for NRS in ICN: resolution response time and accuracy, resolution guarantee, resolution fairness, scalability, manageability, deployed system, and fault tolerance 💖 iconic lineup, honestly

6. IANA Considerations 🦋

this document has no IANA actions ✨ nothing to register here, bestie

7. Security Considerations 🔐

for security guidelines, check out Section 4.9 💜 it's where all the security drama lives 💀

8. References 📚

8.1. Normative References 🍓

[RFC7927]  Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
           Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
           "Information-Centric Networking (ICN) Research
           Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
           <https://www.rfc-editor.org/info/rfc7927>.

8.2. Informative References 📚✨

okay so these are the bibliography bits that help you dig deeper, bestie 🧚 they aren't required to implement anything, but they're giving great background reading 💅

Acknowledgements 🫶

The authors would like to thank Dave Oran, Dirk Kutscher, Ved Kafle, Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kühlewind, and Colin Perkins for very useful reviews, comments, and improvements to the document. 💜 bestie, that's a whole squad of legends 👑

Authors' Addresses 🎀

these are the wonderful humans who wrote this thing 🦋

Jungha Hong
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea

Email: jhong@etri.re.kr


Tae-Wan You
ETRI
Yuseung-Gu
218 Gajeong-ro
Daejeon
34129
Republic of Korea

Email: twyou@etri.re.kr


Lijun Dong
Futurewei Technologies Inc.
10180 Telesis Court
San Diego, CA 92121
United States of America

Email: lijun.dong@futurewei.com


Cedric Westphal
Futurewei Technologies Inc.
2330 Central Expressway
Santa Clara, CA 95050
United States of America

Email: cedric.westphal@futurewei.com


Börje Ohlman
Ericsson Research
SE-16480 Stockholm
Sweden

Email: Borje.Ohlman@ericsson.com

That's the whole RFC, bestie! 🌈💅

📦 where this page comes from