\section{Background: What is this about}

The Linux FreeS/WAN project is a funded project. It has the mandate to
produce an IPsec implementation for Linux. The ultimate goal of this effort
is to provide systems and software to permit citizens for the world to keep
all of their Internet traffic private.
\footnote{See \htmladdnormallink{http://www.freeswan.org/}{http://www.freeswan.org/}}.

Testing networking protocols is often difficult. By definition there is at
least one network involved and often several independant systems attached to
the network. 

With many application layer network protocols (e.g. http) one can cheat - the 
network is the virtual ``loopback'' device, and multitasking permits both
ends of a protocol to run on the same host. It is therefore common to see
people doing all sorts of network development using a garden variety notebook.

The situation is not the same for transport and network layer protocols such
as IP, TCP and IPsec. These layers of the protocol are more fundamental. They 
are typically implemented inside a system kernel. This makes development work
as difficult as generic kernel work.

If one is to test them on one's notebook or desktop, one risks putting ones
own development environment at risk. It is common experience that doing
kernel development is much easier with at least two machines - one machine is 
crashed every ten minutes and the other machine is used as the development
host. The split between development and testing is much better understood in
embedded system work - the machine under test is often of a totally different 
type than the development machine. Historically, the machine under test (a
VCR or a modem) is incapable of even running a development environment. 

Network protocol development work is further complicated by the need to have
more than one machine involved. 

\subsection{eXtreme Programming}

The growing discipline of eXtreme Programming\cite{XP}
has a number of fundamental principles
\begin{itemize}
\item rapid feedback
\item assume simplicitiy
\item incremental change
\item embracing change
\item quality work
\end{itemize}

\cite{XP} goes on to explain that the fundamental activities are coding,
testing, listening and designing. XP tries to reach the point where one
writes the test cases before the code. To do this, the cost (in effort and time) of
testing must be reduced such that all tests can be run frequently - several
times a day if possible. This very rapid feedback reduces the risk of
introducing problems - permitting developers to program more efficiently and
with more confidence 

This paper describes the typical requirements for doing network testing. The
reasons why it is expensive and why it is difficult to automate are
explained. 
Our solution, uses User-Mode-Linux to turn machines into processes. The
scaffolding is then used to control these processes, to put them through
their paces on a regular basis.

No solution is perfect on the first pass - XP actually encourages partial
solutions to be implemented and feedback to be received - so we describe our
second pass, which at the time of writing, is still in the design phase.





