Wikipedia

Named data networking

Named Data Networking (NDN) (related to content-centric networking (CCN), content-based networking, data-oriented networking or information-centric networking (ICN)) is a proposed Future Internet architecture that seeks to address problems in contemporary internet architectures like IP.[1][2] NDN has its roots in an earlier project, Content-Centric Networking (CCN), which Van Jacobson first publicly presented in 2006. The NDN project is investigating Jacobson's proposed evolution from today's host-centric network architecture IP to a data-centric network architecture (NDN). The stated goal of this project is that with a conceptually simple shift, far-reaching implications for how people design, develop, deploy, and use networks and applications could be realized.[3]

NDN has three core concepts that distinguish NDN from other network architectures. First, applications name data and data names will directly be used in network packet forwarding; consumer applications would request desired data by its name, so communications in NDN are consumer-driven. Second, NDN communications are secured in a data-centric manner wherein each piece of data (called a Data packet) will be cryptographically signed by its producer and sensitive payload or name components can also be encrypted for the purpose of privacy. In this way, consumers can verify the packet regardless of how the packet is fetched. Third, NDN adopts a stateful forwarding plane where forwarders will keep a state for each data request (called an Interest packet), and erase the state when a corresponding data packet comes back. NDN's stateful forwarding allows intelligent forwarding strategies, and eliminates loops.

Its premise is that the Internet is primarily used as an information distribution network, which is not a good match for IP, and that the future Internet's "thin waist" should be based on named data rather than numerically addressed hosts. The underlying principle is that a communication network should allow a user to focus on the data they need, named content, rather than having to reference a specific, physical location where that data is to be retrieved from, named hosts. The motivation for this is derived from the fact that the vast majority of current Internet usage (a "high 90% level of traffic") consists of data being disseminated from a source to a number of users.[4] Named-data networking comes with potential for a wide range of benefits such as content caching to reduce congestion and improve delivery speed, simpler configuration of network devices, and building security into the network at the data level.

Overview

edit

Today's Internet's hourglass architecture centers on a universal network layer, IP, which implements the minimal functionality necessary for global inter-connectivity. The contemporary Internet architecture revolves around a host-based conversation model, which was created in the 1970s to allow geographically distributed users to use a few big, immobile computers.[5] This thin waist enabled the Internet's explosive growth by allowing both lower and upper layer technologies to innovate independently. However, IP was designed to create a communication network, where packets named only communication endpoints.


Sustained growth in e-commerce, digital media, social networking, and smartphone applications has led to dominant use of the Internet as a distribution network. Distribution networks are more general than communication networks, and solving distribution problems via a point-to-point communication protocol is complex and error-prone.

The Named Data Networking (NDN) project proposed an evolution of the IP architecture that generalizes the role of this thin waist, such that packets can name objects other than communication endpoints. More specifically, NDN changes the semantics of network service from delivering the packet to a given destination address to fetching data identified by a given name. The name in an NDN packet can name anything – an endpoint, a data chunk in a movie or a book, a command to turn on some lights, etc. The hope is that this conceptually simple change allows NDN networks to apply almost all of the Internet's well-tested engineering properties to a broader range of problems beyond end-to-end communications.[6] Examples of NDN applying lessons learned from 30 years of networking engineering are that self-regulation of network traffic (via flow balance between Interest (data request) and data packets), and security primitives (via signatures on all named data) are integrated into the protocol from the start.

History

edit

Early research

edit

The philosophy behind NDN was pioneered by Ted Nelson in 1979, and later by Brent Baccala in 2002. In 1999, the TRIAD project at Stanford proposed avoiding DNS lookups by using the name of an object to route towards a close replica of it. In 2006, the Data-Oriented Network Architecture (DONA) project at UC Berkeley and ICSI proposed a content-centric network architecture, which improved TRIAD by incorporating security (authenticity) and persistence as first-class primitives in the architecture. Van Jacobson gave a Google Talk, A New Way to Look at Networking, in 2006 on the evolution of the network, and argued that NDN was the next step. In 2009, PARC announced their content-centric architecture within the CCNx project, which was led by Jacobson who was a research fellow at PARC at the time. On 21 September 2009, PARC published the specifications for interoperability and released an initial open source implementation (under GPL) of the Content-Centric Networking research project on the Project CCNx site. NDN is one instance of a more general network research direction called information-centric networking (ICN), under which different architecture designs have emerged.[7] The Internet Research Task Force (IRTF) established an ICN research working group in 2012.

Current state

edit

NDN includes sixteen NSF-funded principal investigators at twelve campuses, and growing interest from the academic and industrial research communities.[8][9] More than 30 institutions form a global testbed. There exists a large body of research and an actively growing code base. contributed to NDN.

The NDN forwarder is currently supported on Ubuntu 18.04 and 20.04, Fedora 20+, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+, and several other platforms. Common client libraries are actively supported for C++, Java, Javascript, Python, .NET Framework (C#), and Squirrel programming languages. The NDN-LITE is a lightweight NDN library designed for IoT networks and constrained devices. NDN-LITE is being actively developed and so far, NDN-LITE has been adapted to POSIX, RIOT OS, NRF boards. An NDN simulator and emulator are also available and actively developed. Several client applications are being developed in the areas of real-time conferencing, NDN friendly file systems, chat, file sharing, and IoT.

Key architectural principles

edit
  • End-to-end principle: Enables the development of robust applications in the face of network failures. NDN retains and expands this design principle.
  • Routing and forwarding plane separation: This has proven necessary for Internet development. It allows the forwarding plane to function while the routing system continues to evolve over time. NDN uses the same principle to allow the deployment of NDN with the best available forwarding technology while new routing system research is ongoing.
  • Stateful forwarding: NDN routers keep the state of recently forwarded packets, which allows smart forwarding, loop detection, flow balance, ubiquitous caching, etc.
  • Built-in security: In NDN, data transfer is secured at the network layer by signing and verification of any named data.[10]
  • Enable user choice and competition: The architecture should facilitate user choice and competition where possible. Although not a relevant factor in the original Internet design, global deployment has demonstrated that “architecture is not neutral".[11] NDN makes a conscious effort to empower end users and enable competition.

Architecture overview

edit

Types of packets

edit

Communication in NDN is driven by receivers i.e., data consumers, through the exchange of two types of packets: Interest and Data. Both types of packets carry a name that identifies a piece of data that can be transmitted in one Data packet.

 
Overview of the Packet Contents for NDN Packet

Packet types

  • Interest: A consumer puts the name of a desired piece of data into an Interest packet and sends it to the network. Routers use this name to forward the Interest toward the data producer(s).
  • Data: Once the Interest reaches a node that has the requested data, the node will return a Data packet that contains both the name and the content, together with a signature by the producer's key which binds the two. This Data packet follows in reverse the path taken by the Interest to get back to the requesting consumer.

For the complete specification see NDN Packet Format Specification.

Router architecture

edit

To carry out the Interest and Data packet forwarding functions, each NDN router maintains three data structures, and a forwarding policy:

  • Pending Interest Table (PIT): stores all the Interests that a router has forwarded but not satisfied yet. Each PIT entry records the data name carried in the Interest, together with its incoming and outgoing interface(s).
  • Forwarding Information Base (FIB): a routing table which maps name components to interfaces. The FIB itself is populated by a name-prefix based routing protocol, and can have multiple output interfaces for each prefix.
  • Content Store (CS): a temporary cache of Data packets the router has received. Because an NDN Data packet is meaningful independent of where it comes from or where it is forwarded, it can be cached to satisfy future Interests. Replacement strategy is traditionally least recently used, but the replacement strategy is determined by the router and may differ.
  • Forwarding Strategies: a series of policies and rules about forwarding interest and data packets. Note that the Forwarding Strategy may decide to drop an Interest in certain situations, e.g., if all upstream links are congested or the Interest is suspected to be part of a DoS attack. These strategies use a series of triggers in the forwarding pipeline and are assigned to name prefixes. For instance, by default /localhost uses the Multicast forwarding strategy to forward interests and data to any local application running on a client NFD. The default forwarding strategy (i.e. "/") is the Best Route forwarding strategy.

When an Interest packet arrives, an NDN router first checks the Content Store for matching data; if it exists in the router returns the Data packet on the interface from which the Interest came. Otherwise the router looks up the name in its PIT, and if a matching entry exists, it simply records the incoming interface of this Interest in the PIT entry. In the absence of a matching PIT entry, the router will forward the Interest toward the data producer(s) based on information in the FIB as well as the router's adaptive Forwarding Strategy. When a router receives Interests for the same name from multiple downstream nodes, it forwards only the first one upstream toward the data producer(s).

When a Data packet arrives, an NDN router finds the matching PIT entry and forwards the data to all down-stream interfaces listed in that PIT entry. It then removes that PIT entry, and caches the Data in the Content Store. Data packets always take the reverse path of Interests, and, in the absence of packet losses, one Interest packet results in one Data packet on each link, providing flow balance. To fetch large content objects that comprise multiple packets, Interests provide a similar role in controlling traffic flow as TCP ACKs in today's Internet: a fine-grained feedback loop controlled by the consumer of the data.

Neither Interest nor Data packets carry any host or interface addresses; routers forward Interest packets toward data producers based on the names carried in the packets, and forward Data packets to consumers based on the PIT state information set up by the Interests at each hop. This Interest/Data packet exchange symmetry induces a hop-by-hop control loop (not to be confused with symmetric routing, or with routing at all!), and eliminates the need for any notion of source or destination nodes in data delivery, unlike in IP's end-to-end packet delivery model.

Names

edit

Design

edit

NDN names are opaque to the network. This allows each application to choose the naming scheme that fits its needs, and naming can thus evolve independently from the network.

Structure

edit

The NDN design assumes hierarchically structured names, e.g., a video produced by UCLA may have the name /ucla/videos/demo.mpg, where ‘/’ delineates name components in text representations, similar to URLs. This hierarchical structure has many potential benefits:

  • Relationship specification: allows applications to represent the context and relationships of data elements. EX: segment 3 of version 1 of a UCLA demo video might be named /ucla/videos/demo.mpg/1/3
  • Name aggregation: /ucla could correspond to an autonomous system originating the video
  • Routing: allows the system to scale and aids in providing the necessary context for the data

Specifying a name

edit

To retrieve dynamically generated data, consumers must be able to deterministically construct the name for a desired piece of data without having previously seen the name or the data through either:

  • an algorithm allows the producer and consumer to arrive at the same name based on information available to both.
  • Interest selectors in conjunction with longest prefix matching retrieve the desired data through one or more iterations.

Current research is exploring how applications should choose names that can facilitate both application development and network delivery. The aim of this work is to develop and refine existing principles and guidelines for naming, converting these rules into naming conventions implemented in system libraries to simplify future application development.[12]

Namespaces

edit

Data that may be retrieved globally must have globally unique names, but names used for local communications may require only local routing (or local broadcast) to find matching data. Individual data names can be meaningful in various scopes and contexts, ranging from “the light switch in this room” to “all country names in the world”. Namespace management is not part of the NDN architecture, just as address space management is not part of the IP architecture. However naming is the most important part of NDN application designs. Enabling application developers, and sometimes users, to design their own namespaces for data exchange has several benefits:

  • increasing the closeness of mapping between an application's data and its use of the network.
  • reducing the need for secondary notation (record-keeping to map application configuration to network configuration).
  • expanding the range of abstractions available to the developers.
  • named based content requests also introduces the concerns on privacy leakage. Thanks to separation of namespace management from NDN architecture, it is possible to provide privacy preserving naming scheme by making minor changes in conventional NDN naming scheme.[13]

Routing

edit

Solutions to IP issues

edit

NDN routes and forwards packets based on names, which eliminates three problems caused by addresses in the IP architecture:

  • Address space exhaustion: NDN namespace is essentially unbounded. The namespace is only bounded by the max interest packet size of 8kb and the number of possible unique combinations of characters composing names.
  • NAT traversal: NDN does away with addresses, public or private, so NAT is unnecessary.
  • Address management: address assignment and management is no longer required in local networks.
  • In network multicasting: A producer of data does not need to receive multiple interests for the same data since the PIT entries at downstream forwarders will aggregate interests. The producer receives and responds to a single interest and those forwarding nodes in which multiple incoming interest were received will multicast the data replies to the interfaces those interests were received from.
  • High loss end to end reliability: IP based networks require lost or dropped packets to be retransmitted by the sender. However, in NDN if an interest expires before a data reply reaches the requester the data reply is still cached by forwarders along the return path. The retransmitted interest only needs to reach a forwarder with a cached copy of the data giving NDN based networks higher throughput than IP based networks when packet loss rates are high.

Protocols

edit

NDN can use conventional routing algorithms such as link state and distance vector. Instead of announcing IP prefixes, an NDN router announces name prefixes that cover the data the router is willing to serve. Conventional routing protocols, such as OSPF and BGP, can be adapted to route on name prefixes by treating names as a sequence of opaque components and doing component-wise longest prefix match of a name in an Interest packet against the FIB table.[14] This enables a wide array of inputs to be aggregated in real time and distributed across multiple interface environments simultaneously without compromising content encryption.[15] Key interface analytics are likewise spared by the process. Application transfer and data sharing within the environment are defined by a multi-modal distribution framework, such that the affected cloud relay protocols are unique to the individual runtime identifier.[16]

PIT state

edit

The PIT state at each router supports forwarding across NDN's data plane, recording each pending Interest and the incoming interface(s), and removing the Interest after the matching Data is received or a timeout occurs. This per hop, per packet state differs from IP's stateless data plane. Based on information in the FIB and performance measurements, an adaptive forwarding strategy module in each router makes informed decisions about:

  • Control flow: since each Interest retrieves at most one Data packet, a router can directly control flow by controlling the number of pending interests it keeps.
  • Multicast data delivery: the PIT recording the set of interface on which the same data has arrive, naturally supports this feature.
  • Updating paths to accommodate changes in their view of the network.[17]
  • Delivery: a router can reason about which Interests to forward to which interfaces, how many unsatisfied Interests to allow in the PIT, as well as the relative priority of different Interests.

Interest

edit

If a router decides that the Interest cannot be satisfied, e.g., the upstream link is down, there is no forwarding entry in the FIB, or extreme congestion occurs, the router can send a NACK to its downstream neighbor(s) that transmitted the Interest. Such a Negative Acknowledgment (NACK) may trigger the receiving router to forward the Interest to other interfaces to explore alternate paths. The PIT state enables routers to identify and discard looping packets, allowing them to freely use multiple paths toward the same data producer. Packets cannot loop in NDN, which means there is no need for time-to-live and other measures implemented in IP and related protocols to address these issues.

Security

edit

Overview

edit

In contrast to TCP/IP security (e.g., TLS) which secures communication by securing IP-to-IP channels, NDN secures the data itself by requiring data producers to cryptographically sign every Data packet. The publisher's signature ensures the integrity and enables authentication of data provenance, allowing a consumer's trust in data to be decoupled from how or where it is obtained. NDN also supports fine-grained trust, allowing consumers to reason about whether a public key owner is an acceptable publisher for a specific piece of data in a specific context. The second primary research thrust is designing and developing usable mechanisms to manage user trust. There has been research into 3 different types of trust models:

  • hierarchical trust model: where a key namespace authorizes use of keys. A data packet carrying a public key is effectively a certificate, since it is signed by a third party, and this public key is used to sign specific data.[18]
  • web of trust: to enable secure communication without requiring pre-agreed trust anchors.[19]
  • lightweight trust for IoT: The NDN trust model primarily based on asymmetric cryptography, which is infeasible for resource constraint devices in IoT paradigm.[13]

Application security

edit

NDN's data-centric security has natural applications to content access control and infrastructure security. Applications can encrypt data and distribute keys as named packets using the same named infrastructure to distribute keys, effectively limiting the data security perimeter to the context of a single application. To verify a data packet's signature, an application can fetch the appropriate key, identified in the packet's key locator field, just like any other content. But trust management, i.e., how to determine the authenticity of a given key for a particular packet in a given application, is a primary research challenge. Consistent with an experimental approach, NDN trust management research is driven by application development and use: solving specific problems first and then identifying common patterns. For example, the security needs of NLSR required development of a simple hierarchical trust model, with keys at lower (closer to root) levels, being used to sign keys in higher levels in which keys are published with names that reflect their trust relationship. In this trust model, the namespace matches the hierarchy of trust delegation, i.e., /root/site/operator/ router/process. Publishing keys with a particular name in the hierarchy authorizes them to sign specific data packets and limits their scope. This paradigm can be easily extended to Other applications where real world trust tends to follow a hierarchical pattern, such as in our building management systems (BMS).[20] Since NDN leaves the trust model under the control of each application, more flexible and expressive trust relations, may also be expressed. One such example is ChronoChat,[19] which motivated experimentation with a web-of-trust model. The security model is that a current chatroom participant can introduce a newcomer to others by signing the newcomer's key. Future applications will implement a cross-certifying model (SDSI) [13, 3], which provides more redundancy of verification, allowing data and key names to be independent, which more easily accommodates a variety of real-world trust relationships.

Routing efficiency and security

edit

Furthermore, NDN treats network routing and control messages like all NDN data, requiring signatures. This provides a solid foundation for securing routing protocols against attack, e.g., spoofing and tampering. NDN's use of multipath forwarding, together with the adaptive forwarding strategy module, mitigates prefix hijacking because routers can detect anomalies caused by hijacks and retrieve data through alternate paths.[21] Owing to multi-source, multicast content-delivery nature of Named Data Networking, the random linear coding can improve over all network efficiency.[22] Since NDN packets reference content rather than devices, it is trickier to maliciously target a particular device, although mitigation mechanisms will be needed against other NDN-specific attacks, e.g., Interest flooding DoS.[23][24] Furthermore, having a Pending Interest Table, which keeps state regarding past requests, which can make informed forward decisions about how to handle interest has numerous security advantages:[25]

  • Load Balancing: the number of PIT entries is an indicator of router load; constraining its size limits the effect of a DDoS attack.
  • Interest timeout: PIT entry timeouts offer relatively cheap attack detection, and the arrival interface information in each PIT entry could support a push-back scheme in which down stream routers are informed of unserved interests, which aides in detecting attacks.

See also

edit

References

edit
  1. ^ "NSF Future Internet Architectures (FIA)". nsf.gov. National Science Foundation.
  2. ^ "NSF - Future Internet Architectures". Future Internet Architectures -- Next Phase. National Science Foundation.
  3. ^ Zhang, Lixia; Afanasyev, Alexander; Burke, Jeffrey; Jacobson, Van; claffy, kc; Crowley, Patrick; Papadopoulos, Christos; Wang, Lan; Zhang, Beichuan (28 July 2014). "Named data networking". ACM SIGCOMM Computer Communication Review. 44 (3): 66–73. doi:10.1145/2656877.2656887. S2CID 8317810.
  4. ^ Jacobson, Van. "A New Way to look at Networking". You Tube. Google Talk.
  5. ^ Jacobson, Van; Smetters, Diana K.; Thornton, James D.; Plass, Michael; Briggs, Nick; Braynard, Rebecca (1 January 2012). "Networking named content". Communications of the ACM. 55 (1): 117. doi:10.1145/2063176.2063204. S2CID 52895555.
  6. ^ "Networking: Executive Summary". named-data.net/. Named Data Networking.
  7. ^ Xylomenos, George; Ververidis, Christopher N.; Siris, Vasilios A.; Fotiou, Nikos; Tsilopoulos, Christos; Vasilakos, Xenofon; Katsaros, Konstantinos V.; Polyzos, George C. (2014). "A Survey of Information-Centric Networking Research". IEEE Communications Surveys & Tutorials. 16 (2): 1024–1049. CiteSeerX 10.1.1.352.2228. doi:10.1109/SURV.2013.070813.00063. S2CID 6645760.
  8. ^ "Named Data Networking: Next-Phase Participants". named-data.net. Named Data Networking.
  9. ^ Kisliuk, Bill (3 September 2015). "UCLA-led consortium to focus on developing a new architecture for the Internet". UCLA Newsroom. No. SCIENCE + TECHNOLOGY. University of California, Los Angeles. University of California, Los Angeles.
  10. ^ Smetters, Diana; Jacobson, Van. Securing Network Content (PDF) (Technical report).
  11. ^ Clark, D.D.; Wroclawski, J.; Sollins, K.R.; Braden, R. (2005). "Tussle in cyberspace: defining tomorrow's Internet". IEEE/ACM Transactions on Networking. 13 (3): 462–475. CiteSeerX 10.1.1.163.3356. doi:10.1109/TNET.2005.850224. S2CID 47081087.
  12. ^ Moiseenko, Illya; Zhang, Lixia (August 25, 2014). "Consumer-Producer API for Named Data Networking". NDN Technical Reports.
  13. ^ a b Bilal, Muhammad; et al. (2020). "Secure Distribution of Protected Content in Information-Centric Networking". IEEE Systems Journal. 14 (2): 1921–1932. arXiv:1907.11717. Bibcode:2020ISysJ..14.1921B. doi:10.1109/JSYST.2019.2931813. S2CID 198967720.
  14. ^ Zhang; et al. (2014). "Named data networking". ACM SIGCOMM Computer Communication Review. 44 (3): 66–73. doi:10.1145/2656877.2656887. S2CID 8317810.
  15. ^ Ghali; et al. (2014). "Needle in a haystack: Mitigating content poisoning in named-data networking". Proceedings of NDSS Workshop on Security of Emerging Networking Technologies. doi:10.14722/sent.2014.23014. ISBN 978-1-891562-36-5.
  16. ^ Zhu, Z (2013). "Let's ChronoSync: Decentralized dataset state synchronization in Named Data Networking". 2013 21st IEEE International Conference on Network Protocols (ICNP). pp. 1–10. doi:10.1109/ICNP.2013.6733578. ISBN 978-1-4799-1270-4. S2CID 14086875.
  17. ^ Yi, Cheng; Afanasyev, Alexander; Wang, Lan; Zhang, Beichuan; Zhang, Lixia (26 June 2012). "Adaptive forwarding in named data networking". ACM SIGCOMM Computer Communication Review. 42 (3): 62. CiteSeerX 10.1.1.251.2724. doi:10.1145/2317307.2317319. S2CID 8598344.
  18. ^ Jacobson, Van; Smetters, Dian K.; Thornto, Jams D.; Plass, Micael F.; Briggs, Nichoas H.; Braynard, Rebecca L. (2009-12-01). "Networking named content". Proceedings of the 5th international conference on Emerging networking experiments and technologies. pp. 1–12. CiteSeerX 10.1.1.642.2386. doi:10.1145/1658939.1658941. ISBN 9781605586366. S2CID 220961152.
  19. ^ a b Zhu, Zhenkai; Bian, Chaoyi; Afanasyev, Alexander; Jacobson, Van; Zhang, Lixia (October 10, 2012). "Chronos: Serverless Multi-User Chat Over NDN" (PDF). NDN Technical Reports.
  20. ^ Shang, Wentao; Ding, Qiuhan; Marianantoni, A.; Burke, J; Zhang, Lixia (26 June 2014). "Securing building management systems using named data networking". IEEE Network. 28 (3): 50–56. doi:10.1109/MNET.2014.6843232. S2CID 8859671.
  21. ^ Yi, Cheng; Afanasyev, Alexander; Moiseenko, Ilya; Wang, Lan; Zhang, Beichuan; Zhang, Lixia (2013). "A case for stateful forwarding plane". Computer Communications. 36 (7): 779–791. CiteSeerX 10.1.1.309.1500. doi:10.1016/j.comcom.2013.01.005.
  22. ^ Bilal, Muhammad; et al. (2019). "Network-Coding Approach for Information-Centric Networking". IEEE Systems Journal. 13 (2): 1376–1385. arXiv:1808.00348. Bibcode:2019ISysJ..13.1376B. doi:10.1109/JSYST.2018.2862913. S2CID 51894197.
  23. ^ Afanasyev, Alexander; Mahadevan, Priya; Moiseenko, Ilya; Uzun, Ersin; Zhang, Lixia (2013). "Interest Flooding Attack and Countermeasures in Named Data Networking" (PDF). IFIP.
  24. ^ Wählisch, Matthias; Schmidt, Thomas C.; Vahlenkamp, Markus (2013). "Backscatter from the Data Plane -- Threats to Stability and Security in Information-Centric Network Infrastructure" (PDF). Computer Networks. 57 (16): 3192–3206. arXiv:1205.4778. doi:10.1016/j.comnet.2013.07.009. S2CID 5767511.
  25. ^ Afanasyev, Alexander; Mahadevan, Priya; Moiseenko, Ilya; Uzun, Ersin; Zhang, Lixia (2013). "Interest Flooding Attack and Countermeasures in Named Data Networking" (PDF). IFIP.
edit
Retrieved from "https://en.wiki.x.io/w/index.php?title=Named_data_networking&oldid=1231301199"