DE102015100518B4 - Verbessern des Datenschutzes durch Verschleiern von Turn-Verbindungen (traversal using relays around network address translator) und damit verwandte Verfahren, Systeme und computerlesbare Medien - Google Patents

Verbessern des Datenschutzes durch Verschleiern von Turn-Verbindungen (traversal using relays around network address translator) und damit verwandte Verfahren, Systeme und computerlesbare Medien Download PDF

Info

Publication number
DE102015100518B4
DE102015100518B4 DE102015100518.2A DE102015100518A DE102015100518B4 DE 102015100518 B4 DE102015100518 B4 DE 102015100518B4 DE 102015100518 A DE102015100518 A DE 102015100518A DE 102015100518 B4 DE102015100518 B4 DE 102015100518B4
Authority
DE
Germany
Prior art keywords
turn
server
address
client
transport address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102015100518.2A
Other languages
English (en)
Other versions
DE102015100518A1 (de
Inventor
Alan B. Johnston
John H. Yoakum
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Avaya Inc
Original Assignee
Avaya Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Avaya Inc filed Critical Avaya Inc
Publication of DE102015100518A1 publication Critical patent/DE102015100518A1/de
Application granted granted Critical
Publication of DE102015100518B4 publication Critical patent/DE102015100518B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/2539Hiding addresses; Keeping addresses anonymous
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/256NAT traversal
    • H04L61/2589NAT traversal over a relay server, e.g. traversal using relay for network address translation [TURN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer

Landscapes

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

Abstract

Verfahren zum Verschleiern von TURN-Verbindungen (Traversal Using Relays around Network Address Translator), Folgendes umfassend: Empfangen, durch einen TURN-Server, der auf einer Computereinrichtung ausgeführt wird, einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes von einem TURN-Client, sich mit einem TURN-Peer zu verbinden; Maskieren, durch den TURN-Server, einer Anwesenheit des TURN-Servers für den TURN-Peer; Vermitteln, über den TURN-Server, von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage der Maskierung; Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes; Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse; und Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.

Description

  • ALLGEMEINER STAND DER TECHNIK
  • Gebiet der Offenbarung
  • Die Technologie der Offenbarung bezieht sich im Wesentlichen auf TURN-Verbindungen (Traversal Using Relays around Network Address Translator) und insbesondere auf das Verbessern des Datenschutzes in TURN-Verbindungen zwischen TURN-Clients und TURN-Servern. Entsprechende Verfahren und Systeme sind dem Fachmann bekannt aus:
    • • Johnston et al., ”WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web,” (Book), Second Edition, Smashwords Edition, Digital Codex LLC, Jun. 2013, 254 pages.
    • • Mahy et al., ”Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” Internet Engineering Task Force, Request for Comments: 5766, Standards Track, Internet Engineering Task Force (IETF), Apr. 2010, 67 pages.
    • • Rosenberg, J.: ”Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” Network Working Group, Request for Comments: 5245, Standards Track, Internet Engineering Task Force (IETF), Apr. 2010, 117 pages.
  • Technischer Hintergrund
  • Ein Host (z. B. eine mit einem Netz verbundene Computereinrichtung), die sich hinter einer NAT-Einrichtung oder einem NAT-System (Network Address Translator) befindet, wünscht möglicherweise, mit anderen Hosts zu kommunizieren, von denen sich manche möglicherweise ebenfalls hinter NATs befinden. Hierzu setzen die Hosts möglicherweise „Hole Punching”-Techniken ein, um zu versuchen, einen direkten Kommunikationspfad zu finden, der eine Computereinrichtung über dazwischenliegende NATs und/oder Router mit einer anderen verbindet, aber nicht über Relays vermittelt wird. Hole Punching-Techniken können sich aber als erfolglos erweisen, wenn sich ein oder beide Hosts hinter NATs befinden, die mit Zuordnungsverhaltensweisen konfiguriert sind, die mit direkten Kommunikationspfaden inkompatibel sind. So können zum Beispiel NATs, die mit einer Zuordnungsverhaltensweise nach „adressenabhängiger Zuordnung” oder „adressen- und portabhängiger Zuordnung”, als nicht einschränkende Beispiele, konfiguriert sind, direkte Kommunikationspfade zwischen Hosts verhindern.
  • Wenn ein direkter Kommunikationspfad nicht gefunden werden kann, ist es möglicherweise erforderlich, einen Zwischenhost einzusetzen, um die Kommunikationen zwischen den zwei Hosts zu vermitteln. Ein Protokoll zum Vermitteln von Kommunikationen, beschrieben im Request for Comments (RFC) 5766 der Internet Engineering Task Force (IETF) (online verfügbar, z. B. unter http://tools.ietf.org/search/rfc5766) ist bekannt als TURN (Traversal Using Relays around NAT). Das TURN-Protokoll erlaubt es einem Host (hier bezeichnet als ein „TURN-Client”), anzufordern, dass ein TURN-Server als Zwischenhost dient, um Kommunikationen an und von anderen Hosts (bezeichnet als „TURN-Peers”) zu vermitteln. Um dies zu erreichen, erhält der TURN-Client eine über TURN vermittelte Transportadresse vom TURN-Server. Die über TURN vermittelte Transportadresse umfasst eine IP-Adresse (Internet Protocol) und einen Port im TURN-Server, durch den Netzkommunikationen zwischen dem TURN-Client und dem TURN-Peer übermittelt werden können. Zum Beispiel werden vom TURN-Peer an die über TURN vermittelte Transportadresse gesendete Kommunikationen vom TURN-Server an den TURN-Client gesendet. Vom TURN-Client an die über TURN vermittelte Transportadresse gesendete Kommunikationen werden vom TURN-Server an den TURN-Peer unter Einsatz von über TURN vermittelten Transportadressen als Quelladresse gesendet.
  • Der Einsatz eines TURN-Servers kann allerdings Bedenken bezogen auf den Datenschutz in einem TURN-Client aufkommen lassen. Wenngleich der Einsatz des TURN-Servers die Topologie des Netzes versteckt, mit dem der TURN-Client verbunden ist, können Informationen, die potenziell den Datenschutz des TURN-Clients beeinträchtigen können, bei der Einrichtung der TURN-Verbindung und/oder aufgrund von Merkmalen einer TURN-Verbindung zwischen dem TURN-Client und dem TURN-Server durchsickern. Zum Beispiel kann ein TURN-Peer in der Lage sein, auf Grundlage der beim Verbindungsaufbau vom TURN-Client empfangenen Kandidatenadressen zu bestimmen, dass der TURN-Server eingesetzt wird, und somit, dass der TURN-Client möglicherweise versucht, seine Adresse zu verstecken oder zu verbergen. Wenn der TURN-Peer also in der Lage ist, festzustellen, dass der TURN-Server für mehrere Kommunikationssitzungen eingesetzt wird, kann der TURN-Peer in der Lage sein, zu bestimmen, dass die mehreren Kommunikationssitzungen mit demselben TURN-Client verknüpft sind. Es ist daher Aufgabe der Erfindung, ein Verfahren und ein System bereitzustellen, welches TURN-Verbindungen zu Zwecken des Datenschutzes verschleiert.
  • KURZDARSTELLUNG DER DETAILLIERTEN BESCHREIBUNG
  • Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1. Sie wird weiter gelöst durch ein System mit den Merkmalen des Anspruchs 5 und ein nicht-flüchtiges, computerlesbares Medium mit den Merkmalen des Anspruchs 6. In dieser detaillierten Beschreibung offenbarte Ausführungsformen bieten ein Verbessern des Datenschutzes durch Verschleiern von TURN-Verbindungen (Traversal Using Relays around Network Address Translator). Verwandte Verfahren, Systeme und computerlesbare Medien werden ebenfalls offenbart.
  • In einer Ausführungsform wird ein Verfahren zum Verschleiern von TURN-Verbindungen bereitgestellt. Das Verfahren umfasst das Empfangen, durch einen TURN-Server, der auf einer Computereinrichtung ausgeführt wird, einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes von einem TURN-Client, sich mit einem TURN-Peer zu verbinden. Ferner umfasst das Verfahren das Maskieren, durch den TURN-Server, der Anwesenheit des TURN-Servers für den TURN-Peer. Das Verfahren umfasst auch das Vermitteln, über den TURN-Server, von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage der Maskierung.
  • Das Verfahren umfasst weiter das Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes, das Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse, und das Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.
  • In einer weiteren Ausführungsform wird ein System zum Verschleiern von TURN-Verbindungen bereitgestellt. Das System umfasst einen TURN-Server, der auf einer ersten Computereinrichtung ausgeführt wird. Der TURN-Server ist kommunikativ mit einem TURN-Client gekoppelt und konfiguriert, eine Anforderung zum Bereitstellen eines ersten TURN-Dienstes vom TURN-Client zu empfangen, sich mit einem TURN-Peer zu verbinden. Der TURN-Server ist ferner konfiguriert zum Maskieren einer Anwesenheit des TURN-Servers für den TURN-Peer. Der TURN-Server ist auch konfiguriert zum Vermitteln von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage des Maskierens.
  • Der TURN-Server ist weiter konfiguriert zum: Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes, Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse, und Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.
  • In einer weiteren Ausführungsform wird ein nicht transientes computerlesbares Medium mit darauf gespeicherten computerausführbaren Befehlen bereitgestellt, um zu veranlassen, dass ein Prozessor ein Verfahren implementiert, um TURN-Verbindungen zu verschleiern. Das unter Einsatz der computerausführbaren Befehle implementierte Verfahren umfasst das Empfangen, durch einen TURN-Server, der auf einer Computereinrichtung ausgeführt wird, einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes von einem TURN-Client, sich mit einem TURN-Peer zu verbinden. Das unter Einsatz der computerausführbaren Befehle implementierte Verfahren umfasst ferner das Maskieren, durch den TURN-Server, einer Anwesenheit des TURN-Servers für den TURN-Peer. Das unter Einsatz der computerausführbaren Befehle implementierte Verfahren umfasst auch das Vermitteln, über den TURN-Server, von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage der Maskierung. Das unter Einsatz der computerausführbaren Befehle implementierte Verfahren umfasst weiter das Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes, das Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse, und das Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.
  • KURZBESCHREIBUNG DER FIGUREN
  • Die beiliegenden Zeichnungsfiguren, die in diese Patentschrift aufgenommen sind und einen Bestandteil von ihr bilden, veranschaulichen diverse Ausgestaltungen der Offenbarung und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Offenbarung zu erläutern.
  • 1 ist ein Begriffsschema, das ein interaktives TURN-System (Traversal Using Relays around Network Address Translator) mit einem TURN-Client und einem TURN-Server zum Verbessern des Datenschutzes durch Verschleiern von TURN-Verbindungen darstellt;
  • 2 ist ein Schema einer beispielhaften getarnten Kandidatenliste, die vom TURN-Client aus 1 erzeugt sein kann, zum Verschleiern einer von TURN vermittelten Transportadresse in der getarnten Kandidatenliste;
  • 3 ist ein Flussdiagramm, welches beispielhafte Abläufe des TURN-Clients aus 1 zum Verschleiern von TURN-Verbindungen darstellt;
  • 4 ist ein Flussdiagramm, das weitere beispielhafte Abläufe des TURN-Clients aus 1 zum Erzeugen einer getarnten Kandidatenliste darstellt;
  • 5 ist ein Flussdiagramm, welches beispielhafte Abläufe des TURN-Servers aus 1 zum Verschleiern von TURN-Verbindungen darstellt;
  • 6 ist ein Flussdiagramm, welches weitere beispielhafte Abläufe des TURN-Servers aus 1 zum Maskieren einer Anwesenheit des TURN-Servers für einen TURN-Peer darstellt;
  • 7 ist ein Flussdiagramm, welches ferner beispielhafte Abläufe des TURN-Servers aus 1 zum Verschleiern einer folgenden TURN-Verbindung durch Auswählen einer zweiten über TURN vermittelten Transportadresse auf der Grundlage einer ersten über TURN vermittelten Transportadresse darstellt; und
  • 8 ist ein Blockdiagramm eines beispielhaften prozessorbasierten Systems, welches den TURN-Client und/oder den TURN-Server aus 1 beinhalten kann.
  • DETAILLIERTE BESCHREIBUNG
  • Nunmehr werden mit Bezug auf die Zeichnungsfiguren diverse beispielhafte Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Wort „beispielhaft” wird hierin in der Bedeutung „als ein Beispiel, ein Beispielsfall oder zur Veranschaulichung dienend” genutzt. Jede hierin als „beispielhaft” beschriebene Ausführungsform ist nicht zwangsläufig als gegenüber anderen Ausführungsformen bevorzugt oder vorteilhaft auszulegen.
  • In dieser detaillierten Beschreibung offenbarte Ausführungsformen bieten ein Verbessern des Datenschutzes durch Verschleiern von TURN-Verbindungen (Traversal Using Relays around Network Address Translator). Verwandte Verfahren, Systeme und computerlesbare Medien werden ebenfalls offenbart. In dieser Hinsicht wird in einer Ausführungsform ein Verfahren zum Verschleiern von TURN-Verbindungen bereitgestellt. Das Verfahren umfasst das Erhalten, durch einen TURN-Client, der auf einer ersten Computereinrichtung ausgeführt wird, einer oder mehrerer Kandidatenadressen, die mit dem TURN-Client verknüpft sind, wobei die eine oder die mehreren Kandidatenadressen eine über TURN vermittelte, von einem TURN-Server bereitgestellte Transportadresse umfassen. Das Verfahren umfasst ferner das Erzeugen einer getarnten Kandidatenliste auf der Grundlage der einen oder der mehreren Kandidatenadressen, in der die über TURN vermittelte Transportadresse verschleiert ist. Das Verfahren umfasst ferner das Erzeugen einer Verbindungsaufbaunachricht, umfassend die getarnte Kandidatenliste und gerichtet an einen TURN-Peer, der auf einer zweiten Computereinrichtung ausgeführt wird, und Senden der Verbindungsaufbaunachricht an die zweite Computereinrichtung.
  • In einer weiteren Ausführungsform wird ein Verfahren zum Verschleiern von TURN-Verbindungen bereitgestellt. Das Verfahren umfasst das Empfangen, durch einen TURN-Server, der auf einer Computereinrichtung ausgeführt wird, einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes von einem TURN-Client, sich mit einem TURN-Peer zu verbinden. Ferner umfasst das Verfahren das Maskieren, durch den TURN-Server, einer Anwesenheit des TURN-Servers für den TURN-Peer. Das Verfahren umfasst auch das Bereitstellen, durch den TURN-Server, des ersten TURN-Dienstes an den TURN-Client.
  • 1 illustriert ein beispielhaftes interaktives TURN-System 10, welches, wie hier offenbart, durch Verschleiern von TURN-Verbindungen verbesserten Datenschutz bereitstellt. Insbesondere stellt das beispielhafte interaktive TURN-System 10 Folgendes bereit: einen TURN-Client 12, der auf einer Computereinrichtung 14 ausgeführt wird, und einen TURN-Server 16, der auf einer Computereinrichtung 18 ausgeführt wird. Der TURN-Server 16 kann Kommunikationen zwischen dem TURN-Client 12 und einem TURN-Peer 20, der auf einer Computereinrichtung 22 ausgeführt wird, vermitteln. Auf diese Weise können Hindernisse, wie ein NAT-System oder NAT-Gerät (Network Address Translator) (nicht dargestellt), das einen direkten Kommunikationspfad zwischen dem TURN-Client 12 und dem TURN-Peer 20 verhindern kann, mit vom TURN-Server 16 bereitgestellten TURN-Diensten überwunden werden.
  • Es versteht sich, dass die Computereinrichtungen 14, 18 und 22 sich alle innerhalb desselben öffentlichen oder privaten Netzes befinden können oder sich innerhalb separater, kommunikativ gekoppelter öffentlicher oder privater Netze befinden können. Einige Ausführungsformen des interaktiven TURN-Systems 10 von 1 können vorsehen, dass jede der Computereinrichtungen 14, 18 und 22 eine beliebige Computereinrichtung mit Netzkommunikationsfähigkeiten sein kann, etwa ein Smartphone, ein Tabletcomputer, eine dedizierte Web-Appliance, ein Medienserver, ein Desktop- oder ein Server-Computer oder eine speziell angefertigte Kommunikationseinrichtung, wobei es sich um nicht einschränkende Beispiele handelt. In einigen Ausführungsformen können die Elemente der Computereinrichtungen 14, 18 und 22 über mehr als eine Computereinrichtung 14, 18, 22 verteilt sein.
  • Bevor die Abläufe im TURN-Client 12 und im TURN-Server 16 zum Verbessern des Datenschutzes diskutiert werden, wird der Aufbau von Kommunikationen in einem herkömmlichen interaktiven TURN-System beschrieben. Der TURN-Client 12 sendet zunächst eine Anforderung 24 zum Bereitstellen eines TURN-Dienstes (zum Beispiel eine Anforderung für eine TURN-Zuweisung, als nicht einschränkendes Beispiel) für den TURN-Server 16. Als Reaktion auf die Anforderung 24 stellt der TURN-Server 16 eine über TURN vermittelte Transportadresse 26 an den TURN-Client 12 bereit. Die über TURN vermittelte Transportadresse 26 umfasst eine IP-Adresse (Internet Protocol) und einen Port, bereitgestellt durch den TURN-Server, durch den Kommunikationen zwischen dem TURN-Client 12 und dem TURN-Peer 20 übermittelt werden.
  • Der TURN-Client 12 tauscht dann Verbindungsaufbaunachrichten (nicht dargestellt) mit dem TURN-Peer 20 aus, wobei jede Verbindungsaufbaunachricht Kandidatenadressen umfasst, über die der TURN-Client 12 und der TURN-Peer 20 jeweils voneinander erreicht werden können. Jede Kandidatenadresse kann Informationen enthalten, wie etwa eine IP-Adresse und einen Port, ein Protokoll, eine Prioritätsgewichtung und/oder einen Kandidatenadresstyp als nicht einschränkende Beispiele. Als Nächstes wird ein als „Hole Punching” bekannter Prozess ausgeführt, um den am besten geeigneten Kommunikationspfad zwischen dem TURN-Client 12 und dem TURN-Peer 20 auf der Grundlage der ausgetauschten Kommunikationsadressen zu bestimmen. Hole Punching-Techniken können auf Interactive Connectivity Establishment (ICE) basieren, wie beschrieben in IETF RFC 5245 (online verfügbar, z. B. unter http://tools.ietf.org/search/rfc5245). Aufgrund der hohen Bandbreitenanforderungen für TURN-Verbindungen begünstigen Hole Punching-Techniken in der Regel eine direkte Verbindung zwischen dem TURN-Client 12 und dem TURN-Peer 20 über eine Verbindung über den TURN-Server 16, falls möglich.
  • Der Einsatz eines herkömmlichen interaktiven TURN-Systems kann dennoch Bedenken bezogen auf den Datenschutz im TURN-Client 12 aufkommen lassen. Obwohl der Gebrauch des TURN-Servers 16 die Topologie des Netzes, mit dem der TURN-Client 12 verbunden ist, versteckt, können Informationen, die potenziell den Datenschutz des TURN-Clients 12 gefährden, dennoch bei der Einrichtung einer TURN-Verbindung und/oder aufgrund der Merkmale der TURN-Verbindung durchsickern. Zum Beispiel kann ein TURN-Peer 20 in der Lage sein, auf Grundlage der beim Verbindungsaufbau vom TURN-Client 12 empfangenen Kandidatenadressen zu bestimmen, dass der TURN-Server 16 eingesetzt wird, und somit, dass der TURN-Client 12 möglicherweise versucht, seine Adresse zu verstecken oder zu verbergen. Wenn der TURN-Peer 20 also in der Lage ist, festzustellen, dass der TURN-Server 16 für mehrere Kommunikationssitzungen eingesetzt wird, kann der TURN-Peer 20 in der Lage sein, zu bestimmen, dass die mehreren Kommunikationssitzungen mit demselben TURN-Client 12 verknüpft sind.
  • In dieser Hinsicht werden der TURN-Client 12 und der TURN-Server 16 bereitgestellt, um durch Verschleiern von TURN-Verbindungen im interaktiven TURN-System 10 den Datenschutz zu verbessern. In manchen Ausführungsformen des interaktiven TURN-Systems 10 ist der TURN-Client 12 konfiguriert, TURN-Verbindungen zu verschleiern, indem die über TURN vermittelte und vom TURN-Server 16 zugeordnete Transportadresse 26 in der dem TURN-Peer 20 bereitgestellten Kandidatenliste verschleiert werden. Der TURN-Client 12 erhält zunächst eine oder mehrere Kandidatenadressen 28, die mit dem TURN-Client 12 verknüpft sind, und die eine(n) oder mehrere IP-Adressen und Ports enthalten, über die der TURN-Peer 20 versuchen kann, sich mit dem TURN-Client 12 zu verbinden. Das Erhalten der einen oder der mehreren Kandidatenadressen 28 kann das Senden einer Anforderung 24 zum Bereitstellen eines TURN-Dienstes (zum Beispiel eine Anforderung für eine TURN-Zuweisung, als nicht einschränkendes Beispiel) an den TURN-Server 16 und das Erhalten der über TURN vermittelten Transportadressen 26 vom TURN-Server 16 umfassen.
  • Auf der Grundlage einer oder mehrerer Kandidatenadressen 28, erzeugt der TURN-Client 12 dann eine getarnte Kandidatenliste 30, um sie in einer Verbindungsaufbaunachricht 32 einzuschließen, die an den TURN-Peer 20 gesendet wird. Wie hier verwendet bezieht sich der Begriff „getarnte Kandidatenliste” auf eine Liste von Kandidatenadressen, einschließlich die über TURN vermittelte Transportadresse 26, wobei die über TURN vermittelte Transportadresse 26 verschleiert ist (d. h. nicht direkt als eine über TURN vermittelte Transportadresse 26 identifiziert werden kann). In manchen Ausführungsformen kann der TURN-Client 12 die getarnte Kandidatenliste 30 erzeugen, um die über TURN vermittelte Transportadresse 26 zu verschleiern, indem die über TURN vermittelte Transportadresse 26 als eine serverreflexive Kandidatenadresse (im Gegensatz zu einer Relay-Kandidatenadresse oder eine Host-Kandidatenadresse als nicht einschränkende Beispiele) identifiziert wird. Wie nach dem Stand der Technik bekannt ist, kann eine serverreflexive Kandidatenadresse in der Regel mit einer NAT verknüpft werden, während eine Relay-Adresse in der Regel mit einem TURN-Server und eine Host-Kandidatenadresse in der Regel mit einem TURN-Client verknüpft sein kann. Durch Identifizieren der über TURN vermittelten Transportadresse 26 als serverreflexive Kandidatenadresse in der getarnten Kandidatenliste 30 kann der TURN-Client 12 die Anwesenheit der über TURN vermittelten Transportadresse 26 weniger offensichtlich machen.
  • Manche Ausführungsformen stellen bereit, dass der Turn-Client 12 die getarnte Kandidatenliste 30 erzeugt, um die über TURN vermittelte Transportadresse 26 zu verschleiern, durch Bereitstellen einer unauthentischen über TURN vermittelten Transportadresse in der getarnten Kandidatenliste 30. Der TURN-Client 12 kann ferner angeben, dass die unauthentische über TURN vermittelte Transportadresse eine höhere Priorität aufweist als die über TURN vermittelte Transportadresse 26 in der getarnten Kandidatenliste 30. Auf diese Weise kann es der TURN-Client 12 dem TURN-Peer 20 erschweren, die über TURN vermittelte Transportadresse 26 in der getarnten Kandidatenliste 30 zu identifizieren und gleichzeitig die Fähigkeit beizubehalten, eine TURN-Verbindung unter Einsatz der über TURN vermittelten Transportadresse 26 aufzubauen. Zum Beispiel kann durch den Hole Punching-Prozess eine Verbindung über die höher priorisierte, aber unauthentische über TURN vermittelte Transportadresse versucht werden, wird aber fehlschlagen. Das Hole Punching-Protokoll kann auf die über TURN vermittelte Transportadresse 26 zurückgreifen, um eine TURN-Verbindung aufzubauen.
  • Nach einigen Ausführungsformen hier kann der TURN-Client 12 die getarnte Kandidatenliste 30 erzeugen, um die über TURN vermittelten Transportadressen 26 durch das Bereitstellen einer unauthentische Privatadresse (z. B. eine Privatadresse, die nicht mit dem TURN-Client 12 verknüpft ist) in der getarnten Kandidatenliste 30 zu verschleiern. Als nicht einschränkende Beispiele kann der TURN-Client 12 eine unauthentische Privatadresse aus einem Privatadressraum mit IP-Adressen von 10.0.0.0 bis 10.255.255.255 und/oder einem Privatadressraum mit IP-Adressen von 192.168.0.0 bis 192.168.255.255 bereitstellen. Hierdurch kann der TURN-Client 12 eine echte Privatadresse verbergen, die mit dem TURN-Client 12 verknüpft sein kann, und gleichzeitig möglicherweise aufkommenden Zweifel verhindern, wenn eine Privatadresse nicht in der getarnten Kandidatenliste 30 bereitgestellt wird.
  • Manche Ausführungsformen des interaktiven TURN-Systems 10 können bereitstellen, dass der TURN-Server 16 konfiguriert ist, die TURN-Verbindungen zu verschleiern, indem eine Anwesenheit des TURN-Servers 16 für den TURN-Peer 20 maskiert wird. Der TURN-Server 16 kann die Anforderung 24 zum Bereitstellen eines TURN-Dienstes (eine Anforderung für eine TURN-Zuweisung, als nicht einschränkendes Beispiel) vom TURN-Client 12 erhalten, um sich mit dem TURN-Peer 20 zu verbinden. Der TURN-Server 16 kann dann Abläufe durchführen, um die Anwesenheit des TURN-Servers 16 für den TURN-Peer 20 zu maskieren, bevor Kommunikationen 34 zwischen dem TURN-Client 12 und dem TURN-Peer 20 auf der Grundlage des Maskierens vermittelt werden.
  • In manchen Ausführungsformen kann der TURN-Server 16 konfiguriert sein, um eine Anwesenheit des TURN-Servers 16 durch Anwenden verschiedener Adressen für TURN-Signalisierungs- und TURN-Vermittlungsabläufe zu maskieren. Dementsprechend kann der TURN-Server 16 eine TURN-Signalisierungsadresse 36 zum Kommunizieren von TURN-Nachrichten 38 zwischen dem TURN-Server 16 und dem TURN-Client 12 zuordnen. Der TURN-Server 16 kann ferner die über TURN vermittelte Transportadresse 26, anders als die TURN-Signalisierungsadresse 36, zum Vermitteln der Kommunikationen 34 zwischen dem TURN-Client 12 und dem TURN-Peer 20 zuordnen. In manchen Ausführungsformen können die TURN-Signalisierungsadresse 36 und die über TURN vermittelte Transportadresse 26 in verschiedenen Subnetzen und/oder verschiedenen Adressblöcken liegen. Auf diese Weise kann die Wahrscheinlichkeit, dass TURN-Nachrichten zum Signalisieren durch einen Beobachter, wie etwa den TURN-Peer 20 mit TURN-Vermittlungstraffic verknüpft werden, minimiert.
  • Manche Ausführungsformen können bereitstellen, dass der TURN-Server 16 konfiguriert ist, eine Anwesenheit des TURN-Servers 16 zu maskieren, indem sichergestellt wird, dass eine unauthentische ChannelData-Nachricht 40, die vom TURN-Peer 20 empfangen wird, keine Fehlerrückmeldung vom TURN-Server 16 erzeugt. ChannelData-Nachrichten sind Nachrichten, die zwischen dem TURN-Peer 20 und dem TURN-Server 16 übermittelt werden, um Daten über die über TURN vermittelte Transportadresse 26 zu senden und zu empfangen. Falls der TURN-Server 16 auf die unauthentische ChannelData-Nachricht 40 mit einer Fehlermeldung antwortet, könnte die Anwesenheit des TURN-Servers 16 aufgedeckt werden. Stattdessen kann der TURN-Server 16 unbemerkt die unauthentische ChannelData-Nachricht 40 verwerfen.
  • Nach mehreren der hier offenbarten Ausführungsformen, kann der TURN-Server 16 konfiguriert werden, eine Anwesenheit des TURN-Servers 16 zu maskieren, indem eine über TURN vermittelte Transportadresse 26 zugeordnet wird, die nicht mit einer Unternehmens-Serverfarm (nicht dargestellt) verbunden ist. Eine über TURN vermittelte Transportadresse 26, die mit einer Unternehmens-Serverfarm verbunden zu sein scheint, kann als wahrscheinlicher mit dem TURN-Server 16 verbunden zu sein scheinen und weniger wahrscheinlich als tatsächliche IP-Adresse eines Endbenutzers. Als Ergebnis kann eine umgekehrte IP-Abfrage nach der über TURN vermittelten Transportadresse 26 die Anwesenheit des TURN-Servers 16 für einen außenstehenden Beobachter, wie etwa den TURN-Peer 20 anzeigen. Durch Zuordnen der über TURN vermittelten Transportadresse 26, die nicht mit einer Unternehmens-Serverfarm verbunden ist, kann der TURN-Server 16 ferner seine Anwesenheit für den TURN-Peer 20 maskieren.
  • In manchen Ausführungsformen kann der TURN-Server 16 konfiguriert sein, eine Anwesenheit des TURN-Servers 16 zu maskieren, indem eine zweite über TURN vermittelte Transportadresse 26(2) für eine TURN-Kommunikationssitzung auf Grundlage einer ersten über TURN vermittelten Transportadresse 26(1) ausgewählt wird, die in einer vorherigen Kommunikationssitzung eingesetzt wurde. Zum Beispiel kann der TURN-Server 16 eine einheitliche Strategie zum Auswählen der zweiten über TURN vermittelten Transportadresse 26(2) einsetzen, die von der ersten über TURN vermittelten Transportadresse 26(1) verschieden ist. Auf diese Weise können Kommunikationen 42(2) an den TURN-Client 12 vermittelt werden, ohne dass der TURN-Peer 20 in der Lage ist, eine einzelne über TURN vermittelte Transportadresse 26 mit dem TURN-Client 12 zu verbinden. In manchen Ausführungsformen, kann der TURN-Server 16 die Auswahl der zweiten über TURN vermittelten Transportadresse 26(2) davon abhängig machen, ob eine Anforderung 44 zum Bereitstellen eines TURN-Dienstes vom selben TURN-Client 12 wie die Anforderung 24 empfangen wurde. In diesem Fall kann der TURN-Server 16 die zweite über TURN vermittelte Transportadresse 26(2) auswählen, die mit der ersten über TURN vermittelten Transportadresse 26(1) identisch ist. Kommunikationen 42(1) können an den TURN-Client 12 vermittelt werden, ohne den Verdacht zu erregen, dass über TURN vermittelte Transportadressen 26 zwischen Kommunikationssitzungen verändert worden sind.
  • Um eine beispielhaft getarnte Kandidatenliste 46 darzustellen, die durch den TURN-Client 12 aus 1 erzeugt worden sein kann, um eine TURN-Verbindung zu verschleiern, wird 2 bereitgestellt. Wie in 2 gezeigt, enthält die getarnte Kandidatenliste 46 die Kandidatenadressen 48. Die Kandidatenadressen 48 umfassen Spalten oder Felder, die Folgendes identifizieren: Protokolle 50, Prioritätsgewichtungen 52, IP-Adressen 54, Portnummern 56 und Adresstypen 58 der Kandidatenadressen 48. Die Protokolle 50 für die Kandidatenadressen 48 können unter Anderem zum Beispiel UDP (User Datagram Protocol) und TCP (Transport Control Protocol) umfassen. Die Prioritätsgewichtungen 52 können von einem Hole Punching-Protokoll eingesetzt werden, um eine Präferenz unter den Kandidatenadressen 48 zu bestimmen. So können zum Beispiel höhere Werte für die Prioritätsgewichtungen 52 die eher bevorzugten Kandidatenadressen 48 angeben. Die IP-Adressen 54 und die Portnummern 56 geben gemeinsam mit den Kandidatenadressen 48 verbundene Netzadressen an, während die Adresstypen 58 angeben, ob die Kandidatenadressen 48, als nicht einschränkende Beispiele, serverreflexive Kandidatenadressen, Relay-Kandidatenadressen oder Host-Kandidatenadressen sind.
  • In dem Beispiel aus 2 zeigt die getarnte Kandidatenliste 46, wie eine mit einem TURN-Server verknüpfte Kandidatenadresse 48 verborgen werden kann. Die getarnte Kandidatenliste 46 umfasst eine unauthentische über TURN vermittelte Transportadresse 60, eine über TURN vermittelte Transportadresse 62 (z. B. die über TURN vermittelte Transportadresse 26 aus 1), eine mit dem TURN-Client 12 aus 1 verbundene Privatadresse 64 und eine unauthentische Privatadresse 66. Die unauthentische, über TURN vermittelte Transportadresse 60 wird als Relay-Kandidatenadresse (in der Regel assoziiert mit TURN-Servern) identifiziert und erhält die höchste Prioritätsgewichtung 52. Tatsächlich ist die unauthentische über TURN vermittelte Transportadresse 60 aber keine gültige TURN-Server-IP-Adresse. Im Gegensatz dazu ist die über TURN vermittelte Transportadresse 62 authentisch und erhält eine niedrigere Prioritätsgewichtung 52 als die unauthentische über TURN vermittelte Transportadresse 60. Die über TURN vermittelte Transportadresse 62 wird auch identifiziert als vom Typ „SERVERREFLEXIV”, was üblicherweise eher mit einer NAT-Einrichtung als mit einem TURN-Server verbunden ist. Dementsprechend wird die Wahrscheinlichkeit, dass die über TURN vermittelte Transportadresse 62 als echte TURN-Serveradresse identifiziert wird, verringert. Auf ähnliche Weise werden sowohl die mit dem TURN-Client 12 verbundene Privatadresse 64 und die unauthentische Privatadresse 66 in der getarnten Kandidatenliste 46 bereitgestellt und verringern so die Fähigkeit eines Beobachters, zu bestimmen, welche echt ist.
  • Wie oben beschrieben kann der TURN-Client 12 aus 1 zum Verbessern des Datenschutzes durch Verschleiern von TURN-Verbindungen konfiguriert werden. In dieser Hinsicht wird 3 bereitgestellt, um beispielhafte Abläufe des TURN-Clients 12 aus 1 zum Verschleiern von TURN-Verbindungen darzustellen. Der Klarheit halber wird beim Beschreiben von 3 auf Elemente von 1 Bezug genommen. In 3 beginnen die Abläufe damit, dass der TURN-Client 12 eine oder mehrere mit dem TURN-Client 12 verbundene Kandidatenadressen 28 erhält (Block 68). Die eine oder die mehreren Kandidatenadressen 28 umfassen eine von einem TURN-Server 16 bereitgestellte, über TURN vermittelte Transportadresse 26.
  • Der TURN-Client 12 erzeugt dann eine getarnte Kandidatenliste 30 auf der Grundlage der einen oder der mehreren Kandidatenadressen 28, in welcher die über TURN vermittelte Transportadresse 26 verschleiert ist (Block 70). Wie oben erläutert, kann die über TURN vermittelte Transportadresse 26 durch Identifizieren der über TURN vermittelten Transportadresse 26 als serverreflexive Kandidatenadresse in der getarnten Kandidatenliste 30, durch Einschließen einer unauthentischen über TURN vermittelten Transportadresse in der getarnten Kandidatenliste 30 und/oder durch Einschließen einer unauthentischen Privatadresse in der getarnten Kandidatenliste 30 verschleiert werden. Der TURN-Client 12 erzeugt dann eine Verbindungsaufbaunachricht 32, umfassend die getarnte Kandidatenliste 30, und gerichtet an einen TURN-Peer 20, der auf einer Computereinrichtung 22 ausgeführt wird (Block 72). Der TURN-Client 12 sendet dann die Verbindungsaufbaunachricht 32 an die Computereinrichtung 22 (Block 74).
  • 4 ist ein Flussdiagramm, das ferner beispielhafte Abläufe des TURN-Clients 12 aus 1 zum Erzeugen der getarnten Kandidatenliste 46 aus 2 darstellt. Der Klarheit halber wird beim Beschreiben von 4 auf Elemente aus den 1 und 2 Bezug genommen. In 4 steht Block 76 für Abläufe zum Erzeugen einer getarnten Kandidatenliste 46 auf der Grundlage der einen oder der mehreren Kandidatenadressen 28, in der die über TURN vermittelte Transportadresse 62 verschleiert ist. Es versteht sich, dass die Abläufe aus Block 76 in 4 den Abläufen aus Block 70 in 3 entsprechen.
  • In manchen Ausführungsformen umfassen die Abläufe aus Block 76 in 4 zum Erzeugen der getarnten Kandidatenliste 46 möglicherweise, dass der TURN-Client 12 die über TURN vermittelte Transportadresse 62 als eine serverreflexive Kandidatenadresse in der getarnten Kandidatenliste 46 (Block 78) identifiziert. Wie oben erläutert ist eine serverreflexive Kandidatenliste üblicherweise eher mit einem NAT als mit einem TURN-Server verbunden. Dementsprechend kann durch Identifizieren der über TURN vermittelten Transportadresse 62 als eine serverreflexive Kandidatenadresse die Anwesenheit der über TURN vermittelten Transportadresse 62 in der getarnten Kandidatenliste 46 weniger offensichtlich gestaltet werden.
  • Manche Ausführungsform können bereitstellen, dass die Abläufe aus Block 76 zum Erzeugen der getarnten Kandidatenliste 46 umfassen, dass der TURN-Client 12 eine unauthentische über TURN vermittelte Transportadresse 60 in der getarnten Kandidatenliste 46 bereitstellt (Block 80). Der TURN-Client 12 kann dann angeben, dass die unauthentische über TURN vermittelte Transportadresse 60 eine höhere Priorität aufweist als die über TURN vermittelte Transportadresse 62 in der getarnten Kandidatenliste 46 (Block 82). Die unauthentische über TURN vermittelte Transportadresse 60 kann somit die Anwesenheit der über TURN vermittelten Transportadresse 62 verschleiern, indem sie als echte TURN-Serveradresse erscheint.
  • Nach manchen der Ausführungsformen hier können die Abläufe aus Block 76 zum Erzeugen der getarnten Kandidatenliste 46 umfassen, dass der TURN-Client 12 eine unauthentische Privatadresse 66 in der getarnten Kandidatenliste 46 bereitstellt (Block 84). Als nicht einschränkende Beispiele kann die unauthentische Privatadresse zum Beispiel aus einem Privatadressraum mit IP-Adressen von 10.0.0.0 bis 10.255.255.255 und/oder einem Privatadressraum mit IP-Adressen von 192.168.0.0 bis 192.168.255.255 ausgewählt sein. Auf diese Weise kann eine echte, möglicherweise mit dem TURN-Client 12 verbundene Privatadresse, wie etwa die Privatadresse 64 aus 2, in der getarnten Kandidatenliste 46 verschleiert sein.
  • Wie oben bemerkt, kann der Datenschutz auch dadurch verbessert werden, dass der TURN-Server 16 aus 1 TURN-Verbindungen verschleiert. In dieser Hinsicht wird 5 bereitgestellt, um beispielhafte Abläufe des TURN-Servers 16 aus 1 zum Verschleiern von TURN-Verbindungen darzustellen. Der Klarheit halber wird beim Beschreiben von 5 auf Elemente von 1 Bezug genommen. In 5 beginnen die Abläufe damit, dass der TURN-Server 16 eine Anforderung 24 zum Bereitstellen eines ersten TURN-Diensts von einem TURN-Client 12 erhält, sich mit einem TURN-Peer 20 zu verbinden (Block 86). Die Anforderung 24 kann zum Beispiel eine Anforderung für eine TURN-Zuordnung durch den TURN-Server 16 sein.
  • Der TURN-Server 16 maskiert dann eine Anwesenheit des TURN-Servers 16 für den TURN-Peer 20 (Block 88). Beispielhafte Abläufe zum Maskieren der Anwesenheit des TURN-Servers 16 für den TURN-Peer 20 werden detaillierter bezogen auf 6 erläutert. Der TURN-Server 16 vermittelt dann Kommunikationen 34 zwischen dem TURN-Client 12 und dem TURN-Peer 20 auf Grundlage des Maskierens (Block 90).
  • 6 ist ein Flussdiagramm, welches beispielhafte Abläufe des TURN-Servers 16 aus 1 zum Maskieren der Anwesenheit des TURN-Servers 16 für einen TURN-Peer 20. Der Klarheit halber wird beim Beschreiben von 6 auf Elemente aus 1 Bezug genommen. In 6 steht Block 92 für Abläufe zum Maskieren einer Anwesenheit des TURN-Servers 16 für den TURN Peer 20 (Block 92). Es versteht sich, dass die Abläufe aus Block 92 in 6 den in Block 88 in 5 dargestellten Abläufen entsprechen.
  • In manchen Ausführungsformen können die Abläufe aus Block 92 zum Maskieren einer Anwesenheit des TURN-Servers 16 beinhalten, dass der TURN-Server 16 eine TURN-Signalisierungsadresse 36 zum Kommunizieren von TURN-Nachrichten 38 zwischen dem TURN-Server 16 und dem TURN-Client 12 zuordnet (Block 94). Der TURN-Server 16 ordnet auch eine über TURN vermittelte Transportadresse 26 zum Vermitteln von Kommunikationen 34 zwischen dem TURN-Client 12 und dem TURN-Peer 20 zu, wobei die über TURN vermittelte Transportadresse 26 von der TURN-Signalisierungsadresse 36 (Block 96) verschieden ist. Durch Einsetzen verschiedener Adressen für TURN-Signalisierung und TURN-Vermittlung kann der TURN-Server 16 die Wahrscheinlichkeit, dass TURN-Nachrichten zum Signalisieren durch einen Beobachter mit TURN-Vermittlungstraffic verknüpft werden, minimieren.
  • Manche Ausführungsformen können bereitstellen, dass die Abläufe aus Block 92 zum Maskieren einer Anwesenheit des TURN-Servers 16 einschließen können, dass der TURN-Server 16 eine unauthentische ChannelData-Nachricht 40 vom TURN-Peer 20 erhält (Block 98). Der TURN-Server 16 verwirft dann unbemerkt die unauthentische ChannelData-Nachricht 40 (Block 100). Durch unbemerktes Verwerfen der unauthentischen ChannelData-Nachricht 40 verhindert der TURN-Server 16 es, seine Anwesenheit zu bestätigen, wie es ansonsten der Fall wäre, wenn der TURN-Server 16 eine Fehlermeldung an den TURN-Peer 20 senden würde.
  • Nach einigen der hier offenbarten Ausführungsformen können die Abläufe aus Block 92 zum Maskieren einer Anwesenheit des TURN-Servers 16 beinhalten, dass der TURN-Server 16 eine über TURN vermittelte Transportadresse 26 zuordnet, die nicht mit einer Unternehmens-Serverfarm verbunden ist (Block 102). Wie oben bemerkt, kann eine über TURN vermittelte Transportadresse 26, die mit einer Unternehmens-Serverfarm verbunden zu sein scheint, die Anwesenheit des TURN-Servers 16 für einen Beobachter andeuten, der eine umgekehrte IP-Abfrage zur über TURN vermittelten Transportadresse 26 durchführt. Durch Zuordnen einer über TURN vermittelten Transportadresse 26, die nicht mit einer Unternehmens-Serverfarm verbunden ist, kann dementsprechend der TURN-Server 16 ferner seine Anwesenheit für den TURN-Peer 20 maskieren.
  • 7 ist ein Flussdiagramm, welches weitere beispielhafte Abläufe des TURN-Servers 16 aus 1 zum Verschleiern einer folgenden TURN-Verbindung durch Auswählen einer zweiten über TURN vermittelten Transportadresse 26(2) auf der Grundlage einer ersten über TURN vermittelten Transportadresse 26(1) darstellt. Der Klarheit halber wird beim Beschreiben von 7 auf Elemente von 1 Bezug genommen. Die Abläufe in 7 beginnen damit, dass der TURN-Server 16 Kommunikationen 34 unter Einsatz einer ersten über TURN vermittelten Transportadresse 26(1) (Block 104) vermittelt. Es versteht sich, dass die Abläufe aus Block 104 in 7 den in Block 90 in 5 dargestellten Abläufen entsprechen. Der TURN-Server 16 kann dann eine Anforderung 44 zum Bereitstellen eines zweiten TURN-Dienstes erhalten (Block 106). Die Anforderung 44 kann, als nicht einschränkendes Beispiel, eine Anforderung für eine zweite TURN-Zuordnung sein.
  • Der TURN-Server 16 wählt eine zweite über TURN vermittelte Transportadresse 26(2) zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse 26(1) (Block 108). In manchen Ausführungsformen können die Abläufe aus Block 108 zum Auswählen der zweiten über TURN vermittelten Transportadresse 26(2) beinhalten, dass der TURN-Server 16 die zweite über TURN vermittelte Transportadresse 26(2) auswählt, die von der ersten über TURN vermittelten Transportadresse 26(1) verschieden ist (Block 110). Auf diese Weise kann der TURN-Server 16 Kommunikationen 42(2) an den TURN-Client 12 vermitteln, ohne dass der TURN-Peer 20 in der Lage ist, eine einzelne über TURN vermittelte Transportadresse 26 mit dem TURN-Client 12 zu verbinden.
  • Manche Ausführungsformen können bereitstellen, dass die Abläufe aus Block 108 zum Auswählen der zweiten über TURN vermittelten Transportadresse 26(2) beinhalten können, dass der TURN-Server 16 zunächst bestimmt, ob die Anforderung 44 von einem selben TURN-Client 12 empfangen wurde wie die Anforderung 24 zum Bereitstellen eines ersten TURN-Dienstes (Block 112). Falls der TURN-Server 16 in Block 112 bestimmt, dass die Anforderung 44 und die Anforderung 24 vom selben TURN-Client 12 empfangen worden sind, kann der TURN-Server 16 die zweite über TURN vermittelte Transportadresse 26(2) auswählen, die mit der ersten über TURN vermittelten Transportadresse 26(1) identisch ist (Block 114). Kommunikationen 42(1) können dann an den TURN-Client 12 vermittelt werden, ohne den Verdacht zu erregen, dass über TURN vermittelte Transportadressen 26 zwischen Kommunikationssitzungen verändert worden sind. Ansonsten kann der TURN-Server 16, falls der TURN-Server 16 in Block 112 bestimmt, dass die Anforderung 44 und die Anforderung 24 von einem anderen Client als dem TURN-Client 12 empfangen worden sind, die zweite über TURN vermittelte Transportadresse 26(2) auswählen, die mit der ersten über TURN vermittelten Transportadresse 26(1) identisch oder von dieser verschieden ist, abhängig von der Implementierung des TURN-Servers 16 (Block 116).
  • 8 stellt eine Blockdiagrammdarstellung eines Verarbeitungssystems 118 in der beispielhaften Form eines beispielhaften Computersystems 120 bereit, das angepasst ist, um Befehle zum Durchführen der hierin beschriebenen Funktionen auszuführen. In manchen Ausführungsformen kann das Verarbeitungssystem 118 Anweisungen ausführen, um die Funktionen des TURN-Clients 12 und/oder des TURN-Servers 16 aus 1 auszuführen. In diesem Zusammenhang kann das Verarbeitungssystem 118 das Computersystem 120 umfassen, innerhalb dessen ein Satz von Befehlen zum Veranlassen, dass das Verarbeitungssystem 118 eine beliebige oder beliebige mehrere der hierin erörterten Methodiken durchführt, ausgeführt werden kann. Das Verarbeitungssystem 118 ist möglicherweise mit anderen Maschinen in einem Local Area Network (LAN), einem Intranet, einem Extranet oder dem Internet verbunden (etwa vernetzt, wobei es sich um ein nicht einschränkendes Beispiel handelt). Das Verarbeitungssystem 118 wird möglicherweise in einer Client-Server-Netzumgebung oder als gleichrangige Maschine in der Umgebung eines Peer-to-Peer-(oder dezentralen)Netzes betrieben. Auch wenn nur ein einziges Verarbeitungssystem 118 veranschaulicht wird, sind die Begriffe „Controller” und „Server” auch so aufzufassen, dass sie eine beliebige Gruppe von Maschinen beinhalten, die individuell oder gemeinsam einen Satz (oder mehrere Sätze) von Befehlen zum Durchführen einer beliebigen oder beliebiger mehrerer der hierin erörterten Methodiken ausführen. Das Verarbeitungssystem 118 ist möglicherweise ein Server, ein Personal Computer, ein Desktop-Computer, ein Laptop-Computer, ein Personal Digital Assistant (PDA), ein Computerpad, eine mobile Einrichtung oder eine beliebige andere Einrichtung und verkörpert möglicherweise, wobei es sich um nicht einschränkende Beispiele handelt, einen Server oder einen Computer eines Benutzers.
  • Das beispielhafte Computersystem 120 beinhaltet eine Verarbeitungseinrichtung oder einen Prozessor 122, einen Hauptspeicher 124 (ein Read Only Memory (ROM), einen Flashspeicher, einen dynamischen Schreib-Lese-Speicher (DRAM) wie ein synchrones DRAM (SDRAM) etc. als nicht einschränkende Beispiele) und einen statischen Speicher 126 (einen Flashspeicher, einen statischen Schreib-Lese-Speicher (SRAM) etc. als nicht einschränkende Beispiele), die möglicherweise über einen Bus 128 miteinander kommunizieren. Alternativ kann die Verarbeitungseinrichtung 122 möglicherweise direkt oder über irgendein anderes Konnektivitätsmittel mit dem Hauptspeicher 124 und/oder dem statischen Speicher 126 verbunden sein.
  • Die Verarbeitungseinrichtung 122 stellt eine oder mehrere Verarbeitungseinrichtungen wie einen Mikroprozessor, eine Zentralverarbeitungseinheit (CPU) oder dergleichen dar. Insbesondere ist die Verarbeitungseinrichtung 122 möglicherweise ein Mikroprozessor für Rechenvorgänge mit komplexem Befehlssatz (CISC), ein Mikroprozessor für Rechenvorgänge mit reduziertem Befehlssatz (RISC), ein Mikroprozessor für überlange Befehlswörter (VLIW), ein Prozessor, der andere Befehlssätze implementiert, oder Prozessoren, die eine Kombination von Befehlssätzen implementieren. Die Verarbeitungseinrichtung 122 ist konfiguriert, um Verarbeitungslogik in Befehlen 130 und/oder gecachten Befehlen 132 zum Durchführen der hierin erörterten Abläufe und Schritte auszuführen.
  • Das Computersystem 120 beinhaltet weiter möglicherweise eine Kommunikationsschnittstelle in Form einer Netzschnittstelleneinrichtung 134. Es kann auch einen Eingang 136 zum Empfangen von Eingaben und Auswahloptionen, die bei der Ausführung der Befehle 130, 132 an das Computersystem 120 zu kommunizieren sind, beinhalten oder nicht. Es kann auch einen Ausgang 138, der unter anderem (eine) Anzeige(n) 140 beinhaltet/beinhalten oder nicht. Die Anzeige(n) 140 ist/sind möglicherweise eine Videoanzeigeeinheit (eine Flüssigkristallanzeige (LCD) oder eine Kathodenstrahlröhre (CRT) als nicht einschränkende Beispiele), eine Einrichtung für alphanumerische Eingaben (eine Tastatur als nicht einschränkendes Beispiel), eine Cursorsteuereinrichtung (eine Maus als nicht einschränkendes Beispiel) und/oder eine Touchscreen-Einrichtung (eine Tablet-Eingabeeinrichtung oder ein Bildschirm als nicht einschränkende Beispiele).
  • Das Computersystem 120 beinhaltet möglicherweise eine oder auch keine Datenablageeinrichtung 142, welche die Nutzung eines Laufwerks/von Laufwerken 144 beinhaltet, um die hierin beschriebenen Funktionen in einem computerlesbaren Medium 146 abzulegen, auf dem ein oder mehrere Sätze von Befehlen 148 (z. B. Software) abgelegt sind, die eine beliebige oder beliebige mehrere der hierin beschriebenen Methodiken oder Funktionen verkörpern. Die Funktionen können die Verfahren und/oder andere Funktionen des Verarbeitungssystems 118, eine Teilnehmerbenutzereinrichtung und/oder einen Lizenzierungsserver beinhalten, wobei es sich um nicht einschränkende Beispiele handelt. Der eine oder die mehreren Sätze von Befehlen 148 können während ihrer Ausführung durch das Computersystem 120 auch vollständig oder mindestens teilweise innerhalb des Hauptspeichers 124 und/oder innerhalb der Verarbeitungseinrichtung 122 liegen. Der Hauptspeicher 124 und die Verarbeitungseinrichtung 122 bilden ebenfalls für Maschinen zugängliche Ablagemedien. Die Befehle 130, 132 und/oder 148 können weiter über ein Netz 150 über die Netzschnittstelleneinrichtung 134 gesendet oder empfangen werden. Das Netz 150 kann ein Intra-Netz oder ein Inter-Netz sein.
  • Wenngleich das computerlesbare Medium 146 in einer beispielhaften Ausführungsform als einzelnes Medium gezeigt ist, ist der Begriff „für Maschinen zugängliches Ablagemedium” so aufzufassen, dass er ein einzelnes Medium oder mehrere Medien beinhaltet (eine zentrale oder eine dezentrale Datenbank und/oder assoziierte Cache-Speicher und Server als nicht einschränkende Beispiele), die den einen oder die mehreren Sätze von Befehlen 148 ablegen. Der Begriff „für Maschinen zugängliches Ablagemedium” ist auch so aufzufassen, dass er beliebige Medien beinhaltet, die fähig sind, einen Satz von Befehlen zur Ausführung durch die Maschine abzulegen, zu codieren oder zu übermitteln, und die veranlassen, dass die Maschine eine beliebige oder beliebige mehrere der hierin offenbarten Methodiken durchführt. Der Begriff „für Maschinen zugängliches Ablagemedium” ist demgemäß so aufzufassen, dass er Halbleiterspeicher, optische und magnetische Medien und Trägerwellensignale beinhaltet, jedoch nicht darauf beschränkt ist.
  • Die hierin offenbarten Ausführungsformen sind möglicherweise in Hardware und in Befehlen, die in Hardware abgelegt sind, ausgeführt und liegen möglicherweise, wobei es sich um nicht einschränkende Beispiele handelt, in einem Random Access Memory (RAM), einem Flashspeicher, einem Read Only Memory (ROM), einem Electrically Programmable ROM (EPROM), einem Electrically Erasable Programmable ROM (EEPROM), in Registern, auf einer Festplatte, einer Wechselfestplatte, einer CD-ROM oder einem computerlesbaren Medium in irgendeiner anderen aus dem Stand der Technik bekannten Form vor. Ein beispielhaftes Ablagemedium ist an den Prozessor gekoppelt, sodass der Prozessor Informationen auf dem Ablagemedium lesen und das Ablagemedium mit Informationen beschreiben kann. Alternativ kann das Ablagemedium fest in den Prozessor integriert sein. Der Prozessor und das Ablagemedium können sich in einer anwendungsspezifischen integrierten Schaltung (ASIC) befinden. Die ASIC kann sich in einem Remote-Endgerät befinden. Alternativ können sich der Prozessor und das Ablagemedium als separate Komponenten in einem Remote-Endgerät, in einer Basisstation oder auf einem Server befinden.
  • Es wird auch angemerkt, dass die in beliebigen der beispielhaften Ausführungsformen hierin beschriebenen Ablaufschritte beschrieben werden, um Beispiele bereitzustellen und eine Erörterung zu ermöglichen. Die beschriebenen Abläufe sind auch in zahlreichen anderen statt nur in den veranschaulichten Reihenfolgen durchführbar. Des Weiteren können Abläufe, die als einzelner Ablaufschritt beschrieben werden, in der Praxis auch in etlichen unterschiedlichen Schritten durchgeführt werden. Zusätzlich können ein oder mehrere in den beispielhaften Ausführungsformen erörterte Ablaufschritte kombiniert werden. Es versteht sich, dass die in den Flussdiagrammen veranschaulichten Ablaufschritte auf zahlreiche unterschiedliche Arten modifiziert werden können, die sich für Fachleute ohne weiteres ergeben. Es verstünde sich für Fachleute auch, dass Informationen und Signale unter Nutzung beliebiger einer Vielzahl unterschiedlicher Technologien und Techniken dargestellt werden können. Daten, Befehle, Kommandos, Informationen, Signale, Bits, Symbole und Chips, auf die in der obigen Beschreibung gegebenenfalls Bezug genommen wird, können durch Spannungen, Ströme, elektromagnetische Wellen, Magnetfelder oder Partikel, optische Felder oder Partikel oder beliebige Kombinationen davon dargestellt sein, wobei es sich um nicht einschränkende Beispiele handelt.
  • Die vorangehende Beschreibung der Offenbarung wird bereitgestellt, um Fachleute zu einer Anfertigung gemäß der Offenbarung oder zu ihrer Nutzung zu befähigen. Verschiedene Modifikationen der Offenbarung werden sich für Fachleute ohne weiteres ergeben, und die allgemeinen, hierin definierten Prinzipien können auf andere Variationen angewendet werden, ohne vom Gedanken oder vom Schutzbereich der Offenbarung abzuweichen. Daher soll die Offenbarung nicht auf die hierin beschriebenen Beispiele und Ausführungen eingeschränkt sein, sondern ihr soll der weitestmögliche Schutzbereich zukommen, der mit den Prinzipien und den Neuheitsmerkmalen, die hierin offenbart werden, vereinbar ist.

Claims (6)

  1. Verfahren zum Verschleiern von TURN-Verbindungen (Traversal Using Relays around Network Address Translator), Folgendes umfassend: Empfangen, durch einen TURN-Server, der auf einer Computereinrichtung ausgeführt wird, einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes von einem TURN-Client, sich mit einem TURN-Peer zu verbinden; Maskieren, durch den TURN-Server, einer Anwesenheit des TURN-Servers für den TURN-Peer; Vermitteln, über den TURN-Server, von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage der Maskierung; Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes; Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse; und Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.
  2. Verfahren nach Anspruch 1, wobei das Maskieren der Anwesenheit des TURN-Servers Folgendes umfasst: Zuordnen einer TURN-Signalisierungsadresse zum Kommunizieren von TURN-Nachrichten zwischen dem TURN-Server und dem TURN-Client; und Zuordnen einer über TURN vermittelten Transportadresse zum Vermitteln der Kommunikationen zwischen dem TURN-Client und dem TURN-Peer; wobei die über TURN vermittelte Transportadresse von der TURN-Signalisierungsadresse verschieden ist.
  3. Verfahren nach Anspruch 2, wobei die TURN-Signalisierungsadresse und die über TURN vermittelte Transportadresse in verschiedenen Subnetzen oder verschiedenen Adressblöcken oder Kombinationen aus diesen liegen.
  4. Verfahren nach Anspruch 1, wobei das Maskieren der Anwesenheit des TURN-Servers Folgendes umfasst: Empfangen, durch den TURN-Server, einer unauthentischen ChannelData-Nachricht vom TURN-Peer; und als Rückmeldung auf das Empfangen einer unauthentischen ChannelData-Nachricht, unbemerktes Verwerfen der ChannelData-Nachricht.
  5. System zum Verschleiern von TURN-Verbindungen (Traversal Using Relays around Network Address Translator), Folgendes umfassend: einen TURN-Server, der auf einer ersten Computereinrichtung ausgeführt wird, wobei der TURN-Server kommunikativ mit einem TURN-Client verbunden ist und konfiguriert ist zum: Empfangen einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes vom TURN-Client, sich mit einem TURN-Peer zu verbinden; Maskieren einer Anwesenheit des TURN-Servers für den TURN-Peer; Vermitteln von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage des Maskierens Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes; Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse; und Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.
  6. Nicht-flüchtiges, computerlesbares Medium, auf dem computerausführbare Befehle gespeichert sind, welche einen Prozessor dazu veranlassen, ein Verfahren zum Verschleiern von TURN-Verbindungen (Traversal Using Relays around Network Address Translator) zu implementieren, das Folgendes umfasst: Empfangen einer Anforderung zum Bereitstellen eines ersten TURN-Dienstes vom TURN-Client, sich mit einem TURN-Peer zu verbinden; Maskieren einer Anwesenheit des TURN-Servers für den TURN-Peer; Vermitteln von Kommunikationen zwischen dem TURN-Client und dem TURN-Peer unter Einsatz einer ersten über TURN vermittelten Transportadresse, auf der Grundlage des Maskierens Empfangen, durch den TURN-Server, einer Anforderung zum Bereitstellen eines zweiten TURN-Dienstes; Auswählen einer zweiten über TURN vermittelten Transportadresse zum Bereitstellen des zweiten TURN-Dienstes auf der Grundlage der ersten über TURN vermittelten Transportadresse; und Vermitteln von mit dem zweiten TURN-Dienst verknüpften Kommunikationen unter Einsatz der zweiten über TURN vermittelten Transportadresse.
DE102015100518.2A 2014-01-27 2015-01-14 Verbessern des Datenschutzes durch Verschleiern von Turn-Verbindungen (traversal using relays around network address translator) und damit verwandte Verfahren, Systeme und computerlesbare Medien Active DE102015100518B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/164,332 US9356915B2 (en) 2014-01-27 2014-01-27 Enhancing privacy by obscuring traversal using relays around network address translator (TURN) connections, and related methods, systems, and computer-readable media
US14/164,332 2014-01-27

Publications (2)

Publication Number Publication Date
DE102015100518A1 DE102015100518A1 (de) 2015-07-30
DE102015100518B4 true DE102015100518B4 (de) 2017-11-30

Family

ID=52673997

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015100518.2A Active DE102015100518B4 (de) 2014-01-27 2015-01-14 Verbessern des Datenschutzes durch Verschleiern von Turn-Verbindungen (traversal using relays around network address translator) und damit verwandte Verfahren, Systeme und computerlesbare Medien

Country Status (4)

Country Link
US (1) US9356915B2 (de)
CN (1) CN104811435B (de)
DE (1) DE102015100518B4 (de)
GB (2) GB2524628B (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10075447B2 (en) * 2015-03-04 2018-09-11 Neone, Inc. Secure distributed device-to-device network
US9961014B2 (en) * 2015-11-13 2018-05-01 Nanning Fugui Precision Industrial Co., Ltd. Network communication method based on software-defined networking and server using the method
US10462101B2 (en) * 2015-11-13 2019-10-29 Nanning Fugui Precision Industrial Co., Ltd. Network communication method based on software-defined networking and server using the method
CN115150076A (zh) * 2022-06-27 2022-10-04 联信摩贝软件(北京)有限公司 一种基于量子随机数的加密系统及方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7853680B2 (en) * 2007-03-23 2010-12-14 Phatak Dhananjay S Spread identity communications architecture
CN101179581B (zh) * 2007-12-13 2010-06-09 北京邮电大学 一种采用ice中继候选地址进行媒体传输的方法
EP2071809A1 (de) * 2007-12-13 2009-06-17 Alcatel Lucent Verfahren zum Aufbau einer Verbindung in einem peer-to-peer Netzwerk mit Netzwerkadressübersetzung (NAT)
CN101252527B (zh) * 2008-04-09 2011-01-26 腾讯科技(深圳)有限公司 一种网络中转的方法、网络中转服务器和内核管理模块
EP2608488B1 (de) * 2011-12-22 2014-05-14 BlackBerry Limited Dialoggründung über eine Peer-to-Peer-Architektur
EP2725765B1 (de) * 2012-10-29 2016-04-06 BlackBerry Limited Verfahren und System für den TCP-Drehbetrieb hinter einer restriktiven Firewall
US9055032B2 (en) * 2013-04-12 2015-06-09 Blackberry Limited Secure network tunnel between a computing device and an endpoint

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MAHY, R.; MATTHEWS, P.; ROSENBERG, J.: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). Internet Engineering Task Force, RFC 5766 [online], April 2010 [recherchiert am 01.08.2017]. Im Internet: <URL:http://www.faqs.org/rfcs/>
ROSENBERG, J.: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. Internet Engineering Task Force, RFC 5245 [online], April 2010 [recherchiert am 01.08.2017]. Im Internet: <URL:http://www.faqs.org/rfcs/>

Also Published As

Publication number Publication date
GB2589045B (en) 2021-08-11
GB2524628B (en) 2021-06-30
GB2589045A (en) 2021-05-19
US9356915B2 (en) 2016-05-31
GB202102747D0 (en) 2021-04-14
DE102015100518A1 (de) 2015-07-30
GB201501338D0 (en) 2015-03-11
US20150215290A1 (en) 2015-07-30
CN104811435A (zh) 2015-07-29
GB2524628A (en) 2015-09-30
CN104811435B (zh) 2019-08-13

Similar Documents

Publication Publication Date Title
DE102014108888B4 (de) Virtuelle Back-to-Back-Web-Real-Time-Communications(WebRTC)-Agenten und verwandte Verfahren, Systeme und computerlesbare Medien
DE102014108903B4 (de) Skalierbare Web-Real-Time-Communications(WebRTC)-Medienengines und verwandte Verfahren, Systeme und computerlesbare Medien
DE102015104897B4 (de) Verbessern von Medieneigenschaften während interaktiver Web-Real-Time-Communications(WebRTC)-Sitzungen durch Nutzung von Session-Initiation-Protocol(SIP)-Endpunkten und verwandte Verfahren, Systeme und computerlesbare Medien
DE102007046627B4 (de) Verfahren und Vorrichtung zum Organisieren von Internet-Kommunikationsvorgängen unter Nutzung einer dynamischen STUN-Infrastrukturkonfiguration
DE102015100518B4 (de) Verbessern des Datenschutzes durch Verschleiern von Turn-Verbindungen (traversal using relays around network address translator) und damit verwandte Verfahren, Systeme und computerlesbare Medien
DE602004007301T2 (de) Adressierungs-verfahren und -vorrichtung zum aufbau von hip-verbindungen zwischen gewöhnlichen und hip-fähigen netzknoten
DE102014108904A1 (de) Virtuelle Web-Real-Time-Communications(WebRTC)-Gateways und verwandte Verfahren, Systeme und computerlesbare Medien
DE112020001459T5 (de) Konsistente Route-Ankündigungen zwischen redundanten Controllern im globalen Netzwerk-Access-Point
DE102014103209A1 (de) Ausgleichen sensorischer benutzerbeeinträchtigungen bei interaktiven web-real-time-communications(webrtc)-sitzungen und verwandte verfahren, systeme und computerlesbare medien
DE202015009251U1 (de) Netzwerkpaketkapselung und Routing
DE102016206941A1 (de) Kommunizieren über Nur-IPv6 Netzwerke unter Verwendung von IPv4 Wortkennungen
DE102014115895B4 (de) Bereitstellen eines Ursprungseinblicks für Webanwendungen über Session-Traversal-Utilities-for-Network-Address-Translation(STUN)-Nachrichten und verwandte Verfahren, Systeme und computerlesbare Medien
DE102014115893A1 (de) Bereitstellen einer intelligenten Verwaltung für interaktive Web-Real-Time-Communications(WebRTC)-Flüsse und verwandte Verfahren, Systeme und computerlesbare Medien
CN102231763A (zh) 一种基于nat穿透的共享方法
DE112019005826T5 (de) Lastverteilter Zugang zu verteilten Endpunkten unter Verwendung globaler Netzwerkadressen
CN1863157A (zh) 穿越nat实现网络通信的方法及装置
EP2193649A1 (de) Verfahren und vorrichtung zur verbindung paketorientierter kommunikationsendgeräte
US20190281611A1 (en) Traffic scheduling and processing method, user-side translator and core translator
DE112020004639T5 (de) Verwaltung verteilter endpunkte
DE112022003743T5 (de) Sichere frame-verschlüsselung als dienst
EP1593253B1 (de) Verfahren und anordnung zur transparenten vermittlung des datenverkehrs zwischen datenverarbeitungseinrichtungen sowie ein entsprechendes computerprogamm-erzeugnis und ein entsprechendes computerlesbares speichermedium
CN106878481A (zh) 一种网络互连协议ip地址获取方法、装置和系统
EP2165510B1 (de) Ressourcenzugriff unter vermittlung durch ein sicherheitsmodul
DE112021004469T5 (de) Verfahren und systeme zur effizienten virtualisierung von transparenten inline-computernetzwerkgeräten
DE102013110613B4 (de) Verteilte Anwendung von Unternehmensrichtlinien auf interaktive Web-Real-Time-Communications(WebRTC)-Sitzungen und verwandte Verfahren, Systeme und computerlesbare Medien

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000