JakeHillion/dissertation-4-dissertation
1
0
Fork 0
Code Issues Pull Requests Releases 1 Wiki Activity

Reset to compilable state

Browse Source
This commit is contained in:
Jake Hillion 2021-05-13 15:32:30 +01:00
parent 852b624324
commit 4e23615e39
6 changed files with 105 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
2_Preparation/preparation.tex
View File

@ -86,90 +86,7 @@ When applying message authentication, it was sufficient to authenticate messages
It was previously mentioned that my solution is transparent to the higher layer security encapsulated by proxied packets. Further to this, my solution provides transparent security in the other direction, where proxied packets are encapsulated by another security solution. Consider the case of a satellite office that employs both a whole network corporate VPN and my solution. The network can be configured in each of two cases: the multipath proxy runs behind the VPN, or the VPN runs behind the multipath proxy. It was previously mentioned that my solution is transparent to the higher layer security encapsulated by proxied packets. Further to this, my solution provides transparent security in the other direction, where proxied packets are encapsulated by another security solution. Consider the case of a satellite office that employs both a whole network corporate VPN and my solution. The network can be configured in each of two cases: the multipath proxy runs behind the VPN, or the VPN runs behind the multipath proxy.
Packet structures for proxied packets in each of these cases are given in Figure \ref{fig:whole-network-vpn-behind} and Figure \ref{fig:whole-network-vpn-infront}, for the VPN Wireguard \citep{donenfeld_wireguard_2017}. In Figure \ref{fig:whole-network-vpn-infront}, the portals are only accessible via the VPN protected network. It can be seen that the packet in Figure \ref{fig:whole-network-vpn-infront} is shorter, given the removal of the message authentication code and the data sequence number. The data sequence number is unnecessary, given that Wireguard uses the same anti-replay algorithm, and thus replayed packets would have been caught entering the secure network. Further, the message authentication code is unnecessary, as the authenticity of packets is now guaranteed by Wireguard. Packet structures for proxied packets in each of these cases are given in Appendix \ref{appendix:layered-security}, with Figure \ref{fig:whole-network-vpn-behind} and Figure \ref{fig:whole-network-vpn-infront} for the VPN Wireguard \citep{donenfeld_wireguard_2017}. In Figure \ref{fig:whole-network-vpn-infront}, the portals are only accessible via the VPN protected network. It can be seen that the packet in Figure \ref{fig:whole-network-vpn-infront} is shorter, given the removal of the message authentication code and the data sequence number. The data sequence number is unnecessary, given that Wireguard uses the same anti-replay algorithm, and thus replayed packets would have been caught entering the secure network. Further, the message authentication code is unnecessary, as the authenticity of packets is now guaranteed by Wireguard.
\begin{figure}
\begin{leftfullpage}
\centering
\begin{bytefield}[bitwidth=0.6em]{32}
\bitheader{0-31} \\
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$} \\
\begin{rightwordgroup}{UDP\\Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{rightwordgroup} \\
\begin{rightwordgroup}{CC\\Header}
\bitbox{32}{Acknowledgement number} \\
\bitbox{32}{Negative acknowledgement number} \\
\bitbox{32}{Sequence number}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Proxied\\Wireguard\\Packet}
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$} \\
\begin{leftwordgroup}{UDP Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{leftwordgroup} \\
\begin{leftwordgroup}{Wireguard\\Header}
\bitbox{8}{type} & \bitbox{24}{reserved} \\
\wordbox{1}{receiver} \\
\wordbox{2}{counter}
\end{leftwordgroup} \\
\wordbox[tlr]{1}{Proxied IP packet} \\
\skippedwords\\
\wordbox[blr]{1}{}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Security\\Footer}
\bitbox{32}{Data sequence number} \\
\wordbox[tlr]{1}{Message authentication code} \\
\wordbox[blr]{1}{$\cdots$}
\end{rightwordgroup}
\end{bytefield}
\caption{Packet structure for a configuration with a Wireguard client behind my multipath proxy.}
\label{fig:whole-network-vpn-behind}
\end{leftfullpage}
\end{figure}
\begin{figure}
\begin{fullpage}
\centering
\begin{bytefield}[bitwidth=0.6em]{32}
\bitheader{0-31} \\
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$}\\
\begin{rightwordgroup}{UDP\\Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Wireguard\\Header}
\bitbox{8}{type} & \bitbox{24}{reserved} \\
\wordbox{1}{receiver} \\
\wordbox{2}{counter}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Tunnelled\\Proxy\\Packet}
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$}\\
\begin{leftwordgroup}{UDP Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{leftwordgroup} \\
\begin{leftwordgroup}{CC\\Header}
\bitbox{32}{Acknowledgement number} \\
\bitbox{32}{Negative acknowledgement number} \\
\bitbox{32}{Sequence number}
\end{leftwordgroup} \\
\wordbox[tlr]{1}{Proxied IP packet} \\
\skippedwords\\
\wordbox[blr]{1}{}
\end{rightwordgroup}
\end{bytefield}
\caption{Packet structure for a configuration with a Wireguard client in front of my multipath proxy.}
\label{fig:whole-network-vpn-infront}
\end{fullpage}
\end{figure}
Supporting and encouraging this layering of protocols provides a second benefit: if the security in my solution degrades with time, there are two options to repair it. One can either fix the open source application, or compose it with a security solution that is not broken, but perhaps provides redundant security guarantees, translating to additional overhead. To this end, the security features mentioned are all configurable. This allows for flexibility in implementation. Supporting and encouraging this layering of protocols provides a second benefit: if the security in my solution degrades with time, there are two options to repair it. One can either fix the open source application, or compose it with a security solution that is not broken, but perhaps provides redundant security guarantees, translating to additional overhead. To this end, the security features mentioned are all configurable. This allows for flexibility in implementation.

4
3_Implementation/implementation.tex
View File

@ -14,7 +14,7 @@
Implementation of the proxy is in two parts: software that provides a multipath layer 3 tunnel between two hosts, and the system configuration necessary to utilise this tunnel as a proxy. An overview of the software and system is presented in figure \ref{fig:dataflow-overview}. Implementation of the proxy is in two parts: software that provides a multipath layer 3 tunnel between two hosts, and the system configuration necessary to utilise this tunnel as a proxy. An overview of the software and system is presented in figure \ref{fig:dataflow-overview}.
This chapter will detail this implementation in three sections. The software will be described in sections \ref{section:implementation-software-structure} and \ref{section:implementation-producer-consumer}. Section \ref{section:implementation-software-structure} explains the software's structure and dataflow. Section \ref{section:implementation-producer-consumer} details the implementation of both TCP and UDP methods of transporting the tunnelled packets between the hosts. The system configuration will be described in section \ref{section:implementation-system-configuration}, along with a discussion of some of the oddities of multipath routing, such that a reader would have enough knowledge to implement the proxy. This chapter will detail this implementation in three sections. The software will be described in sections \ref{section:implementation-packet-transport} and \ref{section:implementation-producer-consumer}. Section \ref{section:implementation-software-structure} explains the software's structure and dataflow. Section \ref{section:implementation-producer-consumer} details the implementation of both TCP and UDP methods of transporting the tunnelled packets between the hosts. The system configuration will be described in section \ref{section:implementation-system-configuration}, along with a discussion of some of the oddities of multipath routing, such that a reader would have enough knowledge to implement the proxy.
\begin{sidewaysfigure} \begin{sidewaysfigure}
\includegraphics[width=\textheight]{overview.png} \includegraphics[width=\textheight]{overview.png}
@ -189,7 +189,7 @@ A directory tree of the repository is provided in figure \ref{fig:repository-str
% -------------------------- Packet Transport ------------------------------ % % -------------------------- Packet Transport ------------------------------ %
% -------------------------------------------------------------------------- % % -------------------------------------------------------------------------- %
\section{Packet Transport} \section{Packet Transport}
\label{section:implementation-producer-consumer} \label{section:implementation-packet-transport}
As shown in figure \ref{fig:dataflow-overview} and described in section \ref{section:implementation-software-structure}, the interfaces through which transport for packets is provided between the two hosts are producers and consumers. A transport pair is then created between a consumer on one host and a producer on the other, where packets enter the consumer and exit the corresponding producer. Two methods for producers and consumers are implemented: TCP and UDP. As the greedy load balancing of this proxy relies on congestion control, TCP provided a base for a proof of concept, while UDP expands on this proof of concept to produce a usable solution. This section discusses, in section \ref{section:implementation-tcp}, the method of transporting discrete packets across the continuous byte stream of a TCP flow. Then, in section \ref{section:implementation-udp}, it goes on to discuss adding congestion control to UDP datagrams, while avoiding retransmissions. As shown in figure \ref{fig:dataflow-overview} and described in section \ref{section:implementation-software-structure}, the interfaces through which transport for packets is provided between the two hosts are producers and consumers. A transport pair is then created between a consumer on one host and a producer on the other, where packets enter the consumer and exit the corresponding producer. Two methods for producers and consumers are implemented: TCP and UDP. As the greedy load balancing of this proxy relies on congestion control, TCP provided a base for a proof of concept, while UDP expands on this proof of concept to produce a usable solution. This section discusses, in section \ref{section:implementation-tcp}, the method of transporting discrete packets across the continuous byte stream of a TCP flow. Then, in section \ref{section:implementation-udp}, it goes on to discuss adding congestion control to UDP datagrams, while avoiding retransmissions.

18
A1_LanguageSamples/languagesamples.tex
View File

@ -5,24 +5,24 @@
\label{appendix:language-samples} \label{appendix:language-samples}
\begin{figure} \begin{figure}
\inputminted[firstline=1,lastline=48]{cpp}{LanguageSamples/Samples/main.cpp} \inputminted{rust}{A1_LanguageSamples/Samples/main.rs}
\caption{A sample script written in Rust to collect packets from a TUN interface and print them from multiple threads}
\label{fig:rust-tun-sample}
\end{figure}
\begin{figure}
\inputminted[firstline=1,lastline=48]{cpp}{A1_LanguageSamples/Samples/main.cpp}
\caption{A sample script written in C++ to collect packets from a TUN interface and print them from multiple threads} \caption{A sample script written in C++ to collect packets from a TUN interface and print them from multiple threads}
\label{fig:cpp-tun-sample} \label{fig:cpp-tun-sample}
\end{figure} \end{figure}
\begin{figure} \begin{figure}
\ContinuedFloat \ContinuedFloat
\inputminted[firstline=49]{cpp}{LanguageSamples/Samples/main.cpp} \inputminted[firstline=49]{cpp}{A1_LanguageSamples/Samples/main.cpp}
\end{figure} \end{figure}
\begin{figure} \begin{figure}
\inputminted{rust}{LanguageSamples/Samples/main.rs} \inputminted{go}{A1_LanguageSamples/Samples/main.go}
\caption{A sample script written in Rust to collect packets from a TUN interface and print them from multiple threads}
\label{fig:rust-tun-sample}
\end{figure}
\begin{figure}
\inputminted{go}{LanguageSamples/Samples/main.go}
\caption{A sample script written in Go to collect packets from a TUN interface and print them from multiple threads} \caption{A sample script written in Go to collect packets from a TUN interface and print them from multiple threads}
\label{fig:go-tun-sample} \label{fig:go-tun-sample}
\end{figure} \end{figure}

88
A2_LayeredSecurity/layeredsecurity.tex Normal file
View File

@ -0,0 +1,88 @@
%!TEX root = ../thesis.tex
% ********************** Thesis Appendix B - Layered Security *************************
\chapter{Layered Security Packet Diagrams}
\label{appendix:layered-security}
\begin{figure}
\begin{leftfullpage}
\centering
\begin{bytefield}[bitwidth=0.6em]{32}
\bitheader{0-31} \\
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$} \\
\begin{rightwordgroup}{UDP\\Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{rightwordgroup} \\
\begin{rightwordgroup}{CC\\Header}
\bitbox{32}{Acknowledgement number} \\
\bitbox{32}{Negative acknowledgement number} \\
\bitbox{32}{Sequence number}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Proxied\\Wireguard\\Packet}
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$} \\
\begin{leftwordgroup}{UDP Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{leftwordgroup} \\
\begin{leftwordgroup}{Wireguard\\Header}
\bitbox{8}{type} & \bitbox{24}{reserved} \\
\wordbox{1}{receiver} \\
\wordbox{2}{counter}
\end{leftwordgroup} \\
\wordbox[tlr]{1}{Proxied IP packet} \\
\skippedwords\\
\wordbox[blr]{1}{}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Security\\Footer}
\bitbox{32}{Data sequence number} \\
\wordbox[tlr]{1}{Message authentication code} \\
\wordbox[blr]{1}{$\cdots$}
\end{rightwordgroup}
\end{bytefield}
\caption{Packet structure for a configuration with a Wireguard client behind my multipath proxy.}
\label{fig:whole-network-vpn-behind}
\end{leftfullpage}
\end{figure}
\begin{figure}
\begin{fullpage}
\centering
\begin{bytefield}[bitwidth=0.6em]{32}
\bitheader{0-31} \\
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$}\\
\begin{rightwordgroup}{UDP\\Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Wireguard\\Header}
\bitbox{8}{type} & \bitbox{24}{reserved} \\
\wordbox{1}{receiver} \\
\wordbox{2}{counter}
\end{rightwordgroup} \\
\begin{rightwordgroup}{Tunnelled\\Proxy\\Packet}
\wordbox[tlr]{1}{IPv4 Header} \\
\wordbox[blr]{1}{$\cdots$}\\
\begin{leftwordgroup}{UDP Header}
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
\bitbox{16}{Length} & \bitbox{16}{Checksum}
\end{leftwordgroup} \\
\begin{leftwordgroup}{CC\\Header}
\bitbox{32}{Acknowledgement number} \\
\bitbox{32}{Negative acknowledgement number} \\
\bitbox{32}{Sequence number}
\end{leftwordgroup} \\
\wordbox[tlr]{1}{Proxied IP packet} \\
\skippedwords\\
\wordbox[blr]{1}{}
\end{rightwordgroup}
\end{bytefield}
\caption{Packet structure for a configuration with a Wireguard client in front of my multipath proxy.}
\label{fig:whole-network-vpn-infront}
\end{fullpage}
\end{figure}

2
thesis-info.tex
View File

@ -62,7 +62,7 @@
%\renewcommand{\submissiontext}{change the default text here if needed} %\renewcommand{\submissiontext}{change the default text here if needed}
%% Full title of the Degree %% Full title of the Degree
\degreetitle{Bachelor of Arts} \degreetitle{Computer Science Tripos - Part II}
%% College affiliation (optional) %% College affiliation (optional)
\college{Queens' College} \college{Queens' College}

7
thesis.tex
View File

@ -175,9 +175,10 @@
%TC:ignore %TC:ignore
\begin{appendices} % Using appendices environment for more functunality \begin{appendices} % Using appendices environment for more functunality
\include{LanguageSamples/languagesamples} \include{A1_LanguageSamples/languagesamples}
\include{OutboundGraphs/outboundgraphs} \include{A2_LayeredSecurity/layeredsecurity}
\include{Proposal/proposal} \include{A3_OutboundGraphs/outboundgraphs}
\include{A4_ProjectProposal/proposal}
\end{appendices} \end{appendices}