DE60116754T2

DE60116754T2 - Sicherere registrierung von domänennamen

Info

Publication number: DE60116754T2
Application number: DE60116754T
Authority: DE
Inventors: Victor Fairfax LARSON; Durham Robert Leesburg SHORT; Colby Edmund Crownsville MUNGER; Michael South Riding WILLIAMSON
Original assignee: Science Applications International Corp SAIC
Current assignee: Virnetx Inc
Priority date: 2000-04-26
Filing date: 2001-04-25
Publication date: 2006-08-31
Anticipated expiration: 2021-04-26
Also published as: JP2011124985A; JP5377562B2; EP1542429B1; JP5478698B2; JP5180274B2; JP2011205641A; EP1542429A1; EP2330801B1; JP2011205642A; WO2001092997A2; EP1284079B1; JP2003535560A; JP5478697B2; AU2001259140A1; JP5095900B2; JP5165776B2; EP1284079A2; WO2001092997A3; DE60116754D1; JP2013062862A

Description

HINTERGRUND DER ERFINDUNG
Um Sicherheit und Anonymität für die Kommunikation über das Internet zu schaffen, sind eine ungeheuere Vielfalt von Verfahren vorgeschlagen und realisiert worden. Die Vielfalt stammt teilweise von den verschiedenen Anforderungen für verschiedene Internet-Anwender.
Zum Beispiel ist aus DE A 199 24575 eine Vorrichtung zur Bereitstellung eines Dienstes für sichere Domänennamen für ein Computernetz bekannt, die ein Portal und eine Domänennamen-Datenbank, die sichere Computernetzadressen speichert, umfasst.
Darüber hinaus ist in 1 ein grundlegendes heuristisches System als Hilfe bei der Diskussion der verschiedenen Sicherheitstechniken veranschaulicht. Zwei Endgeräte, ein Ursprungsendgerät 100 und ein Zielendgerät 110, stehen in Kommunikation über das Internet. Es ist erwünscht, dass die Kommunikation sicher, d. h. geschützt vor Abhören, ist. Zum Beispiel kann das Endgerät 100 sichere Informationen über das Internet 107 zum Endgerät 110 übertragen. Außerdem kann es erwünscht sein zu verhindern, dass ein Abhörer entdeckt, dass das Endgerät 100 in Kommunikation mit dem Endgerät 110 steht. Falls z. B. das Endgerät 100 ein Anwender ist und das Endgerät 110 eine Website hostet, kann der Anwender des Endgeräts 100 nicht wünschen, dass jemand in den Zwischennetzen weiß, welche Websites er "besucht". Somit wäre die Anonymität z. B. ein Problem für Unternehmen, die ihre Marktforschungsinteressen vertraulich halten möchten und somit bevorzugen würden, dass verhindert wird, dass Außenstehende wissen, welche Websites oder anderen Internet-Ressourcen sie "besuchen". Diese zwei Sicherheitsprobleme können Datensicherheit bzw. Anonymität genannt werden.
Üblicherweise wird die Datensicherheit unter Verwendung einer Form der Datenverschlüsselung bewältigt. Sowohl bei dem Ursprungs- als auch bei dem Zielendgerät 100 und 110 ist ein Verschlüsselungsschlüssel 48 bekannt. Die Schlüssel können bei dem Ursprungs- und bei dem Zielendgerät 100 bzw. 110 privat und öffentlich sein oder können symmetrische Schlüssel sein (wobei für beide Teilnehmer zum Verschlüsseln und zum Entschlüsseln derselbe Schlüssel verwendet wird). In diesem Kontext sind viele Verschlüsselungsverfahren bekannt und verwendbar.
Um Verkehr vor einem lokalen Administrator oder ISP zu verbergen, kann ein Anwender in der Kommunikation über einen verschlüsselten Kanal mit einem äußeren Proxy einen lokalen Proxy-Server verwenden, so dass der lokale Administrator oder ISP nur den verschlüsselten Verkehr sieht. Proxy-Server verhindern, dass Zielserver die Identitäten der Ursprung-Clients bestimmen. Dieses System verwendet einen Zwischen-Server, der zwischen Client und Ziel-Server eingefügt ist. Der Ziel-Server sieht nur die Internet-Protokoll-Adresse (IP-Adresse) des Proxy-Servers und nicht den Ursprungs-Client. Der Ziel-Server sieht nur die Adresse des äußeren Proxy. Dieses Schema beruht auf einem vertrauenswürdigen äußeren Proxy-Server. Außerdem sind Proxy-Schemata anfällig für Verkehrsanalyseverfahren der Bestimmung der Identitäten von Sendern und Empfängern. Eine weitere wichtige Beschränkung von Proxy-Servern ist, dass der Server die Identitäten sowohl des anrufenden als auch des angerufenen Teilnehmers kennt. In vielen Fällen, z. B., wenn der Proxy-Server durch einen Internet-Dienste-Anbieter (ISP) bereitgestellt wird, würde es ein Ursprungsendgerät wie etwa das Endgerät A bevorzugen, seine Identität vor dem Proxy verborgen zu halten.
Um die Verkehrsanalyse zu vereiteln, nutzt ein Chaum-Mixes genanntes Schema einen Proxy-Server, der Nachrichten mit fester Länge sendet und empfängt, die Leernachrichten enthalten. Mehrere Ursprungsendgeräte sind über einen Mix (einen Server) mit mehreren Ziel-Servern verbunden. Es ist schwer zu sagen, welche der Ursprungsendgeräte mit welchen der verbundenen Ziel-Server kommunizieren, wobei die Leernachrichten die Bemühungen des Abhörers, durch Analysieren des Verkehrs kommunizierende Paare zu erfassen, verwirren. Ein Nachteil ist, dass ein Risiko besteht, dass der Mix-Server gefährdet werden könnte. Eine Möglichkeit, dieses Risiko zu bewältigen, ist, die Verantwortung auf mehrere Mixes zu verteilen. Falls ein Mix gefährdet wird, können die Identitäten des Ursprungs- und des Zielendgeräts verborgen bleiben. Diese Strategie erfordert eine Anzahl alternativer Mixes, so dass die zwischen die Ursprungs- und Zielendgeräte eingefügten Zwischen-Server außer durch Gefährden mehr als eines Mix nicht bestimmbar sind. Die Strategie umhüllt die Nachricht mit mehreren Schichten verschlüsselter Adressen. Der erste Mix in einer Folge kann nur die äußere Schicht der Nachricht entschlüsseln, um den nächsten Ziel-Mix in der Folge zu offenbaren. Der zweite Mix kann die Nachricht entschlüsseln, um den nächsten Mix zu offenbaren usw. Der Ziel-Server empfängt die Nachricht und optional eine mehrschichtig verschlüsselte Nutznachricht, die Antwortinformatio nen enthält, um die Daten auf die gleiche Weise zurückzusenden. Die einzige Möglichkeit, ein solches Mix-Schema zu besiegen, ist, mit den Mixes gemeinsame Sache zu machen. Falls die Pakete alle eine feste Länge haben und mit Leerpaketen gemischt sind, gibt es keine Möglichkeit, irgendeine Art Verkehrsanalyse auszuführen.
Eine nochmals weitere Anonymitätstechnik, die 'Crowds' genannt wird, schützt die Identität des Ursprungsendgeräts vor den Zwischen-Proxies, indem sie sicherstellt, dass die Ursprungsendgeräte zu einer Gruppe von Proxies gehören, die Crowds genannt wird. Die Crowd-Proxies sind zwischen Ursprungs- und Zielendgerät eingefügt. Jeder Proxy, über den die Nachricht gesendet wird, wird zufällig durch einen in Informationsflussrichtung voraus angeordneten Proxy gewählt. Jeder Zwischen-Proxy kann die Nachricht entweder zu einem weiteren zufällig gewählten Proxy in der "Crowd" oder zu dem Ziel senden. Somit können selbst die Crowd-Mitglieder nicht bestimmen, ob ein vorangehender Proxy der Absender der Nachricht war oder ob sie einfach von einem anderen Proxy übergeben wurde.
Das anonyme ZKS-IP-Protokoll (Null-Kenntnis-Systeme-IP-Protokoll) ermöglicht, dass Anwender irgendeines von bis zu fünf verschiedenen Pseudonymen auswählen, während Desktop-Software den abgehenden Verkehr verschlüsselt und ihn in Anwenderdatagrammprotokoll-Pakete (UDP-Pakete) einhüllt. Der erste Server in einem 2+-Sprung-System erhält die UDP-Pakete, entfernt eine Verschlüsselungsschicht, fügt eine weitere hinzu und sendet den Verkehr daraufhin zu dem nächsten Server, der abermals eine weitere Verschlüsselungsschicht entfernt und eine neue hinzufügt. Der Anwender kann die Anzahl der Sprünge steuern. Beim letzten Server wird der Verkehr mit einer nicht verfolgbaren IP-Adresse entschlüsselt. Die Technik wird Zwiebel-Routing genannt. Dieses Verfahren kann unter Verwendung der Verkehrsanalyse besiegt werden. Als ein einfaches Beispiel können Datenbündel von Paketen von einem Anwender während Zeitdauern niedrigen Betriebs die Identitäten des Senders und des Empfängers offenbaren.
Firewalls versuchen, LANs vor unberechtigtem Zugriff und feindlicher Ausnutzung oder Beschädigung an mit dem LAN verbundenen Computern zu schützen. Firewalls stellen einen Server bereit, über den der gesamte Zugriff auf das LAN gehen muss. Firewalls sind zentralisierte Systeme, die einen administrativen Organisationsaufwand zur Wartung erfordern. Sie können durch Anwendungen der virtuellen Maschine ("Applets") gefährdet werden. Sie flößen ein falsches Gefühl der Sicherheit ein, das zu Sicherheitsverletzungen z. B. durch Anwender führt, die sensible Informationen an Server außerhalb der Firewall senden oder die Verwendung von Modems unterstützen, die die Firewall-Sicherheit umgehen. Firewalls sind nicht nützlich für verteilte Systeme wie etwa Geschäftsreisende, Extranets, Kleinarbeitsgruppen usw.
ZUSAMMENFASSUNG DER ERFINDUNG
Es werden ein Verfahren zum Registrieren eines sicheren Domänennamens gemäß Anspruch 1 und ein computerlesbares Speichermedium gemäß Anspruch 3 geschaffen.
Ein sicherer Mechanismus für die Kommunikation über das Internet, der ein Protokoll enthält, das als das Protokoll des getunnelten agilen Routing (TARP-Protokoll) bezeichnet wird, verwendet ein eindeutiges Zwischenschicht-Verschlüsselungsformat und spezielle TARP-Router. TARP-Router besitzen eine ähnliche Funktion wie normale IP-Router. Jeder TARP-Router hat eine oder mehrere IP-Adressen und verwendet das normale IP-Protokoll zum Senden von IP-Paketnachrichten ("Paketen" oder "Datagrammen"). Die zwischen TARP-Endgeräten über TARP-Router ausgetauschten IP-Pakete werden schließlich zu verschlüsselten Paketen, deren wahre Zieladresse außer gegenüber TARP-Routern und -Servern verborgen ist. Der normale oder "Klar" oder "Außen"-IP-Anfangsblock, der an TARP-IP-Paketen angebracht wird, enthält nur die Adresse eines Routers oder Ziel-Servers des nächsten Sprungs. Das heißt, anstatt in dem Zielfeld des IP-Anfangsblocks ein Endziel anzugeben, zeigt der IP-Anfangsblock des TARP-Pakets immer auf einen nächsten Sprung in einer Reihe von TARP-Router-Sprüngen oder auf das Endziel. Das heißt, da das Ziel immer der TARP-Router des nächsten Sprungs sowie das Endziel sein könnte, gibt es von einem abgefangenen TARP-Paket keine offene Angabe des wahren Ziels des TARP-Pakets.
Das wahre Ziel jedes TARP-Pakets ist unter einer Verschlüsselungsschicht verborgen, die unter Verwendung eines Verbindungsschlüssels erzeugt wird. Der Verbindungsschlüssel ist der Verschlüsselungsschlüssel, der für die verschlüsselte Kommunikation zwischen den Sprüngen verwendet wird, die zwischen einem Ursprungs-TARP-Endgerät und einem Ziel-TARP-Endgerät liegen. Jeder TARP-Router kann die äußere Verschlüsselungsschicht entfernen, um den Ziel-Router für jedes TARP-Paket zu offenbaren. Um den zum Entschlüsseln der äußeren Verschlüsselungsschicht eines TARP-Pakets benötigten Verbindungsschlüssel zu identifizieren, kann ein Empfangs-TARP- oder Routing-Endgerät das sendende Endgerät durch die Sender/Empfänger-IP-Nummern in dem Klartext-IP-Anfangsblock identifizieren.
Wenn die äußere Verschlüsselungsschicht entfernt worden ist, bestimmt der TARP-Router das Endziel. Jedes TARP-Paket 140 erfährt eine minimale Anzahl von Sprüngen, um die Verkehrsanalyse vereiteln zu helfen. Die Sprünge können zufällig oder durch einen festen Wert gewählt werden. Im Ergebnis kann jedes TARP-Paket zufällige Touren unter einer Anzahl geographisch verschiedener Router durchlaufen, bevor es sein Ziel erreicht. Da jede Tour unabhängig zufällig bestimmt wird, ist höchstwahrscheinlich für jedes Paket, das eine gegebene Nachricht bildet, jede Tour anders. Dieses Merkmal wird agiles Routing genannt. Die Tatsache, dass verschiedene Pakete verschiedene Leitwege nehmen, schafft deutliche Vorteile, indem sie es für einen Eindringling erschwert, alle Pakete zu erhalten, die eine gesamte Mehrpaketnachricht bilden. Die zugeordneten Vorteile haben mit der im Folgenden diskutierten inneren Verschlüsselungsschicht zu tun. Das agile Routing wird mit einem weiteren Merkmal kombiniert, das diesen Zweck fördert; einem Merkmal, das sicherstellt, dass irgendeine Nachricht in mehrere Pakete zerlegt wird.
Die IP-Adresse eines TARP-Routers kann geändert werden, was ein Merkmal ist, das IP-Agilität genannt wird. Jeder TARP-Router kann unabhängig oder gemäß Anweisung von einem anderen TARP-Endgerät oder -Router seine IP-Adresse ändern. Außerdem wird ein getrennter, unveränderlicher Identifizierer oder eine getrennte, unveränderliche Adresse definiert. Diese Adresse, die die TARP-Adresse genannt wird, ist nur den TARP-Routern und -Endgeräten bekannt und kann jederzeit durch einen TARP-Router oder durch ein TARP-Endgerät unter Verwendung einer Nachschlagetabelle (LUT) korreliert werden. Wenn ein TARP-Router oder -Endgerät seine IP-Adresse ändert, aktualisiert er/es die anderen TARP-Router und -Endgeräte, die wiederum ihre jeweiligen LUTs aktualisieren.
Die Nachrichten-Nutznachricht ist hinter einer inneren Verschlüsselungsschicht in dem TARP-Paket verborgen, das nur unter Verwendung eines Sitzungsschlüssels entsperrt werden kann. Der Sitzungsschlüssel ist für irgendeinen der Zwischenschicht-TARP-Router nicht verfügbar. Der Sitzungsschlüssel wird verwendet, um die Nutznachrichten der TARP-Pakete zu entschlüsseln, was den Datenstrom zu rekonstruieren ermöglicht.
Die Kommunikation kann unter Verwendung von Verbindungs- und Sitzungsschlüsseln privat gemacht werden, die wiederum gemäß irgendeinem gewünschten Verfahren gemeinsam genutzt und verwendet werden können. Zum Beispiel können öffentliche/private Schlüssel oder symmetrische Schlüssel verwendet werden.
Um einen Datenstrom zu übertragen, konstruiert ein TARP-Ursprungsendgerät aus einer Reihe von IP-Paketen, die durch einen Vermittlungsschichtprozess (IP-Schichtprozess) erzeugt werden, eine Reihe von TARP-Paketen. (Es wird angemerkt, dass die Begriffe "Vermittlungsschicht", "Sicherungsschicht", "Anwendungsschicht" usw. in dieser Beschreibung entsprechend der Open-Systems-Interconnection-Netzterminologie (OSI-Netzterminologie) verwendet werden.) Die Nutznachrichten dieser Pakete werden zu einem Block und einem unter Verwendung des Sitzungsschlüssels verschlüsselten Kettenblock zusammengesetzt. Dabei wird natürlich angenommen, dass alle IP-Pakete für dasselbe TARP-Endgerät bestimmt sind. Daraufhin wird der Block verschachtelt und der verschachtelte verschlüsselte Block in eine Reihe von Nutznachrichten, eine für jedes zu erzeugende TARP-Paket, zerlegt. Daraufhin werden unter Verwendung der IP-Anfangsblöcke aus den Datenstrompaketen zu jeder Nutznachricht spezielle TARP-Anfangsblöcke IP_T hinzugefügt. Die TARP-Anfangsblöcke können gleich normalen IP-Anfangsblöcken oder auf gewisse Weise angepasst sein. Sie sollten eine Formel oder Daten zum Entschachteln der Daten des Ziel-TARP-Endgeräts, einen Lebensdauerparameter (TTL-Parameter) zur Angabe der Anzahl der Sprünge, die noch auszuführen sind, einen Datentypidentifizierer, der angibt, ob die Nutznachricht z. B. TCP- oder UDP-Daten enthält, die TARP-Adresse des Senders, die Ziel-TARP-Adresse und, falls auf irgendeine Weise Attrappendaten über die TARP-Nutznachrichtendaten verteilt sind, einen Indikator, ob das Paket reale oder Attrappendaten enthält, oder eine Formel zum Herausfiltern von Attrappendaten enthalten.
Obgleich hier in Bezug auf den Sitzungsschlüssel die Kettenblockverschlüsselung diskutiert wird, wird angemerkt, dass irgendein Verschlüsselungsverfahren verwendet werden kann. Vorzugsweise sollte wie in der Kettenblockverschlüsselung ein Verfahren verwendet werden, das eine unberechtigte Entschlüsselung ohne ein Gesamtergebnis des Verschlüsselungsprozesses erschwert. Somit wird dem Inhalt der Kommunikation dadurch, dass der verschlüsselte Block auf mehrere Pakete geteilt wird und es für einen Eindringling erschwert wird, Zugang zu allen diesen Paketen zu erhalten, eine zusätzliche Sicherheitsschicht verliehen.
Um die Verkehrsanalyse durch Verringern der Spitze-Durchschnitt-Netzlast vereiteln zu helfen, können zu einem Strom Attrappen- oder Leerdaten hinzugefügt werden. Es kann erwünscht sein, den TARP-Prozess mit einer Fähigkeit zur Reaktion auf die Tageszeit oder auf andere Kriterien zu versehen, um während Zeitdauern niedrigen Verkehrs mehr Attrappendaten zu erzeugen, so dass Kommunikationsdatenbündel an einem Punkt im Internet nicht mit Kommunikationsdatenbündeln an einem anderen Punkt verknüpft werden können, um die Kommunikationsendpunkte zu offenbaren.
Außerdem helfen Leerdaten, die Daten in eine größere Anzahl unauffällig großer Pakete zu zerlegen, was es ermöglicht, die Verschachtelungsfenstergröße zu erhöhen, während eine sinnvolle Größe für jedes Paket aufrechterhalten wird. (Die Paketgröße kann eine einzige Standardgröße sein oder aus einem festen Bereich von Größen ausgewählt werden.) Ein Hauptgrund für den Wunsch, jede Nachricht in mehrere Pakete zu zerlegen, ist offensichtlich, falls ein Kettenblock-Verschlüsselungsschema verwendet wird, um vor der Verschachtelung die erste Verschlüsselungsschicht zu bilden. Auf einen Abschnitt oder auf die Gesamtheit einer Nachricht kann eine Einzelblockverschlüsselung angewendet werden und dieser Abschnitt oder diese Gesamtheit daraufhin zu einer Anzahl getrennter Pakete verschachtelt werden. Angesichts des agilen IP-Routing der Pakete und der damit zusammenhängenden Schwierigkeit der Rekonstruktion einer Gesamtfolge von Paketen, um ein einzelnes blockverschlüsseltes Nachrichtenelement zu bilden, können Attrappenpakete die Schwierigkeit der Rekonstruktion eines gesamten Datenstroms erheblich erhöhen.
Das obige Schema kann vollständig durch Prozesse realisiert werden, die zwischen der Sicherungsschicht und der Vermittlungsschicht jedes an dem TARP-System beteiligten Servers oder Endgeräts arbeiten. Da das oben beschriebene Verschlüsselungssystem zwischen die Sicherungsschicht und die Vermittlungsschicht eingefügt werden kann, können die an der Unterstützung der verschlüsselten Kommunikation beteiligten Prozesse für Prozesse in der IP-Schicht (Vermittlungsschicht) und darüber vollständig transparent sein. Außerdem können die TARP-Prozesse auch für die Sicherungsschichtprozesse vollständig transparent sein. Somit werden durch die Einfügung des TARP-Stapels keine Operationen in der oder über der Vermittlungsschicht oder in der oder unter der Sicherungsschicht beeinflusst. Dies schafft zusätzliche Sicherheit für alle Prozesse in der oder über der Vermittlungsschicht, da die Schwierigkeit eines unberechtigten Durchdringens der Sicherungsschicht (z. B. durch einen Hacker) wesentlich erhöht wird. Selbst neu entwickelte Server, die in der Kommunikationssteuerschicht ausgeführt werden, lassen alle Prozesse unter der Kommunikationssteuerschicht anfällig für einen Angriff. Es wird angemerkt, dass die Sicherheit in dieser Architektur verteilt ist. Das heißt, Notebook-Computer, die z. B. von leitenden Angestellten auf der Straße verwendet werden, können ohne irgendeine Gefährdung der Sicherheit über das Internet kommunizieren.
IP-Adressenänderungen, die durch TARP-Endgeräte und -Router vorgenommen werden, können in regelmäßigen Intervallen, in zufälligen Intervallen oder bei Erfassung von "Angriffen" erfolgen. Die Änderung von IP-Adressen behindert die Verkehrsanalyse, die offenbaren könnte, welche Computer kommunizieren, und schafft außerdem einen Grad der Unempfindlichkeit gegen einen Angriff. Das Niveau der Unempfindlichkeit gegen einen Angriff ist annähernd proportional zu der Rate, mit der sich die IP-Adresse des Hosts ändert.
Wie erwähnt wurde, können in Reaktion auf Angriffe IP-Adressen geändert werden. Ein Angriff kann z. B. durch eine regelmäßige Reihe von Nachrichten offenbart werden, die angeben, dass ein Router in irgendeiner Weise sondiert wird. Bei Erfassung eines Angriffs kann der TARP-Schicht-Prozess auf dieses Ereignis dadurch reagieren, dass er seine IP-Adresse ändert. Außerdem kann er einen Teilprozess erzeugen, der die ursprüngliche IP-Adresse behält und in irgendeiner Weise weiter mit dem Angreifer in Wechselwirkung bleibt.
Durch jedes TARP-Endgerät können auf einer durch einen Algorithmus bestimmten Grundlage Attrappenpakete erzeugt werden. Zum Beispiel kann der Algorithmus ein zufälliger sein, der die Erzeugung eines Pakets auf zufälliger Grundlage verlangt, wenn das Endgerät ungenutzt ist. Alternativ kann der Algorithmus auf die Tageszeit oder auf die Erfassung von niedrigem Verkehr reagieren, um während Zeiten niedrigen Verkehrs mehr Attrappenpakete zu erzeugen. Es wird angemerkt, dass Pakete vorzugsweise eher in Gruppen als einzeln erzeugt werden, wobei die Gruppen so groß sind, dass sie reale Nachrichten simulieren. Außerdem kann die Hintergrundschleife einen Zwischenspeicher haben, der es wahrscheinlicher macht, dass Attrappenpakete eingefügt werden, wenn ein Nachrichtenstrom empfangen wird, so dass Attrappenpakete in normale TARP-Nachrichtenströme eingefügt werden können. Alternativ kann der Algorithmus eher die Rate des Fallenlassens von Attrappenpaketen als ihres Weiteleitens erhöhen, als sie weiterzuleiten, falls eine große Anzahl von Attrappenpakten mit regulären TARP-Paketen empfangen werden. Das Ergebnis des Fallenlassens und des Erzeugens von Attrappenpaketen auf diese Weise ist, dass die sichtbare Größe ankommender Nachrichten verschieden von der sichtbaren Größe abgehender Nachrichten gemacht wird, um die Verkehrsanalyse vereiteln zu helfen.
In verschiedenen weiteren Ausführungsformen der Erfindung kann eine skalierbare Version des Systems konstruiert werden, in der jedem Paar kommunizierender Knoten in dem Netz mehrere IP-Adressen im Voraus zugewiesen werden. Jedes Knotenpaar stimmt über einen Algorithmus zum "Springen" zwischen (sowohl sendenden als auch empfangenden) IP-Adressen überein, so dass ein Abhörer für zwischen dem Paar übertragene Pakete offensichtlich ständig zufällige IP-Adressenpaare (Quelle und Ziel) sieht. Da jeder Knoten lediglich verifiziert, dass ein besonderes Paket ein gültiges Quell/Ziel-Paar von dem abgestimmten Algorithmus enthält, können verschiedenen Anwendern in demselben Teilnetz überlappende oder "wieder verwendbare" IP-Adressen zugeordnet werden. Vorzugsweise werden die Quell/Ziel-Paare vorzugsweise zwischen irgend zwei Knoten während irgendeiner gegebenen Ende-Ende-Sitzung nicht wiederverwendet, obgleich es begrenzte IP-Blockgrößen oder längere Sitzungen erfordern könnten.
Weitere in dieser Teilfortführungsanmeldung beschriebene Verbesserungen enthalten: (1) einen Lastverteiler, der Pakete gemäß der Übertragungswegqualität auf verschiedene Übertragungswege verteilt; (2) einen DNS-Proxy-Server, der in Reaktion auf eine Domänennamenanfrage transparent ein virtuelles privates Netz erzeugt; (3) ein Groß/Klein-Verbindungsbandbreiten-Managementmerkmal, das Dienstverweigerungsangriffe an Systemdrosselpunkten verhindert; (4) einen Verkehrsbegrenzer, der ankommende Pakete reguliert, indem er die Rate begrenzt, mit der ein Sender mit einem Empfänger synchronisiert werden kann; und (5) eine Signalsynchronisiereinrichtung, die ermöglicht, dass eine große Anzahl von Knoten mit einem Zentralknoten kommunizieren, indem sie die Kommunikationsfunktion auf zwei getrennte Entitäten aufteilt.
Die vorliegende Erfindung schafft unter Verwendung eines neuen agilen Netzpro tokolls, das auf das vorhandene Internet-Protokoll (IP) aufbaut, Schlüsseltechnologien zur Realisierung eines sicheren virtuellen Internet. Das sichere virtuelle Internet arbeitet über die vorhandene Internet-Infrastruktur und verbindet in der gleichen Weise wie das vorhandene Internet mit Client-Anwendungen. Die durch die vorliegende Erfindung geschaffenen Schlüsseltechnologien, die das sichere virtuelle Internet unterstützen, enthalten eine "Ein-Klick"-Technik und eine "Kein-Klick"-Technik, um Teil des sicheren virtuellen Internet zu werden, einen Dienst für sichere Domänennamen (SDNS) für das sichere virtuelle Internet und einen neuen Zugang zum Verbinden spezifischer Client-Anwendungen mit dem sicheren virtuellen Internet. Gemäß der Erfindung verbindet der Dienst für sichere Domänennamen, außer, dass er eine Möglichkeit zum Registrieren von und Versorgen mit Domänennamen und Adressen schafft, mit vorhandenen Anwendungen.
Gemäß einem Aspekt der vorliegenden Erfindung kann ein Anwender zweckmäßig unter Verwendung einer "Ein-Klick"-Technik oder einer "Kein-Klick"-Technik ein VPN aufbauen, ohne dass es erforderlich ist, für den Aufbau eines VPN Anwenderidentifizierungsinformationen, ein Kennwort und/oder einen Verschlüsselungsschlüssel einzugeben. Die Vorteile der vorliegenden Erfindung werden durch ein Verfahren zum Aufbauen einer sicheren Kommunikationsverbindung zwischen einem ersten Computer und einem zweiten Computer über ein Computernetz wie etwa über das Internet geschaffen. In einer Ausführungsform wird eine sichere Kommunikationsbetriebsart bei einem ersten Computer freigegeben, ohne dass ein Anwender irgendwelche kryptographischen Informationen eingibt, um die Kommunikationsbetriebsart der sicheren Kommunikation aufzubauen, indem er vorzugsweise lediglich ein Symbol auswählt, das auf dem ersten Computer angezeigt wird. Alternativ kann die Kommunikationsbetriebsart der sicheren Kommunikation durch Eingabe einer Anweisung in dem ersten Computer freigegeben werden. Daraufhin wird auf der Grundlage der freigegebenen Kommunikationsbetriebsart der sicheren Kommunikation zwischen dem ersten Computer und dem zweiten Computer eine sichere Kommunikationsverbindung über ein Computernetz aufgebaut. Gemäß der Erfindung wird in Reaktion auf die Freigabe der Kommunikationsbetriebsart der sicheren Kommunikation bestimmt, ob auf dem ersten Computer ein Software-Modul der sicheren Kommunikation gespeichert ist. Daraufhin wird auf eine vorgegebene Computernetzadresse zugegriffen, um das Software-Modul der sicheren Kommunikation zu laden, wenn das Software-Modul nicht auf dem ersten Computer gespeichert ist. Nachfolgend wird das Proxy-Software-Modul in dem ersten Computer gespeichert. Die sichere Kommunikationsverbin dung ist eine Kommunikationsverbindung eines virtuellen privaten Netzes über das Computernetz. Vorzugsweise kann das virtuelle private Netz auf dem Einfügen eines oder mehrerer Datenwerte, die sich gemäß einer Pseudo-Zufallsfolge ändern, in jedes Datenpaket beruhen. Alternativ kann das virtuelle private Netz auf einem Computernetzadressen-Sprungregime beruhen, das verwendet wird, um die Computernetzadressen oder andere Datenwerte in Paketen, die zwischen dem ersten Computer und dem zweiten Computer übertragen werden, pseudo-zufällig so zu ändern, dass der zweite Computer die Datenwerte in jedem zwischen dem ersten Computer und dem zweiten Computer übertragenen Paket mit einem sich bewegenden Fenster gültiger Werte vergleicht. Eine nochmals weitere Alternative sichert, dass das virtuelle private Netz auf einem Vergleich zwischen einem Diskriminatorfeld in jedem Datenpaket mit einer für den ersten Computer unterhaltenen Tabelle gültiger Diskriminatorfelder beruhen kann.
Gemäß einem weiteren Aspekt der Erfindung wird eine Anweisung eingegeben, um einen Setup-Parameter zu definieren, der der Kommunikationsbetriebsart der sicheren Kommunikationsverbindung zugeordnet ist. Folglich wird die sichere Kommunikationsbetriebsart automatisch aufgebaut, wenn über das Computernetz eine Kommunikationsverbindung aufgebaut wird.
Außerdem schafft die vorliegende Erfindung ein Computersystem mit einer Kommunikationsverbindung zu einem Computernetz und mit einer Anzeige, die einen Hyperlink für den Aufbau eines virtuellen privaten Netzes über das Computernetz anzeigt. Wenn der Hyperlink für den Aufbau des virtuellen privaten Netzes ausgewählt wird, wird über das Computernetz ein virtuelles privates Netz aufgebaut. Daraufhin wird über die Kommunikation des virtuellen privaten Netzes ein Nicht-Standard-Top-Level-Domänenname zu einer vorgegebenen Computernetzadresse wie etwa zu einer Computernetzadresse für einen Dienst für sichere Domänennamen (SDNS) gesendet.
Die vorliegende Erfindung schafft einen Domänennamendienst, der sichere Computernetzadressen für sichere Nicht-Standard-Top-Level-Domänennamen bereitstellt. Die Vorteile der vorliegenden Erfindung werden durch einen Dienst für sichere Domänennamen für ein Computernetz geschaffen, der ein mit einem Computernetz wie etwa mit dem Internet verbundenes Portal und eine über das Portal mit dem Computernetz verbundene Domänennamen-Datenbank enthält. Gemäß der Erfindung authentisiert das Portal eine Abfrage für eine sichere Computer netzadresse, wobei die Domänennamen-Datenbank sichere Computernetzadressen für das Computernetz speichert. Jede sichere Computernetzadresse beruht auf einem Nicht-Standard-Top-Level-Domänennamen wie etwa .scom, .sorg, .snet, .snet, .sedu, .smil und .sint.
Die vorliegende Erfindung schafft eine Möglichkeit zum Kapseln von vorhandenem Anwendungsnetzverkehr in der Anwendungsschicht eines Client-Computers, so dass die Client-Anwendung sicher mit einem durch ein agiles Netzprotokoll geschützten Server kommunizieren kann. Außerdem werden die Vorteile der vorliegenden Erfindung durch ein Verfahren zum Kommunizieren unter Verwendung einer privaten Kommunikationsverbindung zwischen einem Client-Computer und einem Server-Computer über ein Computernetz wie etwa das Internet geschaffen. Gemäß der Erfindung wird ein Informationspaket von dem Client-Computer über das Computernetz zu dem Server-Computer gesendet. Das Informationspaket enthält Daten, die in der Anwendungsschicht des Client-Computers in den Nutznachrichtenabschnitt des Pakets eingefügt werden und wird zum Bilden einer virtuellen privaten Verbindung zwischen dem Client-Computer und dem Server-Computer verwendet. Das geänderte Informationspaket kann über eine Firewall gesendet werden, bevor es über das Computernetz zu dem Server-Computer gesendet wird, wobei die vorliegende Erfindung dadurch, dass sie über vorhandenen Protokollen (d. h. UDP, ICMP und TCP) arbeitet, die Firewall leichter durchdringt. Das Informationspaket wird auf der Server-Seite in einer Kernel-Schicht eines Betriebssystems empfangen. Daraufhin wird in der Kernel-Schicht des Betriebssystems auf dem Host-Computer bestimmt, ob das Informationspaket die Daten enthält, die zum Bilden der virtuellen privaten Verbindung verwendet werden. Die Server-Seite antwortet dadurch, dass sie zu dem Client-Computer ein Informationspaket sendet, das in der Kernel-Schicht so geändert worden ist, dass es in dem Nutznachrichtenabschnitt des Antwortinformationspakets Informationen über die virtuelle private Verbindung enthält. Vorzugsweise sind das Informationspaket von dem Client-Computer und das Antwortformationspaket von der Server-Seite jeweils ein UDP-Protokoll-Informationspaket. Alternativ könnten beide Informationspakete ein TCP/IP-Protokoll-Informationspaket oder ein ICMP-Protokoll-Informationspaket sein.
KURZBESCHREIBUNG DER ZEICHNUNG
1 ist eine Veranschaulichung der sicheren Kommunikation über das Internet gemäß einer Ausführungsform des Standes der Technik.
2 ist eine Veranschaulichung der sicheren Kommunikation über das Internet gemäß einer Ausführungsform der Erfindung.
3a ist eine Veranschaulichung eines Prozesses des Bildens eines getunnelten IP-Pakets gemäß einer Ausführungsform der Erfindung.
3b ist eine Veranschaulichung eines Prozesses des Bildens eines getunnelten IP-Pakets gemäß einer weiteren Ausführungsform der Erfindung.
4 ist eine Veranschaulichung eines OSI-Schicht-Ortes eines Prozesses, der zur Realisierung der Erfindung verwendet werden kann.
5 ist ein Ablaufplan, der einen Prozess zum Leiten eines getunnelten Pakets gemäß einer Ausführungsform der Erfindung veranschaulicht.
6 ist ein Ablaufplan, der einen Prozess zum Bilden eines getunnelten Pakets gemäß einer Ausführungsform der Erfindung veranschaulicht.
7 ist ein Ablaufplan, der einen Prozess zum Empfangen eines getunnelten Pakets gemäß einer Ausführungsform der Erfindung veranschaulicht.
8 zeigt, wie eine sichere Sitzung zwischen einem Client und einem TARP-Router aufgebaut und synchronisiert wird.
9 zeigt ein IP-Adressen-Sprungschema zwischen einem Client-Computer und einem TARP-Router, das in jedem Computer Sende- und Empfangstabellen verwendet.
10 zeigt die Redundanz physikalischer Verbindungen zwischen drei Internet-Dienste-Anbietern (ISPs) und einem Client-Computer.
11 zeigt, wie mehrere IP-Pakete in einen einzigen "Rahmen" wie etwa in einen Ethernet-Rahmen eingebettet werden können, und zeigt ferner die Verwendung eines Diskriminatorfelds zum Tarnen der wahren Paketempfänger.
12A zeigt ein System, das gesprungene Hardwareadressen, gesprungene IP-Adressen und gesprungene Diskriminatorfelder verwendet.
12B zeigt mehrere verschiedene Zugänge für gesprungene Hardwareadressen, IP-Adressen und Diskriminatorfelder gemeinsam.
13 zeigt eine Technik zum automatischen Wiederherstellen der Synchronisation zwischen dem Sender und dem Empfänger unter Verwendung eines teilweise öffentlichen Sync-Werts.
14 zeigt ein "Fixpunkt"-Schema zum Wiedergewinnen der Synchronisation zwischen einem Sender und einem Empfänger.
15 zeigt weitere Einzelheiten des Fixpunktschemas aus 14.
16 zeigt, wie zwei Adressen für den Vergleich mit Anwesenheitsvektoren in mehrere Segmente getrennt werden können.
17 zeigt eine Speicheranordnung für die aktive Adresse eines Empfängers.
18 zeigt die Speicheranordnung des Empfängers nach dem Empfang einer Sync-Anforderung.
19 zeigt die Speicheranordnung des Empfängers, nachdem neue Adressen erzeugt worden sind.
20 zeigt ein System, das verteilte Übertragungswege verwendet.
21 zeigt mehrere Verbindungssendetabellen, die in dem System aus 20 zum Leiten von Paketen verwendet werden können.
22A zeigt einen Ablaufplan zum Einstellen von Gewichtungswertverteilungen, die mehreren Übertragungsverbindungen zugeordnet sind.
22B zeigt einen Ablaufplan zum Einstellen eines Gewichtungswerts auf null, falls ein Sender abgeschaltet wird.
23 zeigt ein System, das verteilte Übertragungswege mit angepassten Gewichtungswertverteilungen für jeden Weg nutzt.
24 zeigt ein Beispiel, das das System aus 23 verwendet.
25 zeigt einen herkömmlichen Domänennamen-Nachschlagedienst.
26 zeigt ein System, das einen DNS-Proxy-Server mit transparenter VPN-Erzeugung nutzt.
27 zeigt Schritte, die zur Realisierung der transparenten VPN-Erzeugung anhand einer DNS-Nachschlagefunktion ausgeführt werden können.
28 zeigt ein System, das eine Verbindungsschutzfunktion enthält, die die Paketüberlastung auf einer Verbindung LOW BW mit niedriger Bandbreite verhindert.
29 zeigt eine Ausführungsform eines Systems, das die Prinzipien aus 28 nutzt.
30 zeigt ein System, das durch Drosseln der Rate, mit der Synchronisationen ausgeführt werden, die Paketübertragungsraten reguliert.
31 zeigt einen Signalisierungs-Server 3101 und einen Transport-Server 3102, die zum Aufbauen eines VPN mit einem Client-Computer verwendet werden.
32 zeigt Nachrichtenflüsse, die sich auf die Synchronisationsprotokolle aus 31 beziehen.
33 zeigt einen Systemblockschaltplan eines Computernetzes, in dem die sichere "Ein-Klick"-Kommunikationsverbindung der vorliegenden Erfindung zur Verwendung geeignet ist.
34 zeigt einen Ablaufplan zum Installieren und Aufbauen einer sicheren "Ein-Klick"-Kommunikationsverbindung über ein Computernetz gemäß der vorliegenden Erfindung.
35 zeigt einen Ablaufplan für das Registrieren eines sicheren Domänenna mens gemäß der vorliegenden Erfindung.
36 zeigt einen Systemblockschaltplan eines Computernetzes, in dem eine private Verbindung gemäß der vorliegenden Erfindung so konfiguriert werden kann, dass sie eine Firewall zwischen zwei Computernetzen leichter durchquert.
37 zeigt einen Ablaufplan für den Aufbau einer virtuellen privaten Verbindung, die unter Verwendung eines vorhandenen Netzprotokolls gekapselt ist.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Wie in 2 gezeigt ist, nutzt ein sicherer Mechanismus für die Kommunikation über das Internet eine Anzahl spezieller Router oder Server, die TARP-Router 122–127 genannt werden, die dahingehend ähnlich normalen IP-Routern 128–132 sind, dass jeder eine oder mehrere IP-Adressen besitzt und das normale IP-Protokoll zum Senden normal aussehender IP-Paket-Nachrichten verwendet, die TARP-Pakete 140 genannt werden. Da jedes TARP-Paket 140 wie in einem normalen IP-Paket eine Zieladresse enthält, sind die TARP-Pakete 140 gleich normalen IP-Paket-Nachrichten, die durch normale IP-Router 128–132 geleitet werden. Anstatt in dem Zielfeld des IP-Anfangsblocks ein Endziel anzugeben, zeigt der IP-Anfangsblock des TARP-Pakets 140 aber stattdessen auf einen nächsten Sprung in einer Reihe von TARP-Router-Sprüngen oder auf das Endziel, das TARP-Endgerät 110. Da der Anfangsblock des TARP-Pakets nur das Ziel des nächsten Sprungs enthält, gibt es von einem abgefangenen TARP-Paket keine offene Angabe des wahren Ziels des TARP-Pakets 140, da das Ziel immer der TARP-Router des nächsten Sprungs sowie das Endziel, das TARP-Endgerät 110, sein könnte.
Das wahre Ziel jedes TARP-Pakets ist hinter einer äußeren Verschlüsselungsschicht verborgen, die unter Verwendung eines Verbindungsschlüssels 146 erzeugt wird. Der Verbindungsschlüssel 146 ist der Verschlüsselungsschlüssel, der für die verschlüsselte Kommunikation zwischen den Endpunkten (TARP-Endpunkten oder TARP-Routern) einer einzelnen Verbindung in der Kette von Sprüngen verwendet wird, die das Ursprungs-TARP-Endgerät 100 und das Ziel-TARP-Endgerät 110 verbinden. Jeder TARP-Router 122–127 kann unter Verwendung des Verbindungsschlüssels 146, den er zur Kommunikation mit dem vorangehenden Sprung in einer Kette verwendet, den Verbindungsschlüssel zum Offenbaren des wahren Ziels eines TARP-Pakets verwenden. Um den zum Entschlüsseln der äußeren Verschlüsselungsschicht eines TARP-Pakets benötigten Verbindungsschlüssel zu identifizieren, kann ein empfangendes TARP- oder Routing-Endgerät das sendende Endgerät (das den verwendeten Verbindungsschlüssel angeben kann) durch das Senderfeld des Klar-IP-Anfangsblocks identifizieren. Alternativ kann diese Identität hinter einer weiteren Verschlüsselungsschicht in verfügbaren Bits in dem Klar-IP-Anfangsblock verborgen sein. Beim Empfang einer TARP-Nachricht bestimmt jeder TARP-Router unter Verwendung der Authentisierungsdaten in dem TARP-Paket, ob die Nachricht eine TARP-Nachricht ist. Dies könnte in verfügbaren Bytes in dem IP-Anfangsblock des TARP-Pakets aufgezeichnet sein. Alternativ könnten TARP-Pakete dadurch authentisiert werden, dass unter Verwendung des Verbindungsschlüssels 146 zu entschlüsseln versucht wird und zu bestimmen versucht wird, ob die Ergebnisse erwartungsgemäß sind. Das Erstere kann rechnerische Vorteile haben, da es keinen Entschlüsselungsprozess umfasst.
Wenn die äußere Entschlüsselungsschicht durch einen TARP-Router 122–127 abgeschlossen ist, bestimmt der TARP-Router das Endziel. Vorzugsweise ist das System so konstruiert, dass veranlasst wird, dass jedes TARP-Paket 140 eine minimale Anzahl von Sprüngen erfährt, was die Verkehrsanalyse vereiteln hilft. Der Lebensdauerzähler in dem IP-Anfangsblock der TARP-Nachricht kann dazu verwendet werden, eine Anzahl von TARP-Router-Sprüngen anzugeben, die noch abgeschlossen werden müssen. Daraufhin dekrementiert jeder TARP-Router den Zähler und bestimmt daraus, ob er das TARP-Paket 140 an einen weiteren TARP-Router 122–127 oder an das Ziel-TARP-Endgerät 110 weiterleiten sollte. Als ein Verwendungsbeispiel kann der TARP-Router, der das TARP-Paket 140 empfängt, das TARP-Paket 140 an das Ziel-TARP-Endgerät 110 weiterleiten, falls der Lebensdauerzähler nach dem Dekrementieren null oder unter null ist. Falls für ein Verwendungsbeispiel der Lebensdauerzähler nach dem Dekrementieren über null ist, kann der TARP-Router, der das TARP-Paket 140 empfängt, das TARP-Paket 140 zu einem TARP-Router 122–127 weiterleiten, den das momentane TARP-Endgerät zufällig auswählt. Im Ergebnis wird jedes TARP-Paket 140 über eine minimale Anzahl von Sprüngen der TARP-Router 122–127, die zufällig gewählt werden, geleitet.
Somit unternimmt jedes TARP-Paket unabhängig von den herkömmlichen Faktoren, die den Verkehr im Internet bestimmen, zufällige Touren zwischen einer An zahl geographisch verschiedener Router, bevor es sein Ziel erreicht, wobei höchstwahrscheinlich jede Tour für jedes Paket, das eine gegebene Nachricht bildet, anders ist, da jede Tour, wie oben beschrieben wurde, unabhängig zufällig bestimmt wird. Dieses Merkmal wird agiles Routing genannt. Aus Gründen, die gleich klar werden, schafft die Tatsache, dass verschiedene Pakete verschiedene Leitwege nehmen, deutliche Vorteile, indem sie es für einen Eindringling erschwert, alle Pakete zu erhalten, die eine gesamte Mehrpaketnachricht bilden. Das agile Routing wird mit einem weiteren Merkmal, das diesen Zweck fördert, einem Merkmal, das sicherstellt, dass irgendeine Nachricht in mehrere Pakete zerlegt wird, kombiniert.
Ein TARP-Router empfängt ein TARP-Paket, wenn eine von dem TARP-Router verwendete IP-Adresse mit der IP-Adresse in dem IP-Anfangsblock IP_C des TARP-Pakets übereinstimmt. Allerdings braucht die IP-Adresse eines TARP-Routers nicht konstant zu bleiben. Um Angriffe zu vermeiden und zu managen, kann jeder TARP-Router unabhängig oder gemäß Anweisung von einem anderen TARP-Endgerät oder -Router seine IP-Adresse ändern. Außerdem wird ein getrennter, unveränderlicher Identifizierer oder eine getrennte, unveränderliche Adresse definiert. Diese Adresse, die die TARP-Adresse genannt wird, ist nur TARP-Routern und -Endgeräten bekannt und kann durch einen TARP-Router oder ein TARP-Endgerät jederzeit unter Verwendung einer Nachschlagetabelle (LUT) korreliert werden. Wenn ein TARP-Router oder -Endgerät seine IP-Adresse ändert, aktualisiert er/es die anderen TARP-Router und -Endgeräte, die ihrerseits ihre jeweiligen LUTs aktualisieren. In der Realität muss ein TARP-Router jedes Mal eine TARP-Adresse unter Verwendung seiner LUT in eine reale IP-Adresse umsetzen, wenn er die Adresse eines Ziels in dem verschlüsselten Anfangsblock nachschlägt.
Obgleich jeder TARP-Router, der ein TARP-Paket empfängt, die Fähigkeit besitzt, das Endziel des Pakets zu bestimmen, ist die Nachrichten-Nutznachricht hinter eine innere Verschlüsselungsschicht in dem TARP-Paket eingebettet, die nur unter Verwendung eines Sitzungsschlüssels entsperrt werden kann. Der Sitzungsschlüssel ist für irgendeinen der TARP-Router 122–127, die zwischen dem Ursprungs-TARP-Endgerät 100 und dem Ziel-TARP-Endgerät 110 eingreifen, nicht verfügbar. Der Sitzungsschlüssel wird verwendet, um die Nutznachrichten der TARP-Pakete 140 zu entschlüsseln, was das Rekonstruieren einer Gesamtnachricht ermöglicht.
In einer Ausführungsform kann die Kommunikation unter Verwendung von Verbindungs- und Sitzungsschlüsseln privat gemacht werden, die wiederum gemäß irgendeinem gewünschten Verfahren gemeinsam genutzt und verwendet werden können. Zum Beispiel können zwischen den Verbindungs- oder Sitzungsendpunkten unter Verwendung eines Verfahrens mit öffentlichen Schlüsseln ein öffentlicher Schlüssel oder ein symmetrischer Schlüssel übermittelt werden. Auf Wunsch kann irgendeiner einer Vielzahl weiterer Mechanismen zum Sichern von Daten verwendet werden, um sicherzustellen, dass nur berechtigte Computer Zugriff auf die privaten Informationen in den TARP-Paketen 140 haben.
Wie in 3a gezeigt ist, wird zur Konstruktion einer Reihe von TARP-Paketen ein Datenstrom 300 von IP-Paketen 207a, 207b, 207c usw. wie etwa eine Reihe von Paketen, die durch einen Vermittlungsschichtprozess (IP-Schichtprozess) gebildet werden, in eine Reihe kleiner Segmente zerlegt. In dem vorliegenden Beispiel werden gleichgroße Segmente 1–9 definiert und zur Konstruktion einer Menge verschachtelter Datenpakete A, B und C verwendet. Hier wird angenommen, dass die Anzahl der gebildeten verschachtelten Pakete A, B und C drei ist und dass die Anzahl der IP-Pakete 207a–207c, die zum Bilden der drei verschachtelten Pakete A, B und C verwendet werden, genau drei ist. Natürlich kann die Anzahl der IP-Pakete, die über eine Gruppe verschachtelter Pakete verteilt sind, ebenso wie die Anzahl verschachtelter Pakete, über die der ankommende Datenstrom verteilt ist, irgendeine zweckmäßige Zahl sein. Das letztere, die Anzahl verschachtelter Pakete, über die der Datenstrom verteilt ist, wird das Verschachtelungsfenster genannt.
Um ein Paket zu erzeugen, verschachtelt die sendende Software die normalen IP-Pakete 207a usw., um eine neue Menge verschachtelter Nutznachrichtendaten 320 zu bilden. Diese Nutznachrichtendaten 320 werden daraufhin unter Verwendung eines Sitzungsschlüssels verschlüsselt, um eine Menge mittels Sitzungsschlüssel verschlüsselter Nutznachrichtendaten 330 zu bildet, von denen jede, A, B und C, die Nutznachrichten eines TARP-Pakets bilden. Unter Verwendung der IP-Anfangsblockdaten werden aus den ursprünglichen Paketen 207a–207c neue TARP-Anfangsblöcke IP_T gebildet. Die TARP-Anfangsblöcke IP_T können gleich normalen IP-Anfangsblöcken sein oder auf irgendeine Weise angepasst sein. In einer bevorzugten Anführungsform sind die TARP-Anfangsblöcke IP_T IP-Anfangsblöcke mit hinzugefügten Daten, die die folgenden für das Leiten und für die Wie derherstellung von Nachrichten erforderlichen Informationen liefern, wobei einige der Daten normal sind oder in normalen IP-Anfangsblöcken enthalten sein können:

1. Eine Fensterfolgenummer – ein Identifizierer, der angibt, wohin das Paket in der ursprünglichen Nachrichtenfolge gehört.
2. Eine Verschachtelungsfolgenummer – ein Identifizierer, der die Verschachtelungsfolge angibt, die zum Bilden des Pakets verwendet wird, so dass das Paket zusammen mit anderen Paketen in dem Verschachtelungsfenster entschachtelt werden kann.
3. Ein Lebensdauerdatum (TTL-Datum) – es gibt die Anzahl der TARP-Router-Sprünge an, die auszuführen sind, bevor das Paket sein Ziel erreicht. Es wird angemerkt, dass der TTL-Parameter ein Datum liefern kann, das in einer wahrscheinlichkeitstheoretischen Formel verwendet wird, um zu bestimmen, ob das Paket zu dem Ziel oder zu einem weiteren Sprung geleitet werden soll.
4. Datentypidentifizierer – dieser gibt an, ob die Nutznachricht z. B. TCP- oder UDP-Daten enthält.
5. Senderadresse – diese gibt die Adresse des Senders in dem TARP-Netz an.
6. Zieladresse – diese gibt die Adresse des Zielendgeräts in dem TARP-Netz an.
7. Attrappe/real – ein Indikator, ob das Paket reale Nachrichtendaten oder leere Attrappendaten oder eine Kombination enthält.

Offensichtlich dürfen die Pakete, die in ein einzelnes Verschachtelungsfenster gehen, nur Pakete mit einem gemeinsamen Ziel umfassen. Somit ist in dem gezeigten Beispiel angenommen, dass die IP-Anfangsblöcke der IP-Pakete 207a–207c alle dieselbe Zieladresse enthalten oder wenigstens durch dasselbe Endgerät empfangen werden, so dass sie entschachtelt werden können. Es wird angemerkt, dass Leer- oder Attrappendaten oder Leer- oder Attrappenpakete hinzugefügt werden können, um ein größeres Verschachtelungsfenster zu bilden, als es ansonsten für die Größe einer gegebenen Nachricht erforderlich wäre. Attrappen- oder Leerdaten können zu einem Strom hinzugefügt werden, um durch Nivellierung der Last in dem Netz eine Verkehrsanalyse vereiteln zu helfen. Somit kann es erwünscht sein, den TARP-Prozess mit einer Fähigkeit zu versehen, auf die Tageszeit oder auf andere Kriterien zu reagieren, um während Zeitdauern niedrigen Verkehrs mehr Attrappendaten zu erzeugen, so dass Kommunikationsdaten bündel an einem Punkt im Internet nicht mit Kommunikationsdatenbündeln an einem anderen Punkt verbunden werden können, um die Kommunikationsendpunkte zu offenbaren.
Außerdem helfen Attrappendaten, die Daten in eine größere Anzahl unauffällig großer Pakete zu zerlegen, was es ermöglicht, die Verschachtelungsfenstergröße zu erhöhen, während eine sinnvolle Größe für jedes Paket aufrechterhalten wird. (Die Paketgröße kann eine einzige Standardgröße sein oder aus einem festen Bereich von Größen ausgewählt werden.) Ein Hauptgrund für den Wunsch, jede Nachricht in mehrere Pakete zu zerlegen, ist klar, falls ein Kettenblock-Verschlüsselungsschema verwendet wird, um vor der Verschachtelung die erste Verschlüsselungsschicht zu bilden. Auf einen Abschnitt oder auf die Gesamtheit einer Nachricht kann eine Einzelblockverschlüsselung angewendet werden und daraufhin dieser Abschnitt oder diese Gesamtheit zu einer Anzahl getrennter Pakete verschachtelt werden.
Wie in 3b gezeigt ist, werden in einer alternativen Betriebsart der TARP-Paket-Konstruktion eine Reihe von IP-Paketen angesammelt, um ein vorgegebenes Verschachtelungsfenster zusammenzustellen. Die Nutznachrichten der Pakete werden verwendet, um unter Verwendung des Sitzungsschlüssels einen einzelnen Block 520 für die Kettenblockverschlüsselung zu konstruieren. Es wird angenommen, dass die Nutznachrichten, die zum Bilden des Blocks verwendet werden, für dasselbe Endgerät bestimmt sind. Wie in der beispielhaften Ausführungsform aus 3b gezeigt ist, kann die Blockgröße mit dem Verschachtelungsfenster übereinstimmen. Nach der Verschlüsselung wird der verschlüsselte Block in getrennte Nutznachrichten und Segmente geteilt, die wie in der Ausführungsform aus 3a verschachtelt werden. Daraufhin werden die resultierenden verschachtelten Pakete A, B und C wie in dem Beispiel aus 3a als TARP-Pakete mit TARP-Anfangsblöcken gepackt. Der verbleibende Prozess ist so, wie er anhand in 3a gezeigt ist und anhand dieser Figur diskutiert wurde.
Wenn die TARP-Pakete 340 gebildet werden, wird jedes gesamte TARP-Paket 340, das den TARP-Anfangsblock IP_T enthält, für die Kommunikation mit dem TARP-Router des ersten Sprungs unter Verwendung des Verbindungsschlüssels verschlüsselt. Der TARP-Router des ersten Sprungs wird zufällig gewählt. Zu jedem verschlüsselten TARP-Paket 340 wird ein letzter unverschlüsselter IP-Anfangsblock IP_C hinzugefügt, um ein normales IP-Paket 360 zu bilden, das zu einem TARP-Router übertragen werden kann. Es wird angemerkt, dass der Prozess des Konstruierens des TARP-Pakets 360 nicht wie beschrieben in Phasen erfolgen muss. Die obige Beschreibung ist lediglich eine nützliche Heuristik zur Beschreibung des Endprodukts, d. h. des TARP-Pakets.
Es wird angemerkt, dass der TARP-Anfangsblock IP_T abgesehen davon, dass er die oben identifizierten Informationen enthält, eine vollständig angepasste Anfangsblockkonfiguration ohne Ähnlichkeit mit einem normalen IP-Anfangsblock sein könnte. Dies ist so, da dieser Anfangsblock nur durch TARP-Router interpretiert wird.
Das obige Schema kann vollständig durch Prozesse realisiert werden, die zwischen der Sicherungsschicht und der Vermittlungsschicht jedes an dem TARP-System beteiligten Servers oder Endgeräts arbeiten. Anhand von 4 kann ein TARP-Empfänger 405 ein Ursprungsendgerät 100, ein Zielendgerät 110 oder ein TARP-Router 122–127 sein. In jedem TARP-Sender-Empfänger 405 wird ein Sendeprozess erzeugt, um normale Pakete von der Vermittlungsschicht (IP-Schicht) zu empfangen und TARP-Pakete zur Übermittlung über das Netz zu erzeugen. Es wird ein Empfangsprozess erzeugt, um normale IP-Pakete, die TARP-Pakete enthalten, zu empfangen und aus diesen normale IP-Pakete zu erzeugen, die an die Vermittlungsschicht (IP-Schicht) "nach oben übergeben" werden. Es wird angemerkt, dass die empfangenen TARP-Pakete 140 dort, wo der TARP-Sender-Empfänger 405 ein Router ist, nicht zu einem Strom von IP-Paketen 415 verarbeitet werden, da sie lediglich als richtige TARP-Pakete authentisiert und daraufhin an einen weiteren TARP-Router oder an ein TARP-Ziel-Endgerät 110 übergeben zu werden brauchen. Der Zwischenprozess, eine "TARP-Schicht" 420, könnte entweder mit der Sicherungsschicht 430 oder mit der Vermittlungsschicht 410 kombiniert sein. Auf jeden Fall würde er zwischen der Sicherungsschicht 430 eingreifen, so dass der Prozess reguläre IP-Pakete empfangen würde, die eingebettete TARP-Pakete empfangen, und eine Reihe neu zusammengesetzter IP-Pakete an die Vermittlungsschicht 410 "heraufreichen". Als ein Beispiel der Kombination der TARP-Schicht 420 mit der Sicherungsschicht 430 kann ein Programm die normalen Prozesse erweitern, die eine Kommunikationskarte, z. B. eine Ethernet-Karte, ausführt. Alternativ können die TARP-Schicht-Prozesse einen Teil eines dynamisch ladbaren Moduls bilden, das geladen und ausgeführt wird, um die Kommunikation zwischen der Vermittlungs- und der Sicherungsschicht zu unterstützen.
Da das oben beschriebene Verschlüsselungssystem zwischen die Sicherungsschicht und die Vermittlungsschicht eingefügt werden kann, können die an der Unterstützung der verschlüsselten Kommunikation beteiligten Prozesse für Prozesse in der IP-Schicht (Vermittlungsschicht) und darüber vollständig transparent sein. Außerdem können die TARP-Prozesse auch für die Sicherungsschichtprozesse vollständig transparent sein. Somit werden durch die Einfügung des TARP-Stapels keine Operationen in der oder über der Vermittlungsschicht oder in der oder unter der Sicherungsschicht beeinflusst. Dies schafft zusätzliche Sicherheit für alle Prozesse in der oder über der Vermittlungsschicht, da die Schwierigkeit des unberechtigten Durchdringens der Sicherungsschicht (z. B. durch einen Hacker) wesentlich erhöht ist. Selbst neu entwickelte Server, die in der Kommunikationssteuerschicht ausgeführt werden, lassen alle Prozesse unter der Vermittlungsschicht anfällig für einen Angriff. Es wird angemerkt, dass die Sicherheit in dieser Architektur verteilt ist. Das heißt, Notebook-Computer, die z. B. von leitenden Angestellten auf der Straße verwendet werden, können ohne irgendeine Gefährdung der Sicherheit über das Internet kommunizieren.
Es wird angemerkt, dass IP-Adressenänderungen, die durch TARP-Endgeräte und -Router vorgenommen werden, in regelmäßigen Intervallen, in zufälligen Intervallen oder bei Erfassung von "Angriffen" erfolgen können. Die Änderung der IP-Adressen behindert die Verkehrsanalyse, die offenbaren könnte, welche Computer kommunizieren, und schafft außerdem einen Grad der Unempfindlichkeit gegenüber einem Angriff. Das Niveau der Unempfindlichkeit gegenüber einem Angriff ist annähernd proportional zu der Rate, mit der sich die IP-Adresse des Hosts ändert.
Wie erwähnt wurde, können IP-Adressen in Reaktion auf Angriffe geändert werden. Ein Angriff kann z. B. durch eine reguläre Reihe von Nachrichten offenbart werden, die angibt, dass ein Router in irgendeiner Weise sondiert wird. Bei Erfassung eines Angriffs kann der TARP-Schicht-Prozess auf dieses Ereignis durch Ändern seiner IP-Adresse reagieren. Um dies auszuführen, konstruiert der TARP-Prozess eine TARP-formatierte Nachricht z. B. im Stil von Internet-Steuerungsnachrichtprotokoll-Datagrammen (ICMP-Datagrammen); diese Nachricht enthält die TARP-Adresse der Maschine, ihre frühere IP-Adresse und ihre neue IP-Adresse. Die TARP-Schicht sendet dieses Paket an wenigstens einen bekannten TARP-Router; wobei der TARP-Router nach Empfang und Verifizierung der Nachricht seine LUT mit der neuen IP-Adresse für die angegebene TARP-Adresse aktua lisiert. Daraufhin formatiert der TARP-Router eine ähnliche Nachricht und rundsendet sie an die anderen TARP-Router, so dass sie ihre LUTs aktualisieren können. Da zu erwarten ist, dass die Gesamtzahl der TARP-Router in irgendeinem gegebenen Teilnetz verhältnismäßig klein ist, sollte dieser Prozess des Aktualisierens der LUTs verhältnismäßig schnell sein. Allerdings kann er nicht ebenso gut funktionieren, wenn es eine verhältnismäßig große Anzahl von TARP-Routern und/oder eine verhältnismäßig große Anzahl von Clients gibt; dies hat eine Verfeinerung dieser Architektur zur Schaffung einer Skalierbarkeit motiviert; diese Verfeinerung hat zu einer zweiten Ausführungsform geführt, die im Folgenden diskutiert wird.
Außerdem kann der TARP-Prozess bei Erfassung eines Angriffs einen Teilprozess erzeugen, der die ursprüngliche IP-Adresse aufrechterhält und weiter mit dem Angreifer in Wechselwirkung bleibt. Das Letztere kann eine Gelegenheit bieten, den Angreifer zu verfolgen oder die Verfahren des Angreifers zu untersuchen (was unter Hinzuziehung der Analogie eines kleinen Fischs in einem Aquarium, der "denkt", dass er im Ozean ist, tatsächlich aber unter Beobachtung gefangen ist, "Aquariumhaltung" genannt wird). Eine Historie der Kommunikation zwischen dem Angreifer und der aufgegebenen (im Aquarium gehaltenen) IP-Adresse kann zur Analyse durch den Menschen aufgezeichnet oder gesendet werden oder zur Reaktion auf irgendeine Weise weiter synthetisiert werden.
Wie oben erwähnt wurde, können zu den abgehenden Datenströmen durch TARP-Endgeräte oder -Router Tarn- oder Leerdaten oder Tarn- oder Leerpakete hinzugefügt werden. Diese Tarnpakete können, außer dass sie es zweckmäßig machen, Daten über eine größere Anzahl getrennter Pakete zu verteilen, außerdem die Last in inaktiven Abschnitten des Internet nivellieren helfen, um Verkehrsanalyseanstrengungen vereiteln zu helfen.
Durch jedes TARP-Endgerät 100, 110 oder durch jeden Router 122–127 können auf einer durch einen Algorithmus bestimmten Grundlage Tarnpakete erzeugt werden. Zum Beispiel kann der Algorithmus ein zufälliger sein, der die Erzeugung eines Pakets auf zufälliger Grundlage verlangt, wenn das Endgerät ungenutzt ist. Alternativ kann der Algorithmus auf die Tageszeit oder auf die Erfassung von wenig Verkehr reagieren, um während Zeiten wenigen Verkehrs mehr Tarnpakete zu erzeugen. Es wird angemerkt, dass die Pakete vorzugsweise eher in Gruppen, die so groß sind, dass sie reale Nachrichten simulieren, als einzeln erzeugt werden.
Damit Tarnpakete in normale TARP-Nachrichtenströme eingefügt werden können, kann die Hintergrundschleife außerdem einen Zwischenspeicher haben, der es wahrscheinlicher macht, dass Tarnpakete eingefügt werden, wenn ein Nachrichtenstrom empfangen wird. Das heißt, wenn eine Reihe von Nachrichten empfangen werden, kann die Tarnpaketerzeugungsrate erhöht werden. Alternativ kann der Algorithmus eher die Rate des Fallenlassens von Tarnpaketen erhöhen, als sie weiterzuleiten, falls zusammen mit regulären TARP-Paketen eine große Anzahl von Tarnpaketen empfangen werden. Das Ergebnis dessen, das Tarnpakete auf diese Weise fallengelassen und erzeugt werden, ist, dass die sichtbare Größe ankommender Nachrichten verschieden von der sichtbaren Größe abgehender Nachrichten ist, um die Verkehrsanalyse vereiteln zu helfen. Die Empfangsrate von Tarnpaketen oder anderen Paketen kann für die Prozesse zum Fallenlassen und Erzeugen von Tarnpakten über verfallende Zähler für Tarnpakete und reguläre Pakete angegeben werden. (Ein verfallender Zähler ist einer, der seinen Wert in Reaktion auf die Zeit rücksetzt oder dekrementiert, so dass er einen hohen Wert enthält, wenn er in schneller Folge inkrementiert wird, während er einen kleinen Wert enthält, wenn er entweder langsam oder wenige Male in schneller Folge inkrementiert wird.) Es wird angemerkt, dass das Ziel-TARP-Endgerät 110 Tarnpakete in gleiche Anzahl und Größe wie diese empfangenen TARP-Pakete erzeugen kann, damit es so erscheint, dass es lediglich Pakete leitet und somit nicht das Zielendgerät ist.
Wie in 5 gezeigt ist, können in dem oben beschriebenen Verfahren zum Leiten von TARP-Paketen die folgenden besonderen Schritte verwendet werden.

• S0. Es wird eine Hintergrundschleifenoperation ausgeführt, die einen Algorithmus anwendet, der die Erzeugung von Tarn-IP-Paketen bestimmt. Wenn ein verschlüsseltes TARP-Paket empfangen wird, wird die Schleife unterbrochen.
• S2. Das TARP-Paket kann in irgendeiner Weise sondiert werden, um das Paket zu authentisieren, bevor es unter Verwendung des Verbindungsschlüssels zu entschlüsseln versucht wird. Das heißt, der Router kann dadurch, dass er an einigen Daten, die bei dem IP-Anfangsblock enthalten sind, der an dem verschlüsselten TARP-Paket angebracht ist, das in der Nutznachricht enthalten ist, eine ausgewählte Operation ausführt, bestimmen, dass das Paket ein authentisches TARP-Paket ist. Dies ermöglicht es zu vermeiden, dass eine Entschlüsselung an Paketen ausgeführt wird, die keine authen tischen TARP-Pakete sind.
• S3. Das TARP-Paket wird entschlüsselt, um die Ziel-TARP-Adresse sowie eine Angabe, ob das Paket ein Tarnpaket oder Teil einer realen Nachricht ist, freizulegen.
• S4. Falls das Paket ein Tarnpaket ist, wird der verfallende Tarnzähler inkrementiert.
• S5. Anhand des Tarnungs-Erzeugungs/Fallenlass-Algorithmus und des Werts des verfallenden Tarnzählers kann der Router entscheiden, das Paket zu verwerfen, falls es ein Tarnpaket ist. Falls das empfangene Paket ein Tarnpaket ist und bestimmt wird, dass es verworfen werden sollte (S6), kehrt die Steuerung zu Schritt S0 zurück.
• S7. Der TTL-Parameter des TARP-Anfangsblocks wird dekrementiert und es wird bestimmt, ob der TTL-Parameter größer als null ist.
• S8. Falls der TTL-Parameter größer als null ist, wird aus einer durch den Router unterhaltenen Liste von TARP-Adressen zufällig eine TARP-Adresse gewählt, wobei der Verbindungsschlüssel und die IP-Adresse, die dieser TARP-Adresse entsprechen, zur Verwendung beim Erzeugen eines neuen IP-Pakets, das das TARP-Paket enthält, gespeichert werden.
• S9. Falls der TTL-Parameter null oder kleiner ist, wird die IP-Adresse, die der TARP-Adresse des Ziels entspricht, zur Verwendung beim Erzeugen des neuen IP-Pakets, das das TARP-Paket enthält, gespeichert.
• S10. Das TARP-Paket wird unter Verwendung des gespeicherten Verbindungsschlüssels verschlüsselt.
• S11. Zu dem Paket wird ein IP-Anfangsblock hinzugefügt, der die gespeicherte IP-Adresse enthält, das verschlüsselte TARP-Paket wird mit einem IP-Anfangsblock umhüllt und das fertig gestellte Paket wird zu dem nächsten Sprung oder zum Ziel übertragen.

Anhand von 6 können in dem oben beschriebenen Verfahren zum Erzeugen von TARP-Paketen die folgenden besonderen Schritte genutzt werden.

• S20. Eine Hintergrundschleifenoperation wendet einen Algorithmus an, der die Erzeugung von Tarn-IP-Paketen bestimmt. Wenn ein Datenstrom, der IP-Pakete enthält, zur Sendung empfangen wird, wird die Schleife unterbrochen.
• S21. Die empfangenen IP-Pakete werden zu einer Menge gruppiert, die aus Nachrichten mit einer konstanten IP-Zieladresse besteht. Die Menge wird weiter zerlegt, so dass sie mit einer maximalen Größe eines Verschachtelungsfensters übereinstimmt. Die Menge wird verschlüsselt und zu einer Menge von Nutznachrichten verschachtelt, die dazu bestimmt sind, zu TARP-Paketen zu werden.
• S22. Aus einer Nachschlagetabelle wird die der IP-Adresse entsprechende TARP-Adresse bestimmt und gespeichert, um den TARP-Anfangsblock zu erzeugen. Es wird ein Anfangs-TTL-Zählwert erzeugt und in dem Anfangsblock gespeichert. Der TTL-Zählwert kann zufällig mit Minimal- und Maximalwerten sein oder kann fest oder durch einen anderen Parameter bestimmt sein.
• S23. In den TARP-Anfangsblöcken jedes Pakets werden die Fensterfolgenummern und die Verschachtelungsfolgenummern aufgezeichnet.
• S24. Für jedes TARP-Paket wird zufällig eine TARP-Router-Adresse gewählt und die ihr entsprechende IP-Adresse zur Verwendung in dem Klar-IP-Kopf gespeichert. Der diesem Router entsprechende Verbindungsschlüssel wird identifiziert und zum Verschlüsseln der TARP-Pakete verwendet, die verschachtelte und verschlüsselte Daten und TARP-Anfangsblöcke enthalten.
• S25. Es wird ein Klar-IP-Kopf mit der echten IP-Adresse des Routers des ersten Sprungs erzeugt und zu jedem der verschlüsselten TARP-Pakete und der resultierenden Pakete hinzugefügt.

Wie in 7 gezeigt ist, können in dem oben beschriebenen Verfahren zum Empfangen von TARP-Paketen die folgenden besonderen Schritte genutzt werden.

• S40. Es wird eine Hintergrundschleifenoperation ausgeführt, die einen Algorithmus anwendet, der die Erzeugung von Tarn-IP-Paketen bestimmt. Wenn ein verschlüsseltes TARP-Paket empfangen wird, wird die Schleife unterbrochen.
• S42. Das TARP-Paket kann sondiert werden, um das Paket zu authentisieren, bevor versucht wird, es unter Verwendung des Verbindungsschlüssels zu entschlüsseln.
• S43. Das TARP-Paket wird mit dem geeigneten Verbindungsschlüssel entschlüsselt, um die Ziel-TARP-Adresse und eine Angabe, ob das Paket ein Tarnpaket oder Teil einer realen Nachricht ist, freizulegen.
• S44. Falls das Paket ein Tarnpaket ist, wird der verfallende Tarnzähler inkrementiert.
• S45. Falls das Paket anhand des Verfall-Erzeugungs/Fallenlass-Algorithmus und des Werts des verfallenden Tarnzählers ein Tarnpaket ist, kann der Empfänger wählen, es zu verwerten.
• S46. Die TARP-Pakete werden gecached, bis alle Pakete, die ein Verschachtelungsfenster bilden, empfangen worden sind.
• S47. Wenn alle Pakete eines Verschachtelungsfensters empfangen worden sind, werden die Pakete entschachtelt.
• S48. Daraufhin wird der Paketblock kombinierter Pakete, die das Verschachtelungsfenster definieren, unter Verwendung des Sitzungsschlüssels entschlüsselt.
• S49. Daraufhin wird der entschlüsselte Block unter Verwendung der Fensterfolgedaten geteilt, wobei die IP_T-Anfangsblöcke in normale IP_C-Anfangsblöcke umgesetzt werden. Die Fensterfolgenummern werden in die IP_C-Anfangsblöcke integriert.
• S50. Daraufhin werden die Pakete zu den IP-Schicht-Prozessen hinaufgereicht.

1. SKALIERBARKEITSVERBESSERUNGEN
Das oben beschriebene IP-Agilitätsmerkmal stützt sich auf die Fähigkeit, IP-Adressenänderungen an alle TARP-Router zu senden. Wegen der potentiellen Beschränkungen beim Heraufskalieren dieser Merkmale für ein großes Netz wie etwa das Internet werden die Ausführungsformen, die dieses Merkmal enthalten, als "Boutique"-Ausführungsformen bezeichnet. (Allerdings wären die "Boutique"-Ausführungsformen robust zur Verwendung in kleineren Netzen wie etwa z. B. in kleinen virtuellen privaten Netzen.) Ein Problem bei den Boutique-Ausführungsformen ist, dass der zum Aktualisieren aller Router erforderliche Nachrichtenverkehr dann, wenn häufig IP-Adressenänderungen auftreten sollen, ausreichend schnell eine schwere Belastung des Internet erzeugt, wenn die TARP-Router- und/oder Client-Bevölkerung groß wird. Die zu den Netzen hinzugefügte Bandbreitenbelastung z. B. in ICMP-Paketen, die zum Aktualisieren aller TARP-Router verwendet würden, könnte das Internet für eine große Realisierung, die sich dem Maßstab des Internet annähert, überfluten. Mit anderen Worten, die Skalierbarkeit des Boutique-Systems ist beschränkt.
Es kann ein System konstruiert werden, das einige der Merkmale der obigen Ausführungsformen eintauscht, um die Vorteile der IP-Agilität ohne die zusätzliche Nachrichtenbelastung zu liefern. Dies wird durch IP-Adressen-Sprünge gemäß einem gemeinsam genutzten Algorithmus erreicht, der die IP-Adressen bestimmt, die zwischen Verbindungen verwendet werden, die an Kommunikationssitzungen zwischen Knoten wie etwa TARP-Knoten beteiligt sind. (Es wird angemerkt, dass die IP-Sprungtechnik auf die Boutique-Ausführungsform ebenfalls anwendbar ist.) Das in Bezug auf das Boutique-System diskutierte IP-Agilitätsmerkmal kann so geändert werden, dass es gemäß diesem skalierbaren Regime dezentralisiert und durch den oben beschriebenen gemeinsam genutzten Algorithmus bestimmt ist. Mit diesem neuen IP-Agilitätstyp können weitere Merkmale des Boutique-Systems kombiniert werden.
Die neue Ausführungsform besitzt den Vorteil, dass sie eine IP-Agilität schafft, die durch einen lokalen Algorithmus und durch eine Menge von IP-Adressen, die durch jedes kommunizierende Knotenpaar ausgetauscht werden, bestimmt ist. Diese lokale Bestimmung ist dahingehend sitzungsunabhängig, dass sie die Kommunikation zwischen einem Knotenpaar unabhängig davon, ob die Sitzung oder die Endpunkte zwischen dem direkt kommunizierenden Knotenpaar übertragen werden, bestimmt.
In den skalierbaren Ausführungsformen werden jedem Knoten in dem Netz Blöcke von IP-Adressen zugeordnet. (Diese Skalierbarkeit erhöht sich in Zukunft, wenn Internet-Protokoll-Adressen auf 128-Bit-Felder erhöht werden, was die Anzahl verschieden adressierbarer Knoten wesentlich erhöht.) Somit kann jeder Knoten irgendeine der diesem Knoten zugewiesenen IP-Adressen verwenden, um mit anderen Knoten in dem Netz zu kommunizieren. Tatsächlich kann jedes Paar kommunizierender Knoten mehrere Quell-IP-Adressen und Ziel-IP-Adressen verwenden, um miteinander zu kommunizieren.
Jedes kommunizierende Knotenpaar in einer an irgendeiner Sitzung beteiligten Kette speichert zwei Blöcke von IP-Adressen, die Netzblöcke genannt werden, und einen Algorithmus und einen Keim für die Umrechnung auf Zufallszahlen, um aus jedem Netzblock das nächste Paar von Quell/Ziel-IP-Adressen auszuwählen, die zum Senden der nächsten Nachricht verwendet werden. Mit anderen Worten, der Algorithmus bestimmt die Folgeauswahl von IP-Adressenpaaren, einer Sender- und einer Empfänger-IP-Adresse, aus jedem Netzblock. Die Kombination aus Algorithmus, Keim und Netzblock (IP-Adressenblock) wird ein "Sprungblock" genannt. Ein Router gibt an seine Clients getrennte Sende- und Empfangsprung blöcke aus. Die Sendeadresse und die Empfangsadresse des IP-Anfangsblocks jedes durch den Client gesendeten abgehenden Pakets werden mit den durch den Algorithmus erzeugten Sende- und Empfangs-IP-Adressen gefüllt. Der Algorithmus wird durch einen Zähler "getaktet" (indiziert), so dass der Algorithmus jedes Mal, wenn ein Paar verwendet wird, ein neues Sendepaar für das nächste zu sendende Paket produziert.
Der Empfangssprungblock des Routers ist gleich dem Sendesprungblock des Clients. Der Router verwendet den Empfangssprungblock, um vorauszusagen, was das Sende- und Empfangs-IP-Adressenpaar für das nächste erwartete Paket von diesem Client sein wird. Da Pakete außer der Reihe empfangen werden können, ist es nicht möglich, dass der Router mit Sicherheit voraussagt, welches IP-Adressenpaar im nächsten Folgepaket sein wird. Um dieses Problem anzugehen, erzeugt der Router einen Bereich von Voraussagen, die die Anzahl möglicher Sende/Empfangs-Adressen gesendeter Pakete umfassen, von denen das nächste empfangene Paket vorwärts springen könnte. Falls es eine verschwindend kleine Wahrscheinlichkeit gibt, dass ein gegebenes Paket vor 5 Paketen ankommt, die durch den Client vor dem gegebenen Paket gesendet werden, kann der Router somit eine Reihe von 6 Sende/Empfangs-IP-Adressenpaaren (oder ein "Sprungfenster") erzeugen, um mit dem nächsten empfangenen Paket zu vergleichen. Wenn ein Paket empfangen wird, wird es in dem Sprungfenster als solches gekennzeichnet, so dass ein zweites Paket mit dem gleichen IP-Adressenpaar verworfen wird. Falls ein Paket außer der Reihe in einer vorgegebenen Zeitablaufdauer nicht ankommt, kann es je nach dem für diese Kommunikationssitzung verwendeten Protokoll oder möglicherweise vereinbarungsgemäß für die erneute Übertragung angefordert werden oder einfach aus der Empfangstabelle verworfen werden.
Wenn der Router das Paket des Clients empfängt, vergleicht er die Sende- und Empfangs-IP-Adressen des Pakets mit den nächsten N vorausgesagten Sende- und Empfangs-IP-Adressenpaaren, wobei er das Paket zurückweist, wenn es kein Mitglied dieser Menge ist. Empfangene Pakete, die nicht die vorausgesagten Quell/Ziel-IP-Adressen haben, die in dem Fenster liegen, werden zurückgewiesen, so dass mögliche Hacker auf Hindernisse stoßen. (Bei der Anzahl möglicher Kombinationen ist es selbst für ein recht großes Fenster schwer, zufällig darin zu liegen.) Falls das Paket ein Mitglied dieser Menge ist, nimmt es der Router an und verarbeitet es weiter. Diese als "IHOP" bezeichnete verbindungsgestützte IP- Sprungstrategie ist ein Netzelement, das selbstständig ist und nicht notwendig von Elementen des oben beschriebenen Boutique-Systems begleitet ist. Falls das in Verbindung mit der Boutique-Ausführungsform beschriebene Routing-Agilitätsmerkmal mit dieser verbindungsgestützten IP-Sprungstrategie kombiniert würde, wäre es der nächste Schritt des Routers, den TARP-Anfangsblock zu entschlüsseln, um den Ziel-TARP-Router für das Paket zu bestimmen und um zu bestimmen, welches der nächste Sprung für das Paket sein sollte. Daraufhin würde der TARP-Router das Paket zu einem zufälligen TARP-Router oder zu dem Ziel-TARP-Router weiterleiten, mit dem der Quell-TARP-Router eine verbindungsgestützte IP-Sprungkommunikation hergestellt hat.
8 zeigt, wie ein Client-Computer 801 und ein TARP-Router 811 eine sichere Sitzung herstellen können. Wenn der Client 801 eine IHOP-Sitzung mit dem TARP-Router 811 herstellen möchte, sendet der Client 801 zu dem TARP-Router 811 ein "Sichere-Synchronisation"-Anforderungs-Paket ("SSYN"-Paket) 821. Dieses SYN-Paket 821 enthält das Authentisierungstoken des Clients 801 und kann in einem verschlüsselten Format zu dem Router 811 gesendet werden. Die Quell- und die Ziel-IP-Nummer in dem Paket 821 sind die momentane feste IP-Adresse des Clients 801 und eine "bekannte" feste IP-Adresse für den Router 811. (Aus Sicherheitsgründen kann es erwünscht sein, irgendwelche Pakete von außerhalb des lokalen Netzes, die für die bekannte feste IP-Adresse des Routers bestimmt sind, zurückzuweisen.) Beim Empfang und bei der Validierung des SSYN-Pakets 821 des Clients 801 antwortet der Router 811 damit, dass er zu dem Client 801 eine verschlüsselte "sichere Synchronisationsquittierung" ("SSYN ACK") 822 sendet. Dieses SSYN ACK 822 enthält die Sende- und Empfangssprungblöcke, die der Client 801 verwenden wird, wenn er mit dem TARP-Router 811 kommuniziert. Der Client 801 quittiert das Antwortpaket 822 des TARP-Routers 811 dadurch, dass er ein verschlüsseltes SSYN ACK ACK-Paket 823 erzeugt, das von der festen IP-Adresse des Clients 801 zu der bekannten festen IP-Adresse des TARP-Routers 811 gesendet wird. Gleichzeitig erzeugt der Client 801 ein SSYN ACK ACK-Paket; dieses als das Paket zur Initialisierung einer sicheren Sitzung (SSI-Paket) 824 bezeichnete SSYN ACK-Paket wird mit dem ersten {Sender-, Empfänger-} IP-Paar in der Sendetabelle 921 (9) des Clients wie in dem durch den TARP-Router 811 in dem SSYN ACK-Paket 822 gelieferten Sendesprungblock spezifiziert gesendet. Der TARP-Router 811 antwortet auf das SSI-Paket 824 mit einem SSI ACK-Paket 825, das mit dem ersten {Sender-, Empfänger-} IP-Paar in der Sendetabelle 923 des TARP-Routers gesendet wird. Wenn diese Pakete erfolgreich ausgetauscht worden sind, wird die sichere Kommunikationssitzung aufgebaut, wobei die gesamte weitere sichere Kommunikation zwischen dem Client 801 und dem TARP-Router 811 über diese sichere Sitzung durchgeführt wird, solange die Synchronisation aufrechterhalten wird. Falls die Synchronisation verloren geht, können der Client 801 und der TARP-Router 802 die sichere Sitzung durch die in 8 skizzierte und oben beschriebene Prozedur erneut herstellen.
Während die sichere Sitzung aktiv ist, unterhalten sowohl der Client 901 als auch der TARP-Router 911 (9) ihre jeweiligen Sendetabellen 921, 923 und Empfangstabellen 922, 924, wie sie durch den TARP-Router während der Sitzungssynchronisation 822 geliefert werden. Es ist wichtig, dass die Folge der IP-Paare in der Sendetabelle 921 des Clients gleich der in der Empfangstabelle 924 des TARP-Routers ist; ähnlich muss die Folge der IP-Paare in der Empfangstabelle 922 des Clients gleich der in der Sendetabelle 923 des Routers sein. Dies ist erforderlich, damit die Sitzungssynchronisation aufrechterhalten wird. Der Client 901 braucht während der sicheren Sitzung nur eine Sendetabelle 921 und eine Empfangstabelle 922 zu unterhalten. Unabhängig davon, ob es sich um eine TCP- oder im eine UDP-Sitzung handelt, nutzt jedes durch den Client 901 gesendete Folgepaket das nächste {Sende-, Empfangs-} IP-Adressenpaar in der Sendetabelle. Der TARP-Router 911 erwartet, dass jedes von dem Client 901 ankommende Paket das nächste in seiner Empfangstabelle gezeigte IP-Adressenpaar trägt.
Da Pakete außer der Reihe ankommen können, kann der Router 911 aber einen "Vorgriffs"-Puffer in seiner Empfangstabelle unterhalten, wobei er zuvor empfangene IP-Paare für zukünftige Pakete als ungültig kennzeichnet; jedes zukünftige Paket, das ein IP-Paar enthält, das in dem Vorgriffspuffer ist, aber als zuvor empfangen gekennzeichnet ist, wird verworfen. Die Kommunikation von dem TARP-Router 911 zu dem Client 901 wird auf gleiche Weise aufrechterhalten; insbesondere wählt der Router 911 das nächste IP-Adressenpaar aus seiner Sendetabelle 923 aus, wenn er ein zu dem Client 901 zu sendendes Paket konstruiert, während der Client 901 einen Vorgriffspuffer erwarteter IP-Paare an Paketen, die er empfängt, unterhält. Jeder TARP-Router unterhält für jeden Client, der momentan mit oder über diesen TARP-Router an einer sicheren Sitzung beteiligt ist, getrennte Paare von Sende- und Empfangstabellen.
Während Clients ihre Sprungblöcke von dem ersten Server empfangen, der sie mit dem Internet verbindet, tauschen Router Sprungblöcke aus. Wenn ein Router ein verbindungsgestütztes IP-Sprung-Kommunikationsregime mit einem anderen herstellt, tauscht jeder Router des Paars seinen Sendesprungblock aus. Der Sendesprungblock jedes Routers wird zu dem Empfangssprungblock des anderen Routers. Die Kommunikation zwischen Routern wird so bestimmt, wie es durch das Beispiel eines Clients beschrieben wurde, der ein Paket zu dem ersten Router sendet.
Während die obige Strategie in dem IP-Milieu sehr gut funktioniert, sind viele lokale Netze, die mit dem Internet verbunden sind, Ethernet-Systeme. Im Ethernet müssen die IP-Adressen der Zielvorrichtungen unter Verwendung bekannter Prozesse ("Adressenauflösungsprotokoll" und "Umkehradressenauflösungsprotokoll") in Hardware-Adressen übersetzt werden und umgekehrt. Wenn die übertragungsgestützte IP-Sprungstrategie verwendet würde, würde der Korrelationsprozess aber heftig und belastend werden. In einem Ethernet-Netz kann eine Alternative zu der verbindungsgestützten IP-Sprungstrategie genutzt werden. Die Lösung ist sicherzustellen, dass der Knoten, der das Internet mit dem Ethernet verbindet (der der Grenzknoten genannt werden soll), zur Kommunikation mit Knoten außerhalb des Ethernet-LAN das verbindungsgestützte IP-Sprung-Kommunikationsregime verwendet. In dem Ethernet-LAN hat jeder TARP-Knoten eine einzige IP-Adresse, die auf herkömmliche Weise adressiert wird. Anstatt die {Sender-, Empfänger-} IP-Adressenpaare zu vergleichen, um ein Paket zu authentisieren, verwendet der Intra-LAN-TARP-Knoten eines der IP-Anfangsblock-Erweiterungsfelder, um dies zu tun. Somit verwendet der Grenzknoten einen Algorithmus, der durch den Intra-LAN-TARP-Knoten gemeinsam genutzt wird, um ein Symbol zu erzeugen, das in dem freien Feld in dem IP-Anfangsblock gespeichert wird, wobei der Intra-LAN-TARP-Knoten anhand seiner Voraussage des nächsten erwarteten Pakets, das von dieser besonderen Quell-IP-Adresse empfangen werden soll, einen Bereich von Symbolen erzeugt. Falls das Paket nicht in der Menge vorausgesagter Symbole (z. B. Zahlenwerte) liegt, wird das Paket zurückgewiesen, während es angenommen wird, wenn es dies tut. Die Kommunikation von dem Intra-LAN-TARP-Knoten zu dem Grenzknoten wird auf die gleiche Weise ausgeführt, obgleich der Algorithmus aus Sicherheitsgründen notwendig anders ist. Somit erzeugt jeder der kommunizierenden Knoten auf ähnliche Weise wie in 9 Sende- und Empfangstabellen; die Sendetabelle der Intra-LAN-TARP-Knoten ist gleich der Empfangstabelle des Grenzknotens und die Empfangstabelle des Intra- LAN-TARP-Knotens ist gleich der Sendetabelle des Grenzknotens.
Der für den IP-Adressensprung verwendete Algorithmus kann irgendein gewünschter Algorithmus sein. Zum Beispiel kann der Algorithmus ein gegebener Pseudo-Zufallszahlengenerator sein, der Zahlen des Bereichs erzeugt, der die zulässigen IP-Adressen mit einem gegebenen Keim abdeckt. Alternativ können die Sitzungsteilnehmer einen bestimmten Algorithmustyp annehmen und einfach einen Parameter für die Anwendung des Algorithmus spezifizieren. Zum Beispiel könnte der angenommene Algorithmus ein besonderer Pseudo-Zufallszahlengenerator sein, wobei die Sitzungsteilnehmer einfach Keimwerte austauschen könnten.
Es wird angemerkt, dass es keine dauerhafte physikalische Unterscheidung zwischen den Ursprungs- und den Zielendgerätknoten gibt. Jede Vorrichtung an jedem Endpunkt kann eine Synchronisation des Paars beginnen. Außerdem wird angemerkt, dass die Authentisierungs/Synchronisations-Anforderung (und -Quittierung) und der Sprungblockaustausch alle durch eine einzige Nachricht bedient werden können, so dass keine getrennten Nachrichtenaustausche erforderlich zu sein brauchen.
Als eine weitere Erweiterung an der angegebenen Architektur können von einem Client mehrere physikalische Wege verwendet werden, um eine Verbindungsredundanz zu schaffen und Versuche der Dienstverweigerung und der Verkehrsüberwachung zu vereiteln. Wie in 10 gezeigt ist, kann z. B. der Client 1001 drei gleichzeitige Sitzungen mit jedem der drei durch verschiedene ISPs 1011, 1012, 1013 bereitgestellten TARP-Router herstellen. Als ein Beispiel kann der Client 1001 drei verschiedene Telephonleitungen 1021, 1022, 1023 zum Verbinden mit den ISPs oder zwei Telephonleitungen und ein Kabelmodem usw. verwenden. In diesem Schema werden gesendete Pakete auf zufällige Weise unter den verschiedenen physikalischen Wegen gesendet. Diese Architektur schafft einen hohen Grad an Kommunikationsredundanz bei verbesserter Unempfindlichkeit gegenüber Dienstverweigerungsangriffen und Verkehrsüberwachung.
2. WEITERE ERWEITERUNGEN
Das Folgende beschreibt verschiedene Erweiterungen an den oben beschriebenen Techniken, Systemen und Verfahren. Wie oben beschrieben wurde, kann die Sicherheit der zwischen Computern in einem Computernetz (wie etwa dem Internet, einem Ethernet oder anderen) stattfindenden Kommunikation unter Verwendung sichtbar zufälliger Quell- und Ziel-Internet-Protokoll-Adressen (Quell- und Ziel-IP-Adressen) für über das Netz übertragene Datenpakete verbessert werden. Dieses Merkmal verhindert, dass Abhörer bestimmen, welche Computer in dem Netz miteinander kommunizieren, während es ermöglicht, dass die zwei kommunizierenden Computer leicht erkennen, ob ein gegebenes empfangenes Datenpaket zulässig ist oder nicht. In einer Ausführungsform der oben beschriebenen Systeme wird ein IP-Anfangsblock-Erweiterungsfeld verwendet, um ankommende Pakete in einem Ethernet zu authentisieren.
Verschiedene Erweiterungen an den hier zuvor beschriebenen Techniken enthalten: (1) die Verwendung gesprungener Hardware- oder "MAC"-Adressen in einem Rundsendenetz; (2) eine Selbstsynchronisationstechnik, die ermöglicht, dass ein Computer automatisch die Synchronisation mit einem Sender wiedererlangt; (3) Synchronisationsalgorithmen, die ermöglichen, dass sendende und empfangende Computer die Synchronisation im Fall verlorener Pakete oder anderer Ereignisse schnell wiederherstellen; und (4) einen schnellen Paketzurückweisungsmechanismus zum Zurückweisen ungültiger Pakete.
Irgendeine oder alle dieser Erweiterungen können auf irgendeine von verschiedenen Arten mit den oben beschriebenen Merkmalen kombiniert werden.
A. Hardware-Adressensprung
Internet-Protokoll-gestützte Kommunikationstechniken in einem LAN – oder über irgendein dediziertes physikalisches Medium – betten die IP-Pakete typisch in Pakete niedrigerer Ebene ein, die häufig als "Rahmen" bezeichnet werden. Wie in 11 gezeigt ist, umfasst z. B. ein erster Ethernet-Rahmen 1150 einen Rahmenanfangsblock 1101 und zwei eingebettete IP-Pakete IP1 und IP2, während ein zweiter Ethernet-Rahmen 1160 einen anderen Rahmenanfangsblock 1104 und ein einzelnes IP-Paket IP3 umfasst. Allgemein enthält jeder Rahmenanfangsblock eine Quell-Hardware-Adresse 1101A und eine Ziel-Hardware-Adresse 1101B; an dere gut bekannte Felder in Rahmenanfangsblöcken sind zur Klarheit in 11 weggelassen. Zwei Hardware-Knoten, die über einen physikalischen Kommunikationskanal kommunizieren, fügen geeignete Quell- und Ziel-Hardware-Adressen ein, die angeben, welche Knoten in dem Kanal oder Netz den Rahmen empfangen sollten.
Es kann möglich sein, dass ein schändlicher Lauscher Informationen über den Inhalt eines Rahmens und/oder über seine Kommunikationsteilnehmer eher (oder zusätzlich) dadurch erlangt, dass er Rahmen in einem lokalen Netz untersucht, als die IP-Rahmen selbst zu untersuchen. Dies trifft insbesondere zu in Rundsendemedien wie etwa dem Ethernet, in dem es notwendig ist, in den Rahmenanfangsblock die Hardware-Adresse der Maschine, die den Rahmen erzeugt hat, und die Hardware-Adresse der Maschine, zu der der Rahmen gesendet wird, einzufügen. Potentiell können alle Knoten in dem Netz alle über das Netz übertragenen Pakete "sehen". Insbesondere in Fällen, in denen die Kommunikationsteilnehmer nicht wünschen, dass irgendein Dritter identifizieren kann, wer an dem Informationsaustausch beteiligt ist, kann dies ein Problem für die sichere Kommunikation sein. Eine Möglichkeit, dieses Problem anzugehen, ist, das Adressensprungschema nach unten in die Hardware-Schicht zu schieben. In Übereinstimmung mit verschiedenen Ausführungsformen der Erfindung werden Hardware-Adressen auf ähnliche Weise "gesprungen", wie es zur Änderung von IP-Adressen verwendet wird, so dass ein Lauscher weder bestimmen kann, welcher Hardware-Knoten eine besondere Nachricht erzeugt hat, noch, welcher Knoten der beabsichtigte Empfänger ist.
12A zeigt ein System, in dem Medienzugangskontroll-Hardware-Adressen ("MAC"-Hardware-Adressen) "gesprungen werden", um die Sicherheit über ein Netz wie etwa ein Internet zu erhöhen. Obgleich die Beschreibung auf den beispielhaften Fall einer Ethernet-Umgebung Bezug nimmt, sind die erfinderischen Prinzipien gleichfalls auf andere Typen von Kommunikationsmedien anwendbar. Im Ethernet-Fall wird die MAC-Adresse des Senders und des Empfängers in den Ethernet-Rahmen eingefügt und kann durch jeden in dem LAN, der in dem Rundesendebereich für diesen Rahmen ist, beobachtet werden. Für die sichere Kommunikation ist es erwünscht, Rahmen mit MAC-Adressen zu erzeugen, die nicht irgendeinem spezifischen Sender oder Empfänger zugeschrieben werden können.
Wie in 12A gezeigt ist, kommunizieren zwei Computerknoten 1201 und 1202 über einen Kommunikationskanal wie etwa ein Ethernet. Jeder Knoten führt eines oder mehrere Anwendungsprogramme 1203 und 1218 aus, die dadurch kommunizieren, dass sie Pakete über Kommunikations-Software 1204 bzw. 1217 übertragen. Beispiele von Anwendungsprogrammen umfassen Videokonferenzen, E-Mail, Textverarbeitungsprogramme, Telephonie und dergleichen. Die Kommunikations-Software 1204 und 1217 kann z. B. eine OSI-Schichtarchitektur oder einen OSI"Stapel" umfassen, die/der verschiedene Dienste, die auf verschiedenen Noiveaus der Funktionalität bereitgestellt werden, standardisiert.
Die untersten Ebenen der Kommunikations-Software 1204 und 1217 kommunizieren mit Hardware-Komponenten 1206 bzw. 1214, von denen jede eines oder mehrere Register 1207 und 1215 enthalten kann, die ermöglichen, dass die Hardware in Übereinstimmung mit verschiedenen Kommunikationsprotokollen neu konfiguriert oder gesteuert wird. Die Hardware-Komponenten (z. B. eine Ethernet-Netzschnittstellenkarte) kommunizieren über das Kommunikationsmedium miteinander. Jeder Hardware-Komponente ist typisch im Voraus eine feste Hardware-Adresse oder MAC-Nummer zugewiesen worden, die die Hardware-Komponente gegenüber anderen Knoten in dem Netz identifiziert. Einer oder mehrere Schnittstellentreiber steuern den Betrieb jeder Karte und können z. B. so konfiguriert werden, dass sie Pakete von bestimmten Hardware-Adressen annehmen oder zurückweisen. Wie im Folgenden ausführlicher beschrieben wird, schaffen verschiedene Ausführungsformen der erfinderischen Prinzipien unter Verwendung eines oder mehrerer Algorithmen und eines oder mehrerer sich bewegender Fenster, die einen Bereich gültiger Adressen verfolgen, um empfangene Pakete zu validieren, ein "Springen" verschiedener Adressen. Pakete, die gemäß einem oder mehreren der erfinderischen Prinzipien übertragen werden, werden, um sie von normalen Datenpaketen zu unterscheiden, die unter Verwendung normaler, maschinenkorrelierter Adressen klar übertragen werden, allgemein als "sichere" Pakete oder "sichere Nachrichten" bezeichnet.
Ein unkompliziertes Verfahren des Erzeugens nicht zuzuschreibender MAC-Adressen ist eine Erweiterung des IP-Sprungschemas. In diesem Szenarium tauschen zwei Maschinen in demselben LAN, die auf sichere Weise kommunizieren möchten, Zufallszahlengeneratoren und Keime aus und erzeugen Folgen von Quasi-Zufalls-MAC-Adressen für den synchronisierten Sprung. Die Realisierungs- und Synchronisationsprobleme sind dann ähnlich denen des IP-Sprungs.
Allerdings läuft dieser Zugang Gefahr, MAC-Adressen zu verwenden, die momentan in dem LAN aktiv sind – was wiederum die Kommunikation für diese Maschinen unterbrechen könnte. Da eine Ethernet-MAC-Adresse derzeit eine Länge von 48 Bits hat, ist das Risiko, zufällig eine aktive MAC-Adresse zu missbrauchen, tatsächlich recht klein. Falls diese Zahl allerdings mit einer großen Anzahl von Knoten (wie sie in einem umfangreichen LAN zu finden sind), mit einer großen Anzahl von Rahmen (wie es bei Paket-Sprache oder -Streaming-Video der Fall sein könnte) und mit einer großen Anzahl gleichzeitiger virtueller privater Netze (VPNs) multipliziert wird, kann das Risiko, dass die MAC-Adresse einer nicht sicheren Maschine in einem Rahmen mit gesprungener Adresse verwendet wird, tatsächlich nicht trivial werden. Kurz gesagt, wird irgendein Schema, das selbst einem kleinen Risiko unterliegt, die Kommunikation für andere Maschinen in dem LAN zu unterbrechen, zwangsläufig auf Widerstand von den potentiellen Systemadministratoren stoßen. Dennoch ist es technisch möglich und kann in einem LAN, in dem es eine kleine Anzahl von Maschinen gibt, oder wenn alle Maschinen in dem LAN an der MAC-Sprung-Kommunikation beteiligt sind ohne Risiko realisiert werden.
Insbesondere dann, wenn es mehrere Sitzungen oder mehrere Knoten gibt, die an der Kommunikation beteiligt sind, kann der synchronisierte MAC-Adressensprung einen Zusatzaufwand während der Sitzungsherstellung auf sich ziehen. Ein einfacheres Verfahren, MAC-Adressen auf Zufallszahlen umzurechnen, ist zu ermöglichen, dass jeder Knoten jeden einfallenden Rahmen in dem Netz empfängt und verarbeitet. Jeder Netzschnittstellentreiber prüft typisch die Ziel-MAC-Adresse in dem Anfangsblock jedes einfallenden Rahmens, um zu sehen, ob sie mit der MAC-Adresse der Maschine übereinstimmt; falls es keine Anpassung gibt, wird der Rahmen verworfen. Allerdings können diese Prüfungen in einer Ausführungsform gesperrt werden, wobei jedes einfallende Paket zur Verarbeitung an dem TARP-Stapel übergeben wird. Da jeder einfallende Rahmen verarbeitet wird, wird dies als "Promiscuous-Betriebsart" bezeichnet. Die Promiscuous-Betriebsart ermöglicht, dass der Sender vollständig zufällige, unsynchronisierte MAC-Adressen verwendet, da sichergestellt ist, dass die Zielmaschine den Rahmen verarbeitet. Die Entscheidung, ob das Paket wirklich für diese Maschine bestimmt war, wird durch den TARP-Stapel behandelt, der die Quell- und Ziel-IP-Adresse in seinen IP-Synchronisationstabellen auf eine Anpassung prüft. Falls keine Anpassung gefunden wird, wird das Paket verworfen; falls es eine Anpassung gibt, wird das Paket ausgepackt, der innere Anfangsblock bewertet und dann, wenn der innere Anfangsblock angibt, dass das Paket für diese Maschine bestimmt ist, das Paket zu dem IP-Stapel weitergeleitet – während es andernfalls verworfen wird.
Ein Nachteil eines rein zufälligen MAC-Adressensprungs ist seine Auswirkung auf den Verarbeitungsorganisationsaufwand; d. h., da jeder einfallende Rahmen verarbeitet werden muss, wird die CPU viel häufiger in Anspruch genommen, als wenn der Netzschnittstellentreiber die Pakete einseitig entscheidet und zurückweist. Ein Kompromisszugang ist es, unabhängig von dem tatsächlichen Adressaten, für den die Nachricht bestimmt ist, entweder eine einzelne feste MAC-Adresse oder eine kleine Anzahl von MAC-Adressen (z. B. eine für jedes virtuelle private Netz in dem Ethernet) auszuwählen, um sie für die Kommunikation mit gesprungener MAC zu verwenden. In dieser Betriebsart kann der Netzschnittstellentreiber jeden einfallenden Rahmen gegenüber einer vorher festgesetzten MAC-Adresse (oder wenigen vorher festgesetzten MAC-Adressen) prüfen und dadurch die CPU von der Aufgabe der Paketentscheidung in der Bitübertragungsschicht befreien. Dieses Schema verrät keine Nutzinformation an einen Eindringling in dem LAN; insbesondere kann jedes sichere Paket bereits durch einen eindeutigen Pakettyp in dem äußeren Anfangsblock identifiziert werden. Allerdings ist die Zuordnung zwischen einer spezifischen Maschine und einer spezifischen MAC-Adresse effektiv verletzt, da alle an der sicheren Kommunikation beteiligten Maschinen entweder dieselbe MAC-Adresse verwenden oder sie aus einem kleinen Pool vorgegebener MAC-Adressen auswählen.
Da der Netzschnittstellentreiber nicht immer einseitig zwischen sicheren Paketen, die für diese Maschine bestimmt sind, und sicheren Paketen von anderen VPNs unterscheiden kann, wird die CPU in diesem Schema häufiger in Anspruch genommen, als das in der nicht sicheren Kommunikation (oder in einem synchronisierten MAC-Adressensprung) der Fall wäre. Allerdings wird der nicht sichere Verkehr an der Netzschnittstelle leicht beseitigt, wodurch die Menge der von der CPU geforderten Verarbeitung verringert wird. Es gibt Randbedingungen, wo diese Aussagen nicht zutreffen, wobei natürlich z. B. dann, wenn der gesamte Verkehr in dem LAN sicherer Verkehr wäre, die CPU in demselben Grad in Anspruch genommen würde wie im Fall des rein zufälligen Adressensprungs; alternativ kann die Netzschnittstelle ideal sichere Rahmen, die für die lokale Maschine bestimmt sind, von jenen, die andere VPNs bilden, unterscheiden, falls jedes VPN in dem LAN eine andere MAC-Adresse verwendet. Dies sind technische Ab wägungen, die am besten dadurch behandelt werden könnten, dass für den Anwender Administrationsoptionen bereitgestellt werden, wenn er die Software installiert und/oder die VPNs festsetzt.
Allerdings bleibt selbst in diesem Szenarium weiter ein kleines Risiko, dass MAC-Adressen ausgewählt werden, die von einem oder von mehrere Knoten in dem LAN verwendet werden. Eine Lösung für dieses Problem ist, formal eine Adresse oder einen Bereich von Adressen zur Verwendung in der Kommunikation mit gesprungener MAC zuzuweisen. Dies erfolgt typisch über eine Registrierungsbehörde zugewiesener Nummern; z. B. werden im Fall des Ethernet Händlern durch das Institute of Electrical and Electronics Engineers (IEEE) MAC-Adressenbereiche zugewiesen. Ein formal zugewiesener Bereich von Adressen würde sicherstellen, dass sichere Rahmen mit irgendwelchen richtig konfigurierten und richtig funktionierenden Maschinen im LAN nicht in Widerspruch stehen.
Anhand der 12A und 12B werden nun die vielen Kombinationen und Merkmale beschrieben, die den erfinderischen Prinzipien folgen. Wie oben erläutert wurde, ist angenommen, dass zwei Computerknoten 1201 und 1202 über ein Netz oder Kommunikationsmedium wie etwa ein Ethernet kommunizieren. Ein Kommunikationsprotokoll in jedem Knoten (1204 bzw. 1217) enthält ein geändertes Element 1205 und 1216, das bestimmte Funktionen ausführt, die von den Standardkommunikationsprotokollen abweichen. Insbesondere realisiert der Computerknoten 1201 einen ersten "Sprung"-Algorithmus 1208X, der sichtbar zufällige Quell- und Ziel-IP-Adressen (und in einer Ausführungsform sichtbar zufällige IP-Anfangsblock-Diskriminatorfelder) auswählt, um jedes Paket zu dem anderen Computerknoten zu übertragen. Zum Beispiel unterhält der Knoten 1201 eine Sendetabelle 1208, die Tripel aus Quell- (S), Ziel- (D) und Diskriminatorfeldern (DS) enthält, die in abgehende IP-Paket-Anfangsblöcke eingefügt werden. Die Tabelle wird unter Verwendung eines geeigneten Algorithmus (z. B. eines Zufallszahlengenerators, der mit einem geeigneten Keim versehen wird), der dem Empfängerknoten 1202 bekannt ist, erzeugt. Während jedes neue IP-Paket gebildet wird, wird der nächste Folgeeintrag aus der Sendetabelle 1208 des Senders verwendet, um das IP-Quell-, das IP-Ziel- und das IP-Anfangsblockerweiterungsfeld (z. B. Diskriminatorfeld) zu bevölkern. Es ist klar, dass die Sendetabelle nicht im Voraus erzeugt zu werden braucht, sondern stattdessen im Flug durch Ausführen des Algorithmus, wenn jedes Paket gebildet wird, erzeugt werden könnte.
Bei dem empfangenden Knoten 1202 wird der gleiche IP-Sprungalgorithmus 1222X unterhalten und verwendet, um eine Empfangstabelle 1222 zu erzeugen, in der gültige Tripel aus Quell-IP-Adresse, Ziel-IP-Adresse und Diskriminatorfeld aufgeführt sind. Dies ist mittels der ersten fünf Einträge der Sendetabelle 1208 gezeigt, die an die zweiten fünf Einträge der Empfangstabelle 1222 angepasst sind. (Wegen verlorener Pakete, falsch geordneter Pakete oder Übertragungsverzögerungen können die Tabellen zu einem besonderen Zeitpunkt leicht versetzt sein.) Außerdem unterhält der Knoten 1202 ein Empfangsfenster W3, das eine Liste gültiger IP-Quell-, IP-Ziel- und Diskriminatorfelder repräsentiert, die angenommen werden, wenn sie als Teil eines ankommenden IP-Pakets empfangen werden. Während Pakete empfangen werden, verschiebt sich das Fenster W3 in der Liste gültiger Einträge nach unten, so dass sich die möglichen gültigen Einträge mit der Zeit ändern. Zwei Pakete, die außer der Reihe ankommen, aber dennoch an Einträge im Fenster W3 angepasst sind, werden angenommen; jene, die außerhalb des Fensters W3 liegen, werden als ungültig zurückgewiesen. Die Länge des Fensters W3 kann bei Bedarf angepasst werden, um Netzverzögerungen oder anderen Faktoren zu widerspiegeln.
Der Knoten 1202 unterhält unter Verwendung eines potentiell anderen Sprungalgorithmus 1221X eine ähnliche Sendetabelle 1221 zum Erzeugen von IP-Paketen und Rahmen, die für den Knoten 1201 bestimmt sind, und der Knoten 1201 unterhält unter Verwendung desselben Algorithmus 1209X eine angepasste Empfangstabelle 1209. Während der Knoten 1202 unter Verwendung sichtbar zufälliger IP-Quell-, IP-Ziel- und/oder Diskriminatorfelder Pakete zu dem Knoten 1201 sendet, vergleicht der Knoten 1201 die ankommenden Paketwerte mit jenen, die in dem in seiner Empfangstabelle unterhaltene Fenster W1 liegen. Tatsächlich ist die Sendetabelle 1208 des Knotens 1201 mit der Empfangstabelle 1222 des Empfangsknotens 1202 synchronisiert (d. h., die Einträge werden auf die gleiche Weise ausgewählt). Ähnlich ist die Sendetabelle 1221 des Knotens 1202 mit der Empfangstabelle 1209 des Knotens 1201 synchronisiert. Obgleich in 12A ein üblicher Algorithmus für die Quell-, Ziel- und Diskriminatorfelder gezeigt ist (der z. B. für jedes der drei Felder einen anderen Keim verwendet), ist klar, dass zum Festsetzen von Werten für jedes dieser Felder tatsächlich ein völlig anderer Algorithmus verwendet werden könnte. Außerdem ist klar, dass eher eines oder zwei der Felder als wie veranschaulicht alle drei "gesprungen" werden können.
In Übereinstimmung mit einem weiteren Aspekt der Erfindung werden anstelle der IP-Adressen oder zusätzlich zu den IP-Adressen und/oder anstelle des Diskriminatorfelds oder zusätzlich zu dem Diskriminatorfeld Hardware- oder "MAC"-Adressen gesprungen, um die Sicherheit in einem lokalen Netz oder Rundsendenetz zu verbessern. Zu diesem Zweck unterhält der Knoten 1201 ferner eine Sendetabelle 1210, die einen Sendealgorithmus 1210X verwendet, um Quell- und Ziel-Hardware-Adressen zu erzeugen, die in Rahmenanfangsblöcke (z. B. die Felder 1101A und 1101B in 11) eingefügt werden, und die mit einer entsprechenden Empfangstabelle 1224 beim Knoten 1202 synchronisiert ist. Ähnlich unterhält der Knoten 1202 eine andere Sendetabelle 1223, die Quell- und Ziel-Hardware-Adressen enthält und mit einer entsprechenden Empfangstabelle 1211 beim Knoten 1201 synchronisiert ist. Auf diese Weise scheinen abgehende Hardware-Rahmen von vollständig zufälligen Knoten in dem Netz auszugehen und zu ihnen zu gehen, obgleich jeder Adressat bestimmen kann, ob ein gegebenes Paket für ihn bestimmt ist oder nicht. Es ist klar, dass das Hardware-Sprungmerkmal in einer anderen Schicht in dem Kommunikationsprotokoll als das IP-Sprungmerkmal (z. B. in einem Kartentreiber oder in einer Hardware-Karte selbst, um die Leistung zu verbessern) realisiert sein kann.
12B zeigt drei verschiedene Ausführungsformen oder Betriebsarten, die unter Verwendung der oben erwähnten Prinzipien genutzt werden können. In einer ersten Betriebsart, die als "Promiscuous"-Betriebsart bezeichnet wird, wird von allen Knoten in dem Netz eine gemeinsame Hardware-Adresse (z. B. eine feste Adresse für die Quelle und eine weitere für das Ziel) verwendet oder andernfalls eine vollständig zufällige Hardware-Adresse verwendet, so dass ein besonderes Paket nicht irgendeinem Knoten zugeschrieben werden kann. Jeder Knoten muss anfangs alle Pakete, die die gemeinsame (oder zufällige) Hardware-Adresse enthalten, annehmen und die IP-Adressen oder das Diskriminatorfeld untersuchen, um zu bestimmen, ob das Paket für diesen Knoten bestimmt ist. Diesbezüglich können in Übereinstimmung mit einem wie oben beschriebenen Algorithmus entweder die IP-Adressen oder das Diskriminatorfeld oder beide geändert werden. Wie zuvor erläutert wurde, kann dies den Organisationsaufwand jedes Knotens erhöhen, da zusätzliche Verarbeitung beteiligt ist, um zu bestimmen, ob ein gegebenes Paket gültige Quell- und Ziel-Hardware-Adressen besitzt.
In einer zweiten Betriebsart, die als "Promiscuous-pro-VPN"-Betriebsart bezeichnet wird, werden eine kleine Menge fester Hardware-Adressen verwendet, wobei für alle Knoten, die über ein virtuelles privates Netz kommunizieren, eine feste Quell/Ziel-Hardware-Adresse verwendet wird. Falls es z. B. in einem Ethernet sechs Knoten gibt und das Netz derart in zwei private virtuelle Netze aufgeteilt werden soll, dass die Knoten in einem VPN nur mit den anderen zwei Knoten in ihrem eigenen VPN kommunizieren können, können zwei Mengen von Hardware-Adressen verwendet werden: eine Menge für das erste VPN und eine zweite Menge für das zweite VPN. Da nur Pakete geprüft zu werden brauchen, die von dem bestimmten VPN ankommen, verringert dies die Menge des an der Prüfung auf gültige Rahmen beteiligten an Organisationsaufwands. Die IP-Adressen und eines oder mehrere Diskriminatorfelder können für die sichere Kommunikation in dem VPN wie zuvor weiter gesprungen werden. Natürlich gefährdet diese Lösung die Anonymität der VPNs (d. h., ein Außenstehender kann leicht sagen, welcher Verkehr zu welchem VPN gehört, auch wenn er ihn nicht mit einer spezifischen Maschine/Person korrelieren kann). Außerdem erfordert es die Verwendung eines Diskriminatorfelds, um die Anfälligkeit für bestimmte Arten von DoS-Angriffen zu mildern. (Zum Beispiel könnte ohne das Diskriminatorfeld ein Angreifer in dem LAN Rahmen fluten, die die MAC-Adressen enthalten, die von dem VPN verwendet werden; das Zurückweisen dieser Rahmen könnte zu übermäßigem Verarbeitungsorganisationsaufwand führen. Das Diskriminatorfeld würde ein Mittel mit niedrigem Organisationsaufwand bereitstellen, um die falschen Pakete zurückzuweisen.)
In einer dritten Betriebsart, die als "Hardware-Sprung"-Betriebsart bezeichnet wird, werden die Hardware-Adressen wie in 12A veranschaulicht in der Weise geändert, dass die Hardware-Quell- und Hardware-Ziel-Adressen ständig geändert werden, um eine nicht zuzuschreibende Adressierung zu schaffen. Natürlich sind an diesen Ausführungsformen Änderungen möglich, wobei die Erfindung in keiner Beziehung auf diese veranschaulichenden Beispiele beschränkt sein soll.
B. Erweiterung des Adressenraums
Der Adressensprung sichert Sicherheit und Geheimhaltung. Allerdings ist das Niveau des Schutzes durch die Anzahl der Adressen in den Blöcken, die gesprungen werden, beschränkt. Ein Sprungblock bezeichnet eines oder mehrere Felder, die auf paketweiser Grundlage moduliert werden, um ein VPN bereitzustellen. Falls z. B. zwei Knoten mit IP-Adressensprung unter Verwendung von Sprungblöcken mit jeweils 4 Adressen (2 Bits) kommunizieren, gibt es 16 mögliche Adres senpaarkombinationen. Ein Fenster der Größe 16 führt dazu, dass die meisten Adressenpaare die meiste Zeit als gültig angenommen werden. Diese Beschränkung kann unter Verwendung eines Diskriminatorfelds zusätzlich zu den gesprungenen Adressenfeldern oder anstelle der gesprungenen Adressenfelder überwunden werden. Das Diskriminatorfeld wird in genau der gleichen Weise wie die Adressenfelder gesprungen und dazu verwendet zu bestimmen, ob ein Paket durch einen Empfänger verarbeitet werden soll.
Es wird angenommen, dass zwei Clients, die jeweils Vier-Bit-Sprungblöcke verwenden, das gleiche Schutzniveau wünschen, das Clients gewährt wird, die über IP-Sprung zwischen zwei A-Blöcken (24 Adressenbits für den Sprung auswählbar) kommunizieren. Dieses Schutzniveau bietet ein Diskriminatorfeld von 20 Bits, das in Verbindung mit den 4 Adressenbits verwendet wird, die für den Sprung in dem IP-Adressenfeld auswählbar sind. Ein 24-Bit-Diskriminatorfeld bietet ein ähnliches Schutzniveau, falls die Adressenfelder nicht gesprungen oder ignoriert werden. Die Verwendung eines Diskriminatorfelds bietet die folgenden Vorteile: (1) Es kann ein beliebig hohes Schutzniveau geboten werden und (2) der Adressensprung ist unnötig, um den Schutz zu bieten. Dies kann wichtig sein in Umgebungen, in denen der Adressensprung Routing-Probleme verursachen könnte.
C. Synchronisationstechniken
Allgemein wird angenommen, dass dann, wenn ein sendender Knoten und ein empfangender Knoten Algorithmen und Keime (oder ähnliche Informationen, die ausreichen, um eine Quasi-Zufalls-Quell-Tabelle und Quasi-Zufalls-Ziel-Tabelle zu erzeugen) ausgetauscht haben, die nachfolgende Kommunikation zwischen den zwei Knoten problemlos vonstatten geht. Realistisch können aber zwei Knoten wegen Netzverzögerungen oder Ausfall oder anderen Problemen die Synchronisation verlieren. Folglich ist es erwünscht, eine Einrichtung bereitzustellen, um zwischen Knoten in einem Netz, die die Synchronisation verloren haben, die Synchronisation wiederherzustellen.
Eine mögliche Technik ist es zu fordern, dass jeder Knoten beim erfolgreichen Empfang jedes Pakets eine Quittierung liefert, wobei das unquittierte Paket erneut gesendet wird, wenn in einer bestimmten Zeitdauer keine Quittierung empfangen wird. Allerdings treibt dieser Zugang den Organisationsaufwand in die Höhe und kann in Umgebungen mit hohem Durchsatz wie etwa z. B. Streaming-Video oder -Audio unerschwinglich sein.
Ein anderer Zugang ist es, eine automatische Synchronisationstechnik zu verwenden, die hier als "Selbstsynchronisation" bezeichnet wird. In diesem Zugang sind die Synchronisationsinformationen in jedes Paket eingebettet, wodurch ermöglicht wird, dass sich der Empfänger beim Empfang eines einzelnen Pakets selbst erneut synchronisiert, wenn er bestimmt, dass er die Synchronisation mit dem Sender verloren hat. (Wenn die Kommunikation bereits im Gang ist und der Empfänger bestimmt, dass er noch mit dem Sender synchronisiert ist, besteht keine Notwendigkeit zum erneuten Synchronisieren.) Ein Empfänger kann bestimmen, dass er asynchron war, indem er z. B. einen "Totmann"-Zeitgeber verwendet, der nach einer bestimmten Zeitdauer abläuft, wobei der Zeitgeber mit jedem gültigen Paket zurückgesetzt wird. In das öffentliche Sync-Feld (siehe unten) kann ein Zeitstempel hash-codiert werden, um Paketwiederholungsangriffe auszuschließen.
In einer Ausführungsform wird zu dem Anfangsblock jedes durch den Sender ausgesendeten Pakets ein "Sync-Feld" hinzugefügt. Dieses Sync-Feld kann klar oder als Teil eines verschlüsselten Abschnitts des Pakets erscheinen. Unter der Annahme, dass ein Sender und ein Empfänger einen Zufallszahlengenerator (RNG) und einen Keimwert ausgewählt haben, könnte diese Kombination aus RNG und Keim verwendet werden, um eine Zufallszahlenfolge (RNS) zu erzeugen. Die RNS wird daraufhin verwendet, um wie oben beschrieben eine Folge von Quell/Ziel-IP-Paaren (und auf Wunsch Diskriminatorfeldern und Hardware-Quell-Adressen und Hardware-Ziel-Adressen) zu erzeugen. Dagegen ist es nicht notwendig, die gesamte Folge (oder die ersten N – 1 Werte) zu erzeugen, um die N-te Zufallszahl in der Folge zu erzeugen; falls der Folgeindex N bekannt ist, kann der diesem Index entsprechende Zufallswert direkt erzeugt werden (siehe unten). Zum Erzeugen der Quell- und der Ziel-IP-Folge können verschiedene RNGs (und Keime) mit verschiedenen Grundperioden verwendet werden, wobei aber die Grundkonzepte weiter gültig sind. Der Einfachheit halber wird in der folgenden Diskussion angenommen, dass IP-Quell- und IP-Ziel-Adressenpaare (nur) unter Verwendung eines einzigen RNG-Ablaufsteuerungsmechanismus gesprungen werden.
In Übereinstimmung mit einem "Selbstsynchronisations"-Merkmal liefert ein Sync-Feld in jedem Paketanfangsblock einen Index (d. h. eine Folgenummer) in die zum Erzeugen von IP-Paaren verwendete RNS. Das Einsetzen dieses Index in den RNG, der zum Erzeugen der RNS verwendet wird, liefert einen spezifischen Zufallszahlenwert, der wiederum ein spezifisches IP-Paar liefert. Das heißt, aus Kenntnis des RNG, des Keims und der Indexzahl kann direkt ein IP-Paar erzeugt werden; in diesem Schema ist es nicht notwendig, die gesamte Folge von Zufallszahlen zu erzeugen, die dem Folgewert, der der gelieferten Indexzahl zugeordnet ist, vorausgehen.
Da die Kommunikationsteilnehmer vermutlich zuvor RNGs und Keime ausgetauscht haben, sind die einzigen neuen Informationen, die geliefert werden müssen, um ein IP-Paar zu erzeugen, die Folgenummer. Falls diese Nummer durch den Sender in dem Paketanfangsblock geliefert wird, braucht der Empfänger diese Nummer lediglich in den RNG einzusetzen, um ein IP-Paar zu erzeugen – und somit zu verifizieren, dass das in dem Anfangsblock des Pakets erscheinende IP-Paar gültig ist. Falls der Sender und der Empfänger in diesem Schema die Synchronisation verlieren, kann sich der Empfänger nach Empfang eines einzelnen Pakets sofort erneut synchronisieren, indem er einfach das IP-Paar in dem Paketanfangsblock mit dem IP-Paar vergleicht, das aus der Indexnummer erzeugt wird. Somit kann die synchronisierte Kommunikation nach Empfang eines einzelnen Pakets wieder aufgenommen werden, was dieses Schema ideal für die Mehrpunktkommunikation macht. Im äußersten Fall kann es die Notwendigkeit für Synchronisationstabellen vollständig beseitigen; d. h., der Sender und der Empfänger können sich einfach auf die Indexnummer in dem Sync-Feld stützen, um das IP-Paar in jedem Paket zu validieren, und dadurch die Tabellen vollständig beseitigen.
Das oben erwähnte Schema kann inhärente Sicherheitsprobleme haben, die ihm zugeordnet sind – d. h. die Anordnung des Sync-Felds. Falls das Feld in dem äußeren Anfangsblock angeordnet ist, könnte ein Eindringling die Werte des Felds und ihre Beziehung zu dem IP-Strom beobachten. Dies könnte potentiell den Algorithmus gefährden, der zum Erzeugen der IP-Adressenfolge verwendet wird, was die Sicherheit der Kommunikation gefährden könnte. Falls der Wert dagegen in dem inneren Anfangsblock angeordnet wird, muss der Sender den inneren Anfangsblock entschlüsseln, bevor er den Sync-Wert entnehmen und das IP-Paar verifizieren kann; dies öffnet den Empfänger für bestimmte Arten von Dienstverweigerungsangriffen (DoS-Angriffen) wie etwa Paketwiederholung. Das heißt, falls der Empfänger ein Paket entschlüsseln muss, bevor er das IP-Paar validieren kann, könnte er potentiell gezwungen sein, einen erheblichen Bearbeitungsauf wand bei der Entschlüsselung aufzuwenden, falls ein Angreifer einfach zuvor gültige Pakete erneut sendet. In diesem Szenarium sind weitere Angriffsmethodiken möglich.
Ein möglicher Kompromiss zwischen Algorithmussicherheit und Verarbeitungsgeschwindigkeit ist es, den Sync-Wert zwischen einem inneren (verschlüsselten) und einem äußeren (unverschlüsselten) Anfangsblock aufzuteilen. Das heißt, falls der Sync-Wert ausreichend lang ist, könnte er potentiell in einen sich schnell ändernden Teil, der klar betrachtet werden kann, und in einen festen (oder sich sehr langsam ändernden) Teil, der geschützt werden muss, aufgeteilt werden. Der Teil, der klar betrachtet werden kann, wird der "öffentliche Sync"-Abschnitt genannt, während der Teil, der geschützt werden muss, der "private Sync"-Abschnitt genannt wird.
Zum Erzeugen des vollständigen Sync-Werts werden sowohl der öffentliche Sync-Abschnitt als auch der private Sync-Abschnitt benötigt. Allerdings kann der private Abschnitt so gewählt werden, dass er fest ist und sich nur gelegentlich ändert. Somit kann der private Sync-Wert durch den Adressaten gespeichert werden, was die Notwendigkeit beseitigt, den Anfangsblock zu entschlüsseln, um ihn wiederzugewinnen. Falls der Sender und der Empfänger zuvor über die Häufigkeit übereingekommen sind, mit der sich der private Teil der Sync ändert, kann der Empfänger wahlweise einen einzelnen Anfangsblock entschlüsseln, um die neue private Sync zu entnehmen, falls die Kommunikationslücke, die zum Verlust der Synchronisation geführt hat, die Lebensdauer der früheren privaten Sync überschritten hat. Dies sollte keine belastende Menge an Entschlüsselung darstellen und somit den Empfänger nicht für einen einfach auf der Notwendigkeit des gelegentlichen Entschlüsselns eines einzelnen Anfangsblocks beruhenden Dienstverweigerungsangriff öffnen.
Eine Realisierung hiervon ist die Verwendung einer Hash-Funktion mit einer eineindeutigen Abbildung, um aus dem Sync-Wert den privaten und den öffentlichen Sync-Abschnitt zu erzeugen. Diese Realisierung ist in 13 gezeigt, wo (z. B.) ein erster ISP 1302 der Sender und ein zweiter ISP 1303 der Empfänger ist. (Weitere Alternativen von 13 sind möglich.) Ein übertragenes Paket umfasst einen öffentlichen oder "äußeren" Anfangsblock 1305, der nicht verschlüsselt wird, und einen privaten oder "inneren" Anfangsblock 1306, der z. B. unter Verwendung eines Verbindungsschlüssels verschlüsselt wird. Der äußere Anfangsblock 1305 enthält einen öffentlichen Sync-Abschnitt, während der innere Anfangsblock 1306 einen privaten Sync-Abschnitt enthält. Ein Empfangsknoten entschlüsselt den inneren Anfangsblock unter Verwendung einer Entschlüsselungsfunktion 1307, um den privaten Sync-Abschnitt zu entnehmen. Dieser Schritt ist nur dann notwendig, wenn die Lebensdauer der momentan gepufferten privaten Sync abgelaufen ist. (Falls die momentan gepufferte private Sync noch gültig ist, wird sie einfach aus dem Speicher entnommen und wie in Schritt 1308 gezeigt zu der öffentlichen Sync "hinzugefügt" (was eine inverse Hash-Codierung sein könnte).) In Funktion 1308 werden der öffentliche und der entschlüsselte private Sync-Abschnitt kombiniert, um eine kombinierte Sync 1309 zu erzeugen. Daraufhin wird die kombinierte Sync (1309) in den RNG (1310) eingespeist und mit dem IP-Adressenpaar verglichen (1311), um das Paket zu validieren oder zurückzuweisen.
Eine wichtige Betrachtung ist in dieser Architektur das Konzept von "Zukunft" und "Vergangenheit", wo die öffentlichen Sync-Werte betroffen sind. Obgleich die Sync-Werte selbst zufällig sein sollten, um Spoofing-Angriffe zu verhindern, kann es wichtig sein, dass der Empfänger einen Sync-Wert, der bereits gesendet worden ist, schnell identifizieren kann – selbst wenn das Paket, das diesen Sync-Wert enthält, nie tatsächlich von dem Empfänger empfangen wurde. Eine Lösung ist das Hash-Codieren eines Zeitstempels oder einer Folgenummer in den öffentlichen Sync-Abschnitt, der/die leicht entnommen, geprüft und verworfen werden kann, wodurch der öffentliche Sync-Abschnitt selbst validiert wird.
In einer Ausführungsform können die Pakete geprüft werden, indem das durch das Sync-Feld erzeugte Quell/Ziel-IP-Paar mit dem Paar verglichen wird, das in dem Paketanfangsblock erscheint. Falls (1) sie angepasst sind (2) der Zeitstempel gültig ist und (3) der Totmann-Zeitgeber abgelaufen ist, findet eine erneute Synchronisation statt; andernfalls wird das Paket verworfen. Falls genug Verarbeitungsleistung verfügbar ist, können der Totmann-Zeitgeber und die Synchronisationstabellen vollständig vermieden werden, wobei sich der Empfänger einfach bei jedem Paket neu synchronisiert (z. B. validiert).
Das vorstehende Schema kann eine Mathematik großer ganzer Zahlen (z. B. 160 Bits) erfordern, was seine Realisierung beeinflussen kann. Ohne solche Register großer ganzer Zahlen wird der Verarbeitungsdurchsatz beeinflusst und somit potentiell die Sicherheit von einem Dienstverweigerungsstandpunkt beeinflusst. Dennoch werden die Kosten der Realisierung eines solchen Merkmals verringert, während die Merkmale der Verarbeitung einer Mathematik großer ganzer Zahlen weiter verbreitet werden.
D. Weitere Synchronisationsschemata
Falls, wie oben erläutert wurde, W oder mehr aufeinander folgende Pakete zwischen einem Sender und einem Empfänger in einem VPN verloren gehen (wobei W die Fenstergröße ist), ist das Fenster des Empfängers nicht aktualisiert worden, wobei der Sender Pakete sendet, die nicht im Fenster des Empfängers sind. Der Sender und der Empfänger gewinnen die Synchronisation erst wieder, wenn vielleicht die zufälligen Paare in dem Fenster zufällig wiederholt werden. Somit besteht eine Notwendigkeit, einen Sender und einen Empfänger synchron zu halten, wann immer es möglich ist, und die Synchronisation wiederherzustellen, wenn sie verloren gegangen ist.
Um die Synchronisation zwischen einem Sender und einem Empfänger, die aus der Synchronisation gefallen sind, wiederherzustellen, kann ein "Fixpunkt"-Schema verwendet werden. In diesem Schema wird eine Fixpunktnachricht verwendet, die ein zufälliges IP-Adressenpaar enthält, um Synchronisationsinformationen zu übermitteln. In einer Ausführungsform werden zwei Nachrichten verwendet, um Synchronisationsinformationen zwischen einem Sender und einem Empfänger zu übermitteln:

1. SYNC_REQ ist eine Nachricht, die von dem Sender verwendet wird, um anzugeben, dass er synchronisieren möchte; und
2. SYNC_ACK ist eine Nachricht, die von dem Empfänger verwendet wird, um den Sender zu informieren, dass er synchronisiert worden ist.

Gemäß einer Änderung dieses Zugangs unterhalten sowohl der Sender als auch der Empfänger drei Fixpunkte (siehe 14):

1. In dem Sender ist ckpt_o ("Fixpunkt alt") das IP-Paar, das verwendet wurde, um das letzte SYNC_REQ-Paket erneut zu dem Empfänger zu senden. In dem Empfänger ist ckpt_o ("Fixpunkt alt") das IP-Paar, das wiederholte SYNC_REQ-Pakete von dem Sender empfängt.
2. In dem Sender ist ckpt_n ("Fixpunkt neu") das IP-Paar, das zum Senden des nächsten SYNC_REQ-Pakets zu dem Empfänger verwendet wird. In dem Empfänger ist ckpt_n ("Fixpunkt neu") das IP-Paar, das ein neues SYNC_REQ-Paket von dem Sender empfängt und das veranlasst, dass das Fenster des Empfängers wieder ausgerichtet wird, ckpt_o auf ckpt_n gesetzt wird, ein neues ckpt_n erzeugt wird und ein neues ckpt_r erzeugt wird.
3. In dem Sender ist ckpt_r das IP-Paar, das zum Senden des nächsten SYNC ACK-Pakets zu dem Empfänger verwendet wird. In dem Empfänger ist ckpt_r das IP-Paar, das ein neues SYNC ACK-Paket von dem Sender empfängt und das veranlasst, dass ein neues ckpt_n erzeugt wird. Da das SYNC_ACK von dem Empfänger-ISP zu dem Sender-ISP gesendet wird, nimmt das ckpt_r des Senders auf das ckpt_r des Empfängers Bezug und nimmt das ckpt_r des Empfängers auf das ckpt_r des Senders Bezug (siehe 14).

Wenn ein Sender die Synchronisation beginnt, wird das IP-Paar, das er zum Senden des nächsten Datenpakets verwendet, auf einen vorgegebenen Wert eingestellt, wobei dann, wenn ein Empfänger ein SYNC_REQ zuerst empfängt, das Empfängerfenster aktualisiert wird, so dass es auf das nächste IP-Paar des Senders zentriert ist. Dies ist der Hauptmechanismus für die Fixpunktsynchronisation.
Die Synchronisation kann durch einen Paketzähler (z. B. beginne nach je N gesendeten Paketen eine Synchronisation) oder durch einen Zeitgeber (beginne nach je S Sekunden eine Synchronisation) oder durch eine Kombination beider begonnen werden. Siehe 15. Aus Sicht des Senders arbeitet die Technik wie folgt: (1) Jeder Sender sendet periodisch eine "sync request"-Nachricht zu dem Empfänger, um sicherzustellen, dass er synchronisiert ist. (2) Falls der Empfänger noch synchronisiert ist, sendet er eine "sync ack"-Nachricht zurück. (Falls dies funktioniert, ist keine weitere Aktion erforderlich.) (3) Falls in einer Zeitdauer kein "sync ack" empfangen worden ist, sendet der Sender die Synchronisationsanforderung erneut. Falls der Sender den nächsten Fixpunkt erreicht, ohne eine "sync ack"-Antwort zu empfangen, ist die Synchronisation unterbrochen, wobei der Sender das Senden anhalten sollte. Der Sender sendet weiter sync_reqs, bis er ein sync_ack empfängt, wobei an diesem Punkt die Übertragung wiederhergestellt ist.
Aus Sicht des Empfängers arbeitet das Schema wie folgt: (1) Wenn er eine "sync request"-Anforderung von dem Sender empfängt, schiebt er sein Fenster zur nächsten Fixpunktposition vor (wobei er bei Bedarf sogar Paare überspringt) und sendet eine "sync ack"-Nachricht zu dem Sender. Falls die Sync nie verloren gegangen ist, schiebt der "Sprung nach vorn" tatsächlich zu dem nächsten verfügbaren Adressenpaar in der Tabelle vor (d. h. normaler Vorschub).
Falls ein Eindringling die "Sync-Anforderung"-Nachrichten abfängt und die Kommunikation durch Senden neuer zu stören versucht, wird er ignoriert, falls die Synchronisation hergestellt worden ist, oder hilft es tatsächlich, die Synchronisation wiederherzustellen.
Jedes Mal, wenn eine erneute Synchronisation stattfindet, wird ein Fenster neu ausgerichtet. Diese erneute Ausrichtung bedingt das Aktualisieren des Fensters des Empfängers, um die Adressenpaare zu überspannen, die von dem unmittelbar nach Übertragung des SYNC_REQ-Pakets übertragenen Paket verwendet werden. Normalerweise sind der Sender und der Empfänger synchron zueinander. Allerdings kann das Fenster des Empfängers während der erneuten Synchronisation um viele Schritte vorgerückt werden müssen, wenn ein Netzereignis auftritt. In diesem Fall ist es erwünscht, das Fenster vorwärts zu bewegen, ohne die Zwischenzufallszahlen aufeinander folgend durchschreiten zu müssen. (Dieses Merkmal ist auch für den oben diskutierten Auto-Sync-Zugang erwünscht.)
E. Zufallszahlengenerator mit Vorspringfähigkeit
Ein attraktives Verfahren zum Erzeugen zufällig gesprungener Adressen ist die Verwendung gleicher Zufallszahlengeneratoren in dem Sender und in dem Empfänger und ihr Vorrücken, während Pakete gesendet und empfangen werden. Es gibt viele Zufallszahlenerzeugungsalgorithmen, die verwendet werden könnten. Jeder besitzt seine Stärken und Schwächen für Adressensprunganwendungen.
Lineare kongruente Zufallszahlengeneratoren (LCRs) sind schnelle, einfache und gut charakterisierte Zufallszahlengeneratoren, die veranlasst werden können, effizient n Schritte vorzuspringen. Ein LCR erzeugt die mit dem Keim X₀ beginnend Zufallszahlen X₁, X₂, X₃ ... X_k, unter Verwendung einer Rekursion Xi = (aXi-1 + b)mod c (1)wobei a, b und c einen besonderen LCR definieren. Ein weiterer Ausdruck für X_i Xi = ((ai(X0 + b) – b)/(a – 1))mod c (2)ermöglicht die Vorspringfähigkeit. Der Faktor aⁱ kann selbst für moderates i sehr groß wachsen, falls er uneingeschränkt bleibt. Somit können einige spezielle Eigenschaften der Modulo-Operation verwendet werden, um die zur Berechnung von (2) erforderliche Größe und Verarbeitungszeit zu steuern. (2) kann wie folgt neu geschrieben werden: Xi = (ai(X0(a – 1) + b) – b)/(a – 1)mod c (3)
Es kann gezeigt werden, dass Folgendes gilt: (ai(X0(a – 1) + b) – b)/(a – 1)mod c = ((ai mod((a – 1)c)(X0(a – 1) + b) – b)/(a – 1))mod c (4)
(X₀(a – 1) + b) kann als (X₀(a – 1) + b)mod c gespeichert werden, b als b mod c und aⁱ mod((a – 1)c) kann berechnet werden (dies erfordert O(log(i)) Schritte).
Eine praktische Realisierung dieses Algorithmus springt zwischen den Synchronisationen einen festen Abstand n; dies läuft darauf hinaus, alle n Pakete zu synchronisieren. Das Fenster würde n IP-Paare vom Start des vorangehenden Fensters beginnen. Unter Verwendung von X_j ^w, der Zufallszahl am j-ten Fixpunkt, als X₀ und n als i kann ein Knoten einmal pro LCR aⁿ mod((a – 1)c) speichern und Xj+1 w = Xn(j+1) = ((an mod((a – 1)c)(Xj w(a – 1) + b) – b))/(a – 1)mod c (5)einstellen, um die Zufallszahl für die j + 1-te Synchronisation zu erzeugen. Unter Verwendung dieser Konstruktion könnte ein Knoten in einem konstanten Zeitbetrag (unabhängig von n) einen beliebigen (aber festen) Abstand zwischen den Synchronisationen vorwärts springen.
Pseudo-Zufallszahlen im Allgemeinen und LCRs im Besonderen wiederholen schließlich ihre Zyklen. Diese Wiederholung kann eine Anfälligkeit in dem IP-Sprungschema darstellen. Ein Gegner brauchte lediglich auf eine Wiederholung zu waren, um künftige Folgen vorauszusagen. Eine Art, diese Anfälligkeit zu bewältigen, ist das Erzeugen eines Zufallszahlengenerators mit einem bekannten langen Zyklus. Eine Zufallsfolge kann durch einen neuen Zufallszahlengenerator ersetzt werden, bevor sie sich wiederholt. LCRs können mit bekannten langen Zyklen konstruiert werden. Auf viele Zufallszahlengeneratoren trifft das momentan nicht zu.
Zufallszahlengeneratoren können kryptographisch unsicher sein. Ein Gegner kann die RNG-Parameter ableiten, indem er die Ausgabe oder einen Teil der Ausgabe untersucht. Dies trifft auf LCGs zu. Diese Anfälligkeit kann durch Integration eines Verschlüsselers gemildert werden, der so konstruiert ist, dass er die Ausgabe als Teil des Zufallszahlengenerators verwürfelt. Der Zufallszahlengenerator verhindert, dass ein Gegner einen Angriff – z. B. einen bekannten Klartextangriff – gegen den Verschlüsseler vorbereitet.
F. Zufallszahlengeneratorbeispiel
Es wird ein RNG betrachtet, bei dem a = 31, b = 4 und c = 15 ist. Für diesen Fall wird Gleichung (1) zu: Xi = (31Xi-1 + 4)mod 15 (6)
Falls X₀ = 1 gesetzt wird, erzeugt Gleichung (6) die Folge 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 0, 4, 8, 12. Diese Folge wiederholt sich unbegrenzt. Für einen Sprung vorwärts von 3 Zahlen in dieser Folge ist aⁿ = 31³ = 29791, c^·(a – 1) = 15·30 = 450 und aⁿ mod((a – 1)c) = 31³ mod(15·30) = 29791 mod(450) = 91. Gleichung (5) wird zu: ((91(Xi30 + 4) – 4)/30)mod 15 (7)
Tabelle 1 zeigt die Vorwärtssprungberechnungen aus (7). Die Berechnungen beginnen bei 5 und springen um 3 vorwärts.
TABELLE 1
G. Schnelles Paketfilter
Adressensprung-VPNs müssen schnell bestimmen, ob ein Paket einen gültigen Anfangsblock besitzt und somit eine Weiterverarbeitung erfordert oder einen ungültigen Anfangsblock besitzt (ein feindliches Paket) und sofort zurückgewiesen werden soll. Diese schnellen Bestimmungen werden als "schnelle Paketfilterung" bezeichnet. Diese Fähigkeit schützt das VPN vor Angriffen durch einen Gegner, der feindliche Pakete mit einer hohen Geschwindigkeitsrate in den Empfänger flutet, in der Hoffnung, den Prozessor des Empfängers zu sättigen (ein so genannter "Dienstverweigerungs"-Angriff). Die schnelle Paketfilterung ist ein wichtiges Merkmal zur Realisierung von VPNs in gemeinsam genutzten Medien wie etwa dem Ethernet.
Unter der Annahme, dass alle Teilnehmer in einem VPN einen nicht zugewiesenen "A"-Adressenblock gemeinsam nutzen, ist eine Möglichkeit die Verwendung eines experimentellen "A"-Blocks, der irgendeiner Maschine, die keinen Adressensprung in dem gemeinsam genutzten Medium ausführt, nie zugewiesen wird. Die "A"-Blöcke haben eine 24-Bits-Adresse, die im Gegensatz zu den 8 Bits in "C"-Blöcken gesprungen werden kann. In diesem Fall ist der "A"-Block ein Sprungblock. Die Verwendung des experimentellen "A"-Blocks ist eine wahrscheinliche Option in einem Ethernet, da:

1. die Adressen außerhalb des Ethernet keine Gültigkeit haben und nicht durch ein Gateway nach außen zu einem gültigen Außenziel geleitet werden.
2. es 2²⁴ (~16 Millionen) Adressen gibt, die in jedem "A"-Block gesprungen werden können. Dies liefert > 280 Billionen mögliche Adressenpaare, was es sehr unwahrscheinlich macht, dass ein Gegner eine gültige Adresse vermutet. Außerdem sichert es eine akzeptabel niedrige Wahrscheinlichkeit der Kollision zwischen getrennten VPNs (alle VPNs in einem gemeinsam genutzten Medium erzeugen unabhängig zufällige Adressenpaare aus demselben "A"-Block).
3. die Pakete nicht durch jemanden in dem Ethernet empfangen werden, der nicht in einem VPN ist (es sei denn, dass die Maschine in der Promiscuous-Betriebsart ist), was die Auswirkung auf Nicht-VPN-Computer minimiert.

Das Ethernet-Beispiel wird verwendet, um eine Realisierung einer schnellen Paketfilterung zu beschreiben. Der ideale Algorithmus würde schnell einen Paketanfangsblock untersuchen, bestimmen, ob das Paket feindlich ist, und irgendwelche feindlichen Pakete zurückweisen oder bestimmen, an welches aktive IP-Paar der Paketanfangsblock angepasst ist. Das Problem ist ein klassisches Assoziativspeicherproblem. Um dieses Problem zu lösen, sind eine Vielzahl von Techniken (Hash-Codierung, B-Bäume usw.) entwickelt worden. Jeder dieser Zugänge hat seine Stärken und Schwächen. Zum Beispiel können Hash-Tabellen in einem statistischen Sinn sehr schnell zu arbeiten veranlasst werden, wobei sie aber gelegentlich zu einem viel langsameren Algorithmus entarten können. Diese Langsamkeit kann für eine Zeitdauer anhalten. Da die Notwendigkeit besteht, feindliche Pakete jederzeit schnell zu verwerfen, wäre die Hash-Codierung inakzeptabel.
H. Anwesenheitsvektoralgorithmus
Ein Anwesenheitsvektor ist ein Bitvektor der Länge 2ⁿ, der durch n-Bit-Zahlen (jeweils im Bereich von 0 bis 2ⁿ – 1) indiziert werden kann. Die Anwesenheit von k n-Bit-Zahlen (die nicht notwendig eindeutig sind) kann dadurch angegeben werden, dass die Bits in dem durch jede Zahl indizierten Anwesenheitsvektor auf 1 eingestellt werden. Andernfalls sind die Bits in dem Anwesenheitsvektor 0. Eine n-Bit-Zahl x ist genau dann eine der k Zahlen, wenn das x-te Bit des Anwesenheitsvektors 1 ist. Ein schnelles Paketfilter kann dadurch realisiert werden, dass der Anwesenheitsvektor indiziert wird und nach einer 1 gesucht wird, was als der "Test" bezeichnet wird.
Zum Beispiel wird angenommen, dass die Zahl 135 unter Verwendung eines Anwesenheitsvektors dargestellt werden soll. Es wird das 135-te Bit des Vektors eingestellt. Folglich könnte sehr schnell bestimmt werden, ob eine Adresse von 135 gültig ist, indem nur ein Bit geprüft wird: das 135-te Bit. Die Anwesenheitsvektoren könnten den Tabelleneinträgen für die IP-Adressen entsprechend im Voraus erzeugt werden. Tatsächlich können die ankommenden Adressen als Indizes in einen langen Vektor verwendet werden, was Vergleiche sehr schnell macht. Da jeder RNG eine neue Adresse erzeugt, wird der Anwesenheitsvektor aktualisiert, um die Informationen zu widerspiegeln. Während sich das Fenster bewegt, wird der Anwesenheitsvektor aktualisiert, um Adressen, die nicht mehr gültig sind, auf null zu setzen.
Es gibt eine Abwägung zwischen der Effizienz des Tests und der Menge des Speichers, die zum Speichern des Anwesenheitsvektors bzw. der Anwesenheitsvektoren erforderlich ist. Falls z. B. die 48 Bits der Sprungadressen als ein Index verwendet werden sollen, hat der Anwesenheitsvektor 35 Terabytes. Dies ist für praktische Zwecke eindeutig zu groß. Stattdessen können die 48 Bits in mehrere kleinere Felder geteilt werden. Zum Beispiel können die 48 Bits in vier 12-Bit-Felder geteilt werden (siehe 16). Dies verringert die Speicheranforderung auf Kosten dessen, dass gelegentlich ein feindliches Paket verarbeitet werden muss, auf 2048 Bytes. Tatsächlich müssen die zerlegten Adressenabschnitte anstelle eines langen Anwesenheitsvektors an alle vier kürzeren Anwesenheitsvektoren angepasst sein, bevor die Weiterverarbeitung zulässig ist. (Falls der erste Teil des Adressenabschnitts nicht an den ersten Anwesenheitsvektor angepasst ist, besteht keine Notwendigkeit, die verbleibenden drei Anwesenheitsvektoren zu prüfen.)
Ein Anwesenheitsvektor hat genau dann eine 1 in dem y-ten Bit, wenn eine oder mehrere Adressen mit einem entsprechenden Feld von y aktiv sind. Eine Adresse ist nur dann aktiv, wenn jeder durch das geeignete Teilfeld indizierte Anwesenheitsvektor die Adresse 1 ist.
Es wird ein Fenster von 32 aktiven Adressen und von 3 Fixpunkten betrachtet. Mehr als 99% der Zeit wird ein feindliches Paket durch die Indizierung eines Anwesenheitsvektors zurückgewiesen. Mehr als 99,9999995% der Zeit wird ein feindliches Paket durch die Indizierung aller 4 Anwesenheitsvektoren zurückgewiesen. Im Durchschnitt werden feindliche Pakete in weniger als 1,02 Anwesenheitsvektor-Indexoperationen zurückgewiesen.
Der kleine Prozentsatz feindlicher Pakete, die durch das schnelle Paketfilter gehen, wird zurückgewiesen, wenn in dem aktiven Fenster keine angepassten Paare gefunden werden oder wenn es aktive Fixpunkte gibt. Feindliche Pakete, die glücklicherweise an einem Anfangsblock angepasst sind, werden zurückgewiesen, wenn die VPN-Software den Anfangsblock zu entschlüsseln versucht. Allerdings sind diese Fälle sehr selten. Es gibt viele weitere Arten, in denen dieses Verfahren konfiguriert werden kann, um die Platz/Geschwindigkeits-Abwägungen zu entscheiden.
I. Weitere Synchronisationsverbesserungen
Es kann eine leicht geänderte Form der oben beschriebenen Synchronisationstechniken genutzt werden. Die Grundprinzipien des zuvor beschriebenen Fixpunktsynchronisationsschemas bleiben ungeändert. Allerdings sind die Aktionen, die sich aus dem Empfang der Fixpunkte ergeben, etwas anders. In dieser Änderung unterhält der Empfänger zwischen OoO ("gestört") und 2·WINDOW_SIZE + OoO aktive Adressen (1 ≤ OoO ≤ WINDOW_SIZE und WINDOW_SIZE ≥ 1). OoO und WINDOW_SIZE sind Entwurfsparameter, wobei OoO die minimale Anzahl von Adressen ist, die benötigt werden, um wegen Ereignissen in dem Netz oder Ankünften außer der Reihe verlorene Pakete zu versorgen und WINDOW_SIZE die Anzahl von Paketen ist, die gesendet werden, bevor ein SYNC_REQ ausgegeben wird. 17 zeigt eine Speicheranordnung für aktive Adressen eines Empfängers.
Der Empfänger beginnt mit den ersten 2·WINDOW_SIZE Adressen, die geladen und aktiv (zum Empfangen von Daten bereit) sind. Während Pakete empfangen werden, werden die entsprechenden Einträge als "verwendet" gekennzeichnet und sind nicht mehr zum Empfangen von Paketen auswählbar. Der Sender unterhält einen anfangs auf 0 eingestellten Paketzähler, der die Anzahl von Datenpaketen enthält, die seit der letzten Anfangsübertragung eines SYNC_REQ, für das ein SYNC_ACK empfangen worden ist, gesendet wurden. Wenn der Senderpaketzähler gleich WINDOW_SIZE ist, erzeugt der Sender ein SYNC_REQ und führt seine Anfangssendung aus. Wenn der Empfänger ein SYNC_REQ empfängt, das seinem momentanen CKPT_N entspricht, erzeugt er die nächsten WIN-DOW_SIZE Adressen und beginnt er, sie in der beim ersten Platz nach der letzten aktiven Adresse beginnenden Reihenfolge zu laden, wobei er sie zum Beginn der Anordnung zurücksetzt, nachdem das Ende der Anordnung erreicht worden ist. Wenn ein SYNC_REQ empfangen worden ist, kann die Anordnung des Empfängers wie in 18 aussehen. In diesem Fall sind entweder zwei Pakete verloren gegangen oder werden außer der Reihe empfangen, wenn das SYNC_REQ empfangen wird.
19 zeigt die Anordnung des Empfängers, nachdem die neuen Adressen erzeugt worden sind. Falls der Sender kein SYNC_ACK empfängt, gibt er das SYNC_REQ in regelmäßigen Intervallen erneut aus. Wenn der Sender ein SYNC_ACK empfängt, wird der Paketzähler um WINDOW_SIZE dekrementiert. Falls der Paketzähler 2·WINDOW_SIZE – OoO erreicht, hört der Sender auf, Pakete zu senden, bis schließlich das richtige SYNC_ACK empfangen wird. Daraufhin nimmt der Sender das Senden von Datenpaketen wieder auf. Das zukünftige Verhalten ist im Wesentlichen eine Wiederholung dieses Anfangszyklus.
Die Vorteile dieses Zugangs sind:

1. Es besteht keine Notwendigkeit eines effizienten Vorwärtsspringens in dem Zufallszahlengenerator,
2. es wird nie ein Paket gesendet, das keinen entsprechenden Eintrag auf der Empfängerseite besitzt,
3. es ist keine zeitgebergestützte erneute Synchronisation erforderlich. Dies ist eine Folge von 2.
4. Der Empfänger hat immer die Fähigkeit, Datennachrichten anzunehmen, die innerhalb von OoO Nachrichten nach der zuletzt übertragenen Nachricht übertragenen wurden.

J. Variante des verteilten Übertragungswegs
In 20 ist eine weitere Ausführungsform gezeigt, die verschiedene erfinderische Prinzipien enthält. In dieser Ausführungsform enthält ein Nachrichtenübertragungssystem einen ersten Computer 2001 in Kommunikation mit einem zweiten Computer 2002 über ein Netz 2011 aus Zwischencomputern. In einer Variante dieser Ausführungsform enthält das Netz zwei Kanten-Router 2003 und 2004, von denen jeder mit mehreren Internet-Dienste-Anbietern (ISPs) 2005 bis 2010 verbunden ist. In einer wie in 20 gezeigten Anordnung, die lediglich eine Konfiguration repräsentiert und nicht beschränkend sein soll, ist jeder ISP mit mehreren weiteren ISPs gekoppelt. In 20 ist jede Verbindung zwischen ISPs so bezeichnet, dass sie einen spezifischen physikalischen Übertragungsweg angibt (wobei z. B. AD ein physikalischer Weg ist, der den ISP A (Element 2005) mit dem ISP D (Element 2008) verbindet). Die bei jedem Kanten-Router ankommenden Pakete werden auf der Grundlage einer zufällig oder quasi-zufällig ausgewählten Grundlage wahlweise zu einem der ISPs übertragen, an den der Router angeschlossen ist.
Wie in 21 gezeigt ist, enthält der Computer 2001 oder der Kanten-Router 2003 mehrere Verbindungssendetabellen 2100, die für jeden potentiellen Übertragungsweg über das Netz gültige Mengen von IP-Adressen identifizieren, die zum Senden des Pakets verwendet werden können. Zum Beispiel enthält die AD-Tabelle 2101 mehrere IP-Quell/Ziel-Paare, die zufällig oder quasi-zufällig erzeugt werden. Wenn ein Paket vom ersten Computer 2001 zum zweiten Computer 2002 übertragen werden soll, wird eine der Verbindungstabellen zufällig (oder quasizufällig) ausgewählt und das nächste gültige Quell/Ziel-Adressenpaar aus dieser Tabelle verwendet, um das Paket über das Netz zu übertragen. Falls der Weg AD zufällig ausgewählt wird, wird z. B. das nächste Quell/Ziel-IP-Adressenpaar (für das vorgegeben ist, dass es zwischen dem ISP A (Element 2005) und dem ISP B (Element 2008) übertragen werden soll), zum Übertragen des Pakets verwendet. Falls einer der Übertragungswege entartet oder funktionsunfähig wird, kann diese Verbindungstabelle wie in Tabelle 2105 gezeigt auf eine "Betriebsunfähig-Bedingung eingestellt werden, was verhindert, dass Adressen aus dieser Tabelle ausgewählt werden. Die anderen Übertragungswege würden durch diese unter brochene Verbindung nicht beeinflusst.
3. TEILFORTFÜHRUNGSVERBESSERUNGEN
Das Folgende beschreibt verschiedene Verbesserungen und Merkmale, die auf die oben beschriebenen Ausführungsformen angewendet werden können. Die Verbesserungen umfassen: (1) einen Lastverteiler, der die Pakete gemäß der Übertragungswegqualität auf verschiedene Übertragungswege verteilt; (2) einen DNS-Proxy-Server, der in Reaktion auf eine Domänennamenanfrage transparent ein virtuelles privates Netz erzeugt; (3) ein Merkmal des Managements Großer/Kleiner-Verbindungsbandbreite, das Dienstverweigerungsangriffe an Systemdrosselpunkten verhindert; (4) einen Verkehrsbegrenzer, der ankommende Pakete reguliert, indem er die Rate begrenzt, mit der ein Sender mit einem Empfänger synchronisiert werden kann; und (5) eine Signalisierungssynchronisationseinrichtung, die ermöglicht, dass eine große Anzahl von Knoten mit einem Zentralknoten kommunizieren, indem sie die Kommunikationsfunktion auf zwei getrennte Entitäten aufteilt. Im Folgenden wird jede getrennt diskutiert.
A. Lastverteiler
Verschiedene oben beschriebene Ausführungsformen enthalten ein System, in dem ein sendender Knoten und ein empfangender Knoten über mehrere Übertragungswege gekoppelt sind und in dem aufeinander folgende Pakete quasi-zufällig auf die mehreren Wege verteilt werden. Siehe z. B. 20 und 21 und die beigefügte Beschreibung. Die Verbesserung geht über dieses Grundkonzept dahingehend hinaus, dass sie die Verteilung von Paketen auf verschiedene Wege in der Weise umfasst, dass die Lasten auf den Wegen gemäß der Übertragungsstreckenqualität allgemein im Gleichgewicht sind.
In einer Ausführungsform enthält ein System einen sendenden Knoten und einen empfangenden Knoten, die über mehrere Übertragungswege mit potentiell veränderlicher Übertragungsqualität verbunden sind. Aufeinander folgende Pakete werden auf der Grundlage einer Gewichtungswert-Verteilungsfunktion für jeden Weg über die Wege übertragen. Die Rate, mit der die Pakete über einen gegebenen Weg übertragen werden, kann für jeden Weg anders sein. Um Wege zu identifizieren, die verschlechtert worden sind, wird die relative "Gesundheit" jedes Übertragungswegs überwacht. In einer Ausführungsform wird die Gesundheit jedes Wegs in dem Sender überwacht, indem die Anzahl der gesendeten Pakete mit der Anzahl empfangener Paketquittierungen verglichen wird. Jeder Übertragungsweg kann einen physikalisch getrennten Weg (z. B. über eine Einwähltelephonleitung, ein Computernetz, einen Router, eine Bridge oder dergleichen) umfassen oder kann logisch getrennte Wege, die in einem Breitbandkommunikationsmedium enthalten sind, (z. B. getrennte Kanäle in einem FDM, in einem TDM, in einem CDMA oder in einem anderen Typ einer modulierten oder unmodulierten Verbindung) umfassen.
Wenn die Übertragungsqualität eines Wegs unter einen vorgegebenen Schwellenwert fällt und wenn es weitere Wege gibt, die Pakete übertragen können, ändert der Sender den für diesen Weg verwendeten Gewichtungswert, wobei er es unwahrscheinlicher macht, dass ein gegebenes Paket über diesen Weg übertragen wird. Vorzugsweise wird die Gewichtung nicht niedriger als ein Minimalwert eingestellt, der einen Nennverkehr auf dem Weg erhält. Die Gewichtungen der anderen verfügbaren Wege werden so geändert, dass die Änderung in dem betroffenen Weg kompensiert wird. Wenn sich die Qualität eines Wegs soweit verschlechtert, dass der Sender durch die Synchronisationsfunktion abgeschaltet wird (d. h. keine Pakete an dem Ziel ankommen), wird die Gewichtung auf null eingestellt. Falls alle Sender ausgeschaltet sind, werden keine Pakete gesendet.
Herkömmliche TCP/IP-Protokolle enthalten ein "Drosselungs"-Merkmal, das die Übertragungsrate von Paketen verringert, wenn bestimmt wird, dass in der Übertragung Verzögerungen oder Fehler auftreten. Diesbezüglich werden gelegentlich Zeitgeber verwendet, um zu bestimmen, ob Pakete empfangen worden sind. Allerdings umfassen diese herkömmlichen Techniken zum Begrenzen der Übertragung von Paketen nicht mehrere Übertragungswege zwischen zwei Knoten, in denen die Übertragung über einem besonderen Weg in Bezug auf die anderen anhand der Verbindungsqualität geändert wird.
Gemäß bestimmten Ausführungsformen kann eine lineare oder eine exponentielle Abfallsformel angewendet werden, um den Gewichtungswert über die Zeit, in der ein sich verschlechternder Weg verwendet wird, allmählich zu verringern, um Oszillationen zu dämpfen, die andernfalls auftreten könnten, falls die Gewichtungsverteilungen drastisch (z. B. gemäß einer Stufenfunktion) geändert werden. Ähnlich wird dann, wenn sich die Gesundheit eines verschlechterten Wegs ver bessert, der Gewichtungswert für diesen Weg allmählich erhöht.
Die Übertragungsstreckengesundheit kann dadurch, dass die Anzahl der Pakete, die in dem Übertragungsfenster (siehe die oben diskutierten Ausführungsformen) quittiert werden, mit der Anzahl der in diesem Fenster gesendeten Pakete verglichen wird, und durch den Zustand des Senders (d. h. ein oder aus) bewertet werden. Mit anderen Worten, eine spezifische Realisierung verwendet eher als eine saldierende allgemeine Übertragungsstatistik über die Zeit für einen Weg die oben beschriebenen "Fensterungs"-Konzepte, um die Übertragungsweggesundheit zu bewerten.
Dasselbe Schema kann verwendet werden, um virtuelle Verbindungswege von einem "ungesunden" Weg zu einem "gesunden" zu verschieben und einen Weg für eine neue virtuelle Verbindung auszuwählen.
22A zeigt einen Ablaufplan zum Anpassen der Gewichtungswerte, die mehreren Übertragungsstrecken zugeordnet sind. Es wird angenommen, dass die Software, die in einem oder in mehreren Computerknoten ausgeführt wird, die in 22A gezeigten Schritte ausführt. Außerdem wird angenommen, dass die Software auf einem computerlesbaren Medium wie etwa einer magnetischen oder optischen Platte zur Ausführung durch einen Computer gespeichert werden kann.
In Schritt 2201 beginnend wird die Übertragungsqualität eines gegebenen Übertragungswerts gemessen. Wie oben beschrieben wurde, kann die Messung auf einem Vergleich zwischen der Anzahl der über eine besondere Verbindung übertragenen Pakete mit der Anzahl der über die Verbindung empfangenen Paketquittierungen (z. B. pro Zeiteinheit oder in Absolutangaben) beruhen. Alternativ kann die Qualität dadurch bewertet werden, dass die Anzahl der Pakete, die in dem Übertragungsfenster quittiert werden, mit der Anzahl der in diesem Fenster gesendeten Pakete verglichen wird. In einer nochmals weiteren Abwandlung kann die Anzahl fehlender Synchronisationsnachrichten verwendet werden, um die Verbindungsqualität anzugeben. Natürlich sind viele weitere Abwandlungen möglich.
In Schritt 2202 wird eine Prüfung vorgenommen, um zu bestimmen, ob mehr als ein Sender (z. B. Übertragungsweg) eingeschaltet ist. Wenn das nicht der Fall ist, wird der Prozess abgeschlossen und in Schritt 2201 wieder aufgenommen.
In Schritt 2203 wird die Verbindungsqualität mit einem gegebenen Schwellenwert (z. B. 50% oder irgendeine beliebige Zahl) verglichen. Falls die Qualität unter den Schwellenwert fällt, wird in Schritt 2207 eine Prüfung vorgenommen, um zu bestimmen, ob die Gewichtung über einem minimalen Pegel (z. B. 1%) liegt. Wenn das nicht der Fall ist, wird die Gewichtung in Schritt 2209 auf einen minimalen Pegel eingestellt und die Verarbeitung in Schritt 2201 wieder aufgenommen. Falls die Gewichtung über dem minimalen Pegel liegt, wird in Schritt 2208 daraufhin die Gewichtung für diesen Weg allmählich verringert, woraufhin in Schritt 2206 die Gewichtungen für die verbleibenden Wege dementsprechend angepasst werden, um zu kompensieren (sie z. B. erhöht werden).
Falls in Schritt 2203 die Qualität des Wegs größer oder gleich dem Schwellenwert war, wird in Schritt 2204 eine Prüfung vorgenommen, um zu bestimmen, ob die Gewichtung kleiner als ein stationärer Wert für diesen Weg ist. Wenn das der Fall ist, wird die Gewichtung in Schritt 2205 auf den stationären Wert erhöht, wobei in Schritt 2206 die Gewichtungen für die verbleibenden Wege dementsprechend angepasst werden, um zu kompensieren (sie z. B. verringert werden). Falls die Gewichtung in Schritt 2204 nicht kleiner als der stationäre Wert ist, wird die Verarbeitung in Schritt 2201 wieder aufgenommen, ohne die Gewichtungen anzupassen.
Die Gewichtungen können gemäß verschiedenen Funktionen inkrementell angepasst werden, vorzugsweise dadurch, dass der Wert allmählich geändert wird. In einer Ausführungsform wird eine linear abnehmende Funktion verwendet, um die Gewichtungen anzupassen; gemäß einer weiteren Ausführungsform wird eine exponentiell abfallende Funktion verwendet. Das allmähliche Ändern der Gewichtungen hilft, Oszillationen zu dämpfen, die andernfalls auftreten könnten, falls die Wahrscheinlichkeiten abrupt wären.
Obgleich dies in 22A nicht explizit gezeigt ist, können die Prozesse nur periodisch (z. B. gemäß einem Zeitplan) ausgeführt werden, oder sie können kontinuierlich wie etwa in einer Hintergrundbetriebsart ausgeführt werden. In einer Ausführungsform sollen die kombinierten Gewichtungen aller potentiellen Wege addiert Eins ergeben (wobei z. B. dann, wenn die Gewichtung für einen Weg verringert wird, die entsprechenden Gewichtungen, dass die anderen Wege ausgewählt werden, erhöht werden).
Die Anpassungen der Gewichtungswerte für die anderen Wege können anteilsmäßig zugeordnet werden. Zum Beispiel kann eine Verringerung von 10% des Gewichtungswerts für einen Weg zu einer gleichmäßig verteilten Zunahme der Gewichtungen für die verbleibenden Wege führen. Alternativ können die Gewichtungen wie gewünscht gemäß einer gewichteten Formel angepasst werden (wobei z. B. gesunde Wege gegenüber weniger gesunden Wegen bevorzugt werden). In einer nochmals weiteren Änderung kann die Differenz des Gewichtungswerts in einer Weise, die proportional zu ihrer Verkehrsgewichtung ist, über die verbleibenden Verbindungen amortisiert werden.
22B zeigt Schritte, die ausgeführt werden können, um Übertragungsstrecken herunterzufahren, wo ein Sender abschaltet. In Schritt 2210 findet ein Senderabschaltereignis statt. In Schritt 2211 wird ein Test vorgenommen, um zu bestimmen, ob noch wenigstens ein Sender eingeschaltet ist. Wenn das nicht der Fall ist, werden in Schritt 2215 alle Pakete fallengelassen, bis ein Sender eingeschaltet wird. Falls in Schritt 2211 wenigstens ein Sender eingeschaltet ist, wird in Schritt 2212 die Gewichtung für den Weg auf null eingestellt, wobei die Gewichtungen für die verbleibenden Wege dementsprechend angepasst werden.
23 zeigt einen Computerknoten 2301, der verschiedene Prinzipien der oben beschriebenen Ausführungsformen nutzt. Es wird angenommen, dass zwei Computerknoten des in 23 gezeigten Typs über mehrere getrennte physikalische Übertragungswege kommunizieren. Wie in 23 gezeigt ist, sind zur Kommunikation zwischen den zwei Knoten vier Übertragungswege X1 bis X4 definiert. Jeder Knoten enthält einen Paketsender 2302, der in Übereinstimmung mit einer wie oben beschriebenen Sendetabelle 2308 arbeitet. (Der Paketsender kann außerdem arbeiten, ohne die oben beschriebenen IP-Sprungmerkmale zu verwenden, wobei in der folgenden Beschreibung aber angenommen wird, dass in Verbindung mit dem Wegauswahlmechanismus eine Form des Sprungs genutzt wird.) Außerdem enthält der Computerknoten einen Paketempfänger 2303, der in Übereinstimmung mit einer Empfangstabelle 2309 arbeitet, wobei er ein sich bewegendes Fenster W enthält, das sich bewegt, während gültige Pakte empfangen werden. Ungültige Pakete mit Quell- und Zieladressen, die nicht in dem Fenster W liegen, werden zurückgewiesen.
Während jedes Paket für die Sendung vorbereitet wird, werden aus der Sendetabelle 2308 gemäß irgendeinem der verschiedenen oben beschriebenen Algorith men die Quell- und die Ziel-IP-Adresse (oder andere Diskriminatorwerte) ausgewählt, wobei zu einem Übertragungswegschalter 2307 Pakete erzeugt werden, die diese Quell/Ziel-Adressenpaare enthalten, die dem Knoten entsprechen, mit dem die vier Übertragungswege verknüpft sind. Der Schalter 2307, der eine Software-Funktion umfassen kann, wählt gemäß einer Gewichtungsverteilungstabelle 2306 einen der verfügbaren Übertragungswege aus. Wenn z. B. die Gewichtung für den Weg X1 0,2 ist, wird jedes fünfte Paket auf dem Weg X1 übertragen. Wie gezeigt ist, trifft für die anderen Wege ein ähnliches Regime zu. Anfangs kann der Gewichtungswert jeder Verbindung so eingestellt werden, dass er proportional zu ihrer Bandbreite ist, was als ihr "stationärer" Wert bezeichnet wird.
Der Paketempfänger 2303 erzeugt eine Ausgabe an eine Verbindungsqualität-Messfunktion 2304, die wie oben beschrieben so arbeitet, dass sie die Qualität jedes Übertragungswegs bestimmt. (Der Eingang in den Paketempfänger 2303 für den Empfang ankommender Pakete ist der Klarheit halber weggelassen.) Die Verbindungsqualität-Messfunktion 2304 vergleicht für jede Übertragungsstrecke eine Verbindungsqualität mit einem Schwellenwert und erzeugt bei Bedarf eine Ausgabe an die Gewichtungsanpassungsfunktion 2305. Falls eine Gewichtungsanpassung erforderlich ist, werden die Gewichtungen in Tabelle 2306, vorzugsweise gemäß einer allmählichen (z. B. linear oder exponentiell abnehmenden) Funktion, angepasst. In einer Ausführungsform werden die Gewichtungswerte für alle verfügbaren Wege anfangs auf denselben Wert eingestellt, wobei die Gewichtungen nur dann geändert werden, um die Unterschiede zu widerspiegeln, wenn sich die Qualität der Wege verschlechtert.
Die Verbindungsqualitätsmessfunktion 2304 kann wie oben beschrieben veranlasst werden, als Teil einer Synchronisierfunktion zu arbeiten. Das heißt, falls eine erneute Synchronisation stattfindet und der Empfänger erfasst, dass die Synchronisation verloren gegangen ist (was z. B. dazu führt, dass das Synchronisationsfenster W außer der Reihe vorgerückt wird), kann diese Tatsache verwendet werden, um die Verbindungsqualität-Messfunktion 2304 anzusteuern. Gemäß einer Ausführungsform wird unter Verwendung der während der normalen Synchronisation gesammelten Informationen, geringfügig ergänzt durch die Übertragungsstreckengesundheit von dem Empfänger zu dem Sender, eine Lastverteilung ausgeführt. Der Empfänger unterhält einen Zählwert MESS_R(W) der im Synchronisationsfenster W empfangenen Nachrichten. Wenn er eine Synchronisationsanforderung (SYNC_REQ) empfängt, die dem Ende des Fensters W entspricht, nimmt der Empfänger den Zähler MESS_R in die resultierende Synchronisationsquittierung (SYNC_ACK) auf, die zu dem Sender zurückgesendet wird. Dies ermöglicht, dass der Sender gesendete Nachrichten mit empfangenen Nachrichten vergleicht, um die Gesundheit der Verbindung zu beurteilen.
Falls die Synchronisation vollständig verloren geht, verringert die Gewichtungsanpassungsfunktion 2305 den Gewichtungswert auf dem betroffenen Weg auf null. Wenn die Synchronisation wiedergewonnen wird, wird der Gewichtungswert für den betroffenen Weg allmählich auf seinen ursprünglichen Wert erhöht. Alternativ kann die Verbindungsqualität dadurch gemessen werden, dass die Länge der Zeit bewertet wird, die für den Empfänger zum Quittieren einer Synchronisationsanforderung erforderlich ist. In einer Ausführungsform werden für jeden Übertragungsweg getrennte Sende- und Empfangstabellen verwendet.
Wenn der Sender ein SYNC_ACK empfängt, wird das MESS_R mit der Anzahl (MESS_T) der in einem Fenster übertragenen Nachrichten verglichen. Wenn der Sender ein SYNC_ACK empfängt, werden die Verkehrswahrscheinlichkeiten untersucht und bei Bedarf angepasst. MESS_R wird mit der Anzahl (MESS_T) der übertragenen Nachrichten in einem Fenster verglichen. Es gibt zwei Möglichkeiten:

1. Falls MESS_R kleiner als ein Schwellenwert THRESH ist, gilt die Verbindung als ungesund. Falls der Sender ausgeschaltet wurde, wird der Sender eingeschaltet und die Gewichtung P für diese Verbindung auf einen minimalen Wert MIN eingestellt. Dies erhält für Überwachungszwecke einen Erhaltungsverkehr auf der Verbindung, bis sie sich erholt. Falls der Sender eingeschaltet wurde, wird die Gewichtung P für diese Verbindung auf: P' = α·MIN + (1 – α)·P (1)eingestellt. Gleichung 1 dämpft den Verkehrsgewichtungswert während andauernder Zeitdauern von verschlechtertem Dienst exponentiell auf MIN.
2. Falls MESS_R für eine Verbindung größer oder gleich THRESH ist, gilt die Verbindung als gesund. Falls die Gewichtung P für diese Verbindung größer oder gleich dem stationären Wert S für diese Verbindung ist, wird P ungeändert gelassen. Falls die Gewichtung P für diese Verbindung kleiner als THRESH ist, wird P auf: P' = β·S + (1 – β)·P (2)eingestellt, wobei β ein Parameter wie 0 ≤ β ≤ 1 ist, der die Dämpfungsrate von P bestimmt.

Gleichung 2 erhöht die Verkehrsgewichtung während andauernder Zeitdauern von akzeptablem Dienst auf gedämpfte exponentielle Weise auf S.
Anhand von 24 wird nun ein ausführliches Beispiel gegeben. Wie in 24 gezeigt ist, kommuniziert ein erster Computer 2401 über zwei Router 2403 und 2404 mit einem zweiten Computer 2402. Jeder Router ist über drei Übertragungsstrecken mit dem anderen Router gekoppelt. Wie oben beschrieben wurde, können diese physikalisch verschiedene Verbindungen oder logische Verbindungen (einschließlich virtueller privater Netze) sein.
Es wird angenommen, dass eine erste Verbindung L1 eine Übertragungsbandbreite von 100 MB/s aufrechterhalten kann und eine Fenstergröße von 32 hat; die Verbindung L2 kann 75 MB/s aufrechterhalten und hat eine Fenstergröße von 24; und die Verbindung L3 kann 25 MB/s aufrechterhalten und hat eine Fenstergröße von 8. Somit können die kombinierten Verbindungen 200 MB/s aufrechterhalten. Die stationären Verkehrsgewichtungen sind 0,5 für die Verbindung L1; 0,375 für die Verbindung L2 und 0,125 für die Verbindung L3. Für jede Verbindung ist MIN = 1 MB/s, THRESH = 0,8 MESS_T sowie α = 0,75 und β = 0,5. Diese Verkehrsgewichtungen bleiben stabil, bis eine Verbindung für die Synchronisation anhält oder eine Anzahl empfangener Pakete berichtet, die kleiner als ihr THRESH ist. Es wird die folgende Folge von Ereignissen betrachtet:

1. Die Verbindung L1 empfängt ein SYNC_ACK, das ein MESS_R von 24 enthält, das angibt, dass nur 75% der MESS_T (32) in dem letzten Fenster gesendeten Nachrichten erfolgreich empfangen wurden. Die Verbindung 1 liegt unter THRESH (0,8). Folglich wird der Verkehrsgewichtungswert der Verbindung L1 auf 0,12825 verringert, während der Verkehrsgewichtungswert der Verbindung L2 auf 0,65812 erhöht wird und der Verkehrsgewichtungswert der Verbindung L3 auf 0,217938 erhöht wird.
2. Die Verbindungen L2 und L3 sind gesund geblieben und die Verbindung L1 hat das Synchronisieren angehalten. Daraufhin wird der Verkehrsgewichtungswert der Verbindung L1 auf 0 eingestellt, wird der Verkehrsgewichtungswert der Verbindung L2 auf 0,75 eingestellt und wird der Verkehrsgewichtungswert der Verbindung L33 auf 0,25 eingestellt.
3. Schließlich hat die Verbindung L1 ein SYNC_ACK empfangen, das ein MESS_R von 0 enthält, das angibt, dass keine der in dem letzten Fenster gesendeten MESS_T (32) Nachrichten erfolgreich empfangen wurde. Die Verbindung L1 liegt unter THRESH. Der Verkehrsgewichtungswert der Verbindung L1 wird auf 0,005 erhöht, der Verkehrsgewichtungswert der Verbindung L2 wird auf 0,74625 verringert und der Verkehrsgewichtungswert der Verbindung L3 wird auf 0,24875 verringert.
4. Die Verbindung L1 empfängt ein SYNC_ACK, das ein MESS_R von 32 enthält, das angibt, dass 100% der MESS_T (32) in dem letzten Fenster gesendeten Nachrichten erfolgreich empfangen wurden. Die Verbindung L1 liegt über THRESH. Der Verkehrsgewichtungswert der Verbindung L1 wird auf 0,2525 erhöht, während der Verkehrsgewichtungswert der Verbindung L2 auf 0,560625 verringert wird und der Verkehrsgewichtungswert der Verbindung L3 auf 0,186875 verringert wird.
5. Die Verbindung L1 hat ein SYNC_ACK empfangen, das ein MESS_R von 32 enthält, das angibt, dass 100% der in dem letzten Fenster gesendeten MESS_T (32) Nachrichten erfolgreich empfangen wurden. Die Verbindung L1 liegt über THRESH. Der Verkehrsgewichtungswert der Verbindung L1 wird auf 0,37625 erhöht; der Verkehrsgewichtungswert der Verbindung L2 wird auf 0,4678125 verringert und der Verkehrsgewichtungswert der Verbindung L3 wird auf 0,1559375 verringert.
6. Die Verbindung L1 bleibt gesund und die Verkehrswahrscheinlichkeiten nähern sich ihren stationären Verkehrswahrscheinlichkeiten an.

B. Verwendung eines DNS-Proxy zum transparenten Erzeugen virtueller privater Netze
Eine zweite Verbesserung betrifft die automatische Erzeugung eines virtuellen privaten Netzes (VPN) in Reaktion auf eine Domänennamen-Server-Nachschlagefunktion.
Herkömmliche Domänennamen-Server (DNS) stellen eine Nachschlagefunktion bereit, die die IP-Adresse eines angeforderten Computers oder Hosts zurückgibt. Wenn ein Computeranwender z. B. den Web-Namen "Yahoo.com" eintippt, sendet der Web-Browser des Anwenders eine Anforderung an einen DNS, der den Namen in eine vierteilige IP-Adresse umsetzt, die zu dem Browser des Anwenders zurückgegeben und daraufhin durch den Browser verwendet wird, um sich mit der Ziel-Website in Verbindung zu setzen.
Dieses herkömmliche Schema ist in 25 gezeigt. Der Computer 2501 eines Anwenders enthält eine Client-Anwendung 2504 (z. B. einen Web-Browser) und einen IP-Protokollstapel 2505. Wenn der Anwender den Namen eines Ziel-Hosts eingibt, wird an einen DNS 2502 (über den IP-Protokollstapel 2505) eine Anforderung DNS REQ gestellt, die dem Namen zugeordnete IP-Adresse nachzuschlagen. Der DNS gibt die IP-Adresse DNS RESP an die Client-Anwendung 2504 zurück, die daraufhin die IP-Adresse verwenden kann, um mit dem Host 2503 über getrennte Transaktionen wie etwa PAGE REQ und PAGE RESP zu kommunizieren.
In der in 25 gezeigten herkömmlichen Architektur können schändliche Lauscher im Internet die DNS REQ-Pakete und die DNS RESP-Pakete abfangen und somit erfahren, mit welchen IP-Adressen sich der Anwender in Verbindung gesetzt hat. Falls z. B. ein Anwender einen sicheren Kommunikationsweg mit einer Website mit dem Namen "Target.com" aufbauen möchte, wird z. B., wenn sich der Browser des Anwenders mit einem DNS in Verbindung setzt, um die IP-Adresse für diese Website zu suchen, die wahre IP-Adresse dieser Website als Teil der DNS-Abfrage über das Internet offenbart. Dies behindert die anonyme Kommunikation im Internet.
Ein herkömmliches Schema, das sichere virtuelle private Netze über das Internet bereitstellt, liefert zu dem DNS-Server die öffentlichen Schlüssel der Maschinen, für die der DNS-Server die Adressen hat. Dies ermöglicht, dass die Hosts automatisch die öffentlichen Schlüssel eines Hosts wiedergewinnen, mit dem der Host kommunizieren soll, so dass der Host ein VPN aufbauen kann, ohne den Anwender den öffentlichen Schlüssel des Ziel-Hosts eingegeben zu lassen. Eine Realisierung dieses Standards wird derzeit als Teil des FreeS/WAN-Projekts (RFC 2535) entwickelt.
Das herkömmliche Schema leidet an bestimmten Nachteilen. Zum Beispiel kann jeder Anwender eine DNS-Anforderung ausführen. Darüber hinaus werden die DNS-Anforderungen für alle Anwender auf den gleichen Wert aufgelöst.
Gemäß bestimmten Aspekten der Erfindung fängt ein spezialisierter DNS-Server DNS-Anforderungen ab, wobei der Server dann, wenn die Anforderung von einem speziellen Anwendertyp ist (z. B. von einem, für den sichere Kommunikationsdienste definiert sind), nicht die wahre IP-Adresse des Zielknotens zurückgibt, sondern stattdessen automatisch ein virtuelles privates Netz zwischen dem Zielknoten und dem Anwender aufbaut. Das VPN wird vorzugsweise unter Verwendung der IP-Adressen"Sprung"-Merkmale der oben beschriebenen Grunderfindung realisiert, so dass die wahre Identität der zwei Knoten selbst dann nicht bestimmt werden kann, wenn Pakete während der Kommunikation abgefangen werden. Für DNS-Anforderungen, von denen bestimmt wird, dass sie keine sicheren Dienste erfordern (z. B. ein nicht registrierter Anwender) "lässt" der DNS-Server die Anforderung transparent "durch", um eine normale Nachschlagefunktion bereitzustellen und die IP-Adresse des Ziel-Web-Servers zurückzugeben, sofern der anfordernde Host die Berechtigungen zum Auflösen ungesicherter Sites hat. An verschiedene Anwender, die eine gleiche DNS-Anforderung stellen, könnten verschiedene Ergebnisse geliefert werden.
26 zeigt ein System, das verschiedene oben zusammengefasste Prinzipien nutzt. Der Computer 2601 eines Anwenders enthält einen herkömmlichen Client (z. B. einen Web-Browser) 2605 und einen IP-Protokollstapel 2606, der vorzugsweise in Übereinstimmung mit einer wie oben skizzierten IP-Sprungfunktion 2607 arbeitet. Ein geänderter DNS-Server 2602 enthält eine herkömmliche DNS-Server-Funktion 2609 und einen DNS-Proxy 2610. Zwischen den geänderten DNS-Server und eine sichere Ziel-Site 2704 ist ein Pförtner-Server 2603 eingefügt. Eine "unsichere" Ziel-Site 2611 ist außerdem über herkömmliche IP-Protokolle benutzbar.
Gemäß einer Ausführungsform fängt der DNS-Proxy 2610 alle DNS-Nachschlagefunktionen vom Client 2605 ab und bestimmt, ob der Zugang zu einer sicheren Site angefordert worden ist. Falls der Zugang zu einer sicheren Site angefordert worden ist (wie z. B. durch eine Domänennamenerweiterung oder durch Bezugnahme auf eine interne Tabelle dieser Sites bestimmt wird), bestimmt der DNS- Proxy 2610, ob der Anwender ausreichende Sicherheitsberechtigungen hat, um auf die Site zuzugreifen. Wenn das der Fall ist, sendet der DNS-Proxy 2610 zu dem Pförtner 2603 eine Nachricht, die anfordert, dass zwischen dem Anwendercomputer 2601 und der sicheren Ziel-Site 2604 ein virtuelles privates Netz erzeugt wird. In einer Ausführungsform erzeugt der Pförtner 2603 "Sprungblöcke", die durch den Computer 2601 und die sichere Ziel-Site 2604 für die sichere Kommunikation zu verwenden sind. Daraufhin übermittelt der Pförtner 2603 diese zu dem Anwendercomputer 2601. Anschließend gibt der DNS-Proxy 2610 zu dem Anwendercomputer 2601, vorzugsweise unter Verwendung eines sicheren administrativen VPN, die aufgelöste Adresse 2604 zurück, die an ihn durch den Pförtner übergeben worden ist (diese Adresse könnte verschieden von dem tatsächlichen Ziel-Computer sein). Die Adresse, die zurückgegeben wird, braucht nicht die tatsächliche Adresse des Zielcomputers zu sein.
Hätte der Anwender das Nachschlagen einer nicht sicheren Website wie etwa der Site 2611 angefordert, würde der DNS-Proxy die Nachschlageanforderung lediglich zu dem herkömmlichen DNS-Server 2609 übergeben, wobei sie auf herkömmliche Weise behandelt würde und die IP-Adresse der nicht sicheren Website 2611 zurückgegeben würde. Falls der Anwender das Nachschlagen einer sicheren Website angefordert hätte, aber nicht die Berechtigungen zum Erzeugen einer solchen Verbindung hätte, würde der DNS-Proxy 2610 einen Fehler "Host unbekannt" zu dem Anwender zurückgeben. Auf diese Weise könnten an verschiedene Anwender, die Zugriff auf denselben DNS-Namen anfordern, verschiedene Nachschlageergebnisse geliefert werden.
Der Pförtner 2603 kann (wie in 26 gezeigt) in einem getrennten Computer oder als eine Funktion im geänderten DNS-Server 2602 realisiert sein. Im Allgemeinen wird erwartet, dass der Pförtner 2703 das zum sicheren Kommunizieren benötigte Zuordnen und Austauschen von Informationen wie etwa unter Verwendung von "gesprungenen" IP-Adressen erleichtert. Es wird angenommen, dass sichere Hosts wie etwa die Site 2604 mit einer sicheren Kommunikationsfunktion wie etwa mit einer IP-Sprungfunktion 2608 ausgestattet sind.
Es ist klar, dass die Funktionen des DNS-Proxy 2610 und des DNS-Servers 2609 zweckmäßigkeitshalber zu einem einzigen Server kombiniert werden können. Obgleich das Element 2602 als Kombination der Funktionen zweier Server gezeigt ist, kann darüber hinaus veranlasst werden, dass die zwei Server unabhängig arbeiten.
27 zeigt Schritte, die durch den DNS-Proxy-Server 2610 ausgeführt werden können, um Anforderungen für das DNS-Nachschlagen für sichere Hosts zu behandeln. In Schritt 2701 wird eine DNS-Nachschlageanforderung für einen Ziel-Host empfangen. In Schritt 2702 wird eine Prüfung vorgenommen, um zu bestimmen, ob der Zugriff auf einen sicheren Host angefordert wurde. Wenn das nicht der Fall ist, wird die DNS-Anforderung in Schritt 2703 an einen herkömmlichen DNS-Server 2609 übergeben, der die IP-Adresse der Ziel-Site nachschlägt und sie zur Weiterverarbeitung an die Anwendung des Anwenders zurückgibt.
Falls in Schritt 2702 der Zugriff auf einen sicheren Host angefordert wird, wird in Schritt 2704 eine weitere Prüfung vorgenommen, um zu bestimmen, ob der Anwender berechtigt ist, mit dem sicheren Host zu verbinden. Diese Prüfung kann mit Bezug auf eine intern gespeicherte Liste berechtigter IP-Adressen vorgenommen werden oder kann durch Kommunikation mit dem Pförtner 2603 (z. B. über ein "administratives" VPN, das sicher ist) vorgenommen werden. Es ist klar, dass außerdem für verschiedene Kategorien von Hosts verschiedene Sicherheitsniveaus bereitgestellt werden können. Zum Beispiel können einige Sites so konstruiert sein, dass sie ein bestimmtes Sicherheitsniveau haben, wobei das Sicherheitsniveau des Anwenders, der den Zugriff anfordert, an dieses Sicherheitsniveau angepasst sein muss. Außerdem kann das Sicherheitsniveau des Anwenders dadurch bestimmt werden, dass zu dem Computer des Anwenders eine Anforderungsnachricht zurückgesendet wird, die anfordert, dass er beweist, dass er ausreichend Berechtigungen besitzt.
Falls der Anwender nicht berechtigt ist, auf die sichere Site zuzugreifen, wird eine Nachricht "Host unbekannt" zurückgegeben (Schritt 2705). Falls der Anwender ausreichend Sicherheitsberechtigungen besitzt, wird in Schritt 2706 zwischen dem Computer des Anwenders und der sicheren Ziel-Site ein sicheres VPN aufgebaut. Wie oben beschrieben wurde, erfolgt dies vorzugsweise durch Zuordnen eines Sprungregimes, das zwischen dem Computer des Anwenders und der sicheren Ziel-Site ausgeführt wird, wobei es vorzugsweise transparent für den Anwender ausgeführt wird (d. h., der Anwender braucht nicht am Erzeugen der sicheren Verbindung beteiligt sein). Wie in verschiedenen Ausführungsformen dieser Anmeldung beschrieben ist, können irgendwelche der verschiedenen Felder (z. B. IP-Quell/Ziel-Adresse; ein Feld in dem Anfangsblock; usw.) "gesprungen" sein, um sicher zu kommunizieren.
Einige oder alle Sicherheitsfunktionen können so in den Pförtner 2603 eingebettet sein, dass er alle Anforderungen zum Verbinden mit sicheren Sites behandelt. In dieser Ausführungsform kommuniziert der DNS-Proxy 2610 mit dem Pförtner 2603, um (vorzugsweise über ein sicheres administratives VPN) zu bestimmen, ob der Anwender Zugriff auf eine besondere Website hat. Im Folgenden werden beispielhaft verschiedene Szenarien zur Realisierung dieser Merkmale beschrieben:
Szenarium Nr. 1: Der Client hat die Genehmigung, auf den Zielcomputer zuzugreifen, und der Pförtner hat eine Regel, um ein VPN für den Client zu erzeugen. In diesem Szenarium wird die DNS-Anforderung des Clients durch den DNS-Proxy-Server 2610 empfangen, der die Anforderung zum Pförtner 2603 weiterleitet. Der Pförtner baut ein VPN zwischen dem Client und dem angeforderten Ziel auf. Der Pförtner liefert die Adresse des Ziels zum DNS-Proxy, der daraufhin den aufgelösten Namen als ein Ergebnis zurückgibt. Die aufgelöste Adresse kann in einem sicheren administrativen VPN zu dem Client zurückgesendet werden.
Szenarium Nr. 2: Der Client hat keine Berechtigung, auf den Zielcomputer zuzugreifen. In diesem Szenarium wird die DNS-Anforderung des Clients durch den DNS-Proxy-Server 2610 empfangen, der die Anforderung zum Pförtner 2603 weiterleitet. Der Pförtner weist die Anforderung zurück, wobei er den DNS-Proxy-Server 2610 informiert, dass er den Zielcomputer nicht finden konnte. Daraufhin gibt der DNS-Proxy 2610 eine Fehlermeldung "Host unbekannt" zum Client zurück.
Szenarium Nr. 3: Der Client hat die Genehmigung zum Verbinden unter Verwendung einer normalen Nicht-VPN-Verbindung und der Pförtner besitzt keine Regel zum Aufbauen eines VPN für den Client zu der Ziel-Site. In diesem Szenarium wird die DNS-Anforderung des Clients durch den DNS-Proxy-Server 2610 empfangen, der seine Regeln prüft und bestimmt, dass kein VPN benötigt wird. Daraufhin informiert der Pförtner 2603 den DNS-Proxy-Server, die Anforderung zum herkömmlichen DNS-Server 2609 weiterzuleiten, der die Anforderung auflöst und das Ergebnis zum DNS-Proxy-Server und daraufhin zum Client zurückgibt.
Szenarium Nr. 4: Der Client hat keine Genehmigung zum Aufbauen einer norma len/Nicht-VPN-Verbindung und der Pförtner hat keine Regel zum Herstellen eines VPN für den Client zu der Ziel-Site. In diesem Szenarium empfängt der DNS-Proxy-Server die DNS-Anforderung des Clients und leitet sie zum Pförtner 2603 weiter. Der Pförtner 2603 bestimmt, dass kein spezielles VPN benötigt wird, dass der Client aber nicht berechtigt ist, mit Nicht-VPN-Mitgliedern zu kommunizieren. Der Pförtner weist die Anforderung zurück, was veranlasst, dass der DNS-Proxy-Server 2610 eine Fehlermeldung zum Client zurückgibt.
C. Bandbreitenmanagement große Verbindungen/kleine Verbindungen
Ein Merkmal der Grundarchitektur ist die Fähigkeit, so genannte "Dienstverweigerungs"-Angriffe zu verhindern, die auftreten können, falls ein Computer-Hacker einen bekannten Internet-Knoten mit Paketen überflutet und somit verhindert, dass der Knoten mit anderen Knoten kommuniziert. Da IP-Adressen oder andere Felder "gesprungen" sind und Pakete, die mit ungültigen Adressen ankommen, schnell verworfen werden, sind die Internet-Knoten vor einer auf eine einzelne IP-Adresse gerichteten Überflutung geschützt.
In einem System, in dem ein Computer über eine Verbindung mit einer begrenzten Bandbreite (z. B. über einen Kanten-Router) mit einem Knoten, der eine Verbindung mit viel höherer Bandbreite unterstützen kann (z. B. mit einem Internet-Dienste-Anbieter), gekoppelt ist, könnte durch einen bestimmten Hacker eine potentielle Schwäche ausgenutzt werden. Wie in 28 gezeigt ist, wird angenommen, dass ein erster Host-Computer 2801 unter Verwendung der oben beschriebenen IP-Adressensprungprinzipien mit einem zweiten Host-Computer 2804 kommuniziert. Der erste Host-Computer ist über eine Verbindung (LOW BW) mit niedriger Bandbreite über einen Kanten-Router 2802 mit einem Internet-Dienste-Anbieter (ISP) 2803 gekoppelt und wiederum über eine Verbindung (HIGH BW) mit hoher Bandbreite über Teile des Internet mit einem zweiten Host-Computer 2804 gekoppelt. In dieser Architektur kann der ISP eine hohe Bandbreite zum Internet, aber eine viel niedrigere Bandbreite zu den Kanten-Routern 2802 unterstützen.
Es wird angenommen, dass ein Computer-Hacker eine große Menge an einen ersten Host-Computer 2801 adressierter Leerpakete über die Verbindung HIGH BW mit hoher Bandbreite übertragen kann. Normalerweise könnte der Host-Computer 2801 die Pakete schnell zurückweisen, da sie nicht in dem durch das IP-Adressensprungschema zugelassenen Akzeptanzfenster liegen. Da die Pakete über die Verbindung LOW BW mit niedriger Bandbreite laufen müssen, überwältigen die Pakete aber die Verbindung mit niedriger Bandbreite, bevor sie vom Host-Computer 2801 empfangen werden. Folglich wird die Verbindung zum Host-Computer 2801 effektiv überflutet, bevor die Pakete verworfen werden können.
Gemäß einer erfinderischen Verbesserung wird in den Knoten hoher Bandbreite (z. B. in den ISP 2803) eine "Verbindungsschutz"-Funktion 2805 eingeführt, die die für einen Zielknoten niedriger Bandbreite bestimmten Pakete schnell verwirft, falls sie keine gültigen Pakete sind. Jedes für einen Knoten niedriger Bandbreite bestimmte Paket wird kryptographisch authentisiert, um zu bestimmen, ob es zu einem VPN gehört. Falls es kein gültiges VPN-Paket ist, wird das Paket bei dem Knoten hoher Bandbreite verworfen. Falls das Paket als zu einem VPN gehörend berechtigt ist, wird das Paket mit hoher Bevorzugung durchgelassen. Falls das Paket ein gültiges Nicht-VPN-Paket ist, wird es mit einer niedrigeren Dienstqualität (z. B. niedrigeren Priorität) durchgelassen.
In einer Ausführungsform unterscheidet der ISP unter Verwendung des Protokolls des Pakets zwischen VPN- und Nicht-VPN-Paketen. Im Fall des IPSEC [rfc2401] haben die Pakete die IP-Protokolle 420 und 421. Im Fall des TARP-VPN haben die Pakete ein IP-Protokoll, das noch nicht definiert worden ist. Der Verbindungsschutz 2805 des ISP unterhält eine Tabelle gültiger VPNs, die er verwendet, um zu validieren, ob VPN-Pakete kryptographisch gültig sind.
Gemäß einer Ausführungsform werden Pakete, die nicht in irgendwelchen von den Knoten an der Verbindung mit niedriger Bandbreite verwendeten Sprungfenstern liegen, zurückgewiesen oder mit einer niedrigeren Dienstqualität gesendet. Ein Zugang, dies zu tun, ist, eine Kopie der von den Knoten niedriger Bandbreite verwendeten IP-Sprungtabellen zu dem Knoten hoher Bandbreite zu liefern, so dass sowohl der Knoten hoher Bandbreite als auch der Knoten niedriger Bandbreite gesprungene Pakete verfolgen (wobei z. B. der Knoten hoher Bandbreite sein Sprungfenster bewegt, während gültige Pakete empfangen werden). In diesem Szenarium verwirft der Knoten hoher Bandbreite Pakete, die nicht in dem Sprungfenster liegen, bevor sie über die Verbindung mit niedriger Bandbreite übertragen werden. Somit unterhält z. B. der ISP 2903 eine Kopie 2910 der vom Host-Computer 2901 verwendeten Empfangstabelle. Ankommende Pakete, die nicht in dieser Empfangstabelle liegen, werden verworfen. Gemäß einer anderen Ausführungsform validiert der Verbindungsschutz 2805 jedes VPN-Paket unter Verwendung eines verschlüsselten Hash-codierten Nachrichtenauthentisierungscodes (HMAC)[rfc2104]. Gemäß einer weiteren Ausführungsform können getrennte VPN (z. B. unter Verwendung von Sprungblöcken) für die Kommunikation zwischen dem Knoten niedriger Bandbreite und dem Knoten hoher Bandbreite aufgebaut werden (wobei z. B. Pakete, die bei dem Knoten hoher Bandbreite ankommen, in andere Pakete umgesetzt werden, bevor sie zu dem Knoten niedriger Bandbreite gesendet werden).
Wie in 29 gezeigt ist, wird z. B. angenommen, dass ein erster Host-Computer 2900 über das Internet mit einem zweiten Host-Computer 2902 kommuniziert, wobei der Weg eine Verbindung HIGH BW mit hoher Bandbreite zu einem ISP 2901 und eine Verbindung LOW BW mit niedriger Bandbreite über einen Kanten-Router 2904 enthält. In Übereinstimmung mit der hier beschriebenen Grundarchitektur tauschen der erste Host-Computer 2900 und der zweite Host-Computer 2902 Sprungblöcke (oder einen Sprungblockalgorithmus) aus und können angepasste Sende- und Empfangstabellen 2905, 2906, 2912 und 2913 erzeugen. Daraufhin senden die zwei Computer in Übereinstimmung mit der Grundarchitektur Pakete mit anscheinend zufälligen IP-Quell- und IP-Zieladressen, wobei jeder ein entsprechendes Sprungfenster in seiner Empfangstabelle bewegt, während gültige Pakete empfangen werden.
Es wird angenommen, dass ein schändlicher Computer-Hacker 2903 folgern konnte, dass Pakete mit einem bestimmten Bereich von IP-Adressen (z. B. einfachheitshalber der Adressen 100 bis 200) zum ISP 2901 übertragen werden und dass diese Pakete über eine Verbindung mit niedriger Bandbreite weitergeleitet werden. Somit könnte der Hacker-Computer 2903 mit Paketen mit Adressen, die in dem Bereich 100 bis 200 liegen, "überfluten", wobei er erwartet, dass sie entlang der Verbindung LOW BW mit niedriger Bandbreite weitergeleitet werden, was somit veranlasst, dass die Verbindung mit niedriger Bandbreite überwältigt wird. Der schnelle Paketzurückweisungsmechanismus im ersten Host-Computer 3000 hätte wenig Nutzen beim Zurückweisen dieser Pakete, da die Verbindung mit niedriger Bandbreite effektiv verstopft wäre, bevor die Pakete zurückgewiesen werden könnten. In Übereinstimmung mit einem Aspekt der Verbesserung würde der VPN-Verbindungsschutz 2911 aber verhindern, dass sich der Angriff auf die Leistung des VPN-Verkehrs auswirkt, da die Pakete entweder als ungültige VPN-Pakete zurückgewiesen würden oder eine niedrigere Dienstqualität als VPN- Verkehr über die Verbindung mit niedriger Bandbreite erhalten würden. Allerdings könnte ein Dienstverweigerungs-Flut-Angriff Nicht-VPN-Verkehr weiter unterbrechen.
Gemäß einer Ausführungsform der Verbesserung unterhält der ISP 2901 ein getrenntes VPN mit einem ersten Host-Computer 2900 und übersetzt somit Pakete, die bei dem ISP ankommen, bevor sie zum Host-Computer 2900 gesendet werden, in Pakete, die einen anderen IP-Anfangsblock haben. Die kryptographischen Schlüssel, die zum Authentisieren von VPN-Paketen bei dem Verbindungsschutz 2911 verwendet werden, und die kryptographischen Schlüssel, die zum Verschlüsseln und Entschlüsseln der VPN-Pakete beim Host 2902 und beim Host 2901 verwendet werden, können verschieden sein, so dass der Verbindungsschutz 2911 keinen Zugriff auf die privaten Host-Daten hat; er hat lediglich die Fähigkeit zum Authentisieren dieser Pakete.
Gemäß noch einer dritten Ausführungsform kann der Knoten niedriger Bandbreite zu dem Knoten hoher Bandbreite eine spezielle Nachricht senden, die ihn anweist, alle Übertragungen zu einer besonderen IP-Adresse herunterzufahren, so dass lediglich gesprungene Pakete zu dem Knoten niedriger Bandbreite durchgehen. Diese Ausführungsform verhindert, dass ein Hacker mit Paketen unter Verwendung einer einzigen IP-Adresse überflutet. Gemäß noch einer vierten Ausführungsform kann der Knoten hoher Bandbreite so konfiguriert sein, dass er zu dem Knoten niedriger Bandbreite übertragene Pakete verwirft, falls die Übertragungsrate für irgendeine gegebene IP-Adresse einen bestimmten vorgegebenen Schwellenwert übersteigt; dies würde ermöglichen, dass gesprungene Pakete durchgehen. Diesbezüglich kann der Verbindungsschutz 2911 verwendet werden, um zu erfassen, dass die Rate der Pakete an einer gegebenen IP-Adresse eine Schwellenwertrate übersteigt; weitere zu derselben IP-Adresse adressierte Pakete würden fallengelassen oder mit einer niedrigeren Priorität übertragen (z. B. verzögert).
D. Verkehrsbegrenzer
In einem System, in dem mehrere Knoten unter Verwendung der "Sprung"-Technologie kommunizieren, könnte ein verräterischer Eingeweihter das System intern mit Paketen überfluten. Um diese Möglichkeit zu verhindern, umfasst eine erfinderische Verbesserung das Abschließen von "Verträgen" zwischen Knoten in dem System, so dass ein Empfänger jedem Paketsender eine Bandbreitenbegrenzung auferlegen kann. Eine Technik, die dies tut, ist das Verzögern der Annahme einer Fixpunkt-Synchronisationsanforderung von einem Sender, bis eine bestimmte Zeitdauer (z. B. eine Minute) verstrichen ist. Jeder Empfänger kann durch Verzögern der "SYNC ACK"-Antworten auf "SYNC_REQ"-Nachrichten die Rate, mit der sich sein Sprungfenster bewegt, effektiv steuern.
Eine einfache Änderung an der Fixpunktsynchronisationseinrichtung dient dazu, einen Empfänger vor versehentlicher oder absichtlicher Überlastung von einem internen verräterischen Client zu schützen. Diese Änderung beruht auf der Beobachtung, dass ein Empfänger seine Tabellen erst aktualisiert, wenn ein SYNC_REQ auf die gesprungene Adresse CKPT_N empfangen worden ist. Es ist eine einfache Sache, die Erzeugung eines neuen CKPT_N bis zu einem geeigneten Intervall nach früheren Fixpunkten zu verzögern.
Es wird angenommen, dass ein Empfänger den Empfang von einem Sender auf 100 Pakete pro Sekunde beschränken möchte und dass alle 50 Pakete Fixpunkt-Synchronisationsnachrichten ausgelöst werden. Ein konformer Sender würde nicht häufiger als alle 0,5 Sekunden neue SYNC_REQ-Nachrichten ausgeben. Der Empfänger könnte einen nicht konformen Sender vom Synchronisieren verzögern, indem er die Ausgabe des CKPT_N für 0,5 Sekunden, nachdem das letzte SYNC_REQ angenommen wurde, verzögert.
Falls im Allgemeinen M Empfänger N Sender beschränken müssen, die nach je W Nachrichten zum Senden von R Nachrichten pro Sekunden im Ganzen neue SYNC_REQ-Nachrichten ausgeben, könnte jeder Empfänger das Ausgeben eines neuen CKPT_N verzögern, bis M·N·W/R Sekunden verstrichen sind, seit das letzte SYNC_REQ empfangen und angenommen worden ist. Falls der Sender diese Rate zwischen einem Fixpunktpaar überschreitet, gibt er den neuen Fixpunkt aus, bevor der Empfänger bereit ist, ihn zu empfangen, wobei das SYNC_REQ durch den Empfänger verworfen wird. Danach gibt der Sender das SYNC_REQ alle T1 Sekunden erneut aus, bis er ein SYNC_ACK empfängt. Schließlich aktualisiert der Empfänger CKPT_N, wobei das SYNC_REQ quittiert wird. Falls die Übertragungsrate die zulässige Rate stark übersteigt, hält der Sender an, bis er konform ist. Falls der Sender die zulässige Rate etwas übersteigt, hält er schließlich nach mehreren Runden verzögerter Synchronisation an, bis er konform ist. Das Hacken des Codes des Senders, damit er nicht herunter fährt, ermöglicht lediglich, dass der Sender das Akzeptanzfenster verliert. In diesem Fall kann er das Fenster erst wiedergewinnen und fortfahren, nachdem er wieder konform ist.
Wenn das obige Schema realisiert wird, sollten zwei praktische Probleme betrachtet werden:

1. Um statistische Fluktuationen in den Verkehrsankunftszeiten und ungleichförmige Lastverteilung zu berücksichtigen, sollte die Empfängerrate etwas höher als die zulässige Rate sein.
2. Da ein Empfänger mit Recht für eine Zeitdauer weitersendet, nachdem ein SYNC_REQ gesendet worden ist, kann der obige Algorithmus die Bandbreite des Senders künstlich verringern. Falls Ereignisse für eine Zeitdauer verhindern, dass ein konformer Sender synchronisiert (z. B. wenn das Netz ein SYNC_REQ oder ein SYNC_ACK fallen lässt), wird ein SYNC_REQ später als erwartet angenommen. Danach sendet der Sender weniger Nachrichten als erwartet, bevor er den nächsten Fixpunkt feststellt. Der neue Fixpunkt ist nicht aktiviert worden, wobei der Sender das SYNC_REQ erneut senden muss. Dem Empfänger erscheint dies so, als ob der Sender nicht konform ist. Somit wird der nächste Fixpunkt aus Sicht des Senders verspätet angenommen. Dies hat die Wirkung, die zulässige Paketrate des Senders zu verringern, bis der Sender für eine Zeitdauer mit einer Paketrate unter der abgestimmten Rate sendet.

Um dem vorzubeugen, sollte der Empfänger die Zeiten verfolgen, zu denen die letzten C SYNC_REQs empfangen und angenommen wurden, wobei er das Minimum von M·N·W/R Sekunden, nachdem das letzte SYNC_REQ empfangen und angenommen worden ist, 2·M·N·W/R Sekunden, nachdem das vorletzte SYNC_REQ empfangen und angenommen worden ist, C·M·N·W/R Sekunden, nachdem das (C – 1)-te vor dem letzten SYNC_REQ empfangen worden ist, als die Zeit zum Aktivieren von CKPT_N verwendet. Dies verhindert, dass der Empfänger die Paketrate des Senders unangebracht begrenzt, falls wenigstens eines der letzten C SYNC_REQs im ersten Versuch verarbeitet wurde.
30 zeigt ein System, das die oben beschriebenen Prinzipien nutzt. In 30 ist angenommen worden, dass zwei Computer 3000 und 3001 in Übereinstimmung mit den oben beschriebenen "Sprung"-Prinzipien (z. B. gesprungene IP- Adressen, Diskriminatorwerte usw.) über ein Netz N kommunizieren. Obgleich natürlich der Vollduplexbetrieb betrachtet wird, wird der Einfachheit halber der Computer 3000 als der empfangende Computer und der Computer 3001 als der sendende Computer bezeichnet. Obgleich nur ein einziger Sender gezeigt ist, können darüber hinaus mehrere Sender zum Empfänger 3000 senden.
Wie oben beschrieben wurde, unterhält der empfangende Computer 3000 eine Empfangstabelle 3002, die ein Fenster W enthält, das gültige IP-Adressenpaare definiert, die angenommen werden, wenn sie in ankommenden Datenpaketen erscheinen. Der sendende Computer 3001 unterhält eine Sendetabelle 3003, aus der die nächsten IP-Adressenpaare ausgewählt werden, wenn ein Paket zum empfangenden Computer 3000 gesendet wird. (Zur Veranschaulichung ist das Fenster W in Bezug auf die Sendetabelle 3003 ebenfalls veranschaulicht.) Wie in der Funktion 3010 veranschaulicht ist, erzeugt der sendende Computer schließlich eine SYNC_REQ-Nachricht, während er sich durch seine Tabelle bewegt. Dies ist eine Anforderung an den Empfänger 3000, die Empfangstabelle 3002 zu synchronisieren, aus der der Sender 3001 eine Antwort in Form eines (als Teil einer SYNC_ACK-Nachricht enthaltenen) CKPT_N erwartet. Falls der sendende Computer 3001 mehr Nachrichten als seine Zuteilung sendet, erzeugt er die SYNC_REQ-Nachricht vorzeitig. (Falls er geändert wurde, um die SYNC_REQ-Nachrichten-Erzeugung insgesamt zu beseitigen, fällt er aus der Synchronisation, da der Empfänger 3000 Pakete, die außerhalb des Fensters W liegen, schnell zurückweist, wobei die durch den Sender 3001 erzeugten Zusatzpakete verworfen werden.)
Wie in 30 veranschaulicht ist, führt der empfangende Computer 3000 in Übereinstimmung mit den oben beschriebenen Verbesserungen bestimmte Schritte aus, wenn eine SYNC_REQ-Nachricht empfangen wird. In Schritt 3004 empfängt der empfangende Computer 3000 die SYNC_REQ-Nachricht. In Schritt 3005 wird eine Prüfung vorgenommen, um zu bestimmen, ob die Anforderung eine Kopie ist. Wenn das der Fall ist, wird sie in Schritt 3006 verworfen. In Schritt 3007 wird eine Prüfung vorgenommen, um zu bestimmen, ob das vom Sender 3001 empfangene SYNC_REQ mit einer Rate empfangen wurde, die die zulässige Rate R (d. h. die Zeitdauer zwischen der Zeit der letzten SYNC_REQ-Nachricht) übersteigt. Der Wert R kann eine Konstante sein oder es kann veranlasst werden, dass er wie gewünscht schwankt. Falls die Rate R übersteigt, wird die nächste Aktivierung des nächsten CKPT_N-Sprungtabelleneintrags in Schritt 3008 um WIR Sekunden, nachdem das letzte SYNC_REQ angenommen worden ist, verzögert.
Falls die Rate andernfalls nicht überschritten wurde, wird in Schritt 3109 vor dem nächsten SYNC_REQ vom Sender 3101 der nächste CKPT_N-Wert berechnet und in die Sprungtabelle des Empfängers eingefügt. Daraufhin verarbeitet der Sender 3101 das SYNC_REQ auf normale Weise.
E. Signalsynchronisationseinrichtung
In einem System, in dem eine große Anzahl von Anwendern unter Verwendung der sicheren Sprungtechnologie mit einem Zentralknoten kommunizieren, muss eine große Menge Speicher für die Sprungtabellen und ihre Unterstützungsdatenstrukturen eingeplant werden. Falls z. B. eine Million Abonnenten für eine Website gelegentlich mit der Website kommunizieren, muss die Site eine Million Sprungtabellen unterhalten, so dass wertvolle Computerbetriebsmittel verbraucht werden, obgleich zu irgendeiner gegebenen Zeit nur ein kleiner Prozentsatz der Anwender das System tatsächlich nutzen können. Eine erwünschte Lösung wäre ein System, das ermöglicht, dass eine bestimmte maximale Anzahl gleichzeitiger Verbindungen aufrechterhalten werden, das aber Millionen registrierter Anwender jederzeit "erkennen" würde. Mit anderen Worten, aus einer Bevölkerung von einer Million registrierter Anwender könnten zu einer Zeit wenige Tausend gleichzeitig mit einem Zentral-Server kommunizieren, ohne dass es erforderlich ist, dass der Server eine Million Sprungtabellen beträchtlicher Größe unterhält.
Eine Lösung ist, den Zentralknoten in zwei Knoten aufzuteilen: einen Signalisierungs-Server, der den Sitzungsbeginn für das An- und Abmelden der Anwender ausführt (und der nur minimal große Tabellen erfordert), und einen Transport-Server, der größere Sprungtabellen für die Anwender enthält. Der Signalisierungs-Server horcht auf die Millionen bekannter Anwender und führt eine schnelle Paketzurückweisung anderer (gefälschter) Pakete aus. Wenn ein Paket von einem bekannten Anwender empfangen wird, aktualisiert der Signalisierungs-Server eine virtuelle private Verbindung (VPL) zwischen dem Anwender und dem Transport-Server, wo Sprungtabellen zugeordnet und unterhalten werden. Wenn sich der Anwender bei dem Signalisierungs-Server anmeldet, werden Sprungtabellen für die Kommunikation mit dem Transport-Server zum Computer des Anwenders geliefert, so dass die VPL aktiviert wird. Die VPL können abgebaut werden, wenn sie für eine Zeitdauer inaktiv werden, oder können beim Abmelden des Anwenders abgebaut werden. Die Kommunikation mit dem Signalisierungs-Server, um das An- und Abmelden des Anwenders zu ermöglichen, kann unter Verwendung einer Spezialversion des oben beschriebenen Fixpunktschemas ausgeführt werden.
31 zeigt ein System, das bestimmte der oben beschriebenen Prinzipien nutzt. In 31 kommunizieren ein Signalisierungs-Server 3101 und ein Transport-Server 3102 über eine Verbindung. Der Signalisierungs-Server 3101 enthält eine große Anzahl kleiner Tabellen 3106 und 3107, die genug Informationen enthalten, um eine Kommunikationsanforderung mit einem oder mit mehreren Clients 3103 und 3104 zu authentisieren. Wie im Folgenden ausführlicher beschrieben wird, können diese kleinen Tabellen vorteilhaft als ein Spezialfall der zuvor beschriebenen Synchronisierfixpunkttabellen konstruiert sein. Der Transport-Server 3102, der vorzugsweise ein getrennter Computer in Kommunikation mit dem Signalisierungs-Server 3101 ist, enthält eine kleinere Anzahl größerer Sprungtabellen 3108, 3109 und 3110, die zugeordnet werden können, um mit einem der Client-Computer ein VPN zu erzeugen.
Gemäß einer Ausführungsform sendet ein Client, der sich zuvor (z. B. über eine Systemadministrationsfunktion, eine Anwenderregistrierungsprozedur oder ein anderes Verfahren) bei dem System registriert hat, eine Anforderung für Informationen von einem Computer (z. B. von einer Website). In einer Änderung erfolgt die Anforderung unter Verwendung eines "gesprungenen" Pakets, so dass der Signalisierungs-Server 3101 ungültige Pakete von unberechtigten Computern wie etwa von einem Hacker-Computer 3105 schnell zurückweist. Um sicherzustellen, dass ein Hacker den Signalisierungs-Server 3101 nicht mit gefälschten Paketen überfluten kann, kann zwischen allen Clients und dem Signalisierungs-Server ein "administratives" VPN aufgebaut werden. Einzelheiten dieses Schemas werden im Folgenden gegeben.
Der Signalisierungs-Server 3101 empfängt die Anforderung 3111 und verwendet sie, um zu bestimmen, dass der Client 3103 ein gültig registrierter Anwender ist. Nachfolgend gibt der Signalisierungs-Server 3101 an den Transport-Server 3102 eine Anforderung zum Zuordnen einer Sprungtabelle (oder eines Sprungalgorithmus oder eines anderen Regimes) aus, um ein VPN mit dem Client 3103 zu erzeugen. Die zugeordneten Sprungparameter werden zum Signalisierungs-Server 3101 zurückgegeben (Weg 3113), der die Sprungparameter daraufhin, vorzugsweise in verschlüsselter Form, über den Weg 3114 zum Client 3103 liefert.
Anschließend kommuniziert der Client 3103 unter Verwendung der normalen oben beschriebenen Sprungtechniken mit dem Transport-Server 3102. Obgleich der Signalisierungs-Server 3101 und der Transport-Server 3102 als zwei getrennte Computer veranschaulicht sind, ist klar, dass sie natürlich zu einem einzigen Computer kombiniert sein können und ihre Funktionen in dem einzigen Computer ausgeführt werden könnten. Alternativ ist es möglich, die in 31 gezeigten Funktionen anders als gezeigt aufzuteilen, ohne von den erfinderischen Prinzipien abzuweichen.
Ein Vorteil der oben beschriebenen Architektur ist, dass der Signalisierungs-Server 3101 nur eine kleine Menge an Informationen über eine große Anzahl potentieller Anwender zu unterhalten braucht, aber dennoch die Fähigkeit behält, Pakete von unberechtigten Anwendern wie etwa von dem Hacker-Computer 3105 schnell zurückzuweisen. Größere Datentabellen, die zum Ausführen der Sprung- und Synchronisationsfunktion benötigt werden, werden stattdessen in einem Transport-Server 3102 unterhalten, wobei eine kleinere Anzahl dieser Tabellen benötigt werden, da sie nur für "aktive" Verbindungen zugeordnet werden. Nachdem ein VPN für eine bestimmte Zeitdauer (z. B. eine Stunde) inaktiv geworden ist, kann das VPN durch den Transport-Server 3102 oder durch den Signalisierungs-Server 3101 automatisch abgebaut werden.
Es wird nun eine ausführlichere Beschreibung hinsichtlich dessen gegeben, wie ein Spezialfall des Fixpunkt-Synchronisationsmerkmals verwendet werden kann, um das oben beschriebene Signalisierungsschema zu realisieren.
Die Signalisierungssynchronisationseinrichtung kann erforderlich sein, um viele (Millionen) stehender Verbindungen mit niedriger Bandbreite zu unterstützen. Somit sollte sie die Speichernutzung pro VPL minimieren, während sie die durch die Sprungtechnologie gebotene Sicherheit bietet. Um die Speichernutzung in dem Signalisierungs-Server zu verringern, können die Datensprungtabellen vollständig beseitigt werden und die Daten als Teil der SYNC_REQ-Nachricht übermittelt werden. Die von der Server-Seite (Empfänger) und von der Client-Seite (Sender) verwendete Tabelle ist in 31 schematisch als Element 3106 gezeigt.
Abgesehen davon, dass CKPT_N eine kombinierte Daten- und SYNC_REQ-Nachricht oder eine SYNC_REQ-Nachricht ohne die Daten empfangen kann, bleiben die Bedeutung und die Verhalten von CKPT_N, CKPT_O und CKPT_R dieselben wie in der früheren Beschreibung.
Das Protokoll ist eine unkomplizierte Erweiterung der früheren Synchronisationseinrichtung. Es wird angenommen, dass ein Client-Sender eingeschaltet ist und die Tabellen synchronisiert sind. Die Anfangstabellen können "außerhalb des Bands" erzeugt werden. Zum Beispiel kann sich ein Client bei einem Web-Server anmelden, um über das Internet einen Account anzulegen. Der Client empfängt Schlüssel usw. verschlüsselt über das Internet. Inzwischen baut der Server das Signalisierungs-VPN an dem Signalisierungs-Server auf.
Es wird angenommen, dass eine Client-Anwendung auf der stehenden Signalisierungs-VPL des Clients ein Paket zu dem Server senden möchte:

1. Der Client sendet die Nachricht, die an dem inneren Anfangsblock als eine Datennachricht gekennzeichnet ist, unter Verwendung der CKPT_N-Adresse des Senders. Er schaltet den Sender aus und startet einen Zeitgeber T1, der CKPT_O notiert. Die Nachrichten können einer von drei Typen sein: Daten, SYNC_REQ und SYNC_ACK. In dem normalen Algorithmus können einige potentielle Probleme dadurch verhindert werden, dass jeder Nachrichtentyp als Teil des verschlüsselten inneren Anfangsblockfelds identifiziert wird. Da die Daten und das SYNC_REQ an derselben Adresse ankommen, ist es in diesem Algorithmus wichtig, ein Datenpaket und ein SYNC_REQ in der Signalisierungssynchronisationseinrichtung zu unterscheiden.
2. Wenn der Server auf sein CKPT_N eine Datennachricht empfängt, verifiziert er die Nachricht und übergibt sie in dem Stapel nach oben. Die Nachricht kann dadurch verifiziert werden, dass der Nachrichtentyp und andere in dem inneren Anfangsblock enthaltenen Informationen (z. B. Anwenderberechtigungen) geprüft werden. Er ersetzt sein CKPT_O durch CKPT_N und erzeugt das nächste CKPT_N. Er aktualisiert sein CKPT_R der Senderseite, damit es dem CKPT_R der Empfängerseite des Clients entspricht, und sendet ein SYNC_ACK, das in seiner Nutznachricht ein CKPT_O enthält.
3. Wenn der Empfänger auf der Client-Seite auf sein CKPT_R ein SYNC_ACK mit einer Nutznachricht empfängt, die an sein CKPT_O der Senderseite angepasst ist, und wenn der Sender ausgeschaltet ist, wird der Sender eingeschaltet und das CKPT_R der Empfängerseite aktualisiert. Falls die Nutznachricht des SYNC_ACK nicht an das CKPT_O der Senderseite angepasst ist oder der Sender eingeschaltet ist, wird das SYNC_ACK einfach verworfen.
4. T1 läuft ab: Falls der Sender ausgeschaltet ist und das CKPT_O der Senderseite des Clients an das dem Zeitgeber zugeordnete CKPT_O angepasst ist, startet er den Zeitgeber T1, wobei er wieder CKPT_O notiert und wobei unter Verwendung der CKPT_O-Adresse des Senders ein SYNC_REQ gesendet wird. Ansonsten wird keine Maßnahme ergriffen.
5. Wenn der Server auf sein CKPT_N ein SYNC_REQ empfängt, ersetzt er sein CKPT_O durch CKPT_N und erzeugt das nächste CKPT_N. Er aktualisiert sein CKPT_R der Senderseite, damit es dem CKPT_R der Empfängerseite des Clients entspricht, und sendet ein SYNC_ACK, das ein CKPT_O in seiner Nutznachricht enthält.
6. Wenn der Server auf sein CKPT_O ein SYNC_REQ empfängt, aktualisiert er sein CKPT_R der Senderseite, damit es dem CKPT_R der Empfängerseite des Clients entspricht, und sendet ein SYNC_ACK, das in seiner Nutznachricht ein CKPT_O enthält.

32 zeigt den Nachrichtenfluss, um das Protokoll hervorzuheben. Von oben nach unten gelesen, sendet der Client unter Verwendung seines CKPT_N der Senderseite Daten zu dem Server. Der Sender auf der Client-Seite ist ausgeschaltet und ein Wiederholungszeitgeber ist ausgeschaltet. Solange der Sender ausgeschaltet ist, sendet der Sender keine Nachrichten. Daraufhin lädt der Sender auf der Client-Seite CKPT_N in CKPT_O und aktualisiert CKPT_N. Diese Nachricht wird erfolgreich empfangen und in dem Stapel nach oben übergeben. Außerdem synchronisiert sie den Empfänger, d. h., der Server lädt CKPT_N in CKPT_O und erzeugt ein neues CKPT_N, er erzeugt ein neues CKPT_R in dem Sender auf der Server-Seite und sendet ein SYNC_ACK, das das CKPT_O des Empfängers auf der Server-Seite enthält, von dem Server. Das SYNC_ACK wird erfolgreich bei dem Client empfangen. Das CKPT_R des Empfängers auf der Client-Seite wird aktualisiert, der Sender wird eingeschaltet und der Wiederholungszeitgeber abgebrochen. Der Sender auf der Client-Seite ist zum Senden einer neuen Datennachricht bereit.
Nachfolgend sendet der Client unter Verwendung seines CKPT_N auf der Senderseite Daten zu dem Server. Der Sender auf der Client-Seite ist ausgeschaltet und ein Wiederholungszeitgeber ist ausgeschaltet. Solange der Sender ausgeschaltet ist, sendet der Sender keine Nachrichten. Daraufhin lädt der Sender auf der Client-Seite CKPT_N in CKPT_O und aktualisiert CKPT_N. Diese Nachricht ist verloren. Der Zeitgeber auf der Client-Seite läuft ab und im Ergebnis wird auf das CKPT_O des Senders auf der Client-Seite ein SYNC_REQ gesendet (dies geschieht weiter, bis das SYNC_ACK bei dem Client empfangen worden ist). Das SYNC_REQ wird erfolgreich bei dem Sender empfangen. Es synchronisiert den Empfänger, d. h., der Server lädt CKPT_N in CKPT_O und erzeugt ein neues CKPT_N, er erzeugt ein neues CKPT_R in dem Sender auf der Server-Seite und sendet ein SYNC_ACK, das das CKPT_O des Empfängers auf der Server-Seite enthält, von dem Server. Das SYNC_ACK wird erfolgreich bei dem Client empfangen. Das CKPT_R des Empfängers auf der Client-Seite wird aktualisiert, der Sender wird ausgeschaltet und der Wiederholungszeitgeber abgebrochen. Der Sender auf der Client-Seite ist zum Senden einer neuen Datennachricht bereit.
Es gibt zahlreiche weitere Szenarien, die diesem Ablauf folgen. Zum Beispiel könnte das SYNC_ACK verloren gehen. Der Sender würde das SYNC_REQ weiter erneut senden, bis der Empfänger synchronisiert und antwortet.
Die oben beschriebenen Prozeduren ermöglichen, dass sich ein Client beim Signalisierungs-Server 3201 authentisiert, während die Fähigkeit des Signalisierungs-Servers 3201 zum schnellen Zurückweisen ungültiger Pakete, wie sie durch den Hacker-Computer 3205 erzeugt werden könnten, aufrechterhalten wird. In verschiedenen Ausführungsformen ist die Signalisierungssynchronisationseinrichtung tatsächlich eine Ableitung der Synchronisationseinrichtung. Sie bietet denselben Schutz wie das Sprungprotokoll und tut dies für eine große Anzahl von Verbindungen mit niedriger Bandbreite.
F. Sichere Ein-Klick-Online-Kommunikation und Dienst für sichere Domänennamen
Die vorliegende Erfindung schafft eine Technik für den Aufbau einer sicheren Kommunikationsverbindung zwischen einem ersten Computer und einem zweiten Computer über ein Computernetz. Vorzugsweise gibt ein Anwender eine sichere Kommunikationsverbindung unter Verwendung eines einzigen Klicks einer Maus oder einer entsprechenden minimalen Eingabe von einer anderen Eingabevorrichtung wie etwa eines in eine Tastatur eingegebenen Tastendrucks oder eines über einen Trackball eingegebenen Klicks frei. Alternativ wird die sichere Verbindung als Standardeinstellung beim Urladen des Computers aufgebaut (d. h. kein Klick). 33 zeigt einen Systemblockschaltplan 3300 eines Computernetzes, in dem das sichere Ein-Klick-Kommunikationsverfahren der vorliegenden Erfindung geeignet ist. In 33 ist ein Computerendgerät oder Client-Computer 3301 wie etwa ein Personal-Computer (PC) über einen ISP 3303 mit einem Computernetz 3302 wie etwa dem Internet verbunden. Alternativ kann der Computer 3301 über einen Kanten-Router mit dem Computernetz 3302 verbunden sein. Der Computer 3301 enthält eine Eingabevorrichtung wie etwa eine Tastatur und/oder eine Maus und eine Anzeigevorrichtung wie etwa einen Monitor. Der Computer 3301 kann unter Verwendung eines Browser 3306, der auf gut bekannte Weise auf dem Computer 3301 installiert ist und arbeitet, über eine Kommunikationsverbindung 3305 herkömmlich mit einem weiteren mit dem Computernetz 3302 verbundenen Computer 3304 kommunizieren.
Der Computer 3304 kann z. B. ein Server-Computer sein, der für die Durchführung von E-Commerce verwendet wird. In der Situation, wenn das Computernetz 3302 das Internet ist, hat der Computer 3304 typisch einen Standard-Top-Level-Domänennamen wie etwa .com, .net, .org, .edu, .mil oder .gov.
34 zeigt einen Ablaufplan 3400 für die Installation und für den Aufbau einer sicheren "Ein-Klick"-Kommunikationsverbindung über ein Computernetz gemäß der vorliegenden Erfindung. In Schritt 3401 wird der Computer 3301 über eine Nicht-VPN-Kommunikationsverbindung 3305 mit dem Server-Computer 3304 verbunden. Der Web-Browser 3306 zeigt auf gut bekannte Weise eine Web-Seite an, die dem Server 3304 zugeordnet ist. Gemäß einer Änderung der Erfindung enthält die Anzeige des Computers 3301 einen Hyperlink oder ein Symbol, das einen Hyperlink repräsentiert, um eine Kommunikationsverbindung eines virtuellen privaten Netzes (VPN-Kommunikationsverbindung) über das Computernetz 3302 zwischen dem Endgerät 3301 und dem Server 3304 auszuwählen ("Gehe-sicher"-Hyperlink). Vorzugsweise wird der "Gehe-sicher"-Hyperlink als Teil der vom Server-Computer 3304 heruntergeladenen Web-Seite angezeigt, wodurch angegeben wird, dass die Entität, die den Server 3304 bereitstellt, ebenfalls eine VPN-Fähigkeit bereitstellt.
Durch Anzeige des "Gehe-sicher"-Hyperlinks wird ein Anwender beim Computer 3301 informiert, dass die momentane Kommunikationsverbindung zwischen dem Computer 3301 und dem Server-Computer 3304 eine nicht sichere Nicht-VPN-Kommunikationsverbindung ist. In Schritt 3402 wird bestimmt, ob ein Anwender des Computers 3301 einen "Gehe-sicher"-Hyperlink ausgewählt hat. Wenn das nicht der Fall ist, wird die Verarbeitung unter Verwendung eines nicht sicheren (herkömmlichen) Kommunikationsverfahrens wieder aufgenommen (nicht gezeigt). Wenn es der Fall ist, wird in Schritt 3402 bestimmt, dass der Anwender den "Gehe-sicher"-Hyperlink ausgewählt hat, wobei der Ablauf in Schritt 3403 fortgesetzt wird, wo ein dem Hyperlink zugeordnetes Objekt bestimmt, ob auf dem Computer 3301 bereits ein VPN-Kommunikations-Software-Modul installiert worden ist. Alternativ kann ein Anwender in den Computer 3301 einen Befehl eingeben, um "sicherzugehen".
Falls das Objekt in Schritt 3403 bestimmt, dass das Software-Modul installiert worden ist, wird der Ablauf in Schritt 3407 fortgesetzt. Falls das Objekt in Schritt 3403 bestimmt, dass das Software-Modul nicht installiert worden ist, wird der Ablauf in Schritt 3404 fortgesetzt, wo zwischen dem Computer 3301 und einer Website 3308 über das Computernetz 3302 auf gut bekannte Weise eine Nicht-VPN-Kommunikationsverbindung 3307 gestartet wird. Die Website 3308 ist durch alle mit dem Computernetz 3302 verbundenen Computer-Endgeräte über eine Nicht-VPN-Kommunikationsverbindung benutzbar. Nach Verbinden mit der Website 3308 kann ein Software-Modul für das Aufbauen einer sicheren Kommunikationsverbindung über das Computernetz 3302 heruntergeladen und installiert werden. Der Ablauf wird in Schritt 3405 fortgesetzt, wo das Software-Modul zum Aufbauen einer Kommunikationsverbindung, nachdem sich der Computer 3301 mit der Website 3308 verbunden hat, auf gut bekannte Weise heruntergeladen und als Software-Modul 3309 auf dem Computerendgerät 3301 installiert wird. In Schritt 3405 kann ein Anwender optional Parameter für das Software-Modul auswählen und etwa für alle Kommunikationsverbindungen über das Computernetz 3302 eine Kommunikationsbetriebsart der sicheren Kommunikationsverbindung aufbauen. In Schritt 3406 wird die Kommunikationsverbindung zwischen dem Computer 3301 und der Website 3308 auf gut bekannte Weise abgeschlossen.
Ein Anwender am Computer 3301 hat durch Klicken auf den "Gehe-sicher"-Hyperlink eine Kommunikationsbetriebsart der sicheren Kommunikation zwischen dem Computer 3301 und dem Server-Computer 3304 aufgebaut. Gemäß einer Variante der Erfindung braucht der Anwender nicht mehr zu tun, als lediglich auf den "Gehe-sicher"-Hyperlink zu klicken. Der Anwender braucht keine Anwenderidentifizierungsinformationen, Kennwörter oder Verschlüsselungsschlüssel einzugeben, um eine sichere Kommunikationsverbindung aufzubauen. Alle Prozeduren, die für das Aufbauen einer sicheren Kommunikationsverbindung zwischen dem Computer 3301 und dem Server-Computer 3304 erforderlich sind, werden transparent für einen Anwender am Computer 3301 ausgeführt.
In Schritt 3407 ist eine sichere VPN-Kommunikationsbetriebsart aufgebaut worden, wobei das Software-Modul 3309 eine VPN-Kommunikationsverbindung aufzubauen beginnt. In einer Ausführungsform ersetzt das Software-Modul 3309 automatisch den Top-Level-Domänennamen für den Server 3304 im Browser 3406 durch einen sicheren Top-Level-Domänennamen für den Server-Computer 3304. Falls der Top-Level-Domänenname für den Server 3304 z. B. .com ist, ersetzt das Software-Modul 3309 den Top-Level-Domänennamen .com durch einen Top-Level-Domänennamen .scom, wobei "s" sicher bedeutet. Alternativ kann das Software-Modul 3409 den Top-Level-Domänennamen des Servers 3304 durch irgendeinen anderen Nicht-Standard-Top-Level-Domänennamen ersetzen.
Da der sichere Top-Level-Domänenname ein Nicht-Standard-Domänenname ist, gibt eine Abfrage zu einem Standard-Domänennamendienst (DNS) eine Nachricht zurück, die angibt, dass der Universal Resource Locator (die URL) unbekannt ist. Gemäß der Erfindung enthält das Software-Modul 3409 die URL zum Abfragen eines Dienstes für sichere Domänennamen (SDNS), um die URL für einen sicheren Top-Level-Domänennamen zu erhalten. Diesbezüglich greift das Software-Modul 3309 auf ein sicheres Portal 3310 zu, das ein sicheres Netz 3311 mit dem Computernetz 3302 verbindet. Das sichere Netz 3311 enthält einen internen Router 3312, einen Dienst für sichere Domänennamen (SDNS) 3313, einen VPN-Pförtner 3314 und einen sicheren Proxy 3315. Das sichere Netz kann weitere Netzdienste wie etwa E-Mail 3316, mehrere Chat-Räume (von denen nur ein Chat-Raum 3317 gezeigt ist) und einen Dienst für Standard-Domänennamen (STD DNS) 3318 enthalten. Natürlich kann das sichere Netz 3311 weitere Betriebsmittel und Dienste enthalten, die in 33 nicht gezeigt sind.
Wenn das Software-Modul 3309 den Standard-Top-Level-Domänennamen für den Server 3304 durch den sicheren Top-Level-Domänennamen ersetzt, sendet das Software-Modul 3309 in Schritt 3408 über das sichere Portal 3310 vorzugsweise unter Verwendung einer Kommunikationsverbindung 3319 des administrativen VPN eine Abfrage zu dem SDNS 3313. In dieser Konfiguration kann auf das sichere Portal 3310 nur unter Verwendung einer VPN-Kommunikationsverbindung zugegriffen werden. Vorzugsweise kann diese VPN-Kommunikationsverbindung auf einer Technik des Einfügens eines Quell- und Ziel-IP-Adressenpaars in jedes Datenpaket, das gemäß einer Pseudo-Zufallsfolge ausgewählt wird; auf einem IP-Adressensprungregime, das pseudo-zufällig IP-Adressen in zwischen einem Client-Computer und einem sicheren Zielcomputer übertragenen Paketen ändert; auf dem periodischen Ändern wenigstens eines Felds in einer Reihe von Datenpaketen gemäß einer bekannten Folge; auf einer Internet-Protokoll-Adresse (IP-Adresse) in einem Anfangsblock jedes Datenpakets, die mit einer Tabelle gültiger IP-Adressen verglichen wird, die in einer Tabelle in dem zweiten Computer unterhalten werden; und auf einem Vergleich der IP-Adresse in dem Anfangsblock jedes Datenpakets mit einem sich bewegenden Fenster gültiger IP-Adressen und dem Zurückweisen von Datenpaketen mit IP-Adressen, die nicht in dem sich bewegenden Fenster liegen, beruhen. Alternativ können andere Typen von VPNs verwendet werden. Das sichere Portal 3310 authentisiert die Abfrage vom Software-Modul 3309 anhand der besonderen für die VPN-Kommunikationsverbindung 3319 verwendeten Informationssprungtechnik.
Der SDNS 3313 enthält eine Querverweisdatenbank sicherer Domänennamen und entsprechender sicherer Netzadressen. Das heißt, der SDNS 3313 speichert für jeden sicheren Domänennamen eine Computernetzadresse, die dem sicheren Domänennamen entspricht. Eine Entität kann einen sicheren Domänennamen im SDNS 3313 registrieren, so dass ein Anwender, der eine sichere Kommunikationsverbindung zu der Website der Entität wünscht, automatisch die sichere Computernetzadresse für die sichere Website erhalten kann. Darüber hinaus kann eine Entität mehrere sichere Domänennamen registrieren, wobei jeder jeweilige sichere Domänenname eine Zugriffsebene anderer Priorität in einer Hierarchie von Zugriffsebenen auf eine sichere Website repräsentiert. Zum Beispiel kann eine Wertpapierhandels-Website Anwendern einen sicheren Zugang bereitstellen, so dass ein Dienstverweigerungsangriff auf die Website in Bezug auf Anwender, die den Dienst der sicheren Website abonnieren, unwirksam ist. Auf der Grundlage einer sich erhöhenden Gebühr können z. B. verschiedene Abonnementniveaus so beschaffen sein, dass ein Anwender ein gewünschtes Garantieniveau für das Verbinden mit der sicheren Wertpapierhandels-Website auswählen kann.
Wenn ein Anwender den SDNS 3313 für die sichere Computernetzadresse für die Wertpapierhandels-Website abfragt, bestimmt der SDNS 3313 anhand der Identität des Anwenders und der Abonnementebene des Anwenders die besondere sichere Computernetzadresse.
In Schritt 3409 greift der SDNS 3313 auf den VPN-Pförtner 3314 zu, um zwischen dem Software-Modul 3309 und dem sicheren Server 3320 eine VPN-Kommunikationsverbindung aufzubauen. Auf den Server 3320 kann nur über eine VPN-Kommunikationsverbindung zugegriffen werden. Der VPN-Pförtner 3314 beliefert den Computer 3301 und den sicheren Web-Server-Computer 3320 oder einen sicheren Kanten-Router für den Server-Computer 3320 und erzeugt dadurch das VPN. Der sichere Server-Computer 3320 kann ein vom Server-Computer 3304 getrennter Server-Computer sein oder kann derselbe Server-Computer sein, der, wie etwa durch den Server-Computer 3322 gezeigt ist, sowohl Nicht-VPN- als auch VPN-Kommunikationsverbindungsfähigkeit besitzt. Wieder anhand von 34 gibt der SDNS 3313 in Schritt 3410 für die Server-Adresse .scom für einen sicheren Server 3320, der dem Server 3304 entspricht, eine sichere URL an das Software-Modul 3309 zurück.
Alternativ kann auf den SDNS 3313 über das sichere Portal 3310 "klar", d. h., ohne eine Kommunikationsverbindung eines administrativen VPN zu verwenden, zugegriffen werden. In dieser Situation authentisiert das sichere Portal 3310 vorzugsweise die Abfrage unter Verwendung irgendeiner gut bekannten Technik wie etwa einer kryptographischen Technik, bevor es zulässt, dass die Abfrage zum SDNS 3319 fortfährt. Da die Anfangskommunikationsverbindung in dieser Situation keine VPN-Kommunikationsverbindung ist, kann die Antwort auf die Abfrage "klar" sein. Der abfragende Computer kann die Klar-Antwort zum Aufbauen einer VPN-Verbindung zu dem gewünschten Domänennamen verwenden. Alternativ kann die Abfrage zum SDNS 3313 klar sein und können der SDNS 3313 und der Pförtner 3314 so arbeiten, dass sie eine VPN-Kommunikationsverbindung zu dem abfragenden Computer aufbauen, um die Antwort zu senden.
In Schritt 3411 greift das Software-Modul 3309 anhand der durch den VPN-Pförtner 3314 zugeordneten VPN-Betriebsmittel über die VPN-Kommunikationsverbindung 3321 auf den sicheren Server 3320 zu. In Schritt 3412 zeigt der Web-Browser 3306 ein Sicher-Symbol an, das angibt, dass die momentane Kommunikationsverbindung zum Server 3320 eine sichere VPN-Kommunikationsverbin dung ist. Ferner findet die Kommunikation zwischen den Computern 3301 und 3320 über das VPN z. B. unter Verwendung eines wie oben diskutierten "Sprung"-Regimes statt. Wenn die VPN-Verbindung 3321 in Schritt 3413 abgeschlossen wird, wird der Ablauf in Schritt 3414 fortgesetzt, wo das Software-Modul 3309 den sicheren Top-Level-Domänennamen automatisch durch einen entsprechenden nicht sicheren Top-Level-Domänennamen für den Server 3304 ersetzt. Der Browser 3306 greift auf einen Standard-DNS 3325 zu, um die nicht sichere URL für den Server 3304 zu erhalten. Daraufhin verbindet sich der Browser 3306 auf gut bekannte Weise mit dem Server 3304. In Schritt 3415 zeigt der Browser 3306 den "Gehe-sicher"-Hyperlink oder das "Gehe-sicher"-Symbol für die Auswahl einer VPN-Kommunikationsverbindung zwischen dem Endgerät 3301 und dem Server 3304 an. Dadurch, dass der "Gehe-sicher"-Hyperlink erneut angezeigt wird, wird ein Anwender informiert, dass die momentane Kommunikationsverbindung eine nicht sichere Nicht-VPN-Kommunikationsverbindung ist.
Wenn das Software-Modul 3309 installiert wird oder wenn der Anwender offline ist, kann der Anwender optional spezifizieren, dass alle über das Computernetz 3302 aufgebauten Kommunikationsverbindungen sichere Kommunikationsverbindungen sind. Somit ist jedes Mal, wenn eine Kommunikationsverbindung aufgebaut wird, die Verbindung eine VPN-Verbindung. Folglich greift das Software-Modul 3309 transparent auf den SDNS 3313 zu, um die URL für eine ausgewählte sichere Website zu erhalten. Mit anderen Worten, in einer Ausführungsform braucht der Anwender nicht jedes Mal, wenn eine sichere Kommunikation bewirkt werden soll, auf die Sicher-Option zu "klicken".
Zusätzlich kann ein Anwender beim Computer 3301 optional eine sichere Kommunikationsverbindung über den Proxy-Computer 3315 auswählen. Dementsprechend kann der Computer 3301 über den Proxy-Computer 3315 eine VPN-Kommunikationsverbindung 3323 mit dem sicheren Server-Computer 3320 aufbauen. Alternativ kann der Computer 3301 eine Nicht-VPN-Kommunikationsverbindung 3324 zu einer nicht sicheren Website wie etwa zu einem nicht sicheren Server-Computer 3304 aufbauen.
35 zeigt einen Ablaufplan 3500 zum Registrieren eines sicheren Domänennamens gemäß der vorliegenden Erfindung. In Schritt 3501 greift ein Anforderer auf die Website 3308 zu und meldet sich bei einem Registrierungsdienst für sichere Domänennamen an, der über die Website 3308 verfügbar ist. In Schritt 3502 füllt der Anforderer ein Online-Registrierungsformular zum Registrieren eines sicheren Domänennamens mit einem Top-Level-Domänennamen wie etwa .com, .net, .org, .edu, .mil oder .gov aus. Natürlich können andere sichere Top-Level-Domänennamen ebenfalls verwendet werden. Vorzugsweise muss der Anforderer zuvor einen nicht sicheren Domänennamen registriert haben, der dem äquivalenten sicheren Domänennamen, der angefordert wird, entspricht. Zum Beispiel muss ein Anforderer, der den sicheren Domänennamen "website.scom" zu registrieren versucht, zuvor den entsprechenden nicht sicheren Domänennamen "website.com" registriert haben.
In Schritt 3503 fragt der Registrierungsdienst für sichere Domänenamen bei der Website 3308 z. B. unter Verwendung einer Whois-Abfrage eine Server-Datenbank für nicht sichere Domänennamen wie etwa den Standard-DNS 3322 ab, um Eigentümerinformationen in Bezug auf den nicht sicheren Domänennamen, der dem angeforderten sicheren Domänennamen entspricht, zu bestimmen. In Schritt 3504 empfängt der Registrierungsdienst für sichere Domänennamen bei der Website 3308 eine Antwort vom Standard-DNS 3322, wobei er in Schritt 3505 bestimmt, ob es für den entsprechenden nicht sicheren Domänennamen widersprechende Eigentümerinformationen gibt. Falls es keine widersprechenden Eigentümerinformationen gibt, wird der Ablauf in Schritt 3507 fortgesetzt, während der Ablauf andernfalls zu Schritt 3506 übergeht, wo der Anforderer über die widersprechenden Eigentümerinformationen informiert wird. Der Ablauf kehrt zu Schritt 3502 zurück.
Wenn es in Schritt 3505 keine widersprechenden Eigentümerinformationen gibt, informiert der Registrierungsdienst für sichere Domänennamen (Website 3308) den Anforderer, dass es keine widersprechenden Eigentümerinformationen gibt, und fordert den Anforderer auf, die in das Onlineformular eingegebenen Informationen zu verifizieren und eine genehmigte Zahlungsform auszuwählen. Nach Bestätigung der eingegebenen Informationen und geeigneter Zahlungsinformationen wird der Ablauf in Schritt 3508 fortgesetzt, wo der neu registrierte sichere Domänenname über die Kommunikationsverbindung 3326 zum SDNS 3313 gesendet wird.
Falls der angeforderte sichere Domänenname in Schritt 3505 keinen entsprechenden äquivalenten nicht sicheren Domänennamen besitzt, informiert die vorliegende Erfindung den Anforderer über die Situation und fordert den Anforde rer auf, den entsprechenden äquivalenten nicht sicheren Domänennamen für eine erhöhte Gebühr zu erwerben. Durch Annahme des Angebots registriert die vorliegende Erfindung den entsprechenden äquivalenten nicht sicheren Domänennamen automatisch auf gut bekannte Weise beim Standard-DNS 3325. Daraufhin wird der Ablauf in Schritt 3508 fortgesetzt.
G. Sicheres Tunnel-Adressensprungprotokoll über vorhandenes Protokoll unter Verwendung eines Web-Proxy
Außerdem schafft die vorliegende Erfindung eine Technik zur Realisierung der oben beschriebenen Feldsprungschemata in einem Anwendungsprogramm auf der Client-Seite einer Firewall zwischen zwei Computernetzen und in dem Netzstapel auf der Server-Seite der Firewall. Die vorliegende Erfindung verwendet ein neues sicheres verbindungsloses Protokoll, das durch Schichtung des neuen Protokolls über ein vorhandenes IP-Protokoll wie etwa das ICMP-, das UDP- oder das TCP-Protokoll gute Dienstverweigerungs-Zurückweisungsfähigkeiten schafft. Somit erfordert dieser Aspekt der vorliegenden Erfindung keine Änderungen an der Internet-Infrastruktur.
Gemäß der Erfindung wird die Kommunikation durch ein Proxy-Anwendungsprogramm auf der Client-Seite geschützt, das unverschlüsselte, ungeschützte Kommunikationspakete von einer lokalen Browser-Anwendung annimmt. Das Proxy-Anwendungsprogramm auf der Client-Seite tunnelt die unverschlüsselten, ungeschützten Kommunikationspakete durch ein neues Protokoll, wodurch die Kommunikation vor einer Dienstverweigerung auf der Server-Seite geschützt wird. Natürlich können die unverschlüsselten, ungeschützten Kommunikationspakete vor dem Tunneln verschlüsselt werden.
Das Proxy-Anwendungsprogramm auf der Client-Seite ist keine Betriebssystemerweiterung und umfasst keine Änderungen an dem Betriebssystem-Netzstapel und an den Treibern. Folglich ist der Client im Vergleich zu einem VPN leichter zu installieren, zu entfernen und zu unterstützen. Darüber hinaus kann die Proxy-Anwendung auf der Client-Seite durch eine Unternehmens-Firewall unter Verwendung eines viel kleineren "Lochs" in der Firewall zugelassen werden und ist zum Vergleich zum Zulassen eines Protokollschicht-VPN durch eine Unternehmens-Firewall ein niedrigeres Sicherheitsrisiko.
Die Realisierung der vorliegenden Erfindung auf der Server-Seite authentisiert gültige Pakete mit, gesprungenen Feldern ähnlich einem virtuellen privaten Standardnetz sehr früh in der Server-Paketverarbeitung als gültig oder ungültig, um die Auswirkung eines Dienstverweigerungsversuchs im Vergleich zur normalen TCP/IP- und HTTP-Kommunikation stark zu minimieren und dadurch den Server vor ungültiger Kommunikation zu schützen.
36 zeigt einen Systemblockschaltplan eines Computernetzes 3600, in dem eine virtuelle private Verbindung gemäß der vorliegenden Erfindung so konfiguriert werden kann, dass eine Firewall zwischen zwei Computernetzen leichter durchlaufen wird. 37 zeigt einen Ablaufplan 3700 für den Aufbau einer virtuellen privaten Verbindung, die unter Verwendung eines vorhandenen Netzprotokolls gekapselt ist.
In 36 ist ein lokales Netz (LAN) 3601 über eine Firewall-Anordnung 3603 mit einem weiteren Computernetz 3602 wie etwa dem Internet verbunden. Die Firewall-Anordnung arbeitet auf gut bekannte Weise so, dass sie das LAN 3601 mit dem Computernetz 3602 verbindet und das LAN 3601 vor außerhalb des LAN 3601 ausgelösten Angriffen schützt.
Mit dem LAN 3601 ist auf gut bekannt Weise ein Client-Computer 3604 verbunden. Der Client-Computer 3604 enthält ein Betriebssystem 3605 und einen Web-Browser 3606. Das Betriebssystem 3605 stellt Kernel-Betriebsartfunktionen für den Betrieb des Client-Computers 3604 bereit. Der Browser 3606 ist ein Anwendungsprogramm, das auf gut bekannte Weise auf mit dem LAN 3601 und mit dem Computernetz 3602 verbundene Computernetzbetriebsmittel zugreift. Gemäß der vorliegenden Erfindung ist im Client-Computer 3604 außerdem eine Proxy-Anwendung 3607 gespeichert, die in einer Anwendungsschicht mit dem Browser 3606 zusammenarbeitet. Die Proxy-Anwendung 3607 arbeitet als eine Anwendungsschicht im Client-Computer 3604, wobei sie dann, wenn sie freigegeben ist, ungeschützte, unverschlüsselte Nachrichtenpakete, die durch den Browser 3606 erzeugt werden, ändert, indem sie in die Nachrichtenpakete Daten einfügt, die zum Bilden einer virtuellen privaten Verbindung zwischen dem Client-Computer 3604 und einem mit dem LAN 3601 oder mit dem Computernetz 3602 verbundenen Server-Computer verwendet werden. Gemäß der Erfindung schafft eine virtuelle private Verbindung für den Client-Computer nicht das gleiche Sicherheitsniveau wie ein virtuelles privates Netz. Eine virtuelle private Verbindung kann zweckmäßig authentisiert werden, so dass z. B. ein Dienstverweigerungsangriff schnell zurückgewiesen werden kann, wodurch verschiedene Dienstniveaus bereitgestellt werden, die ein Anwender abonnieren kann.
Da die Proxy-Anwendung 3607 in der Anwendungsschicht im Client-Computer 3604 arbeitet, wird die Proxy-Anwendung 3607 zweckmäßig durch einen Anwender installiert und deinstalliert. Bei der Installation konfiguriert die Proxy-Anwendung 3607 den Browser 3606 zweckmäßig so, dass die Proxy-Anwendung für die gesamte Web-Kommunikation verwendet wird. Das heißt, der Nutznachrichtenabschnitt aller Nachrichtenpakete wird mit den Daten zum Bilden einer virtuellen privaten Verbindung zwischen dem Client-Computer 3604 und einem Server-Computer geändert. Vorzugsweise enthalten die Daten zum Bilden der virtuellen privaten Verbindung Feldsprungdaten, wie sie oben in Verbindung mit VPNs beschrieben worden sind. Außerdem sind die geänderten Nachrichtenpakete vorzugsweise konform zu dem UDP-Protokoll. Alternativ können die geänderten Nachrichtenpakete konform zu dem TCP/IP-Protokoll oder zu dem ICMP-Protokoll sein. Alternativ kann die Proxy-Anwendung 3606 z. B. über eine durch den Browser 3606 bereitgestellte Option ausgewählt und freigegeben werden. Zusätzlich kann die Proxy-Anwendung 3607 so freigegeben werden, dass nur der Nutznachrichtenabschnitt speziell konstruierter Nachrichtenpakete mit den Daten zum Bilden einer virtuellen privaten Verbindung zwischen dem Client-Computer 3604 und einem bestimmten Host-Computer geändert wird. Die speziell konstruierten Nachrichtenpakete können z. B. ausgewählte vorgegebene Domänennamen sein.
Wie in 37 gezeigt ist, werden in Schritt 3701 durch den Browser 3606 ungeschützte und unverschlüsselte Nachrichtenpakete erzeugt. In Schritt 3702 ändert die Proxy-Anwendung 3607 den Nutznachrichtenabschnitt aller Nachrichtenpakete, indem sie die Daten zum Bilden einer virtuellen privaten Verbindung zwischen dem Client-Computer 3604 und einem Ziel-Server-Computer in den Nutznachrichtenabschnitt tunnelt. In Schritt 3703 werden die geänderten Nachrichtenpakete über das vom Client-Computer 3604 über das Computernetz 3602 z. B. zur Website (zum Server-Computer) 3608 gesendet.
Die Website 3608 enthält einen VPN-Schutzabschnitt 3609, einen Server-Proxy-Abschnitt 3610 und einen Web-Server-Abschnitt 3611. Der VPN-Schutzabschnitt 3609 ist in die Kernel-Schicht des Betriebssystems der Website 3608 eingebettet, so dass Angriffe großer Bandbreite auf die Website 3608 schnell zurückgewiesen werden. Wenn der Client-Computer 3604 eine authentisierte Verbindung zur Website 3608 beginnt, wird der VPN-Schutzabschnitt 3609 in Schritt 3704 mit der in den Nachrichtenpaketen vom Client-Computer 3604 enthaltenen Sprungfolge verschlüsselt, wodurch eine starke Authentisierung der in die Website 3608 eintretenden Client-Paketströme ausgeführt wird. Der VPN-Schutzabschnitt 3609 kann so konfiguriert werden, dass er je nach einem abonnierten Dienstniveau verschiedene Authentisierungsniveaus und folglich Dienstqualitätsniveaus bereitstellt. Das heißt, der VPN-Schutzabschnitt 3609 kann so konfiguriert werden, dass er alle Nachrichtenpakete durchlässt, bis ein Dienstverweigerungsangriff erfasst wird, wobei der VPN-Schutzabschnitt 3609 in diesem Fall nur Client-Paketströmen, die zu einer verschlüsselten Sprungfolge wie etwa der der vorliegenden Erfindung konform sind, zulässt.
Außerdem arbeitet der Server-Proxy-Abschnitt 3610 in der Kernel-Schicht in der Website 3608, wobei er ankommende Nachrichtenpakete vom Client-Computer 3604 auf der VPN-Ebene fängt. In Schritt 3705 authentisiert der Server-Proxy-Abschnitt 3610 die Nachrichtenpakete auf der Kernel-Ebene im Host-Computer 3604 unter Verwendung der Ziel-IP-Adressen-, UDP-Ports- und Diskriminatorfelder. Daraufhin werden die authentisierten Nachrichtenpakete als normale TCP-Web-Transaktionen zu den authentisierten Nachrichtenpaketen zum Web-Server-Abschnitt 3611 weitergeleitet.
In Schritt 3705 antwortet der Web-Server-Abschnitt 3611 auf vom Client-Computer 3604 empfangene Nachrichtenpakete in Übereinstimmung mit dem besonderen Wesen der Nachrichtenpakete, indem er Antwortnachrichtenpakete erzeugt. Wenn z. B. ein Client-Computer eine Web-Seite anfordert, erzeugt der Server-Abschnitt 3611 Nachrichtenpakete, die der angeforderten Web-Seite entsprechen. In Schritt 3706 gehen die Antwortnachrichtenpakete durch den Server-Proxy-Abschnitt 3610, der in den Nutznachrichtenabschnitt der Nachrichtenpakete Daten einfügt, die zum Bilden der virtuellen privaten Verbindung zwischen dem Host-Computer 3608 und dem Client-Computer 3604 über das Computernetz 3602 verwendet werden. Vorzugsweise enthalten die Daten zum Bilden der virtuellen privaten Verbindung Feldsprungdaten wie etwa die oben in Verbindung mit VPNs beschriebenen. Der Server-Proxy-Abschnitt 3610 arbeitet in der Kernel-Schicht im Host-Computer 3608, um die Daten der virtuellen privaten Verbindung in den Nutznachrichtenabschnitt der Antwortnachrichtenpakete einzufügen. Vorzugs weise sind die durch den Host-Computer 3608 zum Client-Computer 3604 gesendeten geänderten Nachrichtenpakete konform zu dem UDP-Protokoll. Alternativ können die geänderten Nachrichtenpakete konform zu dem TCP/IP-Protokoll oder zu dem ICMP-Protokoll sein.
In Schritt 3707 werden die geänderten Pakete vom Host-Computer 3608 über das Computernetz 3602 gesendet und gehen durch die Firewall 3603. Wenn sie durch die Firewall 3603 durch sind, werden die geänderten Pakete über das LAN 3601 zum Client-Computer 3604 gelenkt und in Schritt 3708 durch die Proxy-Anwendung 3607 in der Anwendungsschicht im Client-Computer 3604 empfangen. Die Proxy-Anwendung 3607 arbeitet so, dass sie die geänderten Nachrichtenpakete schnell bewertet, um zu bestimmen, ob die empfangenen Pakete angenommen oder fallengelassen werden sollten. Falls die in die empfangenen Informationspakete eingefügten Daten der virtuellen privaten Verbindung zu den erwarteten Daten der virtuellen privaten Verbindung konform sind, werden die empfangenen Pakete angenommen. Andernfalls werden die empfangenen Pakete fallengelassen.

Claims

Verfahren zum Registrieren eines sicheren Domänennamens, das die folgenden Schritte umfasst: Empfangen einer Anforderung (3501) zum Registrieren eines sicheren Domänennamens, wobei das Verfahren dadurch gekennzeichnet ist, dass es ferner die folgenden Schritte umfasst: Verifizieren (3507) von Eigentümerinformationen für einen äquivalenten nicht sicheren Domänennamen, der dem sicheren Domänennamen entspricht; Registrieren des sicheren Domänennamens (3508) in einem Dienst für sichere Domänennamen, wenn die Eigentümerinformationen für den äquivalenten nicht sicheren Domänennamen mit den Eigentümerinformationen für den sicheren Domänennamen übereinstimmen.
Verfahren nach Anspruch 1, bei dem der Schritt des Verifizierens von Eigentümerinformationen die folgenden Schritte umfasst: Bestimmen (3505), ob der dem sicheren Domänennamen entsprechende äquivalente nicht sichere Domänenname in einem Dienst für nicht sichere Domänennamen registriert worden ist, und Abfragen (3503), ob der äquivalente nicht sichere Domänenname in dem Dienst für nicht sichere Domänennamen registriert werden sollte, wenn der äquivalente nicht sichere Domänenname nicht in dem Dienst für nicht sichere Domänennamen registriert worden ist.
Computerlesbares Speichermedium, das umfasst: einen Speicherbereich und computerlesbare Befehle für ein Verfahren zum Registrieren eines sicheren Domänennamens, wobei das Verfahren die folgenden Schritte umfasst: Empfangen (3501) einer Anforderung zum Registrieren eines sicheren Domänennamens, wobei das Medium dadurch gekennzeichnet ist, dass das Verfahren ferner die folgenden Schritte umfasst: Verifizieren (3507) von Eigentümerinformationen für einen äquivalenten nicht sicheren Domänennamen, der dem sicheren Domänennamen entspricht; und Registrieren des sicheren Domänennamens (3508) in einem Dienst für sichere Domänennamen, wenn die Eigentümerinformationen für den äquivalenten nicht sicheren Domänennamen mit Eigentümerinformationen für den sicheren Domänennamen übereinstimmen.
Computerlesbares Medium nach Anspruch 3, bei dem der Schritt des Verifizierens von Eigentümerinformationen die folgenden Schritte umfasst: Bestimmen (3505), ob der dem sicheren Domänennamen entsprechende äquivalente nicht sichere Domänenname in einem Dienst für nicht sichere Domänennamen registriert worden ist, und Abfragen (3503), ob der äquivalente nicht sichere Domänenname in dem Dienst für nicht sichere Domänennamen registriert werden sollte, wenn der äquivalente nicht sichere Domänenname nicht in dem Dienst für nicht sichere Domänennamen registriert worden ist.