Challenge Task 2011

Overview

• Task Description
• Requirements
• Assumptions
• Libraries and Tools
• Organization
• Initial Steps
• Time Plan and Milestones
• Groups and Support
• Subversion Repository
• Testbed Infrastructure
• Presentation and Evaluation
• Result
• Reports and Source Code

Task Description

Recent events have put the neutrality of the Internet in question. The Internet as we know today depends heavily on the DNS (Domain Name System) to translate domain names into IP addresses of hosts where information is located. The problem is that DNS has a central authority, making it easy for an entity to arbitrarily and effectively shut down web sites and other services that depend on DNS. The Internet as a free, independent, and censorship-less communication medium can only exist if DNS were government-independent.

The P2P Challenge Task (CT) for the FS11 semester is to design and implement an independent, P2P DNS infrastructure. The application will act as a name server running on PCs of voluntaries who collaborate on keeping the service. This means that every peer will listen on port 53 and "speak" DNS to resolvers (e.g. web browsers). No central authority may be present, that is, the system will suffer no influence from ICANN or governments. Conflicts must be solved by the peers themselves (for example, using voting or a web of trust). Assumptions must be made regarding who has the right to use which name, but it must not be trivial for a single peer to hijack a domain name it has no right to (although more complex attacks don't have to be considered). Every peer must run the same software, although some peers may become more trusted than others.

Requirements

All requirements below must be met in order for the CT to be successfully accomplished.

• The application must work as a DNS name server to a web browser, replying, for example, with resource records (RR) "A" and "CNAME".
• The P2P-based DNS system will resolve names under the TLD "free", e.g. "www.uzh.free".
• When other TLDs are requested (e.g., "com", "net", "org"), the peer must contact a normal DNS name server in order to resolve them (acting as a mere proxy).
• Authorities for names under the "free" TLD must be distributed according to each group's policy. No central authority may be present.
• Only the correct authority has the right to alter its domain names and its corresponding sub-domains, though more complex attacks don't need to be considered.
• A user interface must present means to manage domain names and to visualize what happens when the peer is resolving a name.
• The system must be robust to some peers leaving the system, but a catastrophic scenario does not need to be considered.
• The solution shall be based on P2P mechanisms.
• The solution shall not contain any central elements.
• The solution shall be executable on the provided test setup machines (Linux, Java 1.6).
• The solution may use existing libraries and code, but those must be allowed to be published under GPL or another comparable open software license.
• The final report, consisting of 5-10 pages, shall document the application.

Assumptions

The following facts may be assumed:

• Every peer bootstraps to a trusted peer.
• Up to 20% of the peers may fail unpredictably.
• Note: Further assumptions can be made according to each group's approach.

Libraries and Tools

The items below represent some supporting libraries, tools, or references that might be taken into consideration.

• Use Java as the programming language. You should use the latest version, as this has usually more useful features than older versions. The J2SE Software Development Kit (SDK) can be downloaded under http://java.sun.com/javase/downloads/.
• The assistants know Eclipse well and the use of Eclipse is highly recommended. The most recent release of Eclipse can be downloaded at http://www.eclipse.org/downloads/. Eclipse is available for Windows, Mac OS, Linux and further platforms. If you prefer other IDEs (e.g. Netbeans) you may use them but without support from our side (i.e. good luck!).
• The use of TomP2P as a P2P overlay technology is highly recommended. TomP2P is an open-source implementation of the Kademlia DHT. More information can be found at http://tomp2p.net/. At http://tomp2p.net/doc/quick/ there is a quick introduction to the TomP2P library.
• The use of a Java DNS library such as dnsjava may be useful as well.
• DNS material: RFC 1591, RFC 883, http://technet.microsoft.com/en-us/library/cc775637%28WS.10%29.aspx, http://www.zytrax.com/books/dns/ch8/.
• Java material:Java Tutorial, Java ist auch eine Insel, Java API, Eclipse Dokumentation.
• Hint! A library for cryptography (e.g. java.security) may also be of use.

Organization

• The groups shall be balanced. Every group shall have one Java expert. During the challenge task, the group shall meet every week during exercise hours to work on the task and discuss the next steps.
• The groups shall utilize their homework times to work on the CT, besides the exercise time slots assigned on Thursday.
• The groups shall determine and set-up an internal project plan with the overall milestones timings provided here.
• Distribute the workload so that each group member gets a fair load of work (P2P load balancing) and make sure activities can run in parallel (non-blocking).
• You can use your own laptop and/or the computers in room BIN 1.D.12.

Initial Steps

In order to successfully achieve your goal, the following initial steps are recommended.

• Start by understanding what DNS provides and how it works.
• Understand how TomP2P works, what P2P methodology is used, how nodes are accessed, and what it can provide. Implement a simple example. This example does not need to be part of the solution; the goal is to get used to the API and see how the framework behaves.

Time Plan and Milestones

The challenge task includes three milestones on which specific deliverables have to be handed-in to the supervisors:

• Milestone 1: Design your application. Specify use case(s), functional requirements, modules. Plan how nodes will communicate. Draw sequence diagrams for communication among nodes and inside nodes, among components. Design the protocol used for inter-peer communication. Present to the supervisor a detailed work plan including approach, task distribution among group members, and a ToC of the report.
• Milestone 2: Build a GUI prototype. Implement and test the DNS functionality. Present a draft report to the supervisor, consisting of a table of contents (ToC) and some bullet points on each section.
• Milestone 3: Implement the protocol designed for Milestone 1. Test and debug your application. Hand in the final report, consisting of 5-10 pages, including assumptions, design, structure of code, and installation requirements.
  

The following table shows the time plan for the challenge task with the different milestones:

Groups and Support

During the challenge task each group will be able to ask questions and get support for the task from their supervisors:

Subversion Repository

A SVN repository will be provided to each group. Each repository contains the suggested libraries and an Eclipse project.

The passwords are to be provided by e-mail.

Testbed Infrastructure

During the challenge task and for the final demo 10 Linux PCs (Pentium 4, 2.8 GHz, 500 MB RAM) will be available during exercise hours in BIN 1.D.12.

Presentation and Evaluation

The challenge task will end on the 26.05.2011. On this date, the different groups will present and demonstrate their results, which will be evaluated by a jury.

• Each group will have 10 minutes for presenting the approach chosen and design of the developed application. The presentation shall include slides. A white board and a flip chart can be used additionally.
  
• After presenting the approach and design, each group must give a 10-minute demonstration of the application. The application must run on at least 5 nodes, and it must be demonstrated that it fulfills all requirements. Its properties, such as fault tolerance and load distribution, as well as its performance and robustness, may also be demonstrated. The P2P application shall be pre-installed on the machines for timing reasons.
• The demonstration should be done as follows. Three web servers will serve a web page each (provided by the assistants). The web servers will be assigned to names web[123].groupX. free . A browser will be configured to use one of the applications as DNS resolver and will try to resolve those names. Some output must show what happens under the hood. Resilience to some basic attacks can be demonstrated, such as the peer responsible for web2 trying to hijack web1. Or shut down 2 out of 5 peers and see what happens.
• At least a minimal visualization mechanism shall be provided for viewing the participating nodes and their main interactions. Text output is enough, e.g. "Node A: received message X; origin B; dest C; next hop D". This can be achieved using a log file.
• After the demonstration, each group will be evaluated by the jury. The following criteria will be taken into consideration: fulfillment of requirements, clarity of design, trade-offs considered, and presentation and demonstration of the solution.
• The jury is composed of lecturers and assistants, and each member will cast one vote per group. The results of the votes will be collected and disclosed after the last presentation. In case more than one group achieve the top score, all respective groups will be considered winners.
  
• Finally, the winning group will receive a symbolic prize and the "P2P Challenge Champion 2011" award.

Result

Congratulation to group 4 for winning the 2011 P2P Challenge Task!

Thanks to all participants for the hard work on developing, presenting, and demonstrating interesting and diverse approaches to solve the given problem.

Reports and Source Code

Please find below the report and source code of each group for download. Source code is licensed under GPL. In case of questions, please contact the respective supervisor.