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

Update on Overleaf.

Browse Source
This commit is contained in:
jsh77 2021-05-13 08:19:39 +00:00 committed by overleaf
parent 15e8ab0f7b
commit 27772fe86b
3 changed files with 19 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
1_Introduction/introduction.tex
View File

@ -39,25 +39,21 @@ For each Layer 3 packet that Wireguard transports, it generates and sends a sing
\subsection{Cloudflare} \subsection{Cloudflare}
Cloudflare is a company that uses a global network of servers to provide a variety of infrastructure products, mostly pertaining to websites and security. Two of the products offered by Cloudflare are of particular interest to this project: load balancing and magic WAN. Cloudflare is a company that uses a global network of servers to provide a variety of infrastructure products, mostly pertaining to websites and security \citep{cloudflare_cloudflare_nodate}. Two of the products offered by Cloudflare are of particular interest to this project: load balancing and magic WAN.
Cloudflare provides the option to proxy HTTPS traffic via their global network of servers to your origin server. This layer 7 (application layer) proxy, meaning that it operates on the level of proxying HTTP requests themselves, can take advantage of this knowledge of connections to provide effective load balancing between origin servers. Similarly to this project, Cloudflare can use knowledge of the responsiveness of origin servers to alter the load balancing. This is a similar use case as in this proxy, where items (HTTP requests / IP packets) hit one high bandwidth server (one of Cloudflare's edge servers / the remote proxy), and this server decides which path through which to proxy the item (a chosen origin server / which connection to the local proxy). Cloudflare provides the option to proxy HTTPS traffic via their global network of servers to your origin server. This layer 7 (application layer) proxy operates on the level of proxying HTTP requests themselves, and can take advantage of its knowledge of connections to provide effective load balancing between origin servers. Similarly to my project, Cloudflare can use knowledge of the responsiveness of origin servers to alter the load balancing. This is a similar use case to my proxy, where items (HTTP requests / IP packets) hit one high bandwidth server (one of Cloudflare's edge servers / the remote proxy), and this server decides which path through which to proxy the item (a chosen origin server / which connection to the local proxy).
Unlike Cloudflare load balancing, the proxy presented in this work operates on layer 3. Cloudflare receives a stream of HTTPS requests and forwards each on to a chosen origin server, while the remote proxy receives a stream of IP packets and forwards them via a chosen path to the local proxy. Though these achieve different goals, Cloudflare load balancing provides an example of using a high bandwidth edge server to manage balancing between multiple lesser bandwidth endpoints. Unlike Cloudflare load balancing, the proxy presented in this work operates on layer 3. Cloudflare receives a stream of HTTPS requests and forwards each on to a chosen origin server, while my remote proxy receives a stream of IP packets and forwards them via a chosen path to my local proxy. Though these achieve different goals, Cloudflare load balancing provides an example of using a high bandwidth edge server to manage balancing between multiple lower bandwidth endpoints.
The second product of Cloudflare's that shows some similarity to this project is Magic WAN. Cloudflare Magic WAN provides a fully software defined WAN over their global network. That is, their anycast infrastructure will accept traffic to your network at any of the edge servers on their global infrastructure, before forwarding it to you. This provides some significant benefits, such as DDoS mitigation and firewalling at a far higher capacity than on your origin servers. When a DDoS attack or connections against firewall policies occur, they are cut off at the Cloudflare edge, without ever reaching the limited bandwidth of your local system. The second product of Cloudflare's that shows some similarity to my project is Magic WAN. Cloudflare Magic WAN provides a fully software defined WAN over their global network. That is, their anycast infrastructure will accept traffic to your network at any of the edge servers in their global infrastructure before forwarding it to you. This provides some significant benefits, such as DDoS mitigation and firewalling at a far higher capacity than on your origin servers. When a DDoS attack or connections against firewall policies occur, they are cut off at the Cloudflare edge, without ever reaching the limited bandwidth of your local system.
Magic WAN demonstrates that there can be security benefits to moving your network edge to the cloud. By configuring to block bad traffic at the edge, the limited bandwidth connections at your origin are protected. It further demonstrates that WAN-as-a-Service is possible at a large scale, which is the class of products that this proxy falls in. Magic WAN demonstrates that there can be security benefits to moving your network edge to the cloud. By configuring to block bad traffic at the edge, the limited bandwidth connections at your origin are protected. It further demonstrates that WAN-as-a-Service is possible at a large scale, which is the same class of products as my proxy.
Though neither of these Cloudflare products solve the aims of this proxy, specifically multipath, they show how cloud infrastructure can be leveraged to support the Internet connections of services in different capacities. Though neither of these Cloudflare products solve the aims of my proxy, specifically the multipath problem, they show how cloud infrastructure can be leveraged to support the Internet connections of services in different capacities.
\mynote{QUESTION: How to correctly reference these products?}
\section{Aims} \section{Aims}
\mynote{Probably replace this. `This project aimed to produce proxy software that uses congestion control to manage multiple paths of data flow, intended to be across discrete Internet connections. Such a proxy should...`} This project aims to produce proxy software that uses congestion control to manage transporting packets across multiple paths of data flow, including across discrete Internet connections. When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience, and latency. This project aims to improve throughput and resilience at the cost of latency. By using a layer 3 proxy for entire IP packets, connections are combined in a way that is transparent to devices on both sides of the proxy, overcoming the throughput and availability limitations of each individual connection. The basic structure of this proxy system is shown in Figure \ref{fig:proxy-components}.
This project aims to produce proxy software that uses congestion control to manage transporting packets across multiple paths of data flow, intended to be across discrete Internet connections. When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience, and latency. This project aims to provide throughput and resilience at the cost of latency. By using a layer 3 proxy which carrying entire IP packets, connections are combined in a way that is transparent to devices on both sides of the proxy, overcoming the throughput and availability limitations of each individual connection. The basic structure of such a proxy system is shown in Figure \ref{fig:proxy-components}.
\begin{figure} \begin{figure}
\centering \centering

12
2_Preparation/preparation.tex
View File

@ -10,9 +10,7 @@
\graphicspath{{2_Preparation/Figs/Vector/}{2_Preparation/Figs/}} \graphicspath{{2_Preparation/Figs/Vector/}{2_Preparation/Figs/}}
\fi \fi
Proxying packets is the process of taking packets that arrive at one location and transporting them to leave at another. This Chapter focuses on the preparatory work to achieve this practically and securely, given the design outlined in the previous Chapter, in which the proxy consolidates multiple connections to appear as one to both the wider Internet and devices on the local network. In Sections \ref{section:risk-analysis} and \ref{section:preparation-security}, I discuss the security risks and plans to confront them. In Section \ref{section:language-selection}, I present three languages: Go, Rust and C++, and provide context for choosing Go as the implementation language. Finally, in Sections \ref{section:requirements-analysis} and \ref{section:engineering-approach}, I present a requirements analysis and a description of the engineering approach for the project. Proxying packets is the process of taking packets that arrive at one location and transporting them to leave at another. This chapter focuses on the preparatory work to achieve this practically and securely, given the design outlined in the previous chapter, in which the proxy consolidates multiple connections to appear as one to both the wider Internet and devices on the local network. In Sections \ref{section:risk-analysis} and \ref{section:preparation-security}, I discuss the security risks and plans to confront them. In Section \ref{section:language-selection}, I present three languages: Go, Rust and C++, and provide context for choosing Go as the implementation language. Finally, in sections \ref{section:requirements-analysis} and \ref{section:engineering-approach}, I present a requirements analysis and a description of the engineering approach for the project.
\mynote{QUESTION: Should 'Sections' be capitalised?}
% ---------------------------- Risk Analysis ------------------------------- % % ---------------------------- Risk Analysis ------------------------------- %
\section{Security Analysis} \section{Security Analysis}
@ -25,9 +23,9 @@ Proxying packets is the process of taking packets that arrive at one location an
\label{fig:security-zones} \label{fig:security-zones}
\end{figure} \end{figure}
Any connection between two computers presents a set of security risks. A proxy consists of both these risks, and further, which I will present and discuss in this Section. Firstly, this focuses on layered security. This is the case of the Local Portal and Remote Portal, with everything in between, being viewed as an Internet connection. The focus is on how the risks compare to that of a standard Internet connection, and what guarantees must be made to achieve the same risks for a proxied connection as for a standard connection. Any connection between two computers presents a set of security risks. A proxy consists of both these risks, and further, which I will present and discuss in this section. Firstly, this focuses on layered security. This is the case of the Local Portal and Remote Portal, with everything in between, being viewed as an Internet connection. The focus is on how the risks compare to that of a standard Internet connection, and what guarantees must be made to achieve the same risks for a proxied connection as for a standard connection.
The transportation of packets is in three sections, as shown in Figure \ref{fig:security-zones}. The first segment of the figure is client to portal, which occurs physically in the local zone. Secondly is portal to portal, which occurs across the Internet. Finally is portal to server, which also occurs across the Internet. With the goal of providing security equivalent to a standard connection, the client to portal communication can be considered safe - it is equivalent to connecting a client directly to a modem. Therefore, this Section will focus on the transports of portal to portal, and portal to server communication. The threat model for this analysis will now be described. The transportation of packets is in three sections, as shown in Figure \ref{fig:security-zones}. The first segment of the figure is client to portal, which occurs physically in the local zone. Secondly is portal to portal, which occurs across the Internet. Finally is portal to server, which also occurs across the Internet. With the goal of providing security equivalent to a standard connection, the client to portal communication can be considered safe - it is equivalent to connecting a client directly to a modem. Therefore, this section will focus on the transports of portal to portal, and portal to server communication. The threat model for this analysis will now be described.
\subsection{Threat Model} \subsection{Threat Model}
\label{section:threat-model} \label{section:threat-model}
@ -59,7 +57,7 @@ Packets between the portal and server are transmitted openly across the Internet
\section{Security Solutions} \section{Security Solutions}
\label{section:preparation-security} \label{section:preparation-security}
This Section provides means of alleviating the risks given in Section \ref{section:risk-analysis}. To achieve this goal, the authenticity of packets will be verified. Authenticity in this context means two properties of the object hold: integrity and freshness \citep[pp. 14]{anderson_security_2008}. Integrity guarantees that any modification between the sending and receiving portals can be detected, while freshness guarantees that reuse of a previously transmitted packet can be detected. This section provides means of alleviating the risks given in Section \ref{section:risk-analysis}. To achieve this goal, the authenticity of packets will be verified. Authenticity in this context means two properties of the object hold: integrity and freshness \citep[pp. 14]{anderson_security_2008}. Integrity guarantees that any modification between the sending and receiving portals can be detected, while freshness guarantees that reuse of a previously transmitted packet can be detected.
\subsection{Message Authentication} \subsection{Message Authentication}
@ -188,7 +186,7 @@ The benefits of using a VPN tunnel between the two proxies are shown in Figure \
\section{Language Selection} \section{Language Selection}
\label{section:language-selection} \label{section:language-selection}
In this Section, I evaluate three potential languages (C++, Rust and Go) for the implementation of this software. To support this evaluation, I have provided a sample program in each language. The sample program is intended to be a minimal example of reading packets from a TUN interface, 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}, in appendix \ref{appendix:language-samples}. The first test will be whether the small example is possible, which passed for all three languages. Then, considerations will be the performance of the language, clarity of code of the style needed to complete this software, and the ecosystem of the language. This culminates in choosing Go for the implementation language. In this section, I evaluate three potential languages (C++, Rust and Go) for the implementation of this software. To support this evaluation, I have provided a sample program in each language. The sample program is intended to be a minimal example of reading packets from a TUN interface, 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}, in appendix \ref{appendix:language-samples}. The first test will be whether the small example is possible, which passed for all three languages. Then, considerations will be the performance of the language, clarity of code of the style needed to complete this software, and the ecosystem of the language. This culminates in choosing Go for the implementation language.
Alongside the implementation language, a language is chosen to evaluate the implementation. Two potential languages are considered here, Python and Java. Though Python was initially chosen for rapid development and better ecosystem support, the final result is a combination of both Python and Java - Python for data processing, and Java for systems interaction. Alongside the implementation language, a language is chosen to evaluate the implementation. Two potential languages are considered here, Python and Java. Though Python was initially chosen for rapid development and better ecosystem support, the final result is a combination of both Python and Java - Python for data processing, and Java for systems interaction.

13
PhDThesisPSnPDF.cls
View File

@ -932,7 +932,14 @@ wish to left align your text}
\thispagestyle{empty} \thispagestyle{empty}
% Author
\vspace*{-5.5em}
\hspace{14em}
{\usebox{\PHD@author}}
\vspace*{6.5em}
\begin{singlespace} \begin{singlespace}
\begin{center} \begin{center}
% University Crest Long if college crest is defined % University Crest Long if college crest is defined
@ -957,12 +964,6 @@ wish to left align your text}
\vspace{.15\PHD@titlepagespacing} \vspace{.15\PHD@titlepagespacing}
\fi \fi
% Author
{\usebox{\PHD@author}}
\vspace*{1em}
% Supervisor % Supervisor
\ifPHD@supervisor% \ifPHD@supervisor%
{\usebox{\PHD@supervisor}} {\usebox{\PHD@supervisor}}