Self-Certifying Names for Named Data Networking

Implementation plan :

Our DID implementation is based on the specifications of “DID:self”, a DID method we have published in Mobile Multimedia Laboratory, “DID:self method specification"⁴  A Python3-based software library⁵ currently at TRL3, provides DID document (self-)management functionality by implementing the corresponding Cre ate, Update, and Readmethods. The Create method is used for creating the initial DID document, the Update method is used for modifying it (including key rotation), and the Read method outputs the final DID document and a proof chain that can be used for verifying the binding between a DID and the corresponding document. An application layer solution will combine our implementation with python-ndn ⁶, an NDN client library, to provide the desired functionality as follows. For each content item, the application will generate a public-private key pair from the Curve25519 elliptic curve. The public key will be then treated as a DID and will be used as the name of the content item. The private key that corresponds to a DID/content name, will be used for signing content item metadata. Metadata will include information that can be used for verifying various properties of an item, such as its integrity, version, type, and alternative names. Eventually, the DID document that corresponds to an item, the appropriate proof, and the signed metadata will be included in the payload of a NDN packet. Using python-ndn, the application will interact with the “NDN Forwarding Daemon” (NFD) of a testbed node in order to perform the appropriate (ICN) operations. Our final software will be at least at TRL4, and possibly at TRL5.

Our experiments will consider the following content item types: immutable items, mutable items that may have multiple “representations” (e.g., an image file stored under different encodings), and mutable items that may have different “versions.” When mutable items are used, we need a mechanism to distinguish among different versions or representations of the same item: this is achieved by including the corresponding information in the metadata (e.g., using a “version” and a “type” field). In addition, for mutable items, the DID document may specify the public keys of the entities that are allowed to generate new versions and/or representations of an item. Similarly, our experiments will consider two content delivery modes: the document mode and the channel mode.In the former mode, a content name will be mapped to a data “bucket,” e.g., an image file, whereas in the second case, a content name will be mapped to a data “stream,” e.g., a streamed video. During the project we will perform experimentsrelated tothe following ICN functionalities:

• Caching and Multicast Caching and multicast functionalitiesare provided by the NFD. Therefore, experimentation with these functionalities simply requires the allocation of a suitable topology within the testbed and the application of an appropriate workload at the endpoints.
• Multisource. In order to experiment with multisource, we will implement content name “aliases”. In particular, a content item will be provided by multiple sources and each source will use a different content name. All these name “aliases” will be included in a special field of the item’s metadata called “alsoknownas”. A client application will request simultaneously many of the item’s names, making sure that each request concerns different chunks. This will result in the client receiving different chunks of an item from different sources.
• Multipath. In order to experiment with multipath we will add a new node in the NDN testbed which will be attached to, at least, two nodes, located in different locations. Furthermore, we will allow the content owner to include in DID documents the public keys of in-network nodes that are authorized to modify “control fields” used for orchestrating multipath transmission
• Security. Our security related experiments will focus on detecting fake content. In particular,we will consider cases where an attacker signs a fake item using a revoked or a breached key.Our scenarios will consider various types of compromised keys, including keys allowed to update the DID document, as well as keys allowed to generate new versions/representations of an item.In our experiments we will “inject” fake content from various points of the testbed

_{4 https://github.com/mmlab-aueb/did-sel}

_{5 Mobile Multimedia Laboratory, “DID:self method python library,” available at https://github.com/mmlab-aueb/did-self-py}

_{6 Named Data Networking, “A Named Data Networking client library with AsyncIO support in Python 3,” available at https://github.com/named-data/python-ndn}

Impacts :

With respect to the NGI initiative, our project is anticipated to have impact in the following areas:

• Enhanced EU –US cooperation in Next Generation Internet, including policy cooperation. Beyond ICN, and ICT research in general, we believe that our project can be a starting point for better future EU-US relations in science and technology: both partners, AUEB and UofM, through their active collaboration in organizing international events, such as the ACM SIGCOMM ICN conference, and in participation in international working groups, such as IRTF’s ICNRG, have already established a fruitful relationship that guarantees a successful collaboration. The outcomes of the project will become an excellent showcase of cooperation between the two continents and will set up an example for other similar activities.
• Reinforced collaboration and increased synergies between the Next Generation Internet and the Tomorrow's Internet programmes. The project combines EU-based and US-based researchers and resources to experiment with networking architecture and components that are of interest to both the Next Generation Internet and the Tomorrow’s Internet programmes. For instance, our “DID:self” method is applicable to a number of emerging authentication and authorization standards. Furthermore, the DID-based content authentication mechanism can be applied in other networking and application contexts, such as the emerging Inter-Planetary File System(IPFS)[10], or even HTTP-based services.
• Developing interoperable solutions and joint demonstrators, contributions to standards. The project is expected to be a showcase of the merger of two emerging standards, managed by different standardization bodies. On the one hand, DIDs are primarily pursued by the W3C. On the other hand, ICN standards are mainly developed under the umbrella of the IETF. Both standardization efforts involve partners from academia and industry. Beyond the demonstration of the joint standards, the project is anticipated to inspire new activities in the respective standardization bodies. In particular, we expect to ignite discussions related to self-managed DIDs, as well as to novel content authentication mechanisms. An EU -US ecosystem of top researchers, hi-tech start-ups / SMEs and Internet-related communities collaborating on the evolution of the Internet. The team envisions that this project will not be a mere collaboration between two ICN pioneers but will also establish a permanent link between EU-US ICT research based on the Future Internet ICN approach. EU ICN research efforts are more human-centric, focusing mostly on security and trust, self-sovereignty, and distributed data governance. US efforts on the other hand prioritize deployment and real-world exploitation. Research teams on both continents will benefit from this complementary partnership.

Results :

For each considered ICN functionality we expect to obtain the following results:

• Caching and Multicast. For these functionalities, the project will compare this approach to “vanilla” NDN by experimenting with mutable and immutable items, as well as document and channel delivery modes. When it comes to mutable items and channel mode, we expect to see O(N) reduction in network overhead, where N is the number of recipients receiving the stream. On the other hand, when mutable items and document mode are combined, we expect to see an increase in the number of content “advertisements” required to keep caches up to date, since there is a need to distinguish among the various versions. The degree of the increase depends on two factors: (i) whether or not a new version of an item deprecates the old ones, and (ii) whether or not caches are capable of parsing our item metadata format (a case that will be explored using “incremental deployment” scenarios). Finally, it is expected to see similar performance between the project approach and vanilla NDN when mutable items are used (no matter the delivery mode).
• Multisource and multipath When it comes to multisource and multipath, we will perform two types of experiments. Firstly, the team will utilize multiple sources/paths simultaneously and we will measure the improvement in throughput; this improvement is expected to be log(N) compared to vanilla NDN, where N is the number of paths/sources. Secondly, the team will use the additional paths/sources as a “fallback” mechanism and introduce network failures. In that case, the team will measure the amount of time required to re-gain the original throughput; this is expected to be a few milliseconds. For these experiments, the expected results will also be affected by whether or not in-network nodes can parse and verify DID documents.
• Security. With respect to the security aspects of our system we will perform two types of experiments. Firstly, the team will measure the time required for users to start receiving the correct version of a file in the presence of attackers that have access to the signing key of the content owner. Secondly, the team will measure the time required for users to start receiving the correct version of a file in the presence of attackers that have been authorized by the content owner to host/modify an item, but after some time they start behaving maliciously hence their privileges have to be revoked. In both cases, we expect to see results in the order of a few seconds.

Expected TRL at experiment completition :

NGI related Topic :

Call Reference :