103 lines
7.0 KiB
TeX
103 lines
7.0 KiB
TeX
%*******************************************************************************
|
|
%****************************** Second Chapter *********************************
|
|
%*******************************************************************************
|
|
|
|
\chapter{Preparation}
|
|
|
|
\ifpdf
|
|
\graphicspath{{Preparation/Figs/Raster/}{Preparation/Figs/PDF/}{Preparation/Figs/}}
|
|
\else
|
|
\graphicspath{{Preparation/Figs/Vector/}{Preparation/Figs/}}
|
|
\fi
|
|
|
|
\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 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?
|
|
|
|
The second focus is the direct interaction between the Local Portal and the Remote Portal. Questions like, does having this system make it easier for someone to perform a Denial of Service attack on the principal?
|
|
|
|
These security problems will be considered in the context of the success criteria: provide security no worse than not using this solution at all. That is, the security should be identical or stronger than the threats in the first case, and provide no additional vectors of attack in the second.
|
|
|
|
\subsection{Transparent Security}
|
|
|
|
A convenient factor of the Internet being an interconnected set of smaller networks is that there are very few guarantees of security. At layer 3, none of anonymity, integrity, privacy or freshness are provided once the packet leaves private ranges, so it is up to the application to ensure its own security on top of this lack of guarantees. For the purposes of this software, this is very useful: if there are no guarantees to maintain, applications can be expected to act correctly regardless of how easy it is for these cases to occur.
|
|
|
|
Therefore, to maintain the same level of security for applications, this project can simply guarantee that the packets which leave the Remote Portal are the same as those that came in. By doing this, all of the security implemented above Layer 3 will be maintained. This means that whether a user is accessing insecure websites over HTTP, running a corporate VPN connection or sending encrypted emails, the security of these applications will be unaltered.
|
|
|
|
\subsection{Portal to Portal Communication}
|
|
|
|
\subsubsection{Cost}
|
|
|
|
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.
|
|
|
|
\subsubsection{Denial of Service}
|
|
\label{subsubsection:threats-denial-of-service}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\begin{subfigure}{.49\textwidth}
|
|
\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 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}{ | p{0.4\textwidth} p{0.4\textwidth} | }
|
|
Downlink Capacity & Percentage of Packets \\
|
|
25 Mbps & 25\% \\
|
|
25 Mbps & 25\% \\
|
|
25 Mbps & 25\% \\
|
|
(BAD) 25 Mbps & 25\%
|
|
\end{tabularx}
|
|
\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{Comparing the percentage of packets a bad actor can steal to their downlink capacity.}
|
|
\label{fig:bad-actor-packet-loss}
|
|
\end{figure}
|
|
|
|
If a malicious actor can fool the Remote Portal into sending them a portion of your packets, they are immediately performing an effective Denial of Service on any tunnelled flows relying on loss based congestion control. In figure \ref{fig:fast-bad-actor-packet-loss}, it can be seen that a bad actor, with a significantly faster connection than you, can cause huge packet loss if the Remote Portal would accept them as a valid Local Portal connection.
|
|
|
|
\begin{figure}
|
|
\begin{equation}
|
|
Throughput = \sqrt{\frac{3}{2}}\frac{1}{RTT\sqrt{p}}
|
|
\end{equation}
|
|
\caption{TCP Throughput Equation (New Reno)}
|
|
\label{fig:tcp-throughput}
|
|
\end{figure}
|
|
|
|
However, of much more relevance is \ref{fig:slow-bad-actor-packet-loss}. Given the TCP throughput equation, shown in figure \ref{fig:tcp-throughput}, there is an inverse relation between packet loss and throughput of any TCP connections. Assuming a Round Trip Time of $20ms$ and Maximum Segment Size of $1460$, packet loss of $25\%$ limits the maximum TCP throughput to approximately $1.17Mbps$. In fact, due to this relation, a packet loss of even $1\%$ leads to a maximum throughput of approximately $5.84Mbps$. This means that even a small packet loss can have a drastic effect on the performance of the connection as a whole, and thus makes Remote Portals an effective target for Denial of Service attacks. Care must be taken that all Local Portal connections are from the intended subject.
|
|
|
|
\subsection{Privacy}
|
|
|
|
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.
|
|
|
|
% ------------------------------- Security --------------------------------- %
|
|
\section{Language Selection}
|
|
\label{section:language-selection}
|
|
|
|
TODO
|