RFC 9236

Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service

📅 published April 2022, from ietf

Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service 🦋

okay bestie, let's get into RFC 9236 💖 It's an Informational doc (not a standard, just here to share knowledge ✨) from the Internet Research Task Force (IRTF), and it's basically a research crew's big brain moment about ICN. It was written by J. Hong and T. You (both at ETRI) and V. Kafle (NICT), it's dated April 2022, and it's got ISSN 2070-1721 🌈 The title block doesn't list anything it obsoletes or updates, so it's just a standalone vibe 🫶

Abstract ✨

so the whole doc is about the architectural considerations and implications of using a Name Resolution Service (NRS) in Information-Centric Networking (ICN) 🔥 It explains how the ICN architecture can shift when an NRS shows up, and how that changes the ICN routing system. It's a product of the Information-Centric Networking Research Group (ICNRG) 🍓

Status of This Memo 📜

this doc is not an Internet Standards Track spec. It's published for informational purposes, periodt 💅

it's a product of the Internet Research Task Force (IRTF), which publishes results of Internet-related research and development. These results might not be suitable for deployment, so no pressure 🙈 This RFC represents the consensus of the ICNRG. Documents approved by the IRSG are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💀

for the current status, errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9236 🎀

the copyright line says Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please review those carefully, because they describe your rights and restrictions for this document 🧚

Table of Contents 🗂️

   1.  Introduction
   2.  Terminology
   3.  Background
   4.  Implications of an NRS in ICN
   5.  ICN Architectural Considerations for NRS
     5.1.  Name Mapping Records Registration, Resolution, and Update
     5.2.  Protocols and Semantics
     5.3.  Routing System
   6.  Conclusion
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction 🦋

okay so Information-Centric Networking (ICN) is an approach to evolving Internet infrastructure so you can get Named Data Objects (NDOs) directly by their names ✨ In two common ICN architectures, Named Data Networking (NDN) [NDN] and Content-Centric Networking (CCNx) [CCNx], the name of an NDO is used directly to route a request for that data object. It's iconic, but direct name-based routing has real challenges: getting a globally scalable routing system, handling producer mobility, and supporting off-path caching 😭 We dig into these in Section 3. To handle them, a Name Resolution Service (NRS) has shown up in the literature and in the proposals of several ICN projects [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan] 🌸

this doc describes the changes an NRS could cause in the ICN architecture, and the matching implications for the ICN routing system. It also covers ICN architectural considerations for bringing an NRS in. The scope is the ICN architecture and routing system perspective when using an NRS in ICN. The actual description of the NRS lives in the companion NRS design considerations document [RFC9138], which covers NRS approaches, functions, and design considerations 💅

this doc represents the consensus of the Information-Centric Networking Research Group (ICNRG) 🫶 It got a thorough review from RG members who are actively building and researching the tech in here. It's not an IETF product, and it's not a standard ✨

2. Terminology 📚

  • Name Resolution Service (NRS): an NRS in ICN is a service that translates a content name or data object name into some other info, like a routable prefix, a locator, an off-path-cache pointer, or an alias name. That info is more useful than the input name for forwarding the object request toward the target destination storing the NDO [RFC9138]. An NRS is most likely built on a distributed mapping database system. The Domain Name System (DNS) may be used as an NRS. However, in that case you need to think about the frequent NRS record updates that come from lots of new NDOs and changes in where they live in the network 🔥
  • NRS server: an NRS is made up of distributed NRS servers that store mapping records in their databases. NRS servers store and maintain the mapping records, which map a content or object name to some other info used for forwarding the content request or the content itself 🧚
  • NRS resolver: the client-side function of an NRS is called an NRS resolver. It starts name resolution request queries that ultimately lead to resolving the target data objects. NRS resolvers can live on consumer (or client) nodes and/or ICN routers. An NRS resolver may also cache the mapping records it got through name resolution, for later use 💜
  • Name registration: to fill up the NRS, content names and their mapping records must be registered in the NRS system. That's done by a publisher who has access rights to at least one authoritative NRS server, or by a producer who generates named data objects. The records hold the mapping of an object name to info like other alias names, routable prefixes, and locators, which are used for forwarding the content request. So a publisher or producer creates an NRS registration request and sends it to an NRS server. On registration, the NRS server stores (or updates) the name mapping record in its database, then sends an acknowledgement back to the producer or publisher that made the request 🌷
  • Name resolution: name resolution is the main job of the NRS system. It's performed by an NRS resolver, which can be deployed on a consumer node or an ICN router. Resolvers either return a cached mapping record (one whose lifetime hasn't expired) or send a name resolution request toward an NRS server. The NRS server searches its mapping record database for the content name and, if it finds it, retrieves the mapping record and returns it in a name resolution response message to the NRS resolver ✨
  • NRS node: NRS servers are also called NRS nodes, since they maintain the name records. The terms are used interchangeably 🌈
  • NRS client: a node that uses the NRS is called an NRS client. Any node that starts a name registration, resolution, or update procedure is an NRS client. So NRS resolvers, ICN client nodes, ICN routers, or producers can all be NRS clients 🦋

3. Background 🍓

okay so, a pure name-based routing approach in ICN has real challenges with building a globally scalable routing system, handling producer mobility, and supporting off-path caching. To tackle these, an NRS has been used in proposals and literature from several ICN projects, like this:

Routing scalability: in ICN, application names that identify content are meant to be used directly for packet delivery. So ICN routers run a name-based routing protocol to build name-based routing and forwarding tables. Just like the scalability problem in IP routing, if non-aggregatable name prefixes get injected into the Default Route Free Zone (DFZ) of ICN routers, they'd drive uncontrolled growth of the DFZ routing table size 😭 So providing the level of indirection an NRS offers in ICN can be a way to keep the routing table size under control. The NRS system resolves name prefixes that don't exist in the DFZ forwarding table into globally routable prefixes, like the one proposed in NDN [Afanasyev]. Another approach to routing scalability is the Multi-level Distributed Hash Table (MDHT) used in NetInf [Dannewitz]. It provides name-based anycast routing that can support a non-hierarchical namespace and can be adopted on a global scale [Dannewitz2] 💖

Producer mobility: in ICN, if a producer moves into a different name domain that uses a different name prefix, the request for content that producer made with the original content name has to be forwarded to the moving producer's new location. Producer mobility is way harder in a hierarchical naming scheme than in a flat one, because the routing tables across a broader area need updating to track the producer's movement 🙈 That's why ICN architectures like NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS systems to deal with producers whose location changes ✨

Off-path caching: in-network caching is a common feature of an ICN architecture. Caching can be sorted into on-path caching and off-path caching, depending on where the caches sit relative to the forwarding path from the original content store to a consumer. Off-path caching, sometimes called content replication or content storing, aims to replicate a Named Data Object in various locations within a network to boost content availability, cut access latency, or both 🌸 Those caching spots may not be along the content forwarding path. So finding off-path cached content needs more complex forwarding procedures if you're using pure name-based routing. To support access to off-path caches, the replica locations are usually advertised into a name-based routing system or into an NRS, as described in [Bayhan] 🧚

this doc discusses the architectural considerations and implications of ICN when an NRS is used to solve these name-based routing challenges in ICN 🎀

4. Implications of an NRS in ICN ✨

okay so an NRS is not a mandatory part of an ICN architecture 🫶 most ICN architectures use name-based routing, which means they skip the whole name resolution step. so bringing an NRS in actually changes some architectural stuff, especially around forwarding procedures, latency, and security. let's go through it 💅

Forwarding procedure: once you add an NRS, the name resolution procedure has to be part of the overall ICN routing and forwarding architecture. to plug an NRS in, you need to decide and specify where, when, and how the name resolution task happens. so many decisions, bestie 😭

Latency: an NRS adds latency from the name resolution process, and the routing and forwarding system is the one that takes that hit 🐢 but here's the plot twist 🦋 the total latency for individual requests could still go down, as long as the NRS lookup can find the nearest copies or off-path caches. there might also be a favorable trade-off between name resolution latency and reduced inter-domain traffic, since finding the nearest off-path cached copy of the content saves a lot of traffic. finding the nearest cache can seriously cut down both content discovery and content delivery latency. iconic 🌸

Security: every new component you add, like an NRS, can make the attack surface bigger ⚠️ protecting the NRS system itself is tricky. it may be challenging to defend against attacks like Distributed Denial of Service (DDoS), and against spoofing or alteration of name mapping records and related signaling messages. this is the part where we all need to be extra careful 😬

5. ICN Architectural Considerations for NRS

this section is all about the stuff ICN architecture folks can think about when they're running an NRS system 🎀 it covers the things related to registration, resolution, and update of name mapping records, the protocols and messages, and how everything integrates with the routing system.

5.1. Name Mapping Records Registration, Resolution, and Update

when an NRS is part of an ICN architecture, you have to think about the functions for registering, resolving, and updating name mapping records 📋 the NRS nodes keep track of those records, and they may exist as an overlay network sitting on top of the ICN routers. so the NRS nodes talk to each other by going through ICN routers 🌈 Figure 1 shows NRS nodes and NRS clients connected through an underlying network. the NRS nodes should be placed so that an NRS node is always a short distance away from an NRS client, which keeps the communication latency for name registration and resolution requested by the NRS client super low ✨ the registration, resolution, and record update procedures are quickly covered below.

              +------------+             +------------+
              |  NRS Node  |             |  NRS Node  |
              +------------+             +------------+
                    |                          |
                    |                          |
 +------------+     |                          |     +------------+
 | NRS Client |--------------------------------------| NRS Client |
 +------------+         underlying network           +------------+

      Figure 1: NRS Nodes and NRS Clients Connected through an
                         Underlying Network

Name registration: the producer does the name registration (as an NRS client) when it creates new content 🎨 when a producer creates content and gives it a name from its name prefix space, the producer registers that name with an NRS node. name registration may also be done by an ICN router when the architecture supports off-path caching or cooperative caching, because involving an NRS is a good idea for off-path caching 🧚 ICN routers with forwarder caches don't need to register their cached content, since they sit on the path toward an upstream content store or producer. they'll get hit when a future request is forwarded to the content producer by an ICN router downstream toward the ICN client node. however, ICN routers doing off-path caching of content must invoke the name registration procedure, so other ICN routers can rely on name resolutions to find out about the off-path cache locations. if content gets cached in lots of off-path ICN routers, they might all register the same content names with the same NRS node, which means multiple registration actions 🙈 in that case, the NRS node adds the new location of the content to the name record along with the previous locations. so each name record stored in the NRS node can hold multiple locations of the content. assigning a validity time or a lifetime to each mapping record may be considered, especially for off-path caching content and for managing mobility ⏳

Name resolution: name resolution is done by an NRS client to get the name record from an NRS node. the client sends a name resolution request message and gets back a response containing the record 📨 in the name-based ICN routing context, name resolution is needed by any ICN router whose forwarding information base (FIB) doesn't contain the requested name prefix. name resolution may also be done by the consumer (especially when the consumer is multihomed) to send the content request in a better direction, so it can grab the content from the nearest cache 🏃‍♀️ if the consumer is single homed, it may not bother with name resolution, and instead depends on either straightforward name-based routing or name resolution by an upstream ICN router. in this case, the consumer creates the content request packet containing the content name and forwards it to the nearest ICN router. the ICN router checks its FIB table to see where to forward the content request. if the ICN router can't work out whether the requested content is reachable, it performs name resolution to get the name mapping record and adds that info to its FIB 🗺️ the ICN router may also do name resolution even before a content request shows up, using the name mapping record to set up its FIB. very proactive of it 👑

Name record update: a name record update happens when a content name mapping record changes, for example when the content isn't available in one or more of the previous locations 🔄 the update includes substituting and deleting name mapping records. the update may happen explicitly through the exchange of name record update messages, or implicitly when a timeout occurs and a name record is considered invalid ⏰ implicit updates are possible when each record comes with a lifetime value. only the authoritative producer or node can renew the lifetime 🔐 cached mapping records get erased once the lifetime expires, unless a lifetime extension indication is received from the authoritative producer.

5.2. Protocols and Semantics

to build an NRS system inside a local ICN network domain or a global ICN network domain, new protocols and semantics must be designed and implemented, so names can be managed and resolved across different namespaces 🧩

one way to implement an NRS for CCNx is by extending the basic TLV format and semantics [RFC8569] [RFC8609] 💕 for example, name resolution and response messages can be implemented by defining new type fields in the Interest and Content Object messages [CCNxNRS]. by reusing the existing CCNx Interest and Content Object packets for name resolution and registration, the NRS system can be deployed with only a few ICN protocol changes 🥰 but since the changes are confined to the basic ICN protocol and semantics, the NRS system may not be able to take advantage of more flexible and scalable designs. the glow-up has limits, periodt 🙃

on the other hand, an NRS system can be designed independently, with its own protocol and semantics, like the NRS system described in [Hong] 🦄 for instance, the NRS protocol and messages can be implemented using a RESTful API, and the NRS can run as an application protocol that's independent of the rest of the ICN protocol.

5.3. Routing System

an NRS reduces the routing complexity of an ICN architecture compared to pure name-based routing 🧠 it does this by letting the routing system update its routing table on demand, using name records obtained from the NRS. so the routing system needs to make name resolution requests and process the information it gets back, such as a prefix, a locator, an off-path-cache pointer, or an alias name 💜

no matter what kind of information comes back from name resolution, as long as it's in the form of a name, the content request message in the routing system may be reformatted with that information 🎀 in this case, the content name originally requested by a consumer needs to be included in the reformatted content request, so the integrity of the binding between the name and the requested content can be checked 🔍 in other words, the information from name resolution is used to forward the content request, while the original content name is used to identify the content. alternatively, the resolved information may be used to build the routing table 🗂️

the information from name resolution may not be in the form of a name, though. for example, it may identify tunnel endpoints by IP address, and then be used to construct an IP protocol tunnel to forward the content request through 🚇

6. Conclusion

okay bestie, the big takeaway: a Name Resolution Service (NRS) is not a mandatory part of an ICN architecture, because most ICN architectures use name-based routing without any name resolution procedure 🌸 but pure name-based routing has real challenges, like enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching 😤 to tackle those, an NRS system has shown up in several ICN projects ✨ so this document describes how the ICN architecture changes when an NRS is used, and how that affects the ICN routing system 🦋

the document defines a few terms related to an NRS, and explains the inherent challenges of pure name-based routing in ICN, such as routing scalability, producer mobility, and off-path caching 💅 it walks through how the ICN architecture would change in terms of procedures, latency, and security when an NRS is used. then, based on those architectural changes, it lays out ICN architectural considerations for NRS: the functions for registering, resolving, and updating name mapping records, the protocols and semantics for implementing an NRS system, and the routing system that involves name resolution 🫶

7. IANA Considerations

this document has no IANA actions 🌈

8. Security Considerations 🔥

okay bestie, security is where things get spicy 🌶️ every time we add a new piece like an NRS to the ICN architecture, the attack surface gets bigger, so we have to look at the risks one by one 👀

Namespace security: to deploy an NRS system in ICN, the ICN namespaces (which might be handed out by authoritative entities) must be securely mapped to the content publishers and securely managed by them 🔐 according to the ICN research challenges [RFC7927], a new namespace can also give you an integrity verification function that authenticates its publisher ✨ namespace authentication and mapping between different namespaces still need more investigation 🧐

NRS system security: an NRS needs new entities (like NRS servers) to build distributed and scalable NRS systems 🏗️ that also means those entities, like an NRS server keeping a mapping database, could become the main target of attacks, with tons of malicious requests from countless adversaries doing Denial-of-Service or Distributed-Denial-of-Service attacks 😱 on top of that, NRS clients generally must trust the NRS nodes in other network domains to some degree, and the communication between them must also be protected securely so malicious entities can't crash the party 🚫 and the history of name resolution data needs to be stored and analyzed, kinda like passive DNS, so we can uncover security incidents or find malicious infrastructure 🕵️‍♀️

NRS protocol and message security: the protocols that generate, transmit, and receive NRS messages for name registration, resolution, and record update should be protected by proper security mechanisms 💜 proper security measures must be provided so that only legitimate nodes can initiate and read NRS messages 🙅‍♀️ these messages must be secured with integrity protection and authentication, so unauthorized parties can't mess with them while they're being forwarded through the network 🛡️ security measures to encrypt these messages should also be developed to stop threats to both security and privacy 🤫 honestly, lots of problems that look like the security issues of IP networks and DNS can affect the whole ICN architecture 😭 the DNS QNAME minimization type of approach would be a good fit for keeping privacy during name resolution 🎀 so security mechanisms like accessibility, authentication, and so on for the NRS system [RFC9138] should be considered, to protect not just the NRS system but the whole ICN architecture too 💅

9. References 📚

9.1. Normative References

9.2. Informative References

  • [Afanasyev] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, "SNAMP: Secure namespace mapping to scale NDN forwarding", 2015 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2015.7179398, April 2015, https://doi.org/10.1109/INFCOMW.2015.7179398.
  • [Bayhan] Bayhan, S., Ott, J., Kangasharju, J., Sathiaseelan, A., and J. Crowcroft, "On Content Indexing for Off-Path Caching in Information-Centric Networks", ACM ICN, DOI 10.1145/2984356.2984372, September 2016, https://doi.org/10.1145/2984356.2984372.
  • [CCNx] "Cicn", https://wiki.fd.io/view/Cicn.
  • [CCNxNRS] Hong, J., You, T., and Y. Hong, "CCNx Extension for Name Resolution Service", Work in Progress, Internet-Draft, draft-hong-icnrg-ccnx-nrs-02, 2 July 2018, https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02.
  • [Dannewitz] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and H. Karl, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, https://doi.org/10.1016/j.comcom.2013.01.009.
  • [Dannewitz2] Dannewitz, C., D'Ambrosio, M., and V. Vercellone, "Hierarchical DHT-based name resolution for information-centric networks", Computer Communications vol. 36, issue 7, DOI 10.1016/j.comcom.2013.01.014, April 2013, https://doi.org/10.1016/j.comcom.2013.01.014.
  • [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable Name Resolution System for Information-Centric Networking", ACM ICN, DOI 10.1145/2810156.2812617, September 2015, https://doi.org/10.1145/2810156.2812617.
  • [MF] Future Internet Architecture (FIA), "MobilityFirst", http://mobilityfirst.cs.umass.edu/.
  • [NDN] NDN, "Named Data Networking", September 2010, https://www.named-data.net.
  • [Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding Label support in CCN Protocol", Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02.
  • [SAIL] "Scalable and Adaptive Internet Solutions (SAIL)", https://www.sail-project.eu/.
  • [Zhang2] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A Survey of Mobility Support in Named Data Networking", Named Data Networking, Workshop on Name-Oriented Mobility: Architecture, Algorithms and Applications (NOM), April 2016.

Acknowledgements 🫶

the authors want to give a huge shoutout to Dave Oran (ICNRG Co-chair) 👑 his super useful reviews and comments helped make this document so much better 💖

Authors' Addresses 🦋

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

Ved Kafle
NICT
Koganei
4-2-1 Nukui-Kitamachi, Tokyo
184-8795
Japan
Email: kafle@nict.go.jp
📦 where this page comes from