Project Overview
The project's main goal is to develop a protocol for secure, efficient, asyncronous communication between autonomous nodes. The project will achieve this by developing a software framework for computers on a TCP/IP network to discover each other and collaborate in a decentralized way. Example implementations of this framework include small sensors that would connect wirelessly to each other. These 'nodes' will securely authenticate with each other, and communicate using only encrypted data. The nodes will be device, implementation, and communications medium agnostic, as long as they are capable of fulfilling the requirements of the protocol.Major goals of this project include an implementation agnostic interface, secure communication, and reliable routing. To achieve an implementation agnostic interface, we are using two separate languages, erlang and java, to implement the same application. We are utilizing these prototypes to aid us in designing the protocol to be language agnostic. The challenge for secure communication is the lack of a centralized trust authority. Without the trust authority, new nodes must have a way to authenticate themselves to every other node. The reliable routing goal involves the situation where one node wants to talk to another, and finding the most efficient way to do so when the two nodes cannot directly connect to each other.
Team Personnel
- Primary Contact: Hunter Marshall
- Secondary Contact: John Lin
- Group Members:
- Shawn Doherty
- Contact: sdoher2@illinois.edu
- Bio: My name is Shawn, I'm from Chicago, and I'm going for my CS Bachelor's. As far as my own techy interests, I go for just about anything, and can work well in just about any environment. Except OSX. Its too... gooey for me. Other than that, I'm not picky. It's not hard for me to adapt to new working environments and languages. I am a strong coder, maybe not the strongest on the team, but I can hold my own, and I'm good at catching where bugs are hiding. The aspect of this project most interesting to me is the security question. How we are going to take an open security model and build in our own security.
- Dan Hill
- Contact:
- Bio:My name is Dan, a senior in the CS bachelor's degree program. I am from the middle of nowhere in west central Illinois. I consider myself an average programmer, with my strongest languages being Java and C++ and have worked a bit with Ruby as a scripting language and OCAML as a functional language. My interests right now are in application development, a.i. and robotics (without a lot of experience in the latter two). My next out of class project will probably be an application for the Android mobile phone platform, so I suppose I have some kind of an interest in that as well. I favor Linux as a programming environment, Windows as a general user, and have no interest or familiarity with Macs. My biggest desire from the project is to learn how a real-world company handles a project lifecycle from beginning to end, as neither of my summer internship projects were deployed before I left.
- Kirat Pandya
- Contact:
- Bio:I am Kirat. I'm technically a junior pursuing my Bachelor in Computer Science, but I will be graduating this year,so here I am in CS 492. I am a really strong programmer, and tend to favor C as my strongest language. I have a lot of experience programming at all levels from kernel code to web design. My interests lie in Security, Networking and Systems in that order, so I feel like this project is right up my alley. I am always open to learning new languages, so learning Erlang should be an interesting experience. I feel like this project is not just about implementing a project, but also has a research component to it.
- Jacob Byron
- Contact:
- Bio:I'm Jake and I'm from farm country in central Illinois. I'm also going for my CS bachelor's. I'm familiar with Linux systems as we have to be here, but since it has become less of a requirement I've moved to a more Windows setting of development. I've never touched anything apple, ever. My CS interests revolve around application level development (with a slight interest in security), also algorithms are cool. I'm not a strong network programmer, and I've only ever worked with OCAML in terms of functional languages. I'm very excited to finally be working in a real-world problem solving type of setting, although I don't fully understand the scope of our project yet, I'm sure this can be fixed with our first conversation.
- Shawn Doherty
Full Requirements Document (PDF)
=== Problem Statement ===
The overarching idea for this project is to develop a software framework for computers on a TCP/IP network to discover each other and collaborate in a decentralized way. An example application is within a utility (power grid) infrastructure there might be many (hundreds to hundreds of thousands) sensors all monitoring their respective transformers or power relay stations, all needing to communicate important diagnostic information (temperatures, voltages or throughput) to maintain safe operation of the system.
=== Users ===
The primary contact within Viasat is Hunter Marshall. He works in the Network Systems Group on new initiatives and emerging technologies. Helping Hunter is John Lin who works in Global Satcom Systems specifically on software in that group. The users for this project will vary on the application. If this goes into a utility infrastructure setting the users will be electrical engineers or the like. In a military setting the users might be battlefield techs looking over combat data from a large number of sensors.
=== Vision and Scope ===
The ideal goal for this project is to have (on the order of) 1 million nodes all communicating autonomously on the scale of across the united states, all organizing themselves, all relaying information in fault-tolerant way (½ failure rate for example).
=== Platform ===
The deliverable of this project is primarily the research. As such, there will be emphasis placed on language independence. UML diagrams will be used for organizational and planning purposes. The deployment environment for most of the course is just a computer running Linux, but if all the requirements are achieved in that setting the codebase will be migrated to an embedded system of some sort.
=== Resources ===
The client will be providing us with E-books through the Safari Books Online service. No physical assets will be provided. No expert consultation will be provided.We need 2 Linux machines (and root access to those machines) capable of physical interaction (as well as SSH) from the course staff. The client is acting as a learning/research guide for our project.
== Requirements ==
Functionality and YOU
=== Problem Statement ===
The overarching idea for this project is to develop a software framework for computers on a TCP/IP network to discover each other and collaborate in a decentralized way. An example application is within a utility (power grid) infrastructure there might be many (hundreds to hundreds of thousands) sensors all monitoring their respective transformers or power relay stations, all needing to communicate important diagnostic information (temperatures, voltages or throughput) to maintain safe operation of the system.
=== Users ===
The primary contact within Viasat is Hunter Marshall. He works in the Network Systems Group on new initiatives and emerging technologies. Helping Hunter is John Lin who works in Global Satcom Systems specifically on software in that group. The users for this project will vary on the application. If this goes into a utility infrastructure setting the users will be electrical engineers or the like. In a military setting the users might be battlefield techs looking over combat data from a large number of sensors.
=== Vision and Scope ===
The ideal goal for this project is to have (on the order of) 1 million nodes all communicating autonomously on the scale of across the united states, all organizing themselves, all relaying information in fault-tolerant way (½ failure rate for example).
=== Platform ===
The deliverable of this project is primarily the research. As such, there will be emphasis placed on language independence. UML diagrams will be used for organizational and planning purposes. The deployment environment for most of the course is just a computer running Linux, but if all the requirements are achieved in that setting the codebase will be migrated to an embedded system of some sort.
=== Resources ===
The client will be providing us with E-books through the Safari Books Online service. No physical assets will be provided. No expert consultation will be provided.We need 2 Linux machines (and root access to those machines) capable of physical interaction (as well as SSH) from the course staff. The client is acting as a learning/research guide for our project.
== Requirements ==
- 1. Network composition:
- 1. The system shall be comprised of intercommunicating nodes on a UDP/IP network.
- 2. The exchanges messages must be documented in a language agnostic, byte-order agnostic way.
- 3. Nodes may be in direct communications (edge-connected) to any number of other nodes
- 4. Nodes may be in indirect communication (path-connected) to any number of nodes at any number of network group hops
- 2. Networked node discovery:
- 1. Nodes, on "power-up", should automatically discover other nodes within "range"
- 1. "Range" is defined based on scenario:
- 1. testing: nodes in range are those that are within the multicast IP groups that the new node is subscribed to
- 2. production: nodes in range would be those in wireless range of the current node
- 2. Discovery should not be affected by the connectivity level of the network
- 2. Each node shall maintain a list of active nodes.
- 3. Each node shall send out a heartbeat to ensure that the lists on all other nodes, regarding its availability are up-to-date within any given 10 second period
- 3. Networked node authentication:
- 1. All new nodes must securely authenticate with any other networks that are in rangeR
- 1. Range begin defined as per 2.i.i
- 2. Secure is defined as:
- 1. No unauthorized node may successfully eavesdrop on the network to obtain any unencrypted data as it is passed along (excluding the initial replay attack-safe key exchange
- 2. No unauthorized node may connect to the network
- 3. Apart from initial key exchange, no other data may be passed without suitable encryption
- 4. Node communication
- 1. All nodes that are connected by any number of hops (path-connected) should be able to communicate with each other
- 2. Nodes should be able to transfer data of any size in a fault-tolerant way.
- 1. "fault-tolerant" is defined as best-effort delivery, along the likes of protocols such as TCP.
- 5. Automated network hierarchy
- 1. Nodes shall co-operate in a decentralized way to create a hierarchy among themselves
- 2. This hierarchy shall be structured so as to achieve the following at the highest possible levels
- 1. maximise network connectivity
- 2. maximise network reliability
- 3. maximise network throughput
- 6. Ability to add/change functionality in the code
- 1. All code must be modular.
- 2. Any and all software components of the system should be replaceable without any system downtime or physical acess.
- 3. When a "universal " update has been released to one node on the network, all other nodes should
- 1. download the update
- 2. verify the authenticity and integrity of the update
- 3. update their own running code bases are update without disconnecting from the network
- 4. make a good-faith attemt to ensure all other nodes on the network are updated
- 4. When a "targeted" update has been released to one node on the network,
- 1. targeted nodes should
- 1. download the update
- 2. verify the authenticity and integrity of the update
- 3. update their own running code bases are update without disconnecting from the network
- 4. make a good-faith attemt to ensure all other targeted nodes on the network are updated
- 2. all other nodes should
- 1. make a good-faith attemt to ensure all targeted nodes on the network are updated
- 2. verify the authenticity and integrity of the update
- 7. Interference robustness
- 1. Any illegal messages received by the node must not affect it adversely in any way
- 8. Administration interface
- 1. Provide an "admin" node to connect to a network to
- 1. observe the following
- 1. Network structure
- 2. Calculated average throughput
- 2. issue admin commands to nodes to control the networks in the following ways
- 1. Turn off nodes
- 2. Issue updates, targeted or universal
- 3. Blacklist nodes
- 4. Order network optimization preference for throughput, reliability and/or connectivity
- 9. Multiple language implementations
- 1. The goal of this project will be to research the automated network hierarchy and hot-code swapping techniques necessary to rn a large-scale decentralized network. As such the project must be delivered in at least two languages:
- 1. Erlang
- 2. Java