-
TECHNISCHES
GEBIET
-
Diese
Erfindung stellt eine Technik für
die Herstellung einer sicheren Internet-Kommunikation zwischen zwei
Entitäten
bereit.
-
HINTERGRUND
TECHNIK
-
Das
IPsec (Internet-Sicherheitsprotokoll) ist ein von dem Internet Engineering
Taskforce (ITEF) veröffentlichtes
Protokoll für
die Herstellung von Sicherheit in der Netzwerk(Paket)-Verarbeitungsschicht.
Gegenwärtig
ist das IPsec-Protokoll vielversprechend in Bezug auf das Virtuelle
Private Netzwerk und entfernte Anwendungen für Verbindungsaufbau. Ein Benutzer,
der das IPsec-Protokoll verwendet, gerät jedoch für gewöhnlich in Schwierigkeiten bei
der Überquerung
von Vorrichtungen für
Netzwerk-Adressumwandlung (NAT) und Firewalls, für die der Benutzer über keine
Steuerung verfügt.
Derartige Schwierigkeiten setzen den Verwendungswert des IPsec-Protokolls
sehr stark herab. Aus diesem Grund haben die meisten Verkäufer von
Hardware/Software für
IPsec-Sicherheit proprietäre
Tunnel-Protokolle für den
Transport von IPsec-Paketen in dem Bestreben entwickelt, dieses
Problem zu bewältigen.
-
Die
Verwendung eines proprietären
Tunnel-Protokolls zieht gewisse Nachteile im Vergleich zu der Verwendung
eines offenen (nicht-proprietären)
Tunnel-Protokolls nach sich. Im Gegensatz zu einem offenen Tunnel-Protokoll,
dessen Spezifikation weit verbreitet ist, bleiben die mit proprietären Tunnel-Protokollen assoziierten
Details für
gewöhnlich
vertraulich, was weniger Zuversicht in die Sicherheitseigenschaften
der Protokolle gewährt.
Somit hat bei den meisten proprietären Tunnel-Protokollen der assoziierte
Quellcode keine gleichrangige Bewertung genossen und die begleitende
Identifizierung von Fehlern kann durch Hacker ausgenutzt werden.
Außerdem
verfügen
offene Tunnel-Protokolle
im Allgemeinen über
keine Lizenzeinschränkungen
im Gegensatz zu proprietären
Tunnel-Protokollen.
-
Die
US 2001/0020273 A1 (D1) lehrt ein Verfahren der Kommunikation für ein virtuelles
privates Netzwerk (VPN), das es einem Sender, z. B. einem Personalcomputer
(PC), außerhalb
eines lokalen Netzwerkes (LAN) gestattet, über ein weites Netzwerk (WAN)
auf einen Empfänger,
z. B. einem Endgerät,
auf dem LAN zuzugreifen. Der äußere Sender wird
somit virtuell als ein Endgerät
auf dem LAN betrachtet. Gemäß dem Verfahren,
das durch D1 offenbart wird, erzeugt der äußere Sender ein Paket für die Übertragung
zu dem LAN-Empfänger
und überträgt dieses
Paket zu einem Mittler, z. B. einem Sicherheits-Gateway. Der Mittler
(Sicherheits-Gateway) empfängt
das Paket und hüllt
das Paket gemäß der Information
ein, die über
eine frühere
Internet-Schlüsselaustausch(IKE)-Kommunikation
mit dem LAN-Empfänger
ausgetauscht wurde. Der Sicherheits-Gateway fügt ferner eine Authentifizierungsinformation
hinzu und verschlüsselt
das Paket und sendet anschließend
das Paket zu dem LAN-Empfänger,
der die in dem Paket enthaltene Information wiedergewinnt und verarbeitet.
-
Die
WO 01/15396 A1 beschreibt einen Circuit-Emulator-Dienst über ein
Internetprotokoll(IP)-Netzwerk, in dem ein IPSec-Header optional mit
einem L2TP-Header verwendet wird.
-
Somit
ist ein Bedarf nach einem offenen Tunnel-Protokoll für den Transport
von IPsec-Paketen vorhanden, das die Nachteile des Standes der Technik überwindet.
-
KURZE ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
Erfindung sieht ein Verfahren vor, das wie in Anspruch 1 bestimmt
ist. Kurz gesagt wird gemäß einer
ersten bevorzugten Ausführungsform
der Erfindung eine Technik zum Senden eines IPsec-Pakets von einem
ersten IPsec-Client zu einem zweiten IPsec-Client bereitgestellt,
so dass das Paket bei dem Ereignis der Überquerung einer Firewall und/oder
einer Vorrichtung für
Netzwerk-Adressumwandlung (NAT) unberührt bleibt. Um eine derartige Übertragung
eines IPsec-Pakets zu bewerkstelligen, wird das IPsec-Paket in ein
offenes (z. B. nicht-proprietäres)
Tunnel-Protokoll-Format
verpackt, wie z. B. das Layer-2-Tunneling-Protokoll-(L2TP)-Format, und wird von
dem ersten IPSec-Client an einem L2TP-Netzwerkserver in einem Kommunikations-Netzwerk
empfangen. Der L2TP-Netzwerkserver erstellt einen L2TP-Tunnel zu
dem zweiten IPSec-Client und stellt dann eine Sicherheitsverbindung
zwischen den IPsec-Clients her. Danach sendet der L2TP-Netzwerkserver
das Paket zu dem zweiten IPsec-Client, so dass das Paket bei dem
Ereignis der Überquerung
einer Firewall und/oder einer Vorrichtung für Netzwerk-Adressumwandlung
unberührt
bleibt.
-
Das
L2TP kann L2TP-formatierte Pakete von dem ersten IPsec-Client über eine
zugeordnete Verbindung (z. B. einen Tunnel) empfangen, die von dem ersten
IPsec-Client geöffnet
wurde. Alternativ kann der erste IPsec-Client auf den L2TP-Netzwerkserver über das öffentliche
Internet unter der Voraussetzung zugreifen, dass die Firewall-Richtlinien
des L2TP-Netzwerkservers öffentlich
gerouteten Verkehr zulassen. Falls eine oder mehrere NAT-Vorrichtungen
den ersten und zweiten IPsec-Client separieren, können beide
Clients eine Kommunikationssitzung beginnen, indem jeder einen Tunnel
zu dem L2TP-Netzwerkserver öffnet,
wodurch es den Clients gestattet wird, miteinander zu kommunizieren,
während
sie eine beliebige NAT-Vorrichtung umgehen.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
1 stellt
eine erste Ausführungsform
einer Netzwerk-Architektur
zur Befähigung
eines ersten IPsec-Clients für
die Korrespondenz eines IPsec-formatierten Pakets zu einem zweiten
IPsec-Client dar;
-
2 stellt
eine zweite Ausführungsform
einer Netzwerk-Architektur
zur Befähigung
eines ersten IPsec-Clients für
die Korrespondenz eines IPsec-formatierten Pakets zu einem zweiten
IPsec-Client dar; und
-
3 stellt
eine Ausführungsform
einer Netzwerk-Architektur
zur Befähigung
eines ersten IPsec-Clients für
die Korrespondenz eines IPsec-formatierten Pakets zu einem zweiten
Client dar.
-
DETAILLIERTE
BESCHREIBUNG
-
Die 1 zeigt
eine erste Netzwerk-Architektur 10 zur Befähigung eines
ersten IPsec-Clients, dargestellt durch den IPsec-Gateway 12,
für die
zuverlässige
Sendung von ein oder mehreren IPsec-formatierten Paketen zu einem
zweiten IPsec-Client 14 (z.
B. eine IPsec-Sicherheitsvorrichtung, die mit einem Personalcomputer 15 verbunden ist),
und zwar ohne jegliche schädliche
Auswirkungen, die mit der Überquerung
von (einer) beliebigen Vorrichtung(en) für Netzwerk-Adressumwandlung und/oder
Firewalls verbunden sind. Das Netzwerk 10 schließt einen
offenen (nicht-proprietären)
Format-Tunneling-Protokollnetzwerkserver
ein, wie z. B. einen Layer-2-Tunneling-Protokoll-(L2TP)-Netzwerkserver 16.
In der dargestellten Ausführungsform
der 1 ist der L2TP-Netzwerkserver 16 direkt
mit dem IPsec-Gateway 12 über ein herkömmliches
lokales Netzwerk (LAN) gekoppelt, das als ein Ethernet-LAN 18 gezeigt
ist. Auf diese Weise kann der L2TP-Netzwerkserver 16 direkt
mit dem IP-Gateway 12 kommunizieren,
ohne jegliche Firewalls zu überqueren,
wie z. B. die Firewall 20, die das Netzwerk 18 schützt.
-
Der
L2TP-Netzwerkserver 16 fungiert, um individuelle L2TP-Tunnel in
dem Netzwerk 10 zu verschiedenen Endpunkten zu erstellen,
so dass die von dem Tunnel getragenen L2TP-formatierten Pakete bei
dem Übergang
durch jegliche Vorrichtungen für Netzwerk-Adressumwandlung
(NAT) und/oder Firewalls nicht berührt werden. Somit kann zum
Beispiel der L2TP-Netzwerkserver 16 einen Tunnel 21 zu
einem Internet-Dienstanbieter-Netzwerk 26 erstellen, das
dem IPsec-Client 14 derart dient, dass die von dem Tunnel
getragenen L2TP-formatierten Pakete von der NAT-Vorrichtung 22 unberührt bleiben.
-
Um
ein Paket zu dem IPsec-Client 14 über den L2TP-Netzwerkserver 16 zu
senden, erhält
der erste IPsec-Client (d. h. der IPsec-Gateway 12 der 1)
eine private Realm-Adresse für
den IPsec-Client 14 von
dem ISP-Netzwerk 26. Die private Realm-Adresse unterliegt
typischerweise der Adressumwandlung durch das NAT 22 und
der genauen Untersuchung durch die Firewall des ISP (ist nicht gezeigt).
Sollte der IPsec-Gateway 12 ein IPsec-formatiertes Paket zu der privaten Realm-Adresse durch
Routen des Pakets über
den Router 25, dem öffentlichen
Internet 24, dem NAT 22 und dem ISP-Netzwerk 26 senden,
würden
sich somit wahrscheinlich Übertragungsschwierigkeiten
ergeben.
-
Um
derartige Schwierigkeiten zu vermeiden, beginnt die Datenübertragung
gemäß der Erfindung, indem
der IPsec-Gateway 12 einen L2TP-Tunnel 28 mit
dem L2TP-Netzwerkserver 16 öffnet. Nach dem Öffnen des
Tunnels erhält
der IPsec-Gateway 12 eine Adresse, die mit dem Ende des
Tunnels 28 an dem L2TP-Netzwerkserver 16 assoziiert
ist. Bei einem dem L2TP-Netzwerkserver 16 nun offenen Tunnel
verpackt der IPsec-Gateway 12 jedes IPsec-Paket in ein
L2TP-Format, und zwar typischerweise durch Einhüllen des IPsec-Pakets in eine L2TP-Schale
für die Übertragung
zu dem L2TP-Netzwerkserver
unter Verwendung der Adresse, die mit dem Ende des Tunnels 28 assoziiert
ist, der mit dem Server endet.
-
Nach
Empfang des L2TP-formatierten Pakets, das das IPsec-Paket enthält, gestattet
es dann der L2TP-Netzwerkserver 16 dem IPsec-Gateway 12 (der
erste IPsec-Client), eine Sicherheit, die mit dem IPsec-Client 14 assoziiert
ist, über
den Tunnel 21 herzustellen. Sobald die Sicherheitsverbindung
hergestellt ist, sendet der L2TP-Netzwerkserver 16 jedes von
dem IPsec-Gateway 12 empfangene L2TP-verpackte IPsec-Paket über den
Tunnel 21 zu dem IPsec-Client 14.
-
Um
die Paketübertragung
in der beschriebenen Art und Weise zu erleichtern, kann der L2TP-Netzwerkserver 16 dem
IPsec-Gateway 12 virtuell eine beliebige Adresse, die für das Ende
des Tunnels 28 bestimmt ist, unter der Voraussetzung zuteilen,
dass eine derartige Adresse sich nicht mit der privaten Realm-Adresse
für das
ISP-Netzwerk 26 im Konflikt befindet. Aus diesem Grund
sollte der L2TP-Netzwerkserver 16 vorzugsweise separate
private Realm-Adressen zuteilen, um die Reservierung einer großen Auswahl
von potenziellen Adressen zu vermeiden, die mit dem Ende des Tunnels 28 assoziiert
sind. In einem solchen Fall muss (müssen) die Routing-Tabelle(n)
des IPsec-Gateways 12 entsprechend angepasst sein. Um die
derartige Paketübertragung
zu erleichtern sollte ferner die Firewall des L2TP-Netzwerkservers 16 einen
IPsec- und IKE-Verkehr von dem IPsec-Gateway 12 zulassen
und sollte auch einen L2TP-Verkehr zwischen sich selbst und dem öffentlichen
Internet 24 zulassen, während
anderer Verkehr nicht zugelassen wird.
-
Die 2 zeigt
eine zweite Ausführungsform einer
Netzwerk-Architektur 100 für die Übertragung von
IPsec-Paketen gemäß der Erfindung.
Die Architektur 100 verwendet Elemente, die mit der Architektur 10 der 1 gemeinsam
sind, und deshalb bezeichnen ähnliche
Bezugsziffern ähnliche
Elemente. Die Architektur 100 der 2 unterscheidet
sich von der Architektur 10 der 1 in einer
Haupthinsicht. In der Netzwerk-Architektur 100 der 2 genießt der L2TP-Netzwerkserver 16 keine
zugeordnete Verbindung mit einem bestimmten IPsec-Gateway, wie z.
B. über
den Tunnel 28 in der Netzwerk-Architektur 10 der 1.
Mit der Netzwerk-Architektur 100 der 2 kann
an Stelle davon der L2TP-Netzwerkserver 16 auf einen beliebigen
IPsec-Client zugreifen, wie z. B. den IPsec-Gateway 12 der 2,
der auf dem öffentlichen
Internet 24 sichtbar ist. (In der Netzwerk-Architektur 100 der 2 genießen sowohl
der IPsec-Gateway 12 als auch der L2TP-Netzwerkserver 16 eine
Verbindung mit demselben Router (d. h. Router 25), so dass
der Server L2TP-verpackte
IPsec-Pakete von dem IPsec-Gateway 12 über den Router 25 ohne
eine tatsächliche
Verbindung mit dem öffentlichen
Internet 24 empfangen kann.)
-
Um
die Übertragung
von IPsec-Paketen zu erleichtern, muss der L2TP-Netzwerkserver 16 der 2 den
IPsec-Clients, wie z. B. dem IPsec-Gateway 12 der 2, öffentlich
routfähige
Adressen zuteilen. Ansonsten könnte
der IPsec-Gateway der 2 mit dem L2TP-Netzwerkserver 16 nicht
betriebsbereit kommunizieren. Ferner muss der L2TP-Netzwerkserver 16 über ausreichend
aufgelockerte Firewall-Richtlinien verfügen, um IPsec- und IKE-Verkehr von einer
beliebigen IP-Adresse zuzulassen.
-
Der
Zugriff auf den L2TP-Netzwerkserver 16 über das öffentliche Internet 24 liefert
eine Flexibilität, zieht
aber die Möglichkeit
einer Verzögerung
nach sich, weil Pakete zuerst über
das öffentliche
Internet 24 zu dem Server (oder in dem Fall der 2 über den
Router 25 zu dem L2TP-Server) und dann schließlich von
dem Server zu dem Bestimmungsort geroutet werden. Im Vergleich vermeidet
die Netzwerk-Architektur 10 der 1 diese
mögliche Schwierigkeit,
weil sich der L2TP-Netzwerkserver 16 als auch der IPsec-Gateway 12 auf
demselben lokalen Netzwerk befinden.
-
Die 3 stellt
eine dritte Netzwerk-Architektur 1000 zur Erleichterung
einer Opportunist-Verschlüsselung
zwischen dem ersten und zweiten IPsec-Client 120 und 140 dar,
wobei jeder typischerweise eine IP-Sicherheitsvorrichtung umfasst,
die jeweils einem entsprechenden der Computer 1501 und 1502 dient. In der Ausführungsform der 3 verfügt jeder
der IPsec-Clients 120 und 140 über eine Verbindung über jeweils
ein separates der ISP-Netzwerke 2601 und 2602 und der NAT-Vorrichtungen 2501 und 2502 mit
dem öffentlichen
Internet 240.
-
Um
IPsec-Pakete sicher auszutauschen, öffnet jeder der IPsec-Clients 120 und 140 jeweils
einen separaten der L2TP-Tunnel 2801 und 2802 zu einem L2TP-Netzwerkserver 160,
der auf dieselbe Art und Weise wie der L2TP-Netzwerkserver 16 der 1 und 2 konfiguriert
ist. Mit den für
die IPsec-Clients 120 bzw. 140 geöffneten
Tunneln 2801 und 2802 gestattet es der L2TP-Netzwerkserver 160 den
zwei IPsec-Clients, eine Sicherheitsverbindung herzustellen. Nachdem
eine Sicherheitsverbindung zueinander hergestellt wurde, kann jeder
IPsec-Client ein IPsec-Paket
zu dem anderen über
den L2TP-Netzwerkserver 160 senden. Mit den für die IPsec-Clients 120 bzw. 140 geöffneten
Tunneln 2801 und 2802 kann der L2TP-Netzwerkserver 160 das
L2TP-verpackte IPsec-Paket von einem IPsec-Client zu einem anderen
korrespondieren, während
jegliche Übertragungsschwierigkeiten über jede
der NAT-Vorrichtungen 2501 und 2502 vermieden werden.
-
Die
Netzwerk-Architektur 1000 der 3 zeigt
einen einzelnen L2TP-Netzwerkserver 160, der beiden IPsec-Clients 120 und 140 dient.
Unter solchen Umständen
würde der
L2TP-Netzwerkserver jedem IPsec-Client eine den Server identifizierende private
Realm-Adresse zuteilen, um es jedem IPsec-Client zu gestatten, mit
dem Server zu kommunizieren, damit für jeden IPsec-Client ein entsprechender
der Tunnel 2801 und 2802 geöffnet
wird. In dem Fall von mehreren L2TP-Netzwerkservern müsste jeder
eine öffentlich
routfähige
Adresse für
den IPsec-Client zuteilen, der von jedem Server bedient wird.
-
Die
Implementierung des Übertragungsverfahrens
von IPsec-Paketen der Erfindung setzt einige Anforderungen an den
IPsec-Gateway 12 der 1 und 2.
In der öffentlichen
Implementierung der 2 muss sich der IPsec-Gateway 12 tatsächlich nicht
einmal dessen bewusst sein, dass irgendetwas spezielles stattfindet.
Die einzigen Anforderungen sind die üblichen Anforderungen an einen IPsec-Gateway:
dass er auf dem öffentlichen
Internet 24 sichtbar ist, dass er den L2TP-Netzwerkserver 16 sieht
und dass er den öffentlichen
Teil der von den IPsec-Clients, wie z. B. dem IPsec-Client 14,
verwendeten Schlüssel
während
der Authentifizierung kennt.
-
In
dem Fall, wo der L2TP-Netzwerkserver 16 der 1 und 2 private
Realm-Adressen den IPsec-Clients zuteilt, wie z. B. dem IPsec-Client 14, muss
der IPsec-Gateway über
Routing-Tabellen-Eingaben
verfügen,
um Pakete für
diese Adressen entsprechend über
den L2TP-Netzwerkserver zu routen.
-
Die
Anforderungen für
den L2TP-Netzwerkserver 16 und 160 unterscheiden
sich für
unterschiedliche Implementierungsszenarios. In sämtlichen Fällen muss der L2TP-Netzwerkserver
für die IPsec-Clients sichtbar
sein. Zusätzlich
sollte der L2TP-Netzwerkserver 16 den Authentifizierungsmechanismus
in sowohl dem L2TP als auch PPP verwenden und er sollte die Paket-Komprimierung
abschalten. Die Sicherheitsmechanismen des L2TP und PPP sind rudimentär und nicht
ausreichend, um gegen Denial-of-Service-Angriffe zu schützen, aber sie
erschweren die Arbeit der Hacker tatsächlich. Die Komprimierung ist
hier nutzlos, weil die Pakete verschlüsselt werden, bevor sie an
das PPP für
die Komprimierung übertragen
werden. In Abhängigkeit
von dem Szenario teilt der L2TP-Netzwerkserver private Realm- oder öffentliche
Realm-Adressen den
IPsec-Clients zu und muss somit eine geeignete Auswahl von zuzuteilenden
Adressen aufweisen.
-
Weil
der L2TP-Netzwerkserver Routing-Verzögerungen und mögliche Denial-of-Service-Angriffe einbringt,
sollte er nur verwendet werden, wenn eine NAT-Vorrichtung oder eine
inkompatible Firewall mit dem IPsec-Verkehr wechselwirkt. Der IPsec-Client muss
deshalb über
einen Zugriff auf einen 'NAT-Feststellungsdienst' verfügen, der
ihm zu bestimmen hilft, ob der L2TP-Tunnel benötigt wird. Dieser Dienst kann
viele Formen annehmen aber die einfachste Form ist ausreichend,
und zwar ein UDP-Dienst, der die Adresse und den Port der Quelle
wiedergibt, von dem er die Anfrage kommen sieht. Das Platzieren von
diesem NAT-Feststellungsdienst
auf derselben Maschine wie das LNS erscheint am einfachsten und am
effektivsten. In der Ausführungsform
der 1 sind das LNS und der IPsec-Gateway miteinander gekoppelt
und es könnte
sich somit als nützlich
erweisen, diese Verbindung durch die Verwendung von zugehörigen Domain-Namen
zu reflektieren, wie z. B. ipsec.corporate.domain.net und 12tp.corporate.domain.net.
Das würde
die Aufgabe des IPsec-Clients erleichtern, einen geeigneten L2TP-Server
für einen
gegebenen IPsec-Gateway zu lokalisieren.
-
Die
Implementierung des Übertragungsverfahrens
für IPsec-Pakete
der Erfindung erfordert, dass jeder IPsec-Client den L2TP-Netzwerkserver in dem
Client-Modus als auch IPsec unterstützt. In beiden Fällen muss
der Client für
das gewählte
Szenario (öffentliche
und private Schlüssel,
Kenntnis des IPsec-Gateways und der LNS-Adressen, usw.) natürlich entsprechend
konfiguriert sein. Zusätzlich
muss die Herstellung der Netzwerkverbindung modifiziert sein, um
die NAT-Feststellung durchzuführen
und, falls angebracht, den L2TP-Tunnel vor dem Herstellen der IPsec-Sicherheitsverbindung
zu öffnen.
-
Die
oben beschriebenen Ausführungsformen stellen
lediglich die Prinzipien der Erfindung dar. Der Fachmann kann verschiedene
Modifikationen und Änderungen
vornehmen, die die Prinzipien der Erfindung verkörpern und unter den Schutzumfang
davon fallen.
-
Dort,
wo technische Merkmale, die in irgendeinem Anspruch erwähnt sind,
von Bezugsziffern gefolgt werden, sind diese Bezugsziffern für den alleinigen
Zweck der Steigerung der Verständlichkeit der
Ansprüche
eingefügt
worden, und dementsprechend besitzen derartige Bezugsziffern keine
beschränkende
Wirkung auf den Schutzumfang von jedem Element, das von derartigen
Bezugsziffern beispielhaft identifiziert wird.