Update on Overleaf.
This commit is contained in:
parent
095d977e83
commit
3d81a24271
@ -16,6 +16,13 @@ Proxying packets is the process of taking packets that arrive at one location an
|
||||
\section{Risk Analysis}
|
||||
\label{section:risk-analysis}
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics{2_Preparation/Figs/security-zones.png}
|
||||
\caption{A summary of the three different connection classes in this proxy.}
|
||||
\label{fig:security-zones}
|
||||
\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.
|
||||
|
||||
Secondly, this section focuses on the connections between the Local Portal and the Remote Portal. This focuses primarily on the risk of accepting and transmitting a packet that is not intended, or sending packets to an unintended recipient.
|
||||
@ -30,6 +37,13 @@ This ensures that guarantees managed by layers above layer 3 are maintained. Reg
|
||||
|
||||
\subsection{Portal to Portal Communication}
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics{2_Preparation/Figs/security-zones-attackers.png}
|
||||
\caption{Four potential directions of attack for portal to portal communication.}
|
||||
\label{fig:security-zones-attackers}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Denial of Service}
|
||||
\label{subsubsection:threats-denial-of-service}
|
||||
|
||||
@ -130,6 +144,13 @@ A specific of the multipath nature of this application is requiring the use of a
|
||||
\subsection{Layered Security}
|
||||
\label{section:layered-security}
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\includegraphics{2_Preparation/Figs/security-zones-vpn.png}
|
||||
\caption{Connection classes covered by a VPN.}
|
||||
\label{fig:security-zones-vpn}
|
||||
\end{figure}
|
||||
|
||||
It was previously mentioned that this solution focuses on maintaing the higher layer security of proxied packets. Further to this, this solution provides transparent security in the other direction. Consider the case of a satellite office that employs both a whole network corporate VPN and this 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.
|
||||
|
||||
These two examples are given in figures \ref{fig:whole-network-vpn-behind} and \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.
|
||||
|
Loading…
Reference in New Issue
Block a user