Update on Overleaf.
This commit is contained in:
overleaf
parent
ec6f88e4d5
commit
821bf69847
@ -112,12 +112,12 @@ The performance gains measured are visible in both directions (inbound and outbo
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{subfigure}{.49\textwidth}
|
||||
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-2R1-2T10S1-R0-1R1-2T10S2-R0-1R1-1T10}
|
||||
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-1R1-1T10S1-R0-1R1-2T10S2-R0-2R1-2T10}
|
||||
\caption{The inbound graph}
|
||||
\label{fig:example-inbound}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}{.49\textwidth}
|
||||
\includegraphics[width=0.9\linewidth]{graphs/OES0-R0-2R1-2T10S1-R0-1R1-2T10S2-R0-1R1-1T10}
|
||||
\includegraphics[width=0.9\linewidth]{graphs/OES0-R0-1R1-1T10S1-R0-1R1-2T10S2-R0-2R1-2T10}
|
||||
\caption{The outbound graph}
|
||||
\label{fig:example-outbound}
|
||||
\end{subfigure}
|
||||
@ -156,9 +156,14 @@ TODO.
|
||||
|
||||
\subsection{More Bandwidth over Two Equal Connections}
|
||||
|
||||
TODO.
|
||||
|
||||
This success criteria is satisfied, as seen in figure \ref{fig:two-equal-connections}. This graph compares the combined performance of two equal connections to one connection of the same speed and one connection of double the speed. It can be seen that the connection comes very close to the double speed connection, showing that this is an effective method of combining, in terms of raw TCP throughput. These tests are conducted using the TCP method of congestion control.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=10cm]{graphs/IES0-DR0-1T10S1-R0-1R1-1T10S2-DR0-2T10}
|
||||
\caption{A graph demonstrating that two connections proxied lie between one connection of the same speed and one connection of double the speed in terms of throughput}
|
||||
\label{fig:two-equal-connections}
|
||||
\end{figure}
|
||||
|
||||
\section{Extended Goals}
|
||||
|
||||
@ -166,8 +171,8 @@ TODO.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[height=7cm]{graphs/IES0-R0-2R1-2T10S1-R0-1R1-2T10S2-R0-1R1-1T10}
|
||||
\caption{Unequal connections compared against equal of both sides}
|
||||
\includegraphics[width=10cm]{graphs/IES0-R0-2R1-2T10S1-R0-1R1-2T10S2-R0-1R1-1T10}
|
||||
\caption{A graph demonstrating that two unequal connections proxied lie between two connections of the lower bandwidth and two connections of the higher bandwidth}
|
||||
\label{fig:unequal-connections}
|
||||
\end{figure}
|
||||
|
||||
@ -180,22 +185,31 @@ This is demonstrated by showing that $1x1MB + 1x2MB$ connections can exceed the
|
||||
\begin{subfigure}{.49\textwidth}
|
||||
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-1R1-1R2-1R3-1T10S1-R0-1R1-1R2-1T10S2-R0-1R1-1T10}
|
||||
\caption{1MB connections}
|
||||
\label{fig:equal-connections-scaling-1MB}
|
||||
\label{fig:four-equal-connections-1MB}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}{.49\textwidth}
|
||||
\includegraphics[width=0.9\linewidth]{graphs/IES0-R0-2R1-2R2-2R3-2T10S1-R0-2R1-2R2-2T10S2-R0-2R1-2T10}
|
||||
\caption{2MB connections}
|
||||
\label{fig:equal-connections-scaling-2MB}
|
||||
\label{fig:four-equal-connections-2MB}
|
||||
\end{subfigure}
|
||||
\caption{Scaling of equal connections}
|
||||
\label{fig:equal-connections-scaling}
|
||||
\label{fig:four-equal-connections}
|
||||
\end{figure}
|
||||
|
||||
This criteria is about throughput increasing with the number of equal connections added. It is demonstrated by comparing the throughput of $2x1MB$, $3x1MB$ and $4x1MB$ connections. This can be seen in figure \ref{fig:equal-connections-scaling-1MB}. A further example is provided of $2x2MB$, $3x2MB$ and $4x2MB$ in figure \ref{fig:equal-connections-scaling-2MB}.
|
||||
This criteria is about throughput increasing with the number of equal connections added. It is demonstrated by comparing the throughput of $2x1MB$, $3x1MB$ and $4x1MB$ connections. This can be seen in figure \ref{fig:four-equal-connections-1MB}. A further example is provided of $2x2MB$, $3x2MB$ and $4x2MB$ in figure \ref{fig:four-equal-connections-2MB}.
|
||||
|
||||
\subsection{Bandwidth Variation}
|
||||
|
||||
TODO.
|
||||
This criteria is about the adaptability of the congestion control system. This can be seen in figure \ref{fig:bandwidth-variation}, a graph in which the capacity of one of the two links is decreased. For $0 < t \leq 10$, both links are $2MB$. For $10 < t \leq 20$, one link is decreased to $1MB$ and the other remains at $2MB$. For $20 < t \leq 30$, both links are returned to $2MB$.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=10cm]{graphs/TIEyS0-R0-2R1-2E10R0-1E20R0-2T30}
|
||||
\caption{A graph demonstrating the effect of decreasing the bandwidth of one of the two connections}
|
||||
\label{fig:bandwidth-variation}
|
||||
\end{figure}
|
||||
|
||||
It can be seen in the graph that the bandwidth initially stabilises at approximately $30Mbps$, before decreasing at just after $t = 10$. The connection then quickly recovers at $t=20$, to the initial rate.
|
||||
|
||||
\subsection{Connection Loss}
|
||||
|
||||
@ -231,15 +245,13 @@ The single interface Remote Portal is achieved using a similar set of commands t
|
||||
|
||||
Not implemented yet.
|
||||
|
||||
|
||||
|
||||
\section{Stretch Goals}
|
||||
|
||||
\subsection{IPv4/IPv6 Support}
|
||||
|
||||
The project is only tested with IPv4.
|
||||
|
||||
\subsection{UDP Proxy Datagrams}
|
||||
\subsection{UDP Proxy Flows}
|
||||
|
||||
TODO
|
||||
|
||||
|
||||
@ -10,23 +10,29 @@
|
||||
\graphicspath{{Implementation/Figs/Vector/}{Implementation/Figs/}}
|
||||
\fi
|
||||
|
||||
% ----------------------- Greedy Load Balancing ---------------------------- %
|
||||
\section{Greedy Load Balancing}
|
||||
|
||||
The implementation of this project is built on the concept of greedy load balancing. By placing the packets to send in a FIFO queue, with each consumer (a flow connected to the other side) grabbing from the queue as soon as their congestion controlled link permits, a fast and adaptive system of network load balancing is achieved.
|
||||
|
||||
TODO
|
||||
|
||||
% --------------------------------- TCP ------------------------------------ %
|
||||
\section{TCP}
|
||||
|
||||
The base implementation is built on TCP. TCP provides congestion control and flow control, which are all that is necessary for this form of greedy load balancing, and therefore solves almost all of the issues given here. To implement such a solution on TCP, the only difference that needs to be made is punctuating the connection. As TCP provides a byte stream and not distinct datagrams, a distinction must be made between the packets. One option is to use a punctuating character, though this would reduce the character set of the packets, and therefore require escape sequences in the packets. The second option is to read the length of the packets and then read the correct amount of data from the stream.
|
||||
The first implementation is built on TCP. TCP provides congestion control and flow control, which are all that is necessary for this form of greedy load balancing, and therefore solves almost all of the issues given here. To implement such a solution on TCP, the only difference that needs to be made is punctuating the connection. As TCP provides a byte stream and not distinct datagrams, a distinction must be made between the packets. One option is to use a punctuating character, though this would reduce the character set of the packets, and therefore require escape sequences in the packets. The second option is to read the length of the packets and then read the correct amount of data from the stream.
|
||||
|
||||
My implementation uses the second option, of punctuating the stream by providing the length of each packet. Although the IP packets do provide their length internally, I kept the TCP flow as flexible as possible. That is, it is kept as simple as possible, so that it doesn't have to be updated for transmitting any other sort of packets. Therefore, the TCP flow is punctuated by sending the length of the packet before the packet itself within the stream. Then, this number of bytes can be read.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{bytefield}[bitwidth=0.99em]{32}
|
||||
\begin{bytefield}[bitwidth=0.9em]{32}
|
||||
\bitheader{0-31} \\
|
||||
\begin{rightwordgroup}{TCP\\Header}
|
||||
\bitbox{16}{Source Port} & \bitbox{16}{Destination Port} \\
|
||||
\wordbox{1}{Sequence Number} \\
|
||||
\wordbox{1}{Acknowledgment Number} \\
|
||||
\bytefieldsetup{bitheight=5em}\bitbox{4}{Data offset} & \bitbox{3}{\begin{turn}{-60}Reserved\end{turn}} & \bitbox{1}{N S} & \bitbox{1}{C R W} & \bitbox{1}{E C E} & \bitbox{1}{U R G} & \bitbox{1}{A C K} & \bitbox{1}{P S H} & \bitbox{1}{R S T} & \bitbox{1}{S Y N} & \bitbox{1}{F I N} & \bitbox{16}{Window Size} \\
|
||||
\bytefieldsetup{bitheight=5em}\bitbox{4}{Data offset} & \bitbox{3}{\begin{turn}{-65}Reserved\end{turn}} & \bitbox{1}{N S} & \bitbox{1}{C R W} & \bitbox{1}{E C E} & \bitbox{1}{U R G} & \bitbox{1}{A C K} & \bitbox{1}{P S H} & \bitbox{1}{R S T} & \bitbox{1}{S Y N} & \bitbox{1}{F I N} & \bitbox{16}{Window Size} \\
|
||||
\bitbox{16}{Checksum} & \bitbox{16}{Urgent Pointer}
|
||||
\end{rightwordgroup} \\
|
||||
\wordbox[tlr]{1}{Proxied IP packet} \\
|
||||
@ -45,17 +51,19 @@ My implementation uses the second option, of punctuating the stream by providing
|
||||
% --------------------------------- UDP ------------------------------------ %
|
||||
\section{UDP}
|
||||
|
||||
To increase the performance of the system, I implemented a UDP method of tunnelling packets, available alongside the TCP method discussed earlier. Using UDP datagrams instead of a TCP flow is a two front approach to increasing performance. Firstly, it removes the issue of head of line blocking, as the protocol does not resend packets when they are not received. Secondly, the datagram design can include less per packet overhead in the form of a header, increasing the efficiency of transmitting packets.
|
||||
The second implementation is built on UDP. Sending each tunnelled packet in a discrete datagram has the benefit of an increased likeness to unproxied IP packets. An example of this is Path MTU Discovery. Over TCP, any length of packet will reach the Remote Portal, as TCP will fragment the byte stream across multiple TCP packets, regardless of the Do Not Fragment flag on an IPv4 packet, or the presence of an IPv6 packet. With UDP, packets that are too large to be transmitted across the link (including the UDP packet itself) will be dropped. Though this does not immediately react in the same way as an unproxied IP packet (ICMP packets need additional handling), it brings the link much closer to transmitting correctly sized IP packets than TCP, which can increase performance.
|
||||
|
||||
The goal was to create a UDP packet structure that allows for congestion control (and implicit flow control), without the other benefits that TCP provides. This is as the other features of TCP are unnecessary for this project, due to being covered by protocols above Layer 3, which function regardless of the tunnelling.
|
||||
Further, sending one datagram per packet has a benefit in terms of head of line blocking. Head of line blocking occurs when a TCP flow must resend the front of the window while the window is full, preventing the flow from transmitting any more data. With the UDP solution, each packet received represents exactly one datagram, and as such can be immediately forwarded, regardless of the order in which it's received. Although this does not entirely solve head of line blocking, it allows an entire window size of packets to be transmitted with significantly reduced latency before the blocker at the start of the window is dealt with (the method for which is not retransmission, and is discussed further later).
|
||||
|
||||
Beyond the benefits of the similarity between datagrams and packets, using UDP as opposed to TCP provides for more flexibility in terms of transmission guarantees. The method of greedy load balancing given relies on congestion control and flow control. However, TCP also provides reliable delivery and ordering. By reducing these guarantees to the minimum congestion control and flow control, transport efficiency can be increased, while still allowing transparency for the proxied packets to provide these guarantees where necessary. Lesser guarantees can also allow for a shorter header, increasing per-packet efficiency, though this is not the case with the presented structure.
|
||||
|
||||
\subsection{Packet Structure}
|
||||
|
||||
The packet structure was decided to allow for effective congestion control and nothing else. This is achieved with a simple 3 part, 12 byte header (shown in figure \ref{fig:udp-packet-structure}). Similarly to TCP, each packet contains an acknowledgement number (ACK) and a sequence number (SEQ). These serve the same purpose as in TCP: providing a method for a congestion controller to know which packets have been received by their partner. However, they are implemented slightly differently. TCP sequence numbers are based on bytes, and as such the sequence number of a packet is the sequence number of the first byte that it contains. As this protocol is designed for transmitting packets, losing part of a packet does not make sense. They will also never be split, as this protocol does not support partial transmission, and as such are atomic. This means that the sequence number can safely represent an individual packet, as opposed to a byte.
|
||||
The packet structure was decided to allow for effective congestion control, with implicit flow control, and nothing else. This is achieved with a simple 3 part, 12 byte header (shown in figure \ref{fig:udp-packet-structure}). Similarly to TCP, each packet contains an acknowledgement number (ACK) and a sequence number (SEQ). These serve the same purpose as in TCP: providing a method for a congestion controller to know which packets have been received by their partner. However, they are implemented slightly differently. TCP sequence numbers are based on bytes, and as such the sequence number of a packet is the sequence number of the first byte that it contains. As this UDP based protocol is designed for transmitting packets, losing part of a packet does not make sense. They will also never be split, as this protocol does not support partial transmission, and as such are atomic. This means that the sequence number can represent an entire packet, as opposed to a byte.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{bytefield}[bitwidth=0.99em]{32}
|
||||
\begin{bytefield}[bitwidth=0.6em]{32}
|
||||
\bitheader{0-31} \\
|
||||
\begin{rightwordgroup}{UDP\\Header}
|
||||
\bitbox{16}{Source port} & \bitbox{16}{Destination port} \\
|
||||
@ -81,9 +89,9 @@ The packet structure was decided to allow for effective congestion control and n
|
||||
|
||||
In addition to these two fields, a further Negative Acknowledgement (NACK) field is required. Due to TCP's promise of reliable transmission, negative acknowledgements can never occur. Either the sender must resend the packet in question, or the flow is terminated. In my protocol, however, it is necessary that the receiver has a method to provide a discontinuous stream of acknowledgements. If this was attempted without a separate NACK number, it would be required that each ACK number is sent and received individually. This decreases the efficiency and correctness of ACKs, both in terms of missing packets, and having to send at least one packet for every packet received.
|
||||
|
||||
The benefit of a NACK is demonstrated in figure \ref{fig:sequence-ack-nack-comparison}. Figure \ref{fig:sequence-ack-continuous} shows a series of ACKs for a perfect set of sequence numbers. This is rather pointless, as there is no point to ACKing packets if you never intend to lose any, but is a situation that can occur for large portions of a flow, given good congestion control and reliable networking. Figure \ref{fig:sequence-ack-discontinuous} shows the same ACK system for a stream of sequence numbers with one missing. It can be seen that the sender and receiver reach an impasse: the receiver cannot increase its ACK number, as it has not received packet 5, and the sender cannot send more packets, as its window is full. The only move is for the receiver to increase its ACK number and rely on the sender realising that it took too long to acknowledge the missing packet, though this is unreliable at best.
|
||||
The benefit of a NACK is demonstrated in figure \ref{fig:sequence-ack-nack-comparison}. Figure \ref{fig:sequence-ack-continuous} shows a series of ACKs for a perfect set of sequence numbers. This is rather pointless, as there is no point to ACKing packets if you never intend to lose any, but is a situation that can occur for large portions of a flow, given good congestion control and reliable networking. Figure \ref{fig:sequence-ack-discontinuous} shows the same ACK system for a stream of sequence numbers with one missing. It can be seen that the sender and receiver reach an impasse: the receiver cannot increase its ACK number, as it has not received packet 5, and the sender cannot send more packets, as its window is full. The only possibility is for the receiver to increase its ACK number and rely on the sender realising that it took too long to acknowledge the missing packet, though this is equivalent to a lost ACK, and would therefore be difficult to detect reliably.
|
||||
|
||||
Figure \ref{fig:sequence-ack-nack-discontinuous} shows how this same situation can be responded to with a NACK field. After the receiver has concluded that the intermediate packet(s) were lost in transit (a function of RTT, to be discussed further later), it updates the NACK field to the highest lost packet, allowing the ACK field to be increased from one after the lost packet. This solution resolves the deadlock of not being able to increase the ACK number without requiring reliable delivery.
|
||||
Figure \ref{fig:sequence-ack-nack-discontinuous} shows how this same situation can be responded to with a NACK field. After the receiver has concluded that the intermediate packet(s) were lost in transit (a function of RTT, to be discussed further later), it updates the NACK field to the highest lost packet, allowing the ACK field to be increased from one after the lost packet. This solution resolves the deadlock of not being able to increase the ACK number without requiring reliable delivery. That is, the receiver increases their NACK similarly to when a TCP sender would retransmit.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
@ -135,7 +143,7 @@ Figure \ref{fig:sequence-ack-nack-discontinuous} shows how this same situation c
|
||||
\label{fig:sequence-ack-nack-comparison}
|
||||
\end{figure}
|
||||
|
||||
In implementing the UDP based protocol, I spent some time reading packet data in Wireshark\footnote{\url{https://wireshark.org}}. After attempting this with simply the RAW byte data, I wrote a dissector for Wireshark for my protocol. This can be seen in figure \ref{fig:udp-wireshark-dissector}. This is a Lua script that requests Wireshark use the given dissector function for UDP traffic on port 1234 (a port chosen for testing). This extracts the three congestion control numbers from the UDP datagram, showing them in a far easier to read format and allowing more efficient debugging of congestion control protocols.
|
||||
As this was a new UDP protocol, I wrote a Wireshark\footnote{\url{https://wireshark.org}} dissector, shown in figure \ref{fig:udp-wireshark-dissector}. This is a Lua script that requests Wireshark use the given dissector function for UDP traffic on port 1234 (a port chosen for testing). It extracts the three congestion control parameters from the UDP datagram, showing them in a far easier to read format and allowing more efficient debugging of congestion control protocols. The extracted data can be seen in figure \ref{fig:udp-wireshark-dissector-results}.
|
||||
|
||||
\begin{figure}
|
||||
\inputminted{go}{Implementation/Samples/wireshark_dissector.lua}
|
||||
@ -203,12 +211,6 @@ A point of interest is the \mintinline{go}{acksToSend} data structure. It can be
|
||||
% ------------------------------- Security --------------------------------- %
|
||||
\section{Security}
|
||||
|
||||
% For the security implementation, I paid careful attention to the work of Wireguard (Donenfeld, “WireGuard.” \cite{donenfeld_wireguard_2017}). Wireguard is a modern, well respected method of securely transferring Layer 3 packets across the Internet.
|
||||
|
||||
% However, as Wireguard is a VPN, it provides certain security benefits that are not within the remit of my threat model (section \ref{section:threat-model}). The primary example of this is privacy. When Wireguard, and most VPNs, send a packet, they first encrypt the contents such that the contents of the datagram are only visible to the intended recipient. For this project, encryption will not be necessary, as that would provide privacy above using the modem without this solution. If a user wishes to also have the benefits of an encrypted Internet connection, the transparency of this solution allows existing VPNs to run underneath and provide that. This follows the philosophy of do one thing and do it well.
|
||||
|
||||
% The security in this solution will be achieved by using public and private key-pairs to perform a key exchange at the beginning of connections, and then using that key to produce a message authentication code for each packet sent across the connection. To prevent replay of earlier messages, a timestamp will be included within the authenticated section of the message. This timestamp can be used to discard messages sent a certain time earlier than received, reducing the usefulness of replay attacks.
|
||||
|
||||
The security in this solution is achieved by providing a set of interfaces for potential cryptographic systems to implement. This can be seen in figure \ref{fig:message-authenticator-interface}. As with all interfaces, the goal here was to create a flexible but minimal interface.
|
||||
|
||||
\begin{figure}
|
||||
@ -219,15 +221,21 @@ The security in this solution is achieved by providing a set of interfaces for p
|
||||
|
||||
As far as is possible, the security of the application relies on external libraries. Although an interesting exercise, implementing security algorithms directly from papers is far more likely to result in errors and thus security flaws. Due to this, I will be using trusted and open source libraries for the scheme I have chosen.
|
||||
|
||||
\subsection{Symmetric Key Cryptography}
|
||||
\subsection{Message Authentication Algorithms}
|
||||
|
||||
When providing integrity and authentication for a message, there are two main choices: a Message Authentication Code (MAC) or signing.
|
||||
The shared key algorithm I chose to implement is BLAKE2s\cite{hutchison_blake2_2013}. It is extremely fast (comparable to MD5) while remaining cryptographically secure. Further to this, BLAKE2s is available in the Go \verb'crypto' library\footnote{\url{https://github.com/golang/crypto}}, which is a trusted and open source implementation.
|
||||
|
||||
TODO: Finish this section.
|
||||
By appending a timestamp to the packet prior to computing the MAC, a guarantee of freshness can be included.
|
||||
|
||||
\subsubsection{BLAKE2s}
|
||||
\subsection{Implementation Details}
|
||||
|
||||
The shared key algorithm I chose to implement is BLAKE2s\cite{hutchison_blake2_2013}. It is extremely fast (comparable to MD5) while remaining cryptographically secure. Further to this, BLAKE2s is available in the Go crypto library\footnote{\url{https://github.com/golang/crypto}}, which is a trusted and open source implementation.
|
||||
\subsubsection{UDP}
|
||||
|
||||
By computing the message authentication code for the entire application controlled segment of the message, including the congestion control header, UDP meets the initial security criteria with no further work. Given that the beginning of a flow includes the congestion control header, it ensures that no flow is started without proving the partner's identity.
|
||||
|
||||
\subsubsection{TCP}
|
||||
|
||||
TCP requires further work than UDP, as the TCP handshake is out of the control of the application. Therefore, a flow level handshake must be completed beyond the initial, for the threat model to be satisfied.
|
||||
|
||||
TODO
|
||||
|
||||
|
||||
BIN
Introduction/Figs/Bottlenecks.jpg
Normal file
BIN
Introduction/Figs/Bottlenecks.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 130 KiB |
@ -13,7 +13,7 @@
|
||||
|
||||
\section{Motivation}
|
||||
|
||||
Most UK residential broadband speeds receive broadband speeds advertised at between 30Mbps and 100Mbps download (Ofcom 2020, \cite{ofcom_performance_2020}). However, it is often possible to have multiple low bandwidth connections installed. More generally, a wider variety of Internet connections for fixed locations are becoming available with time. These include: DSL, Fibre To The Premises, 4G, 5G, Wireless ISPs such as LARIAT and Low Earth Orbit ISPs such as Starlink.
|
||||
Most UK residential broadband speeds receive broadband speeds advertised at between 30Mbps and 100Mbps download (Ofcom 2020, \cite{ofcom_performance_2020}). However, it is often possible to have multiple low bandwidth connections installed. More generally, a wider variety of Internet connections for fixed locations are becoming available with time. These include: DSL, Fibre To The Premises, 4G, 5G, Wireless ISPs such as LARIAT and Low Earth Orbit ISPs such as Starlink. This work focuses on a method of providing an aggregate link from multiple distinct connections, regardless of their likeness.
|
||||
|
||||
\section{Existing Work}
|
||||
|
||||
@ -21,11 +21,11 @@ Most UK residential broadband speeds receive broadband speeds advertised at betw
|
||||
|
||||
MultiPath TCP (Wischik et al. 2011, \cite{wischik_design_2011}) is an extension to the regular Transmission Control Protocol, allowing the creation of subflows. MultiPath TCP was designed with two purposes: increasing resiliency and throughput for multi-homed mobile devices, and providing multi-homed servers with better control over balancing flows between their interfaces.
|
||||
|
||||
The first reason that MPTCP does not satisfy the motivation for this project is temporal. MPTCP is most effective at creating flows when the device has distinct interfaces or IP addresses. In the case of an IPv4 home connection, it is often the case that a single IPv4 address is provided to the home. This leads to the use of NAT for IPv4 addresses behind the router. If an MPTCP capable device lies behind a NAT router which has two external IPv4 addresses, the device itself will have no knowledge of this.
|
||||
The first reason that MPTCP does not satisfy the motivation for this project is temporal. MPTCP is most effective at creating flows when the device has distinct interfaces or IP addresses. In the case of an IPv4 home connection, it is often the case that a single IPv4 address is provided to the home. This leads to the use of NAT for IPv4 addresses behind the router. If an MPTCP capable device lies behind a NAT router which has two external IPv4 addresses, the device itself will have no knowledge of this. This can be solved for server devices by having an IP on each NAT, but does not provide a good solution for more standard devices. These range from WiFi interfaces to IP phones and smart televisions.
|
||||
|
||||
TODO: IPv6 autoconf wrt. multihoming
|
||||
|
||||
Further, it is important to remember legacy devices. Many legacy devices will never support IPv6, and certainly will never support MPTCP. Though it is possible that these devices will not require the performance benefits available from multiple Internet connections, it is likely that they would particularly benefit from a more reliable connection. Being able to apply speed benefits to an entire network without control over every device on it is a significant benefit to the solution provided in this dissertation.
|
||||
Further, it is important to remember legacy devices. Many legacy devices will never support IPv6, and will never support MPTCP. Though it is possible that these devices will not require the performance benefits available from multiple Internet connections, it is likely that they would benefit particularly from a more reliable connection. Being able to apply speed and reliability benefits to an entire network without control over every device on it is a significant benefit to the solution provided in this work.
|
||||
|
||||
The second reason that MPTCP may not provide the change to the Internet that was once hoped is the UDP based protocols that are coming into existence. Although MPTCP is now making its way into the Linux kernel, many services are switching to lighter UDP protocols such as QUIC. The most interesting example of this is HTTP/3, which was previously known as HTTP over QUIC. This shift to application controlled network connections which do not contain unnecessary overhead for each specific application seems to be the direction that the Internet is going in, but suggests that it will be a very long time before even modern applications can benefit from multipathing.
|
||||
|
||||
@ -35,7 +35,11 @@ TODO: Find a study on how many of the connections on the Internet are TCP or UDP
|
||||
|
||||
This project aimed to provide a method of combining a variety of Internet connections, such as the situations listed above.
|
||||
|
||||
When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience and latency. This project aimed to provide throughput and resilience at the cost of latency.
|
||||
|
||||
|
||||
When combining Internet connections, there are three main measures that one can prioritise: throughput, resilience and latency. This project aimed to provide throughput and resilience at the cost of latency. This is achieved by inserting additional items into the network stack, in order to split/combine over bottlenecks, as seen in figure \ref{fig:combining-bottlenecks}.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{Bottlenecks}
|
||||
\caption{A high level overview of the bottlenecks that are combined in this solution.}
|
||||
\label{fig:combining-bottlenecks}
|
||||
\end{figure}
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
\section{Threat Model}
|
||||
\label{section:threat-model}
|
||||
|
||||
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 discuss my analysis of these threats, in both isolation, and compared to the case of connecting directly.
|
||||
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.
|
||||
|
||||
The first focus of this analysis is the transparent security. That is, if the Local Portal is treated as a modem, what security would normally be expected? And for servers communicating with the Remote Portal, what guarantees can they expect of the packets sent and received?
|
||||
|
||||
@ -31,7 +31,7 @@ Therefore, to maintain the same level of security for applications, this project
|
||||
|
||||
\subsubsection{Cost}
|
||||
|
||||
Many Internet connections have caps or cost for additional bandwidth. In a standard network, the control of your cap is physical, in that, if someone wished to increase the load, they would have to physically connect to the modem.
|
||||
Many Internet connections have limits or charges for bandwidth usage. In a standard network, the control of your cap is physical, in that, if someone wished to increase the load, they would have to physically connect to the modem.
|
||||
|
||||
Due to this, it is important that care is taken with regards to cost. The difference is that rather than needing physical access to send data through your connection, all one needs is an Internet connection. A conceivable threat is for someone to send packets to your Remote Portal from their own connection, causing the Portal to forward these packets, and thus using your limited or costly bandwidth.
|
||||
|
||||
@ -41,18 +41,18 @@ Due to this, it is important that care is taken with regards to cost. The differ
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{subfigure}{.49\textwidth}
|
||||
\begin{tabularx}{\textwidth}{ | l l }
|
||||
\begin{tabularx}{\textwidth}{ | p{0.4\textwidth} p{0.4\textwidth} | }
|
||||
Downlink Capacity & Percentage of Packets \\
|
||||
25 Mbps & 5\% \\
|
||||
25 Mbps & 5\% \\
|
||||
25 Mbps & 5\% \\
|
||||
(BAD) 425 Mbps & 85\%
|
||||
\end{tabularx}
|
||||
\caption{A bad actor with a fast connection taking a percentage of packets.}
|
||||
\caption{A bad actor with a faster connection than you taking a percentage of packets.}
|
||||
\label{fig:fast-bad-actor-packet-loss}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}{.49\textwidth}
|
||||
\begin{tabularx}{\textwidth}{ | l l | }
|
||||
\begin{tabularx}{\textwidth}{ | p{0.4\textwidth} p{0.4\textwidth} | }
|
||||
Downlink Capacity & Percentage of Packets \\
|
||||
25 Mbps & 25\% \\
|
||||
25 Mbps & 25\% \\
|
||||
@ -62,7 +62,7 @@ Due to this, it is important that care is taken with regards to cost. The differ
|
||||
\caption{A bad actor with an equally slow connection to you taking a percentage of packets.}
|
||||
\label{fig:slow-bad-actor-packet-loss}
|
||||
\end{subfigure}
|
||||
\caption{Bad actors taking a percentage of packets based on their network speed.}
|
||||
\caption{Comparing the percentage of packets a bad actor can steal to their downlink capacity.}
|
||||
\label{fig:bad-actor-packet-loss}
|
||||
\end{figure}
|
||||
|
||||
@ -82,3 +82,15 @@ 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.
|
||||
|
||||
% ------------------------------- Security --------------------------------- %
|
||||
\section{Security}
|
||||
|
||||
The security of this application is designed to target the threats mentioned in the thread model.
|
||||
|
||||
TODO
|
||||
|
||||
\subsection{Symmetric Key Cryptography}
|
||||
|
||||
When providing integrity and authentication for a message, there are two main choices: a Message Authentication Code (MAC) or signing.
|
||||
|
||||
TODO: Finish this section.
|
||||
|
||||
0
import-graphs.sh
Executable file → Normal file
0
import-graphs.sh
Executable file → Normal file
Loading…
Reference in New Issue
Block a user