diff --git a/Chapters/Introduction.tex b/Chapters/Introduction.tex index a08264c..9025c78 100644 --- a/Chapters/Introduction.tex +++ b/Chapters/Introduction.tex @@ -2,6 +2,250 @@ \label{Introduction} -This chapter introduces the Clan project, articulates its fundamental -objectives, outlines the key components, and examines the driving -factors motivating its development. +\subsection{Motivation} + +Peer-to-peer architectures promise censorship-resistant, fault-tolerant +infrastructure by eliminating single points of failure +\cite{shukla_towards_2021}. +These architectures underpin a growing range of systems---from IoT +edge computing +and content delivery networks to blockchain platforms like Ethereum. +Yet realizing these benefits requires distributing nodes across +genuinely diverse hosting entities. + +In practice, this diversity remains illusory. +Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes +(see Figure~\ref{fig:ethernodes_hosting}), +concentrating nominally decentralized infrastructure +within a handful of cloud providers. +More concerning, these providers operate under overlapping regulatory +jurisdictions, +predominantly the United States and the European Union. +This concentration undermines technical sovereignty: +a single governmental action could compel service termination, +data disclosure, or traffic manipulation across a majority of the network. + +\begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png} + \caption{Distribution of Ethereum nodes hosted by various providers + \cite{noauthor_isps_nodate}} + \label{fig:ethernodes_hosting} +\end{figure} + +Why does this centralization persist despite the explicit goals of +decentralization? +The answer lies in the practical barriers to self-hosting. +Cloud providers offer static IP addresses and publicly routable endpoints, +eliminating the networking complexity that plagues residential and +small-office deployments. +Most internet-connected devices sit behind Network Address Translation (NAT), +which prevents incoming connections without explicit port forwarding +or relay infrastructure. +Combined with dynamic IP assignments from ISPs, maintaining stable +peer connectivity +from self-hosted infrastructure traditionally required significant +technical expertise. + +Overlay VPNs offer a solution to this fundamental barrier. +By establishing encrypted tunnels that traverse NAT boundaries, +mesh VPNs enable direct peer-to-peer connectivity without requiring +static IP addresses or manual firewall configuration. +Each node receives a stable virtual address within the overlay network, +regardless of its underlying network topology. +This capability is transformative: +it allows a device behind consumer-grade NAT to participate +as a first-class peer in a distributed system, +removing the primary technical advantage that cloud providers hold. + +The Clan deployment framework builds on this foundation. +Clan leverages Nix and NixOS to eliminate entire classes of +configuration errors prevalent in contemporary infrastructure deployment, +reducing operational overhead to a degree where a single administrator +can reliably self-host complex distributed services. +Overlay VPNs are central to Clan's architecture, +providing the secure peer connectivity that enables nodes +to form cohesive networks regardless of their physical location or +NAT situation. +As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions +a web interface that enables users to design and deploy private P2P networks +with minimal configuration, assisted by an integrated LLM +for contextual guidance and troubleshooting. + +During the development of Clan, a recurring challenge became apparent: +practitioners held divergent preferences for mesh VPN solutions, +each citing different edge cases where their chosen VPN +proved unreliable or lacked essential features. +These discussions were largely grounded in anecdotal evidence +rather than systematic evaluation. +This observation revealed a clear need for rigorous, +evidence-based comparison of peer-to-peer overlay VPN implementations. + +Existing research on this topic remains sparse. +One notable work from 2024, ``Full-mesh VPN performance evaluation +for a secure edge-cloud continuum'' \cite{kjorveziroski_full-mesh_2024}, +benchmarks a subset of mesh VPNs but focuses primarily +on solutions with a central point of failure. +In contrast, this thesis evaluates more widely adopted mesh VPNs +with an emphasis on fully decentralized architectures. +Furthermore, that study relied exclusively on iperf3 for performance +measurement, +whereas our benchmark suite includes real-world workloads +to better reflect practical usage patterns. + +A further motivation was to create a fully automated benchmarking framework +capable of generating a public leaderboard, +similar in spirit to the js-framework-benchmark +(see Figure~\ref{fig:js-framework-benchmark}). +By providing an accessible web interface with regularly updated results, +we hope to encourage P2P VPN developers to optimize their implementations +in pursuit of top rankings. + +\begin{figure}[H] + \centering + \includegraphics[width=1\textwidth]{Figures/krause-js-framework.png} + \caption{js-framework-benchmark results for Chrome 144.0 + \cite{krause_krausestjs-framework-benchmark_2026}} + \label{fig:js-framework-benchmark} +\end{figure} + +\begin{figure}[h] + \centering + + % Row 1 + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage1.png} + \caption{Stage 1} + \end{subfigure} + \hfill + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage2.png} + \caption{Stage 2} + \end{subfigure} + + \vspace{1em} % Add spacing between rows + + % Row 2 + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage3.png} + \caption{Stage 3} + \end{subfigure} + \hfill + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage4.png} + \caption{Stage 4} + \end{subfigure} + + \vspace{1em} % Add spacing between rows + + % Row 3 + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage5.png} + \caption{Stage 5} + \end{subfigure} + \hfill + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage6.png} + \caption{Stage 6} + \end{subfigure} + + \vspace{1em} % Add spacing between rows + + % Row 4 + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage7.png} + \caption{Stage 7} + \end{subfigure} + \hfill + \begin{subfigure}{0.45\textwidth} + \centering + \includegraphics[width=\linewidth]{Figures/vision/stage8.png} + \caption{Stage 8} + \end{subfigure} + + \caption{Visionary Webinterface to Setup a Clan Family Network} + \label{fig:vision-stages} +\end{figure} + + +\subsection{Research Contribution} + +TODO + +\subsection{Related Work} + +\subsubsection{Nix: A Safe and Policy-Free System for Software Deployment} + +Nix addresses significant issues in software deployment by utilizing +cryptographic hashes to ensure unique paths for component instances +\cite{dolstra_nix_2004}. Features such as concurrent installation of +multiple versions, atomic upgrades, and safe garbage collection make +Nix a flexible deployment system. This work uses Nix to ensure that +all VPN builds and system configurations are deterministic. + +\subsubsection{NixOS: A Purely Functional Linux Distribution} + +NixOS extends Nix principles to Linux system configuration +\cite{dolstra_nixos_2008}. System configurations are reproducible and +isolated from stateful interactions typical in imperative package +management. This property is essential for ensuring identical test +environments across benchmark runs. + +\subsubsection{A Comparative Study on Virtual Private Networks} + +Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate +VPN protocols in the context of industrial communication systems (Industry 4.0), +benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard. +Their analysis focuses on point-to-point protocol performance; throughput, +latency, and CPU overhead; rather than overlay network behavior. +In contrast, this thesis evaluates VPNs that provide a full data plane +with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery. + +\subsubsection{Full-Mesh VPN Performance Evaluation} + +Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a +comprehensive evaluation of full-mesh VPN solutions for distributed +systems. Their benchmarks analyze throughput, reliability under packet +loss, and relay behavior for VPNs including ZeroTier. + +This thesis extends their work in several ways: +\begin{itemize} + \item Broader VPN selection with emphasis on fully decentralized + architectures + \item Real-world workloads (video streaming, package downloads) + beyond synthetic iperf3 tests + \item Multiple impairment profiles to characterize behavior under + varying network conditions + \item Fully reproducible experimental framework via Nix/NixOS/Clan +\end{itemize} + +\subsubsection{UDP NAT and Firewall Puncturing in the Wild} + +Halkes and Pouwelse~\cite{halkes_udp_2011} measure UDP hole punching +efficacy on a live P2P network using the Tribler BitTorrent client. +Their study finds that 79\% of peers are unreachable due to NAT or +firewall restrictions, yet 64\% reside behind configurations amenable +to hole punching. Among compatible peers, over 80\% of puncturing +attempts succeed, establishing hole punching as a practical NAT +traversal technique. Their timeout measurements further indicate that +keep-alive messages must be sent at least every 55 seconds to maintain +open NAT mappings. + +These findings directly inform the evaluation criteria for this thesis. +All mesh VPNs tested rely on UDP hole punching for NAT traversal; +the 80\% success rate sets a baseline expectation, while the 55-second +timeout informs analysis of each implementation's keep-alive behavior +during source code review. + +\subsubsection{An Overview of Packet Reordering in TCP} +TODO \cite{leung_overview_2007} + +\subsubsection{Performance Evaluation of TCP over QUIC Tunnels} +TODO \cite{guo_implementation_2025} \ No newline at end of file diff --git a/Chapters/Methodology.tex b/Chapters/Methodology.tex index d92e003..f8c77de 100755 --- a/Chapters/Methodology.tex +++ b/Chapters/Methodology.tex @@ -342,74 +342,3 @@ Every test result includes metadata recording: Results are organized hierarchically by VPN, TC profile, and machine pair. Each profile directory contains a \texttt{tc\_settings.json} snapshot of the exact impairment parameters applied. - -\section{Related Work} - -\subsection{Nix: A Safe and Policy-Free System for Software Deployment} - -Nix addresses significant issues in software deployment by utilizing -cryptographic hashes to ensure unique paths for component instances -\cite{dolstra_nix_2004}. Features such as concurrent installation of -multiple versions, atomic upgrades, and safe garbage collection make -Nix a flexible deployment system. This work uses Nix to ensure that -all VPN builds and system configurations are deterministic. - -\subsection{NixOS: A Purely Functional Linux Distribution} - -NixOS extends Nix principles to Linux system configuration -\cite{dolstra_nixos_2008}. System configurations are reproducible and -isolated from stateful interactions typical in imperative package -management. This property is essential for ensuring identical test -environments across benchmark runs. - -\subsection{A Comparative Study on Virtual Private Networks} - -Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate -VPN protocols in the context of industrial communication systems (Industry 4.0), -benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard. -Their analysis focuses on point-to-point protocol performance; throughput, -latency, and CPU overhead; rather than overlay network behavior. -In contrast, this thesis evaluates VPNs that provide a full data plane -with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery. - -\subsection{Full-Mesh VPN Performance Evaluation} - -Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a -comprehensive evaluation of full-mesh VPN solutions for distributed -systems. Their benchmarks analyze throughput, reliability under packet -loss, and relay behavior for VPNs including ZeroTier. - -This thesis extends their work in several ways: -\begin{itemize} - \item Broader VPN selection with emphasis on fully decentralized - architectures - \item Real-world workloads (video streaming, package downloads) - beyond synthetic iperf3 tests - \item Multiple impairment profiles to characterize behavior under - varying network conditions - \item Fully reproducible experimental framework via Nix/NixOS/Clan -\end{itemize} - -\subsection{UDP NAT and Firewall Puncturing in the Wild} - -Halkes and Pouwelse~\cite{halkes_udp_2011} measure UDP hole punching -efficacy on a live P2P network using the Tribler BitTorrent client. -Their study finds that 79\% of peers are unreachable due to NAT or -firewall restrictions, yet 64\% reside behind configurations amenable -to hole punching. Among compatible peers, over 80\% of puncturing -attempts succeed, establishing hole punching as a practical NAT -traversal technique. Their timeout measurements further indicate that -keep-alive messages must be sent at least every 55 seconds to maintain -open NAT mappings. - -These findings directly inform the evaluation criteria for this thesis. -All mesh VPNs tested rely on UDP hole punching for NAT traversal; -the 80\% success rate sets a baseline expectation, while the 55-second -timeout informs analysis of each implementation's keep-alive behavior -during source code review. - -\subsection{An Overview of Packet Reordering in TCP} -TODO \cite{leung_overview_2007} - -\subsection{Performance Evaluation of TCP over QUIC Tunnels} -TODO \cite{guo_implementation_2025} \ No newline at end of file diff --git a/Chapters/Motivation.tex b/Chapters/Motivation.tex deleted file mode 100644 index ebdd035..0000000 --- a/Chapters/Motivation.tex +++ /dev/null @@ -1,173 +0,0 @@ -\chapter{Motivation} % Main chapter title - -\label{Motivation} - -Peer-to-peer architectures promise censorship-resistant, fault-tolerant -infrastructure by eliminating single points of failure -\cite{shukla_towards_2021}. -These architectures underpin a growing range of systems---from IoT -edge computing -and content delivery networks to blockchain platforms like Ethereum. -Yet realizing these benefits requires distributing nodes across -genuinely diverse hosting entities. - -In practice, this diversity remains illusory. -Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes -(see Figure~\ref{fig:ethernodes_hosting}), -concentrating nominally decentralized infrastructure -within a handful of cloud providers. -More concerning, these providers operate under overlapping regulatory -jurisdictions, -predominantly the United States and the European Union. -This concentration undermines technical sovereignty: -a single governmental action could compel service termination, -data disclosure, or traffic manipulation across a majority of the network. - -\begin{figure}[H] - \centering - \includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png} - \caption{Distribution of Ethereum nodes hosted by various providers - \cite{noauthor_isps_nodate}} - \label{fig:ethernodes_hosting} -\end{figure} - -Why does this centralization persist despite the explicit goals of -decentralization? -The answer lies in the practical barriers to self-hosting. -Cloud providers offer static IP addresses and publicly routable endpoints, -eliminating the networking complexity that plagues residential and -small-office deployments. -Most internet-connected devices sit behind Network Address Translation (NAT), -which prevents incoming connections without explicit port forwarding -or relay infrastructure. -Combined with dynamic IP assignments from ISPs, maintaining stable -peer connectivity -from self-hosted infrastructure traditionally required significant -technical expertise. - -Overlay VPNs offer a solution to this fundamental barrier. -By establishing encrypted tunnels that traverse NAT boundaries, -mesh VPNs enable direct peer-to-peer connectivity without requiring -static IP addresses or manual firewall configuration. -Each node receives a stable virtual address within the overlay network, -regardless of its underlying network topology. -This capability is transformative: -it allows a device behind consumer-grade NAT to participate -as a first-class peer in a distributed system, -removing the primary technical advantage that cloud providers hold. - -The Clan deployment framework builds on this foundation. -Clan leverages Nix and NixOS to eliminate entire classes of -configuration errors prevalent in contemporary infrastructure deployment, -reducing operational overhead to a degree where a single administrator -can reliably self-host complex distributed services. -Overlay VPNs are central to Clan's architecture, -providing the secure peer connectivity that enables nodes -to form cohesive networks regardless of their physical location or -NAT situation. -As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions -a web interface that enables users to design and deploy private P2P networks -with minimal configuration, assisted by an integrated LLM -for contextual guidance and troubleshooting. - -During the development of Clan, a recurring challenge became apparent: -practitioners held divergent preferences for mesh VPN solutions, -each citing different edge cases where their chosen VPN -proved unreliable or lacked essential features. -These discussions were largely grounded in anecdotal evidence -rather than systematic evaluation. -This observation revealed a clear need for rigorous, -evidence-based comparison of peer-to-peer overlay VPN implementations. - -Existing research on this topic remains sparse. -One notable work from 2024, ``Full-mesh VPN performance evaluation -for a secure edge-cloud continuum'' \cite{kjorveziroski_full-mesh_2024}, -benchmarks a subset of mesh VPNs but focuses primarily -on solutions with a central point of failure. -In contrast, this thesis evaluates more widely adopted mesh VPNs -with an emphasis on fully decentralized architectures. -Furthermore, that study relied exclusively on iperf3 for performance -measurement, -whereas our benchmark suite includes real-world workloads -to better reflect practical usage patterns. - -A further motivation was to create a fully automated benchmarking framework -capable of generating a public leaderboard, -similar in spirit to the js-framework-benchmark -(see Figure~\ref{fig:js-framework-benchmark}). -By providing an accessible web interface with regularly updated results, -we hope to encourage P2P VPN developers to optimize their implementations -in pursuit of top rankings. - -\begin{figure}[H] - \centering - \includegraphics[width=1\textwidth]{Figures/krause-js-framework.png} - \caption{js-framework-benchmark results for Chrome 144.0 - \cite{krause_krausestjs-framework-benchmark_2026}} - \label{fig:js-framework-benchmark} -\end{figure} - -\begin{figure}[h] - \centering - - % Row 1 - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage1.png} - \caption{Stage 1} - \end{subfigure} - \hfill - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage2.png} - \caption{Stage 2} - \end{subfigure} - - \vspace{1em} % Add spacing between rows - - % Row 2 - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage3.png} - \caption{Stage 3} - \end{subfigure} - \hfill - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage4.png} - \caption{Stage 4} - \end{subfigure} - - \vspace{1em} % Add spacing between rows - - % Row 3 - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage5.png} - \caption{Stage 5} - \end{subfigure} - \hfill - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage6.png} - \caption{Stage 6} - \end{subfigure} - - \vspace{1em} % Add spacing between rows - - % Row 4 - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage7.png} - \caption{Stage 7} - \end{subfigure} - \hfill - \begin{subfigure}{0.45\textwidth} - \centering - \includegraphics[width=\linewidth]{Figures/vision/stage8.png} - \caption{Stage 8} - \end{subfigure} - - \caption{Visionary Webinterface to Setup a Clan Family Network} - \label{fig:vision-stages} -\end{figure} diff --git a/main.tex b/main.tex index 95d5f2e..ffe6abc 100644 --- a/main.tex +++ b/main.tex @@ -25,10 +25,10 @@ \documentclass[ 11pt, % The default document font size, options: 10pt, 11pt, 12pt - oneside, % Two side (alternating margins) for binding by default, + oneside,%twoside, % Two side (alternating margins) for binding by default, % uncomment to switch to one side english, % ngerman for German - singlespacing, % Single line spacing, alternatives: onehalfspacing + onehalfspacing, % Single line spacing, alternatives: onehalfspacing % or doublespacing %draft, % Uncomment to enable draft mode (no pictures, no links, % overfull hboxes indicated) @@ -75,13 +75,12 @@ %---------------------------------------------------------------------------------------- \geometry{ - paper=a4paper, % Change to letterpaper for US letter - inner=2.5cm, % Inner margin - outer=3.8cm, % Outer margin - bindingoffset=.5cm, % Binding offset - top=1.5cm, % Top margin - bottom=1.5cm, % Bottom margin - %showframe, % Uncomment to show how the type block is set on the page + paper=a4paper, + inner=3.0cm, % Bindungsseite – braucht mehr Platz + outer=2.5cm, % Außenseite + bindingoffset=0.5cm, % Zusätzlich für Klebebindung + top=2.5cm, + bottom=2.0cm, } %---------------------------------------------------------------------------------------- @@ -91,7 +90,7 @@ \thesistitle{Decrypting the Overlay: A Reproducible Analysis of P2P VPN Implementation and Overhead} % Your thesis title, this is used in the title % and abstract, print it elsewhere with \ttitle -\supervisor{\textsc{Ber Lorke}} % Your supervisor's name, this is +%\supervisor{\textsc{Ber Lorke}} % Your supervisor's name, this is % used in the title page, print it elsewhere with \supname \examiner{Prof. Dr. \textsc{Stefan Schmid}} % Your examiner's name, % this is not currently used anywhere in the template, print it @@ -158,11 +157,11 @@ and Management}} % Your department's name and URL, this is used in \begin{minipage}[t]{0.4\textwidth} \begin{flushright} \large \emph{First Examiner:} \\ - \textcolor{mdtRed}{Prof.\ Dr.\ \textsc{Stefan Schmidt}}\\[1em] + \textcolor{mdtRed}{Prof.\ Dr.\ \textsc{Stefan Schmid}}\\[1em] \emph{Second Examiner:} \\ \textcolor{mdtRed}{\textsc{[TBD]}}\\[1em] - \emph{Supervisor:} \\ - \textcolor{mdtRed}{\supname} + %\emph{Supervisor:} \\ + %\textcolor{mdtRed}{\supname} \end{flushright} \end{minipage}\\[2cm] @@ -350,10 +349,9 @@ and Management}} % Your department's name and URL, this is used in % Include the chapters of the thesis as separate files from the Chapters folder % Uncomment the lines as you write the chapters -\include{Chapters/Motivation} +\include{Chapters/Introduction} \include{Chapters/Methodology} -\include{Chapters/Introduction} %\include{Chapters/Chapter1} %\include{Chapters/Chapter2}