add: batch 4

* add intro and section text
* correct typos
* wrap long lines
* add labels to section titles
* add references
* add circular arrows graph (tikz)
* add overlapping sets graph (tikz)

tex/text.tex

@@ -1,21 +1,74 @@
 % ============================================================================ %
 \nn{Introduction}
-What we have commonly seen being used in the wild in recent years may be
+In this day and age, there has probably been nothing else considered as
-called "professionalizing", by which I mean that what would typically be available 10
+inevitable and impactful on one's personal or professional life, media,
-years ago cannot match to practically anything you can get ready in minutes to
+politics, culture or science as reliable Internet connection, allowing seemless
-cause real harm today.
+interaction and access to information.
+Networking infrastructure powering the Internet has been the target of various
+attacks almost since day one. While the early network interconnections had
+been based on mutual trust and strong sharing spirit for advancement of humanity, with
+increasing amount of participants from different backgrounds (essentially
+democratization) and proliferating deeds of mischief, trust could no longer be
+taken for granted.
+Although trolling has always been an integral part of the Internet culture, it
+had not taken long until criminals found their way into the online world with
+the intention of taking advantage of lacking legislation and collecting easy
+(though huge) economic profit. Furthermore, another popular activity has become
+causing real harm to anybody on the way with the sense of lawlessness.
+
+It is this willful damage in its many shapes and forms brought upon the
+Internet service providers and users that our thesis deals with. What we have
+commonly observed as being used in the wild in recent years may be called
+attack 'professionalizing', by which we mean that the tools typically available
+10 years ago cannot match to practically anything you can get ready in minutes
+to cause real harm today. Since the networks compose the medium of
+communication, it is essential they remained secured and protected, which in
+fact poses a challenging task for us of coming up with new solutions to rapidly
+evolving problem.
+
+On the side of the user, unavailability of the service often means inability to
+proceed with fulfilling their tasks. For the provider, an attack that cripples
+the network or its resources means inability to provide the promised service.
+
+We would like to take a look on some of the conventional methods and tools
+which attackers resort to as well as methods and tools both users and network
+operators may (and should) utilise to protect the network. The main objectives
+of our thesis aim at researching key ways of DoS attack mitigations and
+performing a DoS attack and a BGP blackhole reaction simulation.
+
+Our thesis comprises two main parts - theoretical and practical. The
+theoretical part discusses relevant context, different types of attack methods
+and tools, mitigation attack methods and tools. The practical part describes a
+simulated simple topology and an attack in lab conditions.
+In the first section of the theoretical part, we were focused on attack
+definition. Section \ref{sec:attack-methods} attempts to categorise attack
+methods based on several metrics and explain some of the mentioned. The third
+section presents a list of some of the popular DoS tools that are available.
+Next on, the \autoref{sec:mitigation-methods} traces various ways to mitigate
+attacks, both on the user and provider level and the final section of the
+theoretical part, \autoref{sec:mitigation-tools}, marks out some of the tools
+that can be used to mitigate an attack.
+First of the practical part, \autoref{sec:infrastructure-set-up-description} gives an
+overview of the tools used to construct the lab infrastructure and configure
+the systems, as well as specifics of the configuration. It also focuses on
+setting up the infrastructure and the tools and processes to achieve a
+reproducible outcome. In \autoref{sec:mitigation-tools-set-up}, we set up
+mitigation tools in preparation of an attack. In
+\autoref{sec:attack-tools-set-up} we go through the process of preparing attack
+tools. Section \ref{sec:performing-an-attack} describes performing the attack
+itself. The final section \ref{sec:monitoring} observes the monitoring feeds.
 
 
 % ============================================================================ %
 \part{Theoretical part}
 
+
+\n{1}{Definition} \label{sec:definition}
 While denial of service can be caused in a multitude of different ways and
 impact any part of the stack, we are predominantly going to look at the ones
-pertaining internet networks.
+pertaining Internet networks. First, we shall define what a denial of service
-
+(\it{DoS}) attack in fact \it{is} and we can achieve it by understanding what
-\n{1}{Definition}
+it does.
-First we shall define what a denial of service (\it{DoS}) attack \it{is} and that
-can be achieved by looking at what it does.
 
 A DoS attack is an action that harms a \it{service} in such a way that it can
 no longer serve legitimate requests as a result of being occupied by bogus or
@@ -24,6 +77,17 @@ excessive requests from the attacker.
 A DDoS is a DoS that is distributed among many participant devices (and
 operators).
 
+\begin{figure}
+  \centering
+\begin{tikzpicture}
+  \draw (1,1)[color=red!60,thick,fill=red!15] circle (2.2cm);
+  \draw (0.4,0.2pt) node[below left] {$DoS$};
+  \draw (1,1)[dashed,fill=purple!25] circle (1.2cm);
+  \draw (1,5pt) node[above] {$DDoS$};
+\end{tikzpicture}
+\caption{Illustration of relationship between DoS and DDoS attacks.}
+\end{figure}
+
 The devices participating are generally also victims in this, most of the
 attacks are performed with open DNS resolvers, home routers left to rot by
 vendors, misconfigured web services or IoT devices as involuntary
@@ -33,34 +97,37 @@ start probing and then reap the easy harvest. A quick search for devices
 running with port 123 (NTP) open is certain to return a mind-blowing number
 \cite{ShodanNTPd}.
 
-\n{1}{Context}
+\n{1}{Context} \label{sec:context}
-Only in the past decade we have witnessed many large DoS/DDoS attacks, some of them
+In the last decade only we have witnessed many large DoS/DDoS attacks, some of
-against critical infrastructure services like cloud hosting, DNS, git hosting
+them against critical infrastructure services like cloud hosting, DNS, git
-services or CCTV cameras. All of the attacks weaponized poorly managed
+hosting services or even CCTV cameras. All of the attacks weaponized poorly
-endpoints, unpatched IoT devices or
+managed endpoints, unpatched IoT devices or
-malware-infected-hosts-turned-botnet-zombies. The intensity and frequency has
+malware-infected-hosts-turned-botnet-zombies. The intensity and frequency have
-also been sharply increasing, with the latest of attacks passing over the Tbps
+also been sharply increasing with the latest of attacks passing over the Tbps
 threshold (Akamai mitigated a 1.44Tbps DDoS in 2020
-\cite{akamai2020ddosretrospect}), data from Cisco noting that overall, there
+\cite{akamai2020ddosretrospect}), with data from Cisco Annual Internet Report
-was a \textbf{776\%} growth in attacks between 100 Gbps and 400 Gbps from 2018 to 2019
+showing that overall there was a \textbf{776\%} growth in attacks between 100
-and predictions for the total number of DDoS attacks to double from 7.9 million
+Gbps and 400 Gbps from 2018 to 2019, and with predictions for the total number
-in 2018 to 15.4 million by 2023 \cite{cisco2020report}. The question is: why?
+of DDoS attacks to double from 7.9 million in 2018 to 15.4 million by 2023
+\cite{cisco2020report}. The question is: why?
 
-There motifs will probably more often than not stay a mystery, however, a
+The motifs will probably more often than not stay a mystery; however, a
-proliferation of DDoS-for-hire websites \cite{Santanna2018BooterLG} even on
+proliferation of DDoS-for-hire websites \cite{Santanna2018BooterLG}, even on
-\emph{clearnet} points us to a plausible answer.
+\emph{clearnet}\footnotemark, points us to a plausible answer.
+
+\footnotetext{the surface web; i.e.\ not even attempting to hide}
 
 Somebody is making money selling abusive services that are being used for
 putting competitors out of business or just plain extortion. According to
-Akamai, extortion attacks have seen a widespread return, with a new wave launching in mid-August
+Akamai, extortion attacks have seen a widespread return, with a new wave
-2020 \cite{akamai2021ddos}.
+launching in mid-August 2020 \cite{akamai2021ddos}.
 
 Akamai went on to note that DDoS attackers are expanding their reach across
-geographies and industries, with the number targeted entities now being 57\%
+geographies and industries, with the number of targeted entities now being 57\%
 higher than the year before that.
 
 
-\n{1}{Attack methods}
+\n{1}{Attack methods} \label{sec:attack-methods}
 There are generally several different ways to categorise a method of
 attack:
 \begin{description}
@@ -109,11 +176,12 @@ attack:
     \item IP fragmentation
     \item SYN flood - a rapid sequence of TCP protocol SYN messages
     \item volumetric DDoS attack
-    \item amplification attack (also called "reflection attack")
+    \item amplification attack (also called 'reflection attack')
     \begin{itemize}
-      \item memcached exploit (1:51200)
+      \item memcached (up to 1:51200)
-      \item DNS (\textasciitilde1:50), with a formula \cite{akamaidnsampl} \[R = answer size / query size\]
+      \item DNS with a formula \cite{akamaidnsampl}
-      \item SNMP
+        \rov[DNSamplificationformula]{R = answer size / query size}
+      \item SNMP (theoretically 1:650)
       \item NTP
     \end{itemize}
     \item exploits
@@ -142,9 +210,10 @@ packets, ideally even accompanied by a buffer overflow that the attacker can
 exploit further. Fragmenting TCP segments, on the other hand, targets the TCP
 mechanism for reassembly. Reasonably recent Linux kernel implements protection
 against this \cite{linuxretransmission}.
-In either case, this is a network layer attack, since it targets the way the Internet Protocol requires data to be transmitted and processed.
+In either case, this is a network layer attack, since it targets the way the
+Internet Protocol requires data to be transmitted and processed.
 
-\n{2}{SYN flood}\label{synfloodattack}
+\n{2}{SYN flood} \label{synfloodattack}
 To establish a TCP connection, a \emph{three way handshake} must be
 performed.\\
 That is the opening sequence of a TCP connection that any two machines -
@@ -163,7 +232,7 @@ A malicious actor is able to misuse the handshake mechanism by posing as a
 legitimate \emph{client} (or rather many legitimate clients) and sending large
 number of SYN segments to a \emph{server} willing to establish a connection
 (\it{LISTEN} state). The server replies with a [SYN, ACK], which is a combined
-acknowledgement of the clients request \it{and} a synchronization request of
+acknowledgement of the client's request \it{and} a synchronization request of
 its own.  The client responds back with an ACK and then the connection reaches
 the \it{ESTABLISHED} state.
 
@@ -194,7 +263,8 @@ the transit provider/ISP) and does not aggregate on a single host's interface.
 For this to be a reality the adoption rate of the subject RFC recommendations
 would need to see an proper increase.
 
-As is true for anything, if countermeasures are set up improperly, legitimate traffic could end up being blocked as a result.
+As is true for anything, if countermeasures are set up improperly, legitimate
+traffic could end up being blocked as a result.
 
 \n{2}{Amplified Reflection Attack}
 The name suggests this type of attack is based on two concepts: amplification and
@@ -215,8 +285,9 @@ request with (either a bogus but more commonly) a victim IP address as the
 source address instead of our own that's present there by default.
 The response is then returned \it{back} - not to the actual sender, but simply
 according to the source address.\\
-Since UDP has no concept of a \it{connection} or any verification mechanism, the response arrives at the door of the victim that has never asked for
+Since UDP has no concept of a \it{connection} or any verification mechanism,
-it - in the worst case an unsolicited pile of them.
+the response arrives at the door of the victim that has never asked for it - in
+the worst case an unsolicited pile of them.
 
 This is why the three-way handshake is used with TCP, which was developed later
 than UDP, as it reduces the possibility of false connections.
@@ -243,7 +314,7 @@ recommendations of RFC 3704 gained greater adoption among ISPs.
 Until then, brace yourselves for the next assault.
 
 
-\n{2}{Slowloris}\label{slowloris}
+\n{2}{Slowloris} \label{slowloris}
 The principle of this attack is to first open as many connections as
 possible, aiming to fill the capacity of the server, and then keep them
 open for as long as possible by sending periodic keep-alive packets.\\
@@ -282,7 +353,7 @@ remotely from end hosts without access to routers or the ability to send
 traffic directly to them.
 
 
-\n{1}{Attack tools}
+\n{1}{Attack tools} \label{sec:attack-tools}
 Believe it or not there actually exists a DDoS attack tools topic on
 GitHub
 \url{https://github.com/topics/ddos-attack-tools?o=desc\&s=stars}.
@@ -311,7 +382,8 @@ server to facilitate them until resources bound by bogus requests are freed,
 i.e. the attack ceases to be.
 
 \n{2}{iperf3}
-Massive load producing tool sending a packet flood of protocol of choice towards the target.
+Massive load producing tool sending a packet flood of protocol of choice
+towards the target.
 
 \n{2}{ddosim}
 DDoS simulator methods of flooding:
@@ -323,13 +395,13 @@ DDoS simulator methods of flooding:
 
 \n{2}{Metasploit Framework}
 Metasploit is a penetration testing framework with an open source community
-version and a commercial version (Metasploit Unleashed) available. It enables security
+version and a commercial version (Metasploit Unleashed) available. It enables
-researchers to automate workflows of probing vulnerable services or devices via
+security researchers to automate workflows of probing vulnerable services or
-use of so called modules - smaller programs with definable inputs that perform
+devices via use of so called modules - smaller programs with definable inputs
-prefined actions. Modules are often community-contributed and one can even
+that perform prefined actions. Modules are often community-contributed and one
-write a module ourselves.a The SYN-flooding funtionality has been implemented -
+can even write a module ourselves.a The SYN-flooding funtionality has been
-\texttt{aux/synflood} an auxiliary module. Auxiliary modules do not execute
+implemented - \texttt{aux/synflood} an auxiliary module. Auxiliary modules do
-payloads and perform arbitrary actions that may not be related to
+not execute payloads and perform arbitrary actions that may not be related to
 exploitation, such as scanning, fuzzing and denial of service attacks
 \cite{metasploit}.
 
@@ -345,15 +417,15 @@ thing as discussed above, the only difference is the malicious intent,
 imperceivable to a machine.
 
 
-\n{1}{Mitigation methods}
+\n{1}{Mitigation methods} \label{sec:mitigation-methods}
 Drastic times require drastic measures and since a DDoS attacks coming
 at us practically every other month classify as
 \it{drastic} quite easily, we're forced to act accordingly
 \cite{akamai2021ddos}.
 
 Still, it is more reasonable to prepare than to improvise, therefore the
-following write-up mentions of commonly used mitigation methods at different levels,
+following write-up mentions of commonly used mitigation methods at different
-from a hobbyist server to an e-commerce service to an ISP. The list is
+levels, from a hobbyist server to an e-commerce service to an ISP. The list is
 inconclusive and of course if reading this at a later date, always cross-check
 with the current best practices at the time.
 
@@ -380,8 +452,9 @@ For the entire time we're announcing it, the victim host stays unreachable.
 
 We should make sure to announce the smallest possible prefix to minimise the
 collateral damage. Generally, a /21 or /22 prefix is assigned to an AS (the
-average prefix per AS being 22.7866 as of 11 May 2021 \cite{prefixavgsize}) announcing a black hole
+average prefix per AS being 22.7866 as of 11 May 2021 \cite{prefixavgsize})
-for such a large space would likely cause more damage than the attack itself.
+announcing a black hole for such a large space would likely cause more damage
+than the attack itself.
 
 To reduce BGP overhead, prefixes are usually announced aggregated, with the
 exception of "a~situation", such as when we wish to only stop receiving traffic
@@ -413,10 +486,12 @@ flowing\footnotemark!
 
 Behold, this is what \it{selective black-holing} actually is. Some upstream
 providers define multiple different blackhole communities each followed by a
-predefined action on the upstream. One is able to announce to these communities as needed.
+predefined action on the upstream. One is able to announce to these communities
+as needed.
 Assume we would announce to a community that would in response announce the
 blackhole to internet exchanges in, say, North America and Asia and but allow
-traffic coming from Europe, would be a perfect example of selective black-holing.
+traffic coming from Europe, would be a perfect example of selective
+black-holing.
 This causes two things to happen. First, our customer's IP is still reachable
 from our local area (e.g. Europe) and since our fictitious customer mostly
 serves European customers that's fine. Second, outside of the prefedined radius
@@ -429,11 +504,12 @@ it is reasonably automated and quick to respond, in combination with other
 mitigation methods it can provide a viable protection for the network.
 
 \n{2}{Sinkholing}
-Moving on, this method works by diverting only malicious traffic away from its target,
+Moving on, this method works by diverting only malicious traffic away from its
-usually using a predefined list of IP addresses known to be part of malicious
+target, usually using a predefined list of IP addresses known to be part of
-activities to identify DDoS traffic. False positives can occur more rarely and
+malicious activities to identify DDoS traffic. False positives can occur more
-collateral damage is lesser than with black-holing but since botnet IPs can be
+rarely and collateral damage is lesser than with black-holing but since botnet
-also used by legitimate users this is still prone to false positives.
+IPs can be also used by legitimate users this is still prone to false
+positives.
 Additionally, sinkholing as such is ineffective against IP
 spoofing, which is a common feature in network layer attacks.
 
@@ -447,8 +523,8 @@ scrubbing at an inline rate without impacting legitimate users.
 
 If outsourced, the scrubber service has the bandwidth capacity (either
 on-demand or permanently) to take the hit that we do not have. There are at
-least two ways to go about this - the BGP and the DNS way, we will cover the BGP
+least two ways to go about this - the BGP and the DNS way, we will cover the
-one. Once an attack is identified, we stop announcing the prefix that is
+BGP one. Once an attack is identified, we stop announcing the prefix that is
 currently being hit, contact our scrubbing provider (usually
 automatically/programatically) to start announcing the subject prefix,
 receiving all its traffic (including the attack traffic), the scrubbing service
@@ -459,10 +535,10 @@ appliance that has to have sufficient bandwidth (usually on par with upstream).
 
 A poor man's scrubber:
 \begin{itemize}
-\item hardware accelerated ACLs on switches,
+\item utilizing hardware accelerated ACLs on switches,
-\item switches do simple filtering at \it{inline rate} (ASICs)
+\item switches can do simple filtering at \it{inline rate} (ASICs)
-\item can be effective when attack protocol is easily distinguishable from real
+\item this can be effective when attack protocol is easily distinguishable from
-  traffic
+  real traffic
 \item hit by NTP/DNS/SNMP/SSDP amplification attack
 \end{itemize}
 
@@ -472,8 +548,12 @@ our network (such as 123 or 53), we start signalling to our upstream
 providers, since they can probably handle it better than us and have as much
 interest in doing so as us (or should).
 
-One thing we should do no matter whether we are currently suffering an attack (and
+Volumetric attacks sending traffic in smaller packet sizes will, however,
-scrubbing it ourselves) is to rule out and drop and never receive traffic
+still result in higher CPU utilization, especially on non-dedicated networking
+equipment.
+
+One thing we should do no matter whether we are currently suffering an attack
+(and scrubbing it ourselves) is to rule out and drop and never receive traffic
 appearing to come from \it{our own network}, since such traffic could not exist
 naturally and is obviously spoofed.
 
@@ -493,13 +573,11 @@ Team Cymru \cite{teamcymru}.
 
 In case we have our own ASN, are connected directly at an IXP, have no
 RTBH support upstream and basically have no other choice, we just need
-to find out who is sending the malicious traffic, drop the session and receive
+to find out who is sending the malicious traffic and, if possible, drop the
-traffic from other peers.
+session and receive traffic from other peers.
-
-64B packet size --> lower throughput, high cpu utilization
 
 
-\n{2}{IP masking}\label{ipmasking}
+\n{2}{IP masking} \label{ipmasking}
 This is technique is widely used (e.g. CloudFlare flagship service), relying
 solely on not divulging sensitive information - in this case server IP - to
 attackers and the capacity of the \it{fronting} service to withstand the attack
@@ -511,7 +589,7 @@ other service performs TLS termination in our behalf and \textbf{sees
 everything} (that was encrypted only \emph{in transit} and is not additionally
 encrypted) that \emph{anyone} sends us, before finally forwarding it back.
 
-\n{2}{WAF}\label{waf}
+\n{2}{WAF} \label{waf}
 WAF - \it{Web Application Firewall} - is an appliance used to protect
 (as name suggests) web applications. In this day and age, this is
 especially necessary and enables system administrators to craft protection
@@ -541,7 +619,8 @@ open simultaneously, which can even prevent Slowloris (see \ref{slowloris}).
 Rate-limiting is usually set either on a proxy or a WAF, but some form of
 rate-limiting can even be built into an app.
 
-A well known rate-limiting pluggable solution that can be used with SSHd, HTTP or multitude of other endpoints is \texttt{Fail2Ban}.
+A well known rate-limiting pluggable solution that can be used with SSHd, HTTP
+or multitude of other endpoints is \texttt{Fail2Ban}.
 
 
 \n{2}{Decreased-TIME\_WAIT connection closing}
@@ -569,7 +648,7 @@ prevent such a situation from occurring easily. In Nginx this is set with a
 single line: \texttt{reset\_timedout\_connection on;}
 
 
-\n{1}{Mitigation tools}
+\n{1}{Mitigation tools} \label{sec:mitigation-tools}
 No tools are going to remedy for a bad design decision and that applies
 equally to physical and internet engineering.
 
@@ -584,10 +663,10 @@ There are two main types of firewalls:
 \end{itemize}
 
 A software firewall is just another program running on the operating
-system, apart from the fact that it is typically running with
+system, apart from the fact that it is typically running with system-level
-system-level privileges. It can be run on a general-purpose computer. In fact
+privileges. It can be run on a general-purpose computer. In fact most of the
-most of the consumer-grade operating systems nowadays incorporate or by default
+consumer-grade operating systems nowadays incorporate or by default enable a
-enable a firewall solution.
+firewall solution.
 
 In contrast, an appliance firewall is a dedicated piece of hardware
 purpose-build specifically for the sole role of behaving as a firewall and
@@ -611,7 +690,7 @@ and is replacing (in modern distributions has replaced, although
 backward compatibility has been preserved) the former two - the
 \texttt{nftables} tool.
 
-\n{3}{Netfilter}\label{netfilter}
+\n{3}{Netfilter} \label{netfilter}
 The Linux kernel subsystem named \texttt{Netfilter} is part of the internet
 protocol stack of the kernel and is responsible for packet manipulation and
 filtering \cite{Boye2012NetfilterCT}. The packet filtering and classification
@@ -630,44 +709,42 @@ modules}.
 Part of the \texttt{Netfilter} framework responsible for connection tracking is
 fittingly named Conntrack. Connection, or a \it{flow} is a tuple defined by a
 unique combination of source address, destination address, source port,
-destination port a and the transport protocol used [refneeded flow].
+destination port a and the transport protocol used.
-
 Conntrack keeps track of the flows in a special fixed-size
 (tunable\footnotemark) in-kernel
 hash table structure with a fixed upper limit.
 
 \footnotetext{via \texttt{net.netfilter.nf\_conntrack\_buckets}}
 
-On Linux devices functioning as router devices a common issue is the depletion
+On Linux devices functioning as router devices (especially when you add NAT to
-of space in the conntrack table. Once the maximum number of connection is
+the mix) a common issue is the depletion of space in the conntrack table. Once
-reached, Linux simply logs an error message "\texttt{nf\_conntrack: table full,
+the maximum number of connection is reached, Linux simply logs an error message
-dropping packet}" to the kernel log and "all further new connection requests
+\texttt{nf\_conntrack: table full, dropping packet} to the kernel log and
-are dropped until the table is below the maximum limit again."
+"all further new connection requests are dropped until the table is below the
-\cite{Westphal2017CT}. That, Westphal further notes, is indeed very
+maximum limit again." \cite{Westphal2017CT}. That, as Westphal further notes,
-unfortunate, especially in DoS scenarios.
+is indeed very unfortunate, especially in DoS scenarios.
 
 Unless the router also functions as a NAT, this can be remedied in two ways:
 decreasing the timeout until an established connection is closed and decreasing
 the timeout until an inactive connection in the TIME\_WAIT state is evicted from
 the conntrack table. By default, the TIME\_WAIT timeout is several hours long
-and leaves the router vulnerable to a UDP flood.
+and leaves the router vulnerable to packet floods or Slowloris.
 
 Netfilter is here to help again with conntrack treating entries that have not
 (yet) seen two-way communication specially – they can be evicted early if
 the connection tracking table is full. In case insertion of a new entry fails
-because the table is full, "...the kernel searches the next
+because the table is full, "...the kernel searches the next 8 adjacent buckets
-8 adjacent buckets of the hash slot where the new connection
+of the hash slot where the new connection was supposed to be inserted at for an
-was supposed to be inserted at for an entry that has not seen a
+entry that has not seen a reply. If one is found, it is discarded and the new
-reply. If one is found, it is discarded and the new connection
+connection entry is allocated."\cite{Westphal2017CT}. Randomised source address
-entry is allocated."\cite{Westphal2017CT}. Randomised source address in TCP SYN
+in TCP SYN floods becomes a non-issue because now most entries can be
-floods becomes a non-issue because now most entries can be early-evicted
+early-evicted because the TCP connection tracker sets the "assured" flag only
-because the TCP connection tracker sets the "assured" flag only once the three-way
+once the three-way handshake has completed.
-handshake has completed.
 
-In case of UDP, the assured flag is set once a packet arrives
+In case of UDP, the assured flag is set once a packet arrives after the
-after the connection has already seen at least one packet in
+connection has already seen at least one packet in the reply direction, that is
-the reply direction, that is the request/response traffic
+the request/response traffic does not have the assured bit set and can
-does not have the assured bit set and can therefore be early-dropped at any time.
+therefore be early-dropped at any time.
 
 
 \n{2}{FastNetMon DDoS Mitigation toolkit}
@@ -691,8 +768,26 @@ mitigation reactions.
 
 % ============================================================================ %
 \part{Practical part}
+The plan:
+\begin{figure}
+  \centering
+  \begin{tikzpicture}
+    \fill[even odd rule,gray!30] circle (2.3) circle (2.2);
+      \arcarrow{2}{2.25}{2.5}{165}{200}{5}{red!50,
+        draw = red!50!black, very thick}{attack}
+      \arcarrow{2}{2.25}{2.5}{210}{260}{5}{blue!50,
+        draw = blue!50!black, very thick}{detection}
+      \arcarrow{2}{2.25}{2.5}{270}{320}{5}{green!50,
+        draw = green!50!black, very thick}{blackhole}
+      \arcarrow{2}{2.25}{2.5}{330}{460}{5}{blue!50,
+        draw = blue!50!black, very thick}{wait {\&} withdraw blackhole}
+      \arcarrow{2}{2.25}{2.5}{470}{515}{5}{blue!50,
+        draw = blue!50!black, very thick}{analysis}
+  \end{tikzpicture}
+  \caption{cunning plan} \label{fig:cunning-plan}
+\end{figure}
 
-\n{1}{Infrastructure description}
+\n{1}{Infrastructure Set-Up Description} \label{sec:infrastructure-set-up-description}
 % TODO
 Broader infrastructure description HERE.
 
@@ -738,8 +833,8 @@ defender machines.
   \hline
 }
 The inner (our edge) and the upstream (our transit provider) routers are
-each part of different \it{AS}. They are directly connected and communicate using BGP.
+each part of different \it{AS}. They are directly connected and communicate
-The outer router and the inner router are BGP peers.
+using BGP. The outer router and the inner router are BGP peers.
 
 We assume our upstream provider supports RTBH signalling.
 In this scenario the attacker is directly connected to our UPSTREAM router,
@@ -760,8 +855,6 @@ all that with ansible roles
 BIRD for bgp, static routes for a poor man's router
 
 
-\n{1}{Infrastructure set-up}
-
 \nns{approach 0}
 \begin{itemize}
 \item KVM
@@ -819,12 +912,19 @@ Notably, the system has also been using the \texttt{nftables} backend of
 \texttt{firewalld}, for which, luckily, \texttt{libvirt} was already
 prepared.
 
-\n{1}{Mitigation tools set-up}
+\n{1}{Mitigation tools set-up} \label{sec:mitigation-tools-set-up}
 An open-source DDOS mitigation toolkit named \texttt{fastnetmon} was
 picked to serve as an attack detection tool. It supports analysing traffic from
-multiple different exporter types, including Netflow (v5 adn v9), sFlow and port
+multiple different exporter types, including Netflow (v5 and v9), sFlow and port
 mirrors.
 
+terraform multi-NIC VMs (or use virsh)\\
+ansible-gobgp role on fedora routers to set up bgpd\\
+Netflow exporter to report to fastnetmon\\
+use iperf3 to attack\\
+announce to a specified community to shut down the attack (black hole)
+
+
 BGP black-holing upsides:
 \begin{itemize}
 \item quick and surgically precise way
@@ -832,10 +932,11 @@ BGP black-holing upsides:
 
 BGP black-holing weak spots:
 \begin{itemize}
-\item requires for our BGP peers to be available and willing to help/cooperate to advertise smaller subnets
+  \item requires for our BGP peers to be available and willing to
+    help/cooperate to advertise smaller subnets
 \end{itemize}
 
-\n{1}{Attack tools set-up}
+\n{1}{Attack tools set-up} \label{sec:attack-tools-set-up}
 When considering the way to simulate an attack locally, we weren't
 primarily looking for a tool, which would enable a decentralised (the
 first "D" of DDOS) attack, instead the objective was mainly to congest
@@ -848,16 +949,18 @@ why we're concerned in the first place).
 
 \n{2}{Metasploit \texttt{aux/synflood module}}
 
-\n{1}{Performing an attack}
+\n{1}{Performing an attack} \label{sec:performing-an-attack}
 run the tools
 
-\n{1}{Monitoring}
+\n{1}{Monitoring} \label{sec:monitoring}
 \begin{itemize}
 \item fastnetmon metrics
 \item packet capture on the router interfaces
 \item Netflow signalling
 \end{itemize}
 
+juju4/ansible-fprobe netflow role
+
 % ============================================================================ %
 \nn{Conclusion}