This document describes instructions for the NDSS Artifact Evaluation (AE) process. We provide the VMs as OVA files for the reproduction of evaluations and simple test runs. If you use OVA files, you can skip VM setup steps (1) and proceed from (2).
This section describes how to prepare the client and proxy-server VMs for the TrafficSplitter artifact evaluation.
If you are using the provided OVA files, you may skip this section.
- The VM setup consists of two main steps: (1) installing Ubuntu 24.04 Desktop on VirtualBox and (2) installing the custom Linux kernel. We use Ubuntu 24.04 Desktop rather than the Server edition to make the overall evaluation process easier and more user-friendly.
- Our system uses a non-mainline Linux kernel. We began developing the system when the MPTCP eBPF scheduler was still an experimental feature and had not yet been included in the mainline Linux kernel. Since then, the MPTCP eBPF scheduler has become an official kernel feature. However, we continue to use the older custom kernel because (1) the eBPF-related structures have changed in newer kernel versions, and (2) our system has already been extensively tested and is stable with the kernel version used during development and evaluation.
-
Download the Ubuntu 24.04 Desktop image from:
-
Create two VirtualBox VMs:
- one for the client;
- one for the proxy server.
We recommend allocating at least:
- 50 GB of storage
- 3 CPU cores
- 8 GB of RAM
These resources are mainly required for kernel compilation. After the kernel has been successfully compiled and installed, you may reduce the allocated resources if needed.
-
Install Ubuntu 24.04 Desktop on both VMs.
Please note that shell scripts are provided for the following procedure. You may use the scripts instead of performing each step manually.
-
Clone the MPTCP kernel repository and check out the exact version used in our artifact.
git clone https://github.com/multipath-tcp/mptcp_net-next.git cd mptcp_net-next git fetch origin git checkout 4d907d0e9f974e706ad6f916b8bf2391d82573bf -
Update the Ubuntu APT source configuration.
Open the APT source file:
sudo vim /etc/apt/sources.list.d/ubuntu.sources
Replace or update the contents so that both binary packages (
deb) and source packages (deb-src) are enabled:Types: deb deb-src URIs: http://us.archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports noble-proposed Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg Types: deb deb-src URIs: http://security.ubuntu.com/ubuntu/ Suites: noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpgThis configuration enables access to both binary and source packages from the standard Ubuntu 24.04 repositories. The source repositories are required for installing some kernel build dependencies and related development packages.
-
Update and upgrade the system:
sudo apt update sudo apt upgrade
-
Install the required kernel build dependencies:
sudo apt-get build-dep linux linux-image-unsigned-$(uname -r) sudo apt-get install libncurses-dev gawk flex bison openssl \ libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev \ autoconf -
Copy the current kernel configuration into the
mptcp_net-nextdirectory:cp /boot/config-$(uname -r) .config make olddefconfig -
Generate a self-signed certificate for kernel module signing.
From the
mptcp_net-nextdirectory, run:openssl req -x509 -newkey rsa:4096 \ -keyout certs/mycert.pem \ -out certs/mycert.pem \ -nodes \ -days 3650 -
Update the kernel configuration to use the generated certificate.
Open the kernel configuration file:
sudo vim .config
Find the following options:
CONFIG_SYSTEM_TRUSTED_KEYS CONFIG_MODULE_SIG_KEYUpdate them as follows:
CONFIG_SYSTEM_TRUSTED_KEYS="certs/mycert.pem" CONFIG_MODULE_SIG_KEY="certs/mycert.pem"
-
Compile and install the kernel.
This step may take some time.
make -j$(nproc) sudo make modules_install sudo make install -
Configure GRUB to boot the desired kernel version.
Open the GRUB configuration file:
sudo vim /etc/default/grub
Make the following changes:
GRUB_DEFAULT=saved GRUB_SAVEDEFAULT=true GRUB_TIMEOUT_STYLE=menu GRUB_TIMEOUT=10Then update the GRUB configuration:
sudo update-grub
Reboot the VM and select the newly installed kernel from the GRUB menu.
GRUB should remember the selected kernel for subsequent boots.
-
After rebooting, verify the running kernel:
uname -r-
Clone the TrafficSplitter repository:
git clone https://github.com/LENSS/TrafficSplitter.git
-
Move to the
srcdirectory:cd TrafficSplitter/src/ -
Make the build scripts executable:
chmod +x ./scripts/*.sh -
Run the provided scripts to install the BPF tools and build the TrafficSplitter components:
sudo ./scripts/01-install-bpf-tools.sh sudo ./scripts/02-generate-vmlinux-header.sh sudo ./scripts/03-build-schedulers.sh sudo ./scripts/04-build-mptun.sh
These scripts build the required BPF tools, MPTCP schedulers, and MPTun client/server binaries.
-
Verify the generated files:
ls MPTun_proxy/build/ ls Saflo_scheduler/build/
-
Optionally, remove the local
bpftoolsource directory after installation:sudo rm -rf tools/
After completing these steps on both VMs, proceed to the VirtualBox network configuration.
If you are using the provided OVA files, the VM password is
ndss2027.
We assume that you have already installed VirtualBox and prepared the two VMs either by following the VM setup instructions or by importing the OVA files provided with the artifact.
Before starting the evaluation, create a VirtualBox NAT Network named aeNet on the host machine. This network enables communication between the client and proxy VMs.
The intended IP configuration is:
| Machine | Adapter | IP Address |
|---|---|---|
| User (Client) | NIC 1 | 192.168.10.10 |
| User (Client) | NIC 2 | 192.168.10.11 |
| Proxy Server | NIC 1 | 192.168.10.12 |
| NAT Gateway | — | 192.168.10.1 |
| DHCP Server | — | 192.168.10.2 |
The dynamic DHCP pool is configured as 192.168.10.100–192.168.10.254, leaving the lower addresses available for the fixed VM addresses.
Open a terminal on the host machine.
VBoxManage natnetwork add \
--netname aeNet \
--network "192.168.10.0/24" \
--enable \
--dhcp onVBoxManage natnetwork start --netname aeNetVBoxManage dhcpserver modify \
--network aeNet \
--server-ip 192.168.10.2 \
--lower-ip 192.168.10.100 \
--upper-ip 192.168.10.254 \
--netmask 255.255.255.0 \
--enableBefore assigning the fixed IP addresses, check the names of the imported VMs:
VBoxManage list vmsThe following commands assume that the VM names are:
userproxy-server
If your VM names are different, replace them accordingly in the commands below.
Client NIC 1:
VBoxManage dhcpserver modify \
--network aeNet \
--vm "user" \
--nic 1 \
--fixed-address 192.168.10.10Client NIC 2:
VBoxManage dhcpserver modify \
--network aeNet \
--vm "user" \
--nic 2 \
--fixed-address 192.168.10.11Proxy Server NIC 1:
VBoxManage dhcpserver modify \
--network aeNet \
--vm "proxy-server" \
--nic 1 \
--fixed-address 192.168.10.12VBoxManage dhcpserver restart --network aeNetOpen Command Prompt or PowerShell on the host machine.
VBoxManage.exe natnetwork add --netname aeNet --network "192.168.10.0/24" --enable --dhcp on
VBoxManage.exe natnetwork start --netname aeNet
VBoxManage.exe dhcpserver modify --network aeNet --server-ip 192.168.10.2 --lower-ip 192.168.10.100 --upper-ip 192.168.10.254 --netmask 255.255.255.0 --enable
VBoxManage.exe list vms
The following commands assume that the VM names are user and proxy-server. If your VM names are different, replace them accordingly.
VBoxManage.exe dhcpserver modify --network aeNet --vm "user" --nic 1 --fixed-address 192.168.10.10
VBoxManage.exe dhcpserver modify --network aeNet --vm "user" --nic 2 --fixed-address 192.168.10.11
VBoxManage.exe dhcpserver modify --network aeNet --vm "proxy-server" --nic 1 --fixed-address 192.168.10.12
VBoxManage.exe dhcpserver restart --network aeNet
If Windows reports that VBoxManage.exe is not recognized, run the commands from the VirtualBox installation directory, for example:
C:\Program Files\Oracle\VirtualBox
After creating the NAT Network, configure the network adapters of the two VMs.
The client VM requires two network adapters:
- Adapter 1: NAT Network →
aeNet - Adapter 2: NAT Network →
aeNet
NIC 1: 192.168.10.10
NIC 2: 192.168.10.11
The proxy VM requires one network adapter:
- Adapter 1: NAT Network →
aeNet
The expected IP address is:
NIC 1: 192.168.10.12
This configuration generates the network topology shown below.
This test verifies that the MPTCP tunnel is established correctly, that two subflows are created, and that the Saflo scheduler operates as expected.
On both the client VM and the proxy server VM, open a terminal and move to the eval directory of the TrafficSplitter repository:
cd ~/ndss27/TrafficSplitter/evalPrepare two terminal tabs on each VM:
- Tab 1: Run the evaluation script.
- Tab 2: Monitor the Saflo subflow manager log.
On the proxy server VM, run the following command in the first terminal tab:
sudo ./01-run-func/run-trafficsplitter-server.shThe script configures MPTCP, registers and selects the Saflo scheduler, starts the MPTun proxy server, and starts the Saflo subflow manager.
In the second terminal tab, monitor the subflow manager log:
tail -f 01-run-func/subflow-manager.logThe log shows kernel-level MPTCP subflow information and the operation of the Saflo scheduler.
On the client VM, run the following command in the first terminal tab:
sudo ./01-run-func/run-trafficsplitter-client.shIn the second terminal tab, monitor the client-side subflow manager log:
tail -f 01-run-func/subflow-manager.logAfter the client connects to the proxy, you should observe that the MPTCP tunnel is established with two subflows. The log also shows kernel-level information about the subflows and the operation of the Saflo scheduler.
You can additionally inspect how traffic is distributed across the two client interfaces using Wireshark.
On the client VM, open another terminal tab and run:
sudo wiresharkIn Wireshark, monitor both client network interfaces.
Then, open Firefox and generate some traffic, for example by:
- visiting several websites; or
- playing an online video.
Observe how MPTCP traffic is distributed across the two network interfaces.
A successful basic functionality test should show:
- an MPTCP tunnel established between the client and proxy;
- two active MPTCP subflows;
- Saflo scheduler activity in the subflow manager log; and
- network traffic distributed across both client interfaces.
When you are finished, press Ctrl+C in the terminals running run-trafficsplitter-server.sh and run-trafficsplitter-client.sh to stop the evaluation processes.
Optionally, you can run our BWR implementation with MPTun and eBPF instead of TrafficSplitter and monitor its operation using run-bwr-server.sh and run-bwr-client.sh.
BWR does not use the Saflo subflow manager component.
In this AE, we conduct a scaled-down traffic-analysis evaluation using two defense configurations:
- TrafficSplitter
- BWR
The purpose of this evaluation is to demonstrate the difference between the two defenses:
- TrafficSplitter is designed to provide a more comprehensive defense against both website fingerprinting (WF) and video fingerprinting (VF), as well as other traffic-analysis attacks that fall between them.
- BWR is a traffic-splitting defense designed primarily for website fingerprinting and is therefore used as an attack-specific baseline (i.e., it is ineffective against VF).
We assume a single-path eavesdropper which can monitor one of paths between the user and tunneled-proxy. The eavesdropper is also aware of defense strategies and train its attack classifier on the traces generated under the defenses.
Before conducting the traffic-analysis evaluation, we first prepare traffic traces.
We provide pre-collected traffic traces that are already included in our git repository. So, if your goal is to evaluate the reproducibility of our work or just simply test traffic analysis evaluation, you may skip this section and proceed directly to the scaled-down traffic-analysis evaluation. You just need to unzip the pre-collected traces included in our git repository.
sudo apt install unzip
cd ~/ndss27/TrafficSplitter/eval/02-data-collection
unzip "*.zip"If you would like to collect traffic traces yourself or extend the provided dataset, you can follow the procedure below. We assume an eavesdropper monitoring the first network interface of the client VM; therefore, traffic is collected from this interface. The client generates traffic by visiting websites or playing YouTube videos in Google Chrome while tcpdump records the traffic.
On both VMs, move to the evaluation directory:
cd ~/ndss27/TrafficSplitter/evalAs in Section (3), start the server first, followed by the client.
On the proxy server VM:
sudo ./01-run-func/run-trafficsplitter-server.shOn the client VM:
sudo ./01-run-func/run-trafficsplitter-client.shOn the proxy server VM:
sudo ./01-run-func/run-bwr-server.shOn the client VM:
sudo ./01-run-func/run-bwr-client.shBWR does not use the Saflo subflow manager component.
Open a new terminal tab on the client VM and run:
./02-data/collection/web-collecting.sh <trace-name>For example, when collecting traces with TrafficSplitter:
./02-data/collection/web-collecting.sh trafficsplitterFor BWR:
./02-data/collection/web-collecting.sh bwrSimilarly, collect video traces on the client VM using:
./02-data/collection/video-collecting.sh <trace-name>For example, when collecting traces with TrafficSplitter:
./02-data/collection/video-collecting.sh trafficsplitterFor BWR:
./02-data/collection/video-collecting.sh bwrYou may also run the website and video collection scripts sequentially.
For TrafficSplitter:
./02-data/collection/web-collecting.sh trafficsplitter && \
./02-data/collection/video-collecting.sh trafficsplitterFor BWR:
./02-data/collection/web-collecting.sh bwr && \
./02-data/collection/video-collecting.sh bwrThe second collection script starts only after the first one completes successfully.
This evaluation is conducted on the client VM, where the traffic traces are available.
First, make sure the Python virtual environment is configured properly. If you imported the provided OVA files, it is already configured and you can skip this step. Otherwise, please create and activate a Python virtual environment:
sudo apt install -y python3-venv python3-full
cd ~/ndss27/TrafficSplitter/eval/03-traffic-analysis
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install tensorflow pandas matplotlibmatplotlib is optional and is only needed for plotting traces.
Also, please make sure that the traffic traces are located in the following directory:
TrafficSplitter/eval/02-data-collection/bwr-video-traces/
TrafficSplitter/eval/02-data-collection/bwr-web-traces/
TrafficSplitter/eval/02-data-collection/trafficsplitter-video-traces/
TrafficSplitter/eval/02-data-collection/trafficsplitter-web-traces/
Move to the traffic-analysis evaluation directory:
cd ~/ndss2027/TrafficSplitter/eval/03-traffic-analysisThen run:
./run-traffic-analysis.shThe script automatically:
- preprocesses the TrafficSplitter and BWR website traces;
- preprocesses the TrafficSplitter and BWR video traces;
- trains and evaluates the website-fingerprinting classifier;
- trains and evaluates the video-fingerprinting classifier; and
- prints a summary table in the terminal.
Please note that, because this AE uses a substantially smaller dataset than the full evaluation in the paper, we use lighter versions of the WF and VF classifiers to reduce training time and computational requirements on the VM.
At the end of the evaluation, you should see a summary similar to:
============================================================
Traffic-Analysis Evaluation Results
============================================================
Attack | TrafficSplitter | BWR
--------------------------+------------------+-----------------
Website Fingerprinting | ... | ...
Video Fingerprinting | ... | ...
Values represent mean validation accuracy across the 5 folds.
After the evaluation, you can remove all generated TFRecords, trained models, and evaluation logs by running:
./run-traffic-analysis.sh --clearThis command does not remove the original collected traffic traces.
The exact accuracy values may differ from the full-scale results reported in the paper because this AE uses a much smaller dataset and lighter attack classifiers. However, the scaled-down evaluation is intended to reproduce the main behavioral difference between BWR and TrafficSplitter.
TrafficSplitter is designed to provide broader protection against multiple traffic-analysis attacks. Therefore, it should remain effective against both website fingerprinting (WF) and video fingerprinting (VF).
In contrast, BWR is primarily designed as a website-fingerprinting defense. Its effectiveness is therefore expected to degrade more noticeably under the VF attack.
The purpose of this scaled-down experiment is not to reproduce the exact numerical results from the paper, but to demonstrate the paper's key observation: TrafficSplitter provides more comprehensive protection against different types of traffic-analysis attacks, whereas existing traffic-splitting defenses such as BWR are more attack-specific.
