The attacker’s effort displacement is quantified in terms of the reduction of volumetric SYN flood traffic data-rate as seen at the victim network.
If the SYN flood traffic is reduced at the victim side, then the attacker’s current attack traffic profile would be ineffective so as to force the attacker to increase the SYN flood traffic and attack on all the available locators (on all disparate topologically significant paths traversing through multiple regions of the Internet) to reach the same level of attack success when there was no defence.
The goal of the attacker is to cripple the availability of the victim’s services to the client. We have covered this aspect in §4.2, i.e., using the LC64 defence to enhance availability of victim services to the client. Using the LC64 defence, we ensure that not only clients receive services from the victim but the attacker should bediscouraged as well, in terms of the extra requirements, to increase the data-rate of DoS attack traffic. It is the second part which is the concern of this section’s experiment.
The following two sub-experiments were done, each with 25 iterations (based on the statistical power analysis that gives us the number of iterations to run in order for the results to be significant).
• SYN flood traffic measurements without an active LC64 defence.
• SYN flood traffic measurements with an active LC64 defence.
The bandwidth for the duration of each iteration will be calculated which will give us 25 bandwidth measurements for each sub-experiment. Then, we statistically analyse and discuss the traffic distribution of each sub- experiment. We also, analytically, discuss the effects of LC64 scalability on the attacker’s effort.
In our setup, the LC64 CMS used two L64 namespaces for DNS fast flux. Each L64 namespace is connected to two topologically separate upstream links. One L64 namespace, or ephemeral LC64 value, was active at one particular time; and the LC64 CMS changed to active locator after every 20 seconds using ILNP’s host-based Locator Update (LU) path announcements.
4.3.2 Testing
The attacker generated volumetric SYN flood using the thcsyn67 daemon, which generated ∼0.4 million Packets Per Second (PPS). To test whether this affected the client traffic or not, we tested its affects on an iperf3 flow from the client side. There was around 25 % reduction in client traffic. We then moved on to carry this experiment using ∼0.4 million SYN PPS. Since we used a full-duplex 1 Gbps Ethernet link, the victim’s access link was saturated with ∼0.8 million PPS (∼0.4 million SYN + ∼0.4 million SYN-ACK (with extra overhead of retransmissions) packets).
We again emphasise that we did not use client traffic in this experiment because we wanted to see the traffic distribution of a DoS attack which was
100% effective. The ILNP packet along with TCP segment size was 80 Bytes in both directions, effectively giving us ∼64 MB/s.
The Ethernet channel capacity of our testbed was ∼125 MB/s in each direction. We did not employ another attacker machine to reach this ca- pacity because we wanted to achieve attack traffic stability (the same data rate per iteration) in order to measure the effects of the LC64 defence on the attack traffic distribution. The scenario where Ethernet capacity was reached has already been tested when we measured the increase in client traffic during the LC64 defence in our previous experiment in this chapter. On the same note, Figure4.8showed the execution of ILNP’s control traffic to counter DoS in the case where the channel capacity was exhausted.
tcpstat8 was used at the victim side to count SYN flood PPS before and after enabling the LC64 defence.
Figure 4.9shows the testbed for this experiment.
Figure 4.9: Testbed for LC64 defence to measure attacker’s effort while doing fast flux on both the redundant link and the link under attack.
Each router is directly connected to an ExtremeR Switch x45a-48t with
an isolated port, using 1 Gbps full-duplex Ethernet links. Each machine, apart from the switch in the testbed is a GatewayR GR380 F1 machine with
64-bit IntelR XeonR 8-core CPU (2.27 GHz base frequency)9. 8
https://www.frenchfries.net/paul/tcpstat/
9
https://ark.intel.com/products/40200/Intel-Xeon-Processor-E5520-8M-Cache-2 26- GHz-5 86-GTs-Intel-QPI
Figure 4.10 shows the sequence diagram of the host/network interac- tions during fast fluxing among two locators including the path which is under attack. We included the path under attack in the fast flux to show attack traffic behaviour between locator transitions (we do not recommend inclusion of the attacked path in the DNS fast flux procedure in real world deployments).
Figure 4.10: Sequence diagram for quantifying attacker’s effort. It shows host/network interactions while the LC64 defence is in place. The LC64
CMS fast fluxes between the link under attack (Router 1) and the redundant link (Router 2). RA is the Router Advertisement.
These interactions are:
• t0tot2: In this duration, an attack reaches the victim network because
the upstream link on router 1 is still active. Att1, L64 CMS enables
the interface on router 2 which allows router 2 to send an RA to the victim host. Betweent1 andt2, the client and victim hosts would shift
their communications to a redundant link using the LU mechanism (not shown since we are not using a client in this experiment). Att2,
the LC64 CMS disables the link on router 1 so the attack traffic stops reaching the victim network.
• t2 to t3: After disabling the link on router 1, the LC64 CMS waits
for the duration of the respective active ephemeral LC64 capability. It waits untilt3. During this period, there is no attack traffic seen on
the victim host.
• t3 tot5: At t3, LC64 CMS transitions the network to the old link and
we start noticing the attack traffic at the victim host untilt5 at which
point the LC64 CMS disables the link on router 1. Betweent4 andt5,
the victim host can shift all the legitimate communications (if any) to an active path.
• t5 onwards: We do not see any attack traffic at the victim side for the
duration of the active ephemeral LC64 capability. After the waiting time (time duration of an active LC64 value), the LC64 CMS shifts to the other link. This switching takes place until the enterprise man- agement decides to deactivate the defence.
4.3.3 Results
4. ENTERPRISE SITE DE FENCE 117
SYN flood had a mean of ∼0.46 million SYN flood packets per second before enabling the LC64 defence, and∼0.27 million packets per second after enabling the LC64 defence. This is∼40 % reduction in SYN flood data rate. Some of the attack traffic reached the victim during the soft-handoff period (we set it to arbitrary 2 seconds to allow client connections to shift the network), so instead of seeing a 50 % reduction we saw ∼40 % reduction. Given this observation, an attacker has to attack on the redundant link, as well, to achieve a successful attack on the whole site. This percentage can be reduced to zero if the LC64 CMS does not come back to or re-activate the link on which the attack is happening.
Equation (4.1) shows the change in attack data rate where Rb is the
attack data-rate after enabling the defence, andRa is the attack data-rate
before enabling defence. β is a scaling factor greater than zero. In our testbed, with two ephemeral LC64 values,βtends to be∼0.40. If the LC64 CMS shifts traffic to the redundant links and disables the attacked link for the duration of the attack, thenβ would be zero as the services would have been shifted to the redundant links and they will never come back to the attacked link unless the attack has disappeared.
Rb 'βRa:β≥0 (4.1)