Update on Overleaf.
This commit is contained in:
overleaf
parent
5abb8fc0c9
commit
0248ba39b6
@ -41,7 +41,7 @@ The threat model considered here will be that packets can be injected, read, and
|
||||
\label{fig:security-zones-attackers}
|
||||
\end{figure}
|
||||
|
||||
There are four locations to insert or remove packets in the transport between the two proxies, as shown in Figure \ref{fig:security-zones-attackers}. In this case, Alice can insert packets to the local proxy to be sent to the client, Bob can insert packets to the remote proxy to be sent to the world, Charlie can steal packets from the local proxy destined for the remote portal, and Dave can steal packets from the remote proxy destined for the local proxy. Each of these will be examined for the impact that it would cause.
|
||||
There are four locations to insert or remove packets in the transport between the two proxies, as shown in Figure \ref{fig:security-zones-attackers}. In this case, Alice can insert packets to the local proxy to be sent to the client, Bob can insert packets to the remote proxy to be sent to the world, Charlie can steal packets from the local proxy destined for the remote proxy, and Dave can steal packets from the remote proxy destined for the local proxy. Each of these will be examined for the impact that it would cause.
|
||||
|
||||
The impact of Alice inserting packets of their choosing to the local proxy is none. Considering a client connected directly to a modem, any device on the Internet is able to send packets to this modem. In the case of Alice inserting these packets, they could simply send the packets to the remote proxy instead, achieving the same effect. As such, inserting packets destined for the client presents no additional risk.
|
||||
|
||||
@ -73,7 +73,7 @@ To prevent such forwarding attacks, the connection itself must be authenticated.
|
||||
|
||||
The second is a more dynamic solution. The IP authentication header \citep{kent_ip_2005} achieves this by protecting all immutable parts of the IP header with an authentication code. In the case of this software, authenticating the source IP address, source port, destination IP address, and destination port ensures connection authenticity. By authenticating these addresses, which can be checked easily at both ends, it can be confirmed that both devices knew with whom they were talking, and from where the connection was initiated. That is, an owner of the shared key authorised this communication path.
|
||||
|
||||
However, both of these solutions have some shortfalls when Network Address Translation (NAT) is involved. The second solution, authenticating addresses, fails with any form of NAT (Network Address Translation). This is because the IPs and ports of the packets sent by the sending proxy are different to when they will be received by the receiving proxy, and therefore cannot be authenticated. The first solution, providing a set of addresses, fails with Carrier Grade NAT (CG-NAT), as many users share the IP address, and hence anyone under the same IP could perform an attack. In most cases one of these solutions will work, else one can fail over to the security layering presented in Section \ref{section:layered-security}.
|
||||
However, both of these solutions have some shortfalls when Network Address Translation (NAT) is involved. The second solution, authenticating addresses, fails with any form of NAT. This is because the IPs and ports of the packets sent by the sending proxy are different to when they will be received by the receiving proxy, and therefore cannot be authenticated. The first solution, providing a set of addresses, fails with Carrier Grade NAT (CG-NAT), as many users share the same IP address, and hence anyone under the same IP could perform an attack. In most cases one of these solutions will work, else one can fail over to the security layering presented in Section \ref{section:layered-security}.
|
||||
|
||||
\subsection{Freshness}
|
||||
|
||||
@ -86,7 +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.
|
||||
|
||||
Packet structures for proxied packets in each of these cases are given in Appendix \ref{appendix:layered-security}, as 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}, as 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 proxies 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.
|
||||
|
||||
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.
|
||||
|
||||
@ -122,7 +122,7 @@ For the purposes of this project, the downsides of Rust come from its youthfulne
|
||||
|
||||
\subsubsection{Go}
|
||||
|
||||
The final language to evaluate is Go, often written as GoLang. The primary difference between Go and the other two evaluated languages is the presence of a runtime. The code 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 standard than Rust.
|
||||
The final language to evaluate is Go, often written as GoLang. The primary difference between Go and the other two evaluated languages is the presence of a runtime. The code sample is 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 standard 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 support any number of both producers and consumers. In this project, both SPMC (Single Producer Multi Consumer) and MPSC (Multi Producer Single Consumer) queues are required, so having these provided as a first class feature of the language is beneficial.
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@ This chapter will detail this implementation in three sections. The software wil
|
||||
\section{Packet Transport}
|
||||
\label{section:implementation-packet-transport}
|
||||
|
||||
As shown in Figure \ref{fig:dataflow-overview}, the interfaces through which transport for packets is provided between the two hosts are producers and consumers. A transport pair is then between a consumer on one proxy 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 remove unnecessary overhead and improve performance in the case of TCP-over-TCP tunnelling. This section discusses, in section \ref{section:implementation-tcp}, the method of transporting discrete packets across the continuous byte stream of a TCP flow, before describing why this solution is not ideal. Then, in section \ref{section:implementation-udp}, it goes on to discuss adding congestion control to UDP datagrams, while avoiding ever retransmitting a proxied packet.
|
||||
As shown in Figure \ref{fig:dataflow-overview}, the interfaces through which transport for packets is provided between the two hosts are producers and consumers. A transport pair is between a consumer on one proxy 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 remove unnecessary overhead and improve performance in the case of TCP-over-TCP tunnelling. This section discusses, in section \ref{section:implementation-tcp}, the method of transporting discrete packets across the continuous byte stream of a TCP flow, before describing why this solution is not ideal. Then, in section \ref{section:implementation-udp}, it goes on to discuss adding congestion control to UDP datagrams, while avoiding ever retransmitting a proxied packet.
|
||||
|
||||
\subsection{TCP}
|
||||
\label{section:implementation-tcp}
|
||||
@ -140,7 +140,7 @@ Given the decision to use ACKs and NACKs, the packet structure for UDP datagrams
|
||||
|
||||
TCP New Reno \citep{henderson_newreno_2012} is widely known for its sawtooth pattern of throughput. New Reno is an RTT-based congestion control mechanism, which, in the steady state, increases the window size (number of packets in flight at a time) by 1 for each successful window. In the case of a retransmission, this quantity halves. The window size is the quantity of packets that can be in flight at one time, which depends on the round trip time, as a longer round trip time requires a larger window size to transmit the same amount of packets. For a freshly started New Reno connection, slow start occurs, which increases the window size by 1 for each packet transmitted successfully, as opposed to each full window of packets. This creates an exponential curve, which stops on the first transmission failure.
|
||||
|
||||
To implement an algorithm that performs similarly with works identically for a flawless connection. That is, if no packets are lost, the implementation is identical. This includes increasing the window size by one for each successfully transmitted packet initially, and dropping to increasing by one for each window size later in the process. The difference from TCP's mechanisms arises when packets are lost, and more specifically, how that is detected. This is the NACK mechanism, which sets the NACK to the missing packet if a packet has been waiting for more than $0.5*RTT$ to be acknowledged. This occurs when packet 4 arrives before packet 3, and packet 3 has still not arrived after an additional half of the round trip time (the entire time expected for the packet to arrive), and would cause the NACK field on the next packet to be set to 3, with the ACK field set to 4. When the sender receives this NACK response, it affects the window size as TCP would (halving the size, and stopping slow start).
|
||||
An algorithm that performs similarly but takes advantage of NACKs works identically for a flawless connection. That is, if no packets are lost, the implementation is identical. This includes increasing the window size by one for each successfully transmitted packet initially, and dropping to increasing by one for each window size later in the process. The difference from TCP's mechanisms arises when packets are lost, and more specifically, how that is detected. This is the NACK mechanism, which sets the NACK to the missing packet if a packet has been waiting for more than $0.5*RTT$ to be acknowledged. This occurs when packet 4 arrives before packet 3, and packet 3 has still not arrived after an additional half of the round trip time (the entire time expected for the packet to arrive), and would cause the NACK field on the next packet to be set to 3, with the ACK field set to 4. When the sender receives this NACK response, it affects the window size as TCP would (halving the size, and stopping slow start).
|
||||
|
||||
The congestion control algorithm has multiple threads accessing it at any one time, so uses a mixture of atomic operations and fine-grained locking to remain consistent. The \texttt{ack}, \texttt{nack} and \texttt{windowSize} fields all use atomic operations, such that they can be read immediately and allow a packet to almost be sent without gaining a lock. However, the \texttt{inFlight} and \texttt{awaitingAck} fields are each protected by a mutex, ensuring that they remain consistent. This is a compromise between performance and correctness, limiting code complexity while allowing more performance than coarse-grained locks. Further, high-level data structures (specifically, growable lists) are used, which reduce programming complexity at the cost of some performance. This allows for good readability, and increases the likelihood of writing correct code.
|
||||
|
||||
@ -154,32 +154,6 @@ Congestion control is one of the main point for tests in the repository. The New
|
||||
|
||||
This section details the design decisions behind the application structure, and how it fits into the systems where it will be used. Much of the focus is on the flexiblity of the interfaces to future additions, while also describing the concrete implementations available with the software as of this work.
|
||||
|
||||
% ------------------------------- Proxy ------------------------------------ %
|
||||
\subsection{Proxy}
|
||||
\label{section:implementation-proxy}
|
||||
|
||||
The central structure for the operation of the software is the \verb'Proxy' struct. The proxy is defined by its source and sink, and provides methods for \verb'AddConsumer' and \verb'AddProducer'. The proxy coordinates the dispatching of sourced packets to consumers, and the delivery of produced packets to the sink. This follows the packet data path shown in Figure \ref{fig:dataflow-overview}.
|
||||
|
||||
The proxy is implemented to take a consistent sink and source and accept consumers and producers that vary over the lifetime. This is due to the nature of producers and consumers, as each may be either ephemeral or persistent, depending on the configuration. An example is a device that accepts TCP connections and makes outbound UDP connections. In such a case, the TCP producers and consumers would be ephemeral, existing only until they are closed by the far side. The UDP producers and consumers are persistent, as control of reconnection is handled by this proxy. As the configuration is deliberately intended to be flexible, both of these can exist within the same proxy instance.
|
||||
|
||||
The structure of the proxy is built around the flow graph in Figure \ref{fig:dataflow-overview}. The packet flow demonstrates the four transfers of data that occur within the software: packet source (TUN adapter) to source queue, source queue to consumer, producer to sink queue, and sink queue to packet sink (TUN adapter). For the former and latter, these exist once for an instance of the proxy. The others run once for each consumer or producer. The lifetime of producers and consumers are controlled by the lifetime of these data flow loops and are only referenced within them, such that the garbage collector can collect any producers and consumers for which the loops have exited.
|
||||
|
||||
Finally is the aforementioned ability for the central proxy to restart consumers or producers that support it (those initiated by the proxy in question). Pseudocode for a consumer is shown in Figure \ref{fig:proxy-loops-restart}. Whenever a producer or consumer terminates, and is found to be restartable, the application attempts to restart it until succeeding and re-entering the work loop.
|
||||
|
||||
\begin{figure}
|
||||
\begin{minted}{python}
|
||||
do:
|
||||
while is_reconnectable(consumer) and not is_alive(consumer):
|
||||
reconnect(consumer)
|
||||
while is_alive(consumer):
|
||||
packet = source_queue.popOrBlock()
|
||||
consumer.consume(packet)
|
||||
while is_reconnectable(consumer)
|
||||
\end{minted}
|
||||
\caption{Pseudocode for a consumer, supporting reconnection.}
|
||||
\label{fig:proxy-loops-restart}
|
||||
\end{figure}
|
||||
|
||||
% ---------------------- Running the Application --------------------------- %
|
||||
\subsection{Running the Application}
|
||||
|
||||
@ -215,7 +189,7 @@ The integrated security solution of this software is in two parts: message authe
|
||||
|
||||
\subsubsection{Message Authenticity Verification}
|
||||
|
||||
Message authentication is provided by a pair of interfaces, \verb'MacGenerator' and \verb'MacVerifier'. \verb'MacGenerator' provides a method which takes input data and produces a list of bytes as output, to be appended to the message. \verb'MacVerifier' takes the appended bytes to the message, and confirms whether they are valid for that message.
|
||||
Message authentication is provided by a pair of interfaces, \texttt{MacGenerator} and \texttt{MacVerifier}, which add bytes at consumers and remove bytes at producers respectively. \texttt{MacGenerator} provides a method which takes input data and produces a list of bytes as output, to be appended to the message. \texttt{MacVerifier} takes the appended bytes to the message, and confirms whether they are valid for that message.
|
||||
|
||||
The provided implementation for message authenticity uses the BLAKE2s \citep{hutchison_blake2_2013} algorithm. By using library functions, the implementation is achieved simply by matching the interface provided by the library and the interface mentioned here. This ensures clarity, and reduces the likelihood of introducing a bug.
|
||||
|
||||
@ -227,14 +201,6 @@ Repeat protection takes advantage of the same two interfaces already mentioned.
|
||||
|
||||
One difference between repeat protection and MAC generation is that repeat protection is shared between all producers and consumers. This is in contrast to the message authenticity, which are, as implemented, specific to a producer or consumer. The currently implemented repeat protection is that of \cite{tsou_ipsec_2012}. The code sample is provided with a BSD license, so is compatible with this project, and hence was simply adapted from C to Go. This is created at a host level when building the proxy, and the same shared amongst all producers, so has to be thread safe. Producing the sequence numbers is achieved with a single atomic operation, avoiding the need to lock at all. Verifying the sequences requires altering multiple elements of an array of bytes, so uses locking to ensure consistency. Ensuring that locks are only taken when necessary makes the calls as efficient as possible.
|
||||
|
||||
\subsubsection{Exchange}
|
||||
|
||||
The \verb'Exchange' interface provides for a cryptographic exchange, but is flexible enough to be used for other purposes too, as will be described for UDP congestion control. When beginning a flow, an ordered list of the \verb'Exchange' type is supplied. These exchanges are then performed in order until each has completed. If any exchange fails, the process returns to the beginning.
|
||||
|
||||
Currently, no cryptographic exchange is necessary, as the methods mentioned above are symmetric. However, the exchange interface is taken advantage of when beginning a UDP flow. As UDP requires an initial exchange to initiate congestion control and establish a connection with the other node, this exchange interface is used. By pairing the congestion controller with the initial UDP exchange, the exchange interacts with the congestion controller, setting up the state correctly for the continuing connection.
|
||||
|
||||
This demonstrates the flexibility of combining the exchange interface with other objects. Although the software does not currently implement any key exchange algorithms, this is possible with the interfaces as described. Simply provide a type that implements both \verb'Exchange' and \verb'MacGenerator'. During the exchange, the keys needed for message authentication can be inserted directly into the structure, after which it will work for the lifetime of the consumer.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{tikzpicture}[
|
||||
@ -262,14 +228,14 @@ This demonstrates the flexibility of combining the exchange interface with other
|
||||
\draw[<->] (cc.east) -- (sequence.west);
|
||||
\draw[<->] (sequence.east) -- (data.west);
|
||||
\end{tikzpicture}
|
||||
\caption{Data flow of a UDP packet through the application.}
|
||||
\caption{Expansion of a UDP packet through a consumer/producer.}
|
||||
\label{fig:udp-packet-dataflow}
|
||||
\end{figure}
|
||||
|
||||
% ------------------------ Repository Overview ----------------------------- %
|
||||
\subsection{Repository Overview}
|
||||
|
||||
A directory tree of the repository is provided in Figure \ref{fig:repository-structure}. The top level is split between \verb'code' and \verb'evaluation', where \verb'code' is compiled into the application binary, and \verb'evaluation' is used to verify the performance characteristics and generate graphs. The Go code is built with the Go modules system, the Java code built with Gradle, and the Python code runs in an iPython notebook. Go tests are interspersed with the code, for example in a file named \texttt{flow\_test.go}, providing tests for \texttt{flow.go} in the same directory.
|
||||
A directory tree of the repository is provided in Figure \ref{fig:repository-structure}. The top level is split between \verb'code' and \verb'evaluation', where \verb'code' is compiled to produce the application binary, and \verb'evaluation' is used to verify the performance characteristics and generate graphs. The Go code is built with the Go modules system, the Java code built with Gradle, and the Python code runs in an iPython notebook. Go tests are interspersed with the code, for example in a file named \texttt{flow\_test.go}, providing tests for \texttt{flow.go} in the same directory.
|
||||
|
||||
\begin{figure}
|
||||
\dirtree{%
|
||||
@ -287,6 +253,7 @@ A directory tree of the repository is provided in Figure \ref{fig:repository-str
|
||||
.3 tun\DTcomment{TUN adapter}.
|
||||
.3 udp\DTcomment{UDP datagram transport}.
|
||||
.4 congestion\DTcomment{Congestion control methods}.
|
||||
.3 .drone.yml\DTcomment{CI specification}.
|
||||
.2 evaluation\DTcomment{Result gathering and graph generation}.
|
||||
.3 java\DTcomment{Java automated result gathering}.
|
||||
.3 python\DTcomment{Python graph generation}.
|
||||
|
||||
@ -11,15 +11,7 @@
|
||||
\graphicspath{{4_Evaluation/Figs/Vector/}{4_Evaluation/Figs/}}
|
||||
\fi
|
||||
|
||||
This chapter will discuss the methods used to evaluate my project and the results gained. The results will be discussed in the context of the success criteria laid out in the Project Proposal (Appendix \ref{appendix:project-proposal}).
|
||||
|
||||
This evaluation shows that a network using my method of combining Internet connections can see vastly superior network performance to one without. It will show the benefits to throughput, availability, and adaptability.
|
||||
|
||||
\section{Evaluation Methodology}
|
||||
|
||||
I performed my experiments on a local Proxmox\footnote{\url{https://proxmox.com}} server. To encourage frequent and thorough testing, a harness was built in Python, allowing tests to be added easily and repeated with any code changes.
|
||||
|
||||
Proxmox was chosen due to its RESTful API, for integration with Python. It provides the required tools to limit connection speeds and disable connections. The server that ran these tests holds only a single other virtual machine which handles routing. This limits the effect of external factors on the tests.
|
||||
This chapter will discuss the methods used to evaluate my project and the results gained. The results will be discussed in the context of the success criteria laid out in the Project Proposal (Appendix \ref{appendix:project-proposal}). This evaluation shows that a network using my method of combining Internet connections can see vastly superior network performance to one without. It will show the benefits to throughput, availability, and adaptability.
|
||||
|
||||
The tests are performed on a Dell R710 Server with the following specifications:
|
||||
|
||||
@ -30,42 +22,7 @@ The tests are performed on a Dell R710 Server with the following specifications:
|
||||
\textbf{Kernel} & Linux 5.4 LTS
|
||||
\end{tabular}
|
||||
|
||||
\subsection{Data Gathering}
|
||||
|
||||
To generate these results, a fresh set of VMs (Virtual Machines) are created and the software installed on them. Once this is complete, each test begins, and is repeated a fixed number of times. When visualising the data produced, unless otherwise specified, the error bars will represent the inter-quartile range of the data, and the plotted point the median.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{tikzpicture}[
|
||||
squarednode/.style={rectangle, draw=black!60, fill=red!5, very thick, minimum size=5mm},
|
||||
]
|
||||
|
||||
% Nodes
|
||||
\node[squarednode] at (0,0) (speedtest) {Speed Test Server};
|
||||
\node[squarednode] at (4,0) (remoteportal) {Remote Proxy};
|
||||
\node[squarednode] at (8,0) (localportal) {Local Proxy};
|
||||
\node[squarednode] at (11,0) (client) {Client};
|
||||
|
||||
% Edges
|
||||
\draw[->] ([yshift=6mm]speedtest.north) -- (speedtest.north);
|
||||
\draw[->] ([yshift=6mm]remoteportal.north) -- (remoteportal.north);
|
||||
\draw[->] ([xshift=-7mm,yshift=6mm]localportal.north) -- ([xshift=-7mm]localportal.north);
|
||||
\draw[->] ([yshift=6mm]localportal.north) -- (localportal.north);
|
||||
\draw[->] ([xshift=7mm,yshift=6mm]localportal.north) -- ([xshift=7mm]localportal.north);
|
||||
\draw[->] ([yshift=6mm]client.north) -- (client.north);
|
||||
|
||||
\draw[-] ([yshift=6mm]speedtest.north) -- ([yshift=6mm]localportal.north);
|
||||
\draw[-] ([xshift=7mm,yshift=6mm]localportal.north) -- ([yshift=6mm]client.north);
|
||||
|
||||
% Edge Label
|
||||
\node at ([xshift=-3.5mm,yshift=9mm]localportal.north) {0 .. N};
|
||||
\end{tikzpicture}
|
||||
|
||||
\caption{The network structure of standard tests}
|
||||
\label{fig:standard-network-structure}
|
||||
\end{figure}
|
||||
|
||||
The network structure of all standard tests is shown in figure \ref{fig:standard-network-structure}. Any deviations from this structure will be mentioned. The Local proxy has as many interfaces as referenced in any test, plus one to connect to the client. All Virtual Machines also have an additional interface for management, but this has no effect on the tests.
|
||||
When presenting data, error bars are given of the Inter-Quartile Range (IQR) of the data, with the plotted point being the median.
|
||||
|
||||
\section{Success Criteria}
|
||||
|
||||
@ -95,7 +52,7 @@ The second test is qualitative, involving making a call and checking for disconn
|
||||
|
||||
To demonstrate that all performance gains are bidirectional, I will provide graphs both inbound and outbound to the client for each performance test executed in this evaluation. This will sufficiently show the performance gains in each case. Inbound tests occur with the test server running on the proxy client and the test client running outside, while outbound tests occur with the test server running outside of the proxy and reaching in.
|
||||
|
||||
To demonstrate this somewhat succinctly, a pair of graphs for the same test in a common case will be shown. To demonstrate that this requirement is satisfied for all cases, for each graph of results presented in this evaluation, the graph for the alternative direction will be provided in appendix \ref{appendix:outbound-graphs}.
|
||||
To demonstrate this somewhat succinctly, a pair of graphs for the same test in a common case will be shown. To demonstrate that this requirement is satisfied for all cases, for each graph of results presented for the basic success criteria, the graph for the alternative direction will be provided in appendix \ref{appendix:outbound-graphs}.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
@ -113,14 +70,14 @@ To demonstrate this somewhat succinctly, a pair of graphs for the same test in a
|
||||
\label{fig:bidirectional-gains}
|
||||
\end{figure}
|
||||
|
||||
Figure \ref{fig:bidirectional-gains} shows two graphs of the same set of tests - one for the inbound performance and one for the outbound. It can be seen that both graphs show the same shape, satisfying that the performance gains of this proxy apply in both directions.
|
||||
Figure \ref{fig:bidirectional-gains} has two series for the same set of tests - one for the inbound (reaching in to the client, download) performance and one for the outbound (the client reaching out, upload). It can be seen that both graphs show the same shape, satisfying that the performance gains of this proxy apply in both directions.
|
||||
|
||||
\subsection{IP Spoofing}
|
||||
\label{section:ip-spoofing-evaluation}
|
||||
|
||||
To demonstrate that the IP of the client can be set to the IP of the remote proxy, the network structure shown in figure \ref{fig:standard-network-structure}, used for most of these tests, can be examined further. This will demonstrate that it is possible to set the IP as such, as all of the tests in this section did so.
|
||||
To demonstrate that the IP of the client can be set to the IP of the remote proxy, the network structure shown in Figure \ref{fig:standard-network-structure}, used for most of these tests, can be examined further. This will demonstrate that it is possible to set the IP as such, as all of the tests in this section did so.
|
||||
|
||||
In the given network structure, the speed test server, remote proxy and local proxy are each connected to one virtual switch, which acts as a mock Internet. There is then a separate virtual switch, which connects an additional interface of the local proxy to the client. The IP addresses of the interfaces shown in figure \ref{fig:standard-network-structure} are listed in figure \ref{fig:standard-network-structure-ips}. The IP addresses of the public interfaces are represented by letters, as they use arbitrary public IP addresses to ensure no local network firewall rules impact the configuration.
|
||||
In the given network structure, the speed test server, remote proxy and local proxy are each connected to one virtual switch, which acts as a mock Internet. There is then a separate virtual switch, which connects an additional interface of the local proxy to the client. The IP addresses of the interfaces shown in Figure \ref{fig:standard-network-structure} are listed in Figure \ref{fig:standard-network-structure-ips}. The IP addresses of the public interfaces are represented by letters, as they use arbitrary public IP addresses to ensure no local network firewall rules impact the configuration.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
@ -139,11 +96,11 @@ In the given network structure, the speed test server, remote proxy and local pr
|
||||
\hline
|
||||
Client & eth0 & \emph{B}
|
||||
\end{tabular}
|
||||
\caption{The IP layout of the standard test network structure.}
|
||||
\caption{The IP layout of the test network structure.}
|
||||
\label{fig:standard-network-structure-ips}
|
||||
\end{figure}
|
||||
|
||||
It is shown that the client in this testing setup shares an IP address with the remote proxy. To achieve this, the client configuration is particularly simple. A static route is added for 192.168.1.1 from the eth0 interface, and this then set as the default gateway. The IP address is set as the IP address of the remote proxy. The details of this configuration are provided in figure \ref{section:implementation-system-configuration}.
|
||||
It is shown that the client in this testing setup shares an IP address with the remote proxy. To achieve this, the client configuration is particularly simple. A static route is added for 192.168.1.1 from the eth0 interface, and this then set as the default gateway. The IP address is set as the IP address of the remote proxy. The details of this configuration are provided in Figure \ref{section:implementation-system-configuration}.
|
||||
|
||||
Given that the client shares the IP address of the remote proxy in these cases, it is demonstrated that this success criteria is met. Sharing the IP of the remote proxy allows most routers to be configured behind the local proxy as a client, allowing it to act as a standard Internet connection. An alternative approach, where the local proxy acts as a router, is detailed in section \ref{section:real-world-testing}.
|
||||
|
||||
@ -177,7 +134,7 @@ To demonstrate that more bandwidth is available over two equal connections throu
|
||||
\label{fig:more-bandwidth-equal}
|
||||
\end{figure}
|
||||
|
||||
The results of these tests are given in figure \ref{fig:more-bandwidth-equal}, for both a pair of 1MBps connections and a pair of 2MBps connections. To satisfy this success criteria, the proxied bar on each graph should exceed the throughput of the direct bar of equal bandwidth. It can be seen in both cases that this occurs, and thus the success criteria is met. The throughput far exceeds the single direct connection, and is closer to the single double bandwidth connection than the single equal bandwidth connection, demonstrating a good portion of the maximum performance is achieved.
|
||||
The results of these tests are given in Figure \ref{fig:more-bandwidth-equal}, for both a pair of 1MBps connections and a pair of 2MBps connections. To satisfy this success criteria, the proxied bar on each graph should exceed the throughput of the direct bar of equal bandwidth. It can be seen in both cases that this occurs, and thus the success criteria is met. The throughput far exceeds the single direct connection, and is closer to the single double bandwidth connection than the single equal bandwidth connection, demonstrating a good portion of the maximum performance is achieved.
|
||||
|
||||
\section{Extended Goals}
|
||||
|
||||
@ -223,11 +180,11 @@ This criteria expands on the scalability in terms of number of connections of th
|
||||
\label{fig:more-bandwidth-four}
|
||||
\end{figure}
|
||||
|
||||
Provided in figure \ref{fig:more-bandwidth-four} are results for both 1MBps and 2MBps connections. Firstly, it is clear that the proxy consisting of 4 connections exceeds the throughput of the proxy consisting of 3 connections in both cases. Secondly, it appears that a linear trend is forming. This trends will be further evaluated in section \ref{section:number-of-connections-scaling}, but suggests that the structure of the proxy suffers little loss in efficiency from adding further connections.
|
||||
Provided in Figure \ref{fig:more-bandwidth-four} are results for both 1MBps and 2MBps connections. Firstly, it is clear that the proxy consisting of 4 connections exceeds the throughput of the proxy consisting of 3 connections in both cases. Secondly, it appears that a linear trend is forming. This trends will be further evaluated in section \ref{section:number-of-connections-scaling}, but suggests that the structure of the proxy suffers little loss in efficiency from adding further connections.
|
||||
|
||||
\subsection{Bandwidth Variation}
|
||||
|
||||
This criteria judges the adaptability of the congestion control system in changing network conditions. To test this, the bandwidth of one of the local portal's connections is varied during an iperf3 throughput test. Thus far, bar graphs have been sufficient to show the results of each test. In this case, as the performance should now be time sensitive, I will be presenting a line graph. The error bars on the x-axis represent the range of continuous time results included in each discrete plotted point, while the y-axis error bars again represent the inter-quartile range of the gathered data. The target rates will be plotted as a fixed line for each of the speeds, as opposed to time-series. The error bar for these series will be omitted, as they occlude much of the graph, and are visible in figure (ref needed).
|
||||
This criteria judges the adaptability of the congestion control system in changing network conditions. To test this, the bandwidth of one of the local portal's connections is varied during an iperf3 throughput test. Thus far, bar graphs have been sufficient to show the results of each test. In this case, as the performance should now be time sensitive, I will be presenting a line graph. The error bars on the x-axis represent the range of continuous time results included in each discrete plotted point, while the y-axis error bars again represent the inter-quartile range of the gathered data. The target rates will be plotted as a fixed line for each of the speeds, as opposed to time-series. The error bar for these series will be omitted, as they occlude much of the graph, and are visible in Figure (ref needed).
|
||||
|
||||
\mynote{Reference the graph which shows the errors.}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user