Updates

Named Data Networking (NDN) Project Newsletter for September 2016

The NDN project team compiles and publishes this newsletter monthly to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog.

Community Outreach

  • Call for proposals: The 3rd Named Data Networking (NDN) Hackathon November 4-5th, Colorado State University, Fort Collins, CO Submission deadline: October 26, 2016 Acceptance notification: October 31, 2016
  • As part of ICN 2016, the NDN Team presented a full-day tutorial on “Exploring NDN Research through Real World Problem Solving” at the 3rd ACM Conference on Information Centric Networking (ICN 2016).
  • Coming up in December 2016, adjacent to IEEE Globecom 2016 at the Workshop on Information Centric Networking Solutions for Real World Applications (ICNSRA 2016) in Washington D.C., the NDN team will present two publications (listed below) as well as participate on a panel discussing “Application of ICN in Infrastructure-Free Environments: Rural Areas, Disaster Recovery, and Military Tactical Environments.
  • Save the date: We have revised our plans to host the next NDNcomm at the University of Memphis March 23-24, 2017 immediately preceding IETF 98 in Chicago. We will hold the 4th NDN Hackathon immediately preceding NDNcomm on 22 March, 2017. Lan Wang and Christos Papadopolous will serve as co-chairs.

Read More

“Largest DDoS attack ever delivered by botnet of hijacked IoT devices”

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:

  1. from now on, people may want to always talk about security in IoT,
  2. 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
  3. 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.

Named Data Networking (NDN) Project Newsletter for Summer 2016

The NDN project team compiles and publishes this newsletter periodically to inform the community about recent activities, technical news, meetings, publications, presentations, code releases, and upcoming events. You can find these newsletters posted on the Named Data Networking Project blog.

Read More

Perspective on IPR in ICN core protocols

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!

NFD: Issue Your Own NDN Certificates

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

Read More