2martens
/
uni
mirror of https://github.com/2martens/uni.git
1
0
Fork 0
Code Releases Activity

Sem: IPsec Teil verbessert 

* ASCII-Art statt eingebundene Bilder
* Lesefluss verbessert
This commit is contained in:
Jim Martens 2015-01-02 16:27:41 +01:00
parent 5e0289224c
commit 53d2e36b6c
1 changed files with 59 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
sem/OpenVPN_vs_IPSec-Paper.tex
View File

@ -92,69 +92,92 @@ Die folgenden RFCs sind für IPsec relevant:
\item RFC 5996: Beschreibt das Internet Key Exchange Protocol Version 2 (IKEv2)\cite{RFC5996}
\item RFC 4307: Gibt vor welche Algorithmen für IKEv2 verwendet werden sollten\cite{RFC4307}
\end{itemize}
Es gibt noch viel mehr RFCs die man IPsec zuordnen kann, doch dies sind die wichtigsten. Im folgenden Abschnitt werden wir näher auf die technischen Aspekte von IPsec eingehen und die Themen der einzelnen RFCs näher betrachten.
Es gibt noch viel mehr RFCs, die man IPsec zuordnen kann, doch dies sind die Wichtigsten. Im folgenden Abschnitt werden wir auf die technischen Aspekte von IPsec eingehen und die Themen der einzelnen RFCs näher betrachten.
\subsection{Technischer Aufbau}
\subsubsection{Tunnel Modus und Transport Modus}
IPsec kann in zwei verschiedenen Modi betrieben werden: Transport Modus oder Tunnel Modus. \cite{RFC4301}
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 Tunnel Modus werden die IP-Pakete als Nutzlast neuen Paketen mit anderen Headern übergeben. Dabei werden die Pakete jedoch von den einzelnen Gateways bearbeitet. Das bedeutet im Endeffekt, dass die Sicherheit nur von Gateway zu Gateway und nicht vom einem Ende zum anderen Ende gewährleistet ist. Der Vorteil davon ist, dass die Anwendung für den Nutzer transparent geschieht und beispielsweise vom Router übernommen werden 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}
Der Authentication Header, kurz AH, kann dazu verwendet werden, um die Authentizität und Integrität von Daten zu gewährleisten, und außerdem um Replay-Angriffe abzuwehren. Er ist in RFC 4302 spezifiziert.\cite{RFC4302} Er muss im Gegensatz zur Alternative "`Encapsulating Security Payload"' jedoch nicht von IPsec Implementationen unterstützt werden.\footnote{RFC 4301 3.2. How IPsec Works} Der Grund hierfür ist, dass ESP neben dem, was der AH leistet, zusätzlich noch die Vertraulichkeit der Pakete sicherstellt. Der Authentication Header wird dabei an die IP-Pakete angehängt und sieht wie folgt aus:
Der Authentication Header (kurz: AH) kann dazu verwendet werden, die Authentizität und Integrität von Daten zu gewährleisten und Replay-Angriffe abzuwehren. Er ist in RFC 4302 spezifiziert.\cite{RFC4302} Er muss jedoch im Gegensatz zur Alternative Encapsulating Security Payload (kurz: ESP) nicht von IPsec-Implementationen unterstützt werden.\cite{RFC4301} Der Grund hierfür ist, dass ESP neben dem was AH leistet, zusätzlich noch die Vertraulichkeit der Pakete sicherstellt. Der Authentication Header wird an die IP-Pakete angehängt und sieht wie folgendermaßen aus:
\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{AH-Aufbau.png}
\caption{Aufbau des Authentication Headers aus RFC 4302}
\label{AH-Aufbau}
\end{figure}
\begin{addmargin}[-2em]{0em}
\begin{verbatim}
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{verbatim}
\end{addmargin}
Das 8 Bit lange Feld "`Next Header"' gibt an welche Art Nutzdaten nach dem AH folgen. Eine 4 bedeutet zum Beispiel IPv4 und eine 41 IPv6. Das 8 Bit lange Feld "`Payload Length"' gibt die Anzahl an 32 Bit Worten - 2 im Authentication Header an. Das 16 Bit lange Feld "`Reserved"' ist reserviert, damit man es in Zukunft nutzen kann, falls es benötigt wird. Das 32 Bit lange Feld "`Security Parameters Index"' (SPI) enthält die verwendete Security Association, die beim Versenden des Paketes verwendet wurde. Die Security Association beschreibt dabei, welche Sicherheitsdienste verwendet wurden, damit der Empfänger das Paket verarbeiten kann.
Das 32 Bit lange Feld "`Sequence Number"' wird bei jedem versendeten Paket um 1 erhöht, um so Replay-Angriffe zu verhindern. Der Empfänger akzeptiert das Paket dabei nur, wenn die Sequence Number dabei in einem bestimmten Fenster liegt. Dieses Fenster ist daher vorhanden, da Pakete oft nicht in der selben Reihenfolge empfangen, wie sie versendet werden. Außerdem ist die Nummer mit einer MAC geschützt. Das heißt, wenn der Angreifer die Nummer ändert, dann stimmt der MAC nicht, und wenn er sie nicht ändert, dann fällt diese nicht mehr in das Fenster. Es gibt auch die Möglichkeit ein erweitertes 64 Bit langes Feld für die Sequence Number zu verwenden.
Das 8 Bit lange Feld "`Next Header"' gibt an welche Art Nutzdaten nach dem AH folgen. Eine 4 bedeutet zum Beispiel IPv4 und eine 41 IPv6.\\
Das 8 Bit lange Feld "`Payload Length"' gibt die Länge des AH in 4 Byte Worten - 2 an. Das 16 Bit lange Feld "`Reserved"' ist reserviert, damit man es in Zukunft nutzen kann, falls es benötigt wird.\\
Das 32 Bit lange Feld "`Security Parameters Index"' (SPI) enthält die verwendete Security Association, die beim Versenden des Paketes verwendet wurde. Die Security Association beschreibt dabei, welche Sicherheitsdienste verwendet wurden, damit der Empfänger das Paket verarbeiten kann.\\
Das 32 Bit lange Feld "`Sequence Number"' wird bei jedem versendeten Paket um 1 erhöht, um so Replay-Angriffe zu verhindern. Der Empfänger akzeptiert das Paket dabei nur, wenn die Sequence Number dabei in einem bestimmten Fenster liegt. Dieses Fenster ist daher vorhanden, da Pakete oft nicht in der selben Reihenfolge empfangen, wie sie versendet werden. Außerdem ist die Nummer mit einer MAC geschützt. Das heißt, wenn der Angreifer die Nummer ändert, dann stimmt der MAC nicht, und wenn er sie nicht ändert, dann fällt diese nicht mehr in das Fenster. Es gibt auch die Möglichkeit ein erweitertes 64 Bit langes Feld für die Sequence Number zu verwenden.\\
Das Feld "`Integrity Check Value"' (ICV) enthält den MAC-Wert. Da dieser je nach verwendetem Algorithmus unterschiedlich lang ist, hat das Feld ebenfalls eine Variable Länge, dessen Beschränkung allerdings ist, dass es ein Vielfaches von 32 Bit sein muss, und dass der komplette AH ebenfalls ein vielfaches von 32 Bit bei IPv4 und ein vielfaches von 64 Bit bei IPv6 sein muss. Der MAC-Wert wird zur Überprüfung der Authentizität der Daten verwendet, das heißt es wird überprüft, ob das Paket auch tatsächlich vom Absender und nicht von einem Angreifer stammt.
\subsubsection{Encapsulating Security Payload}
Die Alternative zum AH ist "`Encapsulating Security Payload"', kurz ESP. Wie schon erwähnt muss ESP von IPsec-Implementationen unterstützt werden. ESP ist in RFC 4303 spezifiziert.\cite{RFC4303}
ESP schützt auch wie AH die Integrität und Authentizität der Daten. Zusätzlich bietet es auch noch einen Schutz der Vertraulichkeit. Um dies zu erreichen können die Daten verschlüsselt werden. Der Aufbau von ESP ist wie folgt:
\begin{figure}[htbp]
\centering
\includegraphics[width=0.7\textwidth]{ESP-Aufbau.png}
\caption{Aufbau von ESP aus RFC 4303}
\label{ESP-Aufbau}
\end{figure}
Im Allgemeinen wird zwischen dem Header, der vor den Nutzdaten kommt, dem Trailer, welcher nach den Nutzdaten angelegt ist, und dem Feld zum Prüfen der Authentizität unterschieden. Das heißt beim ESP sind die Nutzdaten, wie der Name schon schließen lässt, von diesen Feldern umgeben.
Das 32 Bit lange Feld "`Security Parameters Index"' (SPI) wird genau wie beim AH verwendet. Das 32 Bit lange Feld "`Sequence Numbers"' ist ebenfalls sehr ähnlich zu dem entsprechenden Feld im AH, allerdings muss die Empfänger die Nummer ignorieren, wenn der Algorithmus zur Überprüfung der Integrität Null ist. Es gibt auch die Option zu einer Erweiterung zu einem 64 Bit langem Feld.\\
Das Feld "`Payload Data"' hat eine variable Länge. Es enthält die Nutzdaten des Paketes.\\
Das Feld "`Padding"' ist 0 bis 255 Bytes lang und kann zu verschiedenen Zwecken verwendet werden. Es gibt einige Verschlüsselungs-Algorithmen die nur Inhalte verschlüsseln können die ein Vielfaches einer bestimmten Byte-Zahl sind. Mit dem Padding-Feld können so die Nutzdaten aufgefüllt werden. Eine weitere Anwendungsmöglichkeit ist mit dem Feld die tatsächliche Länge für einen Angreifer zu verbergen, allerdings wird davon im RFC 4303 abgeraten, da dies nicht effektiv genug ist und das optionale Feld "`TFC Padding"' dafür bereits vorgesehen ist.\cite{RFC4303}\\
Dieses Feld ist anders als das normale Padding-Feld nicht auf 255 Bytes limitiert und kann so einen Angreifer, der die Verkehrsdaten analysiert abwehren. Man kann das Feld im Transport-Modus jedoch nicht immer anwenden.
\begin{addmargin}[-1em]{0em}
\begin{verbatim}
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{verbatim}
\end{addmargin}
Im Allgemeinen wird zwischen dem Header, der vor den Nutzdaten kommt, dem Trailer, welcher nach den Nutzdaten angelegt ist, und dem Feld zum Prüfen der Authentizität unterschieden. Das bedeutet, dass die Nutzdaten bei ESP von diesen Feldern umgeben sind.
Eine weitere Möglichkeit die Verkehrsdaten-Analyse zu verhindern ist dummy-Pakete zu versenden, die keinen nützlichen Inhalt haben, was aber nur für den Absender und Empfänger ersichtlich ist.
Das 32 Bit lange Feld "`Security Parameters Index"' (SPI) wird genau wie beim AH verwendet. Das 32 Bit lange Feld "`Sequence Numbers"' ist ebenfalls sehr ähnlich zu dem entsprechenden Feld im AH, allerdings muss der Empfänger die Nummer ignorieren, wenn der Algorithmus zur Überprüfung der Integrität Null ist. Es gibt auch die Option zu einer Erweiterung zu einem 64 Bit langem Feld.
Das Feld "`Pad Length"' enthält die Länge des Padding-Feldes, jedoch nicht des TFC-Padding-Feldes, da dessen Länge in dem Payload Data-Feld gespeichert wird.\\
Das Feld "`Next Header"' ist 8 Bit lang. Es funktioniert ähnlich wie das entsprechende Feld des AH. Es wird benutzt um den Typ der Nutzdaten zu speichern. Wie schon beim AH gibt es zum Beispiel Werte für IPv4 und IPv6, aber zusätzlich gibt es beim ESP noch den Wert 59, welcher auf ein dummy-Paket hinweist. Das Feld "`Integrity Check Value"' hat eine variable Länge und enthält wie schon beim AH den Message Authentication Code, der benutzt wird um die Authentizität und Integrität der Nachricht zu prüfen. Der MAC wird dabei aus allen vorigen Feldern berechnet und wenn der Inhalt verschlüsselt wird, dann wird der MAC erst nach dem Verschlüsseln generiert.
Das Feld "`Payload Data"' hat eine variable Länge. Es enthält die Nutzdaten des Paketes. Das Feld "`Padding"' ist 0 bis 255 Bytes lang und kann für verschiedene Zwecke verwendet werden. Es gibt einige Verschlüsselungsalgorithmen die nur Inhalte verschlüsseln können, deren Länge ein Vielfaches einer bestimmten Bit-Zahl ist. Mit dem Padding-Feld können die Nutzdaten entsprechend aufgefüllt werden, sodass diese Algorithmen angewendet werden können. Es ist als weitere Anwendungsmöglichkeit auch möglich die tatsächliche Länge einem Angreifer gegenüber zu verbergen. Davon wird allerdings im RFC 4303 abgeraten, da dies nicht effektiv genug ist und das optionale Feld "`TFC Padding"' dafür bereits vorgesehen ist.\cite{RFC4303} Jenes Feld ist anders als das normale Padding-Feld nicht auf 255 Bytes limitiert und kann so einen Angreifer, der die Verkehrsdaten analysiert, abwehren. Jedoch kann das Feld im Transport Modus nicht immer angewendet werden. Eine weitere Möglichkeit die Verkehrsdatenanalyse zu verhindern ist der Versand von dummy-Paketen, die keinen nützlichen Inhalt enthalten. Diese Tatsache ist aber nur für den Absender und Empfänger ersichtlich.
Das Feld "`Pad Length"' enthält die Länge des normalen Padding-Feldes. Die Länge des TFC Padding Feldes wird in dem Payload Data-Feld gespeichert. Das Feld "`Next Header"' ist 8 Bit lang. Es funktioniert ähnlich wie das entsprechende Feld des AH. Es wird benutzt um den Typ der Nutzdaten zu speichern. Wie schon beim AH gibt es zum Beispiel Werte für IPv4 und IPv6. Zusätzlich gibt es beim ESP noch den Wert 59, welcher auf ein dummy-Paket hinweist. Das Feld "`Integrity Check Value"' hat eine variable Länge und enthält den Message Authentication Code, der benutzt wird um die Authentizität und Integrität der Nachricht zu prüfen. Der MAC wird dabei aus allen vorigen Feldern berechnet und wenn der Inhalt verschlüsselt wird, dann wird der MAC erst nach dem Verschlüsseln generiert (encrypt-then-MAC).
\subsubsection{Algorithmen}
In RFC 7321 ist festgehalten welche Algorithmen implementiert werden können, sollen oder müssen.\cite{RFC7321} 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.
In RFC 7321 ist festgehalten welche Algorithmen implementiert werden können, sollen oder müssen.\cite{RFC7321} 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üsselungsalgorithmen und Authentifizierungsalgorithmen für ESP und Authentifizierungsalgorithmen für AH.
Für ESP muss zur Zeit zur Verschlüsselung AES-CBC unterstützt werden. Hierbei werden die Felder Payload Data, Padding, TFC Padding, Pad Length und Next Header verschlüsselt. Im RFC 7321 steht außerdem, dass der Algorithmus Null unterstützt werden muss, was lediglich bedeutet, dass es auch möglich sein muss die Daten nicht zu verschlüsseln.
Für ESP muss aktuell für Verschlüsselung AES-CBC unterstützt werden. Hierbei werden die Felder Payload Data, Padding, TFC Padding, Pad Length und Next Header verschlüsselt. Der RFC 7321 besagt ebenfalls, dass der Algorithmus Null unterstützt werden muss. Dies bedeutet lediglich, dass es auch möglich ist die Daten nicht zu verschlüsseln.
Die Algorithmen zum Authentifizieren sind bei AH und ESP gleich. Unterstützt werden muss HMAC-SHA1-96. Es sind jeweils noch weitere Hinweise zu Algorithmen im RFC vorhanden -- zum Beispiel welche unterstützt werden sollten oder auch nicht unterstützt werden dürfen.
Die Algorithmen zum Authentifizieren sind bei AH und ESP gleich. Unterstützt werden muss HMAC-SHA1-96.\\
Es sind jeweils noch weitere Hinweise zu Algorithmen im RFC vorhanden, welche zum Beispiel unterstützt werden sollten oder auch nicht unterstützt werden dürfen.
\subsubsection{Internet Key Exchange Version 2}
Es gibt bei IPsec eine SPD\footnote{Security Policy Database}. Diese legt fest welche Verfahren angewendet werden dürfen, das heißt hier wird festgelegt welche Security Associations erstellt werden dürfen. Die SA\footnote{Security Associations} werden wiederum in einer eigenen Datenbank gespeichert, also in einer SAD\footnote{Security Associations Database}. Die SA enthalten unter anderem auch die verwendeten Schlüssel.
Es gibt bei IPsec die SPD\footnote{Security Policy Database}. Diese legt fest welche Verfahren angewendet und damit welche Security Associations erstellt werden dürfen. Die SAs\footnote{Security Associations} werden wiederum in einer eigenen Datenbank gespeichert -- der SAD\footnote{Security Associations Database}. Die SAs enthalten unter anderem auch die verwendeten Schlüssel. Die SPD wird üblicherweise per Hand eingerichtet, da diese eher statisch ist und man während der Kommunikation keine Einträge vornehmen muss. Für die SAD wird üblicherweise IKEv2\footnote{Internet Key Exchange Version 2} verwendet, welches die SAs automatisch verwaltet. IKEv2 wird in RFC 5996 spezifiziert.\cite{RFC5996}
Die SPD wird üblicherweise per Hand eingerichtet, da diese eher statisch ist und man während der Kommunikation keine Einträge vornehmen muss. Für die SAD wird üblicherweise IKEv2\footnote{Internet Key Exchange Version 2} verwendet, welches die SAs automatisch verwaltet. IKEv2 wird in RFC 5996 spezifiziert.\cite{RFC5996}
IKE legt dabei fest, wie eine Verbindung aufzubauen ist: Zunächst wird eine Prozedur durchlaufen, um eine Verbindung zwischen den Kommunizierenden herzustellen. Die einzelnen Schritte bestehen immer aus einer Nachricht des Senders und einer Nachricht des Empfängers. Der erste Austausch wird IKE\_SA\_INIT genannt. Hierbei werden zunächst Daten ausgetauscht, um zu vereinbaren wie die Verbindung hergestellt wird, also z.B. welche Algorithmen verwendet werden. Dazu schickt der Initiator dem Empfänger Vorschläge wie die Verbindung aussehen soll und der Empfänger bestätigt dann seine Auswahl. Außerdem werden Diffie-Hellman Werte und Noncen ausgetauscht. Anhand von diesen Werten und den Noncen wird SKEYSEED generiert. Mit Hilfe dieses SKEYSEEDs werden nun mehrere Schlüssel erstellt, die zum Verschlüsseln und Authentifizieren nachfolgender Kommunikation verwendet werden.
Zunächst wird eine Prozedur durchlaufen, um eine Verbindung zwischen den Kommunizierenden herzustellen. Die einzelnen Schritte bestehen immer aus einer Nachricht des Senders und einer Nachricht des Empfängers. Der erste Austausch wird IKE\_SA\_INIT genannt. Hierbei werden zunächst Daten ausgetauscht, um zu vereinbaren wie die Verbindung hergestellt wird, also z.B. welche Algorithmen verwendet werden. Dazu schickt der Initiator dem Empfänger Vorschläge wie die Verbindung aussehen soll und der Empfänger bestätigt dann seine Auswahl. Außerdem werden Diffie-Hellman Werte und Noncen ausgetauscht. Anhand von diesen Werten und den Noncen wird SKEYSEED generiert. Mit Hilfe dieses SKEYSEEDs werden nun mehrere Schlüssel erstellt, die zum Verschlüsseln und Authentifizieren nachfolgender Kommunikation verwendet werden.
Der nächste Austausch wird IKE\_AUTH genannt. Dieser Austausch ist mit den vorher generierten Schlüssel geschützt und die Kommunizierenden können sich jetzt anhand der vorher generierten Schlüssel authentifizieren. Anschließend wird eine SA ausgemacht, die in die SAD eingetragen und später genutzt wird, um die eigentliche Datenkommunikation zu regeln.
Der nächste Austausch wird IKE\_AUTH genannt. Dieser Austausch ist mit den vorher generierten Schlüssel geschützt und nun können sich die Kommunizierenden, ebenfalls anhand der vorher generierten Schlüssel, authentifizieren. Nun wird eine SA ausgemacht, die letztendlich auch in die SAD eingetragen wird, also letztendlich genutzt wird um den später die eigentliche Datenkommunikation zu regeln.
Nachfolgende Kommunikation bezüglich IKE wird CREATE\_CHILD\_SA genannt und kann dazu genutzt werden um weitere SAs zu vereinbaren. Es gibt außerdem noch INFORMATIONAL, welches z.B. für Fehlermeldungen von IKEv2 und ähnliches genutzt wird.
Nachfolgende Kommunikation bezüglich IKE wird CREATE\_CHILD\_SA genannt und kann dazu genutzt werden um weitere SAs zu vereinbaren. Außerdem gibt es noch INFORMATIONAL, welches z.B. für Fehlermeldungen von IKEv2 genutzt wird.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{OpenVPN}