[go: up one dir, main page]

DE60315521T2 - Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten - Google Patents

Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten Download PDF

Info

Publication number
DE60315521T2
DE60315521T2 DE60315521T DE60315521T DE60315521T2 DE 60315521 T2 DE60315521 T2 DE 60315521T2 DE 60315521 T DE60315521 T DE 60315521T DE 60315521 T DE60315521 T DE 60315521T DE 60315521 T2 DE60315521 T2 DE 60315521T2
Authority
DE
Germany
Prior art keywords
vpn
network
routing
connection
certificate
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.)
Expired - Lifetime
Application number
DE60315521T
Other languages
English (en)
Other versions
DE60315521D1 (de
Inventor
Olivier Daude
Jacques Fieschi
Claude Galand
Olivier Hericourt
Jean-Francois Le Pennec
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.)
AT&T Corp
Original Assignee
AT&T 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
Application filed by AT&T Corp filed Critical AT&T Corp
Application granted granted Critical
Publication of DE60315521D1 publication Critical patent/DE60315521D1/de
Publication of DE60315521T2 publication Critical patent/DE60315521T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0254—Stateful filtering
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

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

Description

  • ALLGEMEINER STAND DER TECHNIK
  • ERFINDUNGSGEBIET
  • Die vorliegende Erfindung betrifft die Bildung und Verwendung von sicheren Netzwerkverbindungen. Insbesondere betrifft die vorliegende Erfindung das Bilden sicherer Netzwerkverbindungen für Vorrichtungen, die sich in verschiedenen privaten Netzwerken befinden.
  • BESCHREIBUNG DES VERWANDTEN STANDS DER TECHNIK
  • Es gibt Virtuelle Private Netzwerke („VPN"), die privaten Kommunikationen zwischen Vorrichtungen, die einem gegebenen VPN zugeordnet sind, auch dann ermöglichen, wenn einige oder alle Kommunikationen über ein öffentliches Netzwerk gesendet werden. Die meisten VPN sind in Kategorien unterteilt, die in verschiedenen Schichten der wohlbekannten Sendesteuerprotokoll/Internetprototkoll-(TCP/IP)-Protokollfolge angesiedelt sind. Insbesondere sind die Netzwerk- und Verbindungsschichten der TCP/IP-Protokollfolge (d.h. Schicht 3 bzw. 2) Beispiele für Schichten, die allgemein zum Einrichten von VPN verwendet werden.
  • Mit Bezug auf Netzwerkschicht-VPN gibt es verschiedene bekannte Verfahren zur Einrichtung solcher VPN. Als ein erstes Beispiel kann „Routenfiltern" implementiert werden, um die Routenverbreitung so zu steuern, dass nur bestimmte Netzwerke Routen für andere Netzwerke innerhalb ihrer eigenen interessierenden Gemeinschaft (d.h. VPN) erhalten.
  • Routenfiltern basiert auf der Voraussetzung, dass eine Netzwerkuntergruppe eines zugrundeliegenden IP-Netzwerks, die das VPN unterstützt (wie das Internet), das eigentliche VPN bildet. Mit dieser Netzwerkuntergruppe assoziierte Routen werden so gefiltert, dass sie nicht an ein anderes Netzwerk oder andere Netzwerke bekannt gegeben werden, das/die mit der das VPN bildenden Netzwerkuntergruppe verbunden sind. Im Gegensatz dazu wird keine andere nicht-VPN-Route an die Netzwerkuntergruppe bekannt gegeben.
  • Der Schutz von Diensten auf einem Netzwerkschicht-VPN mit Routenfiltern wird dadurch implementiert, dass jeder VPN-Host daran gehindert wird, auf Pakete zu antworten, die Quelladressen von außerhalb des VPN enthalten. Solche Einschränkungen basieren auf Zugriffssteuerlisten („ACL"), bei denen es sich um Tabellen handelt, die einer Vorrichtung mitteilen, über welche Zugriffsrechte jeder Nutzer verfügt. Das heißt, eine ACL ist eine Liste von Einträgen, die spezifische Zugriffsrechte an Individuen oder Gruppen gewähren oder verwehren.
  • Herkömmliche Netzwerkschicht-VPN mit Routenfiltern weisen jedoch verschiedene damit verbundene Schwierigkeiten auf. Eine solche Anordnung kann beispielsweise so fehlkonfiguriert sein, dass sie fehlerhaft Pakete annimmt, die sie nicht annehmen sollte, und/oder Pakete zurückweist, die angenommen werden sollten. Ein weiteres Problem des Routenfiltern ist, dass, wenn es hinter einer Gateway- oder Firewall-Vorrichtung implementiert ist, Teilnehmernetzwerke einen Router, der extern des Gateways/der Firewall liegt, als voreingestellten Router definieren können, so dass Nutzer des VPN hinter dem Gateway/der Firewall externe Netzwerke erreichen können, solange sie die Adresse des voreingestellten Routers kennen (auch wenn diese nicht bekannt gegeben wird). Zu weiteren Nachteilen dieser Technik gehören Verwaltungsfehler, eine statische Natur des Aufbaus und Beschränkungen der bereitgestellten Sicherheit. Außerdem ist die Komplexität des Definierens und Führen aller Regeln sehr hoch, so dass die Technik sich nicht gut oder nicht sehr leicht skalieren lässt.
  • Als ein letzter Punkt, der mit Netzwerkschicht-VPN mit Routenfiltern verbunden ist, erfordert die Verbindung zwischen zwei verschiedenen VPN (d.h. Inter-VPN-Konnektivität), dass das Netzwerk Pakete externen Ursprungs an die VPN-Verbindungsstelle weiterleitet bzw. routet. Wenn die Pakete an der Verbindungsstelle in das VPN zugelassen werden, können dieselben Pakete über das Netzwerk zu der letztlichen VPN-Zieladresse zurückgeleitet werden. Somit ist die Verbindungsstelle in dem Sicherheitsaufbau verbundener VPN ein sehr sensibler Punkt.
  • Eine zweite Art von Netzwerkschicht-VPN wird unter Verwendung von Tunnelprotokollen aufgebaut Die generische Routing-Einkapselung (GRE) ist ein Netzwerkschicht-Tunnelprotokoll, das zum Aufbau von VPN verwendet wird (Schicht-2-Tunnelprotokolle, wie Schicht-2-Tunnel-Protokoll (L2TP) und Punkt-zu-Punkt-Tunnel-Protokoll (PPTP) sind ebenfalls bekannt und werden unten eingehender erläutert).
  • GRE-Tunnel werden zwischen einem Quell-(Ingress)-Router und einem Ziel-(Egress)-Router konfiguriert, so dass zum Weiterleiten über den Tunnel bestimmte Pakete ferner mit einem neuen Kopf (dem GRE-Kopf) eingekapselt und in den Tunnel mit einer Zieladresse des Tunnelendpunkts (dem neuen Nächster-Hop) platziert werden. Wenn das Paket den Tunnelendpunkt erreicht, wird der GRE-Kopf abgestreift und das Paket wird weiter an das Ziel weitergeleitet, wie in dem ursprünglichen IP-Paket-Kopf festgelegt.
  • In dem GRE-Tunnelprotokoll ist das Routen für das VPN von dem Routen für den Kunden isoliert. Die VPN können denselben privaten Adressraum innerhalb mehrerer VPN ohne eine Kreuzeinwirkung verwenden, wodurch eine beträchtliche Unabhängigkeit des VPN von dem Kundennetzwerk bereitgestellt wird.
  • Hinsichtlich der Implementation des GRE-Tunnelprotokolls bestehen verschiedene Schwierigkeiten. GRE-Tunnel müssen beispielsweise manuell konfiguriert werden, was zu übermäßigen Verwaltungszusatzkosten führt. Außerdem gibt der Datenschutz des Netzwerks Anlass zu Bedenken, weil der Tunnel immer noch verwundbar ist, so dass der Datenschutz nicht absolut ist Außerdem können Pakete, die GRE-Formatierung verwenden, von Quellen dritter Parteien in das VPN injiziert werden. Darüber hinaus müssen Ingressfilter eingesetzt werden, die auf die konfigurierte Tunnelstruktur ausgerichtet sind, um einen größeren Grad Datenschutzintegrität des VPN sicherzustellen. Schließlich muss außerdem sichergestellt werden, dass die CPE-(Customer Premises Equipment)-Router durch den VPN-Serviceprovider verwaltet werden, da die Konfiguration der Tunnelendpunkte eine kritische Komponente der Gesamtarchitektur der Datenschutzintegrität ist.
  • Als ein letztes Beispiel einer Netzwerkschicht-Tunneltechnik wurde IP Sicherheit (IPSec) entwickelt. IPSec ist ein flexibles Rahmenwerk zum Bereitstellen von Netzwerkschichtsicherheit. Frühere Sicherheitsprotokolle schützten oftmals nur einen Teil einer Ende-zu-Ende-Strecke oder zwangen zum Anlegen desselben Schutzes überall entlang der Strecke. IPSec stellt dagegen eine vollständige Ende-zu-Ende-Netzwerkschichtsicherheit bereit, während es die Möglichkeit bereitstellt, die Sicherheitsabdeckung segmentweise entlang jeder gegebenen Strecke genau abzustimmen. IPSec-Protokolle unterstützen Datenursprungsauthentifizierung, Datenintegrität, Datenvertraulichkeit, Verschlüsselungsschlüsselverwaltung und Verwaltung von Sicherheitsassoziationen. Innerhalb des IPSec-Rahmenwerks kann eine Firma sichere Ende-zu-Ende-Lösungen konfigurieren, die sowohl lokal angebrachte Nutzer als auch Nutzer mit Fernzugriff aufnehmen kann und Kommunikationen sowohl innerhalb der Firma als auch zwischen verschiedenen Firmen unterstützen kann.
  • Der mit IPSec verschlüsselte Tunnelmodus lässt jedoch die Stellen des Tunnelingress und des Tunnelegress verletzlich, da diese Punkte ein logischer Teil des Hostnetzwerks als auch ein Teil des verschlüsselten VPN-Netzwerks sind. Jede Korruption der Betriebsweise oder ein Abfangen von unverschlüsseltem Traffic wird an diesen Punkten den Datenschutz des privaten Netzwerks beeinträchtigen. In dem Tunnelmodus wird jedoch der Traffic, der an den verschlüsselten Links zwischen den teilnehmenden Routern übergeht, als sicher betrachtet.
  • Neben Netzwerkschicht-VPN gibt es auch herkömmliche Verbindungsschicht-VPN. Verbindungsschichtprotokolle, wie Frame-Relay oder Asynchroner Transfermodus (ATM) ermöglichen beispielsweise das Aufbauen von VPN als eine Gruppe von privaten virtuellen Schaltungen (PVC). Die aufgebauten VPN sind allgemein nicht voll verzahnt (d.h. jede der VPN-Vorrichtungen ist nicht notwendigerweise in der Lage, direkt mit allen anderen VPN-Vorrichtungen zu kommunizieren). Vielmehr sind sie nur teilweise verzahnt oder verwenden ein Hub-Modell. Obwohl sie robust und einfach sind, lassen sich diese Protokolle nicht leicht skalieren, da jede Peer-to-Peer-Verbindung eine fest zugewiesene PVC ist, die manuell konfiguriert werden muss.
  • Ein Verfahren, um diese Skalierprobleme in Verbindungsschicht-VPN anzugehen, ist die Verwendung von VPN-Etiketten innerhalb einer einfachen Routingumgebung, auf dieselbe Weise, wie Paketetiketten notwendig sind, um die korrekte Routingtabelle pro VPN in Netzwerkschicht-VPN zu aktivieren. Die Verwendung von lokaler Etikettenschaltung schafft effektiv die Architektur des wohlbekannten Mehrfachprotokoll-Etikettschaltungs-(MPLS)-VPN. Die von MPLS verwendeten Architekturkonzepte sind generisch genug, damit sie als Peer-VPN-Modell für die Schalttechnologie für eine Vielzahl von Verbindungsschichttechnologien und in heterogenen Schicht-2-Übertragungs- und Schaltumgebungen wirken können. MPLS erfordert die protokollbasierte Routingfunktionalität in den zwischengeschalteten Vorrichtungen und wirkt durch Sichtbarmachen der Transportinfrastruktur für das Routen.
  • MPLS-VPN haben nicht einen sondern drei Schlüsselbestandteile: (1) Eingeschränkte Verteilung von Routinginformationen als eine Methode, VPN zu bilden und Inter-VPN-Konnektivität zu steuern; (2) Verwendung von VPN-ID und insbesondere die Aneinanderkettung von VPN-ID mit IP-Adressen, um (potenziell) nicht-eindeutige Adressen in eindeutige zu verwandeln, und (3) Verwendung von Etikettschaltungs-MPLS, um Weiterleiten entlang der über (1) und (2) konstruierten Routen bereitzustellen.
  • Zur Unterstützung von VPN in einer MPLS-Umgebung sind zahlreiche Ansätze möglich. In der Basis-MPLS-Architektur bestimmt das an ein in die MPLS-Umgebung eindringendes Paket angebrachte Etikett die Auswahl des Egress-Routers, da die Sequenz von Etikettschaltungen eine virtuelle Ende-zu-Ende-Strecke definiert. Die Erweiterung der lokalen MPLS-Etikett-Hop-by-Hop-Architektur ist die Idee eines globalen Identifizierers pro VPN, der effektiv innerhalb eines Ende-zu-Ende-Kontexts verwendet wird. Dieser globale Identifizierer könnte beim Ingress zugewiesen werden und wird dann als ein Index in eine per-VPN-Routing-Tabelle verwendet, um das Anfangsschaltetikett zu bestimmen. Beim Egress aus der MPLS-Umgebung würde der VPN-Identfizierer wieder als Index in eine Tabelle von globale Identifizier pro VPN verwendet werden, um die Auswahl des nächsten Hop vorzunehmen.
  • In einem anderen Ansatz zur Unterstützung von VPN innerhalb einer MPLS-Umgebung wird ein PE-(Provider Edge)-Router mit einer Vielzahl von logischen Router so konfiguriert, dass jeder logische Router, der einem VPN entspricht, mit einer Gruppe von Routingprotokollen zwischen PE-Routern implementiert werden kann, deren Verarbeitung auf VPN-Routing- und Weiterleitungs-(VRF)-Tabellen basiert. Basierend auf der Routinginformation einer VRF-Tabelle in einem PE-Router wird Nutzertraffic, der von einer CE-(Customer Equipment)-Vorrichtung oder einem anderen PE-Router empfangen wird, an eine andere CE-Vorrichtung oder PE-Router über einen Zugriff bzw. logischen Link weitergeleitet. Für den dynamischen Routingdienst verteilt ein PE-Router Informationen innerhalb von Nutzersites, welche von einer CE-Vorrichtung oder einem anderen PE-Router empfangen wird, an eine andere CE-Vorrichtung oder PE-Router unter Verwendung von Routingprotokollen zwischen PE-Routern. Ein PE-Router implementiert einen oder mehrere logische (d.h. „virtuelle") Router. Er ist normalerweise am Rand eines SP-(Serviceprovider)-Netzwerks angesiedelt.
  • Schließlich gibt es auch Tunneltechniken für Verbindungsschicht-VPN. Beispielsweise bestehen virtuelle private Anwahlnetzwerke (VPDN), die Schicht-2-Tunneltechniken verwenden. Es gibt drei grundsätzliche Verfahren des Implementieren eines VPDN: Schicht-2-Tunnelprotokoll (L2TP), Cisco-Schicht-2-Weiterleitenprotokoll (L2F), von dem L2TP abgeleitet wurde, und Punkt-zu-Punkt-Tunnelprotokoll-(PPTP)-Tunnel. Solche Tunnel stellen VPN dar, die statische oder dynamische Tunnel, in einigen Fällen mit einer vorläufigen Authentifizierungsphase, sind.
  • Kurz gefasst wurden verschiedene Lösungen vorgeschlagen, um beim Herstellen von VPN über ein gemeinsam benutztes IP-Basisnetz verschiedene Grade an Netzwerkdatenschutz zu erzielen. Viele dieser Lösungen erfordern separate Weiterleitungsfähigkeiten pro VPN und verwenden IP- oder MPLS-basierte Tunnel über das Basisnetz. Innerhalb einer VPN-Domain wird auch Routing verwendet, um VPN-Erreichbarkeitsinformationen unter den Router zu verteilen. Jedes Routingprotokoll kann verwendet werden, und nicht auf VPN bezogene Modifikationen oder Erweiterungen sind für das Routingprotokoll erforderlich, um die VPN-Erreichbarkeit zu erzielen.
  • Allgemein ausgedrückt kann ein VPN somit verschiedene Formen annehmen. Bin VPN kann zwischen zwei Endsystemen bestehen oder es kann zwischen zwei oder mehr Netzwerken bestehen. Ein VPN kann unter Verwendung von Tunneln oder Verschlüsselung (auf im Wesentlichen jeder Schicht des Protokollstapels) oder beider oder alternativ unter Verwendung von MPLS oder eines der Verfahren mit „virtuellem Router" aufgebaut werden. Ein VPN kann aus Netzwerken bestehen, die durch geleaste Leitungen, Frame Relay oder ATM mit dem Netzwerk eines Serviceproviders verbunden sind. Als ein letztes Beispiel kann ein VPN aus Einwahl-Teilnehmerverbindungen mit zentralisierten Diensten oder zu anderen Einwahlteilnehmern bestehen.
  • Unabhängig davon, welche der oben genannten Techniken (oder andere bekannte Techniken) zur Bildung eines VPN verwendet werden, versteht sich, dass die Netzwerksicherheit bedacht werden muss. In der Tat ist die Netzwerksicherheit ein Problem in vielen Zusammenhängen abseits von VPN und im Allgemeinen ist die zunehmende Verwendung von Fernzugriff über öffentliche Netzwerke und Internetzugriff für die Kommunikation zwischen Unternehmen eine Hauptantriebskraft hinter der Entwicklung von Sicherheitstechnologie. Insbesondere sind die öffentlichen Schlüsselzertifikate (die unten stehend ausführlicher erörtert werden) und die dynamischen Passwörter zwei Technologiegebiete, die schnell anwachsen, um die Sicherheitsbedürfnisse der heutigen vernetzten Umgebung zu erfüllen. Auf dem Gebiet der VPN werden diese Sicherheitstechnologien in VPN, die auf IPSec basieren, wohl verwendet, aber sie sind nicht so vorteilhaft, wenn sie in Verbindung mit anderen VPN-Technologien verwendet werden.
  • Viele Techniken für die Netzwerksicherheit drehen sich um die Verwendung einer Firewall, die allgemein als eine Kombination aus Hardware und Software bekannt ist und verwendet wird, um eine Sicherheitsrichtlinie, die den Netzwerktraffic zwischen zwei oder mehr Netzwerken regelt, zu implementieren, von denen einige unter Verwaltungssteuerung (z.B. Unternehmensnetzwerke) und andere nicht unter Verwaltungssteuerung (z.B. Internet) stehen können. Eine Netzwerkfirewall dient allgemein als die Hauptverteidigungslinie gegen externe Bedrohungen gegenüber den Computersystemen, Netzwerken und kritischen Informationen eines Unternehmens. Firewalls können auch verwendet werden, um Netzwerke zu partitionieren oder VPN zu isolieren oder zu verbinden. Firewalls verwenden verschiedene Entscheidungsprozesse, wie beispielsweise Paketfiltern, Anwendungsproxies und dynamisches Filter (Stateful Inspection), um ungewünschte Pakete vom Eintreten/Austreten in das oder aus dem geschützten Netzwerks auszufiltern. Solche Entscheidungsprozesse werden unten eingehender dargelegt.
  • Neben diesen sicherheitsbezogenen Filterfunktionen können Firewalls auch Routingfunktionen ausführen, die mit dem geschützten Netzwerk verbunden sind, und die herkömmlich mit einem separaten/individuellen Router verbunden sind. Routing ist ein Entscheidungsprozess über die Disposition jedes Pakets, der durch die Routingvorrichtung gehandhabt wird. Dies gilt für eingehende Pakete, ausgehende Pakete, die ein Netzwerk für externe Ziele verlassen und für Pakete, die unter internen Netzwerken geroutet werden. Letztlich kann es nur zwei Dispositionen von Paketen geben: Weiterleiten oder Verwerfen. Der Routingmechanismus unterscheidet zwischen diesen beiden unter Verwendung der IP-Adresse in dem Paketkopf. Dieser Entscheidungsprozess wird durch eine Datenstruktur, die Routingtabelle genannt wird, geregelt.
  • Die Routingkonfiguration eines Firewallsystems gibt seine Sicht auf die topologische Konfiguration der Netzwerke, an die es angebracht ist, wieder. Eine Routingkonfiguration, die die Netzwerktopologie wiedergibt, wird allgemein so verwendet, dass die Firewall in der Lage sein wird, legitime Pakete an ihre gewünschten Ziele zu liefern. Die meisten Routingkonfigurationen von Firewallsystemen ändern sich selten und sind statisch. Die statische Natur der Routingkonfiguration rührt von dem Umstand her, dass Routingtopologieänderungen Konflikte zwischen Routing- und Filterrichtlinien für bestimmte Filterregeln erzeugen können.
  • Jedes Netzwerk, an das ein Firewallsystem angebracht ist, weist eine Prozedur zum Erhalten neuer IP-Adressen auf. Für das Internet wird diese am dem Internet-Serviceprovider (ISP) erhalten, der mit der Firewall verbunden ist. Für interne Netzwerk sollte eine fest zugewiesene IP-Adresse innerhalb des Unternehmens gegeben sein. Wenn dynamische IP-Adressen verwendet werden, sind möglicherweise, wie bekannt, zusätzliche Authentifizierungstechniken erforderlich.
  • Die Routingtabelle eines Firewallsystems enthält eine Liste von IP-Netzwerkadressen, für die das Firewallsystem Routingdienste bereitstellen wird. Jede Reihe der Tabelle beschreibt ein Netzwerk. Der Index, der verwendet wird, um auf eine Reihe in der Tabelle zuzugreifen ist die Zielnetzwerkadresse des gegenwärtig gerouteten Pakets. Wenn ein Tabellennachschlagen erfolgreich ist, stellt die Tabelle entweder die Adresse des nächsten Routen, an den das Paket gesendet werden soll, oder die Schnittstelle, die zum Aussenden des Pakets verwendet werden soll, bereit. Dieser nächste Router wird als das Zwischenziel verwendet und das Paket wird dorthin weitergeleitet. Wenn das Tabellenachsschlagen fehlschlagt, wird das Paket verworfen. Eine ICMP-(Internet Control Message Protocol)-"Unerreichbar"-Nachricht kann an die Quelle zurückgegeben werden und zeigt an, dass das Paket unzustellbar war.
  • Ungeachtet der verwendeten Routingtechnik wird der Routingmechanismus in der Regel nicht verwendet, um Sicherheitsrichtlinien zu implementieren. D.h. ein Routingmechanismus wird oftmals als zu dynamisch und unzuverlässig zur Ausführung von Sicherheitsfunktionen angesehen. Routinginformationen und Unterstützungsstrukturen sind in erster Linie dazu ausgelegt, Pakete effizient und zuverlässig; nicht sicher, weiterzuleiten. Daher bestehen Filtertechniken, die in Verbindung mit dem Betrieb einer Firewall (und/oder Router) für Sicherheitszwecke implementiert werden können und Beispiele davon (wie oben erwähnt) sind Paketfiltern, Anwendungsproxies und dynamisches Filtern (Stateful Inspection).
  • Paketfiltern an Router wird verwendet, um im möglichen Ausmaß nur autorisierten Netzwerktraffic zuzulassen. Paketfilter spezifizieren zu filternde (zu verwerfende) Pakete während des Routingprozesses. Diese Filterentscheidungen basieren in der Regel auf dem Inhalt der individuellen Paketköpfe (z.B. Quelladresse, Zieladresse, Protokoll, Port). Einige Paketfilterimplementationen bieten Filtermöglichkeiten, die auf anderen Informationen basieren; diese Implementationen werden in Verbindung mit der unten beschriebenen Stateful Inspection eingehender erörtert.
  • Allgemein ausgedrückt bieten Paketfilterrouter den Firewallmechanismus mit der höchsten Leistung. Sie sind jedoch schwieriger zu konfigurieren, da sie auf einer niedrigeren Ebene konfiguriert werden, wodurch sie ein eingehenderes Verständnis von Protokollen erfordern.
  • Paketfiltern ist der Prozess des Entscheiden der Disposition jedes Pakets, das möglicherweise durch einen Router mit Paketfiltern geleitet werden kann. Der Einfachheit halber kann angenommen werden, dass es nur zwei Dispositionen gibt: annehmen und zurückweisen. IP-Filtern stellt den Basisschutzmechanismus für einen routenden Firewallhost bereit und gestattet eine Bestimmung, welcher Traffic durchgeleitet wird, basierend auf dem Inhalt des Pakets, wodurch der Zugriff auf jedes der Netzwerke, der durch den Firewallrouter gesteuert wird, potenziell eingeschränkt wird.
  • Die für jede Filterregel zum Bestimmen der Disposition verwendeten Kriterien können willkürlich komplex sein. Für einen Router mit Paketfiltern kann es mehrere Punkte in dem Routingprozess geben, an denen Regel angelegt werden. Normalerweise werden sie für ankommende Pakete zu der Zeit angelegt, wenn ein Paket empfangen wird, und für ausgehende Pakete werden sie unmittelbar vor dem Senden eines Pakets angelegt. Es kann zu jedem Punkt, wenn Filter angelegt wird, verschiedene Regelgruppen geben. Wenn die gesamte Sicherheitsrichtlinie in Paketfiltern implementiert werden kann, sind andere Frewallmechanismen möglicherweise nicht erforderlich. Wenn einige Elemente der Filterrichtlinie nicht mit Paketfiltern implementiert werden können, sind zusätzliche Frewallmechanismen, wie Proxies, möglicherweise erforderlich.
  • Ein Anwendungsproxy ist ein Anwendungsprogramm, das auf einem Firewallsystem zwischen zwei Netzwerken läuft. Der Firewallhost, auf dem der Proxy läuft, muss nicht notwendigerweise als ein Router fungieren. Wenn ein Clientprogramm eine Verbindung „durch" einen Proxy zu einem Zieldienst einrichtet, richtet es zunächst eine Verbindung direkt zu dem Proxyserverprogramm ein. Der Client verhandelt mit dem Proxyserver, damit der Proxy für den Client dann eine Verbindung zwischen dem Proxy und dem Zieldienst einrichtet. Wenn dies erfolgreich ist, sind zwei Verbindungen eingerichtet: eine zwischen dem Client und dem Proxyserver und eine andere zwischen dem Proxyserver und dem Zieldienst. Nach der Einrichtung empfängt der Proxy dann den Traffic bidirektional zwischen dem Client und dem Dienst und leitet ihn weiter. Der Proxy trifft alle Verbindungs-, Einrichtungs- und Paketweiterleitungsentscheidungen. Jedwede Routingfunktionen, die auf dem Hostsystem aktiv sind, sind für den Proxy allgemein irrelevant.
  • Als letztes Beispiel einer Sicherheitstechnik zum Betrieb auf einem Firewallrouter bezieht sich der Begriff „Stateful Inspection" oder dynamische Paketfilterung auf eine fähigere Gruppe von Filterfunktionen auf Routern. Paketfiltern ist allgemein darauf beschränkt, seine Filterentscheidungen nur auf der Grundlage der Kopfinformationen an jedem individuellen Paket zu treffen, ohne etwaige vorherige Pakete zu betrachten. Stateful-Inspection-Filtern ermöglicht sowohl komplexe Kombinationen von Nutzlast (Nachrichteninhalt) als auch Kontext, der zum Beeinflussen der Filterentscheidungen durch vorherige Pakete eingerichtet wurde. Wie beim Paketfiltern wird Stateful Inspection als ein „Zusatz" zum Routing implementiert.
  • Die Grundmotivation für die Stateful Inspection ist ein Kompromiss zwischen Leistung und Sicherheit. Als „Zusatz" zum Routing liefert die Stateful Inspection eine viel bessere Leistung als Proxies. Es stellt auch einen Zuwachs der Ebene von Firewallfunktionen bereit, welche über das einfache Paketfiltern hinausgehen. Wie bei den Proxies können viel komplexere Steuerkriterien spezifiziert werden und wie beim Paketfiltern hängt Stateful Inspection von einer hohen Qualität (d.h. korrekter) zugrundeliegender Routingimplementation ab.
  • Allgemein ausgedrückt gibt es gute Gründe zur Verwendung von Paketfiltern, Anwendungsproxies und/oder Stateful Inspection, abhängig von der Situation und dem Bedarf eines spezifischen Nutzen. Bestimmte Dienste (z.B. SMTP (Simple Mail Transfer Protocol), HTTP (Hypertext Transfer Protocol) oder NTP (Network Time Protocol) sind in der Regel sicher für die Steuerung über Paketfilter, während andere (z.B. DNS (Domain Name System), FTP (File Transfer Protocol) die nur bei Proxies verfügbaren komplexeren Merkmale erfordern können. Paketfiltern ist schnell, während Anwendungsproxies allgemein langsamer sind. In Fällen, in denen eine größere Zugriffskontrolle erforderlich ist und die schlechtere Leistung von Proxies nicht toleriert werden kann, können Stateful-Inspection-Paketfilter ein annehmbarer Kompromiss sein. In jedem Fall ist es, wenn möglich, vorteilhaft, so viele wie möglich verschiedene Funktionen (d.h. Paketfiltern, Proxies und Stateful Inspection) verfügbar zu haben, wobei sie jeweils dort angelegt werden, wo erforderlich.
  • Obwohl es viele Techniken zur Implementation und Sicherung von individuellen VPN gibt, wie oben dargelegt, besteht ein zusätzlicher Bedarf an VPN, die kreuzkommunizieren können, ohne zu Diensteinbußen für ihre Nutzer zu führen, z.B. ohne Verringerung der Sicherheit zwischen den beiden (oder mehreren) VPN oder innerhalb eines bestimmten der VPN.
  • Bei der Berücksichtigung der Schwierigkeiten, die mit der Verbindung mehrerer VPN untereinander verbunden sind, sollte berücksichtigt werden, dass ein VPN allgemein dazu aufgebaut ist, um einige allgemeine Probleme zu lösen. Zu diesen Problemen gehören beispielsweise die Virtualisierung von Diensten und die Abtrennung von Kommunikationen in geschlossene interessierende Gemeinschaften.
  • Wenn zwei verschiedene Netzwerke, die dieselben oder verschiedene VPN-Technologien verwenden, verbunden werden, müssen die VPN-Netzwerkverbindungsfunktionen somit mindestens die folgenden Grundsätze wahren: Sicherheit der Netzwerkfunktionen, Erhalten der Netzwerkintegrität, Interoperabilität der Dienste und Schutz der Daten. Zu Problemen, die aus diesen Grundsätzen entstehen gehören: Skalierbarkeit, Komplexität, Sicherheit, Kosten von Einsatz und Verwaltung.
  • Sicherheit, die wie bereits erörtert, in verschiedenen Formen implementiert werden kann, bedeutet allgemein das Verhindern von Hacken von Paketen, die aufgespürt, bei der Übertragung modifiziert oder durch nicht autorisierte Parteien einer Trafficanalyse unterzogen werden können. Außerdem bezieht sich Sicherheit auf das Vermeiden von Fehlkonfigurationsfehlern, die Löcher zwischen zwei oder mehr VPN bereitstellen.
  • Beim Verbinden verschiedener VPN untereinander, unabhängig davon, ob ein gegebenes VPN sich hinter einer Firewallvorrichtung befindet oder nicht, stellen einige zentralisierte VPN-Verwaltungswerkzeuge die sichere Konnektivität zwischen mehreren Kunden und mehreren Diensten über eine einzige Verbindung mit flexibler zentralisierter Verwaltung und Steuerung bereit. Sie vereinfachen sichere Verbindung und Verwaltung von Netzwerken mit inkompatiblem Routing oder Adresskonflikten. Sie sind allgemein auf die Art der verwendeten Ausrüstung und den Vendor beschränkt. Solche VPN sind zentralisiert und verfügen über kein sicheres Feedback.
  • Solche VPN-Systeme mit zentralisierter Konfiguration ermöglichen das Aufstellen von Netzwerkrichtlinien, die Hardwarevorrichtungen einbeziehen, sowie Nutzerregistrierungsfunktionen, um Netzwerkrichtlinien und Privilegien einzurichten. Diese herkömmlichen Systeme basieren auf dem, was als Zugriffssteuerliste („ACL") bekannt ist.
  • ACL-basierte Verwaltungssysteme verwalten im Wesentlichen ACL, die in Routern angesiedelt sind, welche den Trafficfluss steuern und ein bestimmtes Niveau von Zugriffssicherheit bereitstellen. Sie können auch das Überwachen von Nutzeraktivität ausführen, um zu bestimmen, wann Nutzer verbunden sind und wo sie, von einem Richtlinienstandpunkt, auf virtuelle LANs in dem Netzwerk abgebildet sind. ACL ermöglichen es Administratoren, Sicherheits- und Trafficsteuerrichtlinien für die Verwaltung verschiedener Vorrichtungen zu definieren gemäß der steuernden Firma, und sie werden allgemein auch verwendet, um den Internetzugriff zu sichern. ACL können zentral durch eine Templatebibliothek verwaltet werden. Zugriffslistenkonfigurationen können für Nutzergruppen und für Vorrichtungen und Netzwerkdienste, die in VPN verwendet werden, verwaltet werden.
  • Herkömmliche Lösungen für die Verbindung von VPN untereinander, insbesondere nicht-zentral verwaltete herkömmliche Lösungen, weisen hinsichtlich der globalen Kreuzprüfung von Vorrichtungen, jeder Art von Support der verbundenen Vorrichtungen und der Verbindung mit anderen Werkzeugen, wie Sicherheitswerkzeugen Mängel auf.
  • Beispiele für Lösungen zum Verbinden von VPN untereinander sind bekannt aus WO 01/16766 und EP 1093255 .
  • Auch wenn eine Technik zum Verbinden von VPN untereinander zentralisiert ist, verwenden solche herkömmlichen Konfigurationen außerdem dieselbe Technologie, d.h. ACL, die auf jede Vorrichtung in dem Netzwerk heruntergeladen werden. Somit können herkömmliche ACL-basierte VPN-Lösungen für die Verbindungsverwaltung nur dann verwendet werden, wenn dasselbe Werkzeug auf beiden Arten von verbundenen VPN betrieben wird. Daher sind allgemein mindestens einige manuelle ACL-Einstellungen notwendig, wenn ein nicht kompatibles Protokoll oder Ausrüstungsstück verwendet wird.
  • Außerdem ist die zentralisierte ACL-Konfiguration statisch und bietet sich nicht für die Automation an. Wenn ein anderes Konfigurationswerkzeug verwendet wird oder durch einen Nutzer, dem Zugriff gewährt worden ist (oder einen Nutzer, der Zugriff versehentlich oder unrechtmäßig erlangt hat), manuelle Modifikationen vorgenommen wurden, gibt es keine direkte Verifikation des Nutzers und/oder des Systems, um auf Fehler oder andere Probleme hin zu prüfen.
  • Eine ACL kann auch die Form einer Filteraussage in Firewalls annehmen, aber weiter denselben Mechanismus, wie oben beschrieben, verwenden. Manchmal werden verschiedene ähnliche Regeln in hintereinandergeschalteten Geräten dupliziert, da ein Vertrauensmangel hinsichtlich dessen besteht, was in anderen Vorrichtungen definiert worden ist. Die Verwendung von ACL hat eine große Auswirkung auf Ressourcen und Leistung in allen Vorrichtungen, so dass jede Vereinfachung die Netzwerkleistung merklich verbessern würde.
  • Als ein letzter Punkt, der sich herkömmlichen Techniken zur Kreuzverbindung von Vorrichtungen in verschiedenen VPN bezieht, ist es für Administratoren von z.B. Firewallroutern möglich, Tabellen zum Verwalten der VPN und der Kreuzverbindungen dazwischen zu führen. Solche Techniken sind jedoch nur für statische Konfigurationen von VPN gangbar, d.h. das/die VPN müssen neu konfiguriert und neu eingestellt werden, bevor eine neue Sendestrecke zwischen den beiden VPN stattfinden kann. Daher ist die Implementation dieser Techniken zu langsam und sie können nicht leicht skaliert werden. Außerdem erfordern solche Techniken die Kenntnis von Kundenparametern von Seiten des Administrators/der Administratoren und können daher möglicherweise nicht ein gewünschtes Niveau von Datenschutz und Sicherheit auf der Seite des/der VPN-Kunden liefern.
  • Kurz gefasst gibt es gegenwärtig keinen herkömmlichen Ansatz, der die Verbindung von VPN auf eine sichere, effiziente, skalierbare, verlässliche, dynamische und dezentralisierte Weise ermöglicht Dieses Ziel wird durch ein Verfahren mit den Merkmalen von Anspruch 1 gelöst.
  • KURZDARSTELLUNG DER ERFINDUNG
  • Die vorliegende Erfindung ermöglicht gemäß einem Beispiel durch Verwalten eines Verbindungsprozesses an einer oder mehreren Stellen, einschließlich beispielsweise einer Firewall- oder einer Gatewayvorrichtung, die Verbindung von VPN untereinander. Die Firewall- oder Gatewayvorrichtung hat Informationen, die sich auf eine Vielzahl von VPN beziehen, und kann die Verbindung zwischen Vorrichtungen in mindestens zwei der VPN erleichtern, indem sie bestimmt, dass eine Vorrichtung in der Tat ein Mitglied des ersten VPN ist, und indem sie Verbindungsparameter des ersten VPN zu dem zweiten VPN auf einer bedarfsweisen Basis weiterleitet. Auf diese Weise ermöglicht die Firewall, das Gateway oder die ähnliche Einrichtung die Verbindung, ohne dass ein vollständig zentralisierter Entscheidungsprozess benötigt wird, unabhängig von der Art der verwendeten Vorrichtung und/oder VPN(s). Außerdem kann die Firewall, das Gateway oder die ähnliche Vorrichtung nur diejenigen VPN-Parameter implementieren, die von beiden VPN gebraucht werden, um miteinander mit einem gewünschten Maß an Sicherheit zu kommunizieren, wodurch die mit der eigentlichen, über die Verbindung stattfindenden Kommunikation assoziierten Routing- und Weiterleitungsprozesse vereinfacht werden. Die mit der Vielzahl von VPN und ihren jeweiligen Mitgliedsvorrichtungen verbundenen Informationen können in einer Abbildungstabelle in der Firewall, dem Gateway oder der ähnlichen Vorrichtung gespeichert werden, und Identifikationsparameter einer Vorrichtung, die eine Verbindung sucht und/oder assoziierte VPN-Parameter können durch Verwendung digitaler Zertifikate verifiziert werden.
  • Gemäß einem ersten Beispiel der Erfindung wird ein Verfahren offengelegt, das es einer ersten Vorrichtung ermöglicht, auf einem Virtuellen Privaten Netzwerk (VPN) mit einer zweiten Vorrichtung außerhalb des VPN zu kommunizieren. Das Verfahren kann die Authentifizierung, an einer Verbindungsvorrichtung, der ersten Vorrichtung als ein Mitglied des VPN enthalten. Das Verfahren kann ferner die Identifizierung, an der Verbindungsvorrichtung, von VPN-Parametern enthalten, die mit dem Verbinden und Weiterleiten von Merkmalen des VPN verbunden sind. Schließlich kann das Verfahren das Weiterleiten von Daten von der ersten Vorrichtung an die zweite Vorrichtung über das VPN und die Verbindungsvorrichtung enthalten, wobei der Weiterleitungsvorgang auf den VPN-Parametern basiert.
  • Gemäß einem zweiten Beispiel der Erfindung wird ein Verfahren zum Weiterleiten von Kommunikationen von einer ersten Vorrichtung in einem Virtuellen Privaten Netzwerk (VPN) zu einer zweiten Vorrichtung über eine Verbindungsvorrichtung offengelegt. Das Verfahren kann den Empfang einer Identifikationsinformation von der ersten Vorrichtung an einer Filter- und Weiterleitungsmaschine innerhalb der Verbindungsvorrichtung, das Weiterleiten der Identifikationsinformationen an ein Steuersubsystem innerhalb der Verbindungsvorrichtung und die Authentifizierung der ersten Vorrichtung als ein Mitglied eines VPN durch Bestätigen an dem Steuersubsystem von mit dem VPN assoziierten VPN-Parameter enthalten. Ferner kann das Verfahren die Bereitstellung von VPN-Parametern an die Filter- und Weiterleitungsmaschine enthalten sowie das Weiterleiten der Kommunikationen von der ersten Vorrichtung zu der zweiten Vorrichtung über die Filter- und Weiterleitungsmaschine und in Übereinstimmung mit den VPN-Parametern.
  • Gemäß einem dritten Beispiel der Erfindung wird eine Verbindungsvorrichtung offengelegt, die die Kommunikationen zwischen einer ersten Vorrichtung in dem Virtuellen Privaten Netzwerk (VPN) und einer zweiten Vorrichtung, die sich nicht in dem VPN befindet, ermöglicht. Eine solche Verbindungsvorrichtung könnte eine Abbildungstabelle, die VPN-Informationen enthält, welche die Funktionen des VPN beschreibt, eine Filter- und Weiterleitungsmaschine, die wirksam ist, um Identifikationsinformationen zu empfangen, welche sich auf die erste Vorrichtung beziehen, und ein Steuersubsystem, das wirksam ist, um die erste Vorrichtung basierend auf den Identifikationsinformationen zu authentifizieren, wobei das Steuersubsystem ferner wirksam ist, um die VPN-Informationen innerhalb der Abbildungstabelle so zu modifizieren, dass die Filter- und Weiterleitungsmaschine die Kommunikationen von der ersten Vorrichtung zu der zweiten Vorrichtung in Übereinstimmung damit sendet, enthalten.
  • Gemäß einem vierten Beispiel der Erfindung wird ein Herstellungsartikel mit einem computerlesbaren Medium mit darin gespeichertem Computerprogramm, welches ein Verfahren zum Verbinden einer ersten Vorrichtung in einem Virtuellen Privaten Netzwerk (VPN) mit einer zweiten Vorrichtung, die sich nicht in dem VPN befindet, ausführt, offenbart. Ein solches Computerprogramm könnte ein erstes Codesegment zum Empfangen einer Authentifizierungsanforderung von der ersten Vorrichtung, ein zweites Codesegment zum Authentifizieren der ersten Vorrichtung als Mitglied des VPN in Reaktion auf die Authentifizierungsanforderung, und ein drittes Codesegment zum Bestimmen von Routing- und Weiterleitungsparametern, die mit einem Intra-VPN-Datentraffic assoziiert sind, enthalten. Schließlich könnte ein solches Computerprogramm auch ein viertes Codesegment zum Implementieren der Routing- und Weiterleitungsparameter hinsichtlich der Kommunikationen zwischen der ersten Vorrichtung und der zweiten Vorrichtung enthalten.
  • Gemäß einem fünften Beispiel der Erfindung wird ein System zum Kreuzverbinden einer ersten Vorrichtung in einem ersten Virtuellen Privaten Netzwerk (VPN) mit einer zweiten Vorrichtung in einem zweiten VPN offenbart. Ein solches System könnte ein Identifikationssubsystem, das wirksam ist, um die erste Vorrichtung und die zweite Vorrichtung zu identifizieren und entsprechende Identifikationsinformationen auszugeben, enthalten. Das System könnte ferner ein Authentifikationssubsystem enthalten, das wirksam ist, um die Identifikationsinformationen zu empfangen und die erste Vorrichtung und die zweite Vorrichtung als Mitglieder des ersten VPN bzw. des zweiten VPN darauf basierend zu authentifizieren und die Authentifikationsinformationen dementsprechend auszugeben. Solche Authentifikationsinformationen könnten eine erste Gruppe von Regeln, die die Datensendung über das erste VPN regeln, und eine zweite Gruppe von Regeln, die die Sendung über das zweite VPN regeln, enthalten. Schließlich könnte ein solches System ein Anpassungssubsystem enthalten, das wirksam ist, um die Authentifikationsinformationen zu empfangen und die erste Gruppe von Regeln an die zweite Gruppe von Regeln anzupassen, so dass es zu einer sicheren Sendung zwischen der ersten und der zweiten Vorrichtung über das erste und zweite VPN kommt.
  • Gemäß einem sechsten Beispiel der Erfindung wird ein Verfahren zum Verbinden einer ersten Vorrichtung in einem ersten Virtuellen Privaten Netzwerk (VPN) mit einer zweiten Vorrichtung in einem zweiten VPN offengelegt. Ein solches Verfahren könnte den Empfang an einer Verbindungsvorrichtung eines ersten Zertifikats, das die Eigenschaften der ersten Vorrichtung und des ersten VPN identifiziert, sowie den Empfang eines zweiten Zertifikats an der Verbindungsvorrichtung enthalten, welches die Eigenschaften der zweiten Vorrichtung und des zweiten VPN identifiziert. Somit kann die Verbindungsvorrichtung wirksam sein, um das erste und zweite Zertifikat zu vergleichen und Informationen bezüglich einer vorbestimmten Anzahl von VPN, von denen das erste und das zweite VPN eine Untergruppe sind, speichern, wodurch die Verbindung der ersten Vorrichtung und der zweiten Vorrichtung auf der Basis des Vergleichvorgangs ermöglicht wird.
  • Schließlich wird gemäß einem siebten Beispiel der Erfindung ein System zum Verbinden einer ersten Vorrichtung in einem Virtuellen Privaten Netzwerk (VPN) mit einer zweiten Vorrichtung, die sich nicht in dem VPN befindet, offengelegt. Ein solches System kann Mittel zum Authentifizieren der ersten Vorrichtung als Mitglied des VPN, Mittel zum Herstellen von VPN-Parametern, die mit dem ersten VPN assoziiert sind, und Mittel zum Senden von Kommunikationen zwischen der ersten Vorrichtung und der zweiten Vorrichtung basierend auf den VPN-Parametern enthalten.
  • Die Merkmale und Vorteile der Erfindung werden am den folgenden Zeichnungen und Beschreibungen ersichtlich.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die vorliegende Erfindung wird mit Bezug auf die beigefügten Zeichnungen beschrieben. In den Zeichnungen bezeichnen ähnliche Bezugszahlen identische oder funktionell ähnliche Elemente. Außerdem kennzeichnet die linken) Ziffern) einer Bezugszahl die Zeichnung, in der die Bezugszahl zuerst erscheint.
  • 1 ist eine schematische Ansicht einer Netzwerkumgebung, die ein Beispiel der vorliegenden Erfindung veranschaulicht.
  • 2 zeigt interne Gatewayfunktionen und externe Vorrichtungen, die in einer Hardwarerepräsentation eines Beispiels der vorliegenden Erfindung involviert sind.
  • 3 zeigt Beispiele von Flüssen, die zwischen externen Vorrichtungen, die gemäß einem Beispiel der Erfindung zwischen externen Vorrichtungen, die eine VPN-Verbindung mit einem Verbindungsgateway herstellen, auftreten können.
  • 4 zeigt eine VPN-Abbildungstabelle gemäß einem Beispiel der Erfindung.
  • 5 zeigt Flüsse, die zwischen involvierten internen Gatewayfunktionen auftreten, um die Verbindung zweier VPN gemäß einem Beispiel der Erfindung einzurichten.
  • 6 zeigt eine Zertifikatstruktur, die in einem Beispiel der Erfindung verwendet wird.
  • Während die vorliegende Erfindung unten mit Bezug auf verschiedene beispielhafte Beispiele beschrieben wird, ist die vorliegende Erfindung nicht auf diese offengelegten Beispiel beschränkt. Andere Beispiele können durch Fachleute implementiert werden, ohne von dem Umfang der vorliegenden Erfindung abzuweichen.
  • Die vorliegende Erfindung stellt gemäß einem Beispiel eine Verbindungsvorrichtung bereit, die eine VPN-Abbildungstabelle enthält, welche speziell konstruierte Zertifikate verwendet, um VPN-Eigenschaften des Nutzers und/oder einer Vorrichtung, mit denen eine Verbindung eingegangen wird, zu identifizieren, und vergleicht diese Eigenschaften mit einer anderen Vorrichtung. Gemäß diesem Beispiel ist die Verbindungsvorrichtung in der Lage, VPN-Verbindungen automatisch zuzulassen, ohne dass ein Bedarf an einem zentralisierten Entscheidungsprozess besteht. Die Verbindungsvorrichtung implementiert alle VPN-Regeln von einem oder beiden der verbindenden VPN, welche für eine sichere Verbindung notwendig sind. Außerdem ist dieses Beispiel der Erfindung von den Arten der Vorrichtung und Arten von VPN-Technologien, die verwendet werden.
  • In einem Beispiel erleichtert die vorliegende Erfindung dann die sichere Verbindung zwischen einem VPN, auf dem Zertifikate aufgebaut wurden, um VPN-Eigenschaften des Nutzers oder der Vorrichtung, zu denen eine Verbindung eingegangen wird, zu identifizieren, und einem VPN, auf dem ebenfalls Zertifikate aufgebaut worden sind, um VPN-Eigenschaften des Nutzers oder der Vorrichtung, zu denen eine Verbindung eingegangen wird, zu identifizieren. Zertifikatvergleich und Anpassungsanalyse durch die Verbindungsvorrichtung ermöglicht oder verhindert den VPN den Austausch von Daten und Routen.
  • Ein Beispiel der Erfindung, das mit diesen Techniken zur Verbindung verbunden ist, ist dafür vorgesehen, spezifische Zertifikatfelder innerhalb einer Vorrichtung oder Nutzerzertifikate zur Ausführung der Verbindung von VPN zu definieren und aufzubauen. Eine in der Verbindungsvorrichtung gespeicherte VPN-Abbildungstabelle kann alle VPN eines definierten Netzwerks repräsentieren. Außerdem schlägt ein Beispiel der vorliegenden Erfindung eine Vorrichtung vor, die solche Verfahren zum Aufbau eines Verbindungsgateways optimiert.
  • Die vorliegende Erfindung stellt somit eine globale Lösung bereit, die nicht direkt mit der Art von Vorrichtung oder der verwendeten VPN-Technologie verknüpft ist, aber dennoch eine sehr sichere Identität für das VPN bereitstellt, wenn eine Verbindung durchgeführt werden muss. Die Vorrichtung, die die Verbindung ausführt, kann ohne zentrale Steuerung oder Rekonfiguration der VPN-Verbindung das Addieren der erforderlichen Regeln automatisch entscheiden und zulassen, welche mit den für die VPN-Eintrittspunkten definierten Regeln beider VPN assoziiert sind. Die Verwendung digitaler Zertifikate in einem Beispiel der Erfindung ermöglicht den einfachen Einsatz der Erfindung. Die vorliegende Erfindung stellt eine hohe Sicherheitsebene sicher und kann für die Konfiguration einschließlich von Filter- und Routingregeln in dem Gateway und der Sicherheitsverwaltung verwendet werden, wodurch die verschiedenen Netzwerkverwaltungswerkzeuge integriert werden können.
  • Obwohl die vorliegende Erfindung in erster Link mit Blick auf das Kreuzverbinden separater Vorrichtungen in separaten VPN erörtert wird, versteht sich, dass nur eine Vorrichtung sich einem VPN befinden muss, damit die Erfindung nützlich ist. Die andere Vorrichtung muss sich nicht in einem separaten VPN befinden und kann beispielsweise ein Gateway, eine Firewall oder eine ähnliche Verbindungsvorrichtung sein.
  • Da die vorliegende Erfindung das dynamische Aktualisieren von VPN-Merkmalen einschließlich der Fähigkeit für Kreuzverbindungen ermöglicht, ist sie erheblich schneller und besser skalierbar, als herkömmliche Systeme aus dem Stand der Technik. Außerdem ermöglicht die vorliegende Erfindung VPN-Kunden, ihre VPN zu schaffen oder zu modifizieren, möglicherweise durch Schaffen oder Modifizieren ihres eigenen digitalen Zertifikats/ihrer eigenen digitalen Zertifikate. Auf diese Weise verfügen Kunden über eine größere Flexibilität und Leichtigkeit beim Verwalten ihres/ihrer VPN. In einem Beispiel der Erfindung können bestimmte solcher Parameter so geführt werden, dass nur der Kunde/die Kunden bestimmte Parameter schaffen oder modifizieren können und VPN-Administratoren werden daran gehindert, die Parameter zu ändern.
  • Nach der allgemeinen Beschreibung der Erfindung legt die folgende Erläuterung und die verbundenen Figuren bestimmte Beispiele ausführlicher dar.
  • 1 ist eine vereinfachte Darstellung zweier Netzwerke 140 und 180, die durch Gateway 160 verbunden sind (bei dem es sich, wie einem Durchschnittsfachmann klar sein dürfte, auch um eine Firewallvorrichtung handeln könnte und/oder verschiedene Routingfunktionalitäten aufweisen könnte). Jedes Netzwerk transportiert verschiedene Virtuelle Private Netzwerke (VPN), die verschiedenen Kundennetzwerken entsprechen können, welche dieselbe Infrastruktur verwenden, die einem Serviceprovider gehört.
  • In diesem Beispiel sind drei VPN 105, 115 und 125 über das Netzwerk 170 dargestellt, wobei nur eine abgesetzte Vorrichtung über dieses VPN verbunden ist. Es versteht sich, dass allgemein eine Vielzahl von Vorrichtungen mit jedem VPN verbunden sein kann, da jedoch das beschriebene Beispiel jede Vorrichtung separat handhabt, reicht eine einzige Vorrichtung pro VPN aus, um den Prozess deutlich zu machen. Die drei abgesetzten Vorrichtungen, die im Netzwerk 170 dargestellt sind, sind: Vorrichtung 100, die über VPN 105 mit Gateway 160 verbunden ist; Vorrichtung 110, die über VPN 115 mit Gateway 160 verbunden ist, und Vorrichtung 120, die über VPN 125 mit Gateway 160 verbunden ist. Über das zweite Netzwerk 180 sind auf ähnliche Weise drei abgesetzte Vorrichtungen auch mit dem Gateway 160 verbunden: Vorrichtung 130 über VPN 135, Vorrichtung 140 über VPN 145 und Vorrichtung 150 über VPN 155.
  • In 1 wird angenommen, dass jedes VPN einen anderen Namen als Identifikationsparameter aufweist. Diese Annahme soll jedoch veranschaulichend und nicht einschränkend sein. Ein Virtuelles Privates Netzwerk globaler Kunden kann beispielsweise sowohl VPN 125 in Netzwerk 170 und VPN 155 in Netzwerk 180 oder VPN 115 und VPN 125 in Netzwerk 170 und VPN 155 in Netzwerk 180 enthalten. Anders ausgedrückt ist praktisch jede Kombination möglich und die Verwendung unterschiedlicher Namen/Bezugszahlen soll hier lediglich eine VPN-Verbindung deutlich identifizieren. Somit kann ein VPN-Identifizierer aus verschiedenen Feldern aufgebaut sein, die falls bevorzugt das VPN globaler Kunden, das Netzwerk, in dem das VPN eingerichtet wird, und/oder die Verbindung für dieses VPN darstellen.
  • Zwischen jedem VPN wird eine mögliche Verbindung eingerichtet dank VPN-Parametern, die entweder vorgeladen oder dynamisch geladen werden können. Die VPN-Parameter werden Routing- und Filterregeln definieren, die auf die zwischen den verbundenen Endvorrichtungen ausgetauschten Flüsse angelegt werden. Endvorrichtungen (100, 110, 120, 130, 140 und 150) können Hosts, Routingvorrichtungen, Gateways oder jede andere Vorrichtung sein, von der bekannt ist, dass sie mit Gateway 160 über ein VPN oder ein Netzwerk, wie Netzwerk 170 und 180, verbunden werden kann.
  • 2 zeigt die Funktionen, die in einem Gateway 160 mit externer Konnektivität mit abgesetzten Vorrichtungen, wie in 1 beschrieben, involviert sind, sowie als Verbindung zu anderen Vorrichtungen, einschließlich der Zertifikatauthorität (CA) 200 und PROXY-Server 205. Diese beiden Vorrichtungen werden in 3 ausführlicher beschrieben, sie stellen jedoch wohlbekannte Standardvorrichtungen dar. Allgemein speichert die Zertifikatauthorität 200 digitale Zertifikate für den Zweck der sicheren Vorrichtungs-VPN-Identifikation. Der Proxyserver 205 wird zum Implementieren der Anwendungsproxytechnik wie oben beschrieben verwendet.
  • Weder Komponente 200 noch 205 befindet sich aus Sicherheitsgründen in dem Netzwerk 170 oder 180. Vielmehr sind sie vorzugsweise mit einem lokalen Netzwerk oder einer fest zugewiesenen Verbindung verbunden. Die Komponenten 200 und 205 können in ein Datennetzwerk gebracht werden (wenn das Netzwerk als sicher genug angesehen wird) oder sie können mit einer gesicherten verschlüsselten Verbindung verbunden werden.
  • Die Zertifikatauthorität 200, die bekannt und oben erwähnt ist, verarbeitet digitale Zertifikate zum Implementieren sicherer Netzwerkverbindungen, wie VPN. Ein Zertifikat ist eine Struktur, die einen öffentlichen Wert (d.h. einen öffentlichen Schlüssel), der an eine Identität geknüpft ist, enthalten. Innerhalb einer spezifischen Art von Zertifikat, wie beispielsweise dem X.509-Zertifikat kann der öffentliche Schlüssel mit einem „Nutzernamen" verknüpft sein. Die CA 200 attestiert, dass der öffentliche Schlüssel zu dem Nutzer gehört, so dass, wenn ein Client ein Zertifikat von einem anderen Nutzer empfängt, die „Stärke" der Verbindung zwischen dem öffentlichen Schlüssel und der Identität abhängig von der Zuverlässigkeit der bestimmten verwendeten CA 200 variieren kann.
  • Ein X.509-Zertifikat weist insbesondere in einigen Aspekten eine sehr formale Struktur auf erhält jedoch in anderer Hinsicht einen Grad an Flexibilität. Diejenigen Elemente, die einem Zertifikat immer enthalten sind, sind wie folgt:
    Subjekt Dies ist der oben genannte „Nutzername", obwohl das Subjektfeld auch jeder Identitätswert sein kann. Eine Anzahl von Namenstellen wird unterstützt. Die voreingestellte ist X.500 Ausgezeichnete Namen (z.B. c=GB; o=Integrität, cn=hughes). Unterstützte alternative Namenstellen enthalten RFC822 E-Mail-Adresse (z.B. johnh@entegrity.com).
  • Ausgeber Dies ist der Name der dritten Partei, die dieses Zertifikat ausgegeben/erzeugt hat, das heißt, die Zertifikatauthorität 200. Es werden dieselben Namenstellen wie für das Subjektfeld definiert verwendet.
  • Öffentlicher Wert Dies ist die Öffentlicher-Schlüssel-Komponente eines Öffentlichen/Privaten-Schlüsselpaars. Ein assoziiertes Feld definiert den verwendeten öffentlichen Schlüsselalgorithmus, beispielsweise, ob es ein RSA, Diffie-Hellmann oder DSA öffentlicher Schlüssel ist.
  • Gültigkeit Zwei Felder werden verwendet, um zu definieren, von wann das Zertifikat gültig ist und bis wann es gültig ist. Zusammen stellen sie die Gültigkeitszeitdauer bereit.
  • Seriennummer Dies ist ein Feld, das eine eindeutige Zertifikatseriennummer für den Ausgeber des Zertifikats bereitstellt.
  • Unterschrifft So werden Subjektidentität und Öffentlicher Wert miteinander verbunden. Die Signatur ist eine digitale Signatur, die durch die CA 200 oder das ganze Zertifikat unter Verwendung des privaten Schlüssels der CA erzeugt wird. Durch Unterschreiben des Zertifikats „zertifiziert" die CA, dass das Subjekt der „Inhaber" des öffentlichen Schlüssels ist und daher den entsprechenden privaten Schlüssel hat.
  • X.509 Version 3 („V3") ist eine Version von X.509, die zu dem Original-X.509-Zertifikatformat einen Erweiterungsmechanismus zufügt. Zertifikaterweiterungen können in Standardfeldern oder Nutzergemeinschaften definiert werden. Einige Beispiele für Zertifikaterweiterung sind: alternative Namensformen, Schlüsselidentifizierer, Schlüsselnutzung, Subjektattribute, Zertifikatrichtlinien und Beschränkungen.
  • Es können auch zusätzliche Erweiterungen gebaut werden. Wie unten ausführlicher erläutert wird, erwägt ein Beispiel der vorliegenden Erfindung die Integration von Erweiterungen für VPN-Identifikationen und verwandte Regeln, wodurch die Verbindung sich die durch die digitalen Zertifikate bereitgestellte Sicherheit zu Nutze machen kann.
  • In 2 verwendet jede mit Gateway 160 verbundene Vorrichtung einen fest zugewiesenen Endpunkt, bei dem es sich um eine Schnittstelle oder eine logische Unterschnittstelle, wie einer Privaten Virtuellen Schaltung (PVC) oder einen Tunnelendpunkt handeln kann. Spezifischer enden die Vorrichtungen 100, 110, 120, 130, 140 und 150, die jeweils über VPN 105, 115, 125, 135, 145 und 155 verbunden sind, in dem Beispiel aus 2 ihre Verbindungen in Schnittstellenblöcken INTFA 251, INTFB 252, INFTFC 253, INTFD 254, INTFE 255 bzw. INTFF 256.
  • An diesen Endpunkten werden die niedrigen Schichten (z.B. Schicht 1 und 2) von den Paketen entfernt, um den IP-Rahmen freizulegen. Der Rahmen könnte ein reines IP-Paket eines Hosts sein oder ein eingekapseltes IP-Paket, im Fall beispielsweise von PRE oder IPSec-Tunnelung. Das an einer Schnittstelle empfangene IP-Paket wird von dem Schnittstellenblock (251-256) an die verbundenen Funktionsblöcke gesendet, die hier als Filter- und Weiterleitungsmaschinen F&FE bezeichnet werden, 261, 262, 263, 264, 265 und 266. F&FE 261-266 können teilweise verwendet werden, um beispielsweise Paketfiltern wie oben beschrieben zu implementieren.
  • Paketinformationen enthalten beispielsweise Paketkopfinformationen (z.B. Quelladresse, Zieladresse, Protokoll, Quellport, Zielport, Paketlänge, Verbindungsstatusinformationen) sowie Paketnutzlast (z.B. Nachrichteninhalt). Auf einige oder alle dieser Informationen kann abhängig von der eigentlichen Implementation des Paketfiltermechanismus in den F&FE-Blöcken in Filterregeln verwiesen werden.
  • F&FE 261-166 haben somit verschiedene Funktionen. Beispielsweise identifizieren sie das Paket und, wenn sie eine IP-Weiterleitungsfunktion implementieren, können sie jedes bekannte Paket weiterleiten oder filtern (gemäß Eingabe- und Ausgaberegeln).
  • Wenn eine neu verbundene Vorrichtung Kommunikationen mit einem F&FE-Block einrichtet (oder in anderen Fallen, wenn Filter- und Weiterleitungsregeln nicht definiert sind), versucht der F&FE-Block, die IP-Vorrichtung, die versucht, eine Verbindung einzurichten, zu identifizieren. Dies kann unter Verwendung einer IP-Quelladresse, die in einem eingehenden Paket gefunden wird, durch eine Rundsendung auf der Strecke oder durch Verwendung einer alternativen Identifikation wie Nutzerauthentifikation erfolgen. Es kann auch eine Vorrichtung ohne eine zugewiesene IP-Adresse sein, die zu Verbindungszwecken eine anfordert.
  • In einem der oben genannten Falle muss die abgesetzte Vorrichtung durch Bestimmen beispielsweise ihrer IP-Adresse, USERID, Name oder anderer solcher Parameter identifiziert werden. Unter Verwendung dieser Informationen sendet der F&FE-Block (z.B. F&FEA 261) eine Anfrage an STEUERUNG-Block 220 über Leitung 212, um ein Nutzerzertifikat oder ein assoziiertes VPN-Zertifikat von einer externen CA 200 zurückzugeben, um zu einer Authentifizierung der verbindenden Vorrichtung fortzuschreiten.
  • An diesem Punkt kann eine Altvorrichtung oder ein digitales Nutzerzertifikat verwendet werden. Ein Administrator kann digitale VPN-Zertifikate als volle Zertifikate einschließlich Nutzer- oder Vorrichtungsparameter implementieren oder kann nur einen Zeiger auf ein Altgerät (oder digitales Nutzerzertifikat) auf ein spezialisiertes digitales Zertifikat setzen, welches nur VPN-Parameter bereitstellt. Dies kann als eine indirekte oder indizierte Zugriffsmethode auf den VPN-Teil eines Vorrichtungszertifikats gesehen werden. In der Beschreibung des hierin erläuterten Beispiels der Erfindung wird ein allgemeines globales digitales Zertifikat verwendet, das sowohl als Altparameter als auch VPN-Parameter enthält.
  • Die Vorrichtungsauthentifizierung erfolgt gemäß dem wohlbekannten ISAKMP-Prozess unter Verwendung einer Sicherheitsassoziation, die beispielsweise zwischen der Vorrichtung 100 und dem Steuerblock 220, wie eingehender mit Bezug auf 3 beschrieben, eingerichtet wird. An dieser Stelle kann kein an VPN 105 ankommender Traffic durch Gateway 160 zu einem anderen VPN geleitet werden, solange die Peer-Vorrichtung nicht authentifiziert und die Regeln zum Routing und Filter nicht definiert sind.
  • Wenn die Verbindung für VPNA 105 authentifiziert ist, decodiert der Steuerblock 220 die VPN-Informationen, die in dem VPN-Zertifikat, das der VPN 105 entspricht, enthalten sind, und stellt mindestens der F&FEA 261 (und möglicherweise anderen F&FE-Blöcken, wenn nötig) die Filter- und Routingparameter und einen Zeiger auf einen F&FE-Block 261 für eine Virtuelle-Router- Verhandlungbereit. Dies erfolgt über Leitungen oder Leitungsgruppen 212 und 214, bei denen es sich um einen seriellen Bus oder einen anderen herkömmlichen Bus handeln kann.
  • Es sei darauf hingewiesen, dass die Verwendung eines gemeinsam benutzten Busses wie 210 für die Weiterleitung von Daten-, Steuerungs- und Routingfunktionen auch für die vorliegende Erfindung angedacht wird, aber die Verwendung fest zugewiesener Busse oder Leitungen ermöglicht, dass die in 2 gezeigten Verbindungen nur als Hardwareverbindungen angesehen werden. Das Implementieren eines gemeinsam verwendeten Busses 210 kann andererseits in einer reinen Softwareumgebung in einem Server erfolgen.
  • In Situationen, in denen zwischen VPN Routing erforderlich ist, kann ein Virtueller Router (Routingblock) unter diesen VPN gemeinsam benutzt werden, um eine gemeinsame Routingtabelle aufzubauen. Jedes VPN, das seinen virtuellen Router gemeinsam benutzt, aktualisiert die gemeinsame Tabelle, welche dann als eine Routingsteuerstelle angesehen werden kann. Ein Teil dieser Routingtabelle wird dann mit regelmäßigen Aktualisierungen (oder bei allen Anderung(en) anderer Weiterleitungsfunktion jedes F&FE 261-266) heruntergeladen. Jede Aktualisierung oder jedes Herunterladen kann abhängig von bestimmten Routingregeln für jedes VPN unterschiedlich sein. Somit kann eine Gruppe Virtueller Router implementiert werden, die in 2 als VR1 bis VR5 231-235 gezeigt sind.
  • Als ein Beispiel können F&FEA 261 und F&FED 264 einen gemeinsamen virtuellen Router VR1 231 in der Verbindung von VPNA 105 bis VPND 135 verwenden (viele der mit diesem Beispiel verbundenen Prozessschritte werden mit Berg auf 3 und/oder 5 eingehender beschrieben). Das erste verbundene und authentifizierte VPN fordert einen virtuellen Router an, wenn die mit diesem VPN assoziierten Regeln implizieren, dass die Verwendung davon notwendig ist. In diesem Beispiel wurde F&FED 264 VR1 231 vor einer Verbindung von Vorrichtung 100 durch VPNA 105 zugewiesen.
  • Wenn das zweite VPN verbunden ist (in diesem Fall VPNA) wird eine Gruppe von Steuernachrichten zwischen F&FEA 261 und F&FED 264 ausgetauscht und ein Zeiger auf VR1 231 wird durch F&FED 264 an F&FEA 261 bereitgestellt. Eine Routingtabelle in VR1 kann dann unter Verwendung von Routingbus 216 aktualisiert werden und Weiterleitungsfunktionen auf beiden Seiten werden parallel aktiviert.
  • In diesem Beispiel wird angenommen, dass VPN-Filterregeln gesetzt worden sind entweder von den Zertifikaten oder von vorher konfigurierten Werten in den VPN-Filtertabellen. Wenn dies in Zertifikaten erfolgt, werden Filteregeln und Parameter in Stellungnahmen umgewandelt, die durch das Gateway 160 verstanden werden, wie beispielsweise Zugriffssteuerlisten (ACL, wie oben ausführlich beschrieben). In diesen Fällen kann eine einzelne aktuelle Stellungnahme einen Parameter zu einer Zeit aufbauen mit der Option, jeder in einer Tabelle gezeigten Stufe zu folgen.
  • ACL kann an einer Medienzugriffssteuer-(MAC)-Adresse, IP-Adresse (Quelle/Ziel), Protokollart und Portnummer oder anderen bekannten Parametern wirken. Eine ACL-Stellungnahme kann an eine Schnittstelle, Unterschnittstelle, virtuelle Schaltung oder Tunnel angelegt werden, entsprechend der definierten VPN-Schnittstelle.
  • Das Weiterleiten von Daten kann dann wie in 5 direkt zwischen den Blöcken F&FEA 261 und F&FED 264 über Datenbus 210 starten. Es kann eine direkte Sendung sein, wenn Paketfiltern aktiviert ist, oder Pakete können von F&FEA 261 zu PROINT-Block 222 weitergeleitet werden, bei dem es sich um den Schnittstellenblock für die externe Firewallproxyfunktion 205 handelt. Wenn die Proxyanwendung läuft, wird ein weiteres Paket (d.h. eine modifizierte Version des von F&FEA 261 empfangenen Pakets) an F&FED 264 gesendet.
  • Es sei darauf hingewiesen, dass der Aufbau des Gateways des in 2 gezeigten und oben erläuterten Beispiels auf einer Mehrfachschichtfirewallarchitektur basiert, so dass alle eingehenden und ausgehenden Pakete durch beide Innen- und Außengatefunktionen laufen (d.h. die F&FE-Funktionen zwischen dem externen Netzwerk (Internet) und dem/den internen Netzwerk(en) bzw. die F&FE-Funktionen zwischen dem Außengateway und dem/den internen Netzwerk(en)).
  • Für die äußere F&FE-Funktion, z.B. F&FEA in dem obigen Beispiel, ist die Routingkonfiguration verhältnismäßig komplex und die Paketfilterregeln sind verhältnismäßig einfach. Die Formulierung der Routingkonfiguration und der Filterregeln muss daher separat und etwas aufeinanderfolgend erfolgen. Dagegen ist die Routingkonfiguration für die innere F&FE-Funktion, z.B. F&FEB in dem obigen Beispiel, verhältnismäßig einfach und die Paketfilterregeln sind allgemein komplexer. Somit sollte in diesem Fall die Routingkonfiguration und die Filterregeln gleichzeitig in dem digitalen Zertifikat formuliert werden. Bei beiden inneren und äußeren F&FE-Funktionen kann es notwendig sein, Regeln, die von verschiedenen digitalen VPN-Zertifikaten kommen, anzulegen. In diesem Fall werden Regeln hinzugefügt und wenn es einen Konflikt zwischen Regeln gibt, sollte die am meisten beschränkte und sicherste Regel implementiert werden. In diesem letzteren Fall kann eine Warnnachricht an einen Sicherheitsadministrator zur Prüfung geschickt werden.
  • 3 beschreibt die externen Flüsse zwischen Gateway 160, abgesetzte Vorrichtungen, wie Vorrichtung A 100, Proxyserver 205 und CA 200 gemäß einem Beispiel der Erfindung und entsprechend den oben mit Bezug auf 2 erläuterten Beispielen.
  • In 3 ist die Verwendung zweier Zertifikate veranschaulicht. Ein Zertifikat wird verwendet, um die Peer-Vorrichtungsidentität einzurichten und ein zweites Zertifikat wird verwendet, um das entsprechende VPN zu identifizieren. Wie in 2 beschrieben, wird, wenn ein neues VPN erfasst wird, die IP-Peer-Vorrichtung darauf erfasst und authentifiziert. Insbesondere wird das Vorrichtungsidentifikationszertifikat durch eine Anforderung 3000 and CA 200 (d.h. REQ_CERT_A) erhalten und das Zertifikat wird an Gateway 160 in Vorgang 305 (SD_CERT_A) bereitgestellt.
  • In 3 wird angenommen, dass IPSec als mindestens eine Basis für die VPN-Sicherheit verwendet wird. Dementsprechend wird eine Sicherheitsassoziation-(SA)-Phase 1 durch Gateway G initiiert (wie herkömmlich und wohlbekannt ist). Die SA-Phase-1-Gruppe von Nachrichten 310 werden von Gateway 160 an Adresse G1 an Vorrichtung A 100 gesendet, welche mit Nachricht(en) PH1AA 315 antwortet. Diese Nachrichten sind allgemein darauf gerichtet, weitere Trafficverhandlungen mittels beispielsweise des „Hauptmodus"-Abschnitts des SA-Phase-1-Austauschs zu schützen.
  • Wie bekannt ist der Hauptmodus dafür ausgelegt, Schutz für die Identität der involvierten Vorrichtungen bereitzustellen. Er ist in der Regel in drei Nachrichtengruppen unterteilt, wobei jede Gruppe zwei Nachrichten enthält. Die ersten beiden Nachrichten werden zum Verhandeln einer Sicherheitsrichtlinie für den Austausch verwendet, die mittleren beiden Nachrichten werden für einen Diffie-Hellmann-Schlüssel-Material-Austausch verwendet und die letzten beiden Nachrichten werden zum Authentifizieren der Peers, wie mit digitalen Signaturen und optionalen zusätzlichen digitalen Zertifikaten verwendet.
  • Die Option des Bereitstellens zusätzlicher digitaler Zertifikate an dieser Stelle kann eine sichere Option sein, die es Gateway 160 ermöglicht, digitale VPN-Zertifikate von CA 200 nur nach einer erfolgreichen gegenseitigen Authentifizierung zwischen Gateway 160 und Vorrichtung 100 zu erhalten. In diesem Fall wird Vorrichtung 100 Gateway 160 entweder einen Zeiger auf das Zertifikat oder einen Schlüssel zum Decodieren/Entziffern der verbundenen digitalen VPN-Zertifikate bereitstellen.
  • Es sei darauf hingewiesen, dass, während digitale Zertifikate nicht allgemein etwas sind, was geschützt werden sollte, das es hauptsächlich öffentliche Werte enthält, einige mit VPN-Zertifikaten verbundene Felder, wie beispielsweise IP-Adressen, Unternetzwerte und Filterregeln nicht offengelegt werden sollten. Daher sollten solche VPN-Zertifikate durch eine sichere Strecke transportiert werden. Somit kann Vorrichtung 100 in dem Beispiel aus 3 es vorziehen, das dazugehörige Zertifikat zu schützten und den Zugriff nur auf authentifizierte Vorrichtungen zu gestatten.
  • Unter der Annahme, dass die gegenseitige Authentifizierung der Vorrichtung 100 und des Gateways 160 zufrieden stellend abgeschlossen ist, wird Gateway 160 eine VPN-Zertifikatprüfung unter Verwendung einer Anforderungsnachricht 340 (REQ_CERT_VPN_A) anfordern und CA 200 wird mit einer Nachricht (oder einer Nachrichtengruppe) 345, die das Zertifikat enthält (SD_CERT-VPNA) antworten.
  • Das Zertifikat kann mittels eines durch Vorrichtung 100 in der vorherigen SA-Verhandlung gegebenen geheimen Schlüssels entziffert werden, oder ein komplexerer Mechanismus kann implementiert werden, wie beispielsweise, dass die Vorrichtung 100 den öffentlichen Verschlüsselungsschlüssel von Gateway 160 bereitstellt oder die Vorrichtung 100 Zulassung zu CA 200 gewährt, um Gateway 160 ihre VPN-Zertifikat bereitzustellen. Gateway 160 und CA 200 können auch untereinander eine SA beginnen (um eine sichere IPSec-Kommunikation aufzubauen oder können eine SLL (Secure Socket Layer) oder ein anderes sicheres Protokoll für das Herunterladen des Zertifikats verwenden.
  • Schließlich kann in 3 eine externe Verbindung 315 zu einem Proxy-Gateway-Server 205, der abhängig von benötigten Filterregeln optional ist, für einen Teil oder den gesamten Traffic zwischen den verbundenen VPN verwendet werden.
  • 4 stellt eine VPN-Abbildungstabelle für ein Netzwerk gemäß einer Ausführungsform der Erfindung dar. Eine solche Tabelle verwendet Parameter, die in einem Zertifikat von Vorrichtungen, wie Vorrichtung 100 zusammen mit Informationen von/über Gateway 160 definiert werden, um Informationen, die zur Verbindung von VPN nützlich sind, zu formulieren. Allgemein entspricht jede VPN-Tabelle einem gegebenen Netzwerk, wie Netzwerk 170 oder Netzwerk 180. Wenn das Gateway 160 mehr als ein Netzwerk unter Verwendung von Tabellen verwaltet, dann kann nur eine Tabelle pro Netzwerk implementiert sein. Beispiele von Feldern pro Tabelle, wie in Reihe 400 gezeigt, sind ein VPN-Identifizierer, die Gatewayschnittstelle (oder Schnittstellengruppe, wenn gemeinsam), auf denen dieses VPN aktiv ist, entsprechend Routing- und oder Filterparameter/-regeln und Listen von Unternetzen, für die die Regeln definiert sind.
  • In einer Ausführungsform der Erfindung wird an alle undefinierten Unternetze automatisch eine „Verweigerung" angelegt. Routingparameter enthalten, welcher virtuelle Router die Routingfunktion für dieses VPN verwaltet und die Art und Parameter für diese Routingfunktion. In dem Filterfeld aus Reihe 400 werden Firewallregeln, die an die F&FE angelegt werden, welche das in Frage stehende VPN verwalten, definiert.
  • In einer anderen Ausführungsform der Erfindung kann eine Haupttabelle verwendet werden, um einen Zeiger für jedes Feld bereitzustellen, der auf eine andere Tabelle oder Datei zeigt. Eine solche Tabelle kann insbesondere in den Fällen nützlich sein, in denen jedes Feld eine große Anzahl von Werten enthalten kann.
  • In einem Beispiel kann Netzwerk 180 diese Tabellenstruktur verwenden und die drei VPN 135, 145 und 155, die zu dem Netzwerk 180 gehören, können jeweils eine fest zugewiesene Reihe 410, 420 bzw. 430 in der Abbildungstabelle haben. In 4 benutzt VPND 135 in Reihe 410 die Schnittstelle INTFD 254 und Vorrichtung 130 handhabt Unternetz 194.200.6.0. Im Allgemeinen kann jede Vorrichtung ein anderes Netzwerk handhaben oder für eine Gruppe oder alle Vorrichtungen kann eine globale Stellungnahme definiert werden.
  • Das Gruppieren von Unternetzen kann die Filterleistung verbessern, indem die Anzahl von anzulegenden Regeln minimiert wird. Beispielsweise kann ein lokaler virtueller Router für VPND 135 VR1 sein und in 4 werden Routen als statisch für dieses VPN gezeigt, so dass die Liste von Routen explizit in diesem Feld gegeben werden kann. Eine Regelgruppe D ist definiert, welche eingehende und ausgehende Regeln, wie allgemein in Gateway 160 verwendet, enthalten kann.
  • Ähnlich ist VPNE 145 in Reihe 420 unter Verwendung einer anderen Schnittstelle (INTFE 255), einer anderen Unternetzliste, eines anderen Protokolls für das Routen und einer anderen Regelgruppe definiert. Auch wenn das Protokoll zufällig dasselbe ist, muss ein anderes Protokoll verwendet werden, wenn es auf einem separaten virtuellen Router läuft. In einigen Fällen kann ein gemeinsamer virtueller Router von verschiedenen VPN, die über dasselbe Netzwerk laufen, verwendet werden, aber auch in diesem Fall ist die Benennung für jedes VPN unterschiedlich (da die Filterregel eine Unterscheidung zwischen den VPN bereitstellt). Ähnlich können zwei VPN ähnliche Filterregeln haben, müssen aber immer noch separat und unabhängig verwaltet werden.
  • Schließlich mit Bezug auf die Reihen aus 4 stellt VPNF 155 Reihe 430 ein drittes unabhängiges VPN an einer anderen Schnittstelle (INTFF 256) bereit, die andere Unternetze aufweist, unter Verwendung eines anderen virtuellen Routers und Protokolls und anderer Gruppen von Firewallregeln.
  • In einer Ausführungsform der Erfindung können bestimmte Parameter innerhalb der Abbildungstabelle aus 4 nur durch VPN-Kunden geschaffen oder modifiziert werden und können durch einen Administrator von Gateway 160 nicht verändert werden. Gemäß dieser Ausführungsform der Erfindung kann eine Abbildungstabelle beispielsweise in Steuerblock 220 in einer Form gespeichert werden, die für einen Administrator von Gateway 160 nur lesbar ist aber für VPN-Kunden beschreibbar ist.
  • Für einige Arten von Netzwerken, die statische VPN betreiben, kann es einfacher sein, nur die Abbildungstabelle aus 4 anstelle von Zertifikaten zu verwenden. Wenn das Gateway 160 beispielsweise zu dem Netzwerk gehört, gibt es möglicherweise keine Sicherheitsprobleme, die das Einrichten von VPN-Routing- und Filterparameter direkt auf dem Gateway 160 erfordern.
  • In einem solchen Szenario kann ein Basisnetzwerk-VPN, wie beispielsweise ein MPLS-Netzwerk, VPN für alle Kunden definiert haben. Außerdem treten in einem solchen Szenario Veränderungen nicht so häufig auf (in der Regel nur, wenn ein neuer Kunde zugefügt werden muss, oder wenn es größere Änderungen in der bestehenden Kundeninfrastruktur gibt). Somit erfordern nur externe Verbindungen von dem Internet, andere externe Netzwerke, Verbindungen auf Anforderung oder DSL-Verbindungen in der Regel Authentifikation und dynamische Verbindung. In solchen Fallen erfolgt die VPN-Abbildung mit einer F&FE-Einheit, die Zertifikate verwendet, und einer F&FE-Einheit, die eine lokal gespeicherte F&FE-Tabelle verwendet.
  • 5 zeigt die Nachrichten- und Paketflüsse zwischen Funktionsblöcken innerhalb von Gateway 160. Die in 5 gezeigten Nachrichten/Paketflüsse entsprechen allgemein der Hardwarebeschreibung von Gateway 160 unter Bezug auf 2. Die beim Verbinden einer Vorrichtung in einem neuen VPN (hier Vorrichtung 100 in VPNA 105) durch das Verbindungsgateway involvierten Funktionsblöcke sind: die relevante Filter- und Weiterleitenmaschine 261, die Filter- und Weiterleitenmaschine(n) (hier ist nur F&FE 264 erforderlich) in den anderen VPN(s), mit denen das neue VPN eine Verbindung aufnehmen will, die virtuellen Router der bestehenden VPN (z.B. VR1 231), die notwendig sind, um VPNA 105 das Zufügen eines oder mehrerer Virtueller Router zu ermöglichen, Steuerblock 22, der für die Verwaltung der VPN-Verbindung/Authentifizierung/Zertifikat verwendet werden soll und (optional) Block PROINT 222, der als Schnittstelle zum externen Proxyserver 205 verwendet wird, falls dies durch die Filterregeln erforderlich ist.
  • Wenn Vorrichtung 100 eine VPN-Verbindung anfordert, wird sie innerhalb von Gateway 160 mit einem Funktionsblock 160 verbunden, der Firewall- und Weiterleitungsmaschine genannt wird (F&FEA 261) und der, nachdem von Steuerblock 220 in Vorgang 510 Authentifikation angefordert wurde (Nachricht ACC_REQ_A erhält Regelnachricht 515 (REGELN A) die seiner Gruppe entsprich). Die Regelnachricht 515 könnte beispielsweise ein digitales Zertifikat enthalten, das die zu implementierenden Regeln enthält, welches Zertifikat durch Steuerblock 220 decodiert und in verschiedene Teile aufgeteilt wird.
  • Eine weitere Regelgruppe wird an den ausstehenden F&FED-Block 264 unter Verwendung von Nachricht 520 (ACC_GRD_A) gesendet, entsprechend einer „Zugriff gewahrt für"-Nachricht, die F&FED 264 mitteilt, mit F&FEA 261 über die Verwendung eines virtuellen Routers in Prozess 525 (VR ZUSTIMMUNG) zu verhandeln. Andere Regelgruppen können nach Bedarf ebenfalls in einer Mehrfachpunktumgebung bereitgestellt werden.
  • In einem Routenaktualisierungsprozess gibt dann jeder abgesetzte Router seine Routen an den gemeinsamen virtuellen Router unter Verwendung von Nachrichten wie ADV_A 530 und ADV_D 540 bekannt. Methodologien für solche Routingaktualisierungen sind als solche herkömmlich und wären einem Durchschnittsfachmann offensichtlich. Sobald die Routingaktualisierungen abgeschlossen sind, aktualisiert der virtuelle Router VR1 231 jede Seite (d.h. Router in jedem VPN) mit der für die Verbindung der VPN erforderlichen Routinginformation unter Verwendung von Nachrichten an F&FEA 261 und F&FE 264, wie beispielsweise RT_UPD_A 535 und RT_UPD_D 545.
  • Sobald F&FE-Funktionen sowohl für das Routen als auch Filtern auf beiden Seiten vollkommen konfiguriert sind, kann der Datentraffic angenommen werden und Regeln werden angelegt. Wenn ein Anwendungsproxy für einen Datenfluss nicht verwendet werden soll, dann besteht der Prozess nach Anlegen der Filterregeln an F&FEA Block 261 im Senden der Daten in IP-Pakete eingekapselt in einer Nachricht 550, die in 5 als FW_PAC_D bezeichnet wird. Antwortpakete oder ähnliche Flüsse, die von den entfernten Seiten kommen, werden dieselbe Strecke, aber in der entgegengesetzten Richtung verwenden und sind in einer Nachricht eingekapselt, die in 5 als FW_PAC_A bezeichnet wird.
  • Wenn alternativ ein Anwendungsproxy für einen Datenfluss verwendet wird, besteht der Prozess am F&FEA-Block 261 darin, die Daten in IP-Pakete eingekapselt in einer Nachricht, die in 5 als FW_A_to_X bezeichnet wird, an den Schnittstellenblock PROINT 222 zu senden, der die externen Verbindungen mit dem Proxyserver 205 verwaltet.
  • In diesem letzteren Fall wird das/werden die Paket(e) in einem Protokoll geringer Schicht eingekapselt, wie beispielsweise Ethernet, und an den Proxyserver 205 weitergeleitet, der dann die dieser Anwendung entsprechende Richtlinie anlegen wird. Die Antwort von dem Proxyserver 205, die dieselbe Ziel-IP-Adresse enthält, wird an F&FED 264 in Nacbricht 570 weitergeleitet, die in 5 als X_TO_D bezeichnet wird.
  • Wenn die Ziel-IP-Adresse in der Antwort von dem Proxyserver nicht die Zieladresse des originalen IP-Pakets ist, sondern die Quelladresse, z.B. wenn der Proxyserver 205 das/die Paket(s) zurückweist, dann leitet der Proxyserver 205 eine Zurückweisungsnachricht an F&FEA 261 und Vorrichtung 100 in einer Nachricht X_TO_Y 565. Antwortpakete oder ähnliche Flüsse, die von den entfernten Seiten kommen, werden dieselbe Strecke durch den Proxyserver in der entgegengesetzten Richtung verwenden und sind Nachrichten FW_D_TO_X 575 eingekapselt, die an den Proxyserver 205, und X_TO_A 565, die von dem Proxyserver 205 an F&FEA-Block 261 gesendet werden.
  • Aus der obigen Erläuterung sollte ersichtlich sein, dass ähnliche Prozesse in einer Peer-to-Peer-Weise zwischen jedem Paar von F&FE-Blöcken auftreten können, sobald eine VPN-Verbindung hergestellt ist.
  • 6 zeigt eine Zertifikatstruktur, die in einem Beispiel der Erfindung verwendet wird. Wie in 6 gezeigt, kann ein Teil 610 von Zertifikat 600 die Identität und Unterschrift der Zertifikatautorität (C) 200 enthalten sowie das Ungültigkeitsdatum des Zertifkats und die öffentlichen Schlüssel der CA (zur Verschlüsselung und Authentifizierung). Ein Teil 620 kann verschiedene Informationen enthalten, die sich auf Vorrichtung 100 mit Adresse A beziehen, einschließlich der Identität, der Vorrichtungsart, der IP-Adresse, der Identifikation des Netzwerks, mit dem diese Vorrichtung verbunden ist (z.B. Netzwerk 170) der lokalen VPN-ID der Verbindung, der globalen VPN-ID für den Kunden, der diese Vorrichtung verwendet (der für einige Vorrichtungen der gleiche sein kann, während jede VPN_ID pro Vorrichtung unabhängig ist) und schließlich einer Kunden-Ide (bei der es sich um einen Kundennamen oder eine andere vorbestimmte ID handeln kann).
  • Ein weiterer Teil 630 enthält den öffentlichen Schlüssel der Vorrichtung 100, den öffentlichen Schlüssel der IPSec Authentifizierung und den öffentlichen Verschlüsselungsschlüssel der IPSec. Ein weiterer Abschnitt 640, der verwendet wird, wenn es sich bei der Vorrichtung 100 um einen Router oder ein Gateway handelt, enthält die Liste von Unternetzen, die durch das VPN verwaltet werden müssen, sowie das Routingprotokoll und assoziierte Routingparameter, die mit dieser Verbindung verbunden sind (z.B. Routenverteilung, statische Routeninformationen und/oder voreingestellter Router).
  • Ein Parameter 650 gibt die Anzahl der Verbindungsblöcke (z.B. Blöcke 251-256 in 2), die für die Verbindung definiert sind. Dann wird jeder Block so ausgelegt, wie bei 651 und 652 gezeigt. Das heißt, jeder Block kann verschiedene Parameter enthalten, wie VPNID, NETID und GLOB-VPNID, lokaler IP-Bereich (Quellbereich) zur Verbindung des neuen VPN und schließlich der IP-Zielbereich und Filterparameter, die mit dieser VPN-Verbindung assoziiert sind (einschließlich Regeln für verschiedene Anwendungen und Protokolle, die bei eingehenden und ausgehenden Traffic zugelassen/abgewiesen werden).
  • Wie oben beschrieben, stellt eine Ausführungsform der vorliegenden Erfindung Techniken zum Verbinden einer Vorrichtung in einem ersten VPN mit einer Vorrichtung in einem zweiten VPN unter Verwendung einer Verbindungsvorrichtung, wie eines Gateways oder Firewall. Die Verbindungsvorrichtung dient der Funktion des Identifizieren und Authentifizierens der Vorrichtung(en), möglicherweise unter Verwendung eines mit der Vorrichtung verbundenen digitalen Zertifikats. Die Verbindungsvorrichtung kann auch eine Abbildungstabelle konstruieren und verwenden, um die Verbindung der beiden auf separaten VPN betriebenen zu unterstützen. Auf diese Weise können Vorrichtung in separaten VPN auf sichere Weise unabhängig von der Art von verwendeten Vorrichtungen und VPN-Techniken, und ohne dass ein Rückgriff auf einen zentralisierten Steuerprozess erforderlich ist, verbunden werden können.
  • Während diese Erfindung in verschiedenen erläuternden Beispielen beschrieben worden ist, können andere Variationen von einem Durchschnittsfachmann ausgeführt werden, ohne von dem Umfang der Erfindung abzuweichen.

Claims (1)

  1. Verfahren zum Verbinden einer ersten Vorrichtung in einem ersten Virtuellen Privaten Netzwerk VPN mit einer zweiten Vorrichtung in einem zweiten VPN, gekennzeichnet durch: Empfangen, an einer Verbindungsvorrichtung, eines ersten Zertifikats, das die Eigenschaften der ersten Vorrichtung und des ersten VPN kennzeichnet, und eines zweiten Zertifikats, das die Eigenschaften der zweiten Vorrichtung und des zweiten VPN kennzeichnet; Vergleichen des ersten und zweiten Zertifikats an der Verbindungsvorrichtung, wobei die Verbindungsvorrichtung Informationen bezüglich einer vorgegebenen Anzahl von VPN, von der das erste und zweite VPN eine Untergruppe ist, speichert; und Zulassen einer Verbindung zwischen der ersten und der zweiten Vorrichtung basierend auf dem Vergleichsvorgang.
DE60315521T 2002-11-06 2003-10-29 Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten Expired - Lifetime DE60315521T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US288574 2002-11-06
US10/288,574 US7574738B2 (en) 2002-11-06 2002-11-06 Virtual private network crossovers based on certificates

Publications (2)

Publication Number Publication Date
DE60315521D1 DE60315521D1 (de) 2007-09-20
DE60315521T2 true DE60315521T2 (de) 2008-04-24

Family

ID=32107628

Family Applications (3)

Application Number Title Priority Date Filing Date
DE60326913T Expired - Lifetime DE60326913D1 (de) 2002-11-06 2003-10-29 Kreuzungen von virtuellen, privaten Netzwerken basiert auf Zertifikate
DE60336352T Expired - Lifetime DE60336352D1 (de) 2002-11-06 2003-10-29 Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten
DE60315521T Expired - Lifetime DE60315521T2 (de) 2002-11-06 2003-10-29 Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten

Family Applications Before (2)

Application Number Title Priority Date Filing Date
DE60326913T Expired - Lifetime DE60326913D1 (de) 2002-11-06 2003-10-29 Kreuzungen von virtuellen, privaten Netzwerken basiert auf Zertifikate
DE60336352T Expired - Lifetime DE60336352D1 (de) 2002-11-06 2003-10-29 Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten

Country Status (4)

Country Link
US (1) US7574738B2 (de)
EP (7) EP1657885B1 (de)
DE (3) DE60326913D1 (de)
HK (1) HK1088741A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014201234A1 (de) * 2014-01-23 2015-07-23 Siemens Aktiengesellschaft Verfahren, Verwaltungsvorrichtung und Gerät zur Zertifikat-basierten Authentifizierung von Kommunikationspartnern in einem Gerät

Families Citing this family (187)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8079086B1 (en) 1997-11-06 2011-12-13 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US9219755B2 (en) 1996-11-08 2015-12-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US7058822B2 (en) 2000-03-30 2006-06-06 Finjan Software, Ltd. Malicious mobile code runtime monitoring system and methods
EP2858309B1 (de) * 2000-06-16 2016-03-23 Fujitsu Limited Kommunikationsvorrichtung mit VPN-Akkomodationsfunktion
JP3947465B2 (ja) * 2000-06-22 2007-07-18 スリーエム エスペ アーゲー 歯科用ワークピースを製造するための装置
US7188365B2 (en) 2002-04-04 2007-03-06 At&T Corp. Method and system for securely scanning network traffic
US7203957B2 (en) 2002-04-04 2007-04-10 At&T Corp. Multipoint server for providing secure, scaleable connections between a plurality of network devices
US20110099621A1 (en) * 2002-04-22 2011-04-28 Nicholas Lizarraga Process for monitoring, filtering and caching internet connections
US8910241B2 (en) 2002-04-25 2014-12-09 Citrix Systems, Inc. Computer security system
US7937471B2 (en) * 2002-06-03 2011-05-03 Inpro Network Facility, Llc Creating a public identity for an entity on a network
US8234358B2 (en) * 2002-08-30 2012-07-31 Inpro Network Facility, Llc Communicating with an entity inside a private network using an existing connection to initiate communication
US8041761B1 (en) * 2002-12-23 2011-10-18 Netapp, Inc. Virtual filer and IP space based IT configuration transitioning framework
US7283529B2 (en) * 2003-03-07 2007-10-16 International Business Machines Corporation Method and system for supporting a dedicated label switched path for a virtual private network over a label switched communication network
US7949785B2 (en) * 2003-03-31 2011-05-24 Inpro Network Facility, Llc Secure virtual community network system
US20040249974A1 (en) * 2003-03-31 2004-12-09 Alkhatib Hasan S. Secure virtual address realm
US20040249973A1 (en) * 2003-03-31 2004-12-09 Alkhatib Hasan S. Group agent
US8473620B2 (en) * 2003-04-14 2013-06-25 Riverbed Technology, Inc. Interception of a cloud-based communication connection
US9160714B2 (en) * 2003-06-30 2015-10-13 Telefonaktiebolaget L M Ericsson (Publ) Using tunneling to enhance remote LAN connectivity
EP1643691B1 (de) * 2003-07-04 2007-12-05 Nippon Telegraph and Telephone Corporation Fernzugriffs-vpn-aushandlungsverfahren und aushandlungseinrichtung
TWI350686B (en) * 2003-07-14 2011-10-11 Nagravision Sa Method for securing an electronic certificate
US7447203B2 (en) 2003-07-29 2008-11-04 At&T Intellectual Property I, L.P. Broadband access for virtual private networks
EP1517482A1 (de) * 2003-09-18 2005-03-23 Hewlett-Packard Development Company, L.P. Auffinden von virtuellen privaten Netzwerken
US8051177B1 (en) * 2003-09-30 2011-11-01 Genband Us Llc Media proxy having interface to multiple virtual private networks
US8146148B2 (en) * 2003-11-19 2012-03-27 Cisco Technology, Inc. Tunneled security groups
GB2408415B (en) * 2003-11-19 2008-04-09 Vodafone Plc Networks
US8661158B2 (en) * 2003-12-10 2014-02-25 Aventail Llc Smart tunneling to resources in a network
US8590032B2 (en) 2003-12-10 2013-11-19 Aventail Llc Rule-based routing to resources through a network
CA2491274A1 (en) * 2004-01-08 2005-07-08 Lpi Level Platforms, Inc. A method and system for secure remote access to computer systems and networks
JP2005276122A (ja) * 2004-03-26 2005-10-06 Fujitsu Ltd アクセス元認証方法及びシステム
EP1587270A1 (de) * 2004-04-14 2005-10-19 Siemens Aktiengesellschaft Individuelles Versenden von Nachrichten an Paketnetz-Teilnehmer
TWI271076B (en) * 2004-07-02 2007-01-11 Icp Electronics Inc Security gateway with SSL protection and method for the same
US20060075229A1 (en) * 2004-09-30 2006-04-06 Marek James A Method and apparatus for maintaining a communications connection while guarding against bandwidth consuming attacks
FR2876525A1 (fr) * 2004-10-08 2006-04-14 France Telecom Procede et dispositif de creation d'un tunnel dans un reseau de telecommunication a permutation d'etiquettes
WO2006044820A2 (en) 2004-10-14 2006-04-27 Aventail Corporation Rule-based routing to resources through a network
US7779461B1 (en) * 2004-11-16 2010-08-17 Juniper Networks, Inc. Point-to-multi-point/non-broadcasting multi-access VPN tunnels
US7590074B1 (en) * 2004-12-02 2009-09-15 Nortel Networks Limited Method and apparatus for obtaining routing information on demand in a virtual private network
US20060130135A1 (en) 2004-12-10 2006-06-15 Alcatel Virtual private network connection methods and systems
US7533808B2 (en) 2005-02-09 2009-05-19 Yuh-Shen Song Privacy protected cooperation network
JP4282620B2 (ja) * 2005-02-28 2009-06-24 株式会社東芝 通信装置、ルータ装置、通信方法および通信プログラム
US7661128B2 (en) * 2005-03-31 2010-02-09 Google Inc. Secure login credentials for substantially anonymous users
US20060224712A1 (en) * 2005-04-04 2006-10-05 Nokia Corporation Device management in a communication system
US7583662B1 (en) * 2005-04-12 2009-09-01 Tp Lab, Inc. Voice virtual private network
DE102005028008A1 (de) * 2005-06-16 2006-12-28 Deutsche Telekom Ag Verfahren und unabhängiges Kommunikationsteilnetz zum Ermitteln labelvermittelter Routen in einem solchen Kommunikationsteilnetz
US20070008895A1 (en) * 2005-07-05 2007-01-11 Sbc Knowledge Ventures Lp Method and apparatus for improving centralized management of customer network sites
US8478986B2 (en) * 2005-08-10 2013-07-02 Riverbed Technology, Inc. Reducing latency of split-terminated secure communication protocol sessions
US20090083537A1 (en) * 2005-08-10 2009-03-26 Riverbed Technology, Inc. Server configuration selection for ssl interception
US8438628B2 (en) * 2005-08-10 2013-05-07 Riverbed Technology, Inc. Method and apparatus for split-terminating a secure network connection, with client authentication
US8613071B2 (en) * 2005-08-10 2013-12-17 Riverbed Technology, Inc. Split termination for secure communication protocols
US7978602B2 (en) 2005-11-14 2011-07-12 Juniper Networks, Inc. Dynamic construction of label switching protocol interfaces
US20070110072A1 (en) * 2005-11-16 2007-05-17 Mark Elias Digital subscriber link interconnection to a virtual private network
WO2007062069A1 (en) * 2005-11-23 2007-05-31 Ils Technology Llc Business-to-business remote network connectivity
US8316429B2 (en) * 2006-01-31 2012-11-20 Blue Coat Systems, Inc. Methods and systems for obtaining URL filtering information
EP1816824A1 (de) * 2006-02-07 2007-08-08 Thomson Licensing Verfahren zum Einfügen eines Gerätes in eine Gruppe von Netzwerkgeräten
US8782393B1 (en) 2006-03-23 2014-07-15 F5 Networks, Inc. Accessing SSL connection data by a third-party
US20070248091A1 (en) * 2006-04-24 2007-10-25 Mohamed Khalid Methods and apparatus for tunnel stitching in a network
US8024787B2 (en) * 2006-05-02 2011-09-20 Cisco Technology, Inc. Packet firewalls of particular use in packet switching devices
US9294477B1 (en) * 2006-05-04 2016-03-22 Sprint Communications Company L.P. Media access control address security
FR2902587B1 (fr) * 2006-06-16 2008-10-17 Alcatel Sa Dispositif de mise en communication de reseaux locaux par un commutateur exclusif et systeme de mise en communication correspondant ainsi qu'un support d'informations et un programme d'ordinateur
US8495181B2 (en) 2006-08-03 2013-07-23 Citrix Systems, Inc Systems and methods for application based interception SSI/VPN traffic
US7843912B2 (en) 2006-08-03 2010-11-30 Citrix Systems, Inc. Systems and methods of fine grained interception of network communications on a virtual private network
WO2008017011A2 (en) * 2006-08-03 2008-02-07 Citrix Systems, Inc. Systems and methods for application-based interception and authorization of ssl/vpn traffic
US8869262B2 (en) 2006-08-03 2014-10-21 Citrix Systems, Inc. Systems and methods for application based interception of SSL/VPN traffic
GB0623101D0 (en) 2006-11-20 2006-12-27 British Telecomm Secure network architecture
US8127347B2 (en) * 2006-12-29 2012-02-28 02Micro International Limited Virtual firewall
WO2008140367A1 (en) * 2007-05-09 2008-11-20 Telefonaktiebolaget Lm Ericsson (Publ) Improved resource sharing for a private network
US8516539B2 (en) 2007-11-09 2013-08-20 Citrix Systems, Inc System and method for inferring access policies from access event records
US8990910B2 (en) 2007-11-13 2015-03-24 Citrix Systems, Inc. System and method using globally unique identities
US8661524B2 (en) * 2007-12-14 2014-02-25 Novell, Inc. Selective desktop control of virtual private networks (VPN's) in a multiuser environment
US9240945B2 (en) 2008-03-19 2016-01-19 Citrix Systems, Inc. Access, priority and bandwidth management based on application identity
US8943575B2 (en) 2008-04-30 2015-01-27 Citrix Systems, Inc. Method and system for policy simulation
JP4931888B2 (ja) * 2008-09-29 2012-05-16 アラクサラネットワークス株式会社 転送装置、転送方法、およびコンピュータプログラム
US8990573B2 (en) 2008-11-10 2015-03-24 Citrix Systems, Inc. System and method for using variable security tag location in network communications
US9137209B1 (en) 2008-12-10 2015-09-15 Amazon Technologies, Inc. Providing local secure network access to remote services
US8230050B1 (en) 2008-12-10 2012-07-24 Amazon Technologies, Inc. Providing access to configurable private computer networks
US8201237B1 (en) 2008-12-10 2012-06-12 Amazon Technologies, Inc. Establishing secure remote access to private computer networks
US9524167B1 (en) 2008-12-10 2016-12-20 Amazon Technologies, Inc. Providing location-specific network access to remote services
US8707043B2 (en) * 2009-03-03 2014-04-22 Riverbed Technology, Inc. Split termination of secure communication sessions with mutual certificate-based authentication
US20100329252A1 (en) * 2009-06-26 2010-12-30 Nortel Networks Limited Method and Apparatus for Enabling Multicast Route Leaking Between VRFs in Different VPNs
US8214653B1 (en) 2009-09-04 2012-07-03 Amazon Technologies, Inc. Secured firmware updates
US9565207B1 (en) 2009-09-04 2017-02-07 Amazon Technologies, Inc. Firmware updates from an external channel
US8887144B1 (en) 2009-09-04 2014-11-11 Amazon Technologies, Inc. Firmware updates during limited time period
US8102881B1 (en) 2009-09-08 2012-01-24 Amazon Technologies, Inc. Streamlined guest networking in a virtualized environment
US8601170B1 (en) 2009-09-08 2013-12-03 Amazon Technologies, Inc. Managing firmware update attempts
US8971538B1 (en) 2009-09-08 2015-03-03 Amazon Technologies, Inc. Firmware validation from an external channel
US8300641B1 (en) 2009-09-09 2012-10-30 Amazon Technologies, Inc. Leveraging physical network interface functionality for packet processing
US8959611B1 (en) 2009-09-09 2015-02-17 Amazon Technologies, Inc. Secure packet management for bare metal access
US8640220B1 (en) * 2009-09-09 2014-01-28 Amazon Technologies, Inc. Co-operative secure packet management
US8381264B1 (en) 2009-09-10 2013-02-19 Amazon Technologies, Inc. Managing hardware reboot and reset in shared environments
US20110103383A1 (en) * 2009-10-30 2011-05-05 Honeywell International Inc. Two dimensional location transparency of software services
US8549300B1 (en) * 2010-02-23 2013-10-01 Juniper Networks, Inc. Virtual single sign-on for certificate-protected resources
US8639801B2 (en) * 2010-03-12 2014-01-28 Softlayer Technologies, Inc. Real-time automated virtual private network (VPN) access management
US8700892B2 (en) * 2010-03-19 2014-04-15 F5 Networks, Inc. Proxy SSL authentication in split SSL for client-side proxy agent resources with content insertion
US8775619B2 (en) * 2010-08-17 2014-07-08 Mcafee, Inc. Web hosted security system communication
DE102010044518A1 (de) * 2010-09-07 2012-03-08 Siemens Aktiengesellschaft Verfahren zur Zertifikats-basierten Authentisierung
DE102010038228A1 (de) 2010-10-15 2012-04-19 Phoenix Contact Gmbh & Co. Kg Verfahren zum Aufbau einer VPN-Verbindung zwischen zwei Netzwerken
US9084234B2 (en) 2010-11-29 2015-07-14 Nec Europe Ltd. Method and base station for supporting a connection between a communication device and a destination device in a target network
US9736065B2 (en) 2011-06-24 2017-08-15 Cisco Technology, Inc. Level of hierarchy in MST for traffic localization and load balancing
US9519777B2 (en) * 2011-10-31 2016-12-13 Novell, Inc. Techniques for controlling authentication
US8908698B2 (en) * 2012-01-13 2014-12-09 Cisco Technology, Inc. System and method for managing site-to-site VPNs of a cloud managed network
CN103546497B (zh) * 2012-07-09 2016-12-21 杭州华三通信技术有限公司 一种分布式防火墙IPSec业务负载分担的方法及装置
US8646064B1 (en) 2012-08-07 2014-02-04 Cloudflare, Inc. Determining the likelihood of traffic being legitimately received at a proxy server in a cloud-based proxy service
US9596271B2 (en) * 2012-10-10 2017-03-14 International Business Machines Corporation Dynamic virtual private network
US9565213B2 (en) 2012-10-22 2017-02-07 Centripetal Networks, Inc. Methods and systems for protecting a secured network
US9137205B2 (en) * 2012-10-22 2015-09-15 Centripetal Networks, Inc. Methods and systems for protecting a secured network
US9270667B2 (en) * 2012-11-01 2016-02-23 Microsoft Technology Licensing, Llc Utilizing X.509 authentication for single sign-on between disparate servers
US10367914B2 (en) 2016-01-12 2019-07-30 Cisco Technology, Inc. Attaching service level agreements to application containers and enabling service assurance
JP5949491B2 (ja) * 2012-11-20 2016-07-06 富士ゼロックス株式会社 情報処理装置及びプログラム
US9203806B2 (en) 2013-01-11 2015-12-01 Centripetal Networks, Inc. Rule swapping in a packet network
US9124552B2 (en) 2013-03-12 2015-09-01 Centripetal Networks, Inc. Filtering network data transfers
US9094445B2 (en) 2013-03-15 2015-07-28 Centripetal Networks, Inc. Protecting networks from cyber attacks and overloading
US9215075B1 (en) * 2013-03-15 2015-12-15 Poltorak Technologies Llc System and method for secure relayed communications from an implantable medical device
JP2014200017A (ja) * 2013-03-29 2014-10-23 ニフティ株式会社 中継装置、情報処理方法、及びプログラム
US9130996B1 (en) 2014-03-26 2015-09-08 Iboss, Inc. Network notifications
US10122605B2 (en) 2014-07-09 2018-11-06 Cisco Technology, Inc Annotation of network activity through different phases of execution
US9729439B2 (en) 2014-09-26 2017-08-08 128 Technology, Inc. Network packet flow controller
US9148408B1 (en) 2014-10-06 2015-09-29 Cryptzone North America, Inc. Systems and methods for protecting network devices
US9906497B2 (en) 2014-10-06 2018-02-27 Cryptzone North America, Inc. Multi-tunneling virtual network adapter
US10277506B2 (en) 2014-12-08 2019-04-30 128 Technology, Inc. Stateful load balancing in a stateless network
US9661011B1 (en) 2014-12-17 2017-05-23 Amazon Technologies, Inc. Techniques for data routing and management using risk classification and data sampling
US9264370B1 (en) 2015-02-10 2016-02-16 Centripetal Networks, Inc. Correlating packets in communications networks
US9736184B2 (en) 2015-03-17 2017-08-15 128 Technology, Inc. Apparatus and method for using certificate data to route data
US9866576B2 (en) 2015-04-17 2018-01-09 Centripetal Networks, Inc. Rule-based network-threat detection
US10476982B2 (en) 2015-05-15 2019-11-12 Cisco Technology, Inc. Multi-datacenter message queue
US9729682B2 (en) 2015-05-18 2017-08-08 128 Technology, Inc. Network device and method for processing a session using a packet signature
US9762485B2 (en) 2015-08-24 2017-09-12 128 Technology, Inc. Network packet flow controller with extended session management
US10965494B2 (en) 2015-10-01 2021-03-30 International Business Machines Corporation Intelligent multi-channel VPN orchestration
US9736120B2 (en) 2015-10-16 2017-08-15 Cryptzone North America, Inc. Client network access provision by a network traffic manager
US9866519B2 (en) 2015-10-16 2018-01-09 Cryptzone North America, Inc. Name resolving in segmented networks
US10205677B2 (en) 2015-11-24 2019-02-12 Cisco Technology, Inc. Cloud resource placement optimization and migration execution in federated clouds
US10084703B2 (en) 2015-12-04 2018-09-25 Cisco Technology, Inc. Infrastructure-exclusive service forwarding
US9871748B2 (en) 2015-12-09 2018-01-16 128 Technology, Inc. Router with optimized statistical functionality
US10142293B2 (en) 2015-12-15 2018-11-27 International Business Machines Corporation Dynamically defined virtual private network tunnels in hybrid cloud environments
US9571457B1 (en) 2015-12-15 2017-02-14 International Business Machines Corporation Dynamically defined virtual private network tunnels in hybrid cloud environments
US9917856B2 (en) 2015-12-23 2018-03-13 Centripetal Networks, Inc. Rule-based network-threat detection for encrypted communications
US11729144B2 (en) 2016-01-04 2023-08-15 Centripetal Networks, Llc Efficient packet capture for cyber threat analysis
US10149166B2 (en) 2016-01-14 2018-12-04 Blackberry Limited Verifying a certificate
US10412048B2 (en) 2016-02-08 2019-09-10 Cryptzone North America, Inc. Protecting network devices by a firewall
US9985883B2 (en) 2016-02-26 2018-05-29 128 Technology, Inc. Name-based routing system and method
US10270603B2 (en) 2016-03-17 2019-04-23 Blackberry Limited Processing certificate validation warnings
US9560015B1 (en) 2016-04-12 2017-01-31 Cryptzone North America, Inc. Systems and methods for protecting network devices by a firewall
US10205651B2 (en) 2016-05-13 2019-02-12 128 Technology, Inc. Apparatus and method of selecting next hops for a session
US10298616B2 (en) 2016-05-26 2019-05-21 128 Technology, Inc. Apparatus and method of securing network communications
US10257061B2 (en) 2016-05-31 2019-04-09 128 Technology, Inc. Detecting source network address translation in a communication system
US10091099B2 (en) 2016-05-31 2018-10-02 128 Technology, Inc. Session continuity in the presence of network address translation
US10200264B2 (en) 2016-05-31 2019-02-05 128 Technology, Inc. Link status monitoring based on packet loss detection
US11075836B2 (en) 2016-05-31 2021-07-27 128 Technology, Inc. Reverse forwarding information base enforcement
US10841206B2 (en) 2016-05-31 2020-11-17 128 Technology, Inc. Flow modification including shared context
US9832072B1 (en) 2016-05-31 2017-11-28 128 Technology, Inc. Self-configuring computer network router
US10009282B2 (en) 2016-06-06 2018-06-26 128 Technology, Inc. Self-protecting computer network router with queue resource manager
US10432532B2 (en) 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US10382597B2 (en) 2016-07-20 2019-08-13 Cisco Technology, Inc. System and method for transport-layer level identification and isolation of container traffic
US10567344B2 (en) 2016-08-23 2020-02-18 Cisco Technology, Inc. Automatic firewall configuration based on aggregated cloud managed information
US9985872B2 (en) 2016-10-03 2018-05-29 128 Technology, Inc. Router with bilateral TCP session monitoring
US10320683B2 (en) 2017-01-30 2019-06-11 Cisco Technology, Inc. Reliable load-balancer using segment routing and real-time application monitoring
US10425511B2 (en) 2017-01-30 2019-09-24 128 Technology, Inc. Method and apparatus for managing routing disruptions in a computer network
US10671571B2 (en) 2017-01-31 2020-06-02 Cisco Technology, Inc. Fast network performance in containerized environments for network function virtualization
WO2018165182A1 (en) 2017-03-07 2018-09-13 128 Technology, Inc. Router device using flow duplication
US11005731B2 (en) 2017-04-05 2021-05-11 Cisco Technology, Inc. Estimating model parameters for automatic deployment of scalable micro services
US10432519B2 (en) 2017-05-26 2019-10-01 128 Technology, Inc. Packet redirecting router
US10439877B2 (en) 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
US10382274B2 (en) 2017-06-26 2019-08-13 Cisco Technology, Inc. System and method for wide area zero-configuration network auto configuration
US10503899B2 (en) 2017-07-10 2019-12-10 Centripetal Networks, Inc. Cyberanalysis workflow acceleration
US10425288B2 (en) 2017-07-21 2019-09-24 Cisco Technology, Inc. Container telemetry in data center environments with blade servers and switches
US10284526B2 (en) 2017-07-24 2019-05-07 Centripetal Networks, Inc. Efficient SSL/TLS proxy
US11233777B2 (en) 2017-07-24 2022-01-25 Centripetal Networks, Inc. Efficient SSL/TLS proxy
US10601693B2 (en) 2017-07-24 2020-03-24 Cisco Technology, Inc. System and method for providing scalable flow monitoring in a data center fabric
US10541866B2 (en) 2017-07-25 2020-01-21 Cisco Technology, Inc. Detecting and resolving multicast traffic performance issues
US11165863B1 (en) 2017-08-04 2021-11-02 128 Technology, Inc. Network neighborhoods for establishing communication relationships between communication interfaces in an administrative domain
US10705882B2 (en) 2017-12-21 2020-07-07 Cisco Technology, Inc. System and method for resource placement across clouds for data intensive workloads
US11595474B2 (en) 2017-12-28 2023-02-28 Cisco Technology, Inc. Accelerating data replication using multicast and non-volatile memory enabled nodes
US20190253341A1 (en) 2018-02-15 2019-08-15 128 Technology, Inc. Service Related Routing Method and Apparatus
US10728361B2 (en) 2018-05-29 2020-07-28 Cisco Technology, Inc. System for association of customer information across subscribers
US10904322B2 (en) 2018-06-15 2021-01-26 Cisco Technology, Inc. Systems and methods for scaling down cloud-based servers handling secure connections
US10764266B2 (en) 2018-06-19 2020-09-01 Cisco Technology, Inc. Distributed authentication and authorization for rapid scaling of containerized services
US11019083B2 (en) 2018-06-20 2021-05-25 Cisco Technology, Inc. System for coordinating distributed website analysis
US10819571B2 (en) 2018-06-29 2020-10-27 Cisco Technology, Inc. Network traffic optimization using in-situ notification system
US10333898B1 (en) 2018-07-09 2019-06-25 Centripetal Networks, Inc. Methods and systems for efficient network protection
US10904342B2 (en) 2018-07-30 2021-01-26 Cisco Technology, Inc. Container networking using communication tunnels
US11218506B2 (en) * 2018-12-17 2022-01-04 Microsoft Technology Licensing, Llc Session maturity model with trusted sources
US11876798B2 (en) * 2019-05-20 2024-01-16 Citrix Systems, Inc. Virtual delivery appliance and system with remote authentication and related methods
US11283782B2 (en) * 2019-11-26 2022-03-22 Hewlett Packard Enterprise Development Lp ISO layer-two connectivity using ISO layer-three tunneling
EP4140106A1 (de) 2020-04-23 2023-03-01 Juniper Networks, Inc. Sitzungsüberwachung unter verwendung von metriken des sitzungsaufbaus
US11362996B2 (en) 2020-10-27 2022-06-14 Centripetal Networks, Inc. Methods and systems for efficient adaptive logging of cyber threat incidents
JP2023554074A (ja) * 2020-12-18 2023-12-26 ダル・アイピー・ピーティーワイ・リミテッド ネットワーク間で信頼できるデータ通信を確立するための方法
US11159546B1 (en) 2021-04-20 2021-10-26 Centripetal Networks, Inc. Methods and systems for efficient threat context-aware packet filtering for network protection
US11831688B2 (en) * 2021-06-18 2023-11-28 Capital One Services, Llc Systems and methods for network security
US20230412583A1 (en) * 2022-06-17 2023-12-21 Cyber Intell Solution, LLC Encrypted Communication Platform and Related Systems and Methods

Family Cites Families (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577209A (en) 1991-07-11 1996-11-19 Itt Corporation Apparatus and method for providing multi-level security for communication among computers and terminals on a network
US5835726A (en) 1993-12-15 1998-11-10 Check Point Software Technologies Ltd. System for securing the flow of and selectively modifying packets in a computer network
FR2716323B1 (fr) 1994-02-14 1996-05-03 France Telecom Système sécurisé d'interconnexion de réseaux locaux via un réseau de transmission public.
US6091820A (en) 1994-06-10 2000-07-18 Sun Microsystems, Inc. Method and apparatus for achieving perfect forward secrecy in closed user groups
AU1748797A (en) 1996-01-16 1997-08-11 Raptor Systems, Inc. Key management for network communication
US5983350A (en) 1996-09-18 1999-11-09 Secure Computing Corporation Secure firewall supporting different levels of authentication based on address or encryption status
US6105027A (en) 1997-03-10 2000-08-15 Internet Dynamics, Inc. Techniques for eliminating redundant access checking by access filters
US6226748B1 (en) * 1997-06-12 2001-05-01 Vpnet Technologies, Inc. Architecture for virtual private networks
US6092200A (en) 1997-08-01 2000-07-18 Novell, Inc. Method and apparatus for providing a virtual private network
US6078953A (en) 1997-12-29 2000-06-20 Ukiah Software, Inc. System and method for monitoring quality of service over network
US6049878A (en) 1998-01-20 2000-04-11 Sun Microsystems, Inc. Efficient, secure multicasting with global knowledge
US6195751B1 (en) 1998-01-20 2001-02-27 Sun Microsystems, Inc. Efficient, secure multicasting with minimal knowledge
US6079020A (en) * 1998-01-27 2000-06-20 Vpnet Technologies, Inc. Method and apparatus for managing a virtual private network
CA2228687A1 (en) * 1998-02-04 1999-08-04 Brett Howard Secured virtual private networks
US6353614B1 (en) 1998-03-05 2002-03-05 3Com Corporation Method and protocol for distributed network address translation
US6055236A (en) 1998-03-05 2000-04-25 3Com Corporation Method and system for locating network services with distributed network address translation
US7032242B1 (en) * 1998-03-05 2006-04-18 3Com Corporation Method and system for distributed network address translation with network security features
US6182226B1 (en) 1998-03-18 2001-01-30 Secure Computing Corporation System and method for controlling interactions between networks
US6226751B1 (en) 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network
US6253321B1 (en) 1998-06-19 2001-06-26 Ssh Communications Security Ltd. Method and arrangement for implementing IPSEC policy management using filter code
US6269099B1 (en) * 1998-07-01 2001-07-31 3Com Corporation Protocol and method for peer network device discovery
US6304973B1 (en) 1998-08-06 2001-10-16 Cryptek Secure Communications, Llc Multi-level security network system
EP1118198A2 (de) 1998-09-30 2001-07-25 Siemens Aktiengesellschaft Anordnung und verfahren zur codierung und decodierung digitaler daten nach dem internet protokoll
US6038322A (en) 1998-10-20 2000-03-14 Cisco Technology, Inc. Group key distribution
US6275588B1 (en) 1998-11-12 2001-08-14 I-Data International A/S Apparatus and method for performing and controlling encryption/decryption for data to be transmitted on local area network
US6006259A (en) 1998-11-20 1999-12-21 Network Alchemy, Inc. Method and apparatus for an internet protocol (IP) network clustering system
US6636898B1 (en) 1999-01-29 2003-10-21 International Business Machines Corporation System and method for central management of connections in a virtual private network
US6330562B1 (en) 1999-01-29 2001-12-11 International Business Machines Corporation System and method for managing security objects
US6662221B1 (en) 1999-04-12 2003-12-09 Lucent Technologies Inc. Integrated network and service management with automated flow through configuration and provisioning of virtual private networks
US6883100B1 (en) 1999-05-10 2005-04-19 Sun Microsystems, Inc. Method and system for dynamic issuance of group certificates
US6496867B1 (en) 1999-08-27 2002-12-17 3Com Corporation System and method to negotiate private network addresses for initiating tunneling associations through private and/or public networks
US6289382B1 (en) 1999-08-31 2001-09-11 Andersen Consulting, Llp System, method and article of manufacture for a globally addressable interface in a communication services patterns environment
EP1222548A4 (de) 1999-08-31 2009-04-22 Anxebusiness Corp System und verfahren um eine vielzahl von privaten virtuellen netzwerken zu verbinden
US6332163B1 (en) 1999-09-01 2001-12-18 Accenture, Llp Method for providing communication services over a computer network system
DE69941817D1 (de) 1999-10-14 2010-01-28 Alcatel Lucent Verfahren zum Verbinden eines Benutzerendgerätes mit einem zweiten Benutzerendgerät, Vorrichtung und Softwaremodul dafür
JP2001160828A (ja) * 1999-12-03 2001-06-12 Matsushita Electric Ind Co Ltd セキュリティ・ゲートウェイ装置におけるｖｐｎ通信方法
GB2364477B (en) 2000-01-18 2003-11-05 Ericsson Telefon Ab L M Virtual private networks
US7320034B2 (en) * 2000-03-20 2008-01-15 International Business Machines Corporation System and method for reserving a virtual connection in an IP network
JP4099930B2 (ja) * 2000-06-02 2008-06-11 株式会社日立製作所 ルータ装置及びｖｐｎ識別情報の設定方法
US6826684B1 (en) 2000-08-28 2004-11-30 Verizon Corporate Services Group Inc. Sliding scale adaptive self-synchronized dynamic address translation
US6954790B2 (en) * 2000-12-05 2005-10-11 Interactive People Unplugged Ab Network-based mobile workgroup system
US20050088977A1 (en) * 2000-12-14 2005-04-28 Nortel Networks Limited Dynamic virtual private network (VPN) tunnel quality of service (QoS) treatment
US6931529B2 (en) * 2001-01-05 2005-08-16 International Business Machines Corporation Establishing consistent, end-to-end protection for a user datagram
US7209479B2 (en) 2001-01-18 2007-04-24 Science Application International Corp. Third party VPN certification
US20020144144A1 (en) * 2001-03-27 2002-10-03 Jeffrey Weiss Method and system for common control of virtual private network devices
US7003662B2 (en) * 2001-05-24 2006-02-21 International Business Machines Corporation System and method for dynamically determining CRL locations and access methods
US6938155B2 (en) 2001-05-24 2005-08-30 International Business Machines Corporation System and method for multiple virtual private network authentication schemes
US7171685B2 (en) 2001-08-23 2007-01-30 International Business Machines Corporation Standard format specification for automatically configuring IP security tunnels
WO2003021443A1 (en) * 2001-08-31 2003-03-13 Adaptec, Inc. Systems and methods for implementing host-based security in a computer network
FI20011949A0 (fi) 2001-10-05 2001-10-05 Stonesoft Corp Virtuaalisen yksityisverkon hallinta
US6789121B2 (en) * 2002-02-08 2004-09-07 Nortel Networks Limited Method of providing a virtual private network service through a shared network, and provider edge device for such network
US7203957B2 (en) 2002-04-04 2007-04-10 At&T Corp. Multipoint server for providing secure, scaleable connections between a plurality of network devices
US20030191843A1 (en) * 2002-04-04 2003-10-09 Joel Balissat Secure network connection for devices on a private network
US20040066747A1 (en) * 2002-10-02 2004-04-08 Ben Jorgensen Methods and structure for automated troubleshooting of a virtual private network connection
US20040093492A1 (en) * 2002-11-13 2004-05-13 Olivier Daude Virtual private network management with certificates

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014201234A1 (de) * 2014-01-23 2015-07-23 Siemens Aktiengesellschaft Verfahren, Verwaltungsvorrichtung und Gerät zur Zertifikat-basierten Authentifizierung von Kommunikationspartnern in einem Gerät

Also Published As

Publication number Publication date
DE60336352D1 (de) 2011-04-21
EP1418730B1 (de) 2009-04-01
EP1657884A3 (de) 2006-06-07
US7574738B2 (en) 2009-08-11
DE60315521D1 (de) 2007-09-20
US20040088542A1 (en) 2004-05-06
EP1657885A3 (de) 2006-10-11
EP1657885A2 (de) 2006-05-17
EP1657884A2 (de) 2006-05-17
DE60326913D1 (de) 2009-05-14
EP1657882A1 (de) 2006-05-17
EP1418730A3 (de) 2004-08-18
EP1657885B1 (de) 2011-03-09
HK1088741A1 (en) 2006-11-10
EP1657881A1 (de) 2006-05-17
EP1657883A1 (de) 2006-05-17
EP1657880A1 (de) 2006-05-17
EP1418730A2 (de) 2004-05-12
EP1657880B1 (de) 2007-08-08

Similar Documents

Publication Publication Date Title
DE60315521T2 (de) Kreuzungen von virtuellen privaten Netzwerken basierend auf Zertifikaten
DE60212289T2 (de) Verwaltung privater virtueller Netze (VPN)
DE69836271T2 (de) Mehrstufiges firewall-system
DE10052312B4 (de) Automatische Sperre gegen unberechtigten Zugriff im Internet (Snoop Avoider) für virtuelle private Netze
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
EP1602214B1 (de) Verfahren, system und speichermedium um kompatibilität zwischen IPsec und dynamischem routing herzustellen
DE60130042T2 (de) Verteilte server-funktionalität für ein emuliertes lan
DE60121755T2 (de) Ipsec-verarbeitung
DE60004707T2 (de) Schema zur bestimmung von transportschichtinformation in gegenwart von ip-sicherkeitsverschlüsselung
DE60311898T2 (de) Verfahren, um ein Paket von einem ersten IPSeC Klienten zu einem zweiten IPSec Klienten über einen L2TP Tunnel zu übertragen
DE102006060040B4 (de) Verfahren und Server zum Bereitstellen einer geschützten Datenverbindung
DE20211995U1 (de) Computersystem zur Sicherung der Kommunikation in Netzwerken
EP2062400B1 (de) Verfahren und system zur adressierung und zum routing bei verschlüsselten kommunikationsbeziehungen
EP1593253B1 (de) Verfahren und anordnung zur transparenten vermittlung des datenverkehrs zwischen datenverarbeitungseinrichtungen sowie ein entsprechendes computerprogamm-erzeugnis und ein entsprechendes computerlesbares speichermedium
DE69636513T2 (de) System zur sicherung des flusses und zur selektiven veränderung von paketen in einem rechnernetz
DE602004002950T2 (de) Verfahren und Vorrichtung zur Zugriffssteuerung
DE60127187T2 (de) System und verfahren zur bereitstellung von diensten in virtuellen privatnetzen
EP1645098B1 (de) Vorrichtung und koppelgerät, so genannter secure-switch, zur sicherung eines datenzugriffes
EP1496666A1 (de) Vorrichtung und Koppelgerät, so genannter transparenter Tunnel-Proxy, zur Sicherung eines Datenzugriffs
EP1699181A1 (de) Verfahren und System zur automatisierten Konfiguration eines Subnetzwerks innerhalb eines Netzwerkes
DE10234562B4 (de) Sichere Netzwerkarchitektur
DE102023126692A1 (de) Synchronisierung einer client-ip-bindungsdatenbank über erweiterte netzwerke hinweg unter nutzung einer bgp-kontrollebene
EP1903464A1 (de) Verfahren und Steuerungsprogramm zur Verwaltung von Benutzerzugriffsrechten in einem Kommunikationsnetzwerk
Joachimpillai et al. Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)
Joachimpillai et al. RFC 8013: Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)

Legal Events

Date Code Title Description
8364 No opposition during term of opposition