NDN RETREAT 2016 / HACKATHON

NDN RETREAT 2016 / HACKATHON

See presentation slides and the project results from the 6th NDN Retreat and 2nd NDN Hackathon in March 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 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

Named Data Networking (NDN) Project Newsletter for March 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 20-23 March 2016 we held the 2nd NDN Hackathon and Project Retreat. We welcomed over 30 participants for the Hackathon and over 50 for the Retreat to the University of California at San Diego campus in La Jolla, CA. The retreat focused on science applications, technical discussions with a focus on NFD development, autoconfiguration IoT over NDN, and architectural principles and future collaboration and funding opportunities. For final agenda, slides, and breakout outcomes see the web page at www.caida.org/workshops/ndn/1603/. For the final list of projects and links to code from the Hackathon, see http://2nd-ndn-hackathon.named-data.net/.

Read More

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

  • Mark your calendars for 20-23 March 2016 when we plan to hold the next NDN Hackathon (open to the public) and Project Retreat (open to NDN Consortium members). We will host the retreat on the University of California at San Diego campus in La Jolla, CA. This retreat will focus on science applications, technical discussions with a focus on NFD development, autoconfiguration IoT over NDN, and architectural principles and I/UCRC proposal planning. For registration information, agenda, and more see the web page at http://www.caida.org/workshops/ndn/1603/.

Read More

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

Technical News

  • The NDN Testbed has grown to 31 Nodes with 84 links. Since our last newsletter, four new sites have connected to the NDN Testbed; University of Goettingen, University of Indonesia, Osaka University, and the University of Minho in Portugal. See the complete list at http://named-data.net/ndn-testbed/.
  • We released version 0.4.0 of Named Data Networking Forwarding Daemon (NFD) and ndn-cxx library. Please see the detailed release notes for NFD and the release notes for ndn-cxx library.  More details about NFD, source code, install instructions, tutorials, HOWTOs, a FAQ and other useful resources are available on the official webpages of NFD and ndn-cxx.
  • We announced the release of version 0.2.2 of Named Data Link State Routing Protocol (NLSR). Detailed release notes for NLSR are available. More information about NLSR, tutorials, installation and configuration guides, and other useful resources are available on the official webpage of NLSR.
  • We published the alpha version of NFD on Android to Google Play store, based on the recently released NFD version 0.4.0. This first release has limited documentation. We welcome help in any form: bug reports and feature requests submitted to redmine, patches, bug fixes, feature implementations, documentation and updates. To opt-in to the alpha testing and to download the NFD app, open https://play.google.com/apps/testing/net.named_data.nfd on your Android device. Source code for the port is available on GitHub: https://github.com/named-data-mobile/NFD-android

Read More