IPSEC: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Thomas (Diskussion | Beiträge) |
Thomas (Diskussion | Beiträge) |
||
| Zeile 1: | Zeile 1: | ||
| − | = | + | =IPSEC Begriffserklärung= |
| − | IPsec (Kurzform für Internet Protocol Security) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie dem Internet ermöglichen soll. | + | IPsec (Kurzform für Internet Protocol Security) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie dem Internet ermöglichen soll. IPSec kann lokale Netze oder auch einzelne Clients mit privaten Netzwerkadressen über das Internet verbinden. Dazu werden die ursprünglichen IP-Pakete verschlüsselt und in neue Pakete eingepackt. Beim Empfänger werden die Pakete wieder ausgepackt, entschlüsselt, geprüft und weitergeleitet. |
| − | + | IPsec soll folgende Funktionen bereit stellen: | |
| − | + | * '''Datenvertraulichkeit:''' Die Daten werden vor der Übertragung verschlüsselt, so dass sie von keinem anderen außer den beteiligten Kommunikationspartnern gelesen werden können. | |
| − | + | * '''Datenintegrität:''' Der einzellne Teilnehmer kann erkennen ob ein empfangenes Paket auch genauso angekommen ist wie es von der Quelle abgeschickt wurde. | |
| − | + | * '''Datenursprungs-Authentifizierung:''' Der Teilnehmer der ein Paket empfangen hat kann erkennen, ob es sich bei dem Absender auch um denjenigen handelt, der dieser in dem Paket vorgibt zu sein. | |
| − | |||
| + | * '''Antireplay:''' Der Empfänger kann wiederholt versendete Pakete erkennen und ablehnen | ||
| − | + | Dazu verwendet IPsec 2 wichtige Netzwerkprotokolle, nämlich ESP (Encapsulated Security Payload) und AH (Authentication Header) | |
| − | + | =Authentication Header (AH)= | |
| − | + | AH, oder IP-Protokoll 51, dient dazu die Integrität eines Paketes sicherzustellen. Hierzu berechnet es auf Basis eines Secret-Keys für jedes Paket, inklusive Header eine Signatur; den sog. hash message authentication code (HMAC). Dieser HMAC stellt den größten und wichtigsten Teil des insgesamt 24Byte großen Authentication Header dar. Da in den HMAC auch die Adress-Felder des IP-Kopfes einbezogen werden können Pakete bei AH-Verbindungen nicht ohne weiteres mit NAT behandelt werden. Hierbei würde die Signatur ungültig. Durch AH werden die Pakete nicht verschlüsselt! | |
| − | + | [[Datei:AH.gif]] | |
| − | + | Der AH wird eingesetzt um folgendes zu gewährleisten: | |
| − | + | * '''Datenintegrität:''' Dies wird ermöglicht durch Berechnen eines Hash-Wertes für das gesamte Paket einschließlich des ursprünglichen IP-Headers, des Datenteils des Pakets und des Authentifizierungs-Headers. Zu den Hash-Algorithmen zählen MD5 und SHA-1. | |
| − | + | * '''Datenursprungs-Authentifizierung:''' Die Quell-IP ist in den Daten enthalten und kann mit den in IPsec eingebenen Werten verglichen werden. Somit kann die Integrität gewährleistet werden. | |
| − | + | * '''Replay-Schutz:''' AH enthält außerdem eine IPsec-Sequenznummer, die in den authentifizierten Daten enthalten ist und vom Empfänger überprüft werden kann. | |
| + | =Encapsulated Security Payload (ESP)= | ||
| − | + | Im Gegensatz zu AH werden bei ESP (IP-Protokoll 50) die Pakete verschlüsselt übertragen. Hierbei wird das komplette IP-Paket inklusive der Headerdaten verschlüsselt und in einem neuen Paket verpackt (encapsulated). Zusätzlich wird wie beim AH die Integrität des Pakets durch einen HMAC sicher gestellt. Dieser bezieht sich jedoch anders als beim AH auf das verschlüsselte Paket, was dem ESP auch NAT ermöglicht. Einen weiteren positiven Aspekt dieses Protokolls stellt die Tatsache dar, daß nach außen nur die Kommunikation zwischen den VPN-Gateways sichtbar ist. Eine Kommunikationsbeziehung der LAN-Clients ist nicht erkennbar – somit können auch keine IP-Adressen für anderweitige Angriffe gewonnen werden. | |
| − | + | [[Datei:ESP.gif]] | |
| − | |||
| − | + | '''''Da ESP heutzutage die meisten der AH-Features auch ausführen kann wird AH kaum noch verwendet.'' | |
| + | ''' | ||
| − | + | =IPsec Kommunikations-Modi= | |
| − | + | IPsec verfügt über 2 Kommunikations-Modi. Den Transport-Modus und den Tunnel-Modus. | |
| − | + | * '''Transport-Modus:''' Im Transport-Modus ist lediglich der Datenanteil eines Pakets betroffen. Der ursprüngliche IP-Header wird nicht verändert. Dieser Modus wird verwendet wenn Sender und Empfänger Endpunkte der Kommunikation sind. (Host-to-Host-VPN) | |
| − | + | * '''Tunnel-Modus:''' Im Tunnel-Modus wird das komplette ursprüngliche Paket als Datenteil eines neuen Pakets betrachtet und ein neuer externer IP-Header erstellt. Dieser Modus ermöglicht Tunneling durch den Kanal zwischen zwei Gateways und ist daher besonders für Side-to-Side-VPN geeignet. | |
| − | + | [[Datei:Tunnel_VS_Transport.png]] | |
| − | + | =Internet Key Exchange= | |
| − | + | Um eine sichere Verbindung im Internet aufzubauen wird ein gemeinsames Verschlüsselungsverfahren benötigt. Durch IKE wird dieses ausgehandelt und der Symmetrische Schlüssel ausgetauscht. IKE ist der Quasi-Standart zum automatischen Schlüsselaustausch im Internet es läuft auf UDP-Port 500 und beschreibt den gesamten Ablauf bis zur Erstellung einer gemeinsamen IPSec-SA (Security Association). IKE läuft dabei in 2 Phasen ab: | |
| − | + | ===Main Mode=== | |
| − | + | Im Main-Mode wird zunächst eine gesicherte Verbindung zwischen 2 Teilnehmern aufgebaut, durch die 3 Austausche von Daten stattfinden: | |
| − | + | 1. Im ersten Austausch sendet die initiierende Seite einen Vorschlag an ihr Gegenüber in der eine Reihe möglicher, durch den Initiator unterstützte Parameter enthalten sind. Jedes dieser Sets enthält einen Verschlüsselungsalgorithmus (DES, 3DES, usw.) und einen Authentifizierungsalgorithmus (Pre-Shared Secret, RSA-Public-Key-Verschlüsselung mit Diffie-Hellman-Austausch Gruppe 1 und 2 oder Public-Key-RSA-Signatur [Zertifikate]). Die andere Seite antwortet dann indem sie ein einzellnes paar, dass sie ebenfalls unterstützt, aus dem angebotenen Set akzeptiert. Falls es keine Übereinstimmung gibt, kann eine IKE-Verbindung nicht aufgebaut werden. | |
| − | |||
| − | + | 2. Im 2ten Austausch werden DH-Schlüssel zwischen den Teilnehmern eingerichtet. Es werden außerdem 2 Werte (Nonces) ausgetauscht bei denen es sich um Hash-Werte handelt die nur die andere Seite interpretieren kann. | |
| − | |||
| − | |||
| − | |||
| − | Im | + | 3. Im letzten Austausch findet findet die tatsächliche Authentifizierung unter Verwendung der zuvor ausgehandelten Methoden statt. |
| − | |||
| − | |||
[[Datei:main.jpg]] | [[Datei:main.jpg]] | ||
===Quick Mode=== | ===Quick Mode=== | ||
| + | |||
Nachdem durch den Main Mode die Authentizität und die Vertraulichkeit gewährleist ist, wird die ISAKMP SA genutzt um die eigentliche IPSec Security Association abzuschließen. | Nachdem durch den Main Mode die Authentizität und die Vertraulichkeit gewährleist ist, wird die ISAKMP SA genutzt um die eigentliche IPSec Security Association abzuschließen. | ||
| − | Auch bei bestehenden Verbindungen wird der QuickMode gebraucht um von Zeit zu Zeit die Schlüssel auszuwechseln. | + | Auch bei bestehenden Verbindungen wird der QuickMode gebraucht um von Zeit zu Zeit die Schlüssel auszuwechseln. Es ist auch möglich für den Quick-Modus die Verwendung von PFS (Perfect Forward Secrecy) anzufordern. PFS schreibt vor, dass neue Verschlüsselungskeys nicht von den alten abgeleitet werden dürfen. |
| − | + | [[Datei:Ipsec-aufbau.jpg]] | |
| − | + | =Pre-shared Key= | |
| − | + | Mit Pre-Shared Key ("vorher vereinbarter Schlüssel") oder kurz PSK bezeichnet man solche Verschlüsselungsverfahren, bei denen die Schlüssel vor der Kommunikation beiden Teilnehmern bekannt sein müssen, also symmetrische Verfahren. PSK-Verschlüsselung hat den Vorteil, dass sie zwischen zwei bekannten Teilnehmern wesentlich einfacher zu realisieren ist als asymmetrische Verschlüsselung. Der große Nachteil des Verfahrens besteht darin, dass beide Teilnehmer den Schlüssel vor der eigentlichen Kommunikation im Geheimen tauschen müssen. Daraus folgt, dass das PSK-Verfahren für viele Anwendungen im Internet (wie z. B. Online-Einkauf) ungeeignet ist, da der vorherige Schlüsseltausch in diesem Fall nicht möglich bzw. viel zu aufwendig ist. In einem solchen Fall verwendet man besser das Public-Key-Verfahren. | |
| − | + | =Public-Key= | |
| − | + | Public-Key Kryptographie basiert auf einem mathematischen Verfahren, bei dem ein Schlüsselpaar aus einem geheimen Schlüssel (Private Key) und einem dazugehörigen öffentlichen Schlüssel (Public Key) erzeugt wird. Mit dem Public Key verschlüsselte Nachrichten können nur mit dem dazugehörigen Private Key entschlüsselt werden. Hat jemand nur den Public Key, so kann er nur verschlüsseln, nicht aber entschlüsseln. | |
| − | + | Daher können die Public Keys problemlos auf unsicheren Kanälen (z.B. per E-Mail) ausgetauscht werden. | |
| − | + | Die einzige Gefahr besteht darin, dass ein Angreifer den Schlüssel vertauscht haben könnte. Wenn Sie ganz sicher gehen wollen, können daher nach dem Schlüsselaustausch die Signaturen der Schlüssel z.B. am Telefon verglichen werden. | |
| − | + | =Zertifikate= | |
| − | + | Als Erweiterung zum Konzept von öffentlichen und privaten Schlüsseln gibt es Zertifikate. Dabei wird der öffentliche Schlüssel von einer Zertifizierungsstelle (engl. Certification Authority, abgekürzt CA), digital signiert. Das ermöglicht bei größeren Installationen, dass eine Gegenstelle anhand der digitalen Signatur feststellen kann, ob ein Schlüssel gültig ist, ohne dass der Schlüssel selbst vorher installiert wurde. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | =Security Associations (SAs)= | |
| − | |||
| − | + | Jede SA kann anhand von 3 Parametern eindeutig identifiziert werden: | |
| − | + | * Der Security Parameter Index (SPI), der in AH- und ESP-Headern immer vorhanden ist | |
| + | * Die Ziel-Ip-Adresse | ||
| + | * Das IPsec-Protokoll, AH oder ESP - Wenn beide verwendet werden muss jedes seine eigene SA haben (insgesamt 4 für eine beidseitige Kommunikation) | ||
| − | |||
| − | |||
| − | + | Jeder Teilnehmer verwaltet eine Datenbank mit aktiven SAs für jede Richtung (eingehend und ausgehend) auf jeder seiner Schnittstellen, die Security Association Database (SAD). Für jede SA enthält die SAD folgende Daten: | |
| + | * Die Zieladresse | ||
| + | * Den SPI | ||
| + | * Die IPsec-Transformation (Protokoll + Algorithmus, z.B. AH, HMAC-MD5, usw.) | ||
| + | * Den in dem Algorithmus verwendeten Schlüssel | ||
| + | * Den IPsec-Modus (Tunnel oder Transport) | ||
| + | * Die SA-Lebensdauer, nach deren Ablauf eine neue eingerichtet werden muss | ||
| + | * Die Antireplay-Sequenz-Zähler | ||
| + | * Einige zusätzliche Parameter wie etwa Path MTU | ||
| − | + | [[Datei:Ipsec_SAs.png]] | |
| + | =Security Policy Database= | ||
| + | Die Auswahl der Verschlüsselungs-Parameter, sowie entsprechender SAs wird über eine andere Datenbank, die Security Policy Database (SPD), verwaltet. Sie wird für jede Schnittstelle einzelln festgelegt und legt folgendes fest: | ||
| + | * Auswahl des zu schützenden, ausgehenden Verkehrs | ||
| + | * Überprüfung, ob der eingehende Verkehr geschützt wurde | ||
| + | * Die für den Schutz notwendigen SAs | ||
| + | * Was zu geschehen hat wenn für einen Fall keine SA vorhanden ist | ||
| + | [[Datei:Ipsec_SAD_SPD.png]] | ||
| − | |||
| − | |||
| − | |||
| − | + | [[Datei:Ipsec-db.jpg]] | |
| − | |||
Version vom 7. September 2017, 08:45 Uhr
IPSEC Begriffserklärung
IPsec (Kurzform für Internet Protocol Security) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie dem Internet ermöglichen soll. IPSec kann lokale Netze oder auch einzelne Clients mit privaten Netzwerkadressen über das Internet verbinden. Dazu werden die ursprünglichen IP-Pakete verschlüsselt und in neue Pakete eingepackt. Beim Empfänger werden die Pakete wieder ausgepackt, entschlüsselt, geprüft und weitergeleitet.
IPsec soll folgende Funktionen bereit stellen:
- Datenvertraulichkeit: Die Daten werden vor der Übertragung verschlüsselt, so dass sie von keinem anderen außer den beteiligten Kommunikationspartnern gelesen werden können.
- Datenintegrität: Der einzellne Teilnehmer kann erkennen ob ein empfangenes Paket auch genauso angekommen ist wie es von der Quelle abgeschickt wurde.
- Datenursprungs-Authentifizierung: Der Teilnehmer der ein Paket empfangen hat kann erkennen, ob es sich bei dem Absender auch um denjenigen handelt, der dieser in dem Paket vorgibt zu sein.
- Antireplay: Der Empfänger kann wiederholt versendete Pakete erkennen und ablehnen
Dazu verwendet IPsec 2 wichtige Netzwerkprotokolle, nämlich ESP (Encapsulated Security Payload) und AH (Authentication Header)
Authentication Header (AH)
AH, oder IP-Protokoll 51, dient dazu die Integrität eines Paketes sicherzustellen. Hierzu berechnet es auf Basis eines Secret-Keys für jedes Paket, inklusive Header eine Signatur; den sog. hash message authentication code (HMAC). Dieser HMAC stellt den größten und wichtigsten Teil des insgesamt 24Byte großen Authentication Header dar. Da in den HMAC auch die Adress-Felder des IP-Kopfes einbezogen werden können Pakete bei AH-Verbindungen nicht ohne weiteres mit NAT behandelt werden. Hierbei würde die Signatur ungültig. Durch AH werden die Pakete nicht verschlüsselt!
Der AH wird eingesetzt um folgendes zu gewährleisten:
- Datenintegrität: Dies wird ermöglicht durch Berechnen eines Hash-Wertes für das gesamte Paket einschließlich des ursprünglichen IP-Headers, des Datenteils des Pakets und des Authentifizierungs-Headers. Zu den Hash-Algorithmen zählen MD5 und SHA-1.
- Datenursprungs-Authentifizierung: Die Quell-IP ist in den Daten enthalten und kann mit den in IPsec eingebenen Werten verglichen werden. Somit kann die Integrität gewährleistet werden.
- Replay-Schutz: AH enthält außerdem eine IPsec-Sequenznummer, die in den authentifizierten Daten enthalten ist und vom Empfänger überprüft werden kann.
Encapsulated Security Payload (ESP)
Im Gegensatz zu AH werden bei ESP (IP-Protokoll 50) die Pakete verschlüsselt übertragen. Hierbei wird das komplette IP-Paket inklusive der Headerdaten verschlüsselt und in einem neuen Paket verpackt (encapsulated). Zusätzlich wird wie beim AH die Integrität des Pakets durch einen HMAC sicher gestellt. Dieser bezieht sich jedoch anders als beim AH auf das verschlüsselte Paket, was dem ESP auch NAT ermöglicht. Einen weiteren positiven Aspekt dieses Protokolls stellt die Tatsache dar, daß nach außen nur die Kommunikation zwischen den VPN-Gateways sichtbar ist. Eine Kommunikationsbeziehung der LAN-Clients ist nicht erkennbar – somit können auch keine IP-Adressen für anderweitige Angriffe gewonnen werden.
Da ESP heutzutage die meisten der AH-Features auch ausführen kann wird AH kaum noch verwendet.
IPsec Kommunikations-Modi
IPsec verfügt über 2 Kommunikations-Modi. Den Transport-Modus und den Tunnel-Modus.
- Transport-Modus: Im Transport-Modus ist lediglich der Datenanteil eines Pakets betroffen. Der ursprüngliche IP-Header wird nicht verändert. Dieser Modus wird verwendet wenn Sender und Empfänger Endpunkte der Kommunikation sind. (Host-to-Host-VPN)
- Tunnel-Modus: Im Tunnel-Modus wird das komplette ursprüngliche Paket als Datenteil eines neuen Pakets betrachtet und ein neuer externer IP-Header erstellt. Dieser Modus ermöglicht Tunneling durch den Kanal zwischen zwei Gateways und ist daher besonders für Side-to-Side-VPN geeignet.
Internet Key Exchange
Um eine sichere Verbindung im Internet aufzubauen wird ein gemeinsames Verschlüsselungsverfahren benötigt. Durch IKE wird dieses ausgehandelt und der Symmetrische Schlüssel ausgetauscht. IKE ist der Quasi-Standart zum automatischen Schlüsselaustausch im Internet es läuft auf UDP-Port 500 und beschreibt den gesamten Ablauf bis zur Erstellung einer gemeinsamen IPSec-SA (Security Association). IKE läuft dabei in 2 Phasen ab:
Main Mode
Im Main-Mode wird zunächst eine gesicherte Verbindung zwischen 2 Teilnehmern aufgebaut, durch die 3 Austausche von Daten stattfinden:
1. Im ersten Austausch sendet die initiierende Seite einen Vorschlag an ihr Gegenüber in der eine Reihe möglicher, durch den Initiator unterstützte Parameter enthalten sind. Jedes dieser Sets enthält einen Verschlüsselungsalgorithmus (DES, 3DES, usw.) und einen Authentifizierungsalgorithmus (Pre-Shared Secret, RSA-Public-Key-Verschlüsselung mit Diffie-Hellman-Austausch Gruppe 1 und 2 oder Public-Key-RSA-Signatur [Zertifikate]). Die andere Seite antwortet dann indem sie ein einzellnes paar, dass sie ebenfalls unterstützt, aus dem angebotenen Set akzeptiert. Falls es keine Übereinstimmung gibt, kann eine IKE-Verbindung nicht aufgebaut werden.
2. Im 2ten Austausch werden DH-Schlüssel zwischen den Teilnehmern eingerichtet. Es werden außerdem 2 Werte (Nonces) ausgetauscht bei denen es sich um Hash-Werte handelt die nur die andere Seite interpretieren kann.
3. Im letzten Austausch findet findet die tatsächliche Authentifizierung unter Verwendung der zuvor ausgehandelten Methoden statt.
Quick Mode
Nachdem durch den Main Mode die Authentizität und die Vertraulichkeit gewährleist ist, wird die ISAKMP SA genutzt um die eigentliche IPSec Security Association abzuschließen. Auch bei bestehenden Verbindungen wird der QuickMode gebraucht um von Zeit zu Zeit die Schlüssel auszuwechseln. Es ist auch möglich für den Quick-Modus die Verwendung von PFS (Perfect Forward Secrecy) anzufordern. PFS schreibt vor, dass neue Verschlüsselungskeys nicht von den alten abgeleitet werden dürfen.
Mit Pre-Shared Key ("vorher vereinbarter Schlüssel") oder kurz PSK bezeichnet man solche Verschlüsselungsverfahren, bei denen die Schlüssel vor der Kommunikation beiden Teilnehmern bekannt sein müssen, also symmetrische Verfahren. PSK-Verschlüsselung hat den Vorteil, dass sie zwischen zwei bekannten Teilnehmern wesentlich einfacher zu realisieren ist als asymmetrische Verschlüsselung. Der große Nachteil des Verfahrens besteht darin, dass beide Teilnehmer den Schlüssel vor der eigentlichen Kommunikation im Geheimen tauschen müssen. Daraus folgt, dass das PSK-Verfahren für viele Anwendungen im Internet (wie z. B. Online-Einkauf) ungeeignet ist, da der vorherige Schlüsseltausch in diesem Fall nicht möglich bzw. viel zu aufwendig ist. In einem solchen Fall verwendet man besser das Public-Key-Verfahren.
Public-Key
Public-Key Kryptographie basiert auf einem mathematischen Verfahren, bei dem ein Schlüsselpaar aus einem geheimen Schlüssel (Private Key) und einem dazugehörigen öffentlichen Schlüssel (Public Key) erzeugt wird. Mit dem Public Key verschlüsselte Nachrichten können nur mit dem dazugehörigen Private Key entschlüsselt werden. Hat jemand nur den Public Key, so kann er nur verschlüsseln, nicht aber entschlüsseln.
Daher können die Public Keys problemlos auf unsicheren Kanälen (z.B. per E-Mail) ausgetauscht werden.
Die einzige Gefahr besteht darin, dass ein Angreifer den Schlüssel vertauscht haben könnte. Wenn Sie ganz sicher gehen wollen, können daher nach dem Schlüsselaustausch die Signaturen der Schlüssel z.B. am Telefon verglichen werden.
Zertifikate
Als Erweiterung zum Konzept von öffentlichen und privaten Schlüsseln gibt es Zertifikate. Dabei wird der öffentliche Schlüssel von einer Zertifizierungsstelle (engl. Certification Authority, abgekürzt CA), digital signiert. Das ermöglicht bei größeren Installationen, dass eine Gegenstelle anhand der digitalen Signatur feststellen kann, ob ein Schlüssel gültig ist, ohne dass der Schlüssel selbst vorher installiert wurde.
Security Associations (SAs)
Jede SA kann anhand von 3 Parametern eindeutig identifiziert werden:
- Der Security Parameter Index (SPI), der in AH- und ESP-Headern immer vorhanden ist
- Die Ziel-Ip-Adresse
- Das IPsec-Protokoll, AH oder ESP - Wenn beide verwendet werden muss jedes seine eigene SA haben (insgesamt 4 für eine beidseitige Kommunikation)
Jeder Teilnehmer verwaltet eine Datenbank mit aktiven SAs für jede Richtung (eingehend und ausgehend) auf jeder seiner Schnittstellen, die Security Association Database (SAD). Für jede SA enthält die SAD folgende Daten:
- Die Zieladresse
- Den SPI
- Die IPsec-Transformation (Protokoll + Algorithmus, z.B. AH, HMAC-MD5, usw.)
- Den in dem Algorithmus verwendeten Schlüssel
- Den IPsec-Modus (Tunnel oder Transport)
- Die SA-Lebensdauer, nach deren Ablauf eine neue eingerichtet werden muss
- Die Antireplay-Sequenz-Zähler
- Einige zusätzliche Parameter wie etwa Path MTU
Security Policy Database
Die Auswahl der Verschlüsselungs-Parameter, sowie entsprechender SAs wird über eine andere Datenbank, die Security Policy Database (SPD), verwaltet. Sie wird für jede Schnittstelle einzelln festgelegt und legt folgendes fest:
- Auswahl des zu schützenden, ausgehenden Verkehrs
- Überprüfung, ob der eingehende Verkehr geschützt wurde
- Die für den Schutz notwendigen SAs
- Was zu geschehen hat wenn für einen Fall keine SA vorhanden ist
