The Named Data Networking Consortium launched on September 3, 2014! (Important changes to be baked into Internet infrastructure. Read carefully.)
In case you haven’t heard:
Named Data Networking (NDN) is a Future Internet Architecture inspired by years of empirical research into network usage and a growing awareness of persistently unsolved problems of the current Internet (IP) architecture. Its central premise is that the Internet is primarily used as an information distribution network, a use that 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.
This project continues research on NDN started in 2010 under NSF’s FIA program. It applies the project team’s increasingly sophisticated understanding of NDN’s opportunities and challenges to two national priorities–Health IT and Cyberphysical Systems–to further the evolution of the architecture in the experimental, application-driven manner that proved successful in the first three years. In particular, our research agenda is organized to translate important results in architecture and security into library code that guides development for these environments and other key applications toward native NDN designs. It simultaneously continues fundamental research into the challenges of global scalability and broad opportunities for architectural innovation opened up by “simply” routing and forwarding data based on names.
Our research agenda includes: (1) Application design, exploring naming and application design patterns, support for rendezvous, discovery and bootstrapping, the role and design of in-network storage, and use of new data synchronization primitives; (2) Security and trustworthiness, providing basic building blocks of key management, trust management, and encryption-based access control for the new network, as well as anticipating and mitigating future security challenges faced in broad deployment; (3) Routing and forwarding strategy, developing and evaluating path-vector, link-state, and hyperbolic options for inter-domain routing, creating overall approaches to routing security and trust, as well as designing flexible forwarding and mobility support; (4) Scalable forwarding, aiming to support real-world deployment, evaluation and adoption via an operational, scalable forwarding platform; (5) Library and tool development, developing reference implementations for client APIs, trust and security, and new network primitives based on the team’s fundamental results, as well as supporting internal prototype development and external community efforts; (6) Social and economic impacts, considering the specific questions faced in our network environments as well as broader questions that arise in considering a “World on NDN.”
We choose Mobile Health and Enterprise Building Automation and Management Systems as specific instances of Health IT and Cyberphysical Systems to validate the architecture as well as drive new research. Domain experts for the former will be the Open mHealth team, a non-profit patient-centric ecosystem for mHealth, led by Deborah Estrin (Cornell) and Ida Sim (UCSF). For the latter, our experts will be UCLA Facilities Management, operators of the second largest Siemens building monitoring system on the West Coast. To guide our research on the security dimensions of these important environments and the NDN architecture more generally, we have convened a Security Advisory Council (NDN-SAC) to complement our own security and trust effort.
The NDN architecture builds on lessons learned from the success of the IP architecture, preserving principles of the thin waist, hierarchical names, and the end-to-end principle. The design reflects a recognition of the major shift in the applications communication model: from the “where” (i.e., the host/location) to the “what” (i.e., the content). Architecting a communications infrastructure around this shift can radically simplify application designs to allow applications to communicate directly using the name of the content they desire and leave to the network to figure out how and where to retrieve it. NDN also recognizes that the biggest weakness in the current Internet architecture is lack of security, and incorporates a fundamental building block to improve security by requiring that all content be cryptographically signed.
Truly an impressive effort and one that will be exciting to watch!
You may want to start with: Named Data Networking: Motivation & Details as an introduction.
One of the features of NDN is that named data can be cached and delivered by a router separate from its point of origin. Any user can request the named data and the caching router only knows that it has been requested. Or in the words of the Motivation document:
Caching named data may raise privacy concerns. Today’s IP networks offer weak privacy protection. One can find out what is in an IP packet by inspecting the header or payload, and who requested the data by checking the destination address. NDN explicitly names the data, arguably making it easier for a network monitor to see what data is being requested. One may also be able to learn what data is requested through clever probing schemes to derive what is in the cache. However NDN removes entirely the information regarding who is requesting the data. Unless directly connected to the requesting host by a point-to-point link, a router will only know that someone has requested certain data, but will not know who originated the request. Thus the NDN architecture naturally offers privacy protection at a fundamentally different level than the current IP networks.
Which sounds attractive, until you notice that the earlier quote ends saying:
and incorporates a fundamental building block to improve security by requiring that all content be cryptographically signed (emphasis added)
If I am interpreting the current NDN statements correctly, routers will not accept or transport un-cryptographically signed data packets.
Cryptographic signing of data packets, depending upon its requirements, will eliminate anonymous hosting of data. Think about that for a moment. What data might not be made public if its transmission makes its originator identifiable?
Lots of spam no doubt but also documents such as the recent Snowden leaks and other information flow embarrassing to governments.
Or to those who do not sow but who seek to harvest such as the RIAA.
NDN is in the early stages, which is the best time to raise privacy, fair use and similar issues in its design.