RNDMISC-440: First Milestone

2023-08-25 08:57:04 +00:00
parent f0c7d3c0d4
commit 0fdf86c992
13 changed files with 308 additions and 72 deletions
--- a/abk.tex
+++ b/abk.tex
@@ -19,6 +19,7 @@
 \newacroplural{Abk}[Abk-en]{Abkürzungen}
 \newacroplural{AS}[ASen]{Autonomen Systemen}
 \newacroplural{VM}[VMs]{Virtuellen Maschinen}
+ \newacroplural{ASN}[ASNs]{Autonome System Nummern}

 \acro{H2O}[\ensuremath{H_2O}]{Di-Hydrogen-Monoxid}
 \acro{API}[API]{Application Programming Interface}
@@ -37,6 +38,8 @@
 \acro{TCP}[TCP]{Transmission Control Protocol}
 \acro{RIP}[RIP]{Routing Information Protocol}
 \acro{OSPF}[OSPF]{Open Shortest Path First}
+ \acro{ASN}[ASN]{Autonome System Nummer}
+ \acro{JSON}[JSON]{JavaScript Object Notation}
 


--- a/bericht.bib
+++ b/bericht.bib
@@ -33,6 +33,14 @@ PUBLISHER	= "O'Reilly",
 YEAR		= 2002
 }

+@misc{Schoch.2022,
+    title    = "API für Route Injection",
+    school   = "Duale Hochschule Baden-Württemberg Karlsruhe",
+    author   = "Schoch, Leon",
+    year     = 2022,
+    month = oct,
+}
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 % Referenzieren von URL's
@@ -106,3 +114,33 @@ YEAR		= 2002
    month =     jan,
    abstract =  {This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. {[}STANDARDS-TRACK{]}},
 }
+
+@misc{rfc5635,
+    series =    {Request for Comments},
+    number =    5635,
+    howpublished =  {RFC 5635},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC5635},
+    url =       {https://www.rfc-editor.org/info/rfc5635},
+    author =    {Warren "Ace" Kumari and Danny R. McPherson},
+    title =     {{Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)}},
+    pagetotal = 15,
+    year =      2009,
+    month =     aug,
+    abstract =  {Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks. This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. This memo provides information for the Internet community.},
+}
+
+@misc{rfc7999,
+    series =    {Request for Comments},
+    number =    7999,
+    howpublished =  {RFC 7999},
+    publisher = {RFC Editor},
+    doi =       {10.17487/RFC7999},
+    url =       {https://www.rfc-editor.org/info/rfc7999},
+    author =    {Thomas King and Christoph Dietzel and Job Snijders and Gert Döring and Greg Hankins},
+    title =     {{BLACKHOLE Community}},
+    pagetotal = 9,
+    year =      2016,
+    month =     oct,
+    abstract =  {This document describes the use of a well-known Border Gateway Protocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named "BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix.},
+}
--- a/bericht.pdf
+++ b/bericht.pdf
--- a/bericht.sty
+++ b/bericht.sty
@@ -169,18 +169,28 @@ Vgl.\cite{\thefield{entrykey}}}
 \usepackage{listings}   % http://www.ctan.org/tex-archive/macros/latex/contrib/listings/

 % Wie sollen die Überschriften benannt werden:
-\renewcommand{\lstlistingname}{Algorithmus}
+\renewcommand{\lstlistingname}{Code Snippet}

 % Wie die Liste der Listings, s. \lstlistoflistings in bericht.tex
-\renewcommand{\lstlistlistingname}{Liste der Algorithmen}
+\renewcommand{\lstlistlistingname}{Liste der Code Snippets}

 % So kann man einen Stil für alle  Algorithmen definieren
 \lstdefinestyle{algoBericht}{
-  numbers=left,              % Zeilennummern einfügen
-  numberstyle=\tiny,         % wie werden sie gesetzt
-  numbersep=5pt,             % Abstand der Nummern zum Text
-  numberblanklines=false,    % bei Leerzeilen keine Nummer ausgeben (aber zählen)
-  basicstyle=\sffamily\small,         % Wie soll der Algorithmus gesetzt werden
+    commentstyle=\color{olive},
+    keywordstyle=\color{magenta},
+    numberstyle=\tiny\color{lightgray},
+    stringstyle=\color{violet},
+    basicstyle=\ttfamily\footnotesize,
+    breakatwhitespace=false,
+    breaklines=true,
+    captionpos=b,
+    keepspaces=true,
+    numbers=left,
+    numbersep=5pt,
+    showspaces=false,
+    showstringspaces=false,
+    showtabs=false,
+    tabsize=4
 }


--- a/bericht.tex
+++ b/bericht.tex
@@ -15,7 +15,7 @@
 % ,11pt
 ,12pt
  ,pdftex
-%  ,disable         % Todo-Markierungen auschalten
+  ,disable         % Todo-Markierungen auschalten
 ]{report}

 % Bitte die Codierung Ihrer Dateien auswählen:
@@ -72,14 +72,14 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 \newcommand{\Titel}{Route Injection}
-\newcommand{\AbgabeDatum}{1. April 2090}
+\newcommand{\AbgabeDatum}{18. September 2023}

-\newcommand{\Dauer}{20 Wochen}
+\newcommand{\Dauer}{27 Wochen}

 % \newcommand{\Abschluss}{Bachelor of Engineering}
 \newcommand{\Abschluss}{Bachelor of Science}

-\newcommand{\Studiengang}{Informatik / Informationstechnik}
+\newcommand{\Studiengang}{Informationstechnik}
 % \newcommand{\Studiengang}{Informatik / Angewandte Informatik}

 \hypersetup{%%
@@ -98,6 +98,7 @@
    kapitel3,
    kapitel4,
    kapitel5,
+    kapitel6,
    changelog
 }

@@ -144,9 +145,19 @@ Gutachter der Studienakademie	 & \BetreuerDHBW		\\

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \begin{abstract}
-    Mittels Remote Triggered Route Injection können End Benutzer bequem über eine Weboberfläche,
-    Routen mittels BGP Communities manipulieren.
-    Um dies zu verwirklichen, wurde das Projekt in verschiedene Teilsysteme unterteilt, welche ihren eigenen Aufgabenbereich haben.
+    Ein \ac{DDoS}-Angriff kann eine starke Auslastung der betroffenen Systeme verursachen.
+    Dies kann einen Absturz zur Folge haben, oder den Zugriff auf die Systeme verhindern.
+    Um dieses Problem zu lösen wurde der Route Injection Service entwickelt, mit welchem ein Nutzer in der Lage ist, Netzwerkroute über \ac{BGP}-Communities zu manipulieren.
+    Ein \ac{DDoS}-Angriff kann daher in ein Blackhole geroutet, und eine Belastung der Zielsysteme verhindert werden.
+
+    \vspace{2cm}
+    \begin{flushleft}
+        \emph{A \ac{DDoS}-Attack can cause a high load on the attacked systems.
+        As a result, the systems might be inaccessible or crash.
+        To solve this problem, we developed the route injection service, which enables a user to manipulate network routes via \ac{BGP}-Communities.
+        A \ac{DDoS}-Attack can then be routed into a blackhole, and a strain on the target systems can be avoided.}
+    \end{flushleft}
+
 \end{abstract}

 \newpage
@@ -163,10 +174,10 @@ Gutachter der Studienakademie	 & \BetreuerDHBW		\\
 \include{kapitel3}
 \include{kapitel4}
 \include{kapitel5}
+\include{kapitel6}

 % Ab hier beginnt der Anhang
-\appendix
-\addcontentsline{toc}{chapter}{Anhang}
+

 \addcontentsline{toc}{chapter}{Index}
 \printindex
@@ -190,6 +201,8 @@ Gutachter der Studienakademie	 & \BetreuerDHBW		\\
 \def\refname{Literaturverzeichnis}
 \printbibliography
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%5
+\appendix
+\addcontentsline{toc}{chapter}{Anhang}


 \end{document}
--- a/erklaerung.tex
+++ b/erklaerung.tex
@@ -20,7 +20,7 @@
 \medskip
 \noindent
 % siehe §5(3) der \enquote{Studien- und Prüfungsordnung DHBW Technik} vom 29.\,9.\,2017 und Anhang 1.1.13
-Ich versichere hiermit, dass ich meine \Was  mit dem Thema:
+Ich versichere hiermit, dass ich meine \Was~mit dem Thema:
    {\Titel}
 selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
 Ich versichere zudem, dass die eingereichte elektronische Fassung mit der gedruckten Fassung übereinstimmt.
@@ -28,7 +28,7 @@ Ich versichere zudem, dass die eingereichte elektronische Fassung mit der gedruc
 \noindent
 \newline
 \underline{\hspace{4cm}}\hfill\underline{\hspace{6cm}}\\
-Ort~~~~~Datum\hfill Unterschrift\hspace{4cm}
+Ort,~~~~~Datum\hfill Unterschrift\hspace{4cm}
 \end{framed}

 \vfill
--- a/images/ri-structure.png
+++ b/images/ri-structure.png
--- a/kapitel1.tex
+++ b/kapitel1.tex
@@ -7,8 +7,6 @@

 \chapter{Einleitung}

-\section{Ziele und Motivation der Arbeit}
-
 Die zunehmende Abhängigkeit von digitalen Kommunikationsnetzwerken und die kontinuierliche Weiterentwicklung der globalen Infrastruktur haben zu einer signifikanten Steigerung des Datenverkehrs im Internet geführt.
 Während diese Fortschritte zahlreiche Vorteile für die Gesellschaft mit sich bringen, eröffnen sie auch neue Herausforderungen im Hinblick auf die Sicherheit und Stabilität des Netzwerkbetriebs.
 In diesem Zusammenhang gewinnt die Fähigkeit, den Datenverkehr effektiv zu leiten und gleichzeitig gegen potenzielle Bedrohungen zu schützen, zunehmend an Bedeutung.
--- a/kapitel2.tex
+++ b/kapitel2.tex
@@ -7,37 +7,37 @@

 \chapter{Grundlagen}

-\section{Aufgabenstellung}
+\section{Einführung in die Problematik}

 Um im Falle eines \ac{DDoS} Angriffs schnell reagieren zu können, muss es eine bequeme und einfache Möglichkeit geben, Routen zu manipulieren.
 Hierfür wurde das Projekt Remote Triggered Blackholing gestartet.
-Im Falle eines \ac{DDoS} Angriffs, könnten somit IP Präfixe des Angreifers gezielt in ein Blackhole geroutet werden.
+Im Falle eines \ac{DDoS}-Angriffs könnten somit IP Präfixe des Angreifers gezielt in ein Blackhole geroutet werden.
 Eine Belastung der Zielsysteme könnte somit verhindert werden, da die boshaften Pakete des Angreifers somit nicht beim Zielsystem ankommen würden, sondern in das schwarze Loch (Blackhole) weitergeleitet werden.
-Um die Routen in Routern manipulieren zu können, müssen diese über Injektoren in diese injiziert werden.
+Um die Routen in Routern manipulieren zu können, müssen diese über Injektoren in die Router injiziert werden.
 Im Verlaufe dieser Projektarbeit wird die Entwicklung der Injektoren Komponente und der Aufbau einer Staging(Testing) Umgebung genauer dargelegt.
-Der Aufbau und die Entwicklung der \ac{API} Komponente wurde bereits zu einem großteil in der T1000 erläutert, jedoch wurde im Rahmen der T2000 diese um einen Delete-Endpunkt erweitert.
+Der Aufbau und die Entwicklung der \ac{API} Komponente wurde bereits zu einem großteil in der T1000 erläutert, jedoch wurde im Rahmen der T2000 diese um einen Delete-Endpunkt erweitert.~\cite{Schoch.2022}

 \newpage


-\section{Genutze Technologien}
+\section{Technologie Selektion}

 \subsection{Django Rest Framework}

-Django ist ein Web-Framework, dessen Ziel es ist, die Entwicklung von Web Applikationen schnell, einfach und übersichtlich zu machen.
+\glqq Django ist ein Web-Framework, dessen Ziel es ist, die Entwicklung von Web Applikationen schnell, einfach und übersichtlich zu machen.
 Das Django \ac{REST} Framework, hier nachfolgend als \ac{DRF} bezeichnet, ist ein \ac{REST} Framework welches auf Django basiert.
 Mit \ac{DRF} lassen sich \ac{REST}-ful \ac{API}s schnell und einfach gestalten.
 Hierfür bietet Django eine Reihe an vorgefertigten Hilfestellung an, welche im Verlaufe dieser Projektarbeit näher erläutert werden.
-Datenbankmodelle werden hier einfach programmatisch deklariert und werden anschließend von Django automatisch verwaltet.
+Datenbankmodelle werden hier einfach programmatisch deklariert und anschließend von Django automatisch verwaltet.
 Über Objekte können somit einzelne Werte aus der Datenbank entnommen werden, ohne sich mühsam mit \ac{SQL} Queries auseinandersetzen zu müssen.
-Sowohl Django als auch \ac{DRF} basieren auf der Programmiersprache Python.
+Sowohl Django als auch \ac{DRF} basieren auf der Programmiersprache Python.\grqq~\cite[Vgl.][S. 8]{Schoch.2022}

 \subsection{Hashicorp Consul}

-Consul, entwickelt von Hashicorp, ist eine Netzwerk Service Lösung, welche eine sichere Kommunikation zwischen Services und Applikation erlaubt.
+\glqq Consul, entwickelt von Hashicorp, ist eine Netzwerk Service Lösung, welche eine sichere Kommunikation zwischen Services und Applikation erlaubt.
 Consul kann sowohl redundant mit mehreren Nodes, als auch standalone genutzt werden.
 Für diese Projektarbeit, wird eine standalone Lösung eingesetzt und es wird lediglich die Key-Value Store Funktion genutzt.
-Mit dieser Funktion können Key-Value Paare über das Netzwerk in Consul gespeichert werden.
+Mit dieser Funktion können Key-Value [\ldots] Paare über das Netzwerk in Consul gespeichert werden.\grqq~\cite{Schoch.2022}

 \subsection{Docker}

@@ -45,19 +45,35 @@ Docker ist Platform zur Containerisierung von Anwendungen.
 Hierdurch wird die Möglichkeit geschaffen eine isoliertes und leichtgewichtige Umgebung zu schaffen, welche sonst lediglich mittels \acp{VM} möglich wäre.
 Durch Docker wird auf produktiven System durch die zusätzliche Isolationsschicht der Containerisierung eine weitere Sicherheitsstufe hinzugefügt, welche potenziellen Angreifern den Zugriff auf das Hostsystem erschwert.

+\subsection{Bird}
+
+Der Bird Internet Routing Daemon (Bird) ist eine Open-Source-Routing-Software, die als Router fungiert.
+Bird implementiert unter anderem \ac{BGP}, um Routing-Informationen zwischen Routern auszutauschen und optimale Routenentscheidungen zu treffen.
+Bird arbeitet neben anderen \ac{BGP}-Routern, um \ac{BGP}-Sessions aufzubauen, Routing-Updates auszutauschen und Routing-Informationen zu speichern.
+Bird kann \ac{BGP}-Routen exportieren und an andere Router weitergeben, indem es \ac{BGP}-`Update`-Messages verwendet und Exportregeln in seiner Konfigurationsdatei folgt.
+Diese Regeln definieren, welche Routen exportiert werden sollen und können durch Filter und Richtlinien gesteuert werden.
+Durch den Export von \ac{BGP}-Routen ermöglicht Bird eine effiziente und zuverlässige Kommunikation und Weiterleitung in großen Netzwerken.
+
+\newpage
+
 \section{Stand der Technik}

 Das \ac{BGP} ist ein Protokoll des Internet-Routings, das die \emph{besten} Wege für den Datenverkehr zwischen \acp{AS} bestimmt.
+Im ursprünglichen Sinne war mit einem \ac{AS} eine Organisation mit einem Standort gemeint, welche intern über ein internes routing Protokoll verfügte.
+Mit der Zeit hat sich die Bedeutung eines \ac{AS} abgewandelt und eine \ac{ASN} kann von einer Organisation Standortübergreifend verwendet werden bzw. eine Organisation kann über mehrere \acp{ASN} verfügen.
 Es verwendet Peering-Verbindungen zwischen Routern, um Informationen über erreichbare Netzwerke auszutauschen und die optimalen Pfade für den Datenaustausch zu ermitteln.
 Anders als bei herkömmlichen Routing Protokollen wie dem \ac{RIP} oder \ac{OSPF}, wird hier eine direkte \ac{TCP} Verbindung zwischen Routern(Neighbours/Nachbarn) hergestellt.
-Wenn zwei \ac{BGP} Nachbarn eine \ac{BGP} Verbindung aufgebaut haben, beginnen diese \ac{BGP} Informationen in Form von Nachrichten auszutauschen.
-Jede Nachricht besteht aus einem Header, und dem tatsächlichen Inhalt.
-\cite[Vgl.][S. 19 f.]{beijnum.2002a}
-Um eine \ac{BGP} Verbindung herzustellen, müssen sich Router über eine Open-Message verbinden.
-Diese wird direkt nach dem Aufbau der \ac{TCP} Verbindung ausgetauscht.
-\cite[Vgl.][S. 20 ff.]{beijnum.2002a}
+Eine weitere Unterscheidung besteht darin, dass es sich bei \ac{BGP} um 'Policy'-basiertes Routing, im Vergleich zu `Metrik` basierten Routing handelt.
+Konkret bedeutet dies, dass ein \ac{AS} selbst bestimmen kann, wie Datenverkehr geroutet werden soll, sollte das \ac{AS} über mindestens zwei Uplinks verfügen.

-\begin{table}[h]
+
+\vspace{1cm}
+Wenn zwei \ac{BGP} Nachbarn eine \ac{TCP} Verbindung aufgebaut haben, beginnen diese \ac{BGP} Informationen in Form von Nachrichten auszutauschen.
+Jede Nachricht besteht aus einem Header, und dem tatsächlichen Inhalt.~\cite[Vgl.][S. 19 f.]{beijnum.2002a}
+Um eine \ac{BGP} Verbindung herzustellen, müssen sich Router über eine `Open`-Message verbinden.
+Diese wird direkt nach dem Aufbau der \ac{TCP} Verbindung ausgetauscht.~\cite[Vgl.][S. 20 f.]{beijnum.2002a}
+
+\begin{table}[H]
 \begin{center}
 \begin{tabular}{ |c|c|c|c|c|c| }
 \hline
@@ -66,14 +82,15 @@ Diese wird direkt nach dem Aufbau der \ac{TCP} Verbindung ausgetauscht.
  \hline
 \end{tabular}
 \end{center}
-\caption{\label{bibtex-macros}Aufbau der Open-Message}
-\centering{Quelle: \cite[RFC4271][]{rfc4271} in Anlehnung an \cite[S. 20]{beijnum.2002a}}
+\caption{\label{open-message}Aufbau der 'Open'-Message}
+\centering{Quelle: \cite[RFC4271][]{rfc4271} in Anlehnung an~\cite[S. 20]{beijnum.2002a}}
 \end{table}

+Sollte die Open-Message erfolgreich vom Gegenstück angenommen worden sein, sendet dieser eine 'Keepalive'-Message zurück.
+Anschließend wird die BGP-Routentabelle über 'Update'-Messages ausgetauscht.~\cite[Vgl.][S. 20]{beijnum.2002a}

-Um Routen zu \glqq annoncieren\grqq\space oder zurückzuziehen wird die 'UPDATE' Message verwendet.

-\begin{table}[h]
+\begin{table}[H]
 \begin{center}
 \begin{tabular}{ |c|c|c|c|c| }
 \hline
@@ -82,24 +99,32 @@ Um Routen zu \glqq annoncieren\grqq\space oder zurückzuziehen wird die 'UPDATE'
  \hline
 \end{tabular}
 \end{center}
-\caption{\label{bibtex-macros}Aufbau der Update-Message}
-\centering{Quelle: \cite[RFC4271][]{rfc4271} in Anlehnung an \cite[S. 20]{beijnum.2002a}}
+\caption{\label{update-message}Aufbau der 'Update'-Message}
+\centering{Quelle:~\cite[RFC4271][]{rfc4271} in Anlehnung an~\cite[S. 20]{beijnum.2002a}}
 \end{table}

+
+Durch die `Update`-Message werden die eigentlichen Informationen übertragen.
+Hierdurch können neue Routen hinzugefügt, oder alte Routen zurückgezogen werden.
+Ein nicht optionales Attribute ist der `AS\_PATH`, welcher beschreibt, über welche \ac{AS} bestimmte Präfixe zu erreichen sind.
+
 \newpage

-\begin{figure}[h]
- \centering
- \fbox{\includegraphics[width=\textwidth]{images/BGP_Example.png}}
- \caption{\label{fig-as-example}Struktur eines beispielhaften BGP-Netzwerks}
- \centering{Quelle: Eigene Abbildung}
-\end{figure}
+%Routepropagation: %TODO Explain how routes are propageted in BGP
+%
+%
+%\begin{figure}[H]
+% \centering
+% \fbox{\includegraphics[width=\textwidth]{images/BGP_Example}}
+% \caption{\label{bgp-network-structure}Struktur eines beispielhaften BGP-Netzwerks}
+% \centering{Quelle: Eigene Abbildung}
+%\end{figure}


 \ac{BGP}-Communities sind ein Mechanismus, mit welchem Netzwerkbetreiber spezifische Gruppen oder Kategorien von Präfixen markieren können.
-Diese Markierungen, als \glqq Communities\grqq  bezeichnet, können verwendet werden, um Routen zu identifizieren und zu beeinflussen, wie sie von anderen \acp{AS} interpretiert werden.
+Diese Markierungen, als \glqq Communities\grqq~bezeichnet, können verwendet werden, um Routen zu identifizieren und zu beeinflussen, wie sie von anderen \acp{AS} interpretiert werden.
 Durch die Verwendung von Communities können Netzwerkbetreiber das Routing auf feinere Weise steuern und anpassen, ohne die Kernstruktur des \ac{BGP}-Netzwerks zu verändern.
-Die Manipulation von Routen mittels \ac{BGP} Communities erfolgt, indem einem bestimmten Präfix eine oder mehrere Community-Markierungen zugewiesen werden.
+Die Manipulation von Routen mittels \ac{BGP} Communities erfolgt, indem einem bestimmten Präfix eine oder mehrere \ac{BGP}-Communities zugewiesen werden.
 Andere \ac{AS} können dann diese Community-Markierungen verwenden, um spezifische Aktionen auszuführen, wie z.B.:

 \begin{itemize}
@@ -110,6 +135,7 @@ Dies kann dazu verwendet werden, den bevorzugten Weg für den Datenverkehr zu be
 Durch Markieren von Präfixen können sie bestimmte \ac{AS} dazu anleiten, den Datenverkehr auf bestimmten Wegen zu leiten, um Netzwerkressourcen effizienter zu nutzen.

 \item Blackhole-Routing: \ac{BGP} Communities können dazu genutzt werden, bestimmte Präfixe zu markieren und den Datenverkehr über Blackholes zu lenken, um Angriffe oder Überlastungen zu bewältigen.
+Spezielle für Blackholing wurde eine eigene Community definiert: \verb|65535:666|~\cite[Vgl.][]{rfc7999}

 \item Routenfilterung: \ac{AS} können Community-Markierungen verwenden, um präzise Routenfilterung durchzuführen.
 Damit können sie bestimmte Routen von bestimmten Quellen oder für bestimmte Zwecke filtern oder akzeptieren.
@@ -118,11 +144,6 @@ Damit können sie bestimmte Routen von bestimmten Quellen oder für bestimmte Zw
 Die Verwendung von \ac{BGP} Communities ermöglicht eine flexiblere und zielgerichtete Steuerung des Internet-Routings.
 Netzwerkbetreiber können so gezielt auf unterschiedliche Anforderungen reagieren und gleichzeitig die Integrität und Stabilität des \ac{BGP}-Netzwerks aufrechterhalten.

-
-\begin{flushleft}
-    Durch den nahezu identischen Technologiestack wie bei der T1000 und um den Lesefluss zu wahren, wurden einige Kurzbeschreibungen in abgeänderter Form wiederverwendet.
-    \end{flushleft}
-
 \newpage

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- a/kapitel3.tex
+++ b/kapitel3.tex
@@ -5,28 +5,40 @@
 %% -*- coding: utf-8 -*-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-\chapter{Injector Komponente}
+\chapter{Architekur}

-\section{Aufgaben}
+Die Architektur des Route Injection Service besteht aus drei wesentlichen Bestandteilen, welche entweder direkt verbunden sind oder mittels Hashicorp Consul Daten austauschen können.

-\section{Umsetzung}
+\begin{figure}[H]
+    \centering
+    \fbox{\includegraphics[width=\textwidth]{images/ri-structure}}
+    \caption{\label{ri-structure}Route Injection Architektur}
+    \centering{Quelle: Firmenintern}
+\end{figure}

-\subsection{Generieren der Config Files für Bird} %TODO RNDMISC-410
+\newpage

-\subsubsection{Integrität der Konfigurationsdatei sicherstellen} %TODO RNDMISC-420
+\section{\ac{API}}

-\subsection{Status der Routen von Bird abfragen} %TODO RNDMISC-361
+Die \ac{API} ist dafür verantwortlich die Eingaben des Users, welche über die Engine übermittelt wurden zu überprüfen und zu validieren.
+Sind die Eingaben nicht korrekt, so gibt die \ac{API} eine entsprechende Fehlermeldung zurück.
+In der Zukunft wird die \ac{API} auch dafür verantwortlich sein entsprechende Monitoring Endpunkte zur Verfügung zu stellen, sodass der allgemeine Status des Service überwacht werden kann.

-\subsubsection{Evaluation der pybird Bibliothek}
+\section{Hashicorp Consul}

-\subsection{Bird und Bird6 aufteilen} %TODO RNDMISC-362
+Hashicorp Consul, im weiteren Verlauf nur `Consul` genannt, wird als Zwischenspeicher für Routen und deren injizierte \ac{BGP}-Communities verwendet.
+Des Weiteren können Injectoren hier Ihren `Heartbeat` abspeichern.

-\subsection{Realisierung des Heartbeats}
+\section{Injector}

-\subsection{Emergency Mode implementieren} %TODO RNDMISC-363
+Der Injector bezieht periodisch(alle 5 Sekunden) die in Consul gespeicherten Routen.
+Sollte es hier eine Änderung gegeben haben, wird eine Konfigurationsdatei für den Bird Routingdaemon neu erstellt.
+Anschließend wird über das 'Bird Controlsocket' der Befehl zum Neuladen der Konfiguration gegeben.

-\section{Testen}
+\section{Router}

+Als Router wird der Bird Routingdaemon eingesetzt.
+Dieser stellt eine \ac{BGP}-Session mit einem physischen Router her, welcher die von Bird zu Verfügung gestellten Router importiert und innerhalb des \ac{BGP}-Netzwerks weitergibt.

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \endinput
--- a/kapitel4.tex
+++ b/kapitel4.tex
@@ -5,12 +5,141 @@
 %% -*- coding: utf-8 -*-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-\chapter{Staging Umgebung}
+\chapter{API Komponente}

-\section{Konzeption} %TODO RNDSUP-423
+\section{Aufgaben}
+
+Die \ac{API} ist die Schnittstelle des Service und außen stehenden Technologien wie der Anexia Engine.
+Ihre Hauptaufgabe besteht darin, eine strukturierte Interaktionsmöglichkeit zu bieten, die es internen Benutzern über Systeme wie der Anexia Engine ermöglicht, \ac{BGP}-Routen mit zugehörigen \ac{BGP}-Communities in das Netzwerk zu injizieren.
+Dies geschieht durch die Annahme von \ac{JSON}-Anfragen, die spezifische Informationen enthalten, nämlich IPv4- oder IPv6-Präfixe und die entsprechenden \ac{BGP}-Communities.
+Die \ac{API} führt eine umfassende Validierung der eingehenden Daten durch, um sicherzustellen, dass die bereitgestellten Informationen korrekt und im erwarteten Format vorliegen.
+Diese Validierung umfasst die Überprüfung der Richtigkeit der IP-Adressbereiche sowie die syntaktische Korrektheit der zugeordneten \ac{BGP}-Communities.
+Durch diesen Schritt wird gewährleistet, dass nur gültige Informationen in das System eingebracht werden.
+Die validierten Daten werden anschließend an Consul, über dessen eigene \ac{API} übermittelt.
+Die Daten werden so abgelegt, dass der Injector einen erleichterten Zugriff hat.
+
+\newpage

 \section{Umsetzung}

+Da die Konzeption und Implementierung der \ac{API} schon umfassend in der Projektarbeit T1000 erläutert wurde, wird auf eine Wiederholung dessen verzichtet.
+In diesem Bericht wird lediglich die Implementierung des `Delete`-Endpunkts dargestellt, da dieser aus zeitlichen Gründen nicht mehr in den ersten beiden Praxisphase implementiert werden konnte, jedoch ein Grundbestandteil des entwickelten Service ist.
+
+\vspace{1cm}
+
+Die Implementierung eines `Delete`-Endpunkts in der API, mittels des Django Rest Frameworks, ermöglicht das Löschen von Routen aus dem System.
+
+\begin{lstlisting}[language=python,
+    frame=single,           % Ein Rahmen um den Code
+    framexleftmargin=15pt,  % Rahmen link von den Zahlen
+    style=algoBericht,
+    label={lst:baserouteviewset},
+    captionpos=b,           % Caption unter den Code setzen
+    caption={BaseRouteViewset Klasse}]
+class BaseRouteViewSet(
+    CreateModelMixin,
+    ReadOnlyModelViewSet,
+    BaseRequestViewSet,
+):
+    @action(detail=False, url_path=r"([A-Za-z-_/]*)status/(?P<task_info_id>[0-9a-z-]+)")
+    def status(self, request, task_info_id):
+        route_object = get_object_or_404(
+            self.serializer_class.Meta.model, task_info_id=task_info_id
+        )
+        propagate_status(route_object)
+        return super().status(request, task_info_id)
+\end{lstlisting}
+
+Der in Snippet 4.1 gezeigte Code stellt eine Mutterklasse dar, von welcher sowohl der `Create`, als auch `Delete`-Endpunkt erben.
+Durch diese Klasse wird die Möglichkeit gegeben, von der Anexia Engine erwartete Endpunkte einfach zu implementieren, ohne dass sich ein Entwickler mit den Feinheiten dessen auseinandersetzen muss.
+Da hier die \verb|CreateModelMixin| Klasse geerbt wird, stellt sich das \ac{DRF} automatisch ein 'POST'-Requests für diesen Endpunkt zu akzeptieren.
+
+\newpage
+
+\begin{lstlisting}[language=python,
+    frame=single,           % Ein Rahmen um den Code
+    framexleftmargin=15pt,  % Rahmen link von den Zahlen
+    style=algoBericht,
+    label={lst:deleterouteviewset},
+    captionpos=b,           % Caption unter den Code setzen
+    caption={DeleteRouteViewset Klasse}]
+class DeleteRouteViewSet(BaseRouteViewSet):
+    queryset = DeleteRoute.objects.all()
+    serializer_class = DeleteRouteSerializer
+
+    def perform_create(self, serializer):
+        super().perform_create(serializer)
+        delete_route(serializer.instance)
+\end{lstlisting}
+
+Die tatsächliche Implementierung fällt durch das Erben von der `BaseRouteViewSet` Mutterklasse sehr simpel aus.
+Durch das Überschreiben der \verb|perform_create| Methode, welche vom \ac{DRF} zur Verfügung gestellt wird, kann diese als Hook benutzt werden um eigenen Code ausführen zu lassen.
+Mit der Super Methode wird sichergestellt, dass die nicht überschriebene Ursprungsmethode von \verb|perform_create| ausgeführt wird.
+Das \ac{DRF} erstellt dann einen Datenbankeintrag mit den vom Nutzer eingegeben Werten.
+Vor dem Ende des Kontextes der Methode wird noch eine weitere Methode \verb|delete_route| aufgerufen.
+
+\begin{lstlisting}[language=python,
+    frame=single,           % Ein Rahmen um den Code
+    framexleftmargin=15pt,  % Rahmen link von den Zahlen
+    style=algoBericht,
+    label={lst:deleteroute},
+    captionpos=b,           % Caption unter den Code setzen
+    caption={delete\_route Methode}]
+def delete_route(instance):
+    consul_instance = prepare_consul(os.getenv("CONSUL_HOST"), os.getenv("CONSUL_PORT"))
+    prefix = str(instance.prefix)
+    prefix_encoding = get_prefix_encoding(prefix)
+    consul_instance.kv.delete(
+        f'v1/route/global/{prefix_encoding}/{prefix.replace("/", "_")}'
+    )
+    update_active_injectors(instance)
+\end{lstlisting}
+
+Hier findet nun das eigentliche Übermitteln der Daten an Consul statt.
+
+
+\chapter{Injector Komponente}
+
+\section{Aufgaben}
+
+Der Injector ist der zentrale Baustein des Route Injection Service, der die Möglichkeit bietet, mittels \ac{BGP} Communities, Routen in das Netzwerk zu injizieren.
+Der Injector erfüllt dabei eine Reihe von wesentlichen Aufgaben:
+\vspace{1cm}
+
+Zuallererst ist der Injector für die Konvertierung der von der \ac{API} empfangenen Routen in eine für den Router (Bird) verständliche Konfigurationsdatei verantwortlich.
+Diese Konvertierung ist von entscheidender Bedeutung, um die Weiterleitung der Routen an den Router in einem kompatiblen Format sicherzustellen.
+Während die Validierung der Präfixe und Communities von der \ac{API} Komponente übernommen wird, hat der Injector eine eigene Validierung für Routen, welchen über den Emergency-Mode angegeben werden, da hier die \ac{API} Komponente überbrückt wird.
+Bei auftretenden Konflikten oder Unstimmigkeiten kann der Injector angemessene Maßnahmen ergreifen, um die Integrität der anderen Komponenten und schlussendlich des Netzwerks, zu gewährleisten.
+Ein wichtiger Aspekt ist auch die aktive Kommunikation des Injectors mit dem Router (Bird).
+Diese Kommunikation erfolgt, um die generierten Konfigurationsänderungen effektiv zu übertragen und sicherzustellen, dass die injizierten Routen nahtlos in das Routing-Protokoll des Routers integriert werden.
+Schließlich stellt der Injector durch präzises loggen sicher, dass im Falle eines Fehlers, oder im schlimmsten Fall, bei einem Absturz der Komponente, Ereignisse festgehalten werden.
+Zusammenfassend fungiert der Injector als entscheidende Schnittstelle, die die Funktionen der \ac{API} und des Routers miteinander verbindet.
+Mit seiner intelligenten Konvertierung und Verwaltung von Routen durch \ac{BGP} Communities gewährleistet er, dass die gewünschten Routing-Änderungen präzise und effizient im \ac{BGP}-Netzwerk implementiert werden.
+
+\newpage
+
+\section{Umsetzung}
+
+\subsection{Generieren der Config Files für Bird} %TODO RNDMISC-410
+
+Um die Routen an den Bird Routing Daemon übermitteln zu können, müssen diese erst in eine für Bird verständliche Konfigurationsdatei umgewandelt werden.
+%Warum verwenden wir Jinja und wie funktionierts?
+
+\subsubsection{Integrität der Konfigurationsdatei sicherstellen} %TODO RNDMISC-420
+
+\subsection{Status der Routen von Bird abfragen} %TODO RNDMISC-361
+
+\subsubsection{Evaluation der pybird Bibliothek}
+
+\subsection{Bird und Bird6 aufteilen} %TODO RNDMISC-362
+
+\subsection{Realisierung des Heartbeats}
+
+\subsection{Emergency-Mode implementieren} %TODO RNDMISC-363
+
+\section{Testen}
+
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \endinput
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- a/kapitel5.tex
+++ b/kapitel5.tex
@@ -5,11 +5,11 @@
 %% -*- coding: utf-8 -*-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

-\chapter{Fazit}
+\chapter{Staging Umgebung}

-\section{Fazit}
+\section{Planung} %TODO RNDSUP-423

-\section{Ausblick}
+\section{Umsetzung}

 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \endinput
--- a/kapitel6.tex
+++ b/kapitel6.tex
@@ -0,0 +1,12 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% Descr:       Vorlage für Berichte der DHBW-Karlsruhe, Ein Kapitel
+%% Author:      Prof. Dr. Jürgen Vollmer, vollmer@dhbw-karlsruhe.de
+%% $Id: kapitel1.tex,v 1.24 2020/03/13 16:02:34 vollmer Exp $
+%% -*- coding: utf-8 -*-
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\chapter{Fazit}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\endinput
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%