DE10392807T5 - Verfahren und Vorrichtung für eine verbesserte Sicherheit für eine Kommunikation über ein Netzwerk - Google Patents

Verfahren und Vorrichtung für eine verbesserte Sicherheit für eine Kommunikation über ein Netzwerk Download PDF

Info

Publication number
DE10392807T5
DE10392807T5 DE10392807T DE10392807T DE10392807T5 DE 10392807 T5 DE10392807 T5 DE 10392807T5 DE 10392807 T DE10392807 T DE 10392807T DE 10392807 T DE10392807 T DE 10392807T DE 10392807 T5 DE10392807 T5 DE 10392807T5
Authority
DE
Germany
Prior art keywords
address
computer
gateway
client
local
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE10392807T
Other languages
English (en)
Other versions
DE10392807B4 (de
DE10392807B9 (de
Inventor
Thomas Albert Cupertino Maufer
Sameer San Jose Nanda
Paul J. Cupertino Sidenblad
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/172,345 external-priority patent/US7191331B2/en
Priority claimed from US10/172,046 external-priority patent/US7143188B2/en
Priority claimed from US10/172,683 external-priority patent/US7120930B2/en
Priority claimed from US10/172,352 external-priority patent/US7143137B2/en
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE10392807T5 publication Critical patent/DE10392807T5/de
Publication of DE10392807B4 publication Critical patent/DE10392807B4/de
Application granted granted Critical
Publication of DE10392807B9 publication Critical patent/DE10392807B9/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/255—Maintenance or indexing of mapping tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

Verfahren für verbesserte Sicherheit beim Kommunizieren über ein Netzwerk zwischen einem Client-Computer hinter einem Adressenübersetzungs-konfigurierten Gateway-Computer und einem entfernten Computer, wobei das Verfahren aufweist:
Bereitstellen einer öffentlichen Adresse an den Client-Computer des Gateway-Computers, wobei die öffentliche Adresse eine öffentliche Adresse des Gateway-Computers oder ein Pool von öffentlichen Adressen des Gateway-Computers ist;
Teilhaben an einer Sicherheits-Vereinigungsverhandlung mit dem entfernten Computer; und
Verwenden der Sicherheits-Vereinigungsverhandlung als eine Anzeige zum Aufzeichnen einer lokalen Adresse für den Client-Computer in Verbindung mit einer Zieladresse für den entfernten Computer, wobei die lokale Adresse und die Zieladresse aus der Sicherheits-Vereinigungsverhandlung erhalten werden und in einer Datenstruktur aufgezeichnet werden, auf die von dem Gateway-Computer zugegriffen werden kann.

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft im Allgemeinen eine verbesserte Sicherheit für die Kommunikation über ein Netzwerk.
  • HINTERGRUND DER ERFINDUNG
  • Das Internet bleibt ein wachsendes öffentliches Netzwerk. Viele Firmen verlassen sich auf die Kommunikation über das Internet, um ihre unternehmerischen Bemühungen zu erleichtern. Dennoch bringt ein öffentlicher Zugang Sicherheitsrisiken mit sich. Um die Sicherheit des Internets zu verbessern hat die Internet Engineering Task Force (IETF) einen Satz von Protokollen konzipiert, welche gesamtheitlich als Internetprotokoll-Sicherheit (Internet Protocol Security = "IPSec") bekannt sind. IPSec ist dahingehend konzipiert, um Authentifizierungen und Verschlüsselungen für die Kommunikation über ein Netzwerk, wie beispielsweise das Internet, bereitzustellen. Die Netzwerk-Adress-Übersetzung (Network Address Translation = NAT) war ebenfalls ein bedeutender Faktor in dem Wachstum des Internets, jedoch steht das Betreiben von NAT bedauerlicherweise in Konflikt mit IPSec.
  • Die NAT übersetzt zwischen einem Satz von einer oder mehreren privaten IP (Internetprotokoll)-Adressen, welche in einem lokalen internen Netzwerkverkehr mit einer oder mehreren "öffentlichen" IP-Adressen verwendet werden, welche dynamisch ausgewählt werden, wenn interne Adressen es wünschen mit externern Maschinen Verkehr auszutauschen. Eine Übersetzungstabelle in einem NAT-Gateway erlaubt dem Internetverkehr einer Organisation, eine (oder mehrere) öffentliche Adresse(n) gemeinsam zu verwenden, welche der Organisation zugeteilt wurden. Herausgehende Pakete für neue Verbindungen haben neue NAT-Übersetzungstabellen-Einträge zur Folge, welche in dem Gateway erzeugt werden. Die NAT-Übersetzungstabelle wird dazu verwendet, um eine inverse Übersetzung des Verkehrs, welcher in der entgegengesetzten Richtung ankommt durchzuführen (d. h., hereinkommender Verkehr - von dem öffentlichen Internet).
  • Ein Client-Computer in einem LAN kann eine lokale IP-Adresse aufweisen, welche statisch zugewiesen wurde; dennoch teilt eine Dynamic Host Configuration Protocol (DHCP)-Servereinheit einem Client-Computer dynamisch eine private IP-Adresse in einem LAN zu. Solch eine private Adresse wird eindeutig aus einem Pool von verfügbaren privaten IP-Adressen ausgewählt. Der DHCP-Serverprozess wird häufig in dem NAT-Gateway co-lokalisiert, kann aber auch in einer separaten Vorrichtung innerhalb des privaten Netzwerkes gehostet werden. So weist beispielsweise ein IP-Paket von einem Client-Computer oder anderen lokalen Maschine, welche ein Teil einer lokalen oder privaten Domain ("dahinter") hinsichtlich eines NAT-Gateways ist, die IP-Quelle und die Zieladressen in dem Header des IP-Paketes auf, und weist Quell- und Ziel-Port-Adressen in dem User Datagram Protocol- oder Transmission Control Protocol (UDP oder TCP)-Header des Paketes auf. Herkömmlicherweise enthält das IP-Quell-Adressfeld des Paketes die private IP-Adresse, welche dem Client-Computer statisch oder dynamisch zugeordnet wurde, während das IP-Ziel-Adressfeld des Paketes die private Adresse für ein Paket, welches für eine andere Maschine hinter dem NAT-Gateway bestimmt ist oder eine öffentliche IP-Adresse für ein Paket, welches für eine andere Maschine, welche nicht hinter dem NAT-Gateway ist, bestimmt ist, enthält, wie beispielsweise entfernte Computer, welche an das Internet angeschlossen sind.
  • Für das letzte Beispiel ändert ein NAT-Gateway das ausgehende IP-Quell-Adressfeld des Pakets von einer lokal eindeutigen privaten IP-Adresse zu einer öffentlichen oder weltweit eindeutigen IP-Adresse. Die neue Quelladresse des Pakets, nun eine öffentliche IP-Quelladresse, ist herkömmlicherweise entweder die IP-Adresse der externen Schnittstelle des NAT-Gateways oder aus einem Pool verfügbarer öffentlicher Adressen zugewiesen, welche durch das NAT-Gateway verwaltet werden.
  • Außerdem, kann es für ein NAT-Gateway erforderlich sein, die Transport-Schicht-Adressen (d. h., TCP- oder UDP-Ports) zu übersetzen, um mehreren Verbindungen zu erlauben, die gleiche IP-Adresse gemeinsam zu verwenden. In den Fällen, bei denen das NAT-Gateway seine eigene öffentliche IP-Adresse als eine öffentliche IP-Adresse für herausgehende Pakete von lokalen Maschinen verwendet, werden externe Verbindungen aus dem NAT-Gateway-Computer hervorgehen. Um zu vermeiden, dass zwei lokale Client-Maschinen mittels der gleichen Remote-IP-Adresse kommunizieren und den gleichen Ziel-TCP oder -UDP-Port auswählen, was es dem NAT-Gateway unmöglich machen würde, zu ermitteln, welcher Client Antwort-Verkehr erhalten soll, wird jede Verbindung des NAT-Gateway-Computers derart übersetzt, dass ausgehender Verkehr von einer eindeutig identifizierbaren öffentlichen IP-Adresse und TCP- oder UDP-Quell-Port-Paar hervorgehen wird. Die Chance, dass solch eine Situation auftritt, scheint fern zu liegen, aber sie ist möglich, insbesondere wenn sich die Anzahl der lokalen Clients erhöht und es eine Situation ist, welche durch das Durchführen der Übersetzung des TCP- oder UDP-Ports zusätzlich zu der Übersetzung der IP-Adresse vermieden werden kann. Da ein NAT-Gateway nicht nur private/öffentliche IP-Adress-Zuordnungen speichert, sondern auch TCP- oder UDP-Port-Zuordnungen für das Übersetzen und Weiterleiten für hereinkommenden Verkehr, wird die NAT manchmal als Netzwerk-Adress- und Port-Übersetzung (Network Address and Port-Translation = NAPT) bezeichnet.
  • Die IPSec hängt teilweise von der Abhandlung von Parametern ab, welche eine Verbindung beherrschen, welche eine verbesserte Sicherheit erfordert. Die Kollektion von Parametern, aufweisend solch exemplarische Begriffe wie Authentifizierung und/oder Verschlüsselungs-Session-Schlüssel, Schlüssel-Lebenszeiten, Verschlüsselungs- oder Authentifizierungs-Algorithmen, ist neben anderen bekannten Begriffen, welche abgehandelte Sicherheitsparameter zwischen gleichrangigen Stationen verwalten, gesammelt als Sicherheits-Vereinigung (Security Association = SA) bekannt. Eine SA-Abhandlung wird gemäß eines Protokolls durchgeführt, welches als Internet-Sicherheits-Vereinigungs- und Schlüssel-Verwaltungs-Protokoll (Internet Security Association and Key Management Protocol = ISAKMP) bekannt ist, welches den Schlüssel-Bestimmungs-Algorithmus von Oakley verwendet. ISAKMP/Oakley ist üblicherweise mehr als Internet-Schlüsselaustausch (Internet Key Exchange = IKE) bekannt. Ein Ergebnis einer IKE-Abhandlung ist eine private Übereinkunft zufällig ausgewählter Session-Schlüssel, welche für das Verschlüsseln und Entschlüsseln und/oder für digitale Unterzeichnungs-Nachrichten (d. h. IP-Pakete) verwendet werden. Der UDP-Port 500 ist für das ISAKMP reserviert, das IPSec-Steuerprotokoll.
  • IPSec-geschützte IP-Pakete werden mindestens einen von zwei Typen von IPSec-Sicherheits-Protokoll-Headern entsprechend, ob eine Authentifizierung, eine Verschlüsselung oder beides in einem IKE abgehandelt wurde, mit einschließen. Um diese IPSec-Sicherheits-Protokoll-Header zum Zweck der Klarheit zusammenzufassen: ein "Authentifizierungs-Header" (AH) wird verwendet, wenn eine Authentifizierung abgehandelt wurde, ein "Encapsulating Security Payload" (ESP) Header wird verwendet, wenn eine Verschlüsselung abgehandelt wurde und ein AH-Header, welcher einen ESP-Header verkapselt, wird verwendet, wenn ein IP-Paket sowohl einen AH- und einen ESP-Header enthält, wie wenn beispielsweise ein ESP mit einem AH abgehandelt wurde.
  • Sobald eine IPSec-Sicherheits-Vereinigung gegründet wurde, spezifiziert ein Internetprotokoll-Header jedes IPSec- geschützten Paketes den Typ des Sicherheitsprotokolls, welches verwendet wird, d. h. AH oder ESP, aufweisend eine Kombination hiervon. In der IP-Version 4 ("IPv4") gibt es ein 8-Bit "Protokoll"-Feld in einem IPv4-Header, welches das nächst höhere Schicht-Protokoll bezeichnet, welches folglich über der IP-Schicht ist. In der IP-Version 6 ("IPv6") gibt es ein 8-Bit "nächstes Header"-Feld welches eine zu dem Protokoll-Feld in einem IPv4-Header gesehen ähnliche Funktionalität bereitstellt. In IPv4 sowie in IPv6 bezeichnet ein Wert von 0x32 den ESP und ein Wert von 0x33 bezeichnet den AH. Die AH- und ESP-Header enthalten beide ein 32-Bit-Feld für numerische Werte, welches als Sicherheitsparameterindex (Security Parameters Index = SPI) bekannt ist. Falls ein IP-Paket digital signiert wurde (unter Verwendung von AH), können bestimmte wichtige Teile des IP-Headers solch eines IP-Paketes nicht modifiziert werden, andernfalls ist es für eine IPSec-Peer-Station, welche solch ein IP-Paket empfängt nicht möglich zu verifizieren, dass die digitale Signatur des IP-Paketes korrekt ist. Aber im Zuge eines konventionellen Ablaufs wird ein NAT-Gateway die IP-Quelladresse des Paketes für herausgehende Pakete (d. h. local-to-remote oder private-to-public) oder die Zieladresse des Paketes für hereinkommende Pakete (d. h. Remote-to-Local oder public-to-private) zu verändern. In jede Richtung wird die NAT-Umformung des IP-Headers die Fähigkeit der IPSec-Peer-Station behindern, die digitale Signatur des AH's zu verifizieren. Als ein Beispiel für herausgehenden Verkehr, wenn ein NAT-Zwischen-Gateway oder -Router die private IP-Quelladresse eines Paketes zu einer globalen oder öffentlichen IP-Adresse ändert, wird die Authentifizierung bei einem empfangenen Computer fehlschlagen, da die private IP-Adresse nicht länger für den Empfänger bei dessen Verifikation der digitalen Signatur verfügbar ist. Vordem war der IPSec-AH in Folge von notwendigen Änderungen die an einem IP-Paket während des Übergangs durch ein NAT-Gateway durchgeführt wurden, inkompatibel mit einem NAT.
  • Für verschlüsselte aber nicht signierte Pakete (d. h. diejenigen IPSec-Pakete, welche durch ESP ohne AH geschützt sind) sind die Transportschicht-Header durch Dritte nicht entschlüsselbar (noch sind sie an ihrer üblichen Stelle in dem Paket, sogar falls sie entschlüsselbar wären), einschließend ein NAT-Gateway, und demnach sind die TCP- oder UDP-Port-Nummern für ein NAT-Gateway für das Verwenden in dem Prozess der herausgehenden und/oder hereinkommenden Übersetzung nicht verfügbar. Also, sogar wenn der IPSec-ESP ohne Rücksicht auf das Vorhandensein eines Authentifizierungs-Headers alleine mit dem grundlegenden NAT-Ablauf interferiert (d. h., ESP ohne AH). Als Erweiterung für ein IP-Paket, welches sowohl durch einen AH und einen ESP geschützt ist, kann seine IP-Quelladresse nicht verändert werden und die Port-Nummern sind verschlüsselt.
  • In der Zusammenfassung können ein AH-Header, ein ESP-Header oder beide einem IP-Paket hinzugefügt werden. Wichtig für eine NAT ist, dass das IP-Quell-Adressfeld von AH-geschützten Paketen nicht verändert werden kann, da es ein Teil der Eingabe des digitalen Signier-Algorithmus ist. Wesentlich für ESP-geschützte Pakete ist, dass die IP-Quelladresse ohne das Eingreifen in die Fähigkeit der Peer-Stationen die empfangenen Pakete zu entschlüsseln, geändert werden kann, obwohl die Quell- und Ziel-Port-Nummern verschlüsselt sind und dadurch durch ein NAT-Gateway nicht entschlüsselbar sind. Im Zusammenhang mit ESP gab es zuvor keinen Mechanismus, um das zurückkehrende Verkehrs-Routing klarzustellen, und zwar, um zu bestimmten, welche private Station ein ESP-geschütztes Paket empfangen soll, da die TCP- oder UDP-Port-Nummern durch das NAT-Gateway nicht entschlüsselbar sind. Darüber hinaus begrenzte zuvor ein ESP-geschützter Verkehr für ein virtuelles privates Netzwerk (VPN) die Anzahl von VPN-Sessions zu der gleichen Remote-IP-Adresse oder schloss nicht standardisierte Modifikationen in einem VPN-Client mit ein.
  • Entsprechend wäre es wünschenswert und nützlich, eine Integration von NAT und IPSec bereitzustellen, welche keinen signifikanten Übergang hinzufügt und keine IP-Quell- oder Zieladresse und/oder TCP- oder UDP-Quell- oder Ziel-Port-Übersetzung benötigt, welche mit dem Sicherheitsalgorithmus des IPSec's inkompatibel ist.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Ein Aspekt der vorliegenden Erfindung ist ein Verfahren für eine verbesserte Sicherheit beim Kommunizieren über ein Netzwerk zwischen einem Client-Computer hinter einem Adressübersetzungs-konfigurierten Gateway-Computer und einem entfernten Computer. Dem Client-Computer des Gateway-Computers wird eine öffentliche Adresse bereitgestellt, wobei die öffentliche Adresse eine öffentliche Adresse des Gateway-Computers oder ein Pool von öffentlichen Adressen des Gateway-Computers ist. Der Gateway-Computer nimmt an einer Sicherheits-Vereinigungsverhandlung mit dem entfernten Computer teil. Der Gateway-Computer verwendet die Sicherheits-Vereinigungverhandlung als eine Anzeige zum Aufzeichnen einer lokalen Adresse für den Client-Computer in Verbindung mit einer Zieladresse für den entfernten Computer, wobei die lokale Adresse und die Zieladresse von der Sicherheits-Vereinigungsverhandlung erhalten werden und in einer Datenstruktur aufgezeichnet werden, auf die von dem Gateway-Computer zugegriffen werden kann.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren zum Verarbeiten eines Internetprotokollsicherheits (IPSec)-Pakets mit einem Netzwerk-Adress-Übersetzungs (Network Address Translation = NAT)-Gateway-Computer. Auf dem NAT-Gateway-Computer wird eine Überprüfung auf eine öffentliche Internetprotokoll (IP)-Quelladresse für das IPSec-Paket durchgeführt, die an dem NAT-Gateway-Computer zuweisbar ist, und in Antwort auf die öffentliche IP-Quelladresse, die von dem NAT-Gateway-Computer zuweisbar ist, wird bestätigt, dass das IPSec-Paket von einem lokalen Computer gesendet wurde. Das IPSec-Paket wird an eine Zieladresse übertragen, ohne die öffentliche IP-Quelladresse zu übersetzen in Antwort auf eine Bestätigung, dass das IPSec-Paket von dem lokalen Computer gesendet wurde.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren zum Routen eines empfangenen Pakets mit einer Quelladresse und einer öffentlichen Adresse eines Gateway-Computers. Auf die Quelladresse wird eine Überprüfung in einer Zuordnungstabelle, die in Verbindung mit der öffentlichen Adresse des Gateway-Computers aufgelistet ist, durchgeführt, und ein Sicherheitsparameterindex wird von dem empfangenen Paket erhalten. In Verbindung mit der Quelladresse des empfangenen Paketes wird eine Überprüfung des Sicherheitsparameterindex in der Zuordnungstabelle durchgeführt. In Antwort auf das Finden des Sicherheitsparameterindex in der Zuordnungstabelle in Verbindung mit der Quelladresse des empfangenen Pakets, wird das empfangene Paket an eine lokale Adresse geroutet, die mit dem Sicherheitsparameterindex und der Quelladresse in der Zuordnungstabelle verbunden ist, wobei die lokale Adresse nicht die öffentliche Adresse des Gateway-Computers ist.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren für die Internet-Schlüsselaustausch-Steuerung (Internet Key Exchange (IKE) control). Es wird ein mit einer Zuordnungstabelle konfigurierter Gateway-Computer bereitgestellt. Bei dem Gateway-Computer wird ein Paket von einem lokalen Client-Computer erhalten und das Paket wird überprüft, um zu ermitteln, ob es ein IKE-Paket ist. In Antwort darauf, dass das Paket ein IKE-Paket ist, wird eine Überprüfung für eine Aufzeichnung, die sowohl eine Internet Protocol (IP)-Zieladresse als auch eine lokale Medium-Access-Control (MAC)-Adresse des IKE-Paketes in der Zuordnungstabelle berücksichtigt, durchgeführt. In Antwort darauf, dass das Paket ein IKE-Paket ist, wird eine Überprüfung für eine Aufzeichnung in der Zuordnungstabelle durchgeführt, die sowohl eine Internetprotokoll (IP)-Zieladresse als auch eine lokale Mediumzugangssteuerungs (MAC)-Adresse des IKE-Pakets in der Zuordnungstabelle berücksichtigt. Eine Überprüfung wird auf für einen Sicherheitsparameterindex durchgeführt, der die Aufzeichnung in der Zuordnungstabelle betrifft, in Antwort auf das Identifizieren der Aufzeichnung in der Zuordnungstabelle.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren für eine Sicherheits-Verhandlungssteuerung für einen Gateway-Computer. Der Gateway-Computer wird mit einem Zugang zu einer Datenstruktur bereitgestellt. An dem Gateway-Computer wird ein Paket empfangen, und es wird ermittelt, ob das Paket ein Sicherheits-Verhandlungspaket ist. Die Datenstruktur wird in Antwort auf das Paket, das Teil der Sicherheitsübertragung ist, auf eine Medium-Access-Control (MAC)-Quelladresse und eine Zieladresse überprüft. In Antwort auf das Finden der Zieladresse in der Datenstruktur und das Nicht-Finden der MAC-Quelladresse in der Datenstruktur in Verbindung mit der Zieladresse, wird bestimmt, ob ein Sicherheitswert für die Zieladresse in der Datenstruktur vorliegt. In Antwort auf das Nicht-Finden des Sicherheitswertes in der Datenstruktur für die Zieladresse, wird die Übertragung des Sicherheits-Verhandlungspaketes unterdrückt.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren zum Bilden eines Pakets mittels eines Client-Computers. Für den Client-Computer wird eine öffentliche Adresse von einem Netzwerk-Adress-Übersetzungs-Gateway-Computer erhalten. Die öffentliche Adresse ist zum Verwenden als eine Quelladresse für das Paket erhalten.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren zum Erzeugen einer Zuordnungstabelle für eine Netzwerk-Adress-Übersetzungs (NAT)-Integration mit Internetprotokollsicherheits (IPSec)-geschützten Paketen. Es wird ein Gateway-Computer mit einem Zugriff auf die Zuordnungstabelle bereitgestellt. An dem Gateway-Computer wird ein Paket von einem Client-Computer, der mit der Mediumzugriffssteuerungs-Adresse in Verbindung ist, empfangen, wobei die Mediumzugriffssteuerungs-Adresse zusätzlich zu einer Quelladresse für das Paket mit dem Paket gesendet wird. Die Quelladresse ist eine öffentliche Adresse des Gateway-Computers. Der Gateway-Computer bestimmt, ob das Paket ein Sicherheits-Verhandlungspaket ist, und in Antwort darauf, dass das Paket ein Sicherheits-Verhandlungspaket ist, wird die Mediumzugriffssteuerungs-Adresse in der Zuordnungstabelle zusammen mit der Zieladresse des Paketes gemäß der Mediumzugriffssteuerungs-Adresse und einem Initiatorindikator gemäß mindestens einer von der Mediumzugriffssteuerungs-Adresse und der Zieladresse aufgezeichnet.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren für die Netzwerk-Adress-Übersetzungs (NAT)-Integration mit einem Authentifizierungs-Header (AH)-geschützten Paket. Ein Client-Computer wird mit einer öffentlichen Adresse von einem NAT-Gateway-Computer bereitgestellt. Der Client-Computer bildet das AH-geschützte Paket mit der öffentlichen Adresse als Quelladresse und sendet das AH-geschützte Paket von dem Client-Computer an den NAT-Gateway-Computer.
  • Ein anderer Aspekt der vorliegenden Erfindung ist eine Datenstruktur für einen Gateway-Computer. Es werden ein Mediumzugriffssteuerungs-Adressfeld, ein lokales öffentliches Adressfeld gemäß dem Mediumzugriffssteuerungs-Adressfeld, ein nicht-lokales Adressfeld gemäß dem Mediumzugriffssteuerungs-Adressfeld und ein Sicherheitsparameter-Indexfeld gemäß dem nicht-lokalen Adressfeld bereitgestellt. Das Sicherheitsparameter-Indexfeld ist für das Speichern des Sicherheitsparameterindex gemäß einer Kommunikation von einer nicht-lokalen Maschine.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren zum Sondieren eines Gateway-Computers durch einen Client-Computer, um zu bestimmen, ob die Netzwerk-Adress-Übersetzung mit Quelladressensicherheit integriert wird. Ein erstes Anfragen einer ersten Adresse des Gateway-Computers wird durch den Client-Computer mit einem ersten Client-Bezeichner vollzogen. Die erste Adresse wird von dem Gateway-Computer in Antwort auf die erste Anfrage gesendet. Ein zweites Anfragen einer zweiten Adresse des Gateway-Computers wird durch den Client-Computer mit einem zweiten Client-Bezeichner vollzogen, wobei der zweite Client-Bezeichner dem ersten Client-Bezeichner ähnlich ist. Die zweite Adresse wird von dem Client-Computer vom Gateway-Computer ausgehend in Antwort auf die zweite Anfrage empfangen. Der Client-Computer ermittelt aus der zweiten angeforderten Adresse, ob die Netzwerk-Adress-Übersetzung für den Gateway-Computer mit der Quelladressensicherheit integriert ist.
  • Ein anderer Aspekt der vorliegenden Erfindung ist ein Verfahren zur Netzwerk-Adress-Übersetzung für Quelladressen-geschützte Pakete. Ein Client-Computer wird in Kommunikationen mit einem Adress-Server-Computer bereitgestellt. Eine erste Anfrage des Client-Computers für eine erste Adresse wird von dem Adress-Server-Computer vollzogen, wobei der Client-Computer durch den Adress-Server-Computer durch eine Mediumzugriff-Steuerungsnummer identifizierbar ist. Eine private Adresse wird durch den Adress-Server-Computer dem Client-Computer in Antwort auf die erste Anfrage bereitgestellt. Eine Änderung der Mediumzugriff-Steuerungsnummer wird durch den Client-Computer erzeugt, um eine geänderte Mediumzugriff-Steuerungsnummer bereitzustellen. Eine zweite Adresse von dem Adress-Server wird durch den Client-Computer angefragt, wobei der Client-Computer von dem Adress-Server-Computer durch die geänderte Mediumzugriff-Steuerungsnummer identifizierbar ist. Der Adress-Server-Computer ordnet dem Client-Computer die erste Anfrage und die zweite Anfrage zu, indem die Mediumzugriff-Steuerungsnummer mit der geänderten Mediumzugriff-Steuerungsnummer in Verbindung gebracht wird; und stellt dem Client-Computer eine öffentliche Adresse in Antwort auf die zweite Anfrage bereit.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Damit die Art und Weise in welcher die oben zitierten Merkmale, Vorteile und Ziele der vorliegenden Erfindung erreicht werden und im Detail besser verstanden werden, wird eine detailliertere Beschreibung der Erfindung, welche oben kurz zusammengefasst wurde, in Bezug auf die darin enthaltenen Ausführungsformen, welche in den anhängenden Zeichnungen dargestellt sind, gegeben.
  • Es wird dennoch darauf hingewiesen, dass die anhängenden Zeichnungen lediglich typische Ausführungsbeispiele dieser Erfindung zeigen und folglich nicht als Limitierung ihres Umfanges anzusehen sind, wobei die vorliegende Erfindung andere ebenso effektive Ausführungsbeispiele zulassen kann.
  • 1 ist ein Blockdiagramm eines exemplarischen Ausführungsbeispiels eines Computersystems gemäß einem oder mehreren Aspekten der vorliegenden Erfindung.
  • 2 ist ein Netzwerkdiagramm eines exemplarischen Ausführungsbeispiels eines Netzwerks gemäß einem oder mehreren Aspekten der vorliegenden Erfindung.
  • 3, 3A und 4 sind jeweils Flussdiagramme exemplarischer Ausführungsbeispiele jeweiliger Teile eines IPSec/NAT-Integrationsprozesses gemäß einem oder mehreren Aspekten der vorliegenden Erfindung.
  • 5A und 5B sind Tabellen exemplarischer Ausführungsbeispiele von IPSec Association Mapping Tabellen (IPSAMTs) gemäß einem oder mehreren Aspekten der vorliegenden Erfindung.
  • DETAILLIERTE BESCHREIBUNG
  • Die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung für die Koexistenz von IPSec und NAT bereit, wobei ein Mechanismus erzeugt wird, in welchem keine IPSec-inkompatible NAT-IP-Adresse oder TCP- oder UDP-Port-Übersetzung auf ein Paket angewendet werden muss, da die äußerlich bestimmten Pakete eines Client-Computers derart konstruiert sind, so dass sie keine private IP-Quelladresse verwenden. Stattdessen erzeugt die IPSec-Software des Clients ihre äußerlich bestimmten Pakete unter Verwendung einer öffentlichen IP-Adresse, welche von einer NAT-Vorrichtung bereitgestellt werden.
  • Der Verkehr von jeder Remote-IP-Adresse zu jeder lokalen Peer-Client-Maschine wird einen eindeutigen Sicherheitsparameterindex in einem AH- oder ESP-Header aufweisen, welche anstelle der TCP- oder UDP-Ports verwendet werden können, um einem NAT-Gateway zu erlauben, zu entscheiden, zu welcher lokalen Station ein IPSec-geschütztes Paket zu senden ist. Solange jeder lokale Client mit einer Remote-IP-Adresse kommuniziert, und kein anderer Client mit der gleichen Remote-IP-Adresse kommuniziert, kann die Übersetzung eine konventionelle NAT-Übersetzung sein, welche lediglich das IP-Quell-Adressfeld mit einschließt. Falls dennoch mehrere lokale Client-Maschinen darauf angewiesen sind, mit der gleichen Remote-IP-Adresse zu kommunizieren, dann kann es für ein IPSec-fähiges NAT-Gateway erforderlich sein, eine IKE-Unterdrückung durchzuführen, um sicher zu stellen, das lediglich ein SA zu einem Zeitpunkt zwischen irgendeinem lokalen/entfernten Paar von Maschinen abgehandelt wird. Eine Feinheit liegt hier in der Tatsache, dass der Sicherheitsparameterindex, während er klar verwendet wird, privat abgehandelt wird, so dass ein NAT-Gateway keinen Zugang zu einem abgehandelten Sicherheitsparameterindex aufweist, welcher in Verwendung ist, bis eine entfernte Station das erste IPSec-geschützte Paket an eine lokale Station sendet. Sobald der Sicherheitsparameterindex bekannt ist, können andere lokale Stationen, eine zu einem Zeitpunkt, ihre eigenen Sicherheits-Vereinigungen mit dieser entfernten Station verhandeln.
  • Ein Aspekt der vorliegenden Erfindung ist ein Verfahren für das Erlauben des Verwendens des IPSec-AH's in Situationen, in welchen ein NAT-Gateway zwischen einem Client-Computer und einem entfernten Computer angeordnet ist. Der Client-Computer fordert eine öffentliche Adresse von dem Gateway-Computer an, und in Antwort darauf wird die öffentliche Adresse dem Client-Computer bereitgestellt. Es wird eine IPSec-Sicherheits-Vereinigung mit einem entfernten Computer verhandeln. Die Sicherheits-Vereinigungsverhandlung wird durch den Gateway-Computer als ein Auslöser verwendet, um eine Verbindung zwischen der lokalen Adresse des Clients (seine MAC-Adresse im Falle einer NAT/AH-Co-Existenz, seine private IP-Adresse im Falle einer NAT/ESP-Co-Existenz) mit der IP-Adresse des entfernten Computers aufzuzeichnen, wobei die lokale Adresse und die Zieladresse von dem ersten ausgehenden Sicherheits-Vereinigungs-verhandelten Paket erhalten wird. Ein Sicherheitsparameter-Indexwert, welcher aus der Sicherheits-Vereinigungsverhandlung mit dem entfernten Computer resultiert, wird in Verbindung mit der lokalen Adresse erhalten und gespeichert, und zwar, sobald die entfernte Station damit beginnt, IPSec-geschützten Verkehr in Richtung des lokalen Clients zu senden.
  • Ein Aspekt der vorliegenden Erfindung ist eine Datenstruktur für einen Gateway-Computer. Die Datenstruktur weist ein lokales Adressfeld (Medium-Access-Control (MAC)- oder IP-Adresse), ein dem oben erwähnten lokalen Adressfeld zugeordnetes Remote-IP-Adressfeld und ein Remote-to-Local-Sicherheitsparameterindex (SPI)-Feld gemäß dem lokalen Adressfeld und dem entfernten Adressfeld auf, um insbesondere Verkehr zu identifizieren, der von der entfernten Adresse zu der lokalen Adresse fließt. Das Remote-to-Local-SPI-Feld speichert mindestens einen Sicherheitsparameterindex von einer entfernt lokalisierten Maschine.
  • Ein Aspekt der vorliegenden Erfindung ist ein Verfahren für die Internet Key Exchange-(IKE) Unterdrückung. Ein Gateway-Computer ist mit einer Zuordnungstabelle konfiguriert. Ein empfangenes Paket wird überprüft, um zu ermitteln ob es ein IKE-Paket ist. Falls es ein IKE-Paket ist, wird die Zuordnungstabelle überprüft, um zu sehen, ob die Ziel-entfernte) IP-Adresse mit einem Eintrag in der Zuordnungstabelle übereinstimmt, welche ebenfalls mit der Quell-MAC-oder IP-Adresse übereinstimmt. Zusätzlich wird der ISAKMP-"Initialisierungscookie"-Wert (64 Bits) für eine Übereinstimmung mit diesem Zuordnungstabellen-Eintrag überprüft, der eine, der mit diesem Paar von Adressen übereinstimmt, und zwar, der MAC- oder IP-Adresse des Clients und der Remote-IP-Adresse. In Antwort darauf, um einen Übereinstimmungseintrag in der Zuordnungstabelle zu finden, wird eine Überprüfung für einen Hinweis vollzogen, ob eine Sicherheitsverhandlung zwischen dem lokalen Client und der Remote-IP-Adresse in Bearbeitung oder vollständig ist. Die Übertragung des IKE-Paketes wird unterdrückt, falls es noch keinen Remote-to-Local-Sicherheitsparameterindex in der Zuordnungstabelle gibt.
  • Ein Aspekt der vorliegenden Erfindung ist in Verfahren für das Gateway-Routing. Ein Remote-to-Local-Paket wird auf einen gültigen Sicherheitsparameterindex für einen Zuordnungstabellen-Eintrag überprüft, welcher mit der Remote-IP-Adresse (die Remote-to-Local-IP-Quelladresse des Paketes) und seiner IP-Zieladresse übereinstimmt, welche die öffentliche IP-Adresse sein muss, welche die Gateway-Maschine der Maschine zugeordnet hat, welche die MAC-Adresse des lokalen Clients verwendet. Falls ein übereinstimmender Remote-to-Local-Sicherheitsparameterindex gefunden wird, welcher dieser Remote-IP-Adresse zugeordnet ist, dann wird das Paket entweder unter der Verwendung einer öffentlichen IP- Zieladresse und seiner MAC-Adresse oder seiner privaten IP-Adresse, wie durch die Inhalte dieser Reihe der Zuordnungstabelle angegeben, an den lokalen Client weitergeleitet. Wenn das private IP-Adressfeld ausgefüllt ist, sind die Inhalte des öffentlichen IP-Adress-und MAC-Adressfeldes leer.
  • Ein Aspekt der vorliegenden Erfindung ist ein Verfahren für das Verarbeiten von IPSec-AH-Paketen durch einen NAT-Gateway-Computer. Das IP-Quell-Adressfeld für ein local-to-remote-IPSec-Paket wird überprüft, um zu sehen, ob es eine private Adresse oder öffentliche Adresse enthält, welche der Station, welche die MAC-Adresse verarbeitet, die in dem MAC-Quelladressfeld des Paketes gefunden wurde, zugeordnet wurde. Falls das Gateway erkennt, dass die IP-Quelladresse des Paketes eine öffentliche Adresse ist, welche dem Gateway ebenfalls bekannt ist, welche es der Maschine, welche die gleiche MAC-Adresse wie die in MAC-Adresse in dem MAC-Quelladressfeld des Paketes aufweist zugeordnet hat, dann wird das IPSec-Paket unverändert von dem NAT-Gateway-Computer übertragen (bis auf für das Dekrementieren des TTL's und Aktualisieren der IP-Quersumme im Falle von IPv4-Paketen; IPv6-Pakete sind reichlich genug, so dass die NAT nicht erforderlich ist, deshalb gibt es keinen IPSec- versus NAT-Problem für Ipv6).
  • Das IP-Quelladressfeld für Remote-to-Local-IPSec-Pakete wird gegen die Remote-IP-Adress-Spalte der Zuordnungstabelle abgeglichen und der SPI des Paketes wird gegen den erwarteten Remote-to-Local-SPI abgeglichen, welcher in einer Zeile der Zuordnungstabelle gespeichert ist, welche dieser Remote-IP-Adresse zugeordnet ist. Falls ein übereinstimmender Zuordnungstabellen-Eintrag gefunden wird, wird das Paket zu der MAC-Adresse (oder privaten IP-Adresse) des lokalen Clients weitergeleitet, welche von der Übereinstimmungs-Zeile in der Zuordnungstabelle extrahiert wurde.
  • In der folgenden Beschreibung werden zahlreiche spezielle Details dargelegt, um ein vollständigeres Verständnis der vorliegenden Erfindung bereitzustellen. Dennoch wird es für den Fachmann offensichtlich sein, dass die vorliegende Erfindung ohne eines oder mehrere dieser speziellen Details betrieben werden kann. In anderen Fällen wurden bekannte Merkmale nicht beschrieben, um zu vermeiden, die vorliegende Erfindung unklar zu gestalten.
  • Unter Bezug auf 1 wird eine Blockdiagramm eines exemplarischen Ausführungsbeispiels eines Computersystems 10 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung gezeigt. Das Computersystem 10 weist eine CPU 11, einen Systemspeicher 13, eine Eingabe-/Ausgabe (I/O)-Schnittstelle 12 und einen NIC 100 auf. Der NIC 100 kann für I/O von/an ein Netzwerk 110 gekoppelt werden. Der NIC 100 weist einen lokalen Speicher 112 auf. Bezugnehmend auf 2 wird ein Netzwerkdiagramm einer exemplarischen Ausführungsform eines Netzwerks 110 gemäß einem oder mehreren Aspekten der vorliegenden Erfindung gezeigt. Das Netzwerk 110 weist ein Wide Area Network (WAN) 104 auf. Das WAN 104 kann das Internet, ein Unternetzwerk ("Subnet") des Internets oder anderes Wide Area Network sein. Ein oder mehrere Computersysteme 101 können von Zeit zu Zeit in das WAN 104 eingeloggt sein. Insbesondere können ein oder mehrere Computersysteme 101 Server sein. Zusätzlich sind DHCP-Server/NAT-Gateways ("Gateways") 106 und 107 jeweils mit den LAN's 102 und 103 gekoppelt. Client-Computer 106-A, 106-B und 106-C können in Kommunikation mit dem Gateway 106 via des LAN's 102 gesetzt werden. Gleichermaßen können die Client-Computer 107-A, 107-B und 107-C in Kommunikation mit dem Gateway 107 via des LAN's 103 gesetzt werden. Die NAT-Gateways 106 und 107 können via eines Routers 108 mit dem WAN 104 gekoppelt sein. Alternativ können die Gateways 106 und 107 Gateway-Router sein, und zwar, eine Kombination eines NAT- Gateways und eines Routers; sogar die DHCP-Server-Funktion kann in die vereinheitlichte Vorrichtung eingegliedert sein.
  • Das Netzwerk 110 ist lediglich ein exemplarisches Ausführungsbeispiel und weniger oder mehr Computer, Gateways, LAN's oder WAN's und Kombinationen hiervon können verwendet werden. Ferner können die Client-Computer 106-A, 106-B und 106-C wie das Computersystem 10 der 1 konfiguriert sein in sofern jeder einen NIC 100 mit einem lokalen Speicher 112 aufweist. Zum Zweck der Klarheit, obwohl andere Zusammenstellungen als die Beschriebenen verwendet werden können, dient der Rest dieser Beschreibung für einen Client-Computer 106-A hinter einem DHCP-/NAT-Gateway 106, welches mittels eines Routers 108 für die Kommunikation mit einem entfernten Server 101 mit dem Internet 104 gekoppelt ist. Ein herkömmliches Beispiel solch eines Netzwerkes können Arbeiter in einem Small Office/Home Office (SOHO) Netzwerk sein, welche über das Internet mit einem Server des Unternehmens verbunden sind. Zum Zweck der Klarheit, bezieht sich eine lokale Adresse auf eine zugeordnete Adresse durch das Gateway und eine nicht lokale Adresse bezieht sich auf alle anderen Adressen.
  • Bezugnehmend auf 3 wird ein Flussdiagramm eines exemplarischen Ausführungsbeispiels eines Teils eines IPSec-/NAT-Integrationsprozesses 200 gemäß einem oder mehrerer Aspekte der vorliegenden Erfindung gezeigt. Der Integrationsprozess 200 weist einen IPSec-/NAT-Client-seitigen Integrationsprozess 299 und einen IPSec-/NAT-Gateway-seitigen Integrationsprozess 298 auf. Bezugnehmend auf 3 und nochmaligen Bezug auf 1 und 2 ist der Integrationsprozess 200 beschrieben.
  • Bei Schritt 201 fordert ein Client-Computer, wie beispielsweise der Client-Computer (oder "Client") 106-A eine IP-Adresse von einem Gateway, wie beispielsweise dem Gateway 106, an. Solch eine Anforderung bei Schritt 201 kann durch eine Software, welche in den Client-Computer 106-A programmiert ist, vollzogen werden, und kann insbesondere ein Teil eines Treibers für eine Netzwerkschnittstelle, wie beispielsweise eine "Netzwerk-Schnittstellen-Karte" oder "NIC" 100, oder kann ein Teil der Hardware oder Firmware solch eines NIC sein, welcher den Programmcode 299, welcher in dem lokalen Speicher 112 gespeichert ist, aufweist, aber nicht darauf beschränkt ist.
  • Falls der Client 106-A eine private IP-Adresse empfängt, dann weiß der Client 106-A, dass ein NAT-Gateway als Client 106-A verwendet wurde, da er die Fähigkeit hat, Verkehr außerhalb einer Privat-Adress-Domain zu senden. Da die Liste von privaten IP-Adressen bekannt ist, kann der Client 106-A testen, um zu bestimmen, ob ihm eine Private IP-Adresse zugeordnet wurde. In Schritt 202 überträgt der Client 106-A eine andere Anforderung für eine IP-Adresse, diesmal durch das Invertieren des lokalen Bits in seinem DHCP-Client-Bezeichner (auch bekannt als seine MAC-Adresse). Wie bekannt ist, ist jedem Computer in einem LAN, aufweisend sowohl Gateways als auch Clients, eine eindeutige Nummer hinsichtlich solch eines LAN's zugeordnet, und zwar, eine MAC-Adresse. Eine herkömmliche MAC-Adresse ist eine 48-Bit-Nummer, welche in zwei 24-Bit-Segmente unterteilt ist, welche als Organizationally Unique Identifier (OUI) und Manufacturer's Unique Identifier bekannt sind. Das erste Byte eines OUI weist ein geringst-signifikantes Bit (LSB) auf, welches ein Multicast-Bit ist. Das bei dem geringst-signifikanten benachbarte Bit in den am meisten signifikanten Bytes ist das lokale Bit.
  • Beispielsweise ordnet einen DHCP-Prozess auf dem NAT-Gateway 106 dem Client-Computer 106-A, welcher in das LAN eingeloggt ist, wie beispielsweise dem LAN 102, eine private IP-Adresse bei Schritt 251 in Antwort auf eine erste DHCP-Anforderung mit einem ersten Client-Bezeichner von Schritt 201 zu, dann kann eine zweite DHCP-Anforderung bei Schritt 202 zu dem NAT Gateway 106 mit einem unterschiedlichen Client-Bezeichner von dem Client-Computer 106-A (welcher in das LAN 102 eingeloggt ist) durchgeführt werden. Es ist wichtig, dass dieser zweite Client-Bezeichner von dem zugehörigen ersten Client-Bezeichner abgeleitet wird. Also, falls das Gateway 106 IPSec über NAT unterstützt, wie durch eine implizierte Überprüfung bei Schritt 252 angegeben, kann es unterscheiden, dass zwei MAC-Adressen von der gleichen Anforderungs-Station sind. Ein NAT-Gateway, welches derart konfiguriert ist, um AH-IPSec zu unterstützen, wird diese Unterscheidung vollziehen und deshalb keine zweite private IP-Adresse senden, wird aber stattdessen eine öffentliche IP-Adresse bei Schritt 255 senden. Falls jedoch solch ein NAT-Gateway AH-IPSec nicht unterstützt, dann wird ein DHCP-Server eine zweite private IP-Adresse bei Schritt 253 zuordnen, da es zwischen diesen beiden MAC-Adressen keinerlei Beziehung zuordnet, welche lediglich in ihren entsprechenden lokalen Bit-Werten abweichen.
  • Falls das Gateway 106 derart konfiguriert ist, um AH-IPSec mit NAT auszuführen, kann das Gateway 106 bei Schritt 254 eine MAC-Adresse für den Client-Computer 106-A in einer Zuordnungstabelle aufzeichnen, um dafür geeignet zu sein, Gateway 106-Pakete mit einer öffentlichen IP-Quelladresse zu senden. Alternativ kann das Gateway 106 auf einen IKE warten, wie folgend im Detail beschrieben.
  • Basierend auf einer Zuordnung von einer privaten IP-Adresse nach Schritt 201 kann der Client 106-A bereits die Anwesenheit eines NAT-Gateways 106 ableiten. Die Zuordnung einer zweiten privaten IP-Adresse deutet dem Client 106-A bei Schritt 204 an, dass das NAT 106 Gateway AH-IPSec nicht unterstützt. Falls der Client 106-A dennoch eine nicht private (d. h. öffentliche) IP-Adresse in Antwort auf eine DHCP-Anforderung von Schritt 202 empfängt, dann weiß der Client 106-A in Antwort darauf bei Schritt 206, dass das NAT-Gateway 106 AH-IPSec unterstützt, und zeichnet eine öffentliche IP-Adresse in Zusammenhang mit einer MAC-Adresse bei Schritt 206 auf, wie nachfolgend im Detail beschrieben wird. Darüber hinaus kann, falls das NAT-Gateway 106 AH-IPSec unterstützt, der Client 106-A dann nacheinander AH und/oder ESP unter der Verwendung von IKE übertragen, welche Fähigkeit wie bei Schritt 207 angedeutet wurde, vermerkt oder aufgezeichnet werden. Dahingehend ist der Client 106-A darauf beschränkt, ESP wirklich mit IKE zu verhandeln, falls er detektiert hat, dass das NAT-Gateway 106 AH-IPSec nicht unterstützt.
  • Ein DHCP-Server in dem NAT-Gateway 106 ist konfiguriert, um zwei MAC-Adressen als zu dem gleichen Client-Computer 106-A korrespondierend zu korrellieren, wenn ein Client-Bezeichner, welcher in einer originalen DHCP-Anforderung geliefert wurde, von dem folgenden DHCP-Client-Bezeichner lediglich dahingehend abweicht, dass er ein invertiertes lokales Bit aufweist. Mit anderen Worten, außer für das lokale Bit ist jeder DHCP-Client-Bezeichner ansonsten identisch. Solch ein DHCP-Server ist in Antwort auf zwei MAC-Adressen programmiert, welche in der Zuordnungstabelle gespeichert sind und sich nur durch das lokale Bit unterscheiden, um eine (eine von) öffentliche(n) Adresse(n) zu übertragen, welche für das Gateway 106 bis zu dem Client-Computer 106-A verfügbar sind, wobei solch eine öffentliche IP-Adresse für eine AH- oder ESP mit AH-IPSec-Session verwendet werden kann, wie nachfolgend im Detail beschrieben wird.
  • Falls dennoch der DHCP-Server das Korrelieren von zwei DHCP-Anforderungen von dem gleichen Client-Computer 106-A, wie beschrieben, nicht unterstützt, wobei sich die Client-Bezeichner nur in dem lokalen Bit-Wert unterscheiden, dann wird eine zweite private IP-Adresse an einen anfordernden Client-Computer 106-A gesendet. Falls ein Client-Computer 106-A eine zweite private Adresse empfängt, wird er DHCP verwenden, um eine der privaten IP-Adressen bei Schritt 204 zurück in den Pool von privaten Adressen zu leiten, so dass diese einer anderen lokalen Station zugeordnet werden kann. Falls eine zweite private IP-Adresse von einem DHCP-Server gesendet wurde, dann informiert dies den Client-Computer 106-A entsprechend darüber, dass NAT verwendet wurde, und dass keine öffentliche IP-Adress-Zuordnungsfähigkeit bereitgestellt wird. In einer anderen Art und Weise dargestellt unterstützt das Gateway 106 NAT, aber es unterstützt nicht AH-IPSec und NAT gemäß den hierin definierten Algorithmen. Also ermittelt der Client-Computer bei Schritt 205, dass er aus Gründen, welche nachfolgend im Detail beschreiben werden, nur IKE-Verhandlungen ESP-basierter Sicherheits-Vereinigungen sicher unterstützen kann.
  • Insbesondere wird eine öffentliche IP-Adresse gemäß einem oder mehreren Aspekten der vorliegenden Erfindung für nur-ESP-IPSec nicht benötigt. Dennoch gibt es herkömmlicherweise kein a-priori-Wissen darüber, ob nur-AH-, nur-ESP- oder ESP-mit-AH-IPSec als ein Ergebnis einer IKE-Verhandlung verwendet wird. Entsprechend fordert der Prozess 200 im Voraus eine öffentliche IP-Adresse nur in dem Fall an, in dem nur-AH- oder ESP-mit-AH-IPSec auf einen IKE vereinbart werden können. Falls verfügbar, wird eine öffentliche IP-Quelladresse verwendet, um dem Gateway 106 anzuzeigen, dass die IPSec-Kommunikation durchgeführt wurde. Das Gateway 106 kann auch einen Schlüssel enthalten, dass die IPSec-Kommunikation durchgeführt wurde durch Beobachten, dass der Client 106-A einen DHCP-Client-Bezeichner mit einem umgedrehten lokalen Bit gesendet hat, um eine öffentliche IP-Adresse anzufordern (und dass eine durch das Gateway 106 zugeordnet wurde), und auch basierend auf einer Initialisierung eines IKE-Austausches von dem Client 106-A. Darüber hinaus wird, da eine öffentliche IP-Quelladresse, wie sie hierin beschrieben wurde, mit ESP-nur-IPSec-, genauso wie mit nur-AH- oder ESP-mit-AH-IPSec-Verkehr funktionieren wird, die Wahrscheinlichkeit eines erfolgreichen IPSec-Ablaufes durch das Verwenden einer öffentlichen IP-Quelladresse, so oft sie für den IKE- und jeden anderen IPSec-Verkehr verfügbar ist, verbessert.
  • Bei Schritt 210 initialisiert der Client-Computer 106-A eine IKE-Verhandlung. Eine IKE-Verhandlung fährt in einer herkömmlichen Art und Weise fort, wobei ein Protokoll-Stapel mit einer privaten IP-Adresse startet und ein IKE-Initialisierungs-Paket erzeugt. Insbesondere für eine IKE-Verhandlung kann eine private IP-Adresse als eine IP-Quelladresse verwendet werden, da IKE ein "NAT-sicheres" Protokoll ist. Der Client 106-A kann auswählen, eine öffentliche Adresse als eine IP-Quelladresse zu verwenden, wenn er eine IKE-Verhandlung initialisiert, falls solch eine öffentliche IP-Adresse verfügbar ist.
  • Alternativ kann der Client-Computer 106-A eher mit einem IKE starten, als eine öffentliche Adresse zu erhalten. Falls das Gateway 106 dennoch nicht konfiguriert wurde, um eine öffentliche IP-Adresse bereit zu stellen (oder nicht fähig war für solch eine Aktion), dann würde dies nicht entdeckt werden bis nachdem eine IKE-Verhandlung vervollständigt ist, was eine Übereinkunft einschließen würde, nur-AH oder ESP-mit-AH zu verwenden, was mit solch einem Gateway 106 inkompatibel wäre. Entsprechend müsste dann ein neuer IKE stattfinden. Der Client-Computer 106-A kann Pakete bilden, welche eine öffentliche Adresse als ihre IP-Quelladresse aufweisen, welche entweder die eigene öffentliche Adresse des Gateways oder eine Adresse ist, die aus einem Pool von öffentlichen Adressen ausgewählt wird, welche das Gateway 106 verwaltet. Der Client-Computer 106-A kann Pakete bilden, welche eine private IP-Quelladresse aufweisen. Mit anderen Worten, kann der Client-Computer 106-A konfiguriert werden, um zwischen einer privaten IP-Adresse und eine öffentlichen IP-Adresse auszuwählen, wobei diese Auswahl in einem Fall im Kontext der Verfügbarkeit vorrausgesetzt ist und, falls verfügbar, ob in einem anderen Fall ein IPSec-Protokoll verwendet werden soll. Sobald eine öffentliche Adresse erhalten wird, kann das Ausbilden eines Paketes mit solch einer öffentlichen Adresse als eine Quelladresse in einer herkömmlichen Weise durchgeführt werden. Im letzteren Kontext, wobei AH-IPSec-NAT erlaubt ist, kann sowohl der IPSec-geschützte und nicht-IPSec-geschützte Verkehr fließen. Als Erinnerung, kann nicht-IPSec-geschützter Verkehr herkömmliches NAT verwenden. Außerdem, innerhalb einer privaten Domain, wie beispielsweise in einem LAN kann der Client 106-A in eine IPSec-geschützte Kommunikation mit einem anderen lokalen Client eingreifen oder nicht. In solch einem Fall der Intra-Domain-Kommunikation mit IPSec, obwohl sogar IPSec verwendet wird, gibt es keinen Bedarf für das Verwenden einer öffentlichen IP-Adresse, da die IP-Zieladressierung sich innerhalb der gleichen privaten Adress-Domain wie die des Client-Computers 106-A befindet. Deshalb, kann ein Benutzer des Clients 106-A ermitteln, ob er oder ob er nicht mit einer Peer-Station mit IPSec oder nicht kommunizieren möchte, und kann ermitteln, ob solch eine Peer-Station eine interne Station ist, d. h., eine lokale Domain-Adresse hat, zu der privaten Adress-Domain des Client-Computers 106-A für solch eine Kommunikation oder nicht.
  • In Antwort auf die Initialisierung eines IKE bei Schritt 210 durch den Client-Computer, kann das Gateway 106 eine Quittung für ein IKE-Initialisierungs-Paket verwenden, um bei Schritt 260 eine MAC-Adresse für solch einen Client-Computer und eine Ziel-IP-Adresse für solch ein IKE-Initialisierungs-Paket aufzuzeichnen. Das NAT-Gateway 106 kann durch das Überprüfen, dass das Paket ein UDP-Paket mit einem Quell-Port und einem Ziel-Port ist, beide gleich 500, ermitteln, dass das Paket ein IKE-Paket ist. Ein Bit, und zwar ein anhängiges Bit, kann bei Schritt 260 gesetzt werden, um zu indizieren, dass herausgehender Verkehr für ein IKE mit dieser MAC-Adresse gesendet wurde. Diese Ziel-IP-Adresse des IKE-Paketes ist für eine entfernte Maschine, wie beispielsweise einem entfernten Server, wie oben erwähnt wurde. Das Gateway 106 nimmt wie auch immer nicht direkt an einer IKE-Verhandlung teil, anders als die mögliche NAT-Übersetzung von IKE-Paketen, und nur dann, falls der Client 106-A eine private IP-Adresse, wie beispielsweise die Quelladresse eines IKE-Paketes verwendet. Beachte, dass ein NAT-Gateway, welches IPSec unterstützt, eine IKE-Unterdrückung unterstützen muss, mit einbeziehend, dass nur eine IKE-Verhandlung zu irgendeiner gegebenen Zeit aktuell sein kann, so dass keine Port-Übersetzung notwendig ist, wenn Netzwerkadressen IKE-Pakete übersetzen, da eine IP-Adress-Übersetzung alleine ausreichend ist.
  • Bezugnehmend auf 5A und 5B wird ein exemplarisches Ausführungsbeispiel einer IPSec Allocating Mapping Table (IPSAMT) 300 zu unterschiedlichen Zeiten gemäß einem oder mehreren Aspekten der vorliegenden Erfindung gezeigt. Die IPSAMT 300 weist eine Zeile für jedes initialisierte IKE und Spalten für entsprechende Felder für eine Zeitmarke 305, ein ISAKMP-Initialisierungscookie 307, einen IPSec-Protokoll-Bezeichner, eine lokale Client-MAC-Adresse 301, eine lokale Client-Public-IP-Adresse 309, eine lokale Client-Private-IP-Adresse 306, einen Remote-to-Local-Sicherheitsparameterindex 302, ein anhängiges Bit 303 und eine Remote-IP-Adresse 304 auf.
  • Das Zeitmarkenfeld 305 wird abhängig von dem Status des anhängigen Bit-Feldes 303 interpretiert. Falls das anhängige Bit-Feld 303 gesetzt ist, wird das Zeitmarkenfeld 305 mit der Zeit des letzten IKE-Paketes zwischen einer Adresse in dem Remote-IP-Adressfeld 304 und einer zugehörigen Adresse in dem lokalen Client-MAC-Adressfeld 301 bestückt. Falls der Status des anhängigen Bit-Feldes 303 klar ist, dann weist das Zeitmarkenfeld 305 die Zeit auf, zu der das letzte IPSec-geschützte Paket von einer Remote-IP-Adresse empfangen wurde, welche mit einer Adresse in dem Remote-IP-Adressfeld 304 in einer Zeile der Zuordnungstabelle 300 übereinstimmt. Falls die Übereinstimmungstabelle 300 voll wird, werden Zeilen, die als längstes ungenutzt waren, als erstes unter der Verwendung von Information von dem Zeitmarkenfeld 305 gelöscht.
  • Das IPSec-Protokollfeld 308 kann als ein 2-Bit-Feld codiert sein, wobei ein Bitmuster von 00 ein ungültiges Muster indiziert, wohingegen 10 ein AH indiziert, 01 ein ESP indiziert und 11 ein ESP mit AH indiziert; dennoch sollte verstanden werden, dass andere Codierungen möglich sind. Das Remote-to-Local-Sicherheitsparameter-Indexfeld 302 ist für das Speichern eines Sicherheitsparameter-Indexwertes gemäß dem Verkehr von einer Adresse in dem Remote-IP-Adressfeld 304, welcher an einen bestimmten lokalen Client adressiert ist, identifiziert durch seine MAC-Adresse und öffentliche oder private IP-Adresse.
  • Weiter bezugnehmend auf 5A und 5B und nochmaligem Bezug auf die 1, 2 und 3, nachdem das NAT-Gateway 106 eine MAC-Adresse für den Client-Computer 106-A in einer Zuordnungstabelle aufzeichnet, um mit einer ersten Remote-IP-Adresse überein zu stimmen, welche in dieser Zuordnungstabelle aufgezeichnet ist, kann die "IKE-Unterdrückung" verwendet werden, um sicher zu stellen, dass nur ein IKE-Austausch zu einem Zeitpunkt zwischen einer lokalen Client-Maschine und einer Remote-IP-Adresse stattfindet. Da nur eine IKE-Verhandlung zu einem gegebenen Zeitpunkt zwischen einem lokalen Client und einer Remote-IP-Adresse aussteht, kann es zu einem gegebenen Zeitpunkt nur einen unvollständigen, fehlenden Index-Eintrag der Sicherheitsparameter für eine Zeile in solch einer Zuordnungstabelle geben. Falls mehrere lokale Maschinen unter Verwendung von IPSec für einen Zugang zur gleichen Remote-IP-Adresse adressiert sind, werden IKE-Verhandlungen auf der Basis von first-come, first-served verarbeitet. Sobald die früheste IKE-Verhandlung vollständig ist, und zwar, sobald ein neuer Eingangs-Sicherheitsparameterindex von dieser Remote-IP-Adresse aufgezeichnet wird, dann wird einer anderen IKE-Verhandlung erlaubt zu starten. Insbesondere das Gateway 106 empfängt ein Paket, welches zu einer seiner öffentlichen IP-Adressen von einer Remote-IP-Adresse adressiert sind, welche 1) das anhängige Bit 303 aufweist, welches in einer Zeile solch einer Zuordnungstabelle gesetzt ist und 2) keinen Sicherheitsparameterindexeintrag in dieser Zeile solche einer Zuordnungstabelle aufweist. Das Gateway 106 zeichnet diesen Sicherheitsparameterindex des Paketes in dieser leeren Lücke in dieser Zeile solch einer Zuordnungstabelle auf, wie beispielsweise IPSAMT 300, und leitet dieses Paket an eine Client-Adresse weiter, welche von derselben Zeile solch einer Zuordnungstabelle genommen wird.
  • Insbesondere weisen AH und ESP entsprechende Sicherheitsparameterindex-Typen auf, und sowohl die Eingangs- und Ausgangs-Sicherheitsparameterindex-Typen existieren. Also kann eine Zuordnungstabelle eine Spalte für AH- oder ESP-Verkehr aufweisen, wobei AH den ESP mit AH aufweist. Dennoch werden Zeilen in einer Zuordnungstabelle durch das Beobachten von IKE-Austauschen zwischen einer lokalen Maschine und einer entfernten Maschine, welche einer Remote-IP-Adresse zugeordnet sind, hinzugefügt.
  • Eine Zuordnungstabelle, welche eine Remote-IP-Adresse eines IKE-Peers und eine MAC-Adresse eines lokalen Clients aufweist, welcher in einer IKE-Konversation mit solche einem IKE-Peer beschäftigt ist, wird dazu verwendet, um einen Sicherheitsparameterindex von solch einem IKE-Peer zu speichern. Insbesondere nachdem eine IKE-Verhandlung vollständig ist, kann solch ein Sicherheitsparameterindex nicht zu solch einer Zuordnungstabelle hinzugefügt werden, bis nachdem IPSec-geschützter Verkehr tatsächlich von einer entfernten Maschine für solch eine Remote-IP-Adresse zu dem NAT-Gateway 106 fließt. Der Sicherheitsparameterindex ist während eines IKE's verschlüsselt und erscheint nur unverschlüsselt oder "im Klartext", wenn reale Daten für solche eine IPSec-Session gesendet werden, und zwar, nachdem eine IKE-Session erfolgreich vervollständigt ist.
  • Zusätzlich zu den oben erwähnten Gründen hinsichtlich der Verbindung zwischen Sicherheitsparameterindizes von einer entfernten Adresse, da die Sicherheitsparameterindizes während eines IKE's verschlüsselt werden und nur im Klartext erscheinen, sobald real verschlüsselte Daten anfangen zu fließen, kann nur ein offener Remote-to-Local-Sicherheitsparamter-Indexeintrag zu der gleichen Ziel-IP- Adresse zu einem Zeitpunkt in einer Zuordnungstabelle erlaubt sein, bis tatsächlich Daten als ein Teil der IKE-Unterdrückung beginnen zu fließen. Mehrere IKE-Sessions können durch das Gateway 106 solange, wie jeder aktive Client mit einer unterschiedlichen Remote-IP-Adresse überträgt, stattfinden. Sobald ein Sicherheitsparameterindex für ein erfolgreich übertragenes IKE für eine Remote-IP-Adresse erhalten wird, kann eine weitere IKE-Session für die gleiche Remote-IP-Adresse initialisiert werden.
  • Entsprechend sollte verstanden werden, dass es viele Modi der Kommunikation gibt. Falls der Client 106-A eine öffentliche IP-Adresse als eine Quelladresse verwendet hat, wenn er seinen IKE- oder IPSec-geschützten Verkehr sendet, dann wird der zurückkommende Verkehr unter der Verwendung einer Zuordnungstabelle mit einem Sicherheitsparameterindex verglichen, wenn verfügbar, mit solch einer MAC-Adresse des Clients, und sobald solch ein Sicherheitsparameterindex verfügbar ist, wird der zurückkommende Verkehr unter Verwendung einer Zuordnungstabelle mit einer Remote-IP-Adresse verglichen, welche ein offenes anhängiges Bit zu einer MAC-Adresse eines Clients aufweist.
  • Falls der Client 106-A bei dem Senden seines nur ESP-IPSec-Verkehrs eine private IP-Adresse verwendet hat, welcher Verkehr anschließend Netzwerk-Adress-übersetzt wird, dann wird für hereinkommenden Verkehr die NAT-IP-Adress-Übersetzung durch eine Verbindung der privaten IP-Adresse eines Clients und einer entfernten IP-Adresse durchgeführt (d. h., eine Quelladresse für hereinkommenden Verkehr), wie in einer Zuordnungstabelle gespeichert, und die Port-Adress-Übersetzung wird unter Verwendung einer Zuordnungstabelle mit einem Sicherheitsparameterindex verglichen, wenn verfügbar, mit solch einer privaten IP-Adresse eines Clients. Falls ein Sicherheitsparameterindex für solch eine entfernte IP-Adresse nicht verfügbar ist, dann wird die private IP-Adresse des Clients, welche ein offenes anhängiges Bit in Verbindung mit solch einer entfernten IP-Adresse aufweist, verwendet. Das Gateway 106 kann nicht in einer expliziten Art und Weise ermitteln, ob eine ISAKMP-Verhandlung, welche durch einen lokalen Client 106-A initialisiert wurde, erfolgreich vervollständigt wurde. Es gibt dennoch zwei implizierte Schlüssel, welche dazu verwendet werden können, um zu verhindern, dass ein unnötig abhängiger Status in der Zuordnungstabelle beibehalten wird. Falls ein lokaler Client einen ISAKMP-Main-Mode-Exchange initialisiert, sollte auf solch einen Main-Mode-Exchange unmittelbar ein Quick-Mode-Exchange folgen. Falls mehr als 5 Sekunden verstreichen, ohne dass Quick-Mode-Pakete gesehen werden, dann muss diese Verhandlung fehlgeschlagen sein, und eine Zeile, welche in Antwort auf solch einen ISAKMP-Main-Mode-Exchange erzeugt wurde, kann von solch einer Zuordnungstabelle entfernt werden. Alternativ ist es möglich, dass ein lokaler Client einen Agressive Mode Exchange initialisiert hat, welcher immer drei Pakete beansprucht. Falls zwei Pakete gesehen werden und dann 5 Sekunden vergehen, ohne dass das dritte Paket gesehen wird, muss solch eine Verhandlung fehlgeschlagen sein, und eine Zeile, welche in Antwort auf solch einen ISAKMP Agressive Mode Exchange erzeugt wurde, kann von solch einer Zuordnungstabelle entfernt werden. Entsprechend kann eine zugeordnete Zeitmarke mit einem ISAKMP-Initialisierungscookie in einer Zuordnungstabelle verwendet werden, um zu ermitteln, ob solch eine zeitliche Begrenzung abgelaufen ist.
  • Entsprechend sollte abgeschätzt werden, dass kein spezieller oder modifizierter VPN benötigt wird, um mehrere VPN-Verbindungen zum selben Zeitpunkt aufrecht zu erhalten, da ein Sicherheitsparameterindex und nicht eine Port-Nummer für das Zurückübersetzen verwendet wird. Also müsste kein TCP- oder UDP-Header für eine Zurückübersetzung zugänglich sein, wie hierin beschrieben wurde. Darüber hinaus, da ein Sicherheitsparameterindex ein festgelegtes Offset ist, wird der Zugang zu ihm in einem Paket für das Verwenden als ein Hinweis auf eine Zuordnungstabelle ermöglicht. Anstatt des Modifizierens des NICs eines lokalen Clients mittels eines Programm-Produkt-Treibers, welcher konfiguriert ist, um eine zweite DHCP-Anforderung durchzuführen, um eine öffentliche IP-Adresse zu erhalten, wird alternativ, falls nur ESP-VPN's verwendet werden, dann das Gateway 106 mit einer Zuordnungstabelle konfiguriert, wobei der Client 106-A nicht konfiguriert zu werden braucht, da der IKE und der nur ESP-IPSec NAT-kompatibel sind.
  • Die IKE-Unterdrückung wird nicht für Clients verwendet, welche unter Verwendung von nur ESP-IPSec mit einer Anzahl von eindeutigen Remote-IP-Adressen kommunizieren. Die IKE-Unterdrückung wird dazu verwendet, um mehrere lokale Maschinen, welche mit der gleichen Remote-IP-Adresse kommunizieren, zu unterstützen. Dennoch ist die Fähigkeit von Viel-zu-Eins-Abbilden für Remote-to-Local-Maschinen für VPN-Sessions ohne das Modifizieren zu einem VPN ein substantieller Vorteil. Ein Beispiel hierfür sind Telearbeiter für ein Unternehmen, welche alle mit dem gleichen Server solch eines Unternehmens kommunizieren möchten.
  • Durch das Einschließen des Erhaltens einer öffentlichen IP-Adresse bei einer Netzwerk-Schnittstellen-Ebene wird keine Einbindung eines ausführenden Systems (OS) benötigt. Mit anderen Worten wird ein IKE bei einer OS-Ebene initialisiert, und in Antwort auf solch eine Initialisierung fordert der NIC 100 automatisch eine öffentliche IP-Adresse an. Diese Anforderung benötigt anders als bei der IKE-Initialisierung keine Aktion des OS. Darüber hinaus ist der NIC 100 für IPSec konfiguriert, so dass eine öffentliche Adresse, falls diese erhalten wurde, automatisch für IPSec-Pakete verwendet werden kann. Zusätzlich können bekannte Protokolle, welche durch Clients und Gateways unterstützt werden ohne das Einführen irgendeines zusätzlichen Signal-Kanals verwendet werden.
  • In Bezugnahme auf 3A wird ein Flussdiagramm eines exemplarischen Ausführungsbeispiels eines IPSec/NAT Gateway- seitigen Integrations-Unter-Prozesses 298 mit IKE-Unterdrückung gemäß einem oder mehreren Aspekten der vorliegenden Erfindung gezeigt. Bei Schritt 217 empfängt das NAT-Gateway 106 ein Paket. Dieses Paket kann ein IKE-Initialisierungs-Paket von Schritt 210 in 3 sein. Bei Schritt 218 überprüft das NAT-Gateway 106 solch ein Paket, um zu ermitteln, ob es ein IKE-Paket ist.
  • Mit weiterem Bezug auf 3A und nochmaligem Bezug auf die 1, 2, 5A und 5B. Falls bei Schritt 218 ein empfangenes Paket kein IKE-Paket ist, dann wird bei Schritt 219 eine Überprüfung durchgeführt, um zu ermitteln, ob das Paket eine öffentliche oder eine private IP-Adresse als eine Quell-IP-Adresse aufweist. Es sollte verstanden werden, dass das NAT-Gateway 106 IPSec und Nicht-IPSec-Pakete empfangen kann, jedoch Client-Computer, wie beispielsweise Client-Computer 106-A bis -C in einem LAN 102, eine öffentliche IP-Adresse als eine IP-Quelladresse zu dem NAT-Gateway 106 nur für Kommunikationen in Bezug auf eine IPSec-Session senden. Insbesondere macht es nichts aus, falls nur-ESP-IPSec ausgehandelt ist, da eine öffentliche IP-Adresse als eine IP-Quelladresse für nur-ESP-Verkehr durch das NAT-Gateway 106 verwendet werden kann. Falls beim Schritt 219 eine Quell-IP-Adresse eine öffentliche IP-Adresse ist, die für das NAT-Gateway 106 verfügbar ist, dann zeigt das dem NAT-Gateway 106 an, so ein empfangenes Paket für eine IPSec-Session zu verarbeiten. Daher wird, falls ein Paket mit einer öffentlichen IP-Quelladresse beim Schritt 219 gefunden wird, es ohne NAT beim Schritt 256 verarbeitet. In anderen Worten, der NAT-Gateway 106 übermittelt so ein Paket mit so einer öffentlichen IP-Adresse als eine Quell-IP-Adresse ohne irgendeine NAT auf diesem Paket. Falls ein Paket mit einer privaten IP-Quelladresse beim Schritt 219 gefunden wird, wird es mit dem NAT beim Schritt 257 verarbeitet. In anderen Worten, das NAT-Gateway 106 ersetzt vor dem Übermitteln dieses Pakets auf das WAN 104 eine öffentliche IP-Adresse durch so eine private IP-Quelladresse.
  • Falls beim Schritt 218 ein empfangenes Paket ein IKE-Paket ist, dann wird beim Schritt 221 eine Überprüfung zum Bestimmen durchgeführt, ob eine Ziel-IP-Adresse für so ein Paket als Teil eines IKE-Unterdrückungs-Unterprogramms 297 in einer Zuordnungstabelle ist. Mittels der IKE-Steuerung oder -Unterdrückung sollte verstanden werden, dass ein IKE-unterdrücktes Paket nicht von dem Gateway 106 übertragen werden würde, bis ein Remote-to-Local-SPI aufgezeichnet wird und das Pending-Bit umgedreht wird, wie unten detaillierter beschrieben ist. In anderen Worten, nur eine IKE-"Unterhaltung" kann zwischen einer vorgegebenen MAC-Adresse eines lokalen Clients und einer vorgegebenen Remote-IP-Adresse stattfinden.
  • Durch Annahme wird IKE-Verkehr immer durch einen lokalen Client, wie Client 106-A, initialisiert, da der NAT jeden externen Verkehr dazu zwingt, durch lokale Clients initialisiert zu werden. Das macht intuitiv Sinn, da eine öffentliche Adresse durch eine private Adresse ersetzt werden muss, und daher Verkehr nur anfänglich in eine Richtung durch einen NAT fliessen kann – von einer lokalen (privaten) Seite zu einer entfernten (öffentlichen) Seite. Die anfänglichen IKE-"Hauptmodus"-Transaktionen des Clients 106-A und seine folgenden IKE-"Schnellmodus"-Transaktionen (oder alternativ zu Haupt- plus Schnell- kann der Client "Agressiv-Modus"-Transaktionen wählen) verwenden dasselbe Client-ausgewählte 64-Bit-Initialisierungscookie in einem ISAKMP-Header. Nachfolgendes Wieder-Verschlüsseln wird nach Ermessen des lokalen Clients 106-A ausgeführt, was entweder weitere Schnellmodus-Transaktionen oder einen neuen Hauptmodus-Austausch aufweisen kann (was den Client veranlasst, ein neues Initialisierungscookie auszuwählen, was bewirkt, dass eine neue Zeile im IPSAMT 300 erzeugt wird, wobei die Zeile anfänglich durch die IP- oder MAC-Adresse des lokalen Clients, die Remote-IP-Adresse und den Initialisierungscookie des Clients definiert ist).
  • Falls beim Schritt 221 keine solche Ziel-IP-Adresse im IPSAMT 300 auftaucht, dann wird beim Schritt 222 eine Zeile im IPSAMT 300 erzeugt und beim Schritt 260 werden eine MAC-Adresse für den Client-Computer 106-A und eine Ziel-IP-Adresse für ein entferntes Computersystem 101 zusammen gespeichert, und ein Pending-Bit für so eine Zeile wird gesetzt, zum Beispiel auf Eins (1) gesetzt, in so einer Zuordnungstabelle, die anzeigt, dass ein Remote-to-Local-Sicherheitsparameterindex, der der Remote-IP-Adresse zugeordnet ist (der ursprünglichen IP-Zieladresse, die in dem IKE-Paket des lokalen Clients gefunden wurde), noch nicht beobachtet wurde. NAT-Verarbeitung wird dann beim Schritt 257 ausgeführt, da IKE-Pakete mit NAT kompatibel sind.
  • Falls beim Schritt 221 schon eine Ziel-IP-Adresse für ein empfangenes Paket im IPSAMT 300 existiert, dann wird eine Überprüfung eines ISAKMP-"Initialisierungscookies" auf ein Anzeichen ausgeführt, dass eine Sicherheitsverhandlung zwischen einer MAC-Adresse eines lokalen Clients oder einer privaten IP-Adresse und einer Remote-IP-Adresse im Gange ist. Herkömmlicherweise ist ein ISAKMP-Initialisierungscookie eine 64-Bit-Binärzahl, obwohl zukünftige Überarbeitungen des ISAKMP-Standards die Größe dieses Feldes ändern können, zufällig von einer Client-Maschine ausgewählt, das alle nachfolgenden ISAKMP-Unterhaltungen zwischen so einem Client und seinem ISAKMP-Peer eindeutig identifiziert. Dieses Cookie ist kein Web-Cookie, das herkömmlicherweise eine kleine Textdatei ist, die ein Web-Server mittels eines Web-Browsers auf einem Client-Computer speichert. Der Gebrauch dieses Feldes erlaubt, dass mehrere ISAKMP-Verhandlungen korreliert werden. Falls beim Schritt 221 kein solches Initialisierungscookie in so einer Zuordnungstabelle auftaucht, dann wird beim Schritt 222 eine Zeile im IPSAMT 300 erzeugt.
  • Falls beim Schritt 221 ein ISAKMP-Initialisierungscookie in einer Zuordnungstabelle mit einem empfangenen ISAKMP-Cookie übereinstimmt, dann wird beim Schritt 223 eine Überprüfung ausgeführt zum Bestimmen, ob ein Pending-Bit für eine zugeordnete Zeile einer solchen Zuordnungstabelle gesetzt ist, nämlich durch die MAC-Adresse des Clients, entfernte IP-Adresse, und Initialisierungscookie zugeordnet, die mit diesem des empfangenen IKE-Pakets, das verarbeitet wird, übereinstimmen. Insbesondere ist ein Pending-Bit optional, da stattdessen eine Überprüfung auf einen Sicherheitsparameterindex durchgeführt werden kann. In dem Fall einer neuen IKE-Unterhaltung zwischen dem lokalen Client 106-A und einer Remote-IP-Adresse wird das Sicherheitsparameter-Indexfeld 302 einen offenen oder leeren Eintrag für diese Zeile aufweisen, da bis jetzt kein IPSec-geschützter Verkehr, der aus diesem IKE-Austausch resultiert, von dem Gateway 106 beobachtet wurde. Insbesondere in einer nachfolgenden oder neuen IKE-Unterhaltung könnte Wieder-Verschlüsseln einer neuen IKE-Unterhaltung erlauben, einen neuen Sicherheitsparameterindex auszuhandeln, der übernommen wird, wenn der alte Sicherheitsparameterindex abläuft. Falls ein Pending-Bit im Pending-Bit-Feld 303 gesetzt ist und ein Sicherheitsparameter-Indexwert in einem Remote-to-Local-SPI-Feld 302 vorhanden ist, dann könnte der Sicherheitsparameter-Indexwert bald ablaufen, und das Gateway 106 kann daher vorhersehen, dass sich so ein Sicherheitsparameterindex im IPSec-geschützten Verkehr auf einen neuen Wert ändert. Dieses Pending-Bit wird gelöscht, wenn so ein neuer Sicherheitsparameterindex auf Remote-to-Local-IPSec-geschützten Paketen detektiert wird.
  • Falls beim Schritt 223 ein Pending-Bit im Pending-Bit-Feld 303 gesetzt ist, zum Beispiel auf Eins (1) gesetzt ist, zum Anzeigen, dass ein Remote-to-Local-Sicherheitsparameterindex von einer Maschine, für die so eine Ziel-IP-Adresse erhalten wurde und im IPSAMT 300 aufgezeichnet wurde. Falls so ein Bit gesetzt wurde – was anzeigt, dass ein Remote-to-Local-Sicherheitsparameterindex für eine Maschine erhalten wurde, die der Ziel-IP-Adresse zugeordnet ist – dann wird eine Zeile in so einer Zuordnungstabelle beim Schritt 222 erzeugt. Das bedeutet, dass ein anderer IKE nicht auf die gleiche Remote-IP-Adresse unterdrückt wird, da ein Remote-to-Local-Sicherheitsparameterindex für einen früheren IKE (von einem anderen lokalen Client) erhalten wurde.
  • Falls jedoch beim Schritt 223 ein Remote-to-Local-Sicherheitsparameterindex-Pending-Bit in einem Pending-Bit-Feld 303 nicht von seinem ursprünglichen Setzwert umgedreht wurde, d. h. noch Null (0) ist, dann zeigt das an, dass kein anderer lokaler Client IKE zum Verhandeln mit der gleichen Remote-IP-Adresse verwenden kann, da kein Remote-to-Local-Sicherheitsparameterindex für IPSec-geschützte Daten von der angezeigten Remote-IP-Adresse in Gebrauch beobachtet wurde. Folglich kann beim Schritt 224 so ein IKE-Paket, oder insbesondere ein IKE-Initialisierungs-Paket, optional in eine Schlange gestellt werden, und zum Erzeugen einer Zeile in einer Zuordnungstabelle beim Schritt 222 gelöst werden, wenn ein Remote-to-Local-Sicherheitsparameterindex-Pending-Bit 303 für eine frühere IPSec-Session gesetzt ist, indem beim Schritt 223 wiederholt geprüft wird. Eine andere Option, eher als in eine Schlange stellen des ISAKMP-Pakets, wäre es, dem lokalen Client ein ICMP-Ziel-unerreichbar (Typ==3) mit einem Subcode==3 (Port unerreichbar), oder ein ICMP-Ziel-unerreichbar (Typ==3) mit einem Subcode==9 (Kommunikation mit Zielhost ist administrativ verboten) zu senden.
  • Mit Bezugnahme zu 4 ist ein Flussdiagramm einer beispielhaften Ausführungsform einer Empfangsseite für einen IPSec/NAT-Integrationsprozess 200 gemäß einem oder mehreren Aspekten der Erfindung gezeigt. Mit fortgeführter Bezugnahme zu 4 und zusätzlicher Bezugnahme zu 1 und 2 wird eine Empfangsseite des Integrationsprozesses 200 beschrieben. Beim Schritt 407 wird ein IP-Paket von einem Computersystem 101 mittels des NAT-Gateways 106 empfangen. Beim Schritt 408 wird zum Bestimmen, ob ein Sicherheitsparameterindex in so einem empfangenen Paket vorhanden ist, ein Vergleich ausgeführt. In anderen Worten, einem IPSec-geschützten Paket, das eines aus nur-AH, nur-ESP und ESP-mit-AH anwendet.
  • Falls eine IKE-Verhandlung von einem lokalen Client mit einigen Remote-IP-Adressen initialisiert wurde, wird ein Pending-Bit in einem Pending-Bit-Feld 303 gesetzt, da keine Remote-to-Lokal-Sicherheitsparameter, die dem Verkehr des entfernten Computersystem 101 zu dem lokalen Client 106-A, der so eine IKE-Verhandlung initialisierte, zugeordnet sind, beobachtet und aufgezeichnet wurden. Falls eine IP-Quelladresse des IKE-Pakets des lokalen Clients 106-A eine private Adresse ist, dann wird diese private IP-Adresse des Clients in dem Local-Client-IP-Adressfeld 306 gespeichert. Wenn dieses Feld besetzt ist, weiß das Gateway 106, dass nur für IPSec-Verkehr nur-ESP-Verkehr zwischen dem Client 106-A und einer entfernten Maschine, die dieser entfernten IP-Adresse zugeordnet ist, erlaubt sein soll. Falls jedoch der lokale Client 106-A eine öffentliche IP-Adresse als die IP-Quelladresse in seinen IKE-Paket(en) verwendet, dann muss sich das Gateway 106 an die MAC-Adresse dieses Clients erinnern, indem sie in dem Lokal-Client-MAC-Adressfeld 301 gespeichert wird. Wenn ein Feld für diese MAC-Adresse des lokalen IKE-Clients besetzt ist, kann der Client 106-A nur-AH-, nur-ESP- oder ESP-mit-AH-Formen von IPSec verwenden. Insbesondere in so einem Fall wird der Client 106-A eine öffentliche IP-Adresse verwenden, die durch den Gateway 106 zugewiesen wurde, die wieder zurückgerufen werden kann, da beim Schritt 254 gespeichert wurde, dass einer Maschine mit dieser MAC-Adresse eine öffentliche IP-Adresse zugewiesen wurde. Nur MAC-Adressen, die beim Schritt 254 aufgezeichnet wurden, sollte erlaubt sein, ihre zugeordneten öffentlichen IP-Adressen zu verwenden.
  • Falls IKE-Unterdrückung verwendet wird, und falls keine IPSec-geschützten Daten von einer Maschine mit einer Remote-IP-Adresse fliessen, die einem lokalen Client in einer Zuordnungstabelle nach einer IKE-Verhandlung zugeordnet ist, wird ein Pending-Bit in einem Pending-Bit-Feld 303 gesetzt bleiben, zum Beispiel auf Eins (1), was andere Clients vom Beginnen von IKE-Verhandlungen mit der gleichen Ziel-IP-Adresse ausschliesst. Folglich kann eine Zeitmarke 305 so verwendet werden, dass, falls ein Remote-to-Local-Sicherheitsparameterindex in einem Remote-to-Local-Sicherheitsparameter-Indexfeld 302 nicht innerhalb einer vorgegebenen Zeit erhalten wird, wodurch so ein Pending-Bit gelöscht wird, zum Beispiel auf Null (0), eine abgelaufene Zeile aus dem IPSAMT 300 entfernt wird, um einer anderen IKE zu der gleichen Remote-IP-Adresse zu erlauben stattzufinden. Diese Zeile muss nicht entfernt werden, bis eine andere Station tatsächlich versucht, eine IKE-Verhandlung mit der gleichen Remote-IP-Adresse zu initiieren, an welchem Punkt so ein Konflikt bemerkt wird. Folglich wird nachgewiesen, dass so ein Pending-Bit im Pending-Bit-Feld 303 auf Eins (1) gesetzt ist und eine zugeordnete Zeitmarke in einem Zeitmarkenfeld 305 wird zum Nachweisen überprüft, dass die Zeile, bzw. diese Zeileneinträge, alt genug ist/sind, um gesäubert zu werden.
  • Falls das Pending-Bit 303 frei ist, d. h. auf Null (0) gesetzt ist, wird eine zugeordnete Zeile im IPSAMT 300 bleiben, bis eine andere IKE-Session zwischen den gleichen zwei Adressen, nämlich entweder eine lokale MAC- oder eine private IP-Adresse eines lokalen Clients und eine Remote-IP-Adresse initialisiert wird. Falls eine andere IKE-Session zwischen zwei Maschinen, die bereits eine IKE-Session aufweisen, wo ein Remote-to-Local-Sicherheitsparameterindex erhalten wurde, initialisiert wird, weist die zugeordnete Zeile für eine vorherige IKE-Session zwischen diesen zwei Maschinen ein gesetztes Bit im Pending-Bit-Feld 303 auf, obwohl ein Remote-to-Local-Sicherheitsparameterindex bekannt ist. Das Setzen so eines Pending-Bits auf Eins (1) zum Beispiel zeigt in diesem Fall an, das für die zugeordnete Zeile das Löschen anhängig ist.
  • In Situationen, wo ein neuer IKE einen existierenden IKE, wo ein Remote-to-Local-Sicherheitsparameterindex erhalten wurde, ersetzen will, kann erwartet werden, dass begonnen wird, dass ein neuer Remote-to-Local-Sicherheitsparameterindex für Verkehr von einer Remote-IP-Adresse zu einem lokalen Client verwendet wird, an welchem Punkt eine neue Zeile aus einer alten Zeile geklont werden kann, die sich nur in dem Wert eines Remote-to-Local-Sicherheitsparameterindex unterscheiden. Wenn einmal so eine neue Zeile erzeugt wurde, kann ein Pending-Bit in dem Pending-Bit-Feld 303 in der alten Zeile wieder gelöscht werden, d. h. auf Null (0) gesetzt werden. Im Allgemeinen wird jedesmal, wenn gesehen wird, dass ein Paket mit einem Tabelleneintrag übereinstimmt, das Zeitmarke-Feld 305 aktualisiert, aber eine alte Zeile sollte bald aufhören, einen Verkehr aufzuweisen, der unter Verwendung eines alten Remote-to-Local-Sicherheitsparameterindex ankommt, was bewirkt, dass die Zeile älter und älter wird, wenn Zeit vergeht. Diese Zeile wird, wenn sie alt genug ist, mittels normaler "Müllsammel"-Aktivitäten gelöscht. Ein neuer IKE kann zum Beispiel initialisiert werden, da ausgetauschte Schlüssel vor dem Ablaufen sind oder abgelaufen sind.
  • Eine neue IKE-Verhandlung kann jederzeit nach Ermessen eines lokalen Clients stattfinden, der so eine neue IKE-Kommunikation initialisiert. IKE-Verhandlungen werden nicht durch eine entfernte Maschine oder eine Remote-IP-Adresse initialisiert, sogar bei bestehenden IKE-Sessions. Ein Session-Urheber, der in dem Fall von NAT immer ein lokaler Client sein muss, initialisiert alle weiteren IKE-Unterhaltungen, zum Beispiel Wieder-Verschlüsselungs-Verhandlungen.
  • Mit fortgeführter Bezugnahme zu den 5A und 5B und einer erneuerten Bezugnahme zu 4, falls beim Schritt 408 kein Sicherheitsparameterindex in einem empfangenen Paket ist, wie in Paketen, die nicht durch IPSec geschützt sind, dann wird so ein Paket beim Schritt 409 geroutet, ohne den IPSAMT 300 zu befragen. So eine Routing-Entscheidung kann von einer Gateway-NAT-Tabelle angestoßen sein, die die nicht-IPSec-NAT-Funktionen des Gateways 106 antreibt. Da NAT gut bekannt ist, wird eine detaillierte Diskussion von NAT aus Zwecken der Klarheit weggelassen.
  • Falls beim Schritt 408 ein Sicherheitsparameterindex in einem Paket gefunden wird, das beim Schritt 407 empfangen wurde, dann wird beim Schritt 410 zum Bestimmen, ob ein Remote-to-Local-Sicherheitsparameterindex für die IP-Quelladresse von so einem Paket existiert, das mit einer Adresse im Remote-IP-Adressfeld 304 übereinstimmt, eine Überprüfung des IPSAMT 300 ausgeführt. Falls es beim Schritt 410 einen Wert vom ISAMT 300 im Remote-to-Local-Sicherheitsparameter-Indexfeld 302 gibt, dann wird beim Schritt 411 so ein übereinstimmendes Paket zu einer zugeordneten Adresse im MAC-Adressfeld 301 des lokalen Clients oder in dem Adressfeld 306 der privaten IP des lokalen Clients geroutet, die einem solchen Wert im Remote-to-Local-Sicherheitsparameter-Indexfeld 302 vom IPSAMT 300 zugeordnet ist, der in so einem empfangenen Paket gefunden ist.
  • Wenn das Gateway 106 einen Client-Computer unter Verwendung einer MAC-Adresse in einer Zuordnungstabelle identifiziert, hat dieser lokale Client eine Gateway-gelieferte öffentliche IP-Adresse als eine IP-Quelladresse in seinen lokal-zu-entfernt-Paketen verwendet. Das Gateway 106 speichert in solche Fällen eine Adresse eines solchen lokalen Clients aus dem Adressenfeld einer öffentlichen IP eines lokalen Clients 309 zum Zurückrufen oder Erinnern, so dass das Gateway 106 sicherstellen kann, dass nur die MAC-Adresse in dieser Domain, die ursprünglich DHCP zum Erhalten so einer öffentlichen IP-Adresse verwendet hat (durch Invertieren seines lokalen Bits), fähig sein sollte, diese öffentliche IP-Adresse zu verwenden.
  • Da die IP-Quelladresse von solchen lokal-zu-entfernt-Paketen schon eine öffentliche IP-Adresse ist, braucht das Gateway keine NAT-Übersetzung des Pakets durchzuführen. Daher können AH-geschützte Pakete aus der lokalen Domain entkommen, ohne auf IP-Adressübersetzung zu treffen, so das die entfernte Seite fähig sein wird, die in dem AH-Header eingebettete digitale Signatur zu bestätigen. Die Adresse des lokalen Clients, ob private IP-Adresse oder (öffentliche IP-Adresse, MAC-Adresse)-Paar, wird aus dem ursprünglichen Verkehr von dem lokalen Client zu der Remote-IP-Adresse aufgezeichnet, so dass das Gateway 106 fähig sein wird zu Bestimmen, zu welchem lokalen Client es den Rück-Verkehr weiterleiten soll. Die MAC-Adresse des lokalen Clients ist aus dem MAC-Quelladressfeld des ersten lokal-zu-entfernt-Pakets extrahiert, das für die Remote-IP-Adresse bestimmt wurde.
  • Für Situationen, in denen es mehr aktive Clients gibt als Gateway-verwaltete öffentliche IP-Adressen, wird es ein Viel-zu-Eins-Abbilden von Remote-IP-Adressen auf lokale Clients geben, bei dem der Remote-to-Local-Sicherheitsparameterindex zum Identifizieren verwendet wird, welche der Zeilen in der Tabelle dem richtigen lokalen Client entspricht. Das Gateway 106 speichert für einen Zurückruf, welche Form von Zieladresse für eine Schlußlieferung zu einer lokalen Station verwendet werden soll. Für Local-Client-Maschinen, deren MAC-Adresse und öffentliche IP-Adresse aufgezeichnet wurden, wird die IP-Zieladresse im Rückverkehr auch die gleiche öffentliche IP-Adresse sein, die das Gateway 106 jeweils solchen Local-Client-Maschinen zugewiesen hat. So weiß das Gateway 106, dass es das Paket, das an die öffentliche IP-Adresse des Clients adressiert ist, ungeändert sicher senden kann (außer, dass die MAC-Zieladresse des MAC-Rahmens die der LAN-Schnittstelle des Gateways auf dem lokalen Unter-Netzwerk sein wird, und die MAC-Zieladresse des Rahmens die MAC-Adresse des lokalen Clients sein wird, die das Gateway 106 in der Übereinstimmungszeile der Tabelle aufgezeichnet hat.
  • Für Verkehr zu lokalen Clients, für die ihre private IP-Adresse aufgezeichnet wurde (allein nur-ESP-Verkehr kann in dieser Kategorie sein), verwendet das Gateway 106 eine Adresse im Remote-IP-Adressfeld 304 und einen Wert im Remote-to-Local-Sicherheitsparameter-Indexfeld 302 zum Identifizieren der richtigen Zeile in einer Zuordnungstabelle, aus der eine Adresse im Adressfeld der privaten IP des lokalen Clients 306 extrahiert wird, wodurch die IP-Zieladresse eines Pakets in so eine private IP-Adresse eines lokalen Clients übersetzt wird.
  • Falls es beim Schritt 410 keinen Wert in einem Remote-to-Local-Sicherheitsparameter-Indexfeld 302 gibt, der einer Zeile einer Zuordnungstabelle zugeordnet ist, deren Adresse im Remote-IP-Adressfeld 304 mit einer IP-Quelladresse eines empfangenen Pakets übereinstimmt, und für die ein Bit im Pending-Bit-Feld 303 dieser Zeile in so einer Zuordnungstabelle gesetzt ist, zum Beispiel auf Eins (1), dann wird beim Schritt 412 der IPSAMT 300 durch Addieren eines Werts, der zu dem Remote-to-Local-Sicherheitsparameter-Indexfeld 302 von so einem empfangenen Paket mit so einer IP-Quelladresse und mit so einem anhängigen Wert addiert ist, aktualisiert. Als Antwort wird ein Bit im Pending-Bit-Feld 303 für diese Zeile gelöscht (d. h. auf Null (0) gesetzt), was den Empfang des anhängigen Remote-to-Local-Sicherheitsparameter-Indexwert anzeigt. Jedesmal, wenn ein Paket mit einer Zeile in der Tabelle übereinstimmt, wird das Zeitmarkenfeld 305 für diese Zeile aktualisiert.
  • In 5B werden Beispiele eines Wertes des Remote-to-Local-Sicherheitsparameter-Indexfeldes 302 jeweils zum Aktualisieren des IPSec-IPSAMT 300 in die Remote-to-Local-Sicherheitsparameterindexspalte oder das Remote-to-Local-Sicherheitsparameter-Indexfeld 302 bzw. die Pending-Bit-Spalte oder das Pending-Bit-Feld 303 geschrieben. Außerdem erlaubt, falls die IKE-Unterdrückung aktiv ist, dann das Löschen eines Bits im Pending-Bit-Feld 303 mittels Umdrehens, zum Beispiel auf Null (0), einem anderen lokalen Client eine IKE-Session für die gleiche Remote-IP-Adresse zu initiieren, die kürzlich in einem anhängigen Empfang eines Sicherheitsparameter-Indexwertzustands war. Nach dem Aktualisieren beim Schritt 412 wird beim Schritt 411 so ein empfangenes IP-Paket mittels des NAT-Gateways 106 gemäß einer Adresse aus dem MAC-Adressfeld 301 des lokalen Clients oder aus dem Adressfeld der privaten ID des lokalen Clients 306 im IPSAMT 300 zu einem Client-Computer 106-A, der dieser zugeordnet ist, geroutet.
  • Insbesondere falls es keine Zeile mit einem übereinstimmenden Remote-to-Local-Sicherheitsparameterindex 302 für ein empfangenes Paket gibt, kann das NAT-Gateway 106 immernoch so ein empfangenes Paket richtig routen, vorausgesetzt, dass nur eine MAC-Adresse eines lokalen Clients mit so einer Remote-IP-Adresse in Verbindung ist. Alternativ kann, falls mehr als ein offener Remote-to-Local-Sicherheitsparameterindex für die gleiche Remote-IP-Adresse erlaubt ist, dann so ein Paket an jede MAC-Adresse des lokalen Clients gesendet werden, die mit so einer Remote-IP-Adresse in Verbindung ist, oder zu der Sende-MAC-Adresse für alle Client-Computer auf dem LAN 102 gesendet werden, und das NAT-Gateway kann dann auf eine bidirektionale Antwort warten, um fähig zu sein, den richtigen lokalen Client mit dem richtigen Remote-to-Local-Sicherheitsparameterindex für diese Remote-IP-Adresse zu verbinden.
  • Es ist möglich, dass zwei verschiedene lokale Clients den gleichen Remote-to-Local-Sicherheitsparameter-Indexwert wählen, wenn sie in IKE-Verhandlungen mit der gleichen Remote-IP-Adresse sind. Das ist sogar dann möglich, wenn eine IKE-Unterdrückung in Fällen verwendet wird, wo alle Clients die gleiche öffentliche IP-Adresse teilen.
  • In Fällen jedoch, wo die zwei Clients, die den gleichen Remote-to-Local-Sicherheitsparameter-Indexwert ausgewählt haben, und ihnen verschiedene öffentliche Local-Client-IP-Adressen zugewiesen sind, kann das Paket basierend auf einer 4-Tupel-Verbindung mit einem empfangenen Paket, nämlich Remote-IP-Adresse, Remote-to-Local-Sicherheitsparameterindex, IPSec-Protocol und öffentliche Local-Client-IP-Adresse, weitergeleitet werden.
  • Für Fälle, in denen die lokalen Clients die gleiche öffentliche IP-Adresse aufweisen, wird jene MAC-Adresse welche zuerst in das IPSAMT 300 kommt, den ganzen zugeordneten Verkehr für diesen Remote-to-Local-Sicherheitsparameterindex 302 empfangen, da es keine Möglichkeit für das Gateway 106 gibt, Verkehr für eine Station von demjenigen einer anderen Station mit einer gleichen 4-Tupel-Verbindung abzugrenzen. Jedoch werden Verbindungen zwischen dem zweiten lokalen Client und dieser Remote-IP-Adresse nicht fortgeführt, und daher werden diese kommunizierenden Parteien eine neue IKE-Verhandlung versuchen, was in aller Wahrscheinlichkeit zu der Wahl eines einzigartigen Remote-to-Local-Sicherheitsparameter-Indexwertes führen wird, da Remote-to-Local-Sicherheitsparameterindizes eine zufällig ausgewählte Zahl aus dem Bereich von 256 bis einschließlich 4.294.967.295 sind, wobei 0 bis 255 reserviert sind.
  • Eine Art, um die Wahl von überlappenden Remote-to-Local-Sicherheitsparameterindizes zu verhindern, wäre, dass Endstationen ihre gegenwärtigen IP-Adressen und Sicherheitsparameterindizes auf ein LAN senden, so dass andere Stationen in der Domain auf Duplikate prüfen können. Jedoch würde so ein Schema signifikante Änderungen der Client-Software erfordern, und ist folglich wesentlich komplexer im Vergleich zum Fehlschlagenlassen einer Verbindungssession, einem Ereignis mit geringer Wahrscheinlichkeit, und zum Wiederherstellen von Endstationen mit einer unbrauchbaren IKE-Session, indem eine andere IKE-Session initialisiert wird.
  • Insbesondere nach einer erfolgreichen IKE-Verhandlung verschlüsseln IKE-Pakete eine obere Schicht einer Protokollinformationen und daher ist diese Information nicht für ein NAT-Gateway 106 verfügbar. Jedoch ist ein Sicherheitsparameterindex für ein Gateway verfügbar, da er nicht für eine IPSec-Session verschlüsselt ist. Außerdem ist ein Sicherheitsparameterindex in jedem Header-Typ, nämlich einem ESP-Header und einem AH einschießlich, aber nicht darauf beschränkt, einem ESP-mit-AH, verfügbar. Folglich weist das NAT-Gateway ein aktualisiertes IPSAMT 300 mit einem Remote-to-Local-Sicherheitsparameter-Indexwert auf, der zum Verbinden mit einer oder beiden Typen von IPSec, nämlich ESP bzw. AH, verwendet werden kann, wenn IKE einmal mittels eines Client-Computers und eines Ziel-Computers vervollständigt ist und verschlüsselte Daten unter Verwendung von Schlüsseln ausgetauscht sind. Insbesondere sollte ersichtlich sein, dass solche IPSAMT's in eine Mehrzahl von Tabellen aufgeteilt werden können, wobei eine oder mehrere Spalten verdoppelt werden können, obwohl eine IPSAMT-Struktur hier als eine einzelne Funktionseinheit beschrieben wurde. Das kann vorteilhaft sein, um eine oder mehrere Tabellen in Hardware, Firmware, Software oder irgendeiner Kombination daraus, erzeugen zu lassen. Folglich ist durch Abbilden einer Tabelle gemeint, dass eine einzelne Zuordnungstabelle genauso wie eine Mehrzahl von Zuordnungstabellen mit Verbindungen enthalten sind. Außerdem kann eine Information, die wie hierin beschrieben gesammelt und zugewiesen ist, in anderen Formen als tabellarisch gespeichert sein, einschließlich einer Datenbank und ähnlicher Datenstrukturen, aber nicht darauf begrenzt.
  • Neue Sicherheitsparameterindizes in einem AH- oder ESP-Paket können auch unter Verwendung eines Sequenznummernfeldes in so einem Paket identifiziert sein. Das erste Paket auf einer neuen Sicherheitsverbindung (SA, security association) wird immer eine Sequenznummer von "0x00-00-00-01" aufweisen. Obwohl sich das Header-Format unterscheidet, benutzen sowohl AH als auch ESP das Sequenznummernfeld dahingehend in der gleichen Weise, dass es in beiden Fällen von "0x00-00-00-01" startet und für jedes Paket, das gesendet wird, um 1 erhöht wird, und dass es 0xFF-FF-FF-FF nicht übersteigen kann. Der erste Remote-to-Local-Sicherheitsparameterindex sollte mit einer Sequenznummer von "0x00-00-00-01" ankommen und jedesmal, wenn die zwei Stationen durch Wieder-Verschlüsseln miteinander verbunden sind, muss der neue Remote-to-Local-Sicherheitsparameterindex mit einem auf "0x00-00-00-01" eingestelltem Sequenznummernfeld ankommen. Ein Paket, das einen neuen Sicherheitsparameter-Indexwert aufweist, aber dessen Sequenznummer größer als "0x00-00-00-01" ist, ist ein ungültiges Paket, welches das Gateway wahlweise verwerfen kann. Es ist jedoch wahrscheinlich, dass ein Weiterleiten solcher Pakete wenig Schaden anrichtet, da der Client gleichermaßen fähig ist, so einen Fehlerzustand zu detektieren.
  • Eine andere Fehlersituation, die das Gateway auswählen könnte zu Erzwingen, könnte das Blockieren von Paketen sein, deren Remote-to-Local-Sicherheitsparameterindex von 0xFF-FF-FF-FF auf 0x00-00-00-00 umspringt. Damit das Gateway diese Einschränkung erzwingen kann, müsste das Gateway entweder die Sequenznummer für jede Zeile in der Zuordnungstabelle nachverfolgen, oder bei dem Sequenznummernwert von 0xFF-FF-FF-FF auslösen, indem die übereinstimmende Zeile aus der Zuordnungstabelle gelöscht wird, so dass zukünftiger Verkehr nicht weitergeleitet werden kann. Wieder sollte der lokale Client fähig sein, auch diese Einschränkung zu erzwingen, so dass es nicht nötig ist, dass das Gateway den Client vor dieser Situation abschirmt, obwohl ein solches Abschirmen nicht, falls ermöglicht, die in diesem Dokument beschriebenen Algorithmen stört.
  • Außerdem kann das erneute SA-Aushandeln von dem Gateway vorgegeben oder vorhergesehen sein, da, wie oben ausgeführt ist, es dem Sequenznummernfeld nicht erlaubt ist, von 0xFF-FF-FF-FF auf 0x00-00-00-00 umzuspringen. Wenn ein Sequenznummernwert innerhalb von 33% oder weniger von 0xFF-FF-FF-FF kommt, kann das Gateway begründet erwarten, dass er einen neuen IKE-Austausch sehen wird, um eine neue SA einzustellen. Natürlich können zwei Parteien wählen, eine neue SA früher auszuhandeln als der Sequenznummernraum umspringen kann – eine ausgehandelte Lebenszeit einer SA kann möglicherweise viel kürzer sein als die Zeit, die ein Peer benötigt, um 4.294.967.295 Pakete zu übertragen. Jedoch kann die Sequenznummer in dem Fall, dass ein SA mit einer sehr langen Lebenszeit ausgehandelt wurde, während der die Paket-Übertragungsrate sehr hoch war, eine Marke aufweisen, das ein neuer IKE-Austausch immanent ist. Es können mehrere SAs zwischen einem lokalen Client und einer entfernten Maschine existieren. Es könnte AH-alleine, ESP-alleine oder ESP-mit-AH geben, wobei jedes einen einzigartigen Sicherheitsparameterindex aufweist. Folglich weist die Zuordnungstabelle 300 eine "IPSec-Protokoll"-Wertspalte 308 auf, die anzeigt, ob ein Remote-to-Local-Sicherheitsparameter-Indexwert AH, ESP oder beidem zugeordnet ist. Ferner kann die Zuordnungstabelle 300 beide AH- und ESP-Sicherheitsparameterindizes unabhängig aufzeichnen, zum Beispiel in getrennten Zeilen in der Tabelle 300, da eine Wahrscheinlichkeit besteht, dass Remote-to-Local-Sicherheitsparameter-Indexwerte die gleichen sein könnten für AH und ESP, so dass ein Aufzeichnen eines AH- oder ESP-Protokolltyps nötig ist, um zu sagen, welcher welcher ist. Insbesondere falls zwei lokale Clients mit der gleichen Remote-IP-Adresse sprechen und beide den gleichen Remote-to-Local-Sicherheitsparameterindex für das gleiche IPSec-Protokoll auswählen, würde das Gateway 106 den ganzen Verkehr für beide Sicherheits-Vereinigungen zu dem Client weiterleiten, der diesen Remote-to-Local-Sicherheitsparameterindex zuerst ausgehandelt hat.
  • Es ist möglich, dass eine SA für eine lange Zeit nach einem IKE-Anfangsaustausch beschäftigt sein könnte, oder nach einem Wieder-Verschlüsselungsaustausch, und sogar obwohl jede Seite einem neuen Sicherheitsparameterindex zugestimmt hat, könnten sie keine IPSec-geschützten Daten kommuniziert haben, so dass keine IPSec-geschützten Daten am Gateway 106 angekommen sind, um dem Remote-to-Local-Sicherheitsparameter-Indexfeld 302 in der Zuordnungstabelle 300 zu erlauben, bevölkert zu werden. Es ist möglich, dass während dieser leisen Zeit eine dritte Partei ein gefälschtes gespooftes Paket auf einem zufällig ausgewählten (ungültigen) Sicherheitsparameterindex mit einer Sequenznummer von 0x00-00-00-01 einsenden könnte. Das Gateway 106 kann solche Pakete unverzüglich zurückweisen, falls er weiß, dass kein IKE zwischen internen und externen Maschinen einer Zeile stattgefunden hat, die mit der übertragenen IP-Quelladresse in dem hereingesendeten Paket übereinstimmen (d. h. falls es keine Zeilen in der Zuordnungstabelle 300 gibt, die das Pending-Bit-Feld 303 auf Eins (1) gesetzt haben und keinen Sicherheitsparameter-Indexwert in dem Remote-to-Local-Sicherheitsparameter-Indexfeld 306 aufweisen). Jedoch können, falls es einen IKE-Austausch gab, aber noch kein IPSec-Verkehr durch das Gateway 106 geflossen ist, nur Endpunkte einer IKE-Verbindung sicher wissen, ob ein Sicherheitsparameterindex gültig ist. Das Gateway 106 sollte daher nach einem vollständigen bidirektionalen IPSec-geschützten Verkehrsaustausch zwischen den IKE-Peers Ausschau halten, bevor ein neuer Remote-to-Local-Sicherheitsparameterindex in das Feld 302 aufgezeichnet wird.
  • Falls ein gefälschtes Paket hereingesendet wurde, wie oben beschrieben, würde ein lokaler Client 106-A entweder so ein gefälschtes Paket verwerfen, oder er würde eine Fehlernachricht senden, oder er würde einen neuen IKE-Austausch starten, um eine existierende SA zu verifizieren oder eine Neue auszuhandeln. Falls der Client 106-A mit einem IPSec-geschützten Paket antwortet, aber die Remote-IP-Adresse in ihrer Antwort einen unterschiedlichen Sicherheitsparameterindex verwendet, dann weiß das Gateway 106, dass der erste Sicherheitsparameterindex, denn es sah, ein gefälschter Remote-to-Local-Sicherheitsparameterindex war.
  • Das Gateway 106 kann ein Pending-Bit 303 nicht löschen, bis es einen bidirektionalen IPSec-geschützten Austausch zwischen einer externen Maschine und einer internen Maschine gesehen hat. Das Gateway 106 kann eine anfängliche Sequenznummer als zusätzlichen Beweis verwenden, dass es einen korrekten Remote-to-Local-Sicherheitsparameter-Indexwert aufweist. Für empfangene gespoofte Pakete, für die so ein Sicherheitsparameterindex für gespoofte Pakete nicht in der Zuordnungstabelle 300 ist, kann das Gateway 106 alle IPSec-geschützten Pakete verwerfen, die behaupten, von einer entfernten IP-Adresse zu sein, die keinen bekannten Sicherheitsparameterindex aufweist – vorausgesetzt, dass das Gateway 106 weiß, dass kein IKE-Austausch aufgetreten ist, der einen existierenden Sicherheitsparameterindex in der Zuordnungstabelle 300 legitim ungültig macht. Das Gateway 106 kann solche Pakete ungeachtet des Wertes in dem Sequenznummernfeld verwerfen. Kurzgefasst, falls ein nicht-übereinstimmender Sicherheitsparameterindex von einer Remote-IP-Adresse eintrifft und keine Zeile, die mit dieser IP-Adresse übereinstimmt, das Pending-Bit 303 gesetzt hat, kann das Paket gelöscht werden.
  • Einige Ausführungsbeispiele der Erfindung sind Programmprodukte die vollständig oder teilweise im Speicher eines Gateway- und/oder eines Client-Computers sitzen können.
  • Ein Speicher kann flüchtigen und/oder nicht-flüchtigen Speicher aufweisen, einschließlich, aber nicht darauf beschränkt, magnetisch lesbarem Speicher (z. B. Floppy-Disk, Festplatte und dergleichen), optisch lesbarem Speicher (z. B. CD-ROM, -RW, DVD-ROM, -RAM und dergleichen) und elektrisch lesbarem Speicher (z. B. DRAM, SRAM, EEPROM, Register, Latchspeicher und dergleichen). Folglich sind einige Ausführungsbeispiele der Erfindung Programmprodukte, die maschinenlesbare Programme aufweisen. Das Programm bzw. die Programme des Programmprodukts definieren Funktionen der Ausführungsbeispiele und können auf einer Mehrzahl von Signal- tragenden Medium enthalten sein, die (i) Information, die dauerhaft auf unbeschreibbaren Speichermedium (z. B. Nur-Lese-Speichervorrichtungen innerhalb eines Computers wie CD-ROM-Platten, die von einem CD-ROM-Laufwerk lesbar sind) gespeichert sind; (ii) änderbare Information, die auf beschreibbaren Speichermedium (z. B. Floppy-Disks innerhalb eines Diskettenlaufwerks oder ein Festplatten-Laufwerk) gespeichert sind; oder (iii) Information, die mittels eines Kommunikationsmittels, wie zum Beispiel durch ein Computer- oder Telefonnetzwerk einschließlich drahtlosen Kommunikationsmitteln übertragen wird, aufweisen, aber nicht darauf beschränkt sind. Das letzte Ausführungsbeispiel weist insbesondere eine Information auf, die aus dem Internet oder anderen Netzwerken heruntergeladen ist. Solche Signal-tragenden Medium stellen Ausführungsbeispiele der Erfindung dar, wenn sie Computer-lesbare Anweisungen tragen, die die Funktionen der Erfindung regeln.
  • Während das Vorangegangene auf das bevorzugte Ausführungsbeispiel der Erfindung gerichtet ist, können andere und weitere Ausführungsbeispiele der Erfindung erdacht werden, ohne vom Haupt-Umfang davon abzurücken, und der Umfang davon wird durch die folgenden Ansprüche bestimmt. Ansprüche, die Schritte auflisten, legen keine Reihenfolge der Schritte fest, außer dass eine solche Reihenfolge explizit angezeigt ist.
  • Alle Marken sind Eigentum ihrer jeweiligen Eigentümer.
  • ZUSAMMENFASSUNG
  • Ein Verfahren und eine Vorrichtung für Intenetprotokollsicherheit (IPSec) und Netzwerkadressenübersetzung (NAT)-Integration ist beschrieben. Zusätzlich ist ein Verfahren und eine Vorrichtung für verbesserte Sicherheit zur Kommunikation über ein Netzwerk, und insbesondere zum Steuern einer Sicherheitsprotokollverhandlung offenbart, um einer Mehrzahl von Clients das Errichten einer virtuellen privaten Netzwerk-Verbindung mit einer gleichen entfernten Adresse zu erlauben. Ferner ist ein Verfahren und eine Vorrichtung für verbesserte Sicherheit zur Kommunikation über ein Netzwerk offenbart, und insbesondere zur NAT-Integrations-IPSec. Ferner ist ein Verfahren und eine Vorrichtung zur Integration von NAT und Quelladressensicherheit einschließlich, aber nicht darauf beschränkt, Bestimmen, ob ein Gateway-Computer für NAT und Quelladressensicherheit integriert ist, beschrieben.
    (3)

Claims (13)

  1. Verfahren für verbesserte Sicherheit beim Kommunizieren über ein Netzwerk zwischen einem Client-Computer hinter einem Adressenübersetzungs-konfigurierten Gateway-Computer und einem entfernten Computer, wobei das Verfahren aufweist: Bereitstellen einer öffentlichen Adresse an den Client-Computer des Gateway-Computers, wobei die öffentliche Adresse eine öffentliche Adresse des Gateway-Computers oder ein Pool von öffentlichen Adressen des Gateway-Computers ist; Teilhaben an einer Sicherheits-Vereinigungsverhandlung mit dem entfernten Computer; und Verwenden der Sicherheits-Vereinigungsverhandlung als eine Anzeige zum Aufzeichnen einer lokalen Adresse für den Client-Computer in Verbindung mit einer Zieladresse für den entfernten Computer, wobei die lokale Adresse und die Zieladresse aus der Sicherheits-Vereinigungsverhandlung erhalten werden und in einer Datenstruktur aufgezeichnet werden, auf die von dem Gateway-Computer zugegriffen werden kann.
  2. Verfahren zum Verarbeiten eines Internetprotokollsicherheits (IPSec)-Pakets mit einem Netzwerk-Adress-Übersetzungs (NAT)-Gateway-Computer, das aufweist: Überprüfen auf dem NAT-Gateway-Computer auf eine öffentliche Internetprotokoll (IP)-Quelladresse für das IPSec-Paket, die an den NAT-Gateway-Computer zuweisbar ist; in Antwort auf die öffentliche IP-Quelladresse, die von dem NAT-Gateway-Computer zuweisbar ist, Bestätigen, dass das IPSec-Paket von einem lokalen Computer gesendet wurde; und Übertragen des IPSec-Pakets an eine Zieladresse ohne die öffentliche IP-Quelladresse zu übersetzen, in Antwort auf die Bestätigung, dass das IPSec-Paket von dem lokalen Computer gesendet wurde.
  3. Verfahren zum Weiterleiten eines empfangenen Pakets mit einer Quelladresse und einer öffentlichen Adresse eines Gateway-Computers, welches aufweist: Überprüfen auf die Quelladresse in einer Zuordnungstabelle, die in Verbindung mit der öffentlichen Adresse des Gateway-Computers aufgelistet ist; Erhalten eines Sicherheitsparameterindex von dem empfangenen Paket; Überprüfen auf den Sicherheitsparameterindex in der Zuordnungstabelle in Verbindung mit der Quelladresse des empfangenen Pakets; und in Antwort auf das Finden des Sicherheitsparameterindex in der Zuordnungstabelle in Verbindung mit der Quelladresse des empfangenen Pakets, Weiterleiten des empfangenen Pakets an eine lokale Adresse, die mit dem Sicherheitsparameterindex und der Quelladresse in der Zuordnungstabelle verbunden ist, wobei die lokale Adresse nicht die öffentliche Adresse des Gateway-Computers ist.
  4. Verfahren zur Sicherheitsverhandlungssteuerung für einen Gateway-Computer, das aufweist: Bereitstellen des Gateway-Computers mit Zugriff auf eine Datenstruktur; Empfangen eines Pakets an dem Gateway-Computer; Bestimmen, ob das Paket ein Sicherheits-Verhandlungspaket ist; Überprüfen der Datenstruktur auf eine Mediumzugangssteuerung (MAC)-Quelladresse und eine Zieladresse in Antwort auf das Paket, das Teil der Sicherheitsverhandlung ist; in Antwort auf das Finden der Zieladresse in der Datenstruktur und das Nicht-Finden der MAC-Quelladresse in der Datenstruktur in Verbindung mit der Zieladresse, Bestimmen, ob ein Sicherheitswert für die Zieladresse in der Datenstruktur ist; und in Antwort auf das Nicht-Finden des Sicherheitswerts in der Datenstruktur für die Zieladresse, Unterdrücken einer Übertragung des Sicherheits-Verhandlungspakets.
  5. Verfahren zur Internet-Schlüsselaustausch (IKE)-Steuerung, das aufweist: Bereitstellen eines Gateway-Computers, der mit einer Zuordnungstabelle eingerichtet ist; Empfangen eines Pakets von einem lokalen Client-Computer an dem Gateway-Computer; Überprüfen, ob das Paket ein IKE-Paket ist; in Antwort darauf, dass das Paket ein IKE-Paket ist, Identifizieren einer Aufzeichnung in der Zuordnungstabelle, die sowohl mit einer Internetprotokoll (IP)-Zieladresse als auch einer lokalen Mediumzugangssteuerungs (MAC)-Adresse des IKE-Pakets in der Zuordnungstabelle übereinstimmt; und Überprüfen auf einen Sicherheitsparameterindex, der die Aufzeichnung in der Zuordnungstabelle betrifft, in Antwort auf das Identifizieren der Aufzeichnung in der Zuordnungstabelle.
  6. Datenstruktur für einen Gateway-Computer, die aufweist: ein Feld einer Mediumzugangssteuerungsadresse; ein Feld einer lokalen öffentlichen Adresse, das dem Mediumzugangssteuerungs-Adressfeld zugeordnet ist; ein Feld einer nicht-lokalen Adresse, das dem Mediumzugangssteuerungs-Adressfeld zugeordnet ist; ein Feld eines Sicherheitsparameterindex, das dem Feld der nicht-lokalen Adresse zugeordnet ist, wobei das Feld eines Sicherheitsparameterindex zum Speichern eines Sicherheitsparameterindex ist, der einer Datenkommunikation von einer nicht-lokalen Maschine zugeordnet ist.
  7. Verfahren für Netzwerk-Adress-Übersetzungs (NAT)-Integration mit einem Authentifizierungs-Header (AH)-geschützten Paket, das aufweist: Bereitstellen eines Client-Computers mit einer öffentlichen Adresse von einem NAT-Gateway-Computer; Bilden des AH-geschützten Pakets mittels des Client-Computers, wobei die öffentliche Adresse die Quelladresse ist; und Senden des AH-geschützten Pakets von dem Client-Computer an den NAT-Gateway-Computer.
  8. Verfahren zum Erzeugen einer Zuordnungstabelle für Netzwerk-Adress-Übersetzungs (NAT)-Integration mit Internetprotokollsicherheits (IPSec)-geschützten Paketen, das aufweist: Bereitstellen eines Gateway-Computers mit Zugriff auf die Zuordnungstabelle; Empfangen eines Pakets an dem Gateway-Computer, wobei das Paket von einem Client-Computer ist, wobei der Client-Computer einer Mediumzugangssteuerungsadresse zugeordnet ist, wobei die Mediumzugangssteuerungsadresse mit dem Paket zusätzlich zu einer Quelladresse für das Paket gesendet ist, wobei die Quelladresse eine öffentliche Adresse des Gateway-Computers ist; Bestimmen, ob das Paket ein Sicherheits-Verhandlungspaket ist; und in Antwort darauf, dass das Paket ein Sicherheits-Verhandlungspaket ist, Aufzeichnen der Mediumzugangssteuerungsadresse, einer Zieladresse des Pakets in Verbindung mit der Mediumzugangssteuerungsadresse, und eines Initiatorindikators in Verbindung mit wenigstens einer von der Mediumzugangssteuerungsadresse und der Zieladresse in der Zuordnungstabelle.
  9. Verfahren gemäß Anspruch 8, ferner aufweisend: Senden des Pakets an die Zieladresse ohne Adressübersetzung der öffentlichen Adresse; Empfangen eines anderen Pakets von einem entfernten Computer in Antwort auf das gesendete Paket; Erhalten des Sicherheitswerts von dem anderen Paket; Bestimmen, ob die Zieladresse in der Zuordnungstabelle eine Rückkehr-Adresse für das andere Paket ist; in Antwort darauf, dass die Rückkehr-Adresse als die Zieladresse in der Zuordnungstabelle ist, Bestimmen, ob der Sicherheitswert in Verbindung mit der Zieladresse in der Zuordnungstabelle ist.
  10. Verfahren zum Bilden eines Pakets mittels eines Client-Computes, das aufweist: Erhalten einer öffentlichen Adresse für den Client-Computer von einem Netzwerk-Adress-Übersetzungs-Gateway-Computer; und Verwenden der erhaltenen öffentlichen Adresse als eine Quelladresse für das Paket.
  11. Verfahren zum Bilden eines Pakets mittels eines Client-Computers, das aufweist: Erhalten einer öffentlichen Adresse und einer privaten Adresse für den Client-Computer von einem Netzwerk-Adress-Übersetzungs-Gateway-Computers; Auswählen von entweder der öffentlichen Adresse oder der privaten Adresse als der Quelladresse für das Paket; und Bilden des Pakets mit der ausgewählten Source-Adresse.
  12. Verfahren zur Netzwerk-Adress-Übersetzung für Quelladressen-geschützte Pakete, das aufweist: Bereitstellen eines Client-Computers; Bereitstellen eines Adress-Server-Computers, der mit dem Client-Computer in Verbindung ist; erstes Anfragen von dem Client-Computer nach einer ersten Adresse von dem Adress-Server-Computer, wobei der Client- Computer von dem Adress-Server-Computer durch eine Mediumzugriff-Steuerungsnummer identifizierbar ist; Bereitstellen einer privaten Adresse von dem Adress-Server-Computer an den Client-Computer in Antwort auf die erste Anfrage; Erzeugen einer Änderung der Mediumzugriff-Steuerungsnummer mittels des Client-Computers zum Bereitstellen einer geänderten Mediumzugriff-Steuerungsnummer; zweites Anfragen von dem Client-Computer nach einer zweiten Adresse von dem Adress-Server, wobei der Client-Computer von dem Adress-Server-Computer durch die geänderte Mediumzugriff-Steuerungsnummer identifizierbar ist; Zuordnen des Client-Computers zu der ersten Anfrage und der zweiten Anfrage mittels des Adress-Server-Computers, indem die Mediumzugriff-Steuerungsnummer mit der geänderten Mediumzugriff-Steuerungsnummer in Verbindung gebracht wird; und Bereitstellen einer öffentlichen Adresse an den Client-Computer mittels des Adress-Server-Computers in Antwort auf die zweite Anfrage.
  13. Verfahren zum Sondieren eines Gateway-Computers mittels eines Client-Computers zum Bestimmen, ob die Netzwerk-Adress-Übersetzung mit Quelladressensicherheit integriert ist, wobei das Verfahren aufweist: erstes Anfragen einer ersten Adresse von dem Gateway-Computer mit einer ersten Client-Identifikation; Empfangen der ersten Adresse von dem Gateway-Computer in Antwort auf die erste Anfrage; zweites Anfragen einer zweiten Adresse von dem Gateway-Computer mit einer zweiten Client-Identifikation, wobei die zweite Client-Identifikation der ersten Client-Identifikation ähnlich ist; Empfangen der zweiten Adresse von dem Gateway-Computer in Antwort auf die zweite Anfrage; und Bestimmen aus der angefragten zweiten Adresse, ob die Netzwerk-Adress-Übersetzung bei dem Gateway-Computer mit der Quelladressensicherheit integriert ist.
DE10392807T 2002-06-13 2003-06-03 Verfahren und Vorrichtung für eine verbesserte Sicherheit für eine Kommunikation über ein Netzwerk Expired - Fee Related DE10392807B9 (de)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US10/172,345 US7191331B2 (en) 2002-06-13 2002-06-13 Detection of support for security protocol and address translation integration
US10/172,352 2002-06-13
US10/172,046 US7143188B2 (en) 2002-06-13 2002-06-13 Method and apparatus for network address translation integration with internet protocol security
US10/172,683 2002-06-13
US10/172,345 2002-06-13
US10/172,046 2002-06-13
US10/172,683 US7120930B2 (en) 2002-06-13 2002-06-13 Method and apparatus for control of security protocol negotiation
US10/172,352 US7143137B2 (en) 2002-06-13 2002-06-13 Method and apparatus for security protocol and address translation integration
PCT/US2003/017502 WO2003107624A1 (en) 2002-06-13 2003-06-03 Method and apparatus for enhanced security for communication over a network

Publications (3)

Publication Number Publication Date
DE10392807T5 true DE10392807T5 (de) 2005-07-28
DE10392807B4 DE10392807B4 (de) 2011-03-10
DE10392807B9 DE10392807B9 (de) 2011-06-16

Family

ID=34109062

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10392807T Expired - Fee Related DE10392807B9 (de) 2002-06-13 2003-06-03 Verfahren und Vorrichtung für eine verbesserte Sicherheit für eine Kommunikation über ein Netzwerk

Country Status (4)

Country Link
JP (1) JP4426443B2 (de)
AU (1) AU2003240506A1 (de)
DE (1) DE10392807B9 (de)
GB (2) GB2405300B (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8042170B2 (en) * 2004-07-15 2011-10-18 Qualcomm Incorporated Bearer control of encrypted data flows in packet data communications
JPWO2007069327A1 (ja) * 2005-12-15 2009-05-21 富士通株式会社 中継装置，中継方法，中継用プログラム，中継用プログラムを記録したコンピュータ読取可能な記録媒体および情報処理装置
JP2008079059A (ja) * 2006-09-22 2008-04-03 Fujitsu Access Ltd ＩＰｓｅｃの複数セッションを処理する通信装置及びその処理方法
JP4708297B2 (ja) * 2006-09-29 2011-06-22 富士通テレコムネットワークス株式会社 ＩＰｓｅｃの複数セッションを処理する通信装置
JP2008259099A (ja) * 2007-04-09 2008-10-23 Atsumi Electric Co Ltd 警備システム
CN104980405A (zh) * 2014-04-10 2015-10-14 中兴通讯股份有限公司 一种对经过nat穿越的ipsec报文进行ah认证的方法及装置
JP6109990B1 (ja) * 2016-03-31 2017-04-05 西日本電信電話株式会社 Ｗｅｂ認証対応中継機
EP3871361B1 (de) 2018-11-15 2023-11-01 Huawei Technologies Co., Ltd. Rekeying einer sicherheitsassoziation sa

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI105753B (fi) * 1997-12-31 2000-09-29 Ssh Comm Security Oy Pakettien autentisointimenetelmä verkko-osoitemuutosten ja protokollamuunnosten läsnäollessa
DE60024237T2 (de) * 1999-03-17 2006-06-29 3Com Corp., Rolling Meadows Verfahren und system zur netzwerkadressübersetzung mit sicherheitseigenschaften
US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses
US7155740B2 (en) * 2000-07-13 2006-12-26 Lucent Technologies Inc. Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel mode

Also Published As

Publication number Publication date
GB0509902D0 (en) 2005-06-22
GB2413248B (en) 2006-06-21
GB2405300A (en) 2005-02-23
JP2005530404A (ja) 2005-10-06
GB2405300B (en) 2006-07-12
JP4426443B2 (ja) 2010-03-03
DE10392807B4 (de) 2011-03-10
DE10392807B9 (de) 2011-06-16
AU2003240506A1 (en) 2003-12-31
GB0427337D0 (en) 2005-01-19
GB2413248A (en) 2005-10-19

Similar Documents

Publication Publication Date Title
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE60314367T2 (de) Verfahren und Vorrichtung zur gleichrangigen Kommunikation
DE60019997T2 (de) Ggesicherte Kommunikation mit mobilen Rechnern
DE60116610T2 (de) Netzwerkadressenübersetzungsgateway für lokale netzwerke unter verwendung lokaler ip-adressen und nicht übersetzbarer portadressen
EP1602214B1 (de) Verfahren, system und speichermedium um kompatibilität zwischen IPsec und dynamischem routing herzustellen
DE60121101T2 (de) Gesichtertes Kommunikationsverfahren, gesichtertes Kommunikationssystem und Gerät
DE60221557T2 (de) Methode und gerät zur adressenübersetzung für gesicherte verbindungen
DE60212289T2 (de) Verwaltung privater virtueller Netze (VPN)
DE10022431B4 (de) Integriertes IP-Netzwerk
DE60311297T2 (de) Gemeinsame port adressenumsetzung in einem router der als nat & nat-pt gateway agiert
US7191331B2 (en) Detection of support for security protocol and address translation integration
DE60213391T2 (de) Persönlicher Firewall mit Positionsdetektion
US7143137B2 (en) Method and apparatus for security protocol and address translation integration
DE60202863T2 (de) Verfahren, Gateway und System zur Datenübertragung zwischen einer Netzwerkvorrichtung in einem öffentlichen Netzwerk und einer Netzwerkvorrichtung in einem privaten Netzwerk
DE10296660B4 (de) Über Netzwerkadressübersetzungs(NAT) -Einrichtungen hinweg betreibbare Kommunikationsprotokolle
US7120930B2 (en) Method and apparatus for control of security protocol negotiation
DE60127276T2 (de) Verfahren und vorrichtung zur erleichterung der peer-zu-peer anwendungskommunikation
US7143188B2 (en) Method and apparatus for network address translation integration with internet protocol security
DE602004007303T2 (de) Identifizierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE60121755T2 (de) Ipsec-verarbeitung
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
DE10052311A1 (de) Manuelles Verhindern des unerlaubten Mithörens in einem virtuellen privaten Netzwerk über das Internet
DE60311898T2 (de) Verfahren, um ein Paket von einem ersten IPSeC Klienten zu einem zweiten IPSec Klienten über einen L2TP Tunnel zu übertragen
DE60024237T2 (de) Verfahren und system zur netzwerkadressübersetzung mit sicherheitseigenschaften

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
8128 New person/name/address of the agent

Representative=s name: DILG HAEUSLER SCHINDELMANN PATENTANWALTSGESELLSCHA

8397 Reprint of erroneous patent document
R020 Patent grant now final

Effective date: 20110702

R082 Change of representative

Representative=s name: KRAUS & WEISERT PATENTANWAELTE PARTGMBB, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee