[This post is a repost from https://yoursunny.com/t/2017/tunnel-Ethernet-over-NDN/ written by NDN developer Junxiao Shi]
Named Data Networking (NDN) is a common network protocol for all applications and network environment. NDN’s network layer protocol runs on top of a best-effort packet delivery service, which includes physical channels such as Ethernet wires, and logical connections such as UDP or TCP tunnels over the existing Internet. Using this underlying connectivity, NDN provides a content retrieval service, which allows applications to fetch uniquely named “Data packets” each carrying a piece of data. The “data” could be practically anything: text file chunks, video frames, temperature sensor readings … they are all data. Likewise, a packet in a lower layer network protocol, such as an Ethernet frame, is also a piece of data. Therefore, it should be possible to encapsulate Ethernet traffic into NDN Data packets, and establish a Virtual Private Network (VPN) through NDN communication. This post describes the architecture of a proof-of-concept Ethernet-over-NDN tunneling program, and shows a simple performance benchmark over the real world Internet.
tap-tunnel creates an Ethernet tunnel between two nodes using NDN communication. Each node runs an instance of tap-tunnel.
This program collects packets sent into a TAP interface, and turn them into NDN packets. It then gains NDN connectivity by connecting to the local NDN Forwarding Daemon (NFD). The diagram below shows the overall architecture: Read More
An article from Networld World reads: Largest DDoS attack ever delivered by botnet of hijacked IoT devices details the recent event.
A 600+Gbps DDoS attack from IoT devices is truly remarkable. Moreover, it was not a reflection attack! The target was protected by Akamai, who had to drop them (it was hosted pro-bono) after a few days of sustained attack because it was costing too much.
There are a few elements that might make this event a game changer:
- from now on, people may want to always talk about security in IoT,
- it raises questions about protecting the little guy from DDoS, the customer here found a home at Google’s Project Shield, but obviously this is not scalable, and
- cloud protection from DDoS is not a general solution despite what cloud providers will have you believe.
To me such events bring to focus the weaknesses and fragility of the IP architecture. With billions of IoT devices projected in the future, even one packet/second (or even per minute) from a fraction of these devices would be enough to cause real damage. We all know about the code quality and ease of patching of IoT devices, this will not change.
Maybe Bruce Schneier’s near-apocalyptic thoughts are not too far off.
The NDN team recently published its perspective on intellectual property rights in ICN core protocols, to address questions we are regularly asked by the ICN community and related industries, and to contribute to the “harmonization” dialogue underway in the ICNRG. Feedback and comments are welcome on the ndn-interest mailing list or by other means!
[This post is a repost from https://yoursunny.com/t/2016/ndncert/ written by NDN developer Junxiao Shi]
To publish contents into a Named Data Networking (NDN) backbone network, you need to connect your NFD end host to the NDN Testbed, run a local producer application, and let the world reach your NFD through Automatic Prefix Propagation. However, a limitation with NDN Forwarding Daemon (NFD)’s Automatic Prefix Propagation is that, the prefix registered toward your end host is always the identity name of your certificate. While this works fine when you only have one or two machines, two problems arise when you want to deploy multiple end hosts:
- Every certificate request needs an email verification and manual approval process, which is inconvenient. Or, you can copy your certificate and private key onto every machine, but in case any of these machines is compromised, your one and only private key will be exposed.
- Certificates requested with the same email address have the same “identity name” and hence Automatic Prefix Propagation would register the same prefix. Unless all your machines serve the same contents, registering the same prefix toward all machines hurts network performance because the router has to rely on flooding and probing to figure out which of your machines serves a certain piece of content.
[This post is a repost from https://yoursunny.com/t/2016/nfd-prefix/ written by NDN developer Junxiao Shi]
Named Data Networking (NDN) is a potential future Internet architecture designed as a distribution network. My last post on yoursunny.com described how to connect an end host running NDN Forwarding Daemon (NFD) to the NDN Testbed, a backbone NDN network for research purposes, and retrieve contents from that network. An equally important topic is: how can you publish contents into the backbone network?
As mentioned in the last post, NDN communication is receiver driven. Interests expressed by the consumer application are forwarded toward the producer following the routing table, and Data packets carrying contents flow back on the reverse path of Interests. Every end host and router along the path between consumer and producer needs to have a route in its routing table, so that NFD can forward the Interest, hop by hop, toward the producer. On your own machine, nfdc register command adds a route to the routing table; however, if you want to publish contents into the backbone network and make them available for others to retrieve, you won’t be able to directly execute nfdc register command on a terminal of the routers. How can you add a route without console access?
We recently published our annual report covering our activities from May 2015 through April 2016. For the entire report see http://named-data.net/wp-content/uploads/2016/06/ndn-ar2016.pdf:
V. Jacobson, J. Burke, L. Zhang, T. Abdelzaher, B. Zhang, k. claffy, P. Crowley, J. Halderman, C. Papadopoulos, and L. Wang, “Named Data Networking Next Phase (NDN-NP) Project May 2015 – April 2016 Annual Report”, Tech. rep., Named Data Networking (NDN), Jun 2016.
This report summarizes our accomplishments during the second year of the Named Data Networking Next Phase (NDN-NP) project (the 5th year of the overall project. This phase of the project focuses on deploying and evaluating the NDN architecture in four environments: building automation management systems, mobile health, multimedia real-time conferencing tools, and scientific data applications. Implementation and testing of pilot applications in these network environments further demonstrated our research progress in namespace design, trust management, and encryption-based access control. Highlights from this year include:
The report for the Second NDN Community Meeting (NDNcomm 2015) is available online now. The meeting, held at UCLA in Los Angeles, California on September 28-29, 2015, provided a platform for attendees from 63 institutions across 13 countries to exchange recent NDN research and development results, to debate existing and proposed functionality in NDN forwarding, routing, and security, and to provide feedback to the NDN architecture design evolution.
[The workshop was partially supported by the National Science Foundation CNS-1345286, CNS-1345318, and CNS-1457074. We thank the NDNcomm Program Committee members for their effort of putting together an excellent program. We thank all participants for their insights and feedback at the workshop.]