-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung bezieht auf IPSec-Verarbeitung und insbesondere,
obwohl nicht notwendigerweise auf eine IPsec-Verarbeitung bei zwischengeschalteten
Netzwerkvorrichtung wie etwa Routern.
-
Hintergrund
der Erfindung
-
IPSec
(Internet-Protocol Sicherheit) ist ein Satz von Protokollen, die
von der Internet Engineering Taskforce (RFC2401) definiert sind,
welcher einen Sicherheitsmechanismus für IP und gewisse höhere Schichtenprotokolle
wie etwa UDP und TCP bereitstellt. IPSec schützt IP-Pakete (oder genauer
gesagt IPSec-Pakete) und höhere
Schichtenprotokolle während
der Übertragung
zwischen Peer-Knoten durch Einführen
von Ursprungsbeweis und Verschlüsselung.
-
Eines
der IPSec-Protokolle ist als "Encapsulating
Security Payload" (ESP,
eingekapselte Sicherheitsnutzlast) bekannt und stellt Zuverlässigkeit,
Datenintegrität
und Datenquellen-Authentifizierung
von IP-Paketen bereit. Dies erfordert das Einfügen eines ESP-Kopfs nach dem
IP-Kopf eines IP-Pakets, aber vor den zu schützenden Daten. Ein ESP-Schwanz wird
nach den zu schützenden
Daten eingeführt.
Ein ESP-Paket wird im Protokollfeld des IP-Kopfs identifiziert.
Ein zu ESP-alternatives
Protokoll ist als "Authentication
Header" (AH, Authentifizierungskopf)
bekannt.
-
Um
IPSec-Paketen zu gestatten, korrekt eingekapselt und entkapselt
zu werden, ist es notwendig, Sicherheitsdienste und einen Schlüssel zwischen
einem Knoten, von dem der Verkehr übertragen wird und dem entfernten
Knoten, der der beabsichtigte Empfänger des Verkehrs ist, zu assoziieren. Das
für diesen
Zweck verwendete Konstrukt ist eine "Security Association" (SA, Sicherheits-Assoziierung). SA
werden zwischen Peerknoten unter Verwendung eines als "Internet Key Exchange" (IKE, Internet-Schlüsselaustausch)-Mechanismus
verhandelt und ihnen wird eine als "Security Parameter Index" (SPI, Sicherheitsparameter-Index)
bekannte Identifikation zugewiesen. Die geeignete SA wird dem empfangenden
Knoten durch Einschließen
des entsprechenden SPI in dem ESP-(oder AH)Kopf bekannt gemacht.
Details der existierenden SAs und der entsprechenden SPIs werden
in einer Sicherheits-Assoziierungs-Datenbank
(SAD) gehalten, die mit jedem IPSec-Knoten assoziiert ist. Solch ein IPSec-System
ist in WO99/67390 offenbart.
-
Die
genaue Weise, in der IPSec in einem System implementiert wird, hängt zu einem
großen Ausmaß von der
Sicherheitsstrategie der Organisation ab, die IPSec einzusetzen
wünscht.
Beispielsweise kann die Organisation Endpunkte (z. B. Anwender-Terminals)
spezifizieren, an die IP-Pakete gesendet werden können oder
von denen sie empfangen werden können,
die für
das Verschlüsseln
von Paketen zu verwendenden bestimmten Sicherheits-Level etc. Die
Strategie wird in einer Sicherheitsvorgehensweisen-Datenbank (SPD,
Security Policy Database) gespeichert, die mit jedem IPSec-Knoten assoziiert ist.
Typischerweise wird die SPD unter einer Mehrzahl von Entitäten des
IPSec-Knotens distributiert.
-
Zusammenfassung
der Erfindung
-
Im
Falle von zwischengeschalteten Netzwerkvorrichtungen, z. B. Routern,
gibt es einen Bedarf an Durchsatz eines hohen Verkehrsvolumens. Die
Implementation von IPSec in solchen Vorrichtungen sollte nicht in
irgendeiner ernsthaften Beeinträchtigung
der Durchsatzraten resultieren. Dies wird am Besten erzielt, indem
IPSec-Verkehr unter Verwendung einer Mehrzahl von IPSec-Prozessoren, die
parallel arbeiten, gehandhabt wird. Eine Parallelverarbeitung kann
auch vorteilhafterweise eingesetzt werden, um IPSec am Endknoten
zu handhaben.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung wird eine Netzwerkvorrichtung
zum Implementieren von IPSec bereitgestellt und umfasst:
zumindest
einen IP-Forwarder, der dafür
eingerichtet ist, IP-Pakete
zu empfangen, von denen jedes mit einer Sicherheits-Assoziierung (SA)
assoziiert ist, um die Destinationen der Pakete zu bestimmen und
die Pakete an ihre Destinationen weiterzuleiten;
eine Mehrzahl
von Sicherheitsprozedurmodulen, die mit dem/den IP-Forwarder(n)
gekoppelt und dafür eingerichtet
sind, Sicherheitsprozeduren für
empfangene Pakete parallel zu implementieren; und
eine Sicherheitssteuerung,
die dafür
eingerichtet ist, vermittelte SAs unter den Sicherheitsprozedurmodulen
zu allozieren und die Sicherheitsprozedurmodule und den/die IP-Forwarder von der
Allozierung zu unterrichten, wodurch der/die IP-Forwarder IP-Pakete an
das die assoziierte SA implementierende Sicherheitsmodulmodul senden
kann.
-
Ausführungsformen
der vorliegenden Erfindung stellen einen effizienten Mechanismus
zum parallelen Handhaben mehrerer SAs bereit, wie es etwa für einen
Hochdurchsatz-IP-Router nötig
ist. Der Mechanismus versucht, die an existierenden IPSec-Protokollen und Hardware
erforderlichen Modifikationen zu minimieren. Die Netzwerkvorrichtung,
in der die Erfindung eingesetzt werden kann, kann beispielsweise
eine zwischengeschaltete Netzwerkvorrichtung (z. B. ein Router)
oder ein Endknoten (z. B. ein Host) sein.
-
Bei
gewissen Ausführungsformen
der vorliegenden Erfindung werden die Sicherheitsprozedur-Module
miteinander gekoppelt, um das Weiterleiten eines IP-Pakets aus einem
Sicherheitsprozedur-Modul an ein anderes zu gestatten.
-
Vorzugsweise
ist der Sicherheits-Controller für
das Erzeugen und Modifizieren von IP-Paketfiltern im/in den IP-Forwarder(n) verantwortlich,
wobei die Filter für
das Routen von IP-Paketen an die Sicherheitsprozedur-Module verantwortlich
sind. Das Filtern von Paketen wird unter Verwendung einer oder mehrerer
Selektoren durchgeführt.
Bevorzugtererweise ist einer der Selektoren der Sicherheitsparameter-Index
(SPI), der eine SA identifiziert und der im Kopf (Header) der IP-Pakete
enthalten ist.
-
Vorzugsweise
ist der Sicherheits-Controller mit einem Internet-Schlüsselaustausch(IKE)-Modul gekoppelt,
das für
das Aushandeln von SAs mit Peer-IKE-Modulen verantwortlich ist.
Der Sicherheits-Controller ist dafür ausgelegt, von den IKE-Modulen Details von
vereinbarten SAs zu empfangen.
-
Es
wird erkannt werden, dass der/die IP-Forwarder, die Sicherheitsprozedur-Module
und/oder der Sicherheits-Controller
als Software oder als Hardware implementiert werden können, oder
in einer Kombination von Hardware und Software.
-
Gemäß einem
zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum
Verarbeiten von IP-Paketen in einer Netzwerkvorrichtung bereitgestellt,
wobei das Verfahren umfasst:
Allozierung von vermittelten SAs
unter einer Mehrzahl von Sicherheitsprozedurmodulen, die dafür eingerichtet
sind, Sicherheitsprozeduren für
empfangene IP-Pakete zu implementieren;
Unterrichten der Sicherheitsprozedurmodule
und zumindest eines IP-Forwarders von der Allozierung; und
Empfangen
von IP-Paketen an dem/den IP-Forwardern, Identifizieren der mit
den Paketen assoziierten SAs und Weiterleiten der Pakete an die,
die assoziierten SAs implementierenden Sicherheitsprozedurmodule.
-
Kurze Beschreibung
der Zeichnungen
-
1 illustriert
schematisch ein virtuelles privates Netzwerk (VPN), das ein Intranet
umfasst;
-
2 illustriert
schematisch die Architektur eines Routers des VPN von 1;
und
-
3 ist
ein Flussdiagramm, das ein Verfahren zum Verarbeiten von Paketen
am Router von 2 illustriert.
-
Detaillierte
Beschreibung einer bevorzugten Ausführungsform
-
Das
Verfahren, das nunmehr beschrieben wird, verwendet die in den nachfolgenden
Dokumenten beschriebenen Merkmale:
[IPSec] RFC 2401, Sicherheits-Architektur
für das
Internet-Protokoll,
November 1998; [REKEY] Internet Entwurf, IPSec-Wiederverschlüsselungs-Themen; [IKE] RFC
2409, der Internetschlüsselaustausch (IKE),
November 1998; [ISAKMP] RFC 2408, Internet Sicherheits-Assoziierungs-
und Schlüsselverwaltungs-Protokoll,
November 1998; [INTDOI] RFC 2407, die Internet-Sicherheits-Domäne der Interpretation
für ISAKMP,
November 1998. Für
ein vollständigeres
Verständnis des
Verfahrens sollte ein Bezug auf diese Dokumente genommen werden.
-
1 illustriert
ein typisches Szenario, bei dem IPSec verwendet werden kann. Ein
lokales Unternehmensbereichs-Netzwerk
(LAN) 1 ist über
einen Router/eine Firewall 2 mit dem Internet 3 verbunden. Entfernte
Hosts können
mit dem Router 2 über
das Internet 3 verbunden sein. Unter Verwendung von IPSec
zum Steuern der Kommunikation zwischen dem Router 2 und
den entfernten Hosts 4 (und damit zwischen den entfernten
Hosts 4 und lokalen Hosts 5) kann ein virtuelles
privates Netzwerk (VPN) etabliert werden. Jeder entfernte Host 4,
der wünscht,
am VPN teilzuhaben, muss zumindest ein Paar SAs (eine zum Senden
von Daten und eine zum Empfangen von Daten) mit dem Router 2 vor
dem Austauschen von anwender-erzeugtem Verkehr mit dem LAN 5 aushandeln.
Die Verhandlung wird unter Verwendung von IKE gemäß der in
einer vorgehensweisen Datenbank (PD) 6 definierten Sicherheitsvorgehensweise
(Nebenbemerkung: die PD kann tatsächlich unter den verschiedenen
IPSec-Entitäten
des Routers 2 verteilt sein) durchgeführt. Das Ergebnis ist, dass
für jeden
am VPN teilhabenden entfernten Host 4 der Router 2 einen
Satz von SAs seiner Sicherheits-Assoziierungs-Datenbank (SAD) 7 hält, die auch
eine distributierte Datenbank sein kann.
-
2 illustriert
die IPSec-Architektur, die vom Router 2 verwendet wird.
Jede der Komponenten dieser Architektur wird nunmehr nacheinander beschrieben.
-
MGMT
-
Ein
Management-Modul (MGMT) handhabt die Verteilung aller Management-Informationen.
Die Informationen beinhalten statische IP-Routen (1), manuelle
IPSec-SAs und IPSec-Vorgehensweisen (2),
IKE-Vorgehensweisen (3) und IP-Filterinformationen (4). Das
MGMT-Modul ist ein existierendes Modul, obwohl wahrscheinlich ist,
dass einige Änderungen notwendig
sind, um diese Ausführungsform
der Erfindung zu implementieren. Die Verteilung von IPSec-Vorgehensweisen
muss beispielsweise von dem früheren
IPFW/IPSec-Modulen zum neuen Sicherheits-Controller-Modul (siehe
unten) geändert
werden. Das Sicherheits-Controller-Modul kann auch andere Management-Informationen erfordern,
um seine Funktionalitäten
auszuführen.
-
IPRT
-
Ein
IP-Routing-Verfahren(IPRT)-Modul verwaltet alle IP-Routing-Informationen
im System. Dieses Modul verteilt die Routen an alle IP-Forwarder (IPFW)
und es empfängt
Routen entweder vom MGMT-Modul oder durch dynamische Routen-Protokolle (z. B.
RIP). Es sind keine Änderungen
an dem existierenden IPRT-Modul erforderlich.
-
IPFW
-
Ein
Satz von IP-Forwarder(IPFW)-Modulen entscheidet, wohin jedes individuelle
Paket innerhalb des Systems gesendet wird. Diese Module haben die Verantwortlichkeit
zur Passung je des Paketes gegen IP-Filter (siehe unten) zum Identifizieren
der lokalen Routing-Information für die Zielbestimmung der Pakete
und zum Weiterleiten der Pakete zu ihren Zielbestimmungen. Die Zielbestimmung
kann ein Interface-Prozess (z. B. LAN oder PPP), ein lokaler UDP/TCP/ICMP/etc.
Handhabungs-Prozess oder ein anderer IPFW sein.
-
Um
das IPFW-Modul so zu verbessern, dass es den hier beschriebenen
verteilten IPSec-Verarbeitungs-Mechanismus handhabt, müssen gewisse Änderungen
vorgenommen und Merkmale hinzugefügt werden. Ein IPFW-Modul muss
wissen, ob eine IPSec-Verarbeitung für ein Paket notwendig ist oder nicht.
Eine Weise zur Einführung
der IPSec-Handhabung im IPFW besteht in der Verwendung von IP-Filtern.
Das Sicherheits-Controller(SC)-Modul
führt daher
dynamisch spezielle IP- Filter
in die IPFW-Module ein. Diese Filter passen zu den "Selektoren" in den Paketen gemäß der IPSec-Vorgehensweise,
die ausgegeben wird. Der Filter weist auf den Sicherheits-Prozessor (SecProc),
die die IPSec-Verarbeitung für
ein Paket handhabt. Somit können
durch Vornehmen nur einer relativ geringen Modifikation am Filter-Mechanismus
in den IPFW-Modulen
alle Pakete, die eine IPSec-Verarbeitung erfordern, zu SecProcs
geroutet werden. Das SC-Modul aktualisiert die Filterdaten, so dass
die SecProc-Allozierung immer korrekt ist. Das SC-Modul weist stets
ein SecProc als das Standard-SecProc
das vom IPFW-Modul verwendet wird, Filtern zu. Falls es keine SAs
gibt, wird das Standard-SecProc zum Handhaben von Paketen verwendet
und es ist dann die Verantwortung von diesem SecProc, herauszufinden,
wie eine neue SA erzeugt wird.
-
Die
Filter in den IPFWs müssen
einen Sicherheitsparameter-Index
(SPI) als einen der Selektoren aufweisen. Mit SPI als Selektor können die
eingehenden IPSec-Pakete zu den richtigen SecProcs geroutet werden.
Alle eingehenden IPSec-Pakete (gerichtet an den Router selbst),
die nicht zum IPSec-Filter passen, können fallengelassen werden.
-
Es
wird erkannt werden, dass im hier beschriebenen Mechanismus ein
IPFW-Modul keinen Zugriff entweder auf die SAD oder SPD erfordert. Stattdessen
trifft es nur Entscheidungen basierend auf IP-Filtermechanismen.
Auf diese Weise können die Änderungen
am IPFW auf einem Minimum gehalten werden. Falls IPFW in Hardware
implementiert wird, sind die einzigen erforderlichen Änderungen:
- – die
Einführung
von IPSec-Selektoren im Filter-Mechanismus;
und
- – eine Änderung
beim Paket-Weiterleit-Pfad an den SecProc.
-
PPP/LAN
-
Vorrichtungsprozesse
wie PPP oder LAN versorgen die IPFW-Module mit Paketen. Auch empfangen sie
geroutete Pakete von den IPFW-Modulen. Die Vorrichtungsprozesse
müssen
keinerlei Kenntnisse über
IPSec aufweisen. Vorrichtungsprozesse erfordern keinerlei Änderungen,
um den hier beschriebenen Mechanismus zu implementieren.
-
IKE
-
Wie
aus der obigen Diskussion ersichtlich sein wird, sorgt das Internetschlüssel-Austausch(IKE)-Modul
für die
SA-Verhandlungen
mit anderen Knoten im VPN. Das IKE-Modul speichert IKE-Vorgehensweisen
und handelt IKE SAs gemäß diesen
Vorgehensweisen aus. Das IKE-Modul kommuniziert mit dem SC-Modul
unter Verwendung einer verbesserten PF_KEY v2-Schnittstelle (8). Das IKE-Modul
hat keine IPSec-Vorgehensweise,
macht aber Anfragen an das SC-Modul über IPSec-Verbindungen. Die
zwei Szenarien, in denen das IKE-Modul involviert
sein kann, sind ein erstes, in dem das IKE-Modul eine IPSec SA-Verhandlung initiiert
und ein zweites, in welchem das IKE-Modul auf eine Initiierungsanforderung
von einem Peer-IKE-Modul (eines anderen IPSec-Knotens) antwortet.
-
IKE-Modul als Initiator:
-
- 1) Das IKE-Modul empfängt IPSec-SA-Verhandlungsanforderungen
aus dem SC-Modul;
- 2) das IKE-Modul überprüft, ob die
Anforderung gemäß den verfügbaren IKE-Vorgehensweisen gestattet
ist;
- 3) das IKE-Modul handelt IPSec-SAs mit dem Überwachungs-IKE-Modul aus; und
- 4) das IKE-Modul gibt die sich ergebenden IPSec-SAs an das SC-Modul
zurück.
-
IKE-Modul als Responder:
-
- 1) das IKE-Modul empfängt Verhandlungsanforderungen
aus dem Überwachungs-IKE-Modul;
- 2) das IKE-Modul überprüft, ob die
Anfrage gemäß den verfügbaren IKE-Vorgehensweisen
gestattet ist;
- 3) das IKE-Modul fragt das SC-Modul, ob die vorgeschlagene IPSec-Verbindung
gemäß den verfügbaren IPSec-Vorgehensweisen gestattet
ist;
- 4) das IKE-Modul handelt mit dem Überwachungs-IKE-Modul IPSec-SAs
aus; und
- 5) das IKE-Modul gibt neue IPSec-SAs an das SC-Modul.
-
Der
IKE-Prozess mit dem Vorgehensweisen-Manager (PM) sollte keinerlei Änderungen
erfordern, außer
insoweit, als der PF_KEY verwendet wird für die Schnittstelle mit dem
SC, das heißt,
nicht IPFW/IPSec direkt.
-
SC
-
Das
Sicherheits-Controller(SC)-Modul handhabt die Verteilung von IPSec-SAs
an unterschiedliche SecProc-Module. Es speichert die IPSec-Vorgehensweisen
(2) und weiß,
in welchen SecProc-Modulen alle IPSec-SAs lokalisiert sind. Wenn
neue SAs erzeugt werden, wählt
das SC-Modul die SecProc-Module aus, in denen die SAs platziert
werden (10). Das SC-Modul installiert auch die folgenden Arten
von IP-Filtern in den IPFW-Modulen.
-
Die
Filter, welche IPSec-Vorgehensweise für ausgehende Pakete spezifizieren;
diese Filter wählen
die SecProcs aus, welche die IPSec-Verarbeitung handhaben. Diese
Filter werden installiert, wenn IPSec-Vorgehensweisen erzeugt werden.
Sie werden nur entfernt, falls IPSec-Vorgehensweisen entfernt werden
oder sich die Konfiguration so ändert,
dass das IPFW-Modul
sich nicht um Pakete kümmern muss,
welche zu den existierenden IPSec-Vorgehensweisen passen. Ein weiterer
Satz von Filtern wird verwendet, welcher zu ausgehenden IPSec-SAs passt.
Diese Filter gestatten es Paketen, innerhalb einer gegebenen SA
sortiert zu werden und dass vardefinierte Aktionen für die sortierten
Pakete ergriffen werden.
-
Die
Filter, die zu eingehenden IPSec-Paketen passen; jede der eingehenden
IPSec-SA erfordert Filter in jenen IPFW-Modulen, welche die IPSec-Pakete
mit der SA handhaben müssen
(ein gewisses spezifisches SPI-Zielbestimmungs-Adresspaar). Diese
Filter werden nur installiert, wenn die SAs erzeugt werden oder
wenn sich die Konfiguration so ändert,
dass das IPFW-Modul
keine Rücksicht auf
Pakete nehmen muss, welche zu den SAs passen, die gemäß existierenden
IPSec-Vorgehensweisen erzeugt sind.
-
Jedesmal,
wenn neue SAs erzeugt oder alte SAs gelöscht werden, muss das SC-Modul
Informationen in den IPFW-Modulen (9) aktualisieren. Genauer
gesagt, aktualisiert das SC-Modul IP-Filterinformationen, so dass
die Filter auf den SecProc weisen, welcher die SA besitzt, oder,
falls in dem Moment keine SA existiert, weisen die Filter auf die
Standard-SecProc.
-
Die
Prozedur, mit der der SC geeignete SecProc-Module auswählt, wird
durch einige Eigenschaften der SecProcs beeinflusst. Beispielsweise muss
das SC-Modul wissen, wieviel Last die SecProc-Module im System aufweisen.
Um die IPSec-Verarbeitung
so gleichmäßig wie
möglich
zwischen unterschiedlichen Prozessoren der Boards im System zu verteilen,
sollte das SC-Modul das SecProc-Modul auswählen, das zum Zeitpunkt der SA-Erzeugung
die geringste Last aufweist. Natürlich sollte
das SC-Modul verschiedene Strafen (Mehraufwandszuschläge) berücksichtigen,
die das System einführt,
wenn Pakete von Prozess zu Prozess gesendet werden. Falls beispielsweise
Pakete zwischen Prozessen gesendet werden, die auf unterschiedlichen
Karten lokalisiert werden, ist die Strafe viel höher als dann, wenn Pakete zwischen
Prozessen auf derselben Karte geschickt werden (natürlich abhängig von
der Gesamtsystem-Architektur).
-
Das
SC-Modul sollte in der Lage sein, SAs zu redistributieren, falls
sich die Systemlast drastisch ändert.
-
Auch
muss das SC-Modul auf die SPD für
IPSec-Vorgehensweisen zugreifen und die SAD für alle SAs. Das SC-Modul ist
ein vollständig
neues Modul in dieser Architektur.
-
SecProc
-
Die
SecProc-Module können
als die Hauptmodule bei der IPSec-Paket-Handhabung angesehen werden. Sie
erfordern einen Zugriff auf sowohl IPSec-SAD als auch SPD, da es
in der Verantwortung der SecProcs liegt, alle IPSec-Vorgehensweisen-Nachschlagungen zu
machen und Entscheidungen darüber
zu treffen, wie oder wer die IPSec-Verarbeitung vornehmen sollte.
-
Ein
SecProc-Modul ist ein Prozess, der die IPSec-verschlüsselung, Entschlüsselung
und Authentisierung tatsächlich
durchführt,
entweder unter Verwendung von Software oder einer dedizierten Hardware.
Es verfügt über Informationen über die SAs,
die es handhaben muss. Es speichert die SA und alle zur Verarbeitung
notwendigen Informationen, wie Sequenzanzahl-Zähler, Statistiken und welche
Algorithmen und Schlüssel
verwendet werden sollen.
-
Ein
SecProc-Modul muss auch wissen, welche SecProc-Module die anderen
SAs handhaben. Dies ist wichtig, falls SA-Bündel verwendet werden (siehe
unten). Es kann erforderlich sein, dass ein SecProc-Modul das Paket
an ein anderes SecProc-Modul (13) weiterleitet, das andere
SAs handhabt. Da das SecProc-Modul
Zugriff auf die IPSec-Vorgehensweise und SA-Informationen aufweist, kann dieses
Modul sehen, welches die SAs sind, die für eine gegebene Vorgehensweise
ausgeteilt werden müssen.
Das erste SecProc-Modul, das ein Paket verarbeitet, muss dem nächsten SecProc-Modul
mitteilen, was der Pfad für
das Paket ist (das nachfolgende SecProc-Modul und SAs, SA-SecProc-Paare).
Jedes SecProc-Modul entfernt dann seine eigenen Paare (wenn es das
Paket verarbeitet hat) und leitet das Paket an das nächste SecProc-Modul
weiter. Der Vorteil dieser Prozedur ist, dass das Nachschlagen der
Vorgehensweise nur einmal vorgenommen wird (vom ersten SecProc-Modul).
-
Unter
einigen Umständen
können
mehrere Level an Sicherheit auf IPSec-Pakete angewendet werden.
Dies führt
zu einem "Bündel" von SAs für eine gegebene
Kommunikation. Falls die gesamte IPSec-Verarbeitung nur unter Verwendung
von Software vorgenommen wird, ist es besser, jede SA in einem Bündel unter
Verwendung desselben SecProc-Moduls vorzunehmen. Somit wird eine
unnötige
Paketweiterleitung vermieden. Falls auf der anderen Seite dedizierte
Hardware verwendet wird, kann es Probleme beim Handhaben aller SAs
in einem SecProc-Modul geben. Falls beispielsweise ein SecProc-Modul
Hardware verwendet, die nur in der Lage ist, einige der im Bündel benötigten Algorithmen auszuführen, kann
das SecProc-Modul nicht verwendet werden, um das gesamte SA-Bündel zu
handhaben.
-
Es
kann weise sein, nur ein SecProc-Modul für alle SAs zu verwenden, die
eine spezifische Algorithmus-Kombination brauchen, die von einer
gewissen Hardware gehandhabt werden kann. Auf diese Weise kann die
Hardware am effizientesten verwendet werden.
-
Es
liegt in der Verantwortung des SC-Moduls, die korrekte SA-Verteilung über die SecProc-Module
zu bestimmen. Jedes SecProc-Modul muss beim SC-Modul registriert
werden. Während
des Registrierungs-Prozesses teilt das SecProc-Modul dem SC-Modul mit, zu was
es in der Lage ist (Algorithmen, Schlüssellängen, etc.).
-
Ein
SecProc-Modul empfängt
immer IP-Pakete entweder von einem anderen SecProc-Modul (das heißt im Falle
eines SA-Bündels
oder wo ein IPFW-Modul Pakete an das falsche SecProc-Modul gesendet
hat und dieses SecProc-Modul die Pakete an das korrekte SecProc-Modul
weiterleitet) oder von einem IPFW- Modul. Ein SecProc-Modul muss in der Lage
sein, die IP-Pakete an das korrekte IPFW-Modul (oder Vorrichtungs-Prozess,
PPP, LAN) nach IPSec-Verarbeitung weiterzuleiten. Ein SecProc-Modul kann ein Standard-IPFW-Modul
aufweisen, an das alle Pakete weitergeleitet werden. Das SC-Modul muss
dieses IPFW-Modul
einstellen, welches weiß, wie
das Paket weitergeleitet wird. Es ist auch möglich, dem SecProc-Modul zu
gestatten, die Weiterleitungsentscheidung selbst zu treffen (Routing-Tabellen). Dies ermöglicht es
dem SecProc-Modul die Pakete direkt an einen Vorrichtungs-Prozess
zu senden, falls dieser Prozess für das SecProc-Modul sichtbar
ist. Somit kann ein Weiterleitungsschritt vermieden werden.
-
Das
aktuelle kombinierte IPFW/IPSec-Modul wird in ein IPFW-Modul und ein IPSec-Modul,
das heißt
ein SecProc-Modul getrennt.
-
3 zeigt
ein Flussdiagramm, welches das Verfahren des Betriebs des IPSec-Routers
weiter illustriert.
-
Es
wird von Fachleuten erkannt werden, dass verschiedene Modifikationen
an den oben beschriebenen Ausführungsformen
vorgenommen werden können,
ohne vom Schutzumfang der vorliegenden Erfindung abzuweichen.