-
Die
Erfindung bezieht sich im Allgemeinen auf das Fragmentieren und
Wiederzusammensetzen von Datenpaketen und insbesondere auf das Fragmentieren
und Wiederzusammensetzen von Datenpaketen, die durch einen Protokollstapel,
der das Internet Key Exchange(„IKE")-Protokoll ausbildet,
erzeugt werden.
-
Informationen,
die über öffentliche
Netzwerke einschließlich
des Internets gesendet werden, enthalten oft vertrauliche und private
Daten. Von einer Person, die zum Beispiel Waren oder Dienste in
einer Online-Transaktion einkaufen möchte, kann gefordert werden,
Geld zu transferieren und/oder Daten von Kreditkarten oder Bankverbindung
an den Händler
zu liefern. Ferner können
autorisierte Sender und Empfänger
Daten, die vertraulich sind, wie etwa ein Dokument zur Unternehmensstrategie, über das
Internet senden wollen. Aus offensichtlichen Gründen stellen diese Informationen
eine Versuchung für
Kriminelle und andere Lauscher dar, die hoch motiviert sind, geheime
und/oder private Daten abzufangen.
-
Aufgrund
der Natur des Internets und anderer öffentlicher Netzwerke ist es
unmöglich
zu garantieren, dass nur der beabsichtigte Empfänger Zugriff auf die empfindlichen
Daten haben wird. Datenübertragungen
sind normalerweise nicht chiffriert oder verschlüsselt und Lauscher können leicht
Informationen abfangen, die nur für ausgewählte Personen oder eine Gruppe
von Personen bestimmt sind. Solange keine bestimmten Vorkehrungen
wie etwa die Chiffrierung der Daten getroffen werden, kann eine Person,
die das Internet oder irgendein öffentliches Netzwerk
als Übertragungsmedium
benutzt, empfindliche Informationen aufs Spiel setzen.
-
Um
dieses Risiko zu vermindern, chiffrieren viele Computernutzer die
Daten, die über
ein Netzwerk gesendet werden sollen, wodurch sie das Risiko vermindern,
dass ein nicht autorisierter Empfänger die Daten abfangen und
lesen kann. Die Chiffrierung wird üblicherweise durch den Einsatz
einer geeigneten mathematischen Funktion zum Abändern einer verständlichen
Reihe von Zahlen in eine Form, die nicht leicht entziffert werden
kann, bewerkstelligt. Die Dechiffrierung wird durch das Umkehren
des Prozesses durchgeführt.
Die Chiffrierung und die nachfolgende Dechiffrierung kann durch
den Einsatz eines Paares von „Schlüsseln" ausgeführt werden.
Die beiden Schlüssel
sind so miteinander verbunden, dass ein Vorgang – die Chiffrierung zum Beispiel – durch die
Verwen dung von einem Schlüssel
des Paares durchgeführt
wird, während
die entgegengesetzte Umwandlung nur mit dem anderen Schlüssel des Paares
berechnet werden kann. Nicht autorisierte Lauscher, die keinen Zugang
zum Schlüsselsatz
haben, der zum Chiffrieren und Dechiffrieren der Informationen verwendet
wird, werden es üblicherweise undurchführbar finden,
auf die vertraulichen Daten zuzugreifen. Der Austausch von Schlüsseln ist
auf diese Weise ein kritischer Teil beim Aufbau von sicheren Kommunikationen über ein
Datennetzwerk.
-
Die
Computer-Industrie im Allgemeinen und die IETF (Internet Engineering
Task Force) im Besonderen haben Sicherheitsstandards und Protokolle eingeführt, die
für die
Chiffrierung von Daten nutzbringend sind, wenn sie implementiert
sind. Darüber hinaus
hat die IETF eine Arbeitsgruppe IPsec (Internet Protcol Security)
eingesetzt, die eine Anzahl von Standards und Aufrufe zur Stellungnahme
(RFCs) veröffentlicht
hat. Die Dokumente liefern Details über vorgeschlagene und tatsächliche
realisierte Verschlüsselungsverfahren
im Industriestandard. Diese Arbeitsgruppe hat unter anderem „The Internet
Key Exchange (IKE)" von
D. Harkins und D. Carrel unter RFC-2409, November 1998 veröffentlicht.
-
Das
IKE-Protokoll wurde entworfen, um Vorlagen für eine beglaubigte Verschlüsselung
für Sicherheitsverbindungen
(„SAs") auszuhandeln und
zu liefern. Insbesondere ist das IKE-Protokoll neben anderen Dingen
für den
sicheren Austausch von Chiffrierschlüsseln zwischen zwei Computern
von Nutzen. Schlüssel,
die über
das IKE-Protokoll ausgetauscht werden, können zum nachfolgenden Chiffrieren
oder Dechiffrieren von Informationen, die zwischen Computern über ein öffentliches
oder privates Netzwerk gesendet werden, benutzt werden
-
Das
IKE-Protokoll beinhaltet eine hochstufige Semantik für Protokolle
zur Schlüsselverwaltung, die
im ISAKMP (Internet Security and Key Management Protocol, Protokoll
zur Sicherheit im Internet und zur Schlüsselverwaltung) und dem DOI
(Internet IP Security Domain of Interpretation, Arbeitsfeld zur Auslegung
der Internet-IP-Sicherheit) spezifiziert sind. Das IKE-Protokoll
wird üblicherweise
in einer hochstufigen Schicht einer Reihe von Stapeln der Netzwerkprotokolle
implementiert. Eine Anwendung innerhalb eines Netzwerkknotens ruft üblicherweise den
IKE-Protokoll-Stapel auf, der daraufhin eine Reihe von eindeutig
definierten Nachrichten erzeugt. Der Code, den das IKE-Protokoll,
d. h. der IKE-Protokoll-Stapel implementiert, ist darüber hinaus
für das Senden
von Nachrichten an einen beabsichtigten Empfängerknoten verantwortlich.
Der IKE-Protokoll- Stapel
implementiert jedoch nicht alle Vorgänge, die notwendig sind, um über ein
Netzwerk zu kommunizieren. Wie andere hochstufige Dienste und Anwendungen
stützt
sich der IKE-Protokoll-Stapel auf niederstufige Stapel, die Protokolle
wie das User Datagram Protocol (UDP, Anwender-Datagramm-Protokoll)
und das Internet Protocol (IP, Internet-Protokoll) implementieren, um die Netzwerkkommunikation
zu ermöglichen.
-
Sämtliche
Kommunikationen über
ein IP-Netzwerk werden durch die Übertragung und das Schalten
von Datenpaketen mit fester Größe durchgeführt. Abhängig vom
Netzwerk wird der IP-Protokollstapel ein Paket mit maximaler Länge senden, dessen
Länge als
maximale Übertragungseinheit (MTU;
Maximum Transmission Unit) bezeichnet wird. Die MTU kann für ein Netzwerk
oder für
eine Anwendung in einem Netzwerk spezifiziert werden. Einige IP-Netzwerke
und Anwendungen bieten eine Methode zum Erkennen oder expliziten
Bestimmen der MTU, z. B. liefern sie einen MTU-Wert als Antwort
auf eine Anfrage aus der sendenden Anwendung. Darüber hinaus
umfasst das IP-Protokoll selbst begrenzte Maßnahmen zum Bestimmen der MTU
für ein
vorgegebenes Netzwerk oder eine vorgegebene Anwendung, wobei die
Bestimmung als MTU-Ermittlung bekannt ist. Jedoch kann es nicht
immer möglich
sein, die MTU für
ein vorgegebenes Netzwerk oder eine vorgegebene Anwendung zu bestimmen.
Wenn die MTU bekannt oder ermittelt ist, und wenn die Daten, die
ein Anwender über
ein IP-Netzwerk zu senden versucht, die MTU für dieses Netzwerk oder diese Anwendung überschreiten,
wird der IP-Protokoll-Stapel
die Daten in kleinere Pakete umpacken, die die maßgebliche
MTU nicht überschreiten.
Der Schritt des Umpackens ist auch unter dem Begriff Fragmentierung
bekannt. Kleinere fragmentierte Datenpakete, die die maßgebliche
MTU nicht überschreiten,
werden dann über
das Netzwerk an den beabsichtigten Empfänger übertragen, wo sie in der Folge
wieder in die originalen Daten zusammengesetzt werden.
-
Wie
alle anderen Daten können
die Informationen, die in einem IKE-Paket enthalten sind und auch
als IKE-Nutzdaten bekannt sind, ab und zu die MTU für ein vorgegebenes
Netzwerk oder eine vorgegebene Anwendung überschreiten. Daher wird ein IP-Protokoll-Stapel, der in einer Übertragungsanwendung
mit freigegebenem IKE aktiv ist, die IKE-Nutzdaten in einer Größe fragmentieren,
die die MTU nicht überschreitet.
Allerdings setzt der IKE-Protokoll-Stapel kein DF-Flag (DF; Don't Fragment; nicht stückeln),
das als Teil einer IKE-Nachricht enthalten ist. Folglich erlaubt
das IKE-Protokoll jedem IP-Stapel, die IKE-Nutzdaten in geeigneter
Weise zu fragmentieren.
-
Darüber hinaus
kann es sein, dass ein lokaler IP-Stapel keine Kenntnis von der
kleinsten MTU auf einem Knoten oder einer Verknüpfung hat, die sich auf dem
Weg vom auslösenden
IKE-Knoten weg befindet. Daher können
die sich ergebenden Fragmente immer noch zu groß für bestimmte Netzwerke und Anwendungen
sein, obwohl der IP-Stapel des auslösenden IKE-Knotens die IKE-Nutzdaten
fragmentieren könnte.
Diese Gegebenheit kann noch eine zusätzliche Fragmentierung der
IKE-Nutzdaten verursachen.
-
Die
Fragmentierung der IKE-Nutzdaten mit bekannten Techniken wie etwa
denen, die vom IP-Stapel eingesetzt werden, wird IKE-Nachrichten
in einem Netzwerk nicht zuverlässig übertragen.
Das ist so, weil die gewöhnlichen
IKE-Nutzdaten nach dem UDP-Protokoll übertragen
werden, das fragmentierte IP-Pakete nicht verfolgt. Darüber hinaus
verfolgen auch viele Netzwerkkomponenten wie etwa die Netzwerk-Adressumsetzer
(NATs; Network Address Translators) nicht die IP-Fragmente. Daher
werden die gesamten IKE-Nutzdaten gefährdet, wenn ein beliebiges
Fragment der IKE-Nutzdaten verloren geht. Als Folge wird der empfangende
IKE-Partner nicht in der Lage sein, Nachrichten vom sendenden IKE-Partner
zu bestätigen
oder darauf zu antworten.
-
Es
gibt eine Vielzahl von Gründen
dafür, dass
ein vorgesehener IKE-Partner eine gesendete IKE-Nachricht nicht
empfangen kann. Zum Beispiel können
Probleme der Infrastruktur des Netzwerks zwischen den IKE-Partnern,
d. h. Kabelprobleme, Datenkollisionen, Software-Probleme usw. verursachen,
dass Pakete nach einem anscheinend zufälligen Muster verloren gehen.
Für diese
Arten von Kommunikationsproblemen ist es möglich, die verloren gegangenen
Pakete erneut zu senden und dadurch einen erfolgreichen Nachrichtenaustausch
zu erreichen. Als weiteres Beispiel können bestimmte Anwendungen
wie etwa die NATs systemische Probleme bei der Behandlung von IKE-Paketen
haben.
-
Das
ist deshalb der Fall, da ein IP-Fragment, das einem IKE-Paket zugeordnet
ist, möglicherweise nicht
ausreichend Informationen enthält,
um es der NAT zu erlauben, die Daten in geeigneter Weise zu formatieren
oder zu lenken. Viele IP-Fragmente werden normalerweise keine Informationen über Ports oder
Status aufweisen, die die NAT benötigt, um eine Adress- und Quellen-Umsetzung
durchzuführen.
Daher können
die IP-Fragmente
von bestimmten NATs routinemäßig fallen
gelassen werden.
-
Demzufolge
gibt es einen Bedarf für
ein verbessertes Verfahren und ein verbessertes System zur Behandlung
von Datenpaketen, die in Übereinstimmung
mit dem bestehen den IKE-Protokoll erzeugt werden. Genauer gesagt,
gibt es einen Bedarf für
ein System und ein Verfahren, um die IKE-Nutzdaten, die eine vorgegebene
MTU überschreiten,
in kleinere Pakete zu fragmentieren, die die MTU nicht überschreiten.
Die Fragmentierung von IKE-Nutzdaten sollte in einer solchen Weise
vorgenommen werden, dass IKE-Pakete
in einem empfangenden Knoten wieder zusammengesetzt werden können.
-
„Minutes
of IPSEC Working Group Meeting", Berichte
der 52. Internet-Technik-Projektgruppe
vom 9. bis 14. Dezember 2001 ist eine Arbeitsgruppe der KTEF, die
die Aufgabe hat, Mechanismen zu entwickeln, die das Client-Protokoll
von IP schützen.
Die IPSEC befasst sich mit einer Vielzahl von Sachverhalten, die
die Entwicklung eines Sicherheitsprotokolls in der Netzwerkschicht
betreffen, um kryptografische Sicherheitsdienste zu bieten, die
flexibel Kombinationen von Authentifizierung, Integrität, Zugangskontrolle
und Vertraulichkeit unterstützen,
was auch die Änderungen
für IKE
umfasst, um einen Durchlass in der Firewall für die Adressumsetzung im Netzwerk (NAT)
zu unterstützen.
Es wird unterstellt, dass das Prüfen
von IPSEC über
NAT einige Probleme aufdeckte, die auch die Fragmentierung von Zertifikaten umfassen.
Mögliche
Ansätze,
um die Fragmentierung zu vermeiden, wurden in Betracht gezogen einschließlich der
Fragmentierung von Paketen in einer Schicht des Netzwerk-Protokoll-Systems,
das oberhalb der Transportschicht, in der sich das UDP(User Datagram
Protocol)-Protokoll befindet, angeordnet ist.
-
Kent
C. A. et al.: „Fragmentation
Considered Harmful",
Computer Communication Review, Association for Computing Machinery,
New York, Vol. 25, Nr. 1 vom Januar 1995 richtet sich auf die Fragmentierung
im Zusammenhang mit dem IP-Protokoll. Das vorgeschlagene IP-Protokoll
erlaubt es einem Gateway, ein Paket zu fragmentieren, wenn es zu
groß ist, um übertragen
zu werden. In diesem Zusammenhang wird offen gelegt, dass die Vermeidung
der Fragmentierung in der richtigen Schicht durchgeführt werden
muss, was voraussetzt, dass der richtige Ort für die Vermeidung der Fragmentierung
die Schicht ist, die in allen IP-Kommunikationen üblich ist,
also die IP-Datagramm-Schicht selbst.
-
Harkins
D. et al.: „The
Internet Key Exchange (IKE) Protocol", Internet Draft, November 2001, beschreibt
Aspekte der Version 2 des Internet Key Exchange-Protokolls.
-
Es
ist das Ziel der vorliegenden Erfindung, ein Verfahren für entsprechende
Netzwerkknoten und Systeme zum Fragmentieren und Wiederzusammensetzen
der Datenpakete, die durch einen Protokoll-Stapel, der das Internet
Key Exchange-Protokoll anwendet, erzeugt werden.
-
Dieses
Ziel wird durch die Inhalte der Hauptansprüche erreicht.
-
Bevorzugte
Ausführungsformen
sind in den Unteransprüchen
definiert.
-
In Übereinstimmung
mit einem Beispiel, das für
das Verständnis
der Erfindung nützlich
ist, bieten das System und das Verfahren einen Mechanismus zum Fragmentieren
und Wiederzusammensetzen der Datenpakete und insbesondere zum Fragmentieren
und Wiederzusammensetzen von Datenpaketen, die durch einen Protokoll-Stapel
erzeugt werden, der das Internet Key Exchange-Protokoll („IKE") anwendet. Dem Beispiel
zufolge ist keine grundlegende Änderung
des IKE-Protokolls erforderlich, um die IKE-Nutzdaten zu fragmentieren und wieder
zusammenzusetzen. Stattdessen ermitteln das System und das Verfahren,
ob es für
den sendenden Knoten notwendig ist, ausgehende IKE-Datenpakete zu
fragmentieren, und ob der empfangende Knoten in der Lage ist, die
fragmentierten Pakete zu empfangen. Ferner fangen das System und
das Verfahren ausgehende IKE-Datenpakete am sendenden Knoten ab, wenn
die Größe derartiger
Pakete einen spezifizierten Schwellenwert überschreitet, und wenn der
empfangende Knoten in der Lage ist, die fragmentierten Pakete zu
empfangen. Die IKE-Pakete werden dann in kleinere Datenpakete fragmentiert,
die über
ein Netzwerk gesendet und am empfangenden Knoten empfangen werden.
Ein Modul innerhalb des empfangenden Knoten, das die fragmentierten
Pakete puffert und anschließend
die originalen IKE-Nutzdaten wieder zusammensetzt, vernichtet die
fragmentierten IKE-Pakete. Ferner umfassen das System und das Verfahren
der Erfindung zahlreiche Eigenschaften, die die Knoten im Netzwerk
vor verschiedenen Angriffen schützen.
-
Weitere
Eigenschaften und Vorzüge
der Erfindung werden aus der nachfolgenden detaillierten Beschreibung
von veranschaulichenden Ausführungsformen
ersichtlich, die mit Bezug auf die begleitenden Abbildungen einher
geht.
-
Kurze Beschreibung der Zeichnungen
-
Während die
beigefügten
Ansprüche
die Eigenschaften der vorliegenden Erfindung in besonderer Weise
darlegen, kann die Erfindung am besten aus der nachfolgenden de taillierten
Beschreibung, die in Verbindung mit den beigefügten Zeichnungen vorgenommen
wird, verstanden werden. Die Zeichnungen zeigen Folgendes:
-
1 zeigt
ein Blockdiagramm, das ein beispielhaftes Rechnernetzwerk darstellt.
-
2 zeigt
ein Blockdiagramm, das einen beispielhaften Rechner darstellt.
-
3 zeigt
ein Blockdiagramm, das beispielhafte Hard- und Software-Komponenten,
die einen Computer in die Lage versetzt, sich mit einem anderen
zu verbinden, darstellt.
-
4 ist
eine Darstellung von Nachrichten, die zwischen zwei verbundenen
Computern nach dem IKE-Protokoll ausgetauscht werden können.
-
5 zeigt
ein Blockdiagramm einer bevorzugten Ausführungsform des Fragmentierers/Reassemblers,
wie er nach der vorliegenden Erfindung aufgebaut ist.
-
6 zeigt
ein beispielhaftes Datenpaket, das nach dem IKE-Protokoll ausgetauscht
werden kann.
-
7 zeigt
ein beispielhaftes IKE-Datenpaket, wie es durch eine bevorzugte
Ausführungsform des
Fragmentierers/Reassemblers modifiziert wird, der nach der vorliegenden
Erfindung aufgebaut ist.
-
8 zeigt
ein Flussdiagramm, das bestimmte bevorzugte Schritte zum Fragmentieren
und Senden eines Datenpaketes darstellt, das nach dem IKE-Protokoll
aufgebaut worden ist, und
-
9 zeigt
ein Flussdiagramm, das bestimmte bevorzugte Schritte zum Empfangen
und Wiederzusammensetzen eines IKE-Datenpaketes darstellt, das fragmentiert
worden ist.
-
Detaillierte Beschreibung
der Erfindung
-
Die
vorliegende Erfindung kann aufgebaut werden, indem kodierte Module
programmiert werden, die auf einem Computer ausgeführt werden.
Im Allgemeinen umfassen Programmmodule Routinen, Objekte, Komponenten,
Datenstrukturen und Ähnliches,
die bestimmte Aufgaben durchführen
oder bestimmte abstrakte Datentypen aufbauen. Die Begriffe „Programm" und „Modul", wie sie hier verwendet
werden, können
ein einzelnes Programmmodul oder mehrfache Programmmodule, die zusammenarbeiten,
bedeuten. Die Erfindung kann auf einer Vielzahl von Computertypen
implementiert werden, was Personalcomputer (PCs), Telefone, Hand-Held-Geräte, Multiprozessorsysteme,
Mikroprozessor-basierte programmierbare Unterhaltungs- und Haushaltselektronik,
Netzwerk-PCs, Minicomputer,
Großrechner und Ähnliches
umfasst. Die Erfindung kann auch in schmal dimensionierten Clients
und verteilten Rechnerumgebungen eingesetzt werden, in denen Aufgaben
durch Fernverarbeitungseinrichtungen durchgeführt werden, die über ein
Kommunikationsnetzwerk verknüpft
sind. In einer verteilten Rechnerumgebung können die Module sowohl auf
lokalen als auch entfernt vorhandenen Speichergeräten vorliegen.
-
Es
wird nun mit Bezug auf die 1 ein Beispiel
einer Netzwerkumgebung beschrieben, in der die Erfindung angewendet
werden kann. Das Beispiel-Netzwerk umfasst verschiedene Computer 100, die
untereinander über
ein Netzwerk 102 kommunizieren, das durch eine Wolke dargestellt
ist. Das Netzwerk 102 kann zahlreiche gut bekannte Komponenten
enthalten wie etwa Router, Gateways, Hubs usw. und kann den Computern 100 ermöglichen, über Kabel-
und/oder Funkmedien zu kommunizieren.
-
Mit
Bezug auf die 2 wird ein Beispiel für eine Basis-Konfiguration
eines Computers 100 dargestellt, auf dem das hier beschriebene
System implementiert werden kann. In der Grundausstattung der Konfiguration
umfasst der Computer 100 üblicherweise mindestens eine
Prozessoreinheit 112 und einen Speicher 114. In
Abhängigkeit
von der genauen Konfiguration und vom Typ des Computers 100 kann der
Speicher 114 flüchtig
(wie etwa RAM), nicht-flüchtig
(wie etwa ROM oder Flashspeicher) oder irgendeine Kombination aus
beiden sein. Diese Grundausstattung der Konfiguration wird in 2 durch
die Linie 106 veranschaulicht. Darüber hinaus kann der Computer
zusätzliche
Eigenschaften/Funktionen enthalten. Zum Beispiel kann der Computer 100 auch
einen zusätzlichen
Speicher (auswechselbar und/oder nicht-auswechselbar) besitzen,
der magnetische oder optische Disks oder Bänder einschließt, jedoch
nicht darauf beschränkt
ist. Die Speichermedien des Computers umfassen die flüchtigen und
nichtflüchtigen,
auswechselbaren und nicht-auswechselbaren Medien, die mittels einer
beliebigen Methode oder Technik zur Speicherung von Informationen
wie etwa computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen
oder anderen Daten implementiert sind. Die Speichermedien des Computers
umfassen, sind jedoch nicht darauf beschränkt, RAM, ROM, EEPROM, Flashspeicher
oder eine andere Speichertechnologie, CD-ROM, DVD (digital versatile
disk) oder andere optische Speicher, Magnetkasset ten, Magnetband,
Magnetplattenspeicher oder andere Magnetspeichergeräte oder
jedes andere Medium, das zum Speichern der gewünschten Informationen verwendet
werden kann und auf das vom Computer 100 zugegriffen werden
kann. Jedes derartige Speichermedium kann Teil des Computers 100 sein.
-
Der
Computer 100 kann auch Kommunikationsverbindungen enthalten,
die es dem Gerät
auch erlauben, mit anderen Geräten
zu kommunizieren. Eine Kommunikationsverbindung ist ein Beispiel
für ein
Kommunikationsmedium. Kommunikationsmedien enthalten üblicherweise
computer-lesbare Anweisungen, Datenstrukturen, Programmmodule oder
andere Daten in Form von modulierten Datensignalen wie etwa in einer
Trägerwelle
oder anderen Transportmechanismen und umfasst jegliches Informationsübergabemedium.
Zum Beispiel – und
nicht zur Einschränkung – umfassen
Kommunikationsmedien verkabelte Medien wie ein Kabelnetzwerk oder
eine Direktverbindung über
Kabel und drahtlose Medien wie etwa Schall, Funk (RF), Infrarot
und andere drahtlose Medien. Der Begriff der computer-lesbaren Medien,
wie er hier verwendet wird, umfasst sowohl Speicher- als auch Kommunikationsmedien.
-
Der
Computer 100 kann auch Eingabegeräte wie eine Tastatur, eine
Maus, einen Stift, eine Spracheingabeeinrichtung, ein Kontakteingabegerät etc. besitzen.
Ausgabegeräte
wie etwa ein Bildschirm 116, Lautsprecher, ein Drucker
etc. können
ebenfalls enthalten sein. Alle diese Geräte sind allgemein bekannt und
brauchen hier nicht ausführlich
erläutert
zu werden.
-
3 zeigt
die logischen Geräte,
Anwendungen und Programmier-Codemodule, gemeinsam gekennzeichnet
durch das Bezugszeichen 120, die den Computer 100 in
die Lage versetzen, über
ein Netzwerk zu kommunizieren. Diese Abbildung veranschaulicht neben
anderen Dingen eine beispielhafte Folge von Protokoll-Stapeln, die
mit den Bezugszeichen 122 bis 126 gekennzeichnet
sind. Die physischen/Hardware-Komponenten 121, die in 3 dargestellt
sind, können
zum Bespiel eine Netzwerk-Schnittstellenkarte (NIC) und verschiedene
Gerätetreiber
für die
Hardware-Komponenten umfassen. Über
der physischen und Hardware-Schicht liegt der Netzwerk-IP-Stapel 122,
der das Internetprotokoll (IP) einrichtet. Der IP-Stapel 122 baut
das Adressierprotokoll auf, das so ausgelegt ist, dass es den Verkehr
innerhalb eines Netzwerks oder zwischen Netzwerken zu steuert.
-
Über dem
IP-Stapel 122 befinden sich verschiedene zusätzliche
Protokoll-Stapel die einen TCP-Stapel 123 (Transmission
Control Protocol), einen UDP-Stapel 124 (User Datagram
Protocol) und einen ICMP-Stapel 125 (Internet Control Message Protocol)
umfassen. Der TCP-Stapel 123 liefert den Code zum Aufbau
eines verbindungsorientierten, zwischen Endpunkten abgesicherten
Protokolls. Ferner sichert der TCP-Stapel 123 eine zuverlässige Interprozesskommunikation
zwischen den Netzwerkgeräten.
Der UDP-Stapel 124 liefert
den Code zum Aufbau eines verbindungslosen Modus der Kommunikation
mit Datagrammen in einer in sich zusammenhängenden Gruppe von Rechnernetzwerken. Das
UDP-Protokoll garantiert nicht die Auslieferung von Paketen oder
dass Datenpakete nicht doppelt gesendet werden. Schließlich umfasst
der ICMP-Stapel 125 den Code, der für die Steuerung des Internet-Protokolls
notwendig ist. Die Hauptfunktionen des ICMP-Stapels 125 umfassen
das Berichten von Fehlern, die Benachrichtigung über Wegeänderungen, die Durchführung, die
Teilnetz-Adressierung und andere Verwaltungsfunktionen. Obwohl die Komponenten 122–125 als
ein Teil der bevorzugten Ausführungsform
dargestellt werden, ist keines davon unbedingt erforderlich, um
die Erfindung zu implementieren. Es können Alternativen zu diesen
Protokoll-Stapeln eingesetzt werden, entweder gesondert oder in
Verbindung mit verschiedenen der vorgenannten Protokoll-Stapel,
um eine Netzwerkverbindung zwischen Knoten in einem Netzwerk auszubilden.
Es könnten
auch mehr oder weniger Protokolle eingesetzt werden.
-
Die
Anwendung und die Dienste auf hoher Ebene umfassen die höchste Schicht 126.
Dort befinden sich die Anwendungsprogramme, die die gewünschte Funktionalität für ein Netzwerkgerät ausführen sollen.
Die Anwendungsprogramme des Computers 100 umfassen zum
Beispiel Programme zur Druckanwendung. Dort befindet sich auch der IKE-Protokoll-Stapel 127.
Der IKE-Protokoll-Stapel 127 erlaubt den sicheren Austausch
von Chiffrierschlüsseln
zwischen zwei Computern. Die Schlüssel, die über den IKE-Protokoll-Stapel 127 ausgetauscht werden,
können
dazu verwendet werden, anschließend
Informationen, die zwischen Computern über ein öffentliches oder privates Netzwerk übertragen werden,
zu chiffrieren. Eine Anwendung, die versucht, eine Sicherheitsverbindung
(SA) aufzubauen, kann den IKE-Protokoll-Stapel 127 aufrufen,
um den Prozess des Schlüsselaustausches
und anderer verbundener Informationen zu starten.
-
IPsec
hat verschiedene Dokumente veröffentlicht,
die Details zum Einrichten einer SA zwischen Knoten bieten. Eines
dieser Dokumente ist „Security
Architecture for the Internet Protocol" von S. Kent und R. Atkinson, RFC-2401
vom November 1998. Ausgehend von einem Zustand, in dem keine Verbindung
zwischen zwei Netzwerkknoten besteht, kann eine SA so aufgebaut
werden, dass jeder Endpunkt der Sicherheit der Verbindung vertraut
und die Identität
eines jeden Knotens dem anderen bestätigt wird. IPsec definiert
besonders zwei Sicherheitsdienste, die beide einen zugehörigen Header
besitzen, der einem IP-Paket, das es beschützt, hinzugefügt wird:
ein Authentifikations-Header („AH") und ein ESP-Header
(Encapsulating Security Payload; gekapselte Sicherheits-Nutzdaten). Das Dokument
der IPsec „IP
Authentication Header" von
S. Kent und R. Atkinson, RFC-2402 vom November 1998, beschreibt
den AH-Header. Das Dokument der IPsec „IP Encapsulating Security
Payload (ESP)" von
S. Kent und R. Atkinson, RFC-2406
vom November 1998, beschreibt den ESP-Header.
-
IPsec-Protokolle
errichten und verwenden eine SA, um eine sichere virtuelle Verbindung
zwischen zwei Endpunkten zu identifizieren. Eine SA ist eine unidirektionale
Verbindung zwischen zwei Endpunkten, die eine einzelne IPsec-Protokollmodus-Verknüpfung darstellt.
Zwei Anschlussendpunkte, d. h. Netzwerkgeräte, einer einzelnen SA definieren
eine sichere virtuelle Verbindung, die durch IPsec-Dienste geschützt wird.
Einer der Endpunkte sendet die IP-Pakete und der andere Endpunkt
empfängt
sie. Da eine SA unidirektional ist, sind mindestens zwei SAs für eine sichere
bidirektionale Kommunikation erforderlich. Es ist auch möglich, mehrfache Schichten
von IPsec-Protokollen zwischen zwei Endpunkten einzurichten, indem
mehrfache SAs zusammengefasst werden.
-
Der
Prozess der Einrichtung einer IPsec-SA ist sowohl mit dem Verhandeln
als auch mit dem Authentisieren verbunden. Die Verhandlung resultiert
in einer Vereinbarung zwischen zwei Endpunkten darüber, welches
Sicherheitsprotokoll und welcher Modus eingesetzt werden sollen,
wie auch welche spezifizierte Chiffrierverfahren und damit verbundene
Parameter verwendet werden sollen. Die Authentifikation stellt sicher,
dass jeder Endpunkt der Identität
des anderen Endpunktes während
der Verhandlung vertrauen kann, und ab dann ist die SA eingerichtet.
-
Das
IKE-Protokoll ist als ein Standard zur Einrichtung von SAs vorgeschlagen
worden. Wie oben angemerkt, befolgt das IKE-Protokoll die Semantik
der ISAKMP, die in „Internet
Security Association and Key Management Protocol" von D. Maughan, M. Schertler, M. Schneider
und J. Turner, RFC-2408 vom November 1998 beschrieben ist. Das Aushandeln
der SA wird als eine Folge von Nachrichten, die zwischen Knoten
in einem Netzwerk ausgetauscht werden, ausgeführt.
-
4 veranschaulicht
einen typischen Satz von Nachrichten, die gemäß den ISAKMP- und den IKE-Protokollen
ausgetauscht werden. Die Netzwerkknoten sind in 4 als
ein Urheberknoten 131 und ein Antworterknoten 132 gekennzeichnet.
In der ersten Folge von Nachrichten, mit dem Bezugszeichen 134 gekennzeichnet,
schlägt
der Urheberknoten 131 in der Nachricht 135a ein
Sicherheitsprotokoll und einen Chiffrieralgorithmus vor. Die Nachricht 135 umfasst
einen IKE-Header, mit HDR bezeichnet, und die Daten, die einer dazugehörigen SA-Nachricht entsprechen.
Der Antwortende sendet eine Antwortnachricht 136, die den
Akzept oder einen Gegenvorschlag zur ersten Nachricht 135 anzeigt.
Die Antwortnachricht umfasst ebenfalls einen IKE-Header, mit HDR
bezeichnet, und die Daten, die seiner Antwort-SA-Nachricht entsprechen.
Sobald die erste Gruppe von Nachrichten vollständig ist, haben sowohl der
Urheberknoten 131 als auch der Antworterknoten 132 den
ausgehandelten Details zugestimmt.
-
Das
nächste
Nachrichtenpaar, das mit dem Bezugszeichen 138 gekennzeichnet
ist, umfasst den Schlüsselaustausch.
Der Urheberknoten 131 sendet zuerst die Nachricht 139,
die einen IKE-Header, die Schlüsseltausch-Nutzdaten
und Einmal-Zufallszahlen enthält.
Der Antworterknoten 132 liefert ganz von selbst eine Nachricht 140,
die ebenfalls Schlüsselaustausch-Nutzdaten
und Einmal-Zufallszahlen enthält.
Aus diesen Informationen kann ein exklusiv geteiltes Geheimnis abgeleitet
werden, das zur Erzeugung von Schlüsseln und einer zukünftigen Schlüsselverwaltung
führt.
-
Das
letzte Nachrichtenpaar
142 enthält wieder eine Nachricht
142 vom
Urheberknoten
131 und eine Antwortnachricht
144 vom
Antworterknoten
132. Das letzte Nachrichtenpaar liefert
eine Identifikation der kommunizierenden Knoten. Deshalb enthält die Nachricht
143 des
Urheberknotens einen IKE-Header und die ID-Nutzdaten des Urhebers.
Die Nachricht
144 des Antworterknotens wiederum enthält wieder
einen IKE-Header und die ID-Nutzdaten des Urhebers. Mehr Details
zu den möglichen
Nachrichten, die zwischen entsprechenden Knoten ausgetauscht werden
können,
sind in der oben genannten RFC-Dokumentation
von Harkins und in „An
Architecture for the Internet Key Exchange Protocol" von P. C. Cheng,
IBM System Journal, Vol. 40, Nr. 3, 2001, enthalten. Darüber hinaus
sind die verschiedenen IPsec-Protokolle, SA-Nachrichten und Ähnliches in
dem
U.S.-Patent 6.055.236 von
Nessett et al. weiterführend
diskutiert.
-
Die
Nachrichten, die nach dem IKE-Protokoll gesendet werden, sind sowohl
im Inhalt als auch in der Datenlänge
variabel. Abhängig
von den Ergebnissen der Verhandlung, die im ersten Paar der IKE-Protokoll-Nachrichten 134 stattfindet,
können
die nachfolgenden Nachrichten variieren. Darüber hinaus kann die Länge der
Zertifizierungsketten, die als Teil der IKE-ID-Nachrichten 142 ausgetauscht
werden, in Abhängigkeit
von der Zertifizirungsautorität und
andere Faktoren, die nicht unter dem Einfluss des Urheber- und des
Antworterknoten stehen, variieren. Demzufolge ist es möglich, dass
die Nachrichten eine maximale Übertragungseinheit
(MTU) überschreiten.
-
Nach
bekannten Techniken wird der lokale IP-Protokoll-Stapel die IKE-Nutzdaten
in eine Größe fragmentieren,
die nicht die MTU überschreitet.
Darüber
hinaus werden andere Router und Netzwerkgeräte auf der Übertragungsstrecke hinter dem
sendenden Knoten die IKE-Nutzdaten noch weiter fragmentieren. Das
wird kein Problem verursachen, wenn alle Fragmente erfolgreich übertragen
werden. Wenn jedoch irgendeines der Fragmente der IKE-Nutzdaten verloren
geht, werden weder der Urheber- noch der Antworterknoten eine Methode
besitzen, das verlorene Fragment zu verfolgen. Als Folge davon wird
ein IKE-Partner nicht in der Lage sein, Nachrichten von einem anderen
IKE-Partner zu bewerten oder darauf zu antworten. Das stellt besonders
ein Problem für Geräte wie etwa
bestimmte NATs dar, die ein systemisches Problem bei der Bearbeitung
von IKE-Paketen
haben können.
Ein IKE-Fragment, das nach bekannten Techniken aufbereitet ist,
kann möglicherweise
nicht genügend
Informationen enthalten, die es einem NAT ermöglichen, dieses oder andere
zugehörige
Fragmente in geeigneter Weise weiterzuleiten.
-
Das
System und das Verfahren der Erfindung lösen dieses Problem dadurch,
indem sie erfassen, ob der Antworterknoten die ausgehenden IKE-Nutzdaten
empfängt.
Wenn nicht, kann der Code, der die Erfindung implementiert, die
erneute Übertragung
mindestens ein weiteres Mal veranlassen. Dieser Aspekt der Erfindung
behandelt den Fall der zufälligen
und sporadischen Übertragungsschwierigkeiten
und verhindert eine unnötige
Fragmentierung der Datenpakete. Wenn es scheint, als ob das erneut übertragene
Paket immer noch nicht vom Antworterknoten empfangen worden ist,
dann wird die Erfindung die IKE-Nutzdaten in Einheiten kleinerer
Größe fragmentieren,
die dann erfolgreich über
das Netzwerk gesendet werden können.
-
5 veranschaulicht
die logische Beziehung zwischen den Codemodulen, die eine bevorzugte
Ausführungsform
der Erfindung implementieren. Die Abbildung gibt die Schicht der
Anwendungen und hochstufigen Dienste 126 der Netzwerkumgebung
wieder, die in 3 in allgemeiner Form dargestellt
ist. Zusätzlich
zum IKE-Protokoll-Stapel 127 umfasst die 5 jedoch
ein Codemodul zum Fragmentieren/Wiederzusammensetzen 150 (hier
im Weiteren „Fragmentierer 150" genannt), das in
der Anwendungsschicht 126 residiert, jedoch logisch unter
dem IKE-Protokoll-Stapel 127 angeordnet ist. In einer Umgebung,
die eine IKE-Fragmentierung unterstützt, wird ein Fragmentierer 150 sowohl
auf dem Urheberknoten als auch auf dem Antworterknoten vorhanden
sein.
-
Der
Fragmentierer 150 fragmentiert die IKE-Datenpakete durch
ein Sendemodul 151 und setzt die IKE-Datenpakete durch
ein Empfangsmodul 152 wieder zusammen. Darüber hinaus
enthält
der Fragmentierer 150 die Logik, dass es notwendig ist, festzustellen,
ob die IKE-Datenpakete am Antworterknoten empfangen worden sind
und erforderlichenfalls eine erneute Übertragung der IKE-Nutzdaten
zu veranlassen. Deshalb führt
der Fragmentierer 150 über
die Fragmentierung oder das Wiederzusammensetzen der Pakete hinaus
viele Funktionen aus und die umschreibende Bezeichnung für dieses
Modul sollte nicht in einer einschränkenden Art und Weise interpretiert
werden.
-
Die
Platzierung des Fragmentierers 150 in der Nähe des IKE-Protokoll-Stapels
stellt sicher, dass wenig oder keine Änderungen am IKE-Protokoll erforderlich
sind, um die Erfindung zu implementieren. Dies kann besonders dann
von Vorteil sein, da die Erfindung kompatibel zu bereits bestehenden
Implementierungen ist. Darüber
hinausliefert die Anordnung des Codes der Erfindung in der Nähe des IKE-Protokoll-Stapels
eine sofort einsetzbare Lösung für das Problem
der verloren gegangenen IKE-Fragmente. Und schliesslich wird dadurch,
dass die Zustandsmaschine des IKE-Protokolls nicht abgewandelt wird,
die zugrunde liegende Sicherheit des IKE-Protokolls nicht gefährdet.
-
Im
Betrieb fängt
der Fragmentierer 150 die ausgehenden IKE-Pakete auf dem
einen Knoten und ebenfalls die eingehenden IKE-Pakete auf dem anderen
Knoten ab. Wenn es notwendig ist, werden die abgefangenen Pakete
an dem einen Ende fragmentiert und am anderen Ende wieder zusammengesetzt.
Jeder Vorgang, der vorgenommen werden muss, um die Fragmentierung
oder das Wiederzusammensetzen von IKE-Nutzdaten zu erreichen, ist deshalb
für den
IKE-Protokoll-Stapel erkennbar.
-
6 veranschaulicht
ein IKE-ID-Paket 160, das zum Beispiel der Nachricht 143 in 4 entspricht.
Das Paket umfasst einen IKE-Header 161, der neben anderen
Dingen ein Flag zum Kennzeichnen, ob die Daten im Nutzbereich verschlüsselt wurden,
enthält.
Ferner enthält
es Informationen, das das nächste
IKE-Paket identifizieren. Darüber
hinaus umfasst das IKE-Paket die aktuellen Daten, die die ID-Nutzdaten
enthalten. Neben anderen Dingen enthalten diese Daten auch die Zertifizierungskette,
die erforderlich ist, um eine SA aufzubauen und zu unterhalten.
-
7 zeigt
die gleichen Daten wie in 6, jedoch
fragmentiert durch den Fragmentierer 150. In einer Weise,
die nachfolgend ausführlicher
beschrieben wird, kann der Fragmentierer 150 eine einzelne Nachricht,
die die MTU überschreitet,
in eine Vielzahl von kleineren Nachrichten umwandeln. Ferner fügt er jeder
kleineren Nachricht, die nur einen Bruchteil der originalen IKE-Nutzdaten
enthält,
einen IKE-Header hinzu. Die Sammlung von Paketen, die in 7 dargestellt
sind, umfasst alle Daten 162, die in den originalen IKE-ID-Nutzdaten
enthalten sind. Darüber
hinaus enthält
das erste Fragment 171 den originalen IKE-Header 161.
Daher behält
der Fragmentierer 150 alle originalen Daten bei, die vom
IKE-Protokoll-Stapel 127 bereitgestellt wurden. Er schneidet den
Datenteil der IKE-Nutzdaten ab, inbesondere, jedoch nicht ausschließlich, für die IKE-ID-Nutzdaten, und verkapselt
dann die Daten innerhalb eines neuen kleineren Pakets, dessen Länge eine
gewählte
MTU nicht überschreitet.
Andere Pakete enthalten den Rest der abgeschnittenen Daten.
-
8 zeigt
die logische Abfolge des Codemoduls, das den Fragmentierer 150 implementiert. Er
versteht sich von selbst, dass dieses Flussdiagramm für eine bevorzugte
Ausführungsform
vorgesehen ist und nicht vollständig
alle möglichen Änderungen
berücksichtigt,
die für
einen Kenner der Technik erkennbar wären. Weiterhin versteht es
sich von selbst, dass die in 8 gezeigte
Logik zumeist auf das Sendemodul 151 innerhalb des Fragmentierers 150 ausgerichtet
ist, obwohl das Empfangsmodul 152 bestimmte Schritte ausführen kann.
-
Beginnend
bei Schritt 181 in 8 wird der Urheberknoten
einer IKE-Anwendung, die mit einem Antworterknoten eine SA aufbauen
möchte,
eine IKE-Nachricht senden. Diese Nachricht kann eine der Nachrichten,
die in 4 dargestellt sind, sein oder irgendeine Nachricht
aus dem IKE-Protokoll-Stapel. Der Fragmentierer 150 überwacht
in Schritt 182 die Nachricht und ermittelt nach einer angemessenen
Zeit, ob eine zutreffende Antwort empfangen worden ist.
-
Wenn
eine passende Antwort empfangen wurde, wird der Fragmentierer 150 dem
Prozess einfach erlauben, in Schritt 183 nach dem normalen IKE-Protokoll
weiterzumachen. Entsprechend dieser Logik wird keine Fragmentierung
erfolgen, wenn die IKE-Nutzdaten erfolgreich übertragen wurden.
-
Wenn
eine passende Antwort in Schritt 182 jedoch nicht empfangen
wird, wird der Fragmentierer 150 in Schritt 184 die
zugehörigen
IKE-Nutzdaten erneut senden. Dieser Schritt, der mehr als ein Mal
wiederholt werden kann, wird durchgeführt, um der Situation zu entsprechen,
in der die Größe der IKE-Nutzdaten
kein Kommunikationsproblem verursacht hat. Zum Beispiel können die
IKE-Nutzdaten wegen einer zeitweiligen Fehlfunktion eines Geräts versehentlich verloren
gehen, in welchem Fall eine Fragmentierung nach der vorliegenden
Erfindung nicht erforderlich wird. Bei der ersten erneuten Übertragung
der originalen IKE-Nutzdaten erkennt der Fragmentierer 150, ob
es möglich
ist, eine passende Antwort ohne eine Fragmentierung der originalen
IKE-Nutzdaten zu empfangen. Die gestrichelte Linie, die den Schritt 185 mit
dem Schritt 184 verbindet, kennzeichnet, dass das Sendemodul 151 versuchen
kann, die IKE-Nutzdaten zum Beispiel drei oder vier Mal erneut zu
senden, bevor es mit dem Schritt 186 weitergeht. Dieser Schritt
spart so die Bandbreite im Netzwerk ein und stellt darüber hinaus
sicher, dass der IKE-Fragmentierer nicht unnötig aufgerufen zu werden braucht. Wenn
nach der erneuten Übertragung
eine passende Antwort empfangen wird, erlaubt der Fragmentierer 150 in
Schritt 185 dem IKE-Protokoll-Stapel wieder, ohne eine
weitere Fragmentierung mit Schritt 183 fortzufahren.
-
Wenn
der Fragmentierer 150 in Schritt 185 nach einem
oder mehreren Versuchen, die originalen IKE-Nutzdaten erneut zu
senden, noch immer keine passende Antwort empfängt, wird er ermitteln, dass die
IKE-Nutzdaten für
dieses bestimmte Netzwerk oder die bestimmte Anwendung die MTU überschreiten.
In diesem Fall wird das Sendemodul 151 entweder den Fragmentierungsprozess
beginnen oder es wird den IKE-Protokoll-Stapel des Urheberknotens veranlassen,
den Prozess zum Aufbauen einer SA mit dem Antworterknoten abzubrechen.
Dieser Schritt zur Bestimmung ist mit dem Bezugszeichen 186 gekennzeichnet.
In Schritt 186 bestimmt das Sendemodul 151, ob
ein Empfangsmodul die Eigenschaft besitzt, fragmentierte Pakete
zu empfangen. Wenn es das nicht kann, kann der Fragmentierer 150 wieder
versuchen, die IKE-Nutzdaten ein oder mehrere Male erneut zu senden
(Schritt ist nicht dargestellt), oder er wird in Schritt 187 den
gesamten Prozess abbrechen. Auf der anderen Seite wird das Sendemodul,
wenn der Empfängerknoten
seinen eigenen Fragmentierer und sein zum Empfang taugliches Modul
besitzt, den Prozess der Fragmentierung der IKE-Nutzdaten für die Übertragung
beginnen.
-
In
einer bevorzugten Ausführungsform
ist der Fragmentierer 150 in der Lage, die Fragmentierungsfähigkeiten
des Empfängerknotens
in Bezug auf einen Identifikationswert des Herstellers (Hersteller-ID)
zu erfassen, der während
einer der ersten Datenaustausche im Prozess zum Aufbau einer SA
gesendet wird. Diese Hersteller-ID wird üblicherweise als ein Teil des
IKE-Protokolls ausgetauscht. Mit Bezug auf eine Nachschlagtabelle
oder eine ähnliche Technik
wird das Sendemodul 151 in der Lage sein, zu bestimmen,
ob das Empfangsmodul 152 die Fähigkeit aufweist, fragmentierte
IKE-Nutzdaten zu bearbeiten.
-
Nach
dem Bestimmen, dass ein angemessenes Empfangsmodul existiert, beginnt
das Sendemodul 151 des Fragmentierers 150 die
originalen IKE-Nutzdaten zu fragmentieren. Der erste Schritt des
Fragmentierungsprozesses in Schritt 188 ist es, einen geeigneten
Wert für
die MTU zu bestimmen. In einer bevorzugten Ausführungsform stellt die geeignete
MTU, die im Fragmentierungsprozess einzusetzen ist, die kleinste
mögliche Übertragungseinheit dar,
die für
das bestimmte Netzwerk, in dem der Urheberknoten und der Antworterknoten
miteinander kommunizieren, spezifiziert ist. Für bestimmte Netzwerke und Anwendungen
zum Beispiel ist die kleinste Einheit in Wählverbindungen 576 Bytes lang.
Daher wird in Schritt 188 die Länge der MTU auf 576 Bytes festgelegt.
-
In
einer anderen Ausführungsform
kann der Fragmentierer 150 versuchen, die MTU in einem
iterativen Prozess zu bestimmen, wobei zunehmend kleinere Paketgrößen ausgewählt werden,
bis eine passende Antwort empfangen wird. Dieser iterative Prozess
ist in der Logik der 8 nicht dargestellt, könnte aber
leicht von durchschnittlichen Kenfern der Technik auf der Basis
der vorangegangenen Beschreibung implementiert werden. Nachdem die
geeignete MTU bestimmt worden ist, ob als optimaler Wert, der in
einem iterativen Prozess ermittelt wird, oder als absoluter Wert,
wird der Fragmentierer 150 die MTU entsprechend herabsetzen,
die für
die zukünftigen
IKE-bezogenen Kommunikationen eingesetzt wird.
-
Im
nächsten
Schritt, dem Schritt 189, fragmentiert der Fragmentierer 150 die
originalen IKE-Nutzdaten. Der Prozess umfasst die Verkapselung und
die Verkürzung
der originalen IKE-Nutzdaten. Wie in 7 veranschaulicht
wird, wird der originale IKE-Header 161 in Schritt 189 ebenfalls
verkapselt und die Nutzdaten werden dann in einzelne Pakete in der
Weise unterteilt, dass die Kombination aus den IKE-Headern und den
Daten die neu bestimmte Größe der MTU
nicht überschreiten.
-
In
einer bevorzugten Ausführungsform
erhalten die Daten, die in den fragmentierten IKE-Paketen enthalten
sind, einen neuen Typ für
IKE-Nutzdaten, ISA_FRAG, der wie folgt definiert ist:
-
Jedes
Fragment wird auf diese Weise Informationen (Metadaten) enthalten,
die die originalen IKE-Nutzdaten und ihre Positionen in den originalen IKE-Nutzdaten
eindeutig identifizieren. Zum Beispiel können die Metadaten, die in
einer ersten fragmentierten Nachricht wie etwa der Nachricht 171 gesendet
werden, wie folgt aussehen: {id = 1, num = 1, flags, last_packet_flag
= false}. Die Daten, die in einer zweiten Nachricht wie etwa der
Nachricht 174 gesendet werden, können wie folgt aussehen: {id
= 1, num = 2, flags, last_packet_flag = false}. Schließlich können die
Daten, die in einer dritten Nachricht wie etwa der Nachricht 176 gesendet
werden, wie folgt aussehen: {id = 1, num = 3, flags, last_packet_flag
= true}. Wie nachfolgend beschrieben wird, verwendet das Empfangsmodul 152 diese
Daten, um die originalen IKE-Nutzdaten wieder zusammenzusetzen.
Es verwendet diese Daten auch dazu, Angriffe von Dritten auf den
Urheber und/oder den Antworter zu vereiteln.
-
In
Schritt 190 werden dann alle Fragmente über das Netzwerk gesendet,
wobei keines von ihnen den festgelegten Wert für die MTU überschreitet. Der Vorteil liegt
darin, dass die IKE-Fragmente, die nach der vorliegenden Erfindung
erzeugt werden, auch von bestimmten Arten von NATs oder Firewalls
effizient verarbeitet werden können,
die entweder IKE-Fragmente auf dem Stand der Technik nicht verfolgen
können
oder damit Schwierigkeiten haben. Für diese oder andere ähnliche
Vorrichtungen kann ein IKE-Fragment,
das mit früher
bekannten Methoden erzeugt worden ist, nicht alle Zustandsinformationen
aufweisen, die für
die NAT oder die Firewall notwendig sind, um das Fragment zu bearbeiten
und zu lenken. Dies gilt besonders für gestörte Fragmente. Wenn zum Beispiel
ein zweites IKE-Fragment, das mit früher bekannten Methoden erzeugt worden
ist, vor dem ersten IKE-Fragment ankommt, werden viele NATs oder
Firewalls nicht genügend
Informationen besitzen, um es an den richtigen Nachfolgeknoten weiterzuleiten.
Deshalb wird die NAT oder die Firewall das Fragment wegwerfen, und
das IKE-Paket wird
beim vorgesehenen Knoten nicht erfolgreich empfangen.
-
Die
vorliegende Erfindung löst
diese Frage dadurch, dass neben anderen Dingen Pakete geringerer
Größe gesendet
werden und Zustandsinformationen in jedes IKE-Fragment aufgenommen
werden. Jedes IKE-Fragment, das nach der vorliegenden Erfindung
erzeugt wird, enthält
einen IKE-Header. Darüber
hinaus wird der sendende Knoten ferner einen UDP-Header in jedes
IKE-Fragment einschließen. Der
UDP-Header wiederum weist spezifische Informationen für NATs,
Firewalls und andere ähnliche Vorrichtungen
auf, damit diese das Fragment bearbeiten können. Die vorliegende Erfindung
stellt auf diese Weise sicher, dass jedes IKE-Fragment die für die Bearbeitung
in einer NAT oder Firewall notwendigen Informationen besitzt, und
sie verringert und/oder eliminiert den Bedarf in bestimmten NATs oder
Firewalls, deren eigenen Fragmentierungs- und Reassemblierungsprozesse
zu verwenden.
-
In
einer bevorzugten Ausführungsform
wird das Sendemodul 151 in Schritt 190 einen Zeitgeber setzen,
um auf eine Antwort zu warten, nachdem es die Fragmente an den vorgesehenen
empfangenden Knoten gesendet hat. Das Sendemodul 151 wird
in Schritt 191 ebenfalls prüfen, um zu ermitteln, ob ein Antwortmodul
eine NAK-Nachricht (Not AcKnowledged, nicht erkannt) gesendet hat.
Wenn eine NAK durch den empfangenden Knoten auf der Basis der nachfolgend
beschriebenen Bedingungen gesendet, und dann vom sendenden Knoten
empfangen wird, wird das entsprechende Fragment oder die Fragmente
in Schritt 192 erneut gesendet. Das Sendemodul 151 wird
in Schritt 193 weiterhin auf eine Antwort warten, bis eine
NAK empfangen wird oder der Zeitgeber abgelaufen ist. Wenn der Zeitgeber
abgelaufen ist, werden alle Fragmente wieder neu gesendet und es
wird in Schritt 190 ein neuer Zeitgeber gesetzt.
-
Der
Prozess zur Übertragung
von Fragmenten und das Setzen eines Zeitgebers in Schritt 190, das
Feststellen in Schritt 191, ob irgendwelche NAKs empfangen
wurden, und das Feststellen in Schritt 193, ob der Zeitgeber
abgelaufen ist, werden solange fortgesetzt, bis eine Antwort empfangen
wird. Nach einer bestimmten Anzahl von Durchläufen wird das Sendemodul schließlich den
Prozess des Versuchs, die fragmentierten Nutzdaten zu übertragen,
abbrechen. Das wird durch die gestrichelte Linie bei Schritt 193 angedeutet.
-
Wenn
jedoch eine Antwort empfangen wurde, ist der Schritt 194 der
letzte Schritt des Übertragungsprozesses,
in dem festgestellt wird, ob es eine passende Antwort auf die originalen
IKE-Nutzdaten gibt. Wenn ja, wird die Steuerung an den IKE-Protokoll-Stapel
zurückgegeben,
der dann wieder nach seinem Protokoll mit Schritt 183 fortfährt. Wenn
auf der anderen Seite der Antworterknoten in Schritt 194 immer
noch keine passende Antwort liefert, wird der Fragmentierer 150 den
Prozess der Einrichtung einer SA in Schritt 187 abbrechen.
In einer bevorzugten Ausführungsform
wird der Fragmentierer 150 alle Fragmente zwei oder mehrere
Male erneut senden, bevor er den gesamten Prozess abbricht. Wenn
in Schritt 194 keine passende Antwort empfangen wurde,
wird folglich das Sendemodul 151 für eine festgelegte Anzahl von
Durchläufen
zum Schritt 190 zurückkehren,
bevor es den Prozess abbricht.
-
9 veranschaulicht
in allgemeiner Form den logischen Fluss des Codemoduls, das den
Fragmentierer 150 auf einem empfangenden Knoten implementiert,
insbesondere des Empfangsmoduls 152. Wie bei der 8 versteht
sich von selbst, dass dieses Flussdiagramm für eine bevorzugte Ausführungsform
bestimmt ist und keinen Anspruch auf Vollständigkeit hinsichtlich aller Änderungen
erhebt, die für
einen Kenner der Technik erkennbar sind. Es versteht sich ferner
von selbst, dass bestimmte Schritte, die in 9 aufgezeigt
sind, vom Sendmodul und/oder vom Empfangsmodul des Fragmentierers 150 ausgeführt werden
können.
-
Obwohl
es nicht notwendigerweise der erste Vorgang für das Empfangsmodul im Fragmentierer 150 ist,
soll der erste Schritt, der in 9 dargestellt ist,
seinen Durchsatz bei der Bearbeitung von IKE-Nachrichten, die nach
der Erfindung fragmentiert sind, in Schritt 196 bekannt
geben. Dieser Schritt wird in der bevorzugten Ausführungsform
ausgeführt,
indem die Hersteller-ID des Empfangsknotens übertragen wird. Alternativ
dazu ist es für
das Empfangsmodul 152 des Fragmentierers 150 möglich, eine
spezifische Nachricht zu senden, die seinen Durchsatz bei der Bearbeitung
fragmentierter IKE-Nutzdaten angibt, sei es als Antwort auf eine
spezifische Anfrage oder nicht (nicht dargestellt). Dieser Schritt
kann bereits früh
beim Versuch des Urhebers, eine SA einzurichten, oder erst nach
der Erkennung eines Problems ausgeführt werden.
-
Auf
Grund der Platzierung des Fragmentierer-Moduls 150 wird
sein Empfangsmodul 152 alle Pakete, die für den IKE-Protokoll-Stapel 127 bestimmt
sind, empfangen oder abfangen. Wenn die originalen IKE-Nutzdaten
bereits ohne Fragmentierung empfangen wurden, wird das Empfangsmodul die
originalen IKE-Nutzdaten an den IKE-Protokoll-Stapel 127 des
Antworterknotens zu seiner üblichen
Bearbeitung weiterleiten (Schritt nicht gezeigt). Das Empfangsmodul 152 wird
jedoch alle Pakete, die nach der vorliegenden Erfindung fragmentiert
wurden, in Schritt 197 abfangen und vernichten. Danach wird
das Empfangsmodul die Metadaten des Fragments zur Bearbeitung des
Fragments selbst verwenden.
-
In
einer Ausführungsform
der Erfindung wird in Schritt 198 das Empfangsmodul die
Fragment-Identität
des empfangenen Fragments (Fragment-ID) überprüfen. Die Datenstruktur, die
oben beschrieben ist, enthält
ein Feld für
die Fragment-ID, das in diesem Schritt verwendet werden kann. Jedes Fragment,
das einem einzigen, nicht fragmentierten IKE-Nutzdaten-Paket entspricht,
wird dieselbe Fragment-ID aufweisen. Das Empfangsmodul des Fragmentierers 150 wird
in Schritt 199 jedes Paketfragment verwerfen, das nicht
eine passende Fragment-ID besitzt. Das Empfangsmodul einer bevorzugten
Ausführungsform
kann zu einem beliebigen Zeitpunkt nur eine bestimmte Anzahl von
IKE-Nutzdaten bearbeiten, auch wenn es fragmentierte IKE-Nutzdaten
sind, bevor es irgendwelche anderen zu bearbeiten versucht. In einer
bevorzugten Ausführungsform
ist diese Anzahl gleich eins. Auf diese Weise muss das Empfangsmodul
alle Fragmente, die zu einem einzigen Satz von IKE-Nutzdaten gehören, empfangen,
d. h. alle Fragmente, die dieselbe Fragment-ID aufweisen, bevor
es versucht, Fragmente mit einer anderen Fragment-ID zu bearbeiten.
-
Darüber hinaus
wird das Empfangsmodul 152 in einer bevorzugten Ausführungsform
der Erfindung die Folgenummer jedes empfangenen Fragments in Schritt 200 überprüfen, um
zu ermitteln, ob die Folgenummer des Fragments in einer entsprechenden
Reihenfolge ist. Wenn ja, wird das Fragment in Schritt 203 für eine weitere
Bearbeitung in einem Puffer gespeichert. Wenn nicht, wird das Empfangsmodul
in Schritt 201 eine Außer-der-Reihe-Fehlerbedingung
festsetzen. In diesem Schritt ermittelt das Empfangsmodul, ob ein
bestimmtes Fragment zu speichern ist, ob es verworfen werden soll und/oder
ob eine NAK-Nachricht an den Urheberknoten gesendet werden soll.
Wenn zum Beispiel das erste und dritte Fragment in einer Folge empfangen worden
sind, das zweite jedoch nicht, kann das Empfangsmodul eine NAK an
das Sendemodul 151 des Urheberknotens senden, damit nach
Schritt 192 in 8 das entsprechende Fragment
erneut übertragen
wird. Wenn auf der anderen Seite ein Fragment empfangen wird, das
die identische Folgenummer enthält
wie ein Fragment, das früher
empfangen wurde, kann das Empfangsmodul 152 dieses Fragment oder
alle Fragmente, die eine bestimmte Folgenummer haben, verwerfen.
Eine weitere Option liegt darin, dass das Empfangsmodul nach einem
Satz festgelegter Regeln in Schritt 203 festlegen kann,
dass das Fragment, das nicht in die Reihe passt, für eine weitere
Bearbeitung gespeichert werden sollte. In dieser letzten Option
kann es erstrebenswert sein, mindestens ein Fragment zu speichern,
dessen Folgenummer sich von einer vorherigen Folgenummer um einen
geringen Wert unterscheidet. Die Regeln zum Bestimmen, welche Außer-der-Reihe-Fragmente
zu speichern und welche zu verwerfen sind, können in Abhängigkeit von der gewünschten
Antwort eines bestimmten Systems erzeugt und flexibel angewendet
werden.
-
Nachdem
ein Fragment gespeichert worden ist, wird das Empfangsmodul 152 dann
in Schritt 204 bestimmen, ob die Gesamtlänge aller
empfangenen und gespeicherten Fragmente einen festgelegten Schwellenwert
für die
Größe überschreitet.
In einer bevorzugten Ausführungsform
liegt diese Grenze bei 64K Bytes, da dies die maximale Größe für alle gegebenen
IKE-Nutzdaten ist. Diese Bestimmung kann flexibel implementiert
werden und so angepasst werden, um Angriffe wie Denial-of-Service
(Dienstverweigerung) oder ähnliche
Angriffe wie etwa solche, die mit den Man-in-the-middle-Angriffen
(Janusangriffe) in Verbindung gebracht werden, zu verhindern oder
abzuschwächen.
Wenn die Grenze für
die Gesamtlänge überschritten
ist, verwirft das Empfangsmodul 152 in Schritt 199 alle
Fragmente, die dieselbe Fragment-ID enthalten.
-
Danach
untersucht das Empfangsmodul 152 die Flags im gespeicherten
Fragment, um zu ermitteln, ob es das Letzte in der Folge der Fragmente
ist. Wenn nicht, geht das Empfangsmodul 152 zurück und wartet
in Schritt 197 auf weitere Fragmente. Wenn das Fragment
das Letzte in der Folge ist, ermittelt das Empfangsmodul als Nächstes dann
in Schritt 206, ob es alle Fragmente empfangen hat, die
zu einer bestimmten Fragment-ID gehören. Wenn nicht alle Fragmente,
die zu einem bestimmten Satz von IKE-Nutzdaten gehören, empfangen
worden sind, geht das Empfangsmodul wiederum zurück und wartet in Schritt 197 auf
weitere Fragmente. Die eingehenden Pakete werden dann wie oben beschrieben untersucht,
bis entweder alle Fragmente, die zu einem bestimmten Satz von IKE-Nutzdaten
gehören, empfangen
worden sind oder bis ein Fragment empfangen wird, das eine neue
Fragment-ID enthält.
Im letzteren Fall wird, wie oben beschrieben, die aktuelle Anordnung
entsprechend den Schritten 198 und 199 verworfen.
Wenn jedoch alle Fragmente in der Folge empfangen worden sind, wird
das Paket in Schritt 207 in der richtigen Reihenfolge zusammengesetzt. Der
Schritt des Zusammensetzens eines Paketes sollte so verstanden werden,
dass alle notwendigen Vorgänge,
um die originalen IKE-Nutzdaten neu zu verpacken, inklusive des
Ablösens
aller Daten, die sich auf den Fragmentierungsprozess beziehen, eingeschlossen
sind. Im letzten Schritt, dem Schritt 208, gibt das Empfangsmodul 152 die
neu verpackten IKE-Nutzdaten an den IKE-Protokoll-Stapel 127 zur normalen
Bearbeitung weiter.
-
In
der voranstehenden Beschreibung der bevorzugten Ausführungsform
wird das Empfangsmodul 152 ein Zusammensetzen von Fragmenten
verwerfen, wenn es ein Fragment empfängt, das eine spätere Fragment-ID
aufweist. In anderen Worten gesagt, wird nur ein Satz von IKE-Nutzdaten
zur selben Zeit bearbeitet. Dieser Prozess wird die Sicherheit maximieren
und die Auswirkungen von Denial-of-Service- und anderen ähnlichen
Angriffen abschwächen.
In alternativen Ausführungsformen könnten vom
Empfangsmodul 152 jedoch mehr als ein Satz von IKE-Nutzdaten
bearbeitet werden. So könnte
zum Beispiel eine diskrete Anzahl von IKE-Nutzdaten wie etwa zwei,
drei, fünfzehn,
siebenundzwanzig usw. verfolgt werden, sobald sie empfangen wird.
-
Darüber hinaus
werden in einer anderen möglichen
Ausführungsform
des Empfangsmoduls 152 die Dateninhalte der Fragmente untersucht,
bevor sie nach den bekannten Verfahren neu gepackt werden. Diese
Untersuchung hilft in einem frühen Stadium
des Empfangsprozesses bei der Bestimmung, ob das Fragment, das empfangen
wurde, von einem gültigen
Partner gesendet wurde.
-
Somit
kann man sehen, dass eine neues und nutzbringendes Verfahren und
Gerät zum Übertragen
von IKE-Nachrichten über
ein Computer-Netzwerk vorgelegt wurde. Angesichts der vielen möglichen
Ausführungsformen,
in denen die Prinzipien der Erfindung angewendet werden können, sollte
erkannt werden, dass die hier beschriebenen Ausführungsformen mit Bezug auf
die skizzierten Zeichnungen nur zur Erläuterung gedacht sind und sollten nicht
als Einschränkung
des Anwendungsbereichs der Erfindung gesehen werden. Die Kenner
der Technik werden zum Beispiel erkennen, dass die Elemente der
dargestellten Ausführungsformen,
die als Ausführungen
in Software gezeigt wurden, auch als Ausführungen in Hardware implementiert
werden können und
auch umgekehrt, oder dass die dargestellten Ausführungsformen in der Anordnung
und den Details verändert
werden können,
ohne sich von der Erfindung zu entfernen.
