NDN RETREAT 2016 / HACKATHON

NDN RETREAT 2016 / HACKATHON

See the results of the 3rd NDN Hackathon held in November 2016.
Read More
TUTORIAL VIDEOS

TUTORIAL VIDEOS

Watch tutorial videos about the NDN project and NDN technologies.
Read More
THE NDN TESTBED IS GROWING

THE NDN TESTBED IS GROWING

The NDN research testbed is a shared resource created for research purposes, that now includes nodes in Asia and Europe.
Read More
NDN VIDEO FAQ

NDN VIDEO FAQ

Questions about NDN answered on video by faculty, students, staff researchers, and colleagues.
Read More

Named Data Networking (NDN) Project Newsletter for October/November 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.

Community Outreach

  • We will host our 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 following NDNcomm on 25-26 March, 2017. You can find details regarding the meeting, travel grants, and accommodations at the NDNcomm webpage.
  • 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 a publication (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.
  • On the heels of our recent NDN Retreat, we held the 3rd Named Data Networking (NDN) Hackathon November 4-5th, Colorado State University, Fort Collins, CO. See which projects took home the coveted Quadcopter Mini Drones at the 3rd NDN Hackathon page.

Read More

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

Let the World Reach Your NFD

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

Prefix Registration Protocol

Before I talk about how to add a route onto a router, let’s have a look at how nfdc register works under the hood. nfdc register implements NFD Management Protocol. When you execute nfdc register /A udp4://192.0.2.1:6363, the program connects to the local NFD instance via a Unix socket, and sends a command to instruct NFD to add a route for /A prefix toward the specified UDP tunnel. The command is encoded as an NDN Interest. All the parameters you entered on the command line are encoded into the name of this Interest. The name also contains a timestamp to prevent a command being processed twice, and a signature which identifies who is sending the command. When NFD receives this Interest, it dispatches the Interest to the management module, which would check the signature and the timestamp, and then decode and execute the command. If everything goes well, the management module generates a successful response as a Data packet, which goes back to nfdc register program and gets displayed on your terminal.

Since the prefix registration command is actually an Interest, you could manually construct the Interest and send it to NFD via a Unix socket, and NFD would execute it indiscriminately, as long as you get the syntax right.

More importantly, the Interest could be sent over a UDP tunnel to a remote NFD instance, and then you can add a route on the router! remote-register-prefix is an unofficial program that allows you to do just that.

However, don’t get too excited yet. As introduced above, the Interest name contains a signature to identify who is sending the command. In most deployments, the default setting of NFD allows anyone to execute any command if the command is sent over a Unix socket. However, when you send the command over a UDP tunnel to a remote NFD instance on the NDN Testbed, more strict signature checking rules will apply. As of Jun 2016, the routers accept a signature only if your certificate can be traced, in a PKI-like hierarchical model, to be trusted by the NDN Testbed Root.

Everyone who has research intentions can request a trusted certificate on ndncert system. Typically, a certificate request on ndncert is manually reviewed in 24 hours. Once your certificate has been approved and correctly installed, you may use remote-register-prefix with this certificate to add a route on the router.

$ remote-register-prefix -p /A -f udp4://131.179.196.46:6363 -i /ndn/edu/arizona/cs/shijunxiao
OK: /A udp4://131.179.196.46:6363

Looking at the router’s status page, you will find the prefix showing up in “RIB” section:

/A on spurs status page

/A on spurs status page

Automatic Prefix Propagation

NFD itself contains Automatic Prefix Propagation, a module that helps an end host to add a route toward itself on the router. Unlike nfdc register and remote-register-prefix which are executed manually, Automatic Prefix Propagation is “automatic”: when a producer application registers itself with the local NFD, if the producer’s name prefix falls under one of the prefixes configured in the Automatic Prefix Propagation, NFD would send a prefix registration command to the router, so that Interests under this prefix can come to the end host NFD and go to the producer application. Since the prefix registration originally comes from a producer application, and this module sends a prefix registration command to the router, it’s called “propagation” in the sense that the prefix registration gets propagated through this module.

Prefixes to Propagate

Automatic Prefix Propagation is somewhat tricky to setup, because the list of prefixes to propagate is not specified in a configuration file, but in the form of a key chain, a container of public-private key pairs. The rationale of this design is that, NFD needs to have access to a user certificate in order to create a valid signature for the prefix registration command. An “identity name” can be derived from the certificate name by dropping certain name components that distinguishes public keys and certificates versions. This “identity name” is the only name prefix that Automatic Prefix Propagation would be willing to send prefix registration commands for; as of NFD 0.4.1, you cannot instruct Automatic Prefix Propagation to register any other prefix, even if your certificate is technically capable of adding a route with any name prefix on the router (as shown in the remote-register-prefix example above).

Where’s the Key Chain?

To make things more confusing, depending on how NFD was installed, you may have to hunt for where Automatic Prefix Propagation’s key chain is stored. Generally, if you installed NFD from source code, the key chain should be in your home directory; if you installed NFD from Ubuntu packages, the key chain would hide inside /var/lib/ndn/nfd. If you are unsure, cat /proc/$(pgrep nfd)/environ | tr '\0' '\n' | grep HOME= may be able to help you; this one-liner shows the $HOME environ of NFD process, which defines the location of its key chain.

If the key chain is in your home directory, as in the case when you installed NFD from source code, Automatic Prefix Propagation should already be able to use your certificates.

If the key chain is stored elsewhere, you’ll need to import your certificate, including the private key, into Automatic Prefix Propagation’s key chain.

Export your private key from your user account key chain into a file:

    $ ndnsec export -o shijunxiao.ndnkey -p /ndn/edu/arizona/cs/shijunxiao
    Passphrase for the private key: 
    Confirm:

And then import it into Automatic Prefix Propagation’s key chain:

    $ sudo HOME=/var/lib/ndn/nfd -u ndn ndnsec import -p shijunxiao.ndnkey
    Passphrase for the private key: 
    Confirm:

Restart NFD.

It’s important that Automatic Prefix Propagation’s key chain only contains certificates trusted by the NDN Testbed Root. A common mistake is to have an expired, self-signed, or otherwise invalid certificate lying around. If Automatic Prefix Propagation happens to use that certificate, the router would not trust the signature, and the prefix registration command would fail. This is true even if said invalid certificate is not set as the default. Therefore, delete all invalid certificates with ndnsec delete command (prefix it with sudo HOME=/var/lib/ndn/nfd -u ndn if your NFD is installed from Ubuntu packages), and ensure ndnsec list -c shows only valid certificates requested from ndncert system.

How to Trigger a Propagation?

To trigger Automatic Prefix Propagation to work for you, three conditions must be met at the same time:

* Your certificate is in Automatic Prefix Propagation’s key chain.
* There is a local producer application that has registered itself under the “identity name” of your certificate.
* Local NFD is connected to an NDN Testbed router.

The first condition is completed when you import your private key, and delete any invalid certificates, as described in the previous section.

To meet the second condition, you may run a producer application, such as our favorite ndnpingserver:

$ ndnpingserver /ndn/edu/arizona/cs/shijunxiao/laptop
PING SERVER /ndn/edu/arizona/cs/shijunxiao/laptop

The third condition obviously requires a UDP tunnel to a router. In addition, you must tell Automatic Prefix Propagation that this tunnel is a connection to an NDN Testbed router (rather than some other machine you have). This is done by adding a route in local NFD with a special prefix /localhop/nfd:

$ nfdc register / udp4://hobo.cs.arizona.edu
Successful in name registration: ControlParameters(Name: /, FaceId: 266, Origin: 255, Cost: 0, Flags: 1, )
$ nfdc register /localhop/nfd udp4://hobo.cs.arizona.edu
Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId: 266, Origin: 255, Cost: 0, Flags: 1, )

If everything goes well, you’ll finally see your prefix pops up on the router status page:

/ndn/edu/arizona/cs/shijunxiao on hobo status page

/ndn/edu/arizona/cs/shijunxiao on hobo status page

The prefix is shorter than producer application’s prefix, because it’s defined by the “identity name” that is derived from the certificate name. “Origin=65” denotes a route created by Automatic Prefix Propagation. As of NFD 0.4.1, none of these parameters are configurable.
Next Steps

Now you have added a route on an NDN Testbed router toward your local NFD, so that others can retrieve contents from you. However, if you have multiple machines, you either have to request a certificate from ndncert for each machine which is inconvenient as each request needs a 24-hour review period, or copy the private key onto every machine which is a security risk; also, if you request those certificates with the same email address, they would have the same “identity name” and hence Automatic Prefix Propagation would register the same prefix toward all your machines, causing inefficiencies in network performance. Junxiao’s next post, NFD: Issue Your Own NDN Certificates will explain how to create sub-certificates signed by your main certificate, and use them on all your machines.

Named Data Networking (NDN) Project Newsletter for May/June 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

  • On May 31-June 1, 2016, NIST hosted a two-day workshop on Named Data Networking on their campus in Gaithersburg, MD. Day 1 theme focused on the Internet of Things, Day 2 theme covered Big Data and Big Media. See the agenda and the webcast.

Read More

NDN-NP Project 2015-2016 Annual Report

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:

Read More

Named Data Networking (NDN) Project Newsletter for April 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

  •  We are pleased to announce that NIST will host a two-day workshop on Named Data Networking on their campus in Gaithersburg, MD on May 31-June 1, 2016. Day 1 theme will focus on the Internet of Things, Day 2 theme will cover Big Data and Big Media. Please find the agenda and links to registration and hotel information online at http://www.nist.gov/itl/antd/named-data-networking.cfm. Registration will close one week prior to the workshop.

Read More