This document provides instructions for the NDSS Artifact Evaluation (AE) process for our paper, Towards Comprehensive Multipath Obfuscation Against Traffic Analysis Attacks in Wireless Networks (Draft). The evaluation procedure is organized into four sections:
- VM Setup: We explain how to prepare the VMs for the artifact evaluation. This includes creating VirtualBox VMs, compiling the custom kernel, and building our system.
- Before Starting the Evaluations: We explain how to configure the VirtualBox NAT Network required for communication between the VMs before running the experiments.
- Basic Functionality Test (E1): We explain how to run our system on the VMs and verify its basic functionality.
- Scaled-Down Traffic-Analysis Evaluation (E2): We explain how to conduct the scaled-down traffic-analysis evaluation on the VMs. This includes collecting real network traffic, preprocessing the traffic traces, and training the attack classifiers.
To simplify the setup process, we also provide pre-configured VMs as OVA files.
The pre-configured VMs (i.e., OVA files) are available here.
If you use the provided OVA files, please note the following:
- You can import each VM into VirtualBox by selecting File > Import Appliance and choosing the provided OVA file.
- The VM password is
ndss2027. - When you boot the VMs, the GRUB menu will appear and prompt you to select a kernel version. You can either wait approximately 10 seconds, in which case GRUB will boot the previously selected kernel, or manually select the custom kernel under Advanced options for Ubuntu > Linux 6.13.0-rc3+.
Once you have imported the VMs from the OVA files, you can skip the VM setup steps in Section 1 and proceed directly to Section 2.
While our goal was to provide a self-contained evaluation environment and workflow, we plan to release the full dataset and scripts used to produce the results reported in our paper soon.
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.
Before conducting experiments, we need to configure the NAT network for the communication between VMs. This configuration generates the network topology shown below.
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.
First, 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 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 system.
- 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 now observe how traffic is distributed across the two client network paths.
On the client VM, open another terminal tab and run:
sudo wiresharkIn Wireshark, monitor both client network interfaces.
Then, open Firefox and generate traffic, for example by:
- visiting several websites; or
- playing an online video.
Observe how the MPTCP traffic is distributed across the two network interfaces.
On the client VM, open another terminal tab and run:
./01-run-func/show-interface-traffic.sh 20Then, open Firefox and generate traffic, for example by:
- visiting several websites; or
- playing an online video.
Run the script multiple times while generating traffic. You should observe that the traffic distribution ratio between the two paths varies across measurements due to the randomness introduced by our traffic-obfuscation strategy.
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.
This artifact evaluation compares two defense configurations:
- TrafficSplitter
- BWR
The goal is to reproduce, at a reduced scale, the main qualitative comparison reported in the paper. TrafficSplitter is designed to provide broader protection against both website fingerprinting (WF) and video fingerprinting (VF), as well as other traffic-analysis attacks with characteristics between them. In contrast, BWR is a traffic-splitting defense designed primarily for website fingerprinting and is therefore used as an attack-specific baseline.
We assume a single-path eavesdropper that can monitor one of the network paths between the client and the MPTun proxy server. The eavesdropper is assumed to know the defense strategy and trains its attack classifier using traffic traces generated under each defense.
The evaluation can be performed using either the pre-collected traces included in the Git repository or traces collected by the evaluator. If your goal is to verify the reproducibility of the traffic-analysis evaluation, you may use the pre-collected traces and skip directly to Section 4.2.
The Git repository includes pre-collected website and video traces for both TrafficSplitter and BWR. To use them, move to the data-collection directory and extract the archives:
sudo apt install -y unzip
cd ~/ndss27/TrafficSplitter/eval/02-data-collection
unzip "*.zip"After extraction, the traces should be available in the following directories:
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/
You may then proceed directly to Section 4.2.
If you would like to collect the traffic traces yourself or extend the provided dataset, follow the procedure below. We assume that the eavesdropper monitors the first network interface of the client VM. The client generates traffic by visiting websites or playing YouTube videos in Google Chrome, while tcpdump records the corresponding traffic.
First, on both VMs, move to the evaluation directory:
cd ~/ndss27/TrafficSplitter/evalAs in Section (3), start the proxy 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.shNote: BWR does not use the Saflo subflow-manager component.
Open a new terminal on the client VM and run:
./02-data/collection/web-collecting.sh <trace-name>For TrafficSplitter:
./02-data/collection/web-collecting.sh trafficsplitterFor BWR:
./02-data/collection/web-collecting.sh bwrThe script automatically opens the 10 websites specified in the shell script while tcpdump captures the corresponding network traffic.
Similarly, collect video traces on the client VM using:
./02-data/collection/video-collecting.sh <trace-name>For TrafficSplitter:
./02-data/collection/video-collecting.sh trafficsplitterFor BWR:
./02-data/collection/video-collecting.sh bwrThe script automatically plays the five YouTube videos specified in the shell script while tcpdump captures the corresponding network traffic.
Note: The provided traces were collected using a YouTube Premium account to avoid advertisements that could introduce additional traffic unrelated to the target videos.
You 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 script starts only after the first script completes successfully.
The traffic-analysis evaluation is conducted on the client VM, where the traffic traces are stored.
If you imported the provided OVA files, the required Python environment is already configured and you may skip this step. Otherwise, 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 required only for plotting traffic traces.
Before running the evaluation, confirm that the TrafficSplitter and BWR website and video traces are available under:
TrafficSplitter/eval/02-data-collection/
Move to the traffic-analysis directory:
cd ~/ndss27/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.
Because this artifact evaluation uses a substantially smaller dataset than the full evaluation reported in the paper, it uses 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 traffic traces.
The exact accuracy values may differ from the full-scale results reported in the paper because this artifact evaluation uses a smaller dataset and lighter attack classifiers. The goal is therefore not to reproduce the exact numerical values, but to reproduce the same qualitative trend.
TrafficSplitter is designed to provide broader protection across different types of traffic-analysis attacks. It should therefore provide comparatively consistent protection under both WF and VF. In contrast, BWR is primarily designed as a website-fingerprinting defense, so its defense effectiveness is expected to degrade more noticeably under VF.
The key observation to reproduce is that TrafficSplitter provides more comprehensive protection across WF and VF, whereas BWR is more attack-specific.
