The Mission to Save the Internet by Rewiring It from the Name Up

For a good analysis of some of the challenges and features in NDN security, I reccomend: http://arxiv.org/pdf/1112.2205

> In Named Data Networking (NDN), packets carry data names instead of source and destination addresses. This paradigm shift leads to a new network forwarding plane: data consumers send Interest packets to request desired data, routers forward Interest packets and maintain the state of all pending Interests, which is then used to guide Data packets back to the consumers. Maintaining the pending Interest state, together with the two-way Interest and Data exchange, enables NDN routers’ forwarding process to measure performance of different paths, quickly detect failures and retry alternative paths. In this paper we describe an initial design of NDN’s forwarding plane and evaluate its data delivery performance under adverse conditions. Our results show that this stateful forwarding plane can successfully circumvent prefix hijackers, avoid failed links, and utilize multiple paths to mitigate congestion. We also compare NDN’s performance with that of IP-based solutions to highlight the advantages of a stateful forwarding plane.

http://named-data.net/wp-content/uploads/comcom-stateful-for...

This challenges the notion that IP's statelessness is one of its core strengths.

https://en.wikipedia.org/wiki/Namecoin

Using a Bitcoin-style blockchain as a name registrar ought to be far less controversial than using it as a value store or a payment system.

Routing and Forwarding

NDN routes and forwards packets on names, which eliminates four problems that addresses pose in the IP architecture: address space exhaustion, NAT traversal, mobility, and address management. There is no address exhaustion problem since the namespace is unbounded. There is no NAT traversal problem since a host does not need to expose its address in order to offer content. Mobility, which requires changing addresses in IP, no longer breaks communication since data names remain the same. Finally, address assignment and management is no longer required in local networks, which is especially empowering for embedded sensor networks.

(...)

Caching

Automatic in-network caching is enabled by naming data. Since each NDN Data packet is meaningful independent of where it comes from or where it may be forwarded to, a router can cache it in its content store to satisfy future requests. Upon receiving a new Interest, the router first checks the Content Store. If there is a data whose name falls under the Interest’s name, the data will be sent back as a response. The Content Store, in its basic form, is just the buffer memory in today’s router. Both IP routers and NDN routers buffer data packets. The difference is that IP routers cannot reuse the data after forwarding them, while NDN routers are able to reuse the data since they are identified by the data names. For static files, NDN achieves almost optimal data delivery. Even dynamic content can benefit from caching in the case of multicast (e.g., teleconferencing) or packet retransmission after a packet loss. Cache management and replacement is subject to ISP policies and is one of our research topics.

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

The NDN architecture does not have a separate transport layer. It moves the functions of today’s transport protocols up into applications, their supporting libraries, and the strategy component in the forwarding plane. Multiplexing and demultiplexing among application processes is done directly using names at the NDN layer, and data integrity and reliability are directly handled by application processes where the appropriate reliability checking, data signing and trust decisions can be made.

An NDN network is designed to operate on top of unreliable packet delivery services, including the highly dynamic connectivity of mobile and ubiquitous computing. To provide reliable delivery, Interest packets that are not satisfied within some reasonable period of time must be retransmitted by the final consumer (the application that originated the initial Interest) if it still wants the data. Such functionality is common to many NDN applications, and is provided by NDN common libraries.

NDN routers manage traffic load through through managing the Interest forwarding rate on a hop-by-hop basis; when a router is overloaded by incoming data traffic from any specific neighbor, it simply slows down or stop sending Interest packets to that neighbor. This also means that NDN eliminates the dependency on end hosts to perform congestion control. Once congestion occurs, data retransmission is aided by caching since the retransmitted Interest will meet the Data right above the link the packet was lost, not the original sender. Thus NDN avoids congestion collapse that can occur in today’s Internet when a packet is lost at the last hop and bandwidth is mostly consumed by repeated retransmissions from the original source host.

Traditional transport services provide point-to-point data delivery and most of today’s distributed applications, including peer-to-peer applications, heavily rely on centralized servers. To aid the development of robust and efficient distributed applications, we envision a fundamentally new building block for distributed systems that we are calling Sync. Built on top of NDN’s basic Interest-Data communication model, Sync utilizes naming conventions to enable multiple parties to synchronize their datasets by exchanging data digests, so that individual parties can discover and retrieve new and missing data in a most efficient and robust manner. We expect that Sync’s role in the NDN architecture will evolve to one similar to TCP’s in the IP architecture.

Qwerty is just a relic from the time of typewriters. It was arranged that way to make sure that the typebars didn't bind even at high typing speeds, so yeah, not really optimized for efficiency.