Compare commits
2 Commits
d396de9f62
...
c5ee9deeba
| Author | SHA1 | Date | |
|---|---|---|---|
| c5ee9deeba | |||
| 200c8ba004 |
1
.gitignore
vendored
1
.gitignore
vendored
@@ -1,4 +1,5 @@
|
|||||||
# LaTeX intermediate and output files
|
# LaTeX intermediate and output files
|
||||||
|
result
|
||||||
*.aux
|
*.aux
|
||||||
**/*.bak.*
|
**/*.bak.*
|
||||||
*.bbl
|
*.bbl
|
||||||
|
|||||||
@@ -6,8 +6,8 @@
|
|||||||
|
|
||||||
This chapter describes the methodology used to benchmark peer-to-peer
|
This chapter describes the methodology used to benchmark peer-to-peer
|
||||||
mesh VPN implementations. The experimental design prioritizes
|
mesh VPN implementations. The experimental design prioritizes
|
||||||
reproducibility at every layer---from dependency management to network
|
reproducibility at every layer; from dependency management to network
|
||||||
conditions---enabling independent verification of results and
|
conditions; enabling independent verification of results and
|
||||||
facilitating future comparative studies.
|
facilitating future comparative studies.
|
||||||
|
|
||||||
\section{Experimental Setup}
|
\section{Experimental Setup}
|
||||||
@@ -20,7 +20,8 @@ identical specifications:
|
|||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item \textbf{CPU:} Intel Model 94, 4 cores / 8 threads
|
\item \textbf{CPU:} Intel Model 94, 4 cores / 8 threads
|
||||||
\item \textbf{Memory:} 64 GB RAM
|
\item \textbf{Memory:} 64 GB RAM
|
||||||
\item \textbf{Network:} 1 Gbps Ethernet (e1000e driver; one machine uses r8169)
|
\item \textbf{Network:} 1 Gbps Ethernet (e1000e driver; one machine
|
||||||
|
uses r8169)
|
||||||
\item \textbf{Cryptographic acceleration:} AES-NI, AVX, AVX2, PCLMULQDQ,
|
\item \textbf{Cryptographic acceleration:} AES-NI, AVX, AVX2, PCLMULQDQ,
|
||||||
RDRAND, SSE4.2
|
RDRAND, SSE4.2
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
@@ -56,7 +57,8 @@ mesh topologies. Table~\ref{tab:vpn_selection} summarizes the selection.
|
|||||||
\hline
|
\hline
|
||||||
\textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\
|
\textbf{VPN} & \textbf{Architecture} & \textbf{Notes} \\
|
||||||
\hline
|
\hline
|
||||||
Tailscale (Headscale) & Coordinated mesh & Open-source coordination server \\
|
Tailscale (Headscale) & Coordinated mesh & Open-source
|
||||||
|
coordination server \\
|
||||||
ZeroTier & Coordinated mesh & Global virtual Ethernet \\
|
ZeroTier & Coordinated mesh & Global virtual Ethernet \\
|
||||||
Nebula & Coordinated mesh & Slack's overlay network \\
|
Nebula & Coordinated mesh & Slack's overlay network \\
|
||||||
Tinc & Fully decentralized & Established since 1998 \\
|
Tinc & Fully decentralized & Established since 1998 \\
|
||||||
@@ -208,9 +210,9 @@ effective round-trip impairment is approximately doubled.
|
|||||||
\begin{tabular}{lccccc}
|
\begin{tabular}{lccccc}
|
||||||
\hline
|
\hline
|
||||||
\textbf{Profile} & \textbf{Latency} & \textbf{Jitter} &
|
\textbf{Profile} & \textbf{Latency} & \textbf{Jitter} &
|
||||||
\textbf{Loss} & \textbf{Reorder} & \textbf{Correlation} \\
|
\textbf{Loss} & \textbf{Reorder} & \textbf{Correlation} \\
|
||||||
\hline
|
\hline
|
||||||
Baseline & --- & --- & --- & --- & --- \\
|
Baseline & ; & ; & ; & ; & ; \\
|
||||||
Low & 2 ms & 2 ms & 0.25\% & 0.5\% & 25\% \\
|
Low & 2 ms & 2 ms & 0.25\% & 0.5\% & 25\% \\
|
||||||
Medium & 4 ms & 7 ms & 1.0\% & 2.5\% & 50\% \\
|
Medium & 4 ms & 7 ms & 1.0\% & 2.5\% & 50\% \\
|
||||||
High & 12 ms & 30 ms & 5.0\% & 10\% & 50\% \\
|
High & 12 ms & 30 ms & 5.0\% & 10\% & 50\% \\
|
||||||
@@ -289,7 +291,8 @@ Key pinned inputs include:
|
|||||||
\item \textbf{nixpkgs:} Follows \texttt{clan-core/nixpkgs}, ensuring a
|
\item \textbf{nixpkgs:} Follows \texttt{clan-core/nixpkgs}, ensuring a
|
||||||
single version across the dependency graph
|
single version across the dependency graph
|
||||||
\item \textbf{clan-core:} The Clan framework, pinned to a specific commit
|
\item \textbf{clan-core:} The Clan framework, pinned to a specific commit
|
||||||
\item \textbf{VPN sources:} Hyprspace, EasyTier, Nebula locked to exact commits
|
\item \textbf{VPN sources:} Hyprspace, EasyTier, Nebula locked to
|
||||||
|
exact commits
|
||||||
\item \textbf{Build infrastructure:} flake-parts, treefmt-nix, disko,
|
\item \textbf{Build infrastructure:} flake-parts, treefmt-nix, disko,
|
||||||
nixos-facter-modules
|
nixos-facter-modules
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
@@ -312,7 +315,7 @@ configuration entirely or rolls back.
|
|||||||
Clan's inventory system maps machines to service roles declaratively.
|
Clan's inventory system maps machines to service roles declaratively.
|
||||||
For each VPN, the orchestrator writes an inventory entry assigning
|
For each VPN, the orchestrator writes an inventory entry assigning
|
||||||
machines to roles (e.g., Nebula lighthouse vs.\ peer). The Clan module
|
machines to roles (e.g., Nebula lighthouse vs.\ peer). The Clan module
|
||||||
system translates this into NixOS configuration---systemd services,
|
system translates this into NixOS configuration; systemd services,
|
||||||
firewall rules, peer lists, and key references. The same inventory
|
firewall rules, peer lists, and key references. The same inventory
|
||||||
entry always produces the same NixOS configuration.
|
entry always produces the same NixOS configuration.
|
||||||
|
|
||||||
@@ -364,12 +367,11 @@ environments across benchmark runs.
|
|||||||
Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate
|
Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate
|
||||||
VPN protocols in the context of industrial communication systems (Industry 4.0),
|
VPN protocols in the context of industrial communication systems (Industry 4.0),
|
||||||
benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard.
|
benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard.
|
||||||
Their analysis focuses on point-to-point protocol performance---throughput,
|
Their analysis focuses on point-to-point protocol performance; throughput,
|
||||||
latency, and CPU overhead---rather than overlay network behavior.
|
latency, and CPU overhead; rather than overlay network behavior.
|
||||||
In contrast, this thesis evaluates VPNs that provide a full data plane
|
In contrast, this thesis evaluates VPNs that provide a full data plane
|
||||||
with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery.
|
with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery.
|
||||||
|
|
||||||
|
|
||||||
\subsection{Full-Mesh VPN Performance Evaluation}
|
\subsection{Full-Mesh VPN Performance Evaluation}
|
||||||
|
|
||||||
Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a
|
Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a
|
||||||
@@ -388,4 +390,3 @@ This thesis extends their work in several ways:
|
|||||||
\item Fully reproducible experimental framework via Nix/NixOS/Clan
|
\item Fully reproducible experimental framework via Nix/NixOS/Clan
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -3,8 +3,10 @@
|
|||||||
\label{Motivation}
|
\label{Motivation}
|
||||||
|
|
||||||
Peer-to-peer architectures promise censorship-resistant, fault-tolerant
|
Peer-to-peer architectures promise censorship-resistant, fault-tolerant
|
||||||
infrastructure by eliminating single points of failure \cite{shukla_towards_2021}.
|
infrastructure by eliminating single points of failure
|
||||||
These architectures underpin a growing range of systems---from IoT edge computing
|
\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.
|
and content delivery networks to blockchain platforms like Ethereum.
|
||||||
Yet realizing these benefits requires distributing nodes across
|
Yet realizing these benefits requires distributing nodes across
|
||||||
genuinely diverse hosting entities.
|
genuinely diverse hosting entities.
|
||||||
@@ -14,7 +16,8 @@ Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
|
|||||||
(see Figure~\ref{fig:ethernodes_hosting}),
|
(see Figure~\ref{fig:ethernodes_hosting}),
|
||||||
concentrating nominally decentralized infrastructure
|
concentrating nominally decentralized infrastructure
|
||||||
within a handful of cloud providers.
|
within a handful of cloud providers.
|
||||||
More concerning, these providers operate under overlapping regulatory jurisdictions,
|
More concerning, these providers operate under overlapping regulatory
|
||||||
|
jurisdictions,
|
||||||
predominantly the United States and the European Union.
|
predominantly the United States and the European Union.
|
||||||
This concentration undermines technical sovereignty:
|
This concentration undermines technical sovereignty:
|
||||||
a single governmental action could compel service termination,
|
a single governmental action could compel service termination,
|
||||||
@@ -28,7 +31,8 @@ data disclosure, or traffic manipulation across a majority of the network.
|
|||||||
\label{fig:ethernodes_hosting}
|
\label{fig:ethernodes_hosting}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Why does this centralization persist despite the explicit goals of decentralization?
|
Why does this centralization persist despite the explicit goals of
|
||||||
|
decentralization?
|
||||||
The answer lies in the practical barriers to self-hosting.
|
The answer lies in the practical barriers to self-hosting.
|
||||||
Cloud providers offer static IP addresses and publicly routable endpoints,
|
Cloud providers offer static IP addresses and publicly routable endpoints,
|
||||||
eliminating the networking complexity that plagues residential and
|
eliminating the networking complexity that plagues residential and
|
||||||
@@ -36,8 +40,10 @@ small-office deployments.
|
|||||||
Most internet-connected devices sit behind Network Address Translation (NAT),
|
Most internet-connected devices sit behind Network Address Translation (NAT),
|
||||||
which prevents incoming connections without explicit port forwarding
|
which prevents incoming connections without explicit port forwarding
|
||||||
or relay infrastructure.
|
or relay infrastructure.
|
||||||
Combined with dynamic IP assignments from ISPs, maintaining stable peer connectivity
|
Combined with dynamic IP assignments from ISPs, maintaining stable
|
||||||
from self-hosted infrastructure traditionally required significant technical expertise.
|
peer connectivity
|
||||||
|
from self-hosted infrastructure traditionally required significant
|
||||||
|
technical expertise.
|
||||||
|
|
||||||
Overlay VPNs offer a solution to this fundamental barrier.
|
Overlay VPNs offer a solution to this fundamental barrier.
|
||||||
By establishing encrypted tunnels that traverse NAT boundaries,
|
By establishing encrypted tunnels that traverse NAT boundaries,
|
||||||
@@ -57,7 +63,8 @@ reducing operational overhead to a degree where a single administrator
|
|||||||
can reliably self-host complex distributed services.
|
can reliably self-host complex distributed services.
|
||||||
Overlay VPNs are central to Clan's architecture,
|
Overlay VPNs are central to Clan's architecture,
|
||||||
providing the secure peer connectivity that enables nodes
|
providing the secure peer connectivity that enables nodes
|
||||||
to form cohesive networks regardless of their physical location or NAT situation.
|
to form cohesive networks regardless of their physical location or
|
||||||
|
NAT situation.
|
||||||
As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
|
As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
|
||||||
a web interface that enables users to design and deploy private P2P networks
|
a web interface that enables users to design and deploy private P2P networks
|
||||||
with minimal configuration, assisted by an integrated LLM
|
with minimal configuration, assisted by an integrated LLM
|
||||||
@@ -79,7 +86,8 @@ benchmarks a subset of mesh VPNs but focuses primarily
|
|||||||
on solutions with a central point of failure.
|
on solutions with a central point of failure.
|
||||||
In contrast, this thesis evaluates more widely adopted mesh VPNs
|
In contrast, this thesis evaluates more widely adopted mesh VPNs
|
||||||
with an emphasis on fully decentralized architectures.
|
with an emphasis on fully decentralized architectures.
|
||||||
Furthermore, that study relied exclusively on iperf3 for performance measurement,
|
Furthermore, that study relied exclusively on iperf3 for performance
|
||||||
|
measurement,
|
||||||
whereas our benchmark suite includes real-world workloads
|
whereas our benchmark suite includes real-world workloads
|
||||||
to better reflect practical usage patterns.
|
to better reflect practical usage patterns.
|
||||||
|
|
||||||
|
|||||||
12
main.tex
12
main.tex
@@ -152,17 +152,19 @@ and Management}} % Your department's name and URL, this is used in
|
|||||||
\begin{minipage}[t]{0.4\textwidth}
|
\begin{minipage}[t]{0.4\textwidth}
|
||||||
\begin{flushleft} \large
|
\begin{flushleft} \large
|
||||||
\emph{Author:}\\
|
\emph{Author:}\\
|
||||||
\href{http://www.johnsmith.com}{\authorname} % Author name -
|
\textcolor{mdtRed}{\authorname}
|
||||||
% remove the \href bracket to remove the link
|
|
||||||
\end{flushleft}
|
\end{flushleft}
|
||||||
\end{minipage}
|
\end{minipage}
|
||||||
\begin{minipage}[t]{0.4\textwidth}
|
\begin{minipage}[t]{0.4\textwidth}
|
||||||
\begin{flushright} \large
|
\begin{flushright} \large
|
||||||
|
\emph{First Examiner:} \\
|
||||||
|
\textcolor{mdtRed}{Prof.\ Dr.\ \textsc{Stefan Schmidt}}\\[1em]
|
||||||
|
\emph{Second Examiner:} \\
|
||||||
|
\textcolor{mdtRed}{\textsc{[TBD]}}\\[1em]
|
||||||
\emph{Supervisor:} \\
|
\emph{Supervisor:} \\
|
||||||
\href{http://www.jamessmith.com}{\supname} % Supervisor name
|
\textcolor{mdtRed}{\supname}
|
||||||
% - remove the \href bracket to remove the link
|
|
||||||
\end{flushright}
|
\end{flushright}
|
||||||
\end{minipage}\\[3cm]
|
\end{minipage}\\[2cm]
|
||||||
|
|
||||||
\vfill
|
\vfill
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user