uni/sem/OpenVPN_vs_IPSec-Paper.tex

%!TEX encoding = UTF-8 Unicode
\documentclass[12pt]{scrartcl}
%\usepackage[applemac]{inputenc} % Mac-Umlaute direkt verwenden öäüß
%\usepackage[isolatin]{inputenc} % PC-Umlaute direkt verwenden 
\usepackage[utf8]{inputenc} % Unicode funktioniert unter Windows, Linux und Mac
\usepackage[T1]{fontenc}
\usepackage{times}
\usepackage[ngerman]{babel}
\usepackage{csquotes}
\usepackage[
backend=biber,
bibstyle=ieee,
citestyle=ieee
]{biblatex}
%\usepackage{ngerman}
\usepackage{graphicx}
\usepackage[hidelinks]{hyperref}\urlstyle{rm}
\usepackage{times}
\usepackage[scaled]{helvet}
\usepackage{a4wide}
\usepackage{rotating}
\usepackage{listings}\lstset{breaklines=true,breakatwhitespace=true,frame=leftline,captionpos=b,xleftmargin=6ex,tabsize=4,numbers=left,numberstyle=\ttfamily\footnotesize,basicstyle=\ttfamily\footnotesize}
\sloppy
\setlength{\parindent}{0em}
\setlength{\parskip}{1.2ex plus 0.5ex minus 0.5ex}
\pagestyle{plain}
\addbibresource{sem.bib}

\begin{document}

\newpage
\thispagestyle{empty}
\begin{center}\Large
Universität Hamburg \par
Fachbereich Informatik
\vfill
Seminararbeit
\vfill
{\Large\textsf{\textbf{Vergleich von IPSec und OpenVPN}}\par}
\vfill
von 
\par\bigskip
Mustafa Eris, Jim Martens, Benjamin Scholz \par
Betreuer: Hannes Federrath \par
%Matrikelnummern 6420323 \par
%Studiengang BSc. Informatik
\end{center}

\newpage
\section*{Zusammenfassung}


\newpage
\tableofcontents

\newpage
\section{Vorbemerkung}
Problem: VPN (Virtual Private Network) aufsetzen
Relevanz: sichere Kommunikation zwischen zwei privaten Netzwerken

\section{Grundlagen}
Was sind VPNs? Warum braucht man sie? Wozu werden sie verwendet?
Was ist das OSI-Referenzmodell? Wie ist es aufgebaut?
\section{IPSec}
Entstehungsgeschichte
Mit Einfluss von einem Komitee entstanden.
Über die Jahre gab es viele Iterationen. 
Der Standards ist in sogenannten "Request for Comments", kurz rfc, festgehalten.
Es gibt nicht nur einen rfc, sondern viele verschiedene für die verschiedenen Aspekte von IPSec.
So ist es leichter Neuerungen einzuführen, da man nur bestimmte rfcs erneuern muss.
Durch die Art und Weise der Entstehung ist IPSec sehr komplex.
Komplexität durch zu viele Optionen, da es einfach zu viele Einflüsse von verschiedenen Seiten gab.
Es gibt ein Mitglied, das die Ansicht vertritt, dass IPSec durch den Einfluss der im Komitee anwesenden NSA-Mitarbeiter so komplex geworden ist.
-------------------------------------------------------------------------------------------------------
\subsection{Entstehungsgeschichte}
IPSec ist unter der Aufsicht eines Komitees entstanden. Diese Vorgehensweise wurde dabei gezwungenermaßen auferlegt und erschwerte nach Ansicht vieler Mitwirkender die Arbeit erheblich. \footnote{Ferguson, Niels, and Bruce Schneier. "A cryptographic evaluation of IPsec." Counterpane Internet Security, Inc 3031 (2000).} 
Die Entstehungsweise führte dazu, dass IPSec unnötig kompliziert wurde. Die einen Mitglieder wollten die eine Lösung implementieren und andere pledierten für eine andere Lösung, was dazu führte, dass beide Lösungen implementiert wurden. Dies geht jedoch zu Lasten der Nutzbarkeit. Zu viele Optionen führen nicht nur zur Verwirrung und Komplizierung der Implementation von IPSec bei den Nutzern, es kann vor Allem auch zu Sicherheitslücken führen. Experten bemängelten diese Komplexität.

\subsubsection{ToDo: guten Titel überlegen}
Die erste Version von IPSec ist 1995 spezifiziert worden. Doch über die Jahre ist der Standard immer weiter entwickelt worden und so gibt es eine zweite Version aus 1998 und eine dritte aus 2005. Diese gelten als zwar allgemein als V2 und V3, jedoch sind verschiedene Aspekte von IPSec in verschiedenen sogenannten "Request for Comments", kurz RFC, spezifiziert. So gibt es beispielsweise ein RFC, dass sich allgemein auf IPSec bezieht, aktuell RFC 4301 aus 2005, und es gibt beispielsweise ein RFC, dass sich auf die zu verwendenden Verschlüsselungsalgorithmen bezieht, aktuell RFC 7321 bereits aus 2014. So ist gewährleistet, dass IPSec weiterhin auf dem neuesten Stand gehalten werden kann, ohne dass man jedes mal die komplette Spezifikation überarbeiten muss.

Technische Details
Ist sehr tief im Betriebssystem verwurzelt. 
Schicht?
Authentication Header vs. ESP
Key Management IKEv2
used algorithms
----------------------------------------------------------------------------------------------
\subsection{Technischer Aufbau}
\subsubsection{Tunnel Modus und Transport Modus}
IPSec kann in zwei verschiedenen Modi betrieben werden: Transport Modus oder Tunnel Modus. 
Beim Tunnel Modus werden die IP-Pakete in neue Pakete verpackt mit einem neuen Header. Dabei werden die Pakete jedoch von den einzelnen Gateways bearbeitet. Das heißt im Endeffekt, dass die Sicherheit nur von Gateway zu Gateway gewährleistet wird und nicht vom einem Ende zum anderen. Der Vorteil ist, dass der Endnutzer die Anwendung nicht merkt, da zum Beispiel der Router dies übernehmen kann. 
Im Transport Modus ist die Sicherheit vom einen zum anderen Ende gewährleistet. Dabei werden die eigentlichen IP-Pakete beibehalten und einige sicherheitsrelevante Felder hinzugefügt.
\subsubsection{Authentication Header}
\subsubsection{Encapsulating Security Payload}
\subsubsection{Algorithmen}
In RFC 4835 ist festgehalten welche Algorithmen implementiert werden können, sollen oder müssen. Dabei sind die Algorithmen mit den Bewertungen must, must not, should, should not und may versehen. Zusätzlich gibt es zum Beispiel must-, was bedeutet, dass es zwar noch implementiert werden muss, aber wahrscheinlich bald zu should herabgestuft wird. Dabei wird unterschieden zwischen Verschlüsselungs-Algorithmen und Authentifizierungs-Algorithmen für ESP und Authentifizierungs-Algorithmen für AH.  


\section{OpenVPN}
Was ist OpenVPN? Wer ist dafür verantwortlich? Wie funktioniert es? 
\section{Vergleich von IPSec mit OpenVPN}

In den vorangegangenen Abschnitten wurden IPSec und OpenVPN vorgestellt. In diesem Abschnitt widmen wir uns dem Vergleich der beiden. Damit ein solcher Vergleich jedoch sinnvoll stattfinden kann, muss im Voraus klar sein, was verglichen wird. Wir benötigen daher Kriterien. Im Folgenden werden die Kriterien erarbeitet und erläutert, warum wir das jeweilige Kriterium für wichtig befinden.

\subsection{Kriterien}
Ein Hauptziel von VPNs ist die sichere Kommunikation zwischen zwei privaten Netzen. In dem Ziel selber steckt daher bereits Sicherheit als Anforderung. Es muss sichergestellt sein, dass Nachrichten von einem Netz zum anderen gelangen, ohne dass sie unterwegs in irgendeiner Weise beeinträchtigt werden. Aus diesem Grund ist natürlich von großem Interesse, wie sicher IPSec bzw. OpenVPN sind und weitergehend, ob eine der beiden Varianten sicherer ist als die andere.

Aus was setzt sich die Sicherheit jedoch zusammen? Zur Sicherheit gehören einerseits die Schutzziele in der IT-Sicherheit: Vertraulichkeit, Integrität, Verfügbarkeit. Andererseits gehören aber auch das Vorhandensein von Sicherheitslücken zur Sicherheit. Denn was nutzt ein theoretisch sicheres Verfahren, wenn es in der Implementation reihenweise Sicherheitslücken gibt?

Allerdings ist es nicht wirklich gangbar IPSec und OpenVPN anhand von Sicherheitslücken zu vergleichen, denn während IPSec ein Standard ist\cite{Kent2005}, handelt es sich bei OpenVPN um eine konkrete Implementation eines SSL/TLS-basierten VPNs\cite{Kotuliak2011}. Daher haben wir uns dagegen entschieden Sicherheitslücken in den Vergleich mit einzubeziehen.

Allerdings sind wir damit noch nicht am Ende unserer Kriterien angelangt. Aus dem Schutzziel der Verfügbarkeit lässt sich die Performance als Kriterium ableiten. Schließlich interessiert es neben der Sicherheit auch, wie schnell die Nachrichten von A nach B kommen. Was konkrete Werte bei einem Performancevergleich angeht, verweisen wir auf einen solchen Vergleich von 2011, welcher im Rahmen der ICETA Konferenz von Kotuliak\cite{Kotuliak2011} unternommen wurde.

Ein weiteres Kriterium ist die Kompatibilität zwischen Lösungen unterschiedlicher Hersteller. Dies liegt darin begründet, dass es aus Gründen der Sicherheit sinnvoll ist, Hardware unterschiedlicher Hersteller zu benutzen, da somit Sicherheitslücken bei einem Hersteller sich nicht auf das gesamte Netzwerk auswirken. Dies ist jedoch nur möglich, wenn die Implementationen der verschiedenen Hersteller zueinander kompatibel sind. In der Hinsicht hat auch Kompatibilität etwas mit Sicherheit zu tun.

Wir haben die Kriterien in dem obigen Abschnitt herausgearbeitet. Zusammengefasst sind es: Vertraulichkeit, Integrität, Verfügbarkeit, Performance und Kompatibilität.

\subsection{Vertraulichkeit}
Wir beginnen den Vergleich mit der Vertraulichkeit. Interessant sind da die unterstützten Verschlüsselungsalgorithmen und die maximalen Schlüssellängen der Algorithmen.

%TODO Vergleich Vertraulichkeit

\subsection{Integrität}
Neben der Vertraulichkeit ist auch die Integrität wichtig. Daher werden wir im folgenden Abschnitt vergleichen, welche Methoden von IPSec und OpenVPN zur Wahrung der Integrität verwendet werden.

%TODO Vergleich Integrität

\subsection{Verfügbarkeit}
Das dritte Schutzziel ist Verfügbarkeit. Traditionell fallen Dinge wie DDOS-Angriffe\footnote{Distributed-Denial-of-Service-Angriffe} unter dieses Schutzziel bzw. beeinträchtigen es. In unserem Zusammenhang ist jedoch viel wichtiger, wie weit verbreitet IPSec bzw. OpenVPN sind. Bei einer hohen Verbreitung ist es intuitiv gesehen erst einmal einfacher eine Verbindung zwischen zwei Netzen aufzubauen, da die Wahrscheinlichkeit, dass die Gegenstelle die gleiche Lösung (IPSec bzw. OpenVPN) unterstützt, höher ist. Ob dies tatsächlich so ist, werden wir im Rahmen des Vergleichs ergründen.

%TODO Vergleich Verfügbarkeit

\subsection{Performance}
Nachdem wir IPSec und OpenVPN bezüglich der Schutzziele verglichen haben, widmen wir uns jetzt der Performance.

%TODO Vergleich Performance

\subsection{Kompatibilität}
Abschließend vergleichen wir die Hardware verschiedener Hersteller auf Kompatibilität zueinander.

%TODO Vergleich Kompatibilität

\clearpage

Pool
\begin{itemize}
	\item IPSec unterstützt Secret Key\cite{Alshamsi2005}, Open VPN (SSL) nicht
	\item IPSec unterstützt eine Authentifizierungsmethode, SSL mehrere\cite{Alshamsi2005}
	\item beide nutzen MACs (Message Authentication Codes) für die Authentifizierung von Nachrichten nach initialem Kontakt\cite{Alshamsi2005}
	\item beide erfordern die Implementation von HMAC-SHA-1 und HMAC-MD5\cite{Alshamsi2005}
	\item IPSec hat Probleme mit Implementationen anderer Hersteller zusammenzuarbeiten, SSL hat dieses Problem nicht\cite{Alshamsi2005}
	\item IPSec in Netzwerkschicht, OpenVPN in Anwendungsschicht
\end{itemize}

\section{Schlussbemerkungen}
Ausblick: (weitere) Vereinfachung von IPSec?, unterschiedliche Ansätze, Vor- und Nachteile bei beiden

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage

\printbibliography
\addcontentsline{toc}{section}{Literaturverzeichnis}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\addcontentsline{toc}{section}{Anhang}

\end{document}