Update on Overleaf.

Evaluation/evaluation.tex

@@ -260,6 +260,7 @@ TODO
 The project only supports TCP and UDP flows for carrying the proxied data.
 
 \section{Performance Evaluation}
+\label{section:performance-evaluation}
 
 The discussion of success criteria above used slow network connections to test scaling in certain situations. This section will focus on testing how the solution scales, in terms of faster individual connections, and with many more connections. Further, all of the above tests were automated and carried out entirely on virtual hardware. This section will show some 'real-world' data, using a Raspberry Pi 4B and real Internet connections.
 

Preparation/preparation.tex

@@ -10,10 +10,10 @@
     \graphicspath{{Preparation/Figs/Vector/}{Preparation/Figs/}}
 \fi
 
-Proxying packets is the process f taking packets arriving at one location and transporting them to leave at another. This chapter focuses on the preparatory work to achieve this correctly, given the design laid out in the previous chapter. In sections \ref{section:threat-model} and \ref{section:preparation-security}, I discuss the security threats and plans to confront them. In section 2.3, I present three languages: Go, Rust and C++ - choosing the most appropriate.  Finally, in sections \ref{section:requirements-analysis} and \ref{section:engineering-approach}, I present a requirements analysis and a summary of the engineering approach for the project.
+Proxying packets is the process of taking packets arriving at one location and transporting them to leave at another. This chapter focuses on the preparatory work to achieve this correctly, given the design laid out in the previous chapter. In sections \ref{section:threat-model} and \ref{section:preparation-security}, I discuss the security threats and plans to confront them. In section 2.3, I present three languages: Go, Rust and C++ - choosing the most appropriate.  Finally, in sections \ref{section:requirements-analysis} and \ref{section:engineering-approach}, I present a requirements analysis and a summary of the engineering approach for the project.
 
-\section{Threat Model}
-\label{section:threat-model}
+% ---------------------------- Risk Analysis ------------------------------- %
+\section{Risk Analysis}
 
 Proxying a network connection via a Remote Portal creates an expanded set of security threats than connecting directly to the Internet via a modem. In this section, I will analyse these threats, in both isolation, and compared to the case of connecting directly.
 
@@ -84,11 +84,28 @@ However, of much more relevance is \ref{fig:slow-bad-actor-packet-loss}. Given t
 
 Though the packets leaving a modem have no reasonable expectation of privacy, having the packets enter the Internet at two points does increase this vector. For example, if a malicious actor convinces the Remote Portal that they are a valid connection from the Local Portal, a portion of packets will be sent to them. However, as a fortunate side effect, this method to attempt sniffing would cause a significant Denial of Service to any congestion controlled links based on packet loss, due to the amount of packet loss caused. Therefore, as long as it is ensured that each packet is not sent to multiple places, privacy should be maintained at a similar level to simple Internet access.
 
+% ----------------------------- Threat Model ------------------------------- %
+\section{Threat Model}
+\label{section:threat-model}
+
+\subsection{Bad Listeners}
+
+A Bad Listener is a Bad Actor that reads packets due to be sent but cannot introduce packets of their own. Recall, as stated in the Risk Analysis section, that this is high risk - taking packets causes significant packet loss and thus effectively denies service for loss based congestion control mechanisms.
+
+\subsubsection{Reflection Attacks}
+
+An attack vector for someone attempting to read but not write packets is a reflection attack. A Reflection Attack is an attack where an attacker is able to provide the challenge you have given either to the victim itself or a friend of the victim, to receive the correct challenge response. A full explanation of this is given in \cite{anderson_security_2008}.
+
+\subsection{Bad Speakers}
+
+TODO: The case where a bad actor can send packets of their own design to the remote portal, and have them sent out.
+
+
 % ------------------------------- Security --------------------------------- %
 \section{Security}
 \label{section:preparation-security}
 
-The security of this application is designed to target the threats mentioned in the thread model.
+The security of this application is designed to target the threats mentioned in the threat model.
 
 TODO
 
@@ -102,21 +119,11 @@ TODO: Finish this section.
 \section{Language Selection}
 \label{section:language-selection}
 
-In this section, I evaluate three potential languages for the development of this software.
+In this section, I evaluate three potential languages (C++, Rust and Go) for the development of this software. To support this evaluation, I have provided a sample script in each language. The sample script is intended to be a minimal example of collected packets from a TUN device, placing them in a queue from a single thread, and consuming the packets from the queue with multiple threads. These examples are given in figures \ref{fig:cpp-tun-sample} through \ref{fig:go-tun-sample}.
 
 \subsubsection{C++}
-Pros
-\begin{itemize}
-    \item Super fast.
-\end{itemize}
 
-Cons
-\begin{itemize}
-    \item Not kernel compatible.
-    \item Too low level for dependencies like TUN drivers.
-    \item Not memory safe.
-    \item Lacklustre IDE support.
-\end{itemize}
+There are two primary advantages to completing this project in C++: speed of execution, and C++ being low level enough to achieve these goals. The negatives of using C++ are demonstrated in the sample script, given in figure \ref{fig:cpp-tun-sample}. It is immediately obvious that to achieve even the base of this project, the code in C++ is multiple times the length of equivalent code in either Rust or Go.
 
 \begin{figure}
     \inputminted{cpp}{Preparation/Samples/main.cpp}
@@ -125,18 +132,10 @@ Cons
 \end{figure}
 
 \subsubsection{Rust}
-Pros
-\begin{itemize}
-    \item (probably) fast.
-    \item Memory safe.
-\end{itemize}
 
-Cons
-\begin{itemize}
-    \item Weird dependencies (e.g. TUN driver getting updated, still alpha).
-    \item Not easily kernel compatible.
-    \item Bad IDE support.
-\end{itemize}
+Rust provides advantages over C++ while still maintaining the speed. It is also memory safe, significantly reducing the programming load of searching for memory errors. The Rust sample is given in figure \ref{fig:rust-tun-sample}, and it is pleasantly concise.
+
+For the purposes of this project, the downsides of Rust come from its youthfulness. This is two-faceted: IDE support and Crate stability. Firstly, the IDE support for Rust in my IDE of choice is provided via a plugin to IntelliJ, and is not as supported as other languages. Secondly, the crate available for TUN support (tun-tap\footnote{\url{https://docs.rs/tun-tap/}}) does not yet provide a stable API, which was noticed during the development of even this test script. Between writing the script initially and re-testing it to place in this document, the API of the Crate had changed to the point where my script no longer type checked. Further, the old version had been pulled, and thus I was left with a script that didn't function. Although writing the API for TUN interaction is not an issue, it can reduce portability compared to a purpose written Crate.
 
 \begin{figure}
     \inputminted{rust}{Preparation/Samples/main.rs}
@@ -145,18 +144,12 @@ Cons
 \end{figure}
 
 \subsubsection{Go}
-Pros
-\begin{itemize}
-    \item Memory managed.
-    \item Perfect concurrency control for this project.
-    \item Excellent IDE support.
-    \item Go modules.
-\end{itemize}
 
-Cons
-\begin{itemize}
-    \item Kind of slow.
-\end{itemize}
+The final language to evaluate is Go, often printed as GoLang. It is the language of choice for this project, with the sample provided in figure \ref{fig:go-tun-sample}. Go is significantly higher level than the other two languages mentioned, and provides a memory management model that is both simpler than C++ and more standardised than Rust.
+
+For the greedy structure of this project, Go's focus on concurrency is extremely beneficial. Go has channels in the standard runtime, which allow any of Single-Producer-Single-Consumer (SPSC), Single-Producer-Multi-Consumer (SPMC), Multi-Producer-Single-Consumer (MPSC) and Multi-Producer-Multi-Consumer (MPMC). In this project, both SPMC and MPSC are required, so having these provided as a first class feature of the language is beneficial.
+
+Garbage collection and first order concurrency come together to make the code produced for this project highly readable. The downside of this runtime is that the speed of the language is negatively affected. However, I think that for the purposes of this first production, that compromise is acceptable. By producing code that makes the functionality of the application clear, future implementations could more easily be built to mirror it. As the Go implementation can achieve respectable performance, as shown in section \ref{section:performance-evaluation}, the compromise of using a well-suited high-level language is one worth taking.
 
 \begin{figure}
     \inputminted{go}{Preparation/Samples/main.go}