DE60024237T2

DE60024237T2 - Verfahren und system zur netzwerkadressübersetzung mit sicherheitseigenschaften

Info

Publication number: DE60024237T2
Application number: DE60024237T
Authority: DE
Inventors: A. David GRABELSKY; S. Michael BORELLA; S. Ikhlaq SIDHU; M. Danny NESSETT
Original assignee: 3Com Corp
Current assignee: 3Com Corp
Priority date: 1999-03-17
Filing date: 2000-03-15
Publication date: 2006-06-29
Anticipated expiration: 2020-03-16
Also published as: EP1159815B1; ATE311060T1; DE60024237D1; WO2000056034A1; EP1159815A1

Description

QUERVERWEISE ZU VERWANDTEN ANMELDUNGEN
Die vorliegende Anmeldung ist eine Teilfortsetzung des US-Patentes Nr. 6,353,614, eingereicht am 5. März 1998.
BEREICH DER ERFINDUNG
Die vorliegende Erfindung betrifft Computernetzwerke. Sie betrifft insbesondere ein Verfahren für eine Adressenumsetzung in einem verteilten Netz mit Netzwerksicherheitsmerkmalen.
HINTERGRUND DER ERFINDUNG
Das Internet Protocol („IP") ist ein Adressierungsprotokoll mit der Aufgabe, die Leitweglenkung von Verkehr in einem Netzwerk oder zwischen Netzwerken zu erleichtern. Das Internet Protocol wird auf vielen Computernetzen einschließlich dem Internet, Intranets und anderen Netzwerken eingesetzt. Derzeitige Versionen des Internet Protocol wie z.B. Internet Protocol Version –4 („IPv4") sind aufgrund ihres begrenzten Adressenraums veraltet. Bei einem 32-Bit-Adressfeld ist es möglich, 2³² unterschiedliche Adressen zuzuweisen, was 4.294.967.296 oder mehr als 4 Milliarden global eindeutige Adressen bedeutet.
Mit dem explosiven Wachstum des Internets und von Intranets werden aber Internet Protocol Adressen mit einem 32-Bit-Adressfeld wohl bald ausgehen. Internet Protocol Version-6 („IPv6") schlägt die Verwendung eines 128-Bit-Adressfeldes für IP-Adressen vor. Eine große Zahl von Legacy-Netzwerken mit einer großen Zahl von Internet-Teilnetzen werden jedoch noch viele Jahre lang ältere Versionen des Internet Protocol mit einem 32-Bit-Adressenraum verwenden.
Network Address Translation („NAT") wurde vorgeschlagen, um die Lebenszeit von Internet Protocol Version 4 und früheren Internet Protocol Versionen zu verlängern, indem zugelassen wird, dass Teilnetze hinter einer einzigen oder einer geringen Zahl von global eindeutigen Internet Protocol Adresse(n) existieren (siehe z.B. „The IP Network Address Translator" von P. Srisuresh und K. Egevang, Internet Engineering Task Force („IETF"), Internet Draft <draft-rfced-info-srisuresh-05.txt> Februar 1998). Eine einzelne globale Internet Protocol Adresse wird für Kommunikationen mit externen Netzwerken wie dem Internet verwendet. Intern verwendet ein Teilnetz („Subnet") lokale Adressierung. Lokale Adressierung kann entweder irgendein Adressierungsschema, das sich von der Internet Protocol Adressierung unterscheidet, oder ein nicht eindeutiger Gebrauch von Internet Protocol Adressen sein. In beiden Fällen werden lokale Adressen an einem Teilnetz (Subnet) nicht auf dem externen, globalen Internet verwendet. Wenn ein Gerät oder Knoten, das/der mit lokaler Adressierung arbeitet, mit der Außenwelt kommunizieren möchte, dann wird seine lokale Adresse in eine gemeinsame externe Internet Protocol Adresse umgewandelt, die für Kommunikationen mit einem externen Netzwerk durch ein Netzwerkadressenumsetzungsgerät verwendet wird. Das heißt, mit Netzwerkadressenumsetzung können ein oder mehrere globale Internet Protocol Adressen von einer größeren Zahl von lokalen Adressen gemeinsam verwendet werden.
Mit der Verwendung von Netzwerkadressenumsetzung zum Verlängern der Lebenszeit des Internet Protocol sind jedoch mehrere Probleme assoziiert. Netzwerkadressenumsetzung steht mit dem End-to-End-Leitweggrundsatz des Internets im Konflikt, der empfiehlt, dass Pakete von einem Ende zum anderen zwischen Netzgeräten laufen, ohne dass der Inhalt eines Pakets über eine Übertragungsroute geändert wird (siehe z.B. „Routing in the Internet" von C. Huitema, Prentice Hall, 1995, ISBN 0-131-321-927).
Derzeitige Versionen der Netzwerkadressenumsetzung ersetzen eine lokale Netzwerkadresse in einem Datenpaket-Header durch eine externe globale Netzwerkadresse bei abgehendem Verkehr, und ersetzen eine externe Netzwerkadresse in einem Datenpaket-Header durch eine lokale Netzwerkadresse bei eingehendem Verkehr. Dieser Typ der Adressenumsetzung ist rechenintensiv, verursacht Sicherheitsprobleme, da bestimmte Verschlüsselungstypen nicht verwendet werden können, oder unterbricht eine Reihe existierender Anwendungen in einem Netzwerk, die keine Netzwerkadressen umsetzen können (z.B. File Transfer Protocol („FTP").
Derzeitige Versionen der Netzwerkadressenumsetzung können aufgrund der benötigten rechnerischen und sonstigen Betriebsmittel nicht einfach über die Größe eines kleinen Teilnetzes mit einem paar Dutzend Knoten oder Geräten hinaus erweitert werden. Netzwerkadressenumsetzung erfordert potentiell Unterstützung für viele verschiedene interne Netzwerkprotokolle, die speziell in einen Umsetzungsmechanismus für externe Protokolle in einem Netzwerkadressenumsetzungsgerät wie einem Netzwerkadressenumsetzungsrouter programmiert sind.
Die rechnerische Belastung des Netzwerkadressenumsetzungsrouters kann erheblich sein und die Netzwerkleistung herabsetzen, besonders wenn mehrere Teilnetze mit Netzwerkadressenumsetzung denselben Netzwerkadressenumsetzungsrouter gemeinsam nutzen. In einem ungünstigsten Szenario setzt ein Netwerkadressenumsetzungsrouter jedes eingehende und abgehende Datenpaket um. Wenn Netzwerkadressenumsetzung zum Umsetzen eines Transmission Control Protocol/Internet Protocol oder User Datagram Protocol/Internet Protocol Datenpakets verwendet wird, dann werden die Internet Protocol, Transmission Control Protocol oder User Datagram Protocol Prüfsummen des Pakets neu berechnet.
Wie in der Technik bekannt ist, werden Transmission Control Protocol („TCP") und User Datagram Protocol („UDP") häufig über IP in Computernetzwerken verwendet. Transmission Control Protocol bietet ein verbindungsorientiertes, zuverlässiges End-to-End-Protokoll, das so ausgelegt ist, dass es in eine geschichtete Protokollhierarchie passt, die Multinetz-Anwendungen unterstützt. User Datagram Protocol bietet ein transaktionsorientiertes Datagram-Protokoll, bei dem Übermittlungs- und Paketduplizierschutz nicht garantiert sind.
Wenn ein Port im Transmission Control Protocol oder User Datagram Protocol Header umgesetzt wird, dann werden auch die Transmission Control Protocol oder User Datagram Protocol Prüfsummen des Paketes neu berechnet. Dies erhöht die Kosten für die Umsetzungskalkulationen in einem Netzwerkadressenumsetzungsrouter noch weiter.
Wenn ein(e) Internet Protocol Adresse oder Port mit Netzwerkadressenumsetzung umgesetzt wird, dann kann dies eine neue Länge für das Datenpaket und eine mögliche Änderung in einer Transmission Control Protocol Sequenznummer ergeben. Dann muss ein Laufende-Sequenznummer-Versatz (d.h. ein Delta) für den Rest der Verbindung geführt werden. Dieses Delta muss auf zukünftigen Verkehr angewendet werden, einschließlich Bestätigungsnummern, wodurch die Rechenzeit in einem Netzwerkadressenumsetzungsrouter noch weiter erhöht wird.
Zusätzlich zum Transmission Control Protocol oder User Datagram Protocol, kann ein Netzwerkadressenumsetzungsrouter auch Netzwerkadressen und Ports umsetzen, Längen andern und Sequenznummern für eine Reihe verschiedener Protokolle führen, die eine Internet Protocol Adresse oder Portnummer verwenden (z.B. FTP, H.323, H.324, CUSeeME, RealAudio, Internet Relay Chat und andere). Diese Umsetzung kann die Rechenzeit in einem Netzwerkadressenumsetzungsrouter noch weiter erhöhen.
Das Internet Protocol wird auf globalen Computernetzen wie dem Internet sowie auf vielen Privatnetzen wie Intranets und virtuellen Privatnetzen verwendet. Es ist häufig wünschenswert, mit dem Internet Protocol gesendete Informationen mit verschiedenen Sicherheitstypen zu schützen. Durch die Verwendung von Sicherheitsmerkmalen (Security) mit dem Internet Protocol können private oder schutzwürdige Informationen über ein öffentliches Netz mit einem gewissen Maß an Zuversicht gesendet werden, dass die privaten oder schutzwürdigen Informationen nicht abgefangen, untersucht oder verändert werden.
Internet Protocol Security („IPsec") ist ein Protokoll zum Implementieren von Sicherheit für Kommunikationen auf Netzwerken mit dem Internet Protocol über die Verwendung von kryptografischen Key-Management-Prozeduren und -Protokollen. Kommunikationen zwischen zwei Endpunkten eines Internet Protocol Verkehrsflusses werden mit dem Internet Protocol Sicherheitsprotokoll auf individueller Internet Protocol Paket-zu-Paket-Basis von Ende zu Ende sicher gemacht. Internet Protocol Sicherheitsprotokollobjekte an Verbindungsendpunkten haben Zugang zu und sind beteiligt an kritischen und schutzwürdigen Operationen, die eine gemeinsame Verbindung sicher machen.
Internet Protocol Sicherheit beinhaltet derzeit zwei Sicherheitsdienste, jeweils mit einem assoziierten Header, der einem Internet Protocol Paket hinzugefügt wird, das geschützt wird. Die beiden Sicherheitsdienste beinhalten einen Authentication Header („AH") und einen Encapsulating Security Payload („ESP") Header. Der Authentication Header bietet Authentifikations- und Integritätsschutz für ein Internet Protocol Paket. Der Encapsulating Security Payload Header bietet Verschlüsselungsschutz und Authentifizierung für ein Internet Protocol Paket.
Die Internet Protocol Sicherheitsprotokoll-Header werden im Protokollfeld eines Internet Protocol Datenpaket-Headers identifiziert. Der Internet Protocol Sicherheitsprotokoll-Header gibt den Typ vor (z.B. Authentication Header oder Encapsulating Security Payload) und enthält einen numerischen Wert mit der Bezeichnung Security Parameter Index („SPI"). Der Security Parameter Index zusammen mit einer Internet Protocol Zieladresse und einem Internet-Sicherheitsprotokoll bilden eine eindeutige Kennung, die von einem Empfangssystem zum Assoziieren eines Datenpakets mit einem „Security Association" genannten Konstrukt verwendet wird. Der Security Parameter Index wird vom Empfangssystem benutzt, um beim korrekten Verarbeiten eines Internet Protocol Pakets zu helfen (z.B. es zu entschlüsseln oder seine Integrität und Authentizität zu verifizieren).
Internet Protocol Sicherheit stellt eine Security Association („SA") her und benutzt sie, um einen sicheren Kanal zwischen zwei Endpunkten zu finden. Eine Security Association ist eine unidirektionale Session zwischen zwei Terminierungsendpunkten. Zwei Terminierungsendpunkte einer einzigen Security Association definieren eine Logiksession, die von Internet Protocol Sicherheitsdiensten geschützt wird. Ein Endpunkt sendet Internet Protocol Pakete, ein zweiter Endpunkt empfängt die Internet Protocol Pakete. Da eine Security Association unidirektional ist, werden für sichere bidirektionale Kommunikationen mindestens zwei Security Associations benötigt. Es ist auch möglich, mehrere Schichten von Internet Protocol Sicherheitsprotokollen zwischen zwei Endpunkten zu konfigurieren, indem mehrere Security Associations miteinander kombiniert werden.
Mit der Verwendung derzeitiger Versionen von Netzwerkadressenumsetzung, wenn Sicherheit erforderlich ist und das Internet Protocol Sicherheitsprotokoll verwendet wird, sind mehrere Probleme verbunden. Derzeitige Netzwerkadressenumsetzungsversionen verletzen bestimmte spezifische Grundsätze des Internet Protocol Sicherheitsprotokolls, die eine Herstellung und Führung sicherer Ende-zu-Ende-Verbindungen eines Internet Protocol Netzwerks zulassen.
Ein Netzwerkadressenumsetzungsrouter muss gewöhnlich ein Internet Protocol Paket modifizieren (z.B. Netzwerkports usw.). Wenn jedoch ein Internet Protocol Paket durch Internet Protocol Sicherheit geschützt wird, dann darf es auf dem Weg von einer Internet Protocol Sicherheitsquelle zu einem Internet Protocol Sicherheitsziel nirgendwo modifiziert werden. Die meisten Netzwerkadressenumsetzungsrouter verletzen die Internet Protocol Sicherheit, indem sie individuelle Internet Protocol Pakete modifizieren oder zu modifizieren versuchen.
Selbst wenn ein Netzwerkadressenumsetzungsrouter Datenpakete, die er weiterleitet, nicht modifiziert, muss er Netzwerkportnummern (z.B. Transmission Control Protocol, User Datagram Protocol usw.) in den Datenpaketen lesen können. Wenn bestimmte Internet Protocol Sicherheitsmerkmale verwendet werden (z.B. Encapsulated Security Payload („ESP")), dann sind die Netzwerkportnummern verschlüsselt, so dass der Netzwerkadressenumsetzungsrouter gewöhnlich die Netzwerkports nicht für ein Netzwerkadressenumsetzungsmapping benutzen kann.
Lokale Host-Netzgeräte auf einem Local Area Network („LAN"), die mit Netzwerkadressenumsetzung arbeiten, besitzen gewöhnlich nur lokale, nicht eindeutige Internet Protocol Adressen. Die lokalen, nicht eindeutigen Internet Protocol Adressen haben keinen Namensraum, der zum Binden eines Encryption-Key (z.B. eines Public Key) an ein eindeutiges Objekt geeignet ist. Ohne diese eindeutige Bindung ist es nicht möglich, die notwendige Authentifizierung zur Herstellung von Security Associations zu erhalten. Ohne Authentifizierung kann ein Endpunkt einer Verbindung über die Identität eines anderen Endpunkts nicht sicher sein, so dass keine sichere und vertrauenswürdige Verbindung hergestellt werden kann.
Kent, S.: ,Evaluating certification authority security' AEROSPACE CONFERENCE, 1998 IEEE, [Online] Bd. 4, 21.–23. März 1998, Seiten 319–327, XP002143438 ISBN: 0-7803-4311-5 betrifft Anwendungen im Internet, die X.509 Public Key Zertifikate verwenden. Beispiele sind Sicherheitsprotokolle wie SSL (in Web-Browsern benutzt), IPSEC (in Firewalls und Desktop-Computern benutzt), S/MIME (ein sicheres E-Mail-Protokoll) und SET (das eCommerce-Kreditkartentransaktionsprotokoll). Die von den Anwendungen verwendeten Public Key Zertifikate werden von Certification Authorities (CA) erstellt, die für die Bindung verschiedener Attribute (z.B. Identität) an einen Public Key bürgen. Somit ist die Sicherheit dieser Anwendungen von der Sicherheit der CA-Funktion abhängig. Dieses Dokument untersucht Sicherheit für CAs. Es beginnt mit einer Charakterisierung von Sicherheitsanforderungen für CAs und fährt mit einer Untersuchung der großen Palette von Attacken fort, die gegen CAs durchgeführt werden können. Dazu gehören Attacken gegen Netzwerkkommunikationen, gegen die von CAs verwendeten Betriebssysteme, technische „Nah"-Angriffe gegen CA-Komponenten (einschließlich kryptografischer Module) und sogar Fehlverhalten von menschlichen Operators. Der Artikel schließt mit einer Untersuchung von drei Ansätzen für eine Ausführung von kryptografischen CA-Unterstützungsfunktionen und analysiert jeden in Bezug auf die an früherer Stelle in dem Artikel entwickelten Attackenszenarios.
THAYER R: ,Bulletproof IP with authentication and encryption, IPSEC adds a layer of armor to IP' DATA COMMUNICATIONS, US MCGRAW HILL, NEW YORK, Bd. 26, Nr. 16, 21. November 1997 (1997-11-21), Seiten 55–58, 60, XP000723268 betrifft drei Aspekte von IPsec: (i) Encapsulating Security Payload (ESP), die die Verschlüsselung oder IP-Nutzdaten definiert; (ii) Authentication Header (AH), der das Authentifizierungsverfahren definiert; und (iii) das IP Security Association Key Management Protocol (ISAKMP), das den Austausch von geheimen Keys zwischen Sender und Empfängern von ESP- oder AH-Paketen verwaltet.
Es ist somit wünschenswert, eine Netzwerkadressenumsetzung zuzulassen, wenn Internet Protocol Sicherheit zum Protokollieren von Internet Protocol Paketen verwendet wird. Die Netzwerkadressenumsetzung soll Internet Protocol Sicherheit ermöglichen und soll die Belastung eines Routers oder eines anderen Netzgerätes nicht erhöhen, das Netzwerkadressenumsetzung bereitstellt.
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren für eine sichere Adressenumsetzung in einem verteilten Netz bereitgestellt, das die folgenden Schritte umfasst:
an einem ersten Netzgerät auf einem ersten Computernetzwerk, Anfordern von einem oder mehreren lokal eindeutigen Sicherheitswerten von einem Routing-Gerät auf dem ersten Computernetzwerk mit einem ersten Protokoll, um das erste Netzgerät bei sicheren Kommunikationen mit einem dritten Netzgerät auf einem externen Netzwerk eindeutig zu identifizieren, und für eine sichere Adressenumsetzung in dem verteilten Netz;
Empfangen der ein oder mehreren lokal eindeutigen Sicherheitswerte auf dem ersten Netzgerät von dem Routing-Gerät mit dem ersten Protokoll; und
Speichern der ein oder mehreren lokal eindeutigen Sicherheitswerte auf dem ersten Netzgerät; und
mit den ein oder mehreren lokal eindeutigen Sicherheitswerten, Herstellen einer sicheren virtuellen Verbindung für sichere Kommunikationen zwischen dem ersten Netzgerät und dem dritten Netzgerät und für eine Adressenumsetzung in dem verteilten Netz.
Das genannte Routing-Gerät ist vorzugsweise ein Verteiltes-Netz-Adressenumsetzungsrouter.
Die ein oder mehreren lokal eindeutigen Sicherheitswerte sind praktischerweise ein oder mehrere Sicherheitsparameterindexe für ein Internet Protocol Sicherheitsprotokoll.
Ebenso ist das genannte Internet Protocol Sicherheitsprotokoll ein Authentication Header Protokoll, ein Encapsulated Security Payload Protokoll oder ein Internet Key Exchange Protokoll.
Ferner ist das genannte erste Protokoll ein Port Allocation Protocol.
Vorteilhafterweise beinhaltet der genannte Anforderungsschritt ferner das Anfordern von einem oder mehreren lokal eindeutigen Ports, die zum eindeutigen Identifizieren des ersten Netzgerätes auf dem ersten Netzwerk für eine Adressenumsetzung in einem verteilten Netz verwendet werden.
Die genannten lokal eindeutigen Ports sind vorzugsweise Port Allocation Protocol Ports.
Die obigen sowie weitere Merkmale und Vorteile einer bevorzugten Ausgestaltung der vorliegenden Erfindung werden anhand der nachfolgenden Beschreibung besser verständlich, die auf die Begleitzeichnungen Bezug nimmt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Bevorzugte Ausgestaltungen der vorliegenden Erfindung werden mit Bezug auf die folgenden Zeichnungen beschrieben. Dabei zeigt:
1 ein Blockdiagramm, das ein Netzwerksystem für eine verteilte Adressenumsetzung illustriert;
2 ein Blockdiagramm, das einen Protokollstapel für ein Netzgerät illustriert;
3 ein Blockdiagramm, das ein Port Allocation Protocol („PAP") illustriert;
4 ein Blockdiagramm, das ein PAP-Anforderungsmeldungslayout illustriert;
5 ein Blockdiagramm, das ein PAP-Antwortmeldungslayout illustriert;
6 ein Blockdiagramm, das ein PAP-Invalidierungsmeldungslayout illustriert; 4A ein Blockdiagramm, das ein PAP-Sicherheitsanforderungsmeldung-Layout illustriert;
5A ein Blockdiagramm, das ein PAP-Sicherheitsantwortmeldungslayout illustriert;
6A ein Blockdiagramm, das ein PAP-Sicherheitsinvalidierungsmeldung-Layout illustriert;
7 ein Blockdiagramm, das ein kombiniertes PAP-Netzwerkadressenlayout illustriert;
8 ein Blockdiagramm, das ein PAP Port-zu-Interne-Netzwerkadresse-Tabellenlayout illustriert;
9 ein Ablaufdiagramm, das ein Verfahren zum Zulassen einer Adressenumsetzung in einem verteilten Netz illustriert;
10 ein Blockdiagramm, das ein Verfahren für eine Adressenumsetzung in einem verteilten Netz illustriert;
11 ein Quellport-Übergangstabellenlayout;
12 ein Internet Protocol Adressenumsetzungstabellenlayout;
13 ein Verfahren für eine abgehende Verteiltes-Netz-Adressenumsetzung mit Portumsetzung;
14 ein Verfahren für eine eingehende Verteiltes-Netz-Adressenumsetzung mit Portumsetzung;
15 ein Blockdiagramm, das ein Internet Protocol Paket-Header-Format illustriert;
16 ein Blockdiagramm, das ein Internet Protocol Security Authentication Header Format illustriert;
17 ein Blockdiagramm, das ein Encapsulating Security Payload Paketformat illustriert;
18 ein Blockdiagramm, das Ende-zu-Ende-Sicherheit zwischen zwei Endpunkten über ein Internet Protocol Netzwerk illustriert;
19 ein Ablaufdiagramm, das ein Verfahren für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert;
20 ein Ablaufdiagramm, das ein Verfahren für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert;
21 ein Blockdiagramm, das ein SPI-zu-interne-Netzwerkadresse-Tabellenlayout illustriert;
22 ein Ablaufdiagramm, das ein Verfahren zum Bereitstellen einer Sicherheitsassoziation mit einer Verteiltes-Netz-Adressenumsetzung illustriert;
23 ein Ablaufdiagramm, das ein Verfahren für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert;
24 ein Ablaufdiagramm, das ein Verfahren für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert; und
25 ein Ablaufdiagramm, das ein Verfahren für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert.
AUSFÜHRLICHE BESCHREIBUNG BEVORZUGTER AUSGESTALTUNGEN
Beispielhaftes Netzwerksystem
1 ist ein Blockdiagramm, das ein beispielhaftes Netzsystem 10 für eine bevorzugte Ausgestaltung der vorliegenden Erfindung illustriert. Das Netzsystem 10 beinhaltet ein erstes Computernetz 12 mit mehreren Netzgeräten (14, 16, 18, 20, 22, 24) und einen Router 26 zum Leiten von Datenpaketen zu einem anderen externen Computernetz. Zu den mehreren Netzgeräten können nach Bedarf Computer (14, 18), Drucker 16, Telefax-Geräte 24, Taschengeräte 20, Telefone 22 oder andere, in 1 nicht illustrierte Netzgeräte gehören. Das erste Computernetz 12 hat eine externe gemeinsame Netzwerkadresse 28 (z.B. eine globale Internet Protocol Adresse 198.10.20.30), um das Netzwerk 12 für ein externes Computernetz wie z.B. ein zweites Computernetz 30 und/oder ein drittes Computernetz 32 außerhalb des ersten Computernetzes 12 zu identifizieren. Die mehreren Netzgeräte (14, 16, 18, 20, 22, 24 und 26) haben eine interne Netzwerkadresse (d.h. eine private Netzwerkadresse) auf dem ersten Computernetz 12 (z.B. 10.0.0.x, nachfolgend erläutert). In einer bevorzugten Ausgestaltung der vorliegenden Erfindung leitet ein Netzzugangsservice-Provider 34 mit einem Router 36 Datenpakete zu/von dem ersten Computernetz 12 zum zweiten Computernetz 30 und/oder dritten Computernetz 32 durch einen zweiten Netzwerk-Switch 38 und einen dritten Netzwerk-Switch 40. In einer weiteren Ausgestaltung der vorliegenden Erfindung ist das erste beispielhafte Computernetz 12 direkt mit dem zweiten Computernetz 30 verbunden.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Computernetz 12 ein Small Office/Home Office („SOHO") Local Area Network („LAN"), das auch „Legacy"-LAN genannt wird. Das erste Computernetz 12 wird auch als „Stub"-Netz bezeichnet. Wie in der Technik bekannt ist, beinhaltet ein Stub-Netz typischerweise mehrere Netzgeräte, die eine gemeinsame externe Netzwerkadresse für die Kommunikation mit einem externen Netz wie z.B. dem Internet verwenden. Das zweite Netzwerk 30 ist das Internet oder ein Intranet, das dritte Netzwerk 32 ist ein öffentliches Fernsprechwählnetz (Public Switched Telephone Network = „PSTN"). Es können jedoch auch andere Netzwerktypen und Netzwerkkomponenten verwendet werden, und die vorliegende Erfindung ist nicht auf die für diese bevorzugte Ausgestaltung beschriebenen Netzwerktypen und Netzwerkomponenten begrenzt. Die vorliegende Erfindung kann mit praktisch jedem Netzwerk verwendet werden, das das Internet Protocol oder andere Protokolle in der Internet Protocol Suite verwendet.
Netzgeräte und Router für bevorzugte Ausgestaltungen der vorliegenden Erfindung beinhalten Netzgeräte, die mit dem Netzsystem 10 auf der Basis von Standards interagieren können, die vom Institute of Electrical and Electronic Engineers („IEEE"), vom International Telecommunications Union Telecommunication Standardization Sector („ITU"), von der Internet Engineering Task Force („IETF") oder vom Wireless Application Protocol („WAP") Forum vorgeschlagen wurden. Es können aber auch Netzgeräte auf der Basis anderer Standards zum Einsatz kommen. IEEE-Standards befinden sich auf dem World Wide Web unter der URL-(Universal Resource Locator)-Adresse „www.ieee.org". Die ITU-(früher als CCITT bekannt)Standards befinden sich unter der URL-Adresse „www.itu.ch". IETF-Standards befinden sich unter der URL-Adresse „www.ietf.org". Die WAP-Standards befinden sich unter der URL-Adresse „www.wapforum.org".
Eine Betriebsumgebung für Netzgeräte und Router der vorliegenden Erfindung beinhaltet ein Verarbeitungssystem mit wenigstens einer schnellen Zentraleinheit („CPU") und einem Memory. Gemäß den Praktiken von Fachpersonen im Bereich Computerprogrammierung wird die vorliegende Erfindung nachfolgend mit Bezug auf Handlungen und symbolische Darstellungen von Operationen oder Befehle beschrieben, die vom Verarbeitungssystem ausgeführt werden, wenn nichts anderes angegeben ist. Solche Handlungen und Operationen oder Befehle werden als „vom Computer ausgeführt" oder als „von der CPU ausgeführt" bezeichnet.
Man wird verstehen, dass Handlungen und symbolisch dargestellte Operationen oder Befehle die Manipulation von elektrischen Signalen oder biologischen Signalen durch die CPU beinhalten. Ein elektrisches System oder biologisches System repräsentiert Datenbits, die eine resultierende Transformation oder Reduktion der elektrischen Signale oder biologischen Signale sowie die Führung von Datenbits an Speicherpositionen in einem Speichersystem bewirkt, um dadurch den Betrieb der CPU sowie andere Signalverarbeitungsabläufe umzukonfigurieren oder auf andere Weise zu verändern. Die Speicherstellen, an denen Datenbits geführt werden, sind physische Stellen, die besondere elektrische, magnetische, optische oder organische Eigenschaften haben, die den Datenbits entsprechen.
Die Datenbits können auch auf einem rechnerlesbaren Medium wie Magnetplatten, Bildplatten, organischem Speicher und sonstigen flüchtigen (z.B. Arbeitsspeicher („RAM")) oder nichtflüchtigen (z.B. Festwertspeicher („ROM")) von der CPU lesbaren Massenspeichersystemen geführt werden. Das rechnerlesbare Medium beinhaltet kooperierende oder untereinander verbundene rechnerlesbare Medien, die ausschließlich auf dem Verarbeitungssystem existieren oder die zwischen mehreren miteinander verbundenen Verarbeitungssystemen verteilt werden, die sich ortsnah oder ortsfern vom Verarbeitungssystem befinden können.
In in der Technik bekannten Netzwerkadressenumsetzungsschemata setzt der Router 26 eine interne Netzwerkadresse wie z.B. eine auf dem ersten Computernetz 12 verwendete interne Netzwerkadresse in eine externe Netzwerkadresse um, wie z.B. eine Netzwerkadresse für abgehenden Verkehr zum zweiten Netzwerk 30 oder zum dritten Netzwerk 32. Der Router 26 setzt auch eine externe Netzwerkadresse in eine interne Netzwerkadresse für eingehenden Verkehr vom zweiten Netzwerk 30 oder vom dritten Netzwerk 32 um. Ein Network Address Translation („NAT") Router übernimmt die gesamte Rechenlast für die Netzwerkadressenumsetzung. Für große Teilnetze wird der NAT-Router zu einem Engpass. Im ungünstigsten Fall erfordert jedes durch den NAT-Router passierende Paket eine Adressenumsetzung. Weitere Informationen über Netzwerkadressenumsetzungen für das Internet Protocol siehe „The IP Network Address Translator (NAT)", Internet Engineering Task Force („IETF") Request for Comments („RFC") RFC-1631, „NAT Bypass for ,End 2 End' Sensitive Applications," von G. Tsirtsis und A. O'Niell, IETF Internet Draft, <draft-tsirtsis-nat-bypass-00.txt>, Januar 1998, oder „The IP Network Address Translator" von P. Srisuresh und K. Egevang, Internet Engineering Task Force („IETF"), Internet Draft <draft-rfced-info-srisuresh-05-txt>, Februar 1998.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung wird Distributed Network Access Translation („DNAT") angewendet. Netzgeräte (14, 16, 18, 22 und 24) auf dem ersten Computernetz 12 fordern einen Satz von lokal eindeutigen Ports vom Router 26 für externe Kommunikationen mit dem externen zweiten Netzwerk 30 oder dem dritten Netzwerk 32 an. Ein lokal eindeutiger Port ist innerhalb des ersten Computernetzes 12 eindeutig und außerhalb des ersten Computernetzes 12 gewöhnlich nicht eindeutig. Lokal eindeutige Ports können für mobile Netzgeräte wie das Gerät 20 verwendet werden, das das Mobile Internet Protocol verwendet, die derzeit nicht permanent am ersten Computernetz 12 angeschlossen sind. Ein mobiles Netzgerät kann physisch zu einem anderen Ort gebracht werden und sich an ein fremdes Computernetz anschließen (d.h. ein anderes als das Heimatcomputernetz 12).
Die Netzgeräte (14, 16, 18, 20, 22, 24) ersetzen vorgabemäßige oder ephemere Ports durch die lokal eindeutigen Ports und verwenden eine Kombinationsnetzwerkadresse inklusive einem lokal eindeutigen Port und eine gemeinsame externe Netzwerkadresse (z.B. eine IP-Adresse) für Kommunikationen mit den externen Netzwerken 30 und 32. Ein Vorgabeport wird typischerweise statisch zugewiesen. Ein ephemerer Port wird typischerweise für eine vorgegebene Zeitdauer dynamisch zugewiesen.
DNAT-Protokollstapel
2 ist ein Blockdiagramm, das einen geschichteten Protokollstapel 42 für ein Netzgerät vom ersten Computernetz 12 illustriert, das für DNAT verwendet wird. Der geschichtete Protokollstapel 42 wird mit Bezug auf Internet Protocol Suites beschrieben, die von der tiefsten zur höchsten eine Link-, Netzwerk-, Transport- und Anwendungsschicht umfassen. Es können jedoch auch mehr oder weniger Schichten verwendet werden, und es können auch unterschiedliche Schichtenbezeichnungen für die Schichten im Protokollstapel 42 verwendet werden (z.B. eine Schichtung auf der Basis des Open Systems Interconnection („OSI") Modells).
Die Netzgeräte (14, 16, 18, 20, 22 und 24) sind mit dem ersten Computernetz 12 mit Netzschnittstellenkarte-(„NIC")-Gerätetreibern 44 für die Hardware-Netzgeräte verbunden, die die Netzgeräte mit dem Computernetz 12 verbinden. Über den Netzschnittstellenkarte-Gerätetreibern 44 befindet sich eine Netzwerkschicht 46 (die auch als Internet Layer für Internet Protocol Suites bezeichnet wird). Die Netzwerkschicht 46 beinhaltet eine IP-Schicht 48. Wie in der Technik bekannt ist, ist IP 48 ein Adressierungsprotokoll, das zum Leiten von Verkehr innerhalb eines Netzwerks oder zwischen Netzwerken ausgelegt ist. Die IP-Schicht 48, nachfolgend IP 48 genannt, ist in RFC-791 beschrieben.
Über der Netzwerkschicht 46 befindet sich eine Transportschicht 50. Die Transportschicht 50 beinhaltet eine Port Allocation Protocol („PAP") Schicht 52, eine Internet Group Management Protocol („IGMP") Schicht 54, eine Control Message Protocol („ICMP") Schicht 56, eine Transmission Control Protocol („TCP") Schicht 58 und eine User Datagram Protocol („UDP") Schicht 60. Es können jedoch auch mehr oder weniger Protokolle verwendet werden.
Die PAP-Schicht 52 ordnet einem Netzgerät lokal eindeutige Ports zu. In einer Ausgestaltung der vorliegenden Erfindung ist die PAP-Schicht 52 eine separate Protokollschicht in der Netzwerkschicht 46. In einer anderen Ausgestaltung der vorliegenden Erfindung wird die PAP-Schicht 52 als Teil der ICMP-Schicht 50 ausgeführt und ist keine separate Protokollschicht. In noch einer weiteren Ausgestaltung der vorliegenden Erfindung wird die PAP-Schicht 52 entweder über ein Transmission Control Protocol oder ein User Datagram Protocol laufen gelassen. Die PAP-Schicht 52 wird nachfolgend erläutert.
Die IGMP-Schicht 54, nachfolgend IGMP 54 genannt, ist für Multicasting verantwortlich. Weitere Informationen über IGMP 54 befinden sich in RFC-1112. Die ICMP-Schicht 56, im Folgenden ICMP 56 genannt, wird für die Internet Protocol Steuerung verwendet. Die Hauptfunktionen von ICMP 56 sind unter anderem Fehler-Reporting, Erreichbarkeitstests (z.B. „Pinging"), Leitwegänderungsavisierung, Leistung, Teilnetzadressierung und andere Wartungsvorgänge. Zu weiteren Informationen über ICMP 56 siehe RFC-792.
Die TCP-Schicht 58, nachfolgend TCP 58 genannt, bietet ein verbindungsorientiertes zuverlässiges End-to-End-Protokoll, das in eine geschichtete Hierarchie von Protokollen passt, die Multinetzanwendungen unterstützen. TCP 58 bietet zuverlässige Inter-Prozess-Kommunikationen zwischen Paaren von Prozessen in Netzgeräten, die an separate, aber untereinander verbundene Netzwerke angeschlossen sind. Zu weiteren Informationen über TCP 58 siehe RFC-793.
Die UDP-Schicht 60, nachfolgend UDP 60 genannt, bietet einen verbindungslosen Kommunikationsmodus mit Datagrams in einem untereinander verbundenen Satz von Computernetzen. UDP 60 bietet ein transaktionsorientiertes Datagram-Protokoll, bei dem Übermittlungs- und Paketduplizierschutz nicht garantiert sind. Zu weiteren Informationen über UDP 60 siehe RFC-768. Es sind nicht sowohl TCP 58 also auch UDP 60 im Protokollstapel 42 erforderlich, TCP 58 oder UDP 60 kann jeweils ohne die andere verwendet werden.
Über der Transportschicht 56 befindet sich eine Anwendungsschicht 62, in der sich Anwendungsprogramme zum Ausführen gewünschter Funktionen für ein Netzgerät befinden. So können beispielsweise die Anwendungsprogramme für das Netzgerät 16 Druckeranwendungsprogramme beinhalten, während Anwendungsprogramme für das Netzgerät 24 Telefax-Anwendungsprogramme beinhalten können, aber es können auch mehr oder weniger Protokollschichten im Protokollstapel 42 verwendet werden. DNAT-Protokoll
3 ist ein Blockdiagramm, das ein Port Allocation Protocol („PAP") 64 illustriert. PAP 64 wird in einer separaten PAP-Schicht 52 oder als integraler Bestandteil von ICMP 50 im Protokollstapel 42 implementiert (2). PAP 64 beinhaltet eine PAP- Anforderungsmeldung 66, eine PAP-Anwortmeldung 68, eine PAP-Invalidierungsmeldung 70 und eine Kombinationsnetzwerkadresse 72. PAP 64 beinhaltet auch eine PAP-Sicherheitsanforderungsmeldung 67, eine PAP-Sicherheitsantwortmeldung 69 und eine PAP-Sicherheitsinvalidierungsmeldung 71. Die PAP-Sicherheitsmeldungen 67, 69, 71 werden für Internet Protocol Sicherheit verwendet und werden nachfolgend erläutert. In einer bevorzugten Ausgestaltung der vorliegenden Erfindung entsprechen Felder in den PAP-Meldungen (66, 68, 70, 67, 69, 71) dem ICMP 50 Standardmeldungsformat. Es könnten aber auch andere Meldungslayouts (d.h. Non-ICMP 50 Meldungsformat) und mehr oder weniger Meldungen für PAP 64 Meldungen verwendet werden.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung wird die PAP-Anforderungsmeldung 66 von einem Netzgerät (14, 16, 18, 20, 22 und 24) zum Router 26 gesendet, um einen Block von lokal eindeutigen Portnummern anzufordern. In einer anderen Ausgestaltung der vorliegenden Erfindung wird PAP 64 mit einem anderen Netzgerät verwendet (z.B. einem Port-Server oder einem anderen Netzgerät separat vom Router 26). In einer weiteren bevorzugten Ausgestaltung der vorliegenden Erfindung wird PAP 64 zum Anfordern eines Blocks von Security Parameter Indexes („SPI") verwendet, die zum Herstellen von Security Associations („SA") verwendet werden, wenn Internet Protocol Sicherheit („IPsec") verwendet wird. Die Verwendung der SPIs wird nachfolgend erläutert.
4 ist ein Blockdiagramm, das ein PAP-Anforderungsmeldungslayout 74 illustriert. Ein Typ-Feld 76 hat ein Byte und einen Wert (z.B. 32) zum Anfordern von lokal eindeutigen Ports. Ein Code-Feld 78 hat ein Byte und einen Wert von null für Ports unter 10.000 und einen Wert von eins für Ports 10.000 oder darüber. Ein Prüfsumme-Feld 80 hat zwei Bytes und einen Wert von einer Einserkomplementsumme des gesamten Layout 74 der PAP-Anforderungsmeldung 66. Wie in der Technik bekannt ist, ist ein Einserkomplement für einen in binär oder Base-2 geschriebenen Wert (d.h. hat nur Nullen und Einsen) die Umkehr einer existierenden eins oder null. So ist ein Einserkomplement von 110₂ beispielsweise 001₂.
Das Angeforderte-Ports-Feld 82 hat ein Byte und einen variablen Wert, der eine Anzahl von durch ein Netzgerät angeforderten lokal eindeutigen Ports anzeigt. Das Angeforderte-Ports-Feld 82 ist vorgabemäßig 16 oder 32, was eine sinnvolle Zahl für die meisten Netzgeräte ist. Es könnten aber auch andere Vorgabenummern verwendet werden. Das Unbenutzt-Feld 84 hat drei Bytes und einen Wert von null. Es können aber auch andere Layouts, Werte und Feldgrößen für die PAP-Anforderungsmeldung 66 verwendet werden.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung sendet ein Netzgerät eine PAP-Anforderungsmeldung 66 nach dem Booten. PAP 64 ist mit dem Dynamic Host Configuration Protocol („DHCP") oder dem BOOTstrap Protocol („BOOTP") assoziiert. DHCP ist ein Protokoll zum Leiten von Konfigurationsinformationen wie IP 48 Adressen zu Hosts auf einem IP 48 Netzwerk. Weitere Informationen über DHCP befinden sich in RFC-1541 und RFC-2131. Das Format von DHCP-Meldungen basiert auf dem Format von BOOTP-Meldungen, die in RFC-951 und RFC-1542 beschrieben sind. Vom Standpunkt des Netzgerätes aus gesehen ist DHCP eine Erweiterung des BOOTP-Mechanismus.
In einer weiteren Ausgestaltung der vorliegenden Erfindung fordern die Netzgeräte (14, 16, 18, 20, 22, 24) lokal eindeutige Ports nach dem Booten an, wenn eine Protokollschicht im geschichteten Protokollstapel 42 eine Anfangsanforderung für ein externes Netzwerk (z.B. 30 oder 32) macht. Die Netzgeräte (14, 16, 18, 20, 22 und 24) können auch mehr lokal eindeutige Ports anfordern, wenn die Zahl der benötigten lokal eindeutigen Ports unter die den Netzgeräten zugeordnete Zahl von lokal eindeutigen Ports fällt.
Die PAP-Anforderungsmeldung 66 wird von einem Netzgerät (14, 16, 18, 20, 22 und 24) nach dem Hinzufügen eines IP 48 Headers oder eines anderen Meldungsheaders zum Router 26 gesendet. Eine PAP-Antwortmeldung 68 wird vom Router 26 zurück zu den Netzgeräten (14, 16, 18, 20, 22, 24) gesendet und bestätigt oder verneint die PAP-Anforderungsmeldung 66.
5 ist ein Blockdiagramm, das ein PAP-Antwortmeldungslayout 86 illustriert. Ein Typ-Feld 88 hat ein Byte und einen Wert zum Empfangen von Antworten (z.B. 32). Ein Code-Feld 90 hat ein Byte und einen Wert von null für Misserfolg und von eins für Erfolg. Ein Prüfsumme-Feld 92 hat zwei Bytes und eine 16-Bit-Einserkomplementsumme der gesamten PAP-Antwortmeldung 68. Ein Tiefster-Port-Feld 94 hat zwei Bytes und ist eine tiefste lokal eindeutige Portnummer, die in einem Block von lokal eindeutigen Ports zugeordnet ist. Ein Gesamtzahl-Ports-Feld 96 hat ein Byte und ist die Gesamtzahl der dem Netzgerät zugeordneten lokal eindeutigen Ports.
Ein Unbenutzt-Feld 98 hat ein Byte und einen Wert von null. Es sind aber auch andere Layouts, Werte und Feldgrößen für die PAP-Antwortmeldung 68 möglich.
Nach dem Empfang einer erfolgreichen PAP-Antwortmeldung 68 speichert ein Netzgerät den Block von lokal eindeutigen Ports, die es verwenden kann. Die lokal eindeutigen Ports werden in einer Datenstruktur mit einem Flag-Feld gespeichert, das anzeigt, ob der lokal eindeutige Port zugeordnet oder unbenutzt ist. Tabelle 1 ist ein Pseudo-Code für beispielhafte Datenstrukturen zum Speichern von lokal eindeutigen Portinformationen. Es sind aber auch andere Datenstrukturen oder Layouts möglich.
Tabelle 1
Die ein oder mehreren lokal eindeutigen Ports werden Protokollen und Anwendungen im geschichteten Protokollstapel 42 auf einem Netzgerät zugeordnet, um vorgabemäßige oder ephemere Ports zu ersetzen. Nach dem Empfang einer erfolglosen PAP-Antwortmeldung 68 kann ein Netzgerät eine andere PAP-Anforderungsmeldung 66 für weniger Ports senden. Wenn der Router 26 keinen ausreichend großen Block von zusammenhängenden lokal eindeutigen Ports für das Netzgerät zuordnen kann, dann kann er eine PAP-Antwort 68 mit einem Erfolgscode senden, kann aber weniger lokal eindeutige Ports als angefordert zuordnen.
6 ist ein Blockdiagramm, das ein PAP-Invalidierungsmeldungslayout 100 illustriert. Eine PAP-Invalidierungsmeldung 70 wird benutzt, um einen Block von gerade einem Netzgerät zugeordneten lokal eindeutigen Ports ungültig zu machen oder deren Zuordnung aufzuheben. Ein Typ-Feld 102 hat ein Byte und einen Wert zum Aufheben der Zuordnung von Ports (z.B. 32). Ein Code-Feld 104 hat ein Byte und einen Wert von zwei. Ein Prüfsumme-Feld 106 hat zwei Bytes und eine Einserkomplementsumme der gesamten PAP-Invalidierungsmeldung 70. Ein Port-Feld 108 hat ein Byte und einen Wert einer lokal eindeutigen Portnummer, die vom Netzgerät verwendet wird, das ungültig gemacht oder dessen Zuordnung aufgehoben wird. Ein Unbenutzt-Feld 110 hat drei Bytes und einen Wert von null. Es sind aber auch andere Layouts, Werte und Feldgrößen für die PAP-Invalidierungsmeldung 70 möglich.
Es ist möglich, dass zwei Netzgeräten überlappende Blöcke von lokal eindeutigen Ports zugeordnet werden, weil der Router 26 abgestürzt ist oder neu bootet. Der Router 26 muss eine PAP-Invalidierungsmeldung 70 senden, um alle lokal eindeutigen Ports ungültig zu machen, die nach dem Neubooten im Gebrauch sind, um dieses Problem verhüten zu helfen. Ein Netzgerät (14, 16, 18, 20, 22 und 24) sendet auch eine PAP-Invalidierungsmeldung 70, wenn es einen lokal eindeutigen Port nicht mehr benötigt.
7 ist ein Blockdiagramm, das ein kombiniertes Netzwerkadressenlayout 112 für eine kombinierte Netzwerkadresse 72 illustriert. Es können jedoch auch andere Layouts verwendet werden. Das kombinierte Netzwerkadressenlayout 112 beinhaltet eine gemeinsame externe Netzwerkadresse 114 wie z.B. eine IP 48 Adresse (z.B. eine gemeinsame Netzwerkadresse 28) und einen lokal eindeutigen Port 116, der durch Senden einer PAP-Anforderungsmeldung 66 und Empfangen einer PAP-Antwortmeldung 68 von einem Netzgerät erhalten wurde. Die Netzgeräte (14, 16, 18, 20, 22, 24) benutzen die kombinierte Netzwerkadresse 72 für Kommunikationen mit dem externen zweiten Netzwerk 30 oder dem dritten Netzwerk 32. Die gemeinsame externe Netzwerkadresse 114 identifiziert das erste Computernetz 12 für ein externes zweites Computernetz (z.B. 30 oder 32).
Wie in der Technik bekannt ist, stellt TCP 58 zum Identifizieren separater Datenströme ein Quellport-Feld in einem TCP 58 Header und ein Quelladressfeld in einem IP 48 Header bereit. Zu weiteren Informationen über TCP-Header siehe RFC-793. Da vorgabemäßige oder ephemere Portkennungen gewöhnlich unabhängig von einem TCP 58 Stapel in einem Netzwerk zugewiesen werden, sind sie typischerweise nicht eindeutig. Um Adressen in einem TCP 58 Stapel eindeutig zu machen, kann eine einen TCP-Stapel 58 identifizierende lokale Internetadresse mit einer vorgabemäßigen oder ephemeren Portkennung, einer Fern-Internetadresse und einer Fern-Portkennung verkettet werden, um eine „Assoziation" zu erzeugen. Die Assoziation ist über alle miteinander verbundenen Netzwerke eindeutig. Assoziationen sind der Fachperson in der Vernetzungstechnik bekannt.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung erhält der Quellport in einem Header einen mit PAP 64 erhaltenen lokal eindeutigen Port und erhält eine gemeinsame externe Netzwerkadresse. Gemeinsam identifizieren sie eindeutig Anwendungen und Protokolle auf den Netzgeräten (14, 16, 18, 20, 22, 24) auf dem ersten Computernetz 12 zum zweiten externen Computernetz (z.B. 30 oder 32), mit einem Wert, der konzeptuell einer von einem TCP-Stapel 58 verwendeten Assoziation ähnlich ist.
Wie ebenfalls in der Technik bekannt ist, hat UDP 60 auch ein Quellport-Feld in einem UDP-Header. Zu weiteren Informationen über UDP 60 Header siehe RFC-768. Der UDP 60 Quellport ist ein nicht-optionales Feld. Es zeigt einen Port des Sendevorgangs an und es wird angenommen, dass dies der Port ist, an den bei Fehlen anderer Informationen eine Antwort zu adressieren ist. Wird er nicht verwendet, dann wird ein Wert von null eingefügt. Ein UDP 60 Header hat auch ein Quelladresse-Feld. Ein lokal eindeutiger Port kann auch in einem UDP 60 Header verwendet werden.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung wird PAP 64 zum Erzeugen einer Kombinationsnetzwerkadresse 72 verwendet, die in den TCP 58 oder UDP 60 Header-Feldern verwendet wird. In einer anderen Ausgestaltung der vorliegenden Erfindung wird die Kombinationsnetzwerkadresse 72 in anderen Meldungsheader-Feldern gespeichert, die vom Router 26 (d.h. Non-IP 48, TCP 58 oder UDP 60 Felder), dem ersten Computernetz 12, dem zweiten Computernetz 30 und dem dritten Computernetz 32 verstanden werden.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung ordnet der Router 26 Blöcke von lokal eindeutigen Ports Netzgeräten (14, 16, 18, 20, 22 und 24) zu. Es können jedoch auch andere Netzgeräte verwendet werden, um lokal eindeutige Ports (z.B. einen Port-Server) zuzuordnen. Der Router 26 führt eine Port-zu-interne-Netzwerkadresse-Tabelle, wenn lokal eindeutige Ports zugeordnet werden. Der Router 26 hat auch eine interne Tabelle, die interne Netzwerkadressen für alle Netzgeräte (14, 16, 18, 20, 22, 24) auf dem ersten Computernetz 12 anzeigt. In einer bevorzugten Ausgestaltung der vorliegenden Erfindung sind die internen Netzwerkadressen für das erste Computernetz 12 private IP 48 Adressen. So lauten beispielsweise die internen IP-Adressen in 1 wie folgt: Computer 14 – 10.0.0.1 (1), Drucker 16 – 10.0.0.2, Computer 18 – 10.0.0.3, Taschencomputer 20 – 10.0.0.4, Telefon 22 – 10.0.0.5, Faxgerät 24 – 10.0.0.6 und Router 26 – 10.0.07. Die internen Adressen werden auf dem externen Computernetz (z.B. dem Internet oder einem Internet) nicht veröffentlicht. Es könnten jedoch auch andere interne Netzwerkadressen verwendet werden (z.B. Medium Access Control („MAC") Protokolladressen).
8 ist ein Blockdiagramm, das ein Layout der vom Router 26 geführten Port-zu-interner-Adresse-Tabelle 118 illustriert. Es könnten aber auch andere Layouts und mehr oder weniger Reihen und Spalten verwendet werden. Das Layout der Port-zu-interner-Adresse-Tabelle 118 hat drei Spalten: eine Interne-Netzwerkadresse-Spalte 120, eine Tiefster-Port-Spalte 122 und eine Anzahl-Ports-Spalte 124. Es könnten jedoch auch mehr oder weniger Spalten oder andere Tabellenlayouts verwendet werden. Die erste Reihe 126 zeigt an, dass einem Netzgerät Ports 1026–1057 für die Verwendung mit der internen Netzwerkadressse 10.0.0.1 (z.B. Computer 14) zugewiesen wurden. Einem zweiten Netzgerät wurden Ports 1058–1073 für die Verwendung mit der internen Netzwerkadresse 10.0.0.3 (z.B. Computer 18) zugeordnet. Eine interne Netzwerkadresse kann mehrere Einträge in der Port-zu-interner-Adresse-Tabelle 118 haben.
Adressenumsetzung in einem verteilten Netz
9 ist ein Ablaufdiagramm, das eine Methode 130 zum Zulassen von Adressenumsetzungen in einem verteilten Netz illustriert. In Schritt 132 fordert ein erstes Netzgerät auf einem ersten Computernetz einen oder mehrere lokal eindeutigen Ports von einem zweiten Netzgerät auf dem ersten Computernetz mit einem ersten Protokoll an. Die lokal eindeutigen Ports werden zum Ersetzen von vorgabemäßigen oder ephemeren Ports in Protokollschichten im geschichteten Protokollstapel 42 auf dem ersten Netzgerät verwendet. Darüber hinaus werden die lokal eindeutigen Ports zum Erzeugen einer Kombinationsnetzwerkadresse 72 verwendet, die einen lokal eindeutigen Port und eine gemeinsame externe Adresse für Kommunikationen mit einem zweiten externen Computernetz ohne Adressenumsetzung umfasst. In Schritt 134 empfängt das erste Netzgerät die ein oder mehreren lokal eindeutigen Ports vom zweiten Netzgerät. In Schritt 136 ersetzt das erste Netzgerät einen oder mehrere vorgabemäßige oder ephemere Ports, die in dem geschichteten Protokollstapel 42 mit ein oder mehreren lokal eindeutigen Ports verwendet werden. Schritt 138 erzeugt das erste Netzgerät eine oder mehrere Kombinationsnetzwerkadressen 72 mit Hilfe der ein oder mehreren lokal eindeutigen Ports und eine gemeinsame externe Netzwerkadresse, die zum Identifizieren des ersten Computernetzes auf dem zweiten externen Computernetz verwendet wird.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Netzgerät ein beliebiges der Netzgeräte (14, 16, 18, 20, 22, 24), das zweite Netzgerät ist der Router 26, das erste Computernetz ist das erste Computernetz 12 (z.B. SOHO LAN), das erste Protokoll ist PAP 64, das zweite externe Computernetz ist entweder das zweite Computernetz 30 (z.B. das Internet oder ein Intranet) oder das dritte Computernetz 32 (z.B. PSTN). Die Kombinationsnetzwerkadresse 72 beinhaltet eine gemeinsame IP 48 Adresse (z.B. eine gemeinsame Netzwerkadresse 28), die Netzgeräte auf dem ersten Computernetz 32 für ein zweites externes Computernetz identifiziert (z.B. 30 oder 32). Die vorliegende Erfindung ist jedoch nicht auf die beschriebenen Netzwerke, Netzgeräte, Netzwerkadressen oder Protokolle begrenzt und es sind auch andere möglich.
Die lokal eindeutigen Ports werden für Objekte wie Protokolle und Anwendungen im geschichteten Protokollstapel 42 auf einem Netzgerät verwendet und sind auf dem ersten Computernetz 12 lokal eindeutig. Die lokal eindeutigen Ports identifizieren ein Netzgerät auf dem ersten Computernetz 12. So wird beispielsweise in TCP 58 gewöhnlich dem TCP 58 Stapel ein vorgabemäßiger oder ephemerer Port zugewiesen (z.B. 1234). Nach dem Zuordnen mit Methode 130 verwendet ein Netzgerät einen lokal eindeutigen Port zum Ersetzen eines vorgabemäßigen oder ephemeren Ports in einer Protokollschicht im geschichteten Protokollstapel 42. Wie in 8 illustriert, werden dem Netzgerät 14 mit einer internen IP 48 Adresse 10.0.0.1 zweiunddreißig lokal eindeutige Ports im Bereich 1026–1057 zugewiesen. Das Netzgerät 14 kann TCP 58 den lokal eindeutigen Port 1032 für die Verwendung als vorgabemäßigen oder ephemeren Port zuweisen. Ein ursprünglicher vorgabemäßiger oder ephemerer Port für TCP 58 war 1234. Die in 7 illustrierte Kombinationsnetzwerkadresse 112 wird TCP 58 dann auf dem Netzgerät 14 für Kommunikationen mit einem externen Netzwerk zugewiesen (z.B. 30 oder 32). Andere lokal eindeutige Ports werden anderen Protokollen und Anwendungen im geschichteten Protokollstapel 42 auf einem Netzgerät zugewiesen, um andere Vorgabeports zu ersetzen.
In einer Ausgestaltung der vorliegenden Erfindung werden lokal eindeutige Ports Protokollschichten im geschichteten Protokollstapel 42 zugewiesen, wenn ein Netzgerät bootet. In einer anderen Ausgestaltung der vorliegenden Erfindung werden lokal eindeutige Ports Protokollschichten im geschichteten Protokollstapel zugewiesen, wenn eine Protokollschicht eine Anforderung für ein externes Netzwerk (z.B. 30 oder 32) macht. In noch einer anderen Ausgestaltung der vorliegenden Erfindung werden lokal eindeutige Ports dynamisch oder On-the-fly in einer individuellen Protokollschicht dynamisch zugewiesen, wenn eine Protokollschicht eine Anforderung für ein externes Netzwerk (z.B. 30 oder 32) macht.
Die lokal eindeutigen Ports mit gemeinsamer externer Netzwerkadresse 28 als Kombinationsnetzwerkadresse 112 identifizieren eindeutig ein Objekt auf einem Netzgerät zu einem externen Netzwerk (z.B. 30 oder 32) ohne Umsetzung.
Netzschnittstellenkarte-Gerätetreiber 44 führen die tatsächliche interne IP 48 Adresse eines Netzgerätes.
Lokal eindeutige Ports können auch mit der gemeinsamen externen Netzwerkadresse 28 verwendet werden (z.B. für Mobile IP). Lokal eindeutige Ports helfen beim Identifizieren eines mobilen Netzgerätes, das von einem Heimatnetz (z.B. im ersten Computernetz 12) zu einem Fremdnetz roamt.
10 ist ein Ablaufdiagramm, das eine Methode 140 für die Adressenumsetzung im verteilten Netz illustriert. In Schritt 142 wird eine Anforderung von einem ersten Netzgerät auf einem ersten Computernetz zu einem zweiten Netzgerät auf dem ersten Computernetz gesendet. Die Anforderung gilt für ein zweites externes Netzwerk und beinhaltet eine Kombinationsnetzwerkadresse 72, die das erste Netzgerät auf dem ersten Netzwerk identifiziert. Die Kombinationsnetzwerkadresse 72 wird mit Methode 130 (9) konstruiert und beinhaltet einen lokal eindeutigen Port und eine gemeinsame externe Adresse zum Identifizieren des ersten Computernetzes für das zweite externe Netzwerk. In Schritt 144 leitet das zweite Netzgerät die Anforderung vom ersten Computernetz zum zweiten externen Netzwerk. In Schritt 146 empfängt das zweite Netzgerät auf dem ersten Computernetz eine Antwort vom externen zweiten Computernetz auf der externen Netzwerkadresse, die das erste Netzwerk von der Kombinationsnetzwerkadresse identifiziert. In Schritt 148 leitet das zweite Netzgerät auf dem ersten Computernetz die Antwort zum ersten Netzgerät auf dem ersten Computernetz mit dem lokal eindeutigen Port von der Kombinationsnetzwerkadresse zum Identifizieren des ersten Netzgerätes.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Netzgerät ein beliebiges der Netzgeräte (14, 16, 18, 20, 22, 24), das zweite Netzgerät ist der Router 26. Das erste Computernetz ist das erste Computernetz 12, und das zweite Computernetz ist das zweite Computernetz 30 oder das dritte Computernetz 32. Die Kombinationsnetzwerkadresse beinhaltet einen mit PAP 64 erhaltenen lokal eindeutigen Port und eine externe IP 48 Adresse für ein externes Netzwerk wie das Internet, ein Intranet oder ein anderes Computernetz. Die vorliegende Erfindung ist jedoch nicht auf die beschriebenen Netzwerke, Netzgeräte, Netzwerkadressen oder Protokolle begrenzt und es können auch andere verwendet werden.
Methode 140 (10) ist mit einem speziellen Beispiel mit TCP 58/IP 48 Schichten vom geschichteten Protokollstapel 42 illustriert. Es können aber auch andere Protokollschichten im geschichteten Protokollstapel 42 verwendet werden. In Schritt 142 sendet das Netzgerät 14 eine TCP 58 Anforderung zum Server 39 (1). Zum Beispiel, eine TCP 58 Anforderung für Server 39 an der externen IP 48 Adresse 192.200.20.3 auf dem zweiten Computernetz 30. Tabelle 2 illustriert ein Beispiel für ein in Schritt 142 gesendetes Anforderungsdatenpaket.
Tabelle 2
Die IP 48 Quelladresse ist die gemeinsame externe Netzwerkadresse 28 (z.B. 198.10.20.30) und der Quellport ist ein lokal eindeutiger Port 1032, der über PAP 64 mit Methode 130 erhalten wurde und für einen TCP 58 Service zur Verfügung steht. In einer Ausgestaltung der vorliegenden Erfindung ersetzt der lokal eindeutige Port 1032 den Vorgabeport 1234 für TCP 58, wenn das Netzgerät 14 gebootet wird. In einer anderen Ausgestaltung der vorliegenden Erfindung wird der Vorgabeport 1234 durch einen lokal eindeutigen Port wie z.B. den lokal eindeutigen Port 1032 ersetzt, wenn eine Protokollschicht in einem geschichteten Protokollstapel die Anforderung macht. Der lokal eindeutige Port zusammen mit der gemeinsamen externen Adresse umfassen die Kombinationsnetzwerkadresse 112.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung wurde der TCP 58 Vorgabeport 1234 durch einen lokal eindeutigen Port 1032 ersetzt. Die IP-Zieladresse ist 192.200.20.3 für den Server 39 (1) auf dem zweiten externen Netzwerk 30, der Zielport ist ein bekannter Internet-Port 80. Wenn die Anforderung einen Netzschnittstellenkarte-Gerätetreiber 44 im geschichteten Protokollstapel 42 erreicht, dann wird ein äußerer IP 48 Header zum Leiten der Anforderung zum Router 26 hinzugefügt. So ist beispielsweise der äußere IP 48 Header ein virtueller Tunnel-Header, der nachfolgend erläutert wird. Netzschnittstellenkarte-Gerätetreiber führen die lokale interne Netzwerkadresse (z.B. 10.0.0.x) für ein Netzgerät für interne Kommunikationen. Tabelle 3 illustriert ein beispielhaftes Datenpaket mit einem äußeren IP 48 Header, der für den Router 26 hinzugefügt wurde.
Tabelle 3
Ein Netzschnittstellenkarte-Gerätetreiber 44 fügt den äußeren IP 48 Header hinzu, einschließlich (z.B. ein virtueller Tunnel-Header) einer IP 48 Quelladresse für das Netzgerät 14 von 10.0.0.1 und einer IP 48 Zieladresse von 10.0.0.7 für den Router 26. In Schritt 144 empfängt der Router 26 das Anforderungsdatenpaket, zieht den äußeren IP 48 Header aus und sendet das Anforderungsdatenpaket zum externen Netzwerk 30.
In Schritt 146 empfängt der Router 26 ein Antwortpaket von einem externen Netzwerk (z.B. 30). Tabelle 4 zeigt ein beispielhaftes Antwortdatenpaket.
Tabelle 4
Der Router 26 empfängt das Antwortpaket vom externen zweiten Netzwerk 30 in Schritt 146 mit einer IP 48 Zieladresse für die gemeinsame externe Netzwerkadresse 198.10.20.30 und einem Zielport, der auf den lokal eindeutigen Port 1032 gesetzt ist. Der Router 26 verwendet die Port-zu-interne-Netzwerkadresse-Tabelle (8) zum Abbilden von Zielport 1032 auf eine interne IP 48 Adresse 10.0.0.1 für den Computer 14. Der Router 26 fügt einen äußeren IP 48 Header (z.B. einen virtuellen Tunnel-Header) zum Leiten des Antwortdatenpakets hinzu, das zum Netzgerät 14 zurückgesandt wird. Tabelle 5 illustriert ein beispielhaftes Antwortpaket mit einem vom Router 26 hinzugefügten äußeren IP 48 Header.
Tabelle 5
Der äußere IP 48 Header hat eine interne IP 48 Quelladresse von 10.0.0.7 für den Router 26 und eine interne IP 48 Zieladresse von 10.0.0.1 für das Netzgerät 14 auf dem Computernetz 12. In Schritt 148 leitet der Router 26 das Antwortdatenpaket zum Netzgerät 14 mit dem äußeren IP 48 Header. Ein Netzschnittstellenkarte-Gerätetreiber 44 im geschichteten Protokollstapel 42 zieht den äußeren IP 48 Header aus und leitet das Antwortdatenpaket zur Netzwerkschicht 46 weiter. Dieser Schritt kann auch im Gerätetreiber erfolgen.
Das Netzgerät 14 sendet eine Anforderung zu einem externen Netzwerk und empfängt eine Antwort vom externen Netzwerk mit DNAT und dem mit PAP 64 zugeordneten lokal eindeutigen Port 1032. Der Router 26 setzt keine Quell/Ziel-IP-48- Adressen oder Quell-/Zielports um. Somit wird DNAT ohne Netzwerkadressenumsetzung am Router 26 durchgeführt.
Eine bevorzugte Ausgestaltung der vorliegenden Erfindung wird mit Bezug auf eine einzelne gemeinsame externe Netzwerkadresse beschrieben, die mehrere Netzgeräte auf dem ersten Computernetz 12 identifiziert und in der Kombinationsnetzwerkadresse 112 mit einem lokal eindeutigen Port verwendet wird. Die vorliegende Erfindung ist jedoch nicht auf eine einzelne gemeinsame externe Netzwerkadresse begrenzt und kann auch mit mehreren gemeinsamen externen Netzwerkadressen ausgeübt werden.
Die Adressenumsetzung in einem verteilten Netz mit Methode 130 (9) und Methode 132 (10) beseitigt die Rechenlast von NAT am Router 26 und lässt es zu, dass mehrere Netzwerkadressen eine einzelne oder eine geringe Zahl von externen Netzwerkadresse(n) verwenden, die einem externen Netzwerk wie dem Internet oder einem Intranet bekannt sind. Anstatt NAT bereitzustellen, leitet der Router 26 Datenpakete von einem Netzgerät (14, 16, 18, 20, 22, 24) auf dem ersten Computernetz 12 zu einem zweiten externen Computernetz wie z.B. dem zweiten Computernetz 30 oder dem dritten Computernetz 32 mit der Kombinationsnetzwerkadresse. Außerdem wird der Router 26 nicht mehr zum Unterstützen von mehreren Anwendungsprogrammen vom geschichteten Protokollstapel 42 benötigt.
Der Router 26 leitet auch Datenpakete vom zweiten externen Computernetz zurück zu einem Netzgerät auf dem ersten Computernetz mit dem lokal eindeutigen Port in der Kombinationsnetzwerkadresse. Der Router 26 wird nicht mehr zum Ersetzen einer internen Netzwerkadresse durch eine externe Netzwerkadresse für abgehenden Verkehr und zum Ersetzen einer externen Netzwerkadresse durch eine interne Netzwerkadresse für eingehenden Verkehr benötigt. Somit beseitigt DNAT der vorliegenden Erfindung die Rechenlast von NAT vom Router 26 und verletzt nicht das Internet-Prinzip des Bereitstellens einer Ende-zu-Ende-Übertragung von Datenpaketen zwischen Netzgeräten ohne Änderungen.
DNAT mit Portumsetzung
In einer weiteren bevorzugten Ausgestaltung der vorliegenden Erfindung wird DNAT ohne Modifikation von Protokollen oder Anwendungen im geschichteten Protokollstapel 42 über der Netzwerkschnittstellengeräte-Treiberschicht 44 ausgeführt. In einer solchen Ausgestaltung wird jedoch ein Netzschnittstellenkarte-Gerätetreiber 44 in den Netzgeräten (14, 16, 18, 20, 22, 24) zum Umsetzen von vorgabemäßigen oder vorgabemäßigen [sic] Ports On-the-fly zu/von lokal eindeutigen Ports verwendet, die von einem Netzgerät mit PAP 64 reserviert werden. Darüber hinaus unterstützt der Netzschnittstellenkarte-Gerätetreiber 44 mehrere Protokolle vom geschichteten Protokollstapel 42 für DNAT mit Portumsetzung.
Man nehme z.B. an, der Computer 14 (1) mit der internen IP 48 Adresse 10.0.0.1 mache eine TCP 58/IP 48 Anforderung von einem Server auf dem zweiten Computernetz 32 (z.B. im Internet) an der externen IP 48 Adresse 192.200.20.3 (d.h. Web-Server 39, 1). Tabelle 6 zeigt das erste TCP 58 Paket, das den Netzschnittstellenkarte-Gerätetreiber 44 des geschichteten Protokollstapels 42 erreicht.
Tabelle 6
Der lokale Quellport für TCP 58 ist 1234, der Zielport ist der bekannte Port 80 für das Internet, die IP 48 Quelladresse ist die gemeinsame externe Netzwerkadresse 28 und die Zieladresse ist die externe IP 48 Adresse für den Server 39 (1).
In der oben erörterten bevorzugten Ausgestaltung unter Anwendung der Methoden 130 und 140 der 9 und 10 werden die lokalen vorgabemäßigen Anwendungs- und/oder Protokollports von einem Netzgerät so modifiziert, dass ein lokal eindeutiger Port verwendet wird, der über PAP 64 in Protokollschichten über den Gerätetreibern erhalten wird. Für DNAT mit Portumsetzung werden Ports jedoch nicht im geschichteten Protokollstapel 42 umgesetzt. Netzschnittstellenkarte-Gerätetreiber bieten stattdessen Port- und Adressenumsetzung. In einer solchen Ausgestaltung stellt ein Netzschnittstellenkarte-Gerätetreiber 44 fest, dass eine Verbindung initiiert wird. Es wird ein Eintrag in einer Source Port Translation Table („SPTT") in einem Netzschnittstellenkarte-Gerätetreiber 44 erzeugt.
11 illustriert ein SPTT-Layout 150. Es können jedoch auch andere Layouts, Feldgrößen und Werte verwendet werden. Ein Vorgabe-Port-Feld 152 hat zwei Bytes und ist eine vorgabemäßige oder ephemere Portnummer, die von einem TCP 58 Service und anderen Anwendungen eines Netzgerätes verwendet wird. Ein Umgesetzter-Port-Feld 154 hat zwei Bytes und ist eine lokal eindeutige Portnummer, die für von PAP 64 zugeordnete externe Kommunikationen verwendet wird. Ein Protokoll-Feld 156 hat ein Byte und einen Wert von null für TCP 58 und einen Wert von eins für UDP 60. Ein Zeitmarke-Feld 158 hat vier Bytes und beinhaltet einen Wert einer aktuellen Systemzeit in Millisekunden, die bei jedem Gebrauch dieses Eintrags aktualisiert wird.
Der TCP 58 Quellport 1234 wird in einen lokal eindeutigen Port umgesetzt, der durch PAP 64 von einem Netzschnittstellenkarte-Gerätetreiber zugeordnet wird. Der TCP 58 Quellport 1234 wird in der TCP 58 Schicht oder einer anderen Protokollschicht über dem Netzschnittstellenkarte-Gerätetreiber 44 im geschichteten Protokollstapel 42 nicht umgesetzt. Ein Eintrag wird zur SPTT 150 hinzugefügt. Tabelle 7 illustriert einen beispielhaften SPTT 150 Tabelleneintrag.
Tabelle 7
Nach dem Umsetzen durch den Netzschnittstellenkarte-Treiber wird ein äußerer IP 48 Header zum Datenpaket hinzugefügt. Der äußere IP-Header wird zum Leiten (durch einen virtuellen Tunnel) verwendet. Der äußere IP-Header hat die interne Adresse des Netzgerätes als IP 48 Quelladresse (z.B. 10.0.0.1) und die interne Netzwerkadresse von Router 26 (z.B. 10.0.0.7) als die Zieladresse. Tabelle 8 illustriert das Datenpaket mit dem äußeren IP 48 Header.
Tabelle 8
Nach dem Empfangen des in Tabelle 4 illustrierten Datenpakets untersucht der Router 26 den Quellport (z.B. 1032) und die äußere IP 48 Quelladresse (z.B. 10.0.0.1), um sicherzustellen, dass ein Netzgerät einen gültigen lokal eindeutigen Port verwendet, der dem Netzgerät zugewiesen wurde. Der Router 26 führt eine IP Address Translation Table („IAPTT").
12 zeigt ein beispielhaftes IAPTT-Layout 160. Es können aber auch andere Layouts, Feldgrößen und Werte verwendet werden. Ein Zielport-Feld 162 hat zwei Bytes und enthält einen lokal eindeutigen Port, der mit PAP 64 erhalten wurde. Ein Interne-IP-Zieladresse-Feld 164 hat vier Bytes und ist die interne IP 48 Adresse 8 z.B. 10.0.0.1) eines Netzgerätes, das den lokal eindeutigen Port im Zielport-Feld 162 verwendet. Ein Protokoll-Feld 166 hat ein Byte und einen Wert von null für TCP 58 oder einen Wert von eins für UDP 60. Ein Zeitmarke-Feld 168 hat vier Bytes und beinhaltet einen Wen einer aktuellen Systemzeit in Millisekunden, der bei jedem Gebrauch dieses Eintrags aktualisiert wird. Tabelle 9 zeigt einen beispielhaften IPATT 160 Tabelleneintrag.
Tabelle 9
Tabelle 9 illustriert, dass ein lokal eindeutiger Port 1032 mit der internen IP 48 Adresse 10.0.0.1 (z.B. Computer 14) für das TCP 58 Protokoll assoziiert ist. Der Router 26 zieht den äußeren IP 48 Header in Tabelle 4 aus und sendet das Datenpaket, das den inneren IP 48 Header und den TCP 58 Header enthält, zum externen Netzwerk 30.
Ein Antwortdatenpaket kommt von einem externen Netzwerk auf der gemeinsamen externen Netzwerkadresse 28 (z.B. 198.10.20.30) an. Ein ankommendes Datenpaket enthält die in Tabelle 10 illustrierten Header.
Tabelle 10
Der Router 26 schlägt den Zielport (d.h. den lokal eindeutigen Port 1032) in IPATT 158 (Tabelle 9) nach und findet die lokale Netzwerkadresse 10.0.0.1 (z.B. für Computer 14). Der Router 26 erzeugt dann einen äußeren IP 48 Header wie z.B. den in Tabelle 11 illustrierten beispielhaften IP 48 Header. Der äußere IP 48 Header hat eine IP 48 Quelladresse für den Router 26 und eine IP 48 Zieladresse für das Netzgerät 14.
Tabelle 11
Der Router 26 überträgt dann das in Tabelle 11 illustrierte Datenpaket zum entsprechenden Netzgerät (z.B. Computer 14 an der internen Adresse 10.0.0.1). Nach dem Empfang des Datenpakets schlägt ein Netzschnittstellenkarte-Treiber den Zielport (z.B. 1032) in der SPTT 148 (z.B. Tabelle 7) nach und findet ein Mapping auf TCP 58, Port 1234. Der lokal eindeutige Port 1032 wird dann zurück auf Vorgabeport 1234 von TCP 58 im Gerätetreiber umgesetzt. Über dem Gerätetreiber erfolgt keine Umsetzung. Dann wird der äußere IP 48 Header ausgezogen. Das Datenpaket wird zu IP 48 in der Netzwerkschicht 46 weitergeleitet. Tabelle 12 illustriert das weitergeleitete Datenpaket.
Tabelle 12
Das Ende der Verbindung wird sowohl vom Router 26 als auch vom Netzgerät 14 erfasst. Nach dem Verbindungsende werden die Einträge in den Tabellen SPTT 148 und IPATT 160 vom Router 26 und vom Netzschnittstellenkartentreiber entfernt.
13 illustriert eine Methode 170 für eine abgehende Verteiltes-Netz-Adressenumsetzung mittels Portumsetzung. In Schritt 172 empfängt ein Netzschnittstellenkarte-Gerätetreiber 44 ein Datenpaket von der Netzwerkschicht 46 (z.B. Tabelle 6). In Schritt 174 führt der Netzschnittstellenkarte-Gerätetreiber 44 einen Test durch, um zu ermitteln, ob eine Zielnetzwerkadresse (z.B. 192.200.20.3) für ein externes Netzwerk (z.B. 30 oder 32) ist. Wenn ja, dann fügt der Netzschnittstellenkarte-Gerätetreiber 44 in Schritt 176 einen äußeren IP 48 Header (z.B. einen virtuellen Tunnel-Header) zum Datenpaket hinzu, dessen Quelladresse auf die interne IP 48 Adresse (z.B. 10.0.0.1) des Netzgerätes und dessen Zieladresse auf die interne Adresse (z.B. 10.0.0.7) (z.B. Tabelle 8) des Routers 26 gesetzt ist. In Schritt 178 wird ein lokaler Quellport für die Anwendung oder das Protokoll vom Header (z.B. TCP 58 Port 1234) in einen lokal eindeutigen Port (z.B. 1032) umgesetzt, der über PAP 64 mit SPTT 150 (z.B. Tabelle 7) erhalten wurde. In Schritt 180 wird das Datenpaket mit dem äußeren IP 48 Header zur Netzschnittstellenkarte-Hardware übertragen, die das Datenpaket zum Router 26 weiterleitet.
Wenn der Test in Schritt 174 ermittelt, dass die Zielnetzwerkadresse für das interne Netzwerk 12 ist, dann wird der vorgabemäßige oder ephemere Quellport in Schritt 182 nicht in einen lokal eindeutigen Port für interne Kommunikationen umgesetzt. Mit der Methode 170 erfolgt die Verteiltes-Netz-Adressenumsetzung über einen Netzschnittstellenkarte-Gerätetreiber und es erfolgt keine Portumsetzung über dem Gerätetreiber. Andere Software- oder Hardware-Module oder Treiber außer dem Netzschnittstellenkarte-Gerätetreiber 44 könnten jedoch auch Ports mit Methode 170 umsetzen.
14 ist ein Ablaufdiagramm, das eine Methode 184 für eine eingehende Verteiltes-Netz-Adressenumsetzung mittels Portumsetzung illustriert. In Schritt 186 wird ein Datenpaket auf einem Netzschnittstellenkarte-Treiber 44 (z.B. Tabelle 11) vom Router 26 empfangen. Der Router 26 empfing das Datenpaket vom externen Netzwerk 30 oder 32 und fügte einen äußeren IP 48 Header hinzu. In Schritt 188 wird in einem Test ermittelt, ob die IP 48 Quelladresse vom inneren IP 48 Header eine externe IP 48 Adresse ist. Wenn ja, dann wird der Zielport vom inneren IP 48 Header in Schritt 190 von einem lokal eindeutigen Port auf einen Vorgabeport (z.B. 1032 → 1234) mittels der SPATT 158 (Tabelle 7) umgesetzt. In Schritt 192 wird der äußere IP 48 Header ausgezogen. In Schritt 192 wird das Datenpaket (z.B. Tabelle 12) zur Netzwerkschicht 46 weitergeleitet.
Wenn bei dem Test in Schritt 188 ermittelt wird, dass die IP 48 Quelladresse für das interne Netzwerk 12 ist, dann wird die IP 48 Quelladresse vom äußeren IP 48 Header in Schritt 196 auf die innere IP 48 Quelladresse kopiert. In Schritt 192 wird der äußere IP 48 Header ausgezogen. In Schritt 194 wird das Datenpaket zur Netzwerkschicht 46 weitergeleitet. Der vorgabemäßige oder lokale Quellport wird nicht in einen lokal eindeutigen Port für interne Kommunikationen umgesetzt.
Dann erfolgt eine Verteiltes-Netz-Adressenumsetzung durch einen Netzschnittstellenkarte-Gerätetreiber mit der Methode 184 und es erfolgt keine Portumsetzung über dem Gerätetreiber. Es könnten jedoch andere Software- oder Hardware-Module oder Treiber außer einem Netzschnittstellenkarte-Gerätetreiber oder in Schichten über dem Netzschnittstellenkarte-Gerätetreiber 44 Ports auch mit der Methode 184 umsetzen.
DNAT (9 und 10) führt Portumsetzung in individuellen Protokollschichten im geschichteten Protokollstapel 42 durch. Die Portumsetzung erfolgt beim Booten für ein Netzgerät oder dynamisch in einer Protokollschicht, wenn eine Protokollschicht eine Anforderung an ein externes Netzwerk (z.B. 30 oder 32) macht.
Im Gegensatz dazu führt DNAT mit Portumsetzung (13 und 14) eine Portumsetzung im Netzschnittstellenkarte-Gerätetreiber 44 auf einem Netzgerät durch. Es werden keine Ports in Protokollschichten über dem Gerätetreiber umgesetzt. Darüber hinaus unterstützt der Netzschnittstellenkarte-Gerätetreiber 44 mehrere Protokolle vom geschichteten Protokollstapel 42 über dem Netzschnittstellenkarte-Gerätetreiber 44 für DNAT mit Portumsetzung. Für abgehende Daten wird ein einer Anwendung oder einem Protokoll zugewiesener Vorgabeport „On-the-fly" im Gerätetreiber in einen lokal eindeutigen Port umgesetzt. Für eingehende Daten setzt das Netzgerät einen lokal eindeutigen Port On-the-Fly zurück auf einen Vorgabeport im Gerätetreiber um. DNAT mit On-the-Fly Portumsetzung im Netzschnittstellenkarte-Gerätetreiber 44 (13 und 14) verursacht mehr Rechen-Overhead auf einem Netzgerät als DNAT mit Portumsetzung in individuellen Protokollschichten (10).
DNAT mit On-the-Fly Portumsetzung im Netzschnittstellenkarte-Gerätetreiber 44 (13 und 14) wird jedoch weiterhin gegenüber nicht verteilter NAT im Router 26 mit in der Technik bekannten Methoden bevorzugt, da Rechenkosten für die Umsetzung über eine Mehrzahl von Netzgeräten verteilt und nicht im Router 26 konzentriert sind. Der Router 26 setzt keine Adressen für die beschriebenen Ausgestaltungen der vorliegenden Erfindung um. Verfahren und Protokoll für die oben beschriebene Verteiltes-Netz-Adressenumsetzung können auch mit Protokollen verwendet werden, die Sicherheit für ein IP 48 benutzendes Netzwerk bieten.
Internet Protocol Sicherheit
Es gibt eine Reihe von Sicherheitsmaßnahmen, die mit IP 48 getroffen werden können. Eine oder mehrere Sicherheitsmaßnahmen können in einem IP 48 Header angedeutet werden. Die Internet Protocol Sicherheitsverarbeitung ist vollständig auf die IP 48 Schicht begrenzt. Sämtliche DNAT-Verarbeitung, wenn sie mit Internet Protocol Security verwendet wird, muss über der IP 48 Schicht laufen, sonst werden die Internet Protocol Sicherheitsparameter verletzt.
15 ist ein Blockdiagramm, das einen IP 48 Paket-Header 200 illustriert. Ein Version-Feld 202 enthält eine IP 48 Protocollversion (z.B. IPv4 oder IPv6). Ein Internet-Header-Länge („IHL") Feld 204 enthält eine Länge für den Header. Ein Type-of-Service („ToS") Feld 206 enthält einen angeforderten Service-Typ. Ein Gesamtlänge-Feld 208 enthält eine Länge von allem in einem IP 48 Datenpaket einschließlich dem IP 48 Header 200. Ein Identifikation-Feld 210 wird mit Paketfragmentierung verwendet. Ein Fragment-Versatz-Feld 212 wird ebenfalls mit Paketfragmentierung verwendet. Ein Time-to-Live („TTL") Feld 214 wird jetzt eine Hop-Zahl, die zum Begrenzen einer Lebensdauer für ein IP 48 Paket mit dem Header verwendet wird. Ein Protokoll-Feld 216 beinhaltet ein Protokoll, das mit dem IP 48 Paket 200 verwendet wird (z.B. TCP 58, UDP 60, ESP, AH usw.). Ein Header-Prüfsumme-Feld 218 wird zum Verifizieren des Inhalts des IP 48 Paket-Headers 200 verwendet. Ein Quelladresse-Feld 220 enthält eine IP 48 Quelladresse für einen Sendeendpunkt. Ein Zieladresse-Feld 222 enthält eine IP 48 Adresse für einen Empfangsendpunkt. Ein Optionen-Feld 224 wird für Sicherheit, Source-Routing, Fehlerberichterstattung, Debugging, Zeitmarkierung und andere Informationen verwendet. IP 48 Daten (z.B. TCP 58, UDP 60 usw.) erscheinen unter dem Optionen-Feld 224.
Internet Protocol Security („IPsec") bietet Sicherheit für IP 48 Pakete. Zu weiteren Informationen über IPsec siehe „Security Architecture for the Internet Protocol" von S. Kent und R. Atkinson, RFC-2401, November 1998. IPsec erfüllt typischerweise drei Sicherheitsanforderungen. IPsec bietet Meldungsauthentifizierung, -integrität und -vertraulichkeit für IP 48 Pakete, die zwischen einem Quell- und einem Zielendpunkt laufen. Beginnend in einem Zustand, in dem keine Verbindung zwischen zwei Endpunkten vorliegt, kann eine Security Association („SA") auf der Basis von IP 48 hergestellt werden, so dass jeder Endpunkt der Sicherheit der Verbindung vertraut, und eine Identität jedes Endpunkts wird für den anderen authentifiziert.
IPsec definiert typischerweise zwei Sicherheitsdienste, jeweils mit einem assoziierten Header, der einem davon geschützten IP 48 Paket hinzugefügt wird. Die beiden Sicherheitsdienste sind ein Authentication Header („AH") und ein Encapsulating Security Payload („ESP") Header. Es können jedoch auch mehr oder weniger Sicherheitsdienste mit IPsec verwendet werden.
Der AH bietet Authentifizierungs- und Integritätsschutz für IP 48 Pakete. Weitere Informationen über AH befinden sich in „IP Authentication Header" von S. Kent und R. Atkinson, RFC-2402, November 1998.
ESP bietet Verschlüsselungsschutz sowie bei Bedarf Authentifizierungs- und Integritätsschutz. Weitere Informationen über ESP siehe in „IP Encapsulating Security Payload (ESP)" von S. Kent und R. Atkinson, RFC-2406, November 1998.
Die IPsec Protokoll-Header werden im Protokoll-Feld 216 eines IP-Paket-Headers 200 identifiziert (15). Ein IPsec Protokoll-Header gibt einen Protokolltyp (d.h. AH oder ESP) vor und enthält einen numerischen Wert mit der Bezeichnung Security Parameter Index („SPI"). Der SPI ist eine eindeutige Kennung, die durch einen Empfangsendpunkt mit einer SA assoziiert ist. Die Identifikationsinformationen werden von einem Empfangsendpunkt verwendet, um bei einer korrekten Assoziation eines IP 48 Pakets mit einer SA zu helfen. Eine korrekte Assoziation eines IP 48 Pakets mit einer SA ist notwendig, um eine richtige IPsec-Verarbeitung anzuwenden.
Die IPsec-Dienste können in einer von zwei Modi angewendet werden, einem „Transportmodus" oder einem „Tunnelmodus". Im Transportmodus wird ein Paket direkt zu seinem Endziel gemäß einer Zieladresse geleitet (z.B. IP 48 Zieladresse 222 (15)). Ein Endziel ist dort, wo die IPsec-Verarbeitung erfolgt, sowie dort, wo das IP 48 Paket „konsumiert" (d.h. verarbeitet) wird. Die IP 48 Zieladresse ist „sichtbar" (d.h. nicht verschlüsselt), wenn das IP 48 Paket das Netzwerk durchläuft.
Wie in der Technik bekannt ist, kann ein virtueller Tunnel durch Einkapseln eines Datenpakets in einem anderen Datenpaket erzeugt werden. So wird beispielsweise vor einem inneren Header eines Datenpakets ein äußerer Header hinzugefügt (z.B. Tabellen 3, 5, 8 und 11). Zwischen dem inneren Header und äußeren Headern befinden sich evtl. weitere Header für einen Datenpfad oder Sicherheit, wie z.B. Sicherheits-Header speziell für eine Tunnel-Konfiguration. Der äußere Header identifiziert typischerweise die „Endpunkte" des Tunnels. Der innere Header identifiziert typischerweise einen ursprünglichen Sender und Empfänger der Daten. Weitere Informationen befinden sich in „IP-in-IP Tunneling" von W. Simpson, RFC-1853, Oktober 1995.
Im Tunnelmodus kapselt ein äußerster IP 48 Tunnel-Header ein geschütztes IP Paket ein. Eine erste Zieladresse ist ein Endpunkt eines Tunnels gemäß einer Tunnelzieladresse. Eine Endzieladresse ist nicht unbedingt dieselbe wie eine Endpunktadresse des Tunnels. Eine IP 48 Zieladresse 222 (15) im IP 48 Header des eingekapselten (d.h. verschlüsselten) Teils kann „sichtbar" sein oder auch nicht. Ipsec-Protokolle stellen eine Security Assocation („SA") her und benutzen sie, um eine sichere virtuelle Verbindung zwischen zwei Endpunkten zu identifizieren. Eine SA ist eine unidirektionale Verbindung zwischen zwei Endpunkten, die eine einzelne IPsec Protokollmodus-Kombination repräsentiert. Zwei Terminierungsendpunkte (d.h. Netzgeräte für den Transportmodus oder Zwischengeräte für den Tunnelmodus) einer einzelnen SA definieren eine sichere virtuelle Verbindung, die durch IPsec-Dienste geschützt wird. Einer der Endpunkte sendet IP 48 Pakete, der andere Endpunkt empfängt sie. Da eine SA unidirektional ist, werden mindestens zwei SAs für sichere bidirektionale Kommunikationen benötigt. Man kann auch mehrere Schichten von IPsec-Protokollen zwischen zwei Endpunkten durch Kombinieren mehrerer SAs konfigurieren.
16 ist ein Blockdiagramm, das einen Internet Protocol Security Authentication Header 226 illustriert. Ein Nächster-Header-Feld 228 ist ein 8-Bit-Feld, das den Typ der nächsten Nutzlast nach dem AH identifiziert. Ein Nutzlastlänge-Feld 230 gibt den Wert eines AH in 32-Bit-Wörtern (d.h. 4 Bytes) vor. Ein Reserviert-Feld 232 ist ein 16-Bit-Feld, das für eine spätere Verwendung reserviert ist. Ein Security Parameters Index („SPI") Feld 234 ist ein arbiträrer 32-Bit-Wert, der in Kombination mit einer IP 48 Zieladresse und einem Sicherheitsprotokoll (z.B. AH oder ESP) eine SA für das Datenpaket eindeutig identifiziert. Ein Satz von SPI-Werten im Bereich von 1 bis 255 wird von der Internet Corporation for Assigned Names and Numbers („ICANN") für eine spätere Verwendung reserviert. Weitere Informationen über ICANN befinden sich unter der URL-Adresse „www.icann.org". Ein SPI größer als 255 wird von einem Zielendpunkt nach der Herstellung einer SA gewählt. Die Zuordnung von SPI mit PAP 64 wird nachfolgend erläutert. Ein Sequenznummer-Feld 236 ist ein vorzeichenloses 32-Bit-Feld mit einem monoton zunehmendem Zählerwert als Sequenznummer. Ein Authentifizierungsdaten-Feld 238 ist ein Feld variabler Länge, das einen Integrity Check Value („ICV") für ein Paket enthält.
Im Transportmodus setzt ein Sendeendpunkt einen AH-Header nach einem IP 48 Header und vor einer oberen Protokollschicht ein (z.B. TCP 58, UDP 60 usw.). Im Tunnelmodus können die äußeren und inneren IP Header/Erweiterungen auf eine Reihe verschiedener Weisen verwendet werden. Die Platzierung des AH-Headers im Tunnelmodus ist von einer Reihe verschiedener Faktoren einschließlich dem verwendeten Tunnelungstyp abhängig. So kann ein Ort für einen AH-Header variieren.
Für abgehende Pakete wird AH angewendet, nachdem eine IPsec-Anwendung ermittelt, dass ein mit einer SA assoziiertes Paket eine AH-Verarbeitung benötigt. Das AH-Sequenznummer-Feld 236 (16) eines Sendeendpunkts wird auf null initialisiert, wenn eine SA hergestellt wird. Der Sendeendpunkt inkrementiert das Sequenznummer-Feld 236 für eine SA. So hat ein erstes AH-Paket mit einer bestimmten SA eine Sequenznummer von 1. Ein im Authentifizierungsdaten-Feld 238 (16) verwendeter AH ICV wird über IP-Header-Felder 200 (15) errechnet, die entweder in Transit immutierbar oder im Hinblick auf den Wert bei der Ankunft an einem Endpunkt für die AH SA vorhersehbar sind. Der AH-Header 226 (16) und explizite Auffüllbytes werden ggf. nach den IP 48 Header 200 Feldern (15) berechnet. Upper-Level-Protokolldaten (z.B. TCP 58, UDP 60), die als in Transit immutierbar angesehen werden, werden zuletzt berechnet. Falls erforderlich, tritt eine IP 48 Fragmentierung nach der AH-Verarbeitung mit einer IPsec Implementation auf.
Für eingehende Pakete wird das Paket vor der AH-Verarbeitung wieder zusammengesetzt. Nach dem Empfang eines einen AH enthaltenden Pakets ermittelt ein Empfangsendpunkt eine geeignete SA auf der Basis einer IP 48 Zieladresse 222 (15), einen AH-Protokoll-Header 226 (16) und einen AH SPI 234 (16). Als Nächstes wird eine Sequenznummer verifiziert. Die Sequenznummer hilft dabei, Replay-Attacken zu verhüten. Ein ICV-Wert wird über geeignete Felder des Pakets mit Hilfe eines vorgegebenen Authentifizierungsalgorithmus errechnet, und es wird verifiziert, dass es sich um denselben Algorithmus wie der ICV handelt, der im Authentifizierungsdaten-Feld 238 des AH-Headers 226 (16) enthalten ist.
17 ist ein Blockdiagramm, das ein ESP-Paketformat 240 illustriert. Ein SPI-Feld 242 ist ein arbiträrer 32-Bit-Wert, der in Kombination mit einer IP 48 Zieladresse und einem Sicherheitsprotokoll (z.B. AH oder ESP) eine SA für das Datenpaket eindeutig identifiziert. Ein Sequenznummer-Feld 244 ist ein 32-Bit-Feld, das einen monoton zunehmenden Zählerwert als Sequenznummer enthält. Ein Nutzdaten-Feld 246 ist ein Feld von variabler Länge, das Daten beinhaltet, die das Nächster-Header-Feld 248 beschreibt. Ein Auffüll-Feld 250 wird mit dem Nutzdaten-Feld 246 zur Verschlüsselung benutzt. Ein Fülllänge-Feld 252 gibt die Anzahl der Stopfbytes an, die unmittelbar voranstehen. Ein Nächster-Header-Feld 248 ist ein 8-Bit-Feld, das einen Datentyp beinhaltet, der im Nutzdaten-Feld 246 enthalten ist. Ein Authentifizierungsdaten-Feld 254 ist ein Feld variabler Länge mit einem Integrity Check Value („ICV"), der über den gesamten ESP-Header 240 minus dem Authentifizierungsdaten-Feld 254 berechnet wird.
Im Transportmodus kapselt ein Sendeendpunkt Upper-Layer-Protokollinformationen in einen ESP-Header und -Trailer und behält einen ursprünglichen IP 48 Header. Im Tunnelmodus können die äußeren und inneren IP 48 Header/Erweiterungen in einer Reihe verschiedener Weisen je nach der angewendeten Verschlüsselung aufeinander bezogen werden. So kann ein Ort für ESP variieren.
Für abgehende Pakete wird ESP angewendet, nachdem eine IPsec Anwendung ermittelt hat, dass ein mit einer SA assoziiertes Paket eine ESP-Verarbeitung wünscht. Der Sendeendpunkt kapselt das Nutzdaten-Feld 246 (17) und die ursprünglichen Upper-Level-Protokollinformationen für den Transportmodus mit einer gewählten Verschlüsselungstechnik in ESP ein. Ein gesamtes IP 48 Datenpaket wird für den Tunnelmodus eingekapselt. Eine eventuell notwendige Auffüllung wird zum Auffüll-Feld 250 hinzugefügt. Das Nutzdaten-Feld 246, das Nächster-Header-Feld 248, das Auffüll-Feld 250 und das Fülllängen-Feld 252 werden mit einer Verschlüsselungstechnik verschlüsselt. Die genauen Schritte, die zum Konstruieren eines äußeren IP 48 Headers angewendet werden, hängen vom Modus (z.B. Transport oder Tunnel) und der angewendeten Verschlüsselungstechnik ab.
Das Sequenznummer-Feld 244 eines Sendeendpunkts wird auf null initialisiert, wenn eine SA hergestellt wird. Der Sendeendpunkt inkrementiert das Sequenznummer-Feld 244 für eine SA. Somit hat ein erstes ESP-Paket mit einer bestimmten SA eine laufende Nummer von 1. Wenn Authentifizierung für die SA gewählt wird, dann berechnet der Sendeendpunkt einen ICV über den gesamten ESP-Header 240 minus dem Authentifizierungsdaten-Feld 254. Falls notwendig, erfolgt nach der ESP-Verarbeitung mit einer IPsec-Implementation eine Fragmentierung.
Für eingehende Pakete wird das Paket bei Bedarf vor der ESP-Verarbeitung wieder zusammengesetzt. Nach dem Empfang eines IP 48 Pakets mit einem ESP-Header 240 ermittelt ein Empfangsendpunkt die geeignete SA auf der Basis von IP-Zieladresse 222 (15), ESP-Protokoll-Header 240 (17) und SPI 242 (17). Die SA gibt an, ob das Sequenznummer-Feld 244 geprüft wird, ob das Authentifizierungsdaten-Feld 254 vorhanden sein soll und welche Verschlüsselungstechniken notwendigenfalls für Entschlüsselung und ICV-Berechnungen anzuwenden sind. Bei der Entschlüsselung werden das ESP-Nutzdaten-Feld 246, das Nächster-Header-Feld 248, das Auffüll-Feld 250 und das Fülllänge-Feld 252 mit einem Key, einer Entschlüsselungstechnik und ggf. kryptografischen Synchronisationsdaten entschlüsselt, von der SA angegeben. Jedes Auffüllen vom Auffüll-Feld 250 wird notwendigenfalls verarbeitet. Ein ursprüngliches IP 48 Paket wird rekonstruiert, einschließlich einem ursprünglichen IP 48 Header 200 (15) plus ursprünglichen Upper-Layer-Protokollinformationen für den Transportmodus im ESP-Nutzdaten-Feld 246 (17). Ein IP 48 Tunnel-Header und ein gesamtes IP 48 Paket werden im ESP-Nutzdaten-Feld 246 für den Tunnelmodus rekonstruiert. Die genauen Schritte zum Rekonstruieren des ursprünglichen IP 48 Pakets hängen vom Modus (d.h. Transport oder Tunnel) ab.
18 ist ein Blockdiagramm, das End-to-End-Sicherheit 256 zwischen zwei Endpunkten über ein IP 48 Netzwerk 30 (z.B. das Internet oder ein Intranet) mit AH, ESP und Kombinationen davon im Transport- und im Tunnelmodus illustriert. Ein erster Endpunkt 258 hat eine sichere Verbindung 260 mit einem zweiten Endpunkt 262. Ein erstes beispielhaftes Datenpaket 264 hat eine erste IP 48 Adresse („IP 1") in einem ersten IP 48 Header, einen AH-Header und Upper-Level-Protokolldaten. Ein zweites beispielhaftes Datenpaket 266 hat eine erste IP 48 Adresse, einen ESP-Header und Upper-Level-Protokolldaten. Ein drittes beispielhaftes Datenpaket 268 hat eine erste IP 48 Adresse, einen AH-Header, einen ESP-Header und Upper-Level-Protokolldaten. Die beispielhaften Datenpakete 264, 266 und 268 werden im Transportmodus verwendet. Ein Typ von Datenpaketlayouts wird gewöhnlich für den Transportmodus je nach dem gewünschten Sicherheitstyp ausgewählt (264, 266 oder 268).
Im Tunnelmodus beinhaltet ein viertes beispielhaftes Datenpaket 270 einen IP 48 Tunnel-Header mit einer IP-Tunneladresse („TIP"), einen AH-Header, einen ursprünglichen IP 48 Header mit einer ersten IP 48 Adresse („IP1") und Upper-Level-Protokolldaten. Ein fünftes beispielhaftes Datenpaket 272 beinhaltet einen IP 48 Tunnel-Header mit einer IP 48 Tunnel-Adresse, einen AH-Header, einen ursprünglichen IP 48 Header mit einer ersten IP 48 Adresse und Upper-Level-Protokolldaten. Ein Typ von beispielhaftem Datenpaket 270 oder 272 wird typischerweise für den Tunnelmodus je nach der gewünschten Sicherheit gewählt. Eine Kombination aus AH und ESP im Tunnelmodus wird gewöhnlich nicht verwendet und ist in 18 nicht illustriert. Eine Kombination von AH und ESP kann aber auch im Tunnelmodus mit der vorliegenden Erfindung zur Anwendung kommen.
Es wurde ein Satz von Protokollen entwickelt, damit zwei Endpunkte eine oder mehrere SAs dazwischen herstellen können. Die Herstellung einer IPsec SA beinhaltet sowohl Negotiation als auch Authentifizierung. Negotiation führt zu einer Vereinbarung zwischen den beiden Endpunkten in Bezug darauf, welche Sicherheitsprotokolle und welcher Modus zu verwenden sind, sowie über spezielle Verschlüsselungstechniken, assoziierte Parameterwerte und SPI-Zuweisung für jede hergestellte SA. Die Authentifizierung gewährleistet, dass jeder Endpunkt der Identität des anderen Endpunkts bei der Negotiation und somit nach dem Herstellen der SA trauen kann.
Es wurde eine Reihe von Standards für Protokolle vorgeschlagen, die SAs herstellen, einschließlich einer Internet Security Association and Key Exchange Protocol („ISAKMP"), ein Oakley Protocol („Oakley") und das Internet Key Exchange („IKE") Protokoll, das ISAKMP und Oakley beinhaltet. Zu weiteren Informationen über ISAKMP siehe „Internet Security Association and Key Management Protocol („ISAKMP")" von D. Maughan, M. Schertler, M. Schneider und J. Turner, RFC-2408, November 1998. Zu weiteren Informationen über Oakley siehe „the OAKLEY Key Determination Protocol" von H.K. Orman, RFC-2412, November 1998. Zu weiteren Informationen über IKE siehe „The Internet Key Exchange (IKE)" von D. Harkins und D. Carrel, RFC-2409, November 1998.
Mit ISAMKP und IKE erfolgt SA-Negotiation als eine Signalaustauschsequenz zwischen zwei Endpunkten. Ein erster Endpunkt schlägt ein Sicherheitsprotokoll und einen Verschlüsselungsalgorithmus vor, ein zweiter Endpunkt akzeptiert oder macht einen Gegenvorschlag. Nach vollendetem Signalaustausch haben beide Endpunkte negoziierte Dateils vereinbart, relevante Sicherheitsparamterinformationen ausgetauscht und die Endpunkte sind bereit, auf einer einzelnen unidirektionalen SA zu senden oder zu empfangen. Ein Teil des Signalaustauschs beinhaltet den Austausch von Authentifizierungsinformationen mit Hilfe einer CA. Dies wird nachfolgend beschrieben.
Die Authentifizierung basiert auf einer vertrauenswürdigen Fremdpartei mit der Bezeichnung Certificate Authority („CA"). Jeder Endpunkt, der an IPsec teilnimmt, erzeugt ein Public/Private-Encryption-Key-Paar und lässt seinen Public-Key von der CA „notarisieren". Die CA bindet die IP 48 Adresse an ihren Public-Key, erzeugt ein Zertifikat und sendet es zu einem Besitzer des Key zurück. Somit sind IP 48 Adressen ein „Sicherheitsnamensraum", um Public-Keys an ihre Besitzer zu binden.
Während der SA-Negotiation gibt ein Endpunkt einem anderen Endpunkt sein Zertifikat zusammen mit einer Signatur, die mit seinem Private-Key verschlüsselt ist. Zertifikat und Signatur werden mit einem Public-Key überprüft. Ein Empfänger (einer an jedem Endpunkt) validiert mit einem Sender-Public-Key aus seinem Zertifikat die Signatur und das Recht des Senders, seine IP 48 Adresse zu verwenden. Da nur der Sender Zugang zum Private-Key hat, ist sich der Empfänger, wenn er die Signatur verifiziert hat, über die „Identität" des Initiators sicher. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung wird die Identität anhand der IP 48 Adresse des Initiators ermittelt, da IP 48 Adressen den Sicherheitsnamensraum bilden, der zum Binden von Public-Keys an ihre Besitzer verwendet wird. Es könnten jedoch auch andere Sicherheitsnamensräume verwendet werden, die eine andere als eine IP 48 Adresse für die Identität des Initiators verwenden. Zertifikate werden mit einem „Time-to-Live" Wert ausgegeben, wonach sie ablaufen und ungültig werden. Das Ergebnis von Negotiation und Authentifizierung ist eine sichere Verbindung 260 (18) für eine unidirektionale SA. Eine zweite SA für bidirektionale Kommunikationen kann auf ähnliche Weise registriert werden.
Wie oben erörtert, müssen in der Technik bekannte NAT-Router IP 48 Pakete modifizieren. Wenn jedoch ein IP 48 Paket durch IPsec geschützt ist, dann kann es nicht irgendwo auf seinem Pfad zum IPsec-Ziel modifiziert werden. In der Technik bekannte NAT-Routers verletzen typischerweise IPsec durch Modifizieren von Paketen. Darüber hinaus muss ein NAT-Router selbst dann, wenn er die Pakete, die er weiterleitet, nicht zu modifizieren brauchte, die TCP 58 oder UDP 60 Portnummern lesen können. Wenn ESP von einem lokalen Endpunkt verwendet wird, dann werden die Portnummern verschlüsselt, so dass der NAT-Router sein benötigtes Mapping nicht vollenden kann.
Lokale Netzgeräte auf einem LAN, die NAT verwenden, besitzen nur lokale, nicht eindeutige IP 48 Adressen. Diese umfassen keinen Sicherheitsnamensraum, der zum Binden eines Public-Key an eine eindeutige Identität (d.h. eine eindeutige globale IP 48 Adresse) geeignet ist. Ohne diese Bindung ist es typischerweise nicht möglich, die Authentifizierung zu erzielen, die zur Herstellung von SAs notwendig ist. Ohne Authentifizierung kann sich kein Endpunkt über die Identität seines Gegenübers sicher sein und kann somit keine sichere und vertrauenswürdige Verbindung über eine SA herstellen. Es kann jedoch DNAT wie oben beschrieben mit IPsec verwendet werden, um einige der Probleme mit in der Technik bekannten NAT-Geräten zu überwinden. Verteiltes-Netz-Adressenumsetzung mit Internet Protocol Sicherheit Ein wie oben beschrieben mit DNAT arbeitendes Netzgerät möchte möglicherweise ebenso eine sichere virtuelle Verbindung mit einem externen Netzgerät mit IPsec (z.B. SPIs) herstellen. Ein solches Netzgerät würde lokal eindeutige Ports anfordern und verwenden und DNAT wie oben beschrieben benutzen. Darüber hinaus kann das Netzgerät lokal eindeutige Sicherheitswerte für die Verwendung von DNAT mit IPsec anfordern.
19 ist ein Ablaufdiagramm, das eine Methode 274 für Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert. In Schritt 276 fordert ein erstes Netzwerk auf einem ersten Computernetz mit einem ersten Protokoll ein oder mehrere lokal eindeutige Sicherheitswerte (z.B. SPIs) von einem zweiten Netzgerät auf dem ersten Computernetz und für eine Adressenumsetzung in einem verteilten Netz an. Die ein oder mehreren lokal eindeutigen Sicherheitswerte dienen zum Identifizieren von Sicherheitsassoziationen für einen Datenempfang auf dem ersten Netzgerät bei sicheren Kommunikationen mit einem dritten Netzgerät auf einem zweiten externen Netzwerk. In Schritt 278 werden die ein oder mehreren lokal eindeutigen Sicherheitswerte auf dem ersten Netzgerät vom zweiten Netzgerät mit dem ersten Protokoll empfangen. Die ein oder mehreren lokal eindeutigen Sicherheitswerte werden in Schritt 280 auf dem ersten Netzgerät gespeichert. Die ein oder mehreren lokal eindeutigen Sicherheitswerte können zum Identifizieren einer eindeutigen Sicherheitsassoziation für sichere Kommunikationen und für eine Adressenumsetzung in einem verteilten Netz verwendet werden. Eine durch den ersten Computer auf dem ersten Netzwerk identifizierte eindeutige Sicherheitsassoziation wird für den Empfang von Paketen auf dem ersten Computer verwendet.
In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Netzgerät ein Netzgerät (14, 16, 18, 20, 22 und 24), das zweite Netzgerät ist der Router 26, das erste Protokoll ist PAP 64, die ein oder mehreren lokal eindeutigen Sicherheitswerte sind mit IPsec verwendete SPIs, einschließlich AH oder ESP. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung werden die lokal eindeutigen Sicherheitswerte mit PAP 64 unter Verwendung einer PAP 64 Sicherheitsanforderungsmeldung 67, einer PAP 64 Sicherheitsantwortmeldung 69 und einer PAP 64 Sicherheitsinvalidierungsmeldung 71 erhalten.
Die 4A, 5A und 6A illustrieren ein beispielhaftes Layout 73 einer PAP 64 Sicherheitsanforderungsmeldung 67, ein Layout 87 für eine PAP 64 Sicherheitsantwortmeldung 69 sowie ein Layout 99 für eine PAP 64 Sicherheitsinvalidierungsmeldung 71. Die PAP 64 Sicherheitsmeldungen werden zur Zuordnung und Zuordnungsaufhebung von lokal eindeutigen Sicherheitswerten (z.B. SPIs) verwendet und sind den PAP 64 Meldungen ähnlich, die zum Zuordnen von lokal eindeutigen Sicherheitswerten verwendet werden.
4A ist ein Blockdiagramm, das ein Layout 73 einer PAP Sicherheitsanforderungsmeldung 67 illustriert. Ein Typ-Feld 75 hat ein Byte und einen Wert (z.B. 33) zum Anfordern von lokal eindeutigen Sicherheitswerten. Ein Code-Feld 77 hat ein Byte und einen Wert von null für lokal eindeutige Sicherheitswerte. Ein Prüfsumme-Feld 79 hat zwei Bytes und einen Wert von einer Einserkomplementsumme des gesamten PAP-Sicherheitsanorderungsmeldung-Layout 73. Das Sicherheitswerteangefordert-Feld 81 hat zwei Bytes und einen variablen Wert, der eine Zahl von von einem Netzgerät angeforderten lokal eindeutigen Sicherheitswerten anzeigt. Das Unbenutzt-Feld 83 hat zwei Bytes und einen Wert von null. Es können jedoch auch andere Layouts, Werte und Feldgrößen für das Layout 73 der PAP Sicherheitsanforderungsmeldung 67 verwendet werden.
5A ist ein Blockdiagramm, das ein Layout 85 einer PAP-Sicherheitsantwortmeldung 69 illustriert. Ein Typ-Feld 87 hat ein Byte und einen Wert zum Empfangen von Sicherheitsantworten (z.B. 33). Ein Code-Feld 89 hat ein Byte und einen Wert von null für Misserfolg und von eins für Erfolg. Ein Prüfsumme-Feld 91 hat zwei Bytes und ist eine 16-Bit-Einserkomplementsumme der gesamten PAP-Sicherheitsantwortmeldung 85. Ein Gesamtzahl-Sicherheitswert-Feld 93 hat zwei Bytes und ist die Gesamtzahl der dem Netzgerät zugeordneten lokal eindeutigen Ports. Ein Unbenutzt-Feld 95 hat zwei Bytes und einen Wert von null. Ein Tiefster-eindeutiger-Sicherheitswert-Feld 97 hat vier Bytes und beinhaltet einen in einem Block von lokal eindeutigen Sicherheitswerten zugeordneten tiefsten lokal eindeutigen Sicherheitswert. Es können jedoch auch andere Layouts, Werte und Feldgrößen für die PAP-Sicherheitsantwortmeldung 85 verwendet werden.
6A ist ein Blockdiagramm, das ein Layout 99 einer PAP-Sicherheitsinvalidierungsmeldung 71 illustriert. Ein Typ-Feld 101 hat ein Byte und einen Wert zum Aufheben der Zuordnung von Sicherheitswerten (z.B. 33). Ein Code-Feld 103 hat ein Byte und einen Wert von zwei. Ein Prüfsumme-Feld 105 hat zwei Bytes und ist eine Einserkomplementsumme der gesamten PAP-Sicherheitsinvalidierungsmeldung 99. Ein Sicherheitswert-Feld 107 hat vier Bytes und einen Wert eines lokal eindeutigen Sicherheitswerts, der von dem Netzgerät verwendet wird, das gerade invalidiert oder dessen Zuordnung gerade aufgehoben wird. Es sind jedoch auch andere Layouts, Werte und Feldgrößen für die PAP-Sicherheitsinvalidierungsmeldung 99 möglich.
Zurück zu 19, das erste Netzgerät, wie z.B. ein Computer 14, verwendet eine PAP 64 Sicherheitsanforderungsmeldung 67 zum Anfordern der lokal eindeutigen SPIs und empfängt die SPIs in einer PAP 64 Sicherheitsantwortmeldung 69. Die lokal eindeutigen SPIs werden auf eine Weise angefordert, empfangen und gespeichert, die den oben beschriebenen lokal eindeutigen DNAT-Ports ähnlich ist. Die vorliegende Erfindung ist jedoch nicht auf diese beispielhafte bevorzugte Ausgestaltung begrenzt und es können auch andere Netzgeräte, Protokolle und Sicherheitswerte verwendet werden. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung ordnet das zweite Netzgerät die auf dem ersten Netzgerät verwendeten ein oder mehreren lokal eindeutigen Sicherheitswerte zu.
20 ist ein Ablaufdiagramm, das eine Methode 282 für die Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert. In Schritt 284 wird eine Anforderungsmeldung in einem ersten Protokoll auf einem zweiten Netzgerät empfangen, die ein oder mehrere lokal eindeutige Sicherheitswerte für ein erstes Netzgerät anfordert. In Schritt 286 werden ein oder mehrere lokal eindeutige Sicherheitswerte auf dem zweiten Netzgerät zugeordnet. In Schritt 288 wird eine Netzwerkadresse für das erste Netzgerät mit den ein oder mehreren lokal eindeutigen Sicherheitswerten in einer mit dem zweiten Netzgerät assoziierten Tabelle gespeichert. Die Tabelle dient zum Führen eines Mapping zwischen einem Netzgerät und einem lokal eindeutigen Sicherheitswert für Verteiltes-Netz-Adressenumsetzung mit Sicherheit. In Schritt 290 werden die ein oder mehreren lokal eindeutigen Sicherheitswerte in einer Antwortmeldung mit dem ersten Protokoll zu dem ersten Netzgerät gesendet.
In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Netzgerät ein Netzgerät (14, 16, 18, 20, 22, 24) auf dem ersten Computernetz 12, das zweite Netzgerät ist der Router 26, das erste Protokoll ist PAP 64, die ein oder mehreren lokal eindeutigen Sicherheitswerte sind SPIs, die mit IPsec einschließlich AH oder ESP verwendet werden. Das erste Netzgerät, z.B. der Kundencomputer 14, verwendet eine PAP 64 Sicherheitsanforderungsmeldung 67 zum Anfordern der lokal eindeutigen SPIs. In Schritt 284 (20) empfängt der Router 26 die PAP 64 Sicherheitsanforderungsmeldung 67. Der Router 26 führt eine Tabelle ähnlich der in 8 illustrierten Port-zu-interne-Netzwerkadresse-Tabelle 118, mit der Ausnahme, dass ein SPI-Wert anstelle einer Portnummer verwendet wird. In Schritt 286 ordnet der Router 26 ein oder mehrere lokal eindeutige SPIs zu. In Schritt 288 wird eine lokale IP 48 Adresse für das erste Netzgerät (z.B. 10.0.0.1) mit den ein oder mehreren lokal eindeutigen SPI-Werten in einer mit dem zweiten Netzgerät assoziierten Tabelle gespeichert (z.B. siehe 21 unten). Die Tabelle dient zum Führen eines Mapping zwischen einem Netzgerät und einem lokal eindeutigen SPI für Verteiltes-Netz-Adressenumsetzung mit Sicherheit. In Schritt 290 werden die ein oder mehreren lokal eindeutigen SPIs vom Router 26 in einer PAP 64 Sicherheitsanforderungsmeldung 69 zum ersten Netzgerät 14 gesendet. Die vorliegende Erfindung ist jedoch nicht auf diese beispielhafte bevorzugte Ausgestaltung begrenzt und es können auch andere Netzgeräte, Protokolle, Meldungen, Tabellen und Sicherheitswerte mit Methode 282 zur Anwendung kommen.
21 ist ein Blockdiagramm, das ein SPI-zu-interne-Netzwerkadresse-Tabellenlayout 292 illustriert, das in Schritt 288 von Methode 284 (20) verwendet wird. 21 ist 8 ähnlich, mit der Ausnahme, dass die lokal eindeutigen SPI-Werte 32 Bits und die lokal eindeutigen Portwerte 16 Bits haben. In 21 beinhaltet eine interne Netzwerkadressenspalte 294 interne Netzwerkadressen für Netzgeräte (14, 16, 18, 20, 22, 24) auf dem ersten Computernetz 12. Die Tiefster-SPI-Spalte 296 hat einen zugeordneten tiefsten SPI-Wert. Die Anzahl-SPIs-Spalte 298 enthält die Gesamtzahl von einem Netzgerät zugeordneten lokal eindeutigen SPIs. So wurden z.B. in Reihe 300 einem Netzgerät 14 (1) mit einer lokalen IP 48 Adresse von 10.0.0.1 auf dem ersten Computernetz 12 32 SPIs beginnend mit einem SPI mit dem Wert „280" zugeordnet. In Reihe 302 wurden einem anderen Netzgerät 18 mit einer lokalen IP 48 Adresse von 10.0.0.3 auf dem ersten Computernetz 12 16 SPIs beginnend mit einem SPI-Wert von „312" zugeordnet. Die vorliegende Erfindung ist jedoch nicht auf dieses SPI-zu-interne-Netzwerkadresse-Tabellenlayout begrenzt und es können auch andere SPI-zu-interne-Netzwerkadresse-Tabellenlayouts zur Anwendung kommen. Ein erstes Netzgerät (z.B. 14, 1) verwendet lokal eindeutige Sicherheitswerte (d.h.SPIs) mit einem zweiten sicheren Protokoll (z.B. IPsec), um eine virtuelle sichere Verbindung (d.h. eine SA) mit einem dritten externen Netzgerät (z.B. 39, 1) herzustellen.
Herstellen von IPsec-Sicherheitsassoziationen mit DNAT
Wie oben erörtert, beinhaltet der Vorgang des Herstellens einer IPsec SA sowohl Negotiation als auch Authentifizierung. Authentifizierung basiert auf einer vertrauenswürdigen Fremdpartei mit der Bezeichnung Certificate Authority („CA"). Jeder Endpunkt, der an einer IPsec SA beteiligt ist, erzeugt ein Public/Private-Encryption-Key-Paar und lässt seinen Public-Key von der CA „notarisieren". Die CA bindet die IP 48 Adresse eines Endpunkts an ihren Public-Key, erzeugt ein Zertifikat und sendet es zu einem Besitzer des Key zurück. Somit werden IP 48 Adressen zum Erzeugen eines Namensraums zum Binden von Public-Keys an ihre Besitzer verwendet.
In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung wird der Router 26 dazu benutzt, bei der Herstellung einer IPsec SA zu helfen, indem er als Local Certificate Authority („LCA") dient. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung dient der Router 26 als LCA und ist selbst bei einer Higher-Level-CA registiert. Der Router 26 wiederum hat ein Zertifikat, in dem ein Public-Encryption-Key für den Router 26 an seine globale IP 48 Adresse (z.B. IP 48 Adresse 28 (1)) gebunden ist, die von der Higher-Level-CA validiert wird. Der Router 26 dient als LCA zum Ausgeben von Sicherheitszertifikaten an andere Netzgeräte (14, 16, 18, 20, 22, 24) auf dem ersten Computernetz 12, um bei der Herstellung einer IPsec SA zu helfen. Es können jedoch auch andere Netzgeräte als LCA neben einem Router 26 verwendet werden.
22 ist ein Ablaufdiagramm, das eine Methode 304 zum Erzeugen einer Sicherheitsassoziation mittels Verteiltes-Netz-Adressenumsetzung illustriert. In Schritt 306 werden ein oder mehrere lokal eindeutige Ports mit einer ersten Meldung von einem ersten Protokoll auf einem ersten Netzgerät von einem zweiten Netzgerät angefordert. Die ein oder mehreren lokal eindeutigen Ports werden für Verteiltes-Netz-Adressenumsetzung verwendet. In Schritt 308 werden ein oder mehrere lokal eindeutige Sicherheitswerte mit einer ersten Meldung vom ersten Protokoll auf einem ersten Netzgerät vom zweiten Netzgerät angefordert. Die ein oder mehreren lokal eindeutigen Sicherheitswerte werden mit einem zweiten sicheren Protokoll verwendet, um eine oder mehrere sichere virtuelle Verbindungen zwischen dem ersten Netzgerät und einem dritten Netzgerät und einem zweiten externen Computernetz und für Verteiltes-Netz-Adressenumsetzung mit Sicherheit herzustellen. In Schritt 310 fordert das erste Netzgerät ein Sicherheitszertifikat vom zweiten Netzgerät an. Das Sicherheitszertifikat beinhaltet eine Bindung zwischen einem Public-Encryption-Key für das erste Netzgerät und einer Kombination aus einer gemeinsamen externen Netzwerkadresse für das erste Netzgerät und den vom zweiten Netzgerät zugeordneten ein oder mehreren lokal eindeutigen Ports. Die Bindung umfasst einen Sicherheitsnamensraum.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung sind die lokal eindeutigen Ports DNAT-Ports, das erste Protokoll ist PAP 64, die erste Meldung ist eine PAP 64 Sicherheitsanforderungsmeldung 67 und das zweite sichere Protokoll ist IPsec und die ein oder mehreren lokal eindeutigen Sicherheitswerte sind SPIs. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung kann IKE als Sicherheitsprotokoll in der IPsec Protocol Suite angesehen werden. In einer weiteren Ausgestaltung der vorliegenden Erfindung wird IKE nicht als Sicherheitsprotokoll in der IPsec Protocol Suite angesehen.
IKE ist ein Sicherheitsprotokoll, das ein Zertifikat und einen SPI-Wert führt. IKE negoziiert einen Session-Key, der einen SPI beinhaltet. Es können jedoch auch andere Protokolle zum Negoziieren eines Session-Key verwendet werden. Die Netzwerkadresse ist eine lokale IP 48 Netzwerkadresse auf dem ersten Computernetz 12 und das zweite Netzgerät ist der Router 26. Die vorliegende Erfindung ist jedoch nicht auf die erörterten Ports, Protokolle, Meldungen, Sicherheitswerte, Netzwerkadressen oder Netzgeräte begrenzt und es können auch andere Ports, Protokolle, Meldungen, Sicherheitswerte, Netzwerkadressen oder Netzgeräte verwendet werden.
In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung werden in Schritt 306 ein oder mehrere lokal eindeutige DNAT-Ports mit einer PAP 64 Anforderungsmeldung 66 auf einem ersten Netzgerät (z.B. 14) vom Router 26 (z.B. mit Methode 130 von 9) angefordert. In Schritt 308 werden ein oder mehrere lokal eindeutige SPIs mit einer PAP 64 Sicherheitsanforderungsmeldung 67 vom Router 26 angefordert (z.B. mit Methode 274 von 19). Die ein oder mehreren lokal eindeutigen SPIs werden mit IPsec zum Herstellen von einer oder mehreren SAs zwischen dem ersten Netzgerät 12 und einem dritten Netzgerät 39 und einem zweiten externen Computernetz 30 verwendet. In Schritt 310 wird ein Sicherheitszertifikat auf dem ersten Netzgerät vom Router 26 empfangen. Das Sicherheitszertifikat beinhaltet eine Bindung zwischen dem Public-Encryption-Key und einer Kombination aus einer gemeinsamen externen IP 48 Adresse für das erste Netzgerät (z.B. 198.10.20.30) und den dem ersten Netzgerät zugeordneten ein oder mehreren lokal eindeutigen DNAT-Ports. Das Sicherheitszertifikat dient zum Herstellen einer SA wie nachfolgend beschrieben.
23 ist ein Ablaufdiagramm, das eine Methode 312 für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert. Eine erste Meldung mit einem ersten Protokoll von einem ersten Netzgerät wird auf einem zweiten Netzgerät zum Anfordern von einem oder mehreren lokal eindeutigen Ports empfangen. Das zweite Netzgerät ordnet ein oder mehrere lokal eindeutige Ports zu. In Schritt 314 sendet das zweite Netzgerät die zugeordneten ein oder mehreren lokal eindeutigen Ports zum ersten Netzgerät mittels einer zweiten Meldung vom ersten Protokoll. Die ein oder mehreren lokal eindeutigen Ports werden für Verteiltes-Netz-Adressenumsetzung verwendet. Eine erste Meldung mit einem ersten Protokoll von einem ersten Netzgerät wird auf einem zweiten Netzgerät zum Anfordern von einem oder mehreren lokal eindeutigen Sicherheitswerten empfangen. Das zweite Netzwerk ordnet ein oder mehrere lokal eindeutige Sicherheitswerte zu. In Schritt 316 sendet das zweite Netzwerk die zugeordneten ein oder mehreren lokal eindeutigen Sicherheitswerte zum ersten Netzgerät mittels einer zweiten Meldung vom ersten Protokoll. Die ein oder mehreren lokal eindeutigen Sicherheitswerte werden mit einem zweiten sicheren Protokoll zum Herstellen einer sicheren virtuellen Verbindung zwischen dem ersten Netzgerät und einem dritten Netzgerät und einem zweiten externen Computernetz verwendet und werden für Verteiltes-Netz-Adressenumsetzung mit Sicherheit verwendet.
Ein Public-Encryption-Key und ein Private-Encryption-Key werden auf dem ersten Netzgerät erzeugt. Der Public-Encryption-Key wird vom ersten Netzgerät zum zweiten Netzgerät gesendet. Das zweite Netzgerät erzeugt ein Sicherheitszertifikat für das erste Netzgerät. Das Sicherheitszertifikat beinhaltet eine Bindung zwischen dem Public-Encryption-Key und einer Kombination aus einer externen Netzwerkadresse für das erste Netzgerät und den ein oder mehreren lokal eindeutigen Sicherheitswerten. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung ist das Sicherheitszertifikat ein Internet X.509 Sicherheitszertifikat. Es können jedoch auch andere Typen von Sicherheitszertifikaten verwendet werden und die vorliegende Erfindung ist nicht auf Internet X.509 Sicherheitszertifikate begrenzt. Zu weiteren Informationen über Internet X.509 Sicherheitszertifikate siehe RFC-2459 „Internet X.509 Public Key Infrastructure Certificate and CRL Profile" von R. Housley, W. Ford, W. Polk und D. Solo. Zu weiteren Informationen über X.509 Sicherheitszertifikat-Management siehe RFC-2510 „Internet X.509 Public Key Infrastructure Certificate Management Protocols" von C. Adams und M. Farrell, und RFC-2511 „Internet X.509 Certificate Request Message Format" von M. Meyer, C. Adams, D. Solo und D. Kemp. In Schritt 318 sendet das zweite Netzgerät das Sicherheitszertifikat zum ersten Netzgerät.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung sind die lokal eindeutigen Ports DNAT-Ports, das erste Protokoll ist PAP 64, die erste Meldung ist eine PAP 64 Sicherheitsanforderungsmeldung 67, die zweite Meldung ist eine PAP 64 Sicherheitsantwortmeldung 69, das zweite sichere Protokoll ist IPsec, die ein oder mehreren lokal eindeutigen Sicherheitswerte sind SPIs, die in der CA verwendete Netzwerkadresse ist eine externe IP 48 Netzwerkadresse der zweiten Netzwerkadresse auf dem ersten Computernetz 12 und das zweite Netzgerät ist der Router 26. Die vorliegende Erfindung ist jedoch nicht auf die erörterten Ports, Protokolle, Meldungen, Sicherheitswerte, Netzwerkadressen oder Netzgeräte begrenzt und es können auch andere Ports, Protokolle, Meldungen, Sicherheitswerte, Netzwerkadressen oder Netzgeräte verwendet werden. Nach dem Empfangen von einem oder mehreren lokal eindeutigen Ports, einem oder mehreren lokal eindeutigen Sicherheitswerten und dem Sicherheitszertifikat kann ein Netzgerät IPsec mit Adressenumsetzung in einem verteilten Netz anwenden.
24 ist ein Ablaufdiagramm, das eine Methode 320 für eine Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert. In Schritt 322 wird eine erste Meldung in einem zweiten sicheren Protokoll auf einem ersten Netzgerät auf einem ersten Netzwerk empfangen, einschließlich einer Anforderung zum Herstellen einer sicheren Verbindung mit dem ersten Netzgerät von einem dritten Netzgerät auf einem zweiten externen Netzwerk. In Schritt 324 wird ein lokal eindeutiger Sicherheitswert für die Verwendung für die sichere Verbindung aus einer gespeicherten Liste von lokal eindeutigen Sicherheitswerten auf dem ersten Netzgerät ausgewählt. Die gespeicherte Liste von lokal eindeutigen Sicherheitswerten wurde von einem zweiten Netzgerät auf dem ersten Netzwerk mit einem ersten Protokoll empfangen (z.B. Methode 304 von 22). In Schritt 326 wird eine zweite Meldung mit dem zweiten sicheren Protokoll zum Herstellen einer sicheren virtuellen Verbindung mit dem ersten Netzgerät auf dem ersten Netzwerk von dem dritten Netzgerät auf dem zweiten externen Netzwerk mit dem gewählten lokal eindeutigen Sicherheitswert gesendet und ein Sicherheitszertifikat vom ersten Netzgerät empfangen (z.B. in Schritt 310 von Methode 304 (22)).
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Netzgerät ein Netzgerät (14, 16, 18, 20, 22 und 24) auf dem ersten Computernetz 12. Das zweite Netzgerät ist der Router 26, das dritte Netzgerät ist ein externes Netzgerät 39, das erste Protokoll ist PAP 64, das zweite Protokoll ist IPsec, der lokal eindeutige Sicherheitswert ist ein vom Router 26 mit PAP 64 zugeordneter SPI und die sichere Verbindung ist eine SA. Die vorliegende Erfindung ist jedoch nicht auf diese beispielhafte bevorzugte Ausgestaltung begrenzt und es können andere Netzgeräte, Protokolle, Sicherheitswerte und sichere Verbindungen mit Methode 320 zur Anwendung kommen.
In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung negoziiert ein Netzgerät eine eingehende IPsec SA mit einem Fern-Netzgerät auf einem IP 48 Netzwerk 30. Der gewählte und einer SA zugewiesene SPI wird aus den ein oder mehreren lokal eindeutigen SPI-Werten ausgewählt, die dem Netzgerät von einem Router 26 mit PAP 64 zugeordnet wurden. In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung beinhaltet eine eingehende IPsec SA eine SA, die am Netzgerät für eingehende Pakete endet (d.h. Pakete, die vom Fern-Netzgerät zum Netzgerät gesendet werden). Für abgehende SAs wird ein SPI vom Fern-Netzgerät gewählt und der Router 26 benutzt keinen lokal eindeutigen SPI. Im Fall von mehreren Levels von eingehenden SAs, die an einem Netzgerät enden, wird ein SPI aus der Liste von lokal eindeutigen SPI-Werten nur einer äußersten SA zugeordnet. Ein SPI wird in einem IPsec Protokoll-Header eines assoziierten IP 48 Pakets gespeichert. Für eine äußerste SA ist ein IPsec Protokoll-Header typischerweise für Kombinationen des IPsec Protokolls (z.B. AH und ESP) und Modus (z.B. Transport und Tunnel) sichtbar. Somit kann der Router 26 auf einen SPI in einer mit einem beliebigen eingehenden IP 48 Paket assoziierten äußersten SA zugreifen. Nach dem Herstellen von einer oder mehreren SAs zwischen einem Netzgerät und einem Fern-Netzgerät kann DNAT mit Sicherheit verwendet werden.
Verwendung von IPsec und DNAT
Ein erstes Netzgerät auf einem ersten Netzwerk tauscht Meldungen mit einem dritten Netzgerät auf einem zweiten externen Netzwerk zum Herstellen einer sicheren Assoziation aus. So tauscht beispielsweise das erste Netzgerät IKE-Meldungen zum Herstellen einer Sicherheitsassoziation mit dem externen dritten Netzgerät aus. Nach dem Austauschen von einigen dieser Meldungen wird ein mit PAP 64 zugeordneter Sicherheitswert (z.B. SPI) zum Vollenden der Herstellung einer Sicherheitsassoziation zwischen den beiden Netzgeräten verwendet.
25 ist ein Ablaufdiagramm, das eine Methode 328 für Verteiltes-Netz-Adressenumsetzung mit Sicherheit illustriert. In Schritt 330 wird eine Anforderung in einem zweiten sicheren Protokoll von einem ersten Netzgerät auf einem ersten Netzwerk zu einem zweiten Netzgerät auf dem ersten Netzwerk für ein drittes Netzgerät auf einem externen zweiten Netzwerk gesendet. Die Anforderung enthält Sicherheitsanforderungsinformationen, die zum ersten Netzgerät geleitet werden. In einer bevorzugten Ausgestaltung der vorliegenden Erfindung beinhalten die Sicherheitsanforderungsinformationen einen lokal eindeutigen Sicherheitswert (z.B. SPI), der vom zweiten Netzgerät mit einem ersten Protokoll (z.B. Methode 304 von 22) zugeordnet wird. Der lokal eindeutige Sicherheitswert wird dem ersten Netzgerät vom zweiten Netzgerät bereitgestellt (z.B. Methode 304 von 22). In einer weiteren Ausgestaltung der vorliegenden Erfindung beinhalten die Sicherheitsanforderungsinformationen ein Sicherheitszertifikat, das von einer CA wie oben erörtert ausgegeben wurde. In Schritt 332 wird die Anforderung vom zweiten Netzgerät zu einem dritten Netzgerät auf einem zweiten externen Netzwerk geleitet. In Schritt 334 wird eine Antwort im zweiten sicheren Protokoll auf dem zweiten Netzgerät auf dem ersten Netzwerk für das erste Netzgerät vom dritten Netzgerät auf dem zweiten externe n Netzwerk empfangen. Die Antwort im zweiten sicheren Protokoll beinhaltet Sicherheitsinformationen von der zum ersten Netzgerät gesendeten Anforderung. In Schritt 336 wird die Antwort vom zweiten Netzgerät zum ersten Netzgerät auf dem ersten Netzwerk mit einem lokal eindeutigen Port von der Antwort im zweiten sicheren Protokoll geleitet. Die Antwort vollendet die Herstellung einer Sicherheitsassoziation zwischen dem ersten Netzgerät und dem externen dritten Netzgerät mit dem lokal eindeutigen Sicherheitswert.
In einer bevorzugten Ausgestaltung der vorliegenden Erfindung ist das erste Netzgerät ein Netzgerät (14, 16, 18, 20, 22 und 24) vom ersten Computernetz 12, das zweite Netzgerät ist der Router 26, das erste Protokoll ist PAP 64, das zweite sichere Protokoll ist IPsec, der lokal eindeutige Sicherheitswert ist ein vom Router 26 im PAP 64 zugeordneter SPI, die Sicherheitsassoziation ist eine SA. In dieser Ausgestaltung der vorliegenden Erfindung beinhaltet IPsec IKE.
Wie oben erörten, ist IKE ein Protokoll, das ein Sicherheitszertifikat und einen SPI-Wert führt. IKE negoziiert einen Session-Key und einen SPI, der mit einem Session-Key assoziiert ist. Es können jedoch auch andere Protokolle zum Negoziieren eines Session-Key verwendet werden. Die vorliegende Erfindung ist jedoch nicht auf diese beispielhafte bevorzugte Ausgestaltung begrenzt und es können auch andere Netzgeräte, Protokolle, Sicherheitswerte und sichere Verbindungen mit Methode 328 zur Anwendung kommen.
IKE kann in zwei separaten Betriebsarten mit der Bezeichnung „Main Mode" und „Aggressive Mode" verwendet werden. Im Main Mode wird ein SPI in einer ersten und zweiten Meldung (die erste vom Initiator zum Responder, die zweite vom Responder zum Initiator) gesendet und dann werden Sicherheitszertifikate in einer fünften und einer sechsten Meldung (die fünfte vom Initiator zum Responder, die sechste vom Responder zum Initiator) gesendet. Die dritte und die vierte Meldung werden zum Fortsetzen der IKE-Negotiationen verwendet. Im Aggressive-Modus wird der SPI jedoch in der ersten und der zweiten Meldung gesendet, während die Zertifikate in der dritten und der vierten Meldung gesendet werden. Die Anforderungs- und Antwortmeldungen in Methode 328 können beliebige der IKE-Meldungen sein, die im Main-Modus oder im Aggressive-Modus zum Senden eines SPI oder eines Sicherheitszertifikats verwendet werden.
In einer beispielhaften bevorzugten Ausgestaltung der vorliegenden Erfindung unter Verwendung von IPsec über DNAT beachtet der Router 26 (1) für abgehende Pakete keine TCP 58 oder UDP 60 Portnummern, obwohl sie mit IPsec mit AH möglicherweise sichtbar sind. Für abgehende Pakete mit IPsec entfernt der Router 26 einen virtuellen Tunnel-Header und leitet das übrige Paket über eine externe Netzschnittstelle 28 zu einem IP 48 Netzwerk 30 weiter. Der virtuelle Tunnel-Header ist ein äußerster Header auf dem Datenpaket.
Für IPsec benutzende eingehende Pakete führt der Router 26 (1) ein Mapping (21) zwischen lokalen IP-Adressen von Netzgeräten (z.B. 14, 16, 18, 20, 22, 24) und SPI-Werten (z.B. Schritt 288 von Methode 282 (20)). Wenn ein AH- oder ESP IPsec Paket am Router 26 ankommt, dann untersucht der Router 26 einen SPI-Wert im äußersten Header eines IPsec Pakets. Wie oben erörtert, ist der äußerste IPsec-Header gewöhnlich sichtbar. Der SPI-Wert im IPsec-Header dient zum Ermitteln einer lokalen IP 54 Adresse eines Zielnetzgerätes. Ein Tunnelungs-Header wird konstruiert und vorne an das Paket gehängt (z.B. siehe Tabellen 3, 5, 8 und 11. Das Paket wird zu einem lokalen Netzgerät weitergeleitet, das lokale Netzgerät entfernt den Tunnel-Header und verarbeitet das Paket. Der Router 26 modifiziert somit keinen Inhalt eines empfangenen IPsec-Pakets.
TCP 58/UDP 60 Ports werden zwar vom Router 26 mit IPsec für Adressen-Mapping nicht verwendet, aber sie werden immer noch für DNAT verwendet, wenn das IPsec-Paket decodiert ist. Das heißt, wenn die IPsec-Eingangsverarbeitung fertig ist, dann wird DNAT wie oben beschrieben verwendet (z.B. siehe 9 und 10 sowie 13 und 14 und zugehörigen Text). Portnummern werden ebenfalls von einem fernen zweiten Netzwerk benötigt, um Verbindungen mit Netzgeräten auf dem ersten Netzwerk ordnungsgemäß zu identifizieren, falls mehr als ein Gerät auf dem ersten Netzwerk Verbindungen mit einem fernen dritten Netzgerät hergestellt hat.
Der Router 26 wird zur Zuordnung und Zuordnungsaufhebung von DNAT-Ports und SPI verwendet. Lokale Netzgeräte können zusätzliche Portnummern und zusätzliche SPIs anfordern, die vom Router 26 zugeordnet werden. Der Router 26 kann auch eine zugeordnete Reihe von DNAT-Ports oder SPIs ungültig machen. Wenn auch IPsec implementiert wird, dann können zusätzliche Sicherheitszertifikate von der LCA mit einer Zuordnung von zusätzlichen DNAT-Ports und SPIs an lokale Netzgeräte ausgegeben werden. Ferner führt der Router 26 eine Liste aller Sicherheitszertifikate, die an seine lokalen Netzgeräte ausgegeben wurden, und stellt sicher, dass die Zuordnungen der assoziierten DNAT-Ports niemals aufgehoben werden, solange die Sicherheitszertifikate mit Bindungen an diese DNAT-Ports gültig sind.
Alternativ hebt der Router 26, wenn er die Erlaubnis hat, Zuordnungen von DNAT-Ports aufzuheben, eventuelle Sicherheitszertifikate mit Bindungen an diese DNAT-Ports auf. Der Rückzug eines Sicherheitszertifikats beinhaltet eine Avisierung von Fernsystemen, die aktive SAs mit den lokalen Netzgeräten hergestellt haben, deren Sicherheitszertifikate zurückgezogen wurden. Eine Zuordnungsaufhebung und ein Einzug eines Sicherheitszertifikats können beispielsweise dann erforderlich sein, wenn ein lokales Netzgerät einen Systemabsturz erfährt. Im Falle eines Systemabsturzes auf dem Router 26 werden Sicherheitszertifikate erneut zu Netzgeräten gesendet oder ungültige Sicherheitszertifikate werden sanft zurückgezogen.
Die Authentifizierungsmethoden sind im Hinblick auf die Form des Namensraums für eine Bindung von Sicherheitszertifikaten wie oben beschrieben nicht beschränkt. So könnte beispielsweise eine Kombination der globalen IP 48 Adresse 28 des Routers 26 und einer Benutzer-Email-Adresse (wo sich der Benutzer auf einem lokalen Netzwerk befindet) für eine Namensraumbindung für ein Sicherheitszertifikat verwendet werden. Der als LCA agierende Router 26 muss ein gültiges Sicherheitszertifikat besitzen, das ihm das Recht gibt, aus einem gewählten Namensraum gezogene Kennungen zu zertifizieren.
Die hier vorgestellten Methoden für bevorzugte Ausgestaltungen der vorliegenden Erfindung erstrecken sich auch auf IPsec im Zusammenhang mit Mobile IP, so dass ein mobiler Knoten zum Führen einer IPsec-geschützten Verbindung beim Roamen möglich ist. Für Mobile IP können die globale IP-Adresse eines Home-Agent eines mobilen Knotens und eine lokale Adresse von mobilen Knoten auf seinem Heimatnetz für eine Namensraumbindung zum Erzeugen eines Sicherheitszertifikats für die Verwendung für IPsec mit DNAT verwendet werden. Diese Informationen stehen einem mobilen Knoten selbst dann zur Verfügung, wenn dieser roamt (d.h. sich vorübergehend in einem Fremdnetz befindet). Ein Heimatnetz eines mobilen Knotens wird als DNAT-Stub-Netzwerk verwaltet, in dem sich der mobile Knoten als lokaler Host befindet, wenn er nicht roamt. Die Verwendung von DNAT mit Mobile IP ist in dem verwandten US-Patent Nr. 6,697,354 beschrieben.
Ein modifizierter Sicherheitsnamensraum kann verwendet werden, um eine eindeutige Kennung in einem Sicherheitszertifikat zu einem Netzgerät zu senden, das keine global eindeutige IP 48 Adresse hat, und ist nicht auf ein Design auf der Basis beschränkt, dass der Router 26 als LCA fungiert. Es ist auch möglich, eine globale CA mit einem modifizierten Namensraum zu definieren und die Notwendigkeit für die LCA oder die Funktion des Router 26 als LCA zu elimineren.
Ein solcher modifizierter Namensraum reicht jedoch typischerweise für die DNAT-Umgebung nicht aus, da er keine lokal eindeutige Portnummer beinhaltet und somit einem Fernsystem nicht garantiert, dass ein lokales Netzgerät das Recht hat, eine bestimmte Portnummer zu verwenden. Ebenso stellt der hierin beschriebene LCA-Ansatz, da Stub-Netzwerke existieren und DNAT Methoden zum gemeinsamen Nutzen von globalen IP 48 Adressen in Stub-Netzwerken beinhaltet, eine Implementation bereit, die auf einer existierenden Infrastruktur aufbauen würde, anstatt eine neue Infrastruktur zu verlangen, wenn ein DNAT-System verwendet wird. Somit kann IPsec mit DNAT verwendet werden, wobei der Router 26 als eine LCA agiert, ohne dass eine neue Infrastruktur zum Unterstützen einer globalen CA nötig ist.
Es ist zu verstehen, dass sich die hierin beschriebenen Programme, Prozesse, Methoden und Systeme nicht auf einen bestimmten Typ von Computer oder Netzwerksystem (Hardware oder Software) beziehen oder darauf begrenzt sind, wenn nichts anders angegeben ist. Es können verschiedene Typen von Universal- oder Spezialcomputersystemen gemäß den hierin beschriebenen Lehren verwendet oder Operationen damit durchgeführt werden.
Im Hinblick auf die große Palette verschiedener Ausgestaltungen, auf die die Grundsätze der vorliegenden Erfindung angewendet werden können, ist zu verstehen, dass die illustrierten Ausgestaltungen lediglich beispielhaft und nicht als den Umfang der vorliegenden Erfindung einschränkend anzusehen sind. So können beispielsweise die Schritte der Ablaufdiagramme in anderen Abfolgen als den beschriebenen ausgeführt werden und es können mehr oder weniger Elemente in den Blockdiagrammen verwendet werden. Es wurden zwar verschiedene Elemente der bevorzugten Ausgestaltungen als softwaremäßig implementiert beschrieben, aber in anderen Ausgestaltungen können alternativ Hardware- oder Firmware-Implementationen zur Anwendung kommen und umgekehrt.
Die Ansprüche sind nicht als auf die beschriebene Reihenfolge oder die beschriebenen Elemente begrenzt zu lesen, es sei denn, dass dies eigens angegeben ist. Daher werden als die Erfindung alle Ausgestaltungen beansprucht, die in den Umfang der nachfolgenden Ansprüche und Äquivalente fallen.

Claims

Verfahren (274) für eine sichere Adressenumsetzung in einem verteilten Netz, das die folgenden Schritte umfasst: an einem ersten Netzgerät (14, 16, 18, 20, 22, 24) auf einem ersten Computernetzwerk (12), Anfordern (276) von einem oder mehreren lokal eindeutigen Sicherheitswerten von einem Routing-Gerät (26) auf dem ersten Computernetzwerk mit einem ersten Protokoll (64), um das erste Netzgerät bei sicheren Kommunikationen mit einem dritten Netzgerät auf einem externen Netzwerk (30, 32) eindeutig zu identifizieren, und für eine sichere Adressenumsetzung in dem verteilten Netz; Empfangen (278) der ein oder mehreren lokal eindeutigen Sicherheitswerte auf dem ersten Netzgerät von dem Routing-Gerät mit dem ersten Protokoll; und Speichern (280) der ein oder mehreren lokal eindeutigen Sicherheitswerte auf dem ersten Netzgerät; und mit den ein oder mehreren lokal eindeutigen Sicherheitswerten, Herstellen einer sicheren virtuellen Verbindung mit einem zweiten sicheren Protokoll für sichere Kommunikationen zwischen dem ersten Netzgerät und dem dritten Netzgerät und für eine Adressenumsetzung in dem verteilten Netz.
Verfahren nach Anspruch 1, bei dem das Routing-Gerät ein Verteiltes-Netz-Adressenumsetzungsrouter ist.
Verfahren nach Anspruch 1, bei dem die ein oder mehreren lokal eindeutigen Sicherheitswerte ein oder mehrere Sicherheitsparameterindexe für ein Internet Protokoll Sicherheitsprotokoll sind.
Verfahren nach Anspruch 3, bei dem das Internet Protokoll Sicherheitsprotokoll ein Authentication Header Protokoll, ein Encapsulated Security Payload Protokoll oder ein Internet Key Exchange Protokoll ist.
Verfahren nach Anspruch 1, bei dem das erste Protokoll ein Port Allocation Protokoll ist.
Verfahren nach Anspruch 1, bei dem der Anforderungsschritt ferner das Anfordern von einem oder mehreren lokal eindeutigen Ports beinhaltet, die zum eindeutigen Identifizieren des ersten Netzgerätes auf dem ersten Netzwerk für eine Adressenumsetzung in dem verteilten Netz verwendet werden.
Verfahren nach Anspruch 6, bei dem die lokal eindeutigen Ports Port Allocation Protokoll Ports sind.