DE69831974T2

DE69831974T2 - Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen

Info

Publication number: DE69831974T2
Application number: DE69831974T
Authority: DE
Inventors: Tatu YLÖNEN
Original assignee: SSH Communications Security Oy
Current assignee: SSH Communications Security Oy
Priority date: 1997-12-31
Filing date: 1998-12-30
Publication date: 2006-06-08
Anticipated expiration: 2018-12-31
Also published as: WO1999035799A3; FI974665A0; FI974665A; EP1036460B1; FI105753B; ATE307449T1; IL136787A0; AU1879599A; EP1036460A2; WO1999035799A2; CA2315722A1; US6795917B1; DE69831974D1; CA2315722C; JP3457645B2; JP2002501332A

Description

Die Erfindung betrifft die Authentifizierung von Datenpaketen in einem digitalen Datenübertragungsnetz. Insbesondere betrifft die Erfindung die Authentifizierung in einem Netz, in welchem Transformationen an Paketen durchgeführt werden, während sie unterwegs sind, was die Verwendung von Authentifizierungsverfahren des Standes der Technik schwierig oder unmöglich macht.
Die Internetsicherheit hat in den letzten Jahren aufgrund des enormen Wachstums des Internets und der rasch ansteigenden Zahl von Unternehmen, die sich ans Netz anschließen, eine größere wissenschaftliche und wirtschaftliche Beachtung erlangt. Das Netz wurde zu einem entscheidenden Teil des Betriebs vieler kommerzieller Unternehmen. Die kommerzielle Nutzung des Internets wird durch Sicherheitsprobleme in bestehenden Internetprotokollen stark eingeschränkt, weshalb eine Verbesserung der Internetsicherheit dringend notwendig ist.
Das IP-Sicherheitsprotokoll (IPSEC) wird durch die IETF (nach engl. Internet Engineering Task Force) standardisiert, um dem IP-Protokoll Sicherheit zu verleihen. Es stellt eine kryptografische Authentifizierung und Vertraulichkeit im Verkehr zwischen zwei kommunizierenden Netzknoten bereit. Es kann sowohl im Ende-zu-Ende-Betrieb direkt zwischen den kommunizierenden Knoten oder Hosts oder im Tunnelbetrieb zwischen Firewalls oder VPN-Geräten (VPN, virtuelles Privatnetz nach engl. Virtual Private Network) verwendet werden. Asymmetrische Verbindungen, bei welchen ein Ende ein Host und das andere Ende eine Firewall oder ein VPN ist, sind ebenfalls möglich.
Das IPSEC führt Authentifizierung und Verschlüsselung auf Paketebene durch Hinzufügen von neuen Protokollköpfen zu jedem Paket durch. Die IPSEC-Authentifizierung wird durch Berechnen eines Authentifizierungscodes über alle Daten und den Großteil des Kopfes des Datenpakets durchgeführt. Der Authentifizierungscode hängt ferner von einem geheimen Schlüssel ab, der nur den kommunizierenden Parteien bekannt ist. Der Authentifizierungscode wird dann im Paket gespeichert und in einem klar definierten Kopf oder Anhang entsprechend eingepackt.
Der Geheimschlüssel zur Authentifizierung kann für jedes Paar von kommunizierenden Hosts manuell konfiguriert werden. In der Praxis werden jedoch spezielle Schlüsselverwaltungsprotokolle verwendet, um die Geheimschlüssel dynamisch zu erzeugen und auszutauschen. Beim IPSEC wird das Standardprotokoll dafür ISAKMP/Oakley-Protokoll genannt, wobei ISAKMP für Internet Security Association Key Management Protocol steht.
Der IPSEC-Authentifzierungsschutz umfasst die Ursprungs- und Zieladressen des Pakets, was bedeutet, dass sie unterwegs nicht geändert werden können, wenn der Authentifizierungscode gültig bleiben soll. Viele Unternehmen verwenden jedoch zurzeit private IP-Adressen innerhalb ihrer eigenen Organisation und übersetzen die Privatadressen an einem externen Gateway (z.B. Router oder Firewall) in weltweit einzigartige Adressen. Dieser Vorgang wird Netzadressübersetzung (NAT für engl. network address translation) genannt. Solch eine Übersetzung bezieht normalerweise sowohl eine Änderung der IP-Adressen als auch der TCP- oder UDP-Portnummern ein.
Ein NAT-Gerät 100 in 1 nimmt Pakete 101 auf, welche durch einen Sendeknoten 102 in einem Privatnetz 103 gesendet werden. Es wandelt die IP-Adressen und Portnummern in diesem Paketen von jenen, die zu einem internen Privatadressraum gehören, in weltweit einzigartige externe Internetadressen in abgehenden Paketen 104 um, bevor es die Pakete durch das externe Netz 105 an einen Empfangsknoten 106 sendet. Die Adressumwandlung erfolgt für Pakete, die das NAT-Gerät 100 passieren in der anderen Richtung, genau umgekehrt. Normalerweise ordnet ein NAT-Gerät 100 IP-Adress- und Portkombinationen verschiedenen IP-Adress- und Portkombinationen zu. Die Zuordnung bleibt für die Dauer einer Netzverbindung konstant, kann sich aber mit der Zeit (langsam) ändern. In der Praxis ist die NAT-Funktionalität häufig in einer Firewall oder einem Router integriert.
Außerdem gibt es andere Arten von Geräten im Internet, welche Pakete legal modifizieren können, wenn sie gesendet werden. Ein typisches Beispiel ist ein Protokollwandler, dessen Hauptaufgabe es ist, das Paket in ein anderes Protokoll umzuwandeln, ohne den normalen Betrieb zu stören. Ihre Verwendung führt zu Problemen, die dem NAT-Fall sehr ähnlich sind. Ein Protokollwandler wandelt Pakete von einem Protokoll in ein anderes Protokoll um. Ein ziemlich einfaches, aber wichtiges Beispiel ist das Umwandeln zwischen IPv4 und IPv6, welche verschiedene Versionen des Internetprotokolls sind. Solche Wandler werden in naher Zukunft äußerst wichtig und alltäglich sein. Ein Paket kann während seines Laufs mehreren Umwandlungen dieser Art unterzogen werden, und es ist möglich, dass die Endpunkte der Kommunikation tatsächlich ein anderes Protokoll verwenden. Wie NAT wird auch die Protokollumwandlung häufig in Routern und Firewalls durchgeführt. Der Aufbau eines IPv4-Paketkopfes ist in 2 veranschaulicht, und der Aufbau eines IPv6-Paketkopfes in 3. Die Spaltenzahlen in 2 und 3 entsprechen Bits.
In 2 sind die Felder des bekannten IPv4-Kopfes wie folgt: Version Nummer 201, IHL 202, Dienstart 203, Gesamtlänge 204, Kennung 205, Markierungen 206, Fragmentoffset 207, Lebensdauer 208, Protokoll 209, Kopfprüfsumme 210, Ursprungsadresse 211, Zieladresse 212, Optionen 213 und Auffüllung 214. In 3 sind die Felder des bekannten vorgeschlagenen IPv6-Kopfes wie folgt: Version Nummer 301, Verkehrsklasse 302, Flusskennzeichnung 303, Nutzlastlänge 304, Nächster Kopf 315, Sprunggrenze 306, Ursprungsadresse 307 und Zieladresse 308. Die Verwendung der Felder in den Köpfen ist einem Fachmann bekannt. Ein IP-Paket besteht aus einem Kopf wie dem in 2 oder 3, der von einem Datenabschnitt begleitet wird. Im IPv6 kann es eine Anzahl von so genannten Erweiterungsköpfen zwischen dem Hauptkopf, der in 3 dargestellt ist, und dem Datenabschnitt geben.
Die gewünschten Sicherheitsmerkmale eines Netzsicherheitsprotokolls umfassen Echtheit (das Paket wurde tatsächlich durch den Knoten gesendet, von dem es behauptet gesendet worden zu sein), Unversehrtheit (das Paket wurde unterwegs nicht modifiziert), Nichtabstreitbarkeit (der Sendeknoten kann nicht leugnen, das Paket gesendet zu haben) und Geheimhaltung (kein Dritter kann die Inhalte des Pakets lesen). Im IPSEC-Protokoll werden Echtheit, Unversehrtheit und Nichtabstreitbarkeit durch Aufweisen eines gemeinsam benutzten Geheimschlüssels, der zum Authentifizieren jedes Pakets verwendet wird, erreicht. Die Authentifizierung erfolgt durch Berechnen eines Nachrichtenauthentifizierungscodes (MAC für engl. message authentication code) unter Verwendung der Inhalte des Pakets und des gemeinsam benutzten Geheimcodes und Senden des berechneten MACs als einen Teil des Pakets in einem Authentifizierungskopf (AH für engl. Authentication Header) oder einem Kopf mit eingebetteter Sicherheitsnutzlast (ESP für Encapsulating Security Payload). Die Geheimhaltung wird normalerweise unter Verwendung einer Verschlüsselung realisiert, und es wird der ESP-Kopf verwendet. Der AH-Kopf ist in 4 veranschaulicht, wobei die Spaltenzahlen Bits entsprechen. Die Felder des bekannten AH-Kopfes sind wie folgt: Nächster Kopf 401, Länge 402, Reserviert 403, Sicherheitsparameter 404 und Authentifizierungsdaten 405. Die Länge des letzten Feldes 405 ist eine veränderliche Zahl von 32-Bit-Wörtern.
Die eingebettete Sicherheitsnutzlast (ESP) kann in einem IP-Paket irgendwo nach dem IP-Kopf und vor dem abschließenden Transportschichtprotokoll erscheinen. Die Internet Assigned Numbers Authority (Zentralregistratur für Internetprotokollparameter und RFC-Nummern) hat der ESP die Protokollnummer 50 zugeordnet. Der Kopf, der einem ESP-Kopf unmittelbar vorangeht, enthält stets den Wert 50 in seinem Nächster-Kopf-Feld (IPv6) oder Protokoll-Feld (IPv4). Die ESP besteht aus einem unverschlüsselten Kopf, dem verschlüsselte Daten folgen. Die verschlüsselten Daten umfassen sowohl die geschützten ESP-Kopffelder als auch die geschützten Benutzerdaten, wobei es sich entweder um ein ganzes IP-Datagramm oder einen Protokollrahmen der oberen Schichten (z.B. TCP oder UDP) handelt. Ein Diagramm auf hoher Ebene eines sicheren IP-Datagramms ist in 5a veranschaulicht, wobei die Felder sind: IP-Kopf 501, optional andere IP-Köpfe 502; ESP-Kopf 503 und verschlüsselte Daten 504. 5b veranschaulicht die zwei Teile eines ESP-Kopfes, wobei es sich um die 32-Bit-Sicherheitsverbindungskennzeichnung (SPI) 505 und das Opaktransformationsdatenfeld 506, dessen Länge veränderlich ist, handelt.
Es gibt verschiedene Möglichkeiten, einen MAC zu berechnen, die in der Fachliteratur allgemein bekannt sind. Ein allgemein verwendetes Verfahren ist das Berechnen einer verschlüsselten kryptografischen Hash-Funktion (z.B. HMAC-SHA1) über die zu authentifizierenden Daten unter Verwendung des gemeinsam benutzten Geheimcodes als den Schlüssel.
Wir werden Echtheit, Unversehrtheit und Nichtabstreitbarkeit zusammen als Paketauthentifizierung bezeichnen. Im IPSEC wird diese Funktion durch Berechnen eines Nachrichtenauthentifizierungscodes (MAC) für das Paket am Sendeknoten, Einbinden des berechneten Nachrichtenauthentifizierungscodes mit dem Paket in einen AH- oder ESP-Kopf und Verifizieren des Nachrichtenauthentifizierungscodes am Empfangsknoten erreicht. Die Verifizierung ist erfolgreich, wenn beide Knoten denselben gemeinsam benutzten Geheimcode kennen und das empfangene Paket mit dem Paket, von dem der MAC berechnet wurde, identisch ist.
NATs und Protokollwandler modifizieren Pakete, wenn sie übertragen werden, schon allein aufgrund ihrer eigenen Natur. Es ist jedoch gerade der Zweck einer Paketauthentifizierung, Modifikationen am Paket zu verhindern, und alle Transformationen an dem Paket bewirken, dass die Authentifizierung misslingt. Eine NAT ändert die Ursprungs- und/oder die Zieladressen eines Pakets, wodurch sie den IPSEC-Authentifizierungscode ungültig macht. Es wurden mehrere Lösungen zur Durchführung einer Authentifizierung in solch einer Umgebung vorgeschlagen, wie beispielsweise die Adressen nicht in den Authentifizierungscode einzubinden, eine Authentifizierung zwischen jedem Paar von benachbarten NAT-Gateways durchzuführen oder die Pakete in einer IP-in-IP-Einkapselung einzupacken. Es ist jedoch keine Lösung bekannt, welche eine Ende-zu-Ende-Authentifizierung bei Vorhandensein einer unbekannten Anzahl von NAT-Zwischengateways erlauben würde, ohne komplexe Verzeichnisse oder eine manuelle Konfiguration oder eine Neuauthentifizierung an jedem Gateway, welches das Paket modifiziert, zu erfordern.
Das ESP-Authentifizierungsverfahren bindet den Paketkopf nicht in den berechneten MAC ein. Das ursprüngliche Ziel dessen war, ESP über NAT funktionieren zu lassen. Es gibt jedoch ernste Probleme bei diesem Ansatz. Erstens enthält der TCP/IP-Kopf eine Prüfsumme, welche neben der tatsächlichen TCP-Nutzlast einen Pseudokopf umfasst, der die Netzadressen und Portnummern des Pakets enthält. Demnach ändert sich TCP/IP-Prüfsumme, wenn eine NAT durchgeführt wird. Normalerweise würde ein NAT-Gerät diese Prüfsumme automatisch korrigieren, aber dies ist unmöglich, wenn das Paket unter Verwendung eines Sicherheitsprotokolls geschützt ist. Dieselbe Situation findet sich beim UDP-Protokoll. Somit können TCP und UDP mit bestehenden Verfahren selbst über ESP nicht verlässlich verwendet werden.
Es gibt einen triftigen Grund, der Anbieter und Unternehmen dazu treibt, Technologien zu verwenden, welche Datenpakete modifizieren: Der IPv4-Adressraum geht zur Neige. Demnach können Unternehmen nicht mehr genügend IP-Adressen zu vernünftigen Preisen erhalten. Ein anderer Grund, der die Unternehmen in dieselbe Richtung bewegt, ist, dass das Umnummerieren von IP-Adressen sehr kostspielig ist, und Unternehmen müssen möglicherweise ihre externen Nummern ändern, wenn sie zu einem anderen Internet-Diensteanbieter überwechseln.
Diese Gründe führen das Internet zu zwei möglichen alternativen Lösungen: die Verwendung von NAT zu verstärken oder auf IPv6 überzugehen (was eine lange Übergangsperiode mit sich bringt, während der Protokollumwandlung allgemein gebräuchlich ist). Das gegenwärtige IPSEC-Protokoll kann keiner dieser Lösungen gerecht werden, ohne die Flexibilität oder die Sicherheit erheblich zu beeinträchtigen.
Das Patent US 5633931 beschreibt ein Verfahren zur Authentifizierung von Paketen unter Verwendung einer Nachrichtensignatur basierend auf einem Sitzungsschlüssel und der Nachricht selbst. Die Patentanmeldung WO 94/10778 beschreibt ein Verfahren und eine Vorrichtung zur Nachrichtenpaketauthentifizierung unter Verwendung eines Message-Digest-Algorithmus.
Es ist eine Aufgabe dieser Erfindung, ein Verfahren zur Paketauthentifizierung bereitzustellen, das gegen Adresstransformationen und Protokollumwandlungen auf dem Weg des Pakets unempfindlich ist. Eine weitere Aufgabe der Erfindung ist die Bereitstellung eines sendenden Netzgeräts und eines empfangenden Netzgeräts, die imstande sind, das zuvor erwähnten Verfahren nutzen.
Die Aufgaben der Erfindung werden erreicht, indem die Adressübersetzungen und/oder Protokollumwandlungen, die an Paketen zwischen den kommunizierenden Hosts durchgeführt werden, zuerst dynamisch ermittelt werden und diese Änderungen zu kompensieren, wenn der Paketauthentifizierungscode berechnet oder verifiziert wird.
Es ist kennzeichnend für das Verfahren gemäß der Erfindung, dass es die folgenden Schritte umfasst:

– Bestimmen der Transformationen, die einem Paket auf dem Weg zwischen dem Sendeknoten und dem Empfangsknoten widerfahren, basierend auf Sondierungsinformationen in einem Paket;
– Überprüfen (1004), dass die bestimmten Transformationen basierend auf der anwendbaren Sicherheitspolitik annehmbar sind; und
– Kompensieren (1004, 1006) der bestimmten annehmbaren Transformationen vor dem Authentifizieren von Paketen, die vom Sendeknoten an den Empfangsknoten übertragen werden.

Die Erfindung gilt auch für ein Netzgerät zum Empfangen von Paketen, dessen kennzeichnendes Merkmal seine Fähigkeit ist, das zuvor erwähnte Verfahren zu nutzen.
Die Erfindung gilt auch für ein Verfahren zum Verarbeiten von Paketen in einem Empfangsknoten, dessen kennzeichnende Merkmale die folgenden Schritte sind:

– Bestimmen der Transformationen, die einem Paket auf dem Weg zwischen dem Sendeknoten und dem Empfangsknoten widerfahren, basierend auf Sondierungsinformationen in einem Paket;
– Überprüfen (1004), dass die bestimmten Transformationen basierend auf der anwendbaren Sicherheitspolitik annehmbar sind; und
– Kompensieren (1004, 1006) der bestimmten annehmbaren Transformationen vor dem Authentifizieren von empfangenen Paketen

Ein erster Teil der Erfindung ist, dass die Netzgeräte oder Knoten, die an der Kommunikation teilnehmen, bei welcher Pakete authentifiziert werden müssen, die Netzadressübersetzungs- und/oder -protokollumwandlungseigenschaften eines Netzpfads durch Austauschen einer Sondierung und Vergleichen von Informationen in der empfangenen Sondierung mit ihrer bekannten Form zum Zeitpunkt der Sendung dynamisch zu ermitteln.
Ein zweiter Teil der Erfindung ist, dass nach dem Ermitteln der Netzadressübersetzungs- und/oder -protokollumwandlungseigenschaften eines Netzpfads der Sendeknoten und/oder der Empfangsknoten alle am Paket durchgeführten Adressübersetzungen und/oder Protokollumwandlungen kompensiert, so dass eine Paketauthentifizierung bei Vorhandensein von Adressübersetzungen und/oder Protokollumwandlungen noch immer sicher erreicht werden kann.
Die neuartigen Merkmale, welche als kennzeichnend für die Erfindung angesehen werden, werden insbesondere in den angehängten Patentansprüchen dargelegt. Die Erfindung selbst ist jedoch sowohl im Hinblick auf ihre Konstruktion als auch ihr Betriebsverfahren zusammen mit anderen zusätzlichen Zielen und Vorteilen durch die folgende Beschreibung von spezifischen Ausführungsformen in Verbindung mit den beiliegenden Zeichnungen am besten zu verstehen.
1 veranschaulicht ein bekanntes NAT-Gerät zwischen einem internen Netz und einem externen Netz,
2 veranschaulicht eine bekannten IPv4-Paketkopf,
3 veranschaulicht einen bekannten IPv6-Paketkopf,
4, 5a und 5b veranschaulichen bekannte Paketköpfe,
6 veranschaulicht eine getrennte Sondierung gemäß der Erfindung,
7 und 8 veranschaulichen verschiedene Möglichkeiten des Manipulierens eines zu sendenden Pakets gemäß der Erfindung,
9 veranschaulicht eine mitlaufende Sondierung gemäß der Erfindung,
10 veranschaulicht eine Ausführungsform der Erfindung als ein Flussdiagramm,
11 veranschaulicht ein Detail von 10,
12 veranschaulicht eine Ausführungsform der Erfindung als eine Zustandsdiagram und
13 veranschaulicht ein Blockdiagramm eines Geräts gemäß der Erfindung.
1 bis 5b wurden in der Beschreibung des Standes der Technik in Bezug genommen, so dass sich die folgende Erörterung hauptsächlich auf 6 bis 13 bezieht.
Die Erfindung wird im Zusammenhang mit dem IP-Protokoll, sowie den IPSEC- und ISAKMP/Oakley-Mechanismen beschrieben. Die vorliegende Erfindung ist jedoch ebenso auf andere Netzprotokolle und andere Sicherheitsmechanismen anwendbar, indem die protokoll- und mechanismusspezifischen Bezeichnungen und Spezifikationen in der folgenden Beschreibung durch die entsprechenden Gegenstücke in den anderen Netzprotokollen und Sicherheitsmechanismen ersetzt werden.
Die vorliegende Erfindung betrifft ein Verfahren zur Durchführung einer Paketauthentifizierung, wenn es NAT-Geräte (Netzadressübersetzungsgeräte) und/oder Protokollwandler gibt, die das Paket modifizieren, während es unterwegs ist. Die Erfindung ist ebenso auf viele andere Arten von Transformationen anwendbar, die am Paket vorgenommen werden könnten, wie beispielsweise Entfernen bestimmter IP-Optionen (z.B. quellengesteuertes Routing) oder Hinzufügen von Sicherheitsoptionen (z.B. IPSO oder CIPSO).
Die Erfindung beruht auf der Tatsache, dass es möglich ist, eine Authentifizierung über Adresstransformationen und/oder Protokollumwandlungen hinweg erfolgreich durchzuführen, indem sie entweder vorher, wenn der Authentifizierungscodes am Sendeknoten erzeugt wird, oder nachher, wenn sie am Empfangsknoten verifiziert werden, kompensiert werden. Eine derartige Kompensation erfordert jedoch die genaue Kenntnis der Transformationen, die an dem Paket zwischen den kommunizierenden Partnern durchgeführt werden. Viele Transformationen sind zeitabhängig – zum Beispiel können die externen Adressen, die von einer NAT auf der Basis "Ersten zuerst bedienen" vergeben werden, mit der Zeit variieren. Selbst wenn die Transformationen konstant sind, wäre das Konfigurieren und Aufrechterhalten der Transformationsinformationen auf eine statische Art und Weise für jedes Paar von möglichen kommunizierenden Knoten äußerst mühsam.
Im Verfahren gemäß der Erfindung kann dynamisch ermittelt werden, welche Transformationen zum Zeitpunkt, zu dem die Kommunikation stattfindet, bei irgendeiner bestimmten Netzverbindung vorgenommen werden, und die Transformationen können kompensiert werden, wenn die Paketauthentifizierung erfolgt. Das Problem teilt sich demnach in eine Reihe von Teilprobleme: Wie kann die Ermittlung zuverlässig und sicher durchgeführt werden, welche ermittelten Transformationen werden als annehmbar angesehen und wie werden die Transformationen kompensiert, die stattfinden, während das Paket unterwegs ist.
Die Transformationseigenschaften des Pfades zwischen den kommunizierenden Knoten müssen mit einer ausreichend kleinen Granularität bestimmt werden. Hierbei bezieht sich ausreichend kleine Granularität auf Bereiche von Netzadressen (z.B. IP-Teilnetze, einzelne IP-Adressen oder sogar Portnummern). Zum Beispiel können viele NATs eine IP-Adress- und Portkombination einer anderen IP-Adress- und Portkombination zuordnen. In solch einem Fall ist die Granularität zu einem Port. Andererseits könnte in einer anderen Umgebung dieselbe festgelegte Transformation für ein ganzes IP-Teilnetz oder einen Satz von Teilnetzen gelten. Die Realisierung muss gewährleisten, dass die Transformationseigenschaften für jede "Granalie" stets getrennt bestimmt werden. Eine Granalie ist hier die größte Einheit von Netzadressen (IP-Adressen, Portnummern), innerhalb der gewährleistet werden kann, dass die Transformation einheitlich ist.
Betrachten wir zuerst das erste Teilproblem, das zuvor erwähnt wurde, nämlich die dynamische Ermittlung der Transformationen, die unterwegs stattfinden. Solche Transformationen können von den Inhalten des IP-Pakets abhängen, insbesondere TCP- und UDP-Portnummern. Es gibt kein einfaches Verfahren, um die Transformationen im Voraus eindeutig zu berechnen, da die benötigten Informationen (z.B. interne Konfiguration und Zustand von NATs) für solch eine Berechnung nicht verfügbar sind und nicht einfach verfügbar gemacht werden können.
Im Verfahren gemäß der Erfindung sondieren die kommunizierenden Partner die Transformationen, die stattfinden, indem sie wenigstens ein Sondierungspaket durch den ganzen Kommunikationspfad zwischen ihnen senden und beobachten, was passiert. Das Sondierungspaket – oder kurz "Sondierung" – muss echten Datenpaketen ähnlich genug sein, so dass die Transformationen, die an ihm durchgeführt werden, gleich sind wie jene, die an tatsächlichen Datenpaketen durchgeführt werden. Das System, welches die Sondierung empfängt, muss auch imstande sein, sie als eine Sondierung zu erkennen. Alternativerweise kann dieser Teil der Erfindung realisiert werden, indem die Sondierungsinformationen in das erste Datenpaket eingebunden werden, das in jeder Richtung gesendet wird. Wir nennen diese zwei Alternativen getrennte Sondierung und mitlaufende (in-line) Sondierung.
In einigen Fällen können die Transformationsinformationen für einige Ziele (welche möglicherweise das "Default" Ziel umfassen) manuell konfiguriert werden. In solchen Fällen besteht keine Notwendigkeit, die Eigenschaften durch Sondieren zu bestimmen; stattdessen können sie direkt aus den Konfigurationsinformationen bestimmt werden. Der Aufbau in 1 zum Beispiel ist einfach genug, damit eine manuelle Konfiguration in diesem Fall möglich ist. Eine manuelle Konfiguration ist jedoch im Allgemeinen nicht möglich, da die benötigten Informationen z.B. über IPv9–IPv6-Umwandlungen womöglich überhaupt nicht verfügbar sind.
Von den Alternativen der getrennten oder der mitlaufenden Sondierung wenden wir uns zuerst der getrennten Sondierung zu. Gemäß 6 sendet hierbei der Sendeknoten 601 ein getrenntes Sondierungspaket 602 an den Empfangsknoten 603. Der Empfangsknoten muss das Sondierungspaket als solches erkennen. Die Möglichkeiten dafür sind begrenzt, da das Paket dasselbe Protokoll (z.B. AH, ESP, TCP oder UDP) und dieselben Portnummern (falls anwendbar) wie die Datenpakete verwenden muss. Alternativen zum Bestimmen, dass es sich um ein Sondierungspaket handelt, umfassen:

– Spezielle Inhalte im Datenabschnitt 702 des Pakets 701 (z.B. ein so genanntes magisches Cookie 703, das durch den Schlüsselverwalter ausgehandelt wird, oder eine Ableitung davon). Dies ist in 7 veranschaulicht. Das magische Cookie 703 kann eine Bitkette sein, die lange genug ist, so dass die Wahrscheinlichkeit, dass es in einem normalen Paket auftritt, äußerst gering (praktisch null) ist.
– Spezielle Markierungen (flags) in den Köpfen des Pakets (z.B. Verwendung einer reservierten Markierung im IP-, TCP- oder UDP-Kopf) oder das Aufweisen eines seltsamen Wertes in irgendeinem Feld.
– Spezielle Optionen im IP-, TCP- oder UDP-Kopf 802 (z.B. eine IP-Optionsnummer, die ausdrücklich für diesen Zweck reserviert ist). Dies ist in 8 veranschaulicht. Eine spezielle Optionsnummer wird für die Option des Identifizierens des Pakets als eine Sondierung verwendet.
– Der Empfangsknoten wird in einen Zustand versetzt, in dem er das nächste Paket zu einer bestimmten Protokoll-, Adress- und Portkombination als eine Sondierung betrachtet. Dieser Zustand könnte durch den Schlüsselverwalter in Kommunikation mit dem Sendeknoten eingestellt und gelöscht werden.

Die Erfindung schränkt das Verfahren, das verwendet wird, nicht darauf ein, eine Sondierung im Empfangsknoten zu erkennen.
Nachdem die getrennte Sondierung den ganzen Kommunikationspfad durchlaufen und der Empfangsknoten sie als eine Sondierung erkannt hat, kann die Bestimmung, welche Transformationen unterwegs stattfanden, erfolgen, indem die ursprünglichen Inhalte (normalerweise Köpfe) der Sondierung mit jenen, die am Empfangsende zu sehen sind, verglichen werden. Dieser Vergleich kann entweder durch den Sendeknoten oder den Empfangsknoten durchgeführt werden. Wenn er durch den Empfangsknoten durchgeführt wird, müssen genügend Informationen an ihn übermittelt werden, um den Vergleich durchzuführen (entweder im Datenabschnitt des Sondierungspakets selbst oder durch eine andere Kommunikation z.B. unter Verwendung des Schlüsselverwalters). Wenn er durch den Sendeknoten durchgeführt wird, muss der Empfangsknoten genügend Informationen über das empfangene Paket zurücksenden, um den Vergleich zu ermöglichen. Eine mögliche Form für das Übermitteln der Information ist, die kompletten ursprünglichen oder empfangenen Köpfe auf die andere Seite im Datenabschnitt eines Pakets zu senden. (Transformationen, welche den Datenabschnitt des Pakets modifizieren würden, sind selten und von einem Sicherheitsstandpunkt aus normalerweise unannehmbar.) In der Ausführungsform von 9 mit der mitlaufenden Sondierung werden die Sondierungsinformationen mit dem ersten Datenpaket 901 gesendet. Es gibt zwei mögliche Formen von mitlaufender Sondierung: eine ununterbrochene und eine unterbrochene Sondierung. Bei der ununterbrochenen Sondierung sieht das Paket 901 wie ein ganz normales Datenpaket für den Empfangsknoten 902 aus und, wenn der Empfangsknoten den verwendeten Sondierungsmechanismus nicht kennt, ignoriert er die Sondierungsinformationen und verarbeitet sie als normales Datenpaket. Demgegenüber kann der Empfangsknoten 902 bei der unterbrochenen Sondierung das Paket nicht normal verarbeiten, wenn der das Sondierungsverfahren nicht kennt.
Eine unterbrochene Sondierung ist der Verwendung eines getrennten Sondierungspakets ähnlich, mit der Ausnahme, dass die Daten für das erste Datenpaket auch im selben IP-Paket wie die Sondierungsinformationen enthalten sind.
Eine ununterbrochene Sondierung wird durch den Empfangsknoten 902 ignoriert, wenn er sie nicht versteht, in welchem Fall die Erfindung nicht anwendbar ist.
Paketauthentifizierte Kommunikationen sind nicht möglich, wenn die Knoten nicht ein geeignetes Verfahren zum Bewältigen derselben unterstützen. Wenn der Empfangsknoten in diesem Fall ein Antwortpaket zurücksendet, enthält es keine Antwortinformationen für die Sondierung. Dies kann vom ursprünglichen Sendeknoten 903 verwendet werden, um zu bestimmen, dass der Empfangsknoten die Sondierung nicht unterstützte. (Es ist zu beachten, dass der Empfangsknoten das Paket wahrscheinlich ignoriert, wenn tatsächlich Transformationen stattfanden.) Wenn der Empfangsknoten die Sondierungsinformationen verstanden hat, ist die Erfindung anwendbar, und das Antwortpaket an den ursprünglichen Sendeknoten enthält alle Antwortinformationen, die an den ursprünglichen Sendeknoten gesendet werden müssen, und seine Sondierungsinformationen, falls angebracht. Vom Gesichtspunkt der Erfindung kann dieses Paket ununterbrochen sein oder nicht, da die Fähigkeiten des ursprünglichen Sendeknotens dem ursprünglichen Empfangsknoten bereits zum Teil bekannt sind, wenn er sein erstes Antwortpaket sendet.
Die Funktion des Antwortpakets ist es, dem Sendeknoten 903 zu bestätigen, dass die Sondierung empfangen wurde und dass der Empfangsknoten paketauthentifizierte Kommunikationen unterstützt. Wenn das ursprüngliche Sondierungspaket oder das Antwortpaket im Netz verloren geht, kann es sein, dass es mehrere Male erneut gesendet werden muss, für immer oder bis eine Wiederholungsversuchszählung überschritten ist.
Wie bereits erwähnt, ist die ununterbrochene mitlaufende Sondierung ein mögliches Verfahren, um gleichzeitig auszuhandeln, ob das andere Ende die Verfahren, die in dieser Offenbarung beschrieben werden, unterstützt, und die dynamische Ermittlung durchzuführen. Es gibt auch andere Verfahren, um auszuhandeln, ob das andere Ende diese Verfahren unterstützt, welche umfassen:

– Es wird unter Verwendung des Schlüsselverwalters verhandelt (z.B. mit ISAKMP/Oakley, unter Verwendung von Anbieter ID Nutzlasten und/oder Erweiterungen zum Basisprotokoll).
– Es wird auf einer Pro-Netz- oder einer Pro-Host-Basis vorkonfiguriert.

Ungeachtet dessen, ob eine getrennte Sondierung oder eine mitlaufende Sondierung verwendet wurde, ist ein notwendiges Erfordernis, um die Transformationen, die stattfinden, kompensieren zu können, dass der Knoten (Sende- oder Empfangsknoten), der die Kompensation durchführt, weiß, welche Transformationen stattfanden. In einer Zweiwegverbindung könnte Kompensation für jedes Paket durch den jeweiligen Sendeknoten, durch den jeweiligen Empfangsknoten oder stets durch dieselbe Seite, ungeachtet der Richtung des Pakets, durchgeführt werden. Das Bestimmen der Transformationen kann am einfachsten durch Vergleichen des empfangenen Pakets (Kopf) mit dem Paket (Kopf), das gesendet wurde, erfolgen. Dazu muss entweder der empfangene Kopf dem Sendeknoten kommuniziert werden, oder der gesendete Kopf muss in seiner ursprünglichen Form dem Empfangsknoten kommuniziert werden. Diese Kommunikation kann entweder als Teil eines mitlaufenden Sondierungsaustausches oder durch Schlüsselverwalterkommunikationen oder andere Verfahren durchgeführt werden. Sowohl das Senden des ursprünglichen Kopfes an den Empfangsknoten als auch das Zurücksenden des empfangenen Kopfes an den Sendeknoten sind durchführbare Optionen.
Betrachten wird nun den Vergleich des gesendeten und des empfangenen Paketkopfes als einen Teil des zweiten Teilproblems, das zuvor definiert wurde: Welche Transformationen sind für die Kompensation annehmbar. Es gibt verschiedene Arten von Transformationen, die an einem Paket stattfinden können, wie beispielsweise:

– IP-Adressen und Portnummern können sich ändern. Dies wird normalerweise durch eine NAT bewirkt. Die Zuordnung zwischen "internen" und "externen" Adressen ist während einer bestimmten Kommunikation festgelegt; die Zuordnung könnte jedoch anders sein, wenn dieselben Adressen und Ports später erneut verwendet werden.
– IP-Optionen könnten entfernt werden. Zum Beispiel können einige Gateways sämtliche quellengesteuerte Routinginformationen entfernen.
– IP-Optionen können hinzugefügt werden. Zum Beispiel können einige Gateways IPSO- oder CIPSO-Optionen zu den Paketen hinzufügen.
– Das Paket wird zwischen IPv4 und IPv6 umgewandelt. Dies bringt Ändern des grundlegenden Kopfaufbaus, Ändern der Reihenfolge von IP-Optionen, Übersetzen von Adressen (obwohl dies manchmal ziemlich unkompliziert ist) mit sich, und es kann die Art und Weise ändern, wie MACs berechnet werden. Dies kann auch das Hinzufügen/Entfernen einiger Optionen mit sich bringen, während einige Optionen an das Pakt übertragen werden könnten. Das Paket könnte mehreren solchen Transformationen hin und her unterzogen werden, insbesondere in der Übergangsperiode, die während der nächsten Jahre wahrscheinlich eintritt. Der Sendeknoten und der Empfangsknoten können ein unterschiedliches Protokoll zur Kommunikation verwenden (z.B. verwendet der eine IPv4 und der andere IPv6). Es ist auch zu berücksichtigen, dass die verschiedenen Gatewayrealisierungen einige Optionen anders verarbeiten oder sie anders ordnen könnten.
– Das Paket könnte zwischen IP und irgendeinem völlig anderen Protokoll umgewandelt werden, oder es könnte zwischen zwei völlig verschiedenen Protokollen umgewandelt werden. Es kann äußerst schwierig oder undurchführbar werden, eine Paketauthentifizierung über solche Umwandlungen aufrechtzuerhalten, aber dies ist dennoch eine mögliche Anwendung dieser Erfindung.
– Der Datenabschnitt des Pakets könnte in einigen Situationen modifiziert werden, wie beispielsweise Modifizieren der IP-Adressen, die darin enthalten sind, in NAT-Geräten, um die so genannten DNS-Informationen so zu gestalten, dass sie den IP-Adressen entsprechen, die innerhalb der NAT zu sehen sind.

Der Vergleich kann durchgeführt werden, indem zuerst im Hinblick auf eine Umwandlung von einem Hauptprotokoll in ein anderes (z.B. IPv4 zu IPv6) geprüft wird. Für das IP kann der Rest des Vergleichs folgendermaßen durchgeführt werden:

– Der Kopf wird in Felder geteilt, z.B. IP-Ursprungsadresse, IP-Zieladresse, Protokoll (TCP/UDP/andere), Ursprungsport, Zielport, IP-Optionen, TCP/UDP-Optionen usw.
– Die meisten Felder können einfach verglichen werden (z.B. Adressen, Protokolle, Ports). Einige Transformationen sind stets eindeutig unannehmbar (z.B. die Protokollnummernänderung) und bewirken, dass der Vergleich misslingt. Andere Beschränkungen können durch Sicherheitsüberlegungen auferlegt werden.
– IP-Optionen können mehreren Arten von Änderungen unterzogen werden, wie beispielsweise Hinzufügung, Entfernung oder Neuordnung. Normalerweise weisen die meisten Pakete jedoch keine IP-Optionen auf, und es werden allgemein sehr wenige Optionen verwendet oder durch die lokale Sicherheitspolitik erlaubt. Wahrscheinlich werden noch weniger Optionen geändert. Höchstwahrscheinlich erlauben die Sicherheitsüberlegungen nur sehr spezifische Arten von Änderungen.
– TCP-Köpfe werden durch normale Netzgateways wahrscheinlich selten geändert. Die meisten Realisierungen können wahrscheinlich Änderungen in ihnen nicht zulassen.

Mit Sicherheitsüberlegungen ist gemeint, dass die Risiken dessen bestimmt werden, dass die Authentifizierungsprozedur entweder einen falschen Alarm schlägt, d.h. die Authentifizierung ablehnt, obwohl nur legale Transformationen stattfanden, oder eine illegale Transformation unbemerkt durchlässt. Der annehmbare Risikograd kann gemäß der Bedeutung der Daten, welche übertragen werden, variieren. Geeignete Risikograde und die daraus folgenden Beschränkungen dessen, was als eine legale Transformation angesehen wird, können durch Experimentieren ohne spezifische Erfindungsaktivität herausgefunden werden.
Es ist denkbar, dass die Transformationen, die auf einem Pfad durch ein Netz stattfinden, sich plötzlich ändern könnten, während eine Kommunikation aktiv ist. Dies könnte z.B. passieren, wenn eine Verbindung aufgerüstet wird, um IPv6 anstelle von IPv4 zu verwenden. Derartige Änderungen sind selten und können wahrscheinlich ignoriert werden. Wenn jedoch gewünscht wird, sie zu bewältigen, ist es möglich, die dynamische Ermittlungsprozedur erneut durchzuführen, wenn mitten in einer aktiven Kommunikation falsch authentifizierte Pakete empfangen werden. Wenn solch eine Neuermittlung unterstützt wird, muss jedoch darauf geachtet werden, dass, um Dienstverweigerungsangriffe zu vermeiden, nur ein paar falsch authentifizierte Pakete gesendet werden.
Sicherheitsüberlegungen sind bei der Durchführung einer dynamischen Ermittlung der Transformationen entscheidend.
Es sind nur einige Arten von Transformationen annehmbar. Wenn beliebige Transformationen erlaubt werden würden, könnten Angreifer IP-Adressen und Ports nach Belieben fälschen, indem sie das andere Ende glauben lassen, dass eine Transformation im Netz stattgefunden hat.
Das Sicherheitsproblem ist aufgrund der Tatsache, dass NATs häufig die tatsächlichen IP-Adressen des Sendeknotens und des Empfangsknotens verbergen, kompliziert. Jede Partei kann dann nur Adressen sehen, die zur Firewall des anderen Endes gehören, nicht aber Adressen von tatsächlichen Maschinen.
Wenn davon ausgegangen wird, dass eine Kompensation von Transformationen dadurch erfolgt, dass ein Ende die Adresse, die am anderen Ende während einer MAC-Berechnung oder -Verifizierung zu sehen ist, ersetzt, muss der Knoten, der die Ersetzung durchführt, die echte IP-Adresse des anderen Knotens kennen.
Es gibt aber eine Möglichkeit, dieses Erfordernis zu vermeiden. Wenn jeder Knoten hinter einer NAT die IP-Adresse (und andere Informationen) erfahren kann, die er außerhalb des NAT-Gateways haben wird, kann er den MAC unter Verwendung dieser Informationen berechnen, und er kann diese Information dem Empfangsknoten als seine echte Adresse kommunizieren. Eine ähnliche Vorgehensweise gilt für den Empfangsknoten.
Kehren wir zu den Sicherheitsüberlegungen zurück. Im Grunde wird gewünscht, zu authentifizieren, dass die empfangenen Pakete tatsächlich von dem Sendeknoten stammen, von dem sie anscheinend herkommen. Es gibt mehrere mögliche Quellen von Informationen über den wahren Sendeknoten, welche umfassen:

– Sie können durch den Sendeknoten mit dem Paket (mitlaufende Sondierung) gesendet und durch Verwenden irgendeines Authentifizierungsschlüssels, den die Partner vereinbart haben, authentifiziert werden. Die Identität des Sendeknoten wurde dem Empfangsknoten zur Kenntnis gebracht, als sie den Authentifizierungsschlüssel vereinbarten.
– Sie können unter Verwendung des Schlüsselverwalters als die Identität, die mit der bestimmten Sicherheitsverbindung verbunden ist, übertragen worden sein. Die Informationen wurden während des Schlüsselaustausches zwischen den Schlüsselverwaltern authentifiziert.
– Sie können in einem Sondierungspaket gesendet und durch irgendeinen Authentifizierungsschlüssel, der für die Sicherheitsverbindung vereinbart wurde, authentifiziert werden.

In der Annahme, dass das Paket durch kryptografische Mittel (sowohl Paketauthentifizierung als auch Geheimhaltungsschutz) ausreichend geschützt ist, interessiert es auch nicht wirklich, auf welche Weise es durch das Netz läuft. In diesem Sinne interessieren uns die IP-Adressen oder Ports im Paket nicht, solange wir sicher sind, dass die Codierungsinformationen mit dem entsprechenden echten Endpunkt ausgehandelt wurden. Die Informationen müssen (ungeachtet dessen, ob wir die vorliegenden Erfindung anwenden) mit anderen Mitteln als den IP-Adressen authentifiziert werden, da IP-Adressen unzuverlässig sind.
Es gibt mehrere bekannte Verfahren, die gegenwärtig zum Authentifizieren des anderen Kommunikationsknotens und Verifizieren seiner Autorisation zu kommunizieren verwendet werden, wobei sie umfassen:

– manuell konfigurierte feste Schlüssel ("Sie dürfen mit jedem kommunizieren, der den Schlüssel kennt")
– dynamisch vereinbarte Schlüssel, die durch einen im vorab geteilten Geheimcode authentifiziert werden ("Sie dürfen mit jedem kommunizieren, der den Geheimcode kennt")
– Zertifikat durch eine verlässliche CA ("Sie dürfen mit jedem kommunizieren, der ein Zertifikat durch die verlässliche CA besitzt")
– Zertifikat durch eine verlässliche CA für einen bestimmten Netzadressbereich ("Sie dürfen mit jedem kommunizieren, der ein Zertifikat durch eine verlässliche CA für die IP-Adresse, die sie verwenden, vorweisen kann")
– Zertifikat durch eine verlässliche Zertifizierungsstelle, das dem anderen Knoten die Genehmigung erteilt, mit einem anderen Knoten zu kommunizieren (z.B. unter Verwendung eines SKPI-Zertifikats)
– andere Formen und eine andere Politik sind ebenso möglich und werden in den kommenden Jahren wahrscheinlich entwickelt.

Einige dieser Verfahren liefern direkt die Identität des entfernten kommunizierenden Knotens oder Benutzers (z.B. in Form eines Namens, der mit dem Zertifikat durch eine verlässliche CA verbunden ist), einige liefern nur eine Autorisation, sagen aber nichts über die Identität des entfernten Knotens oder Benutzers aus.
Auf jeden Fall haben die IP-Adresse und die Portnummer, die durch den entfernten Knoten verwendet werden, einen geringen Wert für Authentifizierungszwecke, wenn NAT verwendet wird, da die Adresse mehr oder weniger zufällig sein wird (normalerweise innerhalb eines Adressbereichs).
Es ist daher der Fall, dass die IP-Adresse und der Port zur Authentifizierung bei Vorhandensein von NAT nicht wirklich verwendbar sind, selbst wenn der Verkehr ansonsten authentifiziert wird. Die Authentifizierung von kommunizierenden Knoten muss unter Verwendung von Zertifikaten oder anderen Informationen erfolgen, die als Teil des Schlüsselaustauschprotokolls ausgetauscht wurden.
Somit achten wir nicht wirklich auf die IP-Adresse, die dem Empfangsknoten gezeigt wird. Diese Adresse braucht nicht authentifiziert zu werden (und es gibt nicht viel, was getan werden könnte, um sie zu authentifizieren, außer des Erfordernisses eines Zertifikats, welches den Bereich von Adressen auflistet, in die das NAT-Gateway sie übersetzen könnte).
Die Informationen, die dem Knoten, der eine Kompensation durchführt, kommuniziert werden, sollten jedoch authentifiziert werden, um Angriffe zu vermeiden, bei denen eine Scheinadresse geliefert wird, um Änderungen irgendwo anders im Paket zu kompensieren. Es kann argumentiert werden, dass ein guter MAC die Bestimmung einer Kompensationsadresse nicht erlauben würde, aber es ist sicherer, die Adresse stets zu authentifizieren. Es kann dienlich sein, die kommunizierten Informationen unter Verwendung desselben Authentifizierungsschlüssels zu authentifizieren, der zum Authentifizieren des Restes des Pakets verwendet wird.
Die lokale Sicherheitspolitik eines Knotens bestimmt, welche Transformationen sie für jede Form von erhaltener Authentifizierung für annehmbar hält. Es sind viele solche Arten von Politik möglich. Eine mögliche Politik wird im Folgenden zusammengefasst:

– Keine Änderungen in anderen Protokollen als IPv4 und IPv6 erlauben.
– Transformation von IPv4 zu IPv6 akzeptieren und Formatänderungen kompensieren.
– beliebige Änderungen der Ursprungsadresse und des Ursprungsports des Initiators der Kommunikation akzeptieren; keine Änderungen der Zieladresse des Initiators oder der Ursprungsadresse des Antwortenden erlauben, außer wenn durch das Zertifikat des Antwortenden ausdrücklich erlaubt. Die Übersetzung zwischen einer IPv4- und der entsprechenden IPv6-Adresse wird jedoch stets erlaubt.
– Keine Änderungen der Protokollnummern (TCP zu UDP zu anderen) erlauben; Portnummern für andere Protokolle als TCP und UDP ignorieren.
– Keine Änderungen der IP-Optionen, TCP-Optionen oder anderer Teile eines Pakets akzeptieren.

Die Erfindung schränkt die Wahl der Politik nicht ein.
Die Sicherheitspolitik wird für gewöhnlich als eine Prüfung im Hinblick auf eine Konfigurationsdatenbank realisiert. In einigen Anwendungen sind die Sicherheitspolitik oder einige Aspekte davon jedoch statisch. Solche statischen Aspekte werden häufig implizit im Code realisiert. Zum Beispiel könnte das Erlauben irgendeiner Änderung irgendeines Kopffeldes einfach als Nichtüberprüfen dieses Feldes realisiert werden. Gleichermaßen kann das Erfordernis, dass irgendein Feld (oder Protokoll) einen spezifischen Wert aufweist, ein einfacher Vergleich sein und z.B. durch einen Paketroutingcode oder einen anderen unbezogenen Code auf der Plattform, auf der das Verfahren realisiert wird, sogar implizit ausgeführt werden.
Sobald die Transformationen, die stattfinden, bestimmt wurden, müssen sie durch einen oder beide der kommunizierenden Knoten kompensiert werden, was das dritte Teilproblem ist, das zuvor definiert wurde. Wenn eine mitlaufende Sondierung verwendet wird, enthält das Sondierungspaket selbst genügend Informationen für den Empfangsknoten, um alle annehmbaren Transformationen zu kompensieren; solche Informationen in jedes Paket einzubinden ist jedoch nicht wünschenswert, da dies Netzbandbreite vergeudet. Demnach ist es wahrscheinlich wünschenswert, im kompensierenden Knoten Aufzeichnungen über die Transformationen zu machen, die stattfinden, und die Transformationen unter Verwendung der aufgezeichneten Informationen zu kompensieren, statt explizite Kompensationsinformationen in jedes Paket einzubinden.
Kompensation kann entweder erfolgen, wenn der MAC berechnet wird wenn ein Paket gesendet wird, oder wenn der MAC nach Empfang eines Pakets verifiziert wird.
Der MAC wird normalerweise aus den Paketinhalten und einem Geheimschlüssel durch Verwenden einer geeigneten kryptografisch soliden Hash-Funktion (oder anderen Funktion, welche Bits auf eine unlösbare Weise zusammenmischt) berechnet, wie folgt:

– Der Geheimschlüssel wird in den MAC eingebunden.
– Die Paketdaten werden in den MAC eingebunden.
– Alle anwendbaren Teile des Paketkopfes werden in den MAC eingebunden. Es gibt einige Felder, welche sich normalerweise ändern, während ein Paket übertragen wird, wie beispielsweise das TTL-Feld. Diese werden nicht in die MAC-Berechnung einbezogen (oder werden vor der MAC-Berechnung auf Null gesetzt). Die meisten anderen Felder werden in die MAC-Berechnung einbezogen.
– Ursprungs- und Zieladressen werden normalerweise in die MAC-Berechnung einbezogen.

Im ESP umfasst der MAC normalerweise nur Paketdaten, nicht den Kopf. Übergeordnete Protokollprüfsummen (z.B. TCP- oder UDP-Prüfsummen) können jedoch Daten vom Kopf enthalten.
Der MAC ist normalerweise ein Bitvektor, wobei jedes Bit von jedem Bit abhängt, das auf eine unlösbare Art und Weise in den MAC eingebunden ist. Die Anzahl von Bits im MAC ist groß genug (mit anderen Worten, der MAC ist solide genug), so dass es nicht möglich ist, Daten zu finden, welche mit einem konkreten MAC übereinstimmen. Die Idee ist, dass es nicht möglich ist, einen MAC zu erzeugen, der mit einem bestimmten Schlüssel ohne Kenntnis des Schlüssels erfolgreich verifiziert werden könnte.
Um Transformationen am Sendeknoten zu kompensieren, wendet der Sendeknoten die Transformationen an, welche durch den Empfangsknoten zu sehen sind, bevor er den MAC berechnet. Demnach stimmt der MAC in dem gesendeten Paket nicht mit dem Paket überein, das der Sendeknoten sendet, sonder er stimmt mit dem Paket überein, das der Empfangsknoten sieht.
Um Transformationen am Empfangsknoten zu kompensieren, wendet der Empfangsknoten Rücktransformationen auf die empfangenen Daten an, bevor er den MAC berechnet. Demnach sendet der Sendeknoten ein Paket, das einen korrekten MAC aufweist, und der Empfangsknoten wandelt das Paket in die Form um, die durch den Sendeknoten vor dem Verifizieren des MACs gesendet wurde.
Neben dem Kompensieren von Änderungen nur im MAC kann der kompensierende Knoten zusätzliche Kompensationsoperationen durchführen, die normalerweise durch das NAT-Gerät durchgeführt werden würden, wenn keine Paketauthentifizierung stattfand. Zum Beispiel können die TCP- oder die UDP-Prüfsumme gemäß den Änderungen, die dem Paket widerfahren sind, aktualisiert werden. Solch eine Aktualisierung kann entweder als eine inkrementale Aktualisierung (wobei im Wesentlichen alte Werte abgezogen und neue Werte zur Prüfsumme addiert werden) oder durch Neuberechnen der gesamten Prüfsumme realisiert werden.
Im Falle von ESP-Paketen ist es manchmal möglich, die dynamische Ermittlung und den MAC-Kompensations-Teilprozess ganz zu vermeiden. Dem ist so, da der ESP-Paketkopf nicht in den MAC eingebunden ist, weshalb der MAC nicht berechnet werden muss. Die Sicherheitspolitik kann festlegen, dass jegliche Transformation im Paketkopf (IP-Adressen) annehmbar ist, solange ein gültiger MAC im Paket vorhanden war. Wenn die Operation über NAT nur für ESP und nur mit einer festgelegten Sicherheitspolitik, die jegliche Änderung im äußeren IP-Kopf erlaubt, unterstützt zu werden braucht, dann kann diese Erfindung so realisiert werden, dass die Prüfsumme jedes empfangenen TCP- oder UDP-Pakets einfach neu berechnet wird.
Manchmal enthält das authentifizierte/verschlüsselte Paket Netzadressen innerhalb des Datenabschnitts. Ein Beispiel ist ein DNS-Paket (DNS für Domänennamensystem); solche Pakete werden verwendet, um Hostnamen IP-Adressen zuzuordnen. Viele NATs führen Transformationen der Inhalte von DNS-Paketen durch; solche Transformationen werden unmöglich, wenn die Paketinhalte geschützt sind. In solch einem Fall ist es möglicherweise notwendig, einige oder alle der Transformationen der Paketinhalte als Teil der Kompensationsphase durchzuführen.
Einige NATs können auch das Sicherheitsprotokoll, wie beispielsweise IPSEC, erkennen und spezielle Zuordnungen zu den Sicherheitsparameterindexwerten (SPI für engl. Security Parameter Index) in den Paketen vornehmen. Die Kompensation kann auch das Ändern des SPI-Wertes auf den im ursprünglichen Wert umfassen. In solch einer Situation würde der ursprüngliche Wert im Sondierungspaket kommuniziert werden.
Betrachten wir nun eine mögliche Realisierung dieser Erfindung im Einzelnen unter Bezugnahme auf das Flussdiagramm in 10. Der Einfachheit halber befasst sich diese Realisierung nur mit dem IPv4-Protokoll und ist nur zur Bewältigung von IPv4-NATs (IP-Adress- und Porttransformationen für TCP- und UDP-Protokolle) bestimmt. Für Fachleute ist jedoch ersichtlich, dass dies erweitert werden könnte, um IPv4–IPv6-Protokollumwandlungen oder andere Arten von Transformationen zu bewältigen. Es wird davon ausgegangen, dass der IPSEC-Mechanismus zur Authentifizierung von IPv4-Paketen verwendet wird. Verschlüsselung wird nicht berücksichtigt; die Authentifizierung kann jedoch ebenso unter Verwendung von ESP-Köpfen eventuell zusammen mit Verschlüsselung erfolgen, wie es hier unter Verwendung von AH-Köpfen beschrieben wird.
Die kommunizierenden Knoten werden Initiator und Responder genannt. Der Initiator ist der Knoten, der das erste Paket sendet, um mit Kommunikationen zu beginnen; der Responder ist derjenige, dem das erste Paket zugesendet wird (und der normalerweise auf dieses Paket durch Zurücksenden eines oder mehrerer Antwortpakete antwortet). In der folgenden Beschreibung beschränken wir uns auf den Fall, in dem ein NAT-Gateway den Initiator vom Internet trennt, und der Responder im Internet unter Verwendung seiner eigenen IP-Adresse und echten Portnummern sichtbar ist. Dieser allgemeine Aufbau ist an sich bekannt und wurde in 1 veranschaulicht.
Wenn der Initiator wünscht, mit dem Responder zu kommunizieren, und die beiden in letzter Zeit nicht miteinander kommuniziert haben (d.h. es wurde noch keine Sicherheitsverbindung zwischen ihnen eingerichtet), beginnt der Initiator zuerst mit einem ISAKMP-Austausch, der allgemein mit 1001 bezeichnet ist, mit dem Responder. Dies geschieht normalerweise durch Senden eines UDP-Pakets an den Port 500 (wobei 500 die Portnummer und kein Bezugszeichen ist) an der IP-Adresse des Responders. Die NAT ersetzt die Ursprungsadresse und den Ursprungsport im Paket. Die Schlüsselverwalter des Initiators und des Responders tauschen ISAKMP-Pakete aus und richten eine ISAKMP-Sicherheitsverbindung zwischen den Schlüsselverwaltern ein. Als Teil dieses Vorgangs authentifizieren (oder autorisieren) sie einander unter Verwendung irgendeines Verfahrens, das durch ISAKMP unterstützt wird.
Als Nächstes wird auf der Stufe, die allgemein mit 1002 bezeichnet ist, eine IPSEC-Sicherheitsverbindung (SA für engl. security association) zwischen dem Initiator und dem Responder (in Wirklichkeit zwei, nämlich eine in jeder Richtung) erzeugt. Ein gemeinsam benutzter Geheimcode ist mit jeder SA verbunden, welcher verwendet wird, um Codierungsmaterial für die IPSEC-Transformationen (Verschlüsselungs- und Authentifizierungsalgorithmen) abzuleiten, das verwendet wird, um den Verkehr zu schützen, der unter Verwendung der SA gesendet wird.
Es ist möglich, dass den ISAKMP-Paketen während des Schlüsselaustausches einige Transformationen zustießen. Diese Transformationen können jedoch nicht verwendet werden, um die Transformationen zu bestimmen, welche den Datenpaketen zustoßen, da die Daten unter Verwendung einer anderen Portnummer übertragen werden und eine andere Zuordnung aufweisen könnten. Bis zu diesem Punkt erfolgte der Verbindungsaufbau gemäß dem Stand der Technik.
Das erste Datenpaket wird dann auf Stufe 1003 vom Initiator an den Responder gesendet. Das Paket wird authentifiziert und anderweitig geschützt, wobei die AH- und ESP-Köpfe verwendet werden, wie während des Schlüsselaustausches ausgehandelt. Zusätzlich wird dem Paket eine spezielle IP-Option hinzugefügt. Diese IP-Option hat eine spezielle reservierte Nummer und wird verwendet, um die Transformationseigenschaften des Kommunikationskanals zwischen dem Initiator und dem Responder zu sondieren. Dies ist eine Variante der ununterbrochenen mitlaufenden Sondierung. Das Format und die Inhalte dieser Option werden in 11 beschrieben. Der MAC 1101 kann zum Beispiel die ersten 96 Bits der HMAC-SHA1 des Restes der Option sein, welche denselben Schlüssel verwendet wie die Authentifizierungstransformation, die für das Paket verwendet wird. Der Wert des Feldes "Sondierung empfangen" 1102 ist FALSCH, um anzuzeigen, dass noch kein Sondierungspaket von der anderen Seite empfangen wurde. Realisierungsspezifische Daten 1103 können alle Daten sein, die der anderen Seite zu kommunizieren sind, wie beispielsweise Informationen über die Merkmale, die durch den Initiator unterstützt werden. Der ursprüngliche IP-Kopf, als das Paket gesendet wurde 1104, ist ebenfalls dargestellt.
Es ist interessant, festzustellen, dass, auch wenn NATs Portnummern ändern, die AH/ESP-Einkapselung den TCP/UDP-Kopf vor der NAT verbirgt, weshalb die NAT Portnummern höchstwahrscheinlich nicht modifizieren kann. Dies kann sich aber auch als nachteilig für die NAT-Leistung erweisen, da nun für jede interne Adresse, die eine Verbindung offen hat, eine externe Adresse zugeordnet werden muss, anstatt durch Modifizieren von Portnummern mehrere auf dieselbe Adresse zu multiplexen. Diese Erfindung ist auch auf jene Fälle anwendbar, in welchen eine NAT Portnummern innerhalb eines AH/ESP-Kopfes ändert.
Wenn vor dem Empfangen einer Sondierungsantwort andere Pakete durch den Initiator an den Responder gesendet werden, enthalten diese Pakete eine ähnliche Sondierungsoption.
Wenn der Responder auf Stufe 1004 ein Paket dieses Formats empfängt, vergleicht er Daten in der empfangenen Sondierungsoption mit Informationen im empfangenen IP-Paket. Er verwendet diesen Vergleich, um eine Rücktransformation für die Transformation zu erzeugen, welche stattfand, während das Paket unterwegs war. Diese Daten werden zur Verwendung bei der Verarbeitung zukünftiger Pakete, die unter Verwendung derselben SA empfangen werden, und, um dem Initiator zu antworten, wenn das erste Paket an ihn gesendet wird, aufgezeichnet.
Wenn der Responder auf Stufe 1005 sein erstes Paket an den Initiator sendet, überprüft er, ob eine Sondierungsoption im ersten Paket vorhanden war, das er vom Initiator empfangen hatte. Wenn dies der Fall ist, bindet er seine eigene Sondierungsoption ein. Diese Sondierungsoption ist mit jener, die durch den Initiator gesendet wurde, identisch, mit der Ausnahme, dass das Feld "Sondierung empfangen" WAHR ist, um anzuzeigen, dass der Responder bereits eine Sondierung empfangen hat und keine Sondierungen mehr durch den Initiator gesendet zu werden brauchen.
In seinem nächsten Paket nach Empfang dieses Pakets auf Stufe 1006 bindet der Initiator noch eine Sondierungsoption ein, welche nun "Sondierung empfangen" WAHR aufweist, um anzuzeigen, dass der Responder keine Sondierungen mehr zu senden braucht. Wenn der Austausch von Paketen reibungslos abgelaufen ist, ist die dynamische Ermittlung von Adressübersetzungen (und Protokollumwandlungen, obwohl unter Bezugnahme auf 10 nicht eigens erörtert) vollendet, und der Initiator und der Responder können mit dem Austauschen von Paketen fortfahren, wobei die Verarbeiten von zukünftigen Paketen, die unter Verwendung derselben SA empfangen werden, gemäß den Informationen über die Adressübersetzungen (und Protokollumwandlungen), die auf den Stufen 1004 und 1006 gespeichert wurden, erfolgt.
Es könnten jedoch Komplikationen auftreten. Das System muss mit verlorenen Paketen umgehen können. Es besteht auch eine geringe Möglichkeit, dass der Responder spontan wünschen könnte, ein Paket an den Initiator zu senden, nachdem die SAs zwischen ihnen getroffen wurden, aber bevor er das erste Paket vom Initiator empfangen hat.
Der richtige Ablauf in Bezug auf das Senden von Sondierungen kann durch die Zustandsmaschine von 12 zusammengefasst werden. Das Zustandskonzept betrifft jede SA getrennt.
Ein Problem, das zuvor noch nicht angesprochen wurde, ist die Granularität von Sicherheitsverbindungen gegenüber der Granularität von Transformationsinformationen. Eine SA könnte zwischen ganzen Teilnetzen, welche mehrere Hosts umfassen, sein, oder sie könnte z.B. nur für ein TCP/IP-Portpaar sein. Demgegenüber sind Transformationsinformationen normalerweise konstant nur pro Host oder sogar nur pro Port (sie können nicht pro Port sein, wenn Portinformationen infolge von AH- und ESP-Köpfen für die NAT nicht sichtbar sind).
Dies wirft die Frage auf, wo die Informationen über die Transformationen zu speichern sind, in der SA oder in einer getrennten Datenstruktur, welche die Transformationsinformationen für jeden Host/Port speichert, und die möglicherweise mit der SA verbunden ist. Beide Ansätze sind möglich. Hier wird davon ausgegangen, dass eine getrennte Datenstruktur verwendet wird, um die Transformationsinformationen für jeden Host, der durch die SA erfasst wird, getrennt aufzuzeichnen.
13 ist ein vereinfachtes Blockdiagramm eines Netzgeräts 1300, das im Verfahren von 10 als der Initiator oder Responder fungieren kann. Die Netzschnittstelle 1301 verbindet das Netzgerät 1300 physikalisch mit dem Netz. Der Adressverwaltungsblock 1302 merkt sich sowohl die korrekten Netzadressen, Portnummern und anderen wichtigen öffentlichen Identifikationsinformationen des Netzgeräts 1300 selbst als auch die seines Partners (nicht dargestellt). Der ISAKMP-Block 1303 ist für den Schlüsselverwaltungsprozess und andere Aktivitäten verantwortlich, die mit dem Austausch von geheimen Informationen verbunden sind. Der Ver- und Entschlüsselungsblock 1304 realisiert die Verschlüsselung und Entschlüsselung von Daten, sobald der Geheimschlüssel durch den ISAKMP-Block 1303 erhalten wurde. Der Kompensationsblock 1305 wird verwendet, um zulässige Transformationen in den gesendeten und/oder empfangenen Paketen gemäß der Erfindung zu kompensieren. Der Paketier- und Depaketierblock 1306 ist der Vermittler zwischen den Böcken 1302 bis 1305 und der physikalischen Netzschnittstelle 1301. Alle Blöcke arbeiten unter der Aufsicht eines Steuerblocks 1307, der auch für das Routen von Informationen zwischen den anderen Blöcken und dem Rest des Netzgeräts sorgt, zum Beispiel um dem Benutzer durch eine Anzeigeeinheit (nicht dargestellt) Informationen anzuzeigen und durch eine Tastatur (nicht dargestellt) Befehle vom Benutzer zu erhalten. Die Blöcke von 13 werden am vorteilhaftesten als vorprogrammierte Arbeitsabläufe eines Mikroprozessors realisiert, wobei die Realisierung an sich den Fachleuten bekannt ist. Andere Anordnungen als die in 13 dargestellte können ebenso verwendet werden, um die Erfindung in die Praxis umzusetzen.

Claims

Verfahren zum Erreichen von Paketauthentifizierung gemäß einer anwendbaren Sicherheitspolitik zwischen einem Sendeknoten (903) und einem Empfangsknoten (902) in einem Netz, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst: Bestimmen der Transformationen, die einem Paket auf dem Weg zwischen dem Sendeknoten und dem Empfangsknoten zustoßen, basierend auf Sondierungsinformationen in einem Paket; Überprüfen (1004), dass die bestimmten Transformationen basierend auf der anwendbaren Sicherheitspolitik annehmbar sind; und Kompensieren (1004, 1006) der bestimmten annehmbaren Transformationen vor dem Authentifizieren von Paketen, die vom Sendeknoten an den Empfangsknoten übertragen werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass jedes Paket, das vom Sendeknoten (903) an den Empfangsknoten (902) übertragen wird, einen kryptografischen Authentifizierungscode (1101) umfasst, der sich von einem Geheimschlüssel und den Inhalten des Originalpakets herleitet.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass zum Kompensieren der bestimmten Transformationen die Inhalte eines Originalpakets am Sendeknoten (903) vor dem Berechnen des kryptografischen Authentifizierungscodes (1101) manipuliert werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass zum Kompensieren der bestimmten Transformationen die Inhalte eines empfangenen Pakets am Empfangsknoten (902) vor dem Verifizieren des kryptografischen Authentifizierungscodes (1101) manipuliert werden.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass wenigstens ein Datenpaket (602, 901), das vom Sendeknoten (903) an den Empfangsknoten (902) übertragen wird, eine gesicherte Kopie wenigstens eines Teils des Originalpaketkopfes (1104) enthält und der Empfangsknoten die gesicherte Kopie im Paketkopf beim Verifizieren des kryptografischen Authentifizierungscodes eines empfangenen Pakets verwendet.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass jede gesicherte Kopie in einer Sonderoption des Paketkopfes gespeichert wird.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Sonderoption eine IP-Option ist.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die gesicherte Kopie kryptografisch authentifiziert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das zugrunde liegende Protokoll, das beim Übertragen von Paketen vom Sendeknoten an den Empfangsknoten angewendet wird, das IPv4-Protokoll ist und die Paketauthentifizierung unter Verwendung des IPSEC-Protokolls erfolgt.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das zugrunde liegende Protokoll, das beim Übertragen von Paketen vom Sendeknoten an den Empfangsknoten angewendet wird, das IPv6-Protokoll ist.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Transformationen IP-Adressübersetzungen (100) umfassen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Transformationen TCP/UDP-Portübersetzungen umfassen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Kompensierens (1004, 1006) der bestimmten annehmbaren Transformationen den Unterschritt des Aktualisierens einer TCP- oder UDP-Prüfsumme umfasst.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Transformationen die Umwandlung zwischen IPv4- und IPv6-Protokollen umfassen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Bestimmung das Verwenden eines Sondierungsverfahrens umfasst, das von den folgenden genommen wird: ununterbrochene mitlaufende (in-line) Sondierung, unterbrochene mitlaufende (in-line) Sondierung, getrennte Sondierung.
Verfahren nach Anspruch 15, wobei das Sondierungsverfahren den Schritt des Sendens einer Sondierung (1003) vom Sendeknoten an den Empfangsknoten umfasst, dadurch gekennzeichnet, dass die Sondierung ein Paket ist, das an dieselbe Netzadresse wie normale Datenpakte gesendet wird.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass als eine Antwort auf den Empfang der Sondierung der Empfangsknoten eine Sondierungsantwort (1005) an den Sendeknoten sendet.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die kommunizierenden Knoten aushandeln, ob sie beide eine Authentifizierung beim Vorhandensein von Transit-Transformationen unterstützen.
Netzgerät (1300) zum Empfangen von Paketen von einem anderen Netzgerät, dadurch gekennzeichnet, dass es Mittel (1305, 1306, 1307) umfasst zum Bestimmen der Transformationen, die einem empfangenen Paket auf dem Weg von einem anderen Netzgerät zustoßen, basierend auf Sondierungsinformationen in einem empfangenen Paket, Überprüfen, dass die bestimmten Transformationen basierend auf der anwendbaren Sicherheitspolitik annehmbar sind, und Kompensieren der bestimmten annehmbaren Transformationen vor dem Authentifizieren eines empfangenen Pakets.
Verfahren zum Verarbeiten von Paketen in einem Empfangsknoten (902) in einem Netz, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst: Bestimmen der Transformationen, welche Paketen auf dem Weg zwischen einem Sendeknoten und dem Empfangsknoten zustoßen, basierend auf Sondierungsinformationen in einem Paket, Überprüfen (1004), dass die bestimmten Transformationen basierend auf der anwendbaren Sicherheitspolitik annehmbar sind, und Kompensieren (1004, 1006) der bestimmten annehmbaren Transformationen vor dem Authentifizieren von empfangenen Paketen.