Challenge Overview
1.0. Project Overview
1.1. Introduction
Welcome to the NASA Disruption Tolerant Networking (DTN) project. DTN is an approach to computer network architecture that seeks to address the technical issues in heterogeneous networks that may lack continuous network connectivity. Examples of such networks are those operating in mobile or extreme terrestrial environments, or planned networks in space. Disruption may occur because of the limits of wireless radio range, sparsity of mobile nodes, energy resources, attack, and noise.
1.2. Project Background
NASA is developing Disruption Tolerant Networking techniques in collaboration with industry and academia. DTN is designed to provide reliable end-to-end delivery of information between nodes and to do so in an environment that experiences frequent connectivity disruptions and topology changes. Such a capability will directly support human and robotic space exploration, as well as have wide applicability to land-mobile and airborne terrestrial communications.
Part of the reality of modern networks is the need to provide robust security capabilities through the use of an architecture that does not overly constrain user operability. A major factor in such security architectures is the mechanism by which cryptographic keys are initialized, distributed and validated among members of a network in order to provide trusted and secure communications supporting confidentiality, authentication and integrity. Most key management approaches in use today rely on either pre-shared secrets (pre-shared public keys or pre-loaded private key pairs), or rely on knowledge of the network connectivity and topology to enable a trusted third party (certificate authority) to authenticate and mediate a “handshake” between two previously unknown nodes.
In a connection disrupted network made up of nodes that come and go at random, it is very hard to base a key management approach on previous knowledge of trusted entities, communication paths, or pre-shared secrets. Trusted network paths come and go (or disappear entirely). Nodes enter and leave the network at random. Pre-shared secrets may be distributed and “expire” before connections are reliably established to verify the credential is valid. These problems drive the need for a new approach to key management and key exchange.
1.3. Problem Statement
1. The problem statement of the project is as follows:
Devise a method by which cryptographic keys can be exchanged among peers in a DTN network suffering from network connectivity disruptions and random topology changes. The method must function in the absence of previous knowledge of network members or pre-shared secrets.
2. Solutions to the problem statement must meet the following criteria:
- It should provide a method (logical / mathematical algorithm) for distribution of symmetric key pairs among previously unknown and un-validated network nodes in a disrupted network environment.
- It should provide a method (logical / mathematical algorithm) for generation, validation, distribution and authentication of asymmetric keys (public/private key pairs) in a disrupted network environment.
- It should provide a method (logical / mathematical algorithm) for detecting and protecting against invalid or malicious manipulation, intrusion, and/or interception of keys during the exchange and validation process.
- Keys and processes must be of sufficient complexity and cryptographic strength to meet the U.S. Federal Information Processing Standards (NIST/FIPS).
- It should provide a method by which multiple, federated, key exchange and management domains can co-exist in the same network.
- It should provide a method by which keys and cryptographic messages of multiple classifications (low, medium, high) or multiple compartments (A, B, C) can co-exist in the same network.
2.0. Competition Task Overview
2.1. Requirements
The first phase of the DTN Security Challenge project focused on gathering and organizing the disparate information on Delay Tolerant Networks so that there is ample documentation available to the community.
The contests run as part of the second phase of the project, attempted to make the problem statement more tractable by redefining it in a way that makes it easier to test and verify logically (like a puzzle). The problem statement was reduced to a special form of a theoretical abstraction used in distributed computing known as the Byzantine Generals' problem. Note that the approximation of the problem statement is incomplete as it doesn't properly account for the largely asynchronous nature of communication in DTNs. Asychronous communication, which is analogous to "network connectivity disruptions" in the problem statement, needs to be properly accounted for in the Byzantine Generals' rendition of the problem statement.
Third phase and final phase of the project will deliver a solution to the redefined problem statement, as well as a working implementation of that solution so that it can be tested.
This contest is part of the second phase of the project. The goal is to study the output of the previous contests that have been run so far (see the Resources section below), and use that information to specify contests that need to be added to/changed in the game plan (see the Atomized Project Plan section) to complete the last phase of the project.
2.2. Submission Deliverables
Your final submission will be a document that includes the following information:
- Suggested improvements to the project's version of the Byzantine Generals' problem that will make it easier to achieve the stated goals.
- Remarks on how to structure the problem statement so that a solution can be obtained by the community via contests.
- Recommendations on contests/races that will be used for preparation & testing (of the solutions). You are free to suggest significant changes to the format of existing contest types or even design new contest types altogether, as long as you make a strong case in your proposal.
- An assessment of whether all the information that has been provided is sufficient to complete the project, and if not - a detailed discussion of the missing pieces which need to be filled in, either by the client or by the community via contests.
It is important that you demonstrate how clearly you understand the subject matter and we encourage you to, where applicable, use diagrams, pseudo-code and math to make your submission stand out.
2.3. Judgement Criteria
- The goal of this contest is to design contests towards solving a problem that is reducible to an agreement (aka consensus) problem.
- DTNs are a peculiar type of distributed system in which communication is predominantly asynchronous. In other words, you are free to suggest and use other abstractions that deal with agreement in asynchronous distributed systems, if they can be adapted to approximate the problem statement better than the Byzatine Generals' problem.
- We are primarily interested in a plan of attack that will produce a working implementation, therefore, some familiarity with asynchronous agreement protocols is expected of submitters.
- Winner(s) will be decided by client reviewers and TopCoder staff.
- The winner may be selected as copilot but this is not guaranteed.
3.0. Resources
3.1. Completed Contests
- DTN Security - Network Elements Documentation - Contest output.
- DTN Security - Network Elements Classification - Contest output.
- DTN Security - Logic Puzzle Idea - Contest output.
- DTN Security - Logic Puzzle Idea Part 2 - Contest output.
3.2. Project Documents
- Security Key Challenge Overview – This contains the full project requirements and overview.
- Glossary - Glossary of terms used in Distruption (or Delay) Tolerant Networking.
Final Submission Guidelines
Refer to sections 2.2 and 2.3 above.