4.4. Wichtige IPsec-Datenbanken (Major IPsec Databases)
Viele der Details, die mit der Verarbeitung von IP-Verkehr in einer IPsec-Implementierung verbunden sind, sind weitgehend eine lokale Angelegenheit und unterliegen nicht der Standardisierung. Einige externe Aspekte der Verarbeitung müssen jedoch standardisiert werden, um Interoperabilität zu gewährleisten und eine minimale Verwaltungsfähigkeit bereitzustellen, die für die produktive Nutzung von IPsec wesentlich ist. Dieser Abschnitt beschreibt ein allgemeines Modell für die Verarbeitung von IP-Verkehr in Bezug auf IPsec-Funktionalität zur Unterstützung dieser Interoperabilitäts- und Funktionalitätsziele. Das unten beschriebene Modell ist nominal; Implementierungen müssen nicht mit den Details dieses Modells übereinstimmen, wie sie präsentiert werden, aber das externe Verhalten von Implementierungen MUSS den von außen beobachtbaren Merkmalen dieses Modells entsprechen, um konform zu sein.
Es gibt drei nominale Datenbanken in diesem Modell: die Sicherheitsrichtliniendatenbank (Security Policy Database, SPD), die Sicherheitsassoziationsdatenbank (Security Association Database, SAD) und die Peer-Autorisierungsdatenbank (Peer Authorization Database, PAD). Die erste spezifiziert die Richtlinien, die die Disposition des gesamten IP-Verkehrs eingehend oder ausgehend von einem Host oder Sicherheitsgateway bestimmen (Abschnitt 4.4.1). Die zweite Datenbank enthält Parameter, die mit jeder eingerichteten (mit Schlüssel versehenen) SA verbunden sind (Abschnitt 4.4.2). Die dritte Datenbank, die PAD, stellt eine Verbindung zwischen einem SA-Verwaltungsprotokoll (wie IKE) und der SPD bereit (Abschnitt 4.4.3).
Mehrere getrennte IPsec-Kontexte
Wenn eine IPsec-Implementierung als Sicherheitsgateway für mehrere Teilnehmer fungiert, KANN sie mehrere getrennte IPsec-Kontexte implementieren. Jeder Kontext KANN völlig unabhängige Identitäten, Richtlinien, Schlüsselverwaltungs-SAs und/oder IPsec-SAs haben und verwenden. Dies ist zum größten Teil eine lokale Implementierungsangelegenheit. Es ist jedoch ein Mittel erforderlich, um eingehende (SA-) Vorschläge mit lokalen Kontexten zu verknüpfen. Zu diesem Zweck KÖNNEN Kontextidentifikatoren vom Initiator zum Responder in den Signalisierungsnachrichten übermittelt werden, wenn dies durch das verwendete Schlüsselverwaltungsprotokoll unterstützt wird, mit dem Ergebnis, dass IPsec-SAs mit einer Bindung an einen bestimmten Kontext erstellt werden. Beispielsweise wird ein Sicherheitsgateway, das VPN-Dienste für mehrere Kunden bereitstellt, in der Lage sein, den Verkehr jedes Kunden dem richtigen VPN zuzuordnen.
Weiterleitungs- vs. Sicherheitsentscheidungen
Das hier beschriebene IPsec-Modell verkörpert eine klare Trennung zwischen Weiterleitungs- (Routing-) und Sicherheitsentscheidungen, um eine breite Palette von Kontexten zu berücksichtigen, in denen IPsec eingesetzt werden kann. Die Weiterleitung kann trivial sein, wenn es nur zwei Schnittstellen gibt, oder sie kann komplex sein, z.B. wenn der Kontext, in dem IPsec implementiert ist, eine ausgeklügelte Weiterleitungsfunktion verwendet. IPsec geht nur davon aus, dass ausgehender und eingehender Verkehr, der die IPsec-Verarbeitung durchlaufen hat, auf eine Weise weitergeleitet wird, die mit dem Kontext übereinstimmt, in dem IPsec implementiert ist. Die Unterstützung verschachtelter SAs ist optional; falls erforderlich, erfordert sie eine Koordination zwischen Weiterleitungstabellen und SPD-Einträgen, um ein Paket mehr als einmal über die IPsec-Grenze zu leiten.
"Lokal" vs "Entfernt"
In diesem Dokument werden in Bezug auf IP-Adressen und Ports die Begriffe "Lokal" und "Entfernt" für Richtlinienregeln verwendet. "Lokal" bezieht sich auf die Entität, die durch eine IPsec-Implementierung geschützt wird, d.h. die "Quell"-Adresse/Port von ausgehenden Paketen oder die "Ziel"-Adresse/Port von eingehenden Paketen. "Entfernt" bezieht sich auf eine Peer-Entität oder Peer-Entitäten. Die Begriffe "Quelle" und "Ziel" werden für Paket-Header-Felder verwendet.
"Nicht-initiale" vs "initiale" Fragmente
In diesem Dokument wird der Ausdruck "nicht-initiale Fragmente" verwendet, um Fragmente zu bezeichnen, die nicht alle Selektorwerte enthalten, die möglicherweise für die Zugriffskontrolle benötigt werden (z.B. enthalten sie möglicherweise nicht das Next Layer Protocol, Quell- und Zielports, ICMP-Nachrichtentyp/-code, Mobility Header-Typ). Und der Ausdruck "initiales Fragment" wird verwendet, um ein Fragment zu bezeichnen, das alle für die Zugriffskontrolle benötigten Selektorwerte enthält. Es sollte jedoch beachtet werden, dass bei IPv6, welches Fragment das Next Layer Protocol und Ports (oder ICMP-Nachrichtentyp/-code oder Mobility Header-Typ) enthält, von der Art und Anzahl der vorhandenen Erweiterungs-Header abhängt. Das "initiale Fragment" ist in diesem Kontext möglicherweise nicht das erste Fragment.