You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+18-23Lines changed: 18 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,17 @@
1
1
# SKYFALL
2
2
3
-
SKYFALL for Low-earth orbit (LEO) satellite networks (LSNs). This repository contains code for paper #109: "Time-varying Bottleneck Links in LEO Satellite Networks: Identification, Exploits, and Countermeasures", to appear at the 32nd Network and Distributed System Security Symposium (NDSS 2025). The DOI is 10.5281/zenodo.13723143. The target URL is https://zenodo.org/doi/10.5281/zenodo.13723142.
3
+
SKYFALL for Low-earth orbit (LEO) satellite networks (LSNs). This repository contains code for paper "Time-varying Bottleneck Links in LEO Satellite Networks: Identification, Exploits, and Countermeasures", to appear at the 32nd Network and Distributed System Security Symposium (NDSS 2025).
4
4
5
5
## What is SKYFALL?
6
6
7
-
SKYFALL helps you to analyze bottleneck ground-satellite links (GSLs) and how to deploy malicious terminals (where and how many) to accordingly achieve link-flooding attacks of various throughput degradations.
7
+
SKYFALL helps you analyze bottleneck ground-satellite links (GSLs) and the possible consequences of being congested.
8
8
9
9
## What are the components?
10
10
11
11
1. A configuration file (`config.json`).
12
12
2. A code directory (`skyfall`).
13
13
3. Bash scripts to run the experiments (`*.sh`).
14
-
4. Links of reproduced data, satellite geo-information, and network data ([`starlink_shell_one-3600-backup`](https://drive.google.com/file/d/1VauMH0Dm6CLrvr9cGfB6mLm6YlLt9QQf/view?usp=sharing) and [`starlink_shell_one-100-backup`](https://drive.google.com/file/d/1py1jELENHA4I_RcOwxnMk4lYSNEdhu92/view?usp=sharing)). The storage for the datasets are 3.3GB and 95MB respectively.
14
+
4. Links of reproduced data, satellite geo-information, and network data ([`starlink_shell_one-3600-backup`](https://drive.google.com/file/d/1rTuCinLNDnB9q8lyPyZgIaXxpHscX5my/view?usp=drive_link) and [`starlink_shell_one-100-backup`](https://drive.google.com/file/d/1eNZg-OF8xsjjjJNGbJ_8kE_j0x-MtSFR/view?usp=drive_link)). The storage for the datasets are 3.3GB and 104MB respectively.
15
15
16
16
## Preparation
17
17
@@ -44,19 +44,17 @@ Or if you have a virtual environment like Conda, you can simply run `bash ./inst
44
44
bash find_vital_GS.sh 3600 64
45
45
```
46
46
47
-
5. Time-Slot Analysis (as shown in Section 5.1. You should specify the number of timeslots, the number of available logical processors for multi-thread, and throughput degradation, e.g., 3600, 64, and 0.9). Throughput degradation could be 1, 0.9, 0.8, 0.7, 0.6, and 0.5 as shown in Section 6. Thus, run the following commands sequentially to analyze the deployment for various degradations: (three hours taken with our hardware, half an hour for each command below)
47
+
5. Time-Slot Analysis (as shown in Section 5.1. You should specify the number of timeslots, the number of available logical processors for multi-thread, and throughput degradation, e.g., 3600, 64, and 0.9). Throughput degradation could be 0.9, 0.8, 0.7, 0.6, and 0.5 as shown in Section 6. Thus, run the following commands sequentially to analyze the deployment for various degradations:
48
48
```
49
-
bash time_slot_analysis.sh 3600 64 1
50
49
bash time_slot_analysis.sh 3600 64 0.9
51
50
bash time_slot_analysis.sh 3600 64 0.8
52
51
bash time_slot_analysis.sh 3600 64 0.7
53
52
bash time_slot_analysis.sh 3600 64 0.6
54
53
bash time_slot_analysis.sh 3600 64 0.5
55
54
```
56
55
57
-
6. Aggregated_deployment (as shown in Section 5.2. You should specify the number of timeslots and throughput degradation, e.g., 3600 and 0.9). Throughput degradation could be like 1, 0.9, 0.8, 0.7, 0.6, 0.5 as shown in Section 6. Thus, run the following commands sequentially to Aggregate the deployment for various degradations: (one minute taken with our hardware)
56
+
6. Aggregated_deployment (as shown in Section 5.2. You should specify the number of timeslots and throughput degradation, e.g., 3600 and 0.9). Throughput degradation could be like 0.9, 0.8, 0.7, 0.6, 0.5 as shown in Section 6. Thus, run the following commands sequentially to Aggregate the deployment for various degradations:
58
57
```
59
-
bash aggregated_deployment.sh 3600 1
60
58
bash aggregated_deployment.sh 3600 0.9
61
59
bash aggregated_deployment.sh 3600 0.8
62
60
bash aggregated_deployment.sh 3600 0.7
@@ -76,19 +74,17 @@ Follow all the seven steps and their shell commands above. **It is better to use
76
74
77
75
After running step 2, a folder named `starlink_shell_one/sat_lla` will be in your current directory. It contains the satellite position information. This step is related to the experimental setting described in Section V.A of the paper.
78
76
79
-
80
77
After running step 3, folders named `starlink_shell_one/+grid_traffic/link_traffic_data` and `starlink_shell_one/circle_traffic/link_traffic_data` contain the GSL and ISL legal traffic information, as well as satellite, ground station (GS), and blcok connection information. This step is also related to the experimental setting described in Section V.A of the paper.
81
78
82
-
After running step 4, vital GSes will be generated in each timeslot folder of `starlink_shell_one/+grid_traffic/link_traffic_data` and `starlink_shell_one/circle_traffic/link_traffic_data`. Step four relates to the Analysis Stage (Section IV.C) of the paper.
83
-
84
-
After running step 5, timeslot analysis results (malicious terminal number, blocks to deploy the malicious terminals, affected traffic and so on) will be generated in each timeslot folder of `starlink_shell_one/+grid_traffic/attack_traffic_data_land_only_bot` and `starlink_shell_one/circle_traffic/attack_traffic_data_land_only_bot`. Step five also relates to the Analysis Stage (Section IV.C) of the paper.
79
+
After running step 4, vital GSes will be generated in each timeslot folder of `starlink_shell_one/+grid_traffic/link_traffic_data` and `starlink_shell_one/circle_traffic/link_traffic_data`. Step four relates to the Analysis Methodology (Section IV.C) of the paper.
85
80
86
-
After running step 6, aggregated deployment results (malicious terminal number, blocks to deploy the malicious terminals, affected traffic, and so on) will be generated in each folder of `starlink_shell_one/+grid_traffic/attack_traffic_data_land_only_bot` and `starlink_shell_one/circle_traffic/attack_traffic_data_land_only_bot`. Step six also relates to the Analysis Stage (Section IV.C) of the paper.
81
+
After running step 5, timeslot analysis results (malicious terminal number, blocks to deploy the malicious terminals, affected traffic and so on) will be generated in each timeslot folder of `starlink_shell_one/+grid_traffic/attack_traffic_data_land_only_bot` and `starlink_shell_one/circle_traffic/attack_traffic_data_land_only_bot`. Step five also relates to the Analysis Methodology (Section IV.C) of the paper.
87
82
83
+
After running step 6, aggregated deployment results (malicious terminal number, blocks to deploy the malicious terminals, affected traffic, and so on) will be generated in each folder of `starlink_shell_one/+grid_traffic/attack_traffic_data_land_only_bot` and `starlink_shell_one/circle_traffic/attack_traffic_data_land_only_bot`. Step six also relates to the Analysis Methodology (Section IV.C) of the paper.
88
84
89
-
After running step 7, reproduced results and figures will be in `starlink_shell_one/results`.
85
+
After running step 7, reproduced results will be in `starlink_shell_one/results`.
90
86
91
-
If running such a reproduction is a burden, all the reproduced data is already available in [`starlink_shell_one-3600-backup`](https://drive.google.com/file/d/1VauMH0Dm6CLrvr9cGfB6mLm6YlLt9QQf/view?usp=sharing). The storage for the datasets is 3.3GB.
87
+
If running such a reproduction is a burden, all the reproduced data is already available in [`starlink_shell_one-3600-backup`](https://drive.google.com/file/d/1rTuCinLNDnB9q8lyPyZgIaXxpHscX5my/view?usp=drive_link). The storage for the datasets is 3.3GB.
92
88
93
89
94
90
## How to run a small demo?
@@ -114,19 +110,17 @@ To run the demo, everything else could be kept the same except the parameter of
114
110
bash find_vital_GS.sh 100 8
115
111
```
116
112
117
-
5.**(Make the timeslots and the number of logical processors smaller, such as 100 and 8)** Time-Slot Analysis (as shown in Section 5.1. You should specify the number of timeslots, the number of available logical processors for multi-thread, and throughput degradation, e.g. 100 8 0.9). Throughput degradation could be like 1, 0.9, 0.8, 0.7, 0.6, 0.5 as shown in Section 6. Thus, run the following commands sequentially to analyze the deployment for various degradations: (ten to thirty minutes taken with our hardware)
113
+
5.**(Make the timeslots and the number of logical processors smaller, such as 100 and 8)** Time-Slot Analysis (as shown in Section 5.1. You should specify the number of timeslots, the number of available logical processors for multi-thread, and throughput degradation, e.g. 100 8 0.9). Throughput degradation could be like 0.9, 0.8, 0.7, 0.6, 0.5 as shown in Section 6. Thus, run the following commands sequentially to analyze the deployment for various degradations:
118
114
```
119
-
bash time_slot_analysis.sh 100 8 1
120
115
bash time_slot_analysis.sh 100 8 0.9
121
116
bash time_slot_analysis.sh 100 8 0.8
122
117
bash time_slot_analysis.sh 100 8 0.7
123
118
bash time_slot_analysis.sh 100 8 0.6
124
119
bash time_slot_analysis.sh 100 8 0.5
125
120
```
126
121
127
-
6.**(Make the timeslots smaller, such as 100)** Aggregated_deployment (as shown in Section 5.2. You should specify the number of timeslots and throughput degradation, e.g. 100 0.9). Throughput degradation could be like 1, 0.9, 0.8, 0.7, 0.6, 0.5 as shown in Section 6. Thus, run the following commands sequentially to Aggregate the deployment for various degradations: (one minute taken with our hardware)
122
+
6.**(Make the timeslots smaller, such as 100)** Aggregated_deployment (as shown in Section 5.2. You should specify the number of timeslots and throughput degradation, e.g. 100 0.9). Throughput degradation could be like 0.9, 0.8, 0.7, 0.6, 0.5 as shown in Section 6. Thus, run the following commands sequentially to Aggregate the deployment for various degradations:
128
123
```
129
-
bash aggregated_deployment.sh 100 1
130
124
bash aggregated_deployment.sh 100 0.9
131
125
bash aggregated_deployment.sh 100 0.8
132
126
bash aggregated_deployment.sh 100 0.7
@@ -139,18 +133,19 @@ To run the demo, everything else could be kept the same except the parameter of
139
133
bash get_results.sh
140
134
```
141
135
142
-
If running such a reproduction is a burden, all the reproduced data is already available in [`starlink_shell_one-100-backup`](https://drive.google.com/file/d/1py1jELENHA4I_RcOwxnMk4lYSNEdhu92/view?usp=sharing). The storage for the dataset is 95MB.
136
+
If running such a reproduction is a burden, all the reproduced data is already available in [`starlink_shell_one-100-backup`](https://drive.google.com/file/d/1eNZg-OF8xsjjjJNGbJ_8kE_j0x-MtSFR/view?usp=drive_link). The storage for the dataset is 104MB.
143
137
144
138
## Results
145
139
Running the above seven steps allows you to get the reproduced results and figures in `starlink_shell_one/results`.
146
140
147
141
### Better Performance of SKYFALL’ Distributed Botnet
148
-
SKYFALL is able to exploit the time-varying bottleneck and achieve good flooding attack performances. We compare it with a baseline, where both are given the same number of bot terminals. We then compare the throughput (ratio) of affected background traffic and number of affected GSLs over time. The results are shown in Figure 9. Under `starlink_shell_one/results/`, `fig-9a`, `fig-9b`, and `fig-9c` contain the corresponding throughput (ratio) data for each timeslot. `fig-10a` contains the number of attacked GSLs for each timeslot, while `fig-10b` documents the maximum, minimum, and average numbers.
142
+
SKYFALL is able to exploit the time-varying bottleneck and achieve good flooding attack performances. We compare it with a baseline, where both are given the same number of bot terminals. We then compare the throughput (ratio) of affected background traffic and number of affected GSLs over time. The results are shown in Figure 10. Under `starlink_shell_one/results/`, `fig-10a`, `fig-10b`, and `fig-10c` contain the corresponding throughput (ratio) data for each timeslot. `fig-11a` contains the CDF of the number of congested GSLs, while `fig-11b` documents the box-plot.
149
143
150
-
### Cost Analysis
151
-
To achieve the same throughput degradation as the baseline approach, SKYFALL is able to leverage a smaller number of malicious terminals (botnet size) for both +Grid and Circular topologies. The results are shown in Figure 12. `fig-12a`, and `fig-12b` under `starlink_shell_one/results/` contain the number of malicious terminals under various degradations for both topologies respectively.
144
+
### Variability Analysis
145
+
The analysis results depend primarily on factors, such as the number and regions of available compromised UTs, which determines the malicious traffic volume. The results are shown in Figure 12 and Figure 13. `fig-12a`, and `fig-12b` under `starlink_shell_one/results/` contain the hroughput degradation with varying numbers of compromised UTs. `fig-13a`, and `fig-13b` under `starlink_shell_one/results/` contain the throughput degradation with varying numbers of
146
+
regional blocks.
152
147
153
-
### Detectability Analysis
148
+
### Stealthiness Analysis
154
149
During SKYFALL's attack, the total malicious traffic of each satellite from all accessed malicious terminals is small. It quantifies the detectability of SKYFALL. The results are shown in Figure 14. Only a small number of satellites are accessed with malicious traffic. Under `starlink_shell_one/results/`, `fig-14a`,and `fig-14b` contain the throughput data of maliciousc traffic for each satellite in ascending order under various throughput
0 commit comments