Reset to compilable state
This commit is contained in:
parent
0a95b2a693
commit
87d93c2ebb
@ -86,7 +86,90 @@ 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
\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.
|
||||
|
||||
|
@ -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}.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
\begin{sidewaysfigure}
|
||||
\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 ------------------------------ %
|
||||
% -------------------------------------------------------------------------- %
|
||||
\section{Packet Transport}
|
||||
\label{section:implementation-packet-transport}
|
||||
\label{section:implementation-producer-consumer}
|
||||
|
||||
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.
|
||||
|
||||
|
@ -5,24 +5,24 @@
|
||||
\label{appendix:language-samples}
|
||||
|
||||
\begin{figure}
|
||||
\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}
|
||||
\inputminted[firstline=1,lastline=48]{cpp}{LanguageSamples/Samples/main.cpp}
|
||||
\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}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}
|
||||
\ContinuedFloat
|
||||
\inputminted[firstline=49]{cpp}{A1_LanguageSamples/Samples/main.cpp}
|
||||
\inputminted[firstline=49]{cpp}{LanguageSamples/Samples/main.cpp}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}
|
||||
\inputminted{go}{A1_LanguageSamples/Samples/main.go}
|
||||
\inputminted{rust}{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{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}
|
||||
\label{fig:go-tun-sample}
|
||||
\end{figure}
|
||||
|
@ -62,7 +62,7 @@
|
||||
%\renewcommand{\submissiontext}{change the default text here if needed}
|
||||
|
||||
%% Full title of the Degree
|
||||
\degreetitle{Computer Science Tripos - Part II}
|
||||
\degreetitle{Bachelor of Arts}
|
||||
|
||||
%% College affiliation (optional)
|
||||
\college{Queens' College}
|
||||
|
@ -175,10 +175,9 @@
|
||||
%TC:ignore
|
||||
\begin{appendices} % Using appendices environment for more functunality
|
||||
|
||||
\include{A1_LanguageSamples/languagesamples}
|
||||
\include{A2_LayeredSecurity/layeredsecurity}
|
||||
\include{A3_OutboundGraphs/outboundgraphs}
|
||||
\include{A4_ProjectProposal/proposal}
|
||||
\include{LanguageSamples/languagesamples}
|
||||
\include{OutboundGraphs/outboundgraphs}
|
||||
\include{Proposal/proposal}
|
||||
|
||||
\end{appendices}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user