meer approach shizzle en plaatje
[tt2015.git] / 1intro.tex
index 2e402b1..0f2360d 100644 (file)
@@ -15,34 +15,37 @@ conformity to the specification of an \emph{existing} implementation.
 
 \subsection{SUT}
 %3,4
-The \textit{System under test} (SUT) is a
-Java\footnote{\url{http://www.java.com}} TCP driven echo server that executed
-on a virtualized Ubuntu system\footnote{\url{http://www.ubuntu.com}} running on
-the Linux kernel\footnote{\url{http://www.kernel.org}} version $3.13$. To test
-the error behaviour custom iptables output policies have to be set
-Listing~\ref{listing:iptables}. This is needed because the kernel by default
-closes all connections from unknown sources and the manually created TCP
-packets used in testing the implementation are from a source unknown to the
-kernel.
-
-\begin{lstlisting}[label={listing:iptables},caption={settings iptables}]
-Chain OUTPUT (policy ACCEPT)
-target prot    opt     source  destination
-ACCEPT tcp     --      anywhere        anywhere        tcp flags:PSH/PSH
-DROP   tcp     --      anywhere        anywhere        tcp flags:RST/RST
-\end{lstlisting}
-
-\subsection{Risks} \label{sec:risks}
+
+\includegraphics[width=\linewidth]{SUTsetup}
+
+The \textit{System under test} (SUT) is the TCP implementation of a system
+running a Linux kernel\footnote{\url{http://www.kernel.org}} version $3.13$.
+TCP is not a program that runs on its own and therefore we have to make use of
+some tools to be able to test the protocol. This is further described in
+Section~\ref{section:testenv}.
+
+The specification of TCP is too big to be tested in one go so we focus on
+specific sections from \textit{RFC793}.
+\begin{itemize}
+       \item Sequence numbers~\cite[Section~3.3]{rfc793}.
+       \item Setting up a connection via the 
+               ``Three-way handshake''~\cite[Section~3.4]{rfc793}.
+       \item Closing a connection~\cite[Section~3.5]{rfc793}.
+       \item Data communication~\cite[Section~3.7]{rfc793}.
+\end{itemize}
+
+\subsection{Risks}
+\label{sec:risks}
 %5. Risks
 Risks can be divided into two categories. Project risks and product risks.
-Because an existing implementation is used the project risk are non applicable.
-Product risks even more so, since it is unknown if the product has been tested
-during development.
+Because an existing implementation is tested the project risks are non
+applicable. Product risks however are very important since it is unknown if the
+product has been tested during development.
 
 The product risks for the SUT are significant because misbehaviour of the SUT
 could have potential large consequences. The key characteristics of TCP are
-integrity and reliability~\cite{rfc793}, these characteristics cease to exist
-when the implementation is faulty.
+integrity and reliability~\cite[Section~1]{rfc793}, these characteristics cease
+to exist when the implementation is faulty.
 
 Because TCP is a core functionality of a networking capable system it is
 crucial that the TCP implementation functions according to the specification.
@@ -50,4 +53,8 @@ Several critical systems could rely on the correct functionality of the TCP
 implementation. A failure in the SUT could therefore have extensive
 consequences. Even more so since TCP is a computer-to-computer protocol, which
 leaves no room for ambiguity, which could be solved in a computer-to-human
-protocol.
+protocol. Another effect of the SUT being a computer-to-computer protocol
+without a standalone program is the fact that we can only observe the SUT
+indirectly. With the use of tools we can see what the output is for a given
+input but there is always the risk that the tools give an incomplete or faulty
+view of the output.