% 
% This document describes the methodology of project tentun developers.
%

\documentclass[twoside,a4paper]{book}
\usepackage{graphics}
\usepackage{makeidx}
\usepackage[dvips]{epsfig}

% \parskip 0.5cm
\parindent 0cm

% the book itself
\begin{document}             % End of preamble and beginning of text.

\title{Methodology for Tentun project}
\author{David Gordon \\ Laurent Birtz }

\maketitle

\section{Project resources and goals}

Tentun is a name chosen because it is related to the notion of
tunneling, where ten is meant as many tunnels. The project is
Sourceforge based with the hopes that a user community will develop
once the foundation of the project is finished. All initial
development will be done on the Linux platform.

As for programming resources, we will use libdnet, vtun, fragroute,
and a few other tools. Libdnet is a multi-platform networking library
written by Dug Song. Hopefully, Tentun will be easily portable to
different platforms if we use this library. Vtun is a tunneling tool
with some interesting implementation ideas. Fragroute was also coded
by Dug Song and is a good example of libdnet usage. Other tools such
as HttpTunnel and IcmpChat are good examples of tunneling tools.

Tunneling has been implemented in many different tools in a fragmented
manner. Tentun aims to unify tunneling implementations as well as
introduced a completely innovative concept. Instead of using protocol
data space, Tentun intends to force protocol RFC specifications to
create a covert stream of data on existing data streams.


\section{Tentative schedule}

The 4 month period of January to April is separated in three major
parts to the project.

\subsection{Milestones' description}

The first part is implementing a tunnel socket to socket over a
network. The tunnel itself is simply UDP or TCP between the
sockets. The challenge is to become familiar with the resources
mentioned earlier and do system network changes programatically.

The second part consists of using protocol data space to create a
stream for a different protocol. For example, implementation would be
able to handle a FTP connection by encoding all FTP traffic within a
HTTP connection. For now, the HTTP connection would be a generated
one, not an actual legitimate HTTP connection.

The third part involves stretching limits of protocol
specifications. For instance, a normal NTP stream of data would be
modified to include a covert telnet stream. The modification could be
that the IP header would now contain a longer packet length allowing
us to append telnet data to NTP stream.

\subsection{Schedule}

\begin{itemize}
\item The first part would take three weeks starting Monday January 13th.

\item The second part would take the month of February.

\item The third part would span the remaining 8 weeks for a total of 15
weeks.
\end{itemize}


\section{Detailed plan}

This section provides a detailed list of tasks for each milestone.

First part:

\begin{itemize}
\item tunnel and route establishment
\item client UDP traffic encoding
\item client UDP traffic decoding
\end{itemize}

Second part:

\begin{itemize}
\item implement plug-in/modular engine for supported protocols
\item code plug-ins for HTTP, FTP, ICMP, and other selected protocols
\end{itemize}

Third part:

\begin{itemize}
\item RFC research/testing for router supported packet mods
\item implement packet mods for covert traffic tunneling
\item map routers and the supported packet mods
\end{itemize}


\section{Possible continuation}

Possible avenues to be explored once the above plan is completed:

\begin{itemize}
\item mechanism for traffic hijacking
\item dynamic route establishment
\end{itemize}



\end{document}               % End of document.

