Named data networking

History

Early research

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. The Internet Research Task Force (IRTF) established an ICN research working group in 2012.

Current state

NDN includes sixteen NSF-funded principal investigators at twelve campuses, and growing interest from the academic and industrial research communities. 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

• 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.
• 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". NDN makes a conscious effort to empower end users and enable competition.

Architecture overview

Types of packets

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.

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

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

Design

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

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

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.

Namespaces

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.

Routing

Solutions to IP issues

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

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. This enables a wide array of inputs to be aggregated in real time and distributed across multiple interface environments simultaneously without compromising content encryption. 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.

PIT state

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.
• 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

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

Overview

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.
• web of trust: to enable secure communication without requiring pre-agreed trust anchors.
• lightweight trust for IoT: The NDN trust model primarily based on asymmetric cryptography, which is infeasible for resource constraint devices in IoT paradigm.

Application security

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). 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, 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

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. Owing to multi-source, multicast content-delivery nature of Named Data Networking, the random linear coding can improve over all network efficiency. 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. 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:

• 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.